MDA - новая концепция интеграции приложений

В современных программных системах активно используются много различных стандартов и технологий промежуточного слоя — CORBA, DCOM, .Net, Web-службы, технологии, основанные на Java и т.д. Все чаще возникает потребность в интеграции и обеспечении взаимодействия систем, основанных на разных технологиях, а также в модернизации существующих программ и их переработке в соответствии с новой технологической основой. Новая архитектурная концепция, предложенная консорциумом OMG, основанная на модельно-ориентированном подходе к разработке программного обеспечения, позволяет существенно упростить и частично автоматизировать разработку, интеграцию и модернизацию систем.

В связи с большим количеством используемых и разрабатываемых стандартов и технологий стало очевидно, что попытка создать единый универсальный стандарт построения и взаимодействия программных систем обречена на неудачу. Примером тому стандарт CORBA, который, хотя и приобрел определенную известность, так и не занял предполагаемого для него места «универсального стандарта». Поэтому консорциум OMG принял решение перейти от «стандарта интеграции» к интеграции стандартов. Концепция MDA (Model Driven Architecture) призвана обеспечить общую основу для описания и использования большинства существующих стандартов, не ограничивая разработчиков в выборе конкретных технологий. Интеграция стандартов достигается за счет: введения концепции платформно-независимой модели приложения; использования унифицированного инструмента (UML) для описания таких моделей; наличия разработанных OMG стандартных отображений моделей в среду большинства технологических платформ и программных инструментов промежуточного слоя.

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

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

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

В статье в основном рассматриваются интеграционные возможности MDA. Модельно-ориентированный подход облегчает интеграцию как разнородных, основанных на различных технологиях распределенных систем, так и организацию взаимодействия между системами, основанными на одной технологии, но использующими разные интерфейсы, сервисы и стандарты. Кроме того, MDA позволяет разрабатывать стандартные сервисы (репозитарии, сервисы событий и сообщений и т.д.), которые поддерживают сразу несколько технологий промежуточного слоя. Например, можно создать репозитарий объектов, который предоставляет соответствующий сервис системам как на базе CORBA, так и на базе Web-сервисов. Это не только упрощает разработку программного обеспечения, но и позволяет организовать взаимодействие различных систем.

Основы MDA

Ядром MDA являются несколько стандартов — UML, MOF, CWM и XMI. Язык UML (Universal Modeling Language) используется для описания всех моделей. Совокупность метамоделей CWM (Common Warehouse Model) представляет наиболее часто используемые в базах данных и инструментах бизнес-анализа метаданные. CWM содержит большое количество различных метамоделей, описывающих функционирование бизнеса. MOF (Meta Object Facility) — общий абстрактный язык для описания метамоделей; на его основе построены формальные описания метамодели для CWM и UML. Последний стандарт, XMI (XML Metadata Interchange), играет служебную роль, описывая отображение моделей MOF и UML на стандарт XML. При этом метамодели преобразуются в DTD-структуру документа, а модели — в тело XML-документа. Это позволяет объединить модель и ее метамодель в одном документе и получить так называемый «самоописываемый» (self-describing) документ, содержащий не только данные, но и информацию, необходимую для их интерпретации.

В основе MDA лежит понятие платформно-независимой модели (platform independent model, PIM). Речь идет о детальной исполняемой модели на языке действий UML (action semantics) с пред- и постусловиями, сформулированными на OCL.

Вполне логично, что для описания PIM выбран язык UML. Этот язык принципиально позиционировался как независящий от платформ и технологий. Однако UML в своих ранних версиях не являлся «точным» языком: он только предоставлял дизайнеру возможность описать структуру и поведение системы, практически не определяя ее функционирование и используемые алгоритмы. В новый стандарт UML 2.0, который был одобрен OMG в июне 2003 года, включено большое количество средств, позволяющих описывать внутреннюю организацию и функционирование системы. Одна из основных задач, которые были решены при создании этого стандарта, — превратить UML в алгоритмически полный исполнимый язык, в то же время, по возможности, не повышая уровня детализации UML-моделей.

Подчеркнем: несмотря на то, что PIM — это детальная исполняемая модель, ее вряд ли можно использовать на практике как финальный программный продукт. UML-инструментарий нового поколения предоставляет унифицированную среду, в которой можно интерпретировать эту модель и получать исполняемый код прототипного качества. Такой код может быть крайне неэффективным, не удовлетворять некоторым функциональным требованиям, не полностью реализовывать функциональность системы и даже требовать участия человека в процессе исполнения. Инструментарий, используемый для интерпретации UML-модели, может быть полуавтоматическим и допускать вмешательство оператора. Только после привязывания к конкретной платформе можно получить код промышленного качества. Но, хотя исполнение PIM-модели и нельзя применять для решения практических задач, оно необычайно важно для целей тестирования и отладки. Фактически, у разработчиков появляется возможность получить первый прототип системы еще до начала стадии кодирования, когда сравнительно легко вносить даже существенные изменения в систему (в том числе, изменения требований и технического задания).

Рис. 1. Стандарты, на которые опирается MDA

Результатом первого этапа разработки в соответствии с подходом MDA является описание PIM на языке UML. Завершенная платформно-независимая модель содержит полное описание системы, однако свободна от деталей, относящихся к реализации и используемым технологиям. После того, как модель построена, ее необходимо преобразовать в платформно-зависимую модель (platform-specific model, PSM). Это преобразование производится с помощью разработанных OMG стандартных отображений, разных для каждой платформы промежуточного слоя; при этом в модель вносится информация, относящаяся к деталям практической реализации и выбранной платформе. Благодаря тому, что преобразование от PIM к PSM стандартизовано, могут быть созданы инструменты — анализаторы и генераторы описания моделей, существенно упрощающие и автоматизирующие это преобразование. На данном этапе по-прежнему существенна работа дизайнеров и архитекторов системы: во многих случаях PIM предоставляет недостаточно данных для полностью автоматического переноса на конкретную технологию, и требуется предварительно разметить и конкретизировать PIM в терминах целевой системы. Скажем, UML-класс из платформно-независимой модели можно отобразить на интерфейс, объект или «тип-значение» (valuetype) при переходе к платформе CORBA. В таких случаях необходимо разметить модель вручную.

Завершенная платформно-зависимая модель содержит всю необходимую информацию для генерации кода системы, а также для генерации вспомогательного кода и описаний, необходимых для использования выбранной платформы и технологий (в частности, могут быть созданы IDL-описания интерфейсов для технологии CORBA). Фактически платформно-зависимая модель близка к UML-модели системы, полученной при классическом подходе к разработке, но более детальна и может содержать больше информации, относящейся к используемым технологиям.

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

Рис. 2. Построение MDA-системы на двух технологических платформах и генерация межплатформного адаптера

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

Преимущества использования MDA

Тестирование и модификация

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

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

Построение нескольких PSM по одной PIM

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

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

Простота модернизации и смены платформы

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

Используя PIM и соответствующее отображение, всегда можно будет с относительной легкостью заново реализовать и модернизировать систему на основе новейших технологий и платформ. Создатели MDA называют это свойство future proofing — защищенностью от устаревания ее технологической платформы.

MDA и интеграция распределенных систем

Межплатформные адаптеры

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

Инструментарий, проводящий отображение, может не только создать PSM для каждого фрагмента системы, но и, проанализировав их взаимодействие на основе платформно-независимой модели, сгенерировать сущности (описания интерфейсов, код посредников, мостов и медиаторов), необходимые для межплатформенного взаимодействия фрагментов системы. Благодаря использованию описания взаимодействия элементов системы, содержащегося в PIM, достигается высокий уровень автоматизации построения гетерогенных систем.

Так, при переходе от PIM к PSM в модели можно пометить, что одна часть системы использует механизм взаимодействия CORBA, другая — XML/SOAP, а третья — COM. Платформно-независимая модель будет разбита на несколько частей с уже описанным взаимодействием между ними. Инструменты могут автоматически сгенерировать подсистему-адаптер для их взаимодействия и все необходимые дополнительные описания (IDL-интерфейсы, схему базы данных и т.д.).

Автоматическая настройка приложений и сервисов

Важной частью подхода MDA являются способы описания и работы с метаданными. Стандарт MOF позволяет описывать метамодели и метаданные, а стандарт XMI дает возможность представлять их единообразно в формате XML. Возможность оперирования и обмена метаданными в едином формате позволяет программам взаимодействовать и обмениваться данными, даже если они не имеют информации друг о друге, т. е. о форматах данных, используемых другой программой. Обмен данными между разнородными источниками может управляться формальными описаниями метаданных о типах, преобразованиях и типизированных отображениях. Совокупность метаданных в системе образует полное описание среды, возможностей системы и установленных программ. Приложения, базы данных и сервисы могут подключаться к среде, получать специфичные для нее метаданные и добавлять свои, что позволяет программам автоматически адаптироваться к среде, а также настраивать необходимые элементы среды в соответствии со своими потребностями. Это возможно, даже если программа «не знакома» с какими-либо элементами среды (т.е. в нее не заложена информация о стандартах, форматах, протоколах и функционировании этих элементов). Все необходимое можно получить из метаданных.

Универсальные сервисы

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

Например, возможно создание универсальных сервисов для хранения и преобразования типов данных. Для CORBA-систем разработан стандартный сервис Interface Repository — основное средство для работы с метаинформацией о типах в этих системах. Этот сервис имеет ряд недостатков: стандартным образом не поддерживается обновление интерфейсов, и сложно отождествить информацию об интерфейсе из репозитария с другими данными, такими как информация о поведении объектов. В то же время у репозитария, основанного на модели MOF, имеется ряд преимуществ:

• поддержка изменения интерфейсов;
• возможность расширить CORBA-модель композицией и наследованием из MOF-модели;
• простота поддержки нескольких репозитариев и интеграции репозитариев интерфейсов с хранилищами другой информации о типах данных.

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

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

Заключение

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

Полезные ссылки

Richard Soley and OMG Staff Strategy Group, «Model Driven Architecture». ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf.

John Poole, «Model-Driven Architecture: Vision, Standards And Emerging Technologies». http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf.

Joaquin Miller, Jishnu Mukerji, «MDA Guide Version 1.0». http://www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf.

OMG Architecture Board MDA Drafting Team, «Model Driven Architecture — A Technical Perspective». http://www.omg.org/cgi-bin/apps/doc?ormsc/01-07-01.pdf.

Unified Modeling Language (UML) specification v1.5. http://www.omg.org/cgi-bin/apps/doc?formal/03-03-01.pdf.

UML Profile for CORBA. http://www.omg.org/cgi-bin/apps/doc?ptc/00-10-01.pdf.

Meta-Object Facility (MOF), v1.4. http://www.omg.org/cgi-bin/apps/doc?formal/02-04-03.pdf.

XML Metadata Interchange (XMI), v1.2. http://www.omg.org/cgi-bin/apps/doc?formal/02-01-01.pdf.

Common Warehouse Metamode (CWM) Specification, v1.1. http://www.omg.org/cgi-bin/apps/doc?formal/03-03-02.pdf.