Diagramy UML

dr inż. Elżbieta Zamiar

ezamiar@wsb.gda.pl
Agenda
◼ Przypomnienie
 Różnice w podejściu strukturalnym a
obiektowym
 Co to jest model
 Charakterystyka języka UML
◼ Diagramy interakcji
◼ Diagram stanów
◼ Diagramy aktywności
◼ Quiz
Model
◼ Spójny opis systemu
◼ Stanowi kompletny obraz systemu utworzony z
określonej perspektywy na pewnym poziomie
szczegółowości, co oznacza, że niektóre elementy
systemu są ukryte, a inne wyeksponowane
◼ Pojedynczy model zazwyczaj nie wystarcza ani do
zrozumienia wszystkich aspektów systemu
jednocześnie, ani do jego implementacji
◼ Proces projektowania systemu informatycznego
polega na kolejnym tworzeniu i wzajemnym
przekształcaniu wielu modeli
Diagram a model

◼ Diagram służy do opisania modelu

◼ Model może być opisywany przy
pomocy wielu diagramów
UML
◼ Służy do modelowania systemów
◼ Jest graficznym językiem wizualizacji,
specyfikowania, tworzenia i dokumentowania
składników i systemów …. informatycznych
◼ UML nie jest metodyką projektowania
◼ Jest notacją, opierającą się o podstawowe pojęcia
obiektowości
◼ Notacja, która może być użyta w dowolnej
metodyce
◼ Zapewnia semantykę ułatwiającą wymianę danych
modelu pomiędzy wieloma narzędziami CASE
(polecam https://prezi.com/p/zu19htr1ldn7/narzedzia-case/ )
Podejście strukturalne a
obiektowe
STRUKTURALNE
◼ dane i procesy modelowane
osobno,
◼ wykorzystanie w zasadzie
tylko prostych typów danych,
◼ dobrze dostosowane do
relacyjnego modelu danych,
◼ podstawowe techniki
 diagramy hierarchii funkcji
(FHD),
 diagramy związków encji
(ERD),
 diagramy przepływu danych
(DFD).
OBIEKTOWE
◼ dane i procesy modelowane
łącznie,
◼ wykorzystują złożone typy
danych,
◼ dostosowane do obiektowego
modelu danych,
◼ podstawowe techniki:
 diagramy opisu struktury
(diagramy klas UML)
 diagramy opisu dynamiki
(przypadki użycia (DPU),
modele dynamiczne UML:
interakcji , czynności i
stanów).
Obiekt, klasa, enkapsulacja

◼ Obiekt – instancja klasy (byt)

enkapsulująca (zamykająca):
 strukturę danych
 zachowanie
◼ Klasa – zbiór obiektów
Rodzaje diagramów

◼ Diagramy opisu
struktury

◼ Diagramy opisu
dynamiki
Diagramy
UML
Diagram struktury
Diagram
pakietów
 Kliknij, aby dodać tekst
Diagram
komponentów

Źrdódło: http://www.e-mentor.edu.pl/artykul/index/numer/53/id/1082
Delegowanie i przejmowanie
zadań przez klasy
◼ Związki pomi
ędzy diagra
mami
UML – Diagram Klas

(ang. Class diagram – CD)

Cel: Opis cech i metod obiektów

istotnych z punktu widzenia
analizowanej dziedziny
Atrybut klasy - widoczność
◼ Pełne określenie atrybutu klasy posiada składnię:

[widoczność] nazwa: typ [krotność] {ograniczenia} =wart. domyślna

◼ 4 poziomy widoczności
 + publiczny – widoczny z każdego miejsca systemu
 # chroniony – widoczny wewnątrz klasy i jej podklas
 - prywatny – widoczny tylko wewnątrz własnej klasy
 ~ publiczny wewnątrz pakietu – widoczny wewnątrz
własnego pakietu
Atrybut klasy - porządkowanie
◼ Pełne określenie atrybutu klasy posiada składnię:

[widoczność] nazwa: typ [krotność] {porządkowanie} =wart. domyślna

◼ Najczęściej stosowane porządkowanie to

 {ordered} – elementy wewnątrz atrybutu są uporządkowane
 {unique}– elementy wewnątrz atrybutu nie mogą się powtarzać
 {readOnly} – elementy wewnątrz atrybutu nie mogą być zmieniane
 {frozen} – elementy wewnątrz atrybutu, po ustawieniu nie mogą być
ponownie edytowane
◼ Krotność jest opcjonalna, domyślnie =1 i oznacza wartości, które
mogę być przechowywane w atrybucie. Jeżeli krotność ma tylko 1
wartość to jest pomijana wraz z nawiasami kwadratowymi i
porządkowanie
Metody klasy - składnia
◼ Metody to procesy, które klasa potrafi wykonać, pełne
określenie metody posiada składnię:

[widoczność] nazwa(parametr1, parametr2,...) :typ {ograniczenia}

◼ Metody mogą mieć również przypisane warunki wstępny i

końcowy
 Warunek wstępny określa w jakim stanie muszą znajdować się
pewne elementy systemu by operacja wykonała się prawidłowo
◼ np. pre: parametr1 != null
 Warunek końcowy określa oczekiwany stan elementu systemu
po wykonaniu operacji
◼ np. post: wynik != null
Relacje - Zależność

◼ Jest najsłabszym rodzajem relacji między

klasami
◼ Zmiana w jednej z klas wpływa jakoś ”na
drugą”.
◼ Zależność ta jest zwykle jednokierunkowa.
◼ Oznacza się ją przerywaną linią ze strzałką
określającą kierunek relacji
 Typy zależności

◼ Do typowych zależności należą:

 <<call>> -operacje klasy E_1 wywołują operacje
klasy E_2
 <<create>>– klasa E_1 tworzy instancje klasy E_2
 <<instantiate>> – obiekt E_1 jest instancją klasy 2
 <<use>> - aby zaimplementować klasę E_1
niezbędna jest klasa E_2
Relacje - asocjacje
◼ Asocjacja reprezentuje czasowe powiązanie między obiektami
dwóch klas
◼ Obiekty te jednak są od siebie niezależne.
◼ Ich czas życia może być różny.
◼ Asocjacja jest równorzędnym do atrybutu sposobem zapisu
cech klasy
Klasa asocjacyjna

◼ Zawiera informacje dotyczące samej

relacji asocjacji a nie przechowywane
przez żaden z połączonych obiektów
Klasa asocjacyjna
Asocjacja kwalifikowana

◼ Wskazuje konkretny atrybut danej klasy

zapewniający unikatowość relacji
◼ Atrybut ten jest jej kwalifikatorem
Relacje - agregacja

◼ Reprezentuje relację całość – część

◼ Część może należeć do kilku całości a
jej czas życia jest od nich niezależny
Relacje – kompozycja
(agregacja całkowita)

◼ Reprezentuje relację całość – część

◼ Część należy tylko do jednej całości a jej
czas życia jest od niej zależny. Jest jednym z
komponentów z których składa się całość
◼ Usunięcie klasy agregującej powoduje usunięcie
wszystkich jego części
Relacja - dziedziczenie

◼ Tworzy hierarchię klas

◼ Relacje wskazują klasę ogólną i klasy
bardziej szczegółowe
 Klasa abstrakcyjna
Klasa abstrakcyjna nie posiada
własnych instancji - obiektów

Na diagramie oznaczana
Jest kursywą w nazwie
Klasy lub słowem {abstract}
Proces tworzenia diagramu
klas
◼ Zidentyfikowanie i nazwanie klas
◼ Połączenie klas z wykorzystaniem asocjacji
◼ Zidentyfikowanie i nazwanie atrybutów i operacji
◼ Określenie cech asocjacji (nazwa, role, nawigacja,
liczebność, agregacja, kwalifikacja)
◼ Opracowanie innych rodzajów związków
(uogólnień, zależności, realizacji)
◼ Wyspecyfikowanie atrybutów i operacji według
składni
Klasa abstrakcyjna

Polimorfizm metod
Diagram klas – telefonia
komórkowa
Diagram klas
Diagram obiektów
◼ Obiekty są konkretnym bytem
inaczej instancją klasy
◼ Mają właściwości
zdefiniowane przez klasę w
tym cechy strukturalne i
behawioralne czyli metody
◼ Posiadają własną tożsamość
◼ Żadne dwa obiekty nie są
takie same
◼ Operacje/metody są wspólne
dla wszystkich obiektów klasy
nie przedstawia ich się osobno
dla każdego obiektu
UML - Diagram aktywności

(ang. Activity diagram – ad)

Inaczej - Diagram czynności
Cel: Modelowanie procesów biznesowych,
scenariuszy,
przypadków użycia
lub algorytmów
Diagram aktywności

◼ Diagram aktywności (czynności) - służy

do modelowania czynności i zakresu
odpowiedzialności elementów bądź
użytkowników systemu.
◼ Nie opisuje działań związanych z jednym
obiektem a wieloma, pomiędzy którymi
może występować komunikacja przy
wykonywaniu czynności.
DPU a diagram aktywności

◼ Przypadki użycia pokazują, co

powinien robić system
◼ Diagramy aktywności umożliwiają
określenie tego, w jaki sposób system
będzie osiągał swoje zamierzone cele
 Jakie akcje?
 Jak te akcje są połączone
Diagram aktywności/czynności

◼ (schematy blokowe) przedstawiają przepływ

sterowania od czynności do czynności
◼ większość diagramów czynności
przedstawia kroki procesu obliczeniowego
◼ łączą idee pochodzące z trzech źródeł:
 diagramów zdarzeń J.Odell'a,
 technik modelowania stanów,
 modelowania sieci Petriego.
Diagram aktywności/czynności
◼ Nie pokazuje wszystkich szczegółów przetwarzania.
◼ Prezentuje aktywności bez pokazywania bytów,
realizujących daną aktywność
◼ Jest punktem startowym dla procesu modelowania
zachowań
◼ Dla skompletowania projektu każda aktywność powinna być
zdekomponowana na szereg operacji (akcji/metod), z
których każdą trzeba będzie na późniejszym etapie
przydzielić do odpowiedniej klasy.
◼ Służy do:
 modelowanie przepływu czynności
 modelowanie operacji
Zastosowanie diagramów
aktywności / czynności

◼ Prezentacji
 wysoko poziomowych procesów biznesowych
 systemów oraz podsystemów
 scenariuszy przypadków użycia
 procesów systemowych charakteryzujących się
dużą liczbą równoległych czynności i sytuacji
decyzyjnych
 operacji
 algorytmów
Czynność vs. akcja
◼ Czynność:
 z perspektywy pojęciowej - to zadanie do wykonania i to
zarówno przez człowieka, jak i przez komputer
 z perspektywy projektu informatycznego - pojedyncza
metoda
 przejścia między stanami nie są związane z nadejściem
zdarzenia, ale z zakończeniem przetwarzania
wyspecyfikowanego dla danego stanu.
◼ Akcje są już niepodzielne, trwanie ich nie podlega
przerwaniu.
Czynność vs. akcja
◼ Czynności na diagramach mogą cechować się
rozbudowaną funkcjonalnością, tj. mogą
reprezentować niezwykle złożone procesy
biznesowe bądź algorytmy przetwarzania
◼ Dla osiągnięcia precyzyjnego ich opisu niezbędna
staje się dekompozycja czynności.
◼ Czynności mogą być i są zwykle dekomponowane
na zhierarchizowane podczynności
Diagram aktywności/czynności
◼ Zawartość:
 stany aktywności:
◼ stany czynności,
◼ przejścia,
◼ rozgałęzienia (branch) - decyzje,
◼ rozwidlanie (fork),
◼ scalanie (join),
◼ tory (swimlane),
◼ przepływ obiektów
 obiekty,
 notatki i ograniczenia.
Przykład diagramu aktywności
Znaczniki sterowania
◼ utworzenie znacznika
sterowania

◼ zniszczenie
wszystkich
znaczników
sterowania

◼ zniszczenie danego
znacznika sterowania
Decyzje

◼ Wyjście decyzji
stanowią dwa lub
więcej przepływów,
z których tylko
jeden może być
zrealizowany
Warunek logiczny
◼ kolejne warunki
muszą się wykluczać,
aby zapewnić
jednoznaczny
przepływ sterowania

◼ Rozgałęzienie
(decyzja)
Scalenie (join)

◼ Integruje kilka
przejść
wychodzących z
różnych
źródłowych
obszarów
współbieżnych,
stanów lub maszyn
stanowych.
Ścieżki współbieżne

◼ Rozwidlenie (1IN
– 2OUT, fork)

◼ Akcje współbieżne

◼ Scalenie
sterowania (2IN-
1OUT, join)
Przerywanie akcji
Złączenia

◼ Każdy przypływ
sterowania
docierający do
wejścia inicjuje
proces wyjściowy
Przykład

diagram aktywnosci -
logowanie.pdf
UML - Diagram interakcji

(ang. Interaction diagram)

Modelowanie interakcji pomiędzy
obiektami, pakietami
lub elementami systemu
Interakcja - definicja

◼ to zbiór komunikatów wysyłanych w

obrębie pewnego zbioru obiektów, w
ustalonym otoczeniu i w ściśle
określonym celu
◼ obrazuje przepływ sterowania w
systemie
◼ opisują komunikaty wysyłane
pomiędzy obiektami
Interakcje - powiązania
◼ Muszą istnieć powiązania między obiektami, aby
możliwe było wysyłanie komunikatów pomiędzy
nimi.
◼ Stereotypowe wiązania:
 <<association>> - widoczność obiektów przez
powiązanie,
 <<self>> - obiekt jest widoczny, bo sam odebrał
komunikat,
 <<global>> - obiekt o globalnym zasięgu,
 <<local>> - obiekt w lokalnym zasięgu,
 <<parameter>> - obiekt jest widoczny, ponieważ jest
parametrem.
Diagramy interakcji -
zadania
◼ Formalizacja dynamicznego zachowania się
systemu
◼ Każdy obiekt mający związek z konkretnym
przypadkiem użycia to obiekt uczestniczący
◼ Diagram interakcji obrazuje związki pomiędzy
obiektami uczestniczącymi
◼ Modelowanie przepływu sterowania z
uwzględnieniem:
 kolejności komunikatów w czasie
 organizacji strukturalnej obiektów
Rodzaje komunikatów
Rodzaje diagramów interakcji

Diagram interakcji

Diagram
Diagram sekwencji Diagram następstw
komunikacji
Diagram interakcji –
diagram sekwencji

(ang. Sequence Diagram –SD)

Modelowanie czasowej sekwencji
wymiany komunikatów podczas
współpracy obiektów, pakietów
lub komponentów
 sterowania pomiędzy obiektami

Diagram sekwencji (SD)

◼ Opisuje interakcje pomiędzy częściami systemu w postaci
sekwencji komunikatów wymienianych między nimi.
◼ Uczestnikami diagramów sekwencji najczęściej są obiekty
(opisane nazwą obiektu i jego klasą), które wymieniają między
sobą komunikaty.
◼ Obrazuje kolejność w czasie wysyłania komunikatów
pomiędzy różnymi obiektami w systemie.
◼ Prezentuje kolejność wywołań operacji, przepływ oraz szablon
realizowanego algorytmu.
◼ Pomija aspekt dostępu i operacji na danych, związany z
komunikacją.
Rodzaje komunikatów w SD
Graficzna prezentacja SD
◼ Składa się z:
 pionowych linii życia (ang. lifelines) poszczególnych obiektów
uczestniczących w interakcji
 wymienianych między nimi komunikatów (wywołań operacji).
◼ Linia życia obiektu to:
 czas, w którym konkretna instancja obiektu jest w stanie przyjmować
komunikaty i wysyłać je
 symbolizuje czas istnienia obiektu w systemie
 białe prostokąty umieszczone na linii życia obiektu oznaczają, że
obiekt jest zajęty wykonywaniem pewnej czynności (natomiast nie mają
bezpośredniego związku z istnieniem obiektu).
◼ Czas jest reprezentowany w postaci pionowej osi diagramu.
◼ Obiekt jest tworzony poprzez wysłanie do niego komunikatu-
konstruktora, natomiast niekoniecznie jest fizycznie usuwany na
końcu linii życia (raczej przestaje być istotny)
◼ Fizycznie usunięcie obiektu można wprost oznaczyć jako znak X na
linii życia.
Prezentacja interakcji w SD

◼ Interakcja w SD jest opisywana na

dwóch poziomach:
 Poziomym – jako oś na której
umieszczono instancje obiektów
biorących udział w interakcji (charakter
statyczny)
 Pionowym – jako oś czasu
reprezentująca ułożone chronologicznie
komunikaty (charakter dynamiczny)
Diagram sekwencji - przykład
Technika tworzenia diagramu
sekwencji
◼ Ustalenie otoczenia (operacja, scenariusz, PU itp.)
◼ Zidentyfikowanie obiektów biorących udział w
operacji (od lewej umieszczane obiekty
najważniejsze)
◼ Narysowanie linii życia obiektów (jeśli są tworzone i
niszczone - dodanie odpowiednich komunikatów)
◼ Dodanie komunikatu inicjującego, kolejne
komunikaty pod nim (dodanie parametrów do
komunikatów, tam gdzie potrzeba)
◼ Dodanie aktywacji (ośrodka sterowania)
◼ Dodawanie ograniczeń
 Zasady i praktyka tworzenia
diagramu sekwencji
◼ Nazywaj aktorów w sposób spójny z diagramami przypadków użycia
◼ Nazywaj obiekty/klasy w sposób spójny z diagramami klas
◼ Po lewej stronie umieszczaj aktorów, którzy są ludźmi lub organizacjami
◼ Po prawej stronie umieszczaj aktorów, którzy są innymi systemami reagującymi na działanie
modelowanego systemu
◼ Po lewej stronie umieszczaj aktorów, którzy są systemami inicjującymi interakcją z modelowanym
◼ Aktor może mieć tą samą nazwę co klasa
◼ Jeżeli nie jest to niezbędne - nie umieszczaj niszczenia (destroy) obiektu
◼ Umieszczaj nazwę obiektu jeżeli występuje odwołanie do niej w komunikacie
◼ Umieszczaj nazwę obiektu jeżeli istnieje wiele obiektów tej samej klasy
◼ Jeżeli umieszczono kilka obiektów o tej samej nazwie, muszą pochodzić z różnych klas
◼ Przy aktorach i obiektach/klasach umieszczaj stereotypy informujące o warstwie systemu, w której one
działają
◼ Umieszczaj najważniejsze komunikaty (zwykle)
◼ Jeżeli komunikat jest wysyłany do obiektu/klasy, który jest implementowany jako składnik
oprogramowania (klasa, interfejs, komponent), nazywaj komunikat z użyciem składni języka
programowania
◼ Jeżeli komunikat wymaga przekazania parametrów, podaj ich nazwy, a nie same typy danych
◼ Komunikaty wychodzące od aktorów, którzy są osobami lub organizacjami, nazywaj w sposób opisowy
(zdaniem)
◼ Komunikaty przesyłane do klas (nie obiektów) implementowane są jako metody statyczne
◼ Przy włączaniu innych przypadków użycia do aktualnie modelowanego stosuj komunikaty ze
stereotypem << include >>
◼ Komunikat tworzący obiekt oznaczaj stereotypem << create >>
◼ Aktywacja nie jest obowiązkowym elementem linii życia, ale ułatwia zrozumienie diagramu - podkreśla
czas trwania danej operacji
Diagramy sekwencji

◼ Uwypuklają kolejność komunikatów w

czasie, Jego elementy to
 linie życia (time)
 ośrodki sterowania (objects, user,
moduł)
 upływ czasu

 stereotypy <<create>> ,<<destroy>>

https://www.youtube.com/watch?v=pCK6prS
q8aw&t=41s
Diagram
sekwencji
https://www.youtube.com/wat
ch?v=pCK6prSq8aw&t=41s
Diagram sekwencji - przykład
Diagram interakcji - Diagram
komunikacji

(ang. Communication
Diagram - CD)
Diagram komunikacji - CD
◼ Specyfikują strukturalne związki pomiędzy
biorącymi udział w interakcji częściami oraz
wymianę komunikatów pomiędzy tymi instancjami.
◼ Akcja spowodowana przekazaniem komunikatu jest
instrukcją wykonywalną.
◼ Rodzaje akcji:
◼ <<call>> - wywołanie operacji,
◼ <<return>> - przekazanie wartości wywołującemu,
◼ <<send>> - wysłanie sygnału do obiektu,
◼ <<create>> - utworzenie nowego obiektu,
◼ <<destroy>> - zniszczenie obiektu.
Komunikat
◼ Forma kontaktu pomiędzy obiektami, której
efektem ma być podjęcie przez docelowy
obiekt pewnej akcji.
◼ Otrzymanie komunikatu przez obiekt wiąże
się z wykonaniem przez niego jego
własnego kodu lub wysłaniem kolejnego
komunikatu do innego obiektu w celu
wykonania przez niego pewnej akcji:
 aktywacja obiektu
 tworzenie obiektu
 niszczenie obiektu.
Komunikaty – notacja
graficzna
◼ Komunikaty w UML są reprezentowane
przez strzałki łączące linie życia
poszczególnych obiektów.
◼ Każdy komunikat wewnątrz interakcji
opatrzony jest kolejnym numerem, co
pozwala na łatwe śledzenie jej przebiegu.
◼ Podstawowe komunikaty:
 wywołanie procedury,
 powrót z wywołania
 wywołanie asynchroniczne.
Diagram komunikacji - zasady
◼ Obiekty na diagramie komunikacji są umieszczone tak, aby łatwo
można było opisać ich relacje pomiędzy sobą.
◼ Komunikacje są przedstawiane za pomocą linii łączących obiekty,
natomiast przesyłane między obiektami komunikaty i dane są
umieszczane obok tych linii.
◼ Każdy komunikat jest opatrzony etykietą liczbową, wskazującą na
kolejność ich wysyłania.
◼ Etykieta ta ma postać liczb oddzielonych kropkami. W przypadku
rozdzielenia sterowania każdy krok powoduje dodanie do etykiet
kroków następnych kolejnych pól z liczbami, np. krok 2 powoduje
utworzenie kroków 2.1, 2.2 leżących bezpośrednio za nim. Krok 2.1
posiada kroki 2.1.1 i 2.1.2, itd.
◼ Nie mogą przekazać wielu informacji dotyczących interakcji, np.
bloków komunikatów. Prezentują rzeczywiste powiązania obiektów i
ich relacji, co może ułatwić zrozumienie interakcji.
Diagram komunikacji
Diagram komunikacji
Zasady tworzenia diagramu
komunikacji
1. Określ jakie obiekty wejdą w jego skład
2. Zdefiniuj związki pomiędzy nimi
3. Wprowadź symbole (opisy wraz ze strzałkami) komunikatów
zapisywane równolegle do linii asocjacji, bądź w poziomie
4. Grot strzałki wskazuje kierunek przepływu komunikatu
5. Nanieś numerację określającą kolejność komunikatów
6. W przypadku dużej ilości komunikatów płynących w tym
samym kierunku i pomiędzy tymi samymi obiektami
dozwolone jest używanie jednej strzałki z kilkoma etykietami.

Po zakończeniu tworzenia diagramu każdy komunikat musi

mieć numer swojej kolejności, nazwę operacji, oraz strzałkę
ustalającą kierunek przepływu.
Diagram interakcji

◼ Diagram interakcji.pdf
UML - Diagram stanów

Diagramy stanów stanowią graficzną

reprezentację
maszyn stanów
Diagram maszyny
stanowej
Maszyna stanów

◼ Określa:
 ciągi stanów przyjmowanych przez obiekt
w odpowiedzi na zdarzenia
zachodzące w czasie jego życia,
 reakcje obiektu na te zdarzenia.
Diagramy stanów (czasowe)

◼ Służą do modelowanie historii życia:

 Instancji klasy
 Przypadku użycia
 Całego systemu
◼ Reprezentują na osi czasu zmiany
dopuszczalnych stanów, jakie może
przyjmować uczestnik w interakcji
Diagram stanów
◼ Graficzne odzwierciedlenie dyskretnego
zachowania systemów stan-przejście
◼ Wykorzystuje 2 notacje – klasyczną i
zakładkową
◼ Podstawowe pojęcie:
 stan,
 przejście,
 stan początkowy,
 stan końcowy.
Podstawowe pojęcie maszyny
stanów (MS)
◼ Stan - okoliczność lub sytuacja w jakiej znajduje się obiekt w cyklu
swojego życia spełniając określony warunek, wykonując czynność
lub czekając na zdarzenie
◼ Przejście - (transition) relacja między dwoma stanami wskazująca,
że obiekt znajdujący się w pierwszym z nich wykona pewne akcje i
przejdzie do drugiego stanu, ilekroć będą spełnione określone
warunki
◼ Stan początkowy – (initial state) to zainicjowanie maszyny
stanowej. Reprezentuje obiekt w momencie jego utworzenia. Każdy
diagram stanu może zawierać tylko jeden taki stan. Do stanu
początkowego nie dochodzą żadne przejścia
◼ Stan końcowy – reprezentuje usunięcie obiektu z systemu. Stan ten
jest opcjonalny (nie wszystkie obiekty są usuwane), w systemie także
może występować wiele różnych stanów końcowych. Ze stanów
końcowych nie można przejść do innych stanów
Przejście, decyzja
◼ Przejście (transition) to
relacja pomiędzy dwoma
stanami wskazująca, że obiekt
znajdujący się w pierwszym
stanie wykona pewne akcje i
przejdzie do drugiego stanu.

◼ Decyzja (decision),
przedstawiająca wybór
pomiędzy dwiema wartościami
logicznymi pewnego
wyrażenia. Warto zauważyć,
że odpowiednio korzystając z
warunków przejść można
pominąć ten pseudostan,
jednak często jego użycie
zwiększa czytelność modelu.
Rozwidlenie (fork)
◼ pozwala na
rozdzielenie
wejściowego
przejścia na dwa
lub więcej przejść
wyjściowych do
różnych obszarów
współbieżnych,
stanów lub maszyn
stanowych.
 Węzeł (junction)

◼ Pozwala na złączenie wielu przejść wejściowych oraz

ich rozdzielenie na szereg przejść wyjściowych
◼ Jest on tzw. statycznym rozgałęzieniem warunkowym,
co oznacza, że realizacja przejść wejściowych nie
determinuje natychmiastowej realizacji przejść
wyjściowych. Szczególnymi przypadkami punktu
węzłowego są decyzja oraz złączenie.
Scalenie (join)

◼ Integruje kilka
przejść
wychodzących z
różnych
źródłowych
obszarów
współbieżnych,
stanów lub maszyn
stanowych.
Zaawansowane kategorie
maszyny stanowej

◼ sekcje symbolu graficznego stanu,

◼ klasyfikacja stanów,
◼ obszary współbieżne,
◼ pseudostany,
◼ rodzaje przejść,
◼ protokołowe maszyny stanowe,
◼ maszyny stanowe zachowania,
◼ zdarzenia.
Etapy procesu tworzenia
diagramu stanów
◼ określenie rodzaju tworzonej maszyny stanowej i
identyfikacja jej obiektów;
◼ zidentyfikowanie poszczególnych stanów maszyny
stanowej;
◼ określenie hierarchii stanów, podstanów oraz
obszarów współbieżnych;
◼ powiązanie stanów oraz ich podstanów przejściami;
◼ zastosowanie adekwatnych pseudostanów;
◼ opracowanie specyfikacji sekcji stanów i przejść
zgodnie z przyjętymi składniami.
Diagram stanów - faktura
Diagram stanów - e-mail
Diagram stanów - przykłady

◼ Aukcja - Diagram stanów_Aukcja.pdf

DC i SD we wzorcu mediatora
Quiz: Wskaż różnice

◼ Diagram przypadków użycia a diagram

aktywności
Przydatne informacje
◼ http://www.uml.org/ strona główna UML-a
organizacji OMG
 specyfikacja OMG dla UML
 specyfikacja języka OCL (formalne ograniczenia
w UML)
 kompletny zestaw artykułów opisujących
elementy UML 2.0 (ang.)
 opis najczęściej stosowanych diagramów UML
◼ Darmowe narzędzie – StarUML -
◼ https://staruml.io
Bibliografia
◼ S. Wrycza, B. Marcinkowski, K.
Wyrzykowski, ,,Język UML 2.0 w
modelowaniu systemów informatycznych'',
Helion, 2005
◼ P. Graessle, H. Baumann, P. Baumann,
,,UML 2.0 w akcji. Przewodnik oparty na
projektach'', Helion, 2006
◼ B.Bruegge, A.H.Dutoit „Inżynieria
oprogramowania z ujęciu obiektowym”,
Helion, 2005
Dziękuję za uwagę

Co było dziś na
wykładzie?
Pytania?
Quiz: Język OCL

◼ Co definiuje język OCL?

Ograniczenie OCL
◼ Jakiego typu i jakie wartości przyjmuje
ograniczenie w języku OCL
Tam i z powrotem

◼ Inżynieria postępująca
 WE – model
 WY - kod
◼ Inżynieria wsteczna / odwracająca
 WE – kod
 WY - model
Pora świętować

Dziękuję za uwagę

dr inż. Elżbieta Zamiar

ezamiar@wsb.gda.pl