Диссертация (1148272), страница 22
Текст из файла (страница 22)
Порт может иметь тип, один из заранее определённых вметамодели, для связи может быть указано, к портам какого типа её разрешеноподключать.Имеется возможность задать отображение статического текста и динамического текста. Динамический текст — поле на фигуре, текст для которого берётсяиз свойства фигуры в репозитории. В редакторе формы фигур указывается имясвойства, откуда надо брать значение. В процессе рисования диаграммы насозданном языке подставляется реальное текущее значение свойства, кроме того,значение свойства можно редактировать прямо на сцене. Статический текст — этонередактируемая надпись на элементе, указываемая при задании формы элемента.Для каждого элемента изображения можно определить условие, при которомон будет отображаться. Условие задаётся в виде логического выражения, вкотором можно использовать значения свойств элемента.Результат создания формы фигуры может быть сохранён в виде XML-строкикак свойство элемента Node в метамодели либо как отдельный XML-файл,который можно переиспользовать при создании других фигур.4.3.3.
Редактор ограниченийОграничения необходимы для того, чтобы, во-первых, минимизировать вероятность ошибок при разработке системы, во-вторых, чтобы иметь возможностьобнаружить ошибку как можно раньше. Наличие средств задания ограниченийпозволяет существенно повысить удобство пользования визуальной технологиейи повысить качество программ, создаваемых с её помощью, поэтому средствазадания ограничений очень распространены в существующих DSM-платформах.Ограничения бывают двух видов — ограничения на состояние разработаннойсистемы во время её работы и ограничения на модель системы в процессе её разработки. Первый вид ограничений схож с операторами assert в текстовых языкахпрограммирования, второй — с синтаксическими проверками кода, выполняемыми компилятором или средой разработки. В случае DSM-платформы первыйвид ограничений может быть реализован только для частных случаев, в рамках110разрабатываемых с помощью DSM-платформы визуальных технологий. Второйже вид ограничений может описываться на уровне метамодели визуальногоязыка, в этом случае ограничения могут автоматически проверяться редакторомдиаграмм.
Далее речь пойдёт исключительно про второй вид ограничений.Задание ограничений на создаваемую модель частично происходит в самой метамодели, правила синтаксиса языка не позволят создать некорректнуюдиаграмму, если редактор строго им следует (что в случае DSM-платформпрактически всегда так, потому что редактор определяется метамоделью). Насколько сложные ограничения можно задать в метамодели языка зависит отиспользуемого метаязыка. Например, метамодель UML использует для заданияограничений полноценный текстовый язык OCL, позволяющий писать скольугодно сложные запросы к репозиторию с моделью и накладывать сколь угодносложные ограничения на её состояние.В системе QReal в соответствии с принципом «не надо знать то, чем непользуешься» сложные ограничения задаются отдельно от метамодели, с помощью модели ограничений.
Метамодель может быть создана без ограничений, онимогут быть добавлены в язык потом, по мере осознания разработчиками языкаих необходимости, и отдельно, без внесения изменений в метамодель. Крометого, в соответствии с идеологией предметно-ориентированного визуальногомоделирования ограничения задаются с помощью специально созданного дляэтого предметно-ориентированного визуального языка. Данный язык, а такжесредства проверки ограничений, разработанные под руководством автора даннойработы, описаны в статье [113], ниже приводится лишь краткое описание данныхсредств.Модель ограничений создаётся после создания метамодели языка (или совместно с ней), также имеется возможность задавать ограничения, проверяемыедля всех метамоделей (например, что связи должны быть обязательно подсоединены к узлам).
Модель ограничений состоит из набора ограничений на узлы исвязи. Для каждого узла или связи возможно указать ограничения на значение егосвойств, для узла можно указать ограничения на входящие и исходящие связи,на содержащиеся в узле элементы или наоборот, на содержащий узел элемент,для связи — на узлы, с которых начинается или которыми заканчивается связь.Для каждого ограничения можно указать его важность — предупреждение или111критическая ошибка.
В случае нарушения ограничения-предупреждения элементнарушитель подсвечивается на диаграмме, в случае нарушения критическогоограничения в дополнение к подсветке в окне ошибок появляется текстовоесообщение.Пример простого ограничения, применимого ко всем типам связей всехметамоделей, приведён на рисунке 4.4. Ограничение требует, чтобы у любойсвязи существовал и начальный, и конечный узел (зелёный квадрат означает узел,из которого исходит связь, красный — узел, в который связь входит, true означает,что они должны существовать).
Ограничение имеет важность «предупреждение».Рис. 4.4: Ограничение, проверяющее наличие начального и конечного узла усвязи.Пример диаграммы с нарушением этого ограничения приведён на рисунке 4.5.Связь, не имеющая конечного узла, выделена средством проверки ограниченийкрасным.Рис. 4.5: Пример отображения нарушения ограничения.112Механизм проверки ограничений реализован следующим образом. По моделиограничений генерируется код подключаемого модуля проверки ограничений наC++, который компилируется в динамическую библиотеку. При запуске QReal всемодули проверки ограничений загружаются в подсистему проверки ограниченийядра QReal.
При выполнении пользователем определённых действий (таких какизменение имени элемента, изменение значения свойства элемента, создание илиудаление элемента, подключение или отключение связи) вызывается обработчикв подсистеме проверки ограничений. Обработчик быстро проверяет наличиеограничения на тип изменённого элемента в списке подключённых модулейпроверки, а также для всех связей и содержащих элемент элементов, и наоборот,элементов, содержащихся в данном. В случае, если в подключённых модулях хотьодно такое ограничение есть, для каждого ограничения вызывается его проверка,результаты собираются в список и, если есть невыполненные ограничения,информация об этом предоставляется пользователю в виде подсветки элементовна диаграмме и, возможно, в текстовом виде в окне ошибок.
Таким образом,несмотря на то, что проверка ограничений вызывается при практически любомредактировании модели, за счёт фильтрации ограничений по типу проверяемогообъекта это не приводит к существенной потере производительности.4.3.4. Редактор правил рефакторингаВозможность автоматически применять рефакторинги для диаграмм довольно редка среди CASE-систем и DSM-платформ, но стала вполне обычнойдля текстовых сред программирования, поэтому ожидается и от создаваемыхвизуальных сред, чтобы успешно конкурировать с текстовыми.
Рефакторингопределяется как изменение внутренней структуры программы без измененияеё видимого поведения с целью сделать её проще для понимания и упроститьеё сопровождение [146]. В случае с визуальными моделями рефакторинг можетрассматриваться как изменение логической модели системы или как изменениевнешнего вида диаграммы, не затрагивающее логическую модель (например,перерасположение элементов). Второй вид рефакторинга исследован достаточнохорошо (см. GraphViz [22], KIELER [37] и т.д.), система QReal используеткомпоненту GraphViz для автоматической раскладки элементов на диаграммах.Первый вид рефакторингов изучен гораздо меньше.113В общем случае схема рефакторинга визуальной модели такова [46].
Системасостоит из нескольких визуальных моделей, характеризующих систему с разныхточек зрения, по моделям автоматически генерируется часть кода, другая частькода, возможно, пишется вручную. При рефакторинге необходимо, во-первых,внести необходимые изменения в редактируемую модель, во-вторых, синхронизировать изменения с другими моделями, в-третьих, выполнить перегенерациюкода по моделям, затронутым изменениями, в-четвёртых, согласовать рукописный код. Рефакторинг вручную может оказаться весьма трудоёмким процессом,поэтому естественно желание его автоматизировать. Но для каждого визуального языка набор рефакторингов может быть свой, зависящий от семантикиконкретного языка.
Поэтому требуется задавать правила рефакторингов на уровнеметамодели. В QReal для задания рефакторингов принят тот же подход, чтои для задания ограничений — правила рефакторингов, если они требуются,определяются в отдельной модели после определения метамодели языка, дляэтого используется специализированный визуальный язык.
Ниже приводитсякраткое описание реализации системы рефакторингов в QReal, подробнее ореализации см. в статьях [118,120]. Общая схема разработки и применения правилрефакторинга представлена на рисунке 4.6.Язык описания правил рефакторинга имеет интересную особенность — егоэлементами являются элементы языка, для которого определяется правило рефакторинга.
Эти элементы автоматически подгружаются из метамодели разрабатываемого языка редактором правил рефакторинга и используются для определенияшаблонов, которые будет сопоставлять в диаграмме средство выполнения рефакторинга при его применении. Сами правила задаются в виде графовых грамматик:правило делится на часть BEFORE, в которой задаётся шаблон, который ищется вдиаграмме, и на часть AFTER, на которую замещается сопоставленный шаблон.При этом в правиле можно использовать специальные элементы, такие как«Выделенный фрагмент диаграммы», каждому элементу можно указать его идентификатор. Элементы, имеющие одинаковый идентификатор в левой и правойчасти правила, считаются одним элементом и будут сохранены (возможно, с изменениями) при рефакторинге. Элементы, идентификатор которых не встречается вчасти BEFORE, будут созданы, элементы, идентификатор которых не встречается114Рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
