Jak opisać przebieg procesu?

Zacznij od granic i wyniku procesu#

Diagram aktywności UML opisuje przebieg zachowania jako przepływ działań, decyzji, danych i ewentualnych ścieżek współbieżnych. Żeby przygotować użyteczny model, najpierw ustal, jaki proces przedstawiasz, co go uruchamia, gdzie się kończy i jaki rezultat ma osiągnąć.

Proces może być biznesowy, systemowy albo ograniczony do działania jednego komponentu. Nie mieszaj poziomów bez powodu: przebieg pracy całej organizacji i algorytm wewnątrz operacji wymagają innego stopnia szczegółowości. Zapisz nazwę, właściciela lub kontekst procesu oraz to, co pozostaje poza zakresem.

Zbierz przebieg i warianty#

Rozpisz scenariusz słowami, zanim narysujesz węzły. Dla każdej czynności ustal, kto ją wykonuje, jakie warunki muszą być spełnione, jakie dane wchodzą i jakie wyniki powstają. Zapytaj również o wyjątki, anulowanie, powtórzenia, czas oczekiwania i równoległe prace.

Rozdziel zdarzenia i kroki, które zmieniają przebieg, od opisu ekranu czy technicznej implementacji. Zweryfikuj dostępność produktu jest akcją; produkt jest dostępny jest warunkiem wyboru ścieżki. Wyświetl komunikat może być istotnym działaniem systemu lub jedynie szczegółem interfejsu — zależnie od celu diagramu.

Akcje i przepływy#

Akcja (action) jest jednostką wykonywanej pracy przedstawianą zwykle zaokrąglonym prostokątem. Nazwij ją krótkim czasownikiem i dopełnieniem, np. Sprawdź dostępność. Zbyt ogólny węzeł, taki jak Obsłuż zamówienie, ukrywa strukturę; zbyt drobny rozbija proces na kliknięcia bez wartości.

Przepływ sterowania (control flow) określa, co może wykonać się po czym. Nie musi przenosić danych. Przepływ obiektów (object flow) pokazuje przenoszenie informacji lub obiektów między węzłami. Używaj go, gdy typ lub treść danych jest ważna dla zrozumienia procesu; nie zmieniaj każdej strzałki sterowania w przepływ obiektów.

Początek oznacza węzeł początkowy, koniec aktywności — węzeł końcowy aktywności. W UML istnieje również węzeł końcowy przepływu, który kończy pojedynczy token, a nie całą aktywność. Narzędzia mogą używać różnych ikon lub nazw; sprawdź semantykę, zanim uznasz symbole za równoważne.

Decyzje, scalanie i warunki#

Węzeł decyzji rozdziela przepływ na ścieżki zależne od warunków ochronnych (guard). Zapisz warunek przy każdej wychodzącej krawędzi, np. [dostępny] i [brak]. Jeśli ścieżki mają być wyczerpujące, uwzględnij wszystkie możliwe wyniki albo warunek [else]. Jeśli kilka warunków może być prawdziwych jednocześnie, rozstrzygnij, czy dopuszczasz wybór niedeterministyczny, czy warunki muszą być rozłączne.

Węzeł scalania łączy alternatywne ścieżki, ale nie czeka na wszystkie wejścia. Wybierz węzeł scalania, gdy jedna z alternatyw dociera do wspólnego dalszego kroku. Nie pomyl go z synchronizacją, która oczekuje na zakończenie wielu przepływów.

Współbieżność: fork i join#

Węzeł rozwidlenia (fork) rozpoczyna równoległe przepływy, a węzeł synchronizacji (join) synchronizuje ich zakończenie. Jeżeli proces wymaga, by po utworzeniu zamówienia równolegle zarezerwować towar i wysłać zlecenie do magazynu, pokaż oba przepływy oddzielnie. Dalszy krok po join następuje po spełnieniu warunków synchronizacji.

Nie używaj fork/join jako dekoracyjnego rozgałęzienia. Gdy przebiega dokładnie jedna ścieżka zależna od decyzji, zastosuj decision/merge. Jeśli do synchronizacji dopuszczasz tylko część napływających przepływów, sprawdź semantykę specyfikacji węzła join i jego warunek, zamiast zakładać, że każdy join zawsze czeka na bezwarunkowo wszystkie wejścia.

Przepływ danych i węzły obiektów#

Węzeł obiektowy może przedstawiać dane lub obiekt przekazywany między działaniami. Piny wejściowe i wyjściowe akcji pomagają opisać wymagane wejście i wytwarzany wynik. Możesz też użyć buforów, magazynów danych, parametrów aktywności i sygnałów, gdy są niezbędne dla modelu.

Nie opisuj każdego parametru i rekordu. Pokaż dane wtedy, gdy zmieniają interpretację procesu, ograniczają możliwość wykonania akcji albo pozwalają śledzić istotny rezultat. Nazwy i typy powinny być spójne z modelem klas lub słownikiem domeny.

Odpowiedzialność i partycje#

Partycje aktywności (activity partitions), tradycyjnie nazywane torami (swimlanes), grupują działania według odpowiedzialności, roli, jednostki organizacyjnej lub komponentu. Pomagają zobaczyć przekazania pracy i miejsca, w których proces przekracza granice zespołów lub systemów.

Partycja nie musi oznaczać konkretnego pracownika ani procesu technicznego. Wybierz kryterium i stosuj je konsekwentnie. Jeśli każda akcja przechodzi przez wiele odpowiedzialności, rozważ inny widok lub nazwij podział zgodnie z tym, co naprawdę koduje.

Przykład: obsługa zamówienia#

Diagram przedstawia podstawową ścieżkę i dwa warunki. Nie mówi, jak długo trwa rezerwacja, jak system rozstrzyga równoczesny zakup ostatniej sztuki ani czy płatność może nadejść po zwolnieniu rezerwacji. Te reguły trzeba dodać, jeśli należą do zakresu procesu. Osobny diagram czasowy, stanów lub sekwencji może wyjaśnić zachowanie, którego nie warto upychać w tej aktywności.

Procedura tworzenia diagramu#

1. Ustal cel, odbiorców, granicę procesu, początek i rezultat.
2. Zapisz scenariusz główny prostymi krokami.
3. Dodaj decyzje, warunki i istotne przebiegi błędne.
4. Oznacz dane wejściowe i wyniki, jeżeli wyjaśniają przepływ.
5. Sprawdź, czy istnieje rzeczywista współbieżność; jeśli tak, użyj fork/join.
6. Pokaż odpowiedzialność partycjami, gdy interesują Cię role lub przekazania.
7. Uporządkuj diagram tak, by można było przejść ścieżki od początku do końca.
8. Zweryfikuj reguły na przykładach i popraw niekompletne warunki.
9. Uprość elementy, które nie wpływają na interpretację.

Diagram aktywności a inne widoki#

Diagram aktywności skupia się na przepływie działań. Diagram sekwencji pokazuje, jak konkretni uczestnicy wymieniają komunikaty w wybranym scenariuszu. Diagram przypadków użycia przedstawia aktorów oraz cele systemu na wysokim poziomie. Diagram maszyny stanów pokazuje cykl życia jednego obiektu lub klasyfikatora.

Jeśli pytasz „co następuje potem?” albo „jak rozgałęzia się proces?”, aktywność jest dobrym kandydatem. Jeśli ważne jest „kto wysyła wiadomość komu?”, wybierz sekwencję. Jeśli kluczowe jest „w jakich stanach może być zamówienie?”, użyj maszyny stanów.

Typowe błędy#

• Diagram bez celu i granicy. Nie wiadomo, jaki proces ani jaki poziom szczegółowości przedstawiono.
• Pomijanie ścieżek błędnych. Model może sugerować sukces zawsze, nawet jeśli reguły dopuszczają odmowę.
• Warunki niewyczerpujące. Niektóry wynik decyzji nie ma dalszego przepływu.
• Decision użyty zamiast fork. Alternatywy to nie współbieżność.
• Merge użyty zamiast join. Połączenie alternatyw nie czeka na kilka aktywnych gałęzi.
• Nieopisane krawędzie. Brak warunku utrudnia odczytanie decyzji.
• Każde kliknięcie jako akcja. Przeładowanie szczegółami interfejsu zaciemnia proces.
• Strzałki danych mylone ze sterowaniem. Wyjaśnij, czy przepływa token sterujący, czy obiekt.
• Partycje bez jasnego kryterium. Podział nie pokazuje wtedy rzeczywistej odpowiedzialności.
• Proces biznesowy zmieszany z algorytmem. Rozdziel poziomy lub przygotuj osobne diagramy.
• Brak sprawdzenia pętli i zakończeń. Upewnij się, że przebieg może się zakończyć lub warunek powtórzenia jest jawny.

Lista kontrolna#

• Czy wiadomo, gdzie proces się zaczyna i jaki rezultat go kończy?
• Czy działania mają konkretne nazwy i odpowiedni poziom szczegółowości?
• Czy warunki wyczerpują wyniki decyzji?
• Czy poprawnie odróżniono decyzję, scalenie, rozwidlenie i synchronizację?
• Czy istotne dane i odpowiedzialności są pokazane bez nadmiaru?
• Czy warianty błędne, anulowanie i powtórzenia są uwzględnione, jeśli mają znaczenie?
• Czy diagram zgadza się z opisem wymagań i innymi widokami?

Opis procesu w UML powstaje przez świadomy wybór działań, warunków, danych i odpowiedzialności. Czytelny diagram nie musi zawierać wszystkich kroków implementacji; musi natomiast pozwalać odbiorcy poprawnie zrozumieć ważne przebiegi i ich ograniczenia.