Справочник по символу BPMN 2.0
Описание всех символов BPMN 2.0 с примерами.
Бесплатный BPMN инструмент
Cawemo - это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.
Бесплатный BPMN инструментОбзор
Обзор элементов
Событие
Осторожно!
Для понимания принципиального поведения событий в BPMN, проверьте документацию События: Основные понятия.
Тип | Стартовые | Промежуточные | Конечные | |||||
Обычные | Событие подпроцесса | Событие подпроцесса
независимые |
Пойманые | Граница | Граница
независимые |
Переброска | ||
Нет | ||||||||
Сообщение | ||||||||
Таймер | ||||||||
Условное | ||||||||
Link | ||||||||
Сигнал | ||||||||
Ошибка | ||||||||
Эскалация | ||||||||
Уничтожение | ||||||||
Компенсирующие | ||||||||
Отмена | ||||||||
Мульти | ||||||||
Мульти параллельные |
Участники
Представляем пулы, дирижер и оркестр
Мы уже описали, как использовать полосы для назначения ответственности за задачи или подпроцессы для разных менеджеров задач. Лейны всегда существуют в пуле, а границы полосы представляют собой границы процесса от начала до конца. Для BPMN пул представляет собой более высокий экземпляр по сравнению с его полосами. Пул предполагает управление процессом - другими словами, он назначает задачи. Он ведет себя как дирижер оркестра, и поэтому этот тип процесса называется «оркестровкой»."
На приведенной ниже диаграмме «проводник» устраивает Фалко для обработки задачи 2, как только Роберт завершает задачу 1. Проводник имеет контроль над процессом на самом высоком уровне, и каждый инструмент в оркестре воспроизводит мелодию, которую дирижер решает:
Считаете ли вы, что это нереально? У многих опытных моделеров процесса есть проблемы с этим способом мышления. Они предпочли бы моделировать последовательность процессов, как показано ниже, исходя из предположения, что в их компании нет всемогущего проводника и что отдельные участники процесса должны сами координировать и сотрудничать:
Но для координации сотрудничества с BPMN требуется явное моделирование. Каждый диспетчер задач назначает отдельный пул, и процесс переходит от одного к другому как поток сообщений, как показано ниже. В принципе, это создает четыре независимых проводника. Они имеют контроль над своими соответствующими мини-процессами, но они не могут ничего делать, кроме как отправлять сообщения, которые запускают их процессы-преемники:
Это кажется сложным - и вам не нужно выбирать этот метод для практического моделирования. Однако он раскрывает основной принцип, который вы должны понимать. Несмотря на то, что полосы BPMN очень похожи на полосы других обозначений процессов, они представляют собой совершенно другой способ мышления, который мы связываем с происхождением BPMN в мире автоматизации процессов. В этом мире механизм процесса контролирует все задачи в процессе, даже если разные менеджеры задач могут их выполнять. Таким образом, технологический механизм приравнивается к таинственному, всемогущему проводнику процесса.
Вы слышали об организации оркестровки в связи с сервис-ориентированной архитектурой (SOA)? Это почти точно задача механизма процесса, за исключением того, что эти сервисы являются не только полностью автоматизированными веб-службами; они также могут быть задачами, выполняемыми участниками процесса в соответствии с технологическим процессом. Что это значит, однако, для чисто функционального моделирования процессов, в котором вы также описываете процессы not , управляемые таким механизмом процесса? На этот вопрос нет общего ответа.
Вы можете исключить пулы и работать только с дорожками, моделируя обмен сообщениями как обычные задачи, как показано выше. Это традиционно, и это прагматическое решение во время, скажем, переходного периода, который позволяет вашим коллегам адаптироваться. В среднесрочной и долгосрочной перспективе, однако, избегая пулов, вы отказываетесь от мощного устройства для повышения значимости моделей процессов.
Мы покажем полезность этого нового мышления на примере. Следует помнить, что если вы будете стремиться гармонизировать свои функциональные и технические модели процессов для достижения лучшего соответствия бизнеса и ИТ, вы неизбежно столкнетесь с этим типом процесса моделирования, используете ли вы BPMN или нет.
Бассейны: искусство сотрудничества
Мы уже рассмотрели процесс, представленный ниже в связи с шлюзом на основе событий:
Теперь рассмотрим более общую картину и подумайте о том, как этот процесс происходит с точки зрения службы доставки пиццы. Предположительно, это выглядит так: Как только мы получим заказ, мы испекли пиццу. Наш заказчик берет его у клиента и собирает деньги, благодаря чему процесс завершается успешно.
мы хотим связать два процесса, то есть изучить взаимодействие клиента и службы доставки с нейтральной точки зрения. Мы можем попытаться смоделировать это взаимодействие с помощью пула и полос движения, как здесь:
Но это не работает: есть задачи и события, которые ссылаются на взаимодействие внутри пула - ожидание доставки, например, или сбор денег. Другие задачи выполняются по ролям, не обращая внимания на их партнеров, таких как выпекание пиццы и употребление пиццы. Нельзя различать эти два визуально. Строго говоря, диаграмма не является семантически корректной, потому что события сообщений всегда относятся к сообщениям, полученным процессом извне, и здесь это не так.
Если мы пойдем с пулами, весь процесс будет выглядеть ниже. Оба процесса в объединенном представлении будут выглядеть так же, как и раньше, но теперь они соединяются через потоки сообщений. BPMN называет эту форму визуализации диаграммой сотрудничества. Он показывает два независимых процесса сотрудничества.
В двух случаях потоки сообщений не заканчиваются действием или событием, а в границах соответствующих пулов участников. Первый - из задачи «запрашивать при доставке»; второй подключается к задаче «собирать деньги». Обоснование первого заключается в том, что наш запрос не влияет на поток последовательности поставщика. Служба пиццы может предоставить информацию или ускорить обработку заказа в ожидании нового заказа, но выпечка, доставка и сбор денег не меняются только потому, что приходит запрос. Что касается сообщений «собирать деньги», недостаток в модели процесса клиента: мы должны платить за пиццу до , мы ее ем, и эта задача все еще отсутствует. Мы добавили его на диаграмму ниже, и теперь мы можем напрямую подключить потоки сообщений к задаче «платить за пиццу».
Объединение пулов
Часто случается так, что мы не знаем процессов всех сторон в деталях. Например, мы можем знать о процессах нашей собственной компании, но не о компаниях-партнерах. До тех пор, пока наш партнер и мы придерживаемся согласованных интерфейсов, таких как прием или отправка определенных сообщений, все может работать плавно. Как клиенты службы доставки пиццы, мы ожидаем, что поставщик:
- Принимайте заказы на пиццу,
- Доставить заказанную пиццу и собрать деньги, и
- Быть доступным для запросов.
Как клиенты, мы мало интересуемся внутренним процессом поставщика. Возможно, он печет, а затем доставляет пиццу; возможно, когда у него нет предметов снабжения, он получает еще одну услугу пиццы, чтобы испечь пиццу и доставить ее. Это его проблема - мы просто ожидаем получить нашу пиццу. При моделировании таких случаев мы можем скрыть процесс доставки и свернуть пул:
Мы могли бы сделать еще один шаг и свернуть бассейн клиента. Теперь мы видим только обмен сообщениями, предполагая, что мы обозначаем стрелки, чтобы дать нам общую идею. Недостатком является то, что мы больше не можем распознавать взаимозависимости. Мы не можем видеть, всегда ли запрос всегда выходит или происходит только при определенных условиях - фактический случай:
Дорожки
Мы говорили о , что делать в наших процессах, но мы еще не объяснили , кто отвечает за выполнение этих задач. В BPMN вы можете ответить на этот вопрос дорожками.
Диаграмма показывает, что задачи в нашем примере были назначены конкретным людям. Мы можем получить после описания процесса из заданий: если Кристиан голоден, он выбирает определенный рецепт. В зависимости от того, что выбирает Кристиан, он может сам позаботиться (Готовить макароны), или он может получить его соседи по комнате на борту. Если последний, Фалко повара Стейк и Роберт готовит Салат. В итоге Кристиан ест. Три полосы (Кристиан, Фалко, Роберт) объединены в один пул, обозначенный «Сообщение с равным доступом».
- Позиции в первичной организации, например, бухгалтерский служащий.
- Роли во вторичной организации, например, сотрудник по защите данных.
- Общие роли, например, клиент.
- Отделы, например, продажи.
- ИТ-приложения, например, CRM-система.
Мероприятия
Задача
До сих пор мы использовали только задачи неопределенных типов, хотя BPMN предоставляет возможность работать с типами задач так же, как и для типов событий. Прежде всего, типы задач предназначены для моделирования процессов которые являются технически выполнимыми. На практике типы задач применяются нечасто. Однако по опыту мы знаем, что типы задач могут быть особенно полезны при разработке инженерных требований.
Маркеры задач
В дополнение к тем различным задачам мы можем отмечать задачи как циклы, несколько экземпляров или компенсаций. Маркеры могут быть объединены с назначенными типами.
Loop
Задача цикла повторяется до тех пор, пока определенное условие не будет применяться или перестанет применяться. Возможно, мы предлагаем разные блюда нашим гостям, пока все не согласятся. Затем мы можем приготовить еду:
В этом примере мы выполнили задачу сначала и проверили после этого, чтобы проверить, нужно ли нам снова выполнить ее. Программисты знают принцип как конструкцию «do-while». Однако мы можем также применить конструкцию «while-do» и, таким образом, проверить условие перед задачей, а не потом. Это происходит редко, но имеет смысл, если задача может вообще не выполняться.
Вы можете присоединить условие, в котором задача цикла выполняется в первый раз или, как показано в примере, применить условие к повторным выполнению в качестве аннотации к задаче. Вы можете сохранить это условие как атрибут на официальном языке вашего инструмента BPMN. Это имеет смысл, если процесс должен выполняться механизмом процесса.
Несколько экземпляров
Отдельные циклы задачи цикла должны следовать друг за другом. Если, например, мы живем в сообщении с равным доступом, и соседи по комнате считают, что есть пицца, задача «выбрать пиццу» должна быть повторяется для каждого соседа по комнате, прежде чем мы можем заказать. Вы сидели вместе и проходили меню, пока, наконец, все не приняли решение. Есть студенческие апартаменты где они do справляются с этим именно так - больше доказательств того, что у студентов слишком много времени на их руках! Для всех соседей по комнате гораздо эффективнее смотреть в меню сразу, и они выбирают пицца вместе. Вы можете смоделировать этот процесс, используя «множественную задачу» (см. Ниже). Несколько задач повторяются несколько раз и могут выполняться последовательно или параллельно, причем последний является более интересным.
Как вы считаете, этот пример абсурден? Как ваша компания проверяет счета-фактуры для групповых заказов, например, для офисных принадлежностей? Вы пересылаете счет-фактуру от одного сотрудника к другому, чтобы каждый человек может подписаться на предметы, которые он заказал, прежде чем оплачивать счет? Если это так, вы живете в разделе с равным доступом, и вам срочно следует рассмотреть возможность оптимизации вашего процесса. Автоматизация счетов-фактур по-прежнему является одним из лучших проектов BPM, и главная цель таких проектов часто является распараллеливанием.
Компенсация
Мы объясняем преимущества события компенсации посредством примера. Тип задачи компенсации применяется исключительно в контексте события компенсации. Соответственно, он интегрируется в диаграмму процесса только ассоциациями, а не потоками последовательностей.
Следует упомянуть возможную комбинацию компенсации с циклом или несколькими экземплярами, как показано ниже. В этом случае оба маркера размещаются параллельно. Как и в случае с другими маркерами, компенсацию можно комбинировать с уже введенными типами задач. Задача ручной коррекции, которая повторяется до тех пор, пока она не удастся или что выполняется многократно и параллельно, насколько это возможно, поэтому является чрезвычайно практичным.
Подпроцессы
Инкапсулировать сложность
Примеры в этом учебнике посвящены простым процессам или они поверхностно структурируют сложные процессы, чтобы модели соответствовали одной странице. При моделировании ландшафта процесса у вас нет такой роскоши. Вы должны выровнять свои процессы, чтобы вы могли получить общие идеи и распознать корреляции. Затем вам нужно разработать подробное описание, чтобы вы могли точно анализировать, где находятся слабые стороны или как вам придется выполнять этот процесс на практике. Возможные корректировки сверху вниз или восходящие агрегаты означают разницу между истинными технологическими моделями и банальными блок-схемами, между сложными программными продуктами BPM и просто программами рисования.
BPMN предоставляет нам подпроцесс, чтобы помочь с расширением / свертыванием. Подпроцесс описывает подробную последовательность, но она не занимает больше места на диаграмме родительского процесса чем задача. Обе задачи и подпроцессы являются частью класса действий и поэтому представлены как прямоугольники с закругленными углами. Единственное отличие - знак плюса, указывая сохраненную подробную последовательность для подпроцесса:
Что хорошего для нас? Это больше всего зависит от того, как ваш инструмент BPMN поддерживает следующие параметры для подключения подпроцессов с их родительскими процессами:
- Представление в отдельной диаграмме процессов : символ подпроцесса связывается с отдельной диаграммой. Если ваш инструмент BPMN отображает модель процесса в веб-браузере, например, нажатие на символ откроет новую страницу, чтобы отобразить подробную диаграмму.
- Расширение диаграммы процессов родительского процесса : активность со знаком плюс называется скомпенсированным подпроцессом. Знак плюса означает, что вы можете нажать на него и сделать подпроцесс расширяется. Спецификация BPMN предусматривает эту опцию, хотя не все ее поставщики реализуют ее. На приведенной ниже диаграмме показано, как подпроцесс был непосредственно расширен на диаграмме родительский процесс. Инструмент, поддерживающий эту функцию, позволяет вам развернуть и свернуть подпроцесс непосредственно на диаграмме, соответственно, чтобы показать или скрыть детали.
Прямое расширение может показаться привлекательным, но часто это не полезно на практике. Расширение подпроцесса требует, чтобы все смежные символы на диаграмме сдвигались, чтобы освободить место. Это может привести к медленной работе со сложной диаграммой, и это может быть визуально противным. Самое главное, что ваш инструмент обеспечивает связь и что вы можете с пользой провести навигацию через диаграммы. Другими словами, он поддерживает первый вариант выше. Да, может быть полезно, чтобы ваш подпроцесс моделировался и расширялся непосредственно из родительского процесса. Это означает, что сегменты процесса остаются локализованными, и вы также можете присоединить события. Это, однако, менее важный вариант.
Поток последовательности родительского процесса заканчивается в обоих случаях на левом краю подпроцесса. Следующий поток последовательности начинается с правого края. Это означает, что потокам последовательности не разрешается превышать границы подпроцесса, которые не каждый новичок знает, и который становится проблемой при расширении подпроцесса. Визуализируйте токен, который ведет себя следующим образом:
- Родительский процесс начинается, и появляется токен.
- Маркер запускает задачу и приходит к подпроцессу, что приводит к тому, что родительский процесс создает экземпляр подпроцесса.
- Внутри подпроцесса создается отдельный токен, который проходит через подпроцесс от начала до конца, но токен родительского процесса ожидает завершения субпроцесса.
- Когда токен подпроцесса приходит в конечное событие, он потребляется, что завершает подпроцесс. Теперь токен родительского процесса перемещается в свое собственное конечное событие.
Инкапсуляция в подпроцессах, которые мы описываем, не ограничивается двумя уровнями. Вы могли бы также легко иметь родительский процесс как подпроцесс, или вы могли бы моделировать дальнейшие подпроцессы на уровень определенного подпроцесса. Сколько уровней вы используете и уровень детализации, который вы применяете для их моделирования, зависит от вас. BPMN не указывает это, и не может быть никакой кросс-компании или кросс-сценария поваренной книги для определения уровней. Участникам наших семинаров BPMN это не нравится, но нет смысла скрывать этот факт и не пытаться объяснить это. В следующих главах мы часто работаем с подпроцессы в объяснении наших лучших практик, но правда в том, что количество уровней уточнения и их соответствующие уровни детализации всегда ситуативны. Это зависит от организации, роли участников проекта, а также цели процесса, который вы моделируете.
Прикрепление событий
Мы уже узнали о промежуточных событиях, которые могут быть связаны с задачами. Те же события можно присоединить и к подпроцессам, что открывает широкий спектр возможностей в процессе моделирования. Как показано на диаграмме ниже, мы можем представить, как спонтанное приглашение на обед приводит к отмене нашего процесса приготовления. Однако в показанном процессе мы могли бы игнорировать приглашение, если наша еда уже подготовлена, и мы уже ели ее:
Когда речь идет о сообщениях, таймерах и условных событиях, родительский процесс всегда прерывает подпроцесс при реагировании на внешние обстоятельства. Однако при событиях с ошибкой, отменой и эскалацией подпроцесс передает эти события в родительский процесс. Это не так абстрактно, как может показаться.
В нижнем правом углу диаграммы выше задача Закупка может завершиться неудачно, потому что элемент больше не доступен. Поскольку элемент Закупка является глобальным подпроцессом, он вызывает событие ошибки, чтобы сообщить родительскому процессу, что что-то пошло не так. В бизнес-условиях это может означать, что клиент, который хотел купить товар, сообщает продавцу, что его или ее заказ окончен, потому что товар отсутствует.
Интересно, что родительские процессы могут обрабатывать сообщение об ошибке по-разному. Хотя разочарованный клиент должен быть проинформирован в рамках процесса заказа, достаточно, чтобы процесс обслуживания запаса удалял элемент из каталога. Соответствующие родительские процессы определяют, какие обстоятельства требуют отмены подпроцесса и что происходит дальше. Это принцип, который вы можете использовать для создания гибких и модульных ландшафтов процесса.
Событие сигнала выполняет две функции. Родительский процесс может реагировать на сигнал, доставленный извне, когда он выполняет подпроцесс - это очень похоже на событие сообщения. Но мы также используем событие сигнала, чтобы подпроцесс передавал в родительский процесс другие вещи, кроме ошибок. Прежде всего, это связано с тем, что мы не можем моделировать этот тип связь с событиями сообщений. BPMN предполагает, что мы всегда отправляем сообщения другим участникам, которые находятся за пределами границ нашего пула; связь между родительским и подпроцессом не подходит для этой формы. Мы не используем сигнальные события для направленной связи, а скорее передаем информацию, сродни рекламе на радио.
Лучшей альтернативой, представленной в BPMN 2.0, является событие эскалации. Подпроцесс может использовать событие эскалации для прямого отчета о родительском процессе, и сообщение не будет рассматриваться как сообщение об ошибке. Кроме того, родительский процесс может получать и обрабатывать сообщения из событий эскалации без отмены подпроцесса, поскольку промежуточные события без прерывания могут быть присоединены:
Активность вызова
Модуляция и повторное использование
В версии 1.2 BPMN дифференцируется между встроенными и многоразовыми подпроцессами путем назначения атрибута подпроцессу. В версии 2.0 BPMN поддерживает эту дифференциацию в принципе, но она определяется по-разному. Подпроцесс теперь встроен по существу, и его можно повторно использовать только определяя его как глобальный подпроцесс, а затем ссылаясь на него посредством активности вызова. Поэтому мы ссылаемся на встроенные подпроцессы и глобальные подпроцессы в следующем.
Встроенный подпроцесс может происходить только в рамках родительского процесса, к которому он принадлежит. Встроенный подпроцесс не может содержать пулы и полосы, но он может быть помещен в пул или полосу родительский процесс. Кроме того, встроенный подпроцесс может иметь только начальное событие; события запуска, такие как сообщения или таймеры, не допускаются. Встроенный подпроцесс имеет практически не что иное, как вид ограниченного объема в родительском процессе, который может выполнять две цели:
- Чтобы инкапсулировать сложность (как уже было описано)
- Формулировать «коллективную инструкцию» на части родительского процесса путем добавления событий или размещения маркеров. Мы рассмотрим этот вариант позже.
С другой стороны, глобальные подпроцессы могут возникать в совершенно разных родительских процессах. Существует много подпроцессов, которые на практике используются снова и снова. Хорошим примером является Закупка изделия, потому что заказчик заказал его или вам нужно перепродать запас. Другим примером является выставление счетов, поскольку вы доставляли или ремонтировали товар, как показано в диаграмму ниже. В этом примере обратите внимание, что действия вызова отличаются от обычных действий их значительно более плотными границами:
Соединение глобальных подпроцессов с его родителем значительно меньше, и у них могут быть свои собственные пулы и полосы. Вы можете думать об участнике, ответственном за подпроцесс, как поставщика услуг для различных родительских процессов. Это похоже на общий сервисный центр.
Свободное соединение также влияет на передачу данных между родительским и подпроцессом. BPMN предполагает, что встроенные подпроцессы могут напрямую считывать все данные родительского процесса, но явное назначение требуется для того, чтобы глобальные подпроцессы могли его читать. Сначала это может показаться всего лишь техническим аспектом, который моделисты и потребители их моделей знайте, но не захотите беспокоиться. Однако, после некоторого рассмотрения, вы можете увидеть влияние этой разницы на организацию. Рассмотрите это: когда ваш бухгалтерский отдел хочет для выставления счета-фактуры на ремонт ему всегда необходимо:
- Абонентский адрес
- Дата поставки
- Описание производительности
- Сумма счета-фактуры
- Ожидаемая дата оплаты
Владельцы обработки заказов, а не только отдел ремонта, должны предоставить эти данные. Учет будет нуждаться в данных в стандартном формате, не так ли? Это хорошо соответствует тому, что BPMN звонки требуют сопоставления данных между родительскими процессами и глобальными подпроцессами. (Вы заметили, как часто эти странные технические вопросы соответствуют организационным потребностям и ожиданиям процесса?) BPMN просто заставляет нас формализовать многие вопросы, которые кажутся само собой разумеющимися, или которые остались без сознания или забыты в процессе проектирования. Формализация - это наша лучшая возможность идти в ногу с быстрым изменением окружающей среды со все более сложными процессами.
Для этого случая
Один маркер, доступный только для подпроцессов, называется ad-hoc. Признайте его тильдой, как показано на диаграмме ниже:
Используйте подпроцесс ad-hoc, чтобы отметить сегмент, в котором могут выполняться содержащиеся в нем действия (задачи или подпроцессы):
- Выполнено в любом порядке,
- Выполнено несколько раз или
- пропустить.
Любая сторона, выполняющая этот подпроцесс, решает, что делать и когда это делать. Можно сказать, что «едва структурированная» природа того, что происходит внутри этого подпроцесса, уменьшает вся идея моделирования процессов до абсурда, потому что то, что происходит, и когда мы больше всего хотим контролировать. С другой стороны, это реальность многих процессов, и вы не можете моделировать их, не представляя их символ свободной формы. Частые примеры - это когда процесс в значительной степени зависит от неявных знаний или творчества, или когда разные сотрудники выполните процесс по-разному. Вы можете использовать подпроцесс ad-hoc для определения того, что может быть нежелательным фактическим состоянием. Это может стать шагом на пути к более стандартизованной процедуре.
BPMN 2.0 указывает, какие символы должны быть, а какие запрещены, в рамках подпроцесса ad-hoc. Они есть:
- Обязательно : Мероприятия
- Май: Объекты данных, потоки последовательностей, ассоциации, группы, потоки сообщений, шлюзы и промежуточные события
- Запрещено : начальные и конечные события, символы для разговоров и хореографий
С помощью спецификации могут быть смоделированы смешанные формы - так называемые слабоструктурированные процессы, как показано здесь:
Подпроцесс события
BPMN 2.0 представил совершенно новую конструкцию - подпроцесс события. Мы находим подпроцесс события в рамках другого процесса или подпроцесса. Распознавайте их своими пунктирными рамками.
Одно событие запуска всегда вызывает подпроцесс события, и это может произойти только в том случае, если процесс включения или подпроцесс остается активным. Для подпроцессов событий может быть прерывание (непрерывная линия) и не прерывание (пунктирная линия). Это та же самая дифференциация, что и для присоединенных промежуточных событий. В зависимости от типа события запуска, подпроцесс события отменяет охватывающий подпроцесс, или он будет выполняться одновременно. Вы можете запускать неперерывные подпроцессы событий так часто, как вы хотите, до тех пор, пока подпроцесс остается активным.
Хорошо, это довольно абстрактно, но мы можем продемонстрировать, как подпроцесс события работает с примером:
Мы пригласили пару друзей на обед. Это начинает подпроцесс «подготовки пищи» к выбору рецепта, а затем готовит еду. Пока мы это делаем, телефон звонит. Другой гость приглашает себя на обед. Спонтанно, как мы, мы просто увеличиваем количество пищи или устанавливаем другое место за столом, не прерывая приготовления пищи. Однако, если авария происходит во время подготовки, ошибка немедленно вызывает подпроцесс прерывания события для исправления. Мы заказываем еду для доставки. Когда этот подпроцесс этого события завершается, мы выходим из закрытого подпроцесса через регулярный выход и участвуем в еде.
Ниже вы можете видеть, как субпроцессы события представлены в свернутом состоянии: кадр является пунктирной линией, и мы снова использовали знак плюса для представления свернутых подпроцессов. В левом верхнем углу у нас также есть начальное событие, запускающее подпроцесс.
Типы событий, которые могут инициировать прерывания и прерывания подпроцессов событий:
Существует еще два типа для подпроцессов прерывания:
Шлюзы
Эксклюзивные шлюзы на основе данных
Определенные вещи могут быть сделаны только при определенных обстоятельствах, поэтому несколько процессов всегда проходят один и тот же курс. В нашем простом примере мы хотим углубиться в детали кулинарии. Управляемый Голод, мы думаем о том, что мы будем готовить сегодня. Мы знаем только три рецепта, поэтому мы выбираем один. Мы можем либо Готовить макароны , либо приготовить Стейк или подготовить салат. Предположим, что эти варианты являются эксклюзивными - мы никогда не будем готовить более одного за раз. Пункт решения о том, что делать дальше, называется шлюзом. Мы решаем на основе имеющихся данных (выбранный рецепт), и мы следим только за одним из путей, который является эксклюзивным шлюзом на основе данных. Мы сокращаем «эксклюзивный шлюз» как XOR .
Осторожно! Имейте в виду, что шлюз - это не задача! Вы должны определить факты и потребности, прежде чем достигнуть шлюза.
Как и на диаграмме выше, мы ставим ключевой вопрос перед шлюзом. Это наша конвенция, которая доказала свою ценность в наших проектах. Возможные ответы идут по параллельным путям после шлюза, как показывает их спецификация BPMN. Мы всегда работаем со шлюзами XOR следующим образом:
- Моделируйте задачу, требующую решения для шлюза XOR.
- После этого смонтируйте шлюз XOR. Создайте вопрос с взаимоисключающими ответами.
- Выделите один исходящий путь (или поток последовательности) для каждого возможного ответа и пометьте путь ответом.
Они идентичны по смыслу. Мы всегда используем версию с X, потому что она кажется менее двусмысленной.
Параллельные шлюзы
Предположим, что теперь нам нужен салат на стороне. Если вы хотите, чтобы Салат неважно, вы могли бы моделировать его, как мы это сделали на этой диаграмме:
Общее время выполнения задачи равно времени выполнения процесса, который составлял в общей сложности 48 минут для Макороны и 43 минуты для Стейк. Поздравляем: вы только что проанализировали свой первый процесс на основе ключевых данных!
Тем не менее, это означает, что вы ожидаете 23 или даже 28 минут, пока не сможете начать есть. Невыносимый! Вы действительно голодны, но что вы можете сделать? Может быть, вы сначала не готовите Салат, а затем готовите Макороны или Стейк, но вы работаете одновременно и параллельно - параллельно. Соответствующим символом является параллельный шлюз или «И шлюз» для краткости, как показано здесь:
Задачи диаграмм как параллельные не делают одновременную обработку обязательной. В отличие от примера, показанного ранее, также не обязательно, чтобы вы подготовьте Салат перед началом других задач. Однако параллельная подготовка уменьшает общее время на 10 минут. Это классическая оптимизация процессов, чтобы сделать задачи параллельными как можно больше.
Встроенные шлюзы на основе данных
Мы хотим сделать наш процесс еще более гибким: когда мы голодны, мы хотим есть
- Только салат,
- Салат и «что-то реальное», как Макороны или Стейк, или
- Только что-то реальное.
Если вы хотите более компактное представление, вы можете использовать шлюз с включенным доступом на основе данных - шлюз OR для краткости:
Осторожно! На практике обработка ИЛИ шлюзов не так проста, как предполагают эти примеры. Легко понять, что прогресс зависит от ожидания того, что другой токен достигнет слияния OR. Труднее будет отслеживать правила синхронизации со сложными диаграммами, которые разрастаются на нескольких страницах.
Шлюзы, основанные на событиях
Мы узнали об эксклюзивной опции шлюза на основе данных (XOR) в качестве способа использования разных путей в отношении обрабатываемых данных. Пользователи других описаний процессов распознают этот тип ветвления, но BPMN дает нам другой способ проектирования путей процесса: шлюз событий - шлюз событий, для краткости. Этот шлюз не маршрутизируется на основе данных, а скорее каким событием имеет место следующее. Чтобы понять пользуйтесь рассмотрением процесса, показанного ниже: Мы заказываем пиццу и ждем его доставки. Мы можем есть только после того, как получим пицца, но что, если пицца не прибудет после 60 минут? Мы сделаем тревожный телефонный звонок, вот что! Мы можем моделировать это с помощью шлюза событий:
Как вы можете видеть здесь, не все промежуточные события сочетаются с шлюзом событий. Однако вы можете комбинировать его с задачей получения.
Событие
Базовые концепты
Задачи и шлюзы - два из трех элементов потока, которые мы узнали до сих пор: Вещи (задачи) должны выполняться при определенных обстоятельствах (шлюзах). Какой элемент потока все еще отсутствует? Вещи (события), которые должны произойти. События не менее важны для моделей процессов BPMN, чем задачи или шлюзы. Мы должны начать с некоторых основных принципов их применения. Мы уже видели события Start, промежуточные события и конечные события. Эти три типа событий также захватывают и / или бросают события:
События отслеживания - это события с определенным триггером. Мы считаем, что они имеют место после активации или увольнения триггера. Как интеллектуальная конструкция, это относительно сложно, поэтому мы упрощаем, вызывая их улавливание событий. Дело в том, что эти события влияют на ход процесса и поэтому должны быть смоделированы. Захват событий может привести к:
- Процесс, начинающийся
- Процесс или путь процесса продолжается
- Выполненная в данный момент задача или отменяется подпроцесс
- Другой путь процесса, используемый во время выполнения задачи или подпроцесса
События броска предполагаются BPMN для запуска самих себя, а не для реагирования на триггер. Можно сказать, что они активны по сравнению с пассивными событиями ловли. Мы называем их короткими событиями, потому что процесс запускает их. Событие броска может быть:
- Запущено во время процесса
- Запущено в конце процесса
Мы также можем моделировать присоединенные промежуточные события с BPMN. Они явно не требуют ожидания, но они прерывают наши действия, как задачи, так и подпроцессы. Такие промежуточные события привязаны, потому что мы размещаем их на границе активности, которую мы хотим прервать.
Токен, проходящий через процесс, будет вести себя следующим образом:
- Токен переходит к задаче 1, которая начинается соответственно.
- Если событие 1 происходит во время обработки задачи 1, задача 1 немедленно отменяется, и токен перемещается через поток исключений в задачу 3.
- С другой стороны, если событие 1 не встречается, задача 1 будет обработана, и токен перемещается по регулярному потоку последовательности к задаче 2.
- Если событие 1 происходит только после завершения задачи 1, оно будет проигнорировано.
Через версию BPMN 1.2, за исключением событий компенсации, присоединенные промежуточные события неизбежно приводили к отмененным действиям. BPMN 2.0 определяет новый символ: промежуточное событие без прерывания. Это звучит неловко, но полезно: