BPMN i UML: czym się różnią i co wybrać do zadania

Otwierasz edytor na starcie projektu — i potykasz się już na pierwszym pytaniu: rysować proces w BPMN czy w UML? W zespole zawsze znajdzie się ktoś przekonany, że „UML jest dla programistów”, i drugi, który równie pewnie odpowie: „BPMN to po prostu ładne schematy blokowe”. Obaj mają rację tylko w połowie.

Różnica między notacjami nie polega na tym, która jest bardziej profesjonalna. Polega na przedmiocie. BPMN opisuje pracę: kto z uczestników co robi, w jakiej kolejności i co uruchamia kolejny krok. UML opisuje system: z jakich części się składa, jak te części są powiązane i jak zachowują się w czasie. Jeden język odpowiada na pytanie „jak przebiega proces”, drugi — „jak zbudowane jest to, co go wykonuje”.

Przecinają się w jednym miejscu — na diagramie aktywności UML. Tam też najczęściej pojawia się zamieszanie.

Dalej — czym są obie notacje, gdzie przebiega granica, trzy pytania do wyboru i jak ten sam proces wygląda w dwóch modelach.

Dwa języki do dwóch różnych pytań

Notacja to umowa co do symboli i zasad ich łączenia. Bez niej dwóch schematów jednego procesu, narysowanych przez dwie osoby, nie da się porównać: u jednego romb to decyzja, u drugiego — po prostu akcent.

BPMN i UML to dwie takie umowy i obie rozwija to samo konsorcjum, OMG. Ale tworzono je dla różnych czytelników. BPMN jest pomyślany tak, żeby schemat przeczytali i właściciel procesu, i analityk, i deweloper, który później ten proces zautomatyzuje. UML wyrósł z projektowania programów, a jego główny czytelnik to ten, kto system buduje.

Stąd prosta zasada, która rzadko zawodzi. Jeśli na schemacie mają być ludzie, komórki organizacyjne i firmy przekazujące sobie pracę — to BPMN. Jeśli na schemacie mają być klasy, komponenty, komunikaty między serwisami i stany obiektów — to UML.

Wybór notacji zaczyna się nie od edytora, ale od pytania: kto będzie czytał schemat i co z nim zrobi.

BPMN: kto, co i w jakiej kolejności

BPMN to skrót od Business Process Model and Notation. Słownik ma niewielki i jest dostrojony do jednego zadania. Pula — uczestnik procesu, zwykle organizacja. Tor wewnątrz puli — rola lub komórka organizacyjna. Zadanie — krok pracy. Zdarzenie — to, co się dzieje: przyszło zgłoszenie, minął termin, otrzymano płatność. Brama — rozwidlenie. Przepływ komunikatów — przekazywanie informacji między uczestnikami, którzy nie mają wspólnego przełożonego.

Jako standard międzynarodowy notacja jest zapisana w ISO/IEC 19510

, a ten standard jest identyczny z wersją OMG BPMN 2.0.1. Określa trzy rodzaje diagramów: procesu, współpracy uczestników i choreografii — wymiany komunikatów między stronami bez ujawniania ich wewnętrznej kuchni. W 2022 roku ISO zrewidowało standard i potwierdziło go, więc obowiązuje. U samego OMG ostatnia wersja to 2.0.2 ze stycznia 2014 roku.

W praktyce analityk prawie cały czas pracuje z pierwszymi dwoma rodzajami. Diagram procesu pokazuje, jak praca przebiega wewnątrz jednej organizacji. Diagram współpracy — jak organizacje przekazują sobie komunikaty: klient wysyła zgłoszenie, bank zwraca decyzję.

Silną stroną BPMN są zdarzenia i granice odpowiedzialności. Na schemacie widać, gdzie proces czeka na sygnał zewnętrzny, gdzie praca przechodzi z rąk do rąk i gdzie może utknąć, bo krok nie ma wykonawcy. Właśnie na tych stykach procesy zwykle się psują.

UML: z czego składa się system i jak się zachowuje

UML — Unified Modeling Language. To nie jeden diagram, ale rodzina, i dzieli się na dwie grupy. Diagramy strukturalne pokazują, z czego system się składa: klasy, komponenty, rozmieszczenie na serwerach. Behawioralne — jak działa: przypadki użycia, sekwencje komunikatów, stany obiektu, aktywności.

Jako standard międzynarodowy UML jest zapisany w dwóch częściach ISO/IEC 19505:2012: pierwsza opisuje infrastrukturę języka, druga — nadbudowę, czyli same diagramy. Obie ISO potwierdziło w 2025 roku. U OMG aktualna wersja to UML 2.5.1 z grudnia 2017 roku.

Ciekawostka: w opisie drugiej części standardu napisano, że UML jest potrzebny także do modelowania procesów biznesowych, nie tylko programów. Więc twierdzenie „UML nie opisuje procesów” jest nieprawdziwe. Opisuje. Pytanie, na ile wygodnie i dla kogo.

Analitykowi z całej rodziny w praktyce potrzebne są cztery–pięć diagramów: przypadków użycia, sekwencji, stanów, aktywności i, rzadziej, klas — gdy trzeba uzgodnić pojęcia dziedziny przedmiotowej. Diagram przypadków użycia pokazuje aktorów i ich cele, ale nie kroki — kroki zapisuje się tekstem, a jak to robić, omawia artykuł User Story i Use Case: czym się różnią i co pisać.

Gdzie się przecinają: diagram aktywności

Diagram aktywności UML potrafi niemal to samo co proces BPMN: akcje, rozwidlenia, gałęzie równoległe, początek i koniec. Ma nawet tory — w specyfikacji nazywają się one partycjami aktywności (activity partitions) i grupują akcje według wykonawcy.

Dlatego prosty proces można narysować i tak, i tak, a schematy będą podobne. Różnica ujawnia się, gdy tylko proces wychodzi poza granice jednego zespołu.

BPMN jest bogatszy w zdarzenia: timery, komunikaty, błędy, eskalacje, przerwania mają swoje symbole i ścisłe znaczenie. Ma pule i przepływy komunikatów do pracy między organizacjami. Schemat BPMN łatwiej przeczytać człowiekowi, który nie projektuje systemów: symbole są bliżej języka biznesu.

Diagram aktywności jest silniejszy, gdy proces przebiega wewnątrz systemu. Naturalnie wpasowuje się w resztę modelu UML: akcja może odwoływać się do operacji klasy, przepływ obiektów — do encji z diagramu klas. Dla algorytmu wewnątrz serwisu jest to wygodniejsze niż BPMN.

Jak wybrać: trzy pytania

Kto będzie czytał schemat. Jeśli wśród czytelników jest właściciel procesu, prawnik lub kierownik komórki — BPMN. Przeczytają pule i tory bez przygotowania. Jeśli schemat czytają tylko architekt i deweloperzy — UML jest im bliższy.

Co jest na schemacie: ludzie czy części systemu. Praca, która przechodzi między ludźmi, komórkami i firmami — BPMN. Współpraca serwisów, cykl życia obiektu, struktura danych — UML. Jeśli na jednym schemacie znajdą się i księgowość, i tabela bazy danych, to sygnał, że schematy powinny być dwa.

Co będzie z modelem dalej. Uzgodnić regulamin, znaleźć wąskie gardło, zautomatyzować proces w systemie BPM — BPMN. Zaprojektować integrację, opisać zachowanie ekranu lub serwisu, przekazać zadanie zespołowi deweloperskiemu — UML.

Jeśli odpowiedzi się rozchodzą, to nie błąd. To znaczy, że w projekcie potrzebne są oba modele.

Ja zaczynałbym od pierwszego pytania. Schemat, którego nie potrafi przeczytać osoba go zatwierdzająca, trzeba rysować od nowa, a to najdroższy błąd przy wyborze notacji.

Jeden proces, dwa modele

Weźmy zwrot pieniędzy za zamówienie. W BPMN to pula klienta i pula firmy z torami „wsparcie”, „magazyn”, „finanse”. Klient składa zgłoszenie — komunikat idzie do firmy. Wsparcie sprawdza zamówienie, brama rozdziela przepływ: towar trzeba zwrócić albo nie. Timer na oczekiwaniu przesyłki: nie przyszła w 14 dni — zgłoszenie zostaje zamknięte. Finanse realizują zwrot, klient otrzymuje powiadomienie. Na tym schemacie widać, gdzie proces czeka i kto odpowiada za który krok.

W UML ten sam zwrot to inne pytania. Diagram stanów zgłoszenia: utworzone, w weryfikacji, czeka na towar, zatwierdzone, odrzucone, wypłacone — i jakie przejścia między nimi są dozwolone. Diagram sekwencji: serwis zwrotów pyta o zamówienie, wywołuje bramkę płatności, otrzymuje odpowiedź, zapisuje w dzienniku. Tutaj widać, co system musi umieć i w jakiej kolejności wymieniać dane.

Oba modele opisują jeden proces i nie kłócą się ze sobą. Łączą je wymagania: krok „finanse realizują zwrot” w BPMN rozwija się w wymagania funkcjonalne, a one — w zachowanie serwisu w UML. Żeby ten związek nie ginął przy zmianach, utrwala się go przez śledzenie — jak to się robi, omówiono w artykule o macierzy śledzenia wymagań. A o tym, gdzie przebiega granica między celem biznesowym a zachowaniem systemu — w analizie czym wymagania biznesowe różnią się od funkcjonalnych.

Jak to brzmi na rozmowie rekrutacyjnej

Pytanie o BPMN i UML zadaje się często, a słaba odpowiedź brzmi jak lista: „BPMN — do procesów, UML — do systemów, w UML jest dużo diagramów”. Prawda, ale tak odpowiada każdy, kto przeczytał jeden artykuł.

Mocna odpowiedź zaczyna się od przedmiotu, a kończy przykładem. BPMN — o pracy uczestników i przekazywaniu jej między nimi, UML — o budowie i zachowaniu systemu. Przecinają się na diagramie aktywności, a prosty proces można narysować w każdej z nich. Dalej — jeden przypadek z twojej praktyki: jaki proces, jaką notację wybrałeś i dlaczego, jaki schemat okazał się potem potrzebny deweloperom.

Jeśli rozmówca drąży głębiej, powiedz, jak wybierasz: kto będzie czytał schemat i co będzie z nim dalej robił. To odróżnia osobę, która rysowała schematy dla ludzi, od tej, która zna tylko nazwy diagramów.