CC BY
53
Визуально-декларативный язык для проектирования автоматизированных информационных систем Ольховик О. В., Белых А. В.
В статье представлен язык, 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.
Вид Выставки: Abstract
Название: varchar(32) Менеджер: Ех^Сотрудник)
Менеджер -> Выставки
Сотрудник: Entity
ФИО: varchar(64)
Телефон: varchar(24) set(5) Email: varchar(24)
ЧислоЗаявок =
С ount(B ыставки. ОткрытыеЗаявки)
Страна: Entity (
Наименование: varchar(32)
Юридическое Лицо: Concept
Название: varchar(64)
Адрес: varchar(128) Страна: Ext(CTpam)
Выставка: Entity
Начало: date Конец: date
Аккредитация: Currency Взнос: Currency
Доход = 8шп(Стенды.Заявки.Общ_Сумма)
Тип Стенда: Abstract Наименование: varchar(32)
Заявка: Entity
ґ Л
Конец <= CurrentDate
ОткрытыеЗаявки = Стенды.Заявки
V J
Выставка: Ех^Выставка) Цена: Currency
Номер: varchar(12)
Дата: date
Экспонент: Ех^Клиент)
Положение: Ех1(Положение_Стенда)
Участники: integer________________________
Стоим_Стенда = Стенд. Цена*Размер*
(1 +Положение.Наценка)
Сумма = СтоимСтенда + Стенд.Выставка.Взнос + Участники*Стенд.Выставка. Аккредитация Скидка = О
Общ Сумма = Сумма - Скидка + Наценка
"Z5"
"ZS"
г ОткрытаяВыставка ^ ^ Отечественнаязаявка ^
Начало => CurrentDate
Наценка = 0
V J V J
ґ~
Клиент: Entity
Контактное лицо: varchar(64) Телефон: varchar(24) set(5) ВидДеятельности: varchar(64)
Положение -> Заяв Положение Стенда: Abstract
Наименование: varchar(36) Наценка: double
Э
Зарубежнаязаявка
Экспонент.Страна.Название != 'Россия'
Ранняя заявка
МЭау(Стенд.Выставка.Начало, Дата) >= 90
Рисунок 1 - Проектная диаграмма «Организация выставок»
Основной элемент проектной диаграммы - класс. Семантика класса описана в [2]. В NVL класс представлен прямоугольником, состоящим из четырех горизонтальных секций (рис. 2). В верхней секции записывается уникальное имя класса и, через двоеточие, его тип: Concept, Abstract, Entity или State. Тип класса характеризует природу его экземпляров (абстракции, сущности, состояния). У класса типа Concept есть только один неявный экземпляр.
Имя класса: Тип класса
имя атрибута: тип атрибута имя атрибута: тип атрибута
имя атрибута: тип атрибута
имя атрибута = формула имя атрибута = формула
имя атрибута = формула
спецификация метода спецификация метода
спецификация метода
а) б)
Рисунок 2 - Классы в ЫУЬ а) спецификация класса; б) пример класса Во второй сверху секции описываются исходные атрибуты. Задаются их имена и типы данных (домены) или экстенсионалы для ссылок. В третьей секции определяются формулы расчетных атрибутов. По исходным атрибутам автоматически генерируется схема базы данных, по расчетным -программный код, реализующий бизнес-логику. Четвертая секция предназначена для спецификации методов. Описание атрибутов и методов выполняется согласно синтаксису декларативного языка КБЬ [3]. Имена атрибутов и методов уникальны внутри класса, а также внутри ветви наследования, за исключением случая явного перекрытия.
Заявка: Entity
Номер: varchar(12)
Дата: date
Экспонент: ЕхІ(Клиент)
Стенд: ЕхІ(Стенд)
Положение: ЕхІ(Положение)
Участники: integer_________________________
СтоимСтенда = Стенд.Цена*Размер*
(1 +Положение.Наценка)
Сумма = СтоимСтенда + Стенд.Выставка.Взнос + Участники*Стенд.Выставка.Аккредитация Скидка О
Общ Сумма = Сумма - Скидка + Наценка
Категория - множество экземпляров класса, соответствующих некоторому логическому условию. В отличие от классов, экземпляры которых задает пользователь, множество экземпляров категории
формируется автоматически из объектов, для которых условие категории в текущий момент времени принимает истинное значение. Категория
изображается четырехугольником с закругленными углами, состоящим из четырех секций (рис. 3). В первой секции записывается имя категории (может отсутствовать). Во второй секции декларируется логическое условие, определяющее категорию. Третья и четвертая секции категории
соответствуют двум последним секциям класса (расчетные атрибуты и методы).
Имя категории
Условие категории
имя атрибута = формула имя атрибута = формула
имя атрибута = формула
спецификация метода спецификация метода
спецификация метода
Ґ N
Конец <= СиггеїіїОаІе
ОткрытыеЗаявки = Стенды.Заявки
V У
Зарубежная_заявка Л
Экспонент.Страна.Название !=
Л Россия'___________________________
Наценка = (Сумма - Скидка) * 0.25
С Отечественная
заявка
Наценка = 0
а) б)
Рисунок 3 - Категории в ЫУЬ а) спецификация категории; б) примеры категории Между классами и категориями могут устанавливаться отношения трех типов: наследование, связь и исключение.
Наследование обозначается стрелкой, направленной от потомка к предку (рис. 4). Формально семантика отношения определена в [2].
Вид Выставки: Abstract
Название: уагсЬаг(32) Менеджер: Ех^Сотрудник)
Выставка: Entity
Начало: date Конец: date
Аккредитация: Currency Взнос: Currency
Доход = 8шп(Стенды.Заявки.Общ_Сумма)
"ZS"
Конец <= CurrentDate
ОткрытыеЗаявки = Стенды.Заявки
ОткрытаяВ ыставка
Начало => CurrentDate
а) б)
Рисунок 4 - Наследование в МУЬ а) спецификация наследования; б) пример наследования
Основные следствия установления наследования между классами и/или категориями следующие:
1. Отношение наследования является предпорядком.
2. Потомок наследует от предка методы и атрибуты со всеми ограничениями. При этом методы и атрибуты в потомке могут дополняться и перекрываться. Исходные атрибуты могут перекрываться только за счет сужения области значений. Условия в категориях так же могут переопределяться только путем сужения области истинности в потомке.
3. Каждый экземпляр класса-потомка связан отношением наследования строго с одним экземпляром класса-предка. При этом значение каждого атрибута экземпляра-предка представляет собой объединение значений соответствующих атрибутов его потомков. Таким образом, наследование значений атрибутов происходит снизу вверх, а ограничений на значения сверху вниз.
4. В классе (категории) непосредственно доступны все атрибуты, объявленные в нем самом, в его предках и в его потомках.
5. Атрибуты и методы Concept-класса неявно переопределяются (становятся терминальными в смысле [2]) в его непосредственных потомках.
С целью повышения качества проектирования на наследование введены ограничения представленные в таблице 1.
Таблица 1 - Ограничения наследования
Может наследовать Concept- Abstract- Entity- State- Категория
от: класс класс класс класс
Объект
Concept-класс + - - - -
Abstract-класс + + - - -
Entity-класс + + - - -
State-класс - - + + -
Категория - + + + +
Отношение связи соответствует связи один-ко-многим или многие-ко-многим в реляционных базах данных. Устанавливается только между классами. Связь изображается сплошной прямой или ломанной линией с кружком на конце у подчиненного класса (рис. 5).
Страна -> Клиенты
Имя прямой ссылки -> имя обратной ссылки
Имя прямой ссылки -> имя обратной ссылки
Страна: Entity Юридическое Лицо: Concept
Наименование: varchar(32)
Название: varchar(64) ИНН: char(10) Адрес: varchar(128) Страна: Ext(CipaHa)
а)
б)
Рисунок 5 - Связи в NVL а) спецификация; б) пример связи Если прямая ссылка может иметь несколько значений (случай многие-ко-многим), кружок ставится с обоих концов линии. В этом случае выбор главного и подчиненного класса зависит только от предпочтений поектировщика. Линия подписывается именами прямой и обратной ссылки разделенными знаком «->». В подчиненном классе появляется явный ссылочный атрибут, через который происходит прямое связывание экземпляров подчиненного класса с экземплярами главного класса (внешний ключ). В главном классе, при этом, неявно образуется обратный атрибут-ссылка.
Отношение исключения связывает два объекта и означает, что их экстенсионалы не пересекаются. На проектной диаграмме оно устанавливается только между категориями, поскольку все классы не связанные отношением наследования, связаны отношением исключения по умолчанию [2]. На практике его удобно использовать как предложение ELSE по отношению к условию, определяющему связанную категорию. Например, категория X определяется условием b и связана с категорией Y отношением исключения. Тогда категория Y определяется условием not b. Исключение изображается прямой или ломанной сплошной линией (рис. 6).
г Отечественная заявка ^ г Зарубежная_заявка л
Экспонент.Страна.Название != 'Россия'
Наценка = 0
Наценка = (Сумма-Скидка) *0.25
v J V J
а) б)
Рисунок 5 - Исключение в ЫУЬ а) спецификация; б) пример В предложенном примере проектная диаграмма (рис. 1) позволяет продемонстрировать почти все особенности и возможности ЫУЬ.
Рекурсивные вычисления разберем на примере другой упрощенной предметной области. Производственное предприятие выпускает изделия, состоящие из сборочных единиц. На изделия поступают заказы. Необходимо рассчитать подетальную плановую потребность (План) на каждую сборочную единицу и ее стоимость с учетом стоимости составных частей (Стоимость). Оба атрибута вычисляются рекурсивно. Проектная диаграмма представлена на рисунке 7.
Сборочная Единица: Entity
Код: char(24)
Название: varchar(32) СобственЦена: Currency
Часть: State
Узел: Ех1(Сборочная_Единица) Количество: double
Потребность = Количество *
Стоим в Узле = Стоимость * Количество
' Узел Л Деталь ^
Части is Null
Стоимость = СобственЦена + 8шп(Части. СтоимвУ зле)
Стоимость = Собствен Цена
V У V J
Узел І8 №11
Потребность = Заказ
Рисунок 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.
