Глава 10. Процесс
Примечание: описанные в данной главе рекомендации по моделированию и выполнению Процессов BPMN НЕОБХОДИМЫ для соответствия требованиями моделирования Процессов BPMN или общим стандартам BPMN. Однако данная глава НЕ ОБЯЗАТЕЛЬНО входит в состав документов соответствия стандартам моделирования Хореографии Процесса BPMN, соответствия стандартам выполнения Процесса BPMN, соответствия стандартам выполнения Процесса BPEL BPMN.
Процесс BPMN представляет собой последовательный поток Действий в организации, направленный на выполнение работы. Графически он изображается в виде диаграммы, содержащей такие Элементы потока, как Действия, События, Шлюзы, а также Поток операций, который и определяет конечную семантику выполнения (см. фигуру 10.1). Для описания работы организации могут использоваться Процессы любого уровня сложности начиная от Процессов масштаба целой организации до Процессов, выполняемых одним человеком. Сгруппированные низкоуровневые Процессы служат для достижения общей бизнес-цели.
Фигура 10.1 – Пример Процесса
Обратите внимание, что термин «процесс», используемый в BPMN, более точно передает суть набора элементов потока. Терминами «взаимодействие» и «хореография» обозначаются взаимоотношения между Процессами.
Пакет Процесса содержит классы, используемые для моделирования потока Действий, Событий и Шлюзов, а также служащие для описания последовательности их выполнения в ходе Процесса (см. фигуру 10.2). Если Процессу дано определение, оно помещается в Definitions.
Фигура 10.2 – Диаграмма классов элемента Process
Процесс относится к классу CallableElement, что позволяет ему ссылаться на другие Процессы и быть повторно использованным ими благодаря использованию Действия Вызов. Процесс МОЖЕТ ссылаться на ряд элементов Interfaces, определяющих его внешнее поведение.
Процесс может использоваться повторно, а также импортироваться и использоваться в составе других Definitions.
Детали атрибутов и ассоциаций модели Процесса изображены на фигуре 10.3.
Фигура 10.3 – Диаграмма классов деталей Процесса
Элемент Process наследуют атрибуты и ассоциации элементов CallableElement (см. таблицу 10.24) и FlowElementContainer (см. таблицу 8.45). Таблица 10.1 содержит информацию о дополнительных атрибутах и ассоциациях элемента Process.
Таблица 10.1 – Атрибуты и ассоциации элемента Process
|
Название атрибута |
Описание/использование |
|
processType: ProcessType = none { None | Private | Public } |
Атрибут processType обеспечивает наличие дополнительной информации о том, насколько абстрактен данный Процесс (насколько публичным он является). Публичный Процесс содержит только те элементы потока, которые являются важными для внешнего заказчика. Содержимое Процесса не моделируется. Такие Процессы доступны для ознакомления и могут быть использованы во Взаимодействии. Обратите внимание, что в BPMN 1.2 публичный процесс назван абстрактным. Приватный процесс является внутренним для данной организации. По умолчанию значение данного атрибута равно «none». |
|
isExecutable: boolean [0..1] |
Данный атрибут является опциональным и указывает, является ли Процесс выполняемый. Выполняемым называется приватный Процесс, моделируемый для выполнения в соответствии с семантическими правилами, изложенными в главе 14. Разумеется, в ходе разработки такого Процесса невозможно исключить отрезки, в которых не окажется достаточно информации для того, чтобы Процесс мог являться выполняемым. Невыполняемый Процесс - это приватный Процесс, моделируемый для подробного или не очень (решает разработчик модели) документирования поведения Процесса. Таким образом, информация, необходимая для выполнения Процесса (например, выражения формальных условий), как правило, не включается в невыполняемые процессы. В публичных Процессах значения атрибутов не имеют такой же семантики, как если бы они уже имели значения «false». Это означает, что в данном случае значение МОЖЕТ БЫТЬ не «true». |
|
auditing: Auditing [0..1] |
Данный атрибут определяет метод проверки схожих свойств. |
|
monitoring: Monitoring [0..1] |
Данный атрибут определяет метод отслеживания схожих свойств. |
|
artifacts: Artifact [0..*] |
Данный атрибут предоставляет список Артефактов, содержащихся в Процессе. |
|
IsClosed: boolean = false |
Данный атрибут указывает, будут ли взаимоотношения (такие, как отправка и получение Сообщений и Событий), не запланированные в Процессе, осуществляться в точке завершения/выполнения данного Процесса. Если выбрано значение «true», то взаимоотношения МОГУТ и НЕ осуществиться. Если выбрано значение «false», то взаимоотношения МОГУТ быть. |
|
supports: Process [0..*] |
Посредством данного атрибута разработчики модели могут показать, что все действия, ведущие к выполнению или завершению одного Процесса, также верны и для другого Процесса. Это означает, что действия, включенные в состав первого Процесса, не будут отличаться от действий второго Процесса. |
|
properties: Property [0..*] |
Данный атрибут указывает на то, что в Процесс МОГУТ БЫТЬ добавлены свойства (properties), определенные разработчиком модели. Все Задачи и Подпроцессы ДОЛЖНЫ иметь доступ к таким свойствам. |
|
resources: ResourceRole [0..*] |
Данный атрибут определяет ресурсы (исполнителей), выполняющие Процесс или являющиеся за него ответственными. Ресурсом (например, исполнителем) может являться одно лицо, группа лиц, роль или должность в организации, а также сама организация. Обратите внимание, что ресурсы, назначенные для какого-либо Процесса, не обуславливают назначенных ресурсов для выполнения Действий, входящих в состав данного Процесса. Для получения более подробной информации о назначении ресурсов. |
|
correlationSubscriptions: CorrelationSubscription [0..*] |
Элементы correlationSubscriptions являются особенностью основанной на контексте корреляции (см. 8.3.3). Используются для установления связи между входящими Сообщениями и контекстом Процесса. В Процессе МОЖЕТ содержаться несколько таких атрибутов. |
|
definitionalCollaborationRef: Collaboration [0..1] |
В случае Процесса, взаимодействующего с другими Участниками, область определения понятия Взаимодействие зависит от данного Процесса. Взаимодействие здесь подразумевает Участников, с которыми взаимодействует Процесс, а именно – что должен выполнять (отправка или получение Задач, Сообщение) тот или иной Участник, что определяется посредством Потоков сообщений. Нет необходимости отображать область определения Взаимодействия на диаграмме. Также Взаимодействие может подразумевать добавление в Процесс информации об Обмене сообщениями. |
Также необходимо указать, что у экземпляра Процесса имеются атрибуты, на значения которых МОГУТ ссылаться выражения (Expressions), см. таблицу 10.2. Эти значения могут быть доступны только в случае, если Процесс находится на стадии выполнения.
Таблица 10.2 – Атрибуты экземпляра Процесса
|
Название атрибута |
Описание/использование |
|
state: string = None |
Для ознакомления с допустимыми значениями см. фигуру 13.2 (Жизненный цикл Действия BPMN) в подразделе 13.2.2. |
10.1. Основные понятия Процесса
10.1.1 Типы процессов BPMN
Моделирование бизнес-процессов предназначено для передачи самой разнообразной информации широкой аудитории.
BPMN охватывает множество типов моделирования и позволяет создавать Бизнес-процессы полного цикла (end-to-end). Существует три основных типа процессов BPMN:
- Приватный невыполняемый (внутренний) Бизнес-процесс.
- Приватный выполняемый (внутренний) Бизнес-процесс.
- Публичный Процесс.
10.1.1.1 Приватный (Внутренний) Бизнес-процесс.
Приватный бизнес-процесс относится к внутренним процессам со специфической структурой. Такие Процессы, как правило, называются потоками работ или Процессами BPM (см. фигуру 10.4). Другое название этого процесса обычно используется для веб-сервисов и звучит как Оркестровка сервисов (Orchestrationof services). Существует два типа приватных Процессов: выполняемые и невыполняемые. Выполняемым называется Процесс, смоделированный для выполнения согласно семантике, описанной в Главе 14. Разумеется, в ходе разработки такого Процесса невозможно исключить отрезки, в которых не окажется достаточно информации для того, чтобы Процесс мог являться выполняемым. Невыполняемый процесс это приватный Процесс, моделируемый для подробного или не очень (решает разработчик модели) документирования поведения Процесса. Таким образом, информация, необходимая для выполнения Процесса (например, выражения формальных условий), как правило, не включается в невыполняемые процессы.
Если при моделировании процесса используется нотация Зон ответственности (swimlanes-like notation) (например, Взаимодействие, см.ниже), то приватный Бизнес-процесс находится в отдельно взятом Пуле. Поток элементов данного Процесса также находится в Пуле и не может выходить за его границы. Поток сообщений, в свою очередь, может пересекать границы Пула для того, чтобы изобразить взаимоотношения между отдельно взятыми приватными Бизнес-процессами.
Фигура 10.4 – Пример приватного Бизнес-процесса.
10.1.1.2 Публичный Процесс
Публичный Процесс подразумевает взаимодействие между приватным Бизнес-процессом и каким-либо другим Процессом или Участником (см. фигуру 10.5). Публичный Процесс содержит лишь те Действия или их последовательность, которые используются для изображения взаимоотношений с другими Участниками. Другие внутренние Действия приватного Бизнес-процесса в публичном Процессе не отображаются. Таким образом, публичный Процесс используется для передачи внешнему миру Сообщений или их последовательности, необходимых для взаимодействия с данным Бизнес-процессом. Публичный Процесс может быть моделирован как отдельно от Взаимодействия, так и внутри него, причем последнее используется для отображения обмена сообщениями между Действиями публичного Процесса и другими Участниками. Обратите внимание, что в BPMN 1.2 публичный Процесс назван абстрактным.
Фигура 10.5 – Пример публичного Процесса
10.1.2 Использование общих для BPMN элементов
Некоторые графические элементы BPMN являются общими как для Процесса, так и для Хореографии и Взаимодействия. Все они могут использоваться на такого рода диаграммах. Следующие подразделы посвящены описанию использования в Хореографии Сообщений, Потока сообщений, Участников, Потока операций, Корреляций, Выражений, а также Сервисов.
Ключевые графические элементы шлюз и Событие также могут использовать как в Процессе, так и в Хореографии. Поскольку упомянутые выше элементы оказывают влияние на ход Процесса или Хореографии, их описанию посвящена значительная часть данной главы (см. разделы События и Шлюзы).
10.2. Действия
Действие представляет собой деятельность, выполняемую внутри Бизнес-процесса. Действие может быть как элементарным, так и неэлементарным (составным). Диаграмма Бизнес-процесса может содержать все существующие виды действий: Задачу, Подпроцесс, а также Вызов, позволяющий включать в состав диаграммы повторно используемые Задачи и Процессы. Поскольку для изображения Процесса используется набор графических элементов, а не один из них, следующие подразделы данного документа содержат подробное описание таких элементов, как Подпроцесс и Задача.
Действия – это точки выполнения работ в ходе Процесса. Они относятся к выполняемым элементам Процесса BPMN.
Класс Activity относится к абстрактным элементам и является сабклассингом элемента FlowElement (см. фигуру 10.6). Отдельно взятые подклассы Действия определяют дополнительные правила семантики, что в последующем определяет характерное для данного класса Действие.
Фигура 10.6 – Диаграмма классов элемента Activity
Класс Действия – это абстрактный суперкласс, объединяющий все отдельно взятые типы Действия.
Элемент Activity наследует атрибуты и ассоциации элемента FlowElement (см. таблицу 8.44). Таблица 10.3 содержит информацию о дополнительных атрибутах и ассоциациях элемента Activity.
Таблица 10.3 - Атрибуты и ассоциации элемента Activity
|
Название атрибута |
Описание/Использование |
|
isForCompensation: boolean = false |
Данный атрибут представляет собой индикатор, согласно которому определяется, будет ли данное Действие использовано в целях компенсации. Значение «false» означает, что выполняемое Действие - результат Стандартного потока операций. Значение «true» указывает на то, что Действие предполагается выполнять только в том случае, если в Потоке операций присутствует Компенсация и она запущена в собственной области видимости. |
|
loopCharacteristics: LoopCharac-teristics [0..1] |
Действие МОЖЕТ выполняться однократно или несколько раз. При повторном использовании Действие ДОЛЖНО иметь атрибут loopCharacteristics, определяющий критерии цикличности. При этом атрибут isExecutable Процесса должен иметь значение «true». |
|
resources: ResourceRole [0..*] |
Данный атрибут определяет ресурс, выполняющий данное Действие или отвечающий за его выполнение. Ресурсом (например, исполнителем) может являться одно лицо, группа лиц, роль или должность в организации, а также сама организация. |
|
default: SequenceFlow [0..1] |
Данный атрибут указывает на Поток операций, который получит Токен в случае, если ни одно из выражений conditionExpressions для других Исходящих потоков операций не имеет значение «true». Все эти выражения ДОЛЖНЫ БЫТЬ проигнорированы. |
|
ioSpecification: Input OutputSpecification [0..1] |
Данный атрибут определяет входные и выходные данные Действия, а также атрибуты InputSets и OutputSets для него. |
|
properties: Property [0..*] |
Свойства определяются разработчиком модели и по желанию МОГУТ БЫТЬ добавлены к атрибутам Действия. Хранятся в самом элементе Действия. |
|
boundaryEventRefs: BoundaryEvent [0..*] |
Ссылка на Промежуточное событие, присоединенное к границам Действия. |
|
boundaryEventRefs: BoundaryEvent [0..*] |
Данный атрибут ссылается на Промежуточное событие, присоединенное к границам Действия. |
|
dataOutputAssociations: DataOutputAssociation [0..*] |
Опциональная ссылка на элементы DataInputAssociation, определяющие то, каким образом будут заполняться входные данные элемента InputOutputSpecification Действия. |
|
startQuantity: integer = 1 |
По умолчанию данный атрибут имеет значение «1». Его значение НЕ МОЖЕТ быть меньше «1». Определяет количество Токенов, которые ДОЛЖНЫ поступить до начала выполнения Действия. Обратите внимание, что любое значение данного атрибута, кроме «1», подходит для моделирования продвинутым разработчиком и должно использоваться с осторожностью. |
|
completionQuantity: integer = 1 |
По умолчанию данный атрибут имеет значение «1». Его значение НЕ МОЖЕТ быть меньше 1. Определяет количество Токенов, которые ДОЛЖНЫ БЫТЬ запущены Действием. Число полученных Токенов отсылается любому Исходящему потоку операций (если выполнены какие-либо из условий Потока операций). Обратите внимание, что любое значение данного атрибута, кроме «1», подходит для моделирования продвинутым разработчиком и должно использоваться с осторожностью. |
Также, и экземпляры Действия имеют свои атрибуты, на значения которых МОГУТ ссылаться выражения. Эти значения доступны лишь в момент выполнения Действия.
Таблица 10.4 содержит информацию об атрибутах экземпляров Действия.
Таблица 10.4 - Атрибуты экземпляра Действия
|
Название атрибута |
Описание/использованию |
|
state: string = None |
Для ознакомления с допустимыми значениями см. фигуру 13.2 (Жизненный цикл Действия BPMN) в подразделе 13.2.2. |
Соединение Потока операций
Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они МОГУТ служить источниками и целями Потока операций, обратитесь к подразделу 2.5.
- Действие МОЖЕТ являться целью Потока операций и иметь любое количество Входящих потоков операций. Входящие потоки операций МОГУТ исходить как от альтернативных, так и от параллельных маршрутов.
- Если Действие не имеет ни одного Входящего потока операций, такое Действие ДОЛЖНО отображаться тогда, когда отображается Процесс.
- Для вышеприведенных правил существуют два исключения: Событие Компенсация и Подпроцесс, работающий с Событиями.
Примечание: Если Действие соединено с несколькими Входящими потоками операций, то такое явление называется Неконтролируемым потоком операций. Этот термин означает, что Действие будет отображаться по прибытии Токена по одному из имеющихся маршрутов. Прибытие Токенов по другим маршрутам не будет иметь значения. Если другой Токен прибывает по тому же самому маршруту, тогда запускается отдельный экземпляр Действия. Если необходимо, чтобы контроль Потока операций все же осуществлялся, он должен сходиться в Шлюзе, предшествующем данному Действию (для более подробной информации о Шлюзах см. подраздел Шлюзы).
- Действие МОЖЕТ являться источником Потока операций и иметь любое количество Исходящих потоков операций. Если Действие имеет несколько Исходящих потоков операций, это означает, что для каждого Потока операций создается свой параллельный маршрут (например, для каждого Потока операций, отходящего от Действия, создаются свои Токены).
- Если Действие не имеет Исходящих потоков операций, оно является конечной точкой одного или более маршрутов Процесса. При завершении События и отсутствии каких-либо других действующих параллельных маршрутов Процесс ДОЛЖЕН БЫТЬ закончен.
- Для вышеприведенных правил существуют два исключения: Событие Компенсация и Подпроцесс, работающий с Событиями.
Соединение Потока сообщений
Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они МОГУТ служить источниками и целями Потока сообщений, обратитесь к пункту 7.5.1 «Правила Соединения Потоков Операций».
Примечание: Все Потоки сообщений ДОЛЖНЫ соединять два разных Пула. Они МОГУТ БЫТЬ присоединены как к границам Пула, так и к элементам потока, находящимся внутри этого Пула. Они НЕ ДОЛЖНЫ соединять два элементам внутри одного Пула.
- Действие МОЖЕТ являться целью Потока сообщений и иметь от нуля (0) и более Входящих потоков сообщений.
- Действие МОЖЕТ являться источником Потока сообщений и иметь от нуля (0) и более Исходящих потоков сообщений.