Почему мы все еще не занимаемся разработкой на основе моделей? [закрыто]

Я - настоящий сторонник разработки, управляемой моделями, я думаю, что у нее есть возможность повысить производительность, качество и предсказуемость. При взгляде на MetaEdit результаты просто потрясающие. Mendix в Нидерландах растет очень быстро и имеет отличные результаты.

Я также знаю, что есть много проблем

• управление версиями генераторов, шаблонов и фреймворка
• проекты, которые просто не подходят для модельно-ориентированной разработки (недостаточно повторений)
• более высокие риски (когда первый проект терпит неудачу, у вас меньше результатов, чем при более традиционной разработке)
• и т.д

Но все же эти проблемы кажутся решаемыми, и выгоды должны перевешивать необходимые усилия.

Вопрос : Что вы видите в качестве самых больших проблем, которые заставляют вас даже не думать о модельно-ориентированной разработке?

Я хочу использовать эти ответы не только для собственного понимания, но и как возможный источник для серии внутренних статей, которые я планирую написать.

Там нет золотого молотка. То, что хорошо работает в одном домене, бесполезно в другом. В разработке программного обеспечения есть некоторая сложность, и никакой волшебный инструмент не удалит его.

Можно также утверждать, что генерация кода полезна только в том случае, если сам язык (или структура) недостаточно высокоуровнев, чтобы учесть мощные абстракции, которые сделали бы MDD относительно бессмысленным.

Интересный вопрос! Признаюсь, я не фанат, но затем я несколько раз пытался использовать разработку, основанную на моделях, в проектах, которые подходят для некоторых вопросов, которые вы только что подняли.

Вот мой список причин:

• Кривая обучения - инструменты моделирования развиваются так быстро, что мне трудно найти инженеров, которые глубоко разбираются в этом инструменте. Я все еще нахожу, что вы так же хороши, как ваш инструмент моделирования. Следует признать, что многие из приведенных ниже проблем могут быть связаны с этой одной проблемой - когда вы считаете, что инструмент слишком ограничен, возможно, вы недостаточно хорошо его знаете.
• Слишком структурированный - лично я был в ситуациях, когда обнаруживал, что инструмент моделирования был слишком структурирован, чтобы позволить мне описать все, что мне нужно было описать. И как только я переключаюсь на рисование некоторых частей модели вне инструмента, все быстро затухает, когда люди начинают перемещаться за пределы инструмента, чтобы найти информацию.
• Затраты на настройку инструмента - каждый раз, когда я пытался автоматически сгенерировать код, я заканчивал тем, что вручную дорабатывал код, как только увидел, что инструмент считал правильным. Я знаю, что после нескольких обходов эта проблема уменьшается, но это означает, что вы должны выжить в первые несколько обходов. Я обычно чувствовал, что мы играем в кроль - сделай модель -> сгенерируй код -> исправь код -> обнови модель -> исправь модель, промой и повторить.
• Управление конфигурацией модели - поскольку модель описывает большие части проекта, на некотором уровне модель CM будет более сквозной, чем встроенный код. Совместное использование файлов моделирования само по себе является искусством - делайте это неправильно, и вы часто сталкиваетесь с тупиком разработчика или устаревшими моделями, когда люди сдаются и переходят к коду.
• время выхода на рынок - у меня возникли определенные проблемы, когда в ситуации, когда необходимость в работе программного обеспечения была срочной. Если проект и команда достаточно малы, я не вижу смысла тратить время на инструмент моделирования, когда можно потратить время на кодирование и тестирование. Не каждый проект достаточно велик, чтобы требовать таких инвестиций.
• Стоимость неудачи - когда я видел, как проекты убегают от инструментов моделирования, это связано с высокой стоимостью неудачи - чтобы использовать инструменты, нужно участие каждого разработчика. Это большие инвестиции в обучение и практическое обучение, и очень дорогая ошибка, если кто-то плохо настроил модель. Мой опыт показывает, что для правильной модели может потребоваться два или три выпуска - так много проектов не выдерживают ошибок моделирования достаточно долго, чтобы реализовать преимущества.

Это уже процитировано, но « Серебряная пуля» не решает проблему очень хорошо:

Сущность программного объекта - это конструкция взаимосвязанных понятий: наборы данных, отношения между элементами данных, алгоритмы и вызовы функций. Эта сущность абстрактна тем, что такая концептуальная конструкция одинакова для многих разных представлений. Тем не менее, он очень точный и богато детализированный.

Я считаю, что трудной частью создания программного обеспечения является спецификация, проектирование и тестирование этой концептуальной конструкции, а не труд ее представления и проверка точности представления. Мы все еще делаем ошибки синтаксиса, чтобы быть уверенным; но они неясны по сравнению с концептуальными ошибками в большинстве систем.

Если это правда, создание программного обеспечения всегда будет трудным. По сути, нет серебряной пули.

Позже Брукс отмечает следующее о понятии «автоматическое программирование»:

В течение почти 40 лет люди ожидали и писали об «автоматическом программировании» или создании программы для решения проблемы из формулировки спецификаций проблемы. Некоторые сегодня пишут, как будто они ожидают, что эта технология обеспечит следующий прорыв.

Парнас подразумевает, что этот термин используется для обозначения гламура, а не для семантического контента, утверждая: «Короче говоря, автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем было доступно в настоящее время программисту».

По сути, он утверждает, что в большинстве случаев это метод решения, а не проблема, спецификация которой должна быть дана.

По сути, я бы сказал, что MDD - это просто еще один эвфемизм для программирования на языке более высокого уровня, чем это было раньше.

Нельзя сказать, что программирование на языке более высокого уровня не может помочь - на самом деле это часто может. Но суть проблемы остается той же: независимо от того, какой прекрасный инструмент или какой язык вы используете, в конце дня вам нужно продумать все проблемы и решить их. Лучшее, что может сделать любой инструмент или любой процесс, - это удалить «нечеткость», чтобы вы могли сосредоточиться на важной проблеме, а именно, как сказал Брукс, « спецификация , проектирование и тестирование этой концептуальной конструкции ».

Потому что не все программирование является объектно-ориентированным, чего ожидают все инструменты MDD. Сам UML основан на презумпции объектов. Конечно, вы можете использовать диаграммы последовательности для моделирования функций, но часто это неуклюже.

Потому что есть такие программисты, как я, которые получают больше прогресса и результатов от TDD, чем от MDD.

Потому что моделирование! = Программирование.

Потому что цена / выгода были слишком высоки на стороне затрат и недостаточны на стороне выгоды. Вероятно, это изменилось с тех пор, как я в последний раз смотрел на MDD, тогда вам пришлось бы платить> 6000 долларов США / место (USD) за инструмент, который был бы умеренно способен к MDD.

Потому что модель, которая в достаточной мере описывает функцию для генерации кода, больше не используется в качестве модели.

Потому что есть такие программисты, как я, которые используют модели только на высоком уровне, а затем прорабатывают детали с помощью кода. В коде вы видите вещи иначе, чем в программном обеспечении для моделирования.

Это некоторые из причин, почему я лично не делаю MDD. Я был подвержен этому, но ничто не смогло сделать меня новообращенным. Возможно, я слишком старая школа. Возможно, я слишком новая школа (что бы это ни было). Это просто не тот инструмент, за который я смог заплатить сам.

Microsoft / Apple / Google не продвигает это :)

То, как развитие становится популярным, во многом связано с инструментами, покровителем и евангелизацией. Очень трудно что-то пробить, не имея большого покровителя (возможно, Ruby на рельсах является исключением, но он все еще мал по сравнению с Java / C # / Python)

Из-за простого закона, который влиял на все эти инструменты моделирования, вы знаете, CASE, UML и такие:

Попасть между программистом и его кодом очень дорого.

Если вы это сделаете, вам нужно создать правильный компилятор / интерпретатор, генераторы кода приводят к ужасному рабочему процессу и ужасной обратной связи с программистом (сообщения об ошибках и тому подобное).

Одна из замечательных идей Domain Driven Design заключается в том, что модели должны быть в коде, а не во внешнем коде.

В конечном итоге вопрос заключается в следующем: почему ваши модели не вписываются в код? Если вы занимаетесь разработкой встраиваемых систем и застряли на C или вам нужно генерировать код для разных платформ, генерация кода может стоить затрат. Для всех остальных более мощный язык программирования и лучший дизайн кода, как правило, лучше, чем проектирование кода в чем-то отличном от кода.

• Похоже на гигантские хлопоты за очень небольшую выгоду.
• Мне всегда кажется, что я пью с крайними случаями и странными вещами, магические вещи, кажется, никогда не работают правильно.
• Оо не серебряная пуля; капля методологии генерации программного обеспечения на ОО не делает ее серебряной.

Но я не люблю корпоративных решений в целом.

У меня была дискуссия, и я хотел бы сделать MDA, но самый большой недостаток - это поддержка инструментов на данный момент. Я использую деривацию MDA, которую я люблю называть «Оценка модели времени выполнения», но об этом позже.

Недостатки MDA, как я знаю:

• Отсутствует поддержка рефакторинга: Предположим, я хочу смоделировать сущности моей модели данных с помощью MDA (Типичный вариант использования № 1). Если у меня есть моя модель, скажем, на UML-диаграмме, и я меняю ее, ничего из моего кода с ней не меняется (по крайней мере, сгенерированные классы), и вместо того, чтобы все еще иметь работающее приложение с более качественными именованными атрибутами, я получаю Много ошибок я должен исправить вручную.
• Отсутствует поддержка отладки. Обычно переводы из модели в код выполняются при наличии некоторого языка преобразования. Обычно это не проблема, но когда мы отлаживаем, мы не должны беспокоиться о сгенерированном коде, а отладчик должен войти в модель преобразования. Вместо этого он входит в сгенерированный код, и, как мы все знаем, преобразования должны выглядеть хорошо, а не сгенерированный код. Хорошо, мы можем напечатать это, но в оптимальном мире сгенерированный код является артефактом компилятора, и его никогда не нужно открывать в редакторе для сеанса отладки (я мог бы жить с этим, и этот аргумент немного теоретический, но это одна из причин против мда)
• Кодированные модели просты: в других примерах модель может моделировать некоторый аспект предметной области, который затем компилируется в код. Да, это MDA, но большинство моделей MDA представляют собой просто сложные файлы конфигурации, которые можно легко обрабатывать во время выполнения.
• Преобразования трудно проверить: если вы используете преобразования в специализированной среде IDE, они выполняются "компилятором" среды IDE. Но преобразования должны рассматриваться как часть кода приложения, и как таковые также должны проходить требования приложения к тестированию и покрытию кода.

То, что я сейчас предпочитаю, это «Оценка модели времени выполнения» (если кто-то знает для этого приемлемое имя, пожалуйста, просветите меня). Мои сущности хранятся в обычных классах Java, и все, что мне нужно для «моделирования», сделано с помощью аннотаций, которые я читаю в начале приложения. Никаких преобразований не требовалось, просто было немного сложно понять мою метамодель.

Все остальное делается либо с помощью файлов свойств, либо с помощью XML для иерархических данных. Если у вас есть модель, она всегда иерархическая, поэтому вы не можете моделировать ничего, что нельзя выразить и с помощью XML. И если вам нужен специальный редактор моделей, который вам, вероятно, придется написать, вы также можете создать редактор, который работает даже во время выполнения приложения и делает приложение более настраиваемым, чем все, что вы можете моделировать.

Я чувствую, что большинство людей, использующих «Нет серебряной пули» Фреда Брукса, чтобы объяснить, почему люди не делают MDD, упускают суть, которую делает Брукс. Конечно, окончательный вывод заключается в том, что действительная внутренняя сложность в разработке программного обеспечения никогда не исчезнет, ​​и поэтому MDD не решит эту проблему.

Но одна из причин, по которой Брукс даже обсуждает эту внутреннюю сложность, состоит в том, чтобы сравнить ее с большим количеством времени, которое мы обычно тратим на борьбу с языками, библиотеками и инструментами, то есть не имея дело с внутренней сложностью проблемы, которую мы пытаемся решить. Так что именно в этом и заключается сияние MDD: устранение всех размышлений и создание адаптированного языка, модели или другого формализма для решения реальной сложности под рукой.

Таким образом, с этой точки зрения, Silver Silver Bullet не является отличной причиной для инвестиций в MDD. То есть, если бы не проблема, которая, по моему мнению, препятствует внедрению MDD: фактическая разработка модели-управляемой среды, которая позволяет полностью сосредоточиться на внутренней сложности проблемы, которую вы пытаетесь решить, гораздо сложнее, чем просто решить проблему на языке общего назначения напрямую. Главным образом потому, что существующие инструменты MDD чрезвычайно сложны.

Сравните это так: гораздо проще написать программу на C, чем написать компилятор C. Вместо того, чтобы просто решать проблему и разбираться с фракцией на языке общего назначения, создание среды MDD для других разработчиков требует от вас написания программы, которая решает все возможные проблемы, связанные с фрифтом, в пространстве проблем заранее. Это довольно сложно.

Насколько мне известно, MDE и MDA недостаточно удовлетворяют потребности разработчика встроенного контроллера. Модели, безусловно, можно использовать для описания системы, но я не думаю, что разработчик встраиваемых систем готов доверять модели для предоставления лучшего или даже правильного исходного кода.

Для Eclipse существует ряд плагинов, которые позволяют разработчику использовать либо модель для создания / обновления кода Java, либо код Java для создания / обновления модели. Это похоже на удобный инструмент. К сожалению, все мои разработки выполнены на ANSI / ISO C, и я не знаю никаких плагинов, которые позволили бы мне делать то же самое.

Кроме того, как разработчик может дать указание модели реализовать код как управляемый событиями HSM или какой-либо другой шаблон проектирования поверх любого другого шаблона проектирования (или анти-шаблона)? Если код обновляется вручную для использования неизвестного шаблона проектирования, может ли модель точно изобразить это?

Как вы реализуете те функции, которые не вписываются в модель?

Короткий ответ… потому что управляемая моделью часто связана с генерацией кода, а код хрупок; что нам нужно, так это устранение кода, и модель, управляемая моделью, безусловно, является подходящим способом.

Некоторые отклонили вопрос, утверждая, что золотого молотка не существует и что разработка программного обеспечения по своей сути сложна.

Я полностью согласен с ними в том, что золотого молотка нет, но я не думаю, что управляемая модель - это поиск золотых молотков или серебряных пуль!

Я хотел бы пойти дальше со сложностью; Есть два вида сложности, которые я называю органической или естественной сложностью, сложность, которая присуща бизнесу и его процессам, но у нас также есть церемониальная сложность.

Сложность, которая проникает в системную инструкцию по инструкции, день за днем. Церемониальная сложность - ненужная сложность - возникает в основном из-за неконтролируемого искажения технического кода с помощью бизнес-ориентированного кода, а также из-за отсутствия структуры и единообразия в системе.

Сегодня вся сложность, которая преследует развитие информационных систем и вызывает отказ и талию, - это церемониальная сложность; сложность, которая может быть устранена.

Церемониальная сложность - это пустая трата, трата, вызванная кодом, меньшая стоимость, изменение неблагоприятного, инвариантного кода; код, который должен быть сведен к своему строгому минимуму.

Как это сделать? Просто! Просто не пиши и не генерируй, во-первых!

Необходимый, инвариантный технический код; код, который используется для чтения / записи, отображения, общения ... Вот где модели попадают, описывая логическую структуру данных - я бы добавил реляционным способом - модели могут обеспечивать общую обработку стандартного чтения / записи, отображения и передачи данные.

Это как операционная система, вы не переписываете ее для каждого проекта, который вы используете. Поэтому необходим технический движок, который обрабатывает инвариантные аспекты программного обеспечения для данной модели. Я называю это движком AaaS (архитектура как услуга).

Что касается ненужного кода, то это ненужный код, поэтому он может оставить его неписанным.

Это оставляет нам необходимый бизнес-ориентированный код, который должен быть написан, необходимые бизнес-ориентированные данные, которые должны быть разработаны, и необходимый пользовательский интерфейс и опыт, который должен быть спроектирован и представлен.

Устраняя хрупкий код, мы можем использовать архитектуру как услугу в качестве новой парадигмы разработки программного обеспечения, основанной в большей степени на моделировании и проектировании, чем на коде.

Я считаю, что есть несколько причин, но одна из них точно состоит в том, что MDD не входит в учебную программу университетов. Обычно самым близким является курс, который учит моделированию, и там модели остаются в виде эскизов (без проверки, генерации кода, отладки на уровне модели). Этот курс «моделирования» часто также знакомит с UML, и студенты ломают голову, зачем изучать такие большие и сложные обозначения, когда ценность создаваемых моделей невысока.

Сравните это с другими областями разработки, такими как разработчики встроенного оборудования или инженеры-контроллеры, где студенты получают совершенно другой опыт. С помощью таких инструментов, как Simulink или Labview, студенты могут нарисовать модель, а затем она сгенерирует вам код, или, по крайней мере, вы сможете запустить его в симуляции.

В прошлых университетах преподавали компиляторы и парсеры, но теперь они должны учить, как создавать генераторы, реализовывать DSL и т. Д.

Модельно-управляемая разработка не имеет смысла, потому что это нисходящая модель для подхода к коду. Невозможно создать полнофункциональное приложение только из модели, поэтому MDD бесполезен !!

Я использую UML только на более высоком уровне абстракции для создания каркаса моего приложения. Я имею в виду создание пакетов, классов и т. Д., А затем немедленно приступить к программированию на языке Java.

Я обнаружил, что живая синхронизация с такими инструментами, как Togethersoft, Omondo, была действительно полезна, когда я впервые начал моделировать в 2004 году. Недавно Omondo представила новый этап, который является своего рода отображением между Java, моделью и идентификатором базы данных. Действительно мощный и хорошо работает в моих проектах.

Мои UML-диаграммы помогают мне ускорить мой проект и больше не бесполезны :-)

MDD добавляет еще один шаг к процессу разработки, который является недостатком в ситуациях, когда нет хорошей модели, и первое непредсказуемое или почти сломанное частичное решение рынка вполне может выиграть большинство мраморов.

Холли Грааль был иметь исполняемые модели бизнес-процессов. Теоретически для этого вам вообще не понадобятся программисты. Практика показывает, что с MDE заставить работать реальную модель так же сложно, как писать код.

Я бы сказал, что для опытного разработчика было бы намного легче заполнять классы, сгенерированные из UML, чем беспокоиться, например, о ExecutableUML. С другой стороны, для ExecutableUML вам необходимы значительные знания в области компьютерных наук, поэтому вы не можете рассчитывать на то, что бизнес-менеджер создаст это самостоятельно. Теоретически он просто объединяет готовые блоки (классы), но на самом деле именно «клей» вызывает проблемы.

Кроме того, полезность MDE ограничена системами с большим повторным использованием компонентов.

MBSE - разработка программного обеспечения на основе моделей - более подходящий термин.

Ставя вопрос о различных инструментах, которые являются точечными решениями, MBSE требует другого рабочего процесса проекта. DSML (предметно-ориентированный язык моделирования) должен быть на уровне абстракции, необходимой для эффективной передачи требований для рассмотрения заинтересованным сторонам. Затем вам необходимо трансформировать модель через все возрастающие уровни уточнения, чтобы в конечном итоге генерировать код.

Когда вы полностью и правильно внедрили процессы DSML и преобразования / генерации, генерация артефактов будет стоить очень дешево. Но пока вы не достигнете этой стадии отладки, это будет очень больно.

Большинство историй успеха для MDD находятся в области Product Line Engineering (PLE), где последовательность подобных продуктов генерируется с использованием установленного инструментария. Конечно, многие из генераторов кода Java являются действительно упрощенными версиями MDD. Некоторый XML в и сгенерированный код.

Вы написали:

Я также знаю, что есть много проблем ... проекты, которые просто не подходят для разработки на основе моделей (недостаточно повторений)

Если ваш код повторяется, то вы либо выбрали плохой язык программирования, либо используете его плохо. С лучшими языками нет необходимости повторяться. Рассмотрим библиотеку Ruby Active Record. Таблицы базы данных создаются путем написания миграций. Нет необходимости повторять определение схемы в любом другом месте. Вам не нужно определять класс с элементами данных, соответствующими столбцам таблицы. Одна строка кода соединяет класс с таблицей.

Я рассматриваю разработку на основе моделей как сложный и неэффективный обход слабых языков программирования.