Mda: структура и состав
Model Driven Architecture (MDA) дословно переводится как «архитектура, управляемая моделью». История ее разработки насчитывает порядка 10 лет. Основным разработчиком MDA является консорциум OMG (Object Management Group). В настоящее время в консорциум OMG входит около 1000 компаний производителей программного и аппаратного обеспечения. Главной задачей OMG является разработка стандартов и спецификаций, регламентирующих применение новых информационных технологий на различных аппаратных и программных платформах. Широко известны такие продукты и технологии, как UML и CORBA, в разработке которых активно участвует OMG [1].
Архитектура MDA предлагает новый интегральный подход к созданию много-платформенных приложений и базируется на трех основных элементах:
UML(Unified Modeling Language) унифицированный язык моделирования;
MOF (MetaObject Facility) абстрактный язык для описания информации о моделях (язык описания метамоделей);
CWM (Common Warehouse Metamodel) общий стандарт описания информационных взаимодействий между хранилищами данных.
Рисунок 1.2 Схема взаимодействия MDAс программными технологиями
На центральном уровне структуры находится собственно MDA, которая «разворачивается» наружу посредством второго уровня, содержащего вышеперечисленные базовые составляющие UML, MOF и CWM, и на третьем, внешнем уровне представлены некоторые из широко известных в настоящее время программных платформ разработки: CORBA, XML, .NET, JAVA. На этом внешнем уровне, по замыслу OMG, могут и должны быть размещены, в принципе, и все возможные будущие технологии разработки. Этим подчеркивается тот факт, что OMG считает архитектуру MDA не просто новой технологией, а скорее «метатехнологией» создания приложений. Последняя отныне будет и единственно актуальной ¬ вне зависимости от развития и появления новых средств разработки, которые MDA уже «заранее интегрировала» в себя [2].
Этапы разработки mda-приложений
Циклограмма разработки MDA-приложений в общем виде включает три основных этапа (рис. 1.3). На первом этапе разработчик, исходя из поставленной передним задачи и знаний о предметной области, формирует платформенно-независимую PIM-модель. При ее создании он полностью абстрагируется от особенностей конкретных программных или аппаратных средств. На втором этапе создаются одна или несколько платформенно-зависимых моделей PSM, которые являются своеобразными «адаптерами» или «драйверами», обеспечивающими интеграцию PIM с одной или несколькими технологиями разработки программных ПРОДУКТОВ
Рисунок 1.3 Этапы создания MDA-приложения
Таким образом, согласно концепции MDA главный акцент при разработке приложений переносится с собственно этапа программирования на этап создания модели. При этом, создав один раз модель, разработчик получает принципиальную возможность генерации приложений для разных аппаратных и программных платформ.
MDA не специфицирует, на каком языке описана PIM, но требует, чтобы описание было на языке, который определен формально и пригоден к автоматической обработке. Для примера формального определения языков моделирования можно взглянуть на Meta Object Facility ¬ специальный язык используемый OMG для определения других языков моделирования, в том числе UML. UML может быть использован для описания как PIM так и PSM. OCL может использоваться в дополнение к UML. При использовании UML в PSM-моделях скорее всего будет использоваться один из UML профилей, как например, OMG CORBA Profile, Enterprise Application Integration Profile, UML/EJB Mapping, Common Warehouse Metamodel.
Основная идея MDA в том, что преобразование из PIM в PSM, а также же генерация кода из PSM, может производиться автоматически. Преобразования проводятся при помощи инструментов преобразования (transformation tools), которые в свою очередь используют правила преобразования. Эти правила будут написаны на языке, который будет описан стандартом QVT (Queries, Views, Transformations). Преобразования могут быть параметризованными, что позволит их подстраивать под нужды конкретных проектов [3].
Рисунок 1.4 Инструменты преобразования на этапах создания MDA-приложения
Итак, на этапе анализа на основании требований вырабатывается платформенно-независимая модель системы (PIM). Она привязана к постановке задачи и предметной области и не зависит от таких деталей реализации, как, например, язык программирования или тип базы данных (реляционная, объектная, иерархическая и т.д.)
Далее, на этапе дизайна будет осуществлен выбор деталей реализации: платформ, языков, распределенной или централизованной архитектуры. На основании этих решений PIM будет преобразована в соответствующие платформенно-зависимые модели (PSM). Для этого преобразования, скорее всего, будут использоваться готовые инструменты преобразования и библиотеки правил преобразования. Из одной PIM может быть сгенерировано несколько PSM. Например, одна из PSM может основываться на CWM метамодели для реляционных баз данных и описывать модель данных. В тоже время другая модель может, используя UML/EJB Mapping, представить PSI в терминах Enterprise Java Beans. Для стыковки разных PSM моделей в процессе PIM⇒PSM трансформации могут также быть сгенерированы так называемые «bridges» ¬ связки между разными PSM моделями, сгенерированными из общей PIM модели [6].
Из PSM при помощи других инструментов преобразований и других наборов правил будет сгенерирован код. Например, если Oracle был выбран как реляционная база данных, то будет использован набор правил, который из соответствующей PSM построит схему базы данных. Другой набор правил может сгенерировать Java код для EJB контейнера. Опять же, при использовании нескольких PSM моделей будут сгенерированы связки на уровне кода между ними, которые, например, позволят сгенерированным Java Beans работать со сгенерированной схемой базы данных Oracle. Хотя преобразования будут делаться автоматически, выбор их параметров останется за дизайнером. Например, он может указать использовать ли определенные возможности платформы или нет, подсказать системе примерные объемы ожидаемых данных, и т.п.
Рисунок 1.5. Этапы создания MDA-приложения и использование «bridges»