Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Разработка метамоделирования "на лету" в системе QReal

Птахина А.И., студентка 4 курса кафедры системного программирования СПбГУ, alinaptakhina@gmail.com

Аннотация

визуальный программирование язык qreal

В статье описывается подход к разработке ПО, основанный на использовании визуального программирования и позволяющий быстро и легко модифицировать визуальный язык программирования. Под метамоделированием ”на лету” подразумевается возможность добавлять новые элементы языка, удалять и изменять существующие прямо в процессе разработки, а также возможность создать свой собственный язык “c нуля”. Приводится описание реализации такого подхода в системе QReal - проекте научно-исследовательской группы кафедры системного программирования СПбГУ, в виде прототипа, включающего в себя все перечисленные возможности модификации визуального языка.

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

На практике часто возникают задачи, при автоматизации решений которых естественным образом возникает необходимость описывать сложные, нетривиальные структуры. Для этого довольно часто возникает потребность видоизменения существующих или добавления новых сущностей языка. Однако визуальные редакторы, в основном, предоставляют пользователю фиксированный набор диаграмм и сущностей. Это ограничивает пользователя, заставляя думать в терминах конкретной диаграммы, а не в терминах предметной области. И, как следствие, приводит к тому, что пользователь отдает предпочтение простому листу бумаги и ручке и сначала пытается нарисовать эскиз на бумаге с помощью абстрактных кругов и стрелок, а потом думает, как его полученное решение перенести в визуальный редактор. Как правило, этот процесс длится долго: нужных элементов языка нет, а добавление новых и изменение существующих затруднительно. Существуют специальные инструментальные средства, позволяющие быстро создавать визуальные языки и редакторы для них, они называются DSM-платформами.

Безусловно, свести работу с CASE-средством до уровня бумаги и ручки не получится, однако хочется предоставить пользователю большую свободу действий. Хочется, чтобы пользователь мог сам создать нужный для его предметной области язык без особых усилий. Ведь решение любой задачи проще всегда начинать с эскиза, с простых элементов, которые в дальнейшем можно детализировать и уточнять в зависимости от потребностей предметной области. Предлагаемый нами подход, позволяющий быстро и легко расширять систему, мы будем называть метамоделированием "на лету". Данная работа базируется на идеях и результатах, полученных в рамках дипломной работы Е.И.Такун [3].

Интерпретация метамоделей

Визуальные языки в современных DSM-платформах, как правило, задаются с помощью метамоделей, то есть моделей синтаксиса языка. Они описывают, какие элементы могут находиться на диаграмме, какие свойства есть у этих элементов, и как элементы могут быть связаны друг с другом. Существует два принципиально разных подхода по работе с метамоделью. Один из них заключается в том, что описание языка может быть сгенерировано как код на текстовом языке программирования по метамодели. Второй - метамодель может интерпретироваться во время работы DSM-платформы. Реализация метамоделирования “на лету” возможна только в случае интерпретируемой метамодели. Основное отличие от генеративного подхода заключается в том, что интерпретация моделей происходит непосредственно во время работы приложения, в то время как генерация обязана завершиться до начала работы. Интерпретатор метамоделей в системе QReal был реализован в рамках моей курсовой работы 3-го курса [2].

Класс интерпретатора для получения информации о сущностях языка имеет доступ к репозиторию с сохраненной метамоделью. Он позволяет извлекать из репозитория все необходимые данные. Для реализации метамоделирования "на лету", класс интерпретатора был расширен функциями добавления и изменения информации.

Режим интерпретируемой диаграммы

В QReal интерфейс пользователя состоит из:

· cцены - на ней рисуются диаграммы;

· палитры - на ней располагаются элементы визуальных языков;

· обозревателя логической модели - в его древовидном представлении отображается логическая структура системы;

· обозревателя графической модели - он древовидно показывает структуру диаграмм, которыми логическая структура визуализируется;

· редактора свойств элементов.

Метамодели в системе QReal можно создавать и изменять при помощи встроенного метаредактора. Он представляет собой удобный инструментарий, позволяющий задавать сущности языка и устанавливать между ними отношения. Созданную в метаредакторе метамодель можно сохранить в формате сохранения QReal.

Чтобы перейти в режим интерпретируемой диаграммы, достаточно при запуске системы QReal выбрать в стартовом диалоге пункт меню “Открыть интерпретируемую диаграмму” (см. рис 4) и загрузить файл с сохраненной метамоделью.

Рис 4: Стартовый диалог QReal

В случае, если не имеется сохраненной метамодели, или хочется создать свой собственный визуальный язык, можно воспользоваться пунктом меню “Создать интерпретируемую диаграмму”. В открывшемся окне ввода необходимо ввести имя создаваемой диаграммы. После этого будет создана диаграмма и редактор с одноименным названием. После этого диаграмма не будет содержать больше никакой информации. Палитра элементов и обозреватели логической и графической модели, а соответственно и редактор свойств QReal, будут пусты, поскольку они пока не содержат элементов. Далее можно переходить к созданию новых элементов диаграммы. Полученную с помощью метамоделирования «на лету» метамодель можно сохранить и далее уточнять и детализировать в метаредакторе. В нем можно задать более сложные отношения между элементами: наследование, связи и пр. После внесения изменений в метамодель ее можно снова использовать в режиме метамоделирования «на лету». Напишем подробнее об операциях, позволяющих изменять метамодель «на лету».

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

Удаление элемента несколько сложнее технически, поскольку уже созданная диаграмма может использовать удаляемый элемент. В этом случае все экземпляры элемента удаляются с диаграммы, при этом, если элемент содержал в себе какие-то другие элементы, то и они тоже будут удалены. Кроме того, удаляемый элемент может находиться в некоторых отношениях с другими элементами с точки зрения метамодели, например, от него могут наследоваться другие элементы. В этом случае наследующиеся от него элементы теряют все унаследованные свойства удалённого элемента. При этом сам элемент удаляется из репозитория, перед этим интерпретатор анализирует все связи этого элемента в метамодели и вносит необходимые изменения.

Редактирование свойств элемента доступно в окне, изображенном на рисунке 5. С его помощью элементу можно добавлять новые свойства, удалять и изменять существующие. Отметим, что модификация унаследованного свойства запрещена, а при редактировании свойств элемента-родителя соответствующие изменения автоматически происходят и в свойствах элемента-наследника.

Как ни странно, в связи с особенностью архитектуры системы QReal, свойство у элемента проще удалить, чем добавить новое. Это связано с тем, что существующие элементы нового свойства не имеют. При последующих обращениях к элементу система попытается получить значение этого свойства, возникнет ошибка. В связи с этим было принято решение запретить пользователю добавлять свойства элементу в случае, если хотя бы одно его представление или представление его элементов-наследников присутствует на сцене, либо в обозревателях графической или логической модели. Однако добавлять новые свойства и изменять существующие в такой ситуации, конечно, можно.

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

Рис 5: Список свойств элемента Рис 6: Редактирование выбранного свойства

У пользователя есть возможность изменить графическое изображение элемента: загрузить существующий рисунок, сохраненный в графическом формате SVG, создать свой собственный с помощью имеющегося в QReal инструментария. Новое изображение будет применено как ко всем представителям данного элемента на сцене, так и к его иконкам в палитре и в обозревателе графической и логической модели.

Применение метамоделирования “на лету”

Рассмотрим, как языки визуального моделирования применяются в разработке аппаратного обеспечения. Создадим визуальный язык для HaSCol [4]. Проведем апробацию метамоделирования “на лету” на задаче об арбитре динамических приоритетов 4 в 1. Сама задача формулируется следующим образом: “На один из четырех входов поступают данные, первый параметр пришедших данных - приоритет. Если в одном такте данные поступили на несколько входов, на выход выдаются данные с наибольшим приоритетом, остальные входы объявляются неготовыми. Если приходит только одно сообщение, оно отправляется на выход”.

Решать поставленную задачу будем в соответствии с оригинальным решением: сначала напишем арбитр динамических приоритетов 2 в 1 (с двумя входами и одним выходом), затем создадим арбитр-функтор 4 в 1, использующий 3 арбитра 2 в 1, который и решит задачу. Для нас принципиально то, что мы взяли известную задачу, с существующим уже решением и не придумываем нового, а просто реализуем известное при помощи метамоделирования “на лету”. Анализируем сущности, необходимые для получения решения и строим их прямо в процессе разработки.

В HaSCol для моделирования аппаратных систем используется понятие процесс - сущность, инкапсулирующая в себе ресурсы (данные), обработчики сигналов и другие процессы, и имеющая входы и выходы (порты). Процесс имеет тип, характеризующий его входы и выходы, процессы могут наследоваться друг от друга. Перенесем данное понятие в визуальный язык, добавив сущности “процесс” и “порт”. И начнем рисовать диаграмму типов процессов. В ходе рисования мы понимаем, что нам нужно выразить наследование процессов, кроме того оказывается удобным понятие языка HaSCol “функтор”, т.е. процесс параметризованный другим процессом. Добавим эти понятия в язык. Для того, чтобы получиться полноценную работающую программу, надо добавить реализацию процессам. Поскольку мы пока не хотим создавать отдельный язык для задания логики реализации, будем писать реализацию в текстовом виде, для чего добавим соответствующий элемент. Результаты этой работы приведены на рисунке 7.

Рис 7: Диаграмма типов процессов для задачи "Арбитр 4 в 1”

Аналогичным образом нарисуем диаграмму отображения портов для задачи "Арбитр 4 в 1", указанную на рисунке 8.

Рис 8: Диаграмма отображения портов для задачи "Арбитр 4 в 1”

Здесь мы видим процесс верхнего уровня Arbiter4to1 - без имени, но с типом и с формальным параметром функтора. Arbiter4to1 имеет 4 входных порта и 1 выходной, их типы здесь уже можно не указывать, они были на диаграмме типов процессов, на предыдущем слайде. Процесс имеет три вложенных процесса А12, А34 и А1234 типа D, который, как следует из диаграммы типов процессов, описывает процессы, имеющие два входа и один выход. Если мы считаем, что в качестве параметра функтора передается арбитр 2 в 1, изображенное на рисунке соединение портов решает задачу.

Заключение

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

В рамках данной концепции было произведено объединение редактирования модели и метамодели, что избавило пользователя от необходимости мыслить в терминах двух абстракций. Теперь уровень метамодели скрыт от пользователя, что позволяет ему полностью сконцентрироваться на задаче, а не на создании инструментария. Полученное решение было апробировано на реальной задаче.

Литература

1. Д.Кознов, Основы визуального моделирования. // Бином. Лаборатория Знаний, Интернет-Университет Информационных Технологий - 2008.

2. А.И.Птахина. Интерпретация метамоделей в metaCASE-системе QReal, курсовая работа, СПбГУ, кафедра системного программирования, 2012. http://se.math.spbu.ru/SE/YearlyProjects/2012/YearlyProjects/2012/345/345_Ptakhina_report.pdf [дата просмотра: 08.04.2013]

3. Е.И.Такун. Реализация режима быстрого прототипирования в CASE-системе QReal, дипломная работа, СПбГУ, кафедра системного программирования, 2011

http://se.math.spbu.ru/SE/diploma/2011/Takun%20Evgenija%20-%20text.doc [дата просмотра: 08.04.2013]

4. Dmitri Boulytchev, Oleg Medvedev. Hardware Description Language

Based on Message Passing and Implicit Pipelining // EWDTS '10 Proceedings of the 2010 East-West Design & Test Symposium. - 2010. -Pages 438-441

Размещено на Allbest.ru