Дипломная работа студента 544 группы icon

Дипломная работа студента 544 группы


Смотрите также:
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 544 группы...
Дипломная работа студента 545 группы...



Загрузка...
скачать
Санкт-Петербургский Государственный Университет

Математико-механический факультет

Кафедра системного программирования


Эффективная реализация расширяемой метамодели CASE-средства на основе UML 2.0

Дипломная работа студента 544 группы

Бакалова Михаила Александровича


Научный руководитель ………………. А.Н. Терехов

д.ф.-м.н., профессор


Рецензент ………………. А.Н. Замышляев

аспирант кафедры системного

программирования СпбГУ


«Допустить к защите» ………………. А.Н. Терехов

заведующий кафедрой,

д.ф.-м.н., профессор


Санкт-Петербург,

2007

Содержание


Научный руководитель ………………. А.Н. Терехов 1

д.ф.-м.н., профессор 1

Рецензент ………………. А.Н. Замышляев 1

аспирант кафедры системного 1

программирования СпбГУ 1

«Допустить к защите» ………………. А.Н. Терехов 1

заведующий кафедрой, 1

д.ф.-м.н., профессор 1

Санкт-Петербург, 1

2007 1

Введение 3

Контекст работы 5

Изначальная задача 5

Новая версия технологии REAL 5

Реализация UML 2.0 6

Переход к новой задаче 7

Общее решение 7

Обзор существующих средств 9

Постановка задачи 12

Реализация CASE-средства 12

Поддержка UML 2.0 в полученном CASE-средстве 12

Предлагаемое решение 13

Описание подхода 13

Архитектура редакторов 16

Расширяемая метамодель 19

Описание графических элементов 21

Процесс реализации UML 2.0 23

Заключение 25

Полученные результаты 25

Список литературы 26

Приложения 28

Приложение 1 28





Введение


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

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

В работе рассматривается эволюция CASE-средсва REAL, разработанного на кафедре системного программирования СПбГУ, в сторону поддержки моделей, ориентированных на предметную область. Рассматриваются различные существующие подходы к реализации подобной функциональности, применяющиеся в таких средствах как, например, Microsoft Visio и Eclipse GMF. Предлагается собственный подход, основанный на рассмотренных существующих решениях, но оптимизированный под задачу быстрого создания 13 редакторов диаграмм UML 2.0 . Подход реализован в прототипе новой технологии REAL-MVC и описан в основной части работы.
^

Контекст работы

Изначальная задача

Новая версия технологии REAL


Изначальной задачей, поставленной перед нашей командой, было создание новой версии CASE-пакета REAL. Необходимо было заново реализовать основную часть системы, сохранив при этом идею существующей методологии. Причиной принятия решения о новой реализации послужило стремление сделать технологию более современной. Во-первых, требовалась поддержка нового стандарта UML 2.0, который значительно отличается от используемого в REAL cинтеза UML и SDL. Во-вторых, было решено добавить новую функциональность и особенности: многопользовательский репозиторий, многоплатформенность, более совершенный интерфейс. Необходима стала также и поддержка новых современных платформ, таких как J2EE, Microsoft.NET, Ruby on Rails.

Изменений требовалось слишком много, и большинство из них были не совместимы со старой реализацией. Таким образом, было принято решение о написании системы заново. К этому времени уже существовали некоторые наработки, которые послужили основой новой системы: новая графово-графическая библиотека, написанная для REAL на C++ студентом Антоном Косякиным в рамках курсовой работы 3го курса.

Архитектура новой системы разрабатывалась с учетом ряда требований, наиболее важными из которых являются: многоплатформенность (поддержка как Microsoft Windows, так и Linux-систем) и слабая связанность отдельных компонент. Ниже приводится схема новой архитектуры, основанной на распространённом шаблоне Model-View-Controller : акцент сделан на разбиении на компоненты и достижении многоплатформенности.



Основные компоненты таковы:

  1. Controller – отвечает за обмен сообщениями между остальными компонентами. Агрегирует все сообщения и доставляет их адресату, таким образом достигается слабая связанность. Controller – не зависит от платформы, его код не меняется при портировании.

  2. Model и Repository – модель. Наборы классов предметной области, представляющие логические сущности на диаграммах: узлы, связи, и.т.п. Сюда также относится и репозиторий – хранилище диаграмм. Эти компоненты тоже не требуется изменять при портировании на другую платформу (операционную систему).

  3. User Interface и View - компоненты пользовательского интерфейса. Они строятся поверх графических абстракий (таких как точка, линия, кнопка, окно) и, поэтому, также являются платформо-независимыми и не требуют изменений при портировании.

  4. Graphical Environment – библиотека классов, реализующих вышеупомянутые графические абстракции. Это – единственная компонента системы, которую необходимо реализовывать заново для каждой платформы. На данный момент существуют 2 её реализации: на основе MFC (Microsoft Foundation Classes, платформа Windows) и на основе Qt (платформы Linux и Windows).
^

Реализация UML 2.0


Реализация UML 2.0 в рамках новой архитектуры была моей основной задачей в этом проекте. Рассмотрим, какое место ей отводилось по изначальной задумке.



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

  1. Логические сущности – элементы диаграмы;

  2. Определённые в стандарте UML 2.0 правила компоновки элементов друг с другом для создания диаграммы;

  3. Определенные в нотации UML 2.0 графические представления логических элементов.

Должно было быть создано по одному редактору на каждый вид диаграммы, определенный стандартом UML 2.0 (всего их 13). Предполагалось, что редактор будет находиться на границе компонент Model и View, для поддержки каждого вида диаграммы необходимо было много программного кода:

  1. Классы элементов диаграмм – по одному на каждый элемент;

  2. Классы, реализующие графическое представление – по одному на каждый элемент;

  3. Классы, реализующие набор логических правил для компоновки элементов – неопределенное количесво (обычно 3 или 4) на каждую диаграмму.

После ручной реализации нескольких редакторов в соответствии с данным подходом, было замечно множество недостатков:

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

  2. Классы логических сущностей похожи друг на друга;

  3. Необходимо много повторяющегося кодирования. Получающийся программный код редакторов трудно модифицировать и сопровождать.
^

Переход к новой задаче

Общее решение


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

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

  2. Во-вторых, реализовав в системе решение более общей задачи, мы автоматически расширяем область её применения за пределы 13 заранее определенных видов диаграмм, которые были бы жестко заданы в случае реализации частного решения. Более гибкая система потенциально имеет большую ценность: поддержка любых видов диаграмм позволяет подстраиваться под предментую область и строить более выразительные модели.

^

Обзор существующих средств


Рассмотрим существующие подходы к решению подобных задач визуального моделирования и наиболее известные технологии, их использующие. Общее название для всех таких подходов – DSM (Domain Specific Modeling )-подходы. Их основная суть заключается в создании и предоставлении визуальных средств (и сопутствующих технологий), ориентированных на конкретные предметные области, их еще называют проблемно-ориентированными визуальными средствами . Были рассмотрены следующие средства:

  1. Microsoft Visio 2003. Visio является простым и удобным средством построения различного вида диаграмм и схем. Среда позволяет создавать новые графические нотации и определять свойства и графическое поведение новых фигур. Для Visio существует библиотека Visio SDK, которая представляет собой API для создания новых программных модулей, расширяющих функциональность Visio. SDK нацелена на платформу Microsoft.NET и является основой используемого в Visio DSM-подхода. Создание новых моделей диаграмм средней сложности (для которых недостаточно простого определения фигур и правил компоновки по умолчанию), таким образом, требует программирования на .NET.

  2. Eclipse Graphical Modeling Framework (GMF) . Основывается на среде Eclipse – написанной на Java кросс-платформенной интегрированной среде разработки ПО. GMF связывает две другие, основанные на Eclipse, технологии: Eclipse Modeling Framework (EMF) и Graphical Editing Framework (GEF).
    GEF представляет собой технологию создания полноценных графических редакторов, включающих возможность задания графических объектов, менеджеры их размещения на диаграмме, окна, диалоги и события пользовательского интерфейса.
    Технология EMF используется для создания сложных моделей различных предметных областей. Модели реализуются посредством генерации классов по схеме, описанной при помощи библиотеки Ecore (библиотека Eclipse для описания метамоделей), или проимпортированной из одного из поддерживаемых форматов (например, XMI ).
    Процесс создания новых типов диаграмм, используемый в Eclipse GMF, состоит в следующем:

    1. Сначала в графическом редакторе GMF Ecore описывается метамодель будущего языка (сущности и правила их компоновки);

    2. Далее разрабатывается описание будущего графического редактора;

    3. После следует описание связей объектов метамодели, полученных на первом шаге, с графическими объектами, полученными на втором шаге;

    4. После этого создаётся описание генератора и генерируется Java-код редактора новых типов диаграмм.

К недостаткам данного подхода можно отнести:

  1. Большое количество промежуточных форматов и описаний, усложняющих использование. Это связано с тем фактом, что технологии GEF и EMF разрабатывались по отдельности, и их интерфейсы плохо совместимы друг с другом;

  2. Генеративную природу подхода и независимость получаемых редакторов друг от друга. Это важно в контексте реализации 13 редакторов UML 2.0, так как ограничивает возможность повторного использования моделей существующих типов диаграмм.
    При изменении некоторого правила, от которого зависят свойства нескольких диаграмм, требуется перекомпилировать все редакторы заново.

  1. Microsoft DSL Tools. Относительно новая разработка компании Microsoft, нацелена на платформу .NET и интегрируется с Microsoft Visual Studio 2005. Подход похож на используемый в Eclipse GMF и состоит в следующем:

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

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

    3. По полученной выше информации генерируется XML-описание графического редактора, по которому генерируется сам редактор.

Microsoft DSL Tools лишены недостатка Eclipse GMF, связанного с большим количеством промежуточных форматов, так как изначально разрабатывались как единая интегрированная среда. Однако, также как и в GMF-подходе, недостатком является генеративность и независимость получаемых редакторов.


^

Постановка задачи

Реализация CASE-средства


Было принято решение разработать собственный подход, который основывался бы на рассмотренных выше, но лучше подходил бы для решения изначальной задачи реализации 13 редакторов диаграмм UML 2.0. Необходимо разработать CASE-средство, реализующее данный подход, которое поддерживало бы быстрое создание графических редакторов различных (заранее неизвестных) видов диаграмм. Основные требования к новой реализации, ставшие постановкой моей задачи, были выделены следующие:

  1. Нужно, по возможности, избежать необходимости создавать каждый новый редактор вручную, программируя на C++. Пользователь должен иметь возможность самостоятельно, без программирования, определять новые виды диаграмм.

  2. Процесс задания нового вида диаграммы должен быть максимально простым и быстрым для пользователя. Не должно быть необходимости в:

    1. Перекомпиляции всего CASE-средства или его частей;

    2. Изучении сложных нотаций и языков;

    3. Использовании дополнительных сторонних технологий и утилит.

  3. Необходима возможность повторного использования созданных типов диаграмм: для описания нового типа диаграммы часто необходимо переиспользовать элементы, определенные в других типах.

  4. Архитектура приложения должна быть достаточно гибкой, для того, чтобы ручное создание редактора было максимально простым. Это необходимо, так как есть опасность сделать общий подход (предыдущий пункт) слишком громоздким, неудобным для пользователя и очень сложным в реализации. Итак, чтобы избежать перегрузки общего решения деталями, необходима возможность ручного программирования частных случаев.
^

Поддержка UML 2.0 в полученном CASE-средстве


Второй частью поставленной в работе задачи является реализация изначального требования: поддержка в CASE-средстве 13 видов диаграмм UML 2.0. Редакторы для этих 13 диаграмм необходимо, по возможности, реализовать на основе разработанного общего подхода.
^

Предлагаемое решение

Описание подхода


В соответствии с поставленной задачей ([Постановка задачи]) был разработан подход, который будет детально описан в последующих главах. Подход основывается на идее метамоделирования (подробнее метамоделирование описано в и ).

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



  • - элементы мета-метамодели;

  • - элементы метамодели;

  • - элементы модели;

В самом низу расположены элементы пользовательских моделей: конкретные сущности на конкретных диаграммах. В примере это диаграмма классов (на ней всего 1 класс, чтобы не перегружать рисунок) и диаграмма случаев использования. Самый нижний уровень называют моделью.

Чтобы описать некоторый тип модели (например, “диаграмма классов”, “диаграмма случаев использования”) необходимо определить сущности, допустимые на диаграмме и правила компоновки этих сущностей (внешний вид элементов диаграммы будет рассмотрен позднее). Необходим способ описания таких сущностей и правил. Таким способом является построение специальных моделей. На рисунке элементы этой модели-описания выделены синим цветом. Модель-описание в примере определяет такие сущности как “Класс” (Class), принадлежащий описанию диаграммы классов, и “Актёр” (Actor), “Случай Использования” (Use Case), “Использование” (Usage, связь актёра и случая использования), принадлежащие описанию диаграммы случаев использования. В описании также присутствуют сущности, определяющие общие характеристики для остальных. Такие модели-описания называют метамоделями, т.к. они являются “языком”, который используется для задания моделей. Каждый элемент модели является экземпляром некого класса – сущности метамодели.

Для того чтобы описывать метамодели, также, в свою очередь, необходим специальный язык. Его элементы (единственный элемент) обозначены на рисунке зелёным цветом. По аналогии с переходом от нижнего уровня к среднему, верхний уровень является моделью-описанием метамодели и называется мета-метамоделью. На практике оказывается, что больше уровней не требуется, описание язык описания мета-метамодели обычно совпадает с самой мета-метамоделью. Подробнее об этом написано в , а про различные приложения понятия метамоделирования – в .

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

В работе использован подход, применяющийся самими авторами UML 2.0 (, ): язык описания модели является языком визуального моделирования. Разбиение на слои (аналогичное приведённому выше в примере), используемое авторами UML 2.0 таково: модели – конкретные диаграммы, описываются на визуальном языке UML (являющимся метамоделью), который описан на визуальном языке MOF (Meta Object Facility, являющимся мета-метамоделью). Более детально подход состоит в следующем:

  1. Вручную на C++ реализуется небольшое подмножество MOF, которого достаточно, чтобы описывать большинство метамоделей;

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

  3. Созданные пользователем метамодели сохраняются в репозиторий (реализация репозитория подробно рассмотрена в дипломной работе Косякина Антона). После этого, на их основе пользователь может создавать собственные модели: графический редактор пользовательских диаграмм интерпретирует метаинформацию из репозитория.
^

Архитектура редакторов


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

Одной из поставленных в работе задач была разработка достаточно гибкой архитектуры приложения, которая позволяла бы быстрое создание графических редакторов вручную на C++. Изначальная идея “чистого” Model-View-Controller претерпела изменения, на диаграмме изображены основные компоненты, составляющие каркас новой реализации.



  • - элементы каркаса, не изменяются при добавлении новых редакторов;

  • - элементы, которые при добавлении новых редакторов необходимо реализовать вручную.

Архитектура приложения в целом является трехуровневой, но при этом специально выделяется граница уровней бизнес-логики и хранения данных . Введение компонент, отвечающих за отображение между репозиторием и объектами C++, часто применяется при моделировании в приложении сложной предметной области. Такое разделение позволяет независимо изменять основные классы каркаса и репозиторий. В процессе реализации CASE-средства это позволило заменить многопользовательский удалённый репозиторий на простой локальный для облегчения отладки и сильно ускорило разработку каркаса.

Рассмотрим наиболее важные с точки зрения реализации редакторов диаграмм компоненты и их назначение.

  1. UI – набор компонент пользовательского интерфейса: окон, кнопок, диалогов. Несмотря на то, что набора реализованных компонент должно быть достаточно для функциональности большинства редакторов, имеется возможность расширять этот набор (UI Extensions).

  2. DomainObject – базовый класс для всех объектов предметной области [link]. Определяет основную функциональность: возможность быть сохранённым в репозиторий, возможность быть добавленным на диаграмму.
    По мере добавления пользователем новых классов предментой области (таких, как например класса MetaClass на рисунке, необходимого для реализации редактора метамоделей) получается некоторая иерархия C++ классов. Для поддержки разнообразных операций над объектами классов этой иерархии (таких как, например, отображение свойств в различных диалогах пользовательского интерфейса) существует параллельная иерархия классов Visitor. Классы Visitor (на рисунке они не обозначены) реализуют шаблон проектирования Visitor , и позволяют добавлять новые операции без изменения иерархии. Это, в частности, позволяет реализовать UI Extensions , упомянутые в предыдущем пункте.

  3. BaseEditor – базовый класс для всех редакторов диаграмм. Определяет основную функциональность по отрисовке и управлению любыми диаграммами. Взаимодействует с репозиторием, используя компоненты для отображения (Mapper-ы).
    Новые графические редакторы (MetaEditor) манипулируют конкретными элементами диаграмм.

  4. ElementMapper – базовый абстрактный класс для компонент, ответственных за синхронихацию объектов предметной области и репозитория. Определяет методы для чтения и записи элементов.
    Новые элементы на диграммах сохраняются и достаются из репозитория с помощю конкретных классов Mapper-ов (MetaClassMapper).

  5. Repository – определяет API для взаимодействия с репозиторием. Реализует протоколы передачи данных для разных типов репозиториев (удаленный сервер и локальные файлы).

  6. ElementCommand – базовый класс шаблона проектирования Command . Является одним из способов реализации обратных вызовов: команды ассоциируются с событиями пользовательского интерфейса, настраиваются объектом графического редактора и вызывают его методы при появлении события. Команды также хранят состояние и предоставляют основу для реализации функциональности UNDO.
    При реализации нового редактора обычно создаются новые команды (MetaClassCommand), которые вызывают его конкретные методы и имеют своё специальное состояние.

  7. DiagramType – описывает понятие “тип диаграммы”, о котором будет подробнее сказано в следующей главе. Тип диаграммы определяет набор допустипых на диаграмме элементов.

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

На основе реализованного каркаса были вручную созданы 2 графических редактора диаграмм: редактор метамоделей и редактор-интерпретатор метаинформации. Редактор метамоделей подробнее описан в следующей главе.
^

Расширяемая метамодель


В данной главе рассматривается один из двух, реализованных вручную на C++, редакторов диаграмм нового CASE-средства. Редактор метамоделей служит основой для функциональности, дающей пользователям возможность создавать собственные редакторы диаграмм. Редактор предоставляет пользователю визуальный язык, являющийся подмоножеством MOF, на котором описываются метамодели. Язык определяет несколько основных сущностей (в скобках указаны соответствующие C++-классы):

  1. Классы (MetaClass). Диаграммы метамоделей состоят из классов и отношений между ними. Каждый класс на такой диаграмме задаёт тип элементов пользовательских моделей. Например, класс Actor на диагрмме метамодели определяет множество всех конкретных актёров, которые могут присутствовать на диаграммах случаев использования.

  2. Атрибуты (MetaClassAttribute). Классы на диаграмме метамоделей имеют атрибуты, описывающие их структурные свойства. Например, если класс Actor имеет свойство name типа String, а класс UseCase имеет свойство description также типа String, то это означает что на любой пользовательской диаграмме случаев использования у каждого актёра должно быть имя, а у каждого случая использования – строковое описание.

  3. Ассоциации (Association). Классы на диаграммах метамоделей могут быть связаны ассоциациями. Ассоциации являются удобным для пользователя способом задания отношений наследования между классами. Все остальные структурные свойства описываются только атрибутами.

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

Следующим шагом для пользователя после описания метамодели в виде диаграммы классов является определение нового типа диаграммы модели. Тип диаграммы модели включает в себя:

  1. Список классов. Это элементы метамодели – типы элементов, допустимых на будущей диаграмме;

  2. Внешний вид каждого из классов списка. Подробнее об описании внешнего вида – в следующей главе.

  3. Графический способ изображения связи для каждой пары элементов, которые могут быть связаны на диаграмме модели. Пары определяются на основе информации, полученной из метамодели. После анализа нотации диаграмм UML 2.0 были выявлены 3 используемых в нотации типа графических связей:

    1. Линии разного типа. Например, стрелка наследования на диаграмме классов.

    2. Связь типа “контейнер”, когда один элемент расположен визуально внутри другого. Например, методы располагаются внутри прямоугольника класса на диаграмме классов.

    3. Связь типа “stick”, когда один из элементов визуально “приклеевается” к другому. Например, прямоугольники активаций на линиях жизни объектов диаграммы последовательностей.

Редактор метамоделей предоставляет пользователю интерфес для определения новых типов диаграмм моделей. Описание предлагаемого способа задания внешнего вида элементов дано в следующей главе.
^

Описание графических элементов


Последним штрихом к определению пользователем нового типа диаграммы, после того как метамодель уже создана, является описание внешнего вида (фигур) элементов на новой диаграмме. Новое CASE-средство предлагает пользователю специально разработанный в рамках данной работы формат, основанный на стандарте W3C SVG (Scalable Vector Graphics, XML – представление векотрной графики). Описания фигур создаются пользователем в современном графическом редакторе (большинство из них поддерживают сохранение рисунков в формате SVG), после чего доводятся вручную в текстовом редакторе для задания связей с моделью и сохраняются в репозитории. В процессе отрисовки текст такого расширенного SVG-формата интерпретируется встроенным в CASE-средство модулем, также реализованным в рамках данной работы. На рисунке приведен простейший пример работы модуля-интерпретатора:



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

  1. Ссылки на значения свойств объектов модели во время исполнения. Например, у класса актёра Actor есть свойство name, для конкретного актёра на конкретной диаграмме задано конкретное значение этого свойства. Синтаксис формата $name$ позволяет ссылаться на это значение во время исполнения;

  2. Условные операторы. Необходимы, например, если нужно по-разному визуально отобразить public и private метод класса на диаграмме. Каждый из вариантов внешнего вида сохраняется в файле фигуры, выбор нужного варианта происходит во время исполнения;

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

Полное описание использованного формата приведено в виде XML-схемы в [Приложение 1]


^

Процесс реализации UML 2.0


Изначальной задачей, поставленной при реализации CASE-средства, была поддержка в нём стандарта UML 2.0. Одной же из задач данной работы стало применение вышеописанного общего подхода для достижения поставленной цели по реализации стандарта.

Реализованный общий подход позволил получить прототип CASE-средства, предоставляющий необходимый инструментарий для решения задачи построения 13-ти редакторов диаграмм UML 2.0. При построении редакторов был использован процесс, проиллюстрированный на диаграмме:



  • - на этом шаге выполняется кодирование на C++.

  • - на этих шагах используется разработанная технология: визуальное задание метамоделей или описание фигур в расширенном SVG-формате.

  • - это различные состояния реализации CASE-средства.

Процесс состоял в следующем:

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

  2. После этого, применяя визуальное моделирование, на реализованном языке было описано ядро метамодели UML 2.0, приведённое в спецификации языка UML. На основе этого ядра стало можно строить метамодели диаграмм UML 2.0.

  3. С применением визуального моделирования в редакторе метамоделей были описаны упрощенные метамодели диаграмм UML 2.0.

  4. После этого в редакторе метамоделей были определены типы диаграмм, определенные в UML, а также были созданы файлы фигур в специальном формате.

  5. После каждой итерации шагов 3 и 4 в CASE-средство добавлялась возможность создавать UML 2.0 на новых типах диаграмм.

Предложенный процесс может быть легко продолжен: у пользователя есть возможность создавать новые типы диаграмм, если это необходимо для построения более выразительных (чем стандартные UML 2.0) моделей специфической предметной области.
^

Заключение

Полученные результаты


Ниже перечислены основные результаты, полученные в процессе работы:

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

  2. На основе разработанного прототипа в создаваемом CASE-средстве реализованы редакторы диаграмм, определенных в стандарте UML 2.0.
^




Список литературы


    1. OMG. UML 2.0 Infrastructure Specification http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

    2. OMG. MOF 2.0 Specification http://www.omg.org/technology/documents/modeling_spec_catalog.htm#MOF

    3. OMG. XMI 2.0 Specification http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI

    4. Ф. Брукс. Мифический человеко-месяц или как создаются программные системы. СПб Символ, 2000.

    5. Д.В. Кознов. Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособие. — Спб. Изд-во СПбГУ, 2004. — 143 с.

    6. Э.Гамма, З.Хельм, Р.Джонсон, Дж.Влиссидес. Приемы объектно-ориентированного проектирования: паттерны проектирования. /Пер. с англ. — СПб. Изд-во Питер, 2004. — 366 с.

    7. Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional; 1st edition (November 5, 2002) — 560 p.

    8. Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional; 1st edition (June 28, 1999) — 464 p.

    9. Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional; 3 edition (September 19, 2003) — 192 p.

    10. Martin Fowler. GUI Architectures. http://www.martinfowler.com/eaaDev/uiArchs.html

    11. John M. Vlissides. Pattern Hatching: Design Patterns Applied (Software Patterns Series). Addison-Wesley Professional; 1st edition (June 22, 1998) — 172 p.

    12. Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern. http://martinfowler.com/articles/injection.html

    13. http://www.w3.org/Graphics/SVG/

    14. http://www.w3.org/XML/

    15. http://www.w3.org/XML/Schema

    16. http://www.eclipse.org/gmf/

    17. Павлинов А. , Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов А. О средствах разработки проблемно-ориентированных визуальных языков. — 24 с.


^

Приложения

Приложение 1


XML-схема формата описания фигур.



<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:complexType name="real:collectionType">

<xs:attribute name="x" type="xs:boolean" use="required"/>

<xs:attribute name="y" type="xs:byte" use="required"/>

<xs:attribute name="name" type="xs:string" use="required"/>

<xs:attribute name="template" type="xs:string" use="required"/>

xs:complexType>

<xs:complexType name="rectType">

<xs:attribute name="x" type="xs:short" use="required"/>

<xs:attribute name="y" type="xs:short" use="required"/>

<xs:attribute name="width" type="xs:short" use="required"/>

<xs:attribute name="height" type="xs:short" use="required"/>

<xs:attribute name="stroke-width" type="xs:byte" use="required"/>

<xs:attribute name="fill" type="xs:string"/>

xs:complexType>

<xs:complexType name="ellipseType">

<xs:attribute name="cx" type="xs:byte" use="required"/>

<xs:attribute name="cy" type="xs:byte" use="required"/>

<xs:attribute name="rx" type="xs:byte" use="required"/>

<xs:attribute name="ry" type="xs:byte" use="required"/>

<xs:attribute name="fill" type="xs:string" use="required"/>

xs:complexType>

<xs:complexType name="circleType">

<xs:attribute name="cx" type="xs:byte" use="required"/>

<xs:attribute name="cy" type="xs:byte" use="required"/>

<xs:attribute name="r" type="xs:byte" use="required"/>

<xs:attribute name="stroke" type="xs:string" use="required"/>

<xs:attribute name="stroke-width" type="xs:byte" use="required"/>

<xs:attribute name="fill" type="xs:string" use="required"/>

xs:complexType>

<xs:complexType name="lineType">

<xs:attribute name="x1" type="xs:byte" use="required"/>

<xs:attribute name="y1" type="xs:byte" use="required"/>

<xs:attribute name="x2" type="xs:byte" use="required"/>

<xs:attribute name="y2" type="xs:byte" use="required"/>

<xs:attribute name="stroke-width" type="xs:byte" use="required"/>

xs:complexType>

<xs:complexType name="real:testType">

<xs:sequence>

<xs:element name="real:when" type="real:whenType" minOccurs="1" maxOccurs="unbounded"/>

xs:sequence>

<xs:attribute name="var" type="xs:string" use="required"/>

xs:complexType>

<xs:complexType name="real:whenType">

<xs:sequence>

<xs:element name="svg" type="svgType"/>

xs:sequence>

<xs:attribute name="value" type="xs:string" use="required"/>

xs:complexType>

<xs:complexType name="svgType">

<xs:choice minOccurs="1" maxOccurs="unbounded">

<xs:element name="svg" type="svgType"/>

<xs:element name="rect" type="rectType"/>

<xs:element name="text" type="textType"/>

<xs:element name="real:collection" type="real:collectionType"/>

<xs:element name="ellipse" type="ellipseType"/>

<xs:element name="line" type="lineType"/>

<xs:element name="real:test" type="real:testType"/>

xs:choice>

<xs:attribute name="width" type="xs:short"/>

<xs:attribute name="height" type="xs:short"/>

<xs:attribute name="id" type="xs:string"/>

xs:complexType>

<xs:complexType name="textType">

<xs:simpleContent>

<xs:extension base="xs:string">

<xs:attribute name="x" type="xs:short" use="required"/>

<xs:attribute name="y" type="xs:short" use="required"/>

<xs:attribute name="font-size" type="xs:byte" use="required"/>

<xs:attribute name="fill" type="xs:string" use="required"/>

xs:extension>

xs:simpleContent>

xs:complexType>

xs:schema>








Скачать 367,75 Kb.
оставить комментарий
Дата05.11.2011
Размер367,75 Kb.
ТипДиплом, Образовательные материалы
Добавить документ в свой блог или на сайт

Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх