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

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

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

        строковый тип

        числовой тип

        тип перечисления. Список элементов перечисления задается в метамодели и на момент запуска приложения хранится в метаплагине.

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

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

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

Система сообщений пользователю

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

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

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

        контейнеры. Задает список элементов, которые могут быть добавлены в данный элемент, как в контейнер.

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

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

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

Итоги

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

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

Общие итоги

Несмотря на то, что задача интерпретирования метамоделей и задача динамической смена типа элемента были рассмотрены по отдельности, интересен именно общий полученный результат. В результате проведенного обзора существующих решений был сделан вывод, что представленные на данный момент CASE-средства и metaCASE-средства недостаточно динамичны. Из рассмотренных средств наиболее удобным в использовании с точки зрения внесения изменений в метамодель в момент работы приложения является MetaEdit+.

Благодаря использованию концепции интерпретируемых метамоделей MetaEdit+ предоставляет возможность “метамоделирования на лету”. Изменения, внесенные в метамодель, автоматически отображаются в модели. Однако уровни абстракции модели и метамодели по-прежнему разделяются. С точки зрения пользовательского интерфейса, это означает, что для внесения изменений в метамодель необходимо использовать отдельный редактор. В случае MetaEdit+ редактор для метамодели с точки зрения пользовательского интерфейса аналогичен редактору моделей, но даже несмотря на это разделение модели и метамодели заставляет пользователя мыслить одновременно в терминах двух уровней абстракции. Это требует от пользователя больших затрат энергии и времени, а также создает дополнительные сложности для использования средства непрофессионалами. Необходимо понимать, что понятие метамодели является сложным и неочевидным для неподготовленного человека, в связи с этим может потребоваться определенное время для изучения тонкостей и различий при работе с метамоделью и моделью.

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

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

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

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

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

        пользователь изначально не имеет полной информации о разрабатываемой системе

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

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

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

Для апробации подхода была использована реальная задача, возникшая в рамках проекта «3vi» компании «Ланит-Терком». 3vi –это коммерческий проект по созданию системы стереозрения и ее приложения к различным задачам. Одной из таких задач является управление различной бытовой техникой с помощью жестов руками. Система должна уметь определять положение центра руки, а также задавать траекторию движения руки, которая распознавалась бы как отдельная команда.

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

       Прямого движения

       Обратного движения

       Движения, отвечающего за приведение системы в активное состояние (пользователь должен указать рукой в сторону камеры)

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

       Состояние ожидания начала жеста

       Состояние ожидания обратного движения руки

       Состояние, в котором находилась state-машина во время прямого движения руки

       Состояние, в котором находилась state-машина во время обратного движения руки

Первый вариант машины состояний выглядел следующим образом:

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

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

Мы решили попробовать применить новый подход к решению данной задачи, так как она хорошо подходит под описание задач, которые удобно решать с помощью метамоделирования «на лету».

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

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

Работа над задачей начинается с создания пустого редактора. При загрузке приложения в списке доступных плагинов необходимо выбрать «New editor». В данном случае, будет создан и загружен метаплагин, в котором нет никакой информации. Для последующего сохранения создается XML файл метамодели. Палитра элементов и редактор свойств не содержат никаких элементов.

Разработчики в данный момент представляют, что им потребуются следующие элементы:

       Начальное состояние

       Состояние ожидания движения

       Переход между состояниями

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

Добавим новый элемент «Начальное состояние» на палитру элементов. Для этого кликнем правой кнопкой мыши на панели инструментов и в появившемся контекстном меню выберем пункт «Add new element» (рис.1). Пользователю будет предложен диалог, в котором ему предстоит заполнить будущее имя и, при желании, описание элемента (рис. 2). Новый элемент будет добавлен в палитру. Он будет иметь заданное имя и определенную по умолчанию форму квадрата.

Изменим графическое представление добавленного элемента. Для этого в контекстном меню палитры элементов выберем пункт «Change shape». Будет открыт дизайнер формы элемента (рис. 3). У пользователя есть возможность как загрузить существующий рисунок, сохраненный в любом графическом формате, поддерживаемом Qt, так и создать собственный с помощью имеющегося инструментария. При завершении редактирования необходимо нажать кнопку «save» для сохранения полученного результата. Внешний вид элемента будет изменен автоматически.