Diagramy interakcji

Diagramy interakcji

• Diagram przebiegu i diagram kooperacji

– zwane diagramami interakcji

– to dwa z

pięciu diagramów UML służących do

modelowania dynamicznych aspektów

systemu.

• Diagram interakcji przedstawia interakcję

jako zbiór obiektów i związków między nimi,

w tym też komunikaty, jakie obiekty

przekazują między sobą.

• Diagram przebiegu

uwypukla kolejność

komunikatów w czasie

, a

diagram kooperacji

organizację strukturalną obiektów

wymieniających komunikaty

Diagramy interakcji

• Diagramy interakcji służą do modelowania

dynamicznych aspektów systemu.

Uwzględnia się na

nich konkretne prototypowe egzemplarze klas,

interfejsów, komponentów i węzłów, a także

komunikaty przekazywane między nimi

. Te wszystkie

byty są rozpatrywane w kontekście pewnego

scenariusza ilustrującego zachowanie systemu.

Diagramy interakcji mogą występować samodzielnie;

wtedy służą do obrazowania, specyfikowania,

tworzenia i dokumentowania dynamicznych

aspektów ustalonego zestawu obiektów. Mogą także

być użyte do modelowania jednego specyficznego

przepływu sterowania w przypadku użycia.

• Diagramy interakcji nadają się także do

wspomagania tworzenia systemu wykonywalnego z

zastosowaniem inżynierii do przodu i inżynierii

wstecz.

Diagramy interakcji

• Diagramy interakcji obrazuje interakcję jako zbiór

obiektów i związków między nimi, w tym też

komunikaty, jakie obiekty przekazują między sobą.

• Diagram przebiegu jest diagramem interakcji, na

którym

uwypukla się kolejność komunikatów w

czasie. Ma postać tabeli, w której obiekty ułożone są

wzdłuż osi X, a komunikaty wzdłuż osi Y,

uporządkowane według czasu ich wysyłania

• Diagram kooperacji jest diagramem interakcji, na

którym

uwypukla się związki strukturalne między

obiektami wysyłającymi i odbierającymi komunikaty.

Graficznie jest to zestaw wierzchołków i krawędzi

sd Dynamic View

k:Klient

PełnomocnikODBC

«object system»

:Transakcja

create

ustalAkcja(a, d, o)

nadajWartosc(d, 3.4)

nadajWartosc(a, "CO")

zatwierdzono

destroy

Diagram przebiegu

Diagram przebiegu pokazuje jak, w
zależności od czasu, przebiega
komunikowanie się danego obiektu z
innymi. Perspektywa ta zawiera
dodatkowy wymiar tj. czas.

Kluczowym elementem jest fakt, że
interakcja jest ciągiem zdarzeń
występujących w czasie w określonej
kolejności

– od początku do końca.

Diagram przebiegu

Diagramy przebiegu mają dwie cechy, które odróżniają je od

diagramów kooperacji.

Występują na nich linie życia obiektów – pionowe przerywane

kreski prezentujące czas istnienia obiektów. Większość obiektów z

diagramu interakcji żyje przez cały czas trwania interakcji.

Znajdują się one w górnej części diagramu, a ich linie życia biegną

od góry do dołu. Podczas interakcji mogą powstawać nowe

obiekty. Ich linie życia rozpoczynają się w chwili odebrania przez

nie komunikatu stereotypowego create. Pewne obiekty są

niszczone. Ich linie życia kończą się w chwili odebrania przez nie

komunikatu stereotypowanego jako destroy (ich śmierć jest

dodatkowo oznakowana wielką literą X).

Na tych diagramach jest uwzględniony ośrodek sterowania –

podłużny, cienki prostokąt reprezentujący okres wykonywania

jakiejś akcji osobiście albo z użyciem procedury podrzędnej. Górna

krawędź tego prostokąta znajduje się na tej samej wysokości co

początek akcji, a dolna – na wysokości zakończenia akcji.

Zagnieżdżenie sterowania (wynikające np. z zastosowania

rekurencji, wywołania własnej operacji, wywołania zwrotnego z

innego obiektu) jest przedstawione za pomocą innego ośrodka

sterowania, umieszczonego trochę na prawo od jego przodka

(głębokość zagnieżdżenia nie jest ograniczona).

Obiekty

• Obiekty są umieszczane na diagramie od

góry z lewej strony. Układamy je w

dowolny sposób, upraszczając diagram.

• Od każdego obiektu w dół biegnie linia

przerywana, nazywana linią życia obiektu.

Wąski prostokąt umieszczany wzdłuż niej

nazywany jest aktywacją.

• Aktywacja przedstawia wykonanie operacji

przez obiekt. Długość prostokąta aktywacji

określa czas jej trwania.

Komunikat

• Komunikat przesyłany między obiektami biegnie od linii

życia obiektu wysyłającego do linii życia obiektu

docelowego. Obiekt może też wysłać komunikat sam do

siebie – od swojej linii życia do swojej linii życia.

• Komunikat może być: prosty, synchroniczny lub

asynchroniczny. Komunikat prosty jest przekazaniem

sterowania od obiektu do obiektu. Jeśli jakiś obiekt wysyła

komunikat synchroniczny, oczekuje potem odpowiedzi na

ten komunikat i dopiero po jej otrzymaniu przechodzi do

dalszych własnych działań. Po wysłaniu komunikatu

asynchronicznego obiekt kontynuuje własne działania bez

oczekiwania na odpowiedź.

• Na diagramie przebiegu komunikat prosty jest oznaczany

strzałką z dwustronnym grotem otwartym, komunikat

synchroniczny – strzałką z dwustronnym grotem pełnym, a

komunikat asynchroniczny – strzałką z jednostronnym

grotem otwartym.

Komunikat

Komunikat wysyłany

do obiektu pewnej klasy

oznacza

żądanie wykonania jednej z metod tej

klasy

, jest więc wywołaniem pewnej metody.

Komunikat może być wysyłany przez system

zewnętrzny lub przez obiekt jednej z klas systemu.

W tym drugim wypadku komunikat jest wysyłany w

trakcie wykonywania jednej z metod klasy, która

jest nadawcą komunikatu. Samo wysłanie

komunikatu nie kończy realizacji metody, w ramach

której został on wysłany.

Wysłanie komunikatu może wiązać się z

przekazaniem pewnych danych wejściowych

do wywoływanej metody oraz pobraniem

danych wyjściowych tej metody

. Nazwa

komunikatu jest nazwą wywoływanej metody.

Czas

• Czas jest przedstawiany jako przesunięcie

względem osi pionowej. Odliczanie zaczyna
się od góry diagramu, a upływowi czasu
odpowiada przesunięcie w dół. Komunikat
znajdujący się wyżej jest wcześniejszy od
tego, który został umieszczony niżej.

• Diagram przebiegu jest dwuwymiarowy.

Obiekty są rozmieszczane od lewej do
prawej, zaś przesunięcia wzdłuż osi pionowej
z góry na dół odpowiada upływowi czasu.

Przykład – diagramu

przebiegu

• Diagram przebiegu obrazujący interakcję GUI –

graficzny interfejs użytkownika z innymi obiektami.

• Kolejność

– Załóżmy, że użytkownik naciska na klawiaturze jakiś

klawisz alfanumeryczny. Jeżeli korzysta z odpowiedniej

aplikacji, np. procesora tekstu, odpowiedni znak

alfanumeryczny natychmiast pojawi się na monitorze. Co

dzieje się za „kulisami” tego zdarzenia?

1 GUI informuje system operacyjny o naciśnięciu klawisza
2. System operacyjny informuje o tym CPU
3. System operacyjny uaktualnia GUI
4. CPU zawiadamia kartę graficzną
5. Karta graficzna wysyła komunikat do monitora
6. Monitor wyświetla znak alfanumeryczny na monitorze, co jest

odpowiedzią (komunikatem zwrotnym) dla użytkownika.

sd Dynamic View

Użytkownik

: GUI

: System

operacyjny

: CPU

: Karta graficzna

: Monitor

nacisnijKlawisz

odpowiedz

Ja widać, komunikaty są asynchroniczne: żaden element, oczekując na
odpowiedź nie wstrzymuje działania.

Przykład – diagramu

przebiegu

•

W przypadku użycia „Kup napój” aktorem jest użytkownik,

który chce kupić puszkę napoju. Inicjuje scenariusz, wkładając

monetę do automatu. Potem dokonuje wyboru. Ponieważ

mówimy o najkorzystniejszym scenariuszu, w automacie jest

przynajmniej jedna puszka wybranego rodzaju , która zostaje

wydana aktorowi.

•

Załóżmy, że w automacie możemy wyróżnić trzy obiekty, na

których działaniu teraz się skupimy. Są to: przód (interfejs,

który automat udostępnia klientom), kasa (urządzenie

przyjmujące pieniądze) i podajnik (urządzenie przechowujące

puszki i wydające je klientowi). Załóżmy także, że kasa steruje

podajnikiem. Kolejność zdarzeń będzie następująca:

1. Kupujący wkłada pieniądze do otworu na przodzie automatu.
2. Kupujący dokonuje wyboru
3. Pieniądze przesuwają się do kasy.
4. Ponieważ jest to najkorzystniejszy scenariusz, zakładamy, że automat

ma w asortymencie puszkę wybranego napoju i kasa wyda

podajnikowi polecenie dostarczenia jej do otworu wylotowego.

sd Dynamic View

Użytkownik

: Przód

: Kasa

: Podajnik

wrzuc(Wplata)

wybierz(Wybor)

wyslij(Wplata, Wybor)

dostarcz(Wybor)

W związku z tym, że diagram przebiegu obrazuje tylko jeden
scenariusz (jeden egzemplarz) z przypadku użycia „Kup napój”,
nazywamy go egzemplarzowym diagramem przebiegu.

Diagram interakcji

• Diagram interakcji przedstawia

pewien scenariusz

przepływu komunikatów pomiędzy obiektami

systemu oraz systemami zewnętrznymi

. Opisują

one

sposób w jaki obiekty współpracują ze

sobą w celu zrealizowania funkcji systemu

Diagram interakcji tworzy się więc dla pewnej funkcji

systemu (niekoniecznie elementarnej). Diagram

interakcji może też opisywać sposób realizacji

pewnej złożonej metody, która wymaga wywołania

metod z innych obiektów.

• Diagram interakcji prezentuje potencjalny scenariusz

przepływu komunikatów. W konkretnej sytuacji

pewne komunikaty mogą nie być wysyłane.

Istota interakcji

 Obiekty nie pozostają bezczynne i wzajemnie na siebie

oddziałują

 Klasy i obiekty muszą się ze sobą komunikować
 To wzajemne oddziaływanie określa się mianem interakcji
 Interakcja ma postać wymiany szeregu komunikatów
 Każda interakcja odbywa się w określonym celu
 Każda interakcja zamyka się w ramach pewnego podzbioru

klas i obiektów

Definicje



Interakcja

to zachowanie polegające na wymianie

komunikatów pomiędzy obiektami w pewnym otoczeniu, w
pewnym celu



Komunikat

to specyfikacja (opis) sposobu łączności miedzy

obiektami

Notacja

 W języku UML komunikat oznaczana jest na diagramach

symbolem strzałki nad którą występuje nazwa komunikatu z
podaniem listy parametrów

 Sposób korzystania z oznaczenia komunikatu zależy od

rodzaju diagramu

 Interakcje (zbiory komunikatów) mogą wystąpić na

diagramach

Przypadków użycia
Kooperacji
Przebiegu
Stanów
Czynności

 Najważniejszymi diagramami służącymi do modelowania

interakcji są diagramy

Kooperacji
Przebiegu

Notacja (na przykładzie)

przykład: Interakcja związana z operacją wyświetlenia listy studentów w oknie
edytora.

W interakcji biorą udział trzy obiekty

1) obiekt klasy Edytor Danych o Studentach

reprezentuje formatkę ekranową służącą do wyświetlania i edycji danych o
studentach

2) obiekt klasy Kartoteka Studentów

reprezentuje klasę zapewniającą obsługę zbioru danych o studentach
pozwala na odczytywanie, edycję, zapisywanie i usuwanie rekordów z bazy
danych

3) obiekt klasy Student

reprezentuje pojedynczego Studenta

Dodatkowo w przykładzie występują dwie tzw. klasy projektowe (Rekord i Paczka),
które w tym przypadku służą do przekazywania danych pomiędzy obiektami.

Rodzaje komunikatów

 Znaczenie słowa "komunikat" należy traktować umownie
 Komunikat jako forma oddziaływania może przybierać różne

formy

 Do podstawowych form komunikacji należą:

 Wywołanie operacji (Call)
 Przekazanie wartości (Return)
 Przesłanie sygnału (Send)
 Utworzenia obiektu (Create)
 Zniszczenia obiektu (Destroy)

Rodzaje komunikatów

 Wywołanie operacji (Call)

Następuje wywołanie operacji na obiekcie docelowym.
Obiekt może wysłać komunikat sam do siebie, wówczas ma miejsce
wywołanie lokalne.

 Przekazanie wartości (Return)

Podczas tej akcji dochodzi do przekazania wartości do obiektu
wywołującego.

 Przesłanie sygnału (Send)

Ma miejsce przekazanie sygnału do obiektu. Sygnał jest dowolnym
asynchronicznym bytem przekazywanym między obiektami.

 Utworzenia obiektu (Create)

W trakcie takiej interakcji dochodzi do utworzenia nowego obiektu.

 Zniszczenia obiektu (Destroy)

Interakcja polega na zniszczeniu obiektu. Obiekt też może zniszczyć
się sam.

Sygnały

 Specyficznym rodzajem komunikatu jest sygnał



Sygnał

to asynchroniczny bodziec przekazywany pomiędzy

obiektami



Sygnał

jest nazwanym obiektem, który jest asynchronicznie

wysyłany (rzucany) i asynchronicznie odbierany
(wychwytywany) przez inny obiekt

 Przykłady:

 Umieszczenie w kolejce komunikatów systemu Windows

skierowanego do określonego okna

 Uruchomienie obsługi wyjątku w języku c++

Przykład

• W sytuacji przedstawionej na rysunku klasa Rysunek nie

wyśle komunikatu do klasy Figura, jeżeli rysunek jest pusty.

Diagram interakcji nie zawiera też informacji o tym czy

dany komunikat jest wysłany tylko raz czy wielokrotnie.

• Warto zwrócić uwagę na dwa podstawowe błędy popełniane

przy tworzeniu diagramów interakcji. Pierwszy z tych

błędów polega na traktowaniu komunikatu jako przepływu

danych (Egzaminator po przeprowadzeniu egzaminu zwraca

wyniki egzaminu. Są to jednak dane wyjściowe metody

Egzaminuj). Przykład kolejnego błędu, który może pojawić

się w tej samej sytuacji, pokazany jest na rys. (Komunikat

Koniec egzaminu został błędnie wprowadzony po to, aby

zobrazować fakt, że po zakończeniu metody Egzaminuj

klasy Egzaminator dalsze operacje wykonywane są przez

klasę Uczelnia. Symbol komunikatu użyto więc dla

przedstawienia zdarzenia polegającego na

Znaczenie diagramów interakcji



Diagramy interakcji

przedstawiają interakcję jako zbiór

obiektów i związków między nimi oraz komunikatów, jakie
obiekty przekazują między sobą.

 Do diagramów interakcji należą (przedstawione już we

wcześniejszych przykładach):

 diagramy przebiegu,
 diagramy kooperacji.

 Diagram przebiegu uwypukla kolejność komunikatów w czasie
 Diagram kooperacji uwypukla organizację strukturalną

obiektów wymieniających komunikaty.

Modelowanie dynamiki

systemu

• Model przypadków użycia wymienia różne sposoby

zachowania się systemu w stosunku do jego

użytkowników.

• Model klas lub model komponentów określa

statyczne zależności między elementami całego

systemu lub jednego z podsystemów.

• Elementem łączącym obydwa modele jest model

interakcji.

• Dzięki diagramom interakcji można zachować

ścisłą relację między dwoma podstawowymi

modelami. Są one spoiwem, dzięki któremu

możliwy jest stopniowa, równoległa rozbudowa

modelu systemu.

Obiekty – elementy modelu

dynamicznego

• Obiekt jest elementem istniejącym

podczas wykonywania się programu.
Stan obiektu przechowywany jest w
pamięci.

• Notacja obiektów: prostokąt z nazwą

obiektu i nazwą klasy. Nazwa obiektu
jest podkreślona dla odróżnienia od
nazwy klasy.

Dynamika: konstrukcja

obiektów

• Konstrukcja obiektu wykonywana jest

podczas jego tworzenia.

• Konstrukcja polega na nadaniu wartości

atrybutom obiektu, na utworzeniu

obiektów agregowanych oraz na

powiązaniu obiektu z innymi obiektami.

• Konstrukcja obiektu może przebiegać na

różne sposoby – w zależności od życzenia

klienta. Klasa może zatem dostarczać kilku

różnych metod konstrukcji.

Dynamika zmiany stanu

podczas życia obiektu

• Po wyprodukowaniu, obiekt ma zainicjowaną

strukturę danych – znajduje się w stanie

początkowym.

• Podczas swego życia, obiekt podlega

zmianom stanu. Zmieniają się wartości

atrybutów oraz powiązania z innymi

obiektami. Elementy składowe obiektu

(agregowane) mogą być tworzone i niszczone.

• Wszystkie możliwe zmiany stanu obiektu

określają jego dynamikę.

• Zmiany stanu obiektu powinny być

realizowane przez wąski interfejs.

Dynamika: zmiana związków z

innymi obiektami

• Podczas swego życia, obiekt może mieć związek z

różnymi obiektami. Wszystkie możliwe związki i

ich krotności uwzględnione są na diagramie klas.

• Powiązania z innymi obiektami mogą się zmieniać

w sposób dynamiczny. Obiekt w pewnym

momencie może być np. związany z dwoma, a w

innym momencie – z pięcioma obiektami

składowymi.

• Zmiana powiązania następuje w wyniku

wywołania metody, która usuwa je lub tworzy

powiązanie z obiektem podanym np. jako

parametr.

Opis dynamiki systemu –

diagramy interakcji

• Język UML umożliwia prezentację

dynamiki działania systemu. Służą

temu diagramy interakcji.

• Diagramy sekwencji przedstawiają

wprost kolejność przesyłania

komunikatów między obiektami.

Diagramy współpracy większy nacisk

niż na porządek komunikatów kładą

na fakt ich wymiany pomiędzy

obiektami.

sd Use Case View

s : Samochod

: Symulator

: Kolo

1. Przemaluj

2. sprawdzKolo

3. jakieCisnienie()

Co to jest diagram

sekwencji?

• Prezentacja komunikacji pomiędzy obiektami klas

współpracującymi przy realizacji przypadku użycia.

• Komunikacja jest inicjowana przez aktora.
• Na diagramie widać kolejność (z góry na dół)

przekazywanych komunikatów rozpoczynających

wykonywanie przez obiekty stosownych operacji.

• Z reguły prezentowany jest tylko jeden scenariusz,

ale standard notacji UML dopuszcza stosowanie

warunków.

• Diagram sekwencji ściśle wiąże się z konkretnym

scenariuszem. Zazwyczaj tworzy się po jednym

diagramie sekwencji dla każdego scenariusza

Utrzymywanie spójności

modelu i kodu

• Dobra zasada: wszelkie modyfikacje

atrybutów, nazw i sygnatur metod

dokonywane są tylko w modelu graficznym,

nie w kodzie.

• Po zmianie jednego z elementów opisu klasy

generowany jest kod. Współczesne narzędzia

CASE umożliwiają zachowanie kodu pisanego

w ramach środowiska deweloperskiego.

• Praca programisty-projektanta: jednoczesna

budowa modelu klas, modelu interakcji i

pisanie kodu.

Klasy, obiekty, komunikaty –

jak wyprodukować kod?

• Na projekt systemu składają się model klas i model

interakcji (diagramy sekwencji). Wszystkie elementy

tych modeli mogą być bezpośrednio lub pośrednio

przełożone na kod.

• Klasa projektowa  szkielet kodu klasy

– Wszystkie atrybuty, operacje, sygnatury operacji są

bezpośrednio realizowane w kodzie.

• Obiekt  zmienna lokalna operacji lub atrybut klasy

– Każdy nazwany obiekt na diagramie sekwencji może być

zadeklarowany w kodzie operacji jako zmienna lokalna

• Komunikat  zawsze odpowiada operacji klasy obiektu

– Wykonanie operacji w wyniku przesłania komunikatu znajduje

odzwierciedlenie w kodzie tej operacji dla odpowiedniej klasy

Diagramy sekwencji

(przebiegu)

• Diagramy sekwencji ułatwiają

tworzenie kodu operacji. Kod operacji
stanowi podsumowanie treści
wszystkich diagramów sekwencji, na
których występuje odpowiedni
komunikat.

• Rolą programisty jest umiejętne

połączenie w kodzie wszystkich
możliwych wywołań operacji.

Diagramy interakcji

• Oprócz modelowania struktury systemu, bardzo

ważne jest pokazanie systemu w działaniu (jego

dynamiki).

• Każdy scenariusz i każda usługa (operacja) mogą

być zrealizowane przy pomocy graficznego zapisu

interakcji między obiektami w działającym

systemie.

• Język UML dostarcza dwóch rodzajów diagramów

do modelowania dynamiki systemów – diagramy

sekwencji i diagramy współpracy.

• Diagramy interakcji stanowią ogniwo pośrednie na

drodze od przypadków użycia do interfejsów oraz

od definicji usług do klas.

Rady i wskazówki

• Dobrze zbudowany diagram interakcji:

– Uwypukla jeden dynamiczny aspekt systemu

– Obrazuje tylko te byty, które są niezbędne do zrozumienia tego

aspektu

– Uwzględnia szczegóły odpowiednie do przyjętego poziomu abstrakcji, z

dodatkami, które są niezbędne do zrozumienia tego, na czym Ci zależy

– Nie jest zbyt ogólny, a zatem czytelnik nie zostanie wprowadzony w

błąd co do istotnego znaczenia

• Gdy rysujesz diagram interakcji

– Nadaj mu nazwę, która określa jego przeznaczenie

– Wybierz diagram przebiegu, jeśli chcesz uwypuklić kolejność

komunikatów w czasie, a diagram kooperacji, jeśli chcesz

zaakcentować związki strukturalne między obiektami uczestniczącymi

w interakcji

– Tak ułóż elementy, żeby zminimalizować liczbę przecinających się linii

– Skorzystaj z notatek i kolorów, żeby zwrócić uwagę czytelnika na to na

czym Ci zależy

– Rozważnie korzystaj z rozgałęzień; w wypadku złożonych rozgałęzień

lepiej użyj diagramu czynności.

Document Outline