background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 1

  

Projektowanie systemów 

informacyjnych

Ewa Stemposz 

Instytut Podstaw Informatyki PAN, 
Warszawa

Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa

Wykład 9

Model dynamiczny (1)

 Diagramy interakcji

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 2

Zagadnienia

Diagramy interakcji:

 Komunikaty: składnia, rodzaje

 Diagramy komunikacji

 Diagramy sekwencji

Generyczne diagramy interakcji:

Współbieżność na diagramach interakcji

 Wyrażanie warunków

 Wyrażanie iteracji

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 3

Diagramy interakcji

Diagramy interakcji: jeden z rodzajów diagramów dynamicznych; 
wykorzystywane do tworzenia opisów współdziałania elementów 
strukturalnych systemu (wystąpień klasyfikatorów) w trakcie realizacji 
zadania (np. przypadku użycia czy też jednego konkretnego scenariusza 
danego przypadku użycia). Interakcja oparta jest o przesyłanie 
komunikatów.
Narzędzia CASE  potrafią wykorzystać diagramy interakcji do 
generowania kodu.

UML 2.0 posiada cztery rodzaje diagramów interakcji: 

  diagramy komunikacji (ang. communication diagrams),
 diagramy sekwencji (ang. sequence diagrams) – izomorficzne z 
diagramami komunikacji,
  diagramy następstwa stanów (inna nazwa: diagramy 
harmonogramowania
) (ang. timing diagrams) – wykorzystywane do 
prezentowania na osi czasu następstwa stanów instancji 
klasyfikatora biorącego udział w interakcji, 
  diagramy przeglądu interakcji (inna nazwa: diagramy 
sterowania interakcją
) (ang. interaction overview diagrams) – 
wykorzystywane do przeglądu (naszkicowania, zarysu) przepływu 
sterowania wewnątrz grupy logicznie powiązanych diagramów.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 4

Adaptacja notacji BNF

=

struktura danych po lewej stronie symbolu = składa się z 

elementów wyspecyfikowanych po stronie prawej

+

odpowiada słowu “i”; wykorzystywane do agregowania 

elementów

[ … ]

definiowana struktura zawiera tylko jeden spośród 

elementów zawartych w nawiasach [ ]; kolejne elementy 

są oddzielane przecinkami

( … )

elementy zawarte w nawiasach ( ) są opcjonalne, co 

oznacza, że mają 0..1 wystąpień

{ … }

definiowana struktura zawiera od 0..* wystąpień 

elementu zawartego w nawiasach { }; kolejne 

wystąpienia są oddzielane przecinkami

* … *

informacje zawarte między * * są traktowane jak 

komentarz, a więc nie stanowią elementów składowych 

definiowanej struktury

Symbol

Znaczenie

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 5

Prezentowanie diagramów interakcji

sd Nazwa diagramu

sd – wyróżnik diagramu sekwencji 
(sequence diagram)

cd – wyróżnik diagramu komunikacji 
(communication diagram)

<nagłówek-diagramu> = (<wyróżnik_diagramu>) + <nazwa-diagramu> + {<parametr>}

cd Nazwa diagramu

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 6

Składnia komunikatu (1)

<komunikat> = (<poprzednik>) + (<wyrażenie_sekwencji>) + <sygnatura_operacji>

<poprzednik> = 
{<nr_obligatoryjnego_komunikatu_poprzedzającego>} + ”/”
                             Przykłady:   2.1/   
                                                 1.3, 1.4, 1.7/
<wyrażenie_sekwencji> =  ([<nr_komunikatu>, 
<nazwa_komunikatu>] + ”:”) +
                                              (<rekurencja>)

<rekurencja> = [<warunek>, <iteracja>]

<warunek> = ”[” {<specyfikacja_warunku>} ”]”
                          Przykłady:   [ocena > 4]    
                                              [ocena_zaliczeniowa >3, 
ocena_egzaminacyjna > 4]

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 7

Składnia komunikatu (2)

<iteracja> = [”*”, ”* [” <specyfikacja_iteracji> ”]”]

                      Przykłady:   *   
                                          * [i = 1..10]

<sygnatura_operacji> = (<atrybut> ”=”) + <nazwa_operacji> + 
                                          (”(” {<argument>} ”)”) + (”:” 
<wartość_zwracana>)

Wartość zwracana jest wykorzystywana tylko dla komunikatów 
zwrotnych i tylko łącznie ze specyfikacją atrybutu

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 8

Rodzaje komunikatów (1)

Rodzaj komunikatu

Notacja

Znaczenie

komunikat 
synchroniczny 
(ang. 
synchronous 
message)

“Normalna” proceduralna sytuacja. 
Nadawca zawiesza działanie, dopóki 
odbiorca nie zwróci  sterowania. 

komunikat
asynchroniczny
(ang. 
asynchronous 
message)

Nadawca komunikatu nie oczekuje na 
odpowiedź odbiorcy, ale też i nie kończy 
własnej aktywności, co oznacza, że nadal 
przetwarza i może wysyłać komunikaty.

komunikat 
zwrotny
(ang. return 
message)

Powrót oznacza nie tylko zakończenie 
komunikatu synchronicznego i 
przekazanie sterowania do nadawcy ale 
może być też związany z zainicjowaniem 
określonej operacji u nadawcy. 
Oznaczanie powrotu nie jest 
obligatoryjne.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 9

Rodzaje komunikatów (2)

Rodzaj komunikatu

Notacja

Znaczenie

komunikat
utracony 
(ang. lost 
message)

Wykorzystywany w modelowaniu 
złożonych interakcji, gdy na etapie 
początkowych prac znany jest nadawca 
komunikatu, natomiast nie jest znany jego 
odbiorca. Odbiorca zostanie 
zidentyfikowany na etapie późniejszym.

komunikat
znaleziony
(ang. found 
message)

Sytuacja podobna, jak powyżej, ale tu 
znany jest odbiorca komunikatu a 
nieznany nadawca.

komunikat
udaremniony 
(opcjonalny?)
(ang. balking 
message)

Nadawca oczekuje bezzwłocznego 
wykonania komunikatu. Jeśli odbiorca nie 
jest gotowy, wtedy komunikat nie jest 
realizowany, a nadawca nie podejmuje 
ponownych prób jego przesłania.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 10

Rodzaje komunikatów (3)

Rodzaj komunikatu

Notacja

Znaczenie

komunikat
oczekujący
(ang.timeout
message)

Nadawca jest w stanie czekać przez 
pewien okres czasu na zrealizowanie 
komunikatu przez odbiorcę. Po upłynięciu 
tego czasu, o ile komunikat nie został 
zrealizowany, nadawca rezygnuje z 
interakcji.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 11

Diagramy komunikacji; przykład

Prosty diagram komunikacji, bez uwidaczniania interakcji między 
obiektami, stanowi coś w rodzaju “wystąpienia fragmentu diagramu 
klas”; pokazuje aktora, relewantne obiekty i powiązania między nimi. 
Możliwe jest pokazanie więcej niż jednego obiektu danej klasy.

Diagram komunikacji pokazuje w jaki sposób system realizuje dany 
przypadek użycia. Współpracujące obiekty, połączone liniami 
nazywanymi “linkami. Linki odpowiadają powiązaniom, czyli 
wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia 
asocjacja musi (?) istnieć na diagramie klas.

:Personel

bibl.

:Członek

bibl.

:Książka

:Egzemplarz 

książki

Można tu pokazywać też
informacje w rodzaju:
 nazwy linków, 

 kierunki nawigowania,

 itd., jak na diagramie klas 
pod warunkiem, że 
zwiększą, a nie zmniejszą 
czytelność diagramu.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 12

Interakcja na diagramach komunikacji 

(1)

Komunikaty przedstawiane są tu w postaci etykiet strzałek rysowanych 
wzdłuż linków między współpracującymi obiektami. 

Diagramy komunikacji mogą dodatkowo pokazywać interakcje 
zachodzące między obiektami zaangażowanymi w realizację danego 
przypadku użycia. Sekwencja interakcji oznacza tu sekwencję 
komunikatów przesyłanych między współpracującymi obiektami.

:Personel

bibl.

:Członek

bibl.

:Książka

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

komunikat wysyłany
od aktora do obiektu
klasy Członek bibl.

Możliwe scenariusze:
     
1) nie można pożyczyć
     2) można pożyczyć ale książka jest niedostępna

  3) można pożyczyć, książka jest, trzeba 
      zarejestrować wypożyczenie

4: Zaznacz wypożyczenie

3: Czy wolny

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 13

Interakcja na diagramach komunikacji 

(2)

Komunikaty mogą być numerowane, albo kolejnymi liczbami 
naturalnymi (jak na poprzednim diagramie), albo stosując tzw. 
numerację zagnieżdżoną. W obu przypadkach, z reguły nie bierze się 
pod uwagę komunikatu wysyłanego od aktora.

:Personel

bibl.

:Członek

bibl.

:Książka

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.2: Zaznacz wypożyczenie
2.1: Czy wolny

Numeracja zagnieżdżona oznacza, że jeśli obiekt o otrzyma 
komunikat m o numerze np. 7.3 to ten numer będzie dołączany jako 
prefix do każdego komunikatu wysyłanego w trakcie realizacji 
komunikatu m przez obiekt o.

agregowanie 
operacji z 
uwzględnieniem 
kierunku interakcji i 
rodzaju komunikatu

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 14

Obiekty wielokrotne

:Personel

bibl.

1: Podaj ilość wypożyczeń

:Członek

bibl.

Obiekty wielokrotne (ang. multiple objects): Pojedyncza 
instancja klasyfikatora może przesłać komunikat do wszystkich 
obiektów danej klasy. Oznaczenie komunikatu symbolem iteracji 
(*) byłoby w tym przypadku nadmiarowe.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 15

Klasyfikatory aktywne

Klasyfikatory aktywne: 

 instancje klasyfikatora są zdolne do inicjowania wątku – 
poprzez wysłanie pierwszego komunikatu w ciągu 
komunikatów zagnieżdżonych,
 instancje klasyfikatora są zdolne do samodzielnego 
inicjowania wysyłania komunikatów w określonych odcinkach 
czasu,
 instancje klasyfikatora mogą prowadzić obliczenia na 
podstawie danych przechowywanych w instancjach innych 
klasyfikatorów.

Przykład instancji klasyfikatora aktywnego:

:NazwaKlasy

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 16

Przykład interakcji komunikatów w 

Javie (1)

:Personel

bibl.

: EgzemplarzKsiążki

1.1: czyMożnaPożyczyć ()

1.2: pożycz (tytuł, członekBibl)

1.2.2: zaznaczWypożyczenie
       (członekBibl)
1.2.1: czyWolny ()

1.3: zaznaczWypożyczenie (egzemplarzKsiążki)

Dla implementacji w języku obiektowym (np. w Javie), przypadek użycia 
“pożycz egzemplarz książki” mógłby być zrealizowany poprzez 
sekwencję komunikatów, jak na poniższym diagramie (bez usuwania 
polskich znaków diakrytycznych). W Javie, metody klasowe mogłyby być 
implementowane za pośrednictwem np. metod statycznych.

:CzłonekBibl

?

1: pożycz (daneOsobowe, tytuł)

: Książka

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 17

Przykład interakcji komunikatów w 

Javie (2)

Diagram klas, zgodny z diagramem komunikacji jak na poprzedniej 
folii, wyglądałby jak poniżej. 

CzłonekBibl

pożycz (daneOsobowe, tytuł)
czyMożnaPożyczyć ()
zaznaczWypożyczenie (egzemplarzKsiążki)

Książka

pożycz (tytuł, członekBibl)

pożyczył

*

0..1

EgzemplarzKsiążki

czyWolny ()
zaznaczWypożyczenie 
(członekBibl)

1..*

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 18

Diagramy sekwencji – notacja 

podstawowa (1)

Diagramy sekwencji nie pokazują linków między współpracującymi obiektami, ale można to
wydedukować w oparciu o zaznaczone komunikaty.

Kolejność  obiektów  nie  ma  tu  znaczenia,  ale  warto  zadbać  o 
czytelność diagramu.

:Personel

bibl.

:Książka

:Członek

bibl.

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

czas

linia życia 

głowa
linii życia 

czas życia 

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 19

Diagramy sekwencji – notacja 

podstawowa (2)

:Personel

bibl.

:Książka

:Członek

bibl.

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

aktywne

życie obiektu

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 20

Ilustracja przekazywania sterowania

:Personel

bibl.

:Książka

:Członek

bibl.

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

Na diagramach sekwencji, wyraźniej niż na diagramach komunikacji, można pokazać 
przekazywanie sterowania.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 21

Nakładanie ograniczeń na przepływ 

czasu (1)

:Sterowanie

:Dzwoniący

:Odbierający

podniesienie słuchawki

ton w słuchawce

wybór cyfry

łączen
ie

ton dzwonka

uruchomienie dzwonka

podniesienie słuchawki

koniec tonu

koniec dzwonienia

.
.
.

a

b

c

d

d’

{b - a < 1 sec.}

{c - b < 10 sec.}

Rozmowa 
jest łączona 
poprzez sieć
{d’ - d < 5 sec.}

Główna przewaga diagramów sekwencji nad diagramami komunikacji 
przejawia się w ich  zdolności do graficznego prezentowania upływu 
czasu, a nawet do podawania ograniczeń  czasowych, czy też – co 
może być kontrowersyjne – skali czasowej. Taka możliwość  może mieć 
duże znaczenie dla opisu systemów czasu rzeczywistego.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 22

Nakładanie ograniczeń na przepływ 

czasu (2)

:Personel

bibl.

:Książka

:Członek

bibl.

:Egzemplarz 

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

A

C

{C-A < 5 sek.}

{ Zaznacz wypożyczenie -
  Czy tytuł dostępny  < 1 sek.}

gdy interesuje nas czas

przesłania komunikatu

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 23

Wartości zwracane; tworzenie, 

usuwanie obiektów 

Czasami przydaje się uwidocznienie wartości zwracanej przez 
komunikat, poprzez instrukcję przypisania. Umożliwia to późniejsze 
wykorzystanie tej wartości, np. jako argumentu dla innego komunikatu. 
Wartość zwracana może też być wykorzystana do specyfikowania 
warunku czy iteracji.

:Sekretariat

ds.  nauczania

:Wykładowca

n = pobierzNazwisko

:Szef 

wykładowców

«create»

 

utwórzSzefaWykładowców (n)

«destroy»

 

usuńWykładowcę

X

koniec życia
obiektu

nowy obiekt pojawia 
się na diagramie w 
miejscu 
korespondującym z 
czasem jego 
utworzenia

Wykładowca

Szef

wykładowców

diagram sekwencji

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 24

Wartości zwracane; tworzenie, 

usuwanie obiektów

Projekt musi specyfikować, kto jest odpowiedzialny za usuwanie 
obiektów
, aby zapobiec tzw. “wyciekaniu pamięci”. Niektóre języki, 
takie jak np.Java czy SmallTalk, posiadają wbudowane mechanizmy 
zbierania nieużytków (ang. garbage collectors). Z grubsza, polega to na 
usuwaniu (w jakimś czasie) wszystkich obiektów, do których nie ma 
żadnych referencji w systemie.

:Sekretariat

ds. nauczania

:Szef

wykładowców

[nowy]

:Wykładowca

[usuwany]

«create»

 

2: utwórzSzefaWykładowców (n)

1: n = pobierzNazwisko

«destroy»

 

3: usuńWykładowcę

Komunikaty wysyłane od aktora są tu numerowane,
aby można było ustalić ich kolejność.

diagram komunikacji

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 25

Generyczne diagramy interakcji (1)

W UML, generyczny diagram interakcji powinien specyfikować 
wszystkie możliwe sekwencje interakcji dla danego przypadku użycia, a 
nie tylko dla jednego ze scenariuszy. Diagram dla pojedynczego 
scenariusza jest tu nazywany wystąpieniem generycznego diagramu 
interakcji. Ponieważ diagramy generyczne mogą w niektórych 
przypadkach okazać się zbyt złożone, dopuszcza się rozwiązania 
połowiczne.

Przedstawianie zachowań warunkowych

Wysłanie komunikatu może być uzależnione od spełnienia wyspecyfikowanego warunku. 

:K

[i = 0] x

[i = 1] y

:K

[i = 0] x

[i = 1] y

Możliwe są wszystkie kombinacje.

Może być wysłany albo komunikat x albo
y. Może też nie być wysłany żaden z nich.

ten sam punkt 
w czasie

dwa różne punkty
w czasie

{dla interakcji 
synchronicznej 
warunki muszą 
się wykluczać}

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 26

Generyczne diagramy interakcji (2)

Warunek,  zapisany  wewnątrz  nawiasów  [  ],  stanowi  wyrażenie  typu 
Boolean  i  może  być    wyrażony  w  języku  naturalnym,  w  języku 
ustrukturalizowanym  (np.  OCL),  w  języku    programowania, 
pseudokodzie czy innej notacji.

:K1

7.1: [i = 0] x

7.2: [i = 1] y

:K2

Linia życia dla wystąpienia klasy K2 uległa
rozgałęzieniu, aby podkreślić fakt, że stan obiektu
może wyglądać inaczej w zależności od tego, który
z komunikatów (x czy y) zostanie wysłany.

Budzi wątpliwości numeracja komunikatów, bo może wykonać się tylko jeden z nich. Być może 
oba powinny być oznaczone przez 7.1

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 27

Generyczne diagramy interakcji (3)

Przedstawianie iteracji

UML umożliwia oznaczenie komunikatu, który ma być wysłany wiele razy, 
poprzez  poprzedzenie go symbolem * (dla iteracji współbieżnej używany 
jest symbol *//). Oczywiście musi być też wyspecyfikowany warunek, 
określający zakończenie iteracji. UML nie narzuca formy warunku. 

Przykłady iteracji:

*[i = 1..10] – komunikat będzie wysłany 10 razy,
*[x  < 10] – komunikat będzie wysyłany dopóki x będzie < 10,
*[pozycja nie znaleziona] – komunikat będzie wysyłany dopóty, dopóki 
pozycja  nie  zostanie  znaleziona,  czyli  do  momentu,  gdy  warunek 
przyjmie wartość FALSE.

Jeśli w trakcie wielokrotnego wysyłania komunikatu x, będzie wysyłany 
także komunikat y, to zostanie on wysłany tyle razy, ile razy wysyłane jest 
x. W takim wypadku, dla zachowania spójności diagramów nie należy 
powtarzać symbolu iteracji przed komunikatem y.

Wyrażanie warunków na diagramach komunikacji jest także możliwe. 
Nie da się tu jednak pokazać rozgałęzienia linii życia obiektu. Wydaje 
się, że poza najprostszymi  sytuacjami, diagramy sekwencyjne lepiej 
modelują realizację bardziej złożonych (z opcjonalnymi scenariuszami) 
przypadków użycia.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 28

Generyczne diagramy interakcji (4)

:K2

:K3

3.1: *[i = 1..2] x

3.1.1: y

:K2

:K3

:K1

:K1

3.1: *[i = 1..2] x

3.1.1: *[j = 1..3] y

xyxy

xyyyxyyy

sekwencja
komunikatów

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 29

Generyczny diagram interakcji dla Javy 

(1)

:Personel

bibl.

: Książka

EgzemplarzKsią

żki

1.1: można = czyMożnaPożyczyć ()

1.2: [można] egzemplarzKsiążki = pożycz (tytuł, członekBibl)

1.2.2:   [wolny] zaznaczWypożyczenie (członekBibl)
1.2.1: *[poprz. egz. zajęty i nie koniec przeglądania] 
wolny = czyWolny ()

:CzłonekBibl.

?

Dla implementacji w Javie przypadku użycia “pożycz egzemplarz 
książki”, generyczny diagram interakcji mógłby wyglądać następująco: 

1: pożycz (daneOsobowe, tytuł)

1.3: [znaleziono wolny egzemplarz] 
zaznaczWypożyczenie (egzemplarzKsiążki)

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 30

Generyczny diagram interakcji dla Javy 

(2)

CzłonekBibl

pożycz (daneOsobowe, tytuł)
czyMożnaPożyczyć : Boolean
zaznaczWypożyczenie (egzemplarzKsiążki)

Książka

pożycz (tytuł, członekBibl) : EgzemplarzKsiążki

pożyczył

*

0..1

EgzemplarzKsiążki

czyWolny : Boolean
zaznaczWypożyczenie 
(członekBibl)

1..*

Diagram klas, zgodny z diagramem komunikacji przedstawionym na 
poprzednim slajdzie, wyglądałby jak poniżej. 

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 31

Podstawowe rodzaje interakcji

Obiekt, adresat komunikatumusi go rozumieć, co oznacza, że klasa 
której jest wystąpieniem, musi dostarczyć tę operację
Konstruowanie diagramów interakcji może pomóc w identyfikowaniu 
zarówno
 metod w klasach, jak i asocjacji między klasami, a przez 
to może prowadzić do korekty diagramu klas, i temu celowi zresztą 
głównie służy. Jest oczywistym, że oba modele: obiektowy i dynamiczny 
muszą być spójne.

Rodzaje interakcji:

 Sekwencyjna (synchroniczna) – tylko jeden aktor może zainicjować 
sekwencję komunikatów i w danym momencie tylko jeden obiekt może 
“działać”. Obiekt  rozpoczyna tzw. aktywne życie” (staje się aktywny) 
w momencie otrzymania komunikatu. Zanim wyśle odpowiedź do 
nadawcy komunikatu, może prowadzić obliczenia czy też wysyłać 
komunikaty do innych obiektów. Wysyłając komunikat do innego obiektu 
nadal pozostaje aktywny, ale jego własna działalność zostaje zawieszona 
do czasu otrzymania odpowiedzi na wysłany komunikat, wysyłanie 
komunikatu zwiazane jest tu z przekazywaniem sterowania do odbiorcy 
komunikatu. W każdym momencie istnieje w systemie stos aktywnych 
obiektów
; na szczycie stosu znajduje się ten obiekt, który aktualnie 
“działa”. Wysłanie odpowiedzi na komunikat powoduje zdjęcie obiektu 
ze stosu.

  

 Współbieżna.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 32

Współbieżność na diagramach 

interakcji

Dla interakcji sekwencyjnych nadawca komunikatu oczekuje na 
odpowiedź odbiorcy  zawieszając własną działalność w trakcie 
oczekiwania. W danym momencie czasu działa tylko jeden obiekt i 
wysyłany może być tylko jeden komunikat. Takie systemy nazywane są 
też czasami proceduralnymi lub jednowątkowymi.

Prosta definicja systemu współbieżnego mówi: wiele obiektów 
może działać jednocześnie, wiele komunikatów może być 
wysyłanych w tym samym czasie
.

Do systemów współbieżnych możemy zaliczyć, np.:

  systemy  rozproszone  –  przetwarzanie  zachodzi  równocześnie  na 
wielu procesorach w różnych miejscach,

 wielowątkowe aplikacje – przetwarzanie równoległe na wielu 
procesorach lub na jednym procesorze z podziałem czasu.

Przetwarzanie współbieżne jest często mylone z przetwarzaniem w 
czasie rzeczywistym, ponieważ systemy czasu rzeczywistego są często 
współbieżne i vice versa. Jednakże idee leżące u podłoża obu rodzajów 
systemów są różne: system jednowątkowy może być systemem czasu 
rzeczywistego, podczas gdy współbieżny może takim systemem nie być. 
Dla systemu czasu rzeczywistego istotne jest wypełnianie ograniczeń 
czasowych.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 33

Modelowanie wielu wątków sterowania

Rozpoczęcie nowego wątku sterowania jest możliwe np. poprzez:

Rozdzielenie istniejącego wątku na kilka innych: Obiekt, który 
działa (bo otrzymał komunikat) może wysłać jednocześnie kilka 
synchronicznych komunikatów. Synchroniczność oznacza tu, że 
będzie oczekiwał na zakończenie wszystkich.
Na diagramie sekwencji byłoby to uwidocznione przez pokazanie 
komunikatów wysyłanych w tym samym punkcie czasowym, jak już 
było prezentowane  wcześniej, ale tym razem bez ograniczenia, że 
warunki muszą się wzajemnie wykluczać. 
Można używać nazw (pojedynczego znaku lub łańcucha znaków) 
na oznaczenie współbieżności komunikatów: np. 2.10.A jest 
współbieżne z 2.10.B dla aktywności spowodowanej wysłaniem 
komunikatu 2.10, w przeciwieństwie do 2.10.1 i 2.10.2, które 
oznaczają komunikaty nie współbieżne.

Aktor, może wysłać nowy komunikat w trakcie przetwarzania systemu. 

Obiekt może wysłać asynchroniczny komunikat do innego 
obiektu
. Oznacza to, że może uaktywnić inny obiekt nie 
zawieszając swojej własnej aktywności.

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 34

Przykład diagramu ze współbieżnością

:Personel

bibl.

:Członek

bibl.

Czy przetrzymuje

[jeśli przetrzymuje] email

:Książka

:Egzemplarz

książki

«create»

 

Rejestruj nową książkę

«create»
Rejestruj nowy

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 35

Law of Demeter (Prawo 

zdroworozsądkowe?)

Powszechnie stosowana reguła (Law of Demeter), określa do jakich 
obiektów mógłby  ewentualnie wysłać komunikat obiekt o w trakcie 
realizacji otrzymanego komunikatu m:

  do siebie samego,

  do obiektów stanowiących argumenty metody m,

  do obiektów, które tworzy w trakcie realizacji komunikatu m,

  do obiektów, z którymi jest bezpośrednio powiązany.
  Ponadto, obiekt mógłby wysłać komunikat, realizujący operację klasową.

KontrolerPracy

Praca

KontrolerWszystkiego

getKP(p:Praca) : KontrolerPracy

Przykład złego 
projektowania, które nie 
stosuje się do np. 
przedostatniej z ww. 
zasad.

*

1

1

*

1

*

background image

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, 
Wykład 9, Slajd 36

Podsumowanie diagramów interakcji

Diagramy interakcji, czyli diagramy komunikacji i sekwencji, jako główne 
zadanie mają wspomożenie projektanta w procesie konstruowania 
modelu obiektowego. Pomoc polega na analizie zachowania systemu w 
trakcie realizacji jego zadań i identyfikowaniu nowych czy też korekcie 
już istniejących elementów modelu, np.: klas, ich atrybutów, metod oraz 
asocjacji między klasami. 

   

Struktura, opisywana przez model obiektowy, musi zapewnić 
możliwość realizacji     zadań postawionych przed systemem.

 Diagramy komunikacji, stanowiące w pewnym sensie wystąpienia 
fragmentu diagramu klas, lepiej przedstawiają związki między obiektami 
biorącymi udział w realizacji danego    przypadku użycia. Łatwiej też 
można tu odwzorować efekty oddziaływania na pojedynczy     obiekt.

 Diagramy sekwencji lepiej przedstawiają zależności czasowe, bardziej 
niż diagramy     komunikacji nadają się do modelowania systemów czasu 
rzeczywistego i złożonych    scenariuszy.

 Oba rodzaje diagramów przedstawiają bardzo podobną informację, w nieco inny sposób.


Document Outline