DIAGRAMY UML.

Prezentacja na temat: "DIAGRAMY UML."— Zapis prezentacji:

1 DIAGRAMY UML

2 Diagramy UML Rafał KASPRZYK
9 diagramów pozwalających opisać elementy systemu z różnych perspektyw W UML 2.0 wyróżnia się już 13 diagramów: Diagram klas Diagramy komponentów Diagramy wdrożenia Diagramy obiektów Diagramy struktury Diagramy pakietów Diagramy przypadków użycia Diagramy sekwencji Diagramy komunikacji nazywane wcześniej diagramami współpracy Diagramy aktywności Diagramy stanów maszyny nazywane wcześniej diagramami stanów Diagramy widoku interakcji Diagramy przebiegów czasowych Rafał KASPRZYK

3 Przypadek użycia Wycinek funkcjonalności, którą system musi realizować, aby spełnić wymagania Opis zbioru ciągów akcji wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Zbiór scenariuszy powiązanych wspólnym celem użytkownika Scenariusz jest to ciąg kroków opisujących interakcje między użytkownikiem, a systemem Przypadek użycia to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku. Scenariusz jest to ciąg kroków opisujących interakcje między użytkownikiem, a systemem. Natomiast przypadek użycia systemu jest to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika. Przypadek użycia to wycinek funkcjonalności, którą system musi realizować aby spełnić wymagania Rafał KASPRZYK

4 Zastosowanie przypadków użycia
Służą do identyfikacji wymagań funkcjonalnych Każdy przypadek użycia powinien opisywać realizację jakiegoś celu biznesowego Cele biznesowe opisywane są z punktu widzenia aktora używającego systemu Umowa między dostawcą, a klientem Ustalenie priorytetów dla wymagań funkcjonalnych Pomagają w określeniu granic systemu Jakie funkcje są realizowane przez system Jakie funkcje należą do innego systemu Przypadek użycia opisuje co system robi, ale nie określa jak to robi Wstęp do szczegółowej analizy i projektowania Podstawa do identyfikacji klas i obiektów Określenie odpowiedzialności i współpracy obiektów Definicja przepływu komunikatów między obiektami Przypadki użycia służą do analizy całego systemu. Można je jednak zastosować także do analizy części systemu, a nawet pojedynczych klas i interfejsów. Przypadki użycia nie tylko definiują oczekiwane zachowanie tych bytów, ale są także podstawą do opracowania dla nich przypadków testowych. Przypadki użycia mają przed sobą dwa podstawowe zadania: - odkrycie, zebranie i uporządkowanie wymagań funkcjonalnych systemu, tego co system ma robić, - dostarczenie informacji dla kolejnych etapów analizy i projektowania systemu. Przypadki użycia nie zajmują się wymaganiami niefunkcjonalnymi. Nie dostarczają informacji o: - koszcie projektu i planowanym zwrocie inwestycji, - czasach realizacji poszczególnych etapów projektu, - wydajności systemu i polityce bezpieczeństwa. Przypadki użycia nie zajmują się bezpośrednio identyfikacją klas i obiektów, ale dostarczają podstawowych informacji koniecznych do realizacji tego zadania. Wymagania funkcjonalne konieczne do: Modelowania logiki biznesowej Wymagania niefunkcjonalne konieczne do: Budowy modelu architektury Rafał KASPRZYK

5 Relacje między przypadkami użycia
Relacja zawierania, <<include>> Pozwala na współdzielenie funkcjonalności pomiędzy podstawowymi przypadkami użycia Reużywalny wycinek funkcjonalności Relacja rozszerzania, <<extend>> Warunkowe rozszerzenie funkcjonalności podstawowego przypadku użycia osadzone w punkcie rozszerzenia Służy do opisywania opcjonalnego przepływu zdarzeń Pozwala na minimalizację liczby zmian wprowadzanych do podstawowego przypadku użycia Relacja uogólnienia Możliwości różnych implementacji tego samego przypadku użycia Specjalizowany przypadek użycia zastępuje podstawowy przypadek użycia w jego relacjach Oznacza szczególną implementację uogólnionego przypadku użycia Do relacji zawierania dochodzi wtedy, gdy kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której nie warto ciągle kopiować z jednego przypadku do drugiego. Rozszerzenie przypadku użycia może wzbogacić go o dodatkowe zachowania, ale w takiej sytuacji podstawowy przypadek użycia musi określić pewne punkty rozszerzenia, a rozszerzający przypadek użycia może dodać nowe zachowania tylko w tych punktach. Przypadek użycia może mieć wiele punktów rozszerzeń, a rozszerzający przypadek użycia może rozszerzać podstawowy przypadek użycia w kilku z tych punktów. Trzecią relacją jest uogólnienie. W istocie jest bardzo podobne do rozszerzenia, jest jednak mniej formalne. Uogólnienie używa się wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest nieco obszerniejszy. Specjalistyczny przypadek użycia może przesłonić dowolną część podstawowego przypadku użycia, ale zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika co podstawowy przypadek użycia. Rafał KASPRZYK

6 Przykłady relacji między przypadkami użycia
Rafał KASPRZYK

7 Przykład bankomatu Diagram przypadków użycia pozwala na wizualizację
Relacji pomiędzy przypadkami użycia Relacji pomiędzy przypadkami użycia a aktorami Relacji pomiędzy aktorami Zarówno uogólnienie, rozszerzenie, jak i zawieranie umożliwiają rozbicie przypadku użycia. W fazie rozwinięcia często rozbijam przypadki użycia, które stają się zbyt skomplikowane. W fazie budowy rozbijam przypadek użycia, gdy okazuje się, że nie mogę go zaimplementować całego w jednej iteracji. Należy stosować następujące reguły: Gdy trzeba powtórzyć coś w kilku przypadkach użycia, a jednocześnie chce się uniknąć powtórzeń, należy używać relacji zawierania Gdy trzeba opisać warianty typowego postępowania przy zachowaniu opisu nieformalnego, należy używać relacji uogólnienia Gdy trzeba opisać warianty typowego postępowania, ale jest potrzebny bardziej formalny opis ze zdefiniowaniem punktów rozszerzeń w przypadku podstawowym, należy używać relacji rozszerzenia. Rafał KASPRZYK

8 Diagramy aktywności Są grafami aktywności i przejść między nimi
Stanowią uogólnioną wersję diagramów stanów maszyna stanu, której podstawowym zadaniem nie jest analiza stanów obiektu, ale modelowanie przetwarzania (przepływu zadań) Stany grafu aktywności (aktywności), odpowiadają stanom wyróżnialnym w trakcie przetwarzania, a nie stanom obiektów Aktywność może być interpretowana jako zadanie do wykonania przez człowieka lub komputer odpowiedzialność/operacja/metoda klasy Przejścia między stanami raczej nie są związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania specyficznego dla danej aktywności Proces warunkowy jest określony za pomocą rozgałęzienia (branch) i scalenia (marge). Procesy współbieżne są określane za pomocą rozwidleń (fork) i złączeń (join). Rafał KASPRZYK

9 Zastosowanie diagramów aktywności
Diagramy aktywności są szczególnie przydatne przy modelowaniu przypływu zadań i w opisie procesów z dużą liczbą równoległych czynności Dają możliwość opisu czynności warunkowych i współbieżnych Proces warunkowy jest przedstawiany za pomocą rozgałęzienia (ang. branch) i scalenia (ang. marge). Procesy współbieżne jest przedstawiany za pomocą rozwidlenia (ang. fork) i złączenia (ang. join). Określają sposób uszeregowane działania Opisują podstawowe reguły porządkujące czynności Pozwalają na określenie obiektów odpowiedzialnych za wykonywanie danej czynności na wysokim poziomie abstrakcji („tory pływackie”) W celu uszczegółowienia należy stosować diagramy interakcji Zrozumienie procesów biznesowych Wygodny sposób analizy przypadków użycia Współdziałanie obiektów na wysokim poziomie abstrakcji Opisanie algorytmu Sekwencyjnego Równoległego i/lub współbieżnego (aplikacje wielowątkowe) Diagram czynności umożliwia wybór kolejności rzeczy do zrobienia. Innymi slowy określa podstawowe reguly porządkujące wykonywanie czynności. Nie są ograniczone do procesów sekwencyjnych, ale potrafią ująć dodatkowo procesy wspólbieżne. Jest to ważne przy modelowaniu procesów biznesowych. Przedsiębiorstwa często mają niepotrzebnie sekwencyjne procesy. Technika zachęcająca do stosowania wspólbieżności jest bardzo cenna, bo zwraca uwagę na możliwość wykonywania pewnych czynności równolegle. Może to poprawić wydajność i szybkość procesów biznesowych. Rafał KASPRZYK

10 Diagram aktywności Rafał KASPRZYK

11 Przykład obsługi zamówienia
Diagram czynności umożliwia wybór kolejności rzeczy do zrobienia. Innymi slowy określa podstawowe reguly porządkujące wykonywanie czynności. Nie są ograniczone do procesów sekwencyjnych, ale potrafią ująć dodatkowo procesy wspólbieżne. Jest to ważne przy modelowaniu procesów biznesowych. Przedsiębiorstwa często mają niepotrzebnie sekwencyjne procesy. Technika zachęcająca do stosowania wspólbieżności jest bardzo cenna, bo zwraca uwagę na możliwość wykonywania pewnych czynności równolegle. Może to poprawić wydajność i szybkość procesów biznesowych. Rafał KASPRZYK

12 Klasa Opis zbiór obiektów, które mają takie same
Atrybuty – opisują stan Najczęściej typy proste lub biblioteczne Nie posiadają własnych reguł biznesowych Ich wartości są istotne dla obiektów klasy Operacje – opisują zachowanie Usługi oferowane przez każdy obiekt klasy Zwykle powodują zmianę stanu obiektu Dzielą się na zapytania i polecenia Związki – uogólnienia, realizacje, zależności, asocjacje, … Zachowanie klasy często zależy od zachowania innej klasy Pozwalają na unikaniu antywzorców (np.”BLOB”) Znaczenie Realizuje jeden bądź więcej interfejsów Interfejs definiuje zewnętrznie obserwowalne zachowanie takiego elementu, określając zbiór deklaracji operacji, ale nigdy sposobu implementacji Klasa to opis zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie. Klasa realizuje jeden bądź więcej interfejsów. Na diagramie jest przedstawiana jako prostokąt, który zwykle zawiera nazwę, atrybuty i operacje. NOTACJA DLA ATRYBUTÓW [visibility] name [multiplicity] [: type] [= init-value] [{property-string}] changeable, read-only, addOnly, frozen NOTACJA DLA OPERACJI [visibility] name [({[param] [: type]}*)] [:return-value] [{property-string}] query, modify Interfejs to zestaw operacji, które wyznaczają uslugi oferowane przez klasę lub komponent. Interfejs definiuje zatem zewnętrznie obserwowalne zachowanie takiego elementu. Można reprezentować pełne zachowanie klasy lub elementu lub jedynie część. Określa zbiór deklaracji operacji (czyli sygnatur) ale nigdy zbiór implementacji operacji. Rafał KASPRZYK

13 Przykład klasy i interfejsu
Rafał KASPRZYK

14 Klasy parametryzowane
Kilka języków, a w szczególności C++, zawiera pojęcie klasy parametryzowalnej albo wzorca, szablonu. Pojęcie to najbardziej przydaje się przy pracy ze zbiorami w językach z kontrolą typów. W ten sposób definiując wzorzec klasy, można zdefiniować zachowanie calej rodziny klas. W ten sposób można korzystając z ogólnej definicji, tworzyć klasy zbiorcze konkretnych elementów. Lista<Osoba> listaOsób Element zastępuje parametr typu. Użycia klasy parametryzowalnej, takiej jak np. Lista<Osoba>, jest nazwane elementem związanym. Element związany można przedstawić na dwa sposoby. Pierwszy jest odbiciem syntaktyki C++. Notacja alternatywna akcentuje związek z wzorcem i umożliwia zmianę elementu związanego. Stereotyp <<bind>> jest stereotypem relacji uszczególowiania. Relacja ta wskazuje, że ListaOsób będzie zgodny z interfejsem Listy. template<class Element> class Lista{ Element *first public: virtual dodaj(const Element& e); virtual usuń(const Element& e); } Rafał KASPRZYK

15 Klasy asocjacyjne Klasy asocjacyjne umożliwiają dodanie dodatkowych atrybutów i operacji do asocjacji Może istnieć tylko jedna instancja klasy asocjacyjnej między dowolnymi dwoma obiektami połączonymi asocjacją Klasy asocjacyjne umożliwiają dodanie atrybutów, operacji i innych elementów do asocjacji. Klasa asocjacyjna wnosi dodatkowe ograniczenie - może istnieć tylko jedna instancja klasy asocjacyjnej między dowolnymi dwoma obiektami połączonymi asocjacją. Diagram nie daje Pracownikowi możliwości drugiego etatu (Stanowiska) w tej samej Firmie. Jeśli jest potrzebna taka możliwość to klasa Stanowisko musi być samoistną klasą. Należy o tym pamiętać!!! Rafał KASPRZYK

16 Asocjacja kwalifikowana
Odpowiednik tablic asocjacyjnych, map i słowników Wskazuje sposób znajdowania powiązanych obiektów Najczęściej powoduje konieczność implementacji powiązania w postaci mapy w kwalifikatorze z kwalifikowanym końcem Asocjacja kwalifikowana jest UML-owym odpowiednikiem pojęcia tablic asocjacyjnych, map lub slowników. Diagram przedstawia przykład asocjacji stosującej kwalifikację Przedstawienie-Bilet. Kwalifikacja mówi, że dla Przedstawienia może istnieć jeden Bilet dla każdej instancji Miejsca na określoną datę. Rafał KASPRZYK

17 Diagram klas dla SI uczelni
SYSTEM INFORMACYJNY UCZELNI Rafał KASPRZYK

18 Stereotypy analityczne dla klas
Terminator (ang. boundary) – modeluje interakcję pomiędzy aktorem a systemem Sterowanie (ang. control) – prowadzi obliczenia, koordynację, nadzoruje transakcje i przebieg sekwencji Encja (ang. entity) – modeluje encje biznesowe, najczęściej o charakterze trwałym (zapisywane w bazie danych) Rafał KASPRZYK

19 Diagramy sekwencji Przedstawiają interakcje pomiędzy obiektami, przy czym największy nacisk kładą na zależności czasowe Stosowane zawsze, gdy kolejność wywołań oraz ograniczenia czasowe są istotna Nadają się do modelowania Systemów czasu rzeczywistego Przetwarzania współbieżnego Złożonych scenariuszy Nie prezentują związków strukturalnych między współdziałającymi obiektami Pozwalają na modelowanie różnych typów interakcji Synchroniczna Asynchroniczna Powrót Komunikat synchroniczny – nadawca zawiesza swoją działalność dopóki odbiorca nie przekaże sterowania, co można oznaczyć symbolem powrotu Powrót – nie jest komunikatem, oznacza zakończenie komunikatu i przekazanie sterowania do nadawcy Komunikat plaski – przekazanie sterowania do odbiorcy, kończąc własną działalność Komunikat asynchroniczny – nadawca komunikat nie oczekuje na odpowiedź nadawcy, ale też nie kończy własnej działalności, nadal przetwarza, może wysyłać komunikaty Rafał KASPRZYK

20 Elementy diagramów sekwencji
Rafał KASPRZYK

21 Przykład biura maklerskiego
Rafał KASPRZYK

22 Diagramy współpracy Kolejność wywołań prezentowana za pomocą numeracji
Stanowią wystąpienie fragmentu diagramu klas Stosowane, gdy przy modelowaniu interakcji ważne jest wzajemne powiązanie obiektów Rodzaje powiązań pomiędzy obiektami <<field>> <<parameter>> <<local>> <<global>> … Diagramy współpracy stanowią wystąpienie fragmentu diagramu klas, lepiej przedstawiają związki między obiektami biorącymi udzial w realizacji danego przypadku użycia. Rafał KASPRZYK

23 Przykład biura maklerskiego
Rafał KASPRZYK

24 Komponenty Fizyczna, wymienna część oprogramowania z dobrze zdefiniowanym interfejsem, wyizolowana z kontekstu i dzięki temu nadająca się do wielokrotnego wykorzystania Każdy komponent jest luźno powiązany z innymi komponentami, najczęściej za pomocą zależności i realizacji Rodzaje komponentów Wdrożenia – podstawa systemu wykonywalnego biblioteki DLL, pliki wykonywalne EXE, EJB Procesu wytwórczego – podstawa do generacji komponentu wdrożeniowego Wykonania – powstałe w wyniku działania systemu Przykłady komponentów programy wykonywalne, biblioteki, tabele, pliki, dokumenty, bazy danych itp. Komponent jest jednostką implementacji z dobrze zdefiniowanym interfejsem, dobrze wyizolowany z kontekstu, nadający się do wielokrotnego wykorzystania. W każdym systemie można spotkać wiele rodzajów wdrożonych komponentów (np. COM+ i Java Beans), a także komponentów będących artefaktami w procesie wytwarzania (np. pliki z kodem źródłowym) i komponenty wykonania (np. wydruki, raporty). Rafał KASPRZYK

25 Diagramy komponentów Rafał KASPRZYK

26 Węzły Sprzętowe składowe działającego systemu Dzielimy na:
Procesory – reprezentują zasoby obliczeniowe Posiadają pewną ilość pamięci i zdolność przetwarzania Mogą wykonywać kod komponentu Urządzenia – są interfejsem do świata zewnętrznego Nie mają zdolności przetwarzania (np. monitor, drukarka) Służą do modelowania infrastruktury sprzętowej (diagramy wdrożenia), pozwalając jednocześnie na zobrazowanie fizycznego rozmieszczenia (rozproszenia) komponentów na poszczególnych węzłach Komponenty reprezentują fizyczne wymienne części systemu, które realizują elementy logiczne, a węzły to fizyczne składniki systemu na których wdrożone zostają komponenty Rafał KASPRZYK

27 Diagramy wdrożenia Rafał KASPRZYK
Diagramy wdrożeniowe pokazują konfigurację systemu czasu wykonywania, czyli rozmieszczenie komponentów na zasobach obliczeniowych czasu wykonywania, zwanych węzłami. Taka konfiguracja może być zarówno statyczna jak i dynamiczna – komponenty i obiekty mogą migrować między węzłami w czasie wykonywania. Diagram wdrożenia pokazują fizyczne rozproszenie komponentów po procesorach i urządzeniach Najczęściej mamy do czynienia z sytuacją w której diagramy komponentów „umieszczane” są na diagramach wdrożenia, aby pokazać, które komponenty działają na których węzłach. Rafał KASPRZYK

28 Diagramy stanów Są grafami stanów i przejść między nimi
Akcje są związane z przejściami i traktuje je jako procesy szybkie i nieprzerywalne Czynności są związane ze stanami, trwają zazwyczaj dłużej, ale mogą zostać przerwane przez zdarzenie Opisują reakcje obiektu na otrzymane komunikaty i zdarzenia zewnętrzne Niezwykle użyteczne do modelowania obiektów reaktywnych, czyli takich których zachowanie charakteryzowane jest przez ciąg odpowiedzi na zdarzenia wywoływane w jego otoczeniu Modelują zachowanie obiektów danej klasy w oderwaniu od reszty systemu Wszystkie obiekty danej klasy znajdujące się w tym samym stanie reagują w jednakowy sposób na otrzymanie tego samego komunikatu lub zdarzenia Maszyna stanu – graf skierowany, którego wierzchołki stanowią stany obiektu, a luki opisują przejścia między stanami. Przejście jest odpowiedzią na zdarzenie. Akcje są związane z przejściami i traktuje się je jako procesy szybkie i nieprzerywalne (atomowe). Czynności są związane ze stanami i mogą trwać dłużej. Czynność może zostać przerwana przez jakieś zdarzenie. Diagramy aktywności są specyficznym rodzajem diagramów stanów, na którym większość stanów to stany czynnościowe, a wszystkie przejścia są uruchamiane w chwili zakończenia czynności w stanie źródłowym. Diagramy aktywności i diagramy stanów są niezwykle użyteczne do modelowania historii życia obiektu. Diagram aktywności obrazuje przepływ sterowania między czynnościami, a diagram stanów przepływ sterowania między stanami. Diagramy stanów nadają się do modelowania dynamicznych aspektów systemu, w szczególności modelowania obiektów reaktywnych, czyli takich którego zachowanie najlepiej jest charakteryzowane przez ciąg odpowiedzi na zdarzenia wywołane w jego otoczeniu. Zwykle taki obiekt jest bezczynny do chwili zajścia zdarzenia. Gdy ono nastąpi, jego reakcja zależy najczęściej od wcześniejszych zdarzeń. Po zakończeniu akcji spowodowanych zdarzeniem obiekt znów jest bezczynny i czeka na następne bodźce. Rafał KASPRZYK

29 Elementy diagramów stanów
Zdarzenia – bodziec, który może uruchomić przejście pomiędzy stanami Wołanie – operacja(a:T) Synchroniczne wywołanie żądania, gdzie obiekt wołający czeka na wynik Zmiana – when(wyr.) Ciągłe czekanie na spełnienie warunku Sygnał – sygnał (a:T) Asynchroniczna komunikacja jednokierunkowa Czas – after(czas) Uzależnione od czasu, definiowanego bezwzględnie lub względnie Stany mogą mieć nazwy i być definiowane na trzy sposoby Wartość atrybutów obiektów Czas, gdy obiekt oczekuje na nadejście jakiegoś zdarzenia Czas, w którym obiekt wykonuje jakieś czynności Przejścia – wskazują, że obiekt przejdzie z jednego stanu do drugiego, ilekroć zajdzie określone zdarzenie i będą spełnione warunki entry/akcja – oznacza wykonanie akcji podczas wejścia do stanu exit/akcja – oznacza wykonanie akcji podczas wyjścia ze stanu zdarzenie(a:T)[dozór]/akcja Przejście zewnętrzne – wykonanie akcji exit zmiana stanu i wykonanie akcji entry Przejście wewnętrzne – wykonanie akcji exit i entry bez zmiany stanu Entry – entry/akcja - oznacza wykonanie akcji podczas wejścia do stanu Exit – exit/akcja - oznacza wykonanie akcji podczas wyjścia ze stanu Przejście zewnętrzne – zdarzenie(a:T)[dozór]/akcja – w odpowiedzi na odebrane zdarzenie następuje zmiana stanu i wykonanie akcji Przejście wewnętrzne - zdarzenie(a:T)[dozór]/akcja – w odpowiedzi na odebrane zdarzenie następuje wykonanie akcji bez zmiany stanu Zdarzenie to specyfikacja zjawiska, które zachodzi w czasie i w przestrzeni. Zdarzenie jest wystąpieniem bodźca, które może uruchomić przejście między stanami. Typy zdarzeń: wołanie: otrzymanie przez obiekt synchronicznego żądania wykonania operacji op(a:T) zmiana: do modelowania sytuacji gdy obiekt zmienia stan po otrzymaniu odp. na wysłany przez siebie komunikat when(wyrażenie) sygnał: otrzymanie przez obiekt asynchronicznego żądania wykonania operacji sygnał(a:T), użyteczne do modelowania zdarzeń pochodzących z zewnątrz systemu czas: upłynięcie czasu określonego w sposób bezwzględny lub względny after(czas) Stan obiektu może być charakteryzowany jako: zbiór wartości obiektu (atrybutów i powiązań) w pewnym sensie podobnych okres czasu w którym obiekt oczekuje na zdarzenie jako okres czasu w którym obiekt przetwarza Nazwa stanu Entry/akcja1/akcja2/... Do/aktywność1/... Exit/akcja1/akcja2/... Przejście to związek pomiędzy dwoma stanami, wskazujący, że obiekt znajdujący się w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu, ilekroć zajdzie określone zdarzenie i będą spełnione odpowiednie warunki. Rodzaje przejść: przejście zewnętrzne i wewnętrzne: zdarzenie[warunek]/akcja przejście automatyczne: [warunek]/akcja Rafał KASPRZYK

30 Przykład obiektu klasy ”Konto Bankowe”
Rafał KASPRZYK

31 Przykład obiektu klasy ”Sesja Użytkownika”
Stan złożony , powstały w efekcie zagnieżdżenia stanów, może być dekomponowany na stany bardziej proste, a dekompozycja jest tu rodzajem specjalizacji. Każdy z podstanów dziedziczy przejścia nadstanu. Tylko jeden z podstanów może być aktywny w danym momencie. Diagramy stanów współbieżnych przydają się w wypadku, gdy dany obiekt ma pewne zbiory niezależnych zachowań. Jednak nie należy mieć zbyt wielu zbiorów współbieżnych zachowań dla pojedynczego obiektu. Jeśli dla jednego obiektu jest kilka skomplikowanych diagramów stanów współbieżnych, to należałoby się zastanowić nad rozbiciem tego obiektu na kilka prostszych. Rafał KASPRZYK