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 — про устрій і поведінку системи. Перетинаються вони на діаграмі активності, і простий процес можна намалювати в будь-якій. Далі — один випадок із твоєї практики: який процес, яку нотацію ти вибрав і чому, яка схема знадобилася потім розробці.

Якщо співрозмовник копає глибше, скажи, як ти вибираєш: хто читатиме схему і що з нею робитимуть далі. Це відрізняє людину, яка малювала схеми для людей, від тієї, яка знає назви діаграм.