CC BY
51
ВЕСТНИК САНКТ-ПЕТЕРБУРГСКОГО УНИВЕРСИТЕТА
Сер. 10. 2011. Вып. 3
УДК 004.434:004.42 Д. В. Кознов
О СПЕЦИФИКАЦИИ ДИАГРАММНЫХ ПРЕОБРАЗОВАНИЙ В ГРАФИЧЕСКИХ РЕДАКТОРАХ*)
Введение. Визуальное моделирование программных приложений (Visual Modeling) - это метод, применяемый в разработке программного обеспечения (ПО), который: 1) использует преимущественно графовые модели для визуализации ПО; 2) предлагает моделировать ПО с разных точек зрения; 3) может применяться в разработке и эволюции ПО, а также в различных видах деятельности по его созданию [1]. Наиболее известным языком визуального моделирования является UML [2], широко применяются на практике программные UML-средства, такие как MagicDraw (компания No Magic), Enterprise Architect (компания Sparx Systems), UModel (компания Altova), Rational Software Modeler/Architect (компания IBM)**). В настоящее время также активно развивается DSM-подход (Domain-Specific Modeling), нацеленный на создание визуальных языков и их программных реализаций для отдельных предметных областей, в частности для использования в одной компании, в определенном крупном проекте или при разработке линейки продуктов (Product Line) [4]. Такая специализация позволяет точнее схватывать абстракции предметной области. Сложность разработки программных средств поддержки данных языков существенно понизилась в связи с развитием таких технологий как Eclipse Modeling Project [5], Miscrosoft DSL Tools [6], MetaEdit+ [7].
В области визуального моделирования программных систем широко используется концепция различных представлений на создаваемую систему. Так, в [8] предлагается набор конкретных представлений, полезных при проектировании и разработке сложного ПО, методы объектно-ориентированного анализа и дизайна 1980-1990-х годов, такие как OMT, OOSE, метод Буча и др., а также рассматривать создаваемое ПО на основе некоторого набора представлений. Первые версии языка UML также состояли из набора представлений, которые являлись различными типами диаграмм и т. д. В дальнейшем в UML все более ослабляются заданность, фиксированность и строгость системы представлений: в последних версиях языка строгое деление на виды диаграмм исчезло. Авторы стандарта пишут, что разработчики UML-средств и пользователи языка могут
Кознов Дмитрий Владимирович — кандидат физико-математических наук, доцент кафедры системного программирования математико-механического факультета Санкт-Петербургского государственного университета. Количество опубликованных работ: более 50. Научные направления: визуальное моделирование (UML-подобные языки и программные средства), разработка технической документации, электронное образование. Сайт: http://www.math.spbu.ru/user/dkoznov. E-mail: [email protected].
*) Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований (грант 11-01-00622-а).
**) По оценкам известного UML-сообщества UML Forum [3], эти средства являются самыми зрелыми на сегодняшний день.
© Д. В. Кознов, 2011
произвольно смешивать различные конструкции языка на разных диаграммах. Гибкая концепция множественности представлений на модель реализована также в языке моделирования SysML [9]. Однако указанные подходы подразумевают лишь статические, определенные на момент работы с моделью, представления. Учитывая сложность современного ПО и соответственно сложность его моделей, это недостаточно для эффективной работы аналитиков, проектировщиков и разработчиков.
Современные программные средства для работы с визуальными моделями должны содержать многочисленные и удобные диаграммные сервисы, позволяющие просматривать (т. е. отображать/скрывать) на диаграммах различные части модели. Это дает возможность пользователю быстрее и лучше навигировать по моделям, смотреть на них то «в целом», то детализируя какой-либо фрагмент. Например, работая с большой моделью классов, «поднятой» в UML-пакет из исходных кодов, удобно иметь возможность отобразить/спрятать все атрибуты и методы некоторого класса, выявить всю иерархию наследования, в которой он участвует, показать классы, связанные с ним ассоциациями, и т. д.*) Подобные сервисы реализованы, например, в системе RescueWare, предназначенной для анализа и трансформаций устаревших приложений на новые платформы [11], а также в других средствах реинжиниринга и возвратного проектирования. Однако до сих пор не существует общего подхода по созданию этих сервисов.
При разработке графических редакторов в рамках DSM-подхода, а также при создании UML-средств можно и нужно предлагать и реализовывать много подобных преобразований, поскольку они очень удобны для пользователей. Без них средства визуального моделирования порой лишаются той «сервисности», которая во многом и делает их применение оправданным. Ведь главная задача программного кода - эффективно работать, а диаграмм и соответственно средств визуального моделирования - быть наглядными, предоставлять дополнительные и удобные средства работы с информацией. Но современные DSM-платформы, в частности Eclipse Modeling Project [5], покрывая значительное количество задач по автоматизации построения графических редакторов, не содержат специальных метасредств по разработке диаграммных сервисов.
Проектирование, разработка и отладка подобных средств оказывается очень трудоемкой задачей. Например, содержательно обсудить подобные преобразования зачастую можно лишь после того, как они уже реализованы в графическом редакторе, но если они реализованы неудачно, то значительное количество усилий оказывается потраченными зря**). Наличие специальных формальных средств, методов и специализированных библиотек может существенно помочь, уменьшив трудоемкость разработки подобных сервисов.
Привлекательным инструментом для создания концепции диаграммных сервисов является трансформационный подход. В области модельно-ориентированного подхода фокус исследований находится на преобразовании моделей (M2M Transformations) и на преобразовании моделей в программный код (M2C Transformations) [14, 15]. Однако работ, применяющих данный подход к спецификации диаграммных сервисов, нет.
Все это приводит к необходимости создания специальной концепции диаграммных сервисов. Мы будем основываться на трансформациях представлений и рассмотрим диаграммные сервисы как преобразования представлений модели с сохранением этой
*) Также требуются специальные средства для работы с большими метамоделями. Например, ме-тамодель языка UML содержит около 250 классов и, будучи представлена на одной диаграмме, оказывается совершенно неудобочитаемой. Метамодель UML в формате Ecore можно найти здесь [10].
**) Проблема неадекватности взглядов разработчиков DSM-средств на удобство использования создаваемых ими инструментов обсуждается в работах [12, 13].
модели в неизменном виде. В дальнейшем будем называть такие преобразования V2V-трансформациями (View-to-View Transformations).
В данной работе предложена концепция V2V-трансформаций. В п. 1 приводятся примеры подобных трансформаций. В п. 2 дается формальное определение V2V-трансформации. В п. 3 V2V-трансформации описываются «изнутри», с точки зрения выполняемых ими действий. В п. 4 приводится метамодель представлений, которая в дальнейшем будет положена в основу библиотеки классов программной поддержки нашего подхода. Наконец, в п. 5 описываются внешние интерфейсы, которые необходимы V2V-трансформации для реализации и выполнения в рамках конкретного графического редактора.
Автор выражает признательность всем участникам семинара «Визуальное моделирование», действующего на кафедре системного программирования СПбГУ, за обсуждение идей, изложенных в статье, за предложения, критику, а также за помощь в оформлении статьи - Елене Храмцовой, Антону Сорокину, Жене Ларчику, Александру Иванову, Кире Вяткиной, Ксении Саутиной и Анатолию Кондратьеву.
1. Примеры У2У-трансформаций. Простейшим примером У2У-трансформации является загрузка/выгрузка на диаграмму элемента, существующего в модели, в позицию на экране, выбранную пользователем редактора. Для диаграмм классов ИМЬ эта пара операций реализована почти во всех ИМЬ-средствах. Рассмотрим примеры более сложных У2У-трансформаций.
На рис. 1, а приведена диаграмма, на которой присутствует класс F. В какой-то момент пользователь захотел увидеть на диаграмме все атрибуты и методы этого класса. На рис. 1, б представлен результат выполнения такого запроса. Отметим, что из-за того, что прямоугольник класса F стал больше, изменилась отрисовка связей остальной части диаграммы.
Рис. 1. Пример У2У-трансформации: отображение атрибутов класса F
Пример трансформации, которая отображает иерархию наследования для класса Е, показан на рис. 2. Отметим, что класс Б на результирующей диаграмме изменил свое местоположение, так как он также участвует в иерархии наследования для класса Е.
2. Формальные определения. Пусть есть некоторая метамодель М. Будем считать, что работа пользователя с любой моделью М - экземпляром метамодели М -происходит в некотором графическом редакторе Е с помощью диаграмм - изменяемых
б
Рис. 2. Пример У2У-трансформации: отображение дерева наследования для класса Е
во времени, редактируемых пользователем и сохраняемых выборок из модели M, имеющих графическое изображение. Часто графический редактор реализует несколько типов диаграмм, например UML-пакеты содержат отдельные редакторы для диаграмм классов, объектов, состояний и переходов и т. д. Будем обозначать через TE множество типов диаграмм редактора E, а через Dt - множество всех диаграмм типа t, где t е Te *} .
Итак, диаграмма является долгоживущим объектом и имеет определенный тип, способ идентификации (т. е. возможность отличить одну диаграмму от другой), механизмы создания, изменения и уничтожения. Кроме того, диаграмма имеет состояние - т. е. некоторое подмножество модели M, которое она отображает. Будем называть это состояние диаграммы представлением. Множество всех возможных представлений диаграмм данного типа t, где t е TE, будем обозначать Vt. Итак, представление состоит из:
• некоторой выборки объектов из модели M;
• информации о том, какие атрибуты этой выборки видимы, а какие нет (так называемые свойства отображения — Display Options);
• графических свойств отображаемых элементов (Graphical Options).
Свойства отображения относятся к определенному типу элемента модели, например, ниже представлены примеры этих свойств для типа элемента модели под названием «Class»:
• отображать/скрывать атрибуты у всех классов,
• отображать/скрывать методы у всех классов,
• отображать/скрывать модификатор у атрибутов классов,
• отображать/скрывать тип у атрибутов классов,
• отображать/скрывать типы параметров и возвращаемого результата у методов классов.
*) Мы связываем тип диаграммы с графическим редактором, а не с метамоделью, так как в общем случае метамодель ничего «не знает» о типах диаграмм, на которых могут отображаться элементы ее моделей. Так, в описании метамодели UML говорится, что нет ограничений на присутствие конструкции того или иного типа на какой-либо диаграмме [16]. В то же время в графическом редакторе все определено строго и однозначно.
Вот примеры графических свойств для элементов модели, изображаемых на диаграмме/представлении: координаты, толщина линий, типы шрифтов, количество точек соединения линий и фигуры на границах фигуры, правила и ограничения на перерисовку (resizing) фигур и линий, виды расположения текста в фигурах (в частности, вид выравнивания, поддержка многострочного расположения текстовых элементов) и пр.
Диаграмму будем обозначать как d, представление - через v, текущее представление диаграммы d - как vj_. У любой диаграммы есть единственное текущее представление:
Vd 3 ! v (v = vd).
Отметим, что одновременно несколько разных диаграмм могут иметь одинаковые представления, и это означает, что на них нарисовано в точности одно и то же:
Vt е Te, Vdi, d2 е Dt ((di = d2)) ^ o3v е Vt((v = vdl & v = vd2)). (1)
Знак равенства «=» для диаграмм означает, что речь идет об одной и той же диаграмме, но может быть находящейся в разных состояниях. Соответственно «=» означает, что речь идет о разных диаграммах. Символ «о» означает модальность «возможно, что». То есть (1) утверждает, что возможна ситуация, когда на двух разных диаграммах нарисовано одно и то же.
Определим V2V-трансформацию как следующую функцию:
V2VM,ti,t2,ReqPattern : Dti х Vti х ReqValues ^ Dt2 x Vt2. (2)
Функция, задаваемая (2), действует на неизменной модели M и определяется для двух фиксированных типов диаграмм ti и t2 е Te , а также для некоторого шаблона запросов к модели ReqPattern (пример такого шаблона - выдать всю иерархию наследования для некоторого класса). Функция (2) действует на множестве всех диаграмм типа ti, каждая из которых в текущий момент имеет определенное представление этого же типа, и позволяет подставлять все допустимые значения ReqValues в шаблон запросов ReqPattern (в частности, любой класс, находящийся на любой из возможных диаграмм классов; для каждого из них является осмысленным запрос отобразить соответствующую иерархию наследования). Отметим, что в большинстве случаев ti = t2 и dtl = dt2, так как V2V-трансформация переводит одну и ту же диаграмму из одного состояния в другое. Однако возможны ситуации, когда по представлению одного типа трансформация генерирует диаграмму другого типа и соответствующее представление для нее, например диаграмму коммуникаций UML по диаграмме взаимодействий. Наконец, V2V-трансформация может преобразовывать одну и ту же диаграмму, а может создавать новую, имеющую этот же тип.
Теперь определим графический редактор для работы с моделями метамодели M и поддерживающий несколько видов диаграмм, где с каждым видом диаграмм связан набор диаграммных сервисов для создания, просмотра и навигации:
Em = ({t, V2VE,t} для всех t е Te). (3)
В (3) V2VE,t обозначает набор V2V-трансформаций для данного вида диаграмм t е Te, реализованный в редакторе E (понятно, что всех возможных трансформаций для этого типа диаграмм может быть значительно больше). Предлагаемый нами подход направлен на разработку именно таких редакторов. Конечно, в визуальных редакторах часто есть еще возможности для изменения и редактирования модели через диаграммы. Но в настоящей работе такие преобразования диаграмм не рассматриваются.
3.У2У-трансформация «изнутри». Итак, в графическом редакторе V2V-TpaHC-формация является функцией-обработчиком некоторой команды, которая, как правило, доступна пользователю из интерфейса графического редактора - из всплывающего меню элемента диаграммы или элемента модели в браузере проекта, из главного меню редактора, из всплывающего меню самой диаграммы и т. д. Вызов этой команды может сопровождаться заданием дополнительных параметров, что может быть сделано, например, в специальном диалоговом окне.
Теперь посмотрим на V2V-трансформацию «изнутри», с точки зрения выполняемых ею действий. V2V-трансформация оказывается композицией трех следующих действий: ModelRequest, ChangingViewModel и Arrangement.
ModelRequest - это запрос к модели, на основании которого создается та выборка из модели, которая должна быть добавлена на конечное представление. ModelRequest = ReqPattern (ReqValue).
ChangingViewModel - это процедура по созданию нового представления - трансформация исходного представления или генерация совершенно нового, - но пока еще без учета графического расположения элементов. Сюда входит как помещение на представление новых элементов из запроса к модели M, так и удаление из представления ненужных элементов.
Arrangement - это процедура задания новых графических свойств, главным образом координат элементов. Она может включать в себя автоматическую раскладку добавляемого на представление подмножества модели, а также изменение расположения прежних элементов (например, их сдвиг, для того чтобы дать место вновь отображаемой информации, как было в примере на рис. 2). Важно, чтобы V2V-трансформация не только формировала новое множество элементов, которое должно быть помещено на представлении, но и производила автоматическую раскладку этих элементов. Если Arrangement будет отсутствовать, то после выполнения V2V-трансформации пользователю могут потребоваться значительные усилия по «ручной» перерисовке помещенных на диаграмму элементов. «Ручная доводка» результатов раскладки может все равно понадобиться, но она должна быть сведена к минимуму.
Особо отметим, что в V2V-трансформациях не нужно задавать все графические свойства элементов представления, так как это чрезмерно загромоздило бы спецификацию трансформации и во многом обессмыслило весь подход. Мы предполагаем, что в окружении трансформации должны быть компоненты, которые взаимодействуют с ней во время ее работы и, в частности, выполняют все действия по отрисовке, для чего содержат все необходимые графические свойства. V2V-трансформация имеет доступ только к некоторым из них, как будет объяснено ниже. Детали взаимодействия раскладки элементов и отрисовки обсуждаются в п. 5.
4. Метамодель представлений. Формально определим метамодель представлений, так как именно над представлениями происходит выполнение V2V-транс-формаций. Эта метамодель будет реализована в рамках предлагаемого подхода, и ее отдельные экземпляры будут существовать в виде соответствующих run-time объектов для каждой диаграммы, когда она открыта в графическом редакторе, созданном с помощью нашего подхода. Наши трансформации (т. е. диаграммные сервисы данного типа диаграммы) будут трансформировать именно модели представлений.
Метамодель представлений изображена на рис. 3. Отметим, что представление и модель представления - не одно и то же. Модель представления - это структура данных для программной работы с представлением, в то время как само по себе представление
есть абстрактное понятие, используемое в формальных определениях или неформальных разговорах о подходе.
Рис. 3. Метамодель представлений
ESpecification - это корневой класс метамодели представлений. Экземпляр данного класса является проектом в графическом редакторе по аналогии, например, с Solution в Microsoft Visual Studio. Этот класс включает в себя модель (класс Model), набор типов элементов модели, которые отображаются на различных типах диаграмм редактора (класс ModelElemKind), и набор типов диаграмм такого редактора (класс DiagramType). Мы не следуем здесь полностью (3) - в частности, в нашей метамодели отсутствуют V2V-трансформации, так как в метамодели мы концентрируемся на задании прикладных классов, которые будут существовать в графическом редакторе,
созданном с помощью предлагаемого подхода. Трансформации являются внешними активными сущностями по отношении к метамодели и преобразуют их экземпляры, следуя подходам QVT и ATL [14, 15].
Класс Model включает в себя класс ModelElement, задающий все элементы, входящие в данную модель (например, классы, ассоциации, концы ассоциаций и пр.). ModelElement имеет уникальный идентификатор (атрибут ID) и имя (атрибут Name), а также множество атрибутов (множественное агрегирование с классом ModelAttribute). В предлагаемой на рис. 3 метамодели представлен лишь фрагмент метамодели того визуального языка, для которого создается данный графический редактор. И этот фрагмент должен быть включен в более детальное описание метамо-дели языка, что может быть сделано путем наследования классов метамодели языка от классов ModelElement, ModelAttribute. Со своей стороны, мы зафиксировали только ту информацию о метамодели визуального языка, которая необходима нашему подходу.
Класс ModelElementKind имеет уникальный идентификатор (атрибут ID) и имя типа элемента модели (атрибут ModelElementKindName). Этот класс агрегируется именно ESpecification, а не DiagramType, поскольку один и тот же тип элемента модели может присутствовать на разных типах диаграмм. Данный класс включает в себя также посредством множественного агрегирования класс DisplayOptionKind.
Класс DisplayOptionKind задает один специальный вид свойства отображения у типа элемента модели. DisplayOptionKind включает в себя уникальный идентификатор (атрибут ID), имя (атрибут Name), текстовое описание, а также значения для выбора (атрибут SelectedValues) - например, для модификатора видимости атрибутов класса такими значениями будут «видимый/невидимый». Конкретные значения этих свойств хранятся в экземплярах класса DisplayOption.
Класс DisplayOption задает одно специальное значение свойства, описанного в экземпляре класса DisplayOptionKind. Он имеет ссылку на класс DisplayOptionKind, а также уникальный идентификатор (атрибут ID) и значение (атрибут Value) - последний является одним из значений атрибута SelectedValues класса DisplayOptionKind.
Каждая диаграмма, а через нее и модель представления имеют некоторый тип, задаваемый классом, - DiagramType. Тип диаграммы имеет уникальный идентификатор (атрибут ID) и имя (атрибут TypeName), а также набор типов модельных элементов, которые могут отображаться на диаграммах и представлениях этого типа (множественная связь с классом ModelElemKind), и набор экземпляров класса DisplayOptionKind. Последние задают те групповые свойства отображения элементов модели, которые хочется задавать сразу для всех элементов диаграммы/модели представления.
Класс Diagram задает диаграммы, имеющиеся в данном графическом редакторе. Он включает в себя уникальный идентификатор (атрибут ID) и имя (атрибут Name), а также ссылку на тип диаграммы. Диаграмма включает в себя модель представления (класс ViewModel). Связь между диаграммой и моделью представления со стороны модели представления имеет множественность 0..1, а со стороны диаграммы - 1. То есть каждая модель представления принадлежит некоторой диаграмме, но диаграмма может не иметь пока еще модели представления - например, она только что создана.
Модель представлений задается классом ViewModel. Он имеет уникальный идентификатор (атрибут ID). Также он включает в себя набор конкретных значений свойств отображения (Display Options), которые задаются для модели представления в целом (множественное агрегирование класса DisplayOption). Каждая модель представления содержит в себе элементы - экземпляры класса ViewElement.
Класс ViewElement имеет уникальный идентификатор (атрибут ID), а также ссылку
на соответствующий элемент модели, который он представляет на диаграмме. Каждый элемент модели может быть несколько раз отображен в разных моделях представлений и, кроме того, неоднократно присутствовать на одной и той же. Элемент представления также может включать вложенные элементы (множественное агрегирование с пометкой Enclosed): например, сложное состояние на диаграммах состояний и переходов содержит внутри себя другие состояния и переходы. Элемент представления имеет свой тип (например, случай использования, состояние, класс), который является экземпляром класса ModelElementKind. Элементы представлений бывают трех видов - фигуры, линии и концы линий. Соответственно класс ViewElement наследуется тремя классами -ViewFigure, ViewLine и ViewLineEnd.
Класс ViewFigure описывает координаты левого верхнего угла прямоугольника, содержащего данную фигуру на диаграмме (атрибут TopLeftConer), а также размер этого прямоугольника (атрибут Rectangle). Класс ViewLine задает описание маршрута линии (атрибут Rout). Маршрут может быть задан координатами точек излома линии и ее стилем. Класс ViewLineEnd содержит координаты точки присоединения конца линии к фигуре (атрибут ConnectionPoint). Атрибуты этих классов являются тем минимальным количеством графических свойств (Graphical Options), которые необходимы для автоматической раскладки элементов представления из V2V-трансформации.
5. Внешние интерфейсы У2У-трансформации. На основе предлагаемого подхода предполагается разработать программную компоненту - «кубик» из конструктора по созданию графических редакторов. Она должна обеспечить программный интерфейс и определенные правила для разработки V2V-трансформаций, а также runtime поддержку для их исполнения в целевом графическом редакторе. Кроме того, компонента должна обеспечить набор внешних интерфейсов, чтобы заданные с ее помощью трансформации можно было бы вызывать извне, а также использовать и ряд интерфейсов со стороны окружения, так как она не должна реализовывать всю работу, нужную для выполнения трансформаций.
На рис. 4, 5 показано, как предлагаемая компонента и ее окружение должны взаимодействовать друг с другом, будучи встроенными в конечный графический редактор.
Компонента V2VTransformations реализует V2V-трансформации данного графического редактора. Она включает в себя код V2V-трансформаций, а также runtime поддержку, обеспечиваемую нашим подходом для исполнения этого кода.
Компонента Environmet скрывает за собой основной код редактора - реализацию рабочей области для отрисовки графических элементов, палитры графических элементов, взаимодействие с пользователем редактора, пункты главного меню и др. Именно через Environment пользователь редактора запускает V2V-трансформацию для выполнения тех диаграммных сервисов, которые ему понадобились в данный момент, используя соответствующие пункты меню, кнопки тулбара и пр.
Компонента Drawing отвечает за отрисовку графических элементов на диаграмме, применяя все необходимые графические свойства (Graphical Options). Эта компонента должна также предоставлять соответствующий пользовательский интерфейс в графическом редакторе для задания Graphical Options (всех или лишь части), что возможно, например в Visio и всех графических редакторах, созданных с его помощью.
Компонента ModelQuerySupport включает в себя средства доступа к модели, например реализацию языка OCL [17], выражения на котором разработчики V2V-трансформаций будут встраивать в их код. Удобно работать с моделью через подобный язык, а не напрямую, так как в этом случае код в трансформации будет значительно меньше и нагляднее, а создавать ее будет проще.
Рис. 4- Компонентная модель
Рис. 5. Взаимодействие компонент
Компонента Model отвечает за хранение и доступ к элементам модели. Эта информация нужна компоненте V2VTransformations для выполнения запросов к модели. Опишем интерфейсы данных компонент.
Интерфейс V2VTAccess содержит заголовки всех трансформаций, которые отвечают за реализацию диаграммных сервисов редактора. Используя данные заголовки,
компонента Enviroment вызывает эти сервисы, когда нужно (либо по требованию пользователя, либо при выполнении диаграммного сервиса как составной части некоторой более крупной функции, выполняемой редактором). Кроме заголовков, сигнатура трансформации должна также содержать описание параметров вызова, значения которых должны быть переданы трансформации из Enviromnet - как правило, это графические свойства, которые пользователь задал «в ручную», в некотором диалоге, перед тем, как вызвать трансформацию.
Интерфейс Draw предназначен для выполнения отрисовки отдельных элементов диаграммы в нужной позиции по команде компоненты V2VTransformations после определения точных координат в результате выполнения алгоритмов раскладки. Интерфейс содержит методы, описанные ниже.
1. Draw (ViewElement) - отвечает за отрисовку элемента в заданной позиции (позиция задается в компоненте V2VTransformations после выполнения алгоритма раскладки и сохраняется в параметрах TopLeftConner для фигуры и в атрибутах ConnectionPoint соответствующих экземпляров класса ViewLineEnd и Rout - класса ViewLine).
2. GetRectangle (ViewFigure) - выдает рамку фигуры, которую она занимает на диаграмме. Эта рамка вычисляется по свойствам отображения (Display Options) фигуры, которые передаются компоненте в качестве параметров компонентой V2VTransformation и используется при автоматической раскладке.
3. GetRout (ViewLine) - выдает маршрут линии, который сохраняется в атрибуте Rout данной линии и используется при автоматической раскладке.
Напомним, что свойства отображения являются теми атрибутами элемента модели, которые должны быть изображены на диаграмме. Например, для класса может быть задано, что нужно отображать на данной диаграмме только его имя и атрибуты, но без типов. По этой информации компонента Draw уже сама устанавливает, сколько нужно места в графическом элементе или рядом с ним, чтобы все это изобразить, и вычисляет рамку элемента, которая только и нужна для алгоритма раскладки, работающего в компоненте V2VTransformations. Данный интерфейс определяет, что из графической обработки входит в компоненту V2VTransforamtions, а что нет.
На рис. ?? показано схематичное взаимодействие компонент во время выполнения V2V-трансформации.
6. Заключение. Предложенный в работе подход требует дальнейшего развития в следующих направлениях:
1. Требуется разработка детальной формальной модели трансформации на основе темпоральных логик, включающей в себя формальное определение диаграммы (в том числе операции по ее созданию разными способами - пустой, автоматически по некоторому запросу к модели и т. д. - модификации и удалению), состояния диаграмм, переходы из одного состояния в другое посредством V2V-трансформаций.
2. Планируется построить детальную программную архитектуру компоненты, реализующей предложенный подход, в контексте Eclipse Modeling Project, который предоставляет большое количество различных инструментов для разработки средств визуального моделирования [18, 19]. В частности, особый интерес представляют такие компоненты этой платформы как GMF, а также его более низкоуровневая альтернатива - пара технологий EMF и GEF.
3. Требуется доработка формального подхода в части задания раскладок элементов представления.
4. Необходимо адаптировать какой-либо из существующих языков задания трансформаций QVT [14] или ATL [15] для задания V2V-трансформаций, поскольку последние могут задаваться как преобразования над метамоделью представлений. Следует включить в этот язык возможности задавать раскладку элементов представления.
5. Планируется выполнить интеграцию предложенного подхода с M2M-транс-формациями, поскольку пользователь графического редактора часто меняет диаграмму, одновременно изменяя и модель.
Литература
1. Кознов Д. В. Основы визуального моделирования. М.: Интернет-университет информ. технологий; БИНОМ. Лаборатория знаний, 2007. 248 с.
2. Буч Г., Максимчук Р. А., Энгл М. У. и др. Объектно-ориентированный анализ и проектирование с примерами приложений (UML 2). 3-е изд. СПб.: Изд-во «Вильямс», 2010. 720 с.
3. UML Forum, UML Tools. URL: http://www.uml-forum.com/tools.htm.
4. Kelly S., Tolvanen J. Domain-Specific Modeling: Enabling Full Code Generation. Wiley: Wiley-IEEE Computer Society Press, 2008. 448 p.
5. Eclipse Modeling Project. URL: http://www.eclipse.org/modeling/.
6. Microsoft DSL Tools. URL: http://msdn.microsoft.com/en-us/library/bb126235.aspx.
7. MetaCase MetaEdit+. URL: http://www.metacase.com/.
8. Kruchten P. The 4+1 View Model of Architecture// IEEE Software. 1995. Vol. 12, N 6. P. 42-50.
9. OMG Systems Modeling Language. Version 1.2. OMG, 2010. 260 p.
10. Eclipse Repositories. URL: http://dev.eclipse.org/viewcvs/viewvc.cgi/.
11. Бабурин Д. Е., Бульонков М. А., Емельянов П. Г., Филаткина Н. Н. Средства визуализации при перепроектировании программ // Программирование. 2001. № 2. С. 21-33.
12. Кознов Д. В. Разработка и сопровождение DSM-решений на основе MSF // Системное программирование. Вып. 3: сб. статей / под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2008. С. 80-96.
13. Kelly S., Pohjonen R. Worst Practices for Domain-Specific Modeling // IEEE Software. 2009. Vol. 26, N 4. P. 22-29.
14. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Version 1.0. OMG, 2008. 240 p.
15. URL: http://www.eclipse.org/atl/.
16. OMG Unified Modeling Language, Superstructure. Version 2.3. OMG, 2010. 758 p.
17. Object Constraint Language (OCL). OMG Specification. Version 2.0, formal/06-05-01. 2006. URL: www.omg.org.
18. Сорокин А. В., Кознов Д. В. Обзор Eclipse Modeling Project // Системное программирование. Вып. 5: сб. статей / под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2010. C. 6-31.
19. Gronback R. C. Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Addison: Wesley Professional, 2009. 736 p.
Статья рекомендована к печати проф. А. Н. Тереховым. Статья принята к печати 10 марта 2011 г.
