Диссертация (Методы и средства разработки графических предметно-ориентированных языков), страница 37

Код из комментария при синтезе добавляется к сгенерированному описанию процесса, таким образом мы получаемполностью специфицированный арбитр 2 к 1, который может быть использованкак фактический параметр функтора Arbiter4to1 (на это указывает отношениегенерализации, связывающее DynamicArbiter и безымянный тип процесса — формальный параметр функтора). Про процесс Arbiter4to1 мы указали пока только то,что он является функтором (готов использовать любой процесс, поддерживающийинтерфейс арбитра 2 к 1, который мы определили с помощью безымянного типа195процесса), и указали, что у него есть 4 входа и один выход — то есть просто«нарисовали» условие задачи.Диаграмма отображения портовДиаграмма отображения портов рисуется для отдельного процесса и используется для отображения связей между входными и выходными портами вложенныхпроцессов того процесса, для которого рисовалась диаграмма. Таким образом, этадиаграмма фактически является графической нотацией для структурного уровняязыка системы CoolKit.

Синтаксис с незначительными изменениями совпадает ссинтаксисом диаграммы составных структур UML. На диаграмме изображаютсяпроцессы и их порты (все порты входов и выходов), связи между портами,внутри процессов могут находиться вложенные процессы. Важно различие между процессом верхнего уровня — процессом, относительно которого рисуетсядиаграмма, и вложенными процессами. Вложенные процессы на самом делеявляются экземплярами процессов, имеют имя и тип.

Процесс верхнего уровняимеет только тип. Пример нотации изображён на рисунке A.16. Вернёмся кнашему примеру с арбитром 4 к 1. Диаграмма отображения портов для этогопримера выглядит так, как показано на рисунке A.17.Здесь мы видим процесс верхнего уровня Arbiter4to1 — без имени, но с типоми с формальным параметром функтора. Arbiter4to1 имеет 4 входных порта и 1выходной, их типы здесь уже можно не указывать, они были на диаграмме типовпроцессов, которую мы нарисовали ранее. Процесс имеет три вложенных процесса A12, A34 и A1234 типа D, который, как следует из диаграммы типов процессов,описывает процессы, имеющие два входа и один выход. Если мы считаем, что вкачестве параметра функтора передаётся арбитр 2 к 1, изображённое на рисункесоединение портов решает задачу.ГенерацияГенерация в язык системы CoolKit проходит довольно очевидным образом,поскольку графический и текстовый языки имеют одинаковую модель представления аппаратного устройства.

Скелеты описаний процессов генерируются подиаграмме типов процессов, потом они дополняются вложенными процессами иконструкциями, описывающими связь портов по диаграмме отображения портов,196потом они дополняются реализацией, которая так или иначе представлена втекстовом виде на диаграмме — в виде комментария или в виде неотображаемогоатрибута процесса. В результате получается полная программа на языке системыCoolKit, готовая к дальнейшей трансляции в VHDL и далее — в эмулятор илиспецификацию устройства.При генерации считается, что одноимённые однотипные сущности в одномпространстве имён представляют собой одну сущность.

То есть, например, еслина одной диаграмме описан процесс с одним входом, а на другой диаграммеописан процесс с тем же именем и другим входом, будет сгенерирован одинпроцесс с двумя входами. Такой подход позволяет изображать на каждой диаграмме только существенные для неё части системы, хотя и может привести кнекоторой сложности для понимания набора диаграмм в целом.

Предполагается,что у средства визуального моделирования существует возможность удобнымспособом предоставить пользователю информацию о невидимых на диаграммеэлементах. Есть некоторые тонкости с тем, что разные формально сущности наразных диаграммах представляют собой одну логическую сущность, например,процесс на диаграмме типов процессов и процесс на диаграмме отображенияпортов. Такие сущности всё же должны считаться генерацией однотипными иобъединяться в одну сущность. Например, двух ранее приведённых диаграмм,описывающих реализацию арбитра 4 к 1, достаточно, чтобы сгенерировать кодна языке системы CoolKit, который приведён в листинге A.4.Для того, чтобы получить исполнимый код, нужно создать экземпляр процессаArbiter4to1, использующий в качестве параметра процесс DynamicArbiter.

Дляэтого достаточно нарисовать диаграмму, изображённую на рисунке A.18.Эта диаграмма породит кодprocess Arbiter = Arbiter4to1(DynamicArbiter);Этот код вместе с приведённым ранее кодом может быть синтезирован иисполнен на эмуляторе.A.3.5. ЗаключениеВ результате работы над технологией QReal:Hascol было создано два языка,с помощью которых описывалась структурная часть системы. Технология не197process DynamicArbiter =beginin one(uint(2), uint(8));in two(uint(2), uint(8));out res(uint(8));group {one(prio1, data1) and prio1 >= prio2,two(prio2, data2) and prio1 < prio2{send res (if prio1 >= prio2 then data1 else data2 fi)}one(_, ddata) {send res (ddata)}two(_, ddata) {send res (ddata)}}endprocess Arbiter4to1 (D : beginin one(uint(2), uint(8));in two(uint(2), uint(8));out res(uint(8));end)=beginin i1 (uint(2), uint(8));in i2 (uint(2), uint(8));in i3 (uint(2), uint(8));in i4 (uint(2), uint(8));out res (uint(8));process A12 = D with one = i1, two = i2, res = A1234.one;process A34 = D with one = i3, two = i4, res = A1234.two;process A1234 = D with res = res;endЛистинг A.4: Реализация арбитра 4 к 1 на языке HaSCoL.198была доведена до промышленного использования, полученные результаты нигдене публиковались, связано это с недостаточной зрелостью базовой технологииQReal на момент работы над QReal:HaSCoL.

Однако проблемы, возникшие приразработке, во многом послужили мотивацией для реализации тех возможностейметатехнологии QReal, которые представляются в данной работе. Кроме того,визуальный язык QReal:HaSCoL далее использовался как пример для апробацииразличных новых возможностей QReal, например, «метамоделирования на лету».С точки зрения введённой в данной работе классификации созданные языкиявляются статическими текстовографическими языками. В данном случае использование текстовой нотации не так осложняет понимание диаграмм, как вслучае QReal:Ubiq (раздел A.2), поскольку текстовая и графическая части невзаимозаменяемы: структурная часть системы целиком описывается графически,поведенческая — целиком текстово. Были предприняты попытки использоватьдиаграммы активностей языка UML 2.0 для задания и поведенческой части вграфическом виде, но в результате получались громоздкие и трудночитаемыедиаграммы, поэтому было принято решение поведенческую часть задавать втекстовом виде.В отличие от всех последующих языков на базе платформы QReal, языкиQReal:HaSCoL создавались на базе метамодели UML 2.0.

Это было сделано длятого, чтобы строго формализовать язык и сделать возможной его реализацию нетолько на базе QReal (впрочем, таких попыток не предпринималось), а такжеопробовать на реальном примере такой подход к разработке синтаксиса языка.Результаты показали, что переиспользование метамодели UML действительнопозволяет сэкономить много усилий (потребовалось ввести всего две-три новыесущности на каждый язык из семейства), однако от разработчика требуетсяхорошо ориентироваться в метамодели UML, что само по себе весьма непросто.Стандарт UML достаточно объёмен, а метамодель весьма запутанна (особуюсложность для читаемости метамодели представляет активное использованиеопераций объединения пакетов PackageMerge и использование сущностей содинаковыми именами в разных пакетах).

Как кажется, затраты на изучениеметамодели UML превышают выгоду, получаемую от переиспользования этойметамодели, так что разрабатывать новый предметно-ориентированный язык «снуля» с использованием метаязыка выбранной DSM-платформы более оправдан-199но, чем перед созданием языка специально изучать метамодель UML. Наличиеэффективных инструментальных средств, помогающих разобраться в большихметамоделях наподобие UML и автоматизировать переиспользование фрагментовметамодели, как кажется, смогло бы изменить ситуацию, однако на данный момент такие средства не распространены, и создание таких средств представляетсяинтересным направлением дальнейших исследований.200Рис.

A.8: Задание интерфейса приложения и переходов между экранами вQReal:Ubiq.Рис. A.9: Структурированный классификатор UML 2.201Рис. A.10: Пример нотации профиля для SystemC.Рис. A.11: Метамодель диаграммы типов процессов.202Рис. A.12: Нотация процессов.Рис. A.13: Нотация функторов.Рис. A.14: Применение функтора.203Рис.