CC BY
38
Том 10. № 5 (59). 2015
Д. В. Ошкало, аспирант, МГТУ им. Н. Э. Баумана, Москва, dmitry.oshkalo@gmail.com
синхронизация моделей при разработке программного обеспечения
Рассмотрен процесс синхронизации как основной механизм корректного переноса изменений между моделями в условиях моделе-ориентированной разработки . Определены его задачи и особенности, сформулированы требования к нему . Предложена реализация процесса при помощи трансформации моделей . На основании приведенной классификации подходов к трансформации и заявленных требований определен наиболее приемлемый для реализации подход и дальнейшие шаги по его доработке .
Ключевые слова: моделе-ориентированная разработка, МОР, синхронизация моделей, трансформация моделей, правила трансформации
введение
В основе моделе-ориентированного подхода к разработке программного обеспечения лежит использование моделей — артефактов, содержащих информацию, необходимую для поддержки различных этапов процесса разработки: проектирования, анализа требований, программной реализации, тестирования, верификации и т. д. Помимо этого, модели могут представлять систему и ее части с различных точек зрения разного уровня абстракции. Модель — это концептуальное описание, выполненное при помощи одного из языков моделирования — UML [1], Ecore [2] или любого другого более специализированного языка (DSL). Ее наполнение определяется средствами языка моделирования, который, в свою очередь, является моделью более высокого уровня, чем те, которые он позволяет описывать. Такая модель называется метамоделью, а модели, описываемые с ее помощью, называются ее экземплярами.
Для обеспечения совместимости языков моделирования, а также возможности многократного использования моделей в различных системах и создания на их основе других моделей был разработан стандарт MOF (Meta-Object Facility) [3], определяющий
отношения между моделями и формирующий многоуровневую архитектуру моделей.
Помимо формального представления информации модели служат для автоматизированного построения различных компонентов системы — программного кода, документации, файлов конфигурации и т. п., а также других моделей. Последний сценарий использования моделей является наиболее сложным и представляет интерес.
Хотя данный подход избавляет разработчиков от необходимости написания шаблонов и заготовок кода, создания конфигурационных файлов и скриптов и т. д., возникает ряд других задач, связанных с созданием и сопровождением моделей, количество и разнообразие которых в зависимости от сложности проекта может быть значительным.
Нередко эти модели так или иначе связаны друг с другом: либо они разрабатывались отдельно, но описывают одну и ту же информацию с разных позиций (например, различного рода концептуальные модели предметной области проекта), либо некоторые модели получены на основе других моделей (например, схема реляционной базы данных, созданная на основе диаграммы классов UML).
Таким образом, можно сказать, что в определенный момент времени в процес-
V^3
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА / JOURNAL OF APPLIED INFORMATICS
Vol. 10. No. 5 (59). 2015 '
се разработки модели являются консистентными по отношению друг к другу — т. е. информация, представленная в одной из моделей, согласованна (консистентна) с другой. Для обеспечения качества процесса разработки необходимо, чтобы связанные друг с другом модели эволюционировали совместно, сохраняя консистентность по отношению друг к другу: при внесении изменений в какую-либо из моделей необходимо, чтобы связанные с ней модели также были модифицированы с учетом этих изменений. Данное обстоятельство существенно усложняет сопровождение моделей в процессе разработки, поэтому необходим определенный механизм переноса изменений между связанными моделями. Таким образом, изменения в моделях рассматриваются как нарушение их консистентности, а перенос изменений — как способ ее восстановления. Процесс взаимного переноса изменений между моделями называется синхронизацией моделей.
Для решения такого рода задач применяются трансформации моделей, играющие ключевую роль в моделе-ориентированном подходе. Помимо переноса изменений между моделями трансформации используются для создания на основе моделей компо-
нентов системы, трансляции одних моделей в другие, рефакторинга моделей и т. п. На рис. 1 изображены основные компоненты сценария трансформации, осуществляющего перенос изменений между моделями т и п, причем как в одну, так и в другую сторону, т. е. изменения в т могут быть перенесены в п и наоборот.
Перенос изменений осуществляется путем применения правил трансформации, определенных в терминах метамоделей, по некоторому принципу. Более подробно эти компоненты описаны ниже.
Наиболее простым способом решения обозначенной проблемы представляется создание набора правил трансформации измененной модели в связанную с ней модель таким образом, что исходная связанная модель уничтожается, а ее новая версия генерируется заново на основе измененной модели согласно определенному набору правил (рис. 2а).
Подобный подход не может считаться достаточным для синхронизации моделей, так как он неработоспособен в тех случаях, когда изменения были внесены в обе модели (рис. 2б). Символом Я на рис. 2 обозначено отношение консистентности, связывающее
Метамодель M «- Ссылается
/
Является экземпляром
Модель m s-
Правила трансформации
Ссылается
Метамодель N
Использует
Является экземпляром
Механизм трансформации
Модель n
Чтение/перенос изменений
Чтение/перенос изменений
Рис. 1. Основные компоненты переноса изменений между моделями Fig. 1. The main components of an inter-model change propagation
TA_j
Том 10. № 5 (59). 2015
а) б)
Рис. 2. Сценарии синхронизации моделей Fig. 2. Model synchronization scenario
модели. Более подробно о нем будет сказано дальше.
В данной статье рассматриваются только те подходы, которые предполагают перенос изменений между моделями с минимально возможным ущербом для их содержимого.
Отметим также, что синхронизация может затрагивать сколь угодно много моделей, однако для рассмотрения ее аспектов достаточно будет сценария с двумя синхронизируемыми моделями.
Целью данной работы является описание основных особенностей процесса синхронизации и его реализация путем трансформации моделей.
Как будет показано, подобная реализация обладает рядом недостатков и не способна выполнить все требования, предъявляемые к синхронизации моделей. Для решения этой проблемы приводится классификация методов трансформации, на основе которой проводится сравнение используемых в настоящее время на практике подходов. По результатам сравнения будет выбран подход для реализации на его основе механизма синхронизации моделей.
Задача синхронизации моделей
Синхронизация моделей представляет собой процесс установления отношения консистентности между моделями. Формально под консистентностью двух моделей понимается следующее.
Пусть имеются метамодели М и N, а также модели т и п, причем т е М , п е N. Две модели т е М и п е N считаются связанны-
ми отношением консистентности Я с М х N тогда и только тогда, когда (т, п)е Я [4].
Отношение Я симметрично:
(Ут еМ,п е N, Я с МхN)(Я(т,п)^ Я(п,т)).
Данное отношение рассматривается на уровне метамоделей. В зависимости от конкретной предметной области, в которой находятся рассматриваемые модели, оно может быть:
1) биективным: каждому экземпляру метамодели М соответствует единственный экземпляр метамодели N и наоборот:
(Ут е М)(3!п е N : Я(т,п))л
л(Уп е N)(3!т е М : Я(т,п));
2) сюръективным: каждый экземпляр ме-тамодели М соответствует единственному экземпляру метамодели N, а каждому экземпляру метамодели N, в свою очередь, соответствует по крайней мере один экземпляр метамодели М:
(Ут е М)(3!п е N : Я(т, п))л
л(Уп е N)(3т е М : Я(т, п));
3) общего характера: каждый экземпляр метамодели М соответствует по крайней мере одному экземпляру метамодели N и наоборот:
4) (Ут е М)(3п е N : Я(т,п))л
л(Уп е N)(3т е М : Я(т, п)).
Отношение Я подразумевает, что элементам одной модели можно поставить в соответствие некоторые элементы другой модели.
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА / JOURNAL OF APPLIED INFORMATICS
Vol. 10. No. 5 (59). 2015 '
Однако что именно стоит за этим соответствием, зависит от конкретной предметной области. Способ задания соответствия также не определен: это может быть перечисление пар элементов метамоделей, использование представлений метамоделей в виде графов и задание соответствия в виде графовых паттернов, а также любой другой способ.
В приведенном выше определении рассматриваются только те случаи, когда отношение Я существует на всем множестве элементов обеих метамоделей. На практике же возможны случаи, когда некоторые элементы метамоделей не участвуют в процессах трансформации, т. е. один вид моделей может содержать в себе информацию, недоступную другому, поэтому при синхронизации таких моделей возможны частичные потери информации, обусловленные тем, что в данном случае по одной модели нельзя достоверно полностью восстановить другую.
На рис. 3 показана схема процесса синхронизации двух моделей.
В определенный момент времени модели т1 е М и п1 е N связаны отношением конси-стентности: (т1, п1) е Я . Далее в модель т1 вносится изменение и, а в модель п1 — V таким образом, что (т2, п2)е Я. Информация о текущем (т1 и п1) и измененном (т2 и п2)
состоянии моделей, а также внесенные в них изменения обрабатываются механизмом синхронизации с целью создания изменений и1 и v1 в моделях т2 и п2 соответственно, таких, что получившиеся модели т3 и п3 будут корректны (т. е. будут продолжать являться экземплярами метамоделей М и N соответственно), а также будут связаны отношением консистентности Я.
К процессу синхронизации моделей предъявляются следующие требования.
1. Детерминированность [5], т. е. предсказуемость результата синхронизации. Данное требование основано на том, что синхронизация моделей не изолирована от процесса проектирования, и разработчик должен точно знать, к чему приведет результат очередной синхронизации. В частности, для одних и тех же моделей результат синхронизации должен быть одинаковым. В работе [6] говорится о том, что детерминированность всегда должна предполагать единственный возможный вариант трансформации элементов между моделями. Принимать ли требование к детерминированности в таком виде, зависит от конкретного случая реализации системы синхронизации.
2. Стабильность [7]: процесс синхронизации не должен изменять модель, если никаких изменений в модели не было сделано.
R
Рис. 3. Схема взаимного переноса изменений между моделями путем синхронизации Fig. 3. Diagram of an inter-model change propagation by means of synchronization
1LJ
Том 10. № 5 (59). 2015
3. Полнота: не должно существовать корректных изменений, которые не могли бы быть перенесены в сопряженные модели. В противном случае внесенные изменения считаются некорректными.
4. Корректность: процесс синхронизации должен быть направлен на то, чтобы привести модели к консистентному состоянию.
5. Принцип Гиппократа, т. е. принцип наименьшего вреда [7]. Процесс синхронизации должен вносить изменения в структуру моделей таким образом, чтобы набор этих изменений был минимально возможным из тех наборов изменений, которые привели бы модели к консистентному состоянию. Принципы стабильности и возможности отката изменений являются частными формами данного принципа.
6. Возможность отката изменений. Данное требование проявляется в следующем сценарии. Исходная модель была модифицирована, и связанные с ней изменения были перенесены в целевую модель — таким образом, обе модели стали консистентными. После этого изменения в первой модели были отменены, она вернулась к своему первоначальному состоянию. В этом случае целевая модель также должна вернуться к своему первоначальному состоянию.
7. Сохранение пользовательских данных [7]. Данное требование означает, что в процессе синхронизации не должны игнорироваться или блокироваться пользовательские изменения в моделях, что проявляется при разрешении конфликтных ситуаций.
Далее проанализируем, как можно реализовать механизм синхронизации, соответствующий приведенной схеме и удовлетворяющий вышеперечисленным требованиям, путем применения трансформации моделей
От трансформаций к синхронизации
Как было отмечено ранее, процесс синхронизации моделей направлен на обеспечение качества разработки программного обеспечения. Так как в процессе разработ-
ки представление о предметной области, ее компонентах и их взаимосвязях может меняться довольно часто, возникает необходимость в частом и, главное, корректном внесении изменений в обе модели с тем условием, чтобы одно представление не противоречило другому.
В первом приближении синхронизацию можно рассматривать как процесс двунаправленных трансформаций моделей. Данный принцип лежит в основе всех использующихся в настоящее время подходов к синхронизации моделей.
В этом случае процесс синхронизации условно можно представить в виде двух функций [6]:
Я : М х N ^ N Я : М х N ^ М
Для заданной пары моделей (т, п)е М х N функция Я изменяет модель п, чтобы она стала консистентной по отношению к модели т, функция Я, соответственно, выполняет обратную операцию.
Однако синхронизация является более сложным процессом по сравнению с двунаправленными трансформациями.
Во-первых, трансформация — это всего лишь механизм переноса изменений. Перед ней не стоит цель связывать что-либо воедино — она лишь средство для актуализации состояния моделей. Решение проблемы синхронизации в этом случае практически полностью остается на стороне разработчика. В отличие от трансформации конечной целью процесса синхронизации является создание взаимосвязи между моделями.
Во-вторых, процессы трансформации не решают проблемы взаимного одновременного переноса изменений между моделями и разрешением связанных с этим спорных ситуаций, возникающих при условии одновременного внесения изменений в обе синхронизируемые модели (рис. 4).
Например, в случае синхронизации диаграммы классов UML со схемой реляционной базы данных соответствие между классами UML и таблицами схемы определено
Vol. 10. No. 5 (59). 2015
Рис. 4. Конфликтные ситуации при синхронизации моделей Fig. 4. Conflict situations in model synchronization
как «каждому классу соответствует таблица с тем же именем и наоборот». Конфликтная ситуация возникнет в том случае, если в диаграмме UML изменить имя одного из классов, а в схеме базы данных удалить соответствующую этому классу таблицу. При попытке переноса изменений изменение в диаграмме приведет к тому, что соответствующая классу таблица должна быть переименована, но она была удалена изменением, осуществленным в схеме. Из такой ситуации возможны два выхода: либо откат изменения в схеме и переименование таблицы согласно изменению в диаграмме UML, либо удаление переименованного класса.
В-третьих, трансформация не направлена на то, чтобы проверять целостность взаимосвязи между моделями. Разумеется, инкрементальные по своему характеру трансформации способны создавать видимость того, что целостность моделей поддерживается, так как модифицируются только отображения измененных компонентов модели. Однако как таковой проверки целостности при этом нет, так как процессы трансформации не обеспечены механизмами поиска соответствий между элементами моделей, а также механизмами планирования переноса изменений. Особенно этот эффект проявляется в том случае, когда отношение кон-систентности между моделями носит общий характер, т. е. одной и той же модели могут соответствовать несколько других моделей. Например, упомянутые выше диаграммы классов UML и схема реляционной ба-
зы данных. В этом случае возможны изменения, которые не повлияют на отношение консистентности между моделями, в связи с чем возможно нарушение принципа наименьшего вреда.
Кроме того, в случаях, когда отношение между моделями не является биекци-ей, необходимо наличие механизма выбора стратегии трансформации элементов одной модели в элементы другой в зависимости от ряда критериев и требований, предъявляемым к моделям. Процессы трансформации позволяют осуществить такой выбор.
Таким образом, можно отметить следующие особенности процесса синхронизации, которые выделяют его на фоне других активностей при моделе-ориентированной разработке.
1. Целью синхронизации является установление консистентности между моделями.
2. Процесс синхронизации должен обладать механизмом проверки целостности моделей.
3. Процесс синхронизации должен обладать механизмом планирования переноса изменений и выбора стратегии переноса на основе определенных критериев.
4. Возникающие в процессе синхронизации спорные ситуации должны разрешаться.
Далее рассмотрим классификацию подходов к трансформации моделей и выделим наиболее важные аспекты, касающиеся возможности их использования при синхронизации с учетом выделенных особенностей этого процесса и требований, предъявляемых к нему.
Том 10. № 5 (59). 2015
Классификация трансформаций моделей
На рис. 5 приведены основные свойства процессов трансформации, по которым их можно классифицировать. Данный набор, однако, не является полным. В нем представлены лишь те свойства, которые представляют интерес с точки зрения процесса синхронизации моделей. Другие варианты свойств трансформаций доступны в [8-10].
Ниже будут рассмотрены следующие подходы, используемые для трансформации моделей: QVT (Query View Transformation) [11], ATL (Atlas Transformation Language) [12], TGG (Triple Graph Grammars) [13], AGG (Attributed Graph Grammars) [14], AToM3 [15] и VIATRA [16]. Выбор обусловлен тем, что данные подходы нашли наиболее широкое практическое применение.
Связи между элементами. Вследствие трансформации устанавливаются связи между элементами моделей, которые могут быть полезны при оценке влияния внесен-
ных изменений, выборе стратегии применения правил трансформации и т. д. Некоторые подходы (QVT, АТ_, TGG) автоматически создают связи между элементами. Наличие связей между элементами моделей является важной составляющей синхронизации.
Отношение между моделями. Модели, участвующие в процессе трансформации, могут быть экземплярами одной метамоде-ли. В этом случае они называются гомогенными, иначе — гетерогенными. Процессы трансформации между гомогенными моделями, как правило, используются в целях ре-факторинга или отладки. Синхронизация же затрагивает только гетерогенные модели. На метамоделях, экземплярами которых являются синхронизируемые модели, может быть задано отношение консистентности — декларативно (QVT, А^) или с использованием дополнительных структур (TGG).
Проверка изменений. Как было отмечено, синхронизация должна осуществлять корректный перенос изменений. Для этого необходимо проверять вносимые в мо-
Рис. 5. Свойства процессов трансформации моделей Fig. 5. Properties of model synchronization processes
79
Vol. 10. No. 5 (59). 2015
дели изменения. Такая проверка может осуществляться либо «на лету», либо уже после применения всех необходимых правил трансформации. В последнем случае при возникновении ошибки происходит откат внесенных изменений. По какому принципу осуществлять проверку изменений и какие параметры моделей должны быть проверены, зависит от используемого подхода и моделей. Например, для диаграмм UML возможна проверка с использованием OCL (Object Constraint Language) [17].
Направленность. Трансформации могут быть как однонаправленными, так и двунаправленными. Для решения задачи синхронизации используются только последние, однако существуют подходы, позволяющие реализовать двунаправленные трансформации путем комбинации двух однонаправленных. Так обстоит дело с ATL [18]. При этом происходит объединение моделей [19], полученных путем прямой и обратной трансформаций с использованием алгоритма diff3 [20], применяемого в системах контроля версий, когда необходима синхронизация различных структурированных наборов данных [21]. Подобный подход позволяет осуществлять двунаправленную синхронизацию с возможностью разрешения конфликтных ситуаций.
Спецификация. Описывает отношение между моделями.
Характер переноса изменений. При внесении изменений в одну из моделей другая может быть полностью создана заново на основе последнего состояния первой, и наоборот. Подобный подход неприемлем для синхронизации моделей, так как нарушает принцип наименьшего вреда. Для его выполнения необходимо, чтобы изменения, вносимые в модель, носили инкрементальный характер, т. е. не затрагивали модель целиком. Подходы,основанные на применении графовых грамматик (AGG, TGG), а также QVT, осуществляют инкрементальный перенос изменений.
Контроль применения правил. Включает в себя несколько аспектов. Под локализацией понимается механизм поиска тех элемен-
тов модели, для которых можно применить правило трансформации. В зависимости от подхода используются разные способы локализации. Например, в подходах, в которых модель представляется в виде графа (AGG, TGG), локализация осуществляется при помощи алгоритмов поиска морфиз-мов на графах: ищется соответствие между графом, являющимся условием применения правила, и графом модели. Порядок применения правил определяет отношения между правилами трансформации с тем, чтобы удовлетворить требованиям детерминированности, полноты, корректности. Обычно порядок определяется приоритетом, назначенным правилу на основании того, к каким элементам модели оно применяется и какое место занимают эти элементы в общей структуре модели. Например, при трансформации диаграмм классов UML сначала необходимо обработать элементы пакетов, после этого — элементы классов, а затем — атрибуты классов. Выбор правила, которое будет применено, может быть как детерминированным (на основании приоритета), так и недетерминированным, как это реализовано в AToM3, AGG и VIATRA.
Кроме того, в AGG есть возможность анализа правил трансформации на предмет обнаружения конфликтов — т. е. когда несколько правил могут быть применены по одному и тому же условию [14]. В некоторых подходах возможна специальная организация правил. Например, в QVT возможно наследование между правилами и логическая композиция правил. Помимо этого, правила могут выполняться в цикле до достижения некоторого условия. Для реализации возможности отката изменений необходимо сохранять историю применения правил.
Правила трансформации (рис. 6) — конструкции, состоящие из двух частей: левой, относящейся к исходной модели, и правой, соответствующей целевой модели.
При соблюдении условий применения правила в исходной модели при синхронизации сначала осуществляется проверка наличия структуры из правой части правила
80
ПРИКЛАДНАЯ ИНФОРМАТИКА / JOURNAL OF APPLIED INFORMATICS /-
' Том 10. № 5 (59). 2015
Рис. 6. Структура и свойства правил трансформации моделей Fig. 6. Structure and properties of model transformation rules
в целевой модели. В случае ее отсутствия она создается, и между элементами обеих моделей устанавливается связь. В противном случае связь устанавливается без создания элементов в целевой модели. Обе части могут содержать следующие конструкции.
Направленность. Правило трансформации читается в одном направлении (слева направо), однако в некоторых подходах (QVT, TGG) правила построены таким образом, что являются двунаправленными (могут читаться и выполняться в обе стороны).
Параметризация. Правила могут иметь дополнительные параметры.
Условия применения. Правила могут содержать условия, ограничивающие возможности их применения. Существует два типа таких условий: PAC (Positive Application Condition) и NAC (Negative Application Condition) [14; 22]. Правило, в состав которого включен PAC, применяется тогда и только тогда, когда условие PAC выполнено. Для NAC, соответственно, правило выполняется тогда, когда условие NAC не выполнено. Условия могут задаваться различными способами: переменными, паттернами и т. д.
Дополнительные структуры могут использоваться для сохранения состояний моделей на случай отката изменений, связей между элементами моделей и других подобных задач.
Переменные могут содержать как элементы моделей, так и промежуточные элементы (при наличии). Также возможно использование переменных, не относящихся к содержимому моделей, а характеризующих внешнюю среду (например, значение переменной, обозначающей СУБД, может влиять на правила отображения типов атрибутов классов UML в соответствующие типы столбцов таблиц).
Логика представляет процедуры извлечения элементов из моделей и ограничения, определенные на элементах моделей. Логика может быть выполняемой и невыполняе-мой. Невыполняемая логика используется для определения отношений между моделями (QVT). Выполняемая логика может иметь декларативную (О^) и императивную (EMF) формы.
Паттерны представляют собой фрагменты модели с одной или несколькими переменными. Существуют строковые, графовые паттерны и паттерны термов. Строко-
v_81
Vol. 10. No. 5 (59). 2015
вые паттерны используются в текстовых шаблонах (QVT). В трансформациях между моделями (в том числе и синхронизации) широко используются графовые паттерны, на которых основан такой подход, как TGG. Основная идея данного подхода — система из двух совместно эволюционирующих моделей представляется в виде графа, который, в свою очередь, состоит из трех связанных друг с другом подграфов. Каждый подграф соответствует определенной схеме графов. Два из этих подграфов подвергаются изменениям, в то время как третий подграф поддерживает связь между их элементами. Благодаря наличию третьего графа связь между элементами двух других графов описывается в явном виде. Хотя выразительность графовых паттернов ограничена, их недостатки можно устранить путем использования дополнительных переменных и языков ограничений (например, OCL). Популярность таких подходов объясняется прежде всего удобством практического применения, которое выражается в наглядности, возможности использования графических редакторов при проектировании правил трансформации, более прозрачных и эффективных методах контроля, верификации и отладки разработанных трансформаций.
Паттерны могут быть представлены с помощью абстрактного или конкретного синтаксиса соответствующей исходной/целевой модели, а синтаксис может быть текстовым или графическим. Синтаксис правила может отличать левую и правую части или же не делать синтаксического различия. В этом случае правило будет двунаправленным. Паттерны и переменные могут быть не-типизированы либо типизированы синтаксически или семантически. В случае синтаксической типизации переменная ассоциируется с элементом метамодели, чьи значения она может принимать. Семантическая типизация позволяет ассоциировать более конкретные свойства.
С учетом требований, предъявляемых к синхронизации моделей, наиболее под-
ходящими для ее реализации являются два подхода: TGG и QVT.
В основе первого лежит использование графовых грамматик. Второй описывает трансформации в виде выражений на языке описания ограничений OCL. Благодаря этому подход представляется более гибким по сравнению с графовыми грамматиками. Однако, несмотря на различия в спецификации и форме записи правил, эти подходы во многом схожи, и можно определить однозначное отображение между ними [23].
Заключение
В статье рассмотрена задача синхронизации моделей при моделе-ориентирован-ной разработке, показаны ее основные особенности. Как уже было отмечено, решение данной задачи осуществляется путем особой организации трансформаций между моделями, хотя ни один из используемых на практике подходов не позволяет полностью удовлетворить требованиям, предъявляемым к синхронизации. По этой причине необходимо выбрать подход, наиболее полно удовлетворяющий требованиям, и определить те аспекты, в которых необходима доработка.
По результатам анализа различных подходов были выбраны подходы, основанные на TGG и QVT. Общими их чертами являются хорошо проработанная теоретическая основа, возможность проверки консистент-ности между моделями, инкрементальный характер изменений в моделях, основанный на приоритетах и иерархиях порядок применения правил. Таким образом, эти подходы удовлетворяют требованиям полноты, корректности, стабильности, возможности отката изменений и принципу наименьшего вреда. По поводу требования детерминированности можно отметить, что в условиях, когда отношение консистентности не является биекцией, одни и те же конструкции одной модели могут по-разному отображаться в другой, поэтому необходимо наличие стратегии выбора правила трансфор-
82L/
Том 10. № 5 (59). 2015
мации с учетом остальных требований. Помимо этого, нужно осуществлять проверку вносимых в модели изменений и разрешать конфликтные ситуации. Эти направления являются наиболее перспективными при реализации процессов синхронизации моделей.
Список литературы
1. Unified Modeling Language. URL: http://www.uml.org
2. Eclipse Modeling Framework. URL: http://eclipse.org/ modeling/emf
3. Meta-Object Facility. URL: http://www.omg.org/mof
4. Antkiewicz M, Czarnecki K. Design space of heterogeneous synchronization // Generative and Transformational Techniques in Software Engineering. 2008. Vol. 5235. P. 3-46.
5. Stevens P. Bidirectional Model Transformations in QVT: Semantic Issues and Open Questions // Model Driven Engineering Languages and Systems. 2007. Vol. 4735. P. 1-15.
6. Stevens P. A Landscape of Bidirectional Model Transformations // Generative and Transformational Techniques in Software Engineering. 2007. Vol. 5235. P. 408-424.
7. Xiong Y, Liu D, Hu Z, Zhao H, Takeichi M, Mei H. Towards automatic model synchronization from model transformations // Proc. 22-nd IEEE/ACM Conf. on Automated software engineering. Atlanta, 2007. P. 164-173.
8. Атисков А. Ю. Подходы к трансформации моделей проектирования информационных систем // Труды СПИИРАН. 2012. № 21. C. 184-202.
9. Czarnecki K, Helsen S. Feature-based survey of model transformation approaches // IBM Systems Journal — Model-driven software development. 2006. Vol. 45. P.612-645.
10. Biehl M. Literature Study on Model Transformations: tech. report, July 2010 / Royal Institute of Technology. Stockholm, 2010. — 28 p.
11. MOF 2.0 Query/View/Transformation. URL: http://www. omg.org/ spec/QVT
12. Atlas Transformation Language. URL: https: //eclipse. org/atl
13. Schuerr A. Specification of Graph Translators with Triple Graph Grammars // Proc. of the 20th Int. Workshop on Graph-Theoretic Concepts in Computer Science. Herrsching, 1995. P. 151-163.
14. Taentzer G. AGG: A Tool Environment for Algebraic Graph Transformation // Applications of Graph Transformations with Industrial Relevance Lecture Notes in Computer Science. 2000. P. 481-488.
15. De Lara J. AToM3 programming tutorial: the AToM3 Python API. URL: http://atom3.cs.mcgill.ca/tutorials. dtml
16. Balogh A, Varro D. Advanced Model Transformation Language Constructs in the VIATRA2 Framework. URL:
http://static.inf.mit.bme.hu/pub/ varro/2006/sac2006_vt-cl.pdf
17. Object Constraint Language. URL: http://www.omg.org/ spec/OCL
18. Xiong Y. A language-based approach to model synchronization in software engineering. PhD Thesis, Department of Mathematical Informatics, University of Tokyo, 2009. — 168 p.
19. Xiong Y, Hui S, Hu Z. From bidirectional model transformation to model synchronization // Elsevier Science. 2009. Vol. 8. P. 21-43.
20. Khanna S, Kunal K, Pierce B. A formal investigation of diff3 // Foudations of Software Technology and Theoretical Computer Science. 2007. Vol. 4855. P. 485-496.
21. Lindholm T. A three-way merge for xml documents // Proc. of the 2004 ACM symposium on Document engineering. N. Y., 2004. P. 1-10.
22. Hermann, F, Ehrig, H., Orejas, F, Czarnecki, K, Diskin, Z, Xiong, Y. Correctness of model synchronization based on triple graph grammars // Proc. of 14-th Conf. on Model Driven Engineering Languages and Systems. Wellington, 2011. P. 668-682.
23. Greenyer J., Kindler E. Reconciling TGGs with QVT // Proc. of 10-th Conf. on Model Driven Engineering Languages and Systems. Nashville, 2007. P. 16-30.
References
1. Unified Modeling Language. Available at: http://www. uml.org (accessed 05.07.2015).
2. Eclipse Modeling Framework. Available at: http:// eclipse.org/ modeling/emf (accessed 05.07.2015).
3. Meta-Object Facility. Available at: http://www.omg.org/ mof (accessed 05.07.2015).
4. Antkiewicz M., Czarnecki K. Design space of heterogeneous synchronization. Generative and Transformational Techniques in Software Engineering, 2008, vol. 5235, pp. 3-46.
5. Stevens P. Bidirectional Model Transformations in QVT: Semantic Issues and Open Questions. Model Driven Engineering Languages and Systems, 2007, vol. 4735, pp. 1-15.
6. Stevens P. A Landscape of Bidirectional Model Transformations. Generative and Transformational Techniques in Software Engineering, 2007, vol. 5235, pp. 408-424.
7. Xiong Y., Liu D., Hu Z., Zhao H., Takeichi M., Mei H. Towards automatic model synchronization from model transformations. Proc. of 22-nd IEEE/ACM Conference on Automated software engineering, Atlanta, 2007, pp. 164-173.
8. Atiskov A. Yu. Podkhody k transformatsii modelei pro-ektirovaniya informatsionnykh sistem [Approaches to transformation of informational systems design models]. TrudySPIIRAN, 2012, vol. 21, pp. 184-202.
9. Czarnecki K., Helsen S. Feature-based survey of model transformation approaches. IBM Systems Journal — Model-driven software development, 2006, vol. 45, pp. 612-645.
\ 83
Vol. 10. No. 5 (59). 2015
10. Biehl M. Literature Study on Model Transformations. Tech. report, July 2010, Royal Institute of Technology, Stockholm, 2010. 28 p.
11. MOF 2.0 Query/View/Transformation. Available at: http://www.omg.org/spec/QVT (accessed 05.07.2015).
12. Atlas Transformation Language. Available at: https: // eclipse.org/atl (accessed 05.07.2015).
13. Schurr A. Specification of graph translators with triple graph grammars. Proc. of the 20th International Workshop on Graph-Theoretic Concepts in Computer Science, Herrsching, Germany, 1994, vol. 903, pp. 151-163.
14. Taentzer G. AGG: A Tool Environment for Algebraic Graph Transformation. Applications of Graph Transformations with Industrial Relevance, Lecture Notes in Computer Science, 2000, pp. 481-488.
15. De Lara J. AToM3 programming tutorial: the AToM3 Python API. Available at: http://atom3.cs.mcgill.ca/tutori-als. dtml (accessed 05.07.2015).
16. Balogh A., Varro D. Advanced Model Transformation Language Constructs in the VIATRA2 Framework. Available at: http://static.inf.mit.bme.hu/ pub/varro/2006/sac2006_vtcl.pdf (accessed 05.07.2015).
17. Object Constraint Language. Available at: http://www. omg.org/ spec/OCL (accessed 05.07.2015).
18. Xiong Y. A language-based approach to model synchronization in software engineering. PhD Thesis, Department of Mathematical Informatics, University of Tokyo, 2009. 168 p.
19. Xiong Y., Hui S., Hu Z. From bidirectional model transformation to model synchronization. Elsevier Science, 2009, vol. 8, pp. 21-43.
20. Khanna S., Kunal K., Pierce B. A formal investigation of diff3. Foudations of Software Technology and Theoretical Computer Science, 2007, vol. 4855, pp. 485-496.
21. Lindholm T. A three-way merge for xml documents. Proc. of the 2004 ACM symposium on Document engineering, New York, 2004, pp. 1-10.
22. Hermann, F., Ehrig, H., Orejas, F., Czarnecki, K., Diskin, Z., Xiong, Y. Correctness of model synchronization based on triple graph grammars. Proc. of 14-th Conference on Model Driven Engineering Languages and Systems, Wellington, 2011, pp. 668-682.
23. Greenyer J., Kindler E. Reconciling TGGs with QVT. Proc. of 10th International Conference on Model Driven Engineering Languages and Systems, MoDELS 2007, Nashville, 2007, vol. 4735, pp. 16-30.
D. Oshkalo, Bauman Moscow State Technical University, Moscow, Russia, dmitry.oshkalo@gmail.com
Model synchronization in software engineering
Model-driven engineering approach considers the software project as a set of interrelated models representing the main artifacts of a development process, such as source code, configuration-al files, schemes of data warehouses, user interface, program architecture, etc. A relation between the models comes either from design dependencies (when one model is generated from another), or from the actual purpose of the models (when several models describe the same feature of the system). Both cases imply the related models to be consistent, i. e. the information is one model is somehow corresponds the information in another. Since the models are being modified, the consistency relation between them is broken and needs to be restored to maintain the development process. The article describes the activity called model synchronization, which handles the changes made to the models and correctly propagates them to the related ones, making them consistent. The activity is proposed to be built upon the well-defined model transformation techniques, which consist of a transformation engine and a set of transformation rules. Model synchronization properties and requirements are defined. Much consideration is given to incremental change propagation, conflict resolution and change verification. The classification of the model transformation methods and its vital parts is presented to define the most suitable approach as a basis for further model synchronization process development.
Keywords: model-driven development, MOF, model transformation, model synchronization, transformation rules. About author: D. Oshkalo, Postgraduate
For citation: Oshkalo D. Model synchronization in software engineering. Prikladnaya Informa-tika — Journal of Applied Informatics, 2015, vol. 10, no. 5 (59), pp. 73-84 (in Russian).
84 J
