Войти
Model Driven Architecture ® (MDA®) - это подход к проектированию программного обеспечения для разработки программных систем. Он предоставляет набор руководящих принципов для структурирования спецификаций, которые выражаются в виде моделей. Архитектура, управляемая моделями, является разновидностью проектирования предметной области и поддерживает проектирование программных систем на основе моделей. Он был запущен Object Management Group (OMG) в 2001 году.
Model Driven Architecture® (MDA®) «обеспечивает подход к извлечению ценности из моделей и архитектуры в поддержку полного жизненного цикла физических, организационных и ИТ-систем». Модель - это (представление) абстракции системы. MDA® обеспечивает ценность, создавая модели на различных уровнях абстракции, от концептуального представления до мельчайших деталей реализации. В литературе OMG говорится о трех таких уровнях абстракции или архитектурных точках зрения: модель, не зависящая от вычислений (CIM), модель, независимая от платформы (PIM), и модель, зависящая от платформы (PSM). CIM описывает систему концептуально, PIM описывает вычислительные аспекты системы без ссылки на технологии, которые могут использоваться для ее реализации, а PSM предоставляет технические детали, необходимые для реализации системы. Однако в OMG Guide отмечается, что эти три архитектурные точки зрения полезны, но представляют собой лишь три из многих возможных точек зрения.
Организация OMG предоставляет спецификации, а не реализации, часто в качестве ответов на запросы предложений (RFP). Реализации поступают от частных компаний или групп с открытым исходным кодом.
Модель MDA связана с несколькими стандартами, включая Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), Метамодель разработки программных процессов (SPEM). и Метамодель Common Warehouse (CWM). Обратите внимание, что термин «архитектура» в Model Driven Architecture не относится к архитектуре моделируемой системы, а скорее к архитектуре различных стандартов и форм моделей, которые служат технологической основой для MDA.
Исполняемый UML был профилем UML, который использовался при рождении MDA. Теперь вместо этого OMG продвигает fUML. (Язык действий для fUML - ALF.)
Группа управления объектами владеет зарегистрированными товарными знаками на термин «Архитектура, управляемая моделями» и его аббревиатурой MDA, а также товарные знаки для таких терминов, как: Разработка приложений на основе моделей, Разработка приложений на основе моделей, Разработка приложений на основе моделей, Программирование на основе моделей, Системы на основе моделей, и другие.
OMG фокусирует Model Driven Architecture® на перспективном проектировании, то есть создании кода из абстрактных, созданных человеком диаграмм моделирования (например, диаграмм классов). Группа OMG ADTF (Рабочая группа по анализу и проектированию) возглавляет эту работу. С некоторой долей юмора группа выбрала ADM (наоборот, MDA), чтобы назвать исследование обратным проектированием. ADM преобразуется в модернизацию, управляемую архитектурой. Задача ADM - разработать стандарты для модельного обратного проектирования унаследованных систем. Метамодель обнаружения знаний (KDM) является наиболее продвинутой из этих усилий и описывает информационные системы с точки зрения различных активов (программ, спецификаций, данных, тестовых файлов, схем баз данных и т. Д.).
Поскольку концепции и технологии, используемые для реализации проектов, а также концепции и технологии, используемые для реализации архитектур, менялись в своем собственном темпе, их разделение позволяет разработчикам систем выбирать из лучших и наиболее подходящих в обеих областях. Дизайн обращается к функциональным требованиям ( сценариям использования ), тогда как архитектура обеспечивает инфраструктуру, через которую реализуются нефункциональные требования, такие как масштабируемость, надежность и производительность. MDA предполагает, что независимая от платформы модель (PIM), которая представляет собой концептуальный проект, реализующий функциональные требования, переживет изменения в технологиях реализации и архитектурах программного обеспечения.
Особое значение для архитектуры, управляемой моделями, имеет понятие преобразования модели. Конкретный стандартный язык для преобразования модели был определен OMG под названием QVT.
Организация OMG предоставляет приблизительные спецификации, а не реализации, часто в качестве ответов на запросы предложений (RFP). OMG документирует общий процесс в документе под названием MDA Guide.
По сути, инструмент MDA - это инструмент, используемый для разработки, интерпретации, сравнения, согласования, измерения, проверки, преобразования и т. Д. Моделей или метамоделей. В следующем разделе «модель» интерпретируется как означающее любой вид модели (например, модель UML) или метамодель (например, метамодель CWM). В любом подходе MDA у нас есть два типа моделей: исходные модели создаются вручную агентами-людьми, а производные модели создаются автоматически программами. Например, аналитик может создать исходную модель UML на основе наблюдений за некоторой неопределенной бизнес-ситуацией, в то время как модель Java может быть автоматически получена из этой модели UML с помощью операции преобразования модели.
Инструмент MDA может быть инструментом, используемым для проверки моделей на полноту, несоответствие или условия ошибок и предупреждений. Также используется для расчета показателей модели.
Некоторые инструменты выполняют более одной из перечисленных выше функций. Например, некоторые инструменты создания могут также иметь возможности преобразования и тестирования. Существуют и другие инструменты, предназначенные исключительно для создания, исключительно для графического представления, исключительно для преобразования и т. Д.
Спецификации OMG реализованы частными компаниями или группами с открытым исходным кодом. Одним из важных источников реализации спецификаций OMG является Eclipse Foundation (EF). Многие реализации стандартов моделирования OMG можно найти в Eclipse Modeling Framework (EMF) или Graphical Modeling Framework (GMF), Eclipse Foundation также разрабатывает другие инструменты различного профиля, такие как GMT. Соответствие Eclipse спецификациям OMG часто не является строгим. Это верно, например, для стандарта OMG EMOF, который EMF приближается к его реализации Ecore. Больше примеров можно найти в проекте M2M, реализующем стандарт QVT, или в проекте M2T, реализующем стандарт MOF2Text.
Следует быть осторожным, чтобы не путать Список инструментов MDA и Список инструментов UML, первый намного шире. Это различие можно сделать более общим, выделив «инструменты переменной метамодели» и «фиксированные инструменты метамодели». Инструмент UML CASE обычно представляет собой «фиксированный инструмент метамодели», поскольку он жестко запрограммирован для работы только с данной версией метамодели UML (например, UML 2.1). Напротив, у других инструментов есть внутренние общие возможности, позволяющие им адаптироваться к произвольным метамоделям или к метамоделям определенного типа.
Обычно инструменты MDA ориентированы на элементарную спецификацию архитектуры, хотя в некоторых случаях инструменты не зависят от архитектуры (или платформы).
Простые примеры архитектурных спецификаций включают:
Некоторые ключевые концепции, лежащие в основе подхода MDA (запущенного в 2001 г.), были впервые разъяснены методом Шлаера-Меллора в конце 1980-х годов. Действительно, отсутствующий ключевой технический стандарт подхода MDA (синтаксиса языка действий для исполняемого UML ) был преодолен некоторыми поставщиками путем адаптации исходного языка действий Шлаера-Меллора (модифицированного для UML). Однако в этот период подход MDA не получил широкого признания в отрасли; при этом Gartner Group по- прежнему определяет MDA как «находящуюся на подъеме» технологию в своем « Цикле обмана» в 2006 году, а Forrester Research объявляет MDA «DOA» в 2006 году. Потенциальные проблемы, которые были подняты в связи с подходом OMG MDA, включают:
Генерация кода означает, что пользователь абстрактно моделирует решения, которые связаны с некоторыми данными модели, а затем автоматизированный инструмент извлекает из частей модели или всего исходного кода для системы программного обеспечения. В некоторых инструментах пользователь может предоставить скелет исходного кода программы в форме шаблона исходного кода, в котором предопределенные токены затем заменяются частями исходного кода программы в процессе генерации кода.
Часто цитируемая критика заключается в том, что диаграммам UML просто не хватает деталей, которые необходимы для того, чтобы содержать ту же информацию, которая содержится в исходном коде программы. Некоторые разработчики даже заявляют, что «Код - это дизайн».
