Диссертация (1148272), страница 32
Текст из файла (страница 32)
Заглушки @@INITHOOKS@@ и @@TERMINATEHOOKS@@заменяются на код инициализации и деинициализации датчиков, зависящий оттого, какие датчики использовались в программе.167#include "kernel.h"#include "ecrobot_interface.h"@@BALANCER@@@@VARIABLES@@void ecrobot_device_initialize(void){@@INITHOOKS@@}void ecrobot_device_terminate(void){@@TERMINATEHOOKS@@}/* nxtOSEK hook to be invoked from an ISR in category 2 */void user_1ms_isr_type2(void){ /* do nothing */ }@@CODE@@Листинг A.1: Пример шаблона для генерации кода на C для nxtOSEK.168Заглушка @@CODE@@ заменяется на код, сгенерированный по диаграмме. По каждому блоку визуального языка генерируется свой небольшой фрагмент программы, реализующий поведение этого блока. Некоторую сложностьпредставляют конструкции, управляющие потоком исполнения — условныеоператоры и операторы цикла. В отличие от структурных текстовых языков,где операторы образуют иерархическую структуру, визуальный язык позволяетсвязывать любой блок с любым блоком, что позволяет рисовать неструктурныепрограммы, где поток управления попадает внутрь «тела» условного оператораили цикла извне.
Это равносильно использованию оператора goto в текстовыхязыках, при этом визуальный язык QReal:Robots (как и многие другие подобныеязыки) не визуализирует структурные конструкции и нарушение структурностиможет произойти незаметно для программиста. Пример неструктурной программы приведён на рисунке A.6. Генератор применяет ряд эвристик для анализапотока исполнения программы и поиска структурных условных операторов ициклов. В случае, если структурный код не может быть порождён по даннойдиаграмме (как, например, представленной на рисунке), генератор выдаёт ошибкуи не генерирует код. Такое решение было принято всвязи со спецификой применения генератора — он должен порождать по возможности качественный ичитаемый код, очевидным образом связанный с диаграммой, поскольку служитдля обучения школьников программированию.
Это исключает использование gotoв сгенерированном коде, и делает нежелательным использование техник gotoelimination [143], поскольку они предполагают раскопирование неструктурныхучастков кода. Интерпретация таких диаграмм, тем не менее, вполне возможна.Рис. A.6: Пример неструктурной программы.169A.1.7. Опыт применения QRealМетамодель языка QReal:RobotsВизуальный язык QReal:Robots создавался в метаредакторе QReal.
Метамодель одной из версий языка представлена на рисунке A.7. Как видно, всяметамодель языка умещается на одном экране. Некоторая содержательная информация на рисунке не показана, поскольку она находится в свойствах элементови редактируется через редактор свойств (например, внешний вид элемента).Метамодель всё же слишком велика, чтобы на рисунке были видны все детали,поэтому ниже приводится словесное описание изображённого.Рис. A.7: Метамодель языка QReal:Robots.Корневым элементом любой диаграммы визуального языка является узел«Диаграмма» (сущность DiagramNode в метамодели).
Она наследуется от узла «Диаграмма», объявленного в импортированной метамодели KernelDiagram,получая от неё все свойства, там объявленные. Корнем иерархии наследованияузлов языка является узел AbstractNode, который связан отношением Contains сDiagramNode, давая тем самым возможность всем своим наследникам распола-170гаться на диаграмме. AbstractNode на рисунке A.7 имеется в двух экземплярах,поскольку от него наследуются все узлы языка, и отношения наследования,соединённые с одним AbstractNode, сделали бы диаграмму трудночитаемой —это пример применения принципа разделения логической и графической моделей.Для узла AbstractNode не задано графическое представление, поэтому он небудет отображаться в палитре и не может быть использован на диаграммах.От AbstractNode наследуется несколько конкретных узлов, видимых в палитре,таких как InitialNode, FinalNode (блоки «Начало» и «Конец» соответственно),и два абстрактных узла — EngineCommand (блок управления двигателями) иSensorBlock (блок работы с датчиками).
Эти узлы абстрактные, поскольку в нихопределяются свойства, общие для всех их потомков (например, порты, к которымприменяются команды двигателей), сами они никакой смысловой нагрузки ненесут и не видны в палитре. От EngineCommand наследуется абстактный блокEngineMovementCommand, имеющий свойство Power (мощность двигателя впроцентах от максимальной), и конкретный блок EngineStop, который не требуетпараметра мощности, и поэтому не наследуется от EngineMovementCommand.
Наследники EngineMovementCommand — блоки EnginesBackward и EnginesForward,которые никаких своих дополнительных свойств не имеют. Кроме блоков, вметамодели описано одно отношение (ControlFlow, «Поток управления»), и дватипа-перечисления: SensorPort (порты, к которым может быть подключен датчик),и GuardType (тип условия над связью «Поток управления», используемого вблоках «Условие» и «Цикл»).ОбсуждениеПервые версии языка создавались в метаредакторе, первый прототип редактора был автоматически сгенерирован по метамодели в весьма короткие сроки —всего за два-три часа, из которых большая часть времени ушла на поиск иконокдля отображения блоков. Возможность быстро получить редактор языка пометамодели и удобство редактирования метамодели в метаредакторе позволилоне только существенно сократить время разработки языка, но и дать возможностьэкспериментировать, меняя свойства и внешний вид элементов.
Кроме того,метамодель оказалось довольно удобно сопровождать, причём не только авторуязыка — работа над QReal:Robots в дальнейшем во многом была передана171студентам, которые быстро разбирались в метаредакторе и могли самостоятельнодобавлять в язык новые блоки или менять существующие. Рассматривалась дажевозможность позволить самим пользователям менять свойства блоков языка(например, учителю скрыть ненужные в данный момент свойства блоков передзанятием), однако пока она не была востребована. Тем не менее, последние версииязыка используют не графическую метамодель, а её XML-представление — завремя работы над проектом XML-вариант метаязыка расширился новыми возможностями, которые не были реализованы в графическом метаязыке, например,задание групп блоков в палитре. Несмотря на это, вносить изменения в язык всёже достаточно просто для людей, занимавшихся разработкой QReal (например,студентов).Если технология сильно сократила время разработки визуального языка иредактора для него, то с созданием других средств инструментальной поддержки,таких как интерпретатора диаграмм или генератора кода, она смогла помочьв значительно меньшей степени.
Это вполне ожидаемо, поскольку эти частисодержат большое количество специфичных знаний предметной области, которыеневозможно обобщить и вынести на метауровень, сделав частью технологии.Например, робот управляется удалённо так называемыми прямыми командами,которые можно посылать по интерфейсам Bluetooth или USB, и как формированиепакета с командой, так и логика работы с каналом передачи данных должныреализовываться вручную. Такого рода работы останутся трудоёмкими прилюбом уровне поддержки со стороны DSM-платформы, поскольку очень многоетребуется изучить самому разработчику: систему прямых команд робота, APIоперационной системы робота для генерации кода в неё, работу с Bluetooth,USB, кросскомпиляцию, прошивку робота, загрузку программы на робот и т.д.Тем не менее, DSM-платформа может взять на себя часть рутинной работыи, предоставляя некий набор шаблонов и методику, организовать и направитьдеятельность автора DSM-решения.Наиболее интересной для автоматизации частью представляется генераторкода, поскольку содержит много похожего от блока к блоку кода.
Генераторсодержит неспецифичные для конкретного языка части, такие как механизманализа потока управления, и такую низкоуровневую функциональность, как кодформирования выходного файла или обхода модели. Некоторые части допус-172кают обобщение до наиболее общей задачи генерации кода (любой генератор,например, должен выводить результаты в некий файл или файлы). Некоторые,такие как анализ потока управления, могут быть применены для всех языков,имеющих в своей основе семантику сетей Петри.
По результатам проектаQReal:Robots было предложено два возможных направления автоматизации создания генераторов: вынесение общей части функциональности в библиотеку(или объектно-ориентированный каркас) разработки генераторов и созданиеинструмента, который бы позволял описывать правила генерации на специализированном языке. Первое направление было реализовано, библиотека поддержкиразработки плагинов QReal теперь содержит код, общий для всех генераторов,куда вынесена функциональность работы с шаблонами, с выходными файлами,механизм отображения ошибок генерации.Была также предпринята попытка переписать генератор QReal:Robots наязыке задания правил генерации, реализованном в QReal, но она была признананеуспешной: оказалось, что знать ещё один текстовый язык (язык описанияправил генерации) и работать со средством, порождающим из него генератор (вкотором может быть довольно большое количество своих ошибок) даже менееудобно, чем писать код на языке общего назначения наподобие C++.
Связаноэто ещё и с тем, что для C++ имеются хорошие среды разработки, тогда какна «самодельном» текстовом языке приходилось писать в довольно неудобномредакторе. В результате этого эксперимента был сделан вывод, что язык описанияправил генерации имеет смысл попробовать сделать графическим (несмотря нато, что он должен активно работать с текстом), и использовать в таком случае всевозможности самой DSM-платформы. Либо же DSM-платформа помимо созданияинструментальных средств для визуальных языков должна позволять создаватьудобные инструментальные средства и для текстовых языков, чтобы предметноориентированные текстовые языки могли эффективно применяться как в DSMрешениях, так и для нужд самой DSM-платформы так же, как применяются сейчасвизуальные языки.
Оба эти направления приводятся здесь, как возможности длядальнейшего исследования, и выходят за рамки данной работы — в QReal как намомент создания DSM-решения QReal:Robots, так и на момент написания этойдиссертации для написания генераторов используется язык C++.173Вторая возможная цель автоматизации создания дополнительных инструментальных средств для языка — интерпретатор диаграмм. В QReal:Robots интерпретатор был написан целиком на C++, и, как и в случае с генератором, усилия наего разработку удалось бы значительно сэкономить, если бы существовала библиотека (или каркас) с общим для всех интерпретаторов кодом. Сам процесс интерпретации как последовательности передачи токенов исполнения и выполнениянеких действий в узле, получившем токен, общий для всех языков с семантикой,основанной на сетях Петри, поэтому может быть реализован языконезависимымобразом.
Действия, выполняемые в узлах, сильно языкозависимы (не все, блокиветвления, параллельного исполнения, начала и конца программы могут присутствовать во многих языках и иметь одинаковую семантику). Специфичные дляконкретного языка действия можно реализовывать на языке общего назначения,либо же на каком-либо интерпретируемом языке общего назначения, наподобиеPython или F# [76]. Использование интерпретируемых языков имеет весомое преимущество — действия можно модифицировать без пересборки интерпретатора,это могут делать в том числе и сами пользователи DSM-решения. Недостатоктакого подхода очевиден: на всех машинах, где используется DSM-решение,требуется наличие интерпретатора выбранного языка. Поскольку на данныймомент задача интерпретации достаточно сложных диаграмм возникала только вQReal:Robots, задача автоматизации создания интерпретаторов в рамках проектаQReal серьёзно не рассматривалась, и соображения выше приведены здесь каквозможные направления дальнейшей работы.A.1.8.
ЗаключениеПроект QReal:Robots, по мнению автора, полностью доказал состоятельностьпредметно-ориентированного подхода и работоспособность подходов, реализованных в проекте QReal и описываемых в данной работе. В результате проектас помощью DSM-платформы была создана система визуального программирования, которая оказалась не хуже разработанных вручную, при этом время наразработку визуального редактора для этой системы удалось с помощью DSMплатформы сократить в несколько десятков раз по сравнению с разработкойредактора с такой же функциональностью вручную. Однако выигрыш во временипри разработке и доведении до отчуждаемого продукта всей системы в целом174оказался не таким значительным, как при разработке визуального редактора— многие задачи оказались неавтоматизируемы в принципе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
