



Projektowanie systemów informatycznych



st. wykł. mgr inż. Janusz Czuchnowski Master of Business Training



e-mail:

[e-mail]



tel. praca: [phone]



pokój: 807a Gmach B



Konsultacje: środa 13.30 – 14.00

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

2



W01 – Wprowadzenie do inżynierii oprogramowania



W02 – Unified Modelling Language - biznesowe przypadki użycia



W03 – Unified Modelling Language - model wymagań



W04 – Podstawowe zasady obiektowości



W05 – Projektowanie obiektowe



W06 – Diagramy klas



W07 – Diagramy sekwencji i interakcji



W08 – Tworzenie modelu obiektowego



W09 – Model testowania - zapewnienie jakości oprogramowania



W10 – Projektowanie strukturalne



W11 – System informacyjny systemu działania



W12 – Proces tworzenia oprogramowania



W13 – Metodyki ewolucyjne projektowania SI



W14 – Zarządzanie zmianą - implementacja i rozwój systemu

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

3





2012-02-15

opr.: st. wykł. mgr inż. Janusz

Czuchnowski

4

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

5





2012-02-15

opr.: st. wykł. mgr inż. Janusz

Czuchnowski

6

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 7

Diagramy interakcji:

 Diagramy współpracy (interakcji)
 Diagramy sekwencji

Generyczne diagramy interakcji:

Współbieżność na diagramach interakcji

 Wyrażanie warunków
 Wyrażanie iteracji

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 8

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.

UML posiada dwa rodzaje diagramów interakcji:

 diagramy współpracy (kolaboracji)
 diagramy sekwencji.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 9

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 10

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 11

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 12

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 13

: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 C#, 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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 14

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 15

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 16

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 17

:Sterowanie

:Dzwoniący

:Odbierający

podniesienie słuchawki

ton w słuchawce

wybór cyfry

łączenie

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 18

: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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 19

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 20

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ść.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 21

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 22

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 23

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 24

: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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 25

: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 C#, 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)

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 26

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 27

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)

 Współbieżna

.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 28

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 29

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 30

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 31

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.

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 32

:Personel

bibl.

:Członek

bibl.

Czy przetrzymuje

[jeśli przetrzymuje] email

:Książka

:Egzemplarz

książki

Rejestruj nową

Rejestruj nowy

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 33

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

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 34

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

*

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

Slajd 35

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.

Wysiłek związany z projektowaniem systemu informatycznego jest duży,
ale efekt uzyskany po sfinalizowaniu wszystkich prac – jest wart tego wysiłku

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

36

2012-02-15

opr.: st. wykł. mgr inż. Janusz Czuchnowski

37