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

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

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

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

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

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

9
architecture mda

5 ответов

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

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

0

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

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

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

...

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

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

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

...

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

6

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

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

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

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

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

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

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

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

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

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

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

следите за обновлениями...

4

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

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

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

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

4

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

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

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

но :

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

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

плюсы :

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

минусы :

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

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

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

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

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

0