You are on page 1of 256

Министерство образования и науки Российской Федерации

Московский государственный университет экономики,
статистики и информатики (МЭСИ)

И.Г. Фёдоров

Моделирование
бизнес-процессов
в нотации BPMN2.0
Научно практическое издание

Москва, 2013
1

УДК 004
ББК 65.23
Ф 333
Рецензенты: Божко В.П. профессор, д.э.н.
Сотников А.Н. профессор, д.ф-м.н.

Фёдоров И. Г.
Моделирование бизнес-процессов в нотации BPMN2.0:
Монография, Москва 2013 г. МЭСИ. – 255 стр.
В книге рассмотрены вопросы создания исполняемых моделей бизнес-процессов в нотации BPMN 2.0. Показано использование нотации для моделирования процессов протекающих
внутри одной организации, а так же процессов межорганизационного взаимодействия, возникающих, например, при реализации электронной коммерции. Рассмотрено моделирование следующих видов диаграмм: схем оркестровки, взаимодействия процессов, диалогов, процессной хореографии. Предлагаемое издание полностью покрывает все типы моделей, реализуемых с помощью нотации BPMN.
Книга предназначена для широкого круга специалистов,
занятых моделированием бизнес-процессов. Она окажется особенно полезной тем из них, которые владеют приемами аналитического моделирования бизнес-процесса и хотели бы перейти к разработке исполняемых моделей.

ISBN 978-5-7764-0772-7

© Фёдоров И.Г., 2013
© МЭСИ, 2013

2

СОДЕРЖАНИЕ
ВВЕДЕНИЕ
А.
Модель бизнес-процесса
Б.
Нотация моделирования
В.
Моделирование бизнес-процессов
Г.
Почему моделирование в нотации BPMN?
Д.
Чем хороша нотация BPMN
Е.
Что изложено в этой книге
Ж.
Кому рекомендуется эта книга
З.
Что использовалось принаписании этой книги
И.
Благодарности

17
17
17
17
19
20
21
22
23
24

1.
БИЗНЕС-ПРОЦЕССЫ И ПРОЦЕСНОЕ УПРАВЛЕНИЕ
1.1.
Производительность труда в непроизводственнй сфере
1.2.
Причины низкой производительности
1.3.
Недопустимо подменять процессное управление автоматизацией
1.4.
Процесс как конвейер
1.5.
Бизнес-процесс
1.6.
Операции и действия
1.7.
Имя бизнес-процесса
1.8.
Управление бизнес-процессами
1.8.1. Три уровня управления бизнес-процессами
1.9.
Типы информационных систем
1.9.1. Процессно-ориентированные информационные системы
1.9.2. Системы управляемые моделью
1.10.
Системы управления бизнес-процессами
1.11.
Классификация бизнес-процессов
1.11.1. Основные, вспомогательные и обеспечивающие
1.11.2. Сквозные процессы
1.11.3. Структурированные процессы
1.11.4. Внутри и межорганизационные процессы
1.11.5. Процессы автоматизированные и автоматические
1.12.
Процесс и документооборот
1.13.
Объект управления процесса
1.13.1. Маркер потока управления процесса
1.13.2. Параллельные потоки управления процесса
1.13.3. Многопоточные операции
1.14.
Модель бизнес-процесса

25
26
27
27
28
28
29
30
31
31
33
33
34
35
36
36
37
38
40
41
41
42
43
44
44
45

3

1.14.1.
1.14.2.
1.14.3.
1.15.
1.16.
1.17.
1.17.1.
1.17.2.
1.18.

Процесс описывает работу
Способы декомпозиции процесса
Функциональные и процессные модели
Исполняемая модель бизнес-процесса
Экземпляр процесса
Версия процесса
Версия модели процесса
Версионировние экземпляров процесса
Стандарты описания бизнес-процессов

46
46
47
47
50
50
50
50
51

2.
2.1.
2.2.
2.3.
2.3.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.
2.4.
2.4.1.
2.5.
2.5.1.
2.6.
2.7.
2.7.1.
2.8.

СПЕЦИФИКАЦИЯ BPMN 2.0
История развития нотации BPMN
Область применения нотации BPMN
Обзор основных элементов нотации
Элементы управления
Соединительные элементы
Элементы данных
Зоны ответственности
Артефакты
Субклассы нотации BPMN
Пример использования элементов нотации BPMN
Категории диаграмм бизнес-процессов
Диаграммы оркестровки
Схемы взаимодействия
Хореография процессов
Схема диалогов
схемамы оркестровки, диалогов хореографии

54
55
57
58
58
59
60
60
61
61
63
64
65
70
71
72
72

3.
3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
3.1.7.
3.2.
3.2.1.

ОПЕРАЦИИ
Виды операций
Интерактивная операция
Ручная операция
Автоматичесая операция
Операция сценарий
Операция бизнес-правило
Операция отправка и получение сообщения
Абстрактная операция
Маркеры операции
Маркер подпроцесса

73
73
74
74
75
75
75
76
76
77
77

4

3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.2.7.
3.3.
3.4.
3.5.
3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.5.5.
3.5.6.
3.5.7.

Маркер цикла
Маркер параллельного выполнения
Маркер последовательного выполнения
Маркер Ad-Hoc операции
Операция компенсация
Комбинации маркеров подпроцесса
Группа Операций
Модель Процесса
Подпроцесс
Вложенный подпроцесс
Повторно используемый подпроцесс
Вызывающая операция
Область действия данных при вызове глобально известного
подпроцесса
AD-Hoc Подпроцесс для конкретного случая
Событийный подпроцесс
Транзакционный процесс

78
78
80
80
81
82
83
84
85
85
87
88
89
90
91
94

4.

ПОТОКИ УПРАВЛЕНИЯ.

98

5.
5.1.
5.2.
5.2.1.
5.2.2.
5.2.3.

99
99
100
101
103

5.6.

ЛОГИЧЕСКИЕ ОПЕРАТОРЫ
Логические операторы и бизнес правила
Типы Логических операторов
Логический оператор «И»
Логический оператор «ИЛИ» управляемый данными (OR)
Логический оператор «Исключащее ИЛИ» управляемый данными
(XOR)
Логический оператор комплексное условие
Событийный оператор «Исключающее ИЛИ»
Событийный оператор «Исключающее ИЛИ», (создает новый
экземпляр процесса)
Событийный оператор «И» (создает новый экземпляр процесса)

6.
6.1.
6.2.
6.2.1.
6.2.2.
6.2.3.

СОБЫТИЯ
Типы событий
Классификация событий
Начальные, промежуточные и конечные
Генерирующие и обрабатывающие
Независимые и прикрепленные

5.3.
5.4.
5.5.

5

105
108
109
111
112

113
114
115
115
115
116

6.11.неявная адресация получателя сообщения Начальные события Составное взаимоисключающее стартовое событие Составное параллельное стартовое событие Способы старта событийного подпроцесса Завершающие события Простое завершающее Событие Событие-прекращение Завершающее событие-сообщение События.5.14.14.1. 6.10.5.3.4.10. 6.8. Прерывающие и непрерывающие События и данные Сигнал Обработка сигналов Сообщения Потоки сообщений Диалоги Отправка и получение сообщений Семантика оправки и получения сообщений Явная адресация получателя сообщения Корелляция .1.11. 6. 6.1.5. 6.5.6. 6. 6. 6.2.14.7. 6.5. 6.5. 6.12.2. 6. устанавливающие статус завершения подпроцесса Событие-ошибка Событие-эскалация Событие-отмена Событие-компенсация Промежуточные события Промежуточные события. 6.2.5. 6.3.2.14.9.2.3.4. 6.8.1.4.1. 6.12. 6. 6.3. 6. 6.4. 6.4. 6. 6.11.5.11.13.3.12. 6. 6.5.12. 6.10.12. размещаемые в потоке управления процесса Простое промежуточное событие Промежуточное событие для работы с сообщениями Событие-таймер Промежуточное событие-условие Промежуточное Составное событие Промежуточное Составное параллельное событие Событие-ссылка События.7.11.1.6. 6. 6. 6.12.10.6. 6. 6. прикрепляемые к границам операций Ретрансляция события Обработка прерывающих и непрерывающих событий Прерывающее событие-таймер Непрерывающее событие-таймер 6 117 117 118 119 121 122 123 125 126 127 127 129 131 132 133 134 135 135 136 137 138 138 139 140 140 141 143 143 144 144 145 145 145 146 147 149 149 150 . 6.4. 6.2.12. 6.6. 6.12.3.12. 6.

5.1.7.5. ИСКЛЮЧИТЕЛЬНЫЕ СИТУАЦИИ Классификация исключительных ситуаций События для обработки исключительных ситуаций Место возникновения исключительных ситуаций Исключительная ситуация в операции Исключительная ситуация в процессе Исключительная ситуация во внешней среде Уровни обработки Исключительных ситуаций Обработка на уровне операции Обработка во вложенном подпроцессе Обработка в вызывающем процессе Действия после обработки исключительной ситуации Без возврата в точку прерывания.1. 7.3. 8.1. 9.7.3. 7.8.1. 8. не прерывающие исполнение процесса Событие-эскалация Обработка эскалации Обработка непрерывающего события-эскалация Обработка компенсации 152 152 154 155 155 156 157 158 158 159 159 161 161 161 161 162 162 163 164 165 166 8.1. 9. 8. 7.2. прерывающие исполнение процесса Исключения.1.1. 7.3. 7.2.1.8.2.2.1. 7.6. 7.2.5.5.4.1.1.7.2. 7.1.1. 9. 8.3. 9. 8. 7. 7.1. 7.9.3. 7.6.1.3.6. ОБЪЕКТЫ ДАННЫХ Жизненный цикл и доступность объектов данных Способы отображения ассоциации на схеме процесса Статус обработки документа Коллекция объектов данных Хранилище данных Внешний вход и выход процесса Семантика исполнения ассоциации данных Полезная информационная нагрузка сигналов и оповещений Потоки данных и управления Замечание о работе с данными: 170 172 173 174 174 175 176 177 177 178 179 9.4. 7. 7. 8. 8.2. 8.2.2.7. 7.7.1.6.3. 8.1.1.4. 7. 8. ЗОНЫ ОТВЕТСТВЕННОСТИ (ДОРОЖКИ И ПУЛЫ) Ролевая модель Как проблема решается в BPM Пул и дорожка Пул 181 181 183 183 184 7 . 7. 7.2.1.4. 7. 7.1. С возвратом в точку прерывания Влияние исключения на текущий процесс Исключения.4.

Чередование маршрутов (CP17) 210 10. Явное завершение (CP11) 212 10. Статус исполнения 209 10.5.9.5.2. Параллельное исполнение (CP2) 194 10. Прекратить исполнение задания (CP19) 213 10. Множественное слияние (CP8) 202 10.1.3. Рекурсиивное исполнение (CP22) 206 10. 9.5.2. Итерации 205 10.2.2. Отложенный выбор (CP16) 209 10. Паттерны завершения 212 10. Неструктурироыванные паттерны 10. Прекратить исполнение группы операций (CP25) 214 10.2.2. Базовые процессные паттерны 193 10. Множественный выбор (CP6) 198 10.5. Структурированные паттерны 199 10.1.1.1.5. Итерация (CP21) 205 10. 9. Параллельное исполнение.5.1.3. Простое слияние (CP5) 196 10.5.4. число экземпляров известно на этапе исполнения (CP14) 209 10.4.1.3.3.1. число экземпляров известно на этапе моделирования (CP13) 208 10. Параллельное исполнение без синхронизации (CP12) 207 10. 9.6.2. координацию исполнения (CP18) 211 10.1.2.4.4.2. Альтернатива (CP4) 195 10. Параллельное исполнение с синхронизацией. Структурированное слияние с синхронизацией (CP7) 199 200 10.1.3.1.5.3.2.6.3.4.6. Дорожка Отбор исполнителей Спецификация WS-Human Task Назначение исполнителей в WS-Human Task 184 186 187 189 10. Прекратить исполнение многопоточной операции (CP26) 215 8 .6.3. Параллельное исполнение 206 10.3.2.1. ПРОЦЕССНЫЕ ПАТТЕРНЫ 193 10.2.6. Последовательное исполнение (CP1) 194 10.6.2.2. Прекратить исполнение процесса (CP20) 214 10.3. Многократное повторение (CP10) 205 10.4.1. Паттерны слияния и синхронизации 199 10. Дискриминатор (CP9) 202 10.1.6.4.3. Синхронизация потоков (CP3) 195 10.4.

2. Множественный ответ 11. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ 11.3.3. Уровни взаимодействия 11. Рассылка сообщений и обработка полученных результатов 11. 231 233 234 СХЕМЫ ДИАЛОГОВ Мульти-пулы Комплексные диалоги 13.1.2.5. Список полученных сообщений 11. 10. СХЕМЫ ХОРЕОГРАФИИ 13.7. Отправка сообщения 11.3.2.9.3.4. Множественные участники взаимодействия 11. Очередь входящих сообщений 11.3.7.7. Негарантированный ответ на запрос 11.11.3.3. Паттерны межорганизационного взаимодействия 11.4.1.3.1. 12. Графические элементы хореографии 13. 12.2. Промежуточные события 13.10.2.8.3. Использование логических операторов в хореографии 236 236 241 241 241 242 244 14.3. 250 ЗАКЛЮЧЕНИЕ ПЕРЕКРЕСТНЫЕ ССЫЛКИ 251 СПИСОК ЛИТЕРАТУРЫ: 255 9 . Получение сообщения 11. Широковещательная рассылка 11.1. Синхронизация с помощью событий Синхронизация без запоминания оповещения (CP23) Синхронизация с запоминанием оповещения (CP24) 216 216 217 11. Начальные события 13.3.10. Запрос с перенаправлением 218 218 220 221 222 223 223 224 225 226 227 227 228 229 229 12. 10. Отправка/получение сообщения 11.1.6. Использование событий в хореографии 13.2.3.3.1.2.2.3. Веерная рассылка сообщений 11. Завершающие события 13.7.

0 Рисунок 3-2. Рисунок 2-17. Повторно используемый подпроцесс Рисунок 3-10. закрытые процессы Рисунок 2-12. Область действия переменных событийного подпроцесса Рисунок 3-18. Схема диалога участников процесса Рисунок 2-18. Ad-hoc операции Рисунок 3-4. открытые процессы Рисунок 2-14. Рисунок 3-13. Пример аналитической схемы процесса Рисунок 2-10. Свернутый и развернутый Ad-Hoc подпроцессы Рисунок 3-14. Публичное взаимодействие. Операция компенсация Рисунок 3-5. Область действия переменных вложенного процесса Рисунок 3-8. Закрытый процесс Рисунок 2-8. Основной набор элементов Рисунок 2-6.СПИСОК ИЛЛЮСТРАЦИЙ: Рисунок 2-1. Основной набор элементов нотации Рисунок 2-5. Основные графические элементы нотации BPMN Рисунок 2-3. Открытый процесс (раскрытый пул) Рисунок 2-9. Вызывающая операция и глобальный процесс. Развернутый и свернутый событийный подпроцессы Рисунок 3-16. Подпроцесс с параллельно исполняемыми заданиями Рисунок 3-9. один открытый процесс Рисунок 2-13. Публичное взаимодействие. Пример исполняемой схемы процесса Рисунок 2-11. Группа задач Рисунок 3-6. диалогов и хореографии Рисунок 3-1. Субклассы нотации BPMN Рисунок 2-4. История развития нотации BPMN Рисунок 2-2. Свернутый транзакционный подпроцесс Рисунок 3-19. Обработка транзакции 10 56 58 62 63 64 65 66 66 67 67 68 68 70 71 71 72 72 73 76 81 82 83 86 86 87 90 88 89 89 90 91 92 93 94 95 97 . Моделирование обмена сообщениями между участниками Рисунок 2-16. Публичное взаимодействие. Развернутый вложенный подпроцессы Рисунок 3-7. Соотношение между схемами оркестровки. Типы операций в нотации BPMN 2. Событийный подпроцесс Рисунок 3-17. Глобальная пользовательская операция Рисунок 3-12. Подпроцесс «двойного» назначения Рисунок 3-11. Подпроцесс «Ad-Hoc» с зависимыми операциями Рисунок 3-15. Операции отправки и получение сообщения Рисунок 3-3. Эквивалентные публичный (а) и приватный (б) процессы Рисунок 2-15. Схема хореографии.

Пример взаимоисключающего старта 132 Рисунок 6-17. Потоки сообщений 122 Рисунок 6-8. Независимые и прикрепленные события 116 117 Рисунок 6-4. Классификация событий по типу обработки 116 Рисунок 6-3. Диалог участников 124 Рисунок 6-10. Пакетная обработка с использованием сигналов 121 Рисунок 6-7. Парные логические операторы "ИЛИ". Парные операторы «Исключающее ИЛИ» 107 108 Рисунок 5-10. Слияние «Исключающее ИЛИ» 107 Рисунок 5-9. Оператор ветвления комплексное условие Рисунок 5-11. Явная адресация получателя сообщения 127 Рисунок 6-13. Парные логические операторы "И" 103 Рисунок 5-4. Взаимодействия 124 Рисунок 6-11. Классификация событий по влиянию на выполнение Рисунок 6-5. 105 Рисунок 5-7. Завершающее событие-эскалация 138 11 . Классификация событий по местоположению в процессе 115 Рисунок 6-2. Завершающее событие-сообщение 137 Рисунок 6-22. Хореографии. Подпроцесс без стартового события. Процесс с несколькими точками старта Рисунок 6-15. Событийный оператор «И» (создает экземпляр процесса) 112 Рисунок 6-1. Логический оператор слияния «И» 102 Рисунок 5-3. Инициирующее диалог и ответное сообщения 123 Рисунок 6-9. Событие-прекращение 136 Рисунок 6-21. Обмен сообщениями между двумя участниками 126 Рисунок 6-12. (создает новый экземпляр процесса) 111 Рисунок 5-14. 130 131 Рисунок 6-14. Процесс «двойного назначения» 131 Рисунок 6-16. Потоки сообщений на диаграммах: Оркестровки. Ассоциация данных в событиях 118 Рисунок 6-6. Оператор ветвление «ИЛИ» управляемый данными 104 Рисунок 5-5. Событийный оператор «исключающее ИЛИ» 110 Рисунок 5-13. Логический оператор ветвления «И» 102 Рисунок 5-2.Рисунок 5-1. Завершающее событие-ошибка 138 Рисунок 6-23. Простое завершающее событие 135 Рисунок 6-20. Событийный оператор «исключающее ИЛИ». Составное стартовое событие 132 Рисунок 6-18. Оператор слияние «ИЛИ» управляемый данными 104 Рисунок 5-6. Событийный подпроцесс для события эскалация 133 Рисунок 6-19. Оператор слияния комплексное условие 109 Рисунок 5-12. Ветвление «Исключающее ИЛИ» управляемое данными 106 Рисунок 5-8.

Обработка ошибки без возврата в основной процесс Рисунок 7-7. прерывающее исполнение процесса 162 Рисунок 7-9. Простое промежуточное событие. Пример завершение процесса 139 Рисунок 6-25. Завершающее событие-компенсация 140 Рисунок 6-26. Простое бизнес исключение 157 Рисунок 7-3. Промежуточное составное параллельное событие 145 Рисунок 6-32. Промежуточное событие-условие 145 Рисунок 6-31. Хранилище данных 176 Рисунок 8-9. Статус обработки информационного объекта 174 Рисунок 8-7. 160 161 Рисунок 7-6. Исключительная ситуация во внешней среде 158 Рисунок 7-4. инициируемый событием-компенсация Рисунок 7-16. Обработка прерывающего прикрепленного события Рисунок 6-36. Направленная ассоциация данных 173 Рисунок 8-5. Промежуточное событие-таймер 144 Рисунок 6-29. Зоны видимости объекта данных 172 Рисунок 8-3. Вложенные подпроцессы 172 Рисунок 8-2. События-сообщения. 146 Рисунок 6-33. Обработка прерывающего события-эскалация 165 Рисунок 7-11. Обработка непрерывающего прикрепленного события-таймер150 Рисунок 6-37. Передача данных в повторно используемый подпроцесс 173 Рисунок 8-4. Входные и выходные данные процесса 176 12 . Обработки непрерывающего события-эскалация 165 Рисунок 7-12. Откат. Ретрансляция события 148 150 Рисунок 6-35. Обработка события прикрепленного к границе процесса.Рисунок 6-24. непрерывающее исполнение процесса 163 Рисунок 7-10. Непрерывающее прикрепленное событие-таймер 151 Рисунок 7-1. размещаемое в потоке 143 Рисунок 6-27. Обработки события-компенсация 167 Рисунок 7-14. Событие-ссылка. Исключение. Откат с использованием событийного подпроцесса 168 168 Рисунок 7-15. Коллекция объектов данных 175 Рисунок 8-8. Ретрансляция ошибки из операции 148 Рисунок 6-34. Пример использования отмены и компенсации 169 Рисунок 8-1. Исключение. Обработка события прикрепленного к границе операции 156 Рисунок 7-2. Обработка ошибки с возвратом в основной процесс 161 Рисунок 7-8. Ненаправленная ассоциация данных 174 Рисунок 8-6. Обработки непрерывающего события-эскалация 166 Рисунок 7-13. размещенные в потоке 143 Рисунок 6-28. Обработка бизнес исключения во вложенном подпроцессе 159 Рисунок 7-5. Промежуточное событие-условие 144 Рисунок 6-30.

Прекратить исполнение многопоточной задачи Рисунок 10-28. Межорганизационное взаимодействие. Парные операторы альтернативный выбор Рисунок 10-8. Последовательное исполнение Рисунок 10-2. Множественный выбор Рисунок 10-7. Непарные узлы ветвления и слияния Рисунок 10-12. Межорганизационное взаимодействие. Прекратить исполнение группы задач Рисунок 10-27. Явное завершение. Параллельное исполнение Рисунок 10-3. Простое слияние Рисунок 10-6. Иерархия дорожек процесса Рисунок 9-2 Основные стадии выполнения операции Рисунок 10-1. Синхронизация без запоминания оповещения Рисунок 11-1. Чередование маршрутов Рисунок 10-21. Явное завершение Рисунок 10-23. Дискриминатор. Выбор взаимоисключающих возможностей Рисунок 10-5. открытый процесс Рисунок 11-3. Мульти-пул Рисунок 11-5. Детализация межорганизационного взаимодействия Рисунок 11-4. Параллельное исполнение с синхронизацией (число экземпляров известно на этапе исполнения) Рисунок 10-19. Итерация Рисунок 10-16. Структурированное слияние с синхронизацией Рисунок 10-9 Неструктурированный паттерн Рисунок 10-10 Структурированный паттерн Рисунок 10-11. Координация исполнения Рисунок 10-22. Прекратить исполнение задания Рисунок 10-25. Синхронизация потоков Рисунок 10-4.Рисунок 8-10. Параллельное исполнение с синхронизацией (число экземпляров известно на этапе моделирования) Рисунок 10-18. Прекратить исполнение процесса Рисунок 10-26. не детерминированная семантика исполнения Рисунок 10-24. Паттерн отправка сообщения 13 176 186 192 194 195 195 196 197 198 200 200 201 201 202 203 204 205 206 208 208 209 210 211 212 213 213 214 214 215 216 217 219 219 220 221 223 . Чтение информации из внешнего хранилища Рисунок 9-1. счетчик Рисунок 10-14. Параллельное исполнение без синхронизации Рисунок 10-17. Дискриминатор Рисунок 10-13. Отложенный выбор Рисунок 10-20. закрытый процесс Рисунок 11-2. Многократное повторение Рисунок 10-15.

Схемы взаимодействия (а) и диалога (б) 233 233 Рисунок 12-2. Атрибуты циклического исполнения операции Таблица 3-4. Комплексный диало 234 Рисунок 12-5.Использование логических операторов на схеме хореографии248 Рисунок 13-12. Диалог участников. Диаграмму взаимодействия. Глобальная задача хореографии 240 Рисунок 13-9. Декомпозиция комплексного диалога 235 Рисунок 12-6. Широковещательная рассылка 229 Рисунок 11-14. Негарантированный ответ на запрос 228 Рисунок 11-13. Использование логических операторов на схеме хорео-графии 246 Рисунок 13-11. Веерная рассылка сообщений 226 Рисунок 11-10. Комбинации маркеров подпроцесса 14 39 74 77 78 79 83 . Виды операций Таблица 3-2. Список полученных сообщений 226 Рисунок 11-11. хореография 237 Рисунок 13-2. мульти-пул Рисунок 12-3. Глобальный диалог 234 Рисунок 12-4. Запрос с перенаправлением 230 Рисунок 12-1. оркестровка. Комплексная диаграмма взаимодействия 235 Рисунок 13-1. Обмен сообщениями. Паттерн получение сообщения 223 Рисунок 11-7.Рисунок 11-6. Задача хореографии с двумя адресатами 238 Рисунок 13-4. несколько пар диалогов 239 240 Рисунок 13-7. Циклическая рассылка запроса 239 Рисунок 13-6. Классификация процессов по степени формализации Таблица 3-1. Веерная рассылка запроса многим участникам 238 Рисунок 13-5. Семантика параллельного исполнения Таблица 3-5. Маркеры операций Таблица 3-3. Пример ошибочной схемы хореографии 244 Рисунок 13-10. Рассылка сообщений и обработка результатов 227 Рисунок 11-12. Использование логического оператора «И» на схеме хореографии 249 СПИСОК ТАБЛИЦ Таблица 1-1. Очередь входящих сообщений 225 Рисунок 11-9. Паттерн отправка и получение сообщения 224 Рисунок 11-8. Однонаправленная задача хореографии 237 Рисунок 13-3. Комплексная задача хореографии Рисунок 13-8.

Моделирование событий в нотации BPMN 114 Таблица 6-2. Обзор завершающих событий 242 Таблица 13-3.Обработчики событий. прикрепляемые к операции 147 170 Таблица 8-1 Графические элементы для изображения данных Таблица 11-1. Обзор завершающих событий 134 Таблица 6-6. Обзор начальных событий 241 Таблица 13-2. Графические элементы для работы с сигналами 119 Таблица 6-3.Таблица 4-1. Операция и событие для отправки и получения сообщения 125 Таблица 6-4. 232 Таблица 13-1. Обзор начальных событий 129 Таблица 6-5. Элементы схемы диалогов. размещаемые в потоке управления 142 Таблица 6-7. 242 Таблица 13-4. Обработчики событий. Потоки управления 98 Таблица 5-1. Число участников взаимодействия 221 Таблица 12-1. прикрепляемые к задаче хореографии 243 15 . Обработчики промежуточных событий. Виды логических операторов 101 Таблица 6-1. События.

.

В реинжиниринге описание бизнес-процессов проводится с целью дальнейшей реорганизации. МОДЕЛЬ БИЗНЕС-ПРОЦЕССА Моделью принято называть некоторый материальный или мысленно представляемый объект или явление. которое пользователь ожидает от соответствующей бизнес системы. Нотация — это синтаксис графического языка моделирования. являющийся упрощённой версией моделируемого объекта или явления (прототипа) и в достаточной степени повторяющий свойства. текстовое. Модель бизнес-процесса есть описание порядка выполнения работ. в которых он может отличаться от прототипа).ВВЕДЕНИЕ А. Разрабатываемая с помощью соответствующей нотации модель бизнес-процесса должна реализовывать поведение. Под бизнес моделью принято понимать формализованное (графическое. точное и адекватное описание системы. Для этого необходимо понять. МОДЕЛИРОВАНИЕ БИЗНЕСПРОЦЕССОВ Различают аналитическое моделирование бизнес-процессов и разработку исполняемых моделей бизнес-процесса. Набор свойств модели определяется целями моделирования. НОТАЦИЯ МОДЕЛИРОВАНИЯ Нотация моделирования (далее нотация) — совокупность графических элементов. существенные для целей конкретного моделирования (опуская несущественные свойства. символьное) описание бизнес-процессов. приводящих к достижению вполне определенного и воспроизводимого результата. которые используются для разработки моделей деятельности компании. Модель должна давать полное. Поведение – это семантика языка моделирования. табличное. В. как ис17 . Б.

что является одной из причин. визуально кажутся простыми и понятными. поэтому достаточно ограничиться его укрупненным описанием. Возникает опасная ситуация. Чем детальнее описание. иначе работа соответствующей системы окажется невозможной. Если в ходе тес18 . требуется ли нести высокие затраты на однократное моделирование бизнес-процессов предприятия. поэтому аналитики предпочитают опускать детали. модель не в полной мере описывает процесс. описывающие бизнес-логику. Может возникнуть вопрос. предъявляемым к информационной системе. Напротив. Диаграммы. разработчики вносят соответствующие изменения прямо в программный код и не модифицируют соответствующие модели процессов. зачастую достаточно важные. тем сложнее оно становится для восприятия и понимания. Часто.полняется процесс. если полученные модели так быстро теряют свою актуальность. Поэтому многие аналитики используют их для согласования с представителями бизнеса. Управление бизнес-процессами порождает потребность глубокого описания всех мельчайших деталей исполнения. разработчикам ИТ систем приходится повторно собирать пропущенные сведения. а существует в головах программистов. почему модель процесса на бумаге не соответствует логике работы ИТ системы. Вследствие чего модели быстро теряют свою актуальность. без которых последующее исполнение окажется невозможным. действия выполняемые. причем их представление о процессе может существенно отличаться от взглядов аналитика. когда показатели процесса выходят за рамки допустимых диапазонов. поскольку не включают бизнесправила. Обычно аналитические модели ограничиваются показом только самых вероятных сценариев исполнения. исполняемые модели должны показывать все возможные маршруты исполнения процесса. не содержат редко применяемых маршрутов обработки. обнаружив несоответствие модели процесса требованиям. графики исполнения. Моделирование часто рассматривается только как средство документирования процессов. Однако простота обманчива. детали не фиксируются явно.

различные типы диаграмм потоков работ. ПОЧЕМУ МОДЕЛИРОВАНИЕ В НОТАЦИИ BPMN? Для моделирования бизнес-процессов используются различные нотации. рынка как IBM. предприятие осуществляет долговременные инвестиции в повышение эффективности своего бизнеса. которую ставили разработчики спецификации BPMN — создание стандартной нотации понятной широкому кругу бизнес пользователей: бизнес-аналитикам. ORACLE. рынка и широко используется в программных системах. Например. Все они находят широкое применение для построения аналитических моделей. но не предназначены для разработки исполняемых моделей. Для создания исполняемых процессных моделей все чаще используется нотация BPMN. Как следствие.тирования выясняется. систем Основная цель. BPMN призвана служить связующим зве19 . следящим за работой предприятия и управляющих им. техническим разработчикам. которое не в полной мере соответствует ожидаемого пользователем. используются только в составе программных средств этой фирмы. у них отсутствует спецификация семантики исполнения. Эти нотации обладают семантикой. Зачастую они являются проприетарными. разработанных такими лидерами ИТ. то соответствующие изменения вносятся в саму модель. Поддержка лидеров ИТ. менеджерам. Спецификация. широкое распространение получила нотация EPC фирмы Software AG. создающим и улучшающим процессы компании. последняя не теряет своей актуальности. которая описывается в руководствах по моделированию в соответствующей нотации. ответственным за реализацию процессов. что модель реализует поведение. SOFTWARE AG и др. Выполняя разработку исполняемых моделей бизнес-процесса. Поскольку они не предназначены для разработки исполняемых моделей. отрасли обеспечивает этой нотации широкую популярность у бизнес-аналитиков и разработчиков ИТ. Г. Она стала стандартом для лидеров ИТ.

большую часть работ по созданию исполняемой модели может выполнить бизнесаналитик. Д. можно говорить. Такие тесты позволяют эффективно выявлять и расшить узкие места процесса. модель расширяется. поскольку базируются на результатах измерений. они при этом видят разный набор слоев модели. но и испытать ее в условиях реальной эксплуатации. это уменьшение разрыва между моделями «Как-Есть» и «Как-Должно-Быть». Благодаря работе с единой моделью упро20 . а переход к модели «КакДолжно-Быть» осуществляется путем проведения небольших эволюционных изменений. как должен исполняться бизнес-процесс. если аналитик и разработчик в паре работают над единой моделью. и ИТ разработчиками. а не на субъективном представлении консультанта. Интересно отметить. Применение нотации BPMN обеспечивает бизнес пользователям ряд преимуществ. уточняется и углубляется. которые реализуют поставленные требования. которая дает общее представление о характере исполнения бизнес-процесса.ном между бизнес пользователями.о. найти более эффективные способы обработки информации. Т. Исполняемая модель помогает не только раскрыть и верифицировать модель бизнес-процесса. что полученные модели «Как-Должно-Быть» носят объективный и достоверный характер. По мере роста понимания того. В первую очередь. которые в понятной форме могут специфицировать свои потребности. На практике это означает. что она позволяет описать поведение ИТ системы с минимальным программированием. ЧЕМ ХОРОША НОТАЦИЯ BPMN Нотация BPMN позволяет начать с разработки высокоуровневой аналитической модели. без участия программистов и разработчиков. Преимущество нотации BPMN заключается в том. что работа с процессом всегда начинается с модели «Как-Есть». причем при постоянном контроле за изменением метрик процесса. Результатом моделирования становится исполняемая модель бизнес-процесса. в разрабатываемых информационных системах. Таким образом.

щается взаимодействие между участниками команды. предназначенных для бизнес-аналитиков и раскрывающих особенности моделирования в нотации BPMN. Благодаря этому удается сблизить представления бизнес пользователей и разработчиков о модели процесса. что приводит к непониманию и ошибкам. Он детально описывает особенности реализации нотации. Описаны основные понятия и термины бизнес моделирования. Третья глава дает общее описание основных возможностей нотации и типов моделей бизнес-процессов. на самом раннем этапе выявить степень соответствия модели реальному бизнес-процессу и таким образом сделать процедуру верификации бизнес-процесса более объективной. К сожалению.. Это вызывает необходимость создания справочных пособий и методических материалов. Предлагаемая читателю книга предназначена. описать синтаксис моделирования и семантику исполнения модели. Книга структурирована следующим образом. Во второй главе дается объяснение основных терминов процессного управления. что бы заполнить этот пробел. что выгодно отличает предлагаемый подход от традиционного. но и протестировать его работу. Е. Она 21 . Однако он предназначен в первую очередь для разработчиков программных средств BPMS и в меньшей степени предназначен для бизнес-аналитиков. В ней сделана попытка системно изложить особенности нотации и правила моделирования бизнес процессов в нотации BPMN. Простота моделирования позволяет бизнес-аналитику с минимальной помощью разработчика не только создать работающий прототип. давали бы рекомендации по ее применению. Бизнес пользователи видят эту же модель. где разные категория разработчиков использует различные модели. на отечественном рынке отсутствуют русскоязычные издания. ЧТО ИЗЛОЖЕНО В ЭТОЙ КНИГЕ Стандарт BPMN является доступным в интернет документом. которые бы систематично описывали саму нотацию.

Ж. правильное использование соответствующих графических элементов является залогом правильного моделирования. которые позволяют описать реакцию системы на изменения внешнего по отношению к процессу бизнес окружения. Седьмая глава описывает события.знакомит с группами элементов моделирования и типами моделей. которые позволяют ввести в модель бизнес-процесса элементы управления. Предлагаемое издание полностью покрывает все типы моделей. Паттерны являются предметом широкого обсуждения на конференциях. например. рассматриваемых по-отдельности. Глава тринадцатая описывает моделирование схем диалога. Семантика поведения группы логических операций может существенно отличаться от семантики каждого из операторов. реализуемых с помощью нотации BPMN. при реализации электронной коммерции. Глава четырнадцатая посвящена моделированию схем процессной хореографии. Восьмая глава описывает практику применения событий для моделирования реакции системы на возникающие ошибки и исключительные ситуации. возникающего. Двенадцатая глава показывает моделирование диаграмм взаимодействия процессов. В этой же главе дается рекомендация по использованию логических операторов и бизнес правил. Одиннадцатая глава посвящена обзору процессных паттернов. Операция есть базовый элемент нотации. Шестая глава посвящена логическим операторам. Девятая глава посвящена связи модели процесса с данными. Пятая глава описывает потоки управления модели бизнес-процесса. Десятая глава посвящена моделированию человеческих ресурсов участников бизнес-процесса. реализуемых в нотации BPMN. обрабатываемыми в ходе исполнения процесса. КОМУ РЕКОМЕНДУЕТСЯ ЭТА КНИГА Эта книга может быть рекомендована широкому кругу спе22 . посвященных системам управления бизнес-процессами. Четвертая глава посвящена операциям бизнес-процесса и особенностям их моделирования. Последующие главы описывают процессы межорганизационного взаимодействия.

Не меньший интерес она может представлять для специалистов клиентского обслуживания. занятых моделированием бизнес-процессов. Она окажется особенно полезной тем из них. например. посвященном вопросам моделирования BPMN.0.Сильвер делится своим опытом моделирования бизнес-процессов. в которой Б. обучающимся по специальностям бизнес-аналитика и ИКТ. управления рисками. финансового сектора существуют департаменты банковских. урегулирования убытков. Спецификация дает сухое описание синтаксиса и семантики моделей. где его ведущий Брюс Силвер дает рекомендации по использованию моделей BPMN. Так же заслуживают внимания блоги «Главное процесс» и 23 . а так же «BPMN Modeling and Reference Guide» авторы которой С. например. Хочется выделить «BPMN Method & Style». Во-первых.циалистов. Автор внимательно следит за публикациями в интернете. материал окажется полезен бизнес аналитикам и специалистам технологам бизнеса. В большинстве организаций. Наконец. страховых и финансовых технологий. был тщательно проработан и проанализирован стандарт BPMN 2. Издание окажется полезным аспирантам и студентам старших курсов. специалисты информационных технологий смогут ознакомиться с новыми принципами моделе-ориентированной разработки процессных информационных систем. которые владеют приемами аналитического моделирования бизнес-процесса и хотели бы перейти к разработке исполняемых моделей. З. Хочется выделить англоязычный блог «WPMS Watch». Разработчики стандарта выпустили несколько книг на английском языке. Уайт и Д Майерс дают подробный обзор возможностей нотации. В первую очередь. ЧТО ИСПОЛЬЗОВАЛОСЬ ПРИНАПИСАНИИ ЭТОЙ КНИГИ При написании этой книги были использованы следующие материалы. поэтому для улучшения понимания конструкций моделирования было необходимо привести достаточное число примеров и иллюстраций.

И.н. Курышевым.С.А. которые помогли довести этот труд до конца. использованных в книге. Автор благодарит сотрудников факультета ИКТ и кафедры ПИЭ МЭСИ за ценные обсуждения и советы. Тельнову за содействие в подготовке материала и помощь в организации данной публикации.А. Рыбак и другие. Е.«Изучаем BPMN». приведенные в этой книге. оказали неоценимую помощь при подготовке рукописи и ее оформлении. Морозов. 24 . которые практически проверяли примеры. Ю.э. В оформлении рукописи приняли активное участие Н.Ф. БЛАГОДАРНОСТИ В написании этой книги автору помогали аспиранты и студены МЭСИ. Анализ обоих блогов оказался очень полезен при подготовке практических примеров. Главы 7 и 10 были написаны совместно с К. Особая благодарность заведующему кафедрой ПИЭ профессору д. их автор Анатолий Белайчук разбирает многочисленные примеры использования BPMN для бизнесмоделирования.

в непроизводственной сфере считается допустимым только самое общее описание действий персонала. непроизводственный сектор не слишком решительно движется по пути процессного управления. связанные с неудовлетворенно25 . знаниями и квалификацией.Чампи заметили: не продукты. при этом. не занимается регулярно своими бизнеспроцессами. добавляя или сокращая персонал. Вариативность действий может иметь ряд негативных последствий: возрастают убытки. А ведь именно процессное управление оценивается как основной резерв повышения эффективности. БИЗНЕС-ПРОЦЕССЫ И ПРОЦЕСНОЕ УПРАВЛЕНИЕ Гуру процессного управления М. в результате. оперируя экономическими критериями. В чем причина низкой эффективности и качества обслуживания клиентов? Даже сфере банковских услуг характерно отсутствие жесткой регламентации действий персонала особенно фронт-офисных операций. но и проведет к повышению качества обслуживания клиентов. они не замечают.Хаммер и Д. что приводит к большой вариативности операций. а эффективные процессы их создания и развития приносят компаниям долгосрочный и устойчивый успех. где менеджмент зорко следит за соблюдением требований производственного процесса и строго карает любые отклонения от технологии. Сотрудники склонны модифицировать свои действия в соответствии с личным опытом. что переход на процессное управление позволит не только добиться повышения эффективности и сокращения расходов на персонал. сокращению рисков. снижаются эффективность работы и качество обслуживания клиентов.1. Большинство производственных компаний уделяют пристальное внимание своим технологическим процессам и повышению их эффективности. Напротив. оптимизируют свою организационную структуру. Компании постоянно ищут пути сокращения расходов и. В противоположность реальному производству.

McKinsey Global Institute.ошибочно думать.в 2. пополнение счета .5 . приходящихся на одну банковскую операцию выше в 2-2. а платеж по счету – в 3.стью клиента уровнем обслуживания. Если со снижением эффективности процессов банки еще могут мириться. что в свою очередь является питательной средой для повышения банковских рисков. а среднее число бумажных документов в 1. 1. что высокая степень автоматизации является гарантией высокой производительности. Можно сделать вывод . ПРОИЗВОДИТЕЛЬНОСТЬ ТРУДА В НЕПРОИЗВОДСТВЕННЙ СФЕРЕ В проведенном компанией McKinsey Global Institute исследовании «Эффективная Россия: Производительность труда как фундамент роста»1 отмечается. Поэтому уменьшение вариативности действий персонала есть первоочередная задача любой организации. 2009. стремящейся к повышению своей эффективности. включая финансовый сектор. что финансовый сектор является одним из самых автоматизированных и обеспеченных ресурсами. Количество сотрудников. 26 . то увеличения рисков банки категорически допустить не могут. что производительность труда во всех отраслях. Последняя есть результат правильной организации труда. 1 Отчет: «Эффективная Россия: Производительность как фундамент роста». В России низким уровнем производительности отличаются все виды услуг – от кредитования (4% от уровня США) до платежных транзакций (13% от уровня США).8 раза. уменьшается возможности контроля со стороны менеджмента.2 раза.1.5 раза.3 раза больше. остается недопустимо низкой. Даже в лучших российских банках самые простые операции занимают в 2 – 6 раз больше времени: снятие денег со счета дольше в 6 раз. И это не смотря на то.

характерно отсутствие жесткой регламентации действий персонала. функциональная автоматизация возводит крепостные стены вокруг 27 . но умалчивает о действительно важных вопросах. что приводит к большой вариативности процессов и. ПРИЧИНЫ НИЗКОЙ ПРОИЗВОДИТЕЛЬНОСТИ Как отмечено в исследовании. модель рассказывает то. как следствие. используемых при реинжиниринге. который бы не знал. чем хорошо организованный труд сотрудников обычной квалификации. нескоординированная деятельность высококлассных специалистов. описывающие процессы компании. что уже хорошо известно. как показывает практика. Получается. когда существуют качественные модели. Т. разработчики ИС проектируют функционально-ориентированные средства автоматизации. остается вне фокуса внимания менеджмента.3. При этом происходит чудовищная подмена понятий – вместо «ломки границ между функциональными подразделениями». Сквозная технология.о. включая сектор финансовых услуг. к чему нас призывают Хаммер и Чампи. отвечают на опрос «что делает компания». НЕДОПУСТИМО ПОДМЕНЯТЬ ПРОЦЕССНОЕ УПРАВЛЕНИЕ АВТОМАТИЗАЦИЕЙ Большинство методологий моделирования бизнеспроцессов. снижению эффективности и качества обслуживания клиентов.. что делает его компания. но не раскрывают деталей о том «как она это делает». относятся к классу функциональных. Но даже в тех случаях.1.2. оказывается менее эффективной. первое противоречие заключается в попытке перейти к процессному управлению через функциональное моделирование. Сложно представить себе руководителя. При этом. всем исследуемым сферам. 1. связывающая несколько подразделений в единое целое.

он подвозит детали к месту работы. конвейер д.такие единицы работ. Бизнес-процесс реализует виртуальный конвейер. БИЗНЕС-ПРОЦЕСС Известно много определений понятия бизнес-процесс. приостановлен. Этим процесс отличается от проекта. которые радикально изменили существующий мир. а не автоматизация отдельных операций.4. Конвейер – это тщательно продуманная система организации труда. Во-первых. повторяемого результата. Реальный конвейер выполняет транспортную и синхронизирующую функции. Аналогичным образом. регламентирующая порядок выполнения операций с целью добиться наивысшей возможной производительности труда и качества результата. Целенаправленная работа. Конвейер означает стандартизацию по выпуску. все они оперируют базовым понятием «работа». Вовторых. это организация труда. приводит к изменению свойств этого объекта. что доказывается многочисленными японскими методиками управления. Таким образом. Под термином бизнес-процесс мы будем понимать совокупность работ. Например. совершаемая субъектом над объектом труда. в результате получается продукт или услуга. по работам и по нормативам. которые могут быть выполнены одним участником. бизнес-процесс – это организация труда. конвейер позволил существенно повысить производительность труда в области материального производства.этих подразделений. 1. на лицо второе противоречие между целью и средствами ее достижения. направленную на получение воспроизводимого.б. 1. который направлен на достижение уни28 . где изготовление некоторого изделия разбито на операции . ПРОЦЕСС КАК КОНВЕЙЕР Есть изобретения. исключая излишние перемещения исполнителя.5. если кто-то не успеет выполнить производственную операцию за отведенный такт времени. возникшими еще в «докомпьютерную» эру. он координирует работу.

Бизнес-процесс есть технология достижения запланированного результата. операция описывает работу. Если организация выпускает товар. посчитано. Таким образом. Для этого она должна требовать от сотрудников выполнять работу в соответствии с определенными стандартами.это единица работы. выполняемая непрерывно. что произведенный продукт будет удовлетворять нормативным требованиям. что бы все произведенные экземпляры были идентичны. Операция . а количество выходов процесса. 1. приводящую к требуемому изменению состояния обрабатываемого изделия. Бизнеспроцесс есть «технология производства» услуг. Для этого технология предлагает разложить работу на элементарные составляющие.о. на одном рабочем месте. Если организация оказывает услуги. в отличие от материального производства.б. которые. однозначно идентифицирован. требование воспроизводимости результата обуславливает повторяемость выполняемых работниками действий. повторяемость продукта процесса. полученное за определенный интервал времени м. производимых над обрабаты29 . она ожидает. Операция состоит из действий или набора действий. В этом определении делается упор на воспроизводимость. зафиксировать и стандартизовать их. В результате выполнения операции состояние предсказуемо изменяется. то она хочет. Технологией называют совокупность методов и инструментов для изготовления продукта с номинальным качеством и оптимальными затратами. над одним обрабатываемым объектом.кального результата. это одновременно означает.6. а не наоборот. Для этого она требует от рабочих выполнять свою работу определенным стандартом способом. Т.б. Дадим определение этим понятиям. не всегда имеют материальное воплощение. До начала выполнения операции объект имеет определенное начальное состояние. ОПЕРАЦИИ И ДЕЙСТВИЯ Бизнес-процесс состоит из операций и действий. что каждый экземпляр результата м.

«урегулировать убыток автострахования». мы ограждаем себя от последующих 30 . которые именуются парой глагол плюс существительное можно идентифицировать результат и посчитать их число за определенный период времени. Действие есть акт взаимодействия оператора с обрабатываемым изделием.ваемым объектом. Хорошее имя процесса состоит из глагола. Например. а действия – к количественным. принятое в результате всей операции. 1. цель Выполнение операции приводит к качественным изменениям обрабатываемого изделия. нет действия. В этих названиях нет глагола. Эта проверка включает ряд действий. выполняемую в процессе и существительного. но их индивидуальные результаты в дальнейшем по отдельности учитываться не будут. в котором достигается определенная. например. указать. только итоговое решение. Для процессов. Неудачными следует считать названия процессов. ИМЯ БИЗНЕС-ПРОЦЕССА Каждый процесс имеет уникальное название. сколько «деятельности» было выполнено за отчетный период. «возмещение убытка». «выдать кредит физическому лицу».состоят из глагола и существительного. «маркетинговая деятельность». операция «проверить платежеспособность клиента» приводит к принятию решения. которые содержат вместо глагола отглагольное существительное. Например: «выдать кредит». указывающего на обрабатываемое изделие. Иногда в название дополнительно вводится уточнение. Правильно именуя процессы. Как следствие. заранее определенная. важного с точки зрения дальнейшего исполнения процесса. «кредитование населения». который указывает на работу. Например.7. поэтому невозможно идентифицировать отдельный результат. например. «предоставить телекоммуникационную услугу». какое количество услуг или убытков было обработано за отчетный период. «урегулировать убыток». невозможно определить. «предоставить услугу». сколько кредитов было выдано за день. позволяющее точнее специфицировать изделие.

что предприятие переходит от иерархической к матричной организационной структуре. 1. он означает управление предприятием с использованием бизнес-процессов. Эти же правила следует применять для именования операций. образующих процесс. Каждый из них имеет характерные особенности. будем выделять три уровня. Вся деятельность предприятия разделяется на отдельные бизнес-процессы.ошибок.1. этот термин означает управление собственно бизнес-процессами. сформированные по функциональноиерархическому принципу. Таким образом. указывающее на объект. которые как живые организмы. либо тип объекта. обозначающий работу и существительное. ТРИ УРОВНЯ УПРАВЛЕНИЯ БИЗНЕСПРОЦЕССАМИ Говоря об управлении бизнес-процессами.8. Первый уровень . Например: «дополнительно проверить заявку». «рассмотреть кредитную историю». Процессное управление подразумевает. подвергаемый преобразованию. которые координируют работу сотрудников из разных структурных подразделений. Каждый бизнес-процесс имеет своего владельца. осуществляемое с целью направить их действия и получить желаемые результаты. участвующими в процессе. Имя должно включать глагол. УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ Управление . 1.8.это целенаправленное информационное воздействие на людей и экономические объекты. дополнительные слова могут уточнять либо вид работы. Рассмотрим уровни управления бизнес-процессами. который отвечает за конкретный результат деятельности данного процесса и руководит всеми сотрудниками. Во-первых. бизнес-процесс пересекает границы подразделений.оперативное управление экземпляра31 . Термин «управление бизнес-процессами» имеет несколько значений. Во-вторых. требую постоянного контроля и вмешательства со стороны менеджера процесса.

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

33 . Так. во-вторых. применяют специальные технические средства управления бизнес-процессом.9. передаются между участниками (людьми и системами) в соответствии с формализованными процедурными правилами.1. в основе большинства информационных систем управления ресурсами (ERP-систем) лежит процессная модель. эта модель. что задания.1. информационную технологию. предлагающую эволюционный подход к проведению изменений. используется однократно для целей написания технического задания и быстро перестает быть актуальной. Системы ориентированные на процессы (process oriented). что существующие ERP-системы создавались для реализации процессного подхода? Хотя внедрение ERP начинается с описания бизнес-процессов.9. как правило. ТИПЫ ИНФОРМАЦИОННЫХ СИСТЕМ Организации. при проектировании которой использовалась модель бизнес-процессов. Этот термин обозначает. но можно ли говорить. как систему. К этому классу следует отнести системы управления потока работ (workflow). обеспечивающую генерацию исполняемой модели процесса непосредственно из графической модели бизнес-процесса. включающие информацию и документы. называемые системами для управления бизнес-процессами (Business Process Management Systems). ПРОЦЕССНО-ОРИЕНТИРОВАННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ Определим информационную систему. во-первых. которые хотят получить наибольшую выгоду от процессного подхода. базирующуюся на процессах (process aware). управленческую концепцию непрерывного совершенствования бизнес-процессов. 1. организуют взаимодействие участников друг c другом и с информационными системами таким образом. направленных на повышение эффективности бизнеса. Системы управления бизнес-процессами относятся к классу процессноориентрированных систем.

В процессно-ориентированных системах под моделью понимают графическое описание последовательности работ. Таким образом. Разработанная модель без изменений и с минимальным программированием преобразуется в исполняемый машинный формат. Процессно-ориентированные системы нацелены на получение синергетического эффекта от скоординированных действий организационных единиц компании. она определяет логику работы проектируемой информационной системы. Многие процессно-ориентированные информационные системы (ИС) содержат жестко запрограммированное описание процессов. выполняемых участниками. В этом случае. модификации подвергается непосредственно исходная модель.9. именно визуальная модель является «исходным текстом программы». что процессно-ориентированные системы создаются для реализации процессного подхода.2. их выполнение менее затратным. управляемой моделью. Можно говорить. чем хорошо организованная работа работников обычной квалификации. Если в дальнейшем понадобится внести изменение в логику работы системы. так что разработчик оказывается защищенным от сложностей программирования.Практика показывает. 34 . в системе. что несогласованная деятельность высококлассных специалистов менее эффективна. что их разработка ведется в терминах предметной области. 1. изменение процедурных правил взаимодействия может оказаться трудоемким. качество повышается. так как потребует перепрограммирования. а не используемой компьютерной среды. Эффект от координации взаимодействия проявляется в том. Созданием модели может заниматься бизнес-аналитик без знания программирования. СИСТЕМЫ УПРАВЛЯЕМЫЕ МОДЕЛЬЮ Отличительная особенность системы управляемой моделью (model driven) заключается в том. что процедуры становятся короче.

процессное управление сводится к их идентификации.1. Современная технология управления бизнес-процессами на базе BPM– это совокупность управленческих методологий и информационных технологий. СИСТЕМЫ УПРАВЛЕНИЯ БИЗНЕСПРОЦЕССАМИ Системы управления бизнес-процессами (BPMS – Business Process Management System) являются одновременно процессно-ориентированными и управляемыми моделью. позволяют контролировать выполнение заданий. созданной с использованием стандартной для отрасли нотации моделирования бизнеспроцессов BPMN. как по времени. стандартизации. Логика работы таких систем полностью основывается на исполняемой визуальной модели бизнес-процесса. чтобы организовать эффективное взаимодействие всех участников процесса. программирование требуется для описания нестандартных ситуаций. возникающих в ходе исполнения процесса. заменяется на постоянную целенаправленную деятельность по контролю и управлению бизнес-процессами. Под управленческой методологией мы будем понимать управление предприятием с помощью бизнес-процессов. изменение логики работы осуществляется через модель процесса. Обычно. от35 . В нашем случае реинжиниринг. генерируется исполняемая на компьютере модель. Суть технологии заключается в том. что непосредственно из модели бизнес-процесса. который изначально ориентирован на однократное радикальное преобразование бизнес-процессов компании. которая позволяет выполнять операции бизнеспроцесса по всей цепочке в автоматизированном режиме.10. реинжинирингу и регламентации бизнес-процессов компании. так и по качеству в соответствии с заранее определенными критериями. При этом вся деятельность предприятия рассматривается как совокупность взаимодействующих бизнес-процессов. помогают менеджеру процесса преодолеть результаты отклонений. Они предназначены.

При необходимости внести изменения в порядок исполнения бизнес-процесса. соответствующие коррекции проводятся аналитиком непосредственно в модели процесса. Среда BPMS позволяет собрать полную статистику периода выполнения бизнес-процесса. Далее мы рассмотрим: • основные. Основной процесс направлен на достижение главной цели компании.11. предлагать решения по их устранению. а так же измерить реальные значения ключевых показателей эффективности. интуитивно понятная пользователю модель бизнес-процесса.1. имеющих реальную ценность для ее внешнего окружения. в первую очередь. Таким образом. Вследствие разделения труда участников операционной 36 . Поэтому улучшение существующей модели процесса осуществляется на основании полных. центр тяжести в разработке перемещается с программиста на бизнес-аналитика. что за основу берется графическая. на создание продуктов или предоставление услуг. • вспомогательные • обеспечивающие процессы • сквозные процессы • внутри. достоверных и актуальных данных.и межорганизационные процессы • автоматизированные и автоматические процессы 1. 1. Благодаря тому. бизнес-аналитик получает средство разрабатывать средства автоматизации бизнес-процессов с минимальным привлечением программистов. КЛАССИФИКАЦИЯ БИЗНЕСПРОЦЕССОВ Процессы компании можно систематизировать по различным классифицирующим признакам.слеживать отклонения.11. ВСПОМОГАТЕЛЬНЫЕ И ОБЕСПЕЧИВАЮЩИЕ Деятельность любой организации направлена. ОСНОВНЫЕ.

Производственный отдел исполняет заказ. СКВОЗНЫЕ ПРОЦЕССЫ Сквозные бизнес-процессы. хотелось бы выделить повторно используемые компоненты. Наконец. Он разметил заказ в клиентском отделе. Обеспечивающие процессы не создают добавленной стоимости продукта. где реализовано процессное управление. направленных на координацию функционирования и развитие организационной системы в интересах достижения стоящих перед ней целей. Можно назвать несколько причин разделения сквозного процесса на подпроцессы. но на практике они оказываются фрагментированными. В организации. возрастает потребность в координации их действий. распадаются на сеть взаимодействующих подпроцессов. заказ проходит различные внутренние подразделения. Во-первых. пересекая границы многих функциональных подразделений.совокупность отдельных видов деятельности. модель процесса. что упростит разработку и сопровождение процессной системы. Организационная и управленческая деятельность служит задачам управления операционной подсистемой и ее координации. Экспедицию отвечает за доставку. а вся внутренняя кухня исполнения заказа скрыта от него в «черном ящике».2. предлагаемого предприятием. которая не 37 . Бухгалтерия фиксирует оплату. Они снабжают ресурсами всю деятельность организации и обеспечивают работу основных процессов. Экономическая служба определяет его стоимость. Во-вторых. 1.11. опять клиентский отдел. Сквозные процессы кажутся нам монолитными.деятельности. клиент обратился в организацию за товаром или услугой. нанимать персонал. Наконец. необходимые для основной деятельности. Далее. заказчик видит только клиентский отдел. осуществлять хозяйственные операции. который подписывает с заказчиком документ об успешности предоставления товара или услуги. Вспомогательные процессы . пронизывают всю организацию насквозь. организация должна закупать изделия и товары. Например.

Т. что исполнитель заранее неизвестен. Рассмотрим три критерия классификации степени структурированности процесса: 1) Выбор следующего исполнителя.11. в юридической деятельности выбор варианта продолжения возможен только после завершения текущего судебного разбирательства.3. при стоимости продукта до 1000 рублей проверяет экономист. а если его цена выше. Но бывают ситуации. какой либо документ. Например.б. 1. ожидать его поступления и лишь затем организовывать доставку. Например. причем существует несколько вариантов продолжения.умещается на стандартном листе. поэтому осуществляется экспертом предметной области.о. то нужно заказать товар. выбор между которыми неоднозначен и не м. формализован. например. поэтому аналитики группируют операции в подроцессы. кажется не понятной и сложной. если для каждого конкретного случая следующий исполнитель назначается на основании неформализованного выбора. а если его нет. СТРУКТУРИРОВАННЫЕ ПРОЦЕССЫ По степени формализации процессы делятся на хорошо и плохо структурированные. Напротив. Например. можно переходить к организации доставки. выбор исполнителя четко формализован. при продаже изделия после приемки заказа идет проверка наличия продукта на складе. движение которого вдоль процесса определяет ход его исполнения. 3) Выбор объекта управления. Обычно выбор следующей операции формализован. Обычно с каждым процессом связан объект управления. 2) Выбор следующей операции. в данном случае адвокатом. если товар есть на складе. то можно говорить. В формализованном процессе следующий участник может быть известен заранее или его выбор формализован. выдача кредита начинается с заполнения документа 38 . В формализованном процессе следующий следующая операция известна заранее. когда следующее действие можно определить только после завершения предыдущего. Например. то старший экономист с более высокими полномочиями.

В другой крайней ситуации. Таблица 1-1. где следующий участник и его действие заранее известны. разбит по полям.под названием заявка. Использование систем BPMS для слабо и плохо формализованных процессов возможно. Формализованные документы удобны для машинной обработки. Но бывают неформализованные документы. где та же заявка может быть описана в простой письменной форме без шаблона и специальных правил. поэтому понять. на заявке ставят свою визу участники. в большей степени подходят средства коллективной работы. когда участник и его действие неизвестно. например письма. в наибольшей степени подходят средства BPMS. ее движение между участниками определяет ход рассмотрения. а документ не формализован. Таблица 1-1 рекомендует выбор средства автоматизации в зависимости от сочетания описанных критериев. Классификация процессов по степени формализации Критерий Следующий участник Следующая операция Объект управления Инструмент Хорошо Известен Степень формализации процесса Слабо Плохо Не формализован Неизвестен Известен Неизвестен Известен Известен Неизвестен Неизвестен Формализован Формализован BPMS Case Management Не формализован DocFlow Не формализован Collaboration 39 . а документ формализован. каждое из них имеет уникальное имя идентификатор. где в заявке заказчик. а где адрес доставки машина не может. Информационный объект заявка формализован. Для хорошо формализованных процессов. позволяет хранить данные определенного вида. однако в этом случае они не в полной мере раскроют свой потенциал и возможности.

входящих в документы. которые «понятны» всем участникам обмена и могут «электронно» стыковаться с корпоративными системами каждого из участников. Реализация процессов межорганизационного взаимодействия происходит. Это может быть взаимодействие компании со своим клиентом или партнером по кооперации. 40 . ВНУТРИ И МЕЖОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ Внутриорганизационные процессы описывают взаимодействие. Консорциум RosettaNet. а затем переходить к стандартизации их взаимодействия. хореографии и диалогов. Словари RosettaNet устанавливают единую терминологию для определения бизнес транзакций между торговыми партнерами. На первом этапе организации «договариваются» о формате документов. обычно. Для решения второй задачи организации стандартизуют последовательности действий по обмену электронными документами. ведь вначале надо стандартизировать выполнение работ внутри каждого из предприятий. Такие процессы обладают повышенной сложностью.4.11. Они делятся на основные. вспомогательные и управления. товаров и услуг. решают данную задачу.4. Например. Для решения первой задачи организации устанавливают единую терминологию для определения бизнес понятий.11. осуществляемое в пределах одной организации. МЕЖОРГАНИЗАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ Межорганизационные процессы отвечают за взаимодействие нескольких предприятий.1. объединяющий более 500 ведущих ИТ компаний создал одноименный индустриальный стандарт для В2В коммуникаций. в два этапа. 1. используемых при обмене. На базе общих словарей строятся электронные документы. Диаграммы взаимодействия. пересылаемые между торговыми партнерами. связанных задачами общего бизнеса. На втором этапе они договариваются о последовательности операций по пересылке этих документов.1. рассматриваемые ниже.

При этом каждую операцию принято рассматривать как сервис. любой процесс связан с некоторым документом. движение которого определяет ход исполнения процесса. Различие между процессом и документооборотом в следующем: жизненный цикл процесса шире. ее обработка участниками образует операции бизнес-процесса.12. Автоматические процессы осуществляются без его участия. 1. Автоматизированные процессы происходят с участием человека в контуре управления. Но это вносит в исполнение процесса определенный субъективизм. при выдаче кредита основным документом является заявка клиента.11.1. пользуясь личным опытом и навыками. который воспринимает ввод команд и данных от пользователя во время работы. обычно он покрывает несколько документов. процесс «от заказа до отгрузки» подразумевает ра41 . точно известны все критерии принятия решения. Например. Безусловно. Различия в следующем: работа машины возможна. когда задание полностью формализовано. В автоматизированном процессе решения менее формализованы. они основаны на двусторонней диалоговой связи между человеком исполнителем и центральным исполняющим узлом. мы вправе ожидать на выходе предполагаемый результат. подав на вход требуемые данные.5. Вторые исполняются без участия человека. чем у одного документа. Первые являются интерактивными. ПРОЦЕССЫ АВТОМАТИЗИРОВАННЫЕ И АВТОМАТИЧЕСКИЕ Бизнес-процессы можно различать по степени вовлечения человека в производственную деятельность. интересами или вкусами. Предполагается. что человек может принять решение. всю работу выполняет машина. как результат возникает вариативность исполнения процесса. ПРОЦЕСС И ДОКУМЕНТООБОРОТ Часто бизнес-процесс смешивают с движением документа. человек часто выполняет работу в соответствии с личными взглядами. Например.

связанные с документами.боту с несколькими документами: «заявкой». 1. возникающих в рамках работы с документом. фиксируют резолюций. ОБЪЕКТ УПРАВЛЕНИЯ ПРОЦЕССА В программировании графом потока управления принято называть множество всех возможных путей исполнения некоторой программы. а потоком управления — траекторию. которая должна показывать все возможные сценарии исполнения. которая сопровождает отгрузку товара или услуги. который является платежным документом. В рамках т. распорядительного документооборота. введем понятие объект управления бизнес-процесса. В управлении бизнес-процессами роль графа играет модель процесса. «сметой». большое внимание уделяется трансформации и переносу информации из одного документа в следующий. что каждый процесс связан с обработкой одного или нескольких документов (информационных объектов). Что бы понять поток управления. компании ведут разнообразные журналы регистрации документов. по которой в данный момент времени исполняется отдельный экземпляр. что. Дело в том. наконец «накладной». «заданием». оперативно получать агрегированную информацию о состоянии исполнения документов в компании. «счетом». содержащей пожелания клиента.н. Среди этих информационных объектов есть такой. в конечном счете. а поток управления есть траектория. являющимся инструкцией по изготовлению заказа. описывающей экономическую сущность заказа. На разных этапах исполнения процесса соответствующий документ становится объектом управления. Для контроля исполнения отдельных поручений. представленное в виде графa.13. позволяет определить текущее состояния обработки. определяя статус исполнения всего процесса. по которой исполняется соответствующая программа. который сохраняет в себе результат выполне42 . В рамках бизнес-процесса эти документы рассматриваются во взаимосвязи. все эти документы рассматриваются по отдельности.

выполнение очередной операции начинается. Назовем информационный объект. В аналитическом моделировании роль маркера играет некоторый документ.ч. Жизненный цикл объекта управления м. МАРКЕР ПОТОКА УПРАВЛЕНИЯ ПРОЦЕССА В теории бизнес-процессов для объяснения потока управления принято использовать понятие маркер процесса. Вспомогательными будем называть остальные информационные объекты. которые фиксируют изменения данных бизнес-процесса. но результаты рассмотрения отмечаются в заявке на получение кредита.ния текущей операции. поскольку траектория движения последнего определяет порядок исполнения процесса. 1. он используется. Выполнение операций процесса приводит к последовательному изменению состояний объекта. «заявка». не раскрывается. В каждый момент времени в BPMS системе рассматривается только один объект управления. в кредитном процессе к заявлению прилагаются различные справки. например.б. который определяется как «теоретическое понятие». делает ее активной и подготавливает ее к исполнению. Мы будем ассоциировать маркер потока управления процесса с объектом управления процесса. Прибытие объекта управления в соответствующую операцию. ее движение вдоль процесса образует поток управления. после поступления 43 . короче.1.13. т. В программировании сходную функцию исполняет переменная состояния. последние являются информационными объектами. Движение объекта управления по траектории процесса определяет порядок исполнения операций процесса.объектом управления. Траектория движения объекта управления образует поток управления процесса. Какая сущность скрывается за этим понятием. в этом случае мы наблюдаем смену объекта управления. Например. чем весь процесс. что бы отобразить ход исполнения бизнес-процесса. связывающий входы и выходы процесса или подпроцесса . но не результат выполнения операции. этапа исполнения или всего процесса целиком и тем самым связывает соответствующие входы и выходы.

3. Возникновение параллельных потоков управления обычно связанно со сменой объекта управления. данном примере им является запрос. например. их синхронизацией. т.13. При моделировании исполняемых процессов объект управления может быть шире. Основной процесс делится на параллельные потоки. 1.«заявки». по схеме будут двигаться несколько маркеров. Если все экземпляры работают с одним общим набором данных. МНОГОПОТОЧНЫЕ ОПЕРАЦИИ Процесс может включать многопоточные операции. ПАРАЛЛЕЛЬНЫЕ ПОТОКИ УПРАВЛЕНИЯ ПРОЦЕССА Один поток управления может вначале разделяться на несколько ветвей. статус обработки. столько раз. в каждом из них есть свой объект управления.б. которые на этапе выполнения порождают много экземпляров исполнения одной задачи. выполнена многократно. при проектировании схем процессов надо следить за ветвлением и слиянием параллельных потоков. Следовательно.2. с целью проверить наличие соответствующего продукта. Т. порожденных из одного объекта управления. включая служебные поля.ч. которого в исходном бумажном документе нет. Мы подробно рассмотрим эту ситуацию в разделе 10 «Процессные паттерны».13. Различают последовательное и параллельное исполнение. при этом образуются параллельные потоки управления процесса. то исполне44 . На практике такая ситуация может привести к коллизии. чем обычный документ. При этом не регламентируется обязательная синхронизация всех потоков при их слиянии. 1. содержащий номенклатуру требуемых деталей. причем их количество может быть не известно в момент моделирования. Например.о. операция «Отправить приглашение гостям» д. по каждому изделию из списка мы посылаем отдельный запрос на склад. Например. сколько гостей в списке приглашенных. заказчик разместил заказ. один поток на узле ветвления может породить несколько потоков на узле слияния.

С точки зрения выполнения. Если поставить целью понимание того. являющийся упрощённой версией моделируемого прототипа. надо следить за разделением процесса на потоки и их дальнейшей синхронизацией. В этом случае. Соответственно. Если каждый экземпляр использует индивидуальный набор данных.использовать модель как программу. Так же как в предыдущем случае. одновременным. внесенные на предыдущем шаге. При этом не регламентируется обязательная синхронизация потоков операции. каждая следующая итерация перезаписывает данные.к. существенные для целей конкретного моделирования. поскольку это может привести к различным коллизиям при выполнении всего процесса. МОДЕЛЬ БИЗНЕС-ПРОЦЕССА Моделью принято называть некоторый материальный или мысленно представляемый объект или явление. Модель в достаточной степени повторяет одни свойства. т. Например. в котором он был создан. 45 .ние. т. несущественные свойства.б. как исполняется процесс. порожденных одной операцией. и опускает другие. Если же цель . в каждом экземпляре процесса одновременно может выполняться некоторое число экземпляров потоков. определяющую регламент взаимодействия пользователей. при рассылке приглашений. 1. обычно. основной поток управления разделяется на несколько параллельных нитей. полной и исполняемой. последовательное. Набор свойств модели бизнес-процесса определяется целями моделирования. Это означает. то для этого достаточно ограничиться описанием укрупненных операций. наборы данных разных экземпляров не зависят друг от друга. то исполнение м. могут исполняться параллельно и одновременно друг с другом. что каждый поток при слиянии может породить отдельные маркеры потока управления.14. в которых модель может отличаться от прототипа. каждый поток является дочерним экземпляром основного процесса. то она должна быть точной.ч.

что бы спланировать работу? Для этого следует создать список работ. синтезировать исходный объект. Функциональная декомпозиция позволяет получить перечень всех тех действий. что бы добиться запланированного результата. В проектном менеджменте список работ получил название структурированная декомпозиция работ (WBS). Вместе с тем. Разработано множество техник составления такого списка. 1. составить расписание исполнения указанных работ. которые необходимо выполнить. она помогает понять распределение работ между подразделениями. но таким образом. что процесс описывает работу. 2. Декомпозиция. Декомпозиция в соответствии с известными стабильными подсистемами приводит к созданию иерархии. В результате получается функциональная модель. Что следует делать. СПОСОБЫ ДЕКОМПОЗИЦИИ ПРОЦЕССА Методология структурного анализа и проектирования (SADT) предполагает рассматривать сложный объект как иерархическую многоуровневую модульную систему. а затем. а какие экономический отдел. что бы из компонентов можно было восстановить. привязанной к существующей структуре организации. что бы получить запланированный продукт или услугу. основанная на отслеживании жизненного 46 . которую необходимо выполнить. Авторы SADT рассматривают четыре способа декомпозиции системы. Концепция декомпозиции предполагает разделять исходный объект на составляющие.14. например. система рассматривается как фиксированное упорядоченное множество объектов и отношений между ними. Как следствие.1. ПРОЦЕСС ОПИСЫВАЕТ РАБОТУ Из приведенного выше определения можно понять.14. 3.1. 1.2. которые необходимо выполнить. модель окажется неприменима к организации с иной структурой. Таким образом. обычно используется декомпозиция работ. какие работы выполняет бухгалтерия. Однако никто не задумывается о влиянии выбора стратегии декомпозиции на результат. которая не привязана к конкретной организационной структуре предприятия.

она отвечает на вопрос: «как выполнять работу?». то результирующую модель можно назвать процессной. 4. Последнее верно лишь в случае использования функциональной декомпозиции.15. 1.цикла какого-либо объекта. Авторы SADT рекомендуют функциональную декомпозицию. Декомпозиция по физическому процессу показывает последовательность действий.3. используют только функциональную декомпозицию. с помощью диаграммы IDEF0 можно описывать процесс. Она располагает операции и действия во временном порядке их выполнения. которые необходимо выполнить. Интересно. позволяет увидеть очередность основных этапов процесса. Но последователи. Если же применялась декомпозиция по процессу. результат можно классифицировать как функциональную модель. ФУНКЦИОНАЛЬНЫЕ И ПРОЦЕССНЫЕ МОДЕЛИ Итак. 1. Она включает расписание исполнения указанных работ. что за моделями IDEF0 прочно закрепилось название функциональная диаграмма. Однако реальные процессы имеют более сложные сценарии исполнения.14. Но если использовать декомпозицию по этапам жизненного цикла. она отвечает на вопрос: «что делать?» и содержит перечень операций и действий. отвечает на вопрос «Как выполняется работа?» и обеспечивает получение процессной модели. забыв рекомендации. что именно способ декомпозиции определяет тип результирующей модели. мы ранее договорились называть такой список структурной декомпозицией работ. Если использовалась функциональная декомпозиция. можно предположить. направленную на получение конкретного результата. но не отвергают остальные стратегии. ИСПОЛНЯЕМАЯ МОДЕЛЬ БИЗНЕСПРОЦЕССА Системы BPM имеют дело с так называемыми исполняемыми 47 .

Функциональная . что бы достичь поставленной цели?».определяет состав выполняемых работ. процедурное описание порядка выполнения операций. Можно предположить. Она представляет собой справочник. методы координации действий участников. Функциональная модель описывает статику системы. Исполняемая модель процесса включает следующие слои. выполняют одинаковые работы. выполняемые субъектами.моделями. стратегию распределения работ между исполнителями. Поведенческая перспектива описывает динамику системы и отвечает на вопрос «Как исполняется процесс?».две компании. чем диаграмма бизнес-процесса. производственной культурой и т. Она включает: (1) аспект бизнес логики.описывает порядок исполнения операций и действий процесса. Исполняемая модель описывает динамику поведения организационной системы. но не указывает порядок их исполнения. поскольку предприятия обладают различной организационной структурой. 4. Организационная – изображает совокупность способов. 3. которое может быть использовано для автоматизации взаимодействия участников друг с другом и машинами без дополнительного кодирования и программирования. структурную декомпозиция работ. помогает ответить на вопрос «что надо делать. работающие в одной сфере бизнеса.д. 2. используемая с целью аналитического описания бизнеспроцесса. Исполняемая модель бизнес-процесса – это описание участников процесса: людей и машин. (2) временной аспект – определяющий 48 . объемнее. перечисляет все действия. а также порядка и времени выполняемых ими операций и действий. называемые перспективами: 1. Модель описывает «идеальный» взгляд на деятельность организации .определяет бизнес сущности предметной области процесса. посредством которых процесс разделяется на отдельные операции. что она существенно сложнее. однако последовательность операций может отличаться. Поведенческая . Информационная .

она потеряет 49 . Информационная перспектива определяет связи между документами и элементами данных. включающая методы. а все вместе они образуют полное представление храктеризующее динамику его исполнения. каждая из которых описывает отдельные аспекты его структуры. Как отобрать кандидатов на выполнение каждой операции? 2. накладываемых на выполнение процесса. (3) аспект бизнес-правил . должны быть взаимоувязаны и хорошо интегрированы между собой. В противном случае. образующие интегрированную модель. Организационная перспектива модели бизнес-процесса описывает динамику распределения работ между сотрудниками в отличие от организационной структуры компании.хронологию событий. время. модель станет сложно сопровождать. но показывает связи между отдельными элементами. Кого из кандидатов следует назначить исполнителем? 3. Разные структурированные документы могут содержать общую информацию. введенные в один документ. становятся доступны в других документах. которая описывает статику распределения сотрудников по структурным подразделениям. Это означает. Частные перспективы. так что данные. Организационная перспектива должна дать ответы на вопросы: 1. что информационная модель должна описывать связи между документами по данным. хранимые в виде образа.декларативное описание ограничений. их длительность. когда стартуют операции. Документы процесса делятся на структурированные и неструктурированные. Для описания информационной перспективы используется иерархическая объектная модель данных. потребуется дополнительное кодирование и программирование. Эта модель не описывает способы хранения информации. которые определяют способы работы с соответствующими бизнес объектами. Каковы привилегии исполнителя. назначенного на исполнение задачи? Интегрированная модель бизнес-процесса суть взаимоувязанная совокупность перечисленных частных моделей.

вернуться к предыдущему варианту. 1. внесенные в схему процесса. определять. ВЕРСИЯ МОДЕЛИ ПРОЦЕССА В ходе постоянных улучшений бизнес-процесса принято фиксировать версии исполняемых моделей. Первая является инструментом разработчика. при необходимости возвращаться к более ранним версиям. вторая – инструментом администратора системы. для каждого шаблона процесса одновременно может исполняться неограниченное число экземпляров процессов (ЭП). Версионировние исполняемых экземпляров процесса осуществляется с помощью централизованной системы управления версиями – специализированного программного обеспечения для облегчения коллективной работы с изменяющейся информацией. в случае неудачных изменений в модели. отслеживающим изменения. Это позволяет.1.17. 1. каждый из которых находится на определенной стадии обработки. Система управления версиями позволяет хранить несколько версий одной и той же модели.16.свойство гибкости и адаптивности. 1. ВЕРСИЯ ПРОЦЕССА В результате изменений шаблона процесса появляются версии модели. 1. В системе могут одновременно существовать много экземпляров процессов. который контролирует экземпляры процесса. кто и когда сделал то или иное изменение.2. исполняемые по данной версии схемы процесса.17. ЭКЗЕМПЛЯР ПРОЦЕССА Как известно. Договоримся различать версионность на уровне схемы процесса и на уровне исполняемой модели процесса. Под экземпляром мы будем понимать частный случай исполнения шаблона процесса.17. ВЕРСИОНИРОВНИЕ ЭКЗЕМПЛЯРОВ ПРОЦЕССА Версионность исполняемой модели процесса означает возможность одновременного исполнения в одной ИТ системе 50 .

. включая миграцию процесса со «старого» шаблона на «новый». что версии шаблона могут быть совместимыми.18. соответствующих разным версиям его шаблона.индустриальный стандарт. Рассмотрим некоторые из них: BPEL Язык исполнения бизнес-процессов (Business Process Execution Language. существовавшими на момент их запуска. большинство языков и нотаций не позволяют описывать одновременно внутри. 1. • Первая версия стандарта. опубликованная в 2002. но.0. Т. опубликована в 2007 г. BPEL) . описания выполняемых ориентированных на интеграцию моделей процессов. к сожалению. СТАНДАРТЫ ОПИСАНИЯ БИЗНЕСПРОЦЕССОВ Существует много способов описания бизнес-процессов. стартовавшие ранее. Нотация не поддерживает визуальное моделирование бизнес-процессов. являлась совместной разработкой IBM. стратегическое управление не ограничивается заменой одного шаблона на другой.организационные процессы. но охватывает еще управление версиями процесса. мы планируем ввести в производство исполнение процесса по новым правилам. SAP. • Текущая версия BPEL 2.сразу нескольких экземпляров одного процесса. BPEL4WS. 51 . когда перевод процесса возможен только при определенных условиях. Siebel и Microsoft . допуская простой перевод ранее запущенного на исполнение процесса на новую схему. могут быть закончены в соответствии со старыми правилами. Например. Может возникнуть и обратная задача: перевести ранее запущенные процессы на вновь вводимый в эксплуатацию шаблон. для этих целей используются различные языки и нотации. BEA. и несовместимыми.и меж. Оригинальное название спецификации Business Process Execution Language for Web Services. Выполнение бизнес-функций осуществляется путем вызова соответствующих веб-служб.о. Однако процессы. При этом разработчик должен помнить.

модель м. www. в основном. Используется в большинстве систем BPMS в качестве основного средства для графического моделирования. проектирования и документирования. • Права принадлежат рабочей группе (консорциуму) OMG (Object Management Group. ориентированных на интерактивное взаимодействие с участниками. BPMN Графическая нотация и модель бизнес-процессов (Business Process Modeling Notation)— индустриальный стандарт визуального описания исполняемых моделей процессов. www.oasisopen. UML был создан для определения. но на основании UML-моделей возможна генерация программного кода. интерпретирована в исполняемый программный код. программных систем.0 опубликована в 2005 г. занимающемуся разработкой и продвижением объектно-ориентированных технологий и стандартов. www. использующий графические обозначения для создания абстрактной модели системы. имеет техническую реализацию.softwareag.org). 52 . UML не является языком программирования. EPC Ориентированная на событие цепочка процессов (Event-driven Process Chains. EPC) — проприета́рная нотация описания бизнес-процессов.ч. визуализации. UML Унифицированный язык моделирования (Unified Modeling Language) — язык графического описания для объектного моделирования в области разработки программного обеспечения. • Текущая версия BPMN 2. Это открытый стандарт. т.org).0 опубликована в 2011 г. Широко используется для документирования рабочих процессов.omg. • Формальная спецификация последней версии UML 2. • Правообладателем является Software AG (www.• Поддерживается организацией OASIS (Organization for the Advancement of Structured Information Standards.org). UML является языком широкого профиля.б.com).omg. • Права принадлежат рабочей группе (консорциуму) OMG (Object Management Group.

• Последняя версия 1. Служит для описания интерфейсов веб-служб.0 опубликована в 2007 г.2 опубликована в 2012. Предметом дальнейшего рассмотрения станет нотация BPMN 2. Это стандарт описания данных.• Последняя версия UML 2. • UML 1. используемым для хранения.w3. www. • Права принадлежат всемирному интернет консорциуму W3C (World Wide Web Consortium. XSD Язык описания структуры XML-документа (XML Schema Definition). • Текущая версия XPDL 2. XPDL Формат описания процесса на основе XML (XML Process Definition Language). www. а также их производных элементов. • Права принадлежат коалиции WfMC (Workflow Management Coalition. их атрибутов. исполнения и переноса моделей бизнес-процесса между различными BPMS средствами.2 принят в качестве международного стандарта ISO/IEC 1950 WSDL Язык описания веб-служб и доступа к ним. Такая система состоит из спецификации новых элементов XML.wfmc.1 опубликована в 2011 г. • Последняя официальная версия 2. • Спецификация XML Schema является рекомендацией всемирного интернет консорциума W3C. используется для моделирования доступных операций.org) .0 была одобрена в качестве рекомендации в 2001 г.4.4. Является техническим стандартом. включая адреса их вызова.org/Consortium). которыми пользуются и обмениваются бизнес-процессы и веб-службы. основанный на языке XML (Web Services Description Language). 53 .0.

в его крайнем проявлении как веб-сервис. его независимость от конкретного производителя и поддержка лидеров компьютерной индустрии обеспечивают BPMN широкое распространение. при выстав54 . однако высокий статус организации разработчика. которые содержат всю необходимую информацию о том. СПЕЦИФИКАЦИЯ BPMN 2. в которых не участвуют люди. вовлеченных в описание и автоматизацию бизнес-процессов: начиная с аналитиков и разработчиков и заканчивая экспертами предметной области. Статус индустриального стандарта означает. а весь процесс. Нотация BPMN одновременно конкурирует и взаимно дополняет язык описания бизнес-процессов WS-BPEL. которая реализована в большинстве продуктов для моделирования и управления бизнес-процессами. как последовательность вызовов сервисов (веб-сервисов). что она носит рекомендательный. как выполняется процесс.0 является одновременно средством графического визуального моделирования бизнес-процессов и языком создания исполняемой модели бизнес-процесса. присутствующими на рынке. Например. как сервис. Такой способ описания удобен для реализации хорошо формализованных процессов. Первоначально два стандарта предназначались для решения одной задачи описать работу участников процесса. а не обязательный характер. Он рассматривает операцию. Нотация BPMN относится к классу индустриальных стандартов Она разработана общественной организацией Object Management Group и утверждена общим решением лидеров ИТ рынка. Язык WS-BPEL так же имеет статус индустриального стандарта.0 Нотация BPMN 2.2. выполняемую сотрудником. что она ориентирована на широкий круг специалистов. В настоящее время актуальной является вторая версия стандарта. Нотация позволяет создавать диаграммы процессов на различных уровнях абстракции: от концептуальных моделей взаимодействия участников процессов (в том числе контрагентов) до технических схем. Основным преимуществом данной нотации является то.

1. интерактивное взаимодействие с участниками не требуется. в частности модель. При этом нотация определяла только внешний вид графических элементов. которые указаны на схеме процесса. В 2004 разработка спецификации перешла к организации Object Management Group. что спецификация охватывает как графическую нотацию. Семантика нотации BPMN очень важна. которая должна подсчитать общую стоимость звонков. Это название подчеркивает. может быть преобразована для последующего исполнения в формат языка WS-BPEL. а в феврале 2006 года OMG опубликовала эту спецификацию 55 . Но. поскольку именно она определяет то. 2. В последнее время наметилась тенденция интеграции обеих спецификаций. ИСТОРИЯ РАЗВИТИЯ НОТАЦИИ BPMN Развитием нотации BPMN (Business Process Model and Notation) в 2001-2004 годах занималась организация Business Process Management Initiative (BPMI). если в ходе процесса необходимо решение человека.лении счета клиенту телекоммуникационной компанией необходимо наладить взаимодействие между коммутатором. созданная в нотации BPMN. который хранит реальную длительность разговоров клиента и биллинговой системой. Такое преобразование стало частью спецификации BPMN 2. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов). Взаимодействие двух систем происходит с использованием веб-сервисов. но не определяла семантику их исполнения. как будут исполняться в реальности те графические элементы. поэтому этот процесс может быть легко описан на WS-BPEL. о которой пойдет речь далее.Business Process Model and Notation означает: нотация и модель бизнес-процессов. Позднее расшифровка изменилась .0 подготовленной OMG. так и исполняемую модель. Первоначально аббревиатура расшифровалась как Business Process Management Notation. такой способ описания становится менее удобен для моделирования.

из которы ых состо оит бизн нес-про оцесс. C2C. что онаа описы ывает гр рафичесское преедставление и модельь процессса. т в ис-полнен нии котторых участвую у ют неск колько контраагентов. Истор рия разви ития нотаации BPM MN Ри Сп пецифи икация BPMN 2..0 разр решает модели ироватьь как би изнес-пр роцессы ы. что о позвол ляет пе-реноси ить диагграммы ы между у разли ичными и средсттвами моделим ровани ия.0 описыва о ает сем мантику у выпол лнения я графич ческих элементтов. Вм месте с тем. Таким м образом. спе-цифик кация опираетсся на формали ф изованн ное опи исание графи-ческих элемен нтов и отношен о ний меж жду ним ми. он на опрееделяетт набор р графи ических х элемеентов и правил л их пр рименен ния для я модел лирован ния посследоваттельно-сти раб бот.0. Начиная со второй в в версии.уже как к свою собствен с нную. подд держиввающим ми нота ацию BPMN B 2.0 состоит из и трех компон нентов. C B2C C и т. Нотация Н я BPMN 2. YAWL Y и др. ко оторая являетсся стан ндартом м де-фак кто для органи изаций. так и те. что о позвол ляет ген нериро овать в автомаа тическом реж жиме пр рограмм мный код к на языках х испол лнения я бизнес-процесссов.. тааких как WS-B BPEL. которы ые зани имаются я модел лирова-нием и создаанием исполн няемых моделеей бизн нес-про оцессов. без потери и какой-л либо см мыслово ой и граафическ кой инф формац ции. кото-рые вы ыполняю ются в рамках р одной органи изации. исунок 2--1. В 2011 го оду OMG G выпу устила последн п нюю на сегодн няшний й день сп пецифи икацию ю BPMN N 2. В Во-вторы ых. . неправи н ильно сводить исполн нение бизнесб 56 6 .д. специф фикация BPM MN 2. специф фикаци ия BPM MN расш шифро-вывается как: Businesss Proceess Mod deling and a Nottation. В-тр ретьих. нотаация по озволяетт описы ывать вссе категгории процесп сов элеектронн ной коммерции и: B2B.0. Во-первых. подчерп кивая.

2. Интеграция осуществляется на уровне метамодели BPMN. • Потоков данных между операциями процесса. • Бизнес стратегию компании Поскольку интегрированная модель бизнес-процесса включает не только поведенческую перспективу. Он предложен и развивается Workflow Management Coalition. 57 . Нотация BPMN не позволяет моделировать другие аспекты модели бизнес-процесса. 2. • Организационную структуру предприятия. но также другие аспекты. ОБЛАСТЬ ПРИМЕНЕНИЯ НОТАЦИИ BPMN Нотация BPMN предназначена для описания: • Порядка исполнения работ образующих бизнес-процесс. По-прежнему декларируется возможность преобразования модели в исполняемый формат XPDL (XML Process Definition Language). • Модель данных. спецификация BPMN уделяет повышенное внимание вопросам интеграции моделей. • Потоков сообщений между процессами. например: • Функциональную (структурную) декомпозицию работ. что позволяет участникам быстрее понять логику исполнения. • Ассоциации обрабатываемых объектов данных с операциями процесса. описываемые перечисленными моделями. Моделирование осуществляется с помощью визуальных диаграмм.процесса исключительно к преобразованию в формат языка WS-BEPL. в настоящее время текущей версией является XPDL 2.2. • Бизнес правила. Язык XPDL предназначенный для описания определений и реализаций рабочих процессов и используется для переноса исполняемой модели бизнес-процессов между разными средами BPMS.

2. п. п. 3.3).1. Данные.0 можно выделить пять основных категорий графических элементов. которые используются для создания схем оркестровки бизнес-процессов (см. в результате которой изменяется состояние объекта управления. 5) и события (см. Элементы управления Соединительные элементы Операция Поток управления Хранилище данных Ненаправленная ассоциация Сообщение Зоны ответственности Артефакты Группа Объект данных Направленная ассоциация Событие Логический оператор Данные Аннотация Ссылка Пул Дорожка Дорожка Рисунок 2-2. логические операторы (см. Соединительные элементы. Операция обозначает единицу работы. «Вынести решение» и т. Артефакты. Рисунок 2-2): 1. Зоны ответственности. ОБЗОР ОСНОВНЫХ ЭЛЕМЕНТОВ НОТАЦИИ В нотации BPMN 2.2.3. 3). ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Элементы управления включают: операции (см. Элементы управления. 5.д. 6. например.3. п. 58 . «Согласовать заявку». Основные графические элементы в нотации BPMN 2. 4.

что бы ограничить длительность операций. продолжить исполнение. Например. Если один процесс иницииру59 .5. после завершения предыдущей. они описывают реакцию на изменение состояния внешних. начать выполнение очередной операции через 1 час. ассоциации. Во-первых. когда выполняется работа. что модель. 6. Они включают: потоки управления (см. В-третьих. 3. прервать исполнение операции через 30 минут после начала. Потоки управления связывают отдельные операции. Например. Событие используется для нескольких целей. изображает факт пересылки информации. п.2.1) позволяют отобразить обмен информационными посылками между участниками процесса. они не изображают последовательность выполнения работ. Сообщения помогают описать структуру информационного обмена между процессами.1). п. Направленные ассоциации служат для указания направления передачи объектов данных и для указания операции.2. если величина запрошенного кредита превышает 1000 рублей. что бы указать моменты времени. Во-вторых. логические операторы и события в логическую цепочку и устанавливают порядок их выполнения. 2. 4). после получения сигнала.5.Логический оператор изображают работу. СОЕДИНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ Соединительные элементы предназначены для связывания остальных элементов нотации. Потоки сообщений (см. 6. Например. которая не изменяет объект. п. потоки сообщений (см. то его согласует старший менеджер. Например. п. но не позволяет отобразить структуру информационного сообщения. но маршрутизирует его в соответствии с некоторым правилом. Ненаправленные ассоциации используется для соединения артефактов с элементами управления и потоками управления. Следует обратить внимание.6).3. по отношению к процессу объектов. которая выполнит компенсацию в случае отката транзакции (см.

Сообщения изображают на схеме процесса информационные посылки. Так или иначе. Поток управления не может пересекать его границу. пул. но не может соединять операции внутри одного пула. 8). логические операторы. который не показывает деталей процесса. но предполагается. что информационная структура объектов отображается. пул всегда явно или неявно присутствует на диаграмме. хранилища данных (см.3. Первона60 . Однако следует учитывать. то необходимо изобразить. Напротив. Объекты данных позволяют описать внутреннюю структуру информационных объектов. Пул это «контейнер». Они включают: объекты данных (см. Хранилища данных изображают внешние по отношению к процессу системы хранения. 8. который очерчивает границы процесса. п.5). какая информация передается от вызывающего процесса в вызываемый. п. например. 2. ЭЛЕМЕНТЫ ДАННЫХ Элементы данных используются для изображения информационных потоков на диаграмме процесса.ет исполнение другого процесса. поток сообщений может изображаться между пулами. 2.4. его называют «белый» ящик. СУБД. Пул разделен на дорожки.3. В некоторых случаях пул не рисуется. которыми обмениваются между собой процессы. служащие для логической группировки операций процесса. Дорожки имеют имя.1. называют «черный» ящик. сообщения. Название пула может указывать владельца процесса. которые служат для группировки операций диаграммы. события и потоки управления. Напротив. но не моделируется. Если пул показывает детали процесса: операции. ЗОНЫ ОТВЕТСТВЕННОСТИ Зоны ответственности – пулы и дорожки есть графические элементы. которые подвергаются обработке в ходе исполнения операций.3.

СУБКЛАССЫ НОТАЦИИ BPMN Если сравнить нотацию BPMN 2. Что бы упростить работу бизнес-аналитиков предлагается разделить все множество элементов на несколько групп (см. чтобы визуализировать исполнителя задания. дорожки чаще используются для аналитического моделирования.о. что делает работу с нотацией достаточно сложной и кропотливой.4.2. Группы – это способ логически объединить на схеме несколько операций процесса. например.чально дорожки предназначались. 61 . для аннотирования отдельных операций на схеме. артефакты никак не влияют на выполнение процесса. выбранную аналитиком. т. так что имя дорожки указывало на роль участника.5. чтобы скрыть излишние детали процесса. на схеме они изображаются. для которых спецификация BPMN не определяет семантики исполнения. Аннотации есть способ добавить на схему необходимые комментарии. 2. Один процесс может включать несколько иерархий дорожек. ассоциации и аннотации. Ассоциация логически связывает комментарий и некоторую операцию. АРТЕФАКТЫ Артефакты . Однако в настоящее время ролевая модель доступа используется редко. Группы могут пересекать несколько дорожек и даже пулов.это графические элементы. что число графических элементов нотации увеличилось с 55 до 116. именование дорожек не оказывает влияния на выбор исполнителя. Дорожки могут быть иерархически вложенными.0 с предыдущей версией BPMN1. они используются для комментирования процесса.ч. 2. Т. можно обнаружить. Чаще всего группирование операций используется для того.3. В целом. отражая иерархию группировок операций. Рисунок 2-3). Поток управления может пересекать границы дорожек. а при исполнении не учитываются. К этой категории элементов относятся группы (операций).

следует внимательно изучить справочное руководство соответ62 . полный набор (+50) позволяет создавать любые типы диаграмм. Субклассы нотации BPMN • Основной набор включает 7 элементов.Рисунок 2-3. • Подмножество описательных элементов (+17) достаточно для построения исполняемой модели. • Подмножество аналитических элементов (+29) • Наконец. В случае возникновения вопросов. а только какое-то подмножество. Следует отметить. При этом вендоры не придерживаются описанных субклассов. а руководствуются своими индивидуальными пристрастиями. что существующие сегодня системы BPMS поддерживают не все 100% элементов нотации. достаточен для разработки концептуальной (не исполняемой) модели процесса.

Начальное и конечное события могут быть типизированными. Использование основного набора элементов нотации Пример (см. Пул разделен на отдельные дорожки. Ветвление и слияние потоков управления осуществляется логическими операторами «И» и «ИЛИ». ПРИМЕР ИСПОЛЬЗОВАНИЯ ЭЛЕМЕНТОВ НОТАЦИИ BPMN Рассмотрим пример (см. иллюстрирующий использование основного набора элементов нотации BPMN. а окончание – завершающим. 63 . Рисунок 2-5) иллюстрирует использование описательного набора элементов нотации. Дорожки являются не обязательным элементом нотации.ствующего продукта. Процесс ограничен пулом. Названия дорожек символизируют роли участников. Рисунок 2-4. он имеет название. которое обозначает название компании. Все элементы управления между началом и стартом связаны в единую цепочку управления посредством потока управления. Начало процесса обозначено стартовым событием. Рисунок 2-4). Однако они позволяют сделать схему процесса более наглядной и читаемой.1. в нашем случае это «автомагазин».4. в нашем примере это событие-таймер и отправка сообщения. поскольку назначение исполнителей определяется для каждой задачи в отдельности. 2.

Все типы диаграмм могут быть объединены в рамках единой модели процесса. Основной набор элементов 2. • исполняемые схемы внутренних процессов. Диаграммы хореографии (Choreography). 4. Модели публичных (внешних) процессов. 2. Диаграммы диалогов (Conversation).5. Диаграммы оркестровки (схемы потока работ). b.Доставить заказ Подпроцесс развернутый Интерактивная операция Объект данных Оформить накладную Ручная операция Отвезти заказ Заказ Принять заказ Утвердить заказ Закрыть заказ Отправить сообщение Принять оплату Начинать по таймеру Интерактивная операция Бизнес правило Отказ Ошибка завершения Подпроцесс глобальный Записать в CRM Рисунок 2-5. КАТЕГОРИИ ДИАГРАММ БИЗНЕСПРОЦЕССОВ Спецификация BPMN 2. 3. 64 . Модели приватных (внутренних) бизнес-процессов: • концептуальные схемы внутренних процессов. которая описывает регламенты обмена сообщениями между участниками. которая помогает сгруппировать отдельные сообщения.0 регламентирует следующие типы диаграмм бизнес-процессов: 1. включая: a. Рассмотрим эти категории бизнеспроцессов. Диаграммы взаимодействия участников одного или нескольких бизнес-процессов (Collaboration). которыми обмениваются участники по темам обсуждения.

а только подразумевается. Пример (см.5.1. п. ДИАГРАММЫ ОТКРЫТОГО ПРОЦЕССА Диаграмма открытого процесса есть схема процесса. Схемы процессов можно разделить на закрытые и открытые. моделируемого внутри некоторого контейнера. то есть координацией вызовов необходимых веб-служб. то схема называется закрытой. показывающая очередность выполнения операций процесса. Рисунок 2-6) иллюстрирует закрытый процесс.1. Рисунок 2-7) иллюстрирует схему открытого процесса. Если пул явно указывается на диаграмме процесса. 2. Рисунок 2-6. приватные (внутренние) и публичные (внешние). 65 . ДИАГРАММЫ ОРКЕСТРОВКИ Диаграмма оркестровки (orchestration) . Пример (см. такой бизнеспроцесс может рассматриваться как набор вызовов вебсервисов. Поэтому моделирование потоков работ иногда называют оркестровкой процесса. Этот контейнер можно изображать на схеме явно или только подразумевать.это схема. С позиции сервис-ориентированных технологий.5. 9). на которой пул явно не указывается.1.2. ДИАГРАММЫ ЗАКРЫТОГО ПРОЦЕССА Диаграмма закрытого процесса есть схема процесса.1.5. Закрытый процесс 2. называемого пулом (см.2.

соединяющие операции процесса. отсутствуют многие детали. 1. которые не позволяют выполнить процесс в соответствии с описанием без дополнительного уточнения. не определены исполнители задач и т. что у процесса единый владелец. ДИАГРАММА ПРИВАТНОГО ВЗАИМОДЕЙСТВИЯ Диаграмма приватного взаимодействия (private) показывает процесс.3. Например. Рисунок 2-6) является приватной. прописаны не все условия логических операций. Пример аналитической схемы процесса 66 .Рисунок 2-7. 2. 2.5.д. На схеме изображены не все переходы. в закрытом или открытом процессе поток управления (см. Рисунок 2-8.1.5.13) не может пересекать границу пула.Рисунок 2-8) создается для документирования и формализации различных областей деятельности организации. схема процесса (см.1. На таких схемах. явно очерченную или только подразумеваемую. как правило. Открытый процесс (раскрытый пул) В любом случае. АНАЛИТИЧЕСКАЯ МОДЕЛЬ ПРОЦЕССА Аналитическая модель процесса (см. который исполняется в пределах какой-либо организации или координируется из единого центра. п.4. Для неисполняемой аналитической модели это означает.

6. опускать все внутренние операции участников (см.2. 1.е. Рисунок 2-9.5. п. Во-первых. необходимую для последующего выполнения процесса в специализированной программной среде BPMS. Публичное взаимодействие. ИСПОЛНЯЕМАЯ МОДЕЛЬ ПРОЦЕССА Исполняемая модель (см. включать спецификацию всех правил.1.5.15) должна содержать всю информацию.1. процессы обоих участников взаимодействия могут моделироваться как «черный ящик». каждый из них имеет своего владельца. т. ДИАГРАММА ПУБЛИЧНОГО ВЗАИМОДЕЙСТВИЯ Диаграмма публичного взаимодействия (public) показывает коммуникацию между двумя приватными процессами. Пример исполняемой схемы процесса 2. Диаграмма публичного взаимодействия может иметь разную степень детализации. Она обязана показывать все возможные маршруты исполнения. определять расписание исполнения процесса. Рисунок 2-9) иллюстрирует исполняемую схему бизнес-процесса. закрытые процессы 67 .5. используемых для маршрутизации потоков. определять исполнителей операций Пример (см. иметь детализацию уровня элементарных действий. у каждого свой центр управления. Рисунок 2-10). Рисунок 2-10.

Поставщик Принять запрос Отправить предложение Принять вопрос Отправить ответ Запрос Предложение Уточнение Ответ Принять предложение Запросить уточнение Принять ответ Заказчик Отправить запрос Рисунок 2-12. видимые участникам информационного обмена. Публичное взаимодействие. которыми обмениваются оба участника. Рисунок 2-12) показывает действия Заказчика и Поставщика. которые видны второму участнику взаимодействия. Примечательно. а действия клиента не показаны вообще. процесс одного из участников может моделировать операции. Рисунок 2-11) показывает взаимодействие компании и ее корпоративного клиента. которыми обмениваются оба участника. действия обоих участников м. отвечающие за коммуникацию между участниками. Остальные операции не изображаются. показаны только те задачи. Пример (см. потоки сообщений.б.Во-вторых. один открытый процесс Наконец. Пример (см. изображены на диаграмме. открытые процессы 68 . что схема показывает только операции. Поставщик Запрос Предложение Уточнение Ответ Отправить запрос Принять предложение Запросить уточнение Принять ответ Заказчик Рисунок 2-11. Действия компании расписаны не полностью. Публичное взаимодействие. Модель позволяет показать потоки сообщений.

электронную почту и т. а на другом листе этот же процесс описывается как приватный. когда в рамках единой модели один лист диаграммы изображает процесс публичного взаимодействия. Неверно представлять одного из участников физическим лицом.5). модели могут отличаться и по существу. что приватный процесс поддерживает публичный. 69 . Более того. Приватный процесс для обмена сообщениями использует сигналы. которое не имеет своего собственного внутреннего бизнес-процесса или не обязано пользоваться BPMS системой Заказчика. но с разной степенью детализации: публичный процесс не до конца определен.Следует особо подчеркнуть две особенности диаграммы публичного взаимодействия: • Во-первых. обе модели изображают один процесс.5. он включает операции. Публичный процесс содержит две операции отправить и принять сообщение. обмен информацией между участниками осуществляется через поток сообщений (см. Принято говорить.1. 2. которых в публичном процессе нет. 6. Рисунок 2-13) показывает две схемы: диаграмму публичного взаимодействия (А) и эквивалентную ей приватную (Б). в нем отсутствуют некоторые детали. а не через абстрактный информационный поток.п. например. оба участника взаимодействия являются юридическими лицами. МОДЕЛИРУЕМЫЕ И НЕМОДЕЛИРУЕМЫЕ ДЕЙСТВИЯ НА ДИАГРАММЕ ВЗАИМОДЕЙСТВИЯ Возможна ситуация. • Во-вторых. если он способен воспроизвести требуемое поведение. Пример (см. Возникает коллизия. тогда как соответствующий ему приватный процесс определен полностью и во всех деталях. которые не важны с точки зрения обмена сообщениями.7. которые осуществляют свою работу в соответствии со своими собственными внутренними бизнес-процессами.

СХЕМЫ ВЗАИМОДЕЙСТВИЯ Представим себе.6. что два процесса исполняются асинхронно и независимо друг от друга. Следует учитывать. как если бы они были экземплярами другого. Эквивалентные публичный (А) и приватный (Б) процессы Приватный процесс. 2. что схема определяет лишь наличие потока сообщений. Взаимодействие между участниками осуществляется при помощи потоков сообщений. ко70 . Схемы взаимодействия (Collaboration) показывают обмен сообщениями между двумя и более участниками. Необходимо лишь. но иногда они должны взаимодействовать и обмениваться информацией. Участники по отдельности управляют своими бизнес-процессами. но не детализирует его содержимое. Рисунок 2-14). На диаграмме публичного процесса допускается появление немоделируемых действий. поддерживающий публичный. модель публичного процесса выглядит как неполностью детализированная схема соответствующего ей приватного.Рисунок 2-13. у каждого есть свой владелец. На схеме показываются только операции. не обязан полностью его копировать. чтобы во время исполнения экземпляры одного процесса вели себя так же.о. которые специфицированы в поддерживающем его приватном процессе. Для изображения участников на схеме взаимодействия обычно используют графический элемент пул (см. Т.

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

Рисунок 2-14 Моделирование обмена сообщениями между участниками

2.7.

ХОРЕОГРАФИЯ ПРОЦЕССОВ

Схема хореографии (без пулов, без оркестровки) показывает
последовательность процедур обмена сообщениями между
двумя и более участниками (см. Рисунок 2-15). В отличие от
обычного процесса, который обязательно изображается внутри
пула, хореография обычно описывается без пулов.

Рисунок 2-15. Схема хореографии.
В целом, хореография похожа на схему приватного процесса, поскольку она так же состоит из цепочки задач хореографии, событий и логических операций. Тем не менее, хореография отличается от схемы оркестровки тем, что операции на
ней отображают факт передачи сообщения между двумя и более участниками.
71

2.7.1. СХЕМА ДИАЛОГОВ
Схема диалога позволяет отобразить информационный обмен
сообщениями, сгруппированными по темам обсуждения. Например, заказ товаров, перевозка грузов, выписка счета м.б. темой диалога между поставщиком и покупателем. По сути, такие схемы изображают различные сценарии общения участников межу собой. Рассмотрим пример из сферы логистики.
Процесс «пополнение запасов» может быть описан следующим
сценарием: создается заказ, назначается перевозчик товара,
транспортировка, оплата, доставка. Таким образом, на схеме
диалога (см. Рисунок 2-16) шестиугольники отображают обмен
сообщениями между пулами – участниками процесса. Мы видим процесс с «высоты птичьего полета», однако все необходимые детали на нем присутствуют.

Рисунок 2-16. Схема диалога участников процесса

2.8.

СХЕМАМЫ ОРКЕСТРОВКИ,
ДИАЛОГОВ ХОРЕОГРАФИИ

Рисунок 2-17 иллюстрирует соотношение между схемами оркестровки, диалогов и хореографии

Рисунок 2-17. Схемы оркестровки, диалогов и хореографии
72

3.ОПЕРАЦИИ
Операции процесса бывают элементарными и составными.
Элементарные операции м.б. поручены одному исполнителю.
Составные операции подразумевают декомпозицию на составляющие их действия низшего порядка. Как правило, детализация составной операции изображается на отдельной диаграмме процесса. Этот тип элементов называется подпроцесс.
Для изображения операций в нотации BPMN используются различные графические элементы. Выделяют несколько типов: операция, подпроцесс, глобальная (вызывающая) операция, транзакция (см. Рисунок 3-1).

Рисунок 3-1. Типы операций в нотации BPMN 2.0
Под операцией будем понимать единицу работы, изображенную на схеме процесса. Операции - главная составляющая любого процесса.
Подпроцесс это группа логически связанных операций.
Подпроцесс может включать одну или несколько связанных
потоками управления операций (см. 3.5)
Глобальная (вызывающая) операция обозначает вызов
повторно используемого, глобально известного подпроцесса
(см. 3.5.2).
Транзакцией называется подпроцесс, который может
быть выполнен либо целиком, либо не выполнен вообще. В
случае, если транзакция не завершена, возникает необходимость вернуть все измененные данные в состояние, предшествовавшее началу выполнения транзакции.

3.1.

ВИДЫ ОПЕРАЦИЙ

В нотации BPMN знак операции процесса может относиться к
одной из семи видов задач, для каждой предусмотрен отдель73

ный маркер, позволяющий визуально различать операции.
Таблица 3-1 показывает маркеры различных видов операций.
Таблица 3-1. Виды операций
Тип операции
Интерактивная (Пользовательская)
Ручная
Автоматическая (Сервис)
Сценарий
Бизнес-правило
Отправка сообщения
Получение сообщения
Нетипизированная, абстрактная

Обозначение

нет

3.1.1. ИНТЕРАКТИВНАЯ ОПЕРАЦИЯ
Интерактивная операция исполняется в среде BPMS, она создает пользовательское задание для участников бизнес-процесса,
которое появляется в рабочей области соответствующего исполнителя на BPMS портале. С интерактивной операцией связанна соответствующая экранная форма, которую видит участник.
Когда стартует исполнение интерактивной операции, для
нее необходимо назначить исполнителя. Процедура выполняется в два этапа, отбор потенциальных исполнителей, выбор
актуального исполнителя (см. п. 9). После того как исполнитель
завершает работу, управление передается следующей по порядку операции.

3.1.2. РУЧНАЯ ОПЕРАЦИЯ
Ручная операция отличается от пользовательской тем, что сотрудники выполняют работу вне рамок BPMS или иной ИС.
Например, получают задание «выкопать яму», «перенести коробки», «приготовить обед» и т.д. В этом случае, в рабочей области портала соответствующий исполнитель только проставляет отметку о факте выполнения ручной операции.

74

3.1.3. АВТОМАТИЧЕСАЯ ОПЕРАЦИЯ
Автоматическая операция выполняются без участия людей.
Как правило, в ней реализуется вызов внешних, по отношению
к BPMS-среде служб, информационных систем, например вебсервисов.
Вначале входные данные операции сопоставляются с аргументами соответствующего сервиса. Затем происходит вызов
сервиса. В конце выходные аргументы сервиса отображаются
на выходной набор данных операции.

3.1.4. ОПЕРАЦИЯ СЦЕНАРИЙ
Операция сценарий содержит в себе простейший программный код, исполнение которого не требует внешних информационных ресурсов. Язык написания сценария зависит от используемой BPMS среды и никак не специфицируется BPMN.

3.1.5. ОПЕРАЦИЯ БИЗНЕС-ПРАВИЛО
Операция бизнес-правило помечает задачу, в которой проверяется значения параметров, определяющих или ограничивающих какие-либо стороны бизнеса. Бизнес-правила можно
менять в ходе исполнения и, таким образом, в режиме реального времени управлять логикой выполнения текущих и вновь
запускаемых экземпляров процесса. Например, банк определил, что если сумма кредита не превышает 100 условных единиц, то проверка заемщика службой безопасности не требуется. В любой момент банк вправе поменять пороговое значения
на 50, и тогда все экземпляры процессов, выполнение которых
еще не дошло до точки принятия решения, у которых сумма
кредита более порогового значения, попадут в службу безопасности. Изменение схемы процесса при этом не потребуется.
Операция бизнес-правило часто используется совместно с логическими операторами. При этом бизнес-правило проверяет истинность некоторого условия, а логический оператор осуществляет маршрутизацию потока управления.

75

3. Операции отправки и получение сообщения Когда поток управления достигает операции принять сообщение (см. используется поток сообщений – пунктирная линия. не имеет реального наполнения. 6. Рисунок 3-2А) последняя генерирует информационное оповещение. а управление передается на следующую операцию. п. Она может использоваться в аналитическом моделирова76 . Что бы указать. Отправка сообщения осуществляется следующим образом: когда поток управления достигает операции отправить сообщение (см. последняя переходит в режим ожидания. она не может иметь входящий поток управления. Следует отметить.). Более подробное они будет рассмотрены ниже (см. Рисунок 3-2. Только после получения сообщения. но только исходящий. кто является получателем.6. Для этого используется специальная операция получить сообщение и стартовать процесс.4. АБСТРАКТНАЯ ОПЕРАЦИЯ Абстрактная (нетипизированная) операция. Рисунок БВ).7. После этого управление передается на следующую операцию. Сразу по получению управления она считается исполненной. что сообщение может переносить полезное информационное наполнение. что бы стартовать исполнения процесса. управление передается следующему заданию.1. соединяющая отправителя и получателя.1. Операция получения сообщения может использоваться для того. 3. выполнение этой операции завершается. ОПЕРАЦИЯ ОТПРАВКА И ПОЛУЧЕНИЕ СООБЩЕНИЯ Операции отправки и получения сообщений предназначены для осуществления межпроцессного взаимодействия.

параллельное исполнение. Составная операция мо77 .2. операция «по случаю» (Ad-Hoc).0 регламентирует шесть видов маркеров. тип операции уточняется и указывается на схеме процесса. компенсация. МАРКЕР ПОДПРОЦЕССА Маркер подпроцесса сигнализирует аналитику. что тот имеет дело с составной операцией – подпроцессом. В дальнейшем.2. Последние. при переходе к исполняемой модели. она допускает несколько способов исполнения. Они размещаются поверх графического элемента. Нотация BPMN 2.ч. параллельное выполнение. МАРКЕРЫ ОПЕРАЦИИ Операция является базовым графическим элементом нотации. когда не ясен окончательно тип моделируемой операции. могут быть составными. 3. Маркеры операций Маркер Тип операции Подпроцесс Цикл Параллельное исполнение Последовательное исполнение Компенсация По-случаю (Ad-Hoc) 3.1. Глубина вложности составных операций не ограничивается. в т. последовательное выполнение. Таблица 3-2. добавляя тем самым определенную семантику.нии. Для того чтобы указать способ исполнения операций используются маркеры. в свою очередь. три маркера для изображения разных видов циклов: обычный цикл. который может быть декомпозирован на отдельные операции.

результат типа Boolean: Если условие ИСТИННО. то в конце итерации loopMaximum: Максимальное количество итераций (повторений) completionCondition Условие завершения. который определяет. МАРКЕР ЦИКЛА Маркер цикла означает последовательное. Атрибуты циклического исполнения операции Атрибут Семантика исполнения loopCounter Счетчик итераций.2.do». когда проводить проверку: Если testBefore = ИСТИННО.жет быть свернутой или раскрытой. МАРКЕР ПАРАЛЛЕЛЬНОГО ВЫПОЛНЕНИЯ Маркер параллельного выполнения означает одновременный. определяющее количество циклов повторения. Число повторений и семантика исполнения определяются встроенными атрибутами опе78 . участвующих в процессе станет известно на этапе исполнения.2. Он применяется.. «repeat. Таблица 3-3 объясняет значения атрибутов: Таблица 3-3. будет запущено нужное число экземпляров операции. разные экземпляры одного процесса могут вызывать разное число контрагентов. все еще не завершенные экземпляры будут завершены. когда аналитик на этапе моделирования не знает точное количество экземпляров в момент исполнения. testBefore Флаг.3. Число повторений и способ исполнения определяются встроенными атрибутами операции и могут гибко перестраиваться. мы заранее не знаем их числа. 3. Число контрагентов.until». Вычисление числа экземпляров выполняется только один раз.2. Если testBefore = ЛОЖНО.. в начале. циклическое исполнение операции. целое число. Развернутый подпроцесс детализуется на отдельной странице диаграммы. описывая электронное взаимодействие с контрагентами. Для цикла можно задать условие повторения: «while.. более того. 3. Например. параллельный запуск нужного числа экземпляров операции..

Если выбран вариант последовательного исполнения. все еще не завершенные экземпляры будут завершены. при которых будет создан еще один экземпляр процесса. • Complex: Комплексное условие определяет порядок создания маркеров потока управления. Семантика параллельного исполнения Атрибут isSequential Семантика исполнения Если ИСТИННО. • All: Один маркер потока управления создается после завершения всех экземпляров.2. то параллельное исполнение.рации. Часто операция с параллельным исполнением обрабатывает коллекцию. результат типа Boolean: Если условие ИСТИННО. то последовательное исполнение. то нужное число экземпляров процесса запускается единовременно. маркер параллельного исполнения.4). • One: Один маркер потока управления создается после завершения первого экземпляра. loopCardinality Количество экземпляров (повторений) loopDataInputRef Указатель на массив данных completionCondition Условие завершения. если установлено соответствующее значение атрибута isSequential. MultiInstanceBehavior: Определяет способ координации завершения па{None|One|All|Complex} раллельных экземпляров: • None: Маркеры потока управления создаются после завершения каждого экземпляра. 3. Если ЛОЖНО. допускает последовательное исполнение (см. Каждый стартуемый экземпляр работает со своим элементов этого 79 . то следующий экземпляр стартует только после завершения предыдущего. Соответствующие атрибуты определяют условия координации и завершения запущенных множественных экземпляров процессов. Аналитик может явно указать число экземпляров или указать условие. п. Таблица 3-4 объясняет назначение атрибутов: Таблица 3-4. Как видно из таблицы. Если выбран вариант параллельного исполнения. интерпретируемую как массив данных.

3. соответственно изменится маркер активности. Работа организуется точно так же. МАРКЕР AD-HOC ОПЕРАЦИИ Операция для случая (ad-hoc) обозначает решение. причем они не обязательно связанны между собой потоками передачи управления.4.2. означает параллельное исполнение (см.until».массива.. Пользователь сам выбирает нужные ему действия... «repeat. если установлено соответствующее значение атрибута isSequential. В этом случае. а затем забронировать гостиницу или может выполнить действия в другом порядке. число запущенных экземпляров определяется количеством элементов в массиве. что маркер последовательного исполнения.do». Он может вначале получить командировочные. Рисунок 3-3) иллюстрирует «ad-hoc» операцию «подготовка командировки».5. как в обычном цикле. Обратим внимание. 3. Данный маркер полезен при моделировании неструктурированных процессов. которое состоит из набора вложенных операций. Последовательность исполнения операций и количество их повторений не регламентируются и определяются пользователем в ходе работы.3). Пример (см. Число повторений и способ исполнения определяются встроенными атрибутами операции.2. 3.. каждая предназначено для решения своей задачи. предназначенное для конкретной проблемы или ситуации. Для цикла можно так же задать условие вида: «while. Пользователь может выбрать подходящую операцию на этапе исполнения. МАРКЕР ПОСЛЕДОВАТЕЛЬНОГО ВЫПОЛНЕНИЯ Маркер последовательного выполнения отображает циклическое выполнение множества экземпляров. 80 .2. Маркер «ad-hoc» используется для обозначения сложного действия.. так же как для параллельного исполнения.

ч. заблокировали средства на счете клиента. Операция A имеет прикрепленное событие компенсация. которая откатит данные в исходное состояние.6. выполняющую компенсацию. Разумеется. т. уже успешно завершились. Рисунок 3-4) иллюстрирует операцию компенсации. Если транзакция не выполнена. что транзакция не выполнена. Часть операций. Операция A есть составная часть некоторой транзакции. составляющих транзакцию. для этого следует откатить измененные в них данные в состояние. предшествовавшее началу выполнения транзакции. ОПЕРАЦИЯ КОМПЕНСАЦИЯ Операция компенсация используется для описания логики отмены действий. мы начали бронировать билеты. средства надо разблокировать. ранее завершенные операции надо отменить. Пусть несколько операций образуют транзакцию. Например. то будет выработан сигнал. компенсацию можно определить не для всех типов операций. которое с помощью направленной ассоциации указывает на операцию.Рисунок 3-3. однако какая-то из оставшихся завершилась отказом. что бронирование отменяется.2. последнее запустит операцию компенсация. который будет перехвален прикрепленным событием. Ad-hoc операции 3. выполненных в некоторой ранее завершенной операции. 81 . однако выяснилось. Это означает. Пример (см.

8. 4. 2. содержащий набор действий. Параллельное исполнение Ad-Hoc подпроцессов. 7. 3. Свернутый подпроцесс. Свернутый Ad-Hoc подпроцесс. 11. Циклическое исполнение подпроцесса.7. 10. Циклическое исполнение Ad-Hoc подпроцесса. 9. она лишь указывает операцию. Циклическое исполнение подпроцесса. выполняющих компенсацию. Подпроцесс Ad-Hoc итеративно повторяется. КОМБИНАЦИИ МАРКЕРОВ ПОДПРОЦЕССА Спецификация BPMN определяет одиннадцать различных вариантов комбинаций маркеров операции. 82 . 3. каждая итерация выполняет компенсацию. выполняемых по случаю. каждый экземпляр выполняет компенсацию Таблица 3-5 показывает допустимые варианты комбинации маркеров (маркеры параллельного и последовательного исполнения не различаются). стрелка направленной ассоциации не обозначает переход управления. реализующий компенсацию. выполняющую откат данных. Свернутый подпроцесс.2. Операция компенсация Следует обратить внимание. Параллельное исполнение подпроцессов. Параллельное исполнение подпроцессов. 1. которые могут использоваться с обычными подпроцессами. 6. 5. Циклическое исполнение Ad-Hoc подпроцесса с компенсацией. Параллельное исполнение Ad-Hoc подпроцессов.Рисунок 3-4.

Рисунок 3-5). Группа может пересекать границы пула. принадлежащие разным процессам (см. Группа никоим образом не оказывает влияния на исполнение процесса. Объединяя несколько задач в группу. объединяя операции. мы можем.3. На схеме процесса группа отображается прямоугольником. ограниченным штрихпунктирной линией. Группа операций 83 . Процесс 1 Процесс 2 Группа задач Рисунок 3-5.Таблица 3-5. Компенсация + Ad. Комбинации маркеров подпроцесса Подпроцесс Компенсация Ad-Hoc Нет Подпроцесс Циклическое исполнение Параллельное исполнение 3. комментировать их.Hoc 1 2 3 4 5 6 7 8 9 10 11 ГРУППА ОПЕРАЦИЙ Группа операций позволяет визуально объединить несколько задач. к примеру.

показывать только наиболее вероятные сценарии исполнения. Исполняемые модели включают полный набор элементов нотации. инициируемая начальным событием. оно включает абстракции высокого уровня. Они не предназначены для последующего исполнения. поэтому могут опускать некоторые детали. основные этапы его выполнения. в последнем случае он присутствует неявно.4. который наиболее часто используют бизнес аналитики. используя для этого ограниченное множество элементов нотации. приближенное представление о рассматриваемом процессе. не включать детализацию действий низкого уровня. • Исполняемые модели предназначены для запуска в среде BPMS. Процесс всегда располагается внутри пула. но используют элементы. МОДЕЛЬ ПРОЦЕССА Модель процесса есть совокупность логически связанных работ. даже редко используемые. в том 84 . 2. в которых программируется семантика исполнения. Это есть предварительное. например. • Аналитические модели служат средством для выявления бизнес проблем исследуемого процесса. содержат детализацию элементарных действий.определяют структуру моделируемого процесса. Исполняемые и аналитические модели процессов могут иметь разную степень детализации и использовать разные подмножества элементов нотации (см. опуская редко используемые. и завершающаяся конечным событием. без которых работа системы окажется невозможной. Они покрывают все допустимые сценарии исполнения. изображаемых на схеме операциями.3. исполнителей и их права доступа к объектам системы. их причинно-следственные связи. Эти модели фокусируются на визуальном представлении бизнес-процесса Они используют расширенный набор элементов. Спецификация различает следующие классы моделей: • Концептуальные модели . определяют участников. п. В некоторых случаях пул может не отображаться.4).

5. во втором случае. Он может изображаться как в свернутом. Подпроцессы м. ВЛОЖЕННЫЙ ПОДПРОЦЕСС Вложенный подпроцесс есть часть родительского процесса. как завершились все существующие в нем потоки управления.числе такие. если произошло событие.5. Поскольку процесс изображается в рамках схемы родительского. Вложенный подпроцесс в качестве стартового события.1. Вложенный подпроцесс изображается на одном листе модели с родительским процессом верхнего уровня (см. он выглядит как операция. глобально известными (global). где явно задается семантика исполнения. В первом случае. Подпроцесс это последовательность логически связанных работ. логических операторов. ПОДПРОЦЕСС Часто сквозные процессы представляются как цепочка взаимодействующих подпроцессов. она представляет отдельный процесс. использует только одно обычное нетипизированное событие. Он завершается после того. он не может изображать пулы и дорожки. у которой добавлен маркер подпроцесса (Рис. Рисунок 3-6). двух видов: вложенными (embedded) и повторно используемыми. запускающего исполнение. имеющая начало и конец.б. указанное в качестве стартового. событий и знаков перехода управления (Рис. составленный из операций. 3. 85 . А). он определен и известен только локально и не может использоваться в других проектах. Подпроцесс запускается. так и в развернутом виде. Б). выполняющая законченное действие. 3.

обе операции Б и В будут запущены одновременно и выполняются параллельно. все сделанные изменения в данных. Область действия переменных вложенного процесса Развернутый подпроцесс изображает группу из нескольких. входящие в подпроцесс исполняются параллельно и независимо друг от друга. Пример (см. Пример (см. графически не связанных потоком управления задач. Когда операция A будет выполнена. стартует подпроцесс. 86 . Рисунок 3-8) показывает две операции Б и В. Рисунок 3-7. Развернутый вложенный подпроцессы Объекты данных. А после его завершения. Рисунок 3-7) иллюстрирует область действия переменных вложенного процесса. что задачи. будут видны в родительском процессе. помещенные внутри вложенного подпроцесса. автоматически доступны операциям вложенного подпроцесса.Рисунок 3-6. которые определены в родительском процессе. Эта форма записи показывает.

а в другой ситуации выступать в качестве процесса верхнего уровня. который доступен для многократного повторного использования. В спецификации BPMN 1. что подпроцесс может использоваться двояко: в одной ситуации как глобальный. ПОВТОРНО ИСПОЛЬЗУЕМЫЙ ПОДПРОЦЕСС Повторно используемый (внешний) подпроцесс это отдельный модуль. путем вызова из разных процессов. Повторно используемый подпроцесс может казаться визуально не отличим от обычного вложенного.Рисунок 3-8. Он представляет некоторый сервис. не показывает последовательность потоков управления. отличия заключаются в способе его запуска. 3.0 этот тип подпроцессов назывался независимый подпроцесс.2.5. который известен глобально и может многократно использоваться путем вызова из разных процессов. Повторно используемый подпроцесс разрабатывается полностью независимо от вызывающего его процесса. Повторно используемый подпроцесс может начинаться и заканчиваться только простыми. Подпроцесс с параллельно исполняемыми заданиями Эта форма записи не предполагает указания стартового или конечного событий подпроцесса. Однако следует учесть. нетипизированными событиями старта и завершения. Он не может начинаться со стартового события сообщение и таймер. при этом он может иметь дополни87 .

Рисунок 3-9. Поскольку модель внешнего подпроцесса разрабатывается на отдельном листе схемы. когда подпроцесс используется как повторно используемый. с использованием событий сообщений и таймеров. Спецификация определяет.б.тельные возможности старта. когда подпроцесс используется как встроенный. Старт по сообщению используется. которые могут выступать в качестве глобальных: • Пользовательская операция • Ручная операция • Операция сценарий 88 .3.ч. ВЫЗЫВАЮЩАЯ ОПЕРАЦИЯ Вызывающая операция (Call Activity) используется. когда возникает необходимость вызвать внешний по отношению к данной модели повторно используемый процесс. четыре типа операций.5. глобально известен. следует использовать вызывающую операцию (Call Activity). В результате исполнения этой операции управление передается в вызываемый подпроцесс. она может включать пулы и дорожки. в т. который имеет два набора стартовых событий. Пример (см. Рисунок 3-9) показывает повторно используемый подпроцесс. а после его окончания снова вернется в родительский. Повторно используемый компонент д. а простое нетипизированное событие старт. 3. Подпроцесс «двойного» назначения Когда возникает необходимость вызвать внешний повторно используемый компонент.

передаваемых ему на вход. а после его окончания управление снова вернется в родительский процесс (см. Придется явно описать набор информационных объектов. Рисунок 3-11). а затем организовать прием возвращаемой информации из подпроцесса в вызывающий процесс. Рисунок 3-10) иллюстрирует вызов глобальной пользовательской операции. возможно определить их взаимное отображение или правило трансформации. Вызывающая операция и глобальный процесс.4. потребуется явно передавать их. изображаемой более толстой линией.5. Вызывающая операция передает управление в вызываемый подпроцесс. ОБЛАСТЬ ДЕЙСТВИЯ ДАННЫХ ПРИ ВЫЗОВЕ ГЛОБАЛЬНО ИЗВЕСТНОГО ПОДПРОЦЕССА В рамках повторно используемого подпроцесса неизвестны данные. Пример (см. 89 .• Операция бизнес-правило Глобальная операция визуально отличима благодаря границе. Рисунок 3-11. Рисунок 3-10. 3. Глобальная пользовательская операция Глобально известный. повторно используемый подпроцесс моделируется на отдельной схеме вне рамок данного процесса. определенные в родительском процессе. Поскольку данные не будут автоматически доступны в вызываемом подпроцессе.

которые. Подпроцесс Ad-Hoc состоит из операций и подпроцессов. Бронировать гостиницу и билеты. например последовательный и параллельный. AD-HOC ПОДПРОЦЕСС ДЛЯ КОНКРЕТНОГО СЛУЧАЯ Подпроцесс для конкретного случая (Ad-Hoc) предназначен для решения слабо формализованной задачи. длительность исполнения и число повторений операций и подпроцессов. так что пользователь в ходе исполнения сам определяет порядок.Рисунок 3-12. перечисленных в Ad-Hoc подпроцессе. Рисунок 3-13. Пользователь сам решает. последний включает две операции. Рисунок 3-13) изображает свернутый и развернутый Ad-Hoc подпроцесс. Во втором случае возможна конкуренция разных операций за доступ к общему ресурсу. Повторно используемый подпроцесс 3. Свернутый и развернутый Ad-Hoc подпроцессы 90 .5.5. Пример (см. время запуска. когда заранее известен возможный спектр всех действий. Пользователь может выбрать разные способы исполнения операций. но нельзя предсказать последовательность их исполнения. в каком порядке выполнять операции. не связаны общими сценариями исполнения.

подпроцессы. потоки сообщений. СОБЫТИЙНЫЙ ПОДПРОЦЕСС Событийный подпроцесс (стартующий по событию) описывает последовательность действий. могут быть частично логически взаимосвязаны. Этот тип подпроцессов не является частью 91 . можно указать операции. Пример (см. ассоциации и ассоциации данных. потоки управления. Подпроцесс Ad-Hoc не может включать следующие элементы нотации BPMN: начальные и конечные события. в котором присутствуют операции. логические элементы. Рисунок 3-14) изображает подпроцесс.5. объекты данных. объекты данных отображают передачу информации между операциями. промежуточные события. что определяет очередность их запуска. связанные потоком управления. включенные в Ad-Hoc подпроцесс. диалоги. Подпроцесс «Ad-Hoc» с зависимыми операциями 3. когда последующая работа может начаться только по завершении предшествующей. осуществляющие откат данных. Рисунок 3-14. например. как будет зарегистрировано некоторое ожидаемое событие.Подпроцесс Ad-Hoc может включать только ограниченное количество элементов нотации BPMN: операции и группы операций. Другой тип связей отображает обмен информацией между операциями процесса Ad-Hoc. Кроме того. элементы процессной хореографии Операции. которую необходимо выполнить после того.6. связь предшествование и последование отображает временную зависимость между работами типа "конец-начало".

Пример (см. Он не связан непосредственными переходами управления с основным процессом. 92 .9). А непрерывающие стартовое событие инициирует исполнение событийного подпроцесса одновременно и параллельно с основным. • Множественное событие (Multiple). параллельно с ним. Рисунок 3-15) иллюстрирует развернутый (А) и свернутый (Б) событийные подпроцессы Рисунок 3-15. причем только определенных типов: • Сообщение (Message). 6. Способ исполнения зависит от типа события. • Сигнал (Signal). которое инициирует старт событийного подпроцесса (см. напротив. Если установлен маркер множественного исполнения. он показывает действия. Развернутый и свернутый событийный подпроцессы Подпроцесс. • Компенсация (Compensation). событийный подпроцесс исполняется многократно. • Условие (Conditional). выполняемые в особой ситуации. который вызывает несколько событийных подпроцессов.стандартного сценария исполнения процесса. Событийный подпроцесс может иметь только одно стартовое событие. • Ошибка (Error). изображаемой прерывистой линией. стартующий по событию может прерывать основной процесс или выполняться одновременно. • Эскалация (Escalation). Рисунок 3-16) изображает родительский процесс. На схеме процесса этот подпроцесс обозначается с границей. Прерывающее стартовое событие приостанавливает основной процесс до окончания событийного. Пример (см.

но разными способами. Второй из вложенных подпроцессов обрабатывает ошибки. все изменения данных. станут автоматически известны в вызывающем процессе. Событийный подпроцесс Событийный подпроцесс является вложенным в основной процесс. он содержит операцию отправки сообщения. Рисунок 3-16. поэтому все переменные. которая прерывает его исполнение. он не прерывает работу основного процесса и может исполняться несколько раз. Вовторых. выполняемые в событийном процессе. возникающие в ходе исполнения основного процесса. будут автоматически доступны в потомке. Рисунок 3-17) изображает область действия переменных событийного подпроцесса. 93 . определенные в родительском процессе. в ходе исполнения основного процесса могла произойти ошибка. Во-первых. И наоборот. Пример (см. Первый из вложенных подпроцессов стартует после получения сообщения.

которая описывает способы координации для атомарных транзакций и для долго живущих бизнес транзакций. билеты и гостиницу мы бронируем через агентство или международную систему заказов. что в обратом порядке. по отношению к BPMS системах и включают межорганизационное взаимодействие.это механизм. либо не выполняется вообще и тогда все изменения данных отменяются. чтобы принимать решение об успешности выполнения всего блока в целом. объединяющие совокупность атомарных транзакций. являются предметом рассмотрения данного вида процессов. соблюдая целостность данных. последовательно отменяются все сделанные ранее изменения в объектах данных.5. что транзакции связаны с изменением данных во внешних. Именно последние.0 опирается на спецификацию Web Services Atomic Transaction. а не отдельных операций порознь. При работе с транзакциями BPMN 2. которая заключается в том. Область действия переменных событийного подпроцесса 3. Важно отметить. которая либо выполняется целиком и успешно.Рисунок 3-17. позволяющий объединять несколько действия в логический блок. ТРАНЗАКЦИОННЫЙ ПРОЦЕСС Транзакция . Транзакционный подпроцесс есть последовательность логически связанных операций. В последнем случае выполняется компенсация данных. 94 .7. например.

соответствует случаю. Свернутый транзакционный подпроцесс 1. изображаемой двойной линией. На схеме транзакционный процесс показывается с границей. что одно из действий не выполнено. управления не возвращается в вызывающий процесс немедленно. Второй. которое на схеме процесса изображаются как автоматическая операция. когда транзакция не была завершена из-за катастрофической внутренней ошибки. когда транзакция завершилась успешно. Рисунок 3-18. содержащий информацию об ошибке. становится возможно оповестить транзакцию. Благодаря этому. Успешное завершение транзакционного процесса отличается от поведения обычного процесса. потребуется внешнее вмешательство. был выполнен откат данных. Первый описывает движение потока управления. Рисунок 3-18). Когда поток управления достигает завершающего события. т. т. Вначале транзакционный 95 . когда транзакция была завершена. то в вызывающий процесс возвращается код завершения. потребуется отменить все предшествующие изменения. Межорганизационное взаимодействие обычно осуществляется с помощью Web Services. но возникла ошибка.Согласно этим спецификациям.ч. Если сервисная операция не завершается успешно. требуется взаимодействие на двух уровнях: между приложениями и между диспетчерами транзакций. Третий выход описывает ситуацию.ч. Он имеет один вход и три выхода (см. как произошло бы в обычном процессе. В спецификациях подробно описываются форматы сообщений и обмен сообщениями для обоих уровней взаимодействия.

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

Обработка транзакции 97 . так что мы не знаем реального состояния данных. Можно попытаться повторить транзакцию. откат средствами BPMS станет невозможен. так что списанные средства вернутся на счет. указан неправильный номер счета. или деньги зачислены на второй счет. то управление направляется на конечное событие Отмена (Cancel). но не списаны с первого и т.дующие ошибочные ситуации: деньги уже ушли с первого счета. но вторая сообщила об ошибке. Вначале будет выполнен откат первой операции. например. то поток управления достигает простого конечного события. В этот момент происходит обмен сообщениями с монитором транзакций. образующие транзакцию успешно завершены.д. но на другой не пришли. Следует отменить операции с данными. после получения подтверждения об успешном завершении. Наконец. а затем начнется выполнение обработчика прерывания. Если первая операция успешно завершена. если любая из операций не была завершена. либо вручную. Придется откатывать данные либо средствами монитора транзакций. Если все операции. исполнение продолжается. Рисунок 3-19. Прикрепленное событие-ошибка указывает сценарий продолжения для этого случая.

ПОТОКИ УПРАВЛЕНИЯ. будет ли выполнен данный поток. которая обозначает условие. если очередная операция завершилась успешно и ее цель была достигнута. Для моделирования развилок в процессе используется условный поток передачи управления. когда условие истинно. Потоки управления Знак Вид перехода Безусловный последовательный поток управления. Таблица 4-1. т. Для моделирования предпочтительного маршрута выполнения процесса обычно используется безусловный последовательный поток. куда надо передать управление. то знак ромбик не ставится. в котором будут выполняться операции процесса. он будет выполнен только в случае. то необходим знак ромбик. Таблица 4-1 показывает типы ПУ. который может содержать некоторый критерий. соответствующее данному переходу. Поток управления по умолчанию используется в случае. помогает выбрать то направление. Поток управления всегда располагается внутри пула. если условие для всех остальных потоков ложно. определяет маршрут. Он показывает порядок.ч. Условие проверяется перед выполнением перехода. в котором выполняются операции процесса. Если условный поток выходит из логического оператора.4. Для моделирования порядка и маршрутов выполнения операций процесса используются потоки управления (ПУ). Если условный поток выходит из операции. Поток управления по умолчанию. Стрелка может иметь надпись. показывает порядок. 98 . они изображаются на схеме в виде толстой. если для всех других потоков проверяемое условие не верно. определяющий. непрерывающейся стрелки в направлении от предшествующей операции к очередной. Условный поток. который не содержат в себе никаких условий. который будет выполнен.

5. Правила поведения: определяют необходимость выполнить соответствующее действие или управляющее воздействие. Например. но маршрутизирует его в соответствии с условием. определяющее или ограничивающее некоторые аспекты бизнеса. Они бывают двух типов: ветвления и слияния. У ЛО ветвления есть один входящий поток и. помогают узнать значения искомых величин. ЛО изображает некоторую работу процесса.5. первые разделяют и маршрутизируют поток управления по нескольким направлениям. но не определяют.правило. два исходящих потока. Входящие и исходящие ПУ могут присоединяться к любой точке границы ЛО. есть бизнес. вторые объединяют и синхронизируют несколько потоков в один. подразделяются на: • Правила вычисления. называемых фактами. ЛО есть элемент бизнес логики процесса. которое определяет направление движения выходного потока. а условие. Принято различать следующие виды бизнес-правил: 1. как предполагается достичь результата. Под бизнес-правилом принято понимать утверждение. Внешне операторы обоих типов не различимы. торговая скидка 99 . Правила определения: устанавливают критерий применимости какого-либо бизнес понятия. ЛОГИЧЕСКИЕ ОПЕРАТОРЫ И БИЗНЕС ПРАВИЛА Логические операторы часто путают с бизнес правилами. называемого фактом. не только к углам.1. по которому осуществляется ветвление. а у ЛО слияния есть несколько входящих и один исходящий.ЛОГИЧЕСКИЕ ОПЕРАТОРЫ В нотации BPMN логические операторы (ЛО) используются для маршрутизации потоков управления (ПУ) по разным направлениям и для синхронизации нескольких потоков. 2. по крайней мере. которая не изменяет входящий информационный поток. Правила постулируют ограничения на исполнение процесса.

что бы явно подписывать потоки управления. отправить сделку на одобрение руководителю с соответствующим уровнем полномочий (правило поведения). • Правила классификации. отдельно описана семантика ветвления и слияния.2. получено с использованием правила вычисления. помогают проверить истинность фактов. определяется правилом классификации. распространенная практика моделирования фиксировать на схеме правило ветвления. Это поможет аналитику четко локализовать соответствующую логику. ТИПЫ ЛОГИЧЕСКИХ ОПЕРАТОРОВ В зависимости от условий. определяющих правила ветвления и слияния. Например. низкая (правило классификации) и. ЛО делятся на виды. 100 . ветвление процесса осуществляется на основе правила поведения. средняя. Однако. наконец. которое. Но что есть Истинно. платежеспособностью клиента и т. причем так. Таблица 5-1 перечисляет все виды ЛО. 5. классифицировать размер скидки: большая. забывая про правила определения. В свою очередь последнее должно получить на вход некоторое значение.определяется общим объемом закупок за определенный период и числом закупок по определенной категории товаров. если на его счете имеется определенная сумма денег и он не имел задолжности по платежам. представим следующую последовательность действий: вычислить величину скидки как функцию от размера текущего заказа (правило вычисления). на основании которого осуществлена маршрутизация. можно предположить.д. Например. клиент классифицируется как VIP. выходящие из ЛО. которое принимает значения Истинно и Ложно. Другая рекомендация заключается в том. что бы отражать условие. а что есть Ложно. Рассмотрим пример. Из сказанного следует практическая рекомендация – следует явно выделять правила определения в отдельные конструкции на диаграмме потоков работ. Отсутствие в модели части бизнес-правил делает диаграмму потоков работ не полной.

1. Создает новый экземпляр Слияние не предупроцесса после наступле. создающее процесс «И». заранее известно в момент моделирования.2. Исходящий поток направ. активирует исходящий поток. ветвей При разделении активиру. тем активирует исходящий поток. ЛОГИЧЕСКИЙ ОПЕРАТОР «И» Логический оператор «И» разветвляет входной ПУ на несколько параллельных ветвей. 101 .смотрено ния всех ожидаемых событий 5. Виды логических операторов Знак Название «И» «ИЛИ» «Исключающее ИЛИ». которые активируются одновременно (см. Рисунок 5-1).Ждет завершения всех ется одна или более вет.Исходящий поток актитивируются одновременно вируется после завери выполняются паралшения всех входящих лельно. Число выходных ветвей д. Число созданных выходных потоков равно числу ветвей.Ожидает завершения ляется лишь по одной из любой входящей ветисходящих ветвей. ные условия слияния. управляемое данными Комплексное условие «Исключающее ИЛИ» событийное «Исключающее ИЛИ». Создает новый экземпляр Слияние не предупроцесса после наступле.созданных ветвей и завей. Моделирует комплексные Моделирует комплексусловия ветвления. создающий Событийное. Семантика Ветвление Слияние Параллельные потоки ак. событийный.б. ви. Создает новый экземпляр Не предусмотрено процесса после наступления любого из указанных событий.смотрено ния одного из указанных событий.Таблица 5-1.

Рисунок 5-1. Синхронизируя три потока. активируя нужное количество выходных ветвей. то выходной поток не будет сформирован. Такое поведение называется синхронизация выходных потоков. Логический оператор ветвления «И» При слиянии параллельных ветвей оператор ждет завершения всех входящих ветвей и только затем активирует исходящий поток (см. поток. мы подтверждаем. Рисунок 5-2). что все три поручения выполнены. Только после завершения всех параллельных ветвей. Рисунок 5-2. Число входящих ветвей д. Логический оператор слияния «И» Пример (см. При этом. затем передает информацию о событии в соответствующие службы.б. заранее известно в момент моделирования. о котором надо известить три службы. важен факт оповещения. разветвляется. Произошло некоторое событие. но асинхронно друг от друга. Каждая ветвь обрабатывается независимо от остальных. поступивший на ЛО «И». 102 . Если одна из ветвей не завершится. Таким образом. на выходе. потоки соединяются и формируют один исходящий поток. три ветви между ЛО ветвления и слияния «И» выполняются параллельно. В данном примере реакция служб нас не интересует. Вначале оператор регистрирует событие в журнале. Рисунок 5-3) иллюстрирует работу пары ЛО «И» ветвления и слияния.

Если оба Условие1 и Условие2 истинны. этот знак позволяет отличить его от условного перехода. в том случае. Парные логические операторы "И" 5. когда ни один из предложенных маршрутов не будет исполнен. то будет активировано задание «Г».2. Пример (см. исполняемую поумолчанию. В момент исполнения происходит анализ каждого из условий и. при этом возникнет ошибка. остальные условия будут проверены и. 103 . пересекающей стрелку. в зависимости от условия. 7). На этом проверка не прерывается. если ни одно из условий не окажется истинно. Рисунок 5-4) иллюстрирует ветвление «ИЛИ-д». будут созданы параллельные ветви. п. разветвляет входной поток на несколько выходных. Если маршрут по-умолчанию в схему не заложен. Если оба условия ложны. Ее можно попытаться перехватить и обработать как событие (см. то Задачи «А» и «Б» будут выполнены. Для каждой выходной ветви должно быть определено свое отдельное условие. если они так же окажутся истинными.2. На схеме процесса безусловный поток управления изображается с косой черточкой. если для какой-то ветви условие истинно. которое включает анализ данных экземпляра процесса. ЛОГИЧЕСКИЙ ОПЕРАТОР «ИЛИ» УПРАВЛЯЕМЫЙ ДАННЫМИ (OR) Логический оператор «ИЛИ» управляемый данными (ИЛИд). Хорошая практика размещать на схеме ветку безусловного перехода. то на этапе исполнения может возникнуть ситуация.Рисунок 5-3. порождается выходной поток в нужном направлении.

ЛО ветвления и слияния используются в паре. Оператор ветвление «ИЛИ» управляемый данными Семантика слияния ПУ на ЛО «ИЛИ-д» является достаточно сложной. клиент позвонил в страховую компанию и сообщил об аварии. которые необходимы в данном 104 . но при этом он не дожидается ПУ из других ветвей.Рисунок 5-6). Дело в том. знает число ветвей.Условие1 А Условие2 По умолчанию Б В Г Рисунок 5-4. Как понять. Замечание: В реальной схеме ЛО могут употребляться не парно. так что узел. завершения скольких ветвей ожидает ЛО «ИЛИ-д». объединяющий потоки. произошло страховое автомобильное событие. что нарушит логику работы процесса. А Б Г В Рисунок 5-5. Оператор слияние «ИЛИ» управляемый данными Рассмотрим пример (см. при этом ЛО «ИЛИ-д» может неверно «рассчитать» число ожидаемых ПУ. которые были созданы. оператор зарегистрировал событие и вызывает только те службы. что ЛО «ИЛИ-д» ожидает поступления ПУ из некоторых параллельных ветвей и синхронизует их в единый выходной поток (как ЛО «И»). а какие ветви он игнорирует? Обычно.

то происходит переход управления в указанном направлении. невозможна. ЛОГИЧЕСКИЙ ОПЕРАТОР «ИСКЛЮЧАЩЕЕ ИЛИ» УПРАВЛЯЕМЫЙ ДАННЫМИ (XOR) Логический оператор «Исключающее ИЛИ» управляемый данными (Искл-ИЛИ) направляет входной поток строго на одну из нескольких выходных ветвей. Для предотвращения конфликта для всех условных переходов. которое включает анализ данных экземпляра процесса. Парные логические операторы "ИЛИ". то выбирается следующий переход. В отличие от обычного «Искл-ИЛИ» выходные потоки рассматриваются как альтернативные и взаимоисключающие. выполнение м. Обычно. если условие не выполнено. но конкретное количество вызываемых служб зависит от обстоятельств аварии и определяется сотрудником компании по результатам телефонного разговора с клиентом. После того. в зависимости от условия.случае.б. Ситуация. в которой перечислены условия.3. как все вызовы служб будут выполнены. продолжено. 5. устанавливается приоритет. оператор слияния объединит потоки. приоритет определяется последовательностью. Если условие выполнено. определяющий порядок проверки условий.2. Все виды служб заранее известны. Рисунок 5-6. а остальные условия игнорируются и не проверяются. Выбирается первый переход по списку. при которой выполняются сразу несколько из условий. 105 .

то операция «Д» будет выполнена два раза. Это необходимо в том случае.11. переход по умолчанию не определен. Пример (см. Если ни одно из условий не выполняется и. пришедших из входящих ветвей. синхронизации не происходит. так что на выходе появится несколько экземпляров потоков и т.д. никакие условия не проверяются. Когда приходит первый поток управления. он так же породит еще один выходной поток.ч. он проходит на выход без ожидания и синхронизации с другими ветвями. генерируется сигнал об ошибке. пересекающей стрелку. т.ч. Если поступят потоки управления из ветвей «А» и «Б». 106 . На схеме процесса безусловный ПУ изображается с косой черточкой. Когда позднее поступит поток управления из другой ветви.1) Условие 1 Условие 2 По умолчанию Рисунок 5-7. перехвачен и обработан с помощью событий (см. пришедшие из всех входных ветвей. потоков в остальных ветвях еще нет. если ни одно из перечисленных условий не может быть выполнено. при этом. ЛО «Искл-ИЛИ» пропускает на выход потоки. этот знак позволяет отличить его от условного перехода. 6.Для ЛО «Искл-ИЛИ» обязательно должен быть определен один безусловный переход передачи управления. Ветвление «Исключающее ИЛИ» управляемое данными При слиянии ПУ.б. п. Рисунок 5-8) иллюстрирует слияние трех потоков. Он м. т.

Но если операторы применяются не парно. то следует быть внимательным.Рисунок 5-8. что делать с «лишним» экземпляром ПУ. т. что бы исключить неконтролируемое размножение потоков управления. Рисунок 5-9) иллюстрирует парное использование операторов «Искл-ИЛИ». Слияние «Исключающее ИЛИ» Если разветвляющий или объединяющий ЛО «Искл-ИЛИ» идут парой. Если другой тип страхового события. Авто Узнать что произошло Вызвать аварийного комиссара Здоровье Имущество Вызвать доктора Вызвать полицию Рисунок 5-9. то инициируется одна последовательность операторов обработки. то поток управления возникнет только в одной из ветвей. Оператор страховой компании принимает звонки от клиентов. Важно. что действия оператора при разных событиях являются взаимоисключающими.ч. порознь. После завершения любой из ветвей процесс продолжается. Парные операторы «Исключающее ИЛИ» 107 . аналитику не надо заботиться. то выполняются иные действия. если произошла авто авария. Пример (см.

Семантика разветвления в целом соответствует операции «ИЛИ» с той разницей. ЛОГИЧЕСКИЙ ОПЕРАТОР КОМПЛЕКСНОЕ УСЛОВИЕ Логический оператор комплексное условие моделирует сложные. в противном случае возможна ситуация. например. по одному на каждую выходную ветвь. Рисунок 5-10. позволяет указать способ синхронизации и число входных потоков. с комплексным условием. что используется одно комплексное условие. например. Например. Комплексное условие должно определять переход по умолчанию. поступления которых следует ожидать. что выходной 108 . что приведет к ошибке периода исполнения.Если аналитик предполагает. тогда как в «ИЛИ» их несколько. составные условия ветвления и слияния. Оператор ветвления комплексное условие Семантика соединения потоков по комплексному условию. в отличие от обычного «ИЛИ». 5. является ли такое поведение ожидаемым или нет. что ЛО «Искл-ИЛИ» используются не парно. в результате чего на выходе узла могут появится несколько выходных потоков.3. путем использования другого ЛО. он должен принять решение. можно указать. что бы обработать и исключить такую ситуацию. которое умеет обрабатывать нестандартную логику объединяемых потоков. когда ни один переходов не будет выбран. В последнем случае. следует принять меры.

на выходе может быть сгенерировано не один. управляемое результатом события. 6. что стандарт не накладывает специальных ограничений на условие синхронизации.2. так что следует использовать комментарии и аннотации. Во втором случае. п. Оператор слияния комплексное условие 5. что бы пояснить смысл использования оператора. поскольку внешне операторы ветвления и объединения неразличимы.поток появится только после завершения определенного количества входных ветвей. Рисунок 5-11. выходной поток не возникнет никогда. Следует быть внимательным. СОБЫТИЙНЫЙ ОПЕРАТОР «ИСКЛЮЧАЮЩЕЕ ИЛИ» Событийный оператор «Исключающее ИЛИ» (Искл-ИЛИ-с) моделирует решение. так что может случиться. Следует учесть.2). Семантика разветвления тако109 . причем с каждым возможным выходным маршрутом связанно отдельное обрабатывающее событие (см. а несколько потоков управления. В первом случае.4. В качестве возможных событий могут выступать: • Сообщение • Таймер • Условие • Сигнал Событийный оператор Исключающее ИЛИ имеет один вход и требуемое число выходных ветвей. в которых размещено по обрабатывающему событию. что число ожидаемых потоков менее или более чем число реально завершаемых.

сигнала системы или таймера.ва: входной поток разветвляется на указанное число параллельных ветвей. размещаемый в одной из параллельных выходных ветвей. Наступившее событие. где останавливается и ждет наступления первого события. Событийный оператор «исключающее ИЛИ» Пример (см. Рекомендуется принять меры. то будет выбрана вторая ветвь. Например. как предусмотрено логикой событийного оператора исключающее ИЛИ. Ожидание может продолжаться не более одного дня с момента отправки. кроме того. что в комплексном узле вместо события-сообщение можно использовать операцию отправить сообщение. Если первым будет получен ответ от получателя. активирует соответствующую ветвь и одновременно аннулирует все остальные. если ни одно из событий не произойдет. что бы процесс не «завис» в этом узле. «работает» как переход по умолчанию. Пример (см. Рисунок 5-12) иллюстрирует работу оператора «Искл-ИЛИ-с». рисунок Б) показывает. то будет выбрана первая ветвь. выводит процесс из зависания после некоторого периода ожидания. Но следует оговориться: операция не может иметь прикрепленных событий. Операция процесса отправляет оповещение и далее начинается ожидание наступления одного из трех событий: ответа от получателя. таймер. 110 . но если раньше продет сигнал завершить ожидание. нельзя одновременно использовать оба знака на одной диаграмме. каждый из потоков достигает соответствующего перехватывающего события. Рисунок 5-12.

не имеет парного событийного ЛО соединяющего потоки. п. но если возникает необходимость объединить потоки. только несколько выходных. то происходит старт процесса. либо путем обращения в офис продаж. позволяет определить сложное условие запуска процесса на исполнение. 5.7). создающий новый экземпляр процесса. поэтому следует использовать обычный 111 . Число ветвей должно быть известно на этапе моделирования. связанное с наступлением одного из нескольких возможных видов событий. наиболее подходящим будет ЛО «Исключающее ИЛИ». СОБЫТИЙНЫЙ ОПЕРАТОР «ИСКЛЮЧАЮЩЕЕ ИЛИ». остальные ветви аннулируются (см. Событийный оператор «исключающее ИЛИ». Этот ЛО не имеет входного потока. либо по таймеру. (создает новый экземпляр процесса) Событийный оператор «Искл-ИЛИ-проц». старт процесса может произойти либо после получения сообщения от клиента по почте. В каждой выходной ветви размещается одно событие. A B Рисунок 5-13. Если наступает любое из перечисленных событий. Например.5.Семантика объединяющего событийного оператора стандартом не специфицирована. 1316. (СОЗДАЕТ НОВЫЙ ЭКЗЕМПЛЯР ПРОЦЕССА) Событийный оператор Исключающее ИЛИ создающий новый экземпляр процесса (Искл-ИЛИ-проц).

создающий новый экземпляр процесса (И-проц). Пример (см. когда необходимы оба: обращение клиента. Рисунок 5-14. 112 . Событийный оператор «И» (создает экземпляр процесса) Парный узел слияния спецификацией не предусмотрен. а так же специальное разрешение от внешней организации.6. Одного из событий для старта процесса недостаточно. моделирует ситуацию. когда старт процесса определяется наступлением сразу всех событий определенных на схеме в момент моделирования. 5. Рисунок 5-14) иллюстрирует старт процесса.ЛО слияния «Исключающее ИЛИ». СОБЫТИЙНЫЙ ОПЕРАТОР «И» (СОЗДАЕТ НОВЫЙ ЭКЗЕМПЛЯР ПРОЦЕССА) Событийный оператор «И».

в смысле обработчик проблемной ситуации. связанное с невозможностью выполнить задачу или процесс. инициируемое внешним по отношению к процессу агентом. в смысле явления. входной информационный поток отсутствует. Следует различать понятия события. • Событие ошибка. так и вследствие изменения внешней информационной среды. Существует входное воздействие в виде оповещения от клиента. связанное с изменением статуса переменной процесса. произошедшее в определенный момент времени и зафиксированное наблюдателем в оповещении от этого объекта. С каждым событием связана причина его появления и возможное воздействие. выполняемые в случая получения соответствующего оповещения. может происходить как в результате выполнения процесса. Обычно событие противопоставляется процессу. клиент разместил заказ. • Событие состояния. операция обращается к внешнему сервису. связано с окончанием отведенного срока рассмотрения заявки или с наступлением конца календарного периода. Событие. В последнем случае вырабатывается сигнал-ошибка. Например. а последний может быть недоступен. связанное с отсчетом времени. События. Например. • Временное событие.6. клиент отозвал свой заказ. а событие только в определенные моменты. который происходит в интервале времени. Например. например.СОБЫТИЯ Термин «событие» является достаточно общим и используется для обозначения изменения свойств некоторого объекта. Будем различать: • Внешнее событие.б. которое оно оказывает на дальнейший исполнение процесса. 113 . событие м. есть некоторая последовательность действий: операция или подпроцесс. после обработки заявки ее статус станет Обработана. как явление и как программу обработчик проблемной ситуации.

Сообщение: принимает и отправляет сообщения.1. Параллельное составное: нужны все из перечисленных. Компенсация: инициирует или обрабатывает откат транзакции Сигнал: связь между процессами один ко многим. Ссылка: связывает две разные части одного процесса. Генерирующее Обрабатывающее Генерирующее Не прерывающее Простое показывает начало процесса или его окончание. Ошибка: обрабатывает заданный тип ошибок. Составное: срабатывает при наступлении нескольких событ.ТИПЫ СОБЫТИЙ Таблица 6-1. . Отмена: инициирует или обрабатывает отмену транзакции. Таймер: отмечает моменты времени и временные периоды Эскалация: поднимает уровень решения задания Условие: проверяет истинность условия. Моделирование событий в нотации BPMN ПромежуНачальные точные ПодПоток Граничные 114 Непрерывающие Прерывающее Обрабатывающ. Прекращение: немедленно завершает все процессы Прерывающее СОБЫТИЯ Верхнего уровня процесс Конечное генерирующее 6.

2. либо одного из его потоков. промежуточные и конечные.2.Рисунок 6-1). Начальные события могут быть только обрабатывающими. после получения обращения от клиента с просьбой о выдаче кредита порождается экземпляр процесса. Начальное событие инициирует создание нового экземпляра процесса. оно используются для синхронизации ветвей данного процесса или потоков управления разных процессов.6. ГЕНЕРИРУЮЩИЕ И ОБРАБАТЫВАЮЩИЕ Все множество событий в нотации BPMN можно условно разделить на генерирующие и обрабатывающие. посылает оповещение в другой процесс или поток управления. например. Соответственно. Промежуточные события могут быть и обрабаты115 . содержащий заявку данного заявителя. а у завершающего контур выполнен толстой линией (см. события классифицируют на начальные. КЛАССИФИКАЦИЯ СОБЫТИЙ События можно классифицировать по разным признакам. Начальное событие имеет контур. у начального события нет входящего потока управления. у завершающего нет исходящего. ПРОМЕЖУТОЧНЫЕ И КОНЕЧНЫЕ В зависимости от положения в процессе. у промежуточных есть оба потока. Классификация событий по местоположению в процессе 6.1. Обрабатывающее событие принимает это оповещения и инициирует заранее предусмотренную программу обработки. выполненный тонкой линией. у промежуточного двойной контур. Генерирующее событие. Промежуточное событие располагается между начальным и конечным. Рисунок 6-1. НАЧАЛЬНЫЕ. 6. Конечное событие завершает выполнение всего процесса.2.2.

Независимые и прикрепленные события 116 . Рисунок Б) показывает прикрепленное обрабатывающее сообщение. элементы.3. На схеме процессе в нотации BPMN генерирующие события имеют закрашенный сплошным цветом маркер внутри окружности. Завершающие . Прикрепленные события привязываются к соответствующим операциям или подпроцессам и могут влиять на их выполнение.только генерирующими. Рисунок 6-3А) показывает независимые события: отправить сообщение является генерирующим.2. Рисунок 6-3. Пример (см. Рисунок 6-2. они могут быть генерирующими или обрабатывающими. они могут быть только обрабатывающими. НЕЗАВИСИМЫЕ И ПРИКРЕПЛЕННЫЕ Промежуточные события можно классифицировать на независимые и прикрепленные. не закрашенный маркер. расположенный внутри окружности (см. а обрабатывающие события имеют контурный. Независимые события размещаются на схеме как отдельные. Классификация событий по типу обработки 6. а ожидать срабатывания таймера является обрабатывающим. Рисунок 6-2).вающими и генерирующими. Второй пример (см.

если они были. У прерывающих событий контур выполнен сплошной линией. будут утеряны. Второй пример (см. В некоторых случаях. Составное. Эскалация.4. результаты работы. Рисунок 6-4. Что бы указать необходимую полезную нагрузку. Пример (см. который либо выполняет его сам. Классификация событий по влиянию на выполнение 6. когда истекло нормативное время. Когда поток 117 . СОБЫТИЯ И ДАННЫЕ Следующие типы событий могут нести полезную информационную нагрузку: Сообщение. Непрерывающие событие. отведенное на исполнение задания. напротив. Прерывающее событие приостанавливает выполнение операции (в том числе подпроцесса). к которой оно прикреплено. следует использовать механизм ассоциации данных. прерывающие события могут завершать выполнение одного или нескольких потоков или даже всего экземпляра процесса в целом. задание отправляется руководителю.3. Рисунок 6-4А) иллюстрирует ситуацию. ПРЕРЫВАЮЩИЕ И НЕПРЕРЫВАЮЩИЕ Обрабатывающие прикрепленные события можно классифицировать на прерывающие и непрерывающие. Исполнение операции А не останавливается. срабатывает таймер.2. При этом операция А прерывается. либо назначает другого исполнителя. Ошибка.6. Рисунок Б) показывает непрерывающее событие. создает дополнительный поток управления внутри процесса. а у непрерывающих – пунктирной. никак не влияет на выполнение операции или процесса не оказывает. он может позвонить исполнителю и попросить его ускорить работу. однако. Сигнал. руководителю отправляется оповещение.

что бы создать полезную информационную нагрузку. Это отображение можно указать с помощью ассоциации данных. но в обратном порядке осуществляется перенос данных из принятого оповещения обратно в процесс. 6. благодаря которому обрабатывающее событие может среагировать только на оповещение определенного типа. Сигнал имеет имя. Заявка Рисунок 6-5. Если ассоциация отсутствует. не содержащее полезной нагрузки. Они могут передаваться внутри одного процесса. Затем. Сигнал реализует широковещательную рассылку. 118 . Рисунок 6-5) иллюстрирует ассоциацию данных при отправке сигнала. Ассоциация данных в событиях Аналогично.4.достигает генерирующего события. между разными процессами одного проекта. внутренние аргументы используются. генерируемую сообщением. Пример (см. однако не все реализации BPM поддерживают такую возможность2. что сигнал может иметь «полезную» информационную нагрузку. происходит отображение входящего информационного потока на внутренние аргументы элемента событие. то отправляется пустое сообщение. при ко- 2 Некоторые реализации BPMS допускают передавать внутри сигнала полезный набор данных. Стандарт говорит. между разными участниками в разных пулах. СИГНАЛ Сигнал есть механизм координации и связи между разными процессами или ветвями одного процесса.

4. ожидающие наступления определенного события.1. 6. Событие. Сигналы могут использоваться на всех уровнях подпроцессов. Таблица 6-2. первые являются источниками. тогда как ошибки сообщают о неудачах. сигнал можно посылать как внутри одного пула. сигналы работают по принципу широковещательной связи. • Координация исполнения цепочки процессов. Он имеет источник. а вторые получателями оповещения. при этом он оповещает об успешных событиях. Механизм сигналов имеет много общего с механизмом обработки ошибок. Во-вторых. генерирующее сигнал. сигнал получат все слушатели.о. • Обработка ошибок. Во-первых. Графические элементы для работы с сигналами Событие. но не имеет определенных получателей. либо прикрепляется к границе некоторой операции. может размещаться либо в потоке управления. генерирующие и принимающие сигнал. Т. что при передаче информации используется один источник и неограниченное количество приемников. генерирующее сигнал Событие. принимающее сигнал. размещается в потоке управления. ОБРАБОТКА СИГНАЛОВ Рассмотрим особенности обработки сигналов. • Синхронизация исполнения нескольких ветвей или разных процессов. принимающее сигнал Событие. Это означает. так и между несколькими пулами.торой оповещение предназначено для приёма всеми процессами получателями. Таблица 6-2 показывает элементы для работы с сигналами. Связь между одним адресантом и многими адре119 . Различают графические элементы. Сигналы находят применение в следующих ситуациях: • Оповещение участников о завершении этапа обработки.

В качестве примера рассмотрим процесс пакетной обработки (см. где изображен один управляющий процесс и заранее неизвестное число подпроцессов. например. а получатель не знает об источнике или других получателях. В-третьих. Когда нужный сигнал будет получен. Это означает. в другой ветви или в другом процессе точка управления остановилась на событии «принимающем сигнал». после чего управление немедленно передается на следующую задачу. при передаче сигнала нельзя идентифицировать конкретный ЭП. он будет проигнорирован. которые позволяют передавать внутри сигнала полезный набор данных. Если сигнал поступит на «принимающее» событие раньше. выполняющих полезную работу. в которой должно поступить сообщение. так что получатели могут выделить нужное оповещение из нескольких возможных. которые его ожидают и где управление приостановлено до получения соответствующего сигнала3. управление будет передано на следующую задачу процесса. что получатель может среагировать. последнее осуществляет широковещательную рассылку оповещения. загрузку данных из подпроцессов во внешнюю учетную систему. Ранее того. Обработка сигнала осуществляется следующим образом. 120 . на получение сигнала определнного содержания. Рисунок 6-6). что сигнал получат все экземпляры процессов. Если событие «принимающее сигнал» прикреплено к границе некоторой операции. Когда поток управления доходит до события генерирующего сигнал. Процесс источник ничего не знает о процессе получателе и об их количестве. Загрузка осуществляется однократно. чем туда прибудет поток управления. Сигнал имеет имя. где ожидает получения соответствующего оповещения. допускают.сатами обеспечивается за счет одинакового именования источника (генерирующего события) и приемника сигнала. по сигналу управляющего процесса 3 Те реализации BPMS . то поступление сигнала инициирует новый поток управления.

но сигналы могут быть отправлены или получены из внешних ИТ систем. они не только извещают о факте наступления события. Адресация получателя сообщения может осуществляться либо явно. Пакетная обработка с использованием сигналов Спецификация BPMN этого явно не определяет. с использованием графического элемента поток сообщений. с использованием механизма корреляции (см. образующих диалоги. либо неявно. позволяющему приложениям. создавать и посылать оповещения в BPMS.6).5. получать и читать обратные послания. 6. 6. но так же позволяют передавать некоторый набор данных.Подпроцес Сигнал1 Загрузка данных Сигнал1 Загрузка данных Сигнал1 Загрузка данных Сигнал1 Рисунок 6-6. 121 .5. для этого служат специальные адаптеры к промежуточному ПО для рассылки сигналов. п. СООБЩЕНИЯ Сообщения реализуют адресную передачу оповещения от источника к получателю.

посылать. Сообщения образуют информационные потоки между отправителем и получателем. а не его содержимое. что бы показать порядок исполнения операций процесса. оно несет информационное наполнение и всегда пересылаются адресно между отправителем и получателем. Рисунок 6-7). Потоки сообщений Не следует путать потоки сообщений и потоки управления. Спецификация BPMN этого явно не определяет. возможно. позволяющему приложениям.б. получать и читать сообщения.1. Для сообщения можно специфицировать его внутреннюю информационную структуру. но сообщения могут быть отправлены или получены из внешних ИТ систем. но она не м.6. при этом следует помнить. Рисунок 6-7. параллельно друг другу. что бы показать об122 .5. Дополнительно на стрелке можно поместить символ конверта с подписью. визуально отображена на схеме процесса. которые изображается пунктирными стрелками с небольшой полой окружностью у отправителя сообщения и полым треугольным указателем у получателя (см. Для этого можно использовать потоки сообщений. создавать. Сообщение есть механизм межпроцессной коммуникации. что мы показываем только заголовок конверта сообщения. для этого служат специальные адаптеры к Java Message Service (JMS) —промежуточному ПО для рассылки сообщений. выполненным на платформе J2EE. ПОТОКИ СООБЩЕНИЙ Процессы могут выполняться длительное время. Первые предназначены. так что может потребоваться синхронизация их действий. вторые служат.

сроки и поставку. и ответные сообщения. ДИАЛОГИ Потоки сообщений могут образовывать диалог между участниками.2. Рисунок 6-9). иерархически вложенными. Рисунок 6-8Б). показывают обмен только между разными процессами. источник и получатель не могут принадлежать одному процессу. является номер контракта. касающиеся общего предмета переговоров. Поставщик и Покупатель ведут переговоры о нескольких контрактах. Рассмотрим пример. обсуждать финансовые условия. имеет заполнение серого цвета (см.о. касательно одной сделки образуют диалог и можно предположить.мен сообщениями.б. разные контракты. оно не имеет заполнения (см. по которому стороны идентифицируют этот диалог. иными словами. 6.5. все переговоры. что ключом. Внутри диалога можно выделить поддиалоги. Рисунок 6-8А). у них будет другой ключ (см. сгруппировать сообщения. а ключи составными. поэтому возникает желание. Инициирующее диалог и ответное сообщения Два участника обмена сообщениями могут общаться по разным поводам. Диалог есть группа сообщений.. Первые целиком расположены внутри одного пула. 123 . вторые. например. диалоги м. объединяемая общей тематикой. А) Б) Рисунок 6-8. при этом различают сообщения инициировавшее диалог. касающиеся разных аспектов условий. напротив. Т.

Потоки сообщений на диаграммах: Оркестровки. Взаимодействия 124 . Хореографии. Взаимодействия и Хореографии (см. Рисунок 6-10) Рисунок 6-10. Диалог участников Потоки сообщений используются на диаграммах: Оркестровки.Рисунок 6-9.

что согласно спецификации BPMN 2. последняя имеет соответствующий значок окружности в верхнем левом углу. так и одноименную задачу. принимающую сообщения. Получение сообщения может инициировать запуск процесса на исполнение. Одноименные элементы операция и событие полностью взаимозаменяемы. Например. то на разных схемах одно и то же действие может отображаться по-разному.0 нельзя пересылать сообщения внутри одного пула.6.5. Одно из возможных решений вопроса заключается в использовании повторно используемых внешних подпроцессов вместо вложенных. вложенный подпроцесс является частью пула и поэтому не может обмениваться сообщениями с родительским процессом. ОТПРАВКА И ПОЛУЧЕНИЕ СООБЩЕНИЙ Обмен сообщениями осуществляется с использованием операций: отправить сообщение и принять сообщение или одноименных событий. Более того. Это накладывает ряд ограничений на моделирование оркестровки. Для этого стандарт разрешает использование как событие. Следует учитывать. как операция. а в другом. 125 Получить . на разных уровнях детализации процесса в одном случае элемент может изображаться как событие. Операция и событие для отправки и получения сообщения Отправить Операция Событие Стартовать экземпляр процесса. Таблица 6-3 изображает Операция и событие для отправки и получения сообщения. Таблица 6-3.3. если диаграмма приватного процесса поддерживает диаграмму публичного процесса. Например.

после чего управление сразу передается на следующую операцию. так что сразу по прибытии точки управления оно генерирует посылку. принимающая сообщение. отправляющее сообщение всегда размещается в потоке управления. генерирующее событие отправки сообщения. может размещаться только в потоке управления. покупатель начинается диалог по уточнению условий. пока не будет получено соответствующее сообщение.Пример (см. После того. при этом оно ведет себя точно так же как и аналогичная операция. то новый поток 126 . покупатель даст ответ на предложение. После прибытия в нее точки управления исполнение приостанавливается до тех пор. Если обработчик события является прерывающим. Поставщик Прдложение Вопрос Ответ Отправить запрос Принять ответ Результат Обработать запрос Рисунок 6-11. После этого. Обмен сообщениями между двумя участниками 6. то в случае поступление сигнала создаст новый поток управления. Событие. Рисунок 6-11) иллюстрирует обмен сообщениями между покупателем и поставщиком в ходе приобретения требуемого товара. Операция. Процесс начинается с получения сообщения от поставщика. Для этого используется промежуточное.4. Если оно прикреплено к границе операции (подпроцесса). может размещаться в потоке управления.5. как поставщик предоставит всю недостающую информацию. принимающее сообщение. СЕМАНТИКА ОПРАВКИ И ПОЛУЧЕНИЯ СООБЩЕНИЙ Событие или операция.

Иногда экземпляр получатель можно указать явно. Явная адресация получателя сообщения 6. то новый поток управления выполняется параллельно с основным потоком. Пример (см. Это приглашение инициирует требуемое число экземпляров процессов. Каждый поставщик возвращает подтверждение в процесс получатель. исполняемый в цикле.6. 6. КОРЕЛЛЯЦИЯ . Рисунок 6-12. то есть может быть только один адресант и один адресат.5. ЯВНАЯ АДРЕСАЦИЯ ПОЛУЧАТЕЛЯ СООБЩЕНИЯ Поставщик Покупатель При пересылке информационных сообщений используется принцип «точка-точка».управления выполняется вместо основного потока. используя потоки сообщений.5. В этих случаях 127 . Адресатом является нужный экземпляр процесса. Если обработчик события является непрерывающим. после чего исполнение завершается. который инициирует требуемое число приглашений.НЕЯВНАЯ АДРЕСАЦИЯ ПОЛУЧАТЕЛЯ СООБЩЕНИЯ На схеме процесса не всегда удается явно указать получателя сообщения при помощи знака поток сообщений. для каждого поставщика в отдельности.5. Рисунок 6-12) показывает подпроцесс.

он может содержать этот же ключ. последняя должна принимать уникальные не повторяющиеся значения.н. которая обрабатывается в процессе. Для идентификации получателя используется т. сложносоставным. который помогает увязать отдельные события в диалоги. а вторая. Напротив. которые позволят однозначно идентифицировать экземпляр процесса. Этот ключ автоматически добавляется к сообщению. Таким образом. процессы могут обмениваться потоками сообщений по разным темам. Корреляция есть механизм. как уже указывалось. а диалоги привязать к парам процессов. позволяет указать адресата сообщения. Непременное условие. необходимо уметь точно указать процесс получатель сообщения. называемая корелляция. Например. отправитель может сопоставить полученный ответ со своим запросом. 128 . Когда Сообщение отправляется от адресанта (отправителя) к адресату (получателю). который позволяет подменить индивидуальный идентификатор процесса на контекстную информацию. корелляционный ключ. который не имеет определенного значения для бизнес аналитика. так что разные части ключа могут использоваться по-отдельности. значение какой-либо переменной процесса.для адресации получателя сообщения используется неявная адресация. желательно разделить эти диалоги. фамилия заказчика не позволяет идентифицировать экземпляр процесса. Когда поступает ответ от получателя. Однако разработчик процесса на стадии моделирования не знает заранее идентифицирующий номер получателя. Как мы помним. В этой ситуации принято использовать механизм корреляции. Одна часть ключа. например. Он м. При отправке сообщения системой автоматически генерируется корреляционный ключ. переменные «номер заказа» или «номер клиента» могут однозначно идентифицировать экземпляр процесса. позволяет связать сообщение с соответствующим диалогом. инициирующему диалог. Обычно для этого используется внутренний идентификатор процесса получателя. поскольку она может повторяться.б.

доступны глобально известные переменные. НАЧАЛЬНЫЕ СОБЫТИЯ Таблица 6-4 содержит краткий обзор начальных событий. Не типизированное событие. который д.б. Создает экземпляр процесса в назначенное время. Обзор начальных событий Сообщение: Таймер Эскалация Условие Ошибка.6. 129 Не прерывающее Простое Подпроцесс Прерывающее Верхнего уровня СОБЫТИЯ . исполнен сотрудником с высоким уровнем полномочий Нельзя использовать данные экземпляра процесса. либо в цикле.6. Составное. Компенсация Инициирует или обрабатывает откат транзакции Сигнал: Создает экземпляр процесса после получения сигнала.. Для процесса определено несколько начальных событий. показывает старт процесса верхнего уровня Создает экземпляр процесса после получения сообщения из другого процесса. Таблица 6-4. но для создания ЭП необходимо и достаточно совершения только одного Параллельное Для создания ЭП должны наступит несоставное сколько событий. Создает процесс. по расписанию. поскольку он еще не создан. Обрабатывает заданный тип ошибок.

если произойдут сразу оба события: неясно. Рисунок 6-14). Рисунок 6-13. Начальное событие является опциональным и в некоторых ситуациях может опускаться.Начальное событие используется для описания процедуры создания экземпляра процесса. Спецификация допускает изображать на диаграмме несколько точек старта одного процесса. Второй и третий столбцы показывают события. что случится. Рисунок 6-13) показывает подпроцесс без стартового события.7). применяемые для старта процесса верхнего уровня. 130 . обе вложенные операции стартуют одновременно и выполняются параллельно. а вместо этого применять событийные операторы «ИЛИ» или «И» (см. обрабатывать его в рамках ранее запущенного экземпляра или следует породить еще один экземпляр процесса. 6. Пример (см. нужно ли игнорировать второе событие. Наступление любого из этих событий порождает экземпляр процесса. связывая каждую с отдельным событием (см. Подпроцесс без стартового события. Первый столбец показывает события. Поэтому спецификация BPMN не рекомендует использовать много точек старта. Однако спецификация не указывает. далее п. применяемые для старта событийного подпроцесса.

Процесс с несколькими точками старта Исключением является подпроцесс. Например. Пример (см. Спецификация предлагает несколько способов решения этой задачи. причем все они являются взаимоисключающими. Если хотя бы одно из них есть простое стартовое событие. Рисунок 6-16) показывает такой подпроцесс «двойного назначения». Событийный логический оператор «Исключающее ИЛИ» (см. СОСТАВНОЕ ВЗАИМОИСКЛЮЧАЮЩЕЕ СТАРТОВОЕ СОБЫТИЕ Представим себе.б. как глобальный и может быть вызван извне с помощью вызывающей операции. важно. связан с заполнением клиентом формы на веб сайте компании. Рисунок 6-16А). позволяет добиться того же 131 . Процесс «двойного назначения» 6. Рассмотрим типовые сценарии. Рисунок 6-15. который в зависимости от обстоятельств может выступать либо как процесс верхнего уровня. Составное взаимоисключающее стартовое событие используется для запуска процесса от первого из перечисленных на схеме событий (см.Рисунок 6-14. что эти события являются взаимоисключающими. Рисунок 6-16Б). этот процесс может рассматриваться.7. либо с его звонком в офис. либо как повторно используемый глобальный. что у процесса есть несколько точек старта. старт процесса продажи м.

если для создания ЭП должно произойти все из перечисленных начальных событий. когда наступит последнее из ожидаемых событий.Рисунок 6-16. Рисунок 6-17). СОСТАВНОЕ ПАРАЛЛЕЛЬНОЕ СТАРТОВОЕ СОБЫТИЕ Синхронный старт используется в том случае.8. Рассмотрим пример (см. иллюстрирующий создание процесса с использованием составного параллельного стартового события. позволяя перечислить все нужные для запуска события. Пример взаимоисключающего старта 6. Сразу же после старта процесс будет ожидать наступления всех из перечисленных промежуточных событий. Рисунок 6-17. составное стартовое событие 132 . Составное параллельное стартовое событие реализует логику «И» для нескольких событий. определенных на схеме. Старт произойдет.

• ошибка. СТАРТ СОБЫТИЙНОГО ПОДПРОЦЕССА Событийный подпроцесс (см. Непрерывающее событие Б A Эскалация Событийный подпроцесс.9. Событийный подпроцесс для события эскалация 133 . подпроцесс будет исполняться параллельно с вызывающим. а вторые нет. • сигнал. • составное параллельное стартовое событие. • компенсация. 3. Первые останавливают исполнение родительского процесса. Следует обратить внимание. • условное. что и основной процесс. 6. • эскалация. Поскольку инициирующее событие является непрерывающим. Пример (см.6) может иметь только одно стартовое событие следующих типов: • сообщение. • составное стартовое событие.2).б. Рисунок 6-18) иллюстрирует запуск событийного подпроцесса в случае наступления события-эскалация. • таймер.6. что стартовое событие м. прерывающим и непрерывающим (см.5. Обрабатывающий событийный подпроцесс находится на том же уровне иерархии. Исполняется оновременно с основным В Эскалация Рисунок 6-18.

ЗАВЕРШАЮЩИЕ СОБЫТИЯ В спецификации BPMN определено 9 разных видов завершающих событий. оно останавливает работу операции. Обзор завершающих событий Наименование Простое Сообщение Эскалация Ошибка Отмена Компенсация Сигнал Составное Прекращение Описание Не обладает никакой дополнительной семантикой. остальные потоки продолжают выполнение. Оповещение имеет уникальное имя т. Таблица 6-5 показывает свойства завершающих событий. Все потоки. Процесс завершается без вызова компенсации или любого другого перехватчика событий. что процесс завершился с ошибкой. Напротив. Используется в транзакционном процессе.Следует помнить. что событие-ошибка м. в том числе изображенные на разных уровнях и в разных пулах. включая все дочерние параллельные.10. Таблица 6-5.д. Показывает. событие-компенсация является не прерывающим. все они являются генерирующими. Сигнал принимают все процессы. только прерывающим. например рассылкой сообщений разным адресатам и т. 6. 134 Знак . Завершение процесса связано с генерацией нескольких различных событий. должны быть немедленно завершены. Текущий поток завершается со статусом эскалация. Показывает. Отправляет сигнал в момент завершения процесса. Отправляет сообщение из завершаемого процесса в другой процесс. а данные возращены в исходное состояние.ч. обработчик реагирует только на определенный тип ошибки.б. в которой произошел сбой. кроме как завершение выполнения потока. что все завершенные операции на данном уровне подпроцесса должны быть отменены. обозначает отмену транзакции.

Завершающее событие может иметь несколько входных потоков управления. то это не остановит исполнение нижней ветви. Простое завершающее событие 6.10. когда будут окончены обе ветви.1.10. 1. Если выполнение верхней ветви завершится первой. циклические и многопоточные операции.13. процесс считается не завершенным. Завершающее событие-прекращение останавливает исполнение всех существующих потоков управления. Б Завершающее событие 1 А Г Д Завершающее событие 2 Рисунок 6-19. п. До тех пор. Если модель допускает размножение потоков управления (см. то завершение одного из них не завершает работы остальных. но не может иметь ни одного выходного. изображающий процесс. Рисунок 6-19). которые существуют на том же уровне.6. ПРОСТОЕ ЗАВЕРШАЮЩЕЕ СОБЫТИЕ Простое завершающее событие позволяет отобразить на схеме процесса место завершается исполнение одного/нескольких потоков управления. СОБЫТИЕ-ПРЕКРАЩЕНИЕ Возможны ситуации.2). Экземпляр процесса считается завершенным только тогда. включая всех вложенные подпроцессы. у каждой из них свое завершающее событие. 135 . Рассмотрим пример (см. пока хотя бы один поток еще выполняется. когда будут завершены все возникшие в нем потоки управления.2. который делится на две ветви. когда завершение одной ветви должно прекратить исполнение других существующих потоков управления. Процесс закончится только тогда.

ЗАВЕРШАЮЩЕЕ СОБЫТИЕ-СООБЩЕНИЕ Завершающее событие-сообщение используется для запуска следующего процесса в цепочке. Но если в ходе проверки оплаты обнаружится. Если операция «Проверить оплату» будет нормально завершена.Рассмотрим пример (см. Главный процесс Проверить оплату Обработать заказ Обработать заказ Запустить исполнение Проверить наличие Рисунок 6-20. а затем в цикле исполняет второй подпроцесс «Обработать заказ». что сквозной процесс разделен на цепочку взаимодействующих подпроцессов. иллюстрирующий завершение процесса с помощью простого события и событияпрекращение. событие-прекращение остановит работу запускаемого в цикле вложенного подпроцесса обработать заказ. что средства не поступили. Представим себе. вложенные подпроцессы. Рисунок 6-20).10. будут завершены: параллельные ветви. Главный процесс инициирует событийный подпроцесс. как «Обработка заказа» будет выполнена. выполнение всего процесса будет полностью остановлено. При этом. Событие-прекращение 6.3. Таким образом. Один их эффективных способов связывания отдельных 136 . то главный процесс завершится после того. циклические и многопоточные операции.

11. Отмена 4. 2. Учитывая. Ошибка. УСТАНАВЛИВАЮЩИЕ СТАТУС ЗАВЕРШЕНИЯ ПОДПРОЦЕССА В программировании. СОБЫТИЯ. Во-первых. когда одна программа вызывает подпрограмму. Во-вторых.подпроцессов заключается в отправке сообщения. чем завершается вызываемая процедура. 137 . инициирующего следующий процесс. например. Для этого последняя возвращает в вызывающую статус своего завершения. она хочет знать. Рисунок 6-21. 3. завершающее генерирующее событие-сообщение связывается диалогом с обрабатывающим стартовым событием-сообщением. присвоив какой либо пользовательской переменной заранее оговоренное значение. Эскалация. можно возвратить статус. Компенсация . При моделировании бизнес-процессов есть два способа передать статус завершения. воспользовавшись одним из нижеперечисленных завершающих событий: 1. Завершающее событие-сообщение 6. можно установить пользовательский статус завершения явно.о. Т. удается передать на вход следующего всю нужную информацию. что сообщения несут полезную информационную нагрузку.

б. то происходит нормальное завершение. 6. Завершающее событие-эскалация 138 . таким образом. Если сотрудник в состоянии принять решение. когда работа не м. СОБЫТИЕ-ОШИБКА Событие-ошибка используется. устанавливающие статус завершения используются только совместно с соответствующими обрабатывающими граничными событиями (см. он выбирает продолжение.11. Оповещение имеет уникальное имя т. Эскалация решения на следующий уровень принятия решения Принять решение Нормальное завершение Рисунок 6-23. СОБЫТИЕ-ЭСКАЛАЦИЯ Событие-эскалация отмечает ситуацию. по имени. Рисунок 6-22.б. связанное с эскалацией. поскольку у сотрудника отсутствуют полномочия. в процессе м. что бы передать в вызывающий процесс информацию о произошедшей ошибке. поручена сотруднику с большим лимитом ответственности.14).1.2. Пример (см. 6. несколько оконечных событий-ошибка. Завершающее событие-ошибка 6. Работа д.11. обработчик среагирует только на ошибки определенного типа. выполнена.События.ч. Рисунок 6-23) иллюстрирует операцию. связанную с приятием решения. Если же не хватает полномочий. необходимые для ее выполнения. Каждое событие имеет уникальное имя.б. их всегда можно различить.

что бы показать. исполнение транзакционного процесса завершается. Главный процесс является транзакционным. Рисунок 6-24) иллюстрирует завершение процесса с помощью события-отмена. Пример завершение процесса 139 . Оно всегда связано с некоторой подпрограммой отката транзакций. В последнем случае будут последовательно. СОБЫТИЕ-ОТМЕНА Событие-отмена используется только внутри транзакционного процесса.11. об этом свидетельствует двойная линия границы. входящих в состав процесса. Первая – простое завершение. В этом примере все завершающие события являются взаимоисключающими. Рисунок 6-24.3. которая либо определена пользователем явно. либо выполняет набор действий по умолчанию. Вторая точка завершения это событие-отмена. но в обратном порядке вызываться программы отката данных для каждой из операций. что транзакция должна была отменена. управление передается на операцию «Оповестить клиента». Пример (см. Посылает оповещение прикрепленному промежуточному событию-отмене. Событие-отмена завешает все потоки внутри исполняющейся транзакции. после этого управление возвращается в вызывающий процесс.6. Процесс имеет две точки завершения. соответствует нормальному сценарию.

Если операция завершится ошибкой.11. а данные возращены в исходное состояние. Существует два способа использования промежуточных событий: 1 Обработчик события размещается в потоке управления процесса и может использоваться для целей генерации 140 .4. оно используются для обработки исключительных ситуаций и для синхронизации отдельных ветвей данного процесса или разных процессов. • Отображение дополнительных операций. что все завершенные операции на данном уровне подпроцесса должны быть отменены. Пример (см. СОБЫТИЕ-КОМПЕНСАЦИЯ Событие-компенсация показывает. Оно выработает оповещение.) изображает автоматическую операцию. откатывающих данные для незавершенных транзакций. Рисунок 6-25. • Отображения временных задержек при выполнении процесса. Промежуточное событие может использоваться для моделирования следующих ситуаций: • Получения входящих или отправки исходящих сообщений внутри процесса. помеченных знаком компенсации. Завершающее событие-компенсация 6.12. то управление будет передано на завершающее событие-компенсация. которое вызовет откат данных в других операциях.6. ПРОМЕЖУТОЧНЫЕ СОБЫТИЯ Промежуточное событие располагается на диаграмме процесса между начальным и конечным событиями.

После этого поток управления покидает элемент обработки события. 2 Обработчик события прикрепляется к границе операции и может использоваться только для обработки события.) после чего поток управления немедленно покидает текущий элемент и продолжает движение далее по процессу.д. сигнал и т. если событие произойдет до того. исполнение останавливается до тех пор. размещаемых в потоке. то немедленно происходит обработка этого событие (отправляется сообщение. 6. оно не может создать новый экземпляр процесса или прекратить выполнение текущего. пока не произойдет соответствующее событие (например. В большинстве случаев такое событие не будет обработано и будет потеряно.1. Таблица 6-6 дает краткую характеристику различным обработчикам событий. ПРОМЕЖУТОЧНЫЕ СОБЫТИЯ. РАЗМЕЩАЕМЫЕ В ПОТОКЕ УПРАВЛЕНИЯ ПРОЦЕССА Когда поток управления достигает генерирующего события размещенного в потоке. Промежуточное событие влияет на выполнение только текущего потока процесса. Поведение генерирующих и обрабатывающих промежуточных событий. различается.или обработки события. что произойдет.12. как поток управления прибудет в обрабатывающее событие. 141 . которые могут размещаться непосредственно в потоке управления процесса. сигнал и т.). Когда поток управления достигает знака обрабатывающего события.д. Спецификация не указывает явно. получено сообщение.

Используется для обмена сообщениями между процессами. может быть только генерирующим. Обрабатывает заданный тип ошибок. размещаемые в потоке управления Поток . Отмена. работает по принципу «один адресат . Инициирует отмену транзакции Компенсация Используется для отката данных. Используется для отображения статуса исполнения. Улкчшает читаемость схемы процесса. Обработчики событий. которые не могут быть визуализированы на схеме процесса. Связывает две точки процесса и подразумевает неявную передачу управления. Может быть только генерирующим Широковещательная связь между процессами и подпроцессами на разных уровнях. Таймер может только обрабатывать событие.один адресант». в том числе составным и содержать в себе другие обработчики событий. но не инициировать его.Простое ОПИСАНИЕ Ошибка Обработчик отсутствует. Обработка всего множества параллельных событий Сообщение. Условие может быть любым. Обработка одного события из множества или генерация всех определенных событии. Изменяет уровень принятия решения. Приостанавливает выполнение экземпляра процесса. Таймер Эскалация Условное Ссылка Сигнал Составное Параллельное составное 142 Обрабатывающее СОБЫТИЯ Генерирующее Таблица 6-6.

События-сообщения.2. Рисунок 6-26) показывает простое промежуточное событие. два процесса синхронизируют свою работу. ПРОСТОЕ ПРОМЕЖУТОЧНОЕ СОБЫТИЕ Простое промежуточное событие используется. но не позволяет изобразить состояние объекта процесса. Пример (см. размещаемое в потоке. размещаемое в потоке 6. а второе ждет получения ответа. Рисунок 6-26. что бы отобразить на схеме процесса этап обработки некоторого объекта. Этап связан с получением объектом определенного статуса. Оно отображает статус исполнения процесса. Простое промежуточное событие. Рисунок 6-27. они отображаются подписями к переходам управления. размещенные в потоке.6. Первое отправляет сообщение. Пример (см.12.3. Таким образом. ПРОМЕЖУТОЧНОЕ СОБЫТИЕ ДЛЯ РАБОТЫ С СООБЩЕНИЯМИ Промежуточные событие отправить и принять сообщения используются в основном для синхронизации двух процессов. Рисунок 6-27) показывает два промежуточных события для работы с сообщениями.12. размещенные в потоке 143 .

Рисунок 6-29. Рисунок Б) показывает логический оператор «исключающее ИЛИ». Событиеусловие задержит исполнение до тех пор. размещенного в потоке.5. Различие между двумя вариантами в том. Промежуточное событие-таймер 6. когда тока управления достигнет узла. Пример (см. СОБЫТИЕ-ТАЙМЕР Промежуточное событие-таймер позволяет определить задержку исполнения. Рисунок 6-26) иллюстрирует использование промежуточного события-таймер. пока заданное условие не будет выполнено.6.4. что логический оператор проверяется один раз. Промежуточное событие-условие 144 .12. Пример (см. Пример (см. размещенные в потоке.12. Задержать исполнение на предустановленной время Рисунок 6-28. Рисунок 6-29А) иллюстрирует использование промежуточного события-условие. который выполняет роль элемента задержки. ПРОМЕЖУТОЧНОЕ СОБЫТИЕ-УСЛОВИЕ Промежуточное событие-условие используется для маршрутизации потока управления.

ПРОМЕЖУТОЧНОЕ СОСТАВНОЕ СОБЫТИЕ Промежуточное составное событие обрабатывает первое из списка ожидаемых событий. Рисунок 6-30) изображает процесс. Пример (см.12. Исполнение будет продолжено. остальные игнорируются. СОБЫТИЕ-ССЫЛКА Событие-ссылка является единственным графическим элементом в данной категории. если обратится клиент.12. Рисунок 6-30) изображает процесс. Пример (см.6. который приостановлен до наступления любого их двух ожидаемых событий. Рисунок 6-31. ПРОМЕЖУТОЧНОЕ СОСТАВНОЕ ПАРАЛЛЕЛЬНОЕ СОБЫТИЕ Промежуточное составное параллельное событие срабатывает при наступлении всех событий из списка ожидаемых. Промежуточное событие-условие 6. Обратился клиент Составное событие Наступил срок Рисунок 6-30. Промежуточное составное параллельное событие 6. которое не отображает какое-либо явление или объ145 .12.7.6. который приостановлен до срабатывания обоих ожидаемых событий. либо закончится срок ожидания. Исполнение будет продолжено.8. либо наступит крайний срок. если обратится клиент.

Дальнейшее выполнение операции. допускается несколько разных ссылок на одной схеме.екты внешнего мира.13. Рисунок 6-32). 146 . Наступление события изменяет нормальный сценарий исполнения. но используется в случае. возникает дополнительный поток управления. 6.ч. расположенными далеко друг от друга на диаграмме процесса. По сути. на который указывает обработчик события. Оно используется для передачи управления между двумя операциями на диаграмме процесса. После окончания дополнительного потока управление м. затруднительно. Событие ссылка имеет имя. бывают только обрабатывающими. прикрепляемые к границам операций. когда изобразить переход.приостанавливает ее исполнение.б. СОБЫТИЯ. Таблица 6-7). к которой прикреплено событие. События-ссылки являются промежуточными и используются только для соединения частей одного процесса. Рисунок 6-32. зависит от типа прикрепленного события: прерывающее . Рассмотрим более подробно прикрепленные событие (см. Событие-ссылка. расположенных внутри одного пула. т. оно является аналогом стрелки потока управления. возвращено в прерванную операцию. ПРИКРЕПЛЯЕМЫЕ К ГРАНИЦАМ ОПЕРАЦИЙ События. Их нельзя применять для отображения межпроцессного взаимодействия (см. а непрерывающее продолжает её работу. по каким-то причинам.

при этом достаточно. к которой прикреплен обработчик. оно выполняет задачу ретрансляции факта инцидента. чтобы произошли все событие из списка. Отличается от Ошибки более широким диапазоном использования.Таблица 6-7. Условие может быть составным и содержать в себе обработчики событий. Таймер Эскалация Условие Ошибка Отмена Сигнал Составное Параллельное составное Непрерывающие СОБЫТИЯ Прерывающее Обрабатывающ. Изменяет уровень принятия решения. прикрепляемые к операции Описание Сообщение Срабатывает при получении сообщения. 147 . Используется в транзакционных процессах.14. чтобы произошло хотя бы одно событие из списка. Перехватывает именованные и безымянные ошибки. Срабатывает один раз в определенный момент времени либо несколько раз по расписанию. Прерывает выполнение операции. Перехватывает сложные составные события. всегда прерывает выполнение всех операций. которые не могут быть визуализированы на схеме процесса. РЕТРАНСЛЯЦИЯ СОБЫТИЯ Рассмотрим более подробно семантику исполнения события. Принимает широковещательное оповещение. необходимо. События. может быть только генерирующим. Перехватывает сложные составные события. произошедшего внутри операции наружу в процесс. 6. прикрепленного к границе операции.

одна ветка заканчивается событием-завершение. Допустим операция автоматическая и вызывает веб-сервис.Ретрансляция ошибки из операции Пример (см. что происходит внутри операции. Ретрансляция события 148 . Это событие «слушает». что бы обработать ее средствами BPMS. прикрепленное событие сможет ретранслировать эту ошибку в процесс. Прикрепленное к границе подпроцесса обрабатывающее событие-ошибка перехватывает внутреннюю ошибку и передает ее на обработку вне подпроцесса.Пример (см. Рисунок 6-33.) показывает операцию с прикрепленным к границе событием-ошибка. Рисунок 6-34. а вторая – генерирующим событием-ошибка. Рисунок 6-34 Рисунок 6-34) показывает процесс с двумя вариантами завершения. Если последний завершится ошибкой. Рисунок 6-33.

В этом случае генерируется дополнительный поток управления. Прикрепленное непрерывающее обрабатывающее граничное событие не останавливает выполнение соответствующей операции. новый поток можно либо завершить и тем самым остановить процесс. прерывающее событие ведет себя как ЛО «исключающее ИЛИ». ПРЕРЫВАЮЩЕЕ СОБЫТИЕ-ТАЙМЕР Прикрепленное прерывающее граничное событие-таймер используется. В этот момент управление передается другой операции. которые были созданы обработчиком не прерывающего события. Рассмотрим данный вопрос более подробно. направленный операцию обработать таймаут. Необходимо следить за логикой выполнения потоков.о. Затем оба потока объединяются на логическом операторе («исключающее ИЛИ»). Такие потоки могут либо сливаться с основным маршрутом. которая связана с обработчиком безусловным переходом. 149 . что бы задать нормативную длительность выполнения операции. который выполняется параллельно с основным маршрутом процесса.1.14. Рисунок 6-35). Таймер срабатывает и создает новый поток управления. происходит передача управления на поток обработки исключительной ситуации. Прикрепленное прерывающее обрабатывающее граничное событие.6. вызывает аварийное прекращение соответствующей операции. После выполнения всех действий по ликвидации последствий аварии. Либо можно вернуть управление в прерванную операцию. управление в нег больше не возвращается. Истек отведенный срок исполнения задания.14. При этом основной поток прерывается. ОБРАБОТКА ПРЕРЫВАЮЩИХ И НЕПРЕРЫВАЮЩИХ СОБЫТИЙ Семантика выполнения прерывающих и не прерывающих обрабатывающих граничных событий сильно различается между собой.2. 6. либо завершаться отдельно. Рассмотрим пример использования прерывающего события-таймер (см. Т..

14. В случае непрерывающего события следует следить. но не прекращает основной. что бы оповестить других участников об истечении нормативной длительности выполнения операции. Рисунок 6-37) показывает ситуацию. 150 . Непрерывающее событие-таймер (см. что бы дополнительный альтернативный поток был явно завершен в нужное время. НЕПРЕРЫВАЮЩЕЕ СОБЫТИЕ-ТАЙМЕР Прикрепленное непрерывающее граничное событие-таймер используется. при этом.3. Значок таймера в левом верхнем углу последнего указывает. Обработка непрерывающего прикрепленного событиятаймер Третий пример (см. когда обработка таймаута осуществляется в событийном вложенном подпроцессе. Например. работа исполнителя не останавливается. что стартовое событие обрабатывает оповещение от таймера. Рисунок 6-36) инициирует альтернативный поток. Обработка прерывающего прикрепленного события 6. необходимо информировать руководителя о задержке исполнения. Рисунок 6-36.Рисунок 6-35.

это происходит за счет отдельного завершающего события. Как правило.Обработать таймаут Рисунок 6-37. После завершения обработки данный поток необходимо завершить. Непрерывающее прикрепленное событие-таймер Следует учитывать. 151 . что непрерывающие прикрепленные обработчики событий в момент своего выполнения порождают новый поток обработки.

Автоматическая операция обращается к внешнему сервису. под исключительной ситуацией в бизнес-процессе понимают возникшую ошибку или бизнес-исключение. предназначенный для описания реакции системы на исключения и ошибки выполнения. При этом нормальный ход выполнения процесса прерывается. которые делают дальнейшее исполнение невозможным или бессмысленным. когда нормальный ход выполнения процесса необходимо временно приостановить. • Во внешней среде: 152 .1. При выполнении интерактивной операции не удается подобрать исполнителя. КЛАССИФИКАЦИЯ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ Исключительные ситуации можно классифицировать по разным принципам. • В подпроцессе или процессе: c. После завершения обработки. соответствующего заданным критериям отбора. 7. Так же как и в программировании. этапа или всего процесса целиком. рассмотрим примеры: 1. ИСКЛЮЧИТЕЛЬНЫЕ СИТУАЦИИ Исключительные ситуации возникают всякий раз.7. По месту возникновения: • В операции: a. b. управление может быть возвращено в прерванный процесс. Истечение времени. d. Завершение процесса с определенным статусом. Обработка исключительной ситуации . отведенного на исполнение отдельной операции. который выполнят обработку возникшей исключительной ситуации.это механизм. а он оказался недоступен. управление передается специальному подпроцессу. требующим специальных мер обработки.

данные возвращаются в состояние. По уровню обработки особой ситуации: • На уровне операции. • Без возврата. клиент может аннулировать заказ в любое время. 7.б. инициировавшую исключительную ситуацию: • С возвратом в точку останова. ранее сделанный заказ.происходят. исполнение процесса не приостанавливается. По времени возникновения: • Синхронные . предшествующее началу исполнения операции. как видно из названия. данные не откатываются. По необходимости отката данных: • С компенсацией. • Асинхронные – происходят на любой стадии исполнения. По влиянию на текущий процесс: • Прерывающие. возникает дополнительный поток управления. Стоит ли продолжать исполнение процесса. 4. • В системе: Ошибка в движке BPM или в одной из библиотек программ. когда процесс находится в определенном состоянии. • На уровне подпроцесса. таймаут сервиса возможен только пока выполняется операция. • Не прерывающие. генерируются системой в результате ошибок и отказов. в которой произошел отказ. 6. По возврату в операцию. исполнение процесса приостанавливается до окончания процедуры обработки. • Бизнес исключения м. в которой произошел отказ. Например. • На уровне родительского процесса. 5. 2.Заказчик отменил. • Без компенсации. в котором находится операция. 3. если его результат уже никому не нужен. 153 . Например. заложены в бизнес-логику или являются результатом действий оператора. По источнику возникновения: • Системные.

Первые два имеют много общего. т. что действие надо выполнить вручную.7. • Отмена.2. Окончание предназначено для обработки таких отказов. работают одинаково. а в другой – исключением. Если возникло исключение. что исполнителю для завершения выполнения операции не хватает полномочий или ресурсов и он вынужден обратиться за помощью к руководителю. • Компенсация. последние имеют уникальное идентифицирующее имя. Компенсация и Отмена используются в транзакционных подпроцессах. когда для решения операции следует привлекать руководителя. • Окончание. что особые ситуации могут быть безымянными и именованными. недоступность внешнего источника информации в одной ситуации может являться сбоем. предшествующее началу выполнения транзакции. означая. действие не завершается. которые не могут быть исправлены. Предполагается. Обратим внимание. дальнейшая обработка не имеет смысла. по сути они отличаются лишь названием.ч. который называется эскалация. соответствующее действие может быть завершено. СОБЫТИЯ ДЛЯ ОБРАБОТКИ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ Для обработки особых ситуаций применяются следующие виды событий: • Исключение. Если произошло именованное событие и сгенерировано оповещение. Например. Если произошла ошибка. Для обработки ситуации. то принять это оповещение сможет только обрабатывающее событие. • Ошибка. имеющее такое же 154 . где может возникнуть необходимость в откате данных в состояние. но с неприемлемым для бизнеса результатом. • Эскалация. используется другой обработчик. возникающих на этапе исполнения.

одновременно несколько однотипных принимающих событий. Прикрепленное к границе операции событие ретранслирует внутреннюю ошибку вовне операции или подпроцесса. но в большинстве реализаций BPM в 155 . Рисунок 7-1А) иллюстрирует операцию с прикрепленным генерирующим событием. Например. У событий для обработки исключительной ситуаций есть область действий. Пример (см. Т. оказалось невозможно подобрать исполнителя. ИСКЛЮЧИТЕЛЬНАЯ СИТУАЦИЯ В ОПЕРАЦИИ В ходе исполнения операции могут возникнуть системные ошибки. то используют ретрансляцию оповещения вовне процесса. как обрабатываются особые ситуации.3. к которому она обращается.о. Если возникает необходимость работать с оповещением вне границ процесса. то оно будет принимать все оповещения данного вида. в процессе м.б. который бы удовлетворял всем выдвигаемым критериям. или произошла ошибка авторизации. а при выполнении интерактивной операции. При этом если имя принимающего обрабатывающего события не задано явно. при исполнении автоматической операции оказался не доступен внешний сервис. а для этого необходимо сделать ошибку в операции известной на уровне процесса и приять соответствующие меры. которая ограничена границами процесса. возникающие на разных уровнях процесса: 7. Хотя спецификация BPMN об этом явно не указывает.имя. МЕСТО ВОЗНИКНОВЕНИЯ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ Рассмотрим.3. Если в ходе исполнения этой операции возникнет внутренняя ошибка. то прикрепленное событие должно узнать о ней и послать оповещение другим операциям процесса.1. 7. На возникшую ситуацию следует отреагировать. причем каждое реагирует на определенное оповещение.

Рисунок 7-2) может завершиться одним из трех возможных результатов: одобрением заказа. Рисунок 7-1. Т. которое м. а третье как бизнес исключение. что в подпроцессе произошло бизнес исключение и обработать его соответствующим образом. Пример (см.свойствах прикрепленного события можно указать тип конкретной системной ошибки. Обработка события прикрепленного к границе операции После обработки ошибки можно вернуть управление в нужную точку процесса. например. по которому оно срабатывает. Оканчивая одну из ветвей генерирующим событием-ошибка. дальнейшее рассмотрение не целесообразно без дополнительной обработки.2. Первые два варианта мы рассматриваем как нормальное завершение. мы явно установили статус завершения подпроцесса. ИСКЛЮЧИТЕЛЬНАЯ СИТУАЦИЯ В ПРОЦЕССЕ Бизнес исключение м. 156 . что решение не принято. обработано на уровне процесса. а возможно. по причине отсутствия всей необходимой информации. Рисунок 7-1Б) показывает.3. отказом. что после обработки управление можно вернуть на предыдущую операцию для повторной обработки.о. вызывающий процесс сможет понять. Предположим. Генерирующее событие посылает оповещение.б. 7. заложено в логику процесса на стадии проектирования.б. процесс (см.

обработчик особой ситуации включает операцию отправки сообщения. которые видны только в пределах данного пула. Простое бизнес исключение 7. Рисунок 7-3). В зависимости от ситуации.3. что все рассмотренные нами до сих пор генерирующие события. рассылали оповещения. Что бы сделать это оповещение известным вне данного процесса. ИСКЛЮЧИТЕЛЬНАЯ СИТУАЦИЯ ВО ВНЕШНЕЙ СРЕДЕ Рассмотрим. Последнее создает специальный поток обработки. Процесс1 порождает внешний Процесс2. Единственным каналом обмена между процессами является поток сообщений. прикрепленное граничное обрабатывающее событие м.Рисунок 7-2. не известно. но последнее известно только в рамках Процесса1.б. в другом процессе. если источник особой ситуации лежит вне текущего процесса. Мы будем помнить. Вне этого пула оповещение. 157 . сгенерированное событием. так что сгенерированное оповещение можно пересылать между процессами только через поток сообщений. оно генерирует оповещение. прерывающим и непрерывающим.3. Рассмотрим пример (см. Поток сообщений достигает Процесса2 и обрабатывается прикрепленным к Процессу2 граничным событием. Позднее в Процессе1 происходит внутренняя ошибка. которую фиксирует прикрепленное к соответствующей операции обрабатывающее событие. что произойдет.

• Если таковой нет. определяющая порядок обработки особых ситуаций. прикрепленное к границе процесса. обработана на уровне операции. Рисунок 7-1) иллюстрирует обработку ошибки на уровне отказавшей операции. будет использовано обрабатывающее событие. в которой она возникла. • Если такой обрабатывающей операции нет. Рассмотрим порядок обработки особых ситуаций.о. на уровне подпроцесса. прикрепленное к границе отказавшей операции. возникает иерархия. Исключительная ситуация во внешней среде 7.1. Т.4. окружающего отказавшую операцию. УРОВНИ ОБРАБОТКИ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ Исключительная ситуация м. в котором находится дефектная операция. Представим себе. что в некоторой операции зафиксирован отказ. то будет выполнен событийный вложенный подпроцесс. • В первую очередь будет выполнено обрабатывающее событие. ОБРАБОТКА НА УРОВНЕ ОПЕРАЦИИ Пример (см.б. 158 .4.Процесс 1 Рисунок 7-3. то ошибка будет задокументирована в файле журнала ошибок BPMS. • Если событийного. на уровне всей системы. вложенного подпроцесса нет. 7.

мы объявим эту ситуацию. ОБРАБОТКА В ВЫЗЫВАЮЩЕМ ПРОЦЕССЕ Повторно рассмотрим предыдущий пример. так что причинно-следственная связь ясна из контекста (см Рисунок 7-4). Обработка бизнес исключения во вложенном подпроцессе 7. что число вариантов завершения увеличилось. на этот раз предположим. ОБРАБОТКА ВО ВЛОЖЕННОМ ПОДПРОЦЕССЕ Если необходимо отреагировать на событие прямо в подпроцессе. показываемом внутри пула. то можно воспользоваться т. как Ошибку 2.3.4.2. Этот подпроцесс начинается с одноименного события. Рисунок 7-4. изображаемого пунктирной линией. когда нет кворума для принятия решения. событийным вложенным подпроцессом. Будем обрабатывать эту ошибку в вызывающем процессе.4. возможна ситуация.7. Для этого он должен иметь 159 .н.

в случае нестандартного завершения подпроцесса со статусом Ошибка 2. что вызвало ошибку. управление будет передано одноименному прикрепленному событию. Теперь. Рисунок 7-5 Рисунок 7-5) одноименное тому. последнее создает новый поток управления. 160 .прикрепленное обрабатывающее событие (см. Рисунок 7-5. Обработка события прикрепленного к границе процесса.

7. ДЕЙСТВИЯ ПОСЛЕ ОБРАБОТКИ ИСКЛЮЧИТЕЛЬНОЙ СИТУАЦИИ После завершения обработки исключительной ситуации управление может быть возвращено в точку прерывания или м. Пример (см. которая прерывает основной процесс. продолжено без возврата. Рисунок 7-7) иллюстрирует обработку ошибки. Рисунок 7-7. т. Рассмотрим примеры.5. 161 .6.б. Обработка ошибки без возврата в основной процесс 7. С ВОЗВРАТОМ В ТОЧКУ ПРЕРЫВАНИЯ Пример (см.7. Рисунок 7-6. с возвратом в основной процесс. Обработка ошибки с возвратом в основной процесс 7.5.ч. операция «Б» в случае ошибки не исполняется. ВЛИЯНИЕ ИСКЛЮЧЕНИЯ НА ТЕКУЩИЙ ПРОЦЕСС По влиянию исключения на текущий процесс различают события: • Прерывающие исполнение процесса.1.2. он приостанавливается до окончания процедуры обработки.5. Рисунок 7-6) показывает обработку ошибки. БЕЗ ВОЗВРАТА В ТОЧКУ ПРЕРЫВАНИЯ.

7.• Не прерывающие. которая вызывает внешний сервис.2. произошла исключительная ситуация. исполнение процесса не приостанавливается.6. которое инициирует запуск событийного подпроцесса. например. ИСКЛЮЧЕНИЯ. операция «А» не будет выполнена. как событийный подпроцесс будет завершен. Завершение нового потока управления означает окончание всего процесса. однако по162 . Во время выполнения операции. Рисунок 7-8). Рисунок 7-8. Поскольку событие является прерывающим. то проблемы с возвратом управления не возникает. Рассмотрим пример (см. После того. НЕ ПРЕРЫВАЮЩИЕ ИСПОЛНЕНИЕ ПРОЦЕССА Если исключение не прерывает исполнение операции. в случае возникновения ошибки во внешнем сервисе. ИСКЛЮЧЕНИЯ. то основной поток управления будет приостановлен. начнет выполняться операция «В».6. Оповещение об ошибке будет перехвачено обрабатывающим событием «Обработка ошибки внешнего сервиса». При этом не всегда легко понять. возникает дополнительный поток управления. куда вернется точка управления. Исключение. Т. ПРЕРЫВАЮЩИЕ ИСПОЛНЕНИЕ ПРОЦЕССА Если событие прерывает обработку процесса. Хотя на схеме это явно не указано. сервис оказался недоступен.1.о.. внутренняя ошибка сервисной операции известна внутри подпроцесса. прерывающее исполнение процесса 7. то при этом создается новый поток управления.

Решение об эскалации. Рисунок 7-9. либо оно основывается на некотором правиле. Эскалация применяется в ситуации. СОБЫТИЕ-ЭСКАЛАЦИЯ Эскалация — означает вынос проблемы для обсуждения на более высоком уровне принятия решения. однако имеет ряд серьезных отличий: 163 . знаний или ресурсов.7. непрерывающее исполнение процесса 7. для этой цели используется событие-таймер. Если лимит исчерпан.является необходимость явного завершения дополнительного потока. основной поток продолжает исполнение. Поскольку событие является непрерывающим. то прикрепленное граничное событие-таймер инициирует новый поток управления. Возникшая проблема не связана со временем или отставанием от норматива. когда у исполнителя не хватает собственных полномочий. на исполнение операции «Выполнить работу» отведено нормативное время. Исключение. при эскалации исполнитель прерывает работу и передает ее руководителю. Рисунок 7-9). Следует быть внимательным и стараться исключить ситуации. либо принимает сам исполнитель. тогда говорят о совместной работе над задачей. это может породить нежелательные последствия. После окончания обработки исключительной ситуации. дополнительный поток следует явно завершить. когда основной и вспомогательный потоки объединяются. Обычно. Событие-эскалация во многом похоже на событие-ошибка. но в отдельных ситуациях он может продолжить исполнение. при невозможности ее разрешения на текущем. Рассмотрим пример (см.

как известно. что исполнитель. может не прерывать выполнение операции. которое создает оповещение. что у него нет достаточных полномочий для принятия решения. в отличие от ошибки. 7.1) Эскалация. прекращает выполнение всех потоков на том же уровне подпроцесса. в случае прерывания выполнения операции. для этого предусмотрено событие эскалация. в котором она произошла. может выбрать одну из опции: «принять решение» или «отказать». что у него недостаточно полномочий для принятия решения. то точка управления приходит в генерирующее прерывающее событие. ОБРАБОТКА ЭСКАЛАЦИИ Для интерактивных операций «характерны» исключительные ситуации. Рассмотрим пример прерывающей эскалации (см. 164 . прекращает работу только того потока. он делится заданием. а во втором непрерывающее. к которой она была прикреплена.1. в котором она была сгенерирована. сотрудник отдает задание руководителю и теряет возможность продолжить исполнения. Рисунок 7-10). 2) Эскалация действует на том же уровне подпроцесса. он должен поднять уровень принятия решения. у него остается возможность продолжить работу над заданием. Например. 3) Эскалация.7. Можно выделить два способа эскалации: во-первых. В первом случае применяется прерывающее событие. однако может случиться. описанной в предыдущем параграфе: сперва ищется вложенный событийный подпроцесс. дальнейшая работа подпроцесса прерывается. генерируемые оператором. Ошибка. Если он выбирает вариант эскалации. затем прикрепленное граничное событие. если их нет. выполнение потока. а во-вторых. на котором была сгенерирована. показывающий. если в ходе исполнения сотрудник поймет. то протоколируется ошибка. 4) После обработки эскалации. может быть продолжено. Дальнейшая обработка эскалации осуществляется в соответствии с последовательностью. выполняющий операцию.

Поскольку обработка эскалации осуществляется во вложенном подпроцессе. Рисунок 7-11. исполнитель и руководитель. имеют доступ к одним данным. в котором осуществляется обработка 165 .Рисунок 7-10. который имеет доступ к контексту экземпляра процесса.2. управление передается следующей операции. связанная с организацией правильной работы с данными. Обработка прерывающего события-эскалация 7. т.ч. Параллельно стартует событийный подпроцесс. изображающий вложенный подпроцесс. Обработки непрерывающего события-эскалация Рассмотрим пример (см. Рисунок 7-11) показывает обработку эскалации с использованием непрерывающего события. оба. руководитель должен консультировать исполнителя.7. ОБРАБОТКА НЕПРЕРЫВАЮЩЕГО СОБЫТИЯ-ЭСКАЛАЦИЯ Пример (см. Если у исполнителя не хватает полномочий. но поток управления не прерывается. Рисунок 7-12). то он выбирает вариант эскалация. За кажущейся простотой этого сценария скрывается определенная сложность.

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

Принять
решение

Эскалировать
менеджеру

Принять

Отклонить

Рисунок 7-12. Обработки непрерывающего события-эскалация

7.8.

ОБРАБОТКА КОМПЕНСАЦИИ

Событие компенсация тесно связано с понятием транзакция.
Обычно транзакции связаны с выполнением комплексных изменений, производимых во многих информационных системах, для транзакционного взаимодействия которых разработан
протокол WS Transaction. Он определяет протоколы:
•Завершения транзакции;
•Ненадежного и надежного двухфазного подтверждения.
Большинство реализаций BPM имеют специальный адаптер, который может анализировать оповещения, пересылаемые
по протоколу WS Transaction, т.ч. если последняя не будет завершена, то обрабатывающее событие сможет «услышать это
166

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

Рисунок 7-13. Обработка события-компенсация
Откат выполняется только для успешно завершенных
транзакций процесса. Если какая-то операция не была завершена вовсе, то откат не производится, поскольку неизвестно,
были ли реально изменены данные. Например, если операция
прервана по причине возникновения исключительной ситуации, то откат невозможен до завершения обработки исключения.
Компенсируемая операция д.б. «видима» для генерирующего события, поэтому последнее должно располагаться:

В потоке текущего процесса;
167

Внутри вложенного событийного подпроцесса, который
«принадлежит» текущему процессу;
Рассмотрим пример, иллюстрирующий последний случай
(см. Рисунок 7-14), он изображает событийный подпроцесс, запускаемый обрабатывающим событием-компенсация. Последнее
срабатывает, получив оповещение от генерирующего событиякомпенсация.

Рисунок 7-14. Откат с использованием событийного подпроцесса
Если текущий подпроцесс содержит операции, помеченные граничным обрабатывающим событием-компенсация, то
происходит следующее: все успешно завершенные операции
последовательно откатываются в состояние предшествующее
их началу.
Рассмотрим следующий пример (см. Рисунок 7-15), многопоточный подпроцесс может завершиться со статусом нормальное завершение или отказ. В последнем случае возникает
необходимость произвести откат данных, измененных в подпроцессе. Поскольку последний является многопоточным, откат будет выполнен столько раз, сколько запускался подпроцесс.

Рисунок 7-15. Откат, инициируемый событием-компенсация
168

Следующий пример связан с использованием транзакционного подпроцесса (см. п. 3.5.7). Этот подпроцесс имеет два
варианта завершения. При нормальном завершении транзакционного процесса, выполнение продолжится в родительском
процессе. В случае завершения подпроцесса генерирующим событием-отмена (см. п. 6.11.3) происходит следующее: сперва
производится откат всех операций, помеченных как компенсируемые; после этого подпроцесс считается завершенным со
статусом отмена. Обрабатывающее событие-отмена, прикрепленное к границе транзакционного подпроцесса, передает
управление на операцию, обрабатывающую отмену, затем потоки управления сливаются.

Рисунок 7-16. Пример использования отмены и компенсации

169

8.ОБЪЕКТЫ ДАННЫХ
Выполнение бизнес-процесса всегда связано с одним или несколькими информационными потоками. Несмотря на то, что
нотация BPMN не предусматривает возможность моделирования структур данных, она позволяет связать абстрактные информационные объекты с операциями, размещенными на схеме процесса. Т.о. на схеме процесса можно изображать объекты
данных: физических, абстрактных, информационных и т.д.
Предполагается, что информационный объект может иметь
внутреннюю структуру. По умолчанию она определяется при
помощи XML схемы документа. Элементы нотации не хранят
внутри себя описание структуры объекта, но содержат ссылку,
указывающую на такое описание. На схеме процесса ссылка
визуализируется при помощи элемента ассоциация данных. В
качестве языка запросов к элементам XML-документа используется XPath.
Всю информацию, которая обрабатывается в процессе
можно разделить на временную и постоянную. К первому типу
относятся те данные, которые существуют только пока выполняется данный процесс. После его завершения эта информация становится не нужной и ликвидируется. Для обозначения
временных объектов на схеме процесса используется элемент
«Объект данных», «Входные и Выходные данные», «Коллекции объектов данных». Ко второму типу относится информация, которая
существует вне рамок процесса, например запись о клиенте в
БД CRM. Соответственно для обозначения места хранения таких данных используется элемент «Хранилище данных». Наконец, сообщения так же позволяют отобразить на схеме обмен
информационными потоками.
Таблица 8-1 показывает графические элементы, используемые для отображения на схеме процесса потоков данных.

Таблица 8-1 Графические элементы для изображения данных
170

инициирующей диалог. Изображает статус информационного объекта по ходу обработки Изображает информационный объект сложной структуры типа массив. Операции процесса могут обрабатывать элементы массива по отдельности.Вид Семантика исполнения Изображает информационный объект. Показывает направление передачи объекта данных от источника к получателю Связывает объект данных с потоком управления. Изображает информационный объект на выходе процесса или отдельной операции процесса. Предметно-ориентированная информационная база данных. Инициирующее сообщение Отображает конверт информационной посылки. 171 . Внутренняя структура данных объекта на схеме не отображается. Ответное сообщение. предназначенная для сохранения результата выполнения операции процесса. полученное инициатором переписки. Изображает информационный объект. необходимый для начала обработки всего процесса или отдельной операции процесса. обрабатываемый в ходе исполнения процесса.

определенный в родительском процессе. Рисунок 8-2) иллюстрирует зоны видимости объектов данных. Подпроцесс1 Подпроцесс2 Подпроцесс3 Объект1 Объект2 Объект3 Рисунок 8-1. Объект данных 1 будет доступен для всего «процесса 1». Вложенные подпроцессы Следующая схема (см. но он недоступен в «Процессе1» и т. в котором он используется. Объект данных 2 будет доступен для «Процесса 2». в каждом определен свой объект данных. но он не доступен вне этого процесса. где он используется. включая все вложенные подпроцессы. 3. п. Зоны видимости объекта данных Рассмотрим следующий пример.д. и «Процесса3». п.5.8. он изображает семейство вложенных подпроцессов (см. Рисунок 8-3). Рисунок 8-2.1). не известен в вызываемом.5. включая все вложенные подпроцессы нижнего уровня. Объект данных. теперь процесс является повторно используемым (см.1. изображенных на предыдущем рисунке. 3. Рассмотрим пример (см. Рисунок 8-1).1. (см. ЖИЗНЕННЫЙ ЦИКЛ И ДОСТУПНОСТЬ ОБЪЕКТОВ ДАННЫХ Жизненный цикл объекта данных связан с жизненным циклом того процесса. он доступен внутри процесса.2). так что в ходе 172 . При запуске экземпляра подпроцесса будет создана копия соответствующего объекта данных.

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

Рисунок 8-3. Передача данных в повторно используемый подпроцесс

8.1.2. СПОСОБЫ ОТОБРАЖЕНИЯ АССОЦИАЦИИ
НА СХЕМЕ ПРОЦЕССА
Существует два способа отображения факта передачи объекта
данных между операциями процесса. Во-первых, направленная
ассоциация данных явно указывает движение информационного объекта от источника к получателю. При этом возникает
ощущение, что потоки управления и данных существуют независимо друг от друга (это не вполне верно – если поток управления направлен на логический оператор «ИЛИ», направление
маршрутизации определяется значением информационного
объекта).

Рисунок 8-4. Направленная ассоциация данных
173

Во-вторых, стандарт допускает альтернативное обозначение передачи объекта данных, когда ненаправленная ассоциация связывает объект данных с потоком управления. В этом
случае, источник и получатель, направление передачи объекта
данных определяются стрелкой потока управления. Такая
форма подчеркивает, что потоки управления и данных суть
одно и то же.

_
Рисунок 8-5.Ненаправленная ассоциация данных

8.1.3. СТАТУС ОБРАБОТКИ ДОКУМЕНТА
В ходе моделирования процесса может возникнуть желание
отобразить статус обработки объекта данных, например заказа клиента. После исполнения операции «Принять заказ» статус заявки имеет значение «Принята», после выполнения операции «Обработать заказ», ее статус изменится на «Обработана», а операция «Выдать заказ» устанавливает статус «Выдан».

Рисунок 8-6. Статус обработки информационного объекта

8.1.4. КОЛЛЕКЦИЯ ОБЪЕКТОВ ДАННЫХ
Коллекция объектов данных рассматривается как набор однотипных элементов, образующих массив. Часто возникает задача обработать по отдельности все элементы массива. Задачу
можно решить, если воспользоваться операцией или подпроцессом параллельного (циклического) исполнения. Если по174

дать коллекцию объектов данных на вход операции параллельного исполнения, то можно так настроить отображение
массива на входные аргументы операции, что последняя будет
выполнена для каждого из элементов этого массива. Используя
коллекция объектов данных можно автоматически породить столько
экземпляров процесса, сколько объектов данных хранится в массиве.
Рассмотрим пример, компания подготовила приглашение
на конференцию, используя данные из CRM сформировала
список, затем рассылает приглашение по почте. Подпроцесс
«отправить приглашение» должен быть выполнен столько раз,
сколько приглашенных указано в списке. Список приглашенных оформлен как коллекция документов. Необходимо дополнительно настроить отображение входных данных операции.

Рисунок 8-7. Коллекция объектов данных

8.1.5. ХРАНИЛИЩЕ ДАННЫХ
В ходе моделирования процесса возникает необходимость отобразить сохранение информации во внешнем хранилище данных или чтение информации из некоторого внешнего источника, например справочника. Для изображения места хранения контекстных данных процесса используется графический
элемент хранилище данных. Учитывая, что под данными в
нотации BPMN понимается не только информация в цифровом виде, то под хранилищем может подразумеваться склады,
помещения, СУБД и т.д. Стрелка ассоциации указывает направление передачи информации: во внешний источник – запись, из внешнего источника - чтение. Пример (см. Рисунок 8-8)
175

иллюстрирует прием заказа, при этом, надо записать данные о
текущем заказе в CRM, затем извлечь из CRM информацию о
предыдущих заказах, что бы рассчитать скидку клиента.

Рисунок 8-8. Хранилище данных

8.1.6. ВНЕШНИЙ ВХОД И ВЫХОД ПРОЦЕССА
В ходе моделирования часто возникает необходимость специфицировать входные и выходные данные процесса, для этого
можно использовать объекты Внешний вход и Внешний выход
процесса. Пример, (см. Рисунок 8-9А) изображает входной документ. Следует быть внимательными, входной документ должен поступить на вход процесса еще до начала его исполнения.
Второй пример (Рисунок Б) изображает выходной документ.

Рисунок 8-9. Входные и выходные данные процесса
Если аналитик не уверен, что документ окажется в наличии до начала работы процесса, надежнее использовать вместо
Внешнего входа чтение информации из внешнего хранилища,
(см. Рисунок 8-10).

Рисунок 8-10. Чтение информации из внешнего хранилища
176

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

8.1.8. ПОЛЕЗНАЯ ИНФОРМАЦИОННАЯ
НАГРУЗКА СИГНАЛОВ И ОПОВЕЩЕНИЙ
Сигналы и оповещения (эскалация, ошибки, сигналы) способны нести полезную информационную нагрузку. Для связывания объектов данных процесса и полезной информационной
нагрузки используется ассоциация данных. Для генерирующих событий входной набор данных отображается на аргументы оповещения. Для обрабатывающего события все наоборот,
аргументы оповещения отображаются на выходной набор
данных. Если полезная нагрузка не предусмотрена, то генери177

Принято считать. который определяется как «теоретическое понятие». содержащаяся на нем. что есть токен. Процесс описывает последовательность изменения состояния системы во времени. Несмотря на невидимость битов и байтов они реально существуют в окружающем материальном мире. который используется для записи результата выполнения очередного действия.н. В производственном процессе фиксируются изменения состояния материального продукта. Попытаемся понять. используемое для определения поведения исполняемого процесса. Переменная процесса движется вдоль диаграммы. К этому классу можно условно отнести процессы документооборота. выполнение очередной работы.рующее событие отправляет пустое сообщение. что бизнес-процессы имеют дело с обработкой именно информации. а не физических свойств документа. необходимо определить т. а информация. При их обработке изменяются не физические свойства носителя. а обрабатывающее не возвращает полезных данных. Переменная 178 . что бы передать его на вход следующего. Под переменной процесса понимается информационный объект. например цвета или плотности бумаги Спецификация BPMN 2. Для облегчения восприятия вводится понятие токен. 8.1. переменную процесса. Когда диаграмма BPMN подготавливается для исполнения в BPMS. что потоки данных и потки управления не связаны между собой. что не вполне верно. ее прибытие в узел активирует.9. тем самым определяет статус обработки. Токен движется вдоль процесса и.0. Хотя документ (лист бумаги) есть вполне материальный объект. решения в ходе работы принимаются на основании информации. ПОТОКИ ДАННЫХ И УПРАВЛЕНИЯ У многих аналитиков возникает ощущение. но не определяет его явно. использует термин поток операций. Но в бизнес-процессе изменение состояния системы фиксируется в информационных объектах.

Если строится модель процесса в BPMS. что движение объекта данных «Заявка» образует поток управления. отражающие ход выполнения операций процесса. токен можно ассоциировать с переменной процесса. 179 .процесса есть суть объект управления. По мере продвижения объекта управления. что происходит с данными. выполнение операций «Рассмотреть заявку» приводит к качественному изменению состояния «Заявки». Т. Когда аналитик строит аналитическую модель процесса. важный с точки зрения выполняемого задания. который можно ассоциировать с токеном процесса. Например. в нем происходят качественные изменения. можно говорить.о. Именно в ней участники ставят свои отметки о ходе рассмотрения дела. ЗАМЕЧАНИЕ О РАБОТЕ С ДАННЫМИ: Нотация BPMN определяет семантику исполнения ЛО «И» только в части потоков управления. Т. при этом она умалчивает о работе с данными. Возможны два сценария: • Каждая ветвь работает со своим элементом общего объекта данных • Все ветви работают с одним и тем же элементом общего объекта данных. Например.о. то в качестве объекта управления он. обычно.2. каждая ветвь работает с общим для всех объектом данных. Давайте рассмотрим.о. Логический оператор «И» разветвляющий входной ПУ на несколько параллельных потоков управления не создает для каждого из них отдельной копии данных. При создании исполняемых процессов работу с данными необходимо учесть. в процессе «согласование кредитной заявки» объектом управления являются документы «Заявка». выбирает какой либо документ. Т. 8. в качестве переменной процесса выбирается объект данных.

могут быть отменены вторым. Поэтому каждый из них помещает свои комментарии в отдельное. то ни имеют доступ к одному и тому же объекту данных. выполняемые в параллельных ветвях. 180 . совпадают. причем первый об этом не узнает. зоны их ответственности не пересекаются. Согласование экономиста и юриста есть две разные функции. Если два работника выполняют одну и ту же функцию. выполненные первым. специально предназначенное для этого поле. Возникает коллизия. изменения. Во втором примере функции. оба работают со своей частью договора. экономист и юрист производят согласование договора.Рассмотрим первый пример.

роль объединяет тех исполнителей. При аналитическом моделировании в качестве объекта рассматривается операция процесса. 181 . а роль может объединять многих участников. В одну роль могут входить несколько сотрудников.Рэмлер и А. управление доступом сводится к назначению пользователю необходимых ролей. Дорожкам дается имя. Поскольку права доступа не назначаются пользователю индивидуально.о. Брейч. вводится иерархическая связь между ролями. которые имеют обязательство исполнить данную операцию. 9.1. плюс к тому. связанных с различными ролями. Они предложили изображать на диаграмме процесса дорожки. которые они должны выполнить. Каждый пользователь системы может участвовать в нескольких ролях. которая закрепляет за каждой операцией соответствующих исполнителей. если ему присвоена соответствующая роль.9. К примеру. Чтобы множества операций. а приобретаются им через определенную ему роль. Отдельный сотрудник может иметь много ролей. которое позволяет однозначно идентифицировать соответствующую категорию пользователей. не пересекались.ЗОНЫ ОТВЕТСТВЕННОСТИ (ДОРОЖКИ И ПУЛЫ) В практике реинжиниринга бизнес-процессов принято создавать процессно-ролевую модель. группирующие пользователей по функциям или что то же самое по работам. роль «секретарь» может включать в себя роль «регистратор» и. которые имеют право выполнить данную операцию. Выполнение пользователем соответствующей операции процесса разрешено. Она обладает следующими свойствами: 1. Концепцию группировки сотрудников по ролям выдвинули Г. Это упрощает администрирование системы в случае добавления нового пользователя или смены им подразделения. РОЛЕВАЯ МОДЕЛЬ Роль – есть группа сотрудников. 2. еще несколько дополнительных операций. т.

Например. пользователю невозможно делегировать права на какой-то определенный информационный объект. Либо у него есть доступ ко всем подобным объектам системы. Сначала. руководитель и его подчиненный могут иметь одинаковое право выполнить операцию. сотрудник и его руководитель. знаний. позволяющий среди всех сотрудников организации найти тех.3. пользователь имеет право выполнить какую-то операцию. В бизнес моделировании в качестве объектов системы рассматривают только операции процесса. Ролевая модель не в состоянии различить этих участников. но работающие в разных территориальных подразделениях не должны видеть процессы друг друга. например. которые обладают сходными правами доступа к объектам системы. либо нет вообще. кому будет пору182 . и др. Затем из числа кандидатов назначается реальный исполнитель. Так же роль не учитывает полномочия сотрудника. Роль не связана с должностью. а только некоторое множество кандидатов. Как следствие. два сотрудника в одной роли. происходит отбор потенциальных исполнителей. при этом нельзя определить раздельные права доступа к отдельным элементам данных или документам.о. но не определяет права доступа к данным процесса. Ролевая модель не указывает реального исполнителя. Т. роль определяет права доступа к операциям. например. Программирование определяет роль как категорию сотрудников. у объектов данных на схеме процесса нет определенных владельцев. Трактовка понятия роль в программировании и бизнесинформатике в немного отличаются. например. поэтому распределение работ между сотрудниками осуществляется в два этапа. Роль не учитывает права доступа к экземплярам процесса. связанные с должностями. навыков. квалификации должности. В результате. кто удовлетворяют установленным критериям: опыта. нельзя указать раздельные права для разных операций. Если пользователь имеет право выполнить несколько операций процесса.

Но в системах управления бизнес-процессами необходимо указать критерии отбора и назначения реального исполнителя.1. Будем различать две категории исполнителей: физические и юридические лица. КАК ПРОБЛЕМА РЕШАЕТСЯ В BPM В первой версии нотации BPMN термины роль и дорожка были. Понятие роль и дорожка по-прежнему используются. 9. диалоги. 183 .1. под исполнителем мы будем иметь в виду физическое лицо. ПУЛ И ДОРОЖКА Для отбора исполнителей используются графические элементы нотации Пул (Pool). Первоначально предполагалось использовать ролевые модели в проектах по реорганизации организационной структуры предприятия и перераспределения обязанностей сотрудников. В случаях. однако они не являются однозначными синонимами.2. или хореография. а в других случаях – нет. так что дорожка определяла исполнителей. 9. которым поручено выполнение задания. Кроме того. Во второй версии стандарта ситуация изменилась. Дорожка (Lane). в проектах по реорганизации организационной структуры роль часто подменяется должностью. Если моделируются схемы взаимодействия. Наконец. В описанной процедуре роль участвует в отборе. но не участвует в назначении. так и физические лица – сотрудники этих компаний. когда моделируется оркестровка приватных (внутренних) бизнес-процессов. поэтому с применением ролевой модели возникают трудности. участниками считаются юридические лица. по сути.чена работа. на схемах публичных (внешних) процессов участниками являются как компании. синонимами. В этом случае вопрос назначения реального исполнителя для операции процесса не являлся предметом рассмотрения. участника бизнеспроцесса. В некоторых ситуациях дорожка определяет исполнителя.

Например. выступает в роли контейнера для потока операций процесса. в первом случае пул и дорожка. Нотация допускает изображать пул как «черный ящик». что модель описывает межорганизационное взаимодействие. У одного заказчика м. процесс внутри подразумевается.2. отвечает за выполнение процесса. они ассоциируются с внутренней сущностью метамодели Участник (Participants). но не изображается. т. фактически. а вторая – есть обобщенное название роли действующего лица. РольУчастника позволяет создать модель процесса.2. указывающий. представим. который. Связь между Пулами отображается посредством потоков сообщений. но не может выходить за границы пула. позволяя графически отобразить организации участников взаимодействия. используемый для группировки и разделения операций процесса. Пул ограничивает процесс и. что в процессе участвуют несколько Поставщиков. причем взаимоотношения с каждым из них описывается одной моделью процесса. Группировка 184 .2. объединяющий одну или несколько дорожек. которая на привязана к конкретных участникам. который может пересекать границы дорожек внутри пула.о.1. 9.9. Иначе их можно было бы назвать «Заказчик» и «Поставщик». как правило.б. несколько поставщиков. Пулы часто применяются при межорганизационном взаимодействии. ПУЛ Пул это графический элемент. ДОРОЖКА Дорожка есть графический элемент. В последнем случае РольУчастника может иметь дополнительный признак мультипликативности. совпадают. заключенного в соответствующем Пуле. Внутренняя переменная Участник (Participants) может быть определена двумя способами: путем указания имени КомпанииУчастника (PartnerEntity) или РолиУчастника (PartnerRole) Первая есть обозначение конкретной организации или ее организационной единицы. в котором участвуют две компании «Рога и копыта» и «Одесская бубличная артель «Московские баранки»».

иерархически организованными дорожками. часто ассоциируют дорожки с названием структурного подразделения.означает размещение нескольких операций процесса в пределах одной дорожки. выполняемые одним пользователем или сотрудниками одного подразделения. должностью или конкретным исполнителем. например. так что аналитик свободен группировать операции процесса по своему усмотрению. Аналитики. в третьем «Иванов Иван Иванович». Во всех примерах дорожка оказывается жестко привязана к организационно-штатной структуре конкретного предприятия или к его сотрудникам. В первом случае дорожка может именоваться «отдел продаж». Критерий группировки в спецификации BPMN не определен. а также внутреннее множество дорожек для должностей. Рисунок 10-1) показывает процесс со вложенными. 185 . дорожка может объединять операции. во втором . так что смена структуры приведет к изменению модели процесса. может существовать множество дорожек отделов предприятия. Например.«старший экономист» или «главный бухгалтер». «бухгалтерия». Дорожки могут быть вложенными. существующих внутри каждого отдела. Пример (см. Принципы группировки на разных дорожках могут различаться.

либо используя параметрический запрос к внешнему каталогу пользователей. выполняющего действие или являющегося ответственным за его выполнение: либо явно указав его имя. каждая дорожка ссылается на отдельный экземпляр этого атрибута. Первый позволяет явно указать на физическое лицо. 4. группу лиц. поэтому он может включать перечисление всех необхо186 . исполняемых человеком. Иван Иванов или «Операционист». Графический элемент операция изображает работу. только два типа используются для описания взаимодействия с человеком участником: пользовательская операция описывает интерактивное взаимодействие пользователя с системой. например. однако. 9. п.1). посредством которого указываться элементы процесса. Иерархия дорожек процесса С каждой Дорожка связан атрибут РазделительныйЭлемент (partitionElement). Графическому элементу операция соответствует два внутренних атрибута Исполнитель (Performer) и Ресурс (Resource). например. Нотация явно не определяет тип и формат запроса. для этого используется параметрический запрос к внешнему каталогу пользователей. выполняемую отдельным пользователем.3. Второй указывает на исполнителей косвенно. которые могут стать исполнителем соответствующего действия. роль или должность в организации. а ручная – работу. например «Продавцами» могут выступать сотрудники в разных должностях.0 определяет два подхода к отбору лица. причем. помогая определить некоторую совокупность лиц. ОТБОР ИСПОЛНИТЕЛЕЙ Спецификация BPMN 2. Рассмотрим отбор и назначения сотрудников для операций. ссылаются на атрибут ресурс.Рисунок 9-1. которые необходимо разместить внутри данной дорожки. так что участник только подтверждает факт ее исполнения. «сотрудник отдела продаж». Нотация BPMN различает семь типов операций (см. возможно работающие в разных подразделениях. выполняемую вне системы. Все дорожки внутреннего множества указывают на разделительный элемент одного типа.

Рассмотрим влияние графических элементов пул. оставляя это на решение аналитика. Спецификация BPMN не разделяет отбор и назначение исполнителей.0 средства. имеющий лимит ответственности более 1000 рублей и знающий английский язык. В этом случае. подключаемой сущности ИндивилуальныйИсполнитель (HumanPerformer). Пример (см. дорожка. по отношению к спецификации BPMN 2. работающий с физическими лицами по направлению потребительское кредитование в определенном территориальном отделении. размещенного внутри дорожки. Атрибут РольРесурса (ResourceRole) сохранен для обеспечения совместимости с предыдущей версией спецификации BPMN 1. операция на выбор исполнителя. WS-Human Task. Напротив. объединяющий две дорожки. например спецификацию. Спецификация BPMN явно не определяет правила и критерии отбора исполнителя. Связанные с ними атрибуты КомпанияУчастник (PartnerEntity) и Роль-Участника (PartnerRole) не оказывают влияния на отбор и назначение исполнителя задания. 9. Если в результате запроса будут 187 . каждая из которых содержит по одной операции. СПЕЦИФИКАЦИЯ WS-HUMAN TASK Что бы воспользоваться отбором через атрибут ресурс придется использовать внешние. В этом месте происходит стыковка с внешней моделью WS-Human Task.0.4. его использование в текущей версии не специфицируется. Рисунок 10 1) показывает пул. атрибуты операции: Исполнитель (Performer) и Ресурс (Resource) непосредственно влияют на отбор участников. Результатом запроса является список потенциальных исполнителей. атрибут Исполнитель (Performer) получит соответствующее значение из внешней. например: сотрудник клиентского отдела. Из анализа спецификации BPMN 2. из которых в дальнейшем одного надо будет назначить исполнителем.димых критериев отбора. что графические элементы пул и дорожка не определяют реального исполнителя операции.0 становится ясно.

отобрана группа исполнителей. Роль. Рисунок 10 1. как происходит назначение исполнителей с использованием спецификации WS-Human Task. Исполнитель и Ресурс. сложно понять их реальное назначение. однако. Разница в том. можно сделать вывод. Пул и Дорожка Итак. Внутренние процессы являются исполнимыми. что нотация BPMN включает графические элементы пул и дорожка. так что каждый из них может добровольно назначить себя самого исполнителем. ролевая модель в них отсутствует. возвращающий список Потенциальных исполнителей. оказывается трудно различить. 188 . что действительно удобно. не использует их для выбора исполнителя интерактивной операции. либо параметрический запрос. отсутствия четкого описания их взаимосвязи. по сути. поэтому спецификация BPMN предлагает использовать либо прямой выбор конкретного исполнителя. Рассмотрим. все они получат предложение выполнить данное задание. Первые относятся к межпроцессному взаимодействию. вторые к внутренним процессам организации. Попытаемся объяснить их предназначение. как происходит отбор и назначение. что модели межпроцессного взаимодействия не являются исполнимыми. Из-за расплывчатости формулировок и вследствие отсутствия точного разъяснения что обозначают сущности Участник. поэтому в них сохранена ролевая модель.

кто удовлетворяет соответствующим критериям выборки. используется.9.ч. выполнять административные функции. несущий полную ответственность за конечный результат выполнения. лицо породившее Задание (экземпляр процесса). 189 . • Актуальный исполнитель (actual owner).5. пользователь или группа пользователей. Он вправе выполнять все действия. выбирается из числа Потенциальных исполнителей. в т. Она формируется путем отбора из числа всех исполнителей только тех. под которой понимается совокупность пользователей. отказаться от назначения. которые инициаторы могут для этого совершить. которым м. предложено исполнение задания. он может контролировать исполнение операции. Формат запроса и его параметры не специфицированы.б. В спецификации не указан состав действий. что бы определить потенциальных исполнителей методом исключения. приостанавливать ее. • Ответственный (stakeholders). которая включает следующие понятия: • Логическая группа участников. это пользователь. назначать и переназначать исполнителей. НАЗНАЧЕНИЕ ИСПОЛНИТЕЛЕЙ В WS-HUMAN TASK Спецификация WS-Human Task оперирует концепцией универсальная пользовательская роль (generic human role). которые не соответствуют критериям отбора. • Инициатор. связанные с операцией. менять приоритет. Исполнитель может быть выбран только из числа кандидатов. Логическая группа формируется динамически путем запроса к внешнему каталогу пользователей. который назначен на исполнение данного задания. объединенных некоторым общим критерием отбора. • Исключенный из числа исполнителей (excluded owners). • Потенциальные исполнители (potential owners) это группа участников.

д. она продолжает 190 . Универсальные пользовательские роли Потенциальный исполнитель. пустой. Запрос возвращает перечень потенциальных исполнителей. они в ручном режиме выбирают пользователей из корпоративного справочника и устанавливают им роль кандидата. операция м. «Ответственный» и «Администратор». содержать имя единственного исполнителя или включать группу лиц. Выполнение операции начинается с состояния «Создано». отгрузке товара и т. все данные. Для этого осуществляется запрос к внешнему каталогу сотрудников. происходит внутренняя инициализация задания. операция изменяет свое состояние на «Зарезервирована». Если назначение состоится. это участник. Для этого. например принятии важного решения. Опишем основные стадии выполнения операции. соответствующих установленным критериям отбора. аналогичные ответственному. Этот список м.б. По результатам инициализируются универсальные пользовательские роли: «Потенциальные исполнители». Теперь любой из кандидатов сможет самостоятельно назначить себя исполнителем выбранного задания. но не несет ответственности за результат.• Бизнес администратор (business administrator). выполняет функции. В третьем случае. начинается отбор потенциальных исполнителей. Рисунок 9-2). предложена единственному исполнителю или сразу отправлена на «Исполнение». В первом случае операция становится доступной сотрудникам с ролями «Ответственный» и «Администратор». необходимые для выполнения подготовлены. в спецификации WS-Human Task представлена соответствующая модель жизненного цикла (см. видна в рабочем портале каждого из кандидатов в виде нового поручения. • Информируемый (notification recipient). Операция в состоянии «Предложена». задание предлагается каждому из кандидатов. который получает оповещения о заслуживающих его внимания бизнес событиях. Исключенный из числа исполнителей и Актуальный исполнитель связаны с этапами выполнения операции.б. которые могут исполнить задание. Во втором случае.

делегирована другому пользователю или возвращена в состояние «Готова».отображаться в рабочем списке только непосредственного исполнителя и становится недоступной остальным кандидатам. Задача м. если сотрудник решил приступить к исполнению. выполнил все предусмотренные действия. не видна остальным исполнителям. Исполнитель. закрыв ненужное ему задание. В случае же неудачного завершения задачи (завершение с сообщением об ошибке). но не захотел выполнять работу и решил завершить сеанс. находится в состоянии «Зарезервировано». не обязательной для исполнения и пропущена при выполнении. он сможет возобновить работу. операция обрела одного актуального исполнителя. а состояние задания меняется на «В работе». Предположим. при этом снова становится видно всем потенциальным исполнителям. При этом операция возвращается в состояние «Зарезервирована». Теперь назначенный пользователь может выполнить три действия: делегировать операцию другому исполнителю. 191 . При делегировании операция передается другому исполнителю. что исполнитель открыл экранное окно. повторно вызвана на исполнение. пользователь не прерывает работу над заданием. задание переходится в состояние «Приостановлено».б. отменить свое назначение или приступить к исполнению. содержащее реальное поручение. причем остается в состоянии «Зарезервировано». в его экранном интерфейсе открывается окно. будет установлено состояние Пропущена. Если в ходе исполнения задачи возникла неустранимые ошибка. который начал исполнять задание. что бы заняться чем-то другим. Итак. посмотрел поручение. откуда она м. Наконец. состояние изменится на «Ошибка». присутствует у него в очереди входящих заданий. Представим себе. а когда исполнитель освободится.б. При отмене назначения задание возвращается в состояние «Готово». что бы произвести новое назначение исполнителя. может работу приостановить. нажал кнопку закрытия задания «OK». задача переходит в состояние Отказано. при этом задание переходит в состояние «Завершена».

Приостановить
исполнение

Остановить
Продолжить

Конкретный
исполнитель

Отобран 1
кандидат

Состояние «Удалена», соответствует ситуации, когда показатель исполнения процесса (например время) вышел за пределы допустимого диапазона, т.ч задача снята с исполнения.

Рисунок 9-2 Основные стадии выполнения операции

192

10. ПРОЦЕССНЫЕ ПАТТЕРНЫ
В предыдущих разделах мы обсудили по отдельности все
элементы нотации BPMN, используемые для оркестровки, описали семантику их исполнения. Однако если связать в определенную последовательность несколько элементов нотации
BPMN, то их поведение окажется более сложным, чем когда мы
рассматривали их по отдельности.
Термин паттерн в информатике обозначает способ решения характерной задачи проектирования, он определяет типовую последовательность действий для определенных стандартных ситуаций. Набор паттернов, возникающих при моделировании оркестровки бизнес-процессов, был описан и размещен на сайте www.workflowpatterns.com. В первоначальном
виде этот материал касался в первую очередь систем workflow,
затем был адаптирован для BPMN 1.0. Авторы проанализировали работу большинства доступных workflow систем, выделили типовые ситуации и обобщили их в виде типовых последовательностей. В данном разделе мы рассмотрим только типовые модели управления потоками операций, другие типы паттернов: управления данными, обработки исключительных ситуаций и распределения ресурсов остаются вне нашего внимания. Мы не будем рассматривать паттерны в порядке их нумерации, но сгруппируем их так же, как это было предложено авторами классификации.

10.1. БАЗОВЫЕ ПРОЦЕССНЫЕ
ПАТТЕРНЫ
В этом разделе мы рассмотрим простейшие типовые последовательности операций. При этом мы обсудим различные варианты реализации типовых ситуаций, допустимые с точки зрения стандарта BPMN 2.0

193

10.1.1. ПОСЛЕДОВАТЕЛЬНОЕ ИСПОЛНЕНИЕ (CP1)
Последовательное исполнение является наиболее простым
способом реализации процесса, когда каждая последующая
операция начинается только после завершения предыдущей.
При этом выход завершенной операции является входом для
следующей, операции соединены только безусловными переходами, ветвления отсутствуют (см. Рисунок 10-1).

Рисунок 10-1, Последовательное исполнение
Недостатком подобного способа исполнения является высокая
длительность исполнения. Можно предположить, что некоторые операции могут исполняться независимо друг от друга,
при этом их можно исполнять параллельно.

10.1.2. ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ (CP2)
Параллельное исполнение применяется в случае, когда выполняемые операции не зависят одна от другой. Пример (см.
Рисунок 10-2) иллюстрирует способы реализации параллельного исполнения. Во-первых, можно разделить входной поток
при помощи ЛО «И» (рис А), при этом активируются сразу все
выходные ветви, так что операции могут исполняться одновременно. Этот способ является наиболее очевидным с точки
зрения нотации. Во-вторых, можно изобразить одну операцию
и две стрелки безусловных переходов, исходящих из нее (рис.
Б). С точки зрения стандарта BPMN 2.0 конструкция является
допустимой, но некоторые средства моделирования не разрешают изображать два безусловных перехода, исходящие из одной операции. В-третьих, можно изобразить вложенный подпроцесс, объединяющий две суб-задачи, которые будут запущены одновременно (рис В).

194

Рисунок 10-2. Параллельное исполнение

10.1.3. СИНХРОНИЗАЦИЯ ПОТОКОВ (CP3)
Синхронизация означает, что несколько параллельных потоков соединяются в один таким образом, что процесс будет продолжен только после прибытия последнего из входящих. Пример (см. Рисунок 10-3) иллюстрирует варианты реализации паттерна синхронизации потоков. Во-первых, можно использовать
ЛО «И» (рис. А), который сформирует исходящий поток только после того, как на вход поступят все ожидаемые входящие
потоки. Во вторых, можно использовать подпроцесс, содержащий две вложенные задачи (рис. Б).

Рисунок 10-3, Синхронизация потоков

10.1.4. АЛЬТЕРНАТИВА (CP4)
Альтернатива предполагает выбор одной из нескольких исключающих друг друга возможностей продолжения. Разветвление потока на несколько альтернативных ветвей может быть
реализовано несколькими способами. Во-первых, можно использовать разветвляющий ЛО «Исключающее ИЛИ» (см. Рисунок 10-4А). Если операция А, с которой начинается ветвление
- автоматическая, ее следует трактовать и изображать как бизнес правило определения (см. п. 3.1.5), которое устанавливает
195

критерий применимости какого-либо бизнес понятия, называемого фактом. В зависимости от того, истинен факт или ложен, происходит ветвление на один из альтернативных маршрутов.
Условие1

А

Б1

Б1
Условие1
А

Б2

Б2
Условие3

Условие3
А

Б3 В

Б3
Б

Рисунок 10-4, Выбор взаимоисключающих возможностей
Во-вторых, существует альтернативный способ моделирования такого ветвления, изображаемый несколькими стрелками управления, исходящими из одной задачи (Рис. Б). Переходы, выполняемые по условию, помечены мини ромбами. Один
из переходов, выполняемый по умолчанию, если ни одно из
условий не верно, помечен косой чертой. Если операция А является интерактивной, тогда паттерн изображают ветвление,
выполняемое по явному указанию пользователя. В этом случае,
в интерфейсе конечного пользователя д.б. предусмотрено соответствующее число кнопок управления, нажатие на любую
приводит к выбору одного из альтернативных вариантов продолжения.

10.1.5. ПРОСТОЕ СЛИЯНИЕ (CP5)
Простое слияние параллельных ветвей описывает такое объединение потоков, когда каждый из входящих потоков порождает соответствующий экземпляр потока на выходе. Образуется
несколько маркеров потока управления, которые последовательно движутся друг за другом по одному маршруту. Например, мы разослали запросы в несколько подразделений, каждое
подготовило свой ответ, эти ответы рассматриваются по отдельности, по мере их поступления. Следует быть вниматель196

сколько маркеров потока управления придет из параллельных ветвей. Но в этом случае. следует позаботиться. Поток управления по любой из входящих ветвей создает поток управления на выходе.о. В большинстве случаев. следующая за простым слиянием. Для этого ЛО ветвления и слияния «Исключающее ИЛИ» должны использоваться в паре. Простое слияние 197 . Дело в том. активной.б. при этом первый поток не дожидается следующего и сразу проходит на выход. Во-первых. будет выполнена столько раз. Рисунок 10-5. найти и отследить поведение парного оператора ветвления будет сложнее. такое поведение не является ожидаемым. Т. в текущий момент времени только одна из параллельных ветвей м. Второй вариант предполагает. поскольку нам кажется. Рисунок 10-5А). а последовательно. поскольку операция. Простое слияние альтернативных параллельных потоков может быть реализовано несколькими способами. можно воспользоваться объединяющим ЛО «Исключающее ИЛИ» (см. а если на вход поступят сразу оба потока.ными. Для этой ситуации справедливы сделанные выше замечания об альтернативности входных потоков. что узел «исключающее ИЛИ» пропускает на выход только один из входящих потоков. что на вход некоторой операции соединен с выходами нескольких предшествующих операций. так что каждый из них инициирует исполнение операции В (см. то узел не сработает. Рисунок 10-5Б). что бы входящие ПУ были действительно альтернативными. Такое поведение может оказаться неожиданным. что потоки приходят на узел не одновременно.

зависит от обстоятельств аварии. для которых выполняется некоторое условие. Во-вторых. Для реализации паттерна можно использовать три формы записи. может быть выбрано сразу несколько или ни одного варианта продолжения. Какие службы будут вызваны. Если несколько условий выполняются одновременно. что будут вызваны все службы или ни одной. Например. то будут активированы сразу несколько выходных потоков.6. Рисунок 10-6А). может случиться. Б1 Условие1 А Условие1 Б2 Условие3 А Б2 Условие3 Б3 А Б Б1 Условие1 А Б1 Б2 Условие3 Б3 В В Рисунок 10-6. может быть использована форма записи. Б). можно использовать оператор «ИЛИ» (см. оператор должен оповестить оперативные службы.1. когда несколько переходов исходят из одной операции (см. Множественный выбор 198 Б3 . Рис В). Во-первых. когда необходимо активировать часть из параллельных ветвей. МНОЖЕСТВЕННЫЙ ВЫБОР (CP6) Множественный выбор используется.10. В-третьих. В отличие от Альтернативы. можно использовать оператор ЛО «Комплексное условие» (Рис. клиент позвонил в call-центр и сообщил об аварии.

Этот паттерн называется структурным. изображенной на рисунке В справедливы ранее сделанные замечания о сложности в отслеживания непарных ЛО ветвления и слияния.2. 10. Рисунок 10-7) иллюстрирует использование парных операторов ветвления и слияния «Исключающее 199 . теперь мы ожидаем. они должны быть явно выделены в тексте программы.2. Исполнение будет продолжено.1. СТРУКТУРИРОВАННОЕ СЛИЯНИЕ С СИНХРОНИЗАЦИЕЙ (CP7) Структурированное слияние с синхронизацией показывает деление одного потока на несколько параллельных ветвей. прихода подтверждений оповещения из обеих ветвей. Проблема при синхронизации нескольких параллельных ветвей возникает. Одно из возможных решений заключается в том. когда нам заранее не известно число ожидаемых входящих потоков.2. когда поступит последнее оповещение. а затем их слияние в единый поток. Хочется провести аналогию с открывающей и закрывающей скобками в обычном программировании. что для формы записи. 10.Следует иметь в виду. Пример (см. ПАТТЕРНЫ СЛИЯНИЯ И СИНХРОНИЗАЦИИ Эта группа паттернов описывает более сложные сценарии объединения потоков. в случае наступления аварии мы оповестили две из трех служб. 10. только после того. Например. что бы использовать операторы разветвления и слияния в паре. который возникнет. поскольку узлы ветвления и слияния используются парно. что парные логические операторы должны быть явно видны на схеме процесса. СТРУКТУРИРОВАННЫЕ ПАТТЕРНЫ Термин структурированный означает.2. как все ранее активированные параллельные потоки будут завершены.

ЛО слияния узнает число входящих ветвей от предшествующего парного ЛО ветвления (см. то на выходе слияния сразу возникает выходной поток. 5. Рисунок 10-8А) показывает парные ЛО ветвления и слияния «И». Б) показывает парные ЛО ветвления и слияния «ИЛИ». Рисунок 10-7.2. Рис. Рисунок 10-8. Как ранее отмечалось.2. Структурированное слияние с синхронизацией 10.2). где узлы ветвления и слияния используются непарно. Параллельные маршруты являются альтернативными.3. Пример (см. Узел слияния ждет поступления (синхронизации) всех входных потоков. Если при ветвлении была активирована только одна ветвь. п. а если при ветвлении были активированы несколько потоков. Усложним пример из предыдуще200 . то следует ждать окончания (синхронизации) последнего. НЕСТРУКТУРИРОЫВАННЫЕ ПАТТЕРНЫ Неструктурированные паттерны. В обоих случаях одному потоку на входе соответствует ровно один на выходе. Парные операторы альтернативный выбор Пример (см.ИЛИ». поэтому на выходе формируется только один ПУ.

Однако после завершения операции Б1 один из потоков не поступит на узел слияния. разместим между парными узлами ветвления и слияния «И» дополнительный ЛО ветвления «исключающее ИЛИ» (см. Возникает тупиковая ситуация (DEAD LOCK). поток из этой ветви не поступит на вход узла слияния «ИЛИ». тупиковая ситуация оказывается невозможна (см. Рисунок 10-9). то коллизия исчезает. Поскольку при первом ветвлении были созданы два потока. направленные на операции Б1 и Б2. Рисунок 10-9 Неструктурированный паттерн Но если мы добавим в схему парный узел слияния «ИЛИ. Рисунок 10-10 Структурированный паттерн 201 .го параграфа. т. Рисунок 10-10). то следующей будет исполнена операция Г. После завершения операции Б1 выходной поток поступает на ЛО «исключающее ИЛИ». узел слияния «И» будет ожидать появления двух ПУ.ч. Если выполняется Условие1. В результате первого ветвления «И» возникнут два потока.

Непарные узлы ветвления и слияния 10. Общее число входящих потоков заранее известно. будет выполнена столько раз. узел бу202 . В результате операция. МНОЖЕСТВЕННОЕ СЛИЯНИЕ (CP8) Множественное слияние демонстрирует пример непарного использования ЛО ветвления и слияния.2. Пример (см. узел слияния вырабатывает маркер на выходе.10. которая расположена после узла слияния. но игнорирует их. формирует на выходе отдельный маркер потока управления. что каждый из потоков. в том числе непарному слиянию. а слияние «исключающее ИЛИ» пропустит на выход поток из каждой параллельной ветви. ДИСКРИМИНАТОР (CP9) Дискриминатор описывает слияние нескольких параллельных потоков управления таким образом. Только когда поступит последний параллельный ПУ. что после поступления первого потока управления из параллельных входных ветвей. поскольку такое поведение может идти в разрез с первоначально планируемой логикой процесса.2. Рисунок 10-11) показывает модель. где осуществляется ветвление на параллельные потоки. при этом он продолжает принимать оставшиеся входящие ПУ. Аналитик должен крайне внимательно относится к не структурированным паттернам. операция В будет выполнена столько раз. прибывающих по параллельным входным ветвям. сколько параллельных потоков поступило на вход узла слияния. Б1 А Б2 В Б3 Рисунок 10-11.4. Его особенность в том. сколько параллельных ветвей приходит на узел слияния.5. В результате.

выполнение паттерна связанно со следующими условиями: • Паттерн описывает объединение потоков. а для объединения потоков используется ЛО комплексное условие.о. 203 . Т. Б1 А Б2 В Б3 Рисунок 10-12. мы проводим конкурс и рассылаем приглашения участникам. Простейший способ реализовать дискриминатор заключается в использовании ЛО комплексное условие. Структурный дискриминатор отличается от паттерна Синхронизация. а второй всех входных потоков управления.дет сброшен в исходное состояние. Рисунок 10-12А) изображает схему. Дискриминатор На исполнение параллельных ветвей следует наложить определенные ограничения. тем. Конкурс будет завершен только после получения и обработки всех ответов на разосланные приглашения. Кандидаты задают вопросы и получают на них ответы. Например. так что он будет готов снова выполнить свою функцию. которые были ранее разделены одним узлом ветвления. что первый ждет появления первого потока управления. затем дают ответ на приглашение. Например. на которой ветвление осуществляется с использованием ЛО «И». они не должны создавать и не уничтожать потоки управления. Пример (см. Число кандидатов заранее известно. • В параллельных ветвях допускаются только парные ЛО ветвления и слияния. При этом мы продолжим отвечать на вопросы остальных участников. Победителем будет объявлен первый. кто пришлет подтверждение.

Дискриминатор. Рисунок 10-13). так что будет готов снова выполнить свою функцию. В общем случае. счетчик 204 . завершены только если работа всего процесса будет прекращена.б. узел будет сброшен в исходное состояние. Ни одна из параллельных ветвей не м. после чего вырабатывает выходной сигнал (см. В этом случае. как работа подпроцесса будет завершена. Рисунок 10-13.б. называемой Счетчик. завершена независимо от остальных. Например. как искомое число N ПУ из параллельных ветвей поступило. После того. паттерн дискриминатор может использоваться. но нас интересует синхронизация только первых N из них (N<M).• • Каждая из ветвей м. что бы объединить и синхронизировать некоторое подмножество из всего множества входящих потоков. начнется исполнение задачи В. Альтернативный способ реализации дискриминатора предполагает использование задачи. После того. Последний суммирует число прошедших через него маркеров потока управления. которое вырабатывает сигнал ошибка.б. на вход приходит M параллельных потоков. все еще не завершенные параллельные потоки будут остановлены. прерывающий работу всего подпроцесса. Перехватывающее прикрепленное событие-ошибка указывает на сценарий продолжения. узел вырабатывает выходной ПУ. исполнена только однократно. Поскольку следующим исполняется промежуточное событие ошибка. Ветви м. Только когда поступит последний поток номер M из параллельной ветви. при этом он продолжает принимать оставшиеся входящие (M-N) ПУ и игнорирует их.

в цикле. что бы ожидаемое число сигналов не превышало количества входных ветвей узла слияния.3. ИТЕРАЦИЯ (CP21) Итерация описывает многократное повторение задания или подпроцесса. то выполняется операция Б. когда некоторый фрагмент процесса требуется многократно повторить.3. 10.Следует позаботиться. то работу следует выполнить повторно. Рис. Часто возникает ситуация. МНОГОКРАТНОЕ ПОВТОРЕНИЕ (CP10) Многократное повторение описывает повторное исполнение отдельной операции или группы задач. Пример (см.2. ИТЕРАЦИИ Эта группа паттернов описывает ситуации. если в результате обработки обнаружен исправимый брак. Многократное повторение 10. Например. 10. то происходит ветвление потока и повторное исполнение задачи А. когда операция или подпроцесс исполняются итеративно. Рисунок 10-14) показывает подпро205 .3.1. Для реализации такой конструкции можно использовать несколько вариантов записи. Пример (см. Если результат достигнут. Второй пример (см. Рисунок 10-14. Б) показывает реализацию цикла Repeat-Until. Рисунок 10-14А) показывает реализацию цикла Do-While. в противном случае возникнет тупиковая ситуация. Если результат обработки не достигнут.

п. при каждой итерации будет создаваться новая копия подпроцесса. исполняемых одновременно.о. полученные в ходе первой итерации. результаты. Рисунок 10-15. Будем различать параллель206 . будут перезаписаны при втором повторении и т. Однако когда все итерации будут завершены. сколько указано в условии повторения. Вложенный подпроцесс имеет непосредственный доступ к объектам данных процесса. Глобально известный подпроцесс не имеет доступа к данным родительского процесса.2.3. В нотации BPMN рекурсия возможна только для повторно используемых процессов. поэтому. Поэтому. 3. РЕКУРСИИВНОЕ ИСПОЛНЕНИЕ (CP22) Рекурсия в программировании есть вызов функции или процедуры из неё же самой. 10.4. поле завершения нужного числа повторений сохранятся результаты только последней итерации. возникает задача объединить все данные разных экземпляров и вернуть результат в вызывающий родительский процесс. Итерация Следует обратить внимание на существенные отличия в исполнении простого вложенного и глобально известного подпроцессов. Поскольку при каждом вызове подпроцесс порождается новая копия данных. Есть возможность указать способ исполнения циклов: Do-While или Repeat-Until (см. рекурсивный вызов подпроцесса не нарушит целостности данных.3. 10. ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ Паттерны в этом разделе описывают ситуацию. исполняемый итеративно столько раз. со своим набором данных. когда одна операция на модели процесса будет исполнена многократно. Т.цесс.д.3). при этом возникнет несколько экземпляров потока управления.

При этом возможны ситуации конкуренции доступа.4. При каждой итерации будет создан отдельный экземпляр данных. 10. ветви исполняются одновременно и асинхронно друг от друга. полученные в результате первого прогона. а во второй появились замечания. логический оператор ветвления «И» порождает несколько потоков управления («Параллельное исполнение (CP2)»). Синхронизация (ожидание окончания последнего из них) отсутствует.ное исполнение и последовательные итерации. В первом случае следует продумать ситуацию. так что результаты. при параллельном согласовании возможна ситуация. этот паттерн для каждой итерации порождает отдельный маркер потока управления на выходе. Во втором случае. 207 . В отличие от паттерна многократного повторения CP10.д. каждый со своим набором данных. Теперь надо консолидировать информацию из обеих ветвей и принять согласованное решение. ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ БЕЗ СИНХРОНИЗАЦИИ (CP12) Параллельное исполнение без синхронизации моделирует параллельное исполнение некоторой операции или группы операций. В первом случае одна операция или группа задач исполняются последовательно требуемое число раз. Пример (см. исполняемую в цикле. поступят на вход второго и т. в окружении которых будет исполняться образ процесса. Например. При этом в любой момент времени существует только один поток управления. связанную с одновременным доступом разных потоков к общим данным. При этом возникает вопрос.д. блокировки. Например. когда в одной ветви согласование прошло. который обрабатывает один набор данных.1. работают ли параллельные экземпляры с одним набором данных или каждый со своей копией. Во втором случае возникает много параллельных потоков управления. необходимо предусмотреть консолидацию данных из параллельных ветвей. гонки и т. Рисунок 10-16) изображает задачу.

ПАРА АЛЛЕЛ ЛЬНОЕ Е ИСПО ОЛНЕН НИЕ С СИНХ ХРОНИ ИЗАЦИ ИЕЙ. ск колько паралле п ельных экземп пляров было б иссполнен но. Рисуно ок 10-177) иллю юстриру ует пат-терн паараллел льного исполне и ения. ЧИСЛО Ч О ЭКЗЕ ЕМПЛ ЛЯРОВ ИЗВЕ ЕСТНО О НА ЭТАПЕ МОДЕ ЕЛИРО ОВАНИ ИЯ (CP13) Паралл лельно ое испол лнениее с синх хронизаацией ((число экземпэ ляров известн но на этапе э м моделир рования) реали изуется анало-дущему у. Семан-тика паараллельного исп полнени ия). 10. число ч п повторе ений за адается я гично предыд внутреенним атрибут а том loop pCardin nality.. Рисуно ок 10-17. Прим мер (см м.4. причем м послее заверш шения всех в пар раллельн ных экзземпля-ров. Параллеельное исполненние с синнхронизаацией (чи исло экзем мпляров в известнно на этапе модел лирования) 208 8 . при этом.Ри исунок 100-16. Пар раллельнное испо олнение без б синххронизац ции Вн нутренн ний атр рибут MultiInsta M anceBehaavior оп пределяеет спо-соб син нхрониззации экземпл э ляров за адачи (ссм. компл лексноее услови ие создан ния мар ркеров потока п управления. Вел личина а All: оп-ределя яет. Табллица 3-4. который к й имеетт значе-ние ко онстантаа. На Н выхо оде образуется стольк ко маркееров по отока уп правле-ния. Н . Знач чение None. Зна-чение One укаазывает.2.. Наконец.. что од дин мар ркер потока уп правлен ния соз-дается после заверше з ения пеервого экземпл э ляра. что будет создан с только один маркер м потока управ-ления. N что о маркееры по-тока уп правлен ния созд даются после заверше з ения кааждого экземпэ ляра. услови ие Complex зад дает сосставное.

При-мер (см м. котораая вычи исляется я на этаапе испо олнения я.5.5. 10. когдаа резулььтат нее достигн нут.Рисун нок 10-18) иллю юстрирует патттерн п параллеельного о исполн нения. Рисуно ок 10-18. а си итуация я. он о фик-сируеттся в ин нформационно ом объеекте и определ о ляет ста атус ис-полнен ния про оцесса.1. успеш-но ли законче з ен очереедной этап. то про оисходи ит норм мальное продол лжениее – перех ход на следую ющий эттап. ПАРА АЛЛЕЛ ЛЬНОЕ Е ИСПО ОЛНЕН НИЕ. что бы б провверить. П Перечисл ленныее ниже паттерн п ны связааны с анализо а ом состо ояния сстатуса испол-нения процесс п са..4. каждый й из котторых связан с с достиж жением м опредееленной й цели. Параллеельное исполненние с синнхронизаацией (чи исло экз земпляро ов извесстно на эттапе испполненияя) 10. Обычн но этап заверш шается приняттием реешения. раассматри ивается я как бр рак. при этом. зна ачение которог к го опред деляет-ся фор рмулой. Реззультатт выполн нения этапа э ессть покаазатель продук кта проц цесса.. Таким Т о образом м. э сл ледует оценить о ь состоя яние со-ответсттвующеего инф формац ционногго объеекта. Ч ЧИСЛО О ЭКЗЕ ЕМПЛЯ ЯРОВ ИЗВЕС И СТНО НА Н ЭТ ТАПЕ ИСПО ОЛНЕН НИЯ (C CP14) Паралл лельно ое испол лнениее с синх хронизаацией ((число экземпэ ляров известн и но на эттапе исп полнения) реаализуетсся анал логично о предыд дущему у.. Есл ли ожид даемый й результтат досттигнут.3. важно ого для я выполн нения всего в би изнес-процесса а в цело ом.10. э чи исло по овторени ий задаается вн нутрен-ним аттрибуто ом loopC Cardinallity. ОТЛО ОЖЕННЫЙ ВЫБО В ОР (CP116) Отлож женный й выбор р показы ывает ветвлени в ие проц цесса в зависиз 209 9 . происходи ит отка аз в об-служиввании или и воззврат наа повто орную обработ о тку. СТА АТУС ИСП ПОЛН НЕНИ ИЯ Весь мааршрутт исполн нения процесса п а можно о раздел лить на а этапы.

определяет пользователь в момент исполнения. Рис. Причем в любой момент времени может исполняться только один из наборов. Выбор нужной подзадачи осуществ210 . Рисунок 10-19). а порядок их исполнения и число повторений в модели не определены. 10.мости от внешнего события. Порядок. управляемое результатом события.5). Для реализации паттерна следует использовать ситуационные Ad-Hoc процессы (см. который моделирует решение. причем с каждым возможным выходным маршрутом связанно отдельное перехватывающее событие. семантика этих элементов не отличается.2. когда в процессе фиксируется только набор операций.5. Рисунок 10-19. Во втором случае (см. вариант продолжения зависит от результатов исполнения внешнего процесса. Мы сможем узнать о наступлении события благодаря оповещению. используется событийный оператор «Исключающее ИЛИ». в котором исполняются наборы и число повторений. Каждый набор может включать единственную операцию или некоторую последовательность операций. п. вместо элемента событие используются задания Отправить-Получить сообщения. Рис. 3.Рисунок 10-19Б). которая содержит две подзадачи А и Б. Рисунок 10-20А) показывает задачу с маркером Ad-Hoc.2. произошедшего в некотором другом процессе. ЧЕРЕДОВАНИЕ МАРШРУТОВ (CP17) Чередование маршрутов описывает ситуацию. А). Таким образом. Отложенный выбор В первом случае (см. Как мы знаем. Можно предложить рассмотреть несколько вариантов решения задачи (см. пересылаемому в форме сообщения. Пример (см.

Б).3. Реализация этого сценария осложняется тем. Во втором случае (см. Рис. Хотя большинство BPMS систем включают программный интерфейс. что выбор маршрута продолжения осуществляется с использованием сообщений. что бы «приостановить-продолжить» исполнение задания. которая содержит две упорядоченные последовательности действий А1-А2 и Б1-Б2. если маркер потока в другой ветви уже достиг определенного этапа. 211 . Третий вариант (см.5. что в нотации BPMN не предусмотрены средства. 9. когда операция в одной ветви может быть исполнена. что операция д. выполнение задачи запрещено. позволяющие управлять статусом исполнения задачи (см. И наоборот. операция с маркером Ad-Hoc. п. Чередование маршрутов 10. Это означает. однако он не доступен для моделирования на схеме процесса. Рисунок 10-20. отправляемых извне. если маркер потока в другой ветви уже закончил некоторый этап.5). Выбор варианта продолжения осуществляется пользователем. КООРДИНАЦИЮ ИСПОЛНЕНИЯ (CP18) Координация исполнения описывает согласованное выполнения двух процессов или параллельных ветвей одного процесса. снята с исполнения.ляет исполнитель. В). Рис.б. предполагает.

6. что процесс п заканч чивается я.1. Риссунок 100-21) илл люстрирует си итуацию ю.. Для я модел лирован ния этап пов исп полнени ия испо ользова-ны про омежуто очные события с я. когдаа заверш шится иссполнен ние всех порож жденны ых в дан нном пр роцессее потоко ов управвления. когдаа операц ция Б может м бы ыть исп полнена а только о парал ллельно о с опе-рацией й А. Для управ-ления исполн и нением другой д ветви можно м и использ зовать прикреп пленны ые обраабатываающие прерыва п ающие событи ия. Первоее разреш шает иссполнен ние. ЯВНО ОЕ ЗАВ ВЕРШЕ ЕНИЕ (CP11) ( Явное заверш шение означает о т. а резульр таты работы утеряны у ы. Рисунокк 10-21.6. (см. 212 2 . она не примен нима к парал-лельны ым ветвя ям одно ого про оцесса. до олжны заканчи иваться я явным м завер-шающи им собы ытием. включ чая влож женныее и выззываемы ые под-процесссы. подпроц п цесса ил ли всего о процессса цели иком 10. посколь п ьку бази ируется я на со-общени иях. К том му же. ПАТ ТТЕРН НЫ ЗАВЕР З РШЕН НИЯ Эти пааттерны ы описыввают сц ценарии и заверш шения о отдельн ной вет-ви проц цесса. что если е оп перация я Б не бу удет за-вершен на до ок кончани ия задач чи А. а втторое заапрещаает. которы ые не со оединя-ются с другим ми ветввями. Недо остаток к этой сх хемы зак ключается в то ом. Для я этого все веттви про оцесса. размеещенны ые в одн ной из ветвей. он на будеет прерввана. Координа К ация исполненияя 10.Пр ример.

Пример (см. следует использовать завершающее событие отмена (см. Б). Рис. еще не завершенных ветвях процесса. Завершение первой из них не окажет влияние на вторую. Явное завершение Однако модель с явным завершением может иметь не детерминированную семантику исполнения (см. не детерминированная семантика исполнения 10. Если ветвь Б завершится первой.ч.6. процесс полностью завершится только после окончания второй ветви. Рисунок 10-22А) показывает процесс. Однако мы не узнаем. которое прекратит исполнение во всех.2. когда по каким-то причинам необходимо прервать и прекратить 213 . была ли начата операция Г. который имеет завершающие события в обеих параллельных ветвях. выполнение ветви В будет прервано. Рисунок 10-22. Рисунок 10-23. была ли завершена операция В и с каким результатом. будет инициировано завершающее событие. Явное завершение. Т. Рисунок 10-23). ПРЕКРАТИТЬ ИСПОЛНЕНИЕ ЗАДАНИЯ (CP19) Прекращение исполнения задания описывает ситуацию. Что бы завершение ветви прекращало исполнение всего процесса.

бу удет выззван обр работчи ик. кото орый пеередаст управ-ление а задачу у Б. который к й перед даст упр равлени ие в зад дачу Б.исполн нение то олько од дной оп перации и процеесса. Преккратить исполнен и ние задания 10. РезульР таты рааботы задачи A будутт утерян ны.6.. если и они н не записсаны наа внешни их хран нилищаах данны ых. Резу ультаты ы ранеее выполн ненной работы ы будутт утерян ны. будет вызван н обрабо отчик. когда по п каки им-то причинаам необ бходимо о прерввать и прекрап тить исполне и ение всеего про оцесса целико ом. Прекр ратить исполненние процеесса 10.4. раб бота этого подп процесса будетт перерввана.6.3. ПРЕК КРАТИ ИТЬ ИС СПОЛН НЕНИЕ Е ПРОЦ ЦЕССА А (CP20) Прекращениее исполнения я проц цесса. Рисунок 10-225. выполн нение этой э зад дачи буд дет пер рервано. опи исывает ситуа-214 4 . ( Риссунок 100-24) пок казываеет задач чу А с прикреп пленны ым прер рывающ щим со обытием м. ПРЕК КРАТИ ИТЬ ИС СПОЛН НЕНИЕ Е ГРУП ППЫ ОПЕР РАЦИЙ Й (CP225) Прекращениее испол лнения я групп пы задаач. Резу ультаты ы работы ы задач чи A буд дут утер ряны. При имер (Р Рисунок 10-25) показып вает по одпроцеесс А с прикре п епленны ым прер рывающ щим соб бытием. Риссунок 10--24. В случаае насту упления я событтия. В слу учае нааступлен ния со-бытия. Пр ример (см. описыва о ает ситтуацию.

порожденных многопоточной операцией A. которые прикрепляются к соответствующей операции. работа этой группы будет перервана. В случае наступления события.б. Прекратить исполнение группы задач 10. будут остановлены и завершены. которые еще не завершились. прервано в любой момент времени. 215 . когда по каким-то причинам необходимо прервать и прекратить исполнение задачи. Рисунок 10-27) изображает прикрепленное событие. Остановка не затронет ранее завершившиеся экземпляры операции.5.н. описывает ситуацию. которое прерывает исполнение всех еще не завершенных экземпляров. Выполнение многопоточной задачи м. Пример (см. когда по каким-то причинам необходимо прервать и прекратить исполнение одной или нескольких задач. Этот паттерн использует особенности т. к которой прикреплено прерывающее событие. прерывающих событий. А Б В Г Рисунок 10-26.6. Результаты работы группы A и Б будут утеряны. Пример (см. а результаты их работы утеряны. который передаст управление а задачу Г. ПРЕКРАТИТЬ ИСПОЛНЕНИЕ МНОГОПОТОЧНОЙ ОПЕРАЦИИ (CP26) Прекращение исполнения многопоточной операции. те экземпляры. Рисунок 10-26) изображает группу из двух задач А и Б). связанны между собой.б. будет вызван обработчик. При этом.цию. имеющей маркер многопоточного исполнения. Задачи не обязательно д.

то олько после п пр рихода оповещ о щения.1. В точноее событи качествве оповеещения я могут использзоваться я событтия и си игналы. только если поток п уп правлен ния ужее находи ится наа элемен нте собы ытие и ожидае о ет прихо ода опо овещени ия. Пр ример (см. Если и собы-тие произошл ло. 10.Ри исунок 100-27. но ПУ П ещее не при ишел до о элемеента пр ромежу-ие. когд да испо олнениее процеесса осстанавли ивается я послее достиж жения элемент э та пром межуточ чное со обытие. Этотт сигнал л иниц циируетт продол лжение исполн нения. С Схема моделим руемогго проц цесса мо ожет вк ключатьь элемеент собы ытие. Испол лнениее будет продолж п жено..33) мы до оговори ились раазделятть событтия как к явлени ия и соб бытия как к прогграмму обрабо отчик.. Паттерн П н называается об бработч чик без запоми инания я события. пока н не будетт полу-чен си игнал изз внешн него иссточник ка. СИН НХРО ОНИЗ ЗАЦИ ИЯ С ПОМО П ОЩЬЮ СОБ БЫТИ ИЙ Эти пааттерны ы описсывают взаимо одействвие (син нхрони изацию) процессса с др ругими процесссами по осредством мех ханизма а собы-тия. посскольку у он сраб ботает.7. Будем разделя ять: обр работчи ики безз запоми инания событи ия и с запомин з нанием. СИНХ ХРОНИ ИЗАЦИ ИЯ БЕЗ З ЗАПОМИН НАНИЯ Я ОПОВ ВЕЩЕН НИЯ (C CP23) Синхронизац ция без запоми инания я оповещ щения описыввает си-туацию ю.7. В парагра п афе (4. Эти пааттерны ы нахо-дят ши ирокое примен п нение пр ри оркеестровк ке неско ольких взаимов действу ующих процесссов. то оповеще о ение нее запоми инается я и теря яется. ( Рисунок 10--28) илл люстрир рует Си инхрони изацию ю 216 6 . Преекратить исполнеение мно огопоточной задаачи 10. которое к е приосттанавли ивает иссполнен ние до тех т пор.

он сможет обработать оповещение и продолжит исполнение без ожидания. оно будет утеряно. когда маркер достигнет узла. так что позднее.без запоминания события между Процессом1 и Процессом2. При этом оповещение запоминается и не теряется. начнет исполняться операция Г. СИНХРОНИЗАЦИЯ С ЗАПОМИНАНИЕМ ОПОВЕЩЕНИЯ (CP24) Синхронизация с запоминанием оповещения работает так же как предыдущий паттерн. а маркер потока управления еще не дошел до элемента промежуточное событие. но вдобавок он позволяет обработать ситуацию. Некоторые BPMS реализуют интеграцию с внешними средствами работы с очередями сообщений. После выполнения задачи В маркер потока управления доходит до промежуточного обрабатывающего элемента событие и останавливается. Если из Процесса1 поступит сигнал. когда событие произошло. Рисунок 10-28. Нотация BPMN не поддерживает этот паттерн. Последние помогают запомнить сообщение. Если оповещение поступит до того. как маркер потока управления достигнет узла промежуточное событие. Для других видов оповещений такая возможность не предусмотрена. однако он может реализовываться внешними средствами.2. исполнение будет продолжено. Синхронизация без запоминания оповещения 10.7. 217 .

для моделирования информационного взаимодействие между процессами следует использовать потоки сообщений. можно рассматривать диаграммы взаимодействия как дальнейшее развитие публичных процессов (см. отображающие роли сотрудников. п. либо указывать обобщенное имя. состав работ в каждом процессе не отображается. управляемыми по отдельности. «Заказчик». Неправильно ассоциировать потоки сообщений с конкретными физическими способами передачи информации между участниками. Пример (см.11.3). Следует говорить о взаимодействии типа B2B.о. осуществляемом между несколькими юридическими лицами.1. Рисунок 11-1) изображает схему взаимодействия заказчика и клиента. например: «Поставщик». работающих в соответствующем юридическом лице.д. 2. что потоки управления не могут пересекать границы пула. Вспомним. В этом случае.ч. факсом или обычной почтой. «Государственная страховая компания» и т. На верхнем (концептуальном) уровне мы изображаем процессы в виде «черных ящиков» и специфицировать только обмен сообщениями между пулами. Каждый пул может содержать дорожки. которое характеризует группу участников. УРОВНИ ВЗАИМОДЕЙСТВИЯ Описание взаимодействия процессов может выполнить с разной степенью детализации.1. Т. каждый из своего единимого центра. «Покупатель». Нас пока не интересуют детали выполне218 .. Организация участник взаимодействия на схеме моделируется пулом. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ Схема взаимодействия (collaboration) показывает информационный обмен сообщениями между двумя и более участниками. т.5. Пул может однозначно идентифицировать участника по имени организации. а последовательность обмена сообщениями не устанавливается. 11. например: «Первый народный банк». например с электронной почтой.

закрытый процесс На следующем уровне детализации изображаются открытые процессы. Здесь представлены последовательности выполнения операций. Во-первых. возникает операция защитить эту информацию. как выполняется процесс внутри компании. открытый процесс На уровне «белых ящиков» действия обоих участников взаимодействия специфицируются детально. В этом случае. операции. выполняемые заказчиком и 219 . которые выполняет заказчик. Рисунок 11-2). на схеме в одном из пулов изображаются операции. Рассмотрим моделирование открытых процессов для обоих участников взаимодействия (см. Рисунок 11-1. и. диаграмма процесса не перегружена излишней информацией о том. Использование схем закрытых процессов оправдано по нескольким причинам. процессы зачастую составляют интеллектуальную собственность организации. Рисунок 11-2. Межорганизационное взаимодействие. разумеется. а второй пул при этом может оставаться «черным ящиком» (см. Применительно к нашему примеру. отвечающие за отправку и получение сообщений. Во-вторых. изображаются на схеме. Межорганизационное взаимодействие.ния процессов или порядок обмена сообщениями между двумя контрагентами. Рисунок 11-3). схема показывает некий диалог участников. в то время как действия клиента по-прежнему не специфицируется.

Детализация межорганизационного взаимодействия 11. МНОЖЕСТВЕННЫЕ УЧАСТНИКИ ВЗАИМОДЕЙСТВИЯ В рассмотренном примере мы использовали сущность «Клиент». Внутренние операции обоих участников.2. Рисунок 12-2) изображает взаимодействие одного заказчика (показан обычным пулом) со множеством клиентов (показаны мульти-пулом). Рисунок 11-3. что компания одновременно может взаимодействовать не с одним клиентов. Пример (см. 220 .клиентом. Что бы отобразить на схеме множественного участника. не связанные с межорганизационным взаимодействием. а со многими. понятно. знак Пул может иметь специальный маркер множественный участник. точно так же в процессе могут участвовать несколько «Поставщиков» или «Производителей». остаются за рамками диаграмм взаимодействия.

на схеме описывается событийная последовательность выполнения операций в процессе. Таблица 11-1. Во втором случае на схеме изображается логическая цепочка обмена сообщениями между участниками. управляемыми по-отдельности.Рисунок 11-4. Число участников взаимодействия Атрибут minimum maximum numParticipants Пояснение Целое число. определяет участников взаимодействия 11. Кроме того. комбинируя их между собой. которые позволяют указать число множественных участников взаимодействия. определяет минимально допустимое число участников взаимодействия Целое число.3. Тем не менее. Типовые конструкции (паттерны). типовые конст221 . В дальнейшем можно описать хореографию процесса. предназначены для моделирования простейших (элементарных) типов межпроцессного взаимодействия. управляемом из единого центра. В первом случае. определяет максимально допустимое число участников взаимодействия Целое число. существуют некоторые различия между оркестровкой процесса и описанием его взаимодействия с другими процессами. Мульти-пул Графический элемент мульти-пул имеет специальные атрибуты. ПАТТЕРНЫ МЕЖОРГАНИЗАЦИОННОГО ВЗАИМОДЕЙСТВИЯ Ранее мы рассматривали приемы разработки диаграмм оркестровки. которые рассматриваются в данном разделе.

1. в зависимости от момента выбора адресата сообщения: во время выполнения экземпляра процесса либо на диаграмме хореографии. выделяют одиночные и множественные межпроцессные взаимодействия. Существуют различные разновидности данного паттерна.рукции используются так же для верификации языков исполнения бизнес-процессов. В зависимости от количества адресатов. Двустороннее взаимодействие включает всего двух участников. • По количеству переданных сообщений. Телефонный провайдер уведомляет заказчика о необходимости оплаты задолженности. Поскольку средств BPMN не достаточно для исчерпывающего описания паттернов. Рисунок 11-5) иллюстрирует использование паттерна отправки сообщения. в то время как многостороннее . Для графического изображения паттернов будем использовать нотацию BPMN. Паттерн отправка сообщения 222 . Предложим следующую классификацию паттернов межпроцессного взаимодействия: • По количеству вовлеченных участников. будем использовать так же текстовые спецификации для каждого из них. ОТПРАВКА СООБЩЕНИЯ Паттерн описывает ситуацию однонаправленной передачи сообщения от отправителя к адресату.3. 11. Рисунок 11-5.нескольких (более двух). Графический элемент пул используется на диаграмме для отображения участников взаимодействия. Пример (см.

В первом случае накапливается очередь сообщений. когда один адресант отправляет сообщение другому адресату. Различают два способа использования паттерна в зависимости от наличия или отсутствия буфера сообщений у адресата. в рамках которого проверяются операции. Отправленное сообщение инициирует новый процесс. произведенные по счету.3... которые будут обработаны получателем по мере возможности.3. Отдел закупок посылает запрос поставщику. сообщение отменяется..3. Клиент Уведомление Проверить операции по счету .2. если в процессе подразумевается использовать параллельный обмен сообщениями между различными участниками одного типа. а обратно получает от него ответ. если поставщиков несколько. Рисунок 11-7 иллюстрирует описанный выше паттерн. В случае... Пример (см. Отправить уведомление .. Во втором случае. Оба сообщения пересылаются между одними и теми же участниками. . если по какой-либо причине адресат не может него обработать моментально. В случае. ОТПРАВКА / ПОЛУЧЕНИЕ СООБЩЕНИЯ Паттерн описывает ситуацию. то ответ должен приходить в тот экземпляр процесса. но теперь уже с позиции адресата. Рисунок 11-6) иллюстрирует использование паттерна получения сообщения адресатом. а в ответ получает коммерческое предложение. Паттерн получение сообщения 11. 223 .11. ПОЛУЧЕНИЕ СООБЩЕНИЯ Банк Паттерн описывает ситуацию однонаправленной передачи сообщения от отправителя к получателю. то тогда необходимо связать между собой соответствующие пары запрос/ответ. Рисунок 11-6.

Рисунок 5. Для этого. от отправителя и т. Паттерн очереди сообщений не покрывает описание этого паттерна (см. 224 . сообщения с запросом и ответом должны содержать один и тот же уникальный ключ для идентификации нужного экземпляра процесса. то ответ должен приходить в тот экземпляр процесса.3. первый ушел».25). Полученные сообщения в очереди могут быть либо сохранены для последующей обработки либо аннулированы. Способ обработки очереди может зависеть от типа сообщения. по принципу FIFO . но обрабатывать будет только то сообщение. в котором покупатель сформировал соответствующий запрос.сколько.«первый пришел.4. когда адресат ожидает несколько входящих сообщений от различных адресантов. Паттерн отправка и получение сообщения 11. которое пришло первым.д. ОЧЕРЕДЬ ВХОДЯЩИХ СООБЩЕНИЙ Паттерн описывает ситуацию. Данная ситуация достаточно распространена при моделировании бизнес-процессов. Рисунок 11-7.

операции с пометкой маркера параллельных множественных экземпляров. За четыре недели до начала парламентских выборов происходит рассылка уведомлений жителям. Очередь входящих сообщений 11. вычисляется в момент выполнении экземпляра процесса. 225 . которые представлены на схеме в виде пула с маркером множественности. Жители. данная конструкция может быть описана с помощью графического элемента .3. получают сообщение и могут его обработать. Список получателей может быть определен как в схеме хореографии процесса.е. Рисунок 11-9) иллюстрирует веерную рассылку. Пример (см. так и непосредственно в момент рассылки сообщения. В нотации BPMN.Рисунок 11-8. т. зарегистрированным в автоматизированной избирательной системе.5. ВЕЕРНАЯ РАССЫЛКА СООБЩЕНИЙ Участник может разослать сообщение одновременно нескольким адресатам.

Рисунок 11-9. Уведомление .... временное ограничение получения. Каждый участник может отправить не более одного сообщения одному адресату.. Рисунок 11-10.. В течение заранее определенного срока. Отправить уведомления . Список полученных сообщений Для иллюстрации паттерна представим процесс аукционных продаж (Рисунок 11-10). Веерная рассылка сообщений 11. любой 226 . которые он получит.3. Продавец выставляет на торги предложение. Обычно. В связи с этим необходимо задать условие. при достижении которого прием сообщений завершится: максимально допустимое количество запросов.. при которой адресат получает одновременно сообщения от разных отправителей.. адресат не знает заранее количество сообщений.6. СПИСОК ПОЛУЧЕННЫХ СООБЩЕНИЙ Паттерн моделирует ситуацию.

либо временными рамками. Рисунок 11-11.8. а в ответ получает несколько сообщений. Во-первых. Рассылка сообщений и обработка результатов 11. Рисунок 11-11). которое сохраняется в списке. Для этого агентство рассылает авиакомпаниям запрос и те в ответ могут прислать свое коммерческое предложение. при которой один участник отправляет другому запрос. Туристическое агентство ищет лучшее предложение среди различных авиакомпаний. Главный вопрос в данной ситуации заключается в том. сроки получения результатов рассылки ограничиваются заранее необходимым количеством сообщений. Обычно.3.7. Приведем пример для иллюстрации паттерна (см. Можно предложить несколько различных сценариев решения данной операции. 11. РАССЫЛКА СООБЩЕНИЙ И ОБРАБОТКА ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ Паттерн моделирует ситуацию. МНОЖЕСТВЕННЫЙ ОТВЕТ Паттерн моделирует ситуацию.3. каждый ответ может содержать в себе 227 . при которой адресант единовременно рассылает сообщение нескольким адресатам и ожидает от них ответа.из покупателей может сделать предложение. каким образом адресант узнает о количестве сообщений. которые он получит в ответ в результате своего запроса. После завершения аукциона выбирается наиболее подходящее предложение.

11. при которой участник отправляет запрос адресату и ожидает его ответа. ожидая ответа от него. для адресанта можно определить временной промежуток. Пример (см. если адресанту поступили «просроченные» ответы. он вправе решать как поступить с этими сообщениями . Наконец. адресант отправляет этот же запрос другому адресату. пока не будет назначен новый исполнитель задания. Негарантированный ответ на запрос 228 . пока адресант не получит необходимого ему ответа. Сотрудник делегирует выполнение операции подчиненному и ожидает подтверждения. Рисунок 11-12. НЕГАРАНТИРОВАННЫЙ ОТВЕТ НА ЗАПРОС Паттерн иллюстрирует ситуацию. либо аннулировать.3. Если тот не отвечает вовремя.9. операция делегируется другому сотруднику и так далее. последнее в цепочке ответов сообщение может иметь характерный признак. иллюстрирует паттерн негарантированный ответ на запрос. В случае. если адресат не ответил вовремя. в течение которого он будет ожидать ответа от адресата своего запроса. В случае. Рисунок 11-12).информацию о том. ожидаются ли другие сообщения.либо обработать их. Вовторых. Ситуация повторяется до тех пор.

что покупатель совершает покупку с использованием сервиса. при которой участник посылает сигнал всем доступным агентам. в качестве принимающей стороны может выступать один. Теперь участник В может взаимодействовать с участником С.11. 229 .3. Например. ШИРОКОВЕЩАТЕЛЬНАЯ РАССЫЛКА Паттерн моделирует ситуацию. ЗАПРОС С ПЕРЕНАПРАВЛЕНИЕМ Возможность совершения запроса с перенаправлением достаточно важна в сервис-ориентированной среде. о котором не подозревал в начале.б.10. без посредничества участника A. которую моделирует данный паттерн (см. Рисунок 11-14). поэтому в момент моделирования реальный адрес м. если участник А отправляет сообщение участнику В. не известен. В зависимости от условий операции. Это означает. Заказчик покупает несколько книг через интернет магазин.11. данный паттерн может использоваться в случае. Широковещательная рассылка 11. где реестр сервисов может динамически изменяться. Производитель Запрос котировок Котировка Поставщик Рисунок 11-13. в котором содержится просьба продолжить диалог с третьим участником С. Для иллюстрации рассмотрим ситуацию.3. Книжный магазин перенаправляет запрос покупателя адрес платежной системы для оплаты заказа. группа или все множество агентов.

Рисунок 11-14. Запрос с перенаправлением 230 .

Каждая тема может рассматриваться как отдельный диалог. сроки поставки и т. С одним поставщиком у неё обсуждается одновременно несколько контрактов. между которыми происходит взаимодействие и тематику передаваемых сообщений и. например. организация покупатель посылает запрос на поставку товара. Элементы Схемы диалогов Схемы диалогов состоят из ограниченного набора графических элементов. Схема диалогов является высокоуровневым способом отображения взаимодействия участников.12. п. иерархически вложенными. Диалоги м. на работе с одним бизнес объектом. один контакт может включать обсуждения: номенклатуры товаров. например.это набор логически связанных информационных сообщений. отвечает на вопрос кто с кем общается и по какому вопросу. Поскольку термин диалог является достаточно общим. Тематика обмена определяется автором. так что каждая сделка может рассматриваться как отдельный диалог. без детализации способов передачи сообщений. «Ответ на Заказ». логически связанные сообщения. на схеме диалога группируются по темам.5. диалог объединяет отдельные сообщения: «Отправить Заказ». посвященные одной теме. Ключевым элементом такой диаграммы является диалог. Таким образом. Технически каждой теме соответствует отдельный корелляционный ключ (см. BPMN предлагает более точное описание: диалог . Для этого. автор диаграммы может произвольно определить тематику диалогов по своему желанию. Спе231 . В этом случае. Например. таким образом. Например. изображаемые на схеме взаимодействия независимо друг от друга.б. Данный вид диаграмм позволяет отобразить участников.д.6). Принцип группировки может основываться. «Подтвердить Заказ». СХЕМЫ ДИАЛОГОВ Схемы диалогов используются для моделирования межпроцессного взаимодействия на концептуальном уровне. Таблица 12-1 показывает основные элементы. способов оплаты и доставки. 6. «Заказом».

она м. в роли поставщика могут выступать много компаний.б. Ограничивает процесс. Если число участников не известно на этапе моделирования. осуществляющих диалог никации Мульти линия Поток диалога связывает с мультипулом. Элементы схемы диалогов. иерархически декомпозирован на вложенные суб-диалоги Глобальный диалог Вызов глобально определенного.группа логически связанных потоков сообщений лог Комплексный диалог Диалог. он может быть декомпозирован на отдельном листе диаграммы. у которого есть много участников. выполняемый одним из участников. который м. Процесс. Один пул может отображать множественных участников. Для соединения диалогов с участниками используются графический элемент 232 . где информационное взаимодействие участников диалога отображается на более детализированном уровне. повторно используемого суб-диалога Мульти-пул Пул (Pool) представляет собой графическое изображение Участника (Participant) Взаимодействия. то используется элемент мульти-пул.Связывает участников.цификация определяет четыре типа диалогов: Таблица 12-1. в диалоге покупателя с поставщиком. Например. в этом случае суб-диалог помечается маркером «+». повторно используемого диалога Комплексный глобальный диалог Пул Вызов глобально определенного. Знак Название Комментарий Обычный диа. составной – состоять из нескольких субтем. Тема обсуждения моделируется с помощью элемента диалог. для каждого исполняется свой экземпляр процесса Линия комму. коммуникации которому соответствует несколько участников Для моделирования участников используются пулы.б.

Диалог является повторно используемым. Рассмотрим пример (см. изображающий обмен сообщениями между Поставщиками.1. поэтому они моделируются мультипулами. поэтому он моделируется с помощью глобального диалога. Схемы взаимодействия (А) и диалога (Б) 12. Рисунок 12-2). Рисунок 12-2. 233 . для его обозначения используется элемент глобальный диалог. то используется мульти-линия. а с Заказчиком о «Продаже товара». мульти-пул Диалог м. повторно используемым. Рисунок 12-3). Диалог участников. МУЛЬТИ-ПУЛЫ Проиллюстрируем использование схемы диалогов на примере аукционных торгов. Рисунок 12-1. С Поставщиком ведется диалог о «Закупке товара». Если линия направлена на мультипул. В этом случае линия коммуникации содержит надпись. В роли поставщиков и Заказчиков могут выступать сразу несколько компаний. Посредником и Заказчиками (см. в этом случае.б.«линия коммуникации». указывающую участников диалога. Рисунок 12-1 иллюстрирует схему взаимодействия (А) и соответствующую ей схему диалога (Б). пусть банк взаимодействует с агентством кредитных историй.

поэтому она позволяет охватить комплексное взаимодействие многих участников со многими. Рисунок 12-5А) показывает декомпозицию на отдельные сообщения. Комплексный диалог Следующая схема (см. посвященных условиям оплаты и условиям оплаты. Глобальный диалог 12.2. Рисунок 12-4) показывает взаимодействие Покупателя и Поставщика. Следующая схема (Рисунок Б) показывает декомпозицию комплексного диалога на два простых. Пример (см. Схема верхнего уровня (Рисунок А) показывает один комплексный диалог о поставке. Покупатель Поставщик Покупатель Поставщик Условия оплаты А Договор о поставке Условия оплаты Б Рисунок 12-4. КОМПЛЕКСНЫЕ ДИАЛОГИ Диаграмма диалогов не показывает мелких деталей. а затем (рисунок Б) соответствующую диаграмму публичного процесса.Рисунок 12-3. 234 .

Поставщик Договор поставки Договор транспортировки Перевозчик Рисунок 12-6. Декомпозиция комплексного диалога Диаграмма публичного взаимодействия может появиться на одном листе модели вмести с диаграммой взаимодействия (см. Рисунок 12-6). Комплексная диаграмма взаимодействия 235 .Рисунок 12-5.

1. которые можно разделить на односторонние. Основной элемент. используемый на диаграмме хореографии. поскольку они описывают так же информирование о произошедших ошибках. а не положением этих полей внутри задачи хореографии. Следует обратить внимание. типовые сценарии взаимодействия описываются с помощью Web Services Message Exchange Patterns (см. разработаны типовые последовательности информационного обмена. Она описывает формальный договор между источником и получателем информационной посылки. http://www.w3. 13. Что бы обмен не носил хаотический характер.html). имеет индивидуальное имя.org/2002/ws/cg/2/07/meps. что адресант и адресат различаются цветом соответствующих полей. • Переходы управления.д. когда запрос не предполагает определенного ответа и двухсторонние. • Потоки сообщений. с ответом. есть задача хореографии. Схема 236 . • Логические элементы. основанного на обмене информационными сообщениями между сторонами. сбоях и т. Поскольку техническим каналом обмена сообщениями обычно является протокол WebService. Не следует сводить эти последовательности только к тривиальным случаям. • События (подмножество элементов оркестровки).13. Она показывает взаимодействие адресанта (инициатора) и адресата (получателя). участвующими во взаимодействии. СХЕМЫ ХОРЕОГРАФИИ Схема Хореографии предназначена для формализации порядка межорганизационного взаимодействия. ГРАФИЧЕСКИЕ ЭЛЕМЕНТЫ ХОРЕОГРАФИИ Схемы хореографии используют следующие графические элементы нотации BPMN: • Задачи хореографии.

однонаправленные диалоги. Инициирующее диалог сообщение и ответное различаются цветом. имеющую двух ад237 . Обмен сообщениями. Пример (см. Рисунок 13-3А) показывает задачу хореографии. там же (рис. С обоими он одновременно ведет одинаковые переговоры. Пример (см. Б) – соответствующая схема оркестровки. содержимое посылки на этой схеме не моделируется. там же (рисунок Б и В) задача хореографии изображена средствами диаграммы оркестровки и взаимодействия. что заказчик отправляет запрос на поставку товара двум поставщикам. Рисунок 13-2. Рисунок 13-1А) показывает двусторонний обмен типа «запрос-ответ». когда инициатор оправляет сообщение. Представим себе. Рисунок 13-1. но не ожидает на нее ответа.н. Однонаправленная задача хореографии В одной задаче хореографии могут участвовать сразу несколько адресатов. оркестровка.Адресант Адресант может показывать конверты сообщений. хореография Допускаются т. Рисунок 13-2А) показывает однонаправленную задачу хореографии. Пример (см.

запрос направляется всем поставщикам. Пример (см. на диаграмме оркестровки они отображаются с помощью мультипулов. Например. Рисунок 13-4. Задача хореографии с двумя адресатами Возможна ситуация. там же (рис. В этом случае принято говорить о множественных участниках. Б) – соответствующая схема оркестровки. там же (рис. но станет известно в момент исполнения. Веерная рассылка запроса многим участникам 238 . Рисунок 13-4А) иллюстрирует веерную рассылку запроса многим участникам. Б) – соответствующая схема оркестровки. их список зависит от типа требуемой поставки. когда число партнеров не было известно на этапе моделирования. Рисунок 13-3.ресатов.

Рисунок 13-6. Пример (см. в которой первый участник осуществляет два диалога со вторым и третьим участниками. Диаграмму взаимодействия. Там же (рис. представим себе. можно заменить этот обмен на комплексную задачу. Рисунок 13-6) показывает диаграмму взаимодействия двух участников. Рисунок 13-5А) показывает циклическую рассылку.б. Б) – соответствующая схема оркестровки. Пример (см. когда два участника обмениваются большим числом посылок. она показывает два поддиалога. повторяющейся.Задача хореографии м. несколько пар диалогов Что бы обмен не выглядел хаотическим. Рисунок 13-7А) показывает комплексную задачу хореографии. что инициатор циклически повторяет рассылку. Б) показана развернутая задача хореографии. которая содержит несколько пар диалогов. Циклическая рассылка запроса Представим себе ситуацию. Рисунок 13-5. которая включала бы в себя несколько диалогов Пример (см. схема взаимодействия (рис В) показывает те же 239 . там же (рис.

Рисунок 13-8. свернутой. Инициирующее сообщение Адресант Инициирующее сообщение Участник1 Участник1 Комплексная задача хореографии Участник2 Участник3 А Б Инициирующее сообщение Задача хореографии Участник1 Задача хореографии Участник2 Участник3 Адресант1 Адресант2 В Рисунок 13-7.диалоги. Б) показана развернутая задача хореографии. рис. показывая нужные диалоги на том же листе. Глобальная задача м. Глобальная задача хореографии 240 . По внешнему виду она отличается рамкой. Пример (см.б. или развернутой. Как и в схемах оркестровки для вызова внешнего подпроцесса предусмотрена глобальная задача. Рисунок 13-8А) показывает свернутую глобальную задачу. там же (см. изображаемой более толстой линией. адресую схему на отдельной странице. Комплексная задача хореографии Комплексная задача хореографии может быть повторно используемой.

ИСП ПОЛЬ ЬЗОВАНИЕ СОБЫТИ ИЙ В ХОР РЕОГР РАФИ ИИ Диаграаммы Хореогр Х рафии могут м использ и зовать о огранич ченный й набор событи ий. Об бзор начаальных событий с й Названи ие Простое Сообщенние Таймер Эскалацция Условноое Ошибка Компенссация Сигнал Составное Параллеельное составноое Знак Опписание Не типиизированнное событие. Обззор заверршающи их событтий содеержит краткий к й обзор использ и зуемых в хореографии и заверш шающих событтий. ЗАВЕРШАЮ ЮЩИЕ Е СОБЫ ЫТИЯ Я Тааблица 13-2. Нет Создаетт экземплляр процеесса в назначенноое время. Раззрешены только сообщениия и таймеер Нет 13. Нет Нет Создаетт экземплляр процеесса послле получеения сигналаа. покаазывает сстарт процессса хореогграфии.13.1.2. 241 1 . что позвол ляет опи исать реакцию р ю процеесса наа внешни ие измеенения. 13. Таблицаа 13-1.2.2.2. НАЧА АЛЬНЫ ЫЕ СО ОБЫТИ ИЯ Таблицаа 13-1. Нет Проверяяется внуутренне условие у о одного из участников. Все участники у и должны иметть общеее представление о времении. Для созздания ЭП Э необхходимо и достаточно совершения толькоо одного из переччисленных событий. по расписани р ию. в циикле. Обзор О н начальны ых событтий пок казываеет кратк кий об-зор исп пользуемых в хореогра х афии начальны н ых собы ытий.

ПРОМЕЖУТОЧНЫЕ СОБЫТИЯ Таблица 13-3 содержит краткий обзор используемых в хореографии промежуточных событий. когда условие станет истинно. Сообщение. Эскалация. Используется для отображения статуса исполнения. ожидающий поступления сигнала. Составное Обработка одного события из множества или генерация всех определенных событии. видимы всем участникам Ссылка Связывает две разные части процесса и подразумевает неявную передачу потока управления от одной операции . Только участники задачи хореографии непосредственно предшествовавшей установке таймера знают значение задержки срабатывания. входящие в проверяемое условие д. Отмена.Таблица 13-2. 242 . Таблица 13-3. Работает как элемент задержки.б. Обзор завершающих событий Название Простое Описание Знак Другие участники не знают про завершение потока. чем через полученные сообщения. Компенсация. Ошибка. Ошибка. Остальные участники не смогут узнать о завершении потока иначе.3. Сигнал Нет Прекращение Не приводит к остановке исполнения других участников. Компенсация Нет Условное Работает как элемент задержки. Сообщение Нет Таймер При установке абсолютных дат все участники знают календарное время. Эскалация.другой. Сигнал Используется для широковещательной связи между участниками. 13. ожидает. Название Описание Простое Знак Обработчик отсутствует. Данные. Обработчики промежуточных событий.

еслии задача хореограафии закаанчивается заверршающим м событием отменна. П Перехваты ывает им менованные и беззымянныее ошибкии. при этом досттаточно. можеет быть И тоолько геннерирующ щим.д. П Проверяет т истиннность уссловия. Прерыввает выполнение задачи. в том м числе составны с м и содерржать в себе другие обрабботчики событий. еслии задача хореограафии закаанчивается заверршающим м событием отменна. позволяеет уведом успешном м завершеении оперрации и т. С Срабатыв вает. которы ые могут произойтти во вреемя выпоолнения операции. прикрепл п ляемые к задаче хореох Таблица 13-4. к которой прикреплен оббработчикк. наапример. с которые не мов ированы на н схеме процессаа. Обработтчики соб графии НаименноваОписаание ниее Сообщенние С Срабатыв вает при получени п и сообщеения.. С Срабатыв вает. Таймер Срабатыввает один раз в определленный момент С времени либо л нескколько рааз по распписанию. Отличается от Ошиббки болеее широкким диаппазоном мить об использоввания. Эскалацция Изменяет уровеньь принятиия решенния. бытий. т П Перехваты ывает слложные составны с е события.одержи ит кратк кий обзор исп пользуеемых в хорео-Таблицаа 13-4со графии и промеежуточн ных при икрепля яемых событий с й. гуут быть визуализи П Принимае ет широкковещательное опповещениие. событие из Ошибка Отмена Компенссация Условноое Сигнал Составное взаимоисщее ключающ 243 3 Знак . чтобы прроизошлоо хотя бы одно и списка. Условие У может б быть любы ым..

что участники оценивают ход процесса только по полученным сообщениям. Рисунок 13-9. Представим ситуацию. ИСПОЛЬЗОВАНИЕ ЛОГИЧЕСКИХ ОПЕРАТОРОВ В ХОРЕОГРАФИИ Диаграммы Хореографии могут использовать логические операторы. пришли к соглашению. когда покупатель и продавец провели переговоры о цене. что позволяет описать не только последовательность обменов. но так же логику взаимодействия.13.4. Пример ошибочной схемы хореографии 244 . покупатель перевел деньги в банк. Следует учитывать. что продавец отпустит товар только после подтверждения от банка о поступлении денег. Понятно.

Пример (см.Рисунок 13-9) показывает ошибочную схему хореографии. Пример (см. осуществляющего ветвление в зависимости от значения данных процесса. следует иметь в виду. Б) – соответствующая схема оркестровки. получает их ответы. участник 1 не вовлечен в предыдущий диалог и не знает. так как она является внутренней для компании и моделируется на схеме потоков работ) и делает выбор в пользу одного из них. 245 . после чего изучает их (эта задача отсутствует на схеме хореографии. что анализируемые данные должны поступить в процесс до момента принятия решения в виде информационного сообщения. Использование логических операторов на схеме хореографии вызывает некоторые затруднения. когда отправлять сообщение. Рисунок 13-10) изображает схему хореографии.Этот пример иллюстрирует важное правило диаграмм хореографии: инициатор диалога должен был быть вовлечен в предыдущий обмен. логический оператор «ИЛИ управляемый данными» предполагает анализ некоторого информационного объекта. Заказчик запрашивает коммерческое предложение от двух поставщиков. Но не обязательно именно в предыдущей задаче. иначе он может знать его результат (это правило не относится к первой задаче в цепочке). которая состоит из трех задач и логического оператора «исключающее ИЛИ управляемое данными». Там же (рис. Например. Это связано с отсутствием в хореографии центрального потока управления и единого объекта управления. Прежде всего.

дающие единое толкование бизнес терминов. Таким 246 . Для этого служат общие словари.Запрос А Заказчик Отправить заказ Заказчик Поставщик 1 Отправить запрос Заказчик Отправить заказ Поставщик 2 Поставщик 1 Поставщик 2 Ответ В Отправить получить Отправить получить Выборать поставщика Рисунок 13-10. на основании которых принимается решения. После того как соответствующее сообщение. что все участники хореографии должны иметь единое представление о данных. он принимает решение и извещает о нем остальных посредством сообщения. Использование логических операторов на схеме хореографии Логика принимаемого решения должна управляться одним участником взаимодействия. содержащее данные отправлено. Это означает. участник уже не может в одностороннем порядке изменить их значения.

образом. Данный пример наглядно демонстрирует альтернативное использование логических операторов «исключающее ИЛИ». либо на событии. основанного на событии. считается лицом принимающим решение. которое устанавливает максимальный допустимый период ожидания. рис Б) изображена соответствующая диаграмма взаимодействия.о. заказчик направляет сообщение тому поставщику. В случае использования логического оператора. участник. Событийный логический оператор работает как «исключающее ИЛИ». срабатывает таймер и процесс поставщика завершается. который выиграл конкурс. Первая задача хореографии рассылает запросы поставщикам и принимает от них ответ.. который оповещает остальных о решении. используя на схеме хореографии логический оператор «событийное исключающее ИЛИ» (см. Т. основанных на данных. там же (см. Что бы второй поставщик не застрял в ожидании подтверждения. используется событие таймер. Рисунок 13-11А). Приняв решение. пропуская оповещение только одному поставщику. которое ему уже никогда не поступит. если оповещение не поступит в течение нормативного времени. Реализуем теперь тот же сценарий. основанного на данных. на схему хореографии необходимо добавить задачу информирования поставщиков о принятом решении. В случае использования логического оператора. 247 . размещать такую задачу на хореографии уже не обязательно.

в которой принимается решение. инициатор хореографии должны участвовать в выполнении задач. В обоих случаях. Использование логических операторов на схеме хореографии Схема хореографии так же допускает использование логических операторов «И». он может инициировать передачу сообщения в логический оператор.Запрос А Заказчик Отправить заказ Заказчик Поставщик 1 Отправить запрос Заказчик Отправить заказ Поставщик 2 Поставщик 1 Поставщик 2 Ответ Участник2 Участник1 Участник3 В Принять запрос оправить ответ Получить заказ Отправить заказ Отправить получить Отправить получить Выборать поставщика Отправить заказ Принять запрос оправить ответ Получить заказ Рисунок 13-11. Рисунок 13-12) показывает использование опе248 . как он будет уверены в успешном завершении этой задачи. Только после того. Пример (см.

Запрос А Заказчик Отправить заказ Заказчик Поставщик 1 Отправить запрос Заказчик Отправить заказ Поставщик 2 Поставщик 1 Поставщик 2 Ответ В Принять запрос оправить ответ Получить заказ Получить заказ Отправить заказ Отправить получить Отправить получить Выборать поставщика Отправить заказ Принять запрос оправить ответ Получить заказ Рисунок 13-12.ратора «И». Использование логического оператора «И» на схеме хореографии 249 . поставщик одновременно рассылает заказы сразу обоим поставщикам.

показать семантику их выполнения. которые мы используем для описания бизнеспроцессов в отрыве от методологии. которые при анализе процесса не опираются на соответствующую методологию. тогда как нам нужен инженерный подход.0. Аналитики. Методология определяет подходы. однако многие используют в нотацию для описания процессов. являются функциональными? Наше утверждение: не нотация. Вместе с тем. что следующая работа сможет стать руководящим документом бизнес-аналитиков. вооружит их методологией моделирования бизнес-процессов. В качестве примера рассмотрим нотацию IDEF0. Хочется надеяться. а методология определяет. неразрывно связанную с методологией SADT. позволяющий превратить ремесло в технологию. рискуют допустить ошибки моделирования. является ли модель функциональной или процессной. требующая серьезной проработки. а нотация помогает зафиксировать результаты. что SADT есть нотация. Напрашивается аналогия с музыкой. что некоторые модели. Вспомним. где музыкальная композиция и нотная грамота суть разные вещи. ЗАКЛЮЧЕНИЕ В данной работе была сделана попытка дать систематическое описать нотации BPMN 2. Это отдельная тема. модели IDEF0 принято называть функциональными.14. Вместе с тем хочется отметить. описать синтаксис использования элементов. приемы и методы моделированию. Будет ошибкой называть нотацию IDEF0 методологией или сказать. 250 . без подобной методологии труд бизнес-аналитика будет напоминать ремесло. часто методологию моделирования подменяют нотацией. Не может ли оказаться. что удалось достигнуть поставленной цели. а это не одно и то же. Хочется надеяться. Изложение снабжено многочисленными примерами. В рамках данной работы не предполагалось описать методологию моделирования бизнес-процессов. по сути.

.................................................................... 66 Действие .................................................................. 29 Вложенный подпроцесс ...................................... 100 Группа операций .................................................................................................... 27 Интерактивная операция ................................................................................................................................................................... 68 Внутриорганизационные процессы .......... 57 Автоматические процессы................................................................................................................................................................................... 100 251 ................................................................................... 72 Генерирующее событие................................................................................................... 18 Альтернатива....... 187 бизнес-процесс ............................ 18 Автоматическая операция .......... 4 Версионность исполняемой ............................................................................................... 122 Завершающее событие-сообщение ............. 167 Вызывающая операция .......................... 45 Диаграмма приватного взаимодействия .................................................................................................................................................................... 109 Дискриминатор ............................................................... 14 Входные и выходные данные процесса ............................................................................................................................................................. 44 Диаграмма оркестровки ........... 5 Диаграмма закрытого процесса ............. 165 Конечное событие ...................................................................................................................ПЕРЕКРЕСТНЫЕ ССЫЛ Абстрактная (нетипизированная) операция ...................................................................... 199 Коллекция объектов данных .......................................................................................................... 162 Завершающее событие-прекращение ...... 59 Автоматизированные процессы........ 56 Исполнение с синхронизацией (число экземпляров известно на этапе исполнения) ................................................................................................................................... 17 Вспомогательные (обеспечивающие) бизнес-процессы .................................................................................. 47 Диалог .............................................................................................................................................................................. 46 Исполняемая модель бизнес-процесса....................................................................................... 124 Интегрированная модель бизнес-процесса .......................................... 25 Итерация ........................................................................................................................................... 195 Жизненный цикл объекта данных ................................................. 44 Диаграмма открытого процесса ..................... 45 Диаграмма публичного взаимодействия .................................................................... 202 Исполняемая модель ..........................................................

........................................................................................ 201 Параллельное исполнение с синхронизацией (число экземпляров известно на этапе моделирования) ............... 190 Направленные ассоциации ......................... 90 Логический оператор комплексное условие................................................................................................ 194 Множественный выбор ............................................................................................................................................................................................. 186 Параллельное исполнение без синхронизации .................................. 8 Операция .. 93 Маркер параллельного выполнения ..................................................................................................................................................................................................................................................................... 100 116 Независимые события ............................................................................... 39 Начальное событие ............................. 100 Объектом управления ........................... 202 Параллельные потоки управления процесса .................................................................. 63 Операция сценарий........................................ 203 Параллельное исполнение..................................... 14 Отложенный выбор ........... 60 Межорганизационные процессы ... 62 Маркер потока управления процесса ............................................................................ 17 Методология структурного анализа и проектирования ..................... 57 Операция для случая (ad-hoc) .............................................................................................................. 87 Логический оператор «Исключающее ИЛИ» управляемый данными .............................................................. 24 Многократное повторение ....... 20 Объекты данных......... 57 Основные процессы ..................................................... 102 Неструктурированные паттерны ...................................................................................................................................... 193 Обрабатывающее событие ...................................................................................................................... 21 252 ........................................................................................................................ 63 Операция компенсация....................................................................................................................................................................................................... 38 Логический оператор «ИЛИ» управляемый данными ........................................................................................... 21 Маркер цикла ............................ 101 Непаправленные ассоциации .............. 39 Оперативное управление ........................................................................................................... 198 Многопоточные операции ......................................................................................................................................... 61 Маркер подпроцесса ............................................................................................................................. 60 Маркер последовательного выполнения ............ 114 Логический оператор............ 22 Множественное слияние................................................. 5 38 Операция бизнес-правило ..........................................................................................................................Координация исполнения ............................................... 205 Корреляция .......................................................................................... 38 Непрерывающие событие ...................................

.................... 10 Система ориентированная на процессы .................. 21 Потоки сообщений .................................................................................................................................................................................................. 172 Ручная операция ..................................................................................................................... 130 Простое слияние параллельных ветвей .................................................................................................................................................................................................................................... 4 Промежуточное событие ............................................................................... 34 Сигнал ........ 188 Процесс ............ 38 Прекращение исполнения задания..... 187 Синхронизация без запоминания оповещения ............................................................................................................. 210 Прекращение исполнения процесса ................................................................................................... 101 Проект ......... 185 Поток обработки исключительной ситуации ........................................................................... 132 Промежуточные событие отправить и принять сообщения ........ 138 Прикрепленное непрерывающее обрабатывающее граничное событие ..................................................................................................................................................Повторно используемый (внешний) подпроцесс ................................................................... 66 Рекурсия...... 102 Приватный процесс поддерживающий публичный ........................... 73 Последовательное исполнение .............................. 104 Синхронизация ................................................. 100 Промежуточное событие-таймер ................................................................................................................................................................................................................................................. 138 Прикрепленное прерывающее обрабатывающее граничное событие ............................................................................ 121 Простое промежуточное событие ............................................................................................................................................. 12 253 ... 131 Промежуточное событие-условие .............. 67 Подпроцесс для конкретного случая (Ad-Hoc) ..... 50 Прикрепленное непрерывающее граничное событие-таймер ............................................................................................ 133 Промежуточное составное событие . 137 Прикрепленное прерывающее граничное событие-таймер ................................. 209 Прерывающее событие ........................................................ 137 Поток управления процесса ................................................ 10 Системы управления бизнес-процессами................................. 208 Прекращение исполнения многопоточной операции ......... 200 Роль ................. 107 Потоки управления...................................................................................................... 56 Семантика нотации BPMN .................................................................................... 132 Промежуточное составное параллельное событие ............................................................................................ 211 Система базирующяся на процессах ...................................................................................... 131 Простое завершающее событие ................................. 70 Подпроцесс ..................................... 137 Прикрепленные события ..................................................

........................................................ 126 Событие-ошибка ......................... 192 Схема взаимодействия ... 213 Схема хореографии ......................................................... 126 Событийный логический оператор «Исключающее ИЛИ»........................................... 166 Чередование маршрутов ............................................... 104 Событие-компенсация ....................... 107 Составное взаимоисключающее стартовое событие ..... 118 Событийный оператор «Исключающее ИЛИ» .................................................. 78 Функциональная модель................... 117 Составное параллельное стартовое событие .............................................................................................................................................................................................................................................. 14 События ........................ 51 Схемы взаимодействия .................... 118 Статус обработки объекта данных ............................................................................................................................................................................................................................................................................................................................................................................................... 8 Транзакционный подпроцесс ............................................................ 38 Событие принимающее сигнал ............................. 125 Событие-ссылка ......... 134 Сообщения................................................................................................. 94 96 Событийный подпроцесс ............................................... 8 Структурированная декомпозиция работ ........................................................................................................................................................ 50 Тактическое управление .................................................................................................................................................................................................................... 127 Событие-отмена ......... 204 254 . 134 Событие-эскалация................. 75 События прикрепляемые к границам операций ..................................................................................................................................Системы управляемые моделью ........ 104 Событие генерирующее сигнал .......................................................... 24 Структурированное слияние с синхронизацией ........................................ 11 Сквозные бизнес-процессы ........... 164 Стратегическое управление .................................................................................................................................................................................................................................... 25 Хранилище данных .....................................

Белайчук «Главное не результат главное процесс» www.brsilver. Silver.com 255 .Белайчук «Учим BPMN» www. S. OMG Business Process Model and Notation (BPMN)Version 2.mainthing.СПИСОК ЛИТЕРАТУРЫ: 1.0 OMG Document Number: formal/2011-01-03 Standard document URL: http://www. M.bpmntraining.White D.0 2. 2008 4.Silver «BPMS Watch» www. Miers BPMN Modeling and Reference Guide Future Strategies Inc. B.omg. B. А.ru 6.ru 7.org/spec/BPMN/2.Weske Business Process Management: Concepts Languages Architectures Springer-Verlag Berlin Heidelberg 2012 5. BPMN Method & Style Cody-Cassidy Press 2011 3. А.

256 .