IV Международная студенческая научная конференция Студенческий научный форум - 2012

Введение

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

Моделирование - это процесс создания моделей, т.е. описаний объекта (процесса) на каком-либо формальном языке.

Модель может быть текстовой или графической. Графические модели более наглядны, что дает им преимущество по сравнению с текстовыми. Однако, текстовые модели, как правило, можно эффективнее обрабатывать. В данной работе рассматриваются только графические, а конкретнее, графовые, модели, т.е. модели, представляющиеся в виде графа.

Чаще всего при разработке программного обеспечения используются универсальные языки моделирования, такие как язык UML. Однако у всех универсальных языков моделирования есть ряд недостатков. Так, они оперируют сильно ограниченным набором элементов. Например, UML использует термины «класс», «ассоциация», «агрегация» и т.п. Но в реальных областях существует множество понятий, которые не всегда можно адекватно отобразить на термины языка.

Другой недостаток универсальных языков моделирования является следствием первого. Если язык не способен адекватно отразить понятия предметной области, то построенные в нем схемы будут достаточно сложными для восприятия. Это снижает выигрыш от применения моделирования.

Третьим недостатком универсальных языков является то, что для их использования необходимо знать синтаксис и семантику этих языков. Человеку, не знакомому с UML, не удастся разобраться в модели предметной области, даже если он является экспертом в этой области. А ведь разработка программного обеспечения без привлечения экспертов невозможна.

Эти недостатки привели к появлению нового подхода к моделированию. Этот подход предполагает разработку специфического (предметно-ориентированного) языка (DSL) моделирования для каждой конкретной предметной области. Такой язык может разрабатываться в виде модели (которая будет называться метамоделью или формализмом) на некоем универсальном языке моделирования (метаязык). При разработке метамодели достаточно лишь описать используемые в области понятия и связи между ними. Логику работы с этими объектами нужно описывать уже в рамках разработки модели. Причем использование в качестве языка моделирования предметно-ориентированного языка позволяет без проблем привлечь к этому процессу экспертов.

Применение метамоделирования разбивает процесс разработки программного обеспечения на следующие этапы:

• 1) разработка языка описания предметной области;
• 2) построение модели на построенном языке метамоделирования;
• 3) генерация кода по построенной на предыдущем шаге модели.

Для того чтобы еще сильнее упростить процесс разработки создаются специальные программные средства, позволяющие автоматизировать этапы 2 и 3. В таких средствах помимо (мета)модели строятся специальные правила (трансформации графов), управляющие ходом генерации. Такие трансформации носят название вертикальных.

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

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

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

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

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

• 1) быть достаточно наглядным и простым в использовании, чтобы допускать возможность привлечения к работе над трансформациями не только программистов;
• 2) позволять создавать трансформации моделей как между формализмами (горизонтально), так и внутри одного формализма (вертикально);
• 3) позволять применять созданные трансформации прямо в системе, т.е. производить интерпретацию моделей в том же интерфейсе, в котором они были разработаны;
• 4) позволять задавать преобразования ограничений, наложенных на модель.

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

В этой работе поставлены следующие задачи:

• 1) обзор и анализ существующих подходов к описанию трансформаций графов;
• 2) обзор и анализ существующих программных средств, в которых реализованы эти подходы;
• 3) выбор математического аппарата для внутреннего и внешнего (пользовательского) представления описанных трансформаций.

Обзор и анализ способов описания графовых трансформаций

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

На данный момент на практике используются два способа описания трансформаций моделей-графов. Этими способами являются графовые грамматики и специальный язык QVT (Query-View-Transformation). В этой работе так же рассматривается ATLAS - диалект языка QVT, часто используемый в существующих системах.

Графовые грамматики и графовые трансформации

Графовая грамматика - обобщение грамматик Хомского на графы.

Центральным объектом в графовых грамматиках является  граф.

Определение 1 [14]. Пусть заданы два  графа . Тогда продукцией называется формула .

Продукция  может быть применена к графу G, содержащему L в качестве подграфа. Результатом этой операции будет граф H, полученный из G путем удаления подграфа L и заменой его подграфом R.

Определение 2 [10]. Графовая грамматика - это 4-ка

(N, T, C, P),

причем

1. N_i, T_i и C_i - наборы нетерминальных, терминальных и соединительных символов i‑й графовой грамматики,

2. N ∩ T ∩ C = ∅,

3. , левая часть продукции P помечена меткой x,

4. P - набор продукций , где  и  -  графы.

Определение 3 [7]. Система графовых грамматик - это (n + 3)‑ка 

(N, T,G₁,G₂, . . . , G_n, g₀),

такая, что

1) N, T - наборы нетерминальных и терминальных символов,

2) G_i = (N_i, T_i, C_i, P_i) - графовые грамматики, причем

            1. ,

            2. ,

3) g₀ - начальный граф.

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

Определение 4 [14]. Графовая трансформация - это тройка , где S и G₀ задают начальный граф, P - набор продукций. Графовая трансформация  эквивалентна конечному набору графов , где  - продукции.

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

Система графовых грамматик может представляться в компьютере в виде набора пар мультиграфов, описывающих левую и правую части продукций. Однако, возможен и другой подход. Обе части продукции объединяются в один граф, вершины и дуги которого имеют специальные служебные метки. Эти метки сообщают системе, относится ли эта вершина/дуга к левой части правила (т.е. будет удаляться при работе системы), к правой (т.е. будет создаваться) или же она входит в обе части правила (т.е. не подвергнется изменениям). Такой подход избавляет нас от дублирования общей информации.

При применении одного из правил грамматики к имеющемуся хост-графу G система должна найти в нем подграф, изоморфный левой части правила. Однако нахождение такого подграфа ничего не говорит нам о возможности применения правила. Часть элементов, которые будут удалены из графа, может быть связана с элементами, не вошедшими в подграф. Тогда встанет вопрос - что делать с ребрами, связывающими две части графа? Эта проблема получила название проблемы висячих ссылок. Для ее решения предложено два подхода:

• 1. Удалять эти ребра вместе с вершинами.
• 2. Запрещать применять правило.

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

Графовые грамматики позволяют наглядно описывать преобразования, которые должны происходить в системе при выzполнении над ней заданных в грамматике операций. На практике чаше встречается использование данного подхода для задания гомогенных трансформаций, однако ничто не мешает применять его для перевода модели в другую метамодель. При этом как графы L_i и R_i продукции P_i, так и промежуточные графы G_i будут содержать элементы (вершины и дуги) из обеих метамоделей.

Рассмотрим простейшую графовую грамматику. Она будет состоять из одного правила (рис. 1).

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

На рис. 1 правило представлено в виде двух разных графов. При этом четыре элемента (три вершины и одна дуга) входят в оба правила и хранятся в памяти в двух экземплярах. На рис. 2 приведено представление этого правила в виде одного помеченного графа. Наличие метки {L} у элемента означает, что он входит в левую часть правила, а метка {R} означает, что элемент входит в правую часть. Обе метки (или метка {L, R}) говорят о том, что элемент не изменяется в процессе работы правила.

Язык Query-View-Transformation (QVT)

В спецификации QVT выделено два языка описания трансформаций [11].

Первый язык - это язык QVT-Relations. Этот язык является достаточно абстрактным и простым в использовании. Однако на нем невозможно описать все тонкости, детали преобразования. Дл этих целей служит второй язык из спецификации QVT - QVT-Core [11,15].

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

Оба языка, и Relations, и Core, описывают трансформации в виде выражений на языке описания ограничений OCL. Это делает данный подход более гибким по сравнению с трехграфовыми грамматиками [8].

В рамках QVT есть возможность наследовать правила. Это позволяет определять достаточно сложные преобразования, не делая их описание слишком громоздким. Но  наследование используется не для повышения описательных возможностей языка, а для повышения эффективности исполнения. За счет наследования можно описывать правила с большим количеством элементов в левой части, но поиск соответствий будет происходить последовательно, начиная с маленьких частей, унаследованных от других правил [11].

 Для них не предусмотрено графическое представление, однако в случае с QVT-Core такое представление не трудно построить. Причем такое представление будет именно трехграфовой грамматикой. Каждая вершина в графах грамматики будет соответствовать переменной в правиле на языке Core [8].

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

ATLAS Transformation Language

ATLAS (иногда ATL) [9] - язык описания трансформаций моделей, диалект языка QVT. Он позволяет производить как гомо-, так и гетерогенные трансформации моделей. При этом в качестве метаязыка используется формализм Meta Object Facility (MOF) [13] (рис. 3).

ATLAS разработан как часть платформы AMMA (ATLAS Model Management Architecture) [9].

Как видно из приведенной схемы, для проведения трансформации необходимо создать файл на языке ATLAS, в котором будут содержаться правила трансформации. Системе нужны также метамодели обеих (начальной и конечной) предметных областей, описанные в терминах метаязыка MOF.

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

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

ATLAS - текстовый язык описания трансформаций. По сравнению с QVT он имеет очень сильное ограничение на создаваемые правила - в нем можно создавать лишь такие правила, в левой части которых будет один элемент модели - вершина или дуга [9]. Это дает возможность автоматически проверять правильность описанной трансформации, хотя и сильно сужает выразительные возможности языка.  Так же следствиями такого подхода являются, с одной стороны, повышение эффективности исполнения одного правила трансформации, с другой стороны, повышается количество правил в рамках одной трансформации.

Однако ATLAS имеет и существенное преимущество по сравнению со стандартами других подходов. В рамках ATLAS достаточно просто реализуется трансформация ограничений, описанных на OCL. Такие ограничения могут транслироваться в новую модель, оставаясь адекватными предметной области. [9]

Язык ATLAS является достаточно популярным языком описания трансформаций и используется во многих проектах по трансформации моделей, например, в рассматриваемом ниже фреймворке для трансформаций DSL. Большинство программ, позволяющих обрабатывать ограничения, используют именно ATLAS. Однако, все недостатки языка QVT присущи так же и ATLAS.

Обзор технологий гетерогенных трансформаций моделей

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

Трансформации в рамках технологии Model Driven Architecture

На данный момент в программировании используется значительное количество технологий и платформ, призванных облегчить процесс разработки, таких как .Net, CORBA и другие. Это приводит к целому ряду дополнительных проблем, таких как выбор технологии для проекта, организации взаимодействия систем, реализованных с использованием разных технологий и т.п. Для решения этих проблем консорциум OMG предложил новый подход к программированию, получивший название Model Driven Architecture (MDA) [12,11].

В основе данного подхода лежит построение двух моделей предметной области. Сначала строится платформо-независимая модель (platform-independent model, PIM) [12]. Данная модель описывает разрабатываемую систему без деталей ее реализации. При этом допускается даже использование предметно-независимых языков для более детального описания логики системы.

Когда платформо-независимая модель построена, строится платформо-зависимая модель (platform-specific model, PSM) [12]. Она является конкретизацией PIM в заранее выбранной технологии.

MDA допускает и спиральный жизненный цикл программы. При этом параллельно будут разрабатываться две модели и код [11].

Хотя разработка двух моделей выглядит лишним усложнением, подход MDA имеет значительное преимущество по сравнению с одномодельными технологиями. Так, с одной стороны, есть возможность автоматически генерировать PSM по построенной PIM, а по PSM, в свою очередь, можно сгенерировать код [11].

Обе модели, и PIM и PSM могут быть построены в разных формализмах. Однако, так как OMG причастен к разработке стандарта UML, данный формализм является наиболее распространенным.

Фреймворк трансформаций DSM в MDA

Для многих предметных областей уже разработаны свои модели и DSM, причем они могут быть описаны не в терминах UML. Внедрение MDA приведет к необходимости перевода этих DSM в формат, используемый в данной технологии. Для облегчения данной работы авторы статьи [3] разработали специальный фреймворк.

Этот фреймворк позволяет преобразовывать модели предметных областей в пары PIM и PSM. Причем обе эти модели будут описаны на UML.

Трансформация модели проходит в три этапа [3]:

• 1. Генерация метамодели. На рис. 4 ей соответствует стрелка 1. Для проведения данного этапа необходимо наличие метаметамодели, описанной в UML. Система анализирует конкретный синтаксис метамодели, принимая метаметамодель как абстрактный синтаксис. В результате получается набор правил, которые преобразуют метамодель ПрО в соответствующую ей метамодель в MDA. Данный этап выполняется над метамоделями, т.е. никак не связан с предметной областью. Это позволяет выполнить его лишь однажды, а полученный результат позволит трансформировать любую модель из данного формализма в MDA.
• 2. Генерация модели. На рисунке ей соответствует стрелка 2. Данный этап полностью аналогичен предыдущему, но выполняется на более низком уровне метамоделирования. Мы используем две метамодели, построенные на этапе 1, в качестве абстрактного синтаксиса, выделяем из модели конкретный синтаксис и строим правила, преобразующие модель между формализмами.
• 3. Трансформация более высокого порядка (HOT, Higher Order Transformation) соответствует стрелке 3 на рис.4. Применение этого преобразования гарантирует, что полученные модели будут соответствовать своим метамоделям. Для этого грамматики, полученные на первом и втором этапах, сливаются в одну. Правила со второго этапа рассматриваются как частные, уточненные случаи правил преобразования метамоделей. Затем слитые правила применяются к (мета)модели.

После применения всех трех этапов пользователь может так же вручную доработать полученную модель, если она не соответствует его ожиданиям.

При трансформации модели данный фреймворк очень сильно огрубляет наложенные на элементы модели ограничения. Единственный способ описания ограничений, которые поддерживает фреймворк - это ограничения, описанные на OCL [3]. Все остальные ограничения будут игнорироваться. Но даже ограничения, описанные на OCL, будут сильно урезаны. Если в одном из элементов указано ограничение, использующее атрибуты другого, в результирующей модели эти два элемента просто будут связанны между собой. Это делается для того, чтобы обеспечить правильность работы третьего этапа трансформации, HOT-трансформации.

Данный фреймворк имеет ряд недостатков. Как уже говорилось, он позволяет преобразовывать модели лишь в UML. Вдобавок, все преобразования моделей описываются лишь на языке описания трансформаций ATL, т.е. в текстовом виде. Это резко повышает необходимый уровень подготовки пользователя.

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

DSL-инструментарий АТоМ3

АТоМ3 [5, 6] - DSL-инструментарий, позволяющий производить разработку в различных формализмах. Для этого система использует методику метамоделирования. Сначала пользователь описывает метамодель (формализм), а за тем строит на ее основе модель предметной области. Вместо реализации метамодели, можно использовать одну из значительного количества заранее реализованных в системе. Так, среди встроенных формализмов есть ER-диаграммы, диаграммы классов UML, сети Петри, конечные автоматы и другие [6]. В рамках одной модели возможно использование лишь одного формализма, но наличие возможности преобразования моделей между формализмами компенсирует этот недостаток.

На рис. 5. показана схема трансформации модели между разными формализмами: из Fsource в Fdest. Как видно из схемы, на вход подается метамодель графовой грамматики. Дело в том, что все трансформации моделей, в том числе и гетерогенные, в АТоМ описываются в виде графовых грамматик. Это позволяет единообразно строить и исполнять трансформации.

В АТоМ для правила также можно указать Условие применения и дополнительное Действие [5], которое внесет в модель дополнительные изменения. В частности, такое Действие может связывать новые вершины (вставленные из Правой части) с вершинами, не вошедшими в найденный подграф, или изменять ограничения целостности, наложенные на модель.

Для выполнения трансформации системе нужны метамодели обоих формализмов, а так же метамодель графовой грамматики. На их основе система сгенерирует модель трансформации, загрузит модель на Fsource и создаст аналогичную её модель на Fdest. Если таким образом производить генерацию кода, то метамодель Fdest станет не нужна.

Рассмотрим теперь изменение ограничений, наложенных на элементы модели. В системе АТоМ все ограничения описываются на языке Python [5,6]. Они не зависят от используемых формализмов, поэтому переносятся без изменений. К сожалению, это приводит к неадекватности данных ограничений в новом формализме, т.е. их придется переписывать заново. В АТоМ есть возможность удалить старые ограничения, чтобы они не мешали в дальнейшей работе. Так же, как уже говорилось, можно указать в правилах графовой грамматики изменение ограничений при выполнении правил, но это не дает значительного облегчения ситуации. Такой подход может быть удобен при изменении достаточно простых ограничений, а описать изменения в более сложных случаях не намного проще, чем переписать с ноля.

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

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

Graph Rewriting and Transformation

Graph Rewriting and Transformation (GReAT) - это графический язык описания трансформаций графов между языками описания предметных областей (DSL) [1].

Данный язык использует модифицированный аппарат графовых грамматик. Грамматика по-прежнему состоит из набора правил, но правило уже не разбивается на левую и правую части, как это предполагается в стандарте графовых грамматик. Вместо этого строится один граф, содержащий как левую, так и правую части правила. Каждый элемент - ребро или дуга - может быть помечен одним из специальных символов, который указывает способ обработки этого элемента [1,16]. Примерами таких символов являются метки CreateNew и Delete. При отображении правила, такие метки будут изображаться в виде специальных маркеров на элементе. Если элемент графа создается в результате исполнения правила, то на нем будет изображена галочка. Если же элемент будет удален, то на нем изображается крестик

Каждое правило содержит в себе следующие элементы (рис. 6) [1]:

- Шаблон - граф, содержащий все участвующие в трансформации вершины и дуги;

- Метки действий - метки CreateNew, Delete и другие;

- Вход - набор входных портов, в которые могут передаваться данные от предыдущего выполненного правила;

- Выход - набор выходных портов, через которые данное правило сможет передать данные последующим;

- Охранное выражение - вычисляется перед применением правила и результат его вычисления разрешает или запрещает применение правила;

- Код означивания атрибутов - при применении правила выполняется данный код и задает значения атрибутам элементов графа;

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

При обработке хостграфа набором правил, каждое правило предварительно парсится специальным модулем [16]. Данный модуль, по сути, определяет по имеющимся меткам левую и правую части правила трехграфовой грамматикой.

Если на элемент навешана метка CreateNew, то этот элемент должен принадлежать правой части и он будет создаваться в процессе применения правила [16].

Если на элемент навешана метка Delete, то этот элемент должен принадлежать левой части и он будет удаляться в про процессе применения правила [16].

Если на элемент не навешано никаких меток, то этот элемент должен принадлежать обеим частям, и он не будет изменяться в процессе применения правила.

 

 

На рис. 6 элементы House и PurchaseOrder соединены с входами. Они должны быть переданы от предыдущего отработавшего правила. В данном правиле все элементы, кроме OrderItem, не имеют меток, а элемент OrderItem помечен меткой CreateNew. При подготовке правила к исполнению все элементы, кроме OrderItem попадут в левую часть. Значит, для применения правила нужно будет найти в хостграфе подграф, соответствующий дому и двум соседним комнатам в нем. Если такой граф найден, будет вычислено охранное выражение HasDoor, отображаемое в виде красного перечеркнутого круга. Это выражение содержит код на C++, который может обращаться к значениям атрибутов элементов найденного подграфа. Если выполнение данного кода вернет true, то правило применится. В результате создастся элемент OrderItem. После этого выполнится код означивания атрибутов, отображающийся в виде элемента AttributeMapping. В итоге, элементы House и OrderItem будут переданы следующему правилу через выходные порты.

Фреймворк VIATRA

Данный фреймворк - средство, предназначенное для верификации и валидации построенных моделей путем их трансформации [4]. В есть лишь один формализм - диаграммы классов UML и создать свои нельзя. Однако данный фреймворк интересен с точки зрения описания трансформаций.

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

Изначально разработчики предложили использовать графовые грамматики [4]. На рис. 7 изображено правило, являющееся частью грамматики, позволяющей эмулировать работу конечного автомата. Как видно из этого рисунка, все части модели, остающиеся неизменными после применения правила, окрашиваются в черный, а остальные - в красный. Это более наглядно, чем символьные маркеры в GReAT.

Однако с появлением похода QVT авторы VIATRA стали поддерживать именно его. Был разработан текстовый язык VTML (Viatra Textual Metamodeling Language) [2].

Такой переход снизил наглядность и простоту использования данного фреймворка, однако появились и некоторые преимущества. Так, была реализована поддержка метамоделирования. Метамодели должны описываться на VTML, однако такое описание легко сконвертировать в диаграмму UML. Вдобавок, авторы значительно улучшили механизм верификации и валидации моделей, что дало возможность шире применять этот фреймворк [2].

На рис. 8 изображена метамодель, аналогичная следующему коду на языке VTML:

entity(UML)

{

entity(Class);

entity(Association);

entity(Attribute);

relation(src,Association,Class);

relation(dst,Association,Class);

relation(parent,Class,Class);

relation(attrs,Class,Attribute);

multiplicity(attrs,many-to-many)

relation(type,Attribute,Class);

}

 

 

Аналогичный синтаксис используется для записи трансформаций моделей. Основой описания трансформации является шаблон. Шаблон - это условие, которое выделяет в модели один из элементов. Это понятие очень близко к Левой части правила графовой грамматики. В VIATRA также есть возможность в описании шаблона сослаться (вызвать) другой шаблон и, таким образом, определить новый шаблон на основе старого [2].

Для описания преобразования необходимо сначала описать шаблоны всех элементов, которые будут в нем участвовать. Затем описывается правило, в котором сначала перечисляются шаблоны элементов, которые нужно найти (Левая часть), а затем с помощью ключевых слов указываются шаблоны элементов, изменяемых этим правилом. Например, ключевое слово new, написанное перед шаблоном, указывает на то, что в модель будет добавлен элемент, который будет удовлетворять этому шаблону. Ключевое слово del говорит об удалении элемента.

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

Заключение

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

Язык QVT является высокоуровневым языком программирования, предоставляющим широкие возможности описания  трансформаций. Вдобавок, для описаний на QVT можно легко построить соответствующую графовую грамматику. Однако этот язык является текстовым, что мешает подключить к работе непрограммистов. Хотя по описаниям трансформаций на QVT легко построить соответствующую графовую грамматику, стандарт языка не предполагает такой возможности. В результате, в большинстве средств, использующих QVT, нет встроенного механизма визуализации.

Язык ATLAS является диалектом языка QVT и, как следствие, наследует все его сильные и слабые стороны: ATLAS является высокоуровневым языком, удобным лишь для программистов. Одним из отличий от QVT является очень жесткое ограничение на создаваемые трансформации - в левой части правил в ATLASе допускается наличие лишь одного элемента. Это сильно усложняет разработку, увеличивая количество правил в системе. С другой стороны, благодаря такому ограничению, авторы ATLASа сумели реализовать автоматическую трансформацию ограничений, описанных на OCL.

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

Все три аппарата (QVT, ATLAS и грамматики) могут применяться при разработке программ как с использованием метамоделирования, так и по технологии MDA. Но в рамках MDA был предложен и особый метод создания трансформаций, использующий возможности как метамоделирования, так и MDA. Он был предложен разработчиками фреймворка трансформаций DSM в MDA. Этот фреймворк сам строит трансформации, основываясь на описанных пользователем метамоделях и моделях. Трансформация проходит в три этапа, каждый из которых автоматически верифицируется. Это гарантирует, что полученная модель соответствует конечной метамодели.

АТоМ является достаточно мощным средство создания графовых грамматик. Отдельно стоит отметить значительное количество отлаженных формализмов и средств их трансформации, которые поставляются вместе с АТоМом. Так, одним из этих формализмов является метамодель GPSS, позволяющая не только наглядно описывать модели систем массового обслуживания, но и генерировать код, соответствующий построенным системам. Однако АТоМ обладает крайне неудобным интерфейсом, а также в АТоМ не предусмотрены средства модификации ограничений, наложенных на модель. Это снижает его привлекательность.

GReAT, как и АТоМ, является мощной средой разработки графовых грамматик. Однако авторы  однако GReAT использовали нетрадиционный способ отображения  правил. Это снижает их наглядность и читабельность. Такой подход удобен для хранения продукций, так как позволяет не тратить память под дублирование неизменяемых элементов. Одним из преимуществ системы GReAT является возможность указания кардинальности элементов. Однако задание кардинальности в графах сопряжено с рядом трудностей, и не всегда такое сокращение можно использовать.

Фреймворк VIATRA не предназначен для горизонтальных трансформаций моделей. Его основное назначение - верификация и валидация построенных моделей путем их трансформации. Язык QVT оказался более подходящим для этих целей, так как авторы разработали простой и надежный алгоритм верификации. В результате, они отказались от наглядности в пользу надежности.

Библиографический список

1.  Balasubramanian D., Narayanan A., Buskirk C., Karsai G. The Graph Rewriting and Transformation Language: GReAT: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://www.springerlink.com/content/b1k10p776651765w/ (дата обращения: 27.12.2011).
2. Balogh A., Varro D. Advanced Model Transformation Language Constructs in the VIATRA2 Framework: [Электронный ресурс] . Систем. требования: Adobe Acrobat Reader. - URL: http://static.inf.mit.bme.hu/pub/varro/2006/sac2006_vtcl.pdf (дата обращения: 27.12.2011).
3. Brambilla M., Fraternali P., Tisi M. A Transformation Framework to Bridge Domain Specific Languages to MDA: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://home.dei.polimi.it/mbrambil/legacytomda/resources/MDWE_best08.pdf (дата обращения: 27.12.2011).
4.  Csertan G., Huszerl G., Majzik I., Pap Z., Pataricza A., Varro D. VIATRA - Visual Automated Transformations for Formal Verification and Validation of UML Models (Tool demonstration) : [Электронный ресурс] . Систем. требования: Adobe Acrobat Reader. - URL: http://static.inf.mit.bme.hu/pub/ase2002_varro.pdf (дата обращения: 27.12.2011).
5. De Lara J. AToM3 programming tutorial: the AToM3 Python API: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://atom3.cs.mcgill.ca/tutorials.dtml (дата обращения: 27.12.2011).
6.  De Lara J., Vangheluwe H., Alfonseca M. Meta-modelling and graph grammars for multi-paradigm modelling in AToM 3: [Электронный ресурс] . Систем. требования: Adobe Acrobat Reader. - URL: http://www.springerlink.com/content/atmw5mtfqa33cmh1/ (дата обращения: 27.12.2011).
7. Grabska E., Strug B. Applying Cooperating Distributed Graph Grammars in Computer Aided Design: [Электронный ресурс] . Систем. требования: Adobe Acrobat Reader. - URL: http://www.springerlink.com/content/1710752758t62806/ (дата обращения: 27.12.2011).
8. Greenyer J., Kindler E. Reconciling TGGs with QVT: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: https://sosa.ucsd.edu/confluence/download/attachments/8257990/Reconciling%2BTGGs%2Bwith%2BQVT.pdf (дата обращения: 27.12.2011).
9. Jouault F., Kurtev I. Transforming Models with ATL: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://wwwhome.cs.utwente.nl/~kurtev/files/Models2005.pdf (дата обращения: 27.12.2011).
10.  Juha-Pekka T., Matti R. MetaEdit+: defining and using domain-specific modeling languages and code generators: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://portal.acm.org/citation.cfm?id=949365 (дата обращения: 27.12.2011).
11.  Kleppe A., Warmer J., and Bast W., MDA Explained. The Model Driven Architecture: Practice and Promise: [Электронный ресурс] . Систем. требования: Adobe Acrobat Reader. - URL: http://www.springerlink.com/content/1350722768t69206/ (дата обращения: 27.12.2011).
12.  MDA Guide Version 1.0. OMG document, Miller, J. and Mukerji, J. Eds., 2003 [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://www.omg.org/docs/omg/03-06-01.pdf (дата обращения: 27.12.2011).
13. Meta Object Facility (MOF) 2.0 Core Specification, OMG document, October 2003, [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://www.omg.org/cgi-bin/doc?ptc/2004-10-15 (дата обращения: 27.12.2011).
14. Montanari U., Rossi F. Graph Rewriting, Constraint Solving and Tiles for Coordinating Distributed Systems: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://www.springerlink.com/content/xmm0090271n6r833/ (дата обращения: 27.12.2011).
15. Stevens P. Bidirectional Model Transformations in QVT: Semantic Issues and Open Questions: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://homepages.inf.ed.ac.uk/perdita/bidirectional.pdf (дата обращения: 27.12.2011).
16.  Vizhanyo A., Neema S., Shi F., Balasubramanian D., Karsai G. Improving the Usability of a Graph Transformation Language: [Электронный ресурс]. Систем. требования: Adobe Acrobat Reader. - URL: http://www.isis.vanderbilt.edu/node/3492 (дата обращения: 27.12.2011).

Научный руководитель:
Доцент кафедры математического обеспечения ВС, к.ф.-м. н., доцент Л.Н. Лядова

Код для цитирования: Скопировать