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

Question

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

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

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

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

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

Answer 1

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

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

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

...

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

Два основных потока могут быть выдающийся, квест на Камень и квест на Эликсир.

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

...

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Некоторые функции ABSE:

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

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

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

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

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

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

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

Оставайтесь с нами ...

Answer 4

Я начал работать с модельно-ориентированными технологиями и 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 и инструменты для всех нужд. Это идеально подходит для поставщиков инструментов, но я подозреваю, что всем нужны и контексты разные.
• При использовании специальных DSL и инструментария для MDE + вам потребуются некоторые дополнительные квалифицированные разработчики, управляемые моделями, которые будут поддерживать вашу собственную фабрику программного обеспечения (разработчик моделей, расширения моделеров, генераторы ...), но вы извлекаете выгоду повсюду и управляете очень просто-точно- устойчивые модели.

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

Answer 5

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

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