Tablica, marker, sześć osób w sali i pytanie właścicielki procesu: „a co się dzieje, kiedy klient odeśle uszkodzony towar?". Cisza. Na tablicy była już narysowana cała obsługa zwrotu: dwanaście prostokątów, strzałki, dwa romby. Tylko że przy żadnym rombie nie było napisane, co decyduje o skręcie w lewo albo w prawo. Diagram wyglądał na gotowy i nie odpowiadał na pierwsze poważne pytanie.
To jest typowa scena z warsztatu i typowy powód, dla którego uczę diagramu aktywności inaczej, niż robi to większość podręczników. Nie od listy symboli, tylko od tego, po co ten diagram w ogóle rysujesz i jakie pytania biznesu ma wytrzymać.
Po co analitykowi diagram aktywności
Diagram aktywności pokazuje przepływ pracy: co się dzieje po czym, kto to robi, gdzie proces się rozgałęzia i gdzie kilka rzeczy idzie równolegle. To jeden z diagramów behawioralnych UML, blisko spokrewniony ze schematem blokowym, ale z dwiema rzeczami, których schemat blokowy nie ma: torami odpowiedzialności i porządną równoległością.
Sięgam po niego w trzech sytuacjach. Kiedy przypadek użycia ma tyle scenariuszy alternatywnych, że tekst przestaje się czytać. Kiedy w jednym przepływie pracuje kilka ról i trzeba pokazać, gdzie piłka przechodzi z ręki do ręki. I kiedy zespół deweloperski pyta „a w jakiej kolejności to się dzieje?", a odpowiedź ma więcej niż jedno „to zależy".
Rynek też o niego pyta, choć rzadziej niż o BPMN. Na job boardzie Analify UML pojawia się w wymaganiach 35 z 292 aktywnych ogłoszeń dla analityków biznesowych (odczyt: wrzesień 2026). Nie jest to warunek wejścia do zawodu, ale w projektach, gdzie architekci i deweloperzy myślą UML-em, analityk bez tego diagramu rozmawia z nimi przez tłumacza.
Kiedy NIE rysować
Tu jestem uparty, bo widziałem za dużo diagramów aktywności narysowanych z rozpędu.
Jeśli modelujesz proces biznesowy end-to-end, z wieloma uczestnikami, zdarzeniami i komunikatami między organizacjami, weź BPMN. Ma bogatszą semantykę zdarzeń, bramki, które biznes zna, i jest językiem, w którym rozmawia się o procesach poza działem IT. Diagram aktywności dobrze znosi przepływ wewnątrz jednego przypadku użycia albo jednej operacji. Na mapę procesów całej firmy jest za wąski.
Jeśli sedno problemu to logika decyzyjna, czyli kombinacja pięciu warunków dająca dwanaście wyników, nie rysuj tego jako kaskady rombów. Wyjdzie choinka, której nikt nie zweryfikuje. Tabela decyzyjna zrobi to na jednej kartce i da się ją przeczytać wiersz po wierszu. Diagram niech pokaże, że decyzja jest, a tabela niech powie, jak wypada.
I trzecia sytuacja: jeśli chcesz pokazać, jak obiekty albo komponenty wymieniają komunikaty w czasie, to nie jest robota dla diagramu aktywności. Pokazuję to na diagramie sekwencji, bo tam chodzi o kolejność wywołań, a nie o przepływ pracy. Oba diagramy dobrze się uzupełniają, a szerszy kontekst, gdzie który leży na mapie UML, opisałem we wpisie o diagramach UML w praktyce.
Notacja, ale tłumaczona przez użycie
Symbole poznasz w pięć minut. Trudność jest w tym, żeby wiedzieć, kiedy którego użyć. Dlatego każdy element opisuję przez pytanie, na które odpowiada.
Węzeł początkowy i końcowy. Czarna kropka na starcie, kropka w kółku na końcu. Odpowiadają na pytanie: co uruchamia ten przepływ i kiedy uznajemy go za zamknięty. Jeśli nie umiesz nazwać wyzwalacza, nie zaczynaj rysować. Diagram bez jasnego początku to zwykle diagram bez jasnego zakresu. Węzłów końcowych może być kilka, bo przepływ może się skończyć sukcesem albo odrzuceniem, i dobrze, żeby obie drogi były widoczne.
Akcja. Prostokąt z zaokrąglonymi rogami. Odpowiada na pytanie: co ktoś robi. Nazywaj czasownikiem i dopełnieniem: „zarejestruj zgłoszenie", „sprawdź stan towaru". Jeśli nazwa akcji brzmi jak nazwa ekranu albo dokumentu, to sygnał, że rysujesz nawigację po systemie, nie pracę.
Decyzja i scalenie. Ten sam romb, dwie różne role. Decyzja rozdziela przepływ według warunku: z rombu wychodzi kilka strzałek, każda z warunkiem w nawiasie kwadratowym, na przykład [w terminie] i [po terminie]. Scalenie łączy gałęzie z powrotem w jedną drogę i nie ma warunków, bo niczego nie sprawdza. Warunki na gałęziach muszą się wykluczać i razem wyczerpywać wszystkie przypadki. Gałąź [else] jest legalna i często ratuje życie.
Rozwidlenie i złączenie. Gruba pozioma kreska. Rozwidlenie mówi: od tego miejsca te rzeczy dzieją się równolegle i nie czekają na siebie. Złączenie mówi: dalej pójdziemy dopiero, gdy wszystkie równoległe gałęzie dobiegną końca. To jedyna różnica między „magazyn przyjmuje towar, a w tym czasie księgowość zwraca pieniądze" a „najpierw magazyn, potem księgowość". Dla biznesu ta różnica to dni oczekiwania klienta.
Partycje, czyli tory. Pionowe albo poziome pasy podpisane nazwą roli lub systemu. Odpowiadają na pytanie: kto za to odpowiada. Każda akcja leży w dokładnie jednym torze. Jeśli nie wiesz, w którym, to znaczy, że nie wiesz, kto to robi, i to jest ustalenie do zrobienia z biznesem, nie problem notacji.
Przepływ obiektów. Prostokąt z nazwą obiektu i jego stanem w nawiasie kwadratowym: Zgłoszenie zwrotu [zarejestrowane], Paczka [odebrana]. Pokazuje, co przechodzi między akcjami i w jakim stanie. Używam go oszczędnie, tylko tam, gdzie stan obiektu naprawdę decyduje o dalszej drodze.
Zdarzenia. Dwa kształty pięciokątne: wklęsły to odbiór sygnału (przepływ czeka, aż coś przyjdzie z zewnątrz), wypukły to wysłanie sygnału. Klepsydra to zdarzenie czasowe. Odpowiadają na pytanie: na co czekamy i co się stanie, jeśli się nie doczekamy. Na warsztatach to właśnie klepsydra najczęściej wywołuje rozmowę, której wcześniej nikt nie odbył.
Krótszą, słownikową wersję tego wszystkiego trzymam w haśle „diagram aktywności" w słowniku Analify, gdyby ktoś w zespole potrzebował ściągi.
Krok po kroku: obsługa zwrotu w sklepie internetowym
Przykład jest ilustracyjny i celowo typowy. Klient kupił coś w sklepie internetowym, chce to odesłać i dostać pieniądze. Przejdźmy tę samą drogę, którą prowadzę ludzi na warsztacie.
Krok 1. Ustal zakres i nazwij aktywność
Jedna aktywność, jeden cel, jeden wyzwalacz. Nazwa: „Obsłuż zwrot towaru". Wyzwalacz: klient zgłasza zwrot w koncie klienta. Koniec: pieniądze wróciły do klienta i towar jest na stanie, albo zwrot został odrzucony i klient wie dlaczego. Zapisz to zdaniem nad diagramem. Będzie pilnować, żebyś nie wciągnął do środka reklamacji gwarancyjnej, która jest innym przepływem.
Krok 2. Wypisz role i narysuj tory
Kto dotyka tego zwrotu? Klient. Obsługa klienta. Magazyn. Dział płatności. Do tego system sklepu, który część rzeczy robi sam. Pięć torów. Jeśli któryś tor przez cały diagram miałby jedną akcję, zastanów się, czy nie zlać go z innym, ale na razie zostaw.
Krok 3. Poprowadź ścieżkę szczęśliwą
Od kropki do kropki, bez ani jednej decyzji. Klient zgłasza zwrot. System rejestruje zgłoszenie. Klient wysyła paczkę. Magazyn odbiera paczkę i ocenia stan towaru. Płatności zwracają pieniądze. System wysyła potwierdzenie. Koniec. Trzymaj jeden poziom szczegółu: „oceń stan towaru" to jedna akcja, nie sześć kroków rozpakowywania kartonu.
Krok 4. Dołóż decyzje z warunkami
Teraz pytasz przy każdej akcji: co może pójść inaczej? Po rejestracji zgłoszenia system sprawdza termin: [w terminie] idziemy dalej, [po terminie] obsługa klienta odrzuca zwrot z uzasadnieniem i przepływ kończy się w osobnym węźle końcowym. Po ocenie stanu towaru: [towar bez śladów użycia] pełny zwrot, [towar uszkodzony] obsługa klienta kontaktuje się z klientem i proponuje zwrot częściowy. Każda gałąź ma warunek. Każda decyzja, która się rozchodzi i wraca, ma scalenie.
Krok 5. Znajdź równoległość
Po pozytywnej ocenie towaru dwie rzeczy nie muszą na siebie czekać: magazyn przyjmuje towar na stan, a płatności zwracają pieniądze. Rozwidlenie przed nimi, złączenie za nimi, dopiero potem system wysyła potwierdzenie. Jeśli biznes powie, że pieniądze wracają dopiero po przyjęciu na stan, to nie jest równoległość i rysujesz to sekwencyjnie. Diagram ma odzwierciedlać regułę, nie Twoje wyobrażenie o wydajnym procesie.
Krok 6. Dopisz obiekty i zdarzenia
Między „wyślij paczkę" a „odbierz paczkę" wstaw obiekt Paczka [w drodze]. Przy oczekiwaniu magazynu na paczkę dodaj klepsydrę: jeśli paczka nie dotrze w ustalonej liczbie dni, system zamyka zgłoszenie i informuje klienta. To zdarzenie czasowe zwykle nie istnieje w głowie nikogo poza magazynem, a bez niego zgłoszenia wiszą otwarte miesiącami.
Krok 7. Przejdź diagram na głos
Zacznij od kropki i opowiedz historię palcem po strzałkach. Za każdym razem, gdy przy rombie musisz powiedzieć „no i wtedy zależy", a warunku nie ma, dopisz go. Gdy przy akcji nie umiesz powiedzieć, kto ją wykonuje, przenieś ją do właściwego toru albo zapisz pytanie do biznesu. Diagram jest gotowy, gdy potrafisz go opowiedzieć bez zająknięcia.
Typowe błędy, które widzę na warsztatach
Diagram jako schemat ekranów. Akcje nazywają się „Ekran logowania", „Formularz zwrotu", „Strona potwierdzenia". To nie jest przepływ pracy, to mapa nawigacji. Poznasz to po tym, że nie da się umieścić akcji w torze roli, bo ekran nie ma odpowiedzialnego. Wracaj do czasowników.
Brak warunków na gałęziach decyzji. Romb, dwie strzałki, żadnego napisu. Autor wie, co miał na myśli. Nikt inny nie wie, a za pół roku autor też nie. Warunek jest częścią diagramu, nie ozdobnikiem.
Mieszanie poziomów szczegółu. Z jednej strony „obsłuż płatność", z drugiej „kliknij przycisk Zapisz". Diagram staje się nieczytelny, bo czytelnik co chwilę zmienia wysokość lotu. Ustal poziom w kroku 1 i trzymaj go; szczegóły rozbij na osobny diagram, jeśli są komuś potrzebne.
Tory bez odpowiedzialności. Tor o nazwie „System", w którym ląduje wszystko, czego nie umiano przypisać. Albo tor „Proces", który niczego nie znaczy. Tor to ktoś, kto może odpowiedzieć na pytanie „czemu to nie zostało zrobione". Jeśli takiej osoby albo komponentu nie ma, tor jest fikcją.
Rozwidlenie bez złączenia. Gałęzie równoległe rozchodzą się i każda kończy własną kropką. Czasem to poprawne. Częściej autor zapomniał, że potwierdzenie do klienta ma wyjść dopiero, gdy obie gałęzie się domkną, i właśnie zaprojektował mail „zwrot zakończony" wysyłany przed przelewem.
Jak wpiąć diagram w wymagania
Diagram aktywności, który leży samotnie w folderze, jest ładnym obrazkiem. Wartość pojawia się, gdy przywiążesz go do reszty dokumentacji.
Najbliższy sąsiad to przypadek użycia. Ścieżka szczęśliwa z kroku 3 to jego przebieg podstawowy. Każda gałąź decyzji z kroku 4 to przebieg alternatywny albo wyjątek. Jeśli pisałeś use case tekstowo według schematu, który rozkładam we wpisie o pisaniu przypadków użycia, diagram aktywności jest jego wizualnym bliźniakiem i powinien się z nim zgadzać co do kroku. Rozjazd między nimi to błąd do naprawienia, a nie dwie „perspektywy".
Drugi sąsiad to kryteria akceptacji. Każdy romb na diagramie to co najmniej dwa kryteria: jedno na każdą gałąź. „Zgłoszenie po terminie zostaje odrzucone z podaniem daty granicznej" i „zgłoszenie w terminie przechodzi do wysyłki" wychodzą prosto z jednej decyzji. Klepsydra daje kolejne: „zgłoszenie bez paczki po ustalonej liczbie dni zostaje zamknięte, a klient dostaje informację". Jeśli masz kłopot z formułowaniem takich zdań, mam osobny wpis o tym, jak pisać kryteria akceptacji. Diagram w tym pomaga, bo nie da się przeoczyć gałęzi, którą widać.
Trzeci sąsiad to testy. Każda kompletna ścieżka od węzła początkowego do końcowego to kandydat na przypadek testowy. Policz je na swoim diagramie zwrotu: ścieżka w terminie z towarem nieuszkodzonym, po terminie, z towarem uszkodzonym, z paczką, która nie dotarła. Cztery ścieżki, cztery testy minimum. Tester dostaje od Ciebie mapę zamiast zgadywania, a Ty wiesz, że każda gałąź ma pokrycie.
Jak czytać diagram z biznesem
Nie tłumacz notacji. Nikt z biznesu nie musi wiedzieć, że romb to węzeł decyzyjny, a gruba kreska to rozwidlenie. Zamiast tego opowiadasz historię: „klient zgłasza zwrot, system sprawdza termin, i tu mam pytanie, bo nie wiem, co robimy, gdy klient zgłosi zwrot dzień po terminie".
Prowadź ludzi ścieżką szczęśliwą do końca, dopiero potem wracaj do rozgałęzień. Przy każdym rombie pytaj o gałąź, której nie ma: „a co, jeśli towar wróci bez paragonu?". Przy każdej klepsydrze pytaj o liczbę dni i o to, kto ją ustalił. Przy każdym torze pytaj właściciela tej roli, czy zgadza się z tym, co mu przypisałeś. To ostatnie potrafi wywołać najciekawszą rozmowę w całym warsztacie, bo okazuje się, że magazyn od dwóch lat robi coś, co formalnie należy do obsługi klienta.
Decyzje, które padają podczas takiej sesji, zapisuj od razu obok diagramu, z datą i osobą. Za miesiąc ktoś zapyta, dlaczego zwrot po terminie jest odrzucany automatycznie, a Ty będziesz mieć odpowiedź w jednym miejscu, zamiast szukać jej w mailach.
I ostatnia rzecz, o której przypominam każdej grupie: diagram, który biznes zrozumiał i poprawił, jest lepszy od diagramu, który jest w stu procentach zgodny ze specyfikacją UML, a leży nietknięty w repozytorium. Notacja ma służyć rozmowie. Jeśli w Twoim zespole prostokąty i romby wystarczą, a klepsydry mylą, zostaw klepsydry na później i dopisz zdarzenie czasowe słowami na marginesie.
Jeśli chcesz sprawdzić, ile z tego zostało Ci w głowie, rozwiąż krótki quiz z diagramu aktywności UML. Jest publiczny, bez zakładania konta, a wynik dostajesz od razu z wyjaśnieniami do każdego pytania.