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

  

Projektowanie systemów 

informacyjnych

Ewa Stemposz, Kazimierz Subieta 

Instytut Podstaw Informatyki PAN, 
Warszawa

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

Wykład 9

Model dynamiczny (1)

 Diagramy interakcji

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

Zagadnienia

Diagramy interakcji:

 Diagramy współpracy

 Diagramy sekwencji

Generyczne diagramy interakcji:

Współbieżność na diagramach interakcji

 Wyrażanie warunków

 Wyrażanie iteracji

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

Diagramy interakcji

Diagramy  interakcji,  stanowiące  jeden  z  rodzajów  diagramów 
dynamicznych,  pozwalają  na  utworzenie  opisu  interakcji  obiektów 
systemu  podczas  realizacji  danego  zadania:  np.  przypadku  użycia  czy 
też jednego konkretnego scenariusza danego przypadku użycia. 
Nie  dla  wszystkich  przypadków  użycia  może  zachodzić  potrzeba 
konstruowania  diagramów    interakcji,  ale  mogą  okazać  się  szczególnie 
użyteczne  np.  do  komunikacji  wewnątrz  zespołu  projektowego  (jak 
zresztą  wszystkie  rodzaje  diagramów)  czy  też  do  rozważenia 
opcjonalnych  realizacji  w  “trudnych  przypadkach”.  Ponadto,  niektóre 
narzędzia  CASE    potrafią  wykorzystać  te  diagramy  do  generacji  kodu, 
co może stanowić ważny powód dla ich konstruowania.

UML posiada dwa rodzaje diagramów interakcji: 

Oba  rodzaje  diagramów,  bazując  na  danym  diagramie  klas,  pokazują 
prawie  tą  samą  informację,  w  nieco  inny  sposób.  Niektóre  narzędzia 
CASE  potrafią  generować  jedne  z  tych  diagramów  z  drugich.  Decyzja, 
który  rodzaj  diagramów  konstruować,  zależy  od  pożądanego  aspektu 
interakcji.

 diagramy współpracy (kolaboracji)  

 diagramy sekwencji. 

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

Diagramy współpracy; przykład

Prosty  diagram  współpracy,  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  współpracy  pokazuje  w  jaki  sposób  system  realizuje  dany 
przypadek  użycia.  Współpracujące  obiekty,  połączone  liniami 
nazywanymi  “linkami”,  tworzą  rodzaj    “kolektywu”  (tzw.  kolaborację). 
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.

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

Interakcja na diagramach współpracy 

(1)

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

Diagramy  współpracy  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

4: Zaznacz wypożyczenie
3: Czy wolny

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

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

Interakcja na diagramach współpracy 

(2)

Na  diagramach  współpracy  nie  pokazuje  się  odpowiedzi  na  wysyłane 
komunikaty.
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.

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

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

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

Przykład interakcji komunikatów w 

Javie (2)

Diagram  klas,  zgodny  z  diagramem  współpracy  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..*

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

Diagramy sekwencji

: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

linia życia 

obiektu

czas

aktywne

życie obiektu

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

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

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

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 współpracy, można pokazać 
przekazywanie sterowania.

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

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  współpracy 
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.

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

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

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

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

UtwórzNowegoSzefaWykładowców (n)

usuń

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

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

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  (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]

2: UtwórzNowegoSzefaWykładowców (n)

1: n := PobierzNazwisko

3: usuń

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

diagram współpracy

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

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ć}

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

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. 

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

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  współpracy  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.

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

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

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

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)

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

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 współpracy przedstawionym na 
poprzednim slajdzie, wyglądałby jak poniżej. 

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

Rodzaje interakcji

Obiekt, adresat komunikatu, musi 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 operacji 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.

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

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.

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

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ć. 
Na  diagramach  kolaboracji  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.

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

Notacja dla oznaczania interakcji

Rodzaj interakcji Symbol

Znaczenie

synchroniczna

“Normalna” 

proceduralna 

sytuacja. 

Nadawca  zawiesza  działanie,  dopóki 
odbiorca nie zwróci  sterowania. Można to 
oznaczyć wykorzystując symbol powrotu.

powrót
(return)

Powrót  nie  jest  komunikatem.  Oznacza 
zakończenie  komunikatu  i  przekazanie 
sterowania do nadawcy.

(synchronous)

jednostronna
(flat)

Nadawca 

komunikatu 

przekazuje 

sterowanie  do  odbiorcy  oraz  kończy 
własną  działalność  nie  oczekując  na 
odpowiedź.

asynchroniczna
(asynchronous)

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.

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

Przykład diagramu sekwencji ze 

współbieżnością

:Personel

bibl.

:Członek

bibl.

Czy przetrzymuje

[jeśli przetrzymuje] email

:Książka

:Egzemplarz

książki

Rejestruj nową

Rejestruj nowy

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

Wyróżnianie subkolaboracji

Złożona kolaboracja

Opisywanie interakcji na wyższym poziomie poprzez ukrywanie detali  − 
jest użyteczne − jak każda abstrakcja. Temu celowi służy wyodrębnienie 
subkolaboracji,  a  następnie  zamiana  jej  na  pakiet.  Pakiet,  w  UML, 
przeznaczony jest do grupowania elementów modelu. Pakiet nie posiada 
własnego interfejsu, w tym sensie, że przesłanie komunikatu do pakietu, 
oznacza przesłanie komunikatu do obiektu wewnątrz pakietu. 
W  UML,  sparametryzowana  kolaboracja  jest  traktowana  jako 
wzorzec projektowy (design pattern).

Wyróżnianie subkolaboracji

Zamiana subkolaboracji

na pakiet

pakiet

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

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 reguły.

*

1

1

*

1

*

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

Podsumowanie diagramów interakcji

Diagramy interakcji, czyli diagramy współpracy 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  współpracy,  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     współpracy 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.