Диссертация (1148239), страница 13
Текст из файла (страница 13)
В главе описываются основные компоненты созданного решенияи обсуждается их использование разработчиком и пользователями создаваемогоязыка.75Глава 5. Платформа QReal5.1. ВведениеВ данной главе описывается архитектура предлагаемой в работе DSMплатформы QReal, позволяющая гибко настраивать компоненты платформы подконкретные решения. Рассматривается состав платформы, функциональность,предлагаемая разработчикам: графический интерфейс пользователя, хранилищемоделей, генераторы кода, отладчики и интерпретаторы моделей, механизмырефакторингов, проверки ограничений и другое.5.2.
Технология QRealТипичный процесс работы с платформой QReal выглядит следующим образом.ИспользуянаборинструментовплатформыQReal,разработчикспециализированного графического языка создает ряд формальных описаний этогоязыка — задает его метамодель (перечисляет набор сущностей языка, возможныесвязи между ними и их свойства), определяет внешний вид элементов, описываетограничения, налагаемые на них или их группы, задает правила преобразованиямоделей для получения исходного кода, описывает семантику сущностей языка ит.п. (про методику разработки визуальных языков и инструменты поддержкипроцессаметамоделированиявQRealсм.диссертационнуюработуЮ. В.
Литвинова). По завершении формальных описаний разработчик языка из нихпосредством инструментов QReal автоматически получает среду визуальнойразработки, имеющую в своей основе данный язык. Так как созданное DSM-решениеиспользует для своей работы инфраструктуру и компоненты платформы QReal, товесь базовый функционал платформы автоматически доступен и для создаваемых наее основе решений. Это позволяет разработчику языка сосредоточиться лишь на76функционале, являющимся особенным для создаваемого языка. Однако, еслиграфическийотсутствуетредакторвподразумеваетбазовойплатформе,какую-тоеефункциональность,придетсяреализовыватькотораяотдельнопрограммированием на C++.
Также в текущей версии QReal “вручную” приходитсяреализовывать и сложные генераторы исходного кода, требующие серьезногоанализа создаваемых моделей (стоит отметить, что платформа предоставляет дляэтого довольно удобные возможности в виде соответствующих программныхинтерфейсов и уже готовых примеров). Более простые генераторы (например,шаблонные генераторы, использующие уже написанные ранее шаблоны конечныхпрограмм) в платформе QReal возможно создавать автоматизированно на основемоделей, задающих операционную семантику языка. К тому же, в большинствеслучаевповизуальныммоделямпроисходитгенерациянеполноценныхприложений, а код, активно использующий API уже существующих библиотек, вкоторых уже реализована значительная часть функциональности, полезной дляданной предметной области. Как правило, это приводит к уменьшению размерагенерируемого кода, а значит, и к сложности генератора кода.
Такие генераторытакже могут быть эффективно созданы автоматизированно по модели описанияоперационной семантики языка.Рассмотрим подробнее архитектуру платформы QReal и то, как онавзаимодействует с создаваемыми на ее основе DSM-решениями.5.3.
Общая архитектура платформы QRealТехнология QReal изначально задумывалась как развитие технологии REAL[52], основывающееся на использовании более современной версии языка UML —2.0.Приэтомнаразрабатываемыемногоплатформенностиоперационныхсистемах(возможностьMSWindows,средстваработыLinuxнакладывалисьнаинаиболееMacOSX),требованияпопулярныхподдержка77многопользовательской разработки, возможность удаленного доступа к репозиториюсистемы и другая актуальная для современных сред визуальной разработки ПОфункциональность. Однако, быстро стало очевидно, что создание большого числаредакторов диаграмм вручную является довольно утомительным занятием, к томужеполучаемаясистемаоказываетсяплохомасштабируемой:созданиедополнительного редактора, являющегося типовым для данного CASE-средства,чаще всего будет осуществляться методом копирования-вставки с дальнейшимидоработками полученного после копирования кода, что влечет как к размножениюуже существующих ошибок, так и к появлению дополнительных, например,связанных с неполнотой вносимых правок.
Возникла необходимость в средствахбыстрого создания визуальных языков и инструментальной поддержки для них [30].Дляавтоматизациипроцессасозданиятакихредакторовметамоделисоответствующих языков должны быть описаны формально с помощью некоторогоязыка7, текстового или графического (или даже набора языков). Далее эти описаниямогут быть использованы следующим образом:●в рамках генеративного подхода [4] по описанию метамодели генерируетсяпрограммный код, который тем или иным образом дополняет код самогоDSM-решения, привнося в него особенности данного языка;●в рамках интерпретативного подхода в состав DSM-решения входит механизм,который по запросу читает нужные данные прямо из описания метамодели иобрабатывает их нужным образом (например, считывает количество и типсвойств элементов и отображает их в редакторе свойств). То есть, во времяработы с редактором происходит интерпретация метамодели языка.Исторически в QReal первым был реализован генеративный подход, посколькуон более прост в реализации и, как правило, откомпилированный код работаетбыстрее, чем некий сложный механизм, интерпретирующий внешние данные.
Это7В случае текстовых языков для этого чаще всего используются формы Бэкуса-Наура.78решение привело к тому, что архитектура как платформы, так и сред разработки,созданных на ее основе, становилась все более и более модульной (см. рис. 13) —конкретныеDSM-решениянабазеQRealполучаютсядополнениемипараметризацией кода самой DSM-платформы. Абстрактная функциональностьредакторов (например, такая, как способность двигать и масштабировать элементына диаграммах, соединять их связями, хранить в репозитории значения их свойств ит.п.) максимально абстрагируется и формирует так называемое “ядро” системы, в товремя как специфика каждого конкретного визуального языка оформляется в видеподключаемогомодуля-плагина.Кодкаждоготакогомодулягенерируетсяавтоматически по описанию метамодели языка, компилируется в плагин и не зависитот каких-либо других частей QReal.
Плагины загружаются диспетчером модулей,который, в свою очередь, предоставляет интерфейс остальным частям QReal длядоступа к информации, содержащейся в плагинах редакторов: именам и типамэлементов и связей между ними, изображениям элементов, числу и типу их свойств,правилам соединения элементов связями и т.п.ПомимоплагиновредактороввQRealсуществуюттакжеплагиныинструментов. В них выносится функциональность различных инструментальныхсредств CASE-пакета, которые могут быть полезны проектировщику — механизмверсионирования моделей, генераторы кода, отладчики и интерпретаторы, механизмзадания и проверки ограничений на создаваемые модели, механизм задания ипроведениярефакторинговмоделейит.п.Этопозволяетмаксимальнопереиспользовать инструменты между создаваемыми на базе QReal DSMрешениями — стоит добавить какую-нибудь функциональность в «ядро» системыили оформить ее в отдельный подключаемый модуль, и все DSM-решения прижелании получат эту функциональность автоматически.Рассмотрим подробнее архитектуру отдельных частей платформы.
Основныебиблиотеки QReal и их взаимодействие показаны на рис. 14.79Рисунок 13. Общая архитектура DSM-решений на основе QReal8Библиотека qrkernel представляет библиотеку классов, используемых во многихдругих модулях: класс для работы с конфигурационными файлами настроек, классидентификаторов сущностей в моделях QReal, классы исключений и т.п.
Как видноиз рис. 14, этот модуль активно используется другими.Назначение библиотеки qrutils сходно с qrkernel, однако если содержимоепоследней используется без исключения всеми другими компонентами, то в qrutlisнаходится код, который может понадобиться лишь некоторым другим компонентам.Например, в qrutils находятся абстрактные классы для кодогенераторов, базоваячасть модуля трансформации графов, некоторые графические утилиты для работы сдиаграммами, средства для вызовов из кода сторонних программ и другие.8Цветом выделены компоненты, разработанные автором в рамках диссертационного исследования80БиблиотекаРепозиторийqrrepoреализуетпредоставляетфункциональностьостальнымрепозиториякомпонентамплатформыQReal.интерфейсRepoApi, который позволяет осуществлять все необходимые операции над моделями— загрузку и сохранение проектов, создание и удаление элементов и связей междуними, получение и установка свойств элементов и связей и многое другое.Компонента qrgui представляет собой основное приложение, реализующееграфический интерфейс пользователя.Рисунок 14.
Основные модули QRealКомпонентавизуальныхeditorPluginsредакторов.ЧерезпредставляютинтерфейссобойподключаемыеEditorInterfaceкаждыймодулиплагинпредоставляет информацию о наборе диаграмм, содержащихся в данном модуле, отипе и числе элементов и связей в языке, о числе, типах и значениях по умолчаниюсвойств каждого типа элемента и связи, о способе группировки элементов языка впалитре QReal, о правилах соединения элементов связями и о правилах помещенияодних элементов в другие как в контейнер, предоставляет фабрику созданияэлементов данного языка и некоторые другие средства, используемые «ядром»81QReal.
Сами плагины редакторов используют общую функциональность платформы,вынесенную в модули qrkernel и qrutils, а также репозиторий через интерфейсElementRepoInterface для получения значений свойств элементов.КомпонентаtoolPluginsпредставляетнаборподключаемыхмодулейинструментов QReal. В подобные плагины выносится любая функциональность,которая напрямую не относится к ядру QReal, то есть потенциально может быть ненужна для определенных DSM-решений. Каждый такой плагин предоставляетинтерфейс ToolPluginInterface, через который с ним можно совершать следующиедействия: запросить список меню и элементов панелей для встраивания в главноеокно QReal, запросить страницу настройки для встраивания в общее окно настроексреды, название главного окна и иконку приложения.
С основной частью QRealплагины инструментов взаимодействуют через интерфейсы InterpretersInterface иModelsInterface. Первый позволяет изменять состояние главного окна (выделять иподсвечивать элементы на диаграммах и некоторые другие), загружать и выгружатьдругие плагины. ModelsInterface представляет доступ к данным моделей —доступны операции создания новых элементов, получения свойств текущих,проверка принадлежности элемента контейнеру и т.п.5.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
