Biggest DevOps Conference in Ukraine! Kubernetes, TensorFlow, KubFlow, Cloud solutions, Ballerina and much more. Register until August, 22!

Очень краткое введение в 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). Преобразования могут быть параметризованы, что позволит их подстраивать под нужды конкретных проектов.

MDA-преобразования

Итак, на этапе анализа на основании требований вырабатывается платформно независимая модель системы (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. Хотя преобразования будут делаться автоматически, выбор их параметров останется за дизайнером. Например, он может указать использовать ли определенные возможности платформы или нет, подсказать системе примерные объемы ожидаемых данных, и т.п.

MDA

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

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

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

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

LinkedIn

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Essentially, all models are wrong, but some are useful©

@awhхорошо, давайте разберемся. По МДД, все есть модель (код, байткод, бинарный код в т.ч.) + трансформации между ними. Например, С# -> трансформация компилятором -> IL-код (тоже модель) -> jit -> инструкциии процессору (тоже модель, финальная для программистов). Что такое «доводка кода», мне неведомо, но поверьте, все что происходит с программой, вкладывается в эту схему (разница может быть уже в деталях, когда и какая происходит трансформация — например, на этапе сборки (компиляционная схема) или же во время исполнения (интерпретационная схема), а в реальности, используется обычно «миксед» схема — часть моделей компилируется, часть интерпретируется). В любом случае, модель просто есть (это просто факты, в терминах мета-модели). Трансформация, генерирующая что-то работающее, может быть. А можеть и не быть. Свойство «исполнимости» зависит от наличия такой автоматической трансформации (неважно какой), а не от модели.

@Виталийсравнимизменение модели -> изменение поведения (executable models) и изменение модели-> генерация кода -> доводка кода-> изменение поведения (подход, описаный в статье) это я и имел в виду:)

2 @awh: изменение модели по определению приводит к изменению поведения приложения, вы что-то запутались; -) 2 @dnovhorodov: я не верю в UML как основу для первичных моделей в MDD (видимо не только я, «бум» MDA, которая появилась аж в 2002-м кажись, тому подтверждение). Причин — несколько: стандартное представление в формате XMI (ужасно громоздкий формат), привязка к фиксированной онтологии верхнего уровня (MOF), ориентация на графическое представление модели (ну это религиозное — я глубоко убежден, что в реальных условиях разработки эффективно можно работать лишь с символьным представлением модели — например в виде простого XML).

на мой взгляд, генерация кода на основе модели действительно является утопической.только потому что отсутствует обратная свзяь — измененя в коде автоматичесеки не приводят к изменению в моделе.Изменения в коде обязательно будут, нельзя на начальном этапе так прописать модель, чтобы она дошла до релиза без измененийТаким образом, модель может быть использована только для начальной генрации кода, но никак для дальнейшего реюза (что обещает статья) Мне больше нравиться подход oslo, где говорят, что модель сама по себе должна быть executable, то есть изменение модели напрямую приводит к изменению поведения приложения. Это конечно, ограничивает возможности, но по крайней мере такая цель для определенных предметных областей практична и достижима.Хотя с oslo щас тоже непонятно что происходит, они походу там опять все переиграют, ждем pdc.

А кто сказал, что цикл разработки в RUP состоит из четкой последовательности шагов и для внесения минорного изменения, шаги нужно повторять? Весь прикол в том, что последовательным является выполнение фаз, а не каких-то там шагов. На каждой из фаз происходят такие процессы как моделирования, управление требованиями и анализ и проектирование. То есть, вы можете внести изменения в продукт на фазе реализации, предварительно на этой же фазе, изменив дизайн. А итеративный подход вообще добавляет ко всему этому значительную гибкость:) Просто удивляет, что часто, когда пишут о каких-то новых вещах, начинают из обсирання RUP. Хотя, те же новомодные Agile-ы используют те же подходы, какие давным-давно были заложены в RUP.

OMG MDA (как набор стандартов) больше мертвое чем живое, можно сказать почти родилось мертвой (мда уж:). Может потому что UML; -) ну, а вообще MDA — представидель generic modeling approach в MDD.Вроде бы единственной хоть какой-то более менее схожей (отдаленно и упрощенной в куче моментов) реализацией на то что омг описала в МДА — является EMF для Java. И даже в этом виде тяжелая, громоздкая фигня — насколько могу судить (юзающих ее лично не знаю никого).Следущей «масштабной» потугой есть MS OSLO (на данный момент тоже все выглядит не столь уж радужно как казалось на PDC’2008). По традиции, МС тяготеет к предметно-зависимому моделированию. MC полностью игнорит стандарты омг (может быть у них другой вижн, и эти стандартны им кажутся никому не нужными монстрами), кажись пересекаются только по MOF-у. Судя по семплам что сейчас есть, эта фигня тоже будет громоздкой и недешевой (во всех смыслах) в юзании.Если же говорить про модель-ориентированную разработку в более широком смысле (собственно работа с моделями и автоматическими трансформациями — без привязки к стандартам OMG), это давно уже не академическая методология и активно юзается на практике. В часности, я уже неоднократно упоминал мой опенсорс предметно-ориентированный MDD-фреймворк для ASP.NET — NReco, где активно юзаются модели на основе простого XML, например модель описывающая маппинг данных на документ Lucene.NET:

<index name="main" xmlns="urn:schemas-nreco:nreco:lucene:v1"><location><r:ref name="luceneMainIndexFolder"/></location><document name="film"><uid>'film_'+#film['id']</uid><field name="id">#film['id']</field><field name="title">#film['title']</field><field name="genres" store="false">#list = #genres.{ #this }, @String@Join(",", #list.ToArray() )</field></document></index>

Также для интерующихся — рекомендую ознакомится с технологиями в рамках MDD по таким ключевым словам: multi-level modeling, domain-specific multimodeling (по этой теме была защищена диссертация одного уважаемого немца где-то пол-года назад, обе эти концепции применимы к NReco).

UML можно использовать для написания PIM и PSM.

а разве UML не является сама PIM?

Якщо трансляція автоматична, то запропонований підхід просто міняє одну мову реалізації на іншу.Якщо трансляція ручна, то додається ще один посередник між потребами замовника/ринка та реалізацією і ще одне джерело помилок.На мою думку єдине, що дозволяє реально зменшити собівартість розробки, це зменшення (скорочення по часу та по кількості кроків) циклу зворотнього зв’язку між задокументованою функцією, робочим продуктом, де вона реалізована, та реальним досвідом використання цієї функції.

Подписаться на комментарии