Diagram aktywności

Czym jest diagram aktywności#

Diagram aktywności (activity diagram) przedstawia przepływ działań, decyzji i danych w zachowaniu systemu, procesu lub wybranej operacji. Pomaga odpowiedzieć na pytania: jakie kroki są wykonywane, w jakiej kolejności, jakie warunki wybierają ścieżkę, które działania mogą zachodzić równolegle i co kończy przebieg.

Diagram należy do rodziny diagramów behawioralnych UML. Można nim modelować zachowanie systemowe, biznesowe lub techniczne, ale zakres powinien być określony. Nie jest automatycznie schematem organizacyjnym ani diagramem BPMN. Ma własne elementy i semantykę, zwłaszcza w zakresie tokenów przepływu, współbieżności oraz obiektów przekazywanych między działaniami.

Diagram aktywności może rozwinąć przypadek użycia, opisać algorytm wysokiego poziomu, przebieg procesu biznesowego lub logikę operacji. Nie zastępuje diagramu sekwencji, jeśli głównym pytaniem jest to, które obiekty wymieniają komunikaty w czasie.

Aktywność i działanie#

Aktywność (activity) jest zachowaniem opisywanym jako sieć węzłów i krawędzi. Może obejmować działania, przepływy sterowania i obiektów, węzły decyzyjne, rozwidlenia, synchronizacje i inne elementy.

Działanie (action) jest pojedynczym krokiem na poziomie szczegółowości wybranego diagramu. Zapisuje się je zwykle w zaokrąglonym prostokącie z krótką nazwą czasownikową, np. Sprawdź dostępność. Jedno działanie może odpowiadać wielu instrukcjom programu; nie należy rozbijać go na poziom pojedynczych linii kodu, jeśli celem jest omówienie procesu.

Poziom szczegółowości powinien być spójny. Jeśli jeden węzeł oznacza „Obsłuż zamówienie”, a kolejny „Ustaw zmienną x”, diagram miesza perspektywę biznesową z implementacyjną. Można modelować oba poziomy, ale na oddzielnych, powiązanych widokach.

Przepływ sterowania i przepływ obiektów#

Przepływ sterowania (control flow) określa, które działanie lub węzeł może zostać wykonane po innym. Rysuje się go strzałką. Nie niesie sam przez się informacji o wartości przekazywanych danych.

Przepływ obiektów (object flow) pokazuje przekazanie obiektu lub danych między węzłami. Może łączyć działanie z węzłem obiektowym, pinem wejściowym lub wyjściowym. Typ danych, krotność i stan mogą zostać pokazane, jeśli mają znaczenie. Różne narzędzia mogą upraszczać wizualne rozróżnienie przepływu obiektów i sterowania; jeżeli typ przepływu jest ważny, opisz go jawnie.

W UML przepływy są krawędziami działania i mogą przenosić tokeny. Token sterowania wskazuje możliwość uruchomienia dalszego zachowania, a token obiektu przenosi wartość. Diagram nie musi modelować tokenów wprost, lecz rozumienie ich pomaga poprawnie interpretować współbieżność i synchronizację.

Węzły początkowe i końcowe#

Węzeł początkowy jest oznaczany wypełnionym czarnym kółkiem. Oznacza punkt startu aktywności lub przepływu w danej strukturze. Aktywność może mieć więcej niż jeden węzeł początkowy, jeśli jej zachowanie dopuszcza niezależne uruchamianie kilku ścieżek.

Węzeł końcowy aktywności jest zwykle rysowany jako czarne kółko otoczone pierścieniem. Zakończenie aktywności kończy jej wykonanie. Węzeł końcowy przepływu, oznaczany kółkiem z krzyżykiem, kończy pojedynczy przepływ, ale niekoniecznie całą aktywność. Te dwa zakończenia nie są zamienne.

Narzędzia mogą używać uproszczonych symboli lub słów kluczowych, np. start i stop. Należy sprawdzić, jaki rodzaj węzła końcowego generuje użyta składnia, zwłaszcza gdy inne ścieżki mogą nadal działać.

Decyzje i warunki#

Węzeł decyzyjny (decision node) jest rombem, do którego prowadzi jeden przepływ, a wychodzi kilka alternatywnych ścieżek. Warunek ochronny (guard) na krawędzi, np. [koszyk poprawny], określa, kiedy dana ścieżka jest dostępna. Warunki powinny być czytelne, spójne i — jeśli decyzja wymaga kompletnego rozgałęzienia — obejmować wszystkie dopuszczalne przypadki. Można zastosować warunek domyślny zapisany jako [else] lub zgodnie z konwencją narzędzia.

Węzeł scalający (merge node) łączy alternatywne ścieżki po decyzji. Nie czeka na wszystkie przychodzące przepływy; przepuszcza token, który dotrze jedną z gałęzi. Rozróżnia to go od węzła synchronizacji.

Decyzja dotyczy wyboru jednej z możliwych ścieżek w danym przebiegu. Jeśli warunki są niedookreślone lub nakładają się na siebie, może być niejasne, czy wybierana jest jedna gałąź, czy kilka. W przypadku wyboru wielu gałęzi należy modelować węzeł decyzyjny zgodnie z właściwą semantyką lub użyć konstrukcji odpowiadającej równoległemu uruchomieniu.

Rozwidlenie i synchronizacja#

Węzeł rozwidlenia (fork node) rozdziela przepływ na ścieżki, które mogą przebiegać równolegle. Jest zwykle przedstawiany grubym paskiem. Węzeł synchronizacji (join node) zbiera tokeny z kilku ścieżek i kontynuuje, gdy warunki synchronizacji są spełnione. Również jest rysowany jako gruby pasek.

Rozwidlenie nie oznacza tylko „wykonaj następny krok”. Oznacza, że dalsze gałęzie mogą być aktywne współbieżnie. Synchronizacja może powodować oczekiwanie na tokeny z wymaganych przepływów. W praktyce trzeba określić, czy wszystkie gałęzie są wymagane, czy używana jest semantyka warunkowa, oraz co się dzieje, gdy jedna gałąź nie może dojść do punktu synchronizacji.

W przykładzie poniżej po walidacji koszyka przygotowanie przesyłki i autoryzacja płatności rozpoczynają się równolegle. Po zakończeniu obu gałęzi proces potwierdza zamówienie. Jeśli architektura wymaga najpierw autoryzacji płatności, a dopiero potem wysyłki, równoległy model byłby błędny i należy pokazać sekwencyjny przepływ.

Przykład: obsługa zamówienia#

Diagram przedstawia kontrolę poprawności koszyka, ścieżkę błędu i dwa równoległe działania dla poprawnego zamówienia. Nazwy są wysokopoziomowe; nie opisują systemu płatniczego ani logistyki w szczegółach.

Romb odpowiada decyzji opartej na wyniku walidacji. Gałąź tak przechodzi przez rozwidlenie, uruchamiając dwa działania, a end fork czeka na oba zanim wykona się potwierdzenie. Gałąź nie omija te kroki i prowadzi do komunikatu o błędzie. Obie alternatywy spotykają się po warunku, a aktywność kończy się po wykonaniu wybranej ścieżki.

Ten przykład zakłada, że wysyłka może być przygotowywana równolegle z autoryzacją. Nie definiuje cofania rezerwacji w przypadku odrzucenia płatności ani anulowania przygotowania przesyłki. Takie scenariusze wymagają dodatkowych ścieżek, zdarzeń lub działań kompensacyjnych.

Partycje aktywności i tory#

Partycja aktywności (activity partition), często nazywana swimlane lub torem, grupuje działania według odpowiedzialności, roli, systemu lub innego kryterium. Pomaga odpowiedzieć na pytanie „kto wykonuje ten krok?” albo „w jakim obszarze zachodzi działanie?”.

Partycja nie jest aktorem ani fizyczną granicą systemu. Może być wielowymiarowa lub hierarchiczna w modelu UML, choć narzędzia często pokazują prostsze kolumny albo wiersze. Umieszczaj działanie w partycji według odpowiedzialności za jego wykonanie, a nie według tego, kto ostatecznie korzysta z wyniku.

Zbyt wiele torów utrudnia śledzenie przepływu. Warto stosować je, gdy podział odpowiedzialności pomaga zrozumieć proces; jeśli diagram pokazuje jeden aktor i jeden system, dodatkowe kolumny mogą być zbędne.

Węzły obiektowe, piny i parametry#

Węzeł obiektowy reprezentuje dane lub obiekt przekazywany między działaniami. Może być typowany, mieć stan lub krotność. Piny są punktami wejścia i wyjścia akcji, przez które przepływają obiekty. Wyspecjalizowane piny mogą reprezentować parametry, wartości stałe, wejścia i wyjścia akcji.

Obiekt przepływający między akcjami może zmieniać stan albo reprezentować różne typy informacji. Jeśli rozróżnienie jest ważne, wpisz typ i stan w etykiecie, np. Zamówienie [opłacone]. Nie sugeruj, że sama linia sterowania przenosi określony dokument lub obiekt.

Parametry wejściowe i wyjściowe aktywności mogą być pokazywane na jej granicy jako węzły parametrów. Są przydatne w modelowaniu operacji lub zachowania o formalnie określonych danych wejściowych i wynikach, ale dla prostego diagramu procesu mogą być nadmiarowe.

Zdarzenia, wyjątki i przepływy przerywające#

Aktywność UML może zawierać więcej niż zwykłe akcje i decyzje. Może przyjmować zdarzenia, wysyłać sygnały, reagować na wyjątki, wykorzystywać regiony przerywające oraz wykonywać działania strukturalne, takie jak pętle i sekcje krytyczne. Elementy te są przydatne w szczegółowych modelach zachowania, systemach reaktywnych lub współbieżnych.

Region przerywający (interruptible activity region) grupuje zachowanie, które może zostać przerwane przez przepływ przerywający. Obsługa wyjątku może kierować przepływ do procedury przechwytującej wyjątek. Te konstrukcje mają własną semantykę; zwykła strzałka z etykietą „przerwij” nie musi być jej poprawnym zamiennikiem.

Nie dodawaj zaawansowanych węzłów do schematu tylko po to, aby diagram wyglądał formalniej. Wybieraj je wtedy, gdy zjawisko takie jak zdarzenie, wyjątek czy współbieżność jest istotną częścią zachowania, a odbiorca potrafi odczytać zastosowaną notację.

Jak tworzyć diagram aktywności#

1. Określ zachowanie i jego granice. Wybierz proces, operację, przypadek użycia lub fragment działania.
2. Ustal początek i warunki zakończenia. Zaznacz wyzwalacz, wejścia oraz wynik, jeżeli są istotne.
3. Rozpisz główne działania. Używaj nazw opisujących czynności, na podobnym poziomie szczegółowości.
4. Połącz kroki przepływem. Rozróżniaj sterowanie od przekazywania danych, gdy niesie to różne znaczenie.
5. Dodaj decyzje i warunki. Upewnij się, że warunki są zrozumiałe i obejmują ścieżki wymagane w modelu.
6. Modeluj równoległość świadomie. Użyj rozwidlenia i synchronizacji tylko wtedy, gdy gałęzie mogą współbiec, a punkt oczekiwania jest znany.
7. Dodaj partycje, jeśli wyjaśniają odpowiedzialność. Unikaj torów, które nie wnoszą nowej informacji.
8. Sprawdź zakończenia. Rozróżnij koniec jednej ścieżki od końca całej aktywności.
9. Zweryfikuj warianty i wyjątki. Dodaj istotne odrzucenia, ponowienia, anulowania i błędy.
10. Przejdź po tokenach logicznie. Odczytaj, co uruchamia każdą akcję, skąd bierze dane i co musi zakończyć się przed dalszym przepływem.

Diagram aktywności a inne diagramy#

Niektóre pytania można modelować więcej niż jednym rodzajem diagramu. Wybieraj ten, który najlepiej wyjaśnia konkretny aspekt, i zachowuj spójność nazw pomiędzy widokami.

Typowe błędy#

• Traktowanie diagramu jak listy kroków. Uwzględnij decyzje, równoległość, dane i zakończenia wtedy, gdy mają znaczenie.
• Mieszanie poziomów szczegółowości. Utrzymuj podobny zakres odpowiedzialności w sąsiednich akcjach.
• Brak warunków na wyjściach z decyzji. Odbiorca nie wie wtedy, kiedy wybierana jest każda ścieżka.
• Mylenie merge z join. Merge łączy alternatywy; join synchronizuje równoległe przepływy.
• Mylenie fork z decision. Fork uruchamia współbieżne gałęzie; decision wybiera ścieżkę na podstawie warunków.
• Używanie join bez analizy tokenów. Jeśli jedna gałąź może się nie zakończyć, aktywność może utknąć przy synchronizacji.
• Założenie, że wszystkie przepływy muszą być sekwencyjne. Jeżeli kroki są niezależne, można rozważyć współbieżność; nie pokazuj jej bez uzasadnienia.
• Nadmiar torów. Partycje powinny pokazywać podział odpowiedzialności, a nie dekorować schemat.
• Brak obsługi wariantów. W modelu procesu pominięte błędy lub anulowania mogą tworzyć fałszywe wrażenie kompletności.
• Założenie, że diagram aktywności to BPMN. Podobieństwo przepływu nie oznacza tej samej notacji ani semantyki.

Co diagram aktywności pokazuje, a czego nie#

Diagram aktywności pokazuje przepływ działań i danych, rozgałęzienia, warunki, zakończenia oraz równoległość w modelowanym zachowaniu. Może uwidaczniać odpowiedzialność dzięki partycjom i stanowić czytelne rozwinięcie scenariusza.

Nie opisuje samodzielnie wszystkich komunikatów między obiektami, pełnego stanu obiektu, wymagań niefunkcjonalnych ani szczegółów infrastruktury. Uzupełnij go diagramem sekwencji, stanów, przypadków użycia lub wdrożenia, zależnie od tego, jakie pytanie ma jeszcze odpowiedzieć dokumentacja.