События (events) в нотации BPMN — одновременно и самая мощная, и самая сложная в изучении составляющая. Их много (все новые виды событий появляются в новых версиях BPMN), и сразу не очень понятно когда, как и для чего использовать то или иное событие. В результате не только пользователи, но и разработчики BPMS делают ошибки — реализуют события не так, как предписано стандартом.
Я бы выделил два уровня вопроса: 1) формальный и 2) содержательный. Одно дело — дать правильное определение, а другое — понимать, чем данный тип события отличается от других и в каких ситуациях им следует воспользоваться.
В этой заметке я остановлюсь на событии типа “сигнал”.
Сигнал, как и сообщение (message) служит для синхронизации и обмена информацией между разными частями процесса. Отличаются друг от друга они тем, что:
- Траектория сообщения явно рисуется на диаграмме пунктирной стрелкой (message flow), в то время как в случае сигнала источник и приемник неявно связываются друг с другом по имени сигнала. То есть если у вас на диаграмме (или на разных диаграммах) изображен источник сигнала (throw — закрашенный треугольник), под которым написано “мы победили”, то ищите приемник (catch — незакрашенный треугольник) с такой же подписью на этой и/или других диаграммах.
- Сообщения могут ходить только между разными пулами (читай — между разными процессами), а для сигналов такого ограничения нет.
- И самое главное различие: сообщение идет от точки к точке: от экземпляра процесса-отправителя к одному определенному экземпляру процесса-получателя (забудем на минуточку о стартовых событиях, start events). Соответственно, чтобы процессный движок смог отправить сообщение, необходимо задать идентификатор процесса-получателя — например, через атрибут процесса. Сигнал же идет от одного экземпляра процесса ко многим: ко всем экземплярам, ожидающих сигнала с данным именем в текущий момент. То есть message — это адресное, а signal — широковещательное сообщение.
ОК, с формальной стороной дела разобрались. А что с содержательной?
BPM Часть 2. Нотации и ПО моделирования Бизнес-процессов
Стандарт BPMN 2.0 дает такой комментарий: “Сигнал BPMN похож на сигнальную ракету, выстрелянную в небо для любого, кому интересно ее увидеть и среагировать.” Я бы предпочел пример хоть как-то относящийся к букве “B” в BPMN, т.е. к бизнесу.
Я не сразу смог придумать применение для сигнала. Сложность в том, что отправитель обязан быть уникальным в том смысле, что в любой момент времени может существовать только один экземпляр такого процесса. Т.е. это должен быть процесс, играющий особую роль в жизни организации — роль координатора или триггера для множества других процессов.
В итоге я нашел примеры таких процессов в планировании.
Например, пусть компания принимает заказы от клиентов, менеджер согласует поступивший заказ с клиентом и размещает его в очередь производственных заказов. Ежедневно в конце дня запускается процедура планирования, которая анализирует поступившие заказы и рассчитывает производственный график на завтра. По завершению планирования все связанные с клиентским заказом процессы получают сигнал о том, что график составлен, и могут, например, уведомить об этом клиента. Постановка пусть очень упрощенная, но весьма типичная для планирования.
Как описать простой бизнес-процесс. Пример
Эту задачу можно решить и при помощи сообщений, но тогда вместо одного сигнала нам придется послать множество сообщений — по одному каждому клиентскому процессу:
На первый взгляд, вариант с сигналом выглядит проще, и это можно считать его преимуществом, но только на первый взгляд.
Ведь ввообще говоря, заказов может оказаться больше, чем мы способны произвести в течении дня, и тогда часть их останется в очереди. Чтобы это учесть, надо в клиентском процессе проверить, попал ли наш заказ в график и если нет, вернуться к ожиданию сигнала:
Как видите, схемы получаются примерно одинаковые по сложности, и какую из них предпочесть — дело вкуса.
06.09.10 | Статьи | BPMN, BPMS, pattern, signal
Комментарии (12)
German 08.09.10 22:25
Отлично написано, но событий там куча! будет еще что то про них?
А еще расскажите пожалуйста по какому принципу вы выставляете типы процессов.
Anatoly Belychook 09.09.10 08:55
Так это же здорово, когда куча событий! Как говорится, нет повода не выпить В октябре я буду проводить тренинг по BPMN, там будет подробнее и про события, и про типы задач.
Сергей Кузин 09.09.10 10:08
Анатолий, в процессе “От заказ до оплаты” перед действием “Отправить заказ в производство” стОит ли добавить промежуточное событие “Ждать запрос от производства”? Ведь отправка произойдёт лишь в конце рабочего дня…
Ещё вариант реализации примера — экземпляр процесса “От заказа до оплаты” после согласования заказа выдаёт сигнал типа “Есть согласованный заказ”, и тогда процесс “Планирование производства” обращается за согласованными заказами только к этим экземплярам процессов в конце рабочего дня (но он должен фиксировать полученные сигналы).
Третий вариант — после согласования все заказы помещаются в отдельное хранилище/буфер/очередь (можно реализовать отдельным процессом?), к которому в конце рабочего дня обращается процесс планирования и выбирает заказы согласно некоторым правилам (объёмы, приоритеты, сроки, …).
Чётвёртый вариант — сам процесс планирования может послать сигнал экземплярам процессов “От заказа до оплаты” о списке попавших в график заказов.
Anatoly Belychook 09.09.10 11:15
Сергей В моей схеме заказ отправится в производство сразу после того, как он успешно согласован. Отправка эта заключается в том, что в таблицу базы данных “Очередь заказов” добавляется запись. А производство (диспетчер-планировщик) прочтет заказы в конце дня. Причем не один, а сразу все накопившиеся заказы.
Это похоже на Ваш третий вариант, только без отдельного процесса (зачем он?). По второму варианту: фиксировать полученные сигналы, и что с ними делать? Наверное, складывать в базу данных? А зачем так сложно, когда можно сразу складывать в базу безо всяких сигналов. А.Б.
Сергей Кузин 09.09.10 11:52
В третьем варианте я стал добавлять отдельный процесс для буфера как раз потому, что про записи в базу данных никакой информации на диаграммах нет (реализация при просмотре диаграммы неочевидна, а часто возникает вопрос, куда же делись заказы). По второму варианту — просто ещё один из способов реализации, пусть и неоптимальный
Сергей Кузин 09.09.10 12:05
За пример — отдельно спасибо!
Anatoly Belychook 09.09.10 12:16
Как это нет информации на диаграммах? А что означает data object, подписанный “Заказы на производство”, и входящие-выходящие в него стрелки?! Это какое-то массовое умопомрачение: люди рисуют процессные диаграммы так, как будто кроме процессов ничего больше нет. Особо продвинутые добавляют еще сигналы. А как же данные?
Они никуда не деваются, отказываться от баз данных никто не собирается, и это законный способ коммуникации между процессами.
German 09.09.10 23:26
а про тренинг можно поподробнее
Anatoly Belychook 10.09.10 09:25
Следите за объявлениями.
Ирина 13.09.10 13:56
Очень интересные возможности могут открыться в будущем по использованию событий типа “сигнал”. На семинаре по “автоматизации процессов в вузе” вы говорили можно использовать стиль “каскад со смещением”, т.к работы не всегда выполняются по плану. Так вот управляющие сигналы смогут координировать действия при таком стиле выполнения.
Например, запланировано сделать точно заказ к определенной дате, но он сделан на неделю позже. Можно выставить формальный диапазон ожидания, не плановый, а с запасом. В вузе по плану диплом на проверку надо сдать в определенную дату, но по факту сдают намного позже. Также ожидание сигнала может стать гарантией, что процесс все равно продолжится независимо от того когда пришел сигнал (это определенная страховка).
Anatoly Belychook 13.09.10 14:08
Ирина Только не упускайте из виду принципиальный момент: сигнал шлется всем, кто его слушает, без исключения. Например, если 10 студентов из группы сдали курсовик на проверку, то реализовать при помощи сигнала ожидание оценки от преподавателя не получится, потому что сигнал от преподавателя получит не одна группа, а студенты всех факультетов и курсов, ожидающие оценку.
Надо использовать сообщения. В примере, разобранном в этой заметке, фокус в том, что процесс планирования принципиально один. Если же у компании несколько производственных площадок, планирование на каждой из которых выполняется независимо, то, опять-таки, использовать сигнал не выйдет. А.Б.
Источник: mainthing.ru
10.4. Событие
Событие – это то, что происходит в течение Бизнес-процесса или его Хореографии . Событие оказывает влияние на ход Бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Объемное понятие « Событие » включает в себя такие попадающие под эту категорию явления Процесса , как: старт Процесса , его завершение, смена статуса задействуемого документа, получение Сообщения и мн.др.
Согласно влиянию Событий на ход Бизнес-процесса , выделяют три типа:
Графический язык моделирования бизнес-процессов BPMN. Версия 2.0
1. Стартовое событие (указывающее на точку запуска Процесса )
2. Конечное событие (указывающее на точку завершения Процесса )
3. Промежуточное событие (указывающее на что-то, происходящее на ограниченном Стартовым и Конечным Событиями отрезке Процесса ).
Вышеперечисленные типы Событий , в свою очередь, могут:
Обрабатывать триггер . Такими являются все Стартовые и некоторые Промежуточные События .
Определять результат (возбуждать триггер) . Такими являются все Конечные и некоторые
Промежуточные События . Они МОГУТ влиять на другие События . Как правило, триггеры
передают информацию из места, где произошло такое Событие , туда, где находится реагирующее на триггер Событие . Согласно стандартам BPMN , возбуждение триггера МОЖЕТ БЫТЬ скрытым (или каким-либо другим, являющимся разновидностью скрытого) или явным (при содействии определяющего результат События ).
Фигура 10.69 – Диаграмма классов элемента Event
10.4.1. Общее представление о Событии
В зависимости от типа События , применяются различные способы запуска триггера в направлении реагирующего на него События : публикация, вынесение непосредственного решения, распространение, отмена, а также компенсация.
Графический язык моделирования бизнес-процессов BPMN. Версия 2.0
В рамках публикации триггер МОЖЕТ быть получен Событием , находящимся в любой части системы, где производится публикация данного триггера . События , для которых используется данный способ возбуждения триггера , образуют группу Обмена сообщениями . В качестве триггеров здесь выступают События , сформированные за рамками Пула , в котором производится их публикация. Обычно они используются для описания B2B модели сообщения между разными Процессами разных Пулов . Для указания определенного экземпляра Процесса в момент, когда такое Сообщение должно достичь данного экземпляра Процесса , используется корреляция . Триггеры , называемые Сигналами , формируются в Пуле , где производится их публикация. Как правило, они используются для распространения Сообщения в Процессах и между ними, а также между Пулами и диаграммами Процессов .
Триггеры , называемые Таймер и Условие , запускаются скрыто. После запуска они ожидают условия, при котором могут повлиять на Событие , обрабатывающее триггер . Эти условия могут быть основаны на временном или статусном критериях.
Триггер , используемый в качестве распространения, передается от места, где было запущено Событие , к наиболее удаленному месту экземпляра (например, на другой уровень Процесса ), к которому привязано Событие , реагирующее на триггер . Триггер , используемый в качестве Ошибки , является критичным и прекращает выполнение в месте его запуска. Эскалация , в свою очередь, критичной не является, а выполнение продолжается в месте запуска этого триггера . В случае, если для двух последних типов триггеров не определено ни одного реагирующего на них События , они считаются невыполненными (неразрешенными). В рамках Процесса или определенного экземпляра Действия рекомендуется использовать завершение, компенсацию , а также отмену . Завершение используется для указания того, что выполнение всех Действий , содержащихся в Процессе или другом Действии , должно быть немедленно завершено (без компенсации или использования
События ). Это касается все экземпляров многоэкземплярного Действия или Процесса .
Компенсация удачно выполненного Действия запускает обработчика этой компенсации . Обработчик компенсации может быть двух типов: определяемый пользователем и скрытый. Скрытый обработчик компенсации , используемый для Подпроцесса , вызывает обработчики компенсаций всех содержащихся в нем Действий в последовательности, обратной Потоку операций . В случае, если вызываемая компенсация предназначается для ещё не выполненного или неудачно выполненного Действия , она никак себя не проявляет (в частности, не возникает никаких ошибок).
Отмена прерывает выполнение всех активных Действий и компенсирует все успешно выполненные Действия Подпроцесса , для которого она используется. Если этот Подпроцесс является Транзакцией , то он возвращается в начало.
Моделирование данных в Событиях
Некоторые События (например, Сообщение, Эскалация, Ошибка, Сигнал, Множественное ) могут содержать в себе данные. Для продвижения данных от реагирующего на триггер События к элементу данных используется Ассоциация данных . Однако при использовании Событий , содержащих данные, должны быть приняты во внимание следующие ограничения:
Если Событие связанно с множеством элементов EventDefinitions , то каждому из этих элементов ДОЛЖЕН соответствовать один Вход для данных (если Событие определяет результат ) или один
Выход для данных (если Событие реагирует на триггер ) События . Порядок расположения элементов EventDefinition и порядок размещения Входов/Выходов для данных определяют, какой Вход/Выход какому элементу соответствует.
Если Событие имеет вход/выход для данных , то для каждой пары «элемент EventDefinition — вход/выход для данных » ДОЛЖЕН БЫТЬ определен элемент ItemDefinition , значение которого равно значению, установленному для элементов ItemDefinition Сообщения ,
Эскалации , Ошибки или Сигнала . В случае, если Событие определяет результат и не имеет входа для данных , то данные в Сообщение, Эскалацию , Ошибку или Сигнал переданы не будут. Если
Графический язык моделирования бизнес-процессов BPMN. Версия 2.0
же Событие реагирует на триггер и не имеет выхода для данных , то данные из Сообщения,
Эскалации, Ошибки или Сигнала не покинул пределы этого События и не попадут в Процесс .
Во время выполнения События ведут себя следующим образом:
Определяющие результат События . После запуска События , соответствующий элемент EventDefinition ссылается на входные данные , автоматически переданные в Сообщение ,
Эскалацию, Ошибку и Сигнал .
Имеющие триггер События . Когда появляется предназначенный для данного События триггер (например, при получении Сообщения ), данные автоматически передаются на выход для данных , соответствующий элементу EventDefinition с описанием триггера .
Общие атрибуты События
Элемент Event наследует атрибуты и ассоциации элемента FlowElement (см. таблицу 8.44). Таблица 10.81 содержит информацию о дополнительных ассоциациях элемента Event .
Таблица 10.81 – Ассоциации элемента Event
properties : Property [0..*]
Источник: studfile.net
Элементы потока (Действие, Событие, Шлюз)
получить практический опыт моделирования бизнес-процессов в нотации BPMN.
Программное обеспечение: онлайн-сервис http://storm.bpmn2.ru/ или BPMN.Studio
2. Задачи
Основными задачами лабораторной работы являются: закрепление и расширение теоретических знаний учащихся, приобретение навыков моделирования простых процессов в нотации BPMN.
Порядок выполнения работы
1. Изучить предлагаемый теоретический материал.
2. Выполнить задание 1, задание 2
Теоретические сведения
Бизнес-процесс определяется как логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей. Международный стандарт ISO 9000 определяет организацию как группу работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений. По-другому организацию можно определить как систематизированное, сознательное объединение действий людей, преследующих достижение конкретных целей. Организация может быть корпоративной, государственной или частной.
Бизнес-процесс в узком смысле можно определить как набор связанных процедур, направленных на достижение определенного результата, представляющего ценность для потребителя. Бизнес-процесс использует определенные ресурсы (финансовые, ма- териальные, человеческие, информационные) для преобразования входных элементов в выходные.
Важным шагом структуризации деятельности любой организации являются выделение и классификация бизнес-процессов. Можно выделить следующие классы процессов: основные процессы; обеспечивающие процессы и процессы управления.
Основными бизнес-процессами являются процессы, непосредственно связанные с созданием стоимости, ориентированные на производство товаров или оказание услуг, составляющих основную деятельность организации и обеспечивающих получение дохода.
Обеспечивающие бизнес-процессы не увеличивают ценность продукта или услуги для потребителя, но необходимы для деятельности предприятия. Они предназначены для поддержки выполнения основных бизнес-процессов. Такими процессами являются финансовое обеспечение деятельности, обеспечение кадрами, юридическое обеспечение, администрирование, обеспечение безопасности, поставка комплектующих материалов,
ремонт и техническое обслуживание и т.д.
Бизнес-процессы управления — это процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и системы в целом. Примерами таких процессов могут быть процессы стратегического, оперативного и текущего плани- рования, процессы формирования и выполнения управляющих воздействий. Процессы управления оказывают воздействие на ice остальные процессы организации.
Бизнес-модель — это формализованное (в данном случае — графическое) описание процессов, связанных с ресурсами, и отражающих существующую или предполагаемую деятельность предприятия.
Построение бизнес-моделей заключается в применении различных методов и средств для визуального моделирования бизнес-процессов. Цели моделирования:
· обеспечить понимание структуры организации и динамики происходящих в ней процессов;
· обеспечить понимание текущих проблем организации и возможностей их решения;
· убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации;
· создать базу для формирования требований к будущей ИС организации. Основная область применения бизнес-моделей — это реинжиниринг бизнес-процессов.
При этом предполагается построение моделей текущей и перспективной деятельности, а также пла- на и программы перехода из первого состояния во второе. Любое современное предприятие является сложной системой, его деятельность включает в себя исполнение десятков тысяч взаимовлияющих функций и операций. Человек не в состоянии понимать, как такая система функционирует в деталях — это выходит за границы его возможностей. Поэтому главная идея создания моделей «AS-IS» и «AS-TO-BE» — понять, что делает (будет делать) рассматриваемое предприятие и как оно функционирует (будет функционировать) для достижения своих целей.
Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) Это методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG). В отличие от других методологий бизнес- моделирования, имеющих статус «фирменного» (EPC) или «национального» (IDEF0) стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology — Object Management Group. Business Process Model and Notation».
Основной целью BPMN является обеспечение доступной нотацией описания бизнес-процессов всех пользователей: от аналитиков, создающих схемы процессов, и разработчиков, ответственных за внедрение технологий выполнения бизнес-процессов, до руководителей и обычных пользователей, управляющих этими бизнес-процессами и отслеживающих их выполнение. Таким образом, BPMN нацелен на устранение расхождения между моделями бизнес-процессов и их реализацией.
По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:
— UML (Unified Modeling Language, Унифицированный язык моделирования):
В стандарте также отмечается, что для большей читабельности и гибкости в методологии BPMN продолжены традиции блок-схем.
Поддержка и дальнейшее развитие BPMN организацией OMG наложило свой «отпечаток» на данную методологию. Одним из ключевых направлений OMG является продвижение UML, предназначенного для моделирования объектно-ориентированных систем. В связи с этим, в BPMN при моделировании (разработке диаграмм), помимо понятий и концепций структурного подхода (действие, поток управления, объект данных и т.д.), используются такие характерные для объектно-ориентированного подхода понятия, как сообщение, обмен сообщениями и поток сообщений.
Элементы (символы) графической нотации BPMN по назначению объединены в категории:
— Объекты (элементы) потока (Flow Objects);
— зоны ответственности (Swimlanes, разделительные дорожки);
— соединяющие элементы (Connecting Objects, связи);
Важно отметить, что одной из причин создания BPMN явилась необходимость построения простого механизма для моделирования как простых, так и сложных моделей бизнес- процессов. Для удовлетворения двух этих противоречащих требований был применен подход систематизации графических элементов нотации по категориям.
Элементы потока являются важнейшими графическими элементами, определяющими ход бизнес- процесса. Элементы потока, в свою очередь, делятся на:
· Действия (бизнес-функции, Activities);
Данные на диаграмме могут быть представлены любыми из следующих четырех элементов:
· Объект данных (Data Objects)
· Входные данные (Data Inputs)
· Выходные данные (Data Outputs)
· Хранилища данных (Data Stores)
Выделяют четыре вида соединяющих Элементов потока, связывающихся друг с другом и с другими элементами:
· Поток операций (Sequence Flow);
· Поток сообщений (Message Flow);
· Ассоциация данных (Data Associations).
Существуют два способа группировки основных элементов моделирования с помощью Зон ответственности:
· Группировка с помощью Пула (Pool);
· Группировка с помощью Дорожки (Lane).
Артефакты используются для добавления дополнительной информации о Процессе.
Выделяют два типовых Артефакта, что не запрещает разработчикам моделей бизнес-процессов либо программам моделирования добавлять любое необходимое количество Артефактов. На данный момент текущий перечень Артефактов включает в себя следующие элементы:
· Текстовая аннотация (Text Annotation).
Таблица 4. Базовый набор элементов моделирования
| Элемент | Нотация |
| Событие (Event) |  |
| Действие (Activity) |  |
| Шлюз (Gateway) |  |
| Поток операций (Sequence Flow) |  |
| Поток сообщений (Message Flow) |  |
| Ассоциация (Association) |  |
| Пул (Pool) |  |
| Дорожка (Lane) |  |
| Объект данных (Data Object) |  |
| Сообщение (Message) |  |
| Группа (блок, содержащий группу объектов одной категории) (Group) |  |
| Текстовая аннотация (связана с Ассоциацией) (Text Annotation) |  |
Элементы потока (Действие, Событие, Шлюз)
Действие (Activity)
Действия изображаются прямоугольниками с закругленными углами. Они подразделяются на Задачи (Task) – элементарные действия, не подлежащие декомпозиции, и Подпроцессы (Sub-Process) – составные действия, которые сами могут быть представлены в виде бизнес-процесса.
Задачи бывают нескольких видов:
· Пользовательская задача — самая распространённая Задача, где человек участвует в качестве исполнителя
· Ручное выполнение — представляет собой Задачу, выполнение которой подразумевает действия человека и исключает использование каких-либо автоматизированных механизмов исполнения или приложений. Ручное выполнение не поддается управлению никаким механизмом выполнения бизнес-процесса. Такой тип Задач можно отнести к неуправляемым, т.е. к Задачам, начало и завершение выполнения которых не отслеживается механизмами выполнения бизнес-процесса. В случае BPMS-систем (систем управления бизнес-процессами), это предполагает собой некоторое действие, которое исполнитель выполняет за рамками системы. Примером такого типа Задач может служить установка телефонного аппарата на территории заказчика специалистом по обслуживанию телефонов или проведение совещания.
· Задача-сценарий — тип Задачи, которые выполняются без участия человека, обозначающее выполнение в процессе некоторого автоматизированного действия. То есть оно выполняется без конкретного исполнителя средствами самой BPMS-системы. Например, это может быть подсчет каких-либо данных — подсчет сумм, введенных пользователем. Такая работа прекрасно выполняется компьютером без участия человека. BPMS-система не только делает это быстрее, но еще и никогда не ошибается в расчетах.
Подпроцессы могут быть изображены на диаграмме в свернутом или развернутом виде. Задачи и свернутые и развернутые подпроцессы могут быть снабжены маркерами, указывающими некоторые
характеристики их выполнения. В частности, Маркером обозначаются действия, выполняющиеся циклично до тех пор, пока не будет соблюдено заданное условие выхода из цикла. Элементы нотации BPMN, изображающие действия, представлены на рис. 4.1.
Рис 4.1. Элементы BPMN: действия
Событие (Event)
События BPMN служат для обозначения различных событий, которые могут начать, прервать и закончить ход процесса. Изображается в виде круга со свободным центром.
События разделяются на:
· Стартовые (начальные) — указывают на то, в какой точке берет начало тот или иной процесс. В контексте потока операций Стартовое событие является начальной точкой в процессе; это означает, что никакой входящий поток операций не может быть соединен со стартовым событием.
· Конечные — указывают на то, в какой точке завершается тот или иной процесс. В контексте Потока операций Конечное событие завершает ход Процесса; это означает, что никакой Исходящий поток операций не может быть соединен с Конечным событием.
Конечное событие представляет собой круг, выполненный одиночной, жирной линией. Толщина линии должна быть жирной настолько, чтобы без труда можно было отличить Конечное событие от Стартового.
· Промежуточные – указывает на то, что происходит на отрезке Процесса, ограниченном Стартовым и Конечным событиями. Промежуточное событие влияет на ход Процесса, однако, не может являться его началом или непосредственным завершением. Промежуточное событие представляет собой круг, который должен быть выполнен двойной тонкой линией.
Кроме того, некоторые типы Событий, используемые в BPMN 1.1 для прерывания хода Действия, в редакции BPMN 2.0 могут использоваться для других целей. Такое Событие изображается в виде круга с пунктирными границами.
Промежуточные и большинство начальных событий могут быть снабжены триггерами 1 , которые отражают причину события.
В нотации BPMN определены следующие типы триггеров:
· Простое — нетипизированное событие, обычно показывающее начало или окончание процесса;
· Сообщение (Message) – исходит от некоторого участника или триггера процесса и предшествует началу, продолжению или окончанию некоторого действия процесса;
· Таймер (Timer) – устанавливает цикл времени течения процесса;
· Ошибка (Error) – генерация или обработка заданного типа ошибок;
· Эскалация (Escalation) – перенос рассмотрения вопроса на более высокий уровень организационной иерархии;
· Отмена (Cancel) – указывает на отмену события;
· Компенсация (Compensation) – показывает, как подпроцесс может быть скомпенсирован последовательностью отката;
· Условное (Conditional) – реакция на изменение бизнес-условий или интеграция бизнес-правил
· Связь (Link) – представляет собой механизм, обеспечивающий подключение окончания события одного потока процесса к началу события другого потока процесса;
· Сигнал (Signal) – передается между процессами и может обрабатываться многими получателями;
· Множественный (Составное событие, Multiple) – указывает на то, что событие может задействовать несколько путей развития процесса или продолжить процесс в случае наличия промежуточного события.
· Параллельное составное событие (Parallel Multiple) – обработка всего множества параллельных событий
· Завершение (Terminate) – вызывает немедленное прекращение выполнения процесса
Путем уточнения конечных событий можно указать результат бизнес-процесса. Основные элементы нотации BPMN, изображающие события, представлены на рис. 2.
1 Триггер (в нотации BPMN) – некое условие или ограничение.
Шлюз (Gateway)
Рис 2. Элементы BPMN: события
Шлюзы изображаются ромбами и представляют точки принятия решений в процессе. С помощью логических операторов организуется ветвление и синхронизация потоков управления в модели процесса. Они бывают единственного, множественного и сложного выбора, а также параллельного исполнения.
Шлюзы единственного выбора разделяются на основанные на данных(решение о дальнейшем ходе процесса принимается на основе проверки условий, заданных для переходов) и основанные на событиях (решение принимается исходя из происходящего в данной точке события, например получения сообщения или срабатывания таймера). Виды шлюзов, определенные в BPMN, представлены на рис. 4.3.
 |
Рис 4.3. Элементы BPMN: шлюзы
Дата добавления: 2021-07-19 ; просмотров: 121 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
