Zacznij od obiektu i jego reguł#

Cykl życia obiektu opisuje, jak zmienia się jego stan w odpowiedzi na zdarzenia i jakie zachowania są dozwolone w poszczególnych sytuacjach. Diagram maszyny stanów UML jest przydatny, gdy ten sam komunikat lub operacja ma inne znaczenie zależnie od stanu obiektu, a reguły przejść trzeba uzgodnić, wdrożyć lub przetestować.

Najpierw określ, którego typu instancji dotyczy model i kiedy jego cykl się zaczyna oraz kończy. Nie modeluj „całego systemu” jako jednego obiektu, jeśli różne elementy mają niezależne stany. Zamówienie, płatność i wysyłka mogą wymagać oddzielnych maszyn, nawet jeżeli ich przebiegi są powiązane.

Odróżnij stan od wartości atrybutu#

Stan (state) to sytuacja obiektu, w której spełnione są określone warunki, obiekt wykonuje pewne zachowanie lub reaguje na zdarzenia w określony sposób. Wartość atrybutu, np. liczba pozycji lub adres, nie musi być osobnym stanem. Status może być prostą cechą, jeśli nie zmienia dopuszczalnych operacji; maszyna stanów jest cenna wtedy, gdy rozróżnienie stanów niesie reguły.

Nazwij stany krótko, zwykle rzeczownikiem lub przymiotnikiem: Nowe, Opłacone, W realizacji, Wysłane. Dla każdego zapisz, co oznacza i jakie działania są w nim dozwolone lub zabronione. Jeśli dwa stany nie różnią się regułami ani zachowaniem, rozważ ich scalenie.

Znajdź zdarzenia i przejścia#

Przejście (transition) prowadzi z jednego stanu do drugiego, gdy wystąpi zdarzenie wyzwalające, zostanie spełniony warunek ochronny i zostanie wykonany efekt, jeśli model go określa. Zapis przejścia może mieć postać zdarzenie [warunek] / efekt.

Przykładowo opłać [autoryzacja poprawna] / zarejestruj płatność może prowadzić ze stanu Nowe do Opłacone. Zdarzeniem jest żądanie opłacenia; warunek ogranicza dopuszczalność przejścia; efekt opisuje działanie wykonywane podczas przejścia. Nie myl warunku z efektem ani z nazwą stanu.

Przejście bez jawnej etykiety może być przejściem automatycznym. Używaj go świadomie: jeśli obiekt powinien czekać na zdarzenie zewnętrzne, brak triggera może błędnie sugerować natychmiastową zmianę.

Stany początkowe, końcowe i wewnętrzne#

Pseudostan początkowy wskazuje punkt wejścia do maszyny; nie jest zwykłym stanem obiektu. Stan końcowy aktywności maszyny oznacza koniec danego przebiegu. W zależności od celu można modelować kilka końcowych rezultatów, np. Dostarczone oraz Anulowane jako stany końcowe albo jako stabilne stany biznesowe, z których obiekt dalej reaguje na zdarzenia.

Przejście wewnętrzne obsługuje zdarzenie bez opuszczania stanu. Jest właściwe, gdy obiekt pozostaje w tym samym stanie, ale wykonuje działanie, np. rejestruje próbę ponownej wysyłki. Działania entry i exit wykonywane przy wejściu do stanu lub jego opuszczaniu pomagają uniknąć powielania efektów na wielu przejściach.

Przykład: cykl życia zamówienia#

Diagram stanów zamówienia: po utworzeniu jest nowe, po opłaceniu oczekuje na realizację, następnie przechodzi do wysłanego i dostarczonego; przed wysyłką może zostać anulowane.
Uproszczony cykl życia zamówienia z warunkowym anulowaniem.

Diagram pokazuje, że zamówienie może zostać anulowane przed płatnością albo po płatności, ale w drugim przypadku efekt obejmuje zwrot. Po wysłaniu w tym modelu anulowanie nie jest dozwolone. To założenie trzeba potwierdzić w regułach sklepu; zwrot po wysyłce może być odrębnym procesem, a nie przejściem do Anulowane.

Procedura budowy maszyny stanów#

  1. Wybierz typ obiektu i granice jego cyklu życia.
  2. Zbierz operacje, zdarzenia, statusy, reguły i przypadki brzegowe z wymagań.
  3. Zapisz kandydatów na stany; zdefiniuj warunki, które je odróżniają.
  4. Połącz przejścia ze zdarzeniami i opisz warunki ochronne.
  5. Dodaj efekty, entry/exit actions lub przejścia wewnętrzne, jeśli wyjaśniają zachowanie.
  6. Określ stan początkowy oraz dopuszczalne zakończenia.
  7. Odtwórz scenariusze sukcesu, błędu, anulowania i powtórzeń.
  8. Szukaj martwych stanów, niedostępnych przejść, luk i przejść bez triggera.
  9. Porównaj nazwy i zdarzenia z wymaganiami oraz innymi diagramami.

Złożone maszyny: stany złożone i regiony#

Jeżeli maszyna ma wiele stanów, można grupować je w stany złożone. Podstany dzielą zachowanie na czytelne obszary, a przejścia do stanu nadrzędnego mogą ograniczać powtarzanie. Region ortogonalny modeluje jednoczesne, niezależne aspekty stanu; nie oznacza jedynie, że dwa działania są „ważne w tym samym czasie”. Wymaga to poprawnej semantyki współbieżnych regionów i zdarzeń.

Historia może pozwolić wznowić ostatni aktywny podstan przy ponownym wejściu do stanu złożonego. Używaj pseudostanów historii dopiero wtedy, gdy wymagania określają takie wznowienie. W przeciwnym razie jawne wejście do stanu początkowego podmaszyny jest prostsze.

Sprawdź kompletność modelu#

Przejdź przez każde zdarzenie w istotnych stanach. Co się stanie, gdy przyjdzie nieoczekiwane zdarzenie? Czy należy je zignorować, zapisać, zgłosić błąd czy obsłużyć? Czy przejścia o tym samym triggerze mają rozłączne warunki? Czy stan końcowy rzeczywiście zamyka cykl, czy instancja dalej żyje i przyjmuje operacje?

Przygotuj tabelę lub testy, w których przypadek wejściowy zawiera stan początkowy, zdarzenie i warunki, a oczekiwany wynik — stan docelowy i efekty. Diagram może ułatwić wyprowadzenie takich testów, ale sam nie dowodzi, że implementacja jest zgodna.

Typowe błędy#

  • Każdy status jako stan. Użyj maszyny, jeśli status wpływa na zachowanie lub dopuszczalne zdarzenia.
  • Stany bez definicji. Sama etykieta może nie rozstrzygać, co jest w danej sytuacji prawdą.
  • Przejście opisane efektem zamiast zdarzeniem. Oddziel trigger, warunek i działanie.
  • Niewzajemnie wykluczające się warunki. To samo zdarzenie może wtedy niejednoznacznie wybierać kilka przejść.
  • Brak obsługi zdarzeń. Ustal, co dzieje się z nieoczekiwanymi sygnałami.
  • Automatyczne przejście bez intencji. Pusta etykieta może sugerować natychmiastową zmianę.
  • Mieszanie cykli życia powiązanych obiektów. Płatność i zamówienie mogą mieć osobne maszyny.
  • Przesadne rozdrobnienie. Stany równoważne pod względem reguł utrudniają czytanie.
  • Założenie, że anulowanie usuwa historię. Przejście stanu nie określa samo z siebie trwałości danych.
  • Brak testowania ścieżek. Sprawdź scenariusze i przypadki brzegowe, nie tylko wygląd diagramu.

Lista kontrolna#

  • Czy wiadomo, którego typu obiektu dotyczy maszyna i kiedy jego cykl się zaczyna?
  • Czy każdy stan wyraża odrębne warunki lub zachowanie?
  • Czy przejścia mają odpowiednie zdarzenia i warunki?
  • Czy efekty są przypisane we właściwym miejscu?
  • Czy przypadki błędne, anulowanie i nieoczekiwane zdarzenia są rozstrzygnięte?
  • Czy nie ma nieosiągalnych stanów ani luk w przebiegu?
  • Czy pozostałe diagramy i wymagania są z modelem spójne?

Modelowanie cyklu życia polega na określeniu, co obiekt może zrobić w danym stanie i jakie zdarzenia zmieniają jego zachowanie. Gdy te reguły są jawne, diagram staje się użyteczną podstawą do rozmów, implementacji i testów.