Диссертация (1148272), страница 23
Текст из файла (страница 23)
4.6: Схема разработки и применения правил рефакторинга.в части AFTER — удалены. Можно модифицировать существующее значениесвойства элемента, для доступа к нему используется ключевое слово EXIST.С технической точки зрения средство применения рефакторингов используеттот же механизм работы с графовыми грамматиками, что и используемый длязадания семантики интерпретации визуальных языков. Этот механизм, а такжесуществующие его аналоги, подробно описан в статьях [129–132]. Физическисредство применения рефакторингов реализовано как подключаемый модуль кQReal, поскольку, в отличие от подсистемы проверки ограничений, не требуеттесной интеграции с ядром системы.1154.3.5.
Средства поддержки технологии «метамоделирования налету»Технология«метамоделированияналету»позволяетразрабатыватьпредметно-ориентированные языки, не используя метаредактор, прямо впроцессе рисования диаграммы на разрабатываемом языке. Методологическиеаспекты технологии, включая описание процесса создания языка в соответствиис ней, описаны в разделе 3.4 настоящей работы, здесь будет кратко описанареализация инструментальных средств поддержки этой технологии в системеQReal.
Более подробное описание реализации можно найти в статье [133].Средства разработки редактораМетамоделирование на лету — это особый режим работы QReal, не доступныйпри работе с такими технологиями, как QReal:Robots. Таким образом, пользователи предметно-ориентированных решений, созданных на основе QReal, имеютвозможность даже не знать о существовании такой функциональности.При создании новой интерпретируемой метамодели будет открыто окноредактора с пустой палитрой.
Элементы добавляются в язык через контекстноеменю палитры. Если создаваемый элемент — сущность, его можно пометить каккорневой элемент диаграммы, в этом случае он будет создаваться автоматическипри создании диаграммы, и только он может быть в корне иерархии включенияэлементов (то есть это тот элемент, в который как в сыновья добавляютсявсе остальные). Вновь созданный элемент будет иметь форму по умолчанию(прямоугольник для сущностей и обычную линию для связей) и не будет иметьсвойств. Элемент уже можно начать использовать, например, если это корневойэлемент нового языка, создать новую диаграмму, куда можно добавлять этот жеили другие элементы.
Форму элемента можно поменять через контекстное менюэлемента. Схематически данный процесс показан на рисунке 4.7.Свойства элемента также можно добавить, удалить или отредактировать черезконтекстное меню. Свойства характеризуются своим именем, типом и значениемпо умолчанию. При создании нового свойства эти характеристики надо будетввести, для существующих свойств их можно редактировать. При этом естьнекоторые ограничения, связанные с поддержанием консистентности модели.116Рис.
4.7: Создание нового элемента языка.Например, элементам, экземпляры которых уже существуют на диаграмме, нельзя добавить новое свойство — уже существующие экземпляры добавленногосвойства иметь не будут, что может привести к ошибкам в инструментальныхсредствах, которые рассчитаны на то, что все обозначенные в метамоделисвойства у экземпляров элементов есть. В таком случае система запрещаетдобавление свойства и требует, чтобы до добавления свойства все экземплярыбыли удалены. При этом удаление свойства элемента безопасно — существующиеэкземпляры будут иметь удалённое свойство, но оно никогда не будет запрошено,поскольку отсутствует в метамодели. Процесс редактирования свойства элементасхематически представлен на рисунке 4.8.Средства разработки генератораСредства «метамоделирования на лету» позволяют создавать прототип генератора для разрабатываемого визуального языка, что делает возможным в короткие117Рис. 4.8: Редактирование свойств элемента.сроки создать прототип полноценного предметно-ориентированного решения,позволяющего создать диаграмму и сгенерировать по ней код.
Реализация средствгенерации для режима «метамоделирования на лету» подробно описана в статье [145].Для задания правил генерации используются шаблоны на текстовом языке,размеченные управляющими конструкциями и выражениями, позволяющимиподставить в генерируемый код значения свойств из модели. Правило генерацииможет быть описано для каждого элемента, при запуске генератора вызовется правило генерации для корневого элемента модели, которое, в свою очередь, можетвызвать правила генерации остальных элементов. Правила могут быть добавленыв процессе редактирования диаграммы с помощью контекстного меню элементав палитре. При этом откроется окно редактора правила, с палитрой языковыхконструкций, снабжённых контекстной справкой, и палитрой свойств элемента,для которого редактируется правило.
Редактор правил имеет синтаксическуюподсветку.118Правило состоит из строк, генерируемых в целевой файл напрямую (онипишутся в кавычках) и ключевых слов, управляющих генерацией, таких как:foreach позволяет обходить элементы коллекций, например, список исходящихсвязей;this позволяет обратиться к текущему генерируемому элементу модели;if позволяет исполнить одну из двух веток правила в зависимости от условия;callGeneratorFor позволяет вызвать другое правило генерации;generateToFile позволяет переключить выходной файл генерации.Правило генерации интерпретируемо, то есть хранится как атрибут типаэлемента в метамодели и может быть вызвано сразу после своего создания.4.4. Сравнение эффективности разработанныхсредств с существующими инструментамиС целью количественного измерения эффективности разработанных в ходедиссертационного исследования методик и инструментальных средств был проведён эксперимент по сравнению процесса разработки визуальных предметноориентированных языков с помощью различных DSM-платформ, включая платформу QReal.
В ходе эксперимента был выбран достаточно простой визуальныйязык — диаграммы «сущность-связь» в нотации Чена [11], для которых сиспользованием двух самых популярных на данный момент DSM-платформ иплатформы QReal был разработан редактор визуального языка, генератор в SQLDDL1 , определено одно семантическое ограничение (сущность должна иметьхотя бы один атрибут) и одно правило рефакторинга (преобразование атрибутав сущность). Измерялось время реализации каждого элемента функциональностииз вышеперечисленных.1Data Definition Language1194.4.1. Организация экспериментаЦелью эксперимента было количественно проверить соответствие достигнутых в данной работе результатов цели работы — снижает ли предложенная методика трудозатраты при разработке инструментальных средств для визуальныхпредметно-ориентированных языков по сравнению с существующими аналогами.Было решено выполнить сравнение с двумя наиболее зрелыми и известнымина данный момент DSM-платформами.
По результатам обзора из главы 2 дляэтого были выбраны платформы MetaEdit+ [36] и Eclipse Modeling Project [79].В силу ограниченности ресурсов на проведение эксперимента было приняторешение реализовать инструментальные средства только для одного, причёмдостаточно простого языка. Несмотря на это, поскольку предлагаемые в даннойработе методики ориентированы на небольшие языки, результаты можно считатьпоказательными.Рассматривались только рекомендованные авторами технологий способы решения задачи, при этом не требующие кодирования на текстовых языках общегоназначения.
Две из трёх участвовавших в эксперименте платформ (QReal иEclipse Modeling Project) имеют открытые исходные коды, третья (MetaEdit+)предоставляет API на основе веб-сервисов для доступа к модели в репозитории,поэтому теоретически все эти платформы позволяют реализовать любую функциональность. Однако в ходе эксперимента считалось, что если для реализациифункциональности требуется программирование на языке общего назначения сиспользованием механизмов расширения системы, то система не позволяет этуфункциональность реализовать, в таком случае измерения не проводились.В эксперименте участвовало два человека, имеющих опыт профессионального программирования, разработки и использования визуальных предметноориентированных языков.
Перед проведением эксперимента участники создалипо одному визуальному языку на всех платформах, выбранных для измерений,чтобы ознакомиться с их возможностями. Работа над задачей экспериментавелась совместно. Таким образом, в эксперименте моделировалась небольшаякоманда разработчиков, имеющая небольшой опыт использования выбраннойDSM-платформы, перед которой поставлена задача разработать полноценноеDSM-решение.120Задача, которую требовалось решить в ходе эксперимента, ставилась следующим образом.• Разработать редактор диаграмм «сущность-связь» в подмножестве нотацииЧена со следующими элементами:– Сущность (имеющая имя);– Атрибут (имеет имя и тип);– Отношение (имеет имя);– Связь между сущностью и атрибутом;– Связь между сущностью и отношением.• Разработать генератор в язык SQL DDL, выдающий схему базы данных подиаграмме, созданной в разработанном редакторе.• Реализовать проверку семантического ограничения на диаграмму — каждаясущность должна быть связана хотя бы с одним атрибутом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
