Создание режима быстрого прототипирования в CASE-системе QReal

­­­­САНКТ – ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

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

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

Создание режима быстрого прототипирования

в CASE-системе QReal

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

Такун Евгении Игоревны

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

2011

SAINT PETERSBURG STATE UNIVERSITY

Mathematics and Mechanics Faculty

Software Engineering Department

IMPLEMENTATION OF RAPID PROTOTYPING MODE

IN QREAL CASE-SYSTEM

A graduate work by
Takun Evgenia

545 group

Saint Petersburg

   2011

Оглавление

Введение

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

Обзор подходов и существующих реализаций

Концепция предметно-ориентированного моделирования

Обзор существующих решений

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

Создание интерпретируемых метамоделей

Динамическая смена типа элемента.

Апробация подхода

Описание реальной задачи

Решение задачи с помощью метамоделирования «на лету»

Заключение

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

Введение

В настоящее время активное развитие программной инженерии усиливает интерес к средствам, позволяющим сделать процесс разработки более простым и комфортным.  Широкое распространение получили CASE-средства.  Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств, покрывающих весь жизненный цикл ПО. Одними из наиболее трудоемких этапов разработки ИС являются анализ и проектирование. При этом большую роль играют методы визуального представления информации. Использование различных видов диаграмм и сущностей позволяет пользователям наглядно и подробно описать необходимые модули  и поведение будущей системы[1]. Среди наиболее известных CASE-средств следует отметить Rational Rose, Altova Model, Visio 2007, Enterprise Architect, Visual paradigm.

Развитие CASE-средств привело к созданию концепции MetaCASE-средств.  Понятие “MetaCASE-средство” появилось в 1991 году в статье Альберта Алдерсона[9]. MetaCASE-средства позволяют автоматически генерировать код произвольных визуальных редакторов по описаниям их метамоделей.  Из-за большей динамичности и гибкости они выглядят более перспективными.  Предполагается, что процесс создания редактора требует усилий очень небольшого количества квалифицированных специалистов, а программирование на полученном предметно-ориентированном языке  не требует от пользователя ни знаний, ни опыта работы сверх того, что ему нужно для решения задач в предметной области. Это позволяет использовать MetaCASE-средства для создания предметно-ориентированных языков, которые могут быть использованы для решения конкретных специфических задач.

Из наиболее известных metaCASE-средств следует отметить MetaEdit+, Eclipse GMF[3], MS DSL Tools[2].

На кафедре системного программирования математико-механического факультета СПбГУ уже несколько лет ведется разработка MetaCASE-средства QReal. Особенностью этой системы является возможность с помощью метамоделирования быстро и удобно реализовывать предметно-ориентированные языки. QReal  в конечном итоге должен представлять собой интегрированную среду разработки, реализующую принципиально новый подход к созданию сложных систем, с низким порогом вхождения для новичков и многократным увеличением производительности профессионалов. Проект является некоммерческим, и, по сути, стал площадкой для экспериментов. В связи с отсутствием ограничений по времени и каких-либо требований со стороны заказчика мы имеем возможность разрабатывать систему в соответствии с нашим видением ситуации, внедрять функциональность, за счет которой QReal будет интересен конечным пользователям и будет выгодно выделяться на фоне существующих MetaCASE-средств.

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

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

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

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

За счет того, что QReal [M1] является MetaCASE-средством, мы имеем возможность решить подобные задачи, реализовав “метамоделирование на лету”, то есть, сделав так, чтобы процесс метамоделирования осуществлялся прямо в процессе разработки модели, и изменение метамодели тут же отображалось в модели.

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

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

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

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

Обзор подходов и существующих реализаций

Концепция предметно-ориентированного моделирования

Предметно-ориентированное моделирование (domain-specific modeling DSM)[3] основано на том, что иногда создание специализированного языка для конкретной предметной области и решение задачи с помощью него может быть быстрее, чем решение той же задачи стандартными существующими языками общего назначения. Идея заключается в том, что языки общего назначения ничего не знают про предметную область, поэтому часто решение достаточно примитивных и типовых с точки зрения предметной области задач усложняется за счет неприспособленности выбранного инструмента[5]. В связи с этим сложно радикально повысить производительность разработчиков[6]. DSM предполагает, что все компоненты (редактор, генератор) ориентированы на конкретную предметную область. Это позволяет перенести разработку с уровня программных конструкций на уровень терминов предметной области. Переход на DSM от визуальных языков общего назначения аналогичен переходу от ассемблерных языков к структурному программированию. Как в свое время отказ от редактирования ассемблерных кодов привел к огромному скачку в продуктивности, так и теперь использование DSM средств вместо визуальных языков общего назначения на некоторых задачах дает по разным оценкам от 300 до 1000% прироста производительности.

Для того чтобы создать новый предметно-ориентированный язык, необходимо определить для него абстрактный и конкретный синтаксис. Абстрактный синтаксис (какие существуют элементы, какие у них свойства, как взаимодействуют между собой) чаще всего определяется в метамодели[10]. Конкретный синтаксис (определяет, как элементы языка будут отображаться для пользователя) обычно задается в специальных графических редакторах. Рассмотрим наиболее распространенные на данный момент DSM-средства с точки зрения возможности и удобства внесения изменений в метамодель[8].

Обзор существующих решений

Eclipse GMF

Среда Eclipse – это кросс-платформенная интегрированная среда разработки программного обеспечения с открытыми исходными кодами. На базе Eclipse создаются различные дополнительные технологии, одна из которых – Eclipse Graphical Modeling Framework (GMF), первая версия которой появилась в середине 2006 года и с тех пор активно дорабатывалась.

Технология GMF предназначена для быстрой разработки предметно-ориентированных визуальных языков. GMF интегрирует две широко известные библиотеки – Eclipse Modeling Framework (EMF) и Graphical Editing Framework (GEF). EMF используется для создания моделей, а GEF – для создания уровня представлений.

Рассмотрим, как происходит создание предметно-ориентированного визуального языка, с точки зрения пользователя:

1.       Разработка доменной модели заданной предметной области. Эта модель является метамоделью будущего DSM-редактора. Разработка происходит с помощью графического редактора GMF Core

2.       Описание графической нотации создаваемого языка

3.       Разработка модели инструментов. Описываются элементы панели будущего редактора (палитры графических объектов, меню, и т.д.)

4.       Разработка модели соответствия. Определяются связи между элементами доменной модели и их графическими представлениями и инструментами.

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

6.       Генерация кода DSM-редактора.

Можно сделать вывод, что создание нового DSM-редактора удобно для пользователя. Но в случае, если пользователь захочет изменить созданный редактор (добавить новые сущности, изменить графическое представление существующих, добавить новые свойства), ему придется снова загрузить метамодель в GMF Core и пройти описанные шесть стадий разработки редактора. В случае если количество желаемых изменений невелико, это будет неоправданно трудоемко.

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

MS DSL Tools

Пакет DSL Tools входит в состав Visual Studio SDK. Он устанавливается в виде надстройки к Visual Studio и используется исключительно как составная часть этой среды разработки. При создании solution автоматически создаются два проекта - Dsl и DslPackage. Dsl предназначен для хранения информации о метамодели, а DslPackage - для хранения настроек пользовательского интерфейса создаваемого редактора.

Рассмотрим, как происходит создание предметно-ориентированного визуального языка с точки зрения пользователя:

1.       Создание метамодели нового предметно-ориентированного языка.

o         Разработка концептуальной метамодели с помощью диаграмм классов UML. На этом этапе определяются основные концепции нового языка. Для создания диаграммы классов можно использовать любой UML-инструмент. Теоретически, DSL Tools предоставляет возможность создавать с его помощью диаграммы классов, но графический редактор DSL Tools не сильно удобен для использования и имеет ряд недостатков. Так, к примеру, все связи обозначаются специальными классами, что резко увеличивает объем спецификации.

o         Перенос концептуальной модели в DSL Tools. Пользователь получает метамодель будущего редактора, выполненную в DSL Tools.

2.       Разработка редактора

o         Дополнение созданной на предыдущем этапе метамодели необходимыми свойствами, определяющими наш будущий редактор. Задаются настройки пользовательского интерфейса. С помощью вставок на C# можно определить дополнительные свойства редактора тогда, когда не хватает стандартных средств DSL Tools.

o         Задание собственных правил валидации новых визуальных моделей.

o         Создание генерационного модуля, который будет выполнять генерацию по моделям в созданном редакторе.

3.       Валидация и генерация

o         Валидация. Проверяется согласованность и корректность элементов метамодели и их атрибутов.

o         Генерация кода целевого редактора. Код генерируется в тексты на языке C#. После компиляции этого кода средствами Visual Studio пользователь получает готовый редактор.

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

MetaEdit+

MetaEdit+ разрабатывался в рамках научно-исследовательских проектов Syti и MetaPHOR в University of Jyväskylä в период с 1988 по 1995 год. Коммерческая версия программы доступна с 1993 года[11][12].

Благодаря использованию подхода, основанного на интерпретации метамоделей, а не на генерации, технология MetaEdit+ позволяет вносить изменения в метамодель во время работы системы.

Процесс создания нового редактора выглядит так:

1.       Определение концепций предметной области.

2.       Создание соответствующих графических представлений (с помощью встроенного графического редактора), задание свойств.

3.       Задание связей между элементами.

4.       Генерация DSL-редактора.

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

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

1.       Платформа MetaEdit+ использует свой собственный формат файлов (MXT) для экспорта моделей.

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

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

MetaLanguage

В 2008 году в межвузовском сборнике научных статей “Математика программных систем” была опубликована статья Л.Н.Лядовой и А.О.Сухова “Языковой инструментарий системы MetaLanguage”. В статье был подробно описан визуальный метаязык и его составляющие[4][7].

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

1.       Создание/модификация метамодели

o         Задание конструкций языка

o         Задание соотношений между конструкциями языка

o         Задание ограничений на элементы метамодели

2.       Создание/модификация модели

o         Создание сущностей предметной области

o         Создание отношений между сущностями

3.       Валидация

o         Проверка ограничений, налагаемых на сущности

o         Проверка ограничений, налагаемых на отношения

4.       Генерация

o         Сохранение модели в формате XML

o         Генерация документации

Авторы статьи утверждают, что платформа MetaLanguage так же, как и MetaEdit+, позволяет динамически обновлять модель после внесения изменений в метамодель. К сожалению, в открытом доступе средство MetaLanguage отсутствует, поэтому оценить на практике его достоинства и недостатки не представилось возможным. Однако эта статья является ценной и заслуживающей внимания, так как она свидетельствует о том, что исследовании в данном направлении велись, и эта тема вызывала интерес.

Встроенный метаредактор в QReal

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

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

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

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

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

Создание интерпретируемых метамоделей

Генерация моделей в QReal

Как и в большинстве современных MetaCASE-средств, метамодель в QReal хранится в текстовом виде в формате XML. В метамодели содержится полная информация о будущей модели:

        набор свойств элемента

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

        свойства отображения элемента

        соотношения между элементами

        свойства, необходимые для валидации моделей

Пользователь имеет возможность изменять метамодель либо путем внесения изменений в соответствующий xml файл метамодели, либо используя реализованный в QReal метаредактор. Метаредактор позволяет загрузить существующую метамодель, внести необходимые изменения (есть возможность изменить все имеющиеся в xml свойства) и сохранить полученную метамодель в формате xml.

Для задания графического представления элемента можно использовать любое средство, позволяющее работать с векторной графикой и, как следствие, способное сохранять рисунок в формате SVG (к примеру, Corel Draw). Также можно воспользоваться встроенным в QReal редактором фигур. Редактор позволяет как загружать имеющиеся рисунки в формате SVG (XML), так и создавать новые. Пользовательский интерфейс редактора интуитивно понятен и схож с пользовательским интерфейсом приложения Paint. Готовый рисунок можно сохранить в формате SDF и использовать при редактировании метамодели.

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

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

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

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

        редактор свойств элемента представляет собой список свойств выбранного на сцене элемента. Свойства могут быть доступными для редактирования (имя элемента, комментарий, и.т.д.) и неизменяемыми (графический и логический идентификатор, тип)

Информация о графическом представлении элементов используется для рисования иконок и отображения элементов на сцене.

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

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

Интерпретируемые метамодели

Основное отличие концепции интерпретируемых метамоделей от концепции генерируемых метамоделей заключается в том, что интерпретация моделей происходит непосредственно во время работы приложения, в то время как генерация обязана завершиться до начала работы. В результате анализа архитектуры QReal было выяснено, что существующую систему плагинов можно использовать и для интерпретации метамоделей. Новый “метаплагин” должен полностью повторять реализацию генерирующихся плагинов, только информация должна получаться не во время компиляции, а при загрузке приложения. С точки зрения пользователя это выглядит так: после загрузки приложения, пользователь получает возможность загрузить определенную метамодель в режиме быстрого прототипирования. Пользователь выбирает xml файл метамодели, в этот момент происходит разбор файла метамодели, и вся информация из него загружается в  соответствующий метаплагин. Графическое представление элементов также генерируется во время разбора файла метамодели. Далее этот метаплагин используется так, как использовались сгенерированные плагины в стандартном режиме работы.

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