Diagram maszyny stanów

Czym jest diagram maszyny stanów#

Diagram maszyny stanów (state machine diagram), nazywany też diagramem stanów, opisuje, jak obiekt lub inny modelowany element zmienia stan w odpowiedzi na zdarzenia. Pokazuje możliwe stany, przejścia między nimi, warunki uruchomienia przejść oraz działania wykonywane przy zmianie lub trwaniu stanu.

Najbardziej przydaje się dla elementu, którego dozwolone zachowanie zależy od jego historii lub bieżącego stanu: zamówienia, rezerwacji, zgłoszenia, sesji, połączenia czy urządzenia. Diagram może odpowiedzieć na pytanie „co może się stać dalej?” w danym stanie i które zdarzenia są wtedy dopuszczalne.

Nie każdy obiekt potrzebuje osobnej maszyny stanów. Jeśli jego zachowanie nie zależy od cyklu życia, diagram może być zbędny. Diagram maszyny stanów nie jest również tym samym co diagram aktywności: pierwszy koncentruje się na stanach jednego elementu i zdarzeniach, drugi na przepływie działań w zachowaniu.

Stan#

Stan (state) jest warunkiem lub sytuacją w cyklu życia modelowanego elementu, w której zachowanie reaguje na zdarzenia w określony sposób. Typowe nazwy stanów to Nowe, Oczekuje na płatność, Zablokowane i Dostarczone. Rysuje się je jako prostokąty z zaokrąglonymi rogami.

Stan to nie po prostu wartość pojedynczego pola. Obiekt może być w stanie Oczekuje na płatność dlatego, że spełnia kilka warunków: ma numer zamówienia, przypisaną kwotę i nie otrzymał potwierdzenia. Stan pomaga wyrazić, jakie zachowanie jest dozwolone, nie tylko jakie dane ma obiekt.

Nie myl stanów ze zdarzeniami, etapami pracy i rolami. Płatność otrzymana brzmi jak zdarzenie; Opłacone jest stanem, w którym obiekt pozostaje po zdarzeniu. Pracownik jest rolą, a nie stanem zamówienia. Czasownikowa nazwa może być użyteczna dla krótkiej czynności, ale stan powinien opisywać trwającą sytuację.

Przejście, zdarzenie, warunek i efekt#

Przejście (transition) określa zmianę z jednego stanu do drugiego. Może zostać zapisane w postaci:

wyzwalacz [warunek ochronny] / efekt

Każda część jest opcjonalna. Przejście bez etykiety może być przejściem automatycznym lub jego szczegóły mogą zostać pominięte w widoku.

• Wyzwalacz (trigger) jest zdarzeniem, które może uruchomić przejście: sygnałem, wywołaniem, zmianą warunku lub upływem czasu.
• Warunek ochronny (guard) jest warunkiem logicznym sprawdzanym, gdy zdarzenie wystąpi. Zapisuje się go w nawiasach kwadratowych, np. [kwota > 0].
• Efekt (effect) jest działaniem wykonywanym w związku z przejściem, np. zwolnijRezerwację().

Zdarzenie nie musi powodować przejścia: może nie mieć obsługi w danym stanie, warunek może być fałszywy albo maszyna może je odroczyć. Jeśli kilka przejść wychodzi z jednego stanu i reaguje na to samo zdarzenie, warunki powinny rozstrzygać, która ścieżka jest dozwolona. Nakładające się lub niepełne warunki mogą prowadzić do niejednoznacznego modelu.

Efekt przejścia wykonuje się przy przejściu, natomiast czynności związane z przebywaniem w stanie modeluje się w jego zachowaniu wejścia, wyjścia lub do.

Przykład: cykl życia zamówienia#

Diagram przedstawia wybrany cykl życia zamówienia. Zdarzenie potwierdzenia płatności przenosi nowe zamówienie do stanu opłaconego. Następne zdarzenia opisują rozpoczęcie realizacji, nadanie przesyłki i potwierdzenie dostarczenia. Zamówienie może zostać anulowane przed opłaceniem albo zwrócone po opłaceniu.

Przejście z Nowe do Oplacone wymaga zdarzenia płatnośćPotwierdzona i spełnienia warunku dodatniej kwoty; przy przejściu wykonywane jest księgowanie. Anulowanie prowadzi do stanu końcowego i zwalnia rezerwację. Stany Dostarczone, Anulowane i Zwrot kończą przedstawiony cykl, ale nie oznacza to, że dane zamówienie musi być usunięte z systemu.

Diagram jest uproszczony: nie pokazuje odrzuconej płatności, ponowienia, częściowej wysyłki, anulowania po opłaceniu ani szczegółowych reguł zwrotu. Jeśli takie scenariusze są istotne, dodaj stany, warunki lub osobne maszyny dla podprocesów. Nie traktuj pominięcia na diagramie jako dowodu, że dana sytuacja jest niemożliwa.

Stany początkowe i końcowe#

Pseudostan początkowy jest oznaczany wypełnionym czarnym kółkiem. Wskazuje, od czego zaczyna się wykonanie maszyny. Strzałka z pseudostanu do stanu początkowego nie reprezentuje zdarzenia biznesowego; inicjuje maszynę.

Stan końcowy aktywności regionu jest pokazywany jako kółko z otaczającym pierścieniem. W maszynie stanów może oznaczać zakończenie danego regionu, niekoniecznie koniec życia obiektu. Pseudostan terminate ma inne znaczenie: kończy wykonanie kontekstu maszyny. Narzędzia i uproszczone przykłady mogą przedstawiać te elementy podobnie, dlatego w modelu formalnym trzeba dobrać symbol do rzeczywistej intencji.

W diagramie mogą wystąpić różne rodzaje stanów końcowych dla zagnieżdżonych regionów. Nie należy więc automatycznie utożsamiać „stanu zamkniętego” obiektu z pseudostanem końcowym UML.

Zachowanie wejścia, wyjścia i aktywności stanu#

Stan może określać zachowanie uruchamiane przy wejściu (entry), przy wyjściu (exit) oraz zachowanie trwające podczas przebywania w stanie (do). Na przykład po wejściu do stanu OczekiwanieNaPłatność system może uruchomić zegar, a przy wyjściu anulować oczekiwanie. Zachowanie do może trwać do zakończenia albo przerwania.

Akcje entry są użyteczne, gdy to samo działanie powinno być wykonane przy każdym wejściu do stanu. Podobnie exit może porządkować zachowanie wykonywane przy każdym opuszczeniu stanu. Nie przenoś do nich działań wykonywanych tylko przy jednym przejściu — w takim przypadku czytelniejszy jest efekt na krawędzi.

Przejście wewnętrzne obsługuje zdarzenie bez opuszczania stanu, więc nie uruchamia jego działań wyjścia i wejścia. Zewnętrzne przejście do tego samego stanu może natomiast opuścić i ponownie wejść do stanu. Wybór ma znaczenie, jeśli entry i exit wywołują efekty.

Stany złożone i regiony#

Stan złożony (composite state) zawiera podstany. Pozwala grupować wspólne zachowanie i modelować szczegóły tylko tam, gdzie są potrzebne. Przykładowy stan Realizacja może zawierać podstany Kompletowanie, Pakowanie i Przygotowanie wysyłki.

Stan złożony może zawierać regiony ortogonalne, których maszyny działają współbieżnie. Na przykład stan Obsługa płatności i dostawy może mieć niezależne regiony płatności i wysyłki. Trzeba wtedy określić, jak przejście wyższego poziomu oddziałuje na aktywne podstany i kiedy cały stan złożony można opuścić.

Hierarchia stanów może dziedziczyć obsługę zdarzeń: jeśli podstan nie obsługuje zdarzenia, może je obsłużyć stan nadrzędny. Pozwala to unikać powielania wspólnych przejść, ale może utrudniać odczyt, jeśli zachowanie jest rozrzucone po wielu poziomach. Kluczowe reakcje powinny pozostawać łatwe do odnalezienia.

Pseudostany i zaawansowane konstrukcje#

UML definiuje pseudostany, które służą do organizacji przejść i nie są zwykłymi stanami obiektu.

• Decyzja (choice) wybiera wyjściową ścieżkę na podstawie warunków ocenianych w chwili wejścia do pseudostanu.
• Węzeł junction łączy lub rozdziela przejścia statycznie, często upraszczając wspólne warunki.
• Fork i join rozdzielają albo synchronizują przepływ w ortogonalnych regionach.
• Pseudostan historii płytkiej (H) pozwala wrócić do ostatnio aktywnego bezpośredniego podstanu stanu złożonego.
• Pseudostan historii głębokiej (H*) pamięta aktywny podstan także w głębszych poziomach zagnieżdżenia.
• Punkty wejścia i wyjścia określają nazwane miejsca przekroczenia granicy podmaszyny lub stanu złożonego.
• Pseudostan terminate kończy wykonanie kontekstu maszyny.

To konstrukcje zaawansowane. Używaj ich, gdy wymaganie dotyczące hierarchii, współbieżności, przerwania lub wznowienia rzeczywiście istnieje. Prostszy diagram zwykłych stanów i przejść będzie lepszy, jeśli te mechanizmy nie są potrzebne.

Jak czytać maszynę stanów#

1. Znajdź pseudostan początkowy i prześledź przejścia do pierwszego stanu.
2. Odczytaj nazwy stanów jako sytuacje, w których znajduje się modelowany element.
3. Na każdym przejściu rozdziel wyzwalacz, warunek ochronny i efekt.
4. Sprawdź, czy zdarzenie jest obsługiwane w danym stanie i czy warunek może być spełniony.
5. Uwzględnij zachowania entry, exit i do oraz poziomy stanów nadrzędnych.
6. Sprawdź, czy przejście kończy region, całą maszynę, czy ją terminuje.
7. Przy stanach złożonych ustal, które regiony są aktywne i jak działają wspólne przejścia.
8. Przejdź przez scenariusze przykładowe i sprawdź, czy każde zdarzenie prowadzi do oczekiwanego stanu.

Rysunek pokazuje dozwolone zachowanie modelu, ale nie zawsze wszystkie ograniczenia lub dane. Warto przejść go z osobą, która zna cykl życia obiektu, i potwierdzić, że każda ścieżka reprezentuje rzeczywiste wymaganie.

Jak tworzyć diagram maszyny stanów#

1. Wybierz element o ważnym cyklu życia#

Zidentyfikuj obiekt, którego dostępne działania zmieniają się w czasie albo zależą od wcześniejszych zdarzeń. Nazwij element, do którego należy maszyna, np. Zamówienie lub Sesja użytkownika.

2. Zapisz stany, a nie same kroki#

Zapytaj, w jakich sytuacjach obiekt pozostaje i jak różni się wtedy jego zachowanie. Jeśli element jest tylko chwilową akcją, rozważ diagram aktywności zamiast maszyny stanów.

3. Wypisz zdarzenia i przejścia#

Dla każdego stanu sprawdź, jakie zdarzenia mogą wystąpić, które są ignorowane lub odraczane i jakie są stany docelowe. Ustal warunki ochronne i efekty.

4. Dodaj zachowanie i hierarchię#

Wstaw działania wejścia, wyjścia i do, jeśli powtarzalnie należą do stanu. Dodaj stany złożone, regiony, historię lub punkty wejścia tylko wtedy, gdy pomagają wyjaśnić rzeczywistą strukturę.

5. Przetestuj ścieżki#

Prześledź scenariusz normalny, błędny, graniczny i powtarzający zdarzenie. Ustal, czy każdy stan jest osiągalny, czy każde zdarzenie ma zrozumiałe zachowanie oraz czy stany końcowe są właściwie użyte.

Diagram maszyny stanów a diagram aktywności#

Ten sam problem może korzystać z obu diagramów: maszyna stanów określa, w jakich stanach może być zamówienie, a diagram aktywności pokazuje szczegółowy przepływ realizacji płatności.

Typowe błędy#

• Mieszanie stanów i zdarzeń. Płatność potwierdzona jest zdarzeniem, Opłacone — stanem po reakcji.
• Modelowanie każdej wartości jako stanu. Stany powinny odpowiadać różnicom w zachowaniu, nie wszystkim polom danych.
• Brak reakcji na ważne zdarzenia. Określ, co się dzieje, gdy zdarzenie jest nieobsługiwane, odroczone lub przychodzi w złym momencie.
• Niepełne lub nakładające się warunki ochronne. Przejścia mogą być niejednoznaczne albo niedostępne.
• Umieszczanie każdej akcji na przejściu. Działania wspólne dla każdego wejścia do stanu lepiej umieścić jako entry.
• Nadużywanie stanów złożonych. Hierarchia powinna upraszczać wspólne zachowania, a nie ukrywać większość logiki.
• Mylenie końca regionu ze stanem terminate. Symbole końcowe mogą mieć odmienne skutki dla maszyny i obiektu.
• Pominięcie efektu przejścia. Zmiana stanu nie musi automatycznie wykonywać wymaganej aktualizacji, np. zwolnienia rezerwacji.
• Używanie diagramu stanów do opisu kolejnych kroków procesu. Jeśli ważne są działania i ich kolejność, rozważ diagram aktywności.
• Założenie, że diagram wylicza wszystkie dane obiektu. Wartości i niezmienniki mogą wymagać diagramu klas, ograniczeń lub tekstu.

Co diagram maszyny stanów pokazuje, a czego nie#

Diagram maszyny stanów pokazuje stany modelowanego elementu, zdarzenia wywołujące przejścia, warunki, efekty oraz opcjonalnie hierarchię i współbieżne regiony. Ułatwia weryfikację, czy cykl życia obiektu dopuszcza właściwe działania w odpowiednich momentach.

Nie opisuje samodzielnie pełnej kolejności działań wewnątrz każdego procesu, struktury obiektów, komunikacji między wieloma uczestnikami ani fizycznego wdrożenia. Uzupełnij go diagramem aktywności, sekwencji lub klas, gdy potrzebne są te perspektywy.