Ze stanami, statusami mamy do czynienia w zamówieniach, wizytach, ubezpieczeniach, obiegu dokumentów, czyli w praktycznie każdym systemie. Bywa, że tworzymy listę stanów, ale już nie zawsze pamiętamy jednoznacznie określić wszystkie możliwości przejść między nimi. Wtedy zaczyna się wymyślanie – tworzenie ograniczeń lub nierealnych możliwości.
Diagram stanów (w notacji UML) pozwala na kompletne i jednoznaczne określenie stanów obiektu oraz zdarzeń powodujących zmiany (przejścia między stanami). Dzięki temu możliwe jest:
- odkrycie brakujących informacji,
- kontrola kompletności wymagań (związanych z danymi i zachowaniem),
- wyjaśnianie niejasności,
- identyfikacja konfliktów wymagań i ich rozstrzyganie.
Poza nazwą – diagram stanów (ang. State Diagram), znane są także inne: diagram maszyny stanów (ang. State Machine Diagram), diagram przejść stanów (ang. State Transition Diagram) czy diagram cyklu życia encji (ang. Entity Life Cycle Diagram).
Od czego zacząć?
Stany ujęte są w sekwencje, w jakiej przyjmuje je obiekt w swoim cyklu życia (od utworzenia do zniszczenia). W każdym stanie istnieje zamknięta lista zdarzeń, które powodują zmianę (przejście) na określony inny stan.
Aby stworzyć prosty diagram stanów, wystarczy zidentyfikować i określić:
- Listę stanów,
- Możliwe przejścia między stanami.
Przykład? Wiadomość w skrzynce. Stany? Odebrana, Odczytana, Zarchiwizowana, W koszu.
Poza tym, na diagramie stanów można przedstawiać także:
- Warunki przejść między stanami (rozgałęzienia wyborów),
- Podstany (stany złożone z podstanów),
- Pseudostany (warunki, przerwania i wznowienia, stany historii),
- Sygnały wysyłane i odbierane,
- Listy stanów,
- Maszyny stanów.
Po szczegóły odsyłam na razie do specyfikacji UML [2].
Stany
Stan (ang. state) reprezentuje określone warunki, w jakich znajduje się obiekt lub status, jaki może on posiadać. Stany wykluczają się nawzajem – obiekt może być w określonym czasie tylko w jednym stanie. Aby je zidentyfikować, należy przeanalizować dziedzinę biznesową (problemową). Ze stanami mogą być związane pewne charakterystyki (atrybuty), np. przejście zamówienia w stan „złożone” powinno wymagać przypisania daty utworzenia.
Obiekt powinien posiadać:
- stan początkowy (np. utworzony, nowy),
- stany pośrednie (np. zatwierdzony, oczekujący),
- stan końcowy (np. usunięty, zakończony).
Przejścia między stanami
Przejście (ang. Transition) reprezentuje zachowanie, które powoduje zmianę stanu obiektu (z określonego stanu do jednego ze stanów możliwych dla niego do osiągnięcia). Przejścia mogą być wyzwalane przez zakończone aktywności, zdarzenia czy inne wyzwalacze, ale tylko te, na które odpowiada obiekt będąc w danym stanie.
Przykłady:
- Nowe zamówienie nie może zostać odebrane, zanim nie będzie wysłane (wtedy dopiero stan „odebrane” będzie osiągalny).
- Zgaszone światło nie reaguje na zdarzenie gaszenia, ale zapalone, już tak.
Ku uwadze
Przygotowując diagramy stanów należy pamiętać, by nie tworzyć ich zbyt wiele i pilnować zgodności z zakresem rozwiązania (czy przejście jest akcją, która znajduje się w granicach rozwiązania?). Niektóre stany, które posiada obiekt, mogą nie mieć znaczenia w kontekście systemu i należy je pominąć.
Przykład:
Przykłady stanów zamówionej pizzy w rzeczywistym procesie jej dostarczania: zamówiona, upieczona, zapakowana, do dostarczenia, odebrana, schrupana. Jeśli system nie ma wspierać zadań kucharza a jedynie same zamówienia i doręczenia – znaczenie będą miały stany: zamówiona i odebrana, dla systemu nie będą miały znaczenia stany: upieczona, zapakowana, do dostarczenia i schrupana (choć dla nas, w świecie rzeczywistym, mogą pozostawać bardzo ważne ;).
Źródła:
- International Institute of Business Analyst IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 2.0, 2009.
- Object Management Group: Unified Modeling Language version 2.4.1 [on-line]. Dostępne: http://www.omg.org/spec/UML/2.4.1/
