Drugi najczęściej stosowany diagram UML 🙂 Diagram aktywności (ang. activity diagram) opisuje przepływ zachowań w systemie. Dzięki DA wiadomo, w jakiej kolejności wykonywane są poszczególne aktywności, a dzięki partycjom wiadomo też, kto lub co daną czynność wykonuje. 

diagram aktywności przedstawia przepływ sterowania między ułożonymi w określoną sekwencję czynnościami, opisuje przepływ zachowań w systemie”

 Elementy, które najczęściej występują w diagramach czynności, to:  

  • Czynność
  • Akcja
  • Przepływ sterowania
  • Początek
  • Koniec
  • Zakończenie przepływu

Diagramy czynności stosuje się w modelowaniu:

  • wysokopoziomowych procesów biznesowych
  • systemów oraz podsystemów
  • scenariuszy przypadków użycia
  • procesów systemowych charakteryzujących się dużą liczbą równoległych czynności i sytuacji decyzyjnych
  • operacji
  • algorytmów

Aktywność, czynność (ang. activity)

Aktywność- to zachowanie systemu, przedstawione w postaci uporządkowanych elementów.

Inaczej mówiąc jest to sekwencja czynności oparta o uporządkowany model przepływu. 

Prezentuje behawioralne zachowanie systemu.
Activity jest czynnością “złożoną” , bardziej “ogólną” niż akcja (action)- activity podlega dekompozycji do innych akcji lub czynności.

Akcja (ang. action)

Wykonywalne, unikatowe zachowanie.
Pojedynczy, szczegółowy krok w procesie.
Wynikiem działania action może być zmiana stanu lub zwrócenie wyniku.
Akcja nie podlega dekompozycji.

Różnica między czynnością a aktywnością

Kryterium Czynność   (Activity)           Akcja (Action)

IstotaPodzielnaNiepodzielna, ze swojej natury nie podlega przerwaniu
Poziom ogólnościOgólnaSzczegółowy przypadek, może być konsekwencją czynności
DekompozycjaDozwolonaNiedozwolona
Czas realizacjiZnaczącyNieznaczny

Przepływ sterowania (ang. control flow)

Przepływ sterowania, przedstawiany jako strzałka z grotem, prezentuję relację między dwoma czynnościami lub akcjami wskazującą, że po wykonaniu źródłowej czynności/akcji sterowanie zostanie przekazane do docelowej czynności/akcji.

Z zasady, do jednej akcji/czynności powinien wchodzić i wychodzić tylko jeden przepływ.

Uwaga: Jeśli trzeba skierować przepływ do dwóch lub więcej czynności/akcji, dla czytelności diagramu, lepiej stosować decision/merge lub fork/join.

Początek (ang. start)

Rozpoczęcie przepływu sterowania, inicjujący funkcjonowanie diagramu czynności.
W diagramach czynności standardowo występuje jeden początek (wyjątkiem mogą być systemy czasu rzeczywistego i sytuacja przechodzenia między PU).
Warto opisywać ”początek”, stosując np. nazwy PU.

Koniec przepływu (ang. flow final)

Punkt zatrzymania wybranego przepływu sterowania.
Zazwyczaj stosowany dla sytuacji wyjątkowych.
Może wystąpić więcej niż jedno zakończenie przepływu.

Koniec aktywności (ang. activity/ action final)

Element kończący aktywność.
Punkt zatrzymania wszystkich przepływów sterowania i danych w diagramie czynności.
Wskazuje na cel (warunek końcowy) realizacji usługi systemowej opisanej przez diagram.
Aktywność może mieć więcej niż jedno zakończenie

Przepływy decyzyjne

Umożliwiają opisanie złożonych sytuacji decyzyjnych.
Prezentują czynności lub akcje, wykonywane po zrealizowaniu alternatywnych, uzależnionych od spełnienia ściśle określonych warunków lub wykonania iteracji.

Decision/merge

Węzeł decyzyjny (ang. decision)

Decyzji używamy w momencie, gdy w modelu jeden przepływ sterowania może być zrealizowany na różne sposoby, po spełnieniu określonego warunku.

W UML jeden jest przepływ wejściowy i wiele wyjściowych z tym, że każdy przepływ wyjściowy powinien być opisany warunkiem. Warunki natomiast muszą być tak określone, żeby się wzajemnie wykluczały.

Dzięki odpowiedniemu opisaniu warunków, po wyjściu z decyzji realizowany jest tylko jeden przepływ wyjściowy.
Pamiętajcie, by zawsze np w notatce opisywać warunki przejść (na przepływach lub dodatkowo w notatce do decision).

Złączenie (ang. merge)

Merge integruje kilka przepływów wejściowych w jeden wyjściowy. Dzięki temu możliwy jest “powrót” do jednej ścieżki z wielu alternatywnych przepływów.
Uwaga! Merge NIE synchronizuje przepływów! Merge także nie realizuje warunków, tylko określa, że każdy zrealizowany przepływ wchodzący do złączenia automatycznie uruchamia wykonanie wyjściowego przepływu

Przepływy współbieżne

Fork i join. Bardzo sympatyczne, i bardzo użyteczne elementy diagramu aktywności.
Najprościej ujmując, fork i join pozwala na poprowadzenie przepływów współbieżnych. I podstawowy warunek stosowania fork i join jest taki, że liczba wszystkich przepływów wynikowych rozwidlenia nie musi być zgodna z liczbą współbieżnych przepływów wejściowych w scaleniu 🙂

Wyglądają identycznie, mogą wystąpić w wersji pionowej lub poziomej. Ale stosuje się je w różnych sytuacjach.

Rozwidlenie (ang. fork)

Fork umożliwia zaznaczenie na modelu jednego przepływu wejściowego oraz dwóch lub więcej przepływów wynikowych (wychodzące).
Wizualizując sobie;) Fork kopiuje znacznik sterowania i przekazuje jego kopię do wszystkich przepływów współbieżnych.

Czyli fork rozwidla proces na wiele równolegle występujących akcji / czynności.

Uwaga! Czynności/akcje występujące po fork nie muszą być realizowane dokładnie w tym samym czasie!

Scalenie (ang. join)

Join scala wiele przepływów w jeden.
Oznacza przekazanie sterowania z wielu współbieżnych, wejściowych przepływów sterowania do jednego wynikowego.
W punkcie scalenia równoległe procesy ulegają synchronizacji.
Można określić specyfikację scalenia, zapisywaną na diagramie na wysokości scalenia (przykładowo, przejście do dalszego procesu będzie warunkowane osiągnięciem przez obiekt jakiegoś stanu).
Znacznik sterowania jest przekierowywany do przepływu tylko w przypadku prawdziwości wyrażenia.

Czyli najprościej mówiąc, join oznacza, że w pewnym momencie wszystkie ścieżki łączą się znów w jeden przepływ 🙂

Partycja (ang. partition)

Umożliwia wskazanie odpowiedzialnego za wykonanie danych akcji/czynności (lub inne istotne dla modelu i specyfikacji) informacji.

Partycje występują w układzie pionowym, poziomym lub obu. Można je zagnieżdżać, tworząc subpartycje.

Można też definiować partycje zewnętrzne (<>) dotyczące obiektów i czynności poza zakresem funkcjonalnym danego przypadku użycia.

Zobacz także:

Diagram aktywności

Leave a Reply

Your email address will not be published.