Вы занимаетесь MDA (Архитектура, управляемая моделями) прямо сейчас? Если да, то какие инструменты вы используете и как это работает?

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

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

Отсутствие ответа на этот вопрос несколько зловещее ... может быть, я позволю Dijkstra поле это.

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

Как вы все помните, первой и главной целью была разработка Эликсира, который дал бы тому, кто выпил его, Вечную Молодость. Но поскольку в вечной бедности нет особого смысла, мир науки быстро приступил к реализации своего второго проекта, а именно. Философский камень, который позволит вам заработать столько золота, сколько вам нужно.

...

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

Можно выделить два основных потока: поиск Камня и поиск Эликсира.

Поиски Камня основаны на предположении, что наши «инструменты программирования» слишком слабы. Одним из примеров является вера в то, что в современных языках программирования отсутствуют необходимые нам «функции». PL / I был одним из самых впечатляющих камней, которые могли быть произведены. Я до сих пор помню рекламу в Datamation, 1968, в которой улыбающаяся Сьюзи Майер в полном цвете объявила, что она решила все свои проблемы программирования, переключившись на PL / I. Было слишком предсказуемо, что несколько лет спустя бедная Сьюзи Майер перестанет улыбаться. Излишне говорить, что квест продолжился, и в свое время был произведен следующий потенциальный камень в форме Ады (за железным занавесом, который воспринимается как PL / II). Даже самой элементарной астрологии для начинающих достаточно, чтобы предсказать, что Ада не будет последним камнем этого типа.

...

Еще одна серия камней в виде «инструментов программирования» производится под названием «программная инженерия», которая с течением времени стремилась заменить интеллектуальную дисциплину дисциплиной управления в той степени, в какой она теперь принята в качестве своего устава. «Как программировать, если не умеешь».

Я провожу собственное независимое исследование в области разработки программного обеспечения на основе моделей с 1999 года. В 2006 году я, наконец, разработал общую методологию моделирования, которую я назвал ABSE (разработка программного обеспечения на основе атома).

Итак, ABSE основывается на двух фундаментальных аспектах:

• Программирование - это декомпозиция проблемы
• Все можно изобразить на дереве

Некоторые особенности ABSE:

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

• Он достаточно универсален, чтобы его можно было применять к корпоративному программному обеспечению, встроенному ПО, играм, авионике, Интернету, фактически к любой области.

• Вам не нужно быть ученым-ракетчиком, чтобы использовать его эффективно. ABSE доступна «простому смертному разработчику». Нет никакой сложности, подобной той, что есть в цепочках инструментов oAW / MDA / XMI / GMF / и т. Д.

• Его мета-метамодель предназначена для поддержки 100% генерации кода из модели. Нет необходимости туда и обратно. Сочетание пользовательского / сгенерированного кода напрямую поддерживается метамоделью.

• Моделью можно одновременно манипулировать. Могут применяться рабочие процессы и контроль версий (требуется поддержка инструмента).

Может показаться, что это утопично, но на самом деле я покинул фазу исследования и сейчас нахожусь на стадии реализации IDE, которая реализует все вышеперечисленное на практике. Думаю, через несколько недель (примерно в конце апреля) у меня будет готов базовый прототип. IDE (названная AtomWeaver) создается посредством ABSE, поэтому AtomWeaver будет первым доказательством концепции методологии ABSE.

Итак, это не MDA (к счастью!), Но, по крайней мере, это очень управляемый подход. Как изобретатель ABSE, я, по понятным причинам, взволнован этим, но уверен, что разработка программного обеспечения на основе моделей получит импульс в 2009 году!

Быть в курсе...

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

MDA OMG - это всего лишь один подход, другие люди демонстрируют успех, используя предметно-ориентированные языки (которые не используют UML для моделирования).

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

У меня есть несколько сайтов: www.modeldrivensoftware.net и www.codegeneration.net, где вы можете получить больше обсуждений, интервью, статей и инструментов по этим темам.

Я начал работать с модельно-ориентированными технологиями и DSL в 1997 году, и у меня все больше и больше энтузиазма вызывает MDE.

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

Но я не следую стандарту MDA по нескольким причинам. MDA обещает выразить ваше программное обеспечение в модели PIM и иметь возможность автоматически преобразовывать его в один или несколько технических стеков (PSM).

Но :

• Кому нужно нацеливаться на несколько технических стеков в реальной жизни? кому нужно ориентироваться на единую и четко определенную архитектуру?
• the magic of MDA stands in the PIM->PSM transformation, but model2model transformation in an iterative and incremental way is tough :
  • model2model is much more complicated than model2text to implement, debug, maintain.
  • поскольку редко удается создать 100% программного обеспечения, необходимо добавить детали в полученную модель PSM и сохранить преобразование после преобразования. Это означает операцию слияния (трехстороннюю, чтобы запомнить добавленные детали). И когда мы имеем дело с моделями, объединение графа объектов намного сложнее, чем текстовое объединение (это работает очень хорошо).
  • вы должны иметь дело с моделью PSM (то есть с моделью, которая очень похожа на ваш окончательный сгенерированный исходный код). Это интересно для поставщика инструмента, поскольку готовые профили PSM и соответствующие генераторы кода могут продаваться и поставляться вместе с инструментом MDA.

Я выступаю за стратегии MDE, в которых PIM представляет собой DSL, который говорит о вашей логической архитектуре (независимо от какого-либо технического стека) и генерирует код из этого PIM с помощью настраиваемого и конкретного генератора кода.

Плюсы:

• вам не нужно иметь дело со сложной и технической моделью PSM. Вместо этого у вас есть код.
• Используя методы DSL, PIM становится более эффективным, устойчивым, выразительным и простым для интерпретации с помощью генераторов кода и документов. Модели остаются простыми и точными.
• он обязывает определять ваши архитектурные требования и концепции на очень раннем этапе (поскольку это ваша метамодель PIM), независимо от какого-либо технического стека. Обычно речь идет об идентификации различных типов данных, услуг, компонентов пользовательского интерфейса с их определением, возможностями и функциями (атрибуты, ссылки на другие концепции; ...).
• сгенерированный код соответствует вашим потребностям, так как он индивидуален. И вы можете сделать это еще проще, если ваш сгенерированный код расширяет некоторые дополнительные классы фреймворка, поддерживаемые вручную.
• you capitalize knowledge in several orthogonal ways :
  • models capitalize the functionalities / business
  • Генераторы кода извлекают выгоду из решений технического сопоставления от ваших логических архитектурных компонентов до определенного технического стека.
  • PIM DSL - это определение вашей логической архитектуры
• с помощью PIM, ориентированного на логическую архитектуру, можно сгенерировать весь технический код и другие файлы, не относящиеся к коду (конфигурации, свойства, ...). Разработчики могут сосредоточиться на реализации бизнес-функций, которые не могут быть полностью выражены с помощью модели, и, как правило, им больше не нужно иметь дело с техническим стеком.
• Операции слияния - это все о файлах с плоским исходным кодом, и это работает очень хорошо.
• вы по-прежнему можете определить несколько генераторов кода, если вы нацелены на несколько технических стеков.

Минусы:

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

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

Большую разницу между MDA и MDE можно резюмировать следующим образом:

• MDA - это набор инструментов и языков общего назначения, предоставляющий готовые профили MD и инструменты для любых нужд. Это идеально подходит для поставщиков инструментов, но я подозреваю, что потребности и контексты у всех разные.
• Благодаря DSL и инструментам для MDE + вам потребуются дополнительные опытные разработчики, управляемые моделями, которые будут поддерживать вашу фабрику нестандартного программного обеспечения (разработчик моделей, расширения для моделистов, генераторы ...), но вы извлекаете выгоду везде и управляете очень простыми, точными и устойчивыми моделями.

Между этими двумя подходами существует своего рода конфликт интересов. Один выступает за повторное использование готовых прекапитализированных компонентов, управляемых моделями, а в другом - вы сами делаете заглавные буквы, определяя DSL и связанные с ними инструменты.

Мы действительно используем MDA и EMF в качестве инструментов. Это экономит нам много человеко-часов за счет генерации кода вместо написания кода вручную. Это действительно требует высокой квалификации аналитиков, но в этом и суть ИТ. Таким образом, мы в основном сосредоточились на самих проблемах, а также на инструментах / фреймворках, которые выполняют генерацию кода и поддержку сгенерированного кода во время выполнения. Наконец, я могу подтвердить, что с MDA мы действительно увеличиваем производительность в 10 раз.