Diagram stanów (diagram maszyny stanowej w UML 2.0)

Diagramy interakcji mówiły nam o zachowaniu obiektów, diagram stanów z kolei służy do tego, by pokazać w jakich stanach mogą być obiekty. Poniżej widzimy diagram stanów obiektu dane:

Dane mogą znajdować się w różnych stanach, które są oznaczone zaokrąglonymi prostokątami. Linie ze strzałkami oznaczają przejścia między stanami. Na diagramie widzimy także przypadek, kiedy istnieją dwie alternatywne drogi przejścia między stanami. Rozwidlenie, podobnie jak scalenie dwóch ścieżek przebiegu zmian stanów jest zaznaczone na diagramie pogrubioną poziomą kreską.

Diagram aktywności (czynności)

Diagram aktywności jest pewną mutacją diagramu stanów, z tą różnicą, że diagram aktywności skupia się raczej na opisaniu jakiegoś procesu, w którym uczestniczy wiele obiektów, zaś diagram stanów pokazuje, jakie są możliwe stany konkretnego obiektu. Diagram aktywności jest bardzo dobrym narzędziem, gdy chcemy przedstawić odpowiedzialność obiektów w ramach jakiegoś procesu.

Na diagramie zaokrąglone prostokąty reprezentują konkretne zadania, które powinien wykonać system (bądź jego elementy), rombami zaznaczamy miejsca, w których są podejmowana decyzje, wynikające z efektów wykonania jakiegoś zadania. Podobnie jak na diagramie stanów (maszyny stanowej) pogrubione poziome linie oznaczają miejsca, w których pewne czynności wykonywane są jednocześnie. W naszym przypadku system komputerowy może sprawdzać, czy dana książka jest dostępna i czy dana osoba ma prawo ją wypożyczyć.

Prostokąt z zagiętym rożkiem oznacza element UML-a, który może wystąpić na dowolnym diagramie – notatkę. Notatka służy do tego, aby przekazać jakieś informacje, które tłumaczą bądź precyzują znaczenie jakiegoś elementu (lub jak to się czasem mówi, artefaktu) diagramu

Oczywiście modelując rzeczywisty system należałoby określić jakie systemy są odpowiedzialna za każde z działań, trzeba by też zadbać o to, żeby nie było wątpliwości, że wysłanie książki następuje tylko wtedy, gdy jest ona zarówna dostępna jaki i osoba chcąca ją wypożyczyć ma do tego prawo.

W tym miejscu warto zrobić następującą uwagę. UML w pewnym sensie nie jest kompletny – nie zawsze udaje się modelować przy jego pomocy każdy aspekt tworzonego systemu. Innymi słowy nie zawsze uda się osiągnąć zależność jeden do jednego między kodem a diagramem. Stąd też pojawiają się pokusy, aby rozszerzyć UML tak, by można było z niego generować gotową aplikację. Warto jednak pamiętać, że UML jest językiem modelowania, a model z założenia nie jest dokładną kopią modelowanego obiektu, lecz takim jego obrazem, który pozwala poznać jego najistotniejsze elementy.

Trzeba pamiętać zatem o tym, aby diagramom UML-owym towarzyszyła odpowiednia dokumentacja, która będzie zawierała istotne informacje, które nie są widoczne na diagramie.