Akcja i aktywność#
Akcja (action) jest wykonywalnym krokiem modelowanego zachowania. Aktywność (activity) porządkuje akcje i przepływy, które opisują proces lub algorytm. Akcja jest zwykle przedstawiana jako zaokrąglony prostokąt z nazwą, na przykład Sprawdź dane albo Zarezerwuj produkt. Diagram aktywności pokazuje, kiedy akcje mogą się rozpocząć i jak ich wyniki wpływają na dalszy przebieg.
Akcja jest pojęciem modelu, niekoniecznie jedną metodą w kodzie. Może odpowiadać operacji, zadaniu użytkownika, wywołaniu usługi lub abstrakcyjnemu fragmentowi zachowania. Wybierz poziom szczegółowości zgodnie z pytaniem diagramu: kroki powinny być wystarczająco konkretne do zrozumienia procesu, ale nie tak drobne, by rysunek stał się listą instrukcji implementacyjnych.
Przepływ sterowania#
Przepływ sterowania (control flow) wskazuje, która akcja może wykonać się po zakończeniu poprzedniej. Strzałka łączy węzły aktywności, a nie przenosi sama danych. W typowym diagramie węzeł początkowy uruchamia przebieg, akcje wykonują pracę, węzły decyzyjne rozdzielają ścieżki, a węzeł końcowy aktywności oznacza koniec całego przebiegu.
Przepływ sterowania kieruje proces do rezerwacji albo odrzucenia zamówienia. Przykład scala ścieżki przed końcem tylko dla prostoty rysunku; w rzeczywistym procesie po odrzuceniu mogą być potrzebne inne działania, jak informacja dla klienta. Nie wynika z niego, że obie akcje wykonują się w każdej instancji.
Przepływ obiektów i piny#
Przepływ obiektów (object flow) pokazuje przekazywanie danych lub obiektów między akcjami. Można go rozróżnić przez etykiety, węzły obiektów albo piny wejściowe i wyjściowe na granicy akcji. Przykładowo Sprawdź dane może otrzymać Zamówienie, a następnie wytworzyć PoprawneZamówienie lub BłędyWalidacji.
Samo połączenie sterowania nie oznacza przekazania danych. Akcja może być uruchomiona po innej akcji, ale potrzebować wejścia pochodzącego z kilku źródeł; modeluj te wartości jawnie, jeżeli ich przepływ ma znaczenie. Węzeł buforujący lub magazyn danych może reprezentować przechowywanie i pobieranie wartości, gdy jest to istotne dla zachowania.
Decyzja i złączenie#
Węzeł decyzyjny rozdziela przepływ na alternatywne ścieżki. Warunki ochronne przy wyjściach, zapisane w nawiasach kwadratowych, określają, która ścieżka jest dostępna. Zwykle warunki powinny być rozłączne i obejmować wszystkie możliwe przypadki; można użyć [else] jako ścieżki domyślnej.
Węzeł złączenia scala alternatywne ścieżki bez synchronizowania ich. Nie czeka na każdą gałąź, tylko przepuszcza tę, która dotarła. To różni go od węzła synchronizacyjnego (fork/join), który może rozdzielać przepływ na współbieżne działania lub czekać na ich ukończenie. Nie łącz alternatyw i współbieżności jednym symbolem bez sprawdzenia, jak czytelnik zinterpretuje przepływ.
Rozdzielanie i synchronizacja#
Węzeł fork dzieli przepływ na równoległe gałęzie; każda może działać niezależnie. Węzeł join synchronizuje przepływy, czekając na wymagane wejścia zgodnie z semantyką modelu. Przykładem może być równoczesne przygotowanie faktury i rezerwacja dostawy, po których system potwierdza zamówienie.
Równoległe linie na diagramie nie oznaczają automatycznie osobnych wątków ani maszyn. Określają współbieżne aspekty zachowania na poziomie modelu. Szczegóły synchronizacji, awarii jednej gałęzi i anulowania pozostałych mogą wymagać jawnego uzupełnienia.
Węzły początkowe i końcowe#
Węzeł początkowy wyznacza początek aktywności. Węzeł końcowy aktywności kończy całą aktywność, natomiast węzeł końcowy przepływu kończy tylko dany przepływ. Różnica jest ważna, gdy proces ma kilka gałęzi: zakończenie jednej z nich nie musi kończyć pozostałych.
Końcowy symbol powinien odpowiadać zakresowi diagramu. Jeśli diagram pokazuje tylko fragment aktywności, jawnie opisz, że wejście lub wyjście jest poza zakresem, zamiast sugerować początek lub koniec całego procesu.
Partycje i odpowiedzialność#
Partycje (swimlanes) grupują akcje według odpowiedzialności, na przykład aktora, zespołu, systemu albo komponentu. Położenie akcji w partycji pomaga odpowiedzieć na pytanie „kto wykonuje ten krok?”. Partycja nie jest automatycznie procesem, komponentem ani granicą wdrożenia; oznacza kategorię odpowiedzialności zdefiniowaną przez model.
Nie twórz osobnej partycji dla każdej osoby, jeśli odpowiedzialność jest taka sama. Przepływy przecinające wiele partycji mogą uwidaczniać przekazania pracy i granice systemu, ale nadmierna liczba pasów utrudnia czytanie.
Jak sprawdzać diagram#
Przejdź przez każdą ścieżkę od początku do właściwego końca. Sprawdź, czy warunki decyzji nie pozostawiają luki ani nie pozwalają na sprzeczne przebiegi, czy wszystkie wymagane dane trafiają do akcji, a każda synchronizacja czeka na odpowiednie gałęzie. Zwróć uwagę na przerwania, wyjątki, anulowanie i ponawianie, jeśli są częścią wymaganego procesu.
Oddziel logikę procesu od szczegółów interfejsu użytkownika. Akcje powinny opisywać zachowanie lub odpowiedzialność, a nie koniecznie każde kliknięcie. Jeśli ważne jest zachowanie obiektu po zdarzeniu, diagram stanów może być lepszym uzupełnieniem.
Typowe błędy#
- Każda strzałka uznana za przepływ danych. Sterowanie i wartości to różne przepływy.
- Węzeł decyzyjny użyty do współbieżności. Rozwidlenie warunkowe nie uruchamia równoległych gałęzi.
- Złączenie alternatyw uznane za synchronizację. Merge scala dostępny przebieg; join czeka na gałęzie.
- Warunki niekompletne lub sprzeczne. Ustal, co dzieje się dla każdego możliwego wyniku.
- Węzeł końcowy źle dobrany. Zakończenie przepływu i całej aktywności mają odmienne skutki.
- Przesadnie drobne akcje. Zachowaj poziom szczegółowości adekwatny do celu diagramu.
- Współbieżność pomylona z wielowątkowością. UML opisuje model zachowania, nie automatyczny wybór mechanizmu wykonania.
Podsumowanie#
Akcje opisują kroki zachowania, a przepływ sterowania określa, w jakiej kolejności mogą się wykonać. Przepływ obiektów przenosi dane. Decyzja wybiera ścieżkę, złączenie scala alternatywy, a fork i join modelują współbieżne gałęzie. Poprawny diagram rozróżnia te znaczenia i obejmuje istotne wyniki oraz zakończenia.