Diagramy interakcji: diagramy sekwencji i komunikacji

Diagramy interakcji:

diagramy sekwencji i komunikacji

Halina Tańska

Unified Modeling Language

Diagramy struktury:

• diagram klas (class diagram)

• diagram obiektów (object diagram)

• diagram komponentów (component diagram)

• diagram pakietów (package diagram)

• diagram wdrożenia (deployment diagram)

• zbiorowy diagram

komponentów (composite structure diagram)

Diagramy dynamiki:

• diagram przypadków użycia (use case diagram)

• diagram czynności (activity diagram)

• diagram maszyny stanów (state machine diagram)

• diagram sekwencji (sequence diagram)

• diagram komunikacji

(communication diagram)

• diagram przeglądu

współdziałania (interaction overview diagram)

• diagram czasowy (timing

diagram)

Diagramy sekwencji – diagramy interakcji

• Diagram sekwencji i diagram komunikacji – 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 sekwencji uwypukla kolejność

komunikatów w czasie, a diagram komunikacji

(kooperacji) organizację strukturalną obiektów

wymieniających komunikaty.

Diagramy interakcji (cd)

• 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 (cd)

• 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 sekwencji (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 komunikacji (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 p:

PełnomocnikODBC

«object system»

:Transakcja

create

ustalAkcja(a, d, o)

nadajWartosc(d, 3.4) nadajWartosc(a, "CO")

zatwierdzono destroy

Przykład diagramu sekwencji

Diagram sekwencji (przebiegu)

Diagram sekwencji (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 sekwencji (przebiegu)

• Diagram sekwencji (przebiegu) składa się z:

– obiektów przedstawionych w postaci standardowych prostokątnych ikon (z podkreślonymi nazwami),

– komunikatów (pokazanych jako linie ciągłe z grotami strzałek)

– czasu (pokazanego jako przesunięcie wzdłuż

pionowej osi).

Diagram sekwencji (przebiegu)

1. 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).

2. 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).

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

Linia życia

• Linia życia to rola uczestnika interakcji, jaką pełni w czasie jej trwania.

• Linia życia reprezentuje współuczestnika

interakcji i czas jego istnienia podczas realizacji scenariusza

• Linie życia reprezentują konkretne byty – obiekty systemu i mogą przyjmować stereotypy, które

świadczą o roli, jaką pełni dany obiekt w

systemie.

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 sekwencji (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.

Komunikat

• Komunikat (ang. Message) jest to informacja przesyłana pomiędzy obiektami.

• Istnieją różne typy komunikatów:

– Synchroniczny oznacza, że obiekt musi czekać na odpowiedź

– Asynchroniczny – nie wymaga oczekiwania na odpowiedź – Wewnętrzny, który obiekt wysyła sam do siebie

– Kreujący – tworzy nowy obiekt

– Destrukcyjny, który usuwa inny obiekt

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 sekwencji (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.

Fragment

• Fragment (ang. Combined Fragment) to konceptualnie zamknięta całość diagramu sekwencji, która rozszerza możliwości

obejmowanego przez siebie obszaru diagramu sekwencji.

• Fragment może zawierać w sobie pętle,

powtórzenia, scenariusze alternatywne lub

wskazywać poziom abstrakcji modelowanego fragmentu systemu.

• Rodzaj fragmentu jest określany poprzez

umieszczenie odpowiedniego słowa kluczowego

w lewym górnym rogu.

Fragment

Słowo

kluczowe opis

alt Dzieli fragment interakcji zgodnie z warunkami logiki boola na dwa alternatywne scenariusze; każda z alternatyw musi posiadać warunek dozoru, którego spełnienie warunkuje wypełnienie danej alternatywy assert Prezentuje fragment interakcji, który musi być wykonany zgodnie z

założonymi warunkami i komunikatami

break Wskazuje na fragment diagramu sekwencji, który realizowany jest po spełnieniu warunku dozoru; spełnienie warunku dozoru skutkuje

wykonaniem sekwencji komunikatów zawartych we fragmencie a

następnie wyjście ze scenariusza; w przypadku, gdy warunek dozoru nie jest spełnionykomunikaty zawarte we fragmencie są pomijane

consider wskazuje na fragment z listy nazw komunkiatów, które są

wyselekcjonowane w tej części interakcji; oznacza to, że mimo innych komunikatów, które znajdują się w danej częśi interakcji pokazane

zostaną tylko te, które są wylistowane za słowem kluczowym consider critical Wskazuje, że dany fragment diagramu sekwencji nie może być

przerwany przez inny proces

Fragment ( ^cd. )

Słowo

kluczowe opis

ignore Wskazuje, że w tym fragmencie interakcji znajdują się wiadomości, które zostały pominięte, gdyż ich widoczność nie zmienia zachowania systemu;

zignorowane wiadomości są wylistowane po słowie ignore

loop Powtórzenie fragment interakcji określoną warunkiem liczbę razy neg Fragment prezentujący jedną lub więcej wiadomości, które są

prawdopodobnie nieprawidłowe

opt Wskazuje na opcjonalny fragment z interakcji; który jest wykonywany po spełnieniu warunku dozoru

par Prezentuje równoległe wykonywanie przepływu wiadomości

seg Wskazuje słabo uszczegółowiony fragment sekwencji, tzn. taki, który jest ogólny

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

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

Przykład – diagramu sekwencji

• 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)

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ę 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.

 Interakcje

 Diagramy interakcji

Podstawy modelowania zachowania

Interakcje

 Notacja

 Komunikaty

 Sygnały

 Komunikaty i relacja powiązania

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

Podstawowe 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 oznaczany 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

 Komunikacji (kooperacji)

 Sekwencji (przebiegu)

 Stanów

 Czynności

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

 Komunikacji (kooperacji)

 Sekwencji (przebiegu)

Notacja (na przykładzie)

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.

Interakcja związana z operacją

wyświetlenia listy studentów w oknie edytora

Notacja (na przykładzie)

Diagram klas dla rozpatrywanego przykładu

Notacja (na przykładzie)

Diagram przebiegu

komunikaty

Notacja (na przykładzie)

Diagram kooperacji

komunikaty

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 tej interakcji dochodzi do utworzenia nowego obiektu.

 Zniszczenia obiektu (Destroy)

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

Notacja (na przykładzie)

Diagram przebiegu uwzględniający różne znaczenia komunikatów

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++

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 sekwencji (przebiegu),

 diagramy komunikacji (kooperacji).

 Diagram sekwencji (przebiegu) uwypukla kolejność komunikatów w czasie

 Diagram Komunikacji (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 komunikacji (kooperacji, współpracy) większy nacisk niż na porządek

komunikatów kładą na fakt ich wymiany pomiędzy

obiektami.

sd Use Case View

: Symulator s : Samochód : Koło

przemaluj

sprawdźKola

jakieCisnienie

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

Realizacja usług i metod klas

• Zestaw diagramów interakcji jest podstawą do określenia struktury komunikacji

(wywołań metod) między obiektami.

• Struktura ta powinna być odzwierciedlona w kodzie metod. Zadanie to należy do

programisty.

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.