Программные продукты и системы

В проектировании сложных автоматизированных систем активно используется графическое представление информации на базе диаграммных языков САПР. Существует большое количество коммерческих и свободно распространяемых программных средств, которые позволяют работать с диаграммными языками, такими как UML, IDEF, EPC, SDL, DFD и т.д., однако их большая часть не ориентирована на коллективную разработку, содержит слабые средства по расширению нотаций языка и зачастую не имеет средств анализа.

Среди диаграммных языков наиболее популярен UML. В статье технология анализа диаграм- мных языков рассматривается на примере UML-диаграмм, хотя система, являясь синтаксически-ориентированной, позволяет исследовать любые классы диаграмм.

Представим сводную таблицу (табл. 1) наиболее популярных программных продуктов для моделирования и описания бизнес-процессов, использующих диаграммные языки.

Таблица 1

Сравнительный анализ программных продуктов

Таблица построена на основе анализа сайтов Rational Software Architect [1], AllFusion ERwin Data Modeler [2], ARIS Platform [3]. Очевидно, что системы ориентированы на использование 2-3 языков, имеют ограниченные средства контроля и анализа.

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

Общие характеристики системы. Инструментарий позволяет выполнять следующие основные функции для пользователя:

–      создание диаграмм графических языков;

–      добавление новых нотаций диаграммно-графических языков;

–      анализ построенных диаграмм по предварительно загруженным в систему описаниям языка и алгоритмам анализа;

–      добавление новых алгоритмов анализа с помощью плагинов;

–      добавление синтаксических и семантических правил графических языков;

–      создание взаимосвязи между построенными проектировщиками диаграммами; мультидоступ  к БД построенных диаграмм.

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

Архитектура системы

На рисунке 1 приведена архитектура системы, содержащая презентационный слой (клиент), слой рендеринга интерфейса (клиент), API для работы с анализатором (сервер), слой бизнес-логики (сервер).

При необходимости пользователь может разместить все элементы системы на одной машине и пользоваться ею как обычным приложением.

Презентационный слой. Уровень презентационной логики реализуется различными системами проектирования, например, Rational Rose или BPWin. Для использования системы анализа диаграммных языков прикладные системы проектирования должны предоставлять

–      доступ к построенной диаграмме и ее внутреннему содержанию (для анализа необходима информация о всех элементах диаграммы и связях между ними);

–      возможность вывода информации об ошибке в консоль в человеко-читаемом виде либо непосредственно на диаграмму (например, подсвечивая элемент красным цветом).

Большинство современных сред разработки позволяет использовать расширения. При разработке системы с множеством различных front-end-компонентов стоит вопрос о создании протокола взаимодействия между элементами системы. Для решения этой проблемы предлагается написать промежуточный слой между сервером и клиентом – слой рендеринга интерфейса.

Слой рендеринга интерфейса. Данный слой отвечает за взаимодействие систем проектирования и анализа диаграмм. Он реализуется в виде плагина к системе проектирования и преобразует внутреннее представление диаграммы в формат, понятный серверу. В качестве базовых выбраны два наиболее распространенных формата – JSON (JavaScript Object Notation) и XML (eXtensible Markup Language). Основными задачами данного компонента являются следующие:

–      авторизация на сервере; пользователь получит уникальную сессию на сервере, в рамках которой будет вести свою работу;

–      преобразование диаграммы в XML/JSON-представление;

–      передача XML/JSON-представления на сервер;

–      получение списка ошибок от анализатора и передача его в презентационный слой.

API для работы с анализатором. Анализатор – сервис, работающий по принципам REST [4]. Одним из преимуществ RESTful-сервиса является предоставление данных в удобном для пользователя формате. Технология REST использует базовые принципы передачи данных по http, это обеспечивает легкость реализации взаимодействия с сервисом и позволяет подключать всевозможные системы проектирования, написанные на различных языках программирования, без больших временных затрат.

Сервер выполняет функции проверки на корректность описания диаграммы; преобразования xml-описания во внутреннее представление, понятное RV-анализатору; запуска анализа входной диаграммы; вывода списка ошибок.

Слой бизнес-логики. Диаграммы анализируются с использованием автоматных RV-грамматик [5]. Схема работы анализатора представлена на рисунке 2.

На этапе инициализации возможны два варианта загрузки диаграммы. При первом анализатору известно, какую диаграмму он анализирует. Из библиотеки грамматик выбирается нужная, и разбор происходит по ней. При втором анализатор получает только диаграмму и по первым 3–5 элементам выбирает нужную грамматику.

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

Режим восстановления – это особое состояние автомата, в котором разрешается проблема обработки ошибочного входного элемента. Происходит восстановление состояния анализатора по методу продолжателей [6]. Данный режим позволяет обнаружить не только первую ошибку в диаграмме, но и по возможности все ошибки, допущенные разработчиком. Запись об ошибке производится в момент перехода в состояние восстановления. Указываются место возникновения ошибки и диагностическая информация о ней.

На третьем этапе формируется отчет об ошибках, обнаруженных в диаграмме. Если список пуст, возвращается сообщение о завершении анализа без ошибок. В противном случае формируется отчет со списком всех ошибок.

RV-грамматика

RV-грамматикой языка L (G) называется упорядоченная пятерка непустых множеств G=(V, Σ, , R, r0), где V={vl, l=} – вспомогательный алфавит; Σ={at, t=} – терминальный алфавит графического языка; ={, t=} – квазитерминальный алфавит; R={ri, i=} – схема грамматики G; r0ÎR – аксиома RV-грамматики.

Продукция PijÎri имеет вид

Pij : ,

где Wv(γ1, ... , γn) – n-арное отношение, определяющее вид операции над внутренней памятью в зависимости от νÎ{0, 1, 2, 3}; Ωμ – оператор модификации, определенным образом изменяющий вид операции над памятью, причем μÎ{0, 1, 2}; rmÎR – имя комплекса продукции-преемника.

Построение RV-грамматики происходит в две фазы: синтез и анализ.

Синтез RV-грамматики включает следующие этапы.

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

2.     Строится матрица допустимых паросочетаний для квазитерминального алфавита.

3.     Определяются отношения над внутренней памятью, обеспечивающие эффективный контроль связности графических объектов.

4.     По матрице допустимых паросочетаний строится граф RV-грамматики, вершинам которого поставлены в соответствие имена комплексов правил, а дугам – квазитермы и операции над внутренней памятью. RV-грамматика может быть представлена не только в виде графов, но и в табличной и аналитической формах.

Таблица 2

Терминальный и квазитерминальный алфавиты языка UML, диаграммы активности

Анализ осуществляется в два этапа:

–      устраняются недетерминированность и неопределенность;

–      производится минимизация RV-грамматики (результат представлен в табл. 3).

Следует отметить, что разработаны грамматики для пяти видов диаграмм: Активность, Последовательность, Варианты использования, Классы и Пакеты.

RV-грамматика отличается линейным временем разбора, небольшими затратами памяти, обеспечивает необходимую полноту разбора и позволяет обнаруживать синтаксические и семантические ошибки.

Таблица 3

Табличная форма RV-грамматики для языка диаграммы активности после минимизации

Таким образом, в статье рассмотрена архитектура системы анализа диаграммных языков. Система предусматривает возможность расширения на произвольное множество языков и подключение различных средств проектирования. По данной архитектуре реализован анализатор для сре- ды моделирования и проектирования WIQA [7] (разработка кафедры «Вычислительная техника» УлГТУ).

Литература

1.          URL: www-01.ibm.com/software/rational/ products/swar­chitect (дата обращения: 02.08.2011).

2.          URL: www.erwin.ru (дата обращения: 02.08.2011).

3.          URL: www.softwareag.com/corporate/products/aris_plat­form (дата обращения: 02.08.2011).

4.          Fielding R.T. Architectural Styles and the Design of Network-based Software Architectures: dissertation doctor of philosophy, University of California: Irvine, 2000, 162 p.

5.          Шаров О.Г., Афанасьев А.Н. Синтаксически-ориенти­рованная реализация графических языков на основе автоматных графических грамматик // Программирование. 2005. № 5. С. 56–66.

6.     Шаров О.Г., Афанасьев А.Н. Нейтрализация синтаксических ошибок в графических языках // Программирование, 2008. № 1. С. 61–67.

7.     Соснин П.И. Концептуальное моделирование компьютеризованных систем. Ульяновск: УлГТУ, 2008. 198 с.