Создание режима быстрого прототипирования в 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 и пройти описанные шесть стадий разработки редактора. В случае если количество желаемых изменений невелико, это будет неоправданно трудоемко.