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 ;).
Diagram stanów w 2026: Fundament bezpiecznego projektowania
W 2026 roku, gdy systemy stają się coraz bardziej złożone i autonomiczne, precyzyjne określenie stanów obiektu to nie luksus, a fundament bezpiecznego wdrożenia. Nawet przy wsparciu AI, to analityk pozostaje strażnikiem logiki biznesowej.
Diagram stanów jest w tym procesie bezlitosnym weryfikatorem – pozwala wyłapać luki w wymaganiach na etapie projektu, zanim zamienią się w kosztowne błędy na produkcji. Często okazuje się, że to właśnie nieprzewidziane przejścia między stanami są najczęstszą przyczyną awarii, które zmuszają zespół do łapania się za głowę. Zrozumienie tej dynamiki pozwala przejść od teoretycznego opisywania funkcji do budowania systemów, które są przewidywalne i odporne na błędy.
Jeśli chcesz opanować tę umiejętność i tworzyć modele, które staną się jasnym drogowskazem dla deweloperów, zapraszam Cię do uporządkowania tej wiedzy w praktyczny sposób.
W moim kursie UML – podstawy modelowania systemów pokazuję, jak przekładać skomplikowaną logikę na czytelne diagramy, zachowując przy tym autentyczność i biznesowy konkret. To GPS, który przeprowadzi Cię przez meandry modelowania tak, abyś zawsze dokładnie wiedział/a, w jakim punkcie projektu się znajdujesz.
Ź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/
FAQ: Diagram stanów w praktyce analitycznej (2026)
Co to jest diagram stanów i dlaczego jest kluczowy w analizie biznesowej?
Diagram stanów to wizualna mapa pokazująca wszystkie cykle życia konkretnego obiektu w systemie np. zamówienia czy wniosku kredytowego. W 2026 roku, przy rosnącej złożoności systemów, jest on kluczowy, ponieważ pozwala precyzyjnie określić, co może się stać z danym obiektem w odpowiedzi na konkretne zdarzenia.
Kiedy najlepiej użyć diagramu stanów zamiast diagramu aktywności czy BPMN?
Diagram aktywności lub procesy w BPMN świetnie pokazują „kto, co i po czym robi” (przepływ pracy). Diagram stanów stosujemy wtedy, gdy chcemy skupić się na logice konkretnego bytu. Jeśli Twój obiekt ma wiele statusów (np. „nowy”, „w weryfikacji”, „zatwierdzony”, „odrzucony”) i skomplikowane reguły przejść między nimi, to właśnie diagram stanów będzie najlepszym narzędziem.
Czy w dobie AI i nowoczesnych technologii diagramy stanów są wciąż potrzebne?
Zdecydowanie tak. Choć AI wspiera nas w generowaniu kodu, to analityk pozostaje odpowiedzialny za spójność logiki biznesowej. W 2026 roku diagram stanów to fundament projektowania systemów odpornych na błędy (resilient systems). Bez tej mapy nawet najlepszy deweloper może narzucić rozwiązanie, które nie będzie optymalne, bo nie przewidział wszystkich sytuacji wyjątkowych.
