Материал: Средства BPMN
16
Генерация кода бизнес-процессов
Проведя анализ требований к существующим ИС, разработанным на основе технологии REAL-IT/.NET и кода ручных изменений, внесённых для поддержки динамических процессов, можно сформулировать следующие требования к генераторам кода:
1.Генерация служебных состояний для различных сущностей, участвующих в процессах
2.Генерация статических классов для уникальных объектов
3.Генерация извлекаемых из диаграммы ограничений на доступ к данным в те или иные этапы процессов, а также элементов интерфейса, отвечающих за смену состояний объектов.
Создание служебных состояний
На BPMN диаграмме отдельно взятые пулы представляют собой различных участников бизнес-процесса (пользователи информационной системы). Такие участники именуются бизнес-сущностями (бизнес-ролями).
Рисунок 4. Участники бизнес-процесса
Каждая бизнес-сущность должна быть экземпляром некоторого класса из модели данных (в приведенном примере, однако, Приемная комиссия (Office)
17
не является экземпляром некоторого класса, т.к. Приемная комиссия существует ровно в одном экземпляре).
Было предложено извлекать из спроектированной диаграммы бизнеспроцессов так называемые служебные состояния, отвечающие набору статусов, в которых может пребывать каждый из участников бизнеспроцесса. В определенный момент времени участник процесса находится в одном из служебных состояний. Каждое служебное состояние соответствует событию (начальному (Start Event), промежуточному (Intermediate Event) или конечному (End Event)) или Пользовательскому заданию (User Task)). Для каждого служебного состояния генерировался соответствующий enumeration, являющийся свойством класса, соответствующей сущности.
Работа со статическими классами, сохраняющими состояние уникальных объектов
Если существует бизнес-сущность, которая является уникальным объектом, то согласно текущим правилам технологии, в модели данных за ненадобностью будет отсутствовать класс, соответствующий этой бизнессущности. Но, вследствие необходимости сохранения состояния этого объекта было решено генерировать соответствующий класс.
У этого класса имеется статическое свойство, отвечающее за состояние уникального объекта в данный момент. Соответственно, изменение в ходе работы ИС состояния уникального объекта означает изменение статического свойства. Идентификационный номер текущего состояния уникального объекта хранится в соответствующей таблице в базе данных.
Также, требование поддержки доступа к состояниям уникальных сущностей выявила необходимость генерации классов, не относящихся напрямую к какой-либо форме.
Дополнительно заметим, что в процессе развития ИС встречаются случаи, когда появляется необходимость отмены требования об
18
уникальности объекта. В случае с использованием статических классов, провести такое изменение становится гораздо легче.
Получаемые из диаграммы бизнес-процессов ограничения и действия
Необходимо сформулировать ограничения, которые будут извлекаться из диаграммы бизнес-процессов и внести необходимые изменения в генератор кода.
Была предложена следующая идея: все изменения раскладываются в некоторый базис, состоящий из элементарных ограничений и элементарных действий. Сформулируем составные элементы этого базиса.
Элементарные ограничения:
1.Ограничения на изменение поля - возможность редактирования поля карточки объекта;
2.Ограничения на создание/редактирование/удаление сущностей - возможность совершать соответствующие операции со списками (включая встроенные списки);
3.Ограничения на статусы (служебные состояния) – из текущего состояния участник бизнес-процесса может перейти лишь в состояния, связанные с нынешним на диаграмме (таким образом, учитывается порядок состояний).
Элементарные действия:
1.Изменение значения поля объекта в зависимости от текущего состояния;
2.Включение/выключение элементарных ограничений.
Действия соответствует кнопке на карточке бизнес-сущности, соответствующие Пользовательским заданиям (User Task).
Каждая такая кнопка:
19
1.Имеет имя, соответствующее имени задания, по которому оно сгенерировано;
2.Становится активной, когда бизнес-сущность переходит в состояние, предшествующее состоянию, сгенерированному по заданию, по которому эта кнопка и сгенерирована. Если на диаграмме задание соединено информационным потоком с промежуточным событиемсообщением из другого пула, то необходимо аналогичное условие на состояние этой бизнес-сущности; При нажатии происходят следующие события:
1.Если задание, соответствующее кнопке, соединено информационным потоком с промежуточным событием-сообщением из другого пула, то происходит смена состояний бизнес-сущностей, накладываются ограничения на редактирование/удаление объектов данных, ассоциированных с информационным потоком.
2.В противном случае, происходит смена состояния бизнес-сущности.
После этого кнопка становится неактивной.
Для поддержки каждого из перечисленных выше элементарных операций был изменён шаблон генерируемой формы и добавлена соответствующая логика в код генератора.
Изменение библиотек поддержки исполнения
Была выделена функциональность, общая для всех приложений, и соответствующие изменения были внесены в библиотеки поддержки исполнения, что позволило сократить количество сгенерированного кода. Основные изменения:
1.Работа с состояниями,
2.Обеспечение доступа к полям БД, сохранение значений статических объектов,
3.Ограничение доступа к полям форм.
20
Апробация
Рассмотрим пример ИС “Поступление в университет”.
Рисунок 5. Спроектированная диаграмма классов