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

Question

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

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

Однако это всего лишь теория. Мне интересно, каковы результаты, когда резина встречается с дорогой. Кроме того, "официальная" версия MDA от OMG, и кажется очень тяжелой. Он в значительной степени основан на UML, который можно считать хорошим или плохим, в зависимости от того, кого вы спрашиваете (я склоняюсь к "плохому").

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

Итак, я хотел бы услышать от людей, которые действительно делают MDA прямо сейчас ("официальный" или нет). Какие инструменты вы используете? Как это работает? Какую часть теоретического обещания вы смогли уловить? Вы видите увеличение эффективности в 10 раз?

Answer 1

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

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

Answer 2

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

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

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

...

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

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

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

...

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

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

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

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

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

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

Оставайтесь в курсе...

Answer 5

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

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

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

Но:

• кому нужно нацелиться на несколько технических стеков в реальной жизни? кому нужно ориентироваться на одну и четко определенную архитектуру?
• магия MDA заключается в преобразовании PIM->PSM, но преобразование model2model итеративным и инкрементным способом является сложным:
  • model2model гораздо сложнее, чем model2text, реализовать, отладить, поддерживать.
  • так как на 100% невозможно сгенерировать программное обеспечение, необходимо добавить детали к полученной модели PSM и сохранить преобразование после преобразования. Это означает операцию слияния (трехстороннюю, чтобы запомнить добавленные детали). А при работе с моделями объединение графа объектов гораздо сложнее, чем текстовое слияние (это работает довольно хорошо).
  • вам приходится иметь дело с моделью PSM (то есть моделью, которая выглядит очень близко к вашему окончательному сгенерированному исходному коду). Это интересно поставщику инструмента, поскольку готовые к использованию профили PSM и связанные генераторы кода могут продаваться и поставляться с инструментом MDA.

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

Плюсы:

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

Минусы:

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

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

Большая разница между MDA и MDE может быть обобщена как:

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

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

Answer 6

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