10.2.5 Подпроцесс

Подпроцесс представляет собой Действие, заключающее в себе другие Действия, Шлюзы, События и Потоки операций. Графически Подпроцесс изображается в качестве элемента Потока операций Процесса в спецификации BPMN 2.0.

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

Далее будут рассмотрены различные типы Подпроцессов.

Встроенный Подпроцесс (Embedded Sub-Process (Sub-Process))

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

• Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой линией.
  • Текст, цвет, размер, а также линии, используемые для изображения Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
    • Одинарная жирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Действия Вызов (Подпроцесс).
    • Пунктирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Событийного Подпроцесса.
    • Двойная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Подпроцесса Транзакции.

Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты (см. фигуру 10.25). Подпроцесс также может быть развернутым (Expanded Sub-Process), при этом его детали отображаются внутри Процесса, в котором данный Подпроцесс содержится (см. фигуру 10.26). В случае, если Подпроцесс является свернутым, то используется маркер, позволяющий отличить Подпроцесс от Задачи.

• Маркер Подпроцесса ДОЛЖЕН изображаться в виде небольшого квадрата, расположенного в центре нижней части графического элемента и заключающего в себе знак «+».

Фигура 10.25 – Графический элемент Свернутый Подпроцесс

Фигура 10.26 – Графический элемент Развернутый Подпроцесс

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

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

Фигура 10.27 – Развернутый Подпроцесс, выступающий в роли «параллельного блока».

BPMN различает пять типов стандартных маркеров Свернутого Подпроцесса. Маркер Подпроцесса, изображенный на фигуре 10.25, может сочетаться с оставшимися четырьмя маркерами: Маркером Цикла (Loop Marker), Многоэкземплярным Маркером (Multiple-Instance Marker), Маркером Компенсации (Compensation Marker) и Маркером Ad Hoc (Ad-Hoc Marker). Свернутый Подпроцесс может содержать от одного до трех вышеуказанных Маркеров. Комбинации Маркеров могут быть любыми, кроме сочетания Маркеров Цикличности и Многоэкземплярного, - эти Маркеры не могут изображаться одновременно (см. фигуру 10.28).

• Маркер Цикла ДОЛЖЕН БЫТЬ выполнен в виде небольшой стрелки, острие которой загнуто в направлении, противоположном направлению самой стрелки.
  • Маркер Цикла МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Многоэкземплярного

• Многоэкземплярный Маркер ДОЛЖЕН БЫТЬ выполнен в виде трех параллельных вертикальных линий.
  • Многоэкземплярный Маркер МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Маркера Цикла.

• Маркер Ad Hoc ДОЛЖЕН БЫТЬ выполнен в виде тильды.
  • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

• Маркер Компенсации ДОЛЖЕН БЫТЬ выполнен в виде двух треугольников, повернутых влево (как кнопка перемотки назад на проигрывателе).
  • Маркер Компенсации МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

• Все вышеописанные Маркеры при совместном отображении ДОЛЖНЫ БЫТЬ сгруппированы и располагаться в центре нижней части графического элемента Подпроцесса.

Цикл Многоэкземплярность Компенсация Ad-Hoc Компенсация + Ad-Hoc

Фигура 10.28 – Маркеры Свернутого Подпроцесса

Свернутый Подпроцесс в BPMN 2.0 относится к Встроенному Подпроцессу, описанному в BPMN 1.2. Повторно используемый Подпроцесс в BPMN 1.2 относится к Действию типа Вызов, описанному в BPMN2.0. Фигура 10.29 представляет собой диаграмму классов Подпроцесса.

Фигура 10.29 - Диаграмма классов элемента SubProcess

Элемент SubProcess наследует атрибуты и ассоциации элементов Activity (см. таблицу 10.3) и элемента FlowElementContainer (см. таблицу 8.45). Таблица 10.20 содержит информацию о дополнительных атрибутах элемента SubProcess.

Таблица 10.20 – Атрибуты элемента SubProcess

Название атрибута	Описание/использование
triggeredByEvent: boolean = false	Данный атрибут указывает на то, что данный Подпроцесс работает с Событиями. · Значение «false» указывает на то, что Подпроцесс является стандартным. · Значение «true» указывает на то, что Подпроцесс работает с Событиями и является причиной возникновения дополнительных ограничений.
triggeredByEvent: boolean = false	Данный атрибут обусловливает наличие списка Артефактов, хранящихся в Подпроцессе.

ReusableSub-Process (CallActivity) Повторно используемый Подпроцесс (Вызов)

Повторно используемый Подпроцесс, описанный в BPMN 1.2, относится к Действию типа Вызов, используемому для вызова предопределенного Подпроцесса.

Событийный Подпроцесс (Event Sub-Process)

Событийным Подпроцессом называется специфический Подпроцесс, используемый внутри Процесса (Подпроцесса). Такой Подпроцесс имеет атрибут triggeredByEvent с установленным значением «true».

Такой Подпроцесс не является частью Стандартного потока операций, включенного в родительский Процесс, и не имеет входящих или исходящих Потоков операций.

• Событийный Подпроцесс НЕ ДОЛЖЕН иметь входящих или исходящих Потоков операций.

Событийный Подпроцесс МОЖЕТ появляться (один раз или многократно) или НЕ появляться в ходе выполнения родительского Процесса. Отличие такого Подпроцесса от стандартного состоит в том, что стандартный Подпроцесс в качестве триггера использует Поток операций, а Событийный Подпроцесс - Стартовое событие. Всякий раз, когда какое-то Стартовое событие запускается во время выполнения родительского Процесса, запускается и Событийный Подпроцесс.

• Стартовое событие Событийного Подпроцесса ДОЛЖНО иметь определенный триггер.
  • Стартовое событие (EventDefinition) ДОЛЖНО БЫТЬ одного из следующих типов: Сообщение, Ошибка, Эскалация, Компенсация, Условие, Сигнал, Множественный.

• Событийный Подпроцесс ДОЛЖЕН содержать одно или более Стартовое событие.

Такой Подпроцесс изображается в виде прямоугольника с закругленным углами (установленное в BPMN отображение графического элемента Подпроцесс).

• Событийный Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой пунктирной линией (см. фигуры 10.30 и 10.31).
  • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
    • Если Событийный Подпроцесс является свернутым, то Стартовое событие в таком Подпроцессе будет являться маркером и отображаться в левом верхнем углу фигуры Подпроцесса (см. фигуру 10.30).

Фигура 10.30 – Графический элемент Свернутый Событийный Подпроцесс

Фигура 10.31 – Графический элемент Развернутый Событийный Подпроцесс

Запуск Событийного Подпроцесса может привести к следующим последствиям в родительском Процессе:

1. Родительский Процесс прерывается.
2. Родительский Процесс продолжает выполняться (не прерывается).

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

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

Фигура 10.32 –Событийные Подпроцессы внутри родительского Подпроцесса

Транзакция (Transaction)

Транзакцией называется специфический тип Подпроцесса, который демонстрирует определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Граница графического элемента Транзакция выполнена двойной линией (см. фигуру 10.33).

• Транзакция представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен двойной тонкой линией.
  • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».

Фигура 10.33 –Подпроцесс Транзакция

Фигура 10.34 – Свернутый Подпроцесс Транзакция

Элемент TransactionSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.21 содержит информацию о дополнительных атрибутах и ассоциациях элемента TransactionSub-Process.

Таблица 10.21 – Атрибуты и ассоциации элемента TransactionSub-Process

Название атрибута

Описание/использование

method: Transaction- Method

Данный атрибут определяет метод, используемый для совершения Транзакции или её отмены. Для выполняемых процессов данный атрибут ДОЛЖЕН содержать особый URL, например, http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, orhttp://docs.oasis-open.org/ws-tx/wsba/2006/ 06/AtomicOutcome для WS-BusinessActivity. Для сохранения совместимости с BPMN 1.1 данный атрибут также может иметь значения "##compensate", "##store" и "##image".

Использование Транзакции может привести к следующим результатам:

1. Удачное завершение. Отображается в виде Стандартного потока операций, отходящего от Транзакции.
2. Неудачное завершение (с использованием События Отмена). При отказе от выполнения Транзакции Действия, находящиеся внутри данной Транзакции, подвергнуться действиям отмены: например, будет выполнена компенсация определенных Действий, или произойдет возврат к Процессу (для получения более подробной информации о компенсации смотрите соответствующий раздел документа). Обратите внимание, что никакой другой механизм остановки Транзакции (например, использование Событий Ошибка и Таймер или каких-либо Действий, не предусмотренных Транзакцией) не повлечет за собой компенсацию. Промежуточное событие Отмена, соединенное с границей Действия, оказывает влияние на направление хода Процесса после того, как произошел возврат и была выполнена компенсация. Это Событие может быть использовано только в том случае, если оно соединено с границей Подпроцесса Транзакции. Оно не может быть использовано в рамках Стандартного потока операций или не прикрепляется к Подпроцессу, не являющемуся Транзакцией. Существует два механизма, способных сигнализировать об отмене Транзакции:
   • Поток операций Транзакции достигает Промежуточного события Отмена. Это Событие используется только для такого типа Подпроцессов.
   • Сообщение об отмене может быть получено посредством протокола транзакции, поддерживающего выполнение данной Транзакции.
3. Риск (Опасность). Появление Риска означает, что какое-то действие в Транзакции выполняется крайне неверно, и это ведет к тому, что стали невозможны ни удачное завершение, ни отмена. Риски отображаются посредством Промежуточного события Ошибка. При появлении Риска выполнение текущего Действия прекращается без возможности компенсации, а Поток операций возобновляется от Промежуточного события Ошибка.

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

Спонтанный Подпроцесс (Ad-Hoc Sub-Process)

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

Графический элемент Спонтанный Подпроцесс содержит маркер, выполненный в виде знака тильды и располагающийся в центре нижней части фигуры Подпроцесса (см фигуру 10.35 и 10.36).

• Маркер Спонтанного Подпроцесса ДОЛЖЕН БЫТЬ выполнен в виде тильды.
  • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

Фигура 10.35 – Графический элемент Свернутый Спонтанный Подпроцесс

Фигура 10.36 – Графический элемент Развернутый Спонтанный Подпроцесс

Элемент Ad-HocSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.22 содержит информацию о дополнительных ассоциациях элемента Ad-HocSub-Process.

Таблица 10.22 – Ассоциации элемента Ad-HocSub-Process

Название атрибута	Описание/использование
completionCondition: Expression	Данный атрибут определяет условия, при которых завершается Процесс. Значение «true» указывает на то, что Процесс будет завершен.
ordering: AdHocOrdering = Parallel { Parallel | Sequential }	Данный атрибут указывает на то, будут ли Действия, включенные в Процесс, выполняться параллельно или НЕОБХОДИМО последовательное их выполнение. Значением по умолчанию является «parallel». Значение «sequential» ограничивает одновременное выполнение нескольких Действий. В данном случае в определенный период времени может быть выполнено лишь одно Действие. Если выбрано значение «parallel», то одновременно может выполняться любое количество Действий, от нуля и более.
cancelRemaining- Instances: boolean = true	Данный атрибут используется только в том случае, если для вышеописанного атрибута ordering установлено значение «parallel». Указывает на то, будут ли отменены запущенные экземпляры Действий, если значение атрибута completionCondition становится «true».

Действия, включенные в состав Спонтанного Подпроцесса, друг с другом, как правило, не соединяются. В ходе выполнения Подпроцесса запущенными МОГУТ одно или несколько Действий. Действия МОГУТ выполняться многократно. То, когда будет запущено Действие, каким будет следующее Действие, а также другие детали выполнения Действий определяются Исполнителем.

Примерами Процессов, входящих в состав Спонтанного Подпроцесса, являются разработка кода (на низком уровне), поддержка клиентов, а также написание главы книги. Рассмотрим, к примеру, написание главы для книги. Мы видим, что данный Процесс включает следующие Действия: поиск темы, составление текста, редактирование текста, создание дизайна, графическое оформление текста, оформление ссылок и т.д. (см. фигуру 10.37). В таком Процессе МОЖЕТ наблюдаться определенная зависимость Задач друг от друга, например, редактирование текста не может происходить раньше его написания. Однако такая корреляция между экземплярами Задачам по написанию и редактированию текста не обязательна. Редактирование может возникать нерегулярно и зависит от текста, полученного в результате выполнения нескольких экземпляров Задачи по написанию текста.

Фигура 10.37 – Спонтанный Подпроцесс написания главы для книги

Хотя в Спонтанном Подпроцессе структура не определена, в его детали все же может быть добавлена информация о последовательности Действий или корреляции данных. К примеру, можно расширить вышеописанный Спонтанный Подпроцесс написания главы для книги путем добавления в него Объектов данных, Ассоциаций или Потоков операций (см. фигуру 10.38).

Однако использование в Спонтанном Подпроцессе элементов потока должно осуществляться со следующими ограничениями, не имеющими отношения к использованию элементов в Подпроцессах других типов:

• В список элементов BPMN, которые ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входит Действие.
• В список элементов BPMN, которые МОГУТ использоваться в Спонтанном Подпроцессе, входят: Объект данных, Поток операций, Ассоциация, Ассоциация данных, Группа, Поток сообщений (может являться как целью, так и результатом), Шлюз, Промежуточное событие.
• В список элементов BPMN, которые НЕ ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входят: Стартовое событие, Конечное событие, Переговоры (графически), Соединители переговоров (графически), Действия Хореографии.

Фигура 10.38 – Спонтанный Подпроцесс написания главы для книги с отображением последовательности Действий и зависимых данных

Объект данных, предоставленный для Задач на входе, является дополнительным ограничением для выполнения этих Задач. В данном случае Исполнители, хотя и решают, когда будут выполнены Задачи, уже ограничены в действиях тем, что не могут начать выполнение Задачи без соответствующих данных. Наличие Потока операций между Задачами (например, между разработкой дизайна и оформлением текста в соответствии с дизайном) устанавливает зависимость, согласно которой вторая Задача ДОЛЖНА быть выполнена после выполнения первой. Это не означает, что вторая Задача должна выполняться незамедлительно, но лишь то, что она ДОЛЖНА выполняться после того, как будет завершена первая Задача.

Проблемой для BPM стало отслеживание статуса Спонтанного Подпроцесса. Как правило, Процессы такого типа контролируются при помощи приложений для групповой работы (например, e-mail). BPMN позволяет моделировать Процессы, необязательные для выполнения, хотя определенные механизмы для выполнения процессов, способные отслеживать Спонтанные Подпроцессы, существуют. Исходя из этого, Спонтанный Подпроцесс будет завершен при определенных условиях, которые указываются посредством установки значения для атрибута completionCondition, определяющего, в свою очередь, атрибуты Процесса, корректируемые Действием данного Процесса.