Модуль 05: Моделирование в BPMN — Практическое задание

Общая информация

Кейс: Процесс обработки заявки на отпуск в крупной компании (500+ сотрудников).

Цель задания: Применить нотацию BPMN 2.0 для моделирования AS-IS и TO-BE процессов, а также спроектировать исполняемую BPMN-диаграмму с использованием событий, задач, шлюзов и граничных событий.

Формат сдачи: Один PDF или документ Markdown, содержащий:

Задание 1: BPMN AS-IS (скриншот из Camunda Modeler или PlantUML-диаграмма)
Задание 2: BPMN TO-BE (скриншот / PlantUML / ASCII)
Задание 3: Анализ XML-кода (ответы на вопросы с цитированием тегов)
Задание 4: Сравнительный анализ BPMN и UML Activity (4 вопроса)

Инструменты: Camunda Modeler (рекомендуется), Draw.io, PlantUML (синтаксис BPMN поддерживается).

Баллы: 10 баллов.

Кейс: Процесс обработки заявки на отпуск

Контекст

Компания «ТехноПрогресс» (500+ сотрудников). Текущий процесс оформления отпусков:

Сотрудник пишет заявление на отпуск на бумаге
Сотрудник несёт заявление Руководителю на подпись (ходит физически по офису)
Руководитель подписывает заявление (если он на месте)
Сотрудник относит подписанное заявление в HR-отдел
HR-специалист проверяет остаток отпускных дней по бумажной карточке или Excel
HR-специалист вносит данные в 1С:ЗУП вручную (тратит ~30 минут)
Сотрудник уходит в отпуск

Проблемы текущего процесса (AS-IS):

❌ Потеря заявлений — бумажные документы теряются, нет централизованного хранения
❌ Долгое согласование — руководитель может быть в командировке/на совещании
❌ Ручной ввод в 1С — HR тратит ~30 минут на каждую заявку, ошибки при вводе
❌ Нет отчётности — невозможно узнать, кто в отпуске, кто планирует
❌ Нет ограничений — сотрудник может подать заявку за 1 день до отпуска (нарушение ТК)

Общие требования для всех заданий (обязательны к выполнению)

№	Требование	За что снимаются баллы
1	Все диаграммы должны содержать минимум 2 Lane	Lane отсутствуют → −0,5 балла от задания
2	Используйте корректные названия элементов (глагол + существительное: «Согласовать заявку», не «Согласование»)	Названия-существительные → −0,2 балла
3	Используйте маркеры событий (Message, Timer, Error) где уместно	Нет маркеров там, где они нужны → −0,3 балла
4	Sequence Flow с условиями должны быть подписаны в квадратных скобках: `[Дней >= 14]`, `[Отказано]`	Нет подписей на условных потоках → −0,2 балла
5	У каждого Gateway должен быть Default Flow (поток по умолчанию)	Нет Default Flow → −0,3 балла
6	Все ветки должны завершаться End Event	Висящие ветки → −0,3 балла

Задание 1: BPMN AS-IS (2,5 балла)

Постройте BPMN-диаграмму текущего процесса (AS-IS) — без автоматизации, только ручные операции.

Пошаговая инструкция

Шаг	Действие	Подсказка
1.1	Создайте один Pool с именем «Компания ТехноПрогресс»	Pool — это весь процесс целиком
1.2	Добавьте 3 Lane внутри Pool: Сотрудник, Руководитель, HR	Lane располагаются вертикально (или горизонтально) внутри Pool
1.3	Разместите Start Event (None Start) в Lane «Сотрудник»	Start Event — кружок с тонкой обводкой, без маркера
1.4	Добавьте User Tasks для всех ручных операций	User Task — прямоугольник со скруглёнными углами и значком человечка
1.5	Соедините задачи Sequence Flow (стрелки)	Каждая стрелка — переход от одной задачи к другой
1.6	Добавьте End Event (None End)	End Event — кружок с толстой обводкой

Какие задачи должны быть на диаграмме (минимум 5):

Сотрудник: «Написать заявление на отпуск» — User Task
Сотрудник: «Отнести заявление руководителю» — User Task
Руководитель: «Подписать заявление» — User Task
Сотрудник: «Отнести заявление в HR» — User Task
HR: «Проверить остаток дней» — User Task
HR: «Внести данные в 1С» — User Task

Важно: В AS-IS не должно быть Service Task, Send Task, автоматических шлюзов. AS-IS — это как есть сейчас, со всеми бумажками и хождениями.

Шаблон ответа для Задания 1

Вставьте скриншот диаграммы. Если используете PlantUML — вставьте код.

[СКРИНШОТ ДИАГРАММЫ AS-IS]

Краткое описание:
На диаграмме отражено ___ шагов. Участники: ____________________.
Проблемы, которые видны на схеме: ______________________________.

Детальная таблица баллов

Критерий	Баллы	Условие получения	Типичная ошибка
3 Lane: Сотрудник, Руководитель, HR	0,5	Все три Lane присутствуют и названы верно	Lane названы должностями («Менеджер», «Специалист HR»), а не ролями — 0,3 балла
Все 5+ шагов процесса отражены	0,5	Минимум 5 User Tasks, покрывающих кейс	Пропущен шаг «Отнести заявление руководителю» — 0,3 балла
User Tasks для всех ручных операций	0,5	Все задачи имеют тип User Task (с человечком)	Использован Abstract Task без маркера — 0,2 балла
Sequence Flow с корректными переходами	0,5	Стрелки идут в логичном порядке, нет «зависших» связей	Стрелка идёт из Lane HR обратно в Lane Сотрудник без необходимости — 0,3 балла
Диаграмма читаема, есть Start и End	0,5	Start Event в начале, End Event в конце, элементы не наложены друг на друга	Нет Start Event — 0 баллов за критерий
Итого	2,5

Задание 2: BPMN TO-BE с автоматизацией (3 балла)

Компания внедряет Portal HRM — систему управления персоналом. Спроектируйте целевой процесс TO-BE.

Что меняется (описание TO-BE)

Сотрудник создаёт заявку на отпуск в Portal HRM через веб-форму
Portal HRM (система) автоматически проверяет:
- Остаток отпускных дней — Business Rule Task (или Service Task)
- Правило: отпуск подаётся не менее чем за 14 дней — Gateway XOR
Если остаток дней > 0 И срок ≥ 14 дней — заявка отправляется Руководителю
Руководитель может согласовать или отклонить — Gateway XOR
Если согласовано:
- Portal HRM автоматически создаёт приказ в 1С — Service Task (интеграция через API)
- Portal HRM отправляет уведомление сотруднику — Send Task
Если не согласовано ИЛИ не прошло проверку:
- Portal HRM уведомляет сотрудника с причиной отказа — Send Task
Boundary Timer (Interrupting): Если руководитель не ответил за 3 рабочих дня — заявка автоматически согласовывается
Event-based Gateway: Если сотрудник пытается подать заявку за < 14 дней до отпуска — требуется дополнительное approval от HR BP (Business Partner). Система ждёт:
- Либо ответ от HR BP (Message)
- Либо тайм-аут 2 дня (Timer) — автоматический отказ

Пошаговая инструкция

Шаг	Действие	Подсказка
2.1	Создайте 2 Pool: «Компания ТехноПрогресс» и «Внешние системы»	Portal HRM — внутри первого Pool. 1С — внутри второго (или как Lane?)
2.2	В Pool «Компания» добавьте Lane: Сотрудник, Portal HRM (система), Руководитель, HR BP	Portal HRM — Lane-система, в ней будут Service Task и Business Rule Task
2.3	В Pool «Внешние системы» добавьте Lane: 1С	Сюда будут лететь Message Flow из Service Task
2.4	Start Event: Message Start (заявка создана в Portal HRM)	Message Start — кружок с конвертом. Процесс стартует, когда система получает сообщение
2.5	Business Rule Task: «Проверить остаток дней»	Прямоугольник с табличкой-маркером
2.6	Gateway XOR: «[Дней >= 14]» vs «[Дней < 14]»	Ромб с крестом (X). Подпишите оба потока
2.7	User Task: «Согласовать заявку» с Boundary Timer (PT72H, Interrupting)	Прямоугольник с человечком. Таймер прикреплён к верхней границе
2.8	Gateway XOR: «Согласовано?» → [Да] / [Нет]	Default Flow = [Нет]
2.9	Service Task: «Создать приказ в 1С» с Message Flow в Pool «Внешние системы»	Прямоугольник с шестерёнкой
2.10	Send Tasks: уведомления сотруднику (одобрено / отказано)	Прямоугольник с закрашенным конвертом (Send Task)
2.11	Event-based Gateway: «Ожидание решения HR BP»	Ромб с двойной обводкой (не путать с XOR!). После него — только Intermediate Catch Events
2.12	После Event-based Gateway: Intermediate Catch Event (Message) — ответ от HR BP и Intermediate Catch Event (Timer) — тайм-аут 2 дня	Кружки с двойной обводкой: конверт (Message) и часы (Timer)
2.13	End Events: для каждой завершающей ветки	«Заявка одобрена», «Заявка отклонена» и т.д.

Ключевые требования к диаграмме TO-BE

Элемент	Обязательно	Сколько раз
Pool: «Компания ТехноПрогресс»	Да	1
Pool: «Внешние системы»	Да	1
Lane: Сотрудник	Да	1
Lane: Portal HRM (Система)	Да	1
Lane: Руководитель	Да	1
Lane: HR BP	Да	1
Lane: 1С (во внешнем Pool)	Да	1
Message Start (конверт)	Да	1
Service Task (шестерёнка)	Да	≥1
Send Task (закрашенный конверт)	Да	≥2
Business Rule Task (табличка)	Да	≥1
Boundary Timer (Interrupting)	Да	1
Event-based Gateway (ромб с двойной обводкой)	Да	1
Intermediate Catch Event (Message)	Да	≥1
Intermediate Catch Event (Timer)	Да	≥1

Шаблон ответа для Задания 2

[СКРИНШОТ ДИАГРАММЫ TO-BE]

Краткое описание TO-BE:
1. Количество участников: ___ (Lane)
2. Автоматизировано: ___ шагов (Service Task + Business Rule Task)
3. Интеграции: ___ (с какими системами)
4. Обработка исключений: ____________________ (таймеры, эскалация)

Что улучшилось по сравнению с AS-IS: _______________________________.

Детальная таблица баллов

Критерий	Баллы	Условие получения	Типичная ошибка
5 Lane (все участники) + 2 Pool	0,5	Все Lane и Pool присутствуют. Pool «Внешние системы» отделён, Message Flow между ними	1С внутри того же Pool — 0,2 балла (должен быть отдельный Pool)
Service Task (1С интеграция) + минимум 2 Send Task	0,5	Service Task — с шестерёнкой, Send Tasks — с закрашенным конвертом	Send Task перепутан с Receive Task — 0,2 балла
Business Rule Task (проверка дней) + Gateway XOR	0,5	Business Rule Task — с табличкой. XOR — подписанные ветки	Business Rule Task без маркера — 0,2 балла
Boundary Timer (Interrupting, 3 дня)	0,5	Прикреплён к User Task «Согласовать заявку», cancelActivity="true" на схеме не видно, но обозначено словом «Interrupting»	Non-Interrupting (пунктирная обводка) вместо Interrupting — 0,2 балла
Event-based Gateway + Message Catch + Timer Catch	0,5	После Event-based Gateway только Intermediate Catch Events. Никаких Task сразу после ромба!	После Event-based Gateway стоит User Task — 0 баллов за критерий (грубая ошибка)
Логика корректна, все ветки завершаются	0,5	Нет «подвешенных» веток. Default Flow указаны. Процесс не может «зависнуть»	Ветка без End Event — 0,2 балла
Итого	3,0

Задание 3: Анализ исполняемой модели (2,5 балла)

Дан фрагмент BPMN-диаграммы в формате XML Camunda. Это «сырой» код, который загружается в BPMN-движок (Camunda, Flowable и др.). Проанализируйте каждый элемент и ответьте на вопросы.

Фрагмент XML (с комментариями)

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:camunda="http://camunda.org/schema/1.0/bpmn">

  <!-- ============================================================
       ПРОЦЕСС: vacation_process
       Атрибут id — уникальный идентификатор процесса.
       Атрибут name — человекочитаемое имя.
       isExecutable="true" — этот процесс может быть запущен
       BPMN-движком (в отличие от чисто "рисуночных" диаграмм).
       ============================================================ -->
  <bpmn:process id="vacation_process"
                name="Обработка заявки на отпуск"
                isExecutable="true">

    <!-- ==========================================================
         START EVENT: start
         Тип: Message Start Event (конверт).
         ⚠️ Обратите внимание: процесс запускается НЕ вручную,
         а когда приходит внешнее сообщение (из Portal HRM).
         Атрибут id="start" — на него могут ссылаться другие элементы.
         ========================================================== -->
    <bpmn:startEvent id="start" name="Заявка создана">
      <!-- messageEventDefinition — это и есть маркер конверта.
           Если бы тега не было — старт был бы None Start.
           Если бы был timerEventDefinition — старт по таймеру. -->
      <bpmn:messageEventDefinition />
    </bpmn:startEvent>

    <!-- ==========================================================
         USER TASK: approve_task
         Тип: User Task (человечек) — задачу выполняет человек.
         Атрибут camunda:assignee="${manager}" — Camunda Expression
         Language (обозначается ${...}).
         ⚠️ Задача НЕ назначена конкретному Иванову, а вычисляется
         через переменную процесса "manager".
         Где задаётся эта переменная? Либо в стартовом сообщении,
         либо在前面的 Service Task.
         ========================================================== -->
    <bpmn:userTask id="approve_task" name="Согласовать заявку"
        camunda:assignee="${manager}">

      <!-- ========================================================
           LOOP CHARACTERISTICS — циклическое выполнение задачи.
           ⚠️ Это значит, что задача будет повторяться, пока
           не выполнится условие выхода.
           Атрибут loopCondition — условие продолжения цикла.
           ${loopCount < 3} — задача будет повторяться, пока
           счётчик loopCount меньше 3.
           ИТОГО: задача выполнится максимум 3 раза (0, 1, 2).
           ======================================================== -->
      <bpmn:standardLoopCharacteristics>
        <bpmn:loopCondition>${loopCount < 3}</bpmn:loopCondition>
      </bpmn:standardLoopCharacteristics>
    </bpmn:userTask>

    <!-- ==========================================================
         BOUNDARY EVENT: timer_boundary
         Тип: Timer Boundary Event (часы на границе задачи).
         Атрибут attachedToRef="approve_task" — прикреплён К
         задаче approve_task.
         ⚠️ cancelActivity="true" — это INTERRUPTING (прерывающий)
         таймер. Если задача не завершилась за отведённое время —
         она прерывается, и поток идёт ПО ТАЙМЕРУ.
         Если бы было cancelActivity="false" — это NON-INTERRUPTING
         (пунктирная обводка), задача бы продолжалась, а таймер
         запускал параллельную ветку.

         timeDuration: PT72H — ISO 8601 формат:
         P = period (период), T = time (время),
         72H = 72 часа (3 дня).
         Другие примеры: PT30M (30 минут), P14D (14 дней).
         ========================================================== -->
    <bpmn:boundaryEvent id="timer_boundary"
                        attachedToRef="approve_task"
                        cancelActivity="true">
      <bpmn:timerEventDefinition>
        <bpmn:timeDuration>PT72H</bpmn:timeDuration>
      </bpmn:timerEventDefinition>
    </bpmn:boundaryEvent>

    <!-- ==========================================================
         SERVICE TASK: create_order_1c
         Тип: Service Task (шестерёнка) — автоматическая задача,
         выполняемая движком без участия человека.
         ⚠️ Способ реализации: camunda:expression — это значит,
         что Camunda выполнит Expression Language-выражение
         синхронно в том же транзакционном контексте.
         Альтернативы:
           - camunda:delegateExpression — вызов Java-класса
           - camunda:topic (External Task) — асинхронный вызов
             через внешнего воркера
           - camunda:script — скрипт (JS, Python, Groovy)

         Выражение: ${oneSClient.createOrder(
           execution.getVariable('orderData'))}
         oneSClient — это Spring Bean (или CDI-бин),
         зарегистрированный в контейнере Camunda.
         createOrder — метод этого бина.
         execution.getVariable('orderData') — получение
         переменной процесса с именем 'orderData'.
         ========================================================== -->
    <bpmn:serviceTask id="create_order_1c"
                      name="Создать приказ в 1С"
                      camunda:expression="${oneSClient.createOrder(
                        execution.getVariable('orderData'))}" />

    <!-- ==========================================================
         END EVENT: end_approved
         Тип: None End Event (кружок с толстой обводкой, без маркера).
         Простое завершение процесса — не отправляет сообщение,
         не кидает ошибку, не выбрасывает сигнал.
         ========================================================== -->
    <bpmn:endEvent id="end_approved" name="Заявка одобрена" />

  </bpmn:process>
</bpmn:definitions>

Вопросы и шаблоны ответов

Вопрос 1. Start Event (0,5 балла)

Вопрос: Какой тип Start Event используется? Что должно произойти, чтобы процесс запустился?

Подсказки:

Посмотрите на тег внутри <bpmn:startEvent> — внутри есть <bpmn:messageEventDefinition />
Сравните: None Start — просто кружок (нет вложенных тегов). Message Start — кружок с конвертом (есть <bpmn:messageEventDefinition />). Timer Start — кружок с часами (<bpmn:timerEventDefinition />)
Message Start означает, что процесс стартует не по нажатию кнопки, а при получении сообщения из внешней системы

Шаблон ответа:

Используется _______________ Start Event (маркер: _______________).
Чтобы процесс запустился, необходимо ______________________________
__________________________________________________________________.

Вопрос 2. User Task и assignee (0,5 балла)

Вопрос: Что означает camunda:assignee="${manager}"? Как Camunda поймёт, кто конкретно этот manager?

Подсказки:

${...} — это Camunda Expression Language (EL), аналогично JSP EL/JUEL
Переменная manager должна быть установлена в контексте процесса до того, как задача reachable
Переменная может прийти: (а) в стартовом сообщении, (б) из предыдущего Service Task, (в) из скрипта
Если переменная не установлена — Camunda бросит исключение при попытке создать таск
Альтернативы assignee: camunda:candidateUsers (список пользователей) или camunda:candidateGroups (группы)

Шаблон ответа:

camunda:assignee="${manager}" означает, что задача назначается
исполнителю, который хранится в переменной процесса ___________.

Camunda определит менеджера следующим образом:
1. _______________________________________________________________
2. _______________________________________________________________

Если переменная manager не задана, то произойдёт ________________.

Вопрос 3. Loop Characteristics (0,5 балла)

Вопрос: Задача approve_task имеет loopCharacteristics. Что это значит? Сколько раз максимум может повторяться задача? Что произойдёт после 3-й попытки?

Подсказки:

standardLoopCharacteristics — это цикл с предусловием: задача выполняется, затем проверяется условие, и если оно истинно — задача запускается снова
loopCount — встроенная переменная Camunda, которая автоматически инкрементируется при каждом повторении цикла (начинается с 0)
Условие ${loopCount < 3} проверяется после выполнения задачи
Важно: После 3-й попытки (когда loopCount = 2 и больше не удовлетворяет условию) поток НЕ выходит из цикла — задача считается выполненной, и поток идёт дальше по обычному Sequence Flow
Максимальное количество выполнений = 3 (при loopCount = 0, 1, 2)
Если бы было MultiInstanceLoopCharacteristics — это был бы параллельный цикл (для нескольких исполнителей)

Шаблон ответа:

loopCharacteristics означает, что задача _________________________
_________________________________________________________________.

Максимальное количество повторений: ___ (при loopCount = ___).
 
После 3-й попытки (когда условие ${loopCount < 3} становится
__________) поток ________________________________________________.

Важное отличие от MultiInstance: _______________________________.

Вопрос 4. Boundary Event (0,5 балла)

Вопрос: Какой тип Boundary Event используется? Что означает cancelActivity="true"? Что произойдёт через 72 часа?

Подсказки:

Событие прикреплено к задаче (attachedToRef="approve_task") — это Boundary Event
Внутри <bpmn:timerEventDefinition> — значит Timer Boundary Event
cancelActivity="true" = Interrupting (прерывающий) — сплошная обводка
cancelActivity="false" = Non-Interrupting (непрерывающий) — пунктирная обводка
PT72H = 72 часа (3 дня), отсчёт начинается с момента старта задачи
Если руководитель не нажал «Согласовать» за 72 часа — задача прерывается, поток уходит по таймеру
Если руководитель успел согласовать до таймера — таймер просто игнорируется, процесс идёт обычным путём

Шаблон ответа:

Тип Boundary Event: __________________ (маркер: __________________).

cancelActivity="true" означает, что это _________________________
(____________________) таймер. Если бы было false — _____________
_________________________________________________________________.

Через 72 часа (PT72H) произойдёт: _______________________________
_________________________________________________________________.
При этом если руководитель согласует заявку до таймера: _________
_________________________________________________________________.

Вопрос 5. Service Task (0,5 балла)

Вопрос: Каким способом реализован вызов 1С (Delegate Expression, Expression, External Task, Script)? Что делает строка ${oneSClient.createOrder(execution.getVariable('orderData'))}?

Подсказки:

camunda:expression — это Expression Language (EL), самый простой способ
Delegate Expression: camunda:delegateExpression="${myBean}" — вызов целого Java-класса
Expression: camunda:expression="${myBean.doStuff(execution)}" — вызов метода бина
External Task: camunda:topic="createOrderIn1C" — асинхронная задача, воркер опрашивает движок
Script: camunda:script — скрипт на JS/Groovy/Python
oneSClient — это Spring Bean (или CDI-бин), зарегистрированный по имени
execution.getVariable('orderData') — получение переменной процесса orderData
Если метод createOrder — выбрасывает BPMN Error (через throw new BpmnError), то можно прикрепить Error Boundary Event к Service Task для обработки ошибки

Шаблон ответа:

Способ реализации: __________________ (атрибут ___________).

Строка ${oneSClient.createOrder(execution.getVariable('orderData'))}
означает:
• oneSClient — это _______________________________________________
• execution.getVariable('orderData') — ___________________________
• Метод createOrder вызывается ___________________________________
  (синхронно/асинхронно), в том же/отдельном потоке.

Если нужно обработать ошибку интеграции с 1С, можно добавить:
_________________________________________________________________.

Дополнительное задание на понимание (бонус, не оценивается)

Подумайте: что нужно изменить в XML, чтобы:

Сделать таймер Non-Interrupting? → cancelActivity="false"
Увеличить лимит повторений задачи до 5? → ${loopCount < 5}
Заменить Expression на External Task? → camunda:topic="createOrderIn1C"
Добавить Error Boundary Event на Service Task? → <bpmn:boundaryEvent attachedToRef="create_order_1c"><bpmn:errorEventDefinition /></bpmn:boundaryEvent>

Задание 4: Сравнительный анализ BPMN и UML Activity (2 балла)

Ответьте на 4 вопроса. Каждый ответ — 3–5 предложений. Используйте конкретные аргументы, примеры из курса.

Пошаговая инструкция

Шаг	Что сделать	Почему это важно
4.1	Прочитайте лекцию 04-03 (Activity Diagrams)	Там есть таблица сравнения BPMN vs Activity
4.2	Для каждого вопроса составьте тезисы	Не пишите «лишь бы было», аргументируйте
4.3	Приведите конкретный пример из вашего опыта или из кейса «ТехноПрогресс»	Примеры = глубина ответа
4.4	Проверьте: ответ содержит и сильные, и слабые стороны обеих нотаций	Баланс = экспертность

Вопросы и шаблоны ответов

Вопрос 4.1: Простота восприятия (0,5 балла)

Вопрос: Для какого типа аудитории (заказчик, разработчик, аналитик) BPMN понятнее, а для какого — UML Activity Diagram? Почему?

Подсказки:

UML Activity старше и проще — Action (прямоугольник со скруглёнными углами), Decision (ромб), Fork/Join (палки)
BPMN требует понимания типов событий (Message, Timer, Error...) — это сложнее для неподготовленного пользователя
Заказчик (business stakeholder) хочет видеть поток шагов, а не технические детали — UML Activity ему проще
Разработчику важно точно знать тип задачи (User Task vs Service Task) — BPMN даёт эту точность
Аналитик должен владеть обеими нотациями, выбирая под задачу

Шаблон ответа:

UML Activity Diagram понятнее для: ______________________________,
потому что ______________________________________________________.

BPMN понятнее для: ______________________________________________,
потому что ______________________________________________________.

Моё мнение: в проекте типа «ТехноПрогресс» для коммуникации с
заказчиком я бы выбрал __________, а для передачи в разработку —.

Вопрос 4.2: Автоматизация (0,5 балла)

Вопрос: Можно ли «запустить» UML Activity Diagram в BPM-движке? Если нет — почему BPMN подходит для этого, а UML — нет?

Подсказки:

BPMN 2.0 — это не только нотация, но и формат (XML, который можно исполнить)
UML Activity — это только нотация, нет стандартного исполняемого формата
BPMN имеет isExecutable="true" и элементы с привязкой к IT: Service Task, Send/Receive Task, Message Events
BPMN-движки (Camunda, Flowable, jBPM) читают XML-файл, создают ProcessInstance и выполняют шаги
UML Activity может быть исполнена только если её вручную переписать в BPMN или в код
Исключение: fUML (Foundational UML) — но это редкость и не индустриальный стандарт

Шаблон ответа:

UML Activity Diagram _________ (можно / нельзя) запустить в
BPM-движке, потому что __________________________________________

BPMN подходит для автоматизации, так как:
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

Практический вывод: если нужна исполняемая модель — выбираем ____.

Вопрос 4.3: Гранулярность (0,5 балла)

Вопрос: В BPMN есть Task, Subprocess, Call Activity. В UML Activity — Action и Structured Activity. Какая нотация даёт более точное описание процесса? В каких ситуациях избыточность BPMN оправдана?

Подсказки:

BPMN различает 8 типов задач: User, Service, Send, Receive, Business Rule, Script, Manual, Reference
UML Activity имеет только Action (общее действие) и Structured Activity (группа действий)
Избыточность BPMN оправдана: когда процесс идёт в разработку (нужно точно указать, кто что делает), при сложных интеграциях (Service Task vs Send Task), при моделировании исключений (Error Boundary Events)
UML Activity достаточна: для верхнеуровневого описания бизнес-процесса, для Presentation to stakeholders, для быстрого «набрасывания» идеи
Пример: «Обработать заказ» — в UML это одно Action, в BPMN можно декомпозировать в Subprocess с 5+ шагами

Шаблон ответа:

Более точное описание даёт __________, потому что _______________

Избыточность BPMN оправдана в ситуациях:
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

При этом UML Activity лучше использовать когда: _________________.

Вопрос 4.4: Реальный выбор (0,5 балла)

Вопрос: В вашем проекте процесс средней сложности (5 ролей, 15 шагов, 3 интеграции с внешними системами). Команда знает UML, но не знает BPMN. Будете ли вы настаивать на BPMN или использовать UML Activity? Аргументируйте.

Подсказки:

3 интеграции — это Service Tasks или Send/Receive Tasks → BPMN даёт точные элементы
5 ролей — Swimlane есть в обеих нотациях (не аргумент)
15 шагов — средняя сложность, обе нотации справятся
Команда не знает BPMN — придётся учить (cost = 2–3 дня обучения)
Ключевой вопрос: процесс будет исполняться в BPM-движке? Если да — BPMN обязателен. Если нет — можно UML.
Компромисс: начать с UML Activity для согласования с заказчиком, затем перевести в BPMN для разработки
Ваш ответ должен быть обоснованным, а не однозначным «да» или «нет»

Шаблон ответа:

Моё решение: ____________________________________________________.

Аргументы за BPMN:
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

Аргументы за UML Activity:
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

Итоговый план действий:
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

Детальная таблица баллов (Задание 4)

Вопрос	Баллы	Условие получения	Типичная ошибка
4.1 — Простота восприятия	0,5	Указаны обе аудитории (кому UML проще, кому BPMN) с обоснованием почему	Только «UML проще», без анализа BPMN — 0,2 балла
4.2 — Автоматизация	0,5	Объяснена разница: BPMN — исполняемый XML, UML — только нотация	Не упомянут `isExecutable` и XML-формат BPMN — 0,2 балла
4.3 — Гранулярность	0,5	Приведены примеры типов задач из BPMN и ситуаций, где избыточность оправдана	Просто «BPMN точнее» без примеров — 0,2 балла
4.4 — Реальный выбор	0,5	Аргументированное решение с учётом контекста (5 ролей, 15 шагов, 3 интеграции, команда не знает BPMN)	Ответ без учёта входных данных — 0,1 балла
Итого	2,0

Итоговые критерии оценки

Распределение баллов по заданиям

Задание	Макс. балл	Вес в оценке	Время выполнения (ориентир)
Задание 1: BPMN AS-IS	2,5	25%	40 мин
Задание 2: BPMN TO-BE	3,0	30%	60 мин
Задание 3: Анализ исполняемой модели	2,5	25%	45 мин
Задание 4: Сравнительный анализ	2,0	20%	30 мин
Всего	10,0	100%	~3 часа

Шкала перевода в оценку

Набрано баллов	Оценка	Уровень
9,0–10,0	Отлично	🟢 Экспертный уровень. Студент готов к реальным проектам
7,0–8,9	Хорошо	🟡 Продвинутый уровень. Требуется практика на реальных кейсах
5,0–6,9	Удовлетворительно	🟠 Базовый уровень. Рекомендуется повторное прохождение сложных тем
0–4,9	Требуется доработка	🔴 Недостаточный уровень. Необходимо пересдать после изучения теории

Как проверяется работа (алгоритм проверяющего)

Шаг	Что проверяется	Макс. балл
1	Задание 1: Lane, Start/End, User Tasks, логика, читаемость	2,5
2	Задание 2: Pool, Lane, правильные типы элементов, Boundary Timer, Event-based Gateway, корректность логики	3,0
3	Задание 3: Полнота ответов, цитирование тегов XML, понимание Camunda-специфики	2,5
4	Задание 4: Глубина анализа, примеры, баланс аргументов	2,0
5	Штрафы за общие требования (см. таблицу ниже)	до −1,5
	Итого	10,0

Штрафы за нарушение общих требований

Нарушение	Штраф
Нет Lane или меньше 2 Lane	−0,5 балла (от общего балла)
Названия элементов — существительные («Согласование», «Проверка»)	−0,2 балла за каждое нарушение (не более −0,6)
Sequence Flow без подписей-условий в квадратных скобках	−0,2 балла за каждый неподписанный поток
Нет Default Flow у Gateway	−0,3 балла за каждый Gateway (не более −0,6)
Ветка без End Event	−0,3 балла за каждую незавершённую ветку
Event-based Gateway с Task вместо Catch Event	−0,5 балла (грубая ошибка)
Pool «Внешние системы» отсутствует или 1С внутри того же Pool	−0,3 балла
Максимальный штраф	−1,5 балла

Примеры правильных и неправильных решений

Правильно (эталон)

Элемент	Как должно быть
User Task	«Согласовать заявку» (глагол + существительное, значок человечка)
Sequence Flow с условием	`[Дней >= 14]` — условие в квадратных скобках
Service Task	«Создать приказ в 1С» (шестерёнка, camunda:expression)
Boundary Timer	Прикреплён к User Task, cancelActivity="true", PT72H
Event-based Gateway	После него — только Intermediate Catch Events (Message + Timer)

Неправильно (типичные ошибки)

Ошибка	Как выглядит	Почему это ошибка
Lane = должности	«Менеджер» вместо «Руководитель»	Lane — это роль, а не должность
Task без маркера	Просто прямоугольник со скруглёнными углами	Непонятно, кто выполняет: человек или система
После Event-based Gateway — User Task	User Task сразу после ромба	Event-based Gateway ждёт события, а не задачи
Нет подписей у XOR	Два потока выходят из ромба без текста	Непонятно, какое условие ведёт куда
Non-Interrupting вместо Interrupting	Пунктирная обводка таймера	Руководитель должен быть прерван, а не дублирован

Требования к оформлению

Формат: Markdown (.md) или PDF
Скриншоты: Если используете Camunda Modeler — экспортируйте диаграмму в PNG (Файл → Экспорт как → PNG). Вставьте в документ.
Задание 3: Код XML дан в задании — на него ссылайтесь текстом. Ответы пишите развёрнуто.
Именование файла: 05-bpmn-assignment_ФамилияИО.md или .pdf
Структура документа:
- Заголовок: ФИО, дата
- Задание 1: скриншот + описание
- Задание 2: скриншот + описание
- Задание 3: ответы на 5 вопросов (с цитированием XML)
- Задание 4: ответы на 4 вопроса

Чек-лист самопроверки перед сдачей

Задание 1 (AS-IS)

Все 3 Lane присутствуют и названы верно
6 User Tasks (минимум 5) покрывают все шаги кейса
Start Event и End Event есть
Нет автоматических элементов (Service Task, Gateway с условиями)
Sequence Flow не пересекаются, диаграмма читаема

Задание 2 (TO-BE)

Задание 3 (XML-анализ)

В ответе цитируются конкретные теги XML (<bpmn:messageEventDefinition />, cancelActivity="true" и т.д.)
Показано понимание разницы Interrupting / Non-Interrupting
Показано понимание loopCharacteristics
Показано понимание способов реализации Service Task (Expression vs Delegate vs External)

Задание 4 (Сравнение)

Каждый ответ — 3–5 предложений
Есть аргументы как «за» BPMN, так и «за» UML
Приведены примеры (из кейса или из курса)
Ответы развёрнутые, не односложные

Модуль 05: Моделирование в BPMN — Практическое задание

Общая информация

Кейс: Процесс обработки заявки на отпуск

Контекст

Общие требования для всех заданий (обязательны к выполнению)

Задание 1: BPMN AS-IS (2,5 балла)

Пошаговая инструкция

Какие задачи должны быть на диаграмме (минимум 5):

Шаблон ответа для Задания 1

Детальная таблица баллов

Задание 2: BPMN TO-BE с автоматизацией (3 балла)

Что меняется (описание TO-BE)

Пошаговая инструкция

Ключевые требования к диаграмме TO-BE

Шаблон ответа для Задания 2

Детальная таблица баллов

Задание 3: Анализ исполняемой модели (2,5 балла)

Фрагмент XML (с комментариями)

Вопросы и шаблоны ответов

Вопрос 1. Start Event (0,5 балла)

Вопрос 2. User Task и assignee (0,5 балла)

Вопрос 3. Loop Characteristics (0,5 балла)

Вопрос 4. Boundary Event (0,5 балла)

Вопрос 5. Service Task (0,5 балла)

Дополнительное задание на понимание (бонус, не оценивается)

Задание 4: Сравнительный анализ BPMN и UML Activity (2 балла)

Пошаговая инструкция

Вопросы и шаблоны ответов

Вопрос 4.1: Простота восприятия (0,5 балла)

Вопрос 4.2: Автоматизация (0,5 балла)

Вопрос 4.3: Гранулярность (0,5 балла)

Вопрос 4.4: Реальный выбор (0,5 балла)

Детальная таблица баллов (Задание 4)

Итоговые критерии оценки

Распределение баллов по заданиям

Шкала перевода в оценку

Как проверяется работа (алгоритм проверяющего)

Штрафы за нарушение общих требований

Примеры правильных и неправильных решений

Правильно (эталон)

Неправильно (типичные ошибки)

Требования к оформлению

Чек-лист самопроверки перед сдачей

Задание 1 (AS-IS)

Задание 2 (TO-BE)

Задание 3 (XML-анализ)

Задание 4 (Сравнение)

Рекомендуемые ресурсы

✍️ Ваш ответ

📚 Материалы модуля

🖼️ Схема и инфографика

🎬 Видео-лекция

📄 Дополнительные материалы (PDF)