Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

А.3.2.1.2.1. Правило СУД

Читайте также:
  1. Вибір оптимального рішення за правилом максИмакс
  2. Закон электромагнитной индукции. Правило Ленца
  3. Как правило, под кадастром понимается упорядоченная совокупность вероятных сведений о правовом, природном, хозяйственном и экономическом состоянии каких либо объектов.
  4. Правило 1. Не уклоняйтесь от встреч
  5. Принцип суперпозиции - правило наложения (Большая советская энциклопедия).
  6. Различие в общественном положении создаёт новые потребности, которые неодинаковы для всех людей. Таким образом, природный закон представляется правилом не всеобщим?

В информатике для регулирования управляющих потоков применяется правило СУД (событие-условие-действие) (Dittrich, Gatziu. Aktive Datenbanksysteme. 1996, с. 10), хотя правила СУД описывают также и бизнес-правила (Herbst, Knolmayer. Geschd ftsregeln. 1995).

События характеризуют направленные действия, заключая в себе факты (что), происходящие в определенный момент времени (когда). В рамках временных событий «что» и «когда» совпадают (например, 6 часов вечера). Условия задают обстоятельства наступления соответствующего события. Действия определяют реакцию на возникновение той или иной ситуации.

В моделях бизнес-процессов ARIS события создаются обрабатывающими функциями или субъектами действия, находящимися за рамками модели. В процессе моделирования отбираются релевантные события, поэтому в модель включаются только те события, которые влияют на бизнес-процесс. Таким образом, условия входят в описание события, сводя правило СУД к правилу СД (событие-действие).

Вместо уравнения «событие = общая сумма заказа известна» с последующей проверкой условия «общая сумма заказа > 5000 долл.» (сценарий (а) на рис. 107) мы для начала введем два возможных релевантных события (сценарий (б) на рис. 107).

 

Рис. 107. Способы моделирования событий

 

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

Связи между событиями могут быть сложными и разнообразными. Например, для активизации некоторой функции может потребоваться несколько событий, при этом иногда играет роль даже последовательность их наступления. Такие сложные события можно описывать «алгебраически», используя операторы дизъюнкции (логического сложения), последовательности, конъюнкции (логического умножения) и отрицания (Dittrich, Gatziu. Aktive Datenbanksysteme. 1996, с. 26).

A.3.2.1.2.2. Событийные диаграммы процессов (СДП)

Метод СДП английской версии - ЕРС) разработан Институтом информационных систем (IWi) Университета Саарланда (Германия) в сотрудничестве с фирмой SAP AG (Keller, Nuttgens, Scheer. Semantische Prozefimodellierung. 1992). Этот метод является ключевым компонентом концепций моделирования SAP R/3 для бизнес-инжиниринга и индивидуальной настройки бизнес-приложений.

Метод основан на концепциях стохастических сетей и сетей Петри. В упрощенных версиях содержатся только описания событий и действий, а условия и сообщения опускаются.

Одно событие может повлечь за собой выполнение нескольких функций. С другой стороны, для инициации события иногда предварительно требуется завершение нескольких функций. Логические отношения описываются символами «и» (/\), «включающее ИЛИ» (\/) и «исключающее ИЛИ» (XOR). На рис. 108 приведены типичные примеры отношений между событиями.

Рис. 108. Отношения между событиями в ЕРС

 

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

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

В связи с изложенным на рис. 110 класс СОБЫТИЕ представлен как подкласс ИНФОРМАЦИОННОГО ОБЪЕКТА. Логические отношения между событиями моделируются ассоциацией между ЛОГИЧЕСКИМ ТИПОМ ОТНОШЕНИЯ (например, «и», «или») и СОБЫТИЕМ.

Многие поставщики бизнес-приложений предоставляют возможность конфигурирования программных решений под

конкретные нужды предприятия при помощи моделей бизнес-процессов. В качестве примера на рис. 109 показан фрагмент модели бизнес-процесса, построенной средствами Baan Dynamic Process Modeling (Baan. Dynamic Enterprise Modeling. 1996). Далее мы рассмотрим сеть Петри, основанную на модели, изображенной на рис. 110.

 

Рис. 109. Модель бизнес-процессов Baan (источник: IDS Prof. Scheer GmbH)

 

Рис. 110. Метамодель управления событиями и сообщениями (метод СДП)

 

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


Дата добавления: 2015-08-03; просмотров: 166 | Нарушение авторских прав


Читайте в этой же книге: А.2.3.3.4. Логические пути доступа | А.2.3.4. Реализация на уровне модели данных | А.2.4. Моделирование на уровне выходов | А.2.4.1. Определение требований на уровне модели выходов | А.2.4.2. Конфигурирование выходов | А.З.1.1.1. Диаграммы связи функция-организация | А.3.1.1.2. Диаграмма взаимодействия | А.3.1.2. Конфигурирование | А.3.2.1.1.1. Объектно-ориентированные диаграммы классов | А.3.2.1.1.3. Поток данных |
<== предыдущая страница | следующая страница ==>
А.3.2.1.1.4. Ассоциация экранов| А.3.2.1.2.3. Диаграммы состояний

mybiblioteka.su - 2015-2024 год. (0.008 сек.)