Trzy diagramy, które ratują projekt przed nieporozumieniem
Na spotkaniu otwierającym projekt rejestracji online sponsor MediFlow - przychodni, która chciała umożliwić pacjentom umawianie wizyt przez internet - zadał proste pytanie: „Co ten system właściwie będzie robił i dla kogo?". Kierownik IT zaczął mówić o API i bazie danych, rejestratorka o pacjentach dzwoniących po 18:00, a dyskusja w pięć minut rozjechała się w trzy strony. Nikt nie był w błędzie - wszyscy mówili o tym samym systemie z innej perspektywy. Brakowało wspólnego rysunku.
Dokładnie po to istnieje UML - Unified Modeling Language, standard Object Management Group (aktualna wersja: UML 2.5.1). To nie jeden diagram, tylko zestaw czternastu, a analityk biznesowy w 90% przypadków sięga po trzy: diagram przypadków użycia (use case - kto i po co korzysta z systemu), diagram sekwencji (sequence - kto do kogo mówi i w jakiej kolejności) oraz diagram aktywności (activity - jak proces przebiega krok po kroku). W tym artykule przejdziemy przez całą trójkę na jednym, spójnym case'ie MediFlow - z naciskiem na te detale notacji, na których wykłada się większość początkujących.
UML to nie zestaw symboli do wykucia. To narzędzie odpowiadające na trzy różne pytania - „co?", „kto z kim?" i „jak?" - i siła analityka polega na tym, że wie, którego diagramu użyć do którego pytania.
Diagram przypadków użycia - kto i po co korzysta z systemu
Diagram przypadków użycia (use case diagram) pokazuje funkcje systemu z perspektywy użytkownika: aktorów, którzy z systemem współdziałają, oraz usługi, które system im świadczy. Mówi co użytkownik może zrobić, nie jak. To czyni go najmocniejszym narzędziem na etapie analizy wymagań - jednym rysunkiem ucinasz dyskusję sponsora z wprowadzenia.
Cztery elementy notacji
- Aktor - rola użytkownika lub system zewnętrzny. Rysowany jako „stick man" (ludzik z kresek). Uwaga: aktor to rola, nie konkretna osoba - „Pacjent", nie „pan Kowalski".
- Przypadek użycia - usługa świadczona aktorowi. Elipsa z nazwą „czasownik + dopełnienie", np. „Umów wizytę". Nazwa to cel, który aktor chce osiągnąć.
- Asocjacja - linia ciągła łącząca aktora z przypadkiem użycia, z którego korzysta. Podstawowa relacja na tym diagramie.
- Granica systemu - prostokąt otaczający przypadki użycia, z nazwą systemu na górze. Aktorzy stoją na zewnątrz - i to nie estetyka, lecz sedno: aktor z definicji jest poza systemem.
Aktorów dzielimy na dwie grupy. Pierwszoplanowy (primary) inicjuje przypadek użycia, bo chce osiągnąć swój cel - w MediFlow to Pacjent umawiający wizytę. Drugoplanowy (secondary) nie inicjuje, ale uczestniczy, bo system go potrzebuje - taką rolę pełni System przypomnień SMS. Pierwszoplanowych rysuje się zwyczajowo po lewej, drugoplanowych po prawej.
+--------- System rejestracji wizyt ----------+
Pacjent ------|--- (Umów wizytę) |
Pacjent ------|--- (Odwołaj wizytę) |
Rejestratorka-|--- (Umów wizytę) (Odwołaj wizytę) |
Lekarz -------|--- (Przeglądaj grafik) |
| (Wyślij przypomnienie SMS) ----------|---- System przypomnień
+---------------------------------------------+«include» i «extend» - kierunki strzałek, na których polega 90% błędów
Między samymi przypadkami użycia istnieją dwie relacje. Obie rysuje się przerywaną strzałką ze stereotypem, ale wskazują w przeciwne strony - i to właśnie tu myli się większość początkujących.
«include» - przypadek bazowy zawsze włącza zachowanie innego. Strzałka biegnie od bazowego DO włączanego. W MediFlow zarówno „Umów wizytę", jak i „Odwołaj wizytę" wymagają sprawdzenia tożsamości pacjenta:
(Umów wizytę) - - «include» - -> (Zweryfikuj tożsamość)
(Odwołaj wizytę) - - «include» - -> (Zweryfikuj tożsamość)Czytasz to jako: „Umów wizytę zawsze obejmuje weryfikację tożsamości". «include» służy do wyciągnięcia wspólnego, obowiązkowego fragmentu, żeby nie opisywać go dwa razy.
«extend» - przypadek rozszerzający dodaje opcjonalne zachowanie do bazowego. Strzałka biegnie od rozszerzającego DO bazowego - odwrotnie niż przy «include»:
(Wyślij przypomnienie SMS) - - «extend» - -> (Umów wizytę)Czytasz: „Wyślij przypomnienie SMS rozszerza Umów wizytę". Przypomnienie wychodzi tylko wtedy, gdy pacjent podał numer i wyraził zgodę - umówienie wizyty działa kompletnie również bez niego. Przypadek bazowy nie wie nic o swoich rozszerzeniach; to rozszerzenie „wpina się" w bazowy.
Reguła pamięciowa: strzałka zawsze wychodzi od tego przypadku, który zna drugi. Bazowy zna swoje obowiązkowe «include». Rozszerzający zna bazowy, do którego się dokleja.
Przykład źle → dobrze
Źle: diagram z elipsami „Zaloguj się", „Wypełnij formularz", „Kliknij Zapisz", „Walidacja pól". To nie usługi systemu, tylko kroki ekranowe - klasyczna dekompozycja funkcjonalna. Sponsor patrzy na 40 elips i dalej nie wie, „co system robi dla pacjenta".
Dobrze: elipsa „Umów wizytę", a kroki (wybór lekarza, potwierdzenie regulaminu) żyją w scenariuszu tekstowym pod nią. Test celu: „czy aktor po wykonaniu tego może wstać od komputera z poczuciem załatwionej sprawy?". Umówiona wizyta - tak. Wypełniony formularz - nie, to środek do celu.
Diagram sekwencji - kto do kogo mówi i czy czeka na odpowiedź
Podczas analizy integracji architekt MediFlow zapytał: „Kto wysyła SMS z potwierdzeniem - portal czy system rejestracji? I czy czekamy na bramkę SMS, zanim pokażemy pacjentowi sukces?". Use case mówi, że SMS „się wysyła". Activity - że krok istnieje. Ale kto do kogo, w jakiej kolejności i czy czeka - na to odpowiada dopiero diagram sekwencji.
Diagram sekwencji przedstawia interakcje między uczestnikami w czasie. Czas płynie z góry na dół: co wyżej, dzieje się wcześniej.
Elementy i - najważniejsze - rodzaje komunikatów
Uczestnik to linia życia (lifeline): prostokąt z nazwą na górze i pionowa przerywana linia w dół. Pasek aktywacji to wąski prostokąt na linii życia - pokazuje, kiedy uczestnik jest zajęty przetwarzaniem. A komunikaty? Tu groty niosą semantykę, którą większość pomija:
| Komunikat | Notacja | Znaczenie |
|---|---|---|
| Synchroniczny | linia ciągła, pełny grot ▶ | nadawca czeka na odpowiedź, zanim zrobi cokolwiek dalej |
| Asynchroniczny | linia ciągła, otwarty grot > | nadawca wysyła i działa dalej, nie czekając |
| Odpowiedź (return) | linia przerywana, otwarty grot | zwrot wyniku do nadawcy komunikatu synchronicznego |
Różnica sync/async to nie kosmetyka, tylko decyzja projektowa. W MediFlow zapytanie o wolne terminy musi być synchroniczne - pacjent patrzy w ekran i czeka na listę. Wysyłka SMS powinna być asynchroniczna: jeśli bramka SMS muli pięć sekund, pacjent nie może przez to gapić się w kręciołek, skoro wizyta jest już zarezerwowana. Odpowiedź na pytanie architekta daje jeden rzut oka na groty.
Scenariusz: Pacjent umawia wizytę online
Pacjent Portal SystemRejestracji Grafik BramkaSMS
| | | | |
|--szukajTerminu(lekarz)-------->| | |
| (sync ▶) | |--pobierzWolneSloty()--(sync ▶)->|
| | |<- - sloty - - - - - - - - - - -|
|<- - listaTerminów - - - - - - -| | |
| | | | |
|--rezerwuj(slot)--------(sync ▶)| | |
| | |--zablokujSlot()--(sync ▶)----->|
| | |<- - ok - - - - - - - - - - - - |
| | |--wyślijSMS(potwierdzenie)----->| (async >)
|<- - potwierdzenieRezerwacji - -| | |Pacjent pyta portal o terminy i czeka (pełny grot); portal pyta system rejestracji, ten - grafik; odpowiedzi wracają liniami przerywanymi. Przy rezerwacji system najpierw synchronicznie blokuje slot (musi się udać, zanim powiemy „sukces"), a SMS leci asynchronicznie - otwartym grotem, bez strzałki powrotnej, bo nikt na niego nie czeka.
Fragmenty alt / opt / loop - a nie „punkty kontrolne"
Jeden diagram sekwencji pokazuje jeden przebieg. Warunki i pętle modeluje się fragmentami wyodrębnionymi (combined fragments) - ramkami z etykietą w lewym górnym rogu:
| Operator | Znaczenie | Przykład MediFlow |
|---|---|---|
| alt | alternatywa - wykona się dokładnie jedna sekcja, każda z guardem [...] | [slot wolny] rezerwacja / [slot zajęty] komunikat o konflikcie |
| opt | opcja - fragment wykona się tylko, gdy guard prawdziwy | [pacjent wyraził zgodę SMS] wyślij SMS |
| loop | pętla - fragment powtarza się, dopóki warunek spełniony | [dopóki nie wybrano terminu] pokazuj kolejne strony slotów |
| par | sekcje wykonują się równolegle | e-mail i SMS wysyłane jednocześnie |
Uwaga terminologiczna: starsze materiały (i niestety część kursów) nazywają te konstrukcje „punktami kontrolnymi". Taki termin nie istnieje w UML 2.5 - poprawna nazwa to fragmenty wyodrębnione z operatorami alt, opt, loop, par. Używaj nazewnictwa ze specyfikacji: zrozumie cię każde narzędzie i znajdziesz temat w dokumentacji.
Diagram aktywności - jak proces przebiega krok po kroku
Po zatwierdzeniu zakresu w MediFlow przyszło pytanie „jak dokładnie przebiega umówienie wizyty?". Rejestratorka opisała proces w osiem zdań, kierownik w dwanaście - i te opisy się nie zgadzały. Kto potwierdza wizytę, gdy pacjent nie ma konta? Słowny opis procesu zawsze ma dziury, których nie widać, dopóki ktoś nie spróbuje go narysować. Od tego jest diagram aktywności.
Węzły kontrolne: decyzja, fork, guard
| Węzeł | Symbol | Znaczenie |
|---|---|---|
| Początkowy | wypełnione kółko ● | tu proces startuje (dokładnie jeden) |
| Końcowy | kółko z obwódką ◉ | tu proces się kończy |
| Decyzyjny | romb ◇ z wieloma wyjściami | wybór jednej ścieżki na podstawie warunku |
| Scalający (merge) | romb ◇ z wieloma wejściami | alternatywne ścieżki schodzą się z powrotem |
| Rozwidlenie / złączenie (fork/join) | gruba pozioma kreska | start / synchronizacja ścieżek równoległych |
Wyjścia z węzła decyzyjnego opisuje się warunkami w nawiasach kwadratowych - guardami: [termin wolny], [termin zajęty]. Warunki muszą się wykluczać i pokrywać wszystkie przypadki, inaczej proces ma dziurę.
Różnica decyzja vs fork jest fundamentalna: po decyzji proces idzie jedną z dróg, po forku - wszystkimi naraz. Gdy system MediFlow po rezerwacji jednocześnie wysyła e-mail z potwierdzeniem i aktualizuje grafik lekarza, to fork; join czeka, aż obie ścieżki się skończą, zanim proces ruszy dalej.
Partycje - kto wykonuje który krok
Proces biznesowy prawie nigdy nie należy do jednej osoby. Partycje (swimlanes, tory pływackie) dzielą diagram na pasy, po jednym na rolę lub system; każda akcja leży w pasie tego, kto ją wykonuje:
| Pacjent | System | Rejestratorka |
|--------------------|----------------------|------------------------|
| ● Wybierz termin → | ◇ [wolny] Zarezerwuj | |
| | [zajęty] Zaproponuj| |
| | inne terminy | |
| Potwierdź wybór → | Wyślij potwierdzenie | |
| | ◇ [brak konta] ────→ | Zweryfikuj telefonicznie|
| | Zapisz wizytę ◉ | |Bez partycji diagram mówi „co po czym". Z partycjami mówi też „kto co robi" - i natychmiast obnaża nieustalone odpowiedzialności. W MediFlow dopiero rysunek z partycjami ujawnił, że nikt nie zdecydował, kto weryfikuje pacjentów bez konta: system czy rejestratorka. Osiem zdań rejestratorki i dwanaście kierownika omijało to pytanie szerokim łukiem.
Który diagram do którego pytania?
| Pytanie | Diagram | Co pokazuje |
|---|---|---|
| Kto i po co korzysta z systemu? | Przypadków użycia | Zakres, aktorzy, usługi systemu |
| Jak przebiega proces krok po kroku? | Aktywności | Kroki, decyzje, role, równoległość |
| Kto do kogo mówi i czy czeka? | Sekwencji | Komunikaty, kolejność, sync/async, integracje |
Praktyka zespołów: use case na ustalanie zakresu, aktywności na warsztaty z biznesem, sekwencje na projektowanie techniczne. To nie konkurencja, lecz trzy zbliżenia tej samej kamery. Jeśli wahasz się między diagramem aktywności a BPMN do opisu procesu - sięgnij po BPMN dla początkujących; mechanika (decyzje, guardy, równoległość, partycje) przenosi się niemal jeden do jednego.
Najczęstsze błędy w diagramach UML
- Odwrotny kierunek «include»/«extend». Najczęstszy błąd na use case. «include» biegnie od bazowego do włączanego, «extend» - od rozszerzającego do bazowego. Strzałka w złą stronę zmienia znaczenie diagramu.
- Aktor wewnątrz granicy systemu. Aktor z definicji jest bytem zewnętrznym. Aktor w prostokącie to sygnał, że ktoś pomylił rolę użytkownika z funkcją systemu.
- Dekompozycja funkcjonalna zamiast celów aktora. Elipsy „Kliknij Zapisz", „Walidacja pól" - to kroki ekranowe, nie usługi. Stosuj test celu.
- Synchroniczny SMS na diagramie sekwencji. Komunikat do bramki SMS z pełnym grotem i odpowiedzią zmusza cały łańcuch wywołań do czekania na zewnętrzny system. Otwarty grot, bez return.
- Mylenie decyzji z forkiem na aktywności. Romb wybiera jedną drogę, gruba kreska uruchamia wszystkie. To zmienia logikę procesu.
- Guardy odpowiadające na różne pytania. Wyjścia z jednej decyzji -
[termin wolny]i[pacjent ma konto]- mogą być prawdziwe naraz. To powinny być dwie osobne decyzje. - „Mega-diagram" wszystkich możliwości. Jeden diagram sekwencji = jeden scenariusz. Przebieg główny osobno, „slot zajęty" osobno, awaria płatności osobno. Fragmenty alt/opt zostaw na drobne rozgałęzienia.
- Termin „punkty kontrolne". W UML 2.5 nie istnieje. Mówisz: fragmenty wyodrębnione, operatory alt/opt/loop/par.
Narzędzia do modelowania UML
- draw.io (diagrams.net) - darmowe, online i desktop, z biblioteką kształtów UML. Świetne do nauki i szybkiego prototypowania.
- Visual Paradigm - pełne wsparcie wszystkich diagramów UML, darmowa edycja Community do użytku niekomercyjnego.
- Enterprise Architect - rozbudowane narzędzie komercyjne dla dużych projektów i pełnej dokumentacji systemu.
- PlantUML - diagramy z kodu tekstowego; idealne, gdy chcesz wersjonować diagramy w Gicie obok kodu.
- Lucidchart - chmurowe, dobra współpraca zespołowa, integracje z Jira i Confluence.
Mini-przykład end-to-end: rezerwacja w MediFlow trzema diagramami
Złóżmy całość. Ten sam fragment systemu MediFlow opisany trzema diagramami, każdy odpowiada na inne pytanie:
- Use case - w granicy „System rejestracji wizyt" elipsa „Umów wizytę" połączona asocjacją z aktorem Pacjent (po lewej). Z „Umów wizytę" biegnie «include» do „Zweryfikuj tożsamość", a „Wyślij przypomnienie SMS" łączy się «extend» do „Umów wizytę". System przypomnień SMS stoi po prawej jako aktor drugoplanowy. Odpowiedź: kto i po co.
- Activity - trzy partycje (Pacjent, System, Rejestratorka). Po „Wybierz termin" romb decyzyjny
[termin wolny]/[termin zajęty]z powrotem do wyboru. Po rezerwacji fork: równolegle „Wyślij e-mail" i „Aktualizuj grafik", potem join. Romb[brak konta]przerzuca pracę do rejestratorki. Odpowiedź: jak, krok po kroku. - Sequence - linie życia Pacjent, Portal, SystemRejestracji, Grafik, BramkaSMS. Zapytanie i rezerwacja synchronicznie (pełne groty, odpowiedzi przerywane), SMS asynchronicznie (otwarty grot). Fragment
altz[slot wolny]/[slot zajęty]. Odpowiedź: kto z kim i czy czeka.
Żaden z tych diagramów sam nie wystarczy - ale razem dają pełny obraz, którego nie da 40 stron prozy. To jest istota modelowania w pracy analityka.
FAQ - diagramy UML w praktyce
Czym różni się diagram aktywności UML od BPMN?
Oba opisują przepływ procesu i mechanika jest niemal identyczna (decyzje, guardy, fork/join, partycje). Diagram aktywności wybieraj, gdy proces żyje obok innych diagramów UML w dokumentacji systemu i zespół zna UML. BPMN - gdy modelujesz dla odbiorców czysto biznesowych albo organizacja ma już repozytorium procesów w tej notacji. BPMN ma też bogatszą semantykę zdarzeń (timery, eskalacje).
Ile diagramów UML naprawdę musi znać analityk biznesowy?
UML ma czternaście typów, ale na co dzień AB sięga po trzy-cztery: przypadków użycia, aktywności, sekwencji, czasem klas (do modelu pojęciowego). Resztę (komponentów, wdrożenia, maszyny stanowej) poznaje się w miarę potrzeby konkretnego projektu.
Kiedy «include», a kiedy «extend»?
«include», gdy fragment jest obowiązkowy i wspólny dla kilku przypadków (weryfikacja tożsamości przy umawianiu i odwoływaniu) - strzałka od bazowego do włączanego. «extend», gdy zachowanie jest opcjonalne i bazowy działa bez niego (przypomnienie SMS) - strzałka od rozszerzającego do bazowego.
Czy muszę rysować paski aktywacji na diagramie sekwencji?
Na poziomie analizy często można je pominąć dla czytelności (jak w przykładach ASCII powyżej). Stają się wartościowe na poziomie projektowania, gdy chcesz pokazać, jak długo dany komponent jest „zajęty" i gdzie nakładają się wywołania.
Diagram sekwencji ma 30 strzałek i nikt go nie czyta - co robić?
To klasyczny objaw „mega-diagramu". Zasada: jeden diagram = jeden scenariusz. Potnij na przebieg główny, „slot zajęty", awarię płatności jako osobne rysunki. Fragmenty alt/opt rezerwuj na drobne, lokalne rozgałęzienia (dwie-trzy strzałki), nie na całe alternatywne historie.
Podsumowanie i następny krok
Trzy diagramy, trzy pytania. Use case mówi co i dla kogo, aktywności - jak krok po kroku, sekwencji - kto z kim i czy czeka. Poprawna notacja to nie pedanteria: odwrócony «include», synchroniczny SMS czy guardy o dwóch różnych pytaniach realnie zmieniają to, co diagram komunikuje zespołowi. A zespół będzie budował to, co zobaczył na rysunku.
Najlepszy sposób na opanowanie UML to narysowanie własnego diagramu. Otwórz edytor diagramów na platformie i odtwórz przypadek MediFlow - albo zacznij od procesu, który znasz na pamięć. Jeśli chcesz najpierw uporządkować pojęcia, zajrzyj do hasła use case w słowniku, a po solidne wymagania pod diagramy - do artykułu jak pisać User Stories.
Diagram UML to środek, nie cel. Celem jest wspólne zrozumienie systemu, zanim ktokolwiek napisze pierwszą linijkę kodu. Im więcej diagramów narysujesz i zweryfikujesz z ludźmi, którzy z systemu będą korzystać, tym naturalniej zaczniesz „myśleć modelami" - a to umiejętność, która wyróżnia dobrego analityka.