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

Блоки языка включали в себя объявления и изменения значенийпеременных и списков, команды отрисовки, условные операторы, подпрограммы.Также был реализован язык, позволяющий описывать пользовательский интерфейс генерируемого приложения и правила переходов между экранами, примертакой диаграммы показан на рисунке A.8.Результатом реализации модельного примера (в качестве которого былавыбрана игра «Крестики-нолики») стало то, что диаграммы переходов междуформами оказались полезны сами по себе, поскольку хорошо визуализируютпереходы, которые могут быть неочевидны в коде.

Кроме того, по ним простосгенерировать скелет приложения, а если сложная логика не требуется (например,приложение-визитка), то и приложение целиком. Однако задание сложной логикибез кода на целевом языке привело к ещё более громоздким диаграммам, которые185хоть и проще для понимания, чем диаграммы из прототипа, полученного напервом этапе работы, но всё же менее удобны, чем ручное кодирование.A.2.6. ЗаключениеПервый этап проекта разрабатывался для мастер-класса в рамках конференции FRUCT 20114 , где был успешно продемонстрирован, а на самой конференциибыл сделан доклад [8]. На мастер-классе демонстрировалась разработка приложения для отображения данных с веб-камеры, аудитории был показан процесссоздания и генерации логики клиентской части.

Технология показалась весьмапривлекательной авторам Ubiq Mobile, поэтому работа над ней была продолженаи после выступления.С точки зрения исследования визуальных языков результаты проекта оказались менее однозначными: конечного ответа на вопрос «возможно ли эффективноиспользовать визуальные языки вместо текстовых при решении достаточнообщих задач» получено не было. С одной стороны, визуальная технологиядала очевидный выигрыш в том, что уменьшила объём необходимых для программирования знаний, с другой стороны, для некоторых задач, возникающихпри разработке мобильного приложения, использование текстовых языков покаэффективнее.Работа над этим проектом поставила новые вопросы, требующие исследования.1.

Полноценная реализация редактора пользовательского интерфейса с визуализацией переходов между формами (или экранами) средствами DSMплатформы. Для этого различные элементы пользовательского интерфейса,такие как поля ввода, кнопки, выпадающие списки и т.д. должны бытьполноправными частями формы элемента языка.2. Поддержка работы с семействами визуальных языков, каждый из которыхможет уточнять более общий язык под конкретную задачу. Таким образомможет быть реализована схема с настраиваемыми элементами из раздела A.2.5 — создать общий язык разработки мобильных приложений, от него4Программа FRUCT 2011, URL: http://fruct.org/node/5016 (дата обращения 08.02.2015)186породить язык задания игр с полем, от него — язык, содержащий специфические блоки для игры «Морской бой».

Это не снимает всех проблем,перечисленных в разделе A.2.5 касательно этой схемы, но представляетсялогичным развитием идей DSM-подхода.A.3. Среда разработки аппаратуры QReal:HaSCoLA.3.1. ВведениеТехнология QReal:HaSCoL была исторически первой технологией, разработанной автором на платформе QReal, и именно опыт её разработки во многомопределил направления дальнейших исследований и, в итоге, полученные вданной диссертации результаты. В частности, в ходе этой работы возниклапотребность в визуальном метаредакторе. Данная технология не используетмногих описанных в этой работе возможностей платформы QReal, посколькуна момент работы над ней эти возможности ещё не были реализованы, кроме того, сведения, приведённые в обзоре аналогичных подходов, могли устареть. Это не представляется критичным недостатком, поскольку основная цельдальнейшего изложения — продемонстрировать пример разработки предметноориентированного визуального языка, причём для данной работы более важныметодологические аспекты, чем специфика предметной области или особенностиреализации конкретной DSM-платформы.

В этом плане предлагаемый примеринтересен тем, что язык создавался и был строго формализован как расширениеметамодели языка UML 2.0, поэтому данный опыт может быть использован длясравнения с более «легковесными» подходами, применявшимися в примерах изразделов A.1 и A.2.A.3.2. Постановка задачиРазличные встроенные устройства играют большую роль в нашей жизни,однако задача их разработки всё ещё остаётся сложной и трудоёмкой. В 80-х годахдвадцатого века появились языки Verilog [97] и VHDL [94], которые и по сей деньостаются фактическим стандартом в деле разработки аппаратного обеспечения.Эти языки позволяют описать устройство аналогично коду обычной программы,187их синтаксис похож на синтаксис традиционных языков программирования.

Онипозволяют синтезировать описание разрабатываемого аппаратного обеспечения,пригодное для производства, или произвести эмуляцию.Тем не менее, данные языки заставляют описывать систему в низкоуровневыхтерминах, поэтому актуальна задача разработки новых технологий с болеевысоким уровнем абстракции. Визуальные методы разработки в данной предметной области даже более применимы, чем в области разработки ПО, посколькуаппаратное обеспечение традиционно описывалось различными чертежами исхемами. Однако же, в силу высокой (и постоянно растущей) сложности аппаратного обеспечения, средство визуального моделирования не может быть просторедактором электронных схем, а должно само поддерживать высокоуровневыеконцепции.

Ещё одним важным требованием, накладываемым на такое средство,является исполнимость модели. Средство должно иметь возможность синтезировать описание устройства в виде, пригодном для использования промышленнымоборудованием при производстве, и генерировать эмулятор устройства, позволяющий вести отладку, тестирование и оценку производительности, не прибегая ксозданию дорогостоящего прототипа. Все эти сложности затрудняют разработкуновых визуальных технологий.На кафедре системного программирования математико-механического факультета СПбГУ разрабатывается текстовый язык разработки аппаратных системHaSCoL (Hardware-Software Codesign Language) [7] гораздо более высокогоуровня, чем VHDL или Verilog. Перед автором данной диссертации была поставлена задача разработать визуальную технологию, которая бы использовалаязык HaSCoL как целевой язык для генерации и позволяла бы проектироватьаппаратуру в высокоуровневых терминах этого языка.

Это дало бы возможностьиспользовать инструментальные средства HaSCoL для создания как спецификации устройства для конфигурации FPGA5 или производства, так и для генерациипрограммного эмулятора. С другой стороны, визуальная технология должна былаповысить удобство программирования на языке HaSCoL, а поскольку этот языкновый, это могло бы позитивно сказаться на эффективности его внедрения. Крометого, использование высокоуровневого языка в качестве целевого для генерациисвело бы к минимуму затраты на анализ предметной области при разработке5Field-Programmable Gate Array188DSM-решения, поскольку большая часть этой работы уже была выполнена приразработке текстового языка.Язык HaSCoL описывает систему в терминах исполняемых параллельнообработчиков сигналов. Обработчики объединены в процессы — сущности,инкапсулирующие в себе ресурсы (данные), обработчики сигналов и другиепроцессы, и имеющие входы и выходы.

Обработчик представляет из себя последовательность однотактовых шагов, выполняющихся, если некоторые условия(получение сообщения, состояние ресурсов процесса) истинны. Обработчикимогут начинать своё исполнение на каждом такте, на котором выполнены условияего старта, вне зависимости от того, выполняются они уже или нет. Примерописания процесса (из неопубликованного описания языка HaSCoL 2008 года)приведён в листинге A.2.Процесс имеет два входа (one, two) с двумя параметрами и выход res, возвращающий значение типа uint(8).

Конструкцией group три обработчика объединеныв группу, перед фигурными скобками записано условие, при истинности которогообработчик начнёт работу, внутри фигурных скобок — тело обработчика. Вусловиях могут участвовать проверки наличия данных на входах, логические выражения с участием входных данных и локальных данных процесса. Конструкцияsend в теле обработчика — посылка сигнала на указанный выход. Входы и выходымогут также иметь несколько портов, каждый порт может быть связан с очередьюсообщений.

Например,in InputData (int(16))[A[1], B];определяет вход с одним параметром и двумя портами, при этом размер очередипорта A — 1, размер очереди порта B — 0.Для поддержки структурной декомпозиции процессов в язык был введёнструктурный уровень. Структурные конструкции позволяют отображать входыобъемлющего процесса на порты входов вложенного, и выходы вложенногопроцесса на выходы объемлющего или входы вложенного, позволяя такимобразом структурно декомпозировать процессы на наборы взаимодействующихвложенных подпроцессов.Каждый процесс имеет свой тип, задаваемый явно или неявно. Тип процесса— перечень его входов и выходов с указанием типов их аргументов. Над типами189process 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)}}endЛистинг A.2: Пример описания процесса на языке HaSCoL.190process Wrapper (P: Proc) =beginprocess X = P;process Y = P;...endЛистинг A.3: Пример описания функтора на языке HaSCoL.процессов определено отношение структурного сабтайпинга — неформальноговоря, процесс A имеет тип, являющийся подтипом типа процесса B, если Aможно везде использовать вместо B.