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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование метаредактора и нового подхода

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

       Добавление нового элемента

       Создание копии существующего

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

       Задание свойств

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

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

Итоги

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

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

Понятие типа элемента в QReal

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

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

        идентификатор (сгенерированный уникальный идентификатор GUID)

        имя редактора, которому принадлежит элемент

        имя типа диаграммы, которой принадлежит элемент

        имя типа элемента

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

              Тип элемента используется на всех этапах работы системы:

        При запуске приложения создаются типы для всех элементов модели

        При добавлении элемента на сцену создается элемент и его графическое представление с конкретным типом

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

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

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

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

Разделение идентификатора элемента

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

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

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

Автоматическое обновление свойств элемента с измененным типом

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