Диссертация (1145120), страница 10
Текст из файла (страница 10)
Однако автоматическая генерация графическихредакторов используется не всегда, а точные модели, как указывалось выше,часто оказываются очень громоздкими (что, в частности, влечёт трудности вих сопровождении, а также обсуждении с различными сторонами,вовлечёнными в разработку DSM-решения). Поэтому часто строят неточныеметамодели, дополнительно задавая точные ограничения на них, например, спомощью языка OCL (Object Constraint Language) [362] (вариантыграфических ограничений на визуальные модели можно посмотреть,например, в работе [30]). Эти ограничения потом реализуются — путёмгенерации кода или «вручную» — в том самом программном интерфейсе,который работает с репозиторием модели и контролирует ввод моделейпользователя, делая невозможным создание некорректных моделей. Часто напрактике подобные ограничения делаются не с помощью OCL, а в видеобычного текста.Один из способов справиться со сложностью точных метамоделейявляется идея концептуального моделирования [65]: предлагалось строитьдве метамодели языка — концептуальную и реализационную.
Переход отодной модели к другой предлагалось поддерживать автоматически спомощью реализации механизма циклической разработки. Помимо двух этихмоделей предполагалась автоматическая генерация схемы документации для50языка по концептуальной модели с последующей доработкой (заполнением)этой схемы и также поддержкой синхронизации с метамоделями языка.Заканчиваяметамодельразговортребуетсяометамоделировании,безоговорочнолишьзаметим,тогда,чтокогдаточнаяпонейпредполагается генерировать код графического редактора для такого языка(как упоминалось выше, многие DSM-платформы позволяют это делать). Востальных случаях требуется ответить на вопрос — зачем мы создаёмметамодель DSM-языка и сколь точной она должна быть.Скрипты и визарды — данный способ задания языка заключается всоздании новой графической нотации и правил-ограничений для контроляспецификаций, которые будут разрабатываться в данной нотации.
При этомграфическая нотация и простейшие ограничения задаются в специальныхдиалоговых средствах DSM-платформы, более сложные ограничения могутзадаваться в специальных скриптах (как правило, в такие DSM-платформывстраивается некоторый несложный скриптовый язык). Данный способэффективен для несложных DSM-языков, а также когда не планируетсяреализовывать мосты из создаваемого графического редактора в другиесредства (если всё-таки планируется, то лучше нарисовать метамодель, пустьдаже не точную).Рассмотрим, как можно использовать скриптово-визардовый способ впакете Microsoft Visio.
C помощью специального диалогового инструмента,встроенного в пакет, можно создать новую палитру (набор элементовнотации), и поместить на неё созданный обычными средствами Visioпроизвольный графический элемент. После этого, используя встроенный вVisio скриптовый язык VBA (Visual Basic for Application), а также другиесредства, можно задать поведение этого графического элемента — связать сним некоторое множество точек соединения, задать правила расположениятекста, перерисовки и т.д. Фактически, данный способ концентрируется наконкретном синтаксисе (нотации), а также на семантике.
Абстрактный51синтаксис не выделен отдельно и задаётся частично вместе с нотацией, ачастично — с семантикой. Наконец, служебный синтаксис является форматом vsd-файла, и в нём смешиваются модель и диаграммы, что затрудняетподдержкуцелостностимногодиаграммныхспецификацийиихсинхронизацию с другими артефактами в других программных средствах. Носуществует множество случаев, где это и не требуется.Как правило, cкриптово-визардовый способ задания визуальных языковиспользуется в «легковесных» DSM-платформах — Microsoft Visio [351],AutoCAD [166], — ориентированных на настройку базового графическогопакета, а не на разработку новых программных инструментов. При этомосновной акцент в таких платформах делается на гибкость графическогопредставления, то есть оказывается возможным создание очень широкогоспектра визуальных языков.
В более программистских DSM-платформах,например, в Microsoft Modeling SDK [213], MetaEdit+ [346] и GMF [398],имеется ряд существенных ограничений на сложность фигур в нотации. Вкачестве примера сложных фигур в DSM-языке приведём элементы нотацииязыка THCL (данный язык подробно рассмотрен в диссертации ниже). Нарис. 1.9 представлен фрагмент диаграммы на THCL. Из этого рисунка видно,что конструкция «блок» (аппаратный функциональный узел системы,например, микросхема, плата и пр.) имеет входящие и исходящие разъёмы,которые ещё к тому же имеют ориентацию по сторонам блока. Каждомуразъёму соответствует имя, которое, фактически, является составной частьюблока. Линии в этом языке также сложно устроены — могут содержатьпереходники, ветвиться и т.д.Такой язык проблематично реализовать вMicrosoft Modeling SDK, MetaEdit+ и GMF.52Рис.
1.9. Пример сложных фигур, реализованных с помощью Microsoft Visio(язык THCL [72])Неформальный способ позволяет задавать DSM-язык в виде документа наестественномязыке,основывающемсянамногочисленныхпримерахиспользования этого языка. Именно на примерах поясняются основныеконструкции и, поскольку DSM-языки обычно не являются сложными, а, сдругой стороны, не все читатели таких спецификаций собираются создаватьграфические редакторы, то такой способ оказывается очень востребованным,таккаконповышаетуровеньосведомлённостизаинтересованных сторон DSM-проекта.оязыкевсехВ силу несложности языкаформальные описания могут быть легко построены по таким примерам,однако возможны неоднозначные трактовки отдельных конструкций.Следует отметить, что даже при формальном способе описания DSM-языканепонимания и противоречия всё равно остаются, так как обычно многиевовлечённыевDSM-проектспециалистыструдомвоспринимаютформальные спецификации.
Поэтому документы и примеры бывают нужныдаже в том случае, если язык определён с помощью метамодели, посколькусемантика и прагматика языка в любом случае задаются неформально.53Особенноважныпримеры—оничастопомогаютисключить«воображаемые» конструкции языка: такие конструкции вроде бы нужны, ноникто не может дать точный ответ на вопрос о том, как их использовать.Ввиду ограниченности ресурсов DSM-проектов такие конструкции лучшеисключать.Автор часто пользуется этим способом на практике, и не только в томслучае, когда не используется автоматическая генерация самого редактора поформальнойметамодели.
Несмотря на то, чторазработка точногоабстрактного синтаксиса языка в виде метамодели повышает качество языка,это является довольно затратной деятельностью — иметь работающийредактор,поддерживающийпредпочтительнее.нужнуюфункциональность,оказываетсяОднако, если язык достаточно сложен, а такженеобходимо интегрировать средства его программной поддержки с другимипрограммными средствами, то разработка метамодели предпочтительна.1.2.3 Платформы разработки предметно-ориентированных решений19Можно выделить следующие наиболее известные платформы разработкипредметно-ориентированных решений в области программной инженерии:MetaEdit+[346], GMF [398], Microsoft Modeling SDK [213], а такжебиблиотеки EMF и GEF [87]. В целом, существует около 40 различныхразработок в этой области, которые, в основном, являются академическимипроектами (с ними можно ознакомиться в работе [115]).MetaEdit+ является наиболее зрелой платформой в области программнойинженерии.
Продукт разрабатывается компанией MetaCase при участииуниверситета города Ювяскюля, Финляндия (University of Jyvaskyla).Продукт развивается с 1991 года и имеет десятки внедрений. Последняяверсия (номер 5.1) вышла в 2014 году.19Имеются многочисленныеВ данном разделе частично используются материалы работ автора [49] и [87].54публикации авторов продукта в области DSM [300], [301], [302], [303], [304],[305], [306], [374], [375], [440].Graphical Modeling Framework (GMF) является частью проекта EclipseModeling Project, включающего в себя набор свободно распространяемыхприложений с открытым исходным кодом, предназначенных для поддержкивизуального моделирования. Самыми известными приложениями этого проекта, помимо GMF, являются EMF (Eclipse Modeling Framework) и GEF(Graphical Editor Framework). Подробнее об этом проекте см.
[87], [233],[268]. Задачей GMF является предоставить разработчикам DSM-средств высокоуровневые возможности для автоматической генерации таких средств наоснове множества метамоделей. Речь идёт именно о реализации DSMсредств, а не столько о профессиональной разработке сложных визуальныхсистем. Процесс разработки графического редактора на основе GMF изображён на рис.
1.10 и состоит из следующих шагов.1. Разработка доменной модели (domain model), то есть абстрактного синтаксиса языка.2. Разработка описания графического редактора (graphical model) — модели графического представления языка, то есть конкретного синтаксиса.3. Разработка описания вспомогательных средств графического редактора(tooling model) — палитры для элементов нотации, списка действий,меню графических объектов и т.д.4.
Разработка модели отображения (mapping model) — описание связейдоменной модели и графических объектов, а также спецификациявспомогательных средств и описание ограничений для доменной модели на OCL или Java.5. Создание модели генератора (generation model) — описание генератораграфического редактора по модели отображения.556. Генерация кода целевого графического редактора, запуск отладочногоэкземпляра Eclipse Application и отладка результата.Рис. 1.10. Процесс разработки графического редактора с помощью GMFБиблиотеки EMF и GEF являются, подобно технологии GMF, частью инициативы EMP, причём используются не только для разработки DSM-средствв области программной инженерии, но также для более широкого классаприложений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
