BPMN и UML: чем отличаются и что выбрать под задачу

Открываешь редактор на старте проекта — и спотыкаешься на первом же вопросе: рисовать процесс в BPMN или в UML. В команде обязательно найдётся человек, уверенный, что «UML — это для программистов», и второй, который так же уверенно ответит: «BPMN — это просто красивые блок-схемы». Оба правы наполовину.

Разница между нотациями не в том, какая из них профессиональнее. Она в предмете. BPMN описывает работу: кто из участников что делает, в каком порядке и что запускает следующий шаг. UML описывает систему: из каких частей она состоит, как эти части связаны и как ведут себя во времени. Один язык отвечает на вопрос «как идёт процесс», второй — «как устроено то, что его исполняет».

Пересекаются они в одном месте — на диаграмме активности UML. Там же чаще всего и путаются.

Дальше — чем устроены обе нотации, где проходит граница, три вопроса для выбора и как один и тот же процесс выглядит в двух моделях.

Два языка для двух разных вопросов

Нотация — это договорённость о значках и правилах их соединения. Без неё две схемы одного процесса, нарисованные двумя людьми, нельзя сравнить: у одного ромб — решение, у другого — просто акцент.

BPMN и UML — две такие договорённости, и обе поддерживает один консорциум, OMG. Но создавались они под разных читателей. BPMN рассчитан на то, чтобы схему прочитали и владелец процесса, и аналитик, и разработчик, который потом этот процесс автоматизирует. UML вырос из проектирования программ, и его основной читатель — тот, кто систему строит.

Отсюда простое правило, которое почти никогда не подводит. Если на схеме должны быть люди, отделы и компании, передающие друг другу работу, — это BPMN. Если на схеме должны быть классы, компоненты, сообщения между сервисами и состояния объектов — это UML.

Выбор нотации начинается не с редактора, а с вопроса: кто будет читать схему и что он с ней сделает.

BPMN: кто, что и в каком порядке

BPMN расшифровывается как Business Process Model and Notation. Словарь у него небольшой и заточен под одну задачу. Пул — участник процесса, обычно организация. Дорожка внутри пула — роль или подразделение. Задача — шаг работы. Событие — то, что происходит: пришла заявка, истёк срок, получен платёж. Шлюз — развилка. Поток сообщений — передача информации между участниками, у которых нет общего начальника.

Как международный стандарт нотация закреплена в ISO/IEC 19510

, и этот стандарт идентичен версии OMG BPMN 2.0.1. Он определяет три вида диаграмм: процесса, взаимодействия участников и хореографии — обмена сообщениями между сторонами без раскрытия их внутренней кухни. В 2022 году ISO пересмотрел стандарт и подтвердил его, так что он действующий. У самого OMG последняя версия — 2.0.2 от января 2014 года.

На практике аналитик почти всё время работает с первыми двумя видами. Диаграмма процесса показывает, как работа идёт внутри одной организации. Диаграмма взаимодействия — как организации передают друг другу сообщения: клиент отправляет заявку, банк возвращает решение.

Сильная сторона BPMN — события и границы ответственности. На схеме видно, где процесс ждёт внешнего сигнала, где работа переходит из рук в руки и где она может застрять, потому что у шага нет исполнителя. Именно на этих стыках процессы обычно и ломаются.

UML: из чего система и как она себя ведёт

UML — Unified Modeling Language. Это не одна диаграмма, а семейство, и делится оно на две группы. Структурные диаграммы показывают, из чего система состоит: классы, компоненты, развёртывание по серверам. Поведенческие — как она работает: варианты использования, последовательности сообщений, состояния объекта, активности.

Как международный стандарт UML закреплён в двух частях ISO/IEC 19505:2012: первая описывает инфраструктуру языка, вторая — надстройку, то есть сами диаграммы. Обе ISO подтвердил в 2025 году. У OMG актуальная версия — UML 2.5.1 от декабря 2017 года.

Любопытная деталь: в описании второй части стандарта сказано, что UML нужен и для моделирования бизнес-процессов, а не только программ. Так что утверждение «UML процессы не описывает» неверно. Описывает. Вопрос в том, насколько удобно и для кого.

Аналитику из всего семейства на практике нужны четыре-пять диаграмм: вариантов использования, последовательности, состояний, активности и, реже, классов — когда нужно договориться о понятиях предметной области. Диаграмма вариантов использования показывает акторов и их цели, но не шаги — шаги записывают текстом, и как это делают, разобрано в статье User Story и Use Case: чем отличаются и что писать.

Где они пересекаются: диаграмма активности

Диаграмма активности UML умеет почти то же, что процесс BPMN: действия, развилки, параллельные ветки, начало и конец. Даже дорожки у неё есть — в спецификации они называются разделами активности (activity partitions) и группируют действия по исполнителю.

Поэтому простой процесс можно нарисовать и так, и так, и схемы будут похожи. Разница проявляется, как только процесс выходит за пределы одной команды.

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

Диаграмма активности сильнее, когда процесс идёт внутри системы. Она естественно встраивается в остальную UML-модель: действие может ссылаться на операцию класса, объектный поток — на сущность из диаграммы классов. Для алгоритма внутри сервиса это удобнее, чем BPMN.

Как выбрать: три вопроса

Кто будет читать схему. Если среди читателей владелец процесса, юрист или руководитель отдела — BPMN. Они прочитают пулы и дорожки без подготовки. Если схему читают только архитектор и разработчики — UML им привычнее.

Что на схеме: люди или части системы. Работа, которая переходит между людьми, отделами и компаниями, — BPMN. Взаимодействие сервисов, жизненный цикл объекта, структура данных — UML. Если на одной схеме оказываются и бухгалтерия, и таблица базы данных, это сигнал, что схем должно быть две.

Что будет с моделью дальше. Согласовать регламент, найти узкое место, автоматизировать процесс в BPM-системе — BPMN. Спроектировать интеграцию, описать поведение экрана или сервиса, передать задачу в разработку — UML.

Если ответы расходятся, это не ошибка. Значит, в проекте нужны обе модели.

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

Один процесс, две модели

Возьмём возврат денег за заказ. В BPMN это пул клиента и пул компании с дорожками «поддержка», «склад», «финансы». Клиент подаёт заявку — сообщение уходит в компанию. Поддержка проверяет заказ, шлюз разводит поток: товар нужно вернуть или нет. Таймер на ожидании посылки: не пришла за 14 дней — заявка закрывается. Финансы проводят возврат, клиент получает уведомление. На этой схеме видно, где процесс ждёт и кто за какой шаг отвечает.

В UML тот же возврат — другие вопросы. Диаграмма состояний заявки: создана, на проверке, ждёт товар, одобрена, отклонена, выплачена — и какие переходы между ними разрешены. Диаграмма последовательности: сервис возвратов запрашивает заказ, вызывает платёжный шлюз, получает ответ, пишет в журнал. Здесь видно, что система должна уметь и в каком порядке обмениваться данными.

Обе модели описывают один процесс и не спорят друг с другом. Связывают их требования: шаг «финансы проводят возврат» в BPMN раскрывается функциональными требованиями, а они — поведением сервиса в UML. Чтобы эта связь не терялась при изменениях, её фиксируют трассировкой — как это делается, разобрано в статье про матрицу трассировки требований. А про то, где проходит граница между целью бизнеса и поведением системы, — в разборе чем бизнес-требования отличаются от функциональных.

Как это звучит на собеседовании

Вопрос про BPMN и UML задают часто, и слабый ответ звучит как список: «BPMN — для процессов, UML — для систем, в UML много диаграмм». Верно, но так отвечает любой, кто прочитал одну статью.

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

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