Очень краткое введение в Model Driven Architecture (MDA)

Для начала давайте взглянем на популярную методологию разработки программного обеспечения под названием RUP (Rational Unified Process). В соответствии с этой методологией, цикл разработки состоит из следующих основных шагов:

1. Выработка и согласование требований
2. Анализ
3. Дизайн
4. Реализация
5. Тестирование
6. Ввод в эксплуатацию

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

Модель, построенная на этапе дизайна (п.3), часто имеет большую ценность чем конкретная реализация и может пережить ее. Например, построение модели сложной системы может занять много человеко-месяцев кропотливого анализа предметной области, консультаций с экспертами, обработки тысяч страниц документации предметной области. Допустим, что после построения такой модели она была реализована в виде инсталлируемого продукта на языке C++. Через несколько лет с развитием интернет-технологий было принято еще реализовать этот продукт в виде веб-сервиса, на языке Java. Хорошо построенная модель позволит использовать большую часть работы по ее построению в новой реализации системы.

Тут мы впервые сталкиваемся с первым ограничением стандартного RUP процесса. Любая модель при ее построении часто несет на себе следы технологий под которые она разрабатывалась (в противном случае она будет слишком абстрактной для того чтобы быть использованной как документ на основании которого делается реализация). Например в UML модели для C++ и для Java могут по-разному использоваться такие ОО концепции как множественное наследование и интерфейсы (в Java нет множественного наследования реализации, а в C++ нет формального различия между классами и интерфейсами).

Как решение этой и других проблем, была предложена методология разработки ПО под названием MDA (Model Driven Architecture). В этой методологии различают два типа моделей: PIM — платформно независимая модель и PSM — платформно зависимая модель. 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). Преобразования могут быть параметризованы, что позволит их подстраивать под нужды конкретных проектов.

Итак, на этапе анализа на основании требований вырабатывается платформно независимая модель системы (PIM). Она привязана к постановке задачи и предметной области и не зависит от таких деталей реализации, как, например, язык программирования или тип базы данных (реляционная, объектная, иерархическая и т.д.)

Далее, на этапе дизайна будет осуществлен выбор деталей реализации: платформ, языков, распределенной или централизованной архитектуры. На основании эти решений PIM будет преобразована в соответствующие платформно зависимые модели (PSM). Для этого преобразования скорее всего будут использоваться готовые инструменты преобразования и библиотеки правил преобразования. Из одной PIM может быть сгенерировано несколько PSM. Например, одна из PSM может основываться на CWM метамодели для реляционых баз данных и описывать модель данных. В тоже время другая модель может, используя UML/EJB Mapping, представить PSI в терминах Enterprise Java Beans. Для стыковки разных PSM моделей в процессе PIM⇒PSM трансформации могут также быть сгенерированы так называемые «bridges» — связки между разными PSM моделями, сгенерированными из общей PIM модели.

Ну и наконец, из PSM при помощи других инструментов преобразований и других наборов правил будет сгенерирован код. Например, если Oracle был выбран как реляционная база данных, то будет использован набор правил, который из соотвествующей PSM построит схему базы данных. Другой набор правил может сгенеририровать Java код для EJB контейнера. Опять же, при использовании нескольких PSM моделей будут сгенерированы связки на уровне кода между ними, которые, например, позволят сгенерированным Java Beans работать с сгенерированной схемой базы данных Oracle. Хотя преобразования будут делаться автоматически, выбор их параметров останется за дизайнером. Например, он может указать использовать ли определенные возможности платформы или нет, подсказать системе примерные объемы ожидаемых данных, и т.п.

Конечно, сгенерированный код не будет представлять собой полную реализацию системы. Современные модели описывают системы только частично, оставляя реализацию значительной ее части человеку. Так что на следующем этапе программисты должны закончить реализацию системы. Возможно, в будущем мы придем к моделям, которые смогут описывать систему полностью, позволяя сгенерировать работающий продукт автоматически из модели. Работы в этом направлении уже ведутся, но они еще в начальной стадии. Если вас интересует это область, то стоит взглянуть на UML Actions Semantics.

Приведенное выше не претендует на сколь нибудь полноценное описание MDA, а скорее ставит своей целью дать очень общее представление об этой области и если она вас заинтересует, подтолкнуть к ее дальнейшему изучению. На данном этапе эта методология находится больше в области академических исследований чем практического применения. Хотя множество деталей еще требуют уточнений и разработки и потребуются еще годы работы перед тем, как мы увидим практические применения MDA, общее видение и направление развития уже достаточно хорошо определены. Многие считают идею генерации работающих систем автоматически из моделей утопической. Взгляд в недалекое прошлое возможно поможет вам отнестись с большим доверием к этой идее. Представьте, как бы отреагировал программист шестидесятых годов прошлого века, который писал программы на ассемблере или в машинных кодах, если бы ему начали рассказывать про современные системы и языки программирования. Труд программиста все еще будет нужен. Просто вместо написания операторов языка Java или C++, он будет работать на более высоком уровне, описывая модели и их трансформации.

Вадим Залива,

сентябрь 2009
www.codeminders.com/jobs.html

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU