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

Тип процесса по умолчанию получается изспецификации процесса, тип можно указать и явно, это используется, например,для описания свойств параметров функторов.Функтор — это процесс, параметризованный другим процессом. Примерописания функтора приведён в листинге A.3.Процесс Wrapper параметризован процессом P типа Proc. Применение функтора выглядит так:process W = Wrapper(aProc);A.3.3. Существующие средства визуального описанияаппаратных системСамый известный из существующих визуальных языков, UML 2, создавалсяс учётом необходимости описывать аппаратные средства. В версиях UML 1.xспециальных средств для описания аппаратных систем не было, поэтому приходилось создавать профили UML, например, UML-RT [72].

В UML 2 этот пробелбыл заполнен, в язык было введено понятие «структурированный классификатор», который может содержать внутри себя набор частей, соединённых междусобой соединителями. Взаимодействие структурированных классификаторов свнешним миром и внутренними частями происходит исключительно через порты.Порт — это точка взаимодействия со строго определённым интерфейсом. Одинструктурированный классификатор может иметь несколько портов, а также имеетвозможность определить, на какой из портов пришёл запрос.

Запросы, прихо-191дящие на порты, могут быть обработаны непосредственно объектом-хозяиномпорта или переданы на порт какой-либо его части. Каждый порт имеет наборпредоставляемых им интерфейсов и набор интерфейсов, требуемых от внешнейсреды. Пример нотации представлен на рисунке A.9.Для задания внутреннего поведения элементов системы в UML 2 обычноиспользуется диаграмма конечных автоматов. Каждый структурированный классификатор может иметь связанный с ним конечный автомат, который описываетреакцию на события, приходящие на его порты.Помимо «чистого» UML 2 используются и специальные профили UML,предназначенные для использования с текстовыми языками (подход, весьмаблизкий к предлагаемому). Пример такого профиля, представленный в работе [70]— профиль UML для языка SystemC. SystemC [3] — язык проектирования уровнясистемы, основанный на C++ и поддерживаемый группой крупных компаний.Система в SystemC состоит из модулей, каждый модуль может содержатьпеременные, порты для взаимодействия с окружением и процессы, реализующие функциональность модуля.

Процессы исполняются параллельно и могутреагировать на события. Связь между модулями осуществляется с помощьюпортов, которые предоставляют модулям доступ к каналам. Каналы бываютпримитивными и иерархическими: иерархический канал — тоже модуль, имеетсвои процессы и может иметь доступ к другим каналам.Профиль UML для SystemC логически разделён на 3 части.1. Структуры и коммуникации — определяет стереотипы для базовых строительных блоков SystemC. Эти стереотипы представляют модули, порты,интерфейсы и каналы и используются на различных диаграммах UML,например, на диаграммах классов и диаграммах композитных структур.2. Поведение и синхронизация — определяет стереотипы для спецификацииповедения процессов SystemC.

Эти стереотипы используются в диаграммахсостояний UML.3. Типы данных — представляет типы данных SystemC.Пример нотации профиля UML для SystemC представлен на рисунке A.10.Как видно из обзора, идея визуального моделирования аппаратного обеспечения не нова, при этом наибольшее внимание уделяется языку UML (по-видимому,192как наиболее распространённому визуальному языку). При этом, существующиеязыки пытаются целиком специфицировать систему графическими средствами,что зачастую приводит к весьма громоздким диаграммам.A.3.4.

Предлагаемый набор визуальных языковОсновные принципы, в соответствии с которыми разрабатывалась нотация,таковы.1. Модель должна быть исполняемой, то есть позволять синтезировать код наязыке системы CoolKit без необходимости ручной корректировки результатов. Пригодная для промышленного использования технология должнапозволять программисту получать готовую низкоуровневую спецификациюсистемы или эмулятор, действуя в одной среде разработки и, желательно, содним представлением системы.2. Графическими примитивами должны быть представлены только те элементы программы, которые наиболее выгодно представлять графически.Остальная необходимая для синтеза информация должна быть представленана визуальной модели в текстовой форме.

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

Для формализации языка используется метамоделирование наметаязыке MOF — синтаксис графических конструкций языка описан с помощьюдиаграмм UML. Метамодель языка построена на метамодели ядра и некоторыхдиаграмм UML, таким образом, язык лишь незначительно отличается от UML,193и его синтаксис и семантика интуитивно понятны специалистам, занимающимся визуальным моделированием. Кроме того, переиспользование метамоделиUML позволило сэкономить массу усилий при формализации языка. Одним изполученных результатов стало понимание того, что формализация предметноориентированных языков программирования может быть существенно упрощенаблагодаря переиспользованию некоей стандартной метамодели, например, UML.Для спецификации системы в нашем языке используется два вида диаграмм— диаграмма типов процессов и диаграмма отображения портов. Заметим, чтомы избежали необходимости использовать диаграммы автоматов для описанияповедения системы — эту роль выполняют текстовые блоки на целевом языке.Диаграмма типов процессов базируется на диаграмме классов UML, а диаграммаотображения портов — на диаграмме композитных структур.Диаграмма типов процессовДиаграмма типов процессов используется для задания основных структурныхсвойств и отношений процессов, составляющих пакет или приложение.

Надиаграмме изображаются сами процессы, их входы и выходы, отношения вложенности, отношения генерализации и функторы. Заметим, что на этой диаграмме нерисуются обработчики событий и могут не рисоваться ресурсы процесса (списокресурсов процесса может быть неполным, из того, что ресурс не изображённа диаграмме, нельзя делать вывод, что он не описан в процессе). Некоторыевложенные процессы тоже могут быть опущены на этой диаграмме, если это неповлияет на корректность модели.

Часть метамодели диаграммы представлена нарисунке A.11.Пример изображения вложенных процессов представлен на рисунке A.12. Каквидно из примера, нотация перечисляет ресурсы, входы и выходы процессов в таком виде, в каком они были в языке системы CoolKit. По-настоящему графическиздесь изображаются только отношения использования одного процесса внутридругого или вложенности процессов (т.е. когда один процесс описан непосредственно внутри другого). Заметим, что вложенный процесс может не иметь имени— тогда оно просто не отображается на диаграмме. Поскольку вложенные илииспользуемые процессы являются деталями реализации объемлющего процесса,они могут не рисоваться на диаграмме.194Существенную выгоду от использования этого типа диаграммы можно получить при использовании в программе функторов.

Пример нотации объявленияфункторов приведён на рисунке A.13.В частности, из-за особенности нотации, которую можно видеть на примере,было принято решение не использовать диаграммы классов UML. Нотация отражает возможность языка системы CoolKit описывать тип процесса — формальный параметр функтора прямо в месте описания формального параметра. Вынесение типов параметров в отдельные графические сущности позволяет сделатьотношения между процессами — формальными или фактическими параметрамифункторов гораздо более наглядными. Применение функтора изображается так,как показано на рисунке A.14.Для того, чтобы проиллюстрировать применение диаграммы типов процессов, рассмотрим содержательный пример — задачу об арбитре динамическихприоритетов 4 в 1 из неопубликованного описания языка HaSCoL.

Задача формулируется следующим образом: на один из четырёх входов поступают данные,первый параметр пришедших данных — приоритет. Если в одном такте данныепоступили на несколько входов, на выход выдаются данные с наибольшимприоритетом, остальные входы объявляются неготовыми. Если приходит толькоодно сообщение, оно отправляется на выход.Следуя оригинальному решению поступим следующим образом — сначаланапишем арбитр динамических приоритетов 2 в 1 (с двумя входами и однимвыходом), затем создадим арбитр-функтор 4 в 1, использующий 3 арбитра 2 в 1,который и решит задачу (см. рисунок A.15).В комментарии — код процесса DynamicArbiter на языке системы CoolKit,описывающий реализацию арбитра 2 к 1.