Диссертация (1148239), страница 24
Текст из файла (страница 24)
Для нового языка процесс нужно будетповторять заново со всеми техническими деталями, что не дает существенногоупрощения, ускорения и автоматизации процесса создания отладчика по сравнениюс ручным кодированием.B.2. Исполнимый UMLПоявление унифицированного языка моделирования UML и его использованиедля объектно-ориентированного моделирования при разработке ПО способствовалосильному продвижению визуального проектирования среди разработчиков. Однако,сам по себе UML — это язык именно проектирования и документирования, а непрограммирования, семантика многих его элементов либо не задана явно, либочересчур детально, но не формально, описана в спецификации, благодаря чему могутслучаться различные ошибки в их согласованности. Для того, чтобы применять146диаграммы UML для генерации кода, был создан язык, получивший названиеисполняемого UML (Executable UML, xUML [115, 150]).
Формально этот языкявляется профилем UML, т.е. подмножеством языка UML c четко определённойсемантикой для каждого элемента. Это подмножество выбрано так, чтобы сделать наоснове UML полноценный визуальный язык программирования общего назначения.Так же, как и UML, xUML основан на объектно-ориентированном подходе, т.е.описание системы ведется в терминах классов, атрибутов и т.п.Для задания семантики отдельных элементов в xUML используется явноопределённая семантика действий (Precise Action Semantics, PAS [118]). PAS — этофиксированныйнаборсемантическихопераций,неимеющийконкретногосинтаксиса и реализации.
PAS обеспечивает независимость, например, отконкретной целевой платформы или языка, на которых будут исполняться модели.Программирование на xUML основано на трёх следующих компонентах.●Диаграмма классов, характеризующая структурную модель наблюдаемойсистемы. В неё входит отображение объектов реального мира классами. Этиклассы имеют атрибуты, а связи между классами представляются в видеотношений.●Диаграмма состояний, определяющая набор действий, которые совершитактивныйобъект,т.е.изображающаяжизненныйциклобъекта,представленный в виде конечного автомата.●Язык действий (Action Language, AL), позволяющий задавать поведениеобъекта при проходе каждого состояния в диаграмме состояний. Оннеобходим для создания экземпляров классов, установки связей между ними,выполнения различных операций над атрибутами и т.п.
AL являетсяконкретнойреализациейPAS,выборкоторойлежитнасоздателяхинструментов и пользователях, а не заложен в xUML. xUML явно определяеттолько PAS. Действия и PAS – это ключевые понятия в исполняемой части147языка xUML. Действие — это конкретная операция, определённая на элементемодели, принадлежащая классу и характеризующая его поведение послеинициализации. Достаточно выучить только один AL, т.к.
остальные будутиметь тот же семантический набор операций. На данный момент существуетдовольно много готовых AL: OAL [126], SMALL [146], TALL [118] и т.д.Таким образом, упрощённо данный подход основан на представленииструктуры разрабатываемой системы в виде диаграмм классов, а поведения в виденабора диаграмм состояний для каждого активного объекта. Действия при проходекаждого состояния в таких диаграммах записываются при помощи AL.
При этомблагодаря тому, что элементы xUML обладают чётко фиксированной семантикой,появляется возможность как однозначно генерировать исполняемый код по модели,так и отлаживать создаваемые модели: симулируются описанные объекты и обменсообщениями между ними, при переходе из одного состояния в другое выполняетсякод, записанный на AL.Разработка ПО с использованием xUML несомненно имеет свои преимущества:разработкасоздаваемыеведётсяспомощьюдиаграммычёткоподмножестваформализованыширокоиизвестногознакомыязыка,большинствуразработчиков, существует мощная инструментальная поддержка, включающаясимуляторы и отладчики создаваемых систем и многое другое. Однако, данныйподходоснованнатрадиционныхпрограммированияинапонятияхстандартныхобъектно-ориентированногоконструкцияхтекстовыхязыковпрограммирования (ветвления, циклы и т.п.), поэтому на практике значительногоповышенияуровняабстракции(и,какследствие,продуктивноститрударазработчиков) он не даёт.B.3.
EProvideEProvide (Eclipse Plugin for Prototyping Visual Interpreters and Debuggers) — это148подключаемый модуль (плагин) для среды разработки Eclipse, позволяющий быстрозадавать операционнуюсемантику дляпредметно-ориентированныхязыков,основанный на технологиях моделирования Eclipse [44]. Подход, использующийся вэтом плагине, описан в статьях [140, 158].В данном подходе для задания исполнимой семантики языка метамодель этогоязыка расширяется дополнительными элементами, обеспечивающими хранениесостоянияэлементовсоздаваемоймоделивовремяееисполнения,функциональность точек останова, слежение за значениями свойств элементовмодели и т.п.
Правила, задающие семантику языка, в EProvide задаются в текстовомвиде с помощью языков QVT Relations, Java, Abstract State Machines (ASM [67]),Prolog или Scheme. С помощью данных правил на основе расширенной метамоделиязыка при запуске процесса отладки создается и инициализируется модель времениисполнения(соответствующаяисходноймодели)ивыполняютсяеепоследовательные преобразования.Данный подход позволяет описывать исполнимую семантику и создаватьотладчики и интерпретаторы для произвольных языков, что существенно расширяетобласть его практической применимости. Инструмент EProvide реализован в рамкахплатформы Eclipse и хорошо интегрирован с другими инструментами платформы.Однако, описание семантики на текстовых языках сильно понижает наглядностьэтих описаний. Стоит также отметить, что создание полноценного отладчика иинтерпретатора языка в платформе Eclipse — довольно сложный процесс,требующих серьезных технических навыков12.
Перенос же созданного средства надругую платформу потребует повторной реализации серьезной части инструментов(например, создания интерпретатора QVT Relations), что весьма нетривиально.12См., например, инструкцию от авторов EProvide:http://sourceforge.net/apps/mediawiki/eprovide/index.php?title=Tutorial:_Developing_a_Robot_DSL_with_EProvide (датаобращения: 18.04.2015)149B.4.
Dynamic Meta ModelingДругим способом задания семантики визуальных языков, использующим вкачестве своей основы технологию преобразования графов, является динамическоеметамоделирование (Dynamic Meta Modeling, DMM) [90]. Основной идеей в DMMявляется тот факт, что модель, созданная при помощи визуального языка,рассматривается как типизированный мультиграф с атрибутами и метками на узлахи рёбрах, допускающий наследование, связанное с возможностью расширения типовузлов и рёбер.
Сам же процесс исполнения связан с преобразованиями такихтипизированных графов. Задаётся соответствующий набор правил преобразованияграфов, которые впоследствии поочерёдно применяются к модели.В общем случае ([138]), правило преобразования графов состоит из правой илевой части. При применении правила к модели происходит следующее: в моделиищется подграф, совпадающий с левой частью, и заменяется на то, что стоит вправой.
При такой замене могут удаляться и добавляться элементы, переставлятьсяконцы связей и т.п.DMM потенциально можно использовать и для визуализации процесса отладкидиаграмм. Можно организовать настраиваемое пошаговое исполнение, т.е. сколькоправил следует применить перед следующим обновлением диаграммы, интерфейс,позволяющий следить за значениями атрибутов различных элементов и изменять ихпрямо во время исполнения и т.п. В случаях, когда правило можно применить вразных местах или когда есть несколько правил, которые можно применить наданном шаге, можно предоставлять этот выбор пользователю. Также можно ввестипонятие точек останова, причём разных видов.
Например, точка останова наприменение конкретного правила, на изменение конкретного элемента, на получениеопределённой конструкции в графе модели и т.п. Подробнее с этими идеями можноознакомиться в работе [62].Основным отличием данного подхода является его наглядность: семантика в150DMM задается визуально в виде правил графовых грамматик. Среди главныхнедостатков этого подхода можно выделить высокую алгоритмическую сложность,связанную с задачей поиска подграфа в графе, а также отсутствие реализации.Стоит, однако, отметить, что в левых частях правил преобразования графов восновном помещают небольшие фрагменты графов, что позволяет добитьсяприемлемого быстродействия инструментов, осуществляющих поиск данныхшаблонов в моделях.B.5.
AToM3Примером реализации идей, заложенных в подходе DMM, является заданиесемантики в DSM-платформе AToM3 (A Tool for Multi-Formalism and MetaModelling, [112]), написанной целиком на языке Python. Трансляция и интерпретациямоделей, а также генерация кода по моделям осуществляется в AToM3 при помощиграфовых грамматик и последовательного преобразования моделей в соответствии справилами грамматики.
В рамках интерпретации и отладки AToM3 поддерживаетпошаговое и непрерывное исполнение модели, причем даже с учетом изменениямодели «на лету», т.е. прямо перед исполнением очередного шага.Модель каждого правила задается графически и сохраняется отдельно в видескрипта на языке Python. По этой модели генерируется ещё один скрипт,являющийся кодом, который будет производить необходимые изменения согласноправилу.
Первый файл необходим для того, чтобы можно было удобно изменятьсостав и логику работы этих правил, а второй — чтобы быстро видеть, какиеоперации будут выполнены при применении правила.Другой отличительной от DMM-подхода особенностью является возможностьпри помощи специальных меток определять, что значение свойства элемента дляприменения правила может быть любым, задавать, оставить ли значение свойстваэлемента модели как есть или изменить его при выполнении правила. Также в151AToM3 можно ставить более сложные ограничения на применение правила,связывающие атрибуты нескольких элементов левой части, при помощи OCL илизадавать их на языке Python.
Кроме дополнительных условий можно на тех жеязыках указывать список действий, которые необходимо исполнить послеприменения правила.B.6. Сравнение подходовОсновные сходства и различия описанных способов задания семантикиинтерпретации визуальных языков можно увидеть в таблице 3. Сравнение подходовосуществлялось по шкале от 0 до 3 по следующим критериям.Универсальность — возможность задания семантики для произвольныхвизуальных языков, т.е. оценка того, насколько подход может быть использован впредметно-ориентированном моделировании.
Двухуровневая отладка совсем несоответствует парадигме DSM, т.к. данный подход ориентирован на созданиеединичного отладчика для определённого языка и не подразумевает удобногообобщения (0 баллов), xUML работает так или иначе только с диаграммами UML (0баллов), в то время как остальные способы не зависят от входного визуального языка(3 балла).Задание семантики на основе хорошо определённого (математически) подходадобавляет программам доказуемость и предсказуемость поведения, т.е.
при такомзаданииневозможнаразличнаяинтерпретацияспецификации,котораябыприсутствовала, например, в большом текстовом описании. За это отвечаеткритерий формальности. DMM и AToM3 основаны на технологии преобразованияграфов (3 балла), EProvide поддерживает задание семантики, основанной настандартеQVTRelation,аxUMLбазируетсянаPAS,котораябыластандартизирована Object Management Group в 2001 году (1 балл).Наглядность средств задания семантики определяется тем, визуально (3 балла)152ли это нужно делать или при помощи текста (0 баллов). Подходы, основанные напреобразованиях графов, т.е. DMM и AToM3, являются большей частьювизуальными, а остальные — текстовыми. xUML, благодаря своей визуальнойсоставляющей в виде диаграмм состояний жизненных циклов объектов, по данномукритерию можно оценить в 1 балл.Наглядность процесса интерпретации зависит от того, как эта интерпретациябудет отображаться пользователю.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
