Stan i maszyna stanów#
Stan (state) opisuje sytuację obiektu lub systemu, która ma znaczenie dla jego zachowania: wpływa na to, jakie zdarzenia może obsłużyć, jakie warunki obowiązują albo jakie działania są dostępne. Maszyna stanów UML przedstawia możliwe stany oraz przejścia między nimi. Jest użyteczna, gdy zachowanie zależy od historii lub aktualnego etapu cyklu życia.
Stan nie jest po prostu wartością jednego atrybutu. Może wynikać z kilku właściwości i kontekstu, a model może abstrahować od szczegółów implementacji. Stan powinien być nazwany tak, aby jasno opisywał utrzymującą się sytuację, na przykład OczekujeNaPłatność, Opłacone albo Wysłane.
Przejście, zdarzenie, warunek i efekt#
Przejście (transition) opisuje zmianę z jednego stanu do drugiego. Może zostać uruchomione przez zdarzenie (trigger), takie jak platnoscPotwierdzona. Warunek ochronny (guard) w nawiasach kwadratowych dopuszcza przejście tylko wtedy, gdy wyrażenie jest prawdziwe. Efekt (effect) po ukośniku opisuje działanie wykonywane w związku z przejściem.
Zamówienie zaczyna w stanie Nowe. Potwierdzenie płatności prowadzi do Oplacone tylko wtedy, gdy kwota jest poprawna; później nadanie przesyłki przenosi je do Wyslane. Zapis pomija anulowanie, odrzucenie płatności, zwrot oraz inne wymagane ścieżki — należałoby je dodać, jeśli diagram ma opisywać pełny cykl życia.
Składnia etykiety przejścia#
Typowa etykieta przejścia ma postać zdarzenie [warunek] / efekt. Zdarzenie może być pominięte, gdy przejście jest bezwarunkowe albo wynika z zakończenia aktywności w stanie. Warunek można pominąć, jeśli nie ogranicza przejścia. Efekt można pominąć, gdy przejście nie wykonuje dodatkowej akcji.
Zdarzenie nie jest nazwą następnego stanu. platnoscPotwierdzona opisuje bodziec, który może wywołać zmianę; Oplacone opisuje sytuację po zmianie. Warunek odpowiada na pytanie, czy wolno przejść, a efekt — co wykonać, gdy przejście następuje. Rozdziel te elementy, by nie ukryć reguł w długim opisie.
Aktywności wejścia, wykonywania i wyjścia#
Stan może mieć aktywność wejściową (entry), wykonywaną po wejściu do stanu; aktywność wyjściową (exit), wykonywaną przy jego opuszczaniu; oraz aktywność do, wykonywaną podczas pozostawania w stanie. Zdarzenia wewnętrzne mogą obsłużyć bodziec bez opuszczania stanu. Wprowadź je wtedy, gdy opisują zachowanie zależne od utrzymywanej sytuacji, nie tylko dla ozdobienia diagramu.
Aktywność do może trwać i zostać przerwana przez przejście lub zdarzenie, zależnie od modelu. Czynności krótkie i atomowe można zapisać jako efekt przejścia albo aktywność wejścia. W systemie czasu rzeczywistego znaczenie przerwań i czasów wymaga precyzyjniejszego modelu.
Stany początkowe, końcowe i złożone#
Węzeł początkowy wskazuje start maszyny lub regionu. Stan końcowy oznacza zakończenie maszyny stanów dla danego kontekstu; nie należy mylić go z pseudostanem zakończenia regionu złożonego, po którym może być wykonywane dalsze zachowanie nadrzędne. W prostej maszynie jeden stan końcowy często wystarcza, ale możliwe są różne zakończenia i ścieżki.
Stan złożony zawiera podstany, a regiony ortogonalne pozwalają modelować współbieżne aspekty zachowania. Zaawansowane konstrukcje, takie jak historia płytka lub głęboka, wybór przejścia czy węzeł połączeniowy, służą konkretnym celom i powinny być wprowadzane dopiero wtedy, gdy prosty graf stanów nie wystarcza. Ich pominięcie w diagramie uproszczonym powinno być jawne.
Stan a przepływ procesu#
Maszyna stanów opisuje odpowiedzi obiektu na zdarzenia i jego cykl życia. Diagram aktywności lepiej pokazuje przepływ pracy, kolejność czynności, decyzje, przepływy danych i współbieżne gałęzie procesu. Gdy pytanie brzmi „co się dzieje po zdarzeniu w różnych stanach?”, wybierz maszynę stanów. Gdy pytanie brzmi „jakie kroki wykonuje proces?”, zwykle lepsza jest aktywność.
Stan może mieć wiele przychodzących i wychodzących przejść. Nie każda para stanów musi być połączona. Przejścia mogą prowadzić do tego samego stanu lub pętli własnej, jeśli zdarzenie zmienia zawartość stanu, lecz nie jego nazwę.
Spójność i kompletność modelu#
Sprawdź, czy każda ważna sytuacja ma stan, a każde wymagane zdarzenie ma zdefiniowaną reakcję w kontekście. Jeśli zdarzenie może zostać zignorowane, odrzucone albo odłożone, opisz to. W przeciwnym razie odbiorca może założyć, że wszystkie niepokazane przypadki są niemożliwe.
Przy przejściach wychodzących z tego samego stanu rozważ, czy ich warunki są rozłączne i czy obejmują wszystkie przypadki. Jeśli więcej niż jeden warunek może być prawdziwy, reguły priorytetu lub wybór przejścia muszą być jasne. Nie dopisuj losowego priorytetu w implementacji, jeśli model go nie uzasadnia.
Typowe błędy#
- Stan nazwany czynnością. Czynność jest zwykle zdarzeniem lub efektem; stan opisuje utrzymującą się sytuację.
- Zdarzenie pomylone ze stanem docelowym. Trigger uruchamia przejście, stan docelowy opisuje wynik.
- Warunek pominięty. Jeśli przejście zależy od reguły, zapisz guard albo opisz ją w dokumentacji.
- Każdy krok procesu zamieniony na stan. Użyj diagramu aktywności, gdy modelujesz sekwencję działań.
- Brak obsługi zdarzeń. Wskaż, czy niewłaściwe zdarzenie jest ignorowane, niedozwolone czy prowadzi do błędu.
- Stan końcowy utożsamiony z usunięciem obiektu. Zakończenie maszyny nie przesądza samo o cyklu życia instancji.
- Niejasne warunki alternatywne. Rozłączne i kompletne warunki ułatwiają implementację i testy.
Podsumowanie#
Stan opisuje istotną sytuację obiektu, a przejście zmianę wywołaną zdarzeniem, ewentualnie ograniczoną warunkiem i połączoną z efektem. Maszyna stanów porządkuje cykl życia i reakcje na zdarzenia. Odróżniaj ją od diagramu aktywności, który lepiej przedstawia kolejność czynności w procesie.