Моделирование бизнес-процессов (стр. 23 )

Триггеры могут активизировать функции приложений. Например, если в системе планирования складских материалов непрерывно контролируется наличие той или иной детали, то при наступлении события «минимальный уровень запасов не поддерживается» инициируется заказ на закупку.

Говоря кратко, триггеры состоят из описания инициирующих событий, контролируемых условий и действий, инициируемых в случае, если эти условия удовлетворяются. Действия представляют собой операции (т. е. транзакции) обновления данных. Более точно, в соответствии с механизмом событие/триггер (ЕТМ) (Kotz. Triggermechanismus in Datenbanksystemen. 1989, с. 54) триггером называется пара действий, состоящая из результата и собственно действия {Т = (Е, А)}. Таким образом, действие А выполняется, как только происходит событие типа Е.

Например, если в процессе разработки продукта по завершении этапа «фаза проектирования 1» запускается процедура проверки результата, то триггер будет выглядеть следующим образом:

EVENT end_of_design_phase_l (design object: DB_ID);

ACTION verification_procedure_A (verif_obj: DB_ID)

=<Verification of verif_obj>;

TRIGGER Tl =

ON end_of_design_phase_l

DO verification_procedure_A (design_object);

(Kotz. Triggermechanismus in Datenbanksystemen. 1989, c. 64).

Здесь к событиям и действиям привязываются идентификаторы различных обрабатываемых объектов. В данном примере проектируемый объект именуется design_object (с идентификатором базы данных DB_ID), а объект, подлежащий проверке действием, именуется verification_object (с идентификатором базы данных DB_ID).

Раздельное описание событий, действий и триггеров обеспечивает различным триггерам доступ к одним и тем же событиям и описаниям действий. В то же время параметризация событий и действий позволяет реализовать различные процедуры управления, несмотря на идентичные базовые описания.

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

Механизм событие/триггер (ЕТМ) можно непосредственно связать с СДП, так как события уже введены, а действия соответствуют функциональным модулям. Триггеры характеризуют контекст между Е и А, совпадая с линиями соединений между событиями и функциями СДП.

Процессы, разработанные в виде СДП, могут быть трансформированы в нотации триггерного управления. Необходимо только дополнить диаграммы СДП символами, принятыми на уровне спецификации проекта. Сюда входит идентификация событий, триггеров и сообщений, соответствующих действиям.

На рис. 124 концепция триггеров представлена в виде метамодели, где класс СОБЫТИЕ является связующим звеном с уровнем определения требований.

Рис. 124. Структура концепции триггеров

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

После инициации того или иного триггера различные состояния базы данных могут проверяться в соответствии с правилами, описанными для триггеров. На это указывает ассоциация УСЛОВИЯ, связывающая ТРИГГЕР с ИНФОРМАЦИОННЫМ ОБЪЕКТОМ.

Если условия удовлетворяются, один триггер может инициировать одну или несколько транзакций. И наоборот, одна транзакция может быть инициирована различными триггерами. Скажем, при проверке складских запасов активизирующим событием может служить определенный момент времени (например, ежечасно проверяется наличие на складе некоего минимума запасов). Другим событием может быть бухгалтерская проводка складского запаса.

А.3.2.3.3. Объектно-ориентированная спецификация проекта

Одним из аспектов парадигмы объектно-ориентированного проектирования является наличие тесных взаимосвязей между фазами жизненного цикла. Проектируемые элементы на уровне определения требований следует в идеале реализовать с мощностью 1:1. Для этого существует ряд методов, один из которых — экспресс-создание прототипов. Тем не менее фазовые концепции характерны даже для объектно-ориентированного проектирования. Однако границы между определением требований, спецификацией проекта и описанием реализации не являются жесткими. Поскольку эти методы моделирования вышли из недр объектно-ориентированного программирования, они в значительной мере аналогичны описанию реализации. В свете этого в некоторых работах (например: Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 66) предлагается использование диаграмм взаимодействия только на уровне определения требований (фаза анализа), тогда как за спецификацией проекта (фаза проектирования) уже закреплены диаграммы классов, последовательностей и состояний. Другие авторы применяют одни и те же методы и диаграммы на обоих уровнях с той лишь разницей, что на стадии спецификации проекта их описание подвергается дальнейшей детализации.

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

А.3.2.3.3.1. Общая детализация

Мы можем разграничить внутренние методы и методы, доступные извне.

Определяются типы атрибутов классов с техническими свойствами, такими как гарантии, начальные значения и параметры (см. рис. 125). Гарантиями называются условия, которым должны удовлетворять объекты. Параметры в операциях указывают, для каких критериев возможен перенос значений после запуска операций. В примере на рис. 125 очевидно представлено, что атрибут «радиус» не должен быть отрицательным (гарантия), центральная точка по умолчанию имеет начальное значение х = 10, у = 10, а окружностью можно манипулировать (если она не отцентрирована на экране) путем изменения координат (положения) центральной точки или ввода новых параметров для создания других радиуса.

Рис. 125. Технические свойства атрибутов (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 36)

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

Термины «программы» и «модули» также используются в объектно-ориентированном системном проектировании; здесь модули содержат код классов, которые им присваиваются, или же связываются с файлами исходного кода и файлами трансляции.

Модули и их взаимосвязи отображаются компонентными диаграммами. Чаще всего их метаструктуры совпадают с метаструктурой отображения модулей. Управление версиями в значительной степени зависит от описания компонентов или модулей.

Термин «пакет» выполняет аналогичную функцию применительно к группировке элементов объектно-ориентированного описания. Пакеты не содержат физических кодов, а лишь объединяют элементы моделирования. Иногда термины «пакет» и «модуль» используются как синонимы.

Модули и пакеты являются компонентами UML и описываются с помощью компонентных диаграмм (см. рис. 126).

Рис. 126. Компонентная диаграмма UML

А.3.2.3.3.2. Связи с базами данных

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

С другой стороны, если в объектно-ориентированном проектировании используются реляционные системы баз данных, могут возникать проблемы со связью двух парадигм проектирования. По умолчанию возможно применения двух противоположных методов для решения этого вопроса (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 136).

Метод 1. Каждый объект каждого класса хранится только в одном отношении, поэтому необходимо обновлять различные виды кортежей в таблице. Принцип метамодели требует, чтобы все КЛАССЫ были связаны только с одним ОТНОШЕНИЕМ (см. рис. 127а).

Рис. 127а. Каждый долговечный объект хранится в реляционной таблице

Метод 2. Для каждого класса создается отдельная таблица с мощностью ассоциации 1:1 (см. рис. 127б). При этом возникает необходимость в группировке данных из нескольких доминирующих классов для объектов подклассов.

Рис. 127б. Каждому классу присваивается отношение

Компромиссным решением было бы хранить данные на самом нижнем уровне подклассов (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 137). Это означало бы группировку всех взаимосвязанных данных в одном объекте. Однако в этом случае при обращении к доминирующим классам с множеством подклассов сначала пришлось бы сгруппировать данные из множества таблиц.

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