CC BY
119
Шибанов С.В., Скоробогатько А.А.
ГОУ ВПО Пензенский государственный университет
МОДЕЛИРОВАНИЕ АКТИВНЫХ ПРАВИЛ В НОТАЦИИ IDEF0
В связи с интенсивным развитием информационных технологий к информационным системам предъявляется все больше и больше требований. Современная информационная система должна не только сохранять и отображать информацию, но и своевременно реагировать на события, возникающие внутри системы и за ее пределами.
Одним из способов решения данной проблемы является применение активных баз данных [1, 2] . Активная база данных (АБД) может выполнять дополнительные действия, явно не указанные в запросе пользователя. Эти действия, а также условия их выполнения, описываются в виде набора активных правил, которые хранятся в активной базе данных вместе с данными предметной области.
Активныхправилабываютдвухвидов: ECA-правила (Event-Condition-Action) и SECA-правила (State-Event-Condition-Action) . ECA-правила используют стандартную для активных баз данных модель Собы-тие-Условие-Действие. Правила этого типа содержат три части: событие, по которому активируется правило, проверяемое условие и выполняемое действие.
SECA-правила, кроме события, условия и действия, учитывают также состояние объекта. Проверка условия и выполнение действия происходят только в том случае, если объект находится в разрешенном состоянии. После выполнения действия объект переводится в новое состояние, определенное в SECA-правиле. Для хранения в активной базе данных правил обоих типов была предложена интегрированная модель активных правил [3].
Применение активных баз данных требует выработки методов проектирования активных правил. Существующие на сегодняшний день методики проектирования ориентированы на анализ предметной области с позиции присутствующих в ней структур данных и процессов. Поэтому необходимо дополнить их средствами анализа и представления активных правил.
Среди распространенных подходов к проектированию информационных систем можно выделить структурный подход, представленный методологиями ARIS [4] и IDEF [5, 6], и объектно-ориентированный подход, представленный нотацией UML [7] . В данной статье рассматривается моделирование активных правил с использованием структурного подхода и нотации IDEF0.
Структурное моделирование с использованием методологии IDEF0 подразумевает рассмотрение информационной системы как единого процесса, преобразующего входные данные в выходные. В ходе проектирования система как процесс декомпозируется на более мелкие процессы, между которыми устанавливаются различные типы связей.
В контексте модели информационной системы блок IDEF0 описывает некоторую функцию, на вход которой подаются исходные данные. На основе этих данных функция генерирует новый набор данных (выход блока). При этом в процессе формирования выхода участвуют, как правило, одно или несколько клиентских приложений (механизмов блока). Правила формирования выхода блока существуют в виде исполняемого кода ИС (управление блока). Под исполняемым кодом ИС понимается в зависимости от архитектуры ИС код клиентских приложений, код процедур сервера приложений, либо код хранимых процедур сервера баз данных.
Рассмотрим выполнение блока IDEF0 в обычной ИС и в ИС с применением АБД.
Клиентское ^ |
приложение ввода данных
Вход 1 Вход 2
>
СУБД
<-
данные Выход 1 Выход 2
Клиентское | приложение обработки данных
Рисунок 1 - выполнение блока в ИС без применения АБД
В обычной ИС (рисунок 1) клиентское приложение ввода данных формирует входы блока и сохраняет их в базу данных. Второе клиентское приложение читает необходимые данные, формирует выходы блока и также сохраняет их в базу данных. На данном примере хорошо виден один из недостатков обычной ИС - ее пассивность: приложение обработки вынуждено самостоятельно запрашивать данные о появлении
новых входов, вследствие чего информация о появлении новых данных на входе блока попадает в приложение обработки с запозданием. Это запаздывание может накапливаться при прохождении информации по блокам системы, что снижает эффективность всей системы в целом.
Рисунок 2 - выполнение блока в ИС с применением АБД
В информационной системе с применением АБД (рисунок 2) входы блока обрабатываются сразу при поступлении в систему. Система управления активной базой данных (СУАБД) может самостоятельно сформировать некоторые из выходов блока («Выход 1» на рисунке), выполнив одно или несколько активных правил. Если для формирования выхода нужно участие человека, то СУАБД посылает уведомление соответствующему клиентскому приложению, которое формирует выход. Таким образом, применение АБД уменьшает количество ручной работы и ускоряет процесс обработки данных системой.
Информация о некоторых выходах может быть отправлена СУАБД за пределы системы («Уведомление о выходе 2» на рисунке). Например, может быть отправлена какая-либо информация клиентам и партнерам организации.
Для применения методологии IDEF при проектировании ИС с использованием АБД требуется расширить нотацию IDEF0, включив в нее средства представления активных правил.
Для моделирования ECA-правила в нотации IDEF0 необходимо моделировать его части: событие, условие и действие. На рисунке 3 изображено событие активного правила в нотации IDEF0.
Рисунок 3 - Событие в нотации IDEF0
Событие изображается как стрелка с меткой «Е» (Event). Над стрелкой указывается название события. Если необходимо указать параметры события, то они указываются как ответвления стрелки-события. В контексте диаграммы IDEF0 стрелка-событие изображает передачу информации о возникновении события между частями информационной системы.
Действие ECA-правила изобразим как блок IDEF0, исполняемый специальным механизмом - АБД, активной базой данных (рисунок 4).
Название
действия
“Ж“
АБД
Рисунок 4 - Действие в нотации IDEF0
В качестве названия блока указывается название действия. В контексте IDEF0 действие является обычной функцией, исполняемой механизмом АБД.
Условие ECA-правила изобразим как стрелку управления с меткой «C» (Condition). Рядом со стрелкой указывается формулировка условия. Условие представляет собой логическое выражение, либо название функции вычисления условия (рисунок 5).
с]
Условие
V
Рисунок 5 - Условие в нотации IDEF0
ECA-правило в нотации IDEF0 представляет собой комбинацию перечисленных выше компонентов - события, условия и действия (рисунок б).
Рисунок б - ECA-правило в нотации IDEF0
Действие ECA-правила изображается как блок IDEF0, на вход которого поступает событие, параметры события и дополнительные входные данные, необходимые для выполнения действия. В качестве управления блока выступает условие, контролирующее запуск срабатывания действия. На выходе блока формируются выходные данные и, возможно, активируются события. Блок действия выполняется механизмом «АБД».Комбинируя различным образом события, условия и действия, мы получаем на диаграмме IDEF0 различные ECA-правила.
Стоит отметить, что АБД в данном примере является дополнительным механизмом, который берет на себя выполнение части функций системы. Укажем способ, посредством которого можно учесть использование АБД на стадии проектирования ИС.
Рассмотрим стандартный блок диаграммы IDEF0 с входами «Вх1» и«Вх2», выходами «Вых1» и «Вых2», механизмом «ПО ИС» (Программное обеспечение информационной системы) и управлением «У». Преобразуем этот блок, добавив к нему механизм «АБД», активную базу данных (рисунок 7).
Рисунок 7 - преобразование блока IDEF0 для включения АБД в проектируемую систему Далее детализируем рассматриваемый блок (рисунок 8). Для входов, которые могут быть обработаны без участия человека (вход «Вх1» на рисунке), создадим отдельные блоки, исполняемые механизмом «АБД». Для остальных входов (вход «Вх2» на рисунке) создадим блок, исполняемый механизмом «ПО ИС». Управление «У» с родительской диаграммы подведем к блокам с механизмом «ПО ИС».
Блок с механизмом АБД - это активное правило, поэтому укажем для него дополнительно событие, по которому должно срабатывать правило (событие «Е1» на рисунке) и, возможно, условие, контролирующее срабатывание правила (условие «С1» на рисунке)
Рисунок 8 - детализация блока IDEF0
Таким образом, мы перепоручили обработку части входов блока активной базе данных. На следующем этапе проектирования блоки с механизмом «АБД» следует преобразовать в активные правила, выполняемые АБД при появлении новых или модификации существующих данных на входе блока.
Для оставшихся блоков следует создать активные правила, уведомляющие соответствующие клиентские приложения о появлении новых данных. Уведомление может осуществляться различными способами: с помощью «сервиса событий» [8], по электронной почте, с помощью служб обмена мгновенными сообщениями, SMS и т.п.
Для стрелок-выходов, направленных за пределы ИС также следует по возможности создать правила-уведомления. В данном случае уведомлением может быть, например, электронное письмо заказчику, обращение к web-службе (при интеграции между информационными системами) и т.п.
Как было упомянуто выше, активные правила хранятся в АБД вместе с обычными данными. Одним из вариантов представления активных правил в АБД является интегрированная модель активных правил
[3] . Для использования этой модели в рамках структурного подхода удобно отобразить ее в нотацию IDEFlx[9].
На рисунке 9 приведен результат отображения интегрированной модели активных правил в нотацию IDEFlx.
Рисунок 9 - отображение интегрированной модели активных правил в нотацию IDEFlx
Сущность Object описывает объекты активной базы данных. Каждый объект имеет название (атрибут name) и имя хранимой процедуры получения текущего состояния объекта (атрибут
getCurrentStateProc).
С каждым объектом связан набор возможных состояний объекта (сущность State). Состояние обладает именем (атрибут name) и именем хранимой процедуры перевода объекта в данное состояние (атрибут enterStateProc).
Событие активной базы данных (сущность Event) в качестве атрибутов имеет имена треххранимых процедур: установки обработчика (атрибут setupHandlerProc), удаления обработчика (атрибут
removeHandlerProc) и проверки наличия обработчика (атрибут isHandlerSetUpProc).
Действия активной базы данных, выполняющихся как итог реакции на наступление событий, описанных в активных правилах, (сущность Action) в качестве атрибута содержит имя хранимой процедуры
выполнения действия (атрибут actionProc).
Активное ECA-правило (сущность ECA) связано с событием, активирующим правило, и с выполняемым действием. Дополнительно ECA-правило в качестве атрибутов содержит имя хранимой процедуры проверки условия (атрибут conditionProc) и имя хранимой процедуры установки контекста (атрибут setActionContextProc).
Активное SECA-правило (сущность SECA) связано с событием, действием, наблюдаемым объектом и двумя состояниями: начальным (атрибут state1) и конечным (атрибут state2). Кроме того, SECA-
правило в качестве атрибутов содержит имена хранимых процедур проверки условия (атрибут conditionProc) и установки контекста (атрибут setActionContextProc).
Представленный на рисунке 9 набор отношений может быть использован для хранения активных правил в реляционной базе данных.
Таким образом, структурное моделирование активных правил включает несколько этапов:
Построение модели информационной системы и ее представление в нотации IDEF0;
Добавление механизма Активная база данных (АБД)к диаграмме IDEF0;
Детализация блоков диаграммы IDEF0 с целью выделения дочерних блоков, исполняемых механизмом Активная база данных (АБД);
Преобразование блоков, исполняемых механизмом Активная база данных (АБД), в активные правила.
ЛИТЕРАТУРА
1. Norman W.Paton, Oscar Dias Active Database Systems // ACM Computing Surveys, Vol.31, No.1,
1999 .
2. Mario G. Piattini, Oscar Diaz Advanced database technology and design - ArtechHouse, 2000.
- 553 с.
3. Шибанов С.В., Скоробогатько А.А., Лысенко Э.В. Интегрированная модель активных правил // Математическое и программное обеспечение систем в промышленной и социальной сферах: междунар. сб. науч. трудов - Магнитогорск: Изд-во Магнитогорск. гос. техн. ун-та им. Г.И. Носова, 2011. - Ч. I.
- с. 41-46
4. Август-Вильгельм Шеер Бизнес-процессы. Основные понятия. Теория. Методы - М.: Просветитель,
1999. - 173 с.
5. Методология функционального моделирования IDEF0 - М: ИПК Издательство стандартов, 2000. -
75 с.
6. David A. Marca, Clement L. McGowan IDEF0 and SADT: A Modeler's Guide - OpenProcess, Inc., 2005. - 392 c.
7. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.
- СПб.: Питер, 2007. - 544 с.
8. Шибанов С.В., Скоробогатько А.А., Лысенко Э.В. Архитектура программных средств управления активными базами данных // Математическое и программное обеспечение систем в промышленной и социальной сферах: междунар. сб. науч. трудов - Магнитогорск: Изд-во Магнитогорск. гос. техн. ун-та им. Г.И. Носова, 2011. - Ч. I. - с. 47-52
9. Thomas A., Bruce M.D.Designing Quality Databases With Idef1X Information Models- Dorset House, 1991. - 584 c.
