×

Вы используете устаревший браузер Internet Explorer. Некоторые функции сайта им не поддерживаются.

Рекомендуем установить один из следующих браузеров: Firefox, Opera или Chrome.

Контактная информация

+7-863-218-40-00 доб.200-80
ivdon3@bk.ru

Визуально-декларативный язык для проектирования автоматизированных информационных систем

Аннотация

О.В. Ольховик, А.В. Белых

В статье представлен язык, N-Visual Language (NVL), предназначенный для проектирования программного обеспечения информационных систем: структуры базы данных и кода, реализующего бизнес-логику.
Ключевые слова: программное обеспечение, база данных, проектная диаграмма,  N-Visual Language,  программная среда Information Systems Developer Studio № гос. регистрации 0420900096\0038

05.13.18 - Математическое моделирование, численные методы и комплексы программ

В статье представлен язык, N-Visual Language (NVL), предназначенный для проектирования программного обеспечения информационных систем: структуры базы данных и кода, реализующего бизнес-логику.
Причины, побудившие нас к разработке NVL – это, с одной стороны, недостаточная выразительность для кодогенерации IDEF-нотаций, с другой – громоздкость стандарта UML 2.0, на что обращено внимание, например, в работе [1].
Теоретические основы NVL описаны в статье [2]. Декларативная состовляющая языка представлена в работе [3].
NVL предназначен для построения проектной диаграммы информационнной системы, из которой автоматически генерируется структура базы данных и программный код для вычисления расчетных данных. Автоматическая генерация в таком случае позволяет:
- не разрабатывать проектные артефакты, описывающие поведение и алгоритмы для программных объектов, реализующих бизнес-логику;
- не писать вручную программный код для реализации бизнес-логики;
- автоматически поддерживать полное соотвествие между проектными артефактами и программным кодом, как в процессе разработки так и во время эксплуатации системы.
NVL разработан так, чтобы для понимания проектной диаграммы и пользователи, и  разработчики прикладывали минимальные усилия, и, тем самым, могли проще находить общий язык. Для этого
- проект программного обеспечения информационной системы выполняется только одной проектной диаграммой;
- проектная диаграмма на уровне представления может разбиваться на любое количество субдиаграмм (подобно ER-диаграмме);
- в диаграмме допускаются идентификаторы, образованные с помощью национальных алфавитов, и их не нужно транслировать в латиницу, поскольку идентификация во внутреннем представлении независима;
- NVL прост и состоит всего из пяти визуальных элементов;
- визуальные элементы NVL аналогичны элементам из стандартов UML 2.0 [4] и IDEF1X [5], и поэтому интуитивно понятны не только разработчикам ИС, но и опытным пользователям.
При структурном подходе к проектированию ИС проектная диаграмма на NVL заменяет ER-диаграммы, диграммы потоков данных (DFD) и диаграммы деятельности (IDEF3), описывающие программный код. Проектная диаграмма может связываться с моделью бизнес-процессов через спецификации входов и выходов на диаграммах IDEF0.
При объектно-ориентированномодходе к созданию программного обеспечения ИС проектная диаграмма может заменить диаграммы реализации UML для программного кода: классов (Class Diagram), кооперации (Collaboration Diagram) последовательности (Sequence Diagram), активности (Activity Diagram) и состояний (Statechart Diagram).    
Прежде чем перейти к описанию языка, расмотрим пример. Предметная область – организация выставок (упрощенный фрагмент). Компания, на арендуемой территории, проводит выставки, на которые в качестве экспонентов приглашаются юридические лица. Выставка характеризуется названием и сроками проведения. Выставка с одним названием может проводится с периодичностью раз или два в год. За проведение выставки отвечает менеджер – сотрудник компании.
Экспонент подает заявку-договор на участие в выставке, где, помимо собственных реквизитов, указывает размер, расположение и тип арендуемого стенда (только одного). В зависимости от этих параметров рассчитывается сумма договора. Кроме того, в сумму договора входят обязательный взнос и аккредитация представителей экспонента. Для иностранных участников наценка составляет 25%. Для участников, оформивших заявку за девяносто дней до начала выставки, скидка – 10%. Помимо суммы договора, необходимо рассчитывать доходность выставок и количество заявок, с которыми работает каждый менеджер.
Проектная диаграмма для данного примера представлена на рис. 1.



Рисунок 1 – Проектная диаграмма «Организация выставок»


Основной элемент проектной диаграммы – класс. Семантика класса описана в [2]. В NVL класс представлен прямоугольником, состоящим из четырех горизонтальных секций (рис. 2). В верхней секции записывается уникальное имя класса и, через двоеточие, его тип: Concept, Abstract, Entity или State. Тип класса характеризует природу его экземпляров (абстракции, сущности, состояния). У класса типа Concept есть только один неявный экземпляр.


а)                                                        б)
Рисунок 2 – Классы в NVL
а) спецификация класса; б) пример класса

Во второй сверху секции описываются исходные атрибуты. Задаются их имена и типы данных (домены) или экстенсионалы для ссылок. В третьей секции определяются формулы расчетных атрибутов. По исходным атрибутам автоматически генерируется схема базы данных, по расчетным – программный код, реализующий бизнес-логику. Четвертая секция предназначена для спецификации методов. Описание атрибутов и методов выполняется согласно синтаксису декларативного языка NDL [3]. Имена атрибутов и методов уникальны внутри класса, а также внутри ветви наследования, за исключением случая явного перекрытия.
Категория – множество экземпляров класса, соответствующих некоторому логическому условию. В отличие от классов, экземпляры которых задает пользователь, множество экземпляров категории формируется автоматически из объектов, для которых условие категории в текущий момент времени принимает истинное значение. Категория изображается четырехугольником с закругленными углами, состоящим из четырех секций (рис. 3). В первой секции записывается имя категории (может отсутствовать). Во второй секции декларируется логическое условие, определяющее категорию. Третья и четвертая секции категории соответствуют двум последним секциям класса (расчетные атрибуты и методы).


а)                                                        б)
Рисунок 3 – Категории в NVL
а) спецификация категории; б) примеры категории

Между классами и категориями могут устанавливаться отношения трех типов: наследование, связь и исключение.
Наследование обозначается стрелкой, направленной от потомка к предку (рис. 4). Формально семантика отношения определена в [2].


а)                                                        б)
Рисунок 4 – Наследование в NVL
а) спецификация наследования; б) пример наследования

Основные следствия установления наследования между классами и/или категориями следующие:

  1. Отношение наследования является предпорядком.
  2. Потомок наследует от предка методы и атрибуты со всеми ограничениями. При этом методы и атрибуты в потомке могут дополняться и перекрываться. Исходные атрибуты могут перекрываться только за счет сужения области значений. Условия в категориях так же могут переопределяться только путем сужения области истинности в потомке.
  3. Каждый экземпляр класса-потомка связан отношением наследования строго с одним экземпляром класса-предка. При этом значение каждого атрибута экземпляра-предка представляет собой объединение значений соответствующих атрибутов его потомков. Таким образом, наследование значений атрибутов происходит снизу вверх, а ограничений на значения сверху вниз.
  4. В классе (категории) непосредственно доступны все атрибуты, объявленные в нем самом, в его предках и в его потомках.
  5. Атрибуты и методы Concept-класса неявно переопределяются (становятся терминальными в смысле [2]) в его непосредственных потомках.

С целью повышения качества проектирования на наследование введены ограничения представленные в таблице 1.
Таблица 1 - Ограничения наследования


Может наследовать от:

Concept-класс

Abstract-класс

Entity-класс

State-класс

Категория

Объект

Concept-класс

+

-

-

-

-

Abstract-класс

+

+

-

-

-

Entity-класс

+

+

-

-

-

State-класс

-

-

+

+

-

Категория

-

+

+

+

+

Отношение связи соответствует связи один-ко-многим или многие-ко-многим в реляционных базах данных. Устанавливается только между классами. Связь изображается сплошной прямой или ломанной линией с кружком на конце у подчиненного класса (рис. 5).

а)                                                                               б)
Рисунок 5 – Связи в NVL
а) спецификация; б) пример связи

Если прямая ссылка может иметь несколько значений (случай многие-ко-многим), кружок ставится с обоих концов линии. В этом случае выбор главного и подчиненного класса зависит только от предпочтений поектировщика. Линия подписывается именами прямой и обратной ссылки разделенными знаком «->». В подчиненном классе появляется явный ссылочный атрибут, через который происходит прямое связывание экземпляров подчиненного класса с экземплярами главного класса (внешний ключ). В главном классе, при этом, неявно образуется обратный атрибут-ссылка.
Отношение исключения связывает два объекта и означает, что их экстенсионалы не пересекаются. На проектной диаграмме оно устанавливается только между категориями, поскольку все классы не связанные отношением наследования, связаны отношением исключения по умолчанию [2]. На практике его удобно использовать как предложение ELSE по отношению к условию, определяющему связанную категорию. Например, категория X определяется условием b и связана с категорией Y отношением исключения. Тогда категория Y определяется условием not b.  Исключение изображается прямой или ломанной сплошной линией (рис. 6).


а)                                                                   б)
Рисунок 5 – Исключение в NVL
а) спецификация; б) пример

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


Рисунок 7 – Проектная диаграмма «Подетальное планирование»
Рекурсивные вычисления в общем случае выполняются, если:

  1. Имеется связь между двумя классами в одной ветви наследования (в примере – это «Узел –> Части»).
  2. Вычисление производится с помощью определения рекурсивного атрибута минимум двумя формулами, одна из которых рекурсивна. Примеры рекурсивных атрибутов: «Потребность» и «Стоимость».
  3. Рекурсивная формула содержит конструкцию <ссылка на класс в ветви наследования>.<рекурсивный атрибут> или зависит от атрибута, формула которого имеет такую конструкцию. Пример первого случая – формула атрибута «Потребность» в классе «Часть», второго – формула атрибута «Стоимость» в категории «Узел». 
  4. Нерекурсивная формула должна быть определена в категории класса, в котором проводятся рекурсивные вычисления. В примере – это «Потребность» в категории «Изделие» и «Стоимость» в категории «Деталь».

Разработана программная среда Information Systems Developer Studio (ISDS), которая позволяет строить проектные диаграммы на NVL, и автоматически генерирует схему базы данных и программный код для расчетных данных. Сейчас проводится тестирование этой среды на практических примерах. Предварительно можно сказать, что процесс проектирования плюс разработки в ISDS намного проще, легче и дешевле, однако необходимо решать проблему оптимизации генерируемого кода.

Литература

1. Robert B. France, Sodipto Ghosh, Trung Dinh-Trong. Model-Driven Development Using UML 2.0: Promises and Pitfalls, Computer (IEEE Computer Society. V.38, No2, February 2005)

2. Белых А.В., Ольховик О.В. N-Модель данных. //"ИЗВЕСТИЯ ЮФУ. Технические науки. Тематический выпуск "Интеллектуальные САПР"", 2009. (в печати).

3. Белых А.В., Ковалев С.М., Ольховик О.В. Декларативный язык для N-модели данных. //"ВЕСТНИК РГУПС,  2009. (в печати).

4. U2 Partners, «Unified Modeling Language: Superstructure», version 2.0, 3rd revised submission to OMG RFP ad/00-09-02, http://www.omg.org/cgi-bin/ doc?ad/2003-04-01, April 2003.

5. Federal Information Processing Standards Publication 184, Announcing the Standard for INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X), December 1993.