---
title: Применение нотаций
questionDates:
  q-transfer-0341: '2026-10-01'
  q-transfer-0359: '2026-10-01'
  q-transfer-0369: '2026-10-01'
  q-transfer-0370: '2026-10-01'
seo:
  description: >-
    Тема «Применение нотаций» для собеседования Systems Analyst. Нарисуйте
    диаграмму последовательностей получения данных из REST-сервиса через
    веб-форму. Составьте схему BPMN для процесса, описывающего работу банкомата
    (устно).
  title: Применение нотаций — Systems Analyst
---

[Все темы Systems Analyst](/prep/systems-analyst)

## Нарисуйте диаграмму последовательностей получения данных из REST-сервиса через веб-форму. [#q-14bee738d69b8181bc27c8a27bae64f6]

Структура диаграммы последовательности для процесса, когда пользователь отправляет запросы в <code>REST</code>-сервис через веб-форму&#58;

{/* prettier-ignore */}
1. <strong>Актеры</strong>&#58;

    - Пользователь (User)

    - REST-сервис (REST Service)

1. <strong>Основные шаги&#58;</strong>

    - Пользователь заполняет и отправляет веб-форму.

    - Веб-сервер получает запрос от пользователя.

    - Веб-сервер отправляет запрос REST-сервису для получения данных.

    - REST-сервис обрабатывает запрос и выполняет необходимые операции.

    - REST-сервис возвращает данные в ответ на запрос.

    - Веб-сервер получает данные от REST-сервиса.

    - Веб-сервер отображает полученные данные пользователю.

1. <strong>События и сообщения&#58;</strong>

    - Событие&#58; "Отправка запроса от пользователя через веб-форму".

    - Сообщение&#58; "Запрос данных к REST-сервису".

    - Событие&#58; "Получение данных от REST-сервиса".

1. <strong>Диаграмма последовательности</strong>&#58;

    - Покажите отдельные линии жизни пользователя, браузера с веб-формой, веб-сервера и REST-сервиса. Если браузер вызывает REST API напрямую, промежуточный веб-сервер не нужен. Добавьте сообщения запроса, ответа и ветку ошибки.

Этот процесс демонстрирует взаимодействие между пользователем, веб-сервером и <code>REST</code>-сервисом при получении данных через веб-форму и <code>REST API</code>.

:::note[Ссылки для изучения]

1. [Участники, сообщения и альтернативные ответы на диаграмме последовательности — PlantUML](https://plantuml.com/ru/sequence-diagram)
2. [Последовательность запроса от формы до базы данных. Максим Бриз Бизнес и системный анализ BPMN, с 3:27](https://www.youtube.com/watch?v=KcUEvd8okm0&t=207s)

:::

---

## <strong>Составьте схему</strong> <code>BPMN</code> <strong>для процесса, описывающего работу банкомата (устно)</strong> [#q-14bee738d69b813580ebe865a6ea961e]

Для описания работы банкомата с использованием <code>BPMN</code> (Business Process Model and Notation) можно представить следующую схему&#58;

{/* prettier-ignore */}
1. <strong>Начало процесса</strong>&#58;

    - Начальное событие&#58; "Пользователь приходит к банкомату".

1. <strong>Основные шаги</strong>&#58;

    - Активность&#58; "Ввод PIN-кода пользователем".

    - Шлюз (Gateway)&#58; "Проверка правильности PIN-кода".

        - Если PIN-код верен&#58; переход к следующему шагу.

        - Если PIN-код неверен&#58; возврат к вводу PIN-кода.

    - Активность&#58; "Выбор операции (снятие/пополнение/баланс)".

    - Шлюз&#58; "Выбор типа операции".

        - Различные ветви в зависимости от выбора операции (снятие/пополнение/просмотр баланса).

    - Активность&#58; "Выполнение операции банкоматом".

    - Шлюз&#58; "Подтверждение выполнения операции".

        - Если операция выполнена успешно&#58; завершение процесса.

        - Если произошла ошибка&#58; переход к началу или альтернативным шагам.

1. <strong>Завершение процесса</strong>&#58;

    - Конечное событие&#58; "Пользователь забирает карту и чек".

:::note[Ссылки для изучения]

1. [Элементы BPMN и построение процесса: события, задачи и шлюзы — Сбер](https://habr.com/ru/companies/sberbank/articles/836092/)
   :::

---

## <strong>Какие бывают</strong> <code>Gateway</code> <strong>в</strong> <code>BPMN</code><strong>?</strong> [#q-14bee738d69b817999f0dc43e4f64df2]

В <code>BPMN</code> (Business Process Model and Notation) существуют различные типы шлюзов (<code>Gateways</code>), которые используются для управления потоком процесса. Основные типы шлюзов в <code>BPMN</code>&#58;

{/* prettier-ignore */}
1. <strong>Exclusive Gateway (</strong><code>XOR</code><strong>)</strong>&#58;

    - Используется для принятия решений на основе условий.

    - Позволяет выбирать один из нескольких исходящих потоков в зависимости от выполнения условия.

1. <strong>Inclusive Gateway (</strong><code>OR</code><strong>)</strong>&#58;

    - Позволяет выбирать несколько исходящих потоков одновременно.

    - Используется для моделирования альтернативных путей выполнения процесса, когда могут выполняться несколько условий одновременно.

1. <strong>Parallel Gateway (</strong><code>AND</code><strong>)</strong>&#58;

    - Используется для разделения потока процесса на несколько параллельных путей.

    - Все исходящие потоки выполняются параллельно и независимо друг от друга.

1. <strong>Complex Gateway</strong>&#58;

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

    - Используется для описания более специфических случаев, требующих детализации логики принятия решений.

Каждый тип шлюза в BPMN имеет свои особенности и применяется в зависимости от необходимости моделирования конкретных условий и потоков выполнения процесса.

:::note[Ссылки для изучения]

1. [XOR, AND и OR: выбор и синхронизация ветвей BPMN — Сбер](https://habr.com/ru/companies/sberbank/articles/836092/)
1. [Комплексный шлюз BPMN и activationCondition — раздел 10.5.5 перевода ELMA](https://elma365.com/ru/bpmn2/10_5/)
1. [Параллельная и исключающая развилки BPMN. Максим Бриз Бизнес и системный анализ BPMN, с 19:52](https://www.youtube.com/watch?v=uEbQTCqyNpc&t=1192s)

:::

---

## Как проверить корректность BPMN-диаграммы? [#q-transfer-0341]

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

:::note[Ссылки для изучения]

1. [Проверка шлюзов BPMN: повторное выполнение и взаимная блокировка потоков — памятка Сбера](https://habr.com/ru/companies/sberbank/articles/836092/)
   :::

---

## Когда в BPMN нужен событийный шлюз? [#q-transfer-0359]

Событийный шлюз нужен, когда после него процесс ждёт одно из нескольких альтернативных событий, например сообщение клиента или истечение таймера. Побеждает первое наступившее событие, остальные ожидающие ветви отменяются. Исходящие ветви должны вести к catching event или receive task и не задаются обычными условиями данных. Exclusive gateway выбирает ветвь сразу по уже известным данным, поэтому это другой механизм. Типичный пример: ждать подтверждение оплаты не больше 15 минут, затем продолжить по сообщению либо по таймауту. Важно проверить, что каждый допустимый исход имеет продолжение.

:::note[Ссылки для изучения]

1. [Событийный шлюз: ожидание альтернативных событий — BPMN 2.0, раздел 10.5.6 в переводе ELMA](https://elma365.com/ru/bpmn2/10_5/)
   :::

---

## Когда использовать фрагмент opt на sequence diagram? [#q-transfer-0369]

Фрагмент `opt` показывает одну условную последовательность: она выполняется, только если истинно guard-условие, например `[товар есть на складе]`. Если условие ложно, взаимодействие внутри фрагмента пропускается. Когда нужно показать две или больше взаимоисключающих ветвей, используют `alt`, а не несколько несвязанных `opt`, если они создают ложное впечатление независимости. Guard пишут как понятное бизнес-условие, а рамкой охватывают только участвующие сообщения и lifeline. Мелкие очевидные проверки лучше не добавлять: диаграмма должна объяснять взаимодействие, а не повторять каждую строку алгоритма.

:::note[Ссылки для изучения]

1. [Фрагменты opt и alt: дополнительное действие и альтернативные ветви sequence diagram](https://habr.com/ru/articles/814769/)
2. [Опциональный фрагмент на диаграмме последовательности. Максим Бриз Бизнес и системный анализ BPMN, с 7:40](https://www.youtube.com/watch?v=KcUEvd8okm0&t=460s)

:::

---

## Как показать цикл на диаграмме последовательности? [#q-transfer-0370]

Повторяющуюся последовательность помещают в combined fragment `loop`. В guard указывают условие или диапазон повторений, например `[для каждого элемента]` или `[пока статус pending]`, а рамка показывает, какие сообщения входят в итерацию. Нужно обозначить, кто меняет условие завершения, иначе диаграмма допускает бесконечный цикл. Если внутри много ветвей и деталей, лучше вынести повторяемое взаимодействие в отдельную диаграмму или `ref`, оставив на верхнем уровне цель цикла. Sequence diagram показывает обмен сообщениями, поэтому сложный алгоритм цикла удобнее описать текстом или activity diagram.

:::note[Ссылки для изучения]

1. [Повторяющийся обмен сообщениями: фрагмент loop в диаграмме последовательности](https://habr.com/ru/articles/814769/)
   :::
