Модельно-управляемая архитектура - Model-driven architecture

Модельно-управляемая архитектура (MDA) это разработка программного обеспечения подход к развитию программные системы. Он предоставляет набор руководящих принципов для структурирования спецификаций, которые выражаются как модели. Модельно-ориентированная архитектура - это своего рода доменная инженерия, и поддерживает модельно-ориентированная инженерия программных систем. Он был запущен Группа управления объектами (OMG) в 2001 году.[1]

Обзор

Тогда, учитывая платформенная модель соответствующий CORBA, .СЕТЬ, Интернет и т. д., платформо-независимая модель (PIM) переводится в один или несколько модели для конкретных платформ (PSM), которые могут запускать компьютеры. Это требует сопоставлений и преобразований и тоже должно моделироваться.

Организация OMG предоставляет приблизительные спецификации, а не реализации, часто как ответы на Запросы предложений (RFP). Реализации поступают от частных компаний или групп с открытым исходным кодом.

Связанные стандарты

Модель MDA связана с несколькими стандартами, включая Единый язык моделирования (UML), Мета-объектный объект (MOF), Обмен метаданными XML (XMI), Корпоративные распределенные объектные вычисления (EDOC), Метамодель программных процессов (SPEM), а Метамодель Common Warehouse (CWM). Обратите внимание, что термин «архитектура» в архитектуре, управляемой моделями, относится не к архитектуре моделируемой системы, а к архитектуре различных стандартов и форм моделей, которые служат технологической основой для MDA.

Исполняемый UML был профиль UML, который использовался при рождении MDA. Теперь OMG продвигает fUML вместо этого. (Язык действий для fUML - ALF.)

Торговая марка

В Группа управления объектами владеет зарегистрированными товарными знаками термина «Архитектура, управляемая моделями» и его аббревиатурой MDA, а также товарными знаками для таких терминов, как: Разработка приложений на основе моделей, Разработка приложений на основе моделей, Разработка приложений на основе моделей, Программирование на основе моделей, Системы на основе моделей и другие.[2]

Темы об архитектуре, управляемой моделями

Подход MDA

OMG фокусирует управляемую на модели архитектуру на перспективном проектировании, то есть создании кода из абстрактных, созданных человеком диаграмм моделирования (например, диаграмм классов).[нужна цитата ]. Группа OMG ADTF (Рабочая группа по анализу и проектированию) возглавляет эту работу. С некоторой долей юмора группа выбрала ADM (наоборот, MDA), чтобы назвать исследование обратным проектированием. ADM декодирует модернизацию на основе архитектуры. Задача ADM - разработать стандарты для модельного обратного проектирования унаследованных систем.[3] Метамодель открытия знаний (KDM) является наиболее продвинутым из этих направлений и описывает информационные системы с точки зрения различных активов (программ, спецификаций, данных, тестовых файлов, схем баз данных и т. Д.).

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

Особое значение для управляемой моделями архитектуры имеет понятие преобразование модели. Конкретный стандартный язык для преобразования модели был определен О, мой бог называется QVT.

Инструменты MDA

Организация OMG предоставляет приблизительные спецификации, а не реализации, часто как ответы на Запросы предложений (RFP). OMG документирует общий процесс в документе, который называется MDA Guide.

По сути, инструмент MDA - это инструмент, используемый для разработки, интерпретации, сравнения, согласования, измерения, проверки, преобразования и т. Д. Моделей или метамоделей.[4] В следующем разделе «модель» интерпретируется как означающая любой тип модели (например, модель UML) или метамодель (например, метамодель CWM). В любом подходе MDA есть два основных типа моделей: начальные модели создаются вручную агентами человека, в то время как производные модели создаются автоматически программами. Например, аналитик может создать начальную модель UML на основе наблюдения за некоторой нечеткой бизнес-ситуацией, в то время как модель Java может быть автоматически получена из этой модели UML посредством Преобразование модели операция.

Инструмент MDA может быть инструментом, используемым для проверки моделей на полноту, несоответствие или условия ошибок и предупреждений. Также используется для расчета показателей модели.[5]

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

Спецификации OMG реализованы частными компаниями или Открытый исходный код группы. Одним из важных источников реализации спецификаций OMG является Фонд Затмения (EF). Многие реализации стандартов моделирования OMG можно найти в Среда моделирования Eclipse (ЭДС) или Платформа графического моделирования (GMF) фонд Eclipse также разрабатывает другие инструменты различного профиля, такие как GMT. Соответствие Eclipse спецификациям OMG часто не является строгим. Это верно, например, для стандарта OMG EMOF, который EMF аппроксимирует своей реализацией Ecore. Больше примеров можно найти в проекте M2M, реализующем стандарт QVT, или в проекте M2T, реализующем стандарт MOF2Text.

Следует быть осторожным, чтобы не перепутать Список инструментов MDA и Список инструментов UML, причем первое намного шире. Это различие можно сделать более общим, разделив «инструменты переменной метамодели» и «фиксированные инструменты метамодели». Инструмент UML CASE обычно представляет собой «фиксированный инструмент метамодели», поскольку он жестко запрограммирован для работы только с данной версией метамодели UML (например, UML 2.1). Напротив, у других инструментов есть внутренние общие возможности, позволяющие им адаптироваться к произвольным метамоделям или к метамоделям определенного типа.

Обычно инструменты MDA фокусируются на элементарной спецификации архитектуры, хотя в некоторых случаях инструменты не зависят от архитектуры (или платформы).

Простые примеры спецификаций архитектуры включают:

  • Выбор одного из поддерживаемых эталонные архитектуры подобно Java EE или Microsoft .NET,
  • Определение архитектуры на более тонком уровне, включая выбор технологии уровня представления, технологии уровня бизнес-логики, технологии сохраняемости и технологии отображения устойчивости (например, объектно-реляционного преобразователя).
  • Метаданные: информация о данных.

Проблемы MDA

Некоторые ключевые концепции, лежащие в основе подхода MDA (запущенного в 2001 г.), были впервые разъяснены Шлаер-Меллор метод в конце 1980-х. Действительно, отсутствующий ключевой технический стандарт подхода MDA (синтаксис языка действий для Исполняемый UML ) был преобразован некоторыми поставщиками путем адаптации оригинального языка действий Шлаера-Меллора (модифицированного для UML)[нужна цитата ]. Однако в этот период подход MDA не получил широкого признания в отрасли; с Gartner Group все еще идентифицируя MDA как «набирающую силу» технологию в 2006 году »Цикл шумихи ",[6] и Forrester Research объявление MDA "D.O.A." в 2006 году.[7] Потенциальные проблемы, которые были подняты в связи с подходом OMG MDA, включают:

  • Неполные стандарты: подход MDA подкреплен множеством технических стандартов, некоторые из которых еще не определены (например, семантический язык действий для xtUML ) или еще не реализованы стандартным образом (например, QVT двигатель трансформации или PIM с виртуальной средой выполнения).[8][9]
  • Привязка к поставщику: хотя MDA задумывался как подход к достижению (технической) независимости от платформы, нынешние поставщики MDA неохотно разрабатывают свои наборы инструментов MDA для обеспечения взаимодействия. Такой результат может привести к привязке к поставщику для тех, кто придерживается подхода MDA.[нужна цитата ]
  • Идеалистический: MDA задуман как прямой инженерный подход, в котором модели, включающие программирование на языке действий, преобразуются в артефакты реализации (например, исполняемый код, схему базы данных) в одном направлении с помощью полностью или частично автоматизированного этапа «генерации». Это согласуется с видением OMG, что MDA должна позволять моделировать полную сложность проблемной области в UML (и связанных стандартах) с последующим преобразованием в законченное (исполняемое) приложение.[10] Однако этот подход подразумевает, что изменения артефактов реализации (например, настройка схемы базы данных) не поддерживаются. Это составляет проблему в ситуациях, когда такая пост-трансформационная «адаптация» артефактов реализации считается необходимой. Доказательства того, что полный подход MDA может быть слишком идеалистичным для некоторых развертываний в реальном мире, были замечены в появлении так называемого «прагматичного MDA».[11] Pragmatic MDA сочетает в себе буквальные стандарты OMG MDA с более традиционными механизмами, управляемыми моделями, такими как двусторонняя инженерия который обеспечивает поддержку для адаптации артефактов реализации.
  • Специализированные наборы навыков: от специалистов по разработке программного обеспечения на основе MDA (как и в случае с другими наборами инструментов) требуется высокий уровень знаний в своей области. Текущие эксперты-практики MDA (часто называемые моделистами / архитекторами) немногочисленны по сравнению с доступностью традиционных разработчиков.[12]
  • Послужной список OMG: Консорциум OMG, который спонсирует подход MDA (и владеет торговой маркой MDA), также представил и спонсировал стандарт CORBA, который сам по себе не стал широко используемым стандартом.[13]
  • Предложение с неопределенной ценностью (UVP): Как уже говорилось, видение MDA позволяет специфицировать систему как абстрактную модель, которая может быть реализована как конкретная реализация (программа) для конкретной вычислительной платформы (например, .NET). Таким образом, приложение, которое было успешно разработано с использованием чистого подхода MDA, теоретически может быть портировано на платформу .NET более новой версии (или даже платформу Java) детерминированным образом, хотя остаются серьезные вопросы относительно практических аспектов перевода (например, как реализация пользовательского интерфейса). Вопрос о том, представляет ли эта возможность существенное ценностное предложение, остается для конкретных пользователей. Тем не менее, приверженцы MDA, которые ищут ценности через «альтернативу программированию», должны быть очень осторожны при оценке этого подхода. Сложность любой данной проблемной области всегда будет оставаться, и программирование бизнес-логики должно осуществляться в MDA, как и в любом другом подходе. Отличие от MDA состоит в том, что используемый язык программирования (например, xtUML) является более абстрактным (чем, скажем, Java или C #) и переплетается с традиционными артефактами UML (например, диаграммами классов). Является ли программирование на языке более абстрактном, чем мейнстрим 3GL языки приведут к созданию систем более высокого качества, более низкой стоимости или более быстрой доставки - это вопрос, на который еще предстоит найти адекватный ответ.
  • MDA была признана возможным способом объединения различных независимо разработанных стандартизированных решений. Для сообщества симуляторов он был рекомендован в качестве коммерческой и отраслевой альтернативы еще одному стандарту, утвержденному Министерством обороны США.[14]

Споры о создании кода

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

Часто цитируемая критика заключается в том, что диаграммам UML просто не хватает деталей, которые необходимы для того, чтобы содержать ту же информацию, которая содержится в исходном коде программы. Некоторые разработчики даже заявляют, что «Код является дизайн".[15][16]

Смотрите также

Рекомендации

  1. ^ «OMG следует новому стратегическому направлению, чтобы развить успех прошлых усилий» В архиве 2006-09-24 на Wayback Machine
  2. ^ http://www.omg.org/legal/tm_list.htm
  3. ^ сайт ADM http://adm.omg.org
  4. ^ Безивен, Дж., Жерар, С., Мюллер, П.А., и Риу, Л. (2003). «Компоненты MDA: вызовы и возможности» (PDF). В: Метамоделирование для MDA. Архивировано из оригинал (PDF) на 2006-12-06. Цитировать журнал требует | журнал = (Помогите)CS1 maint: несколько имен: список авторов (ссылка на сайт)
  5. ^ Монперрус, Мартин; Жезекель, Жан-Марк; Шампо, Жоэль; Hoeltzener, Бриджит (2008). «Подход к измерению на основе модели». Инженерные языки и системы на основе моделей. Конспект лекций по информатике. 5301. С. 505–519. Дои:10.1007/978-3-540-87875-9_36. ISBN  978-3-540-87874-2. ISSN  0302-9743.
  6. ^ "Цикл ажиотажа в отношении новых технологий, 2006 г." $495.00
  7. ^ «MDA - это DOA, отчасти благодаря SOA» В архиве 2007-10-13 на Wayback Machine
  8. ^ «UML - унифицированный или универсальный язык моделирования? UML2, OCL, MOF, EDOC - у императора слишком много одежды»
  9. ^ «MDA: Хорошая идея. Позор за ...»
  10. ^ «Внедрение MDA в Eclipse с использованием прагматичного подхода»
  11. ^ "Ответ Forrester"
  12. ^ "Готовы ли вы к MDA?"
  13. ^ "Взлет и падение CORBA" В архиве 2008-12-02 в Wayback Machine
  14. ^ «Как избежать еще одного зеленого слона»
  15. ^ http://www.developerdotstar.com/mag/articles/reeves_design_main.html Джек В. Ривз
  16. ^ Bleading-Edge

дальнейшее чтение

  • Кевин Лано. «Модельно-ориентированная разработка программного обеспечения с использованием UML и Java». CENGAGE Learning, ISBN  978-1-84480-952-3
  • Дэвид С. Франкель. Архитектура, управляемая моделями: применение MDA к корпоративным вычислениям. Джон Уайли и сыновья, ISBN  0-471-31920-1
  • Меган Киффер Журнал MDA: Архитектура, управляемая моделями, от мастеров. ISBN  0-929652-25-8
  • Аннеке Клеппе (2003). Объяснение MDA, Архитектура, управляемая моделями: практика и перспективы. Эддисон-Уэсли. ISBN  0-321-19442-X
  • Стивен Дж. Меллор (2004). MDA Distilled, Принципы модельно-управляемой архитектуры. Эддисон-Уэсли Профессионал. ISBN  0-201-78891-8
  • Крис Рейстрик. Архитектура на основе модели с исполняемым UML. Издательство Кембриджского университета, ISBN  0-521-53771-1
  • Марко Брамбилла, Хорди Кабот, Мануэль Виммер, Разработка программного обеспечения на основе моделей на практике, предисловие Ричард Соли (О, мой бог Председатель), Morgan & Claypool, США, 2012 г., Синтез лекций по программной инженерии # 1. 182 страницы. ISBN  9781608458820 (мягкая обложка), ISBN  9781608458837 (электронная книга). http://www.mdse-book.com
  • Стэнли Дж. Сьюэлл. Исполнительное обоснование для MDA
  • Сойлу А., Де Каусмекер Патрик. Объединение подходов к разработке систем, основанных на моделях и онтологиях, всеобъемлющая перспектива вычислений, in Proc 24th Intl Symposium on Computer and Information Sciences. 2009, стр. 730–735.

внешняя ссылка