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.