5R]G]LD�
=QDF]HQLH GLDJUDPŃZ VHNZHQFML
Diagramy sekwencji s najcz ciej stosowanymi w praktyce spo ród wszystkich dia-
gramów interakcji, co mo na przypisać ich precyzji w opisywaniu i porz dkowaniu
zło onych interakcji. Diagramy te s ci le powi zane ze scenariuszami przypadków
u ycia, dokumentuj c ich funkcjonalno ć.
'LDJUDP VHNZHQFML MHVW URG]DMHP GLDJUDPX LQWHUDNFML RSLVXMńF\P LQWHUDNFMH SR
PL�G]\ LQVWDQFMDPL NODV\ILNDWRUŃZ V\VWHPX Z SRVWDFL VHNZHQFML NRPXQLNDWŃZ
Z\PLHQLDQ\FK PL�G]\ QLPL
Wła ciwo ci diagramów sekwencji doskonale przedstawiaj koncepcj obiektowego
modelowania systemów informatycznych i pozwalaj na bezpo rednie przej cie do ge-
nerowania kodu ródłowego w j zykach obiektowych, takich jak JAVA, VB .NET czy
te C++. Interakcja na diagramie sekwencji opisywana jest w dwóch wymiarach:
t poziomym  jako o , na której umieszczono instancje klasyfikatorów bior ce
udział w interakcji;
t pionowym  jako o czasu przedstawiaj ca uło one chronologicznie
komunikaty.
Wymiar poziomy ma charakter statyczny, natomiast pionowy  dynamiczny. Diagra-
my sekwencji stwarzaj zatem mo liwo ć dokumentowania interakcji w postaci komu-
nikatów wysyłanych oraz odbieranych przez instancje klasyfikatorów systemu. Obrazuj
one przepływ sterowania w systemie. Oznacza to wyznaczenie kolejno ci i miejsca
wykonywania poszczególnych operacji.
Poza podstawowymi kategoriami poj ciowymi  klasyfikatorem, lini ycia, komu-
nikatem oraz o rodkiem sterowania  diagramy te wzbogacone zostały o cały szereg
innych zaawansowanych, omawianych w niniejszym rozdziale poj ć i zwi zanych
z nimi graficznych oznacze . Do poj ć tych nale ró ne rodzaje komunikatów, warunki,
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 179
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
tworzenie i niszczenie obiektów, samowywoływanie, rozgał zienie, iteracja, fragment
wyodr bniony, brama. Stwarzaj one projektantowi systemu mo liwo ć opracowania
bardzo precyzyjnych specyfikacji dynamiki systemu. Szczególn rol w tym zakresie
pełni operatory interakcji wprowadzone w najnowszej wersji j zyka UML  2.0.
3RGVWDZRZH NDWHJRULH SRM�FLRZH
RUD] QRWDFMD JUDILF]QD
5RG]DMH GLDJUDPŃZ VHNZHQFML
Zakres oczekiwa twórców i u ytkowników systemu w zakresie szczegółowo ci opi-
su interakcji na diagramie sekwencji jest zró nicowany. Zale y on równie od kon-
kretnej fazy cyklu systemu oraz jej zaawansowania, co determinuje potrzeby w zakresie
szczegółowo ci modelu dynamiki systemu. I tak mo na wyró nić trzy rodzaje dia-
gramów sekwencji, w zale no ci od przyj tego stopnia abstrakcji. S to diagramy:
t konceptualny,
t implementacyjny,
t wyst pieniowy.
W celu opracowania konceptualnego diagramu sekwencji (ang. conceptual sequence
diagram) twórca systemu korzysta z podstawowych kategorii poj ciowych i graficz-
nych. Ten typ diagramu stwarza mened erom i u ytkownikom mo liwo ć szybkiego,
ogólnego naszkicowania zakresu i zawarto ci interakcji dla danej aplikacji. W ten spo-
sób powstaje diagram o ogólnym zakresie i łatwych do zidentyfikowania interakcjach.
Konceptualny diagram sekwencji nie został w sposób cisły zdefiniowany w dokumen-
tacji j zyka UML 2.0.
Konceptualny diagram sekwencji, choć jest dobrym punktem wyj cia i platform po-
rozumienia z u ytkownikami, nie stanowi wystarczaj cej podstawy opracowania spe-
cyfikacji programistycznej. Rol t pełni implementacyjny diagram sekwencji (ang.
generic sequence diagram), którego tworzenie inicjowane jest poprzez wykorzystanie
diagramu na poziomie konceptualnym. Diagram ten prezentuje o wiele wy szy poziom
precyzji oraz wi kszy semantyczny zakres interakcji, choć dotyczy tej samej dziedzi-
ny przedmiotowej. Dokonywane jest to dzi ki wykorzystaniu wszystkich kategorii
poj ciowych dost pnych w diagramach sekwencji. Implementacyjny diagram sekwen-
cji, oprócz głównego przepływu scenariusza przypadku u ycia z odpowiedniego dia-
gramu przypadków u ycia, obejmuje tak e wszystkie przepływy alternatywne tego
scenariusza. Diagramy na poziomie implementacyjnym s rutynowymi diagramami
sekwencji. Przekazuje si je programistom jako dokumentacj projektow lub na ich
podstawie automatycznie generuje kod z wykorzystaniem narz dzi CASE.
180 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
Diagramy konceptualne i implementacyjne nie wyczerpuj wszystkich mo liwo ci
prezentowania sekwencji w systemie. Na pełnym, implementacyjnym diagramie se-
kwencji wyst puje wiele rozwi za o charakterze opcjonalnym b d alternatywnym,
których wykonanie jest uzale nione od zdefiniowanych na diagramie warunków. W za-
le no ci od ich spełnienia wykonywane jest okre lone wyst pienie diagramu spo ród
wszystkich kombinacji głównych i alternatywnych przepływów scenariusza danego
przypadku u ycia. Wyst pienie diagramu sekwencji opracowane w odniesieniu do usta-
lonego scenariusza okre la si mianem wyst pieniowego diagramu sekwencji (ang.
instance sequence diagram). Danemu implementacyjnemu diagramowi sekwencji za-
zwyczaj odpowiada wiele wyst pieniowych diagramów sekwencji.
Zale no ci pomi dzy implementacyjnym a wyst pieniowym diagramem sekwencji mo -
na prze ledzić, analizuj c opis przypadku u ycia  Anuluj rezerwacje (tabela 2.3). I tak
implementacyjny diagram sekwencji opisuje zarówno główny, jak i alternatywne prze-
pływy zdarze . Z diagramu implementacyjnego opracowanego na podstawie wspo-
mnianej wy ej tabeli wynikaj cztery wyst pieniowe diagramy sekwencji (a, b, c, d).
Charakteryzuj si one nast puj c kolejno ci przepływów:
a) 1, 2, ..., 6;
b) 1, 2a;
c) 1, 2, 3a;
d) 1, 2, 3, 3b, 4, 5, 6.
Charakterystyk opisanych rodzajów diagramów sekwencji przedstawia tabela 7.1.
7DEHOD Kategorie modelowania a poziomy diagramów sekwencji
.U\WHULXP 5DPD GLDJUDPX .DWHJRULH SRM�FLRZH 3U]\N�DGRZH U\VXQNL
Konceptualny opcjonalna podstawowe 7.3, 7.5, 7.6
diagram sekwencji
Implementacyjny wymagana wszystkie podstawowe 7.21  7.33, 7.38
diagram sekwencji i zaawansowane
Wyst pieniowy wymagana wybrane 7.39
diagram sekwencji
.ODV\ILNDWRU NRPXQLNDW L OLQLD \FLD
Podstawowymi elementami diagramu sekwencji s :
t klasyfikator,
t komunikat,
t linia ycia,
t o rodek sterowania.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 181
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Wyst puj one niezale nie od poziomu abstrakcji, na jakim diagram sekwencji jest
tworzony  na poziomie konceptualnym, implementacyjnym czy te wyst pienio-
wym. Co wi cej  w przyjaznej mened erom, najbardziej ogólnej, strategicznej wer-
sji, konceptualne diagramy sekwencji mog opierać si wył cznie na trzech pierw-
szych z wymienionych poj ć. Bli sz charakterystyk tych kategorii modelowania
przedstawia tabela 7.2. Podane w niej definicje s autorskimi modyfikacjami definicji
proponowanych przez organizacj OMG.
7DEHOD Podstawowe kategorie modelowania diagramów sekwencji
1D]ZD SRM�FLD 1RWDFMD JUDILF]QD 'HILQLFMD
Obiekt
(jako instancja
.ODV\ILNDWRU WR DEVWUDNF\MQD NDWHJRULD PRGH
:PoIisa
klasyfikatora)
ORZDQLD V\VWHPX Z M�]\NX 80/ NWŃUD XRJŃOQLD
NROHNFM� LQVWDQFML R W\FK VDP\FK FHFKDFK
Linia ycia
/LQLD \FLD WR SRZLń]DQD ] NRQNUHWQń LQVWDQFMń
NODV\ILNDWRUD OLQLD QD GLDJUDPLH VHNZHQFML ZVND
]XMńFD RNUHV LVWQLHQLD WHM LQVWDQFML
Komunikat
.RPXQLNDW WR VSHF\ILNDFMD Z\PLDQ\ LQIRUPDFML
PL�G]\ RELHNWDPL ]DZLHUDMńFD ]OHFHQLD Z\NR
QDQLD RNUH ORQHM RSHUDFML
Najcz ciej w ramach diagramów sekwencji ilustrowane s instancje klasyfikatorów
w postaci obiektów. Instancje klasyfikatorów bior ce udział w interakcji nale y roz-
mieszczać na linii poziomej w kolejno ci ich wyst powania. Z ka dej instancji klasy-
fikatora wyprowadza si przerywan lini nazywan lini ycia (ang. lifeline), repre-
zentuj c czas ycia instancji. Wyst pienie na diagramie sekwencji instancji klasyfikatora
jest równoznaczne z wyst pieniem jej linii ycia. Obiekty oraz zwi zane z nimi linie
ycia przedstawia rysunek 7.1.
5\VXQHN
Recepcjonista IRezerwacja BazaDanych
Instancje
klasyfikatorów
z liniami ycia
Kolejn podstawow kategori modelowania, komunikaty, rozmieszcza si na osi pio-
nowej diagramu, pomi dzy liniami ycia instancji klasyfikatorów (rysunek 7.2).
182 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
IRezerwacja BazaDanych
Przesłanie komunikatu
dokonajRezerwacji
Komunikaty porz dkowane s według kolejno ci ich wyst powania. Im pó niej na-
st puje wysłanie komunikatu, tym ni ej umieszcza si go na diagramie (rysunek 7.3).
Istnieje opcja ich numerowania, choć na diagramach sekwencji nie jest to wymagane.
IBankomat SystemOperatoraKart BazaDanych
Klient
wprowad PIN
sprawd Poprawno ćPIN-u
potwierd Autoryzacj Klienta
weryfikujSaldo
sprawd SaldoKonta
wy wietlSaldo
5\VXQHN Sprawdzanie stanu konta za po rednictwem bankomatu
Nie wyst puje konieczno ć wysyłania komunikatów wył cznie do instancji klasyfi-
katorów s siaduj cych na diagramie z nadawc . Z linii ycia danej instancji klasyfikato-
ra mo na przesłać komunikaty do wszystkich innych instancji klasyfikatorów wyst -
puj cych na danym diagramie sekwencji.
5RG]DMH NODV\ILNDWRUŃZ
Jak zaznaczono, diagramy sekwencji zazwyczaj przedstawiaj sposób wzajemnej współ-
pracy obiektów. Diagramy te mog jednak  z wyj tkiem wyst pieniowych dia-
gramów sekwencji  opisywać interakcj pomi dzy instancjami ró nych rodzajów
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 183
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
klasyfikatorów stosowanych we wszystkich innych rodzajach diagramów j zyka UML.
Podstawowe rodzaje klasyfikatorów przedstawianych w ramach diagramów sekwen-
cji zawiera tabela 7.3. Twórcy systemu mog poszerzać spektrum klasyfikatorów po-
przez stereotypy  propozycje własnych oznacze graficznych i poj ciowych.
7DEHOD Wybrane rodzaje klasyfikatorów w j zyku UML
5RG]DM 1RWDFMD JUDILF]QD 5RG]DM 1RWDFMD JUDILF]QD
Aktor Pakiet
Przypadek u ycia Współdziałanie
Klasa Interfejs
Klasa analityczna W zeł
Artefakt Komponent
�artifact
Sygnał
2 URGHN VWHURZDQLD
Linia ycia reprezentuje okres ycia instancji klasyfikatora. W niektórych okresach
swego ycia instancja ta jest w stanie czuwania, podczas gdy w innych jest aktywowana
przez komunikaty, przejmuj c sterowanie interakcj i podejmuj c zlecone działania.
Po wykonaniu operacji zleconych komunikatem i wysłaniu odpowiednich komunikatów
wynikowych instancja klasyfikatora mo e ponownie przechodzić w stan czuwania.
Sytuacje te powoduj , e w odniesieniu do linii ycia zaproponowano now kategori
poj ciow , tj. o rodek sterowania (ang. execution specification).
184 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
2 URGHN VWHURZDQLD MHVW VSHF\ILNDFMń Z\NRQ\ZDQLD F]\QQR FL RSHUDFML OXE LQQHM
MHGQRVWNL ]DFKRZDQLD Z UDPDFK LQWHUDNFML
W praktyce realizacja funkcjonalno ci instancji klasyfikatora  wskazania na linii y-
cia z wykorzystaniem o rodka sterowania  oznacza wykonywanie operacji przetwa-
rzania, obliczania, komunikowania si z innymi instancjami klasyfikatorów czy te
wykonywania algorytmów zło onych z elementarnych akcji. Na diagramie o rodek ste-
rowania przyjmuje postać prostok ta umieszczonego na linii ycia instancji klasyfi-
katora (rysunek 7.4).
5\VXQHN
Kategorie poj ciowe
diagramów sekwencji
O rodek sterowania jest inicjowany aktywacj , a przej cie w stan czuwania dezak-
tywacj . Zastosowanie o rodków sterowania podczas modelowania procesu komuni-
kowania si recepcjonisty z systemem rezerwacji hotelowej przedstawia rysunek 7.5.
Graficzna reprezentacja o rodka sterowania na diagramie sekwencji nie musi mieć
charakteru ci głego. Na konkretnej linii ycia zwi zanej z dan instancj klasyfikato-
ra mo e wyst pić kilka niezale nych o rodków sterowania. Oznacza to, e instancja
ta jest aktywowana wielokrotnie w celu realizacji komunikatów wysyłanych przez in-
ne instancje klasyfikatorów. W ten sposób instancja kilkakrotnie przechodzi w stany
aktywne, jak zaprezentowano na rysunku 7.6, który przedstawia interakcj inwestora
oraz systemu obsługi funduszu inwestycyjnego. Rysunek ten uwzgl dnia ponadto opcje
w postaci mo liwo ci numerowania kolejnych komunikatów oraz umieszczania na dia-
gramie sekwencji parametrów operacji przy komunikatach.
=DDZDQVRZDQH VN�DGQLNL GLDJUDPX
Współczesne aplikacje informatyczne, zwłaszcza pracuj ce w czasie rzeczywistym, s
bardzo zło one. Opisane w scenariuszach przypadków u ycia interakcje aktor  sys-
tem stanowi podstaw specyfikacji interakcji wewn trz systemu informatycznego.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 185
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
5\VXQHN
IRezerwacja BazaDanych
Rezerwacja hotelowa
Recepcjonista
otwórzRezerwacj
sprawd Dost pno ćPokoi
wprowad Dane
dokonajRezerwacji
potwierd Rezerwacj
zamknij
5\VXQHN
SystemOFI
Okres aktywno ci
instancji
Inwestor
klasyfikatorów
1: zlećZakup(jednostkaUczestnictwa)
2: potwierd Zakup
3: odkupJednostki
4: potwierd Odkupienie
Przedstawione dotychczas kategorie modelowania diagramów sekwencji, tj. klasyfika-
tor, komunikat, linia ycia i o rodek sterowania, nie s wystarczaj ce do udokumen-
towania zło ono ci interakcji. Nie pozwalaj na pełne opracowanie implementacyjnych
diagramów sekwencji, b d cych podstaw generowania kodu systemów informatycz-
nych. Dlatego diagramy sekwencji wzbogacono o szereg innych elementów, takich jak:
186 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
t rodzaje komunikatów,
t tworzenie i niszczenie obiektów,
t warunki,
t samowywoływanie,
t iteracja,
t rozgał zienie,
t fragmenty wyodr bnione i operatory interakcji,
t przywoływane wyst pienia interakcji,
t bramy.
Wyst pieniowe diagramy sekwencji mog korzystać z niektórych wymienionych ka-
tegorii poj ciowych, niemniej specyfika wyst pienia zaw a ich zakres.
5RG]DMH NRPXQLNDWŃZ
W istocie komunikaty ró ni si nie tylko tre ci semantyczn , lecz tak e funkcjonal-
no ci . Tre ć semantyczna, czyli polecenie wydane przez nadawc , wyra ona jest pełn
składni komunikatu zdefiniowan w rozdziale 6. Z kolei funkcjonalno ć instancji kla-
syfikatorów okre la si dzi ki wyborowi odpowiedniego rodzaju komunikatu. Specyfi-
ka tych rodzajów wyra ana jest graficznie poprzez wprowadzenie odmiennych ozna-
cze . Wyró nia si nast puj ce rodzaje komunikatów:
t synchroniczny,
t asynchroniczny,
t zwrotny,
t utracony,
t znaleziony,
t opcjonalny,
t oczekuj cy.
W rutynowej interakcji oba bior ce w niej udział instancje klasyfikatorów  klasyfi-
kator-nadawca oraz klasyfikator-odbiorca  s znane i ci le zdefiniowane. Komu-
nikaty bior ce udział w takiej interakcji traktuje si jako kompletne. Nale do nich
komunikaty synchroniczne, asynchroniczne, zwrotne, opcjonalne oraz oczekuj ce.
W praktyce mo e zaistnieć tak e sytuacja, w której jedna z instancji, nadawca b d
odbiorca, jest nieznana. Komunikaty niekompletne charakteryzuj ce opisan sytuacj
nazywa si odpowiednio komunikatem znalezionym oraz komunikatem utraconym.
Dzi ki poj ciu stereotypu zestaw dost pnych rodzajów komunikatów jest rozszerzany
przez ró nych autorów i zespoły praktyków, u ytkuj cych j zyk UML.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 187
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Na zamieszczonych dot d diagramach sekwencji przedstawiano jeden, w istocie do-
minuj cy, rodzaj komunikatu  komunikat synchroniczny. Wysłanie komunikatu
synchronicznego (ang. synchronous message) oznacza przekazanie sterowania do kla-
syfikatora-odbiorcy. W momencie przesłania tego komunikatu aktualny przepływ ste-
rowania klasyfikatora-nadawcy ulega przerwaniu  jest on wznawiany dopiero po
wykonaniu przez klasyfikator-odbiorc operacji inicjowanej przez ten komunikat (ry-
sunek 7.7). Odbiorca aktywuje operacj wskazan w komunikacie, a zatem powinien
wyst pować merytoryczny zwi zek pomi dzy nazw komunikatu a nazw operacji ak-
tywowanej w klasyfikatorze-odbiorcy. Nazwy te, zgodnie z zasad polimorfizmu obiek-
towo ci, mimo wskazywania na t sam operacj nie musz być identyczne. Kwestia
zgodno ci nazewnictwa w przypadku wykorzystania pakietów CASE do tworzenia dia-
gramów sekwencji jest znacznie uproszczona. Nazwy nadawane komunikatom auto-
matycznie przenoszone s jako nazwy operacji do odpowiednich klas.
5\VXQHN
IMagazyn Artykuł
Komunikat
synchroniczny
zmie Cen
W odró nieniu od scharakteryzowanych wy ej komunikatów synchronicznych, komu-
nikaty asynchroniczne (ang. asynchronous messages) nie powoduj przerwania ak-
tualnego przepływu sterowania nadawcy. Instancja klasyfikatora wysyłaj ca komuni-
kat nie oczekuje odpowiedzi, zarazem pozostaj c w stanie aktywno ci, co umo liwia jej
dalsze przetwarzanie b d wysyłanie komunikatów (rysunek 7.8).
5\VXQHN
Nadawca SateIita
Komunikat
asynchroniczny
odbierzSygnał
Komunikaty zwrotne (ang. return messages) wskazuj na powrót sterowania do in-
stancji klasyfikatora po wykonaniu komunikatu synchronicznego (rysunek 7.9). Komu-
nikat ten nie jest umieszczany na diagramach sekwencji obligatoryjnie  projektant
ma daleko posuni t swobod decyzji we wprowadzaniu komunikatów zwrotnych do
diagramów. Funkcj komunikatu zwrotnego jest nie tylko przekazanie sterowania do
danej instancji, ale te zainicjowanie jej okre lonej operacji.
188 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
IMagazyn Artykuł
Komunikat zwrotny
zmie Cen
wy wietl("Cena uaktualniona")
Komunikat okre la si mianem utraconego (ang. lost message) w sytuacji, gdy klasy-
fikator-nadawca jest znany, natomiast odbiorca nieznany (rysunek 7.10). Komunikat
utracony ma znaczenie w modelowaniu zło onych, składaj cych si z wielu frag-
mentów interakcji. Na tym etapie tworzenia systemu jego projektant nie jest w stanie
dokładnie sprecyzować odbiorcy komunikatu przesyłanego pomi dzy fragmentami inte-
rakcji. W dalszych iteracjach procesu tworzenia systemu, po integracji poszczególnych
fragmentów, klasyfikator-odbiorca zostaje jednoznacznie zidentyfikowany.
5\VXQHN
PortaIInternetowy
Komunikat utracony
wy wietlBanner
Je eli odbiorca danego komunikatu jest znany w obr bie danego fragmentu interakcji,
natomiast nadawca jest nieznany, komunikat taki nazywany jest komunikatem znale-
zionym (ang. found message). Komunikat znaleziony zamieszczono na rysunku 7.11.
5\VXQHN
Czujnik
Komunikat znaleziony
zainicjujReakcj
Komunikat znaleziony jest wysyłany spoza danego diagramu sekwencji. Impulsem do
nadania opisywanego komunikatu mo e być przykładowo dym, ogie , hałas czy ruch,
a zatem zjawiska, które nie poddaj si opisowi w postaci standardowych elementów
modelowania diagramów sekwencji j zyka UML.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 189
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Komunikat opcjonalny (ang. balking message) oznacza, e nadawca wysyła do od-
biorcy komunikat, oczekuj c gotowo ci do jego niezwłocznej obsługi przez odbiorc .
Je eli komunikat nie mo e zostać przyj ty bezpo rednio po wysłaniu, nadawca nie po-
dejmuje dalszych prób jego przesyłania (rysunek 7.12). Tym samym komunikat opcjo-
nalny nie w ka dym przypadku jest obsługiwany.
5\VXQHN
Komunikat opcjonalny
Komunikaty oczekuj ce (ang. timeout messages) wykazuj du y stopie podobie -
stwa do komunikatów opcjonalnych. Analogicznie, nadawca wysyła komunikat do od-
biorcy  z tym, e gotów jest czekać na jego obsłu enie przez okre lony odcinek czasu.
Je eli odbiorca nie jest w stanie przyj ć komunikatu w wyspecyfikowanym czasie,
nadawca rezygnuje z danej interakcji (rysunek 7.13).
5\VXQHN
IMagazyn BazaDanych
Komunikat oczekuj cy
nawi Poł czenie
Komunikaty opcjonalny oraz oczekuj cy nie s elementami standardu UML 2.0, lecz
stereotypami graficznymi zaproponowanymi przez korporacj IBM Rational.
7ZRU]HQLH L QLV]F]HQLH RELHNWŃZ
Poszczególne instancje klasyfikatorów mog za po rednictwem operacji zarówno two-
rzyć, jak i niszczyć obiekty. Obiekt zostaje utworzony w wyniku przesłania komuni-
katu stereotypowanego �create. Obiekt ten umieszczany jest na diagramie sekwencji
poni ej pierwotnie istniej cych instancji klasyfikatorów, tak aby jego poło enie było
zgodne z czasem utworzenia (rysunek 7.14). Po słowie kluczowym �create powinna
być umieszczona nazwa operacji tworz cej obiekt, choć nie jest to obligatoryjne.
Obiekt przestaje istnieć wraz z odebraniem przeze komunikatu stereotypowanego
�destroy. Na diagramie sekwencji fakt ten jest dodatkowo oznaczony zdarzeniem
niszcz cym (ang. destruction event), graficznie reprezentowanym w postaci wielkiej
litery X. Równie w tym przypadku po słowie kluczowym opcjonalne jest podanie na-
zwy operacji.
190 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
IKIient WierzyteIno ć
Tworzenie
i niszczenie obiektów
<>
Płatno ć
ui ć
<>
anuluj
UI Control
:DUXQNL
Wykonanie komunikatu mo na uzale nić od spełnienia okre lonych warunków (ang.
guard conditions).
:DUXQHN MHVW WR ]ZLń]DQH ] NRPXQLNDWHP NU\WHULXP RG NWŃUHJR VSH�QLHQLD X]D
OH QLRQH MHVW Z\NRQDQLH RNUH ORQHM RSHUDFML
Konwencja zapisu warunków nie jest ci le definiowana. W zale no ci od specyfiki
projektu i rodzaju stosowanego diagramu sekwencji  konceptualnego, implementa-
cyjnego lub wyst pieniowego  formalny zapis warunku mo e być ró ny. Najcz ciej
spotykane s warunki wyra one w sposób tekstowy oraz z wykorzystaniem pseudo-
kodu. Je li warunek dotycz cy danego komunikatu nie zostanie spełniony, operacja
wskazywana przez komunikat nie jest wykonywana.
Warunki umieszczane s w nawiasach kwadratowych przed nazw komunikatu. Uwa-
runkowany komunikat zaprezentowano na rysunku 7.15, gdzie kupuj cy przyst puje do
licytacji tylko w przypadku, gdy oferowana przez niego cena jest wy sza od ceny wy-
woławczej.
5\VXQHN
ILicytacja
Warunek realizacji
komunikatu
Kupuj cy
[cenaProponowana > cenaWywoławcza]:
przyst pDoLicytacji
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 191
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Na ogół z jednym komunikatem wi e si tylko jeden warunek. Jednak jest równie
mo liwe uzale nienie realizacji jednego komunikatu przez dan instancj klasyfikatora
od spełnienia kilku warunków. Pomi dzy dwoma o rodkami sterowania mo na umie-
cić dowoln liczb uwarunkowanych komunikatów.
Warunki okre lane s tak e mianem wyra e dozoru.
6DPRZ\ZR�DQLH
Kolejn kategori poj ciow stosowan w diagramach sekwencji jest samowywoła-
nie (ang. messages to self). Oznacza ono sytuacj , w której dana instancja klasyfikato-
ra wywołuje własn operacj (rysunek 7.16). Samowywołanie nale y traktować jako
szczególny przypadek iteracji.
5\VXQHN
FormuIarzZakupu : FormuIarz
Samowywołanie
weryfikujKompletno ćDanych
W efekcie samowywoływania na linii ycia danej instancji klasyfikatora pojawia si
zagnie d ony o rodek sterowania. Poj cie zagnie d enia jest ci le zwi zane z kolej-
no ci wzajemnie uzale nionego wywoływania si komunikatów i jest szczegółowo
wyja nione w rozdziale 8.
,WHUDFMD
W zastosowaniach biznesowych wyst puje wiele interakcji, w których ten sam komu-
nikat wykonywany jest wielokrotnie, na zasadzie iteracji.
,WHUDFMD WR ZLHORNURWQH SROLF]DOQH SRZWŃU]HQLH MHGQRVWNL ]DFKRZDQLD Z V\VWHPLH
Krotno ć wykonania iteracji okre lana jest w formie warunku poprzedzonego sym-
bolem *. Podstawowa notacja iteracji jest nast puj ca:
 * |  * [  ]
Iteracj w klasycznym wydaniu przedstawia si jak na rysunku 7.17. Ilustruje on przy-
dzielanie Pracowników zespołu projektowego do konkretnych projektów.
192 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
sd Wewn trzna Rekrutacja Pracowników Do Projektów
KomitetSteruj cyIT ZespółProjektowy DobórPracowników BazaDanych
przydzielLidera
przydziel(lider)
aktualizuj(lider, status)
wy wietl("Lider przydzielony")
kompletujZespółProjektowy
przydziel
*[prac := 1..n]: przydzielSpecjalist (prj, an, prg, tst)
wy wietl("Zespół skompletowany")
zatwierd ZespółProjektowy
5\VXQHN Iteracja w wewn trznej rekrutacji pracowników do projektów
Firma programistyczna wykonuje równolegle wiele projektów. Obsługa kadrowa pro-
jektów wspomagana jest komputerowo. Odpowiedni system pozwala na adekwatne
dopasowanie zawodowych kompetencji pracowników firmy do specyfiki potrzeb kon-
kretnego projektu. Do realizacji ka dego projektu powoływany jest ZespółProjektowy.
W tym celu komitet steruj cy wyznacza lidera zespołu poprzez wysłanie komunikatu
przydzielLidera. Analityczny obiekt graniczny ZespółProjektowy przekazuje komunikat
przydziel z identyfikatorem lidera do analitycznego obiektu steruj cego DobórPra-
cowników. W momencie przydzielenia do konkretnego projektu status lidera zostaje
zmieniony w BazieDanych. Zmiana ta dokonywana jest za po rednictwem komuni-
katu aktualizuj z parametrami lider oraz status. Po dokonaniu aktualizacji statusu in-
terfejs ZespółProjektowy wy wietla potwierdzenie przydzielenia lidera. Kolejnym kro-
kiem w powoływaniu nowego zespołu jest przydzielenie do projektu poszczególnych
pracowników bezpo rednio zaanga owanych w proces tworzenia systemu informatycz-
nego. Pojedynczy projekt jest realizowany przez ustalon grup specjalistów, w tym
zazwyczaj kilku projektantów systemu, analityków systemowych, programistów oraz
testuj cych. Poszczególne specjalizacje członków zespołu reprezentowane s przez
parametry prj, an, prg, tst komunikatu przydzielSpecjalist . Skompletowanie zespołu
zako czone jest ponownym wy wietleniem potwierdzenia. Po wykonaniu procedury
doboru zespołu KomitetSteruj cyIT zatwierdzaZespółProjektowy.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 193
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Pocz wszy od wersji 2.0 standardu UML, zło one interakcje mo na modelować z wy-
korzystaniem fragmentów wyodr bnionych, jak pokazano na rysunku 7.38.
5R]JD��]LHQLH
Zweryfikowanie warunku mo e oznaczać wysłanie komunikatu skutkuj cego wyko-
naniem operacji odbiorcy, tak jak na rysunku 7.15. Jednak realizacja konkretnych ope-
racji mo e opierać si na bloku decyzyjnym składaj cym si z przynajmniej dwóch
wzajemnie wykluczaj cych si warunków. W takim przypadku realizacja wyklucza-
j cych si warunków na diagramie sekwencji oznacza konieczno ć przesyłania komuni-
katów, jak równie przekazania sterowania do odpowiednich instancji klasyfikatorów.
Funkcja obsługi tych warunków przybiera postać rozgał zienia (ang. branch), jak na
rysunku 7.18. A zatem:
5R]JD��]LHQLH MHVW VSRVREHP SU]HND]DQLD VWHURZDQLD QD GLDJUDPLH VHNZHQFML ] OL
QLL \FLD R URGND VWHURZDQLD NODV\ILNDWRUD QDGDZF\ GR NODV\ILNDWRUŃZ RGELRUFŃZ
Z ]DOH QR FL RG VSH�QLHQLD ZDUXQNX SU]\SLVDQHJR GR SU]HV\�DQHJR NRPXQLNDWX
IPaneISteruj cy KataIog Licytacja
Sprzedaj cy
zablokujSprzeda Artykułu
[decyzja o usuni ciu artykułu]: usu Artykuł
[decyzja o przerwaniu licytacji]: zako czLicytacj
5\VXQHN Rozgał zienie
Rysunek 7.18 prezentuje wybrane interakcje dotycz ce licytacji na aukcji interneto-
wej, na któr Sprzedaj cy mo e zgłosić szereg artykułów, umieszczaj c je w Katalo-
gu aukcji. Bie c kontrol nad przebiegiem aukcji umo liwia mu IPanelSteruj cy.
W okresie mi dzy umieszczeniem artykułu w Katalogu a rozpocz ciem Licytacji, Sprze-
daj cy mo e być zainteresowany wycofaniem artykułu z aukcji. Skutkuje to wykre-
leniem artykułu z Katalogu aukcji w wyniku przesłania komunikatu usu Artykuł. Ist-
nieje równie drugi sposób zablokowania sprzeda y artykułu na Licytacji. Znajduje
zastosowanie wtedy, gdy ju w trakcie trwania Licytacji sprzedaj cy zdecyduje si na
wycofanie artykułu i przerwanie Licytacji bez podania przyczyn. Dokonuje si to
w wyniku przesłania komunikatu zako czLicytacj .
194 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
Na diagramach sekwencji wyst puje równie inna odmiana rozgał zienia. Przesłanie
alternatywnych komunikatów wynikaj cych ze spełnienia warunku mo e być tak e
realizowane wył cznie przez jedn instancj klasyfikatora. Wówczas konieczne jest
rozszczepienie linii ycia klasyfikatora-odbiorcy. Poniewa komunikat jest wysyłany
tylko do jednego odbiorcy, w momencie rozpocz cia realizacji uwarunkowanych ko-
munikatów rozszczepia si lini ycia klasyfikatora-odbiorcy, tworz c alternatywne
linie ycia (rysunek 7.19). Po wykonaniu stosownych operacji rozszczepione linie y-
cia mog zostać ponownie poł czone.
Zatem UML pozwala na wprowadzanie dwóch odmian rozgał zie :
[warunki]
t klasyfikator-nadawca kilka klasyfikatorów-odbiorców;
[warunki]
t klasyfikator-nadawca jeden klasyfikator-odbiorca
z rozszczepion lini ycia.
�system
KontraktyTerminowe
Nabywca BiuroMaklerskie Bank
realizujKontrakt
ustalWarto ćBie c
[wBie > wNom]: wykonajKontrakt
transferujZysk
[wBie < wNom]: wykonajKontrakt
potr ćStrat ZDepozytu
transferujDepozyt
potwierd Realizacj Kontraktu
5\VXQHN Realizacja kontraktu terminowego
Na rysunku 7.19 zaprezentowano drugi rodzaj rozgał zienia na diagramach sekwen-
cji. Nabywca decyduje si zrealizować uprzednio nabyty kontrakt terminowy. W tym
celu wysyła komunikat realizujKontrakt do systemu KontraktyTerminowe. Nabywca
mo e spodziewać si zarówno zysków, jak i strat. System ustalaWarto ćBie c
kontraktu. Nast pnie warto ć ta jest porównywana z warto ci nominaln równ cenie
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 195
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
zakupu. Po przeprowadzeniu porównania wysyłany jest komunikat wykonajKontrakt.
Sposób wykonania kontraktu zale y od wyniku finansowego transakcji. W przypadku
osi gni cia zysków s one przelewane na konto Nabywcy kontraktu w wyniku wyko-
nania komunikatu transferujZysk. Natomiast ewentualne straty s potr cane z jego de-
pozytu w wyniku realizacji komunikatu potr ćStrat ZDepozytu. W obu przypadkach
nast pnym krokiem jest transferDepozytu (lub jego pozostałej cz ci) przez Biuro-
Maklerskie na konto Nabywcy w Banku prowadz cym rachunek bie cy Nabywcy.
Transakcja ko czy si potwierdzeniemRealizacjiKontraktu.
Notacja rozgał zie traci obecnie na znaczeniu w zwi zku z wprowadzeniem wraz
z wersj UML 2.0 fragmentu wyodr bnionego z operatorem interakcji alt.
)UDJPHQW\ Z\RGU�EQLRQH L RSHUDWRU\ LQWHUDNFML
Zło ono ć diagramów sekwencji powoduje, e wyró nia si w nich pewne specjalne
obszary interakcji nazywane fragmentami interakcji. W praktyce przyjmuj one postać:
t fragmentów wyodr bnionych (ang. combined fragments),
t przywoływanych wyst pie interakcji (ang. interaction occurrences).
Pod wzgl dem poj ciowym bardziej rozbudowana jest pierwsza z tych kategorii.
)UDJPHQW Z\RGU�EQLRQ\ MHVW WR ORJLF]QLH VSŃMQ\ REV]DU LQWHUDNFML F]� Ł GLDJUDPX
VHNZHQFML FKDUDNWHU\]XMńFD VL� VSHF\ILF]Q\PL Z�D FLZR FLDPL RNUH ORQ\PL SU]H] RSH
UDWRU LQWHUDNFML
Stosowanie fragmentów wyodr bnionych umo liwia bardziej precyzyjne zobrazowa-
nie istoty interakcji, co jest szczególnie wa ne w przypadku systemów czasu rzeczy-
wistego oraz wspomagaj cych skomplikowane procesy biznesowe. Specyfika fragmentu
wyodr bnionego jest ci le uzale niona od charakteryzuj cego go operatora interakcji
(ang. interaction operator).
2SHUDWRU LQWHUDNFML VWDQRZL VSUHF\]RZDQLH IXQNFMRQDOQR FL UHDOL]RZDQHM SU]H] IUDJ
PHQW Z\RGU�EQLRQ\
Fragment wyodr bniony wyst puje w formie obramowanej z wyszczególnieniem na-
główka. W nagłówku obligatoryjnie umieszczony jest operator charakteryzuj cy spe-
cyfik danego fragmentu wyodr bnionego wraz z ewentualnymi parametrami, zapisa-
ny w nast puj cej konwencji:
[]
Specyfikacj fragmentu wyodr bnionego zamieszczono na rysunku 7.20.
Na diagramach sekwencji identyfikuje si fragmenty wyodr bnione, a nast pnie defi-
niuje z wykorzystaniem nast puj cych operatorów interakcji b d cych terminami an-
gielskimi lub ich skrótami (por. tabela 7.3):
196 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
Fragment
wyodr bniony
i jego elementy
t alt  alternatywa,
t opt  opcja,
t break  przerwanie,
t loop  iteracja,
t neg  funkcjonalno ć nieprawidłowa,
t par  współbie no ć,
t critical  obszar krytyczny,
t assert  formuła,
t consider  istotno ć,
t ignore  nieistotno ć,
t stricte  cisłe uporz dkowanie,
t seq  słabe uporz dkowanie.
Fragment wyodr bniony składa si z jednego lub wielu operandów interakcji (ang.
interaction operands).
2SHUDQG LQWHUDNFML VWDQRZL RGG]LHOQń F]� Ł IUDJPHQWX Z\RGU�EQLRQHJR VXE
IUDJPHQW
Reguły tworzenia i u ytkowania operandów interakcji s zró nicowane i uwarunko-
wane specyfik konkretnego fragmentu wyodr bnionego, co zaznacza si odpowied-
nim operatorem interakcji w nagłówku fragmentu wyodr bnionego. I tak:
t we fragmentach wyodr bnionych oznaczonych operatorami opt, loop oraz neg
wyst puje jeden i tylko jeden operand interakcji;
t dla fragmentów wyodr bnionych oznaczonych operatorem alt mo e wyst pić
wiele operandów, jednak realizowany jest tylko jeden z nich, stosownie
do wykonania warunku zapisanego w operandzie;
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 197
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
t je li fragment wyodr bniony oznaczony jest operatorem par, wszystkie
składaj ce si na niego operandy wykonywane s równolegle;
t we fragmentach wyodr bnionych oznaczonych pozostałymi operatorami
poszczególne operandy interakcji wykonywane s sekwencyjnie.
Operandy interakcji umieszczane s w ramach fragmentu wyodr bnionego w układzie
pionowym. Poszczególne operandy oddzielane s przez separatory w postaci linii prze-
rywanej. Separatory naturalnie nie wyst puj we fragmentach wyodr bnionych wy-
korzystuj cych operatory opt, loop oraz neg. W przypadku operatorów alt i opt w ob-
szarze operandu nale y zapisać warunek, który musi być spełniony, aby interakcja
operandu została zrealizowana. Sposób specyfikowania warunków dla operandów za-
mieszczono na rysunku 7.21 oraz 7.22.
Tabela przedstawia list operatorów interakcji (tabela 7.4). Ka dy z nich jednoznacz-
nie charakteryzuje specyficzne cechy opisywanych fragmentów wyodr bnionych. W ko-
lejnych kolumnach tabeli zamieszczono:
t nazw operatora interakcji,
t operator,
t interpretacj istoty operatora interakcji,
t odwołania do rysunków ilustruj cych fragmenty wyodr bnione dla adekwatnych
operatorów.
7DEHOD Operatory interakcji na diagramach sekwencji
3H�QD QD]ZD
2SHUDWRU ,QWHUSUHWDFMD 5\VXQNL
RSHUDWRUD
alternatywa alt Oznacza mo liwo ć wyboru jednego i tylko jednego spo ród 7.21
wszystkich operandów danego fragmentu wyodr bnionego.
Wybór ten jest dokonywany na podstawie warunku
przypisanego do operandu. Warunki mog być opisane
w sposób jawny albo niejawny. Okre lenie warunku jawnego
nast puje poprzez jego umieszczenie w obszarze danego
operandu. Pomini cie takiego zapisu oznacza, e warunek
ten jest domy lny.
opcja opt Oznacza, e operand we fragmencie wyodr bnionym 7.22
wyst pi lub zostanie pomini ty.
przerwanie break Jest skrócon form operatora alt. Wyst puje w sytuacji, 7.23
gdy na diagramie istnieje tylko jeden ci le zdefiniowany
operand, natomiast otoczenie fragmentu wyodr bnionego
potraktowane zostaje w kategoriach drugiego operandu.
W momencie wykonania fragmentu wyodr bnionego
oznaczonego operatorem break otaczaj ce go interakcje
s ignorowane.
198 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
7DEHOD Operatory interakcji na diagramach sekwencji (ci g dalszy)
3H�QD QD]ZD
2SHUDWRU ,QWHUSUHWDFMD 5\VXQNL
RSHUDWRUD
iteracja loop Oznacza powtarzanie operandu okre lon ilo ć razy. Dolna 7.24,
i górna liczba iteracji mo e być wskazana w formie parametru, 7.25,
jak poni ej: 7.32
loop [ ( [ ,  ]  ) ]
Parametr minint jest nieujemn liczb całkowit , natomiast
maxint  liczb całkowit wi ksz od minint. W przypadku
wyspecyfikowania tylko jednego parametru p tla zostanie
wykonana wskazan ilo ć razy. Pomini cie parametrów
jest domy lnie traktowane jako wykonanie p tli od zera
do niesko czono ci.
funkcjonalno ć neg Charakteryzuje operandy, które traktowane s w kategoriach 7.25
nieprawidłowa działa nieprawidłowych. Operandy te wskazuj na wyj tki,
które musz zostać obsłu one. Do takich wyj tków
obsługiwanych w j zykach programowania (np. w j zyku
JAVA) nale m.in. bł d operacji arytmetycznej, indeks
poza zakresem, nieprawidłowy typ danych
i przepełnienie stosu.
współbie no ć par Wskazuje na równoległe wykonywanie wszystkich 7.26,
operandów danego fragmentu wyodr bnionego.
7.28
obszar critical Charakteryzuje fragment wyodr bniony stanowi cy 7.28
krytyczny zamkni t cało ć, który uzyskuje najwy szy priorytet
w realizacji interakcji. Instancje klasyfikatorów uczestnicz ce
w realizacji obszaru krytycznego nie mog uczestniczyć
w innych interakcjach. S zablokowane wył cznie
dla potrzeb wykonania interakcji obszaru krytycznego.
Interakcje wyst puj ce w otoczeniu obszaru krytycznego
i nie ingeruj ce w jego funkcjonowanie mog być
wykonywane równocze nie.
formuła assert Reprezentuje wykonanie sformalizowanego twierdzenia, 7.29
algorytmu. Jest cz sto powi zany z operatorami consider
lub ignore.
istotno ć consider Oznacza fragment wyodr bniony przedstawiaj cy zestaw 7.30
operandów zawieraj cych komunikaty, które musz zostać
wykonane w ramach danego diagramu sekwencji. Składnia
operatora jest nast puj ca:
consider  {  }
W przypadku wyst powania we fragmencie wyodr bnionym
kilku komunikatów s one oddzielane przecinkami;
np. consider {wybierzWykładowc , wybierzPracowni }
consider {wstawArtykułNaAukcj }
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 199
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
7DEHOD Operatory interakcji na diagramach sekwencji (ci g dalszy)
3H�QD QD]ZD
2SHUDWRU ,QWHUSUHWDFMD 5\VXQNL
RSHUDWRUD
nieistotno ć ignore Oznacza fragment wyodr bniony specyfikuj cy komunikaty 7.31
nie maj ce istotnego wpływu na cało ć interakcji. Komunikaty
te mog być wskazane w dowolnym miejscu na diagramie
lub zostać pomini te. Po słowie kluczowym ignore
w nawiasach klamrowych podaje si list nieistotnych
komunikatów:
ignore  {  }
W przypadku wyst powania we fragmencie wyodr bnionym
kilku komunikatów s one oddzielane przecinkami;
np. ignore {skasujPlikiTymczasowe, wyczy ćBufor}
Operator ignore mo e być jednym z parametrów
umieszczonych w nagłówku ramy diagramu sekwencji;
np. sd zarejestrujDokumenty ignore {podajNarodowo ć}
cisłe strict Wskazuje, e operandy musz być wykonywane 7.32
uporz dkowanie w niezmiennej, okre lonej na diagramie kolejno ci.
słabe seq Wskazuje, e komunikaty na ró nych liniach ycia dla 7.33
uporz dkowanie ró nych operandów mog wyst pić w dowolnym porz dku.
Praktyczne zastosowanie wyró nionych operatorów przedstawiaj rysunki 7.21  7.33.
Ka dy z przykładów zawiera:
t nazw operatora interakcji,
t szczegółow charakterystyk modelowanego przypadku biznesowego,
t diagram ilustruj cy opisan sytuacj .
200 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
$OWHUQDW\ZD DOW
System informatyczny u ytkowany w firmie pozwala na aktualizacj zamówie przechowywanych
w bazie danych. Poprzez wysłanie komunikatu pobierzZamówienie u ytkownicy systemu
mog przegl dać zamówienia przechowywane w bazie danych na formatce IZamówienie
oraz aktualizować je. Aktualizacja zamówie jest czynno ci , do wykonania której autoryzacj
maj wył cznie pracownicy działu zamówie . Dost p do zamówie przechowywanych
w bazie danych maj równie inni pracownicy firmy, w szczególno ci obsługuj cy system CRM.
Ta druga grupa pracowników nie ma jednak uprawnie , nie ma autoryzacji do modyfikowania
zamówie , tj. dokonywania operacji wprowadzania, skre lania i aktualizacji danych. W wyniku
przesłania komunikatu wy wietlZamówienie system wy wietla obydwu grupom dane
zamówienia. W przypadku komunikatu aktualizujZamówienie system identyfikuje prawo
dost pu do przeprowadzenia operacji aktualizacji danych w bazie. System realizuje komunikat
zapiszZmiany dla pracowników działu zamówie , natomiast wszystkim pozostałym
u ytkownikom system wy wietla formatk IOdmowa, realizuj c komunikat wy wietlOdmow .
sd AktuaIizacja Zamówienie w Systemie ERP
IZamówienie IOdmowa BazaDanych
U ytkownik
wy wietlZamówienie
pobierzZamówienie
aktualizujZamówienie
aIt
[autoryzacja]
zapiszZmiany
[brakAutoryzacji]
wy wietlOdmow
5\VXQHN Aktualizacja zamówienia w systemie ERP
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 201
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
2SFMD RSW
SerwerPoczty obsługuje wielu Nadawców i Odbiorców poczty elektronicznej. Odbiorcy e-maili
mog zastrzec sobie prawo do nieprzyjmowania do swoich skrzynek wiadomo ci o okre lonych
tematach. SerwerPoczty realizuje to zlecenie poprzez zało enie odpowiednich filtrów na poczt
przychodz c do odbiorców. Serwer przyjmuje listy od nadawców po otrzymaniu komunikatu
wy lijWiadomo ć. W przypadku stwierdzenia otrzymania listu z tematem nieakceptowanym
przez Odbiorc , SerwerPoczty wywołuje komunikat odrzućWiadomo ć, co zaznaczono
we fragmencie wyodr bnionym z zastosowaniem stosownego warunku. Serwer realizuje wi c
opcje przechowywania albo odrzucania wiadomo ci. W dogodnym momencie Odbiorca pobiera
poczt poprzez wysłanie komunikatu pobierzPoczt skierowanego do serwera. Odbiorca
otrzymuje zatem listy wył cznie o akceptowanych przez siebie tematach.
sd Przepływ Poczty EIektronicznej
SerwerPoczty
Nadawca Odbiorca
wy lijWiadomo ć
opt
[temat nieakceptowany]
odrzućWiadomo ć
pobierzWiadomo ć
5\VXQHN Przepływ poczty elektronicznej
202 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
3U]HUZDQLH EUHDN
Agent firmy turystycznej po zrealizowania zlecenia zwi zanego z zamówieniem wycieczki
przyst puje do wygenerowania FakturyWłasnej. Na wst pie dokonuje weryfikacji klienta,
porównuj c podany identyfikator z danymi zarejestrowanymi w obiekcie klasy Klient.
Porównanie to polega na przesłaniu komunikatu weryfikujIdentyfikator. W przypadku
wyst pienia niezgodno ci danych przechowywanych w systemie z podanymi przez Agenta,
w Logu systemowym zapisywany jest fakt zaistnienia tej niezgodno ci. Dokonuje si to
w systemie w efekcie przesłania komunikatu raportujBł d. Tym samym wystawianie faktury
zostaje przerwane. Natomiast je li dane podane przez Agenta i zawarte w obiekcie klasy Klient
s zgodne, nast puj kolejne operacje:
0 nagłówek faktury jest wypełniany na podstawie danych przechowywanych w obiekcie
klasy Klient w wyniku przesłania komunikatu wypełnijNagłówek,
0 obiekt klasy FakturaWłasna przesyła danie wypełnienia poszczególnych pozycji faktury
w postaci komunikatu wypełnijPozycje do obiektu klasy Rezerwacja.
Pozycje faktury wypełniane s danymi przechowywanymi w obiekcie klasy Rezerwacja.
Po wygenerowaniu w systemie faktury jest ona drukowana (komunikat drukuj).
sd Wypełnianie Faktury
KIient FakturaWłasna Rezerwacja Log
Agent
weryfikujIdentyfikator(id)
break
raportujBł d
wypełnijNagłówek
wypełnijPozycje
drukuj
5\VXQHN Wypełnianie faktury
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 203
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
,WHUDFMD ORRS
Klient jest zainteresowany kupnem artykułu na aukcji internetowej. W tym celu wykorzystuje
oprogramowanie znanej internetowej firmy aukcyjnej. Aby wyszukać interesuj ce go licytacje
w danej kategorii, Kupuj cy przegl da ofert wybranej firmy aukcyjnej. W tym celu wprowadza
do formatki IOfertaAukcji nazw poszukiwanego artykułu i zleca systemowi wyszukanie
(przesłanie komunikatu wyszukaj z parametrem artykuł) wszystkich licytacji, w których
przedmiotem sprzeda y jest poszukiwany artykuł. Instancja klasyfikatora IOfertaAukcji
wywołuje operacj wybierzLicytacj obiektu klasy Licytacja. Operacja ta wykonywana
jest jako p tla programowa (iteracja) i pozwala na wyszukanie wszystkich instancji klasy
Licytacja b d cych licytacjami danego artykułu. Po wybraniu wszystkich licytacji zawieraj cych
dany artykuł ich zestawienie zostaje wy wietlone poprzez wykonanie komunikatu wy wietl
na instancji klasyfikatora Licytacja.
sd Wyszukiwanie Ofert Aukcji
IOfertaAukcji Licytacja
Kupuj cy
wyszukaj(artykuł)
Ioop (1, *)
wybierzLicytacj
wy wietl(n licytacja)
5\VXQHN Wyszukiwanie ofert aukcji
204 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
)XQNFMRQDOQR Ł QLHSUDZLG�RZD QHJ
Bank prowadzi kilka osobnych kont firmy. Efektywne monitorowanie płynno ci finansowej
przedsi biorstwa wymaga dost pu do aktualnych sald kont bankowych. Dane te s przechowywane
na serwerze plików w pliku tekstowym, który jest na bie co aktualizowany. DziałFinansowy,
który oczekuje od systemu wy wietlenia aktualnych sald kont, inicjuje proces przesyłania
danych o saldach kont bankowych przechowywanych na serwerze w pliku tekstowym o nazwie
salda.txt. W tym celu wykorzystuje analityczny obiekt graniczny Saldo, który realizuje operacj
aktualizujSalda. Konkretna instancja analitycznej klasy steruj cej TransferDanych zawiera
logik sterowania procesem importowania danych z pliku tekstowego. Interfejsem po rednicz cym
jest obiekt klasy granicznej Saldo-serwer. Po uruchomieniu operacji instancji klasyfikatorów
Konto oraz SerwerPlików, TransferDanych wysyła komunikat do instancji klasyfikatora Saldo,
aby ten wy wietlił na ekranie systemu aktualne dane o saldach kont bankowych. W przypadku,
gdy plik salda.txt nie zostaje znaleziony w okre lonym miejscu na serwerze, system informuje
DziałFinansowy o tym nieprawidłowym zdarzeniu, które jako wyj tek musi zostać obsłu one
przez system.
sd Wczytanie Danych o SaIdach Kont KIientów
DziałFinansowy Saldo TransferDanych Konto Saldo-serwer SerwerPlików
aktualizujSalda
pobierzDane
Ioop
pobierzDaneKont(id,nazwa)
saldo:= pobierz(salda[])
saldo:= czytajPlik(salda.txt)
Ioop
[plik istnieje]: wy wietl(saldo)
neg
wy wietl("nie znaleziono pliku")
[brak pliku]
5\VXQHN Wczytanie danych o saldach kont klientów
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 205
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
:VSŃ�ELH QR Ł SDU
Zadaniem systemu GPS, wykorzystywanego w ratownictwie miejskim i górskim, jest ustalanie
pozycji ledzonego obiektu. SystemInformatycznyGPS, który jest cz ci systemu GPS,
obsługiwany jest przez Operatora inicjuj cego ustalanie pozycji obiektu. Elementy składowe
systemu GPS, tj. SystemInformatycznyGPS, OdbiornikGPS, SatelitaTelekomunikacyjny
i NadajnikGPS wykonuj nast puj ce funkcje równolegle (par):
0 Operator u ytkuje SystemInformatycznyGPS, któremu przekazuje numer obiektu i zleca
podaniePozycjiObiektu. Nast pnie SystemInformatycznyGPS aktualizuje pozycj ledzonego
obiektu poprzez wywołanie operacji podajPozycj na OdbiornikuGPS. OdbiornikGPS,
wykorzystuj c odebrany sygnał z SatelityTelekomunikacyjnego, ustala pozycj ledzonego
obiektu (długo ć i szeroko ć geograficzn oraz wysoko ć nad poziomem morza).
0 SatelitaTelekomunikacyjny w sposób nieprzerwany odbiera sygnały z OdbiornikaGPS
w celu skutecznego zrealizowania operacji nadawaniaSygnału.
NadajnikGPS nieprzerwanie wysyła sygnały do SatelityTelekomunikacyjnego, aby ten
odebrałSygnał, na podstawie którego OdbiornikGPS ustali lokalizacj ledzonego obiektu.
Na tej zasadzie system GPS realizuje współbie ne funkcje.
sd UstaIanie Pozycji Iedzonego Obiektu
Operator SystemInformatycznyGPS OdbiornikGPS SatelitaTelekomunikacyjny NadajnikGPS
par
podajPozycj Obiektu (nrObiektu)
długo ć, szeroko ć, wysoko ć:= ustalPozycj Obiektu(nrObiektu, sygnał)
sygnał:= nadajSygnał
odbierzSygnał(sygnał)
5\VXQHN Ustalanie pozycji ledzonego obiektu
Istnieje uproszczona forma zapisu współbie no ci operandów fragmentu wyodr bnio-
nego na diagramach sekwencji. I tak odpowiednikiem rysunku 7.26 jest rysunek 7.27.
206 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
Ustalanie pozycji
ledzonego obiektu
 skrócona
notacja
współbie no ci
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 207
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
2EV]DU NU\W\F]Q\ FULWLFDO
Integracja systemów informatycznych to rozwi zanie wykorzystywane przez dynamicznie
rozwijaj ce si przedsi biorstwa. W celu zarz dzania relacjami z klientem przedsi biorstwa
inwestuj w systemy CRM (ang. Customer Relationship Management). Operatorzy takich
systemów wprowadzaj jako ciowe i ilo ciowe dane o klientach oraz ich preferencjach.
Systemy CRM pozwalaj na wprowadzenie programów lojalno ciowych, w których przypisuje
si ró ny priorytet ró nym klientom. Klienci, którzy generuj wysokie obroty lub zyski, uzyskuj
najwy szy priorytet. W charakteryzowanym systemie priorytety przypisuje si ka demu
klientowi korporacyjnemu. SystemCRM generuje zlecenie, które poprzez wywołanie operacji
przyjmijZlecenie jest przekazywane do u ytkowanego przez firm systemu elektronicznego
obiegu informacji WFM (ang. Work Flow Management). SystemWFM wykorzystuje generator
kolejkowania. Okre la on na podstawie danych z SystemuCRM priorytet zlecenia i drog jego
realizacji. Instancja klasyfikatora Czas inicjuje wykonanie operacji od wie aj cej kolejk
realizacji zlece wykonywanych w stałych odcinkach czasu oraz archiwizacj zlece w bazie
danych ArchiwizatorZlece . Wszystkie operandy mog być realizowane równolegle, na co
wskazuje operator par i oddzielone przerywanymi liniami poszczególne operandy. W momencie
wykonania operacji kolejkujZlecenia z parametrem klientKorporacyjny, oznaczaj cej
zidentyfikowane zlecenie klienta korporacyjnego, nast puje zablokowanie realizowania
operacji wszystkich instancji klasyfikatorów poza obr bem fragmentu wyodr bnionego
oznaczonego operatorem critical. W praktyce powoduje to natychmiastowe wykonanie
zlecenia klienta korporacyjnego o najwy szym priorytecie w kolejce przy jednoczesnym
zawieszeniu pozostałych zlece , które maj ni szy priorytet i mogłyby przerwać wykonywanie
interakcji w obszarze fragmentu wyodr bnionego oznaczonego operatorem critical. Po wykonaniu
operacji kolejkujZlecenia dla klienta korporacyjnego systemy powracaj do realizowania
równoległych interakcji.
sd Współpraca Systemów CRM, WFM oraz Archiwizatora ZIece
SystemCRM SystemWFM Czas ArchiwizatorZlece
par
przyjmijZlecenie
kolejkujZlecenia(klientIndywidualny)
criticaI
kolejkujZlecenia(klientKorporacyjny)
archiwizujZlecenia(status)
5\VXQHN Współpraca systemów CRM, WFM oraz archiwizatora zlece
208 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
)RUPX�D DVVHUW
W systemie sterowania zapasami w firmie wykorzystywany jest model zapasów z zakresu
bada operacyjnych. W modelu tym monitorowany jest poziom zapasów wszystkich artykułów.
Dla ka dego towaru wyznaczony jest tzw. poziom zamówieniowy, po przekroczeniu którego
nale y zło yć zamówienie na kolejn parti towaru, aby sprostać prognozowanemu popytowi.
Wielko ć partii zakupu jest obliczana według reguły optymalizacyjnej zwanej reguł
pierwiastka kwadratowego:
2 * A * S
Q =
R + (I *U )
gdzie:
Q  optymalna partia,
A  koszt zło enia zamówienia,
S  wielko ć sprzeda y dla okresu prognozowanego,
R  jednostkowy koszt utrzymania zapasu,
I  jednostkowy koszt braku zapasu,
U  współczynnik ryzyka wyra ony prawdopodobie stwem braku zapasów.
Po obliczeniu optymalnej partii zakupu według podanej formuły nast puje natychmiastowe
przesłanie zamówienia do dostawcy danego towaru.
sd Szacowanie OptymaInej Partii Dostaw
ZapasMagazynowy ModeIZapasów PartiaZapasów Dostawa
[stanZapasów < zapasMin]: inicjujZamówienie
assert
obliczIlo ć(Q)
realizujZamówienie
5\VXQHN Szacowanie optymalnej partii dostaw
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 209
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
,VWRWQR Ł FRQVLGHU
Aukcje internetowe umo liwiaj rejestrowanie artykułów, które pó niej staj si przedmiotem
licytacji. Uczestnicy licytacji tj. Sprzedaj cy i Kupuj cy, wykorzystuj przegl darki internetowe
do uczestnictwa w licytacjach czy te ledzenia przebiegu licytacji interesuj cych ich artykułów.
Aby licytacja mogła si odbyć, Sprzedaj cy musi zarejestrować artykuł w systemie aukcji
internetowej. Czynno ć ta jest wykonywana za po rednictwem formatki IRejestracjaArtykułu
i polega na wprowadzeniu wymaganych informacji dotycz cych cech artykułu oraz atrybutów
licytacji, jak równie na wywołaniu operacji wstawArtykułNaAukcj . Nast pnie system tworzy
obiekt klasy Licytacja dzi ki odebraniu od instancji klasyfikatora IRejestracjaArtykułu
komunikatu stereotypowanego �create utwórzLicytacj . Utworzony obiekt w okre lonym
przez Sprzedaj cego terminie i czasie zostanie aktywowany, co spowoduje rozpocz cie
licytacji. Podczas rejestracji artykułu instancja klasyfikatora Licytacja wysyła komunikat
do instancji klasyfikatora Sprzedaj cy, aby ta zweryfikowała, czy na koncie Sprzedaj cego
nie wyst puj zaległo ci finansowe z tytułu obsługi jego poprzednich licytacji. Je li zaległo ć
wyst puje, system wysyła do Sprzedaj cego e-mail z ponagleniem. Realizuje si to w systemie
poprzez wywołanie operacji wy lijPonaglenie. Nale y zwrócić uwag , e wyst pienie
zaległo ci nie determinuje procesu rejestracji artykułu na aukcji internetowej i utworzenia
licytacji. A zatem za komunikaty istotne (consider) uwa a si wstawArtykułNaAukcj oraz
utwórzLicytacj . Konwencja notacji UML nakazuje tu zapisanie nazw operacji istotnych
w nawiasach klamrowych, jak równie umieszczenie nazw tych komunikatów w pentagramie
fragmentu wyodr bnionego po nazwie operatora.
sd Rejestrowanie Artykułu Na Aukcji Internetowej
IRejestracjaArtykułu Sprzedaj cy
Sprzedaj cy
consider {wstawArtykułNaAukcj , utwórzLicytacj }
wstawArtykułNaAukcj
<>
Licytacja
utwórzLicytacj
weryfikujZaległo ć(opłata)
opt
email:=
wy lijPonaglenie
5\VXQHN Rejestrowanie artykułu na aukcji internetowej  operator consider
210 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
1LHLVWRWQR Ł LJQRUH
Przykład podany na poprzednim rysunku w odniesieniu do operatora istotno ci consider pozwala
równie doskonale zilustrować znaczenie operatora ignore. Wyja niono na nim znaczenie
poszczególnych instancji klasyfikatorów (Sprzedaj cy  jako aktor, IRejestracjaArtykułu,
Sprzedaj cy  jako obiekt klasy) oraz dwóch komunikatów: wstawArtykułNaAukcj oraz
utwórzLicytacj . Dwie pierwsze operacje s uznawane za istotne. Inne wywoływane operacje
nie maj znacz cego wpływu na zarejestrowanie artykułu oraz utworzenie obiektu klasy
Licytacja. Hierarchia wa no ci tych komunikatów wynika z reguł biznesowych e-licytacji.
Wskazuj one, e wyst pienie jakiejkolwiek zaległo ci na koncie Sprzedaj cego z tytułu
obsługi poprzednich licytacji nie determinuje zainicjowania procesu rejestracji artykułu
i utworzenia licytacji w systemie. Zatem komunikaty wywołuj ce operacje weryfikujZaległo ć
oraz wy lijPonaglenie okre la si jako nieistotne w stosunku do dwóch podstawowych, wy ej
wymienionych komunikatów. Konwencja notacji operatora ignore polega na umieszczeniu
po słowie kluczowym ignore nazw komunikatów nieistotnych w nawiasach klamrowych.
Komunikaty te mog si pojawić na diagramie lub mo na je pomin ć we fragmencie
wyodr bnionym. Nie oznacza to jednak wyeliminowania tych komunikatów  wprost
przeciwnie, s one ka dorazowo wykonywane w systemie. Stosownie do tych zasad na
niniejszym rysunku jeden z tych komunikatów, weryfikujZaległo ć, przedstawiono explicite,
natomiast wy lijPonaglenie pomini to.
sd Rejestrowanie Artykułu Na Aukcji Internetowej
IRejestracjaArtykułu Sprzedaj cy
Sprzedaj cy
ignore {weryfikuj ZaIegło ć, wy IijPonagIenie}
wstawArtykułNaAukcj
<>
Licytacj a
utwórzLicytacj
weryfikujZaległo ć(opłata)
5\VXQHN Rejestrowanie artykułu na aukcji internetowej  operator ignore
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 211
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
FLV�H XSRU]ńGNRZDQLH VWULFW
Klient posiadaj cy konto bankowe mo e korzystać z kilku form płatno ci. Jedn z nich jest
uregulowanie nale no ci poprzez wystawienie czeku bankowego. W pó niejszym czasie Klient
mo e obejrzeć w formie elektronicznej wystawione przez siebie czeki. W tym celu korzysta
z konta elektronicznego za po rednictwem przegl darki internetowej. Funkcjonalno ć tego
konta pozwala na wyszukanie wszystkich czeków, które Klient wystawił w podanym
przedziale czasu. Wprowadza on dwie daty  dat Od oraz dat Do  jako parametry operacji
przegl dajCzeki, wykonywanej w wyniku przesłania komunikatu na obiekcie granicznym
e-kontoMenu. W efekcie ostatnia z wymienionych instancji klasyfikatora inicjuje komunikat
pobierzCzek przesłany do obiektu steruj cego Przegl danieCzeku. Komunikat ten przysyłany
jest z podanymi wcze niej datami jako parametrami. Wykonywanie kolejnych operacji jest
ci le okre lone (nie mo na zmienić ich kolejno ci), tote zostały one uj te we fragmencie
wyodr bnionym z operatorem strict. Obejmuje on p tl pobierania kopii kolejnych czeków
w formacie jpg i umieszczanie ich w nowym obiekcie granicznym SkanCzeku. Obiekt ten jest
tworzony poprzez wysłanie komunikatu stereotypowanego �create wy wietl ze stosownym
parametrem.
sd Weryfikacja Wystawionych Czeków
Klient e-kontoMenu Przegl danieCzeku Czek
przegl dajCzeki(dataOd, dataDo)
pobierzCzek(dataOd, dataDo)
strict
Ioop
jpg:= pobierz(dataOd, dataDo)
<>
wy wietl(jpg)
SkanCzeku
5\VXQHN Weryfikacja wystawionych czeków
212 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
OPIS
DIAGRAM
5R]G]LD� 0 'LDJUDP VHNZHQFML
6�DEH XSRU]ńGNRZDQLH VHT
U ytkownik Internetu tworzy na IPulpicie swojego systemu informatycznego ikony reprezentuj ce
skróty do najcz ciej odwiedzanych przez niego serwisów. Nale do nich:
0 Portal internetowy,
0 eSerwisUniwersytecki,
0 SystemAukcji internetowej.
Dzi ki temu u ytkownik systemu mo e wywoływać w dowolnej kolejno ci poszczególne
serwisy, wykorzystuj c odpowiednio:
0 komunikat wy wietlStron Główn Portalu,
0 komunikat wy wietlStron Główn Serwisu,
0 komunikat wy wietlStron Główn Aukcji.
sd KoIejno ć Logowania na Serwisach Internetowych
IPuIpit
U ytkownik Portal eSerwisUniwersytecki SystemAukcji
wy wietl
seq
wy wietlStron Główn Portalu
wy wietlStron Główn Serwisu
wy wietlStron Główn Aukcji
5\VXQHN Kolejno ć logowania na serwisach internetowych
3U]\ZR�\ZDQH Z\VWńSLHQLD LQWHUDNFML
W zło onych systemach zaprojektowanie realizacji danego przypadku u ycia na jed-
nym diagramie sekwencji jest trudne. Problem ten rozwi zuje si poprzez przedsta-
wienie danej interakcji na kilku ci le, logicznie powi zanych ze sob diagramach.
Cało ć interakcji syntetycznie przedstawia diagram sterowania interakcj lub imple-
mentacyjny diagram sekwencji, który z punktu widzenia powi zanych diagramów ma
charakter bazowy. Zwi zane diagramem bazowym, spójne tematycznie wyst pienia
interakcji mog być udokumentowane na oddzielnych, lecz ci le powi zanych z dia-
gramem bazowym diagramach sekwencji. St d na diagramach sekwencji, obok frag-
mentów wyodr bnionych opisywanych przez operatory interakcji, mo na modelować
przywołane wyst pienia interakcji (ang. interaction occurrences).
3U]\ZR�\ZDQH Z\VWńSLHQLH LQWHUDNFML MHVW ]DPLHV]F]DQ\P QD GLDJUDPLH ED]RZ\P
RGZR�DQLHP GR FL OH ] QLP SRZLń]DQHJR GLDJUDPX LQWHUDNFML
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 213
OPIS
DIAGRAM
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Wyst pienia te maj du e znaczenie w przypadku rozbudowanych diagramów sekwen-
cji, w których przywołuje si merytorycznie diagramy sekwencji zdefiniowane wcze-
niej w projekcie.
Zastosowanie przywoływanych wyst pie interakcji na diagramach sekwencji pozwala
na zst puj ce (ang. top-down) modelowanie interakcji w systemie. Wyst pienia te ozna-
cza si operatorem przywołania ref, zamieszczonym w pentagramie diagramu. Istniej
dwa sposoby zainicjowania wyst pie interakcji w systemie:
t poprzez komunikat,
t poprzez czynnik czasu.
W pierwszym przypadku odwołanie si do wyst pienia interakcji ref dokonywane jest
za po rednictwem komunikatu przesyłanego z diagramu bazowego przez bram do
pierwszej instancji klasyfikatora przywoływanego wyst pienia interakcji. W drugim
przypadku czynnikiem inicjuj cym jest sekwencja wyst powania elementów diagramu
bazowego, w tym obszarów przywoływanych wyst pie interakcji. Odwołanie si do
wyst pienia interakcji oznacza zawieszenie wykonywania funkcjonalno ci bazowego dia-
gramu sekwencji. Po wykonaniu pełnej funkcjonalno ci przywołanego wyst pienia inte-
rakcji nast puje przekazanie sterowania do bazowego diagramu sekwencji (rysunek 7.34).
Na aukcji internetowej wystawionych jest na licytacj wiele artykułów. W licytacji bio-
r udział aktorzy Kupuj cy i Sprzedaj cy oraz obiekty klas przechowuj ce informacje
zwi zane z przebiegiem danej aukcji: IOfertaAukcji, IPanelSteruj cy, Sprzedaj cy,
Licytacja, Artykuł, Kupuj cy. Funkcjonalno ć aukcji internetowej jest zło ona, tote nie-
które wyst pienia interakcji precyzyjnie udokumentowano na osobnych diagramach
sekwencji. Zatem w syntetycznym, bazowym diagramie sekwencji istnieje mo liwo ć
przywoływania tych udokumentowanych interakcji w postaci wyst pie interakcji ozna-
czonych operatorem ref. W przypadku aukcji internetowej zdefiniowano wcze niej
trzy wyst pienia interakcji: Rejestrowanie Artykułu na Aukcji Internetowej, Logowa-
nie oraz Licytowanie. W pierwszym i drugim przypadku czynnikiem inicjuj cym jest
sekwencja wyst powania elementów diagramu, natomiast w trzecim komunikat in_
zatwierd Sum . Przywołanie ka dego z tych wyst pie interakcji powoduje jego ak-
tywacj i zawieszenie interakcji wykonywanych na bazowym diagramie sekwencji.
Graficznie obszar wyst pienia interakcji oznaczony operatorem ref przysłania linie y-
cia instancji klasyfikatorów, które uczestnicz w interakcjach przywoływanego diagra-
mu. W modelowaniu wyst pie interakcji mo e zaistnieć problem techniczny zwi za-
ny ze wskazywaniem instancji bior cych udział w przywoływanym diagramie. Dotyczy
to sytuacji, w której dla zachowania logiki interakcji nieuniknione jest umieszczenie
pomi dzy instancjami klasyfikatorów, bior cymi udział w przywoływanym wyst pie-
niu interakcji, instancji, które nie uczestnicz w tym wyst pieniu. W takim przypadku
linia ycia instancji klasyfikatora powinna być ci gła, a zatem przykrywać obszar wyst -
pienia interakcji. Tym samym jednoznacznie wskazuje si zestaw instancji klasyfikato-
rów z diagramu bazowego, które uczestnicz w przywoływanym wyst pieniu interakcji.
214 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
Funkcjonowanie
aukcji
internetowej
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 215
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Na rysunku 7.35 zamieszczono diagram zawieraj cy odwołania do diagramów ilustru-
j cych dokonywanie transakcji oraz rejestracj kupuj cego. Pierwsze z przywoływa-
nych wyst pie interakcji wykorzystuje wszystkie instancje klasyfikatorów zamieszczo-
ne na wspomnianym rysunku, natomiast drugie  wył cznie Kupuj cego, IOfert Aukcji
oraz klas Sprzedaj cy.
sd Wybrane Funkcje Aukcji Internetowej
IOfertaAukcji IPaneISteruj cy Sprzedaj cy Licytacj a Artykuł
Kupuj cy Sprzedaj cy
seq
ref
Dokonywanie Transakcji
ref
Rejestracja Kupuj cego
5\VXQHN Wybrane funkcje aukcji internetowej
%UDP\
Diagramy sekwencji, fragmenty wyodr bnione oraz przywoływane wyst pienia inte-
rakcji kontaktuj si ze swoim otoczeniem. Otoczenie to wysyła komunikaty do wymie-
nionych obszarów interakcji lub odbiera je z tych obszarów poprzez bramy (ang. gates).
%UDPD MHVW SXQNWHP SU]HM FLD NRPXQLNDWŃZ ] GR GLDJUDPŃZ VHNZHQFML SU]\ZR�\
ZDQ\FK Z\VWńSLH� LQWHUDNFML RUD] IUDJPHQWŃZ Z\RGU�EQLRQ\FK GR ] LFK RWRF]HQLD
W zwi zku z tym mo na wyró nić nast puj ce rodzaje bram,:
t bramy formalne (ang. formal gates)  dotycz całego diagramu sekwencji;
t bramy wła ciwe (ang. actual gates)  dotycz przywoływanego wyst pienia
interakcji;
t bramy wyra eniowe (ang. expression gates)  dotycz operandów interakcji
danego fragmentu wyodr bnionego.
Zale no ci pomi dzy poj ciami zwi zanymi z bramami ilustruje rysunek 7.36. Ozna-
czenie bramy wyst puje na nim w formie stereotypu.
Praktyczne wykorzystanie poj cia bramy formalnej na diagramie sekwencji przed-
stawia rysunek 7.37. Pozostałe rodzaje bram, tj. bram wła ciw i wyra eniow , za-
prezentowano na rysunku 7.34.
216 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN Bramy w diagramach sekwencji
sd Funkcje Serwera w Sieci Barów Kawowych
Mened er SerwerPlików
prognoza:= ustalPrognoz Sprzeda y
in_zarejestrujZamkni cieDnia
(sprzeda , zu ycie, dostawa, zwrot)
out_archiwizujModyfikowanePliki
raport:= generujRaportRentowno ciRegionu
RaportRentowno ciRegionu
5\VXQHN Funkcje serwera w sieci barów kawowych
Rozległe geograficznie rozmieszczenie sieci barów kawowych mo e spowodować, e
przetwarzanie danych dziennej sprzeda y, obliczanie rentowno ci firmy czy ustalanie
prognoz sprzeda y b dzie niemo liwe do zrealizowania bez wsparcia systemu informa-
tycznego. Aby unikn ć takiej sytuacji, w centrali firmy wykorzystano du y komputer
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 217
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
SerwerPlików. Dzi ki odpowiedniemu oprogramowaniu komputer, poprzez uruchomie-
nie operacji zarejestrujZamkni cieDnia z parametrami: sprzeda , zu ycie, dostawa,
zwrot, codziennie rejestruje dane z zamkni cia dnia ka dego baru kawowego firmy. Dla
bezpiecze stwa SerwerPlików codziennie przesyła komunikatem out_archiwizujModyfi-
kowanePliki wszystkie pliki zmodyfikowane w danym dniu. Ponadto SerwerPlików
dzi ki du ej mocy obliczeniowej obsługuje generator raportów, który umo liwia Me-
ned erom generowanie prognoz sprzeda y. W tym celu Mened er wysyła komunikat
do SerweraPlików, aby ten wykonał operacj ustalPrognoz Sprzeda y. Aby generator
dostarczył raport rentowno ci regionu sprzeda y, nadawca uruchamia na SerwerzePli-
ków operacj generujeRaportRentowno ciRegionu, która powoduje utworzenie w pami -
ci komputera wspomnianego raportu. Komunikat ten przechodzi przez bram nazwan
RaportRentowno ciRegionu.
Bramy mo na nazywać dwojako:
t bezpo rednio, poprzez umieszczenie nazwy bramy przy jej graficznym
stereotypie; nazwa bramy powinna być zbie na z nazw przechodz cego
przez ni komunikatu, poniewa przez ka d bram przechodzi tylko jeden
typ komunikatu;
t po rednio, poprzez dodanie do nazwy komunikatu przechodz cego przez
bram przedrostka wskazuj cego kierunek jego przepływu,
np. in_,
out_.
Oba wymienione sposoby zaprezentowano na rysunku 7.34. Nazwa komunikatu prze-
syłanego przez bram wła ciw do przywoływanego wyst pienia interakcji ref musi
być identyczna z nazw komunikatu przesyłanego przez bram formaln powi zane-
go diagramu.
3URFHV WZRU]HQLD GLDJUDPX VHNZHQFML
Punktem wyj cia w tworzeniu diagramu sekwencji jest przypadek u ycia oraz jego
scenariusze. Kluczowe znaczenie w tworzeniu diagramu sekwencji maj wymienione
poni ej etapy:
analiza adekwatnego przypadku u ycia oraz scenariuszy tego przypadku;
identyfikacja klasyfikatorów, których instancje uczestnicz w interakcji;
opracowanie diagramu konceptualnego, zawieraj cego:
t zidentyfikowane instancje klasyfikatorów, umieszczane na osi poziomej;
t komunikaty, uporz dkowane na osi pionowej;
t o rodki sterowania, zlokalizowane na liniach ycia;
218 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
opracowanie implementacyjnego diagramu sekwencji, na podstawie opracowanego
na trzecim etapie konceptualnego diagramu sekwencji, poprzez wprowadzenie
adekwatnych do specyfikacji danego scenariusza zaawansowanych kategorii
poj ciowych, takich jak:
t rodzaje komunikatów,
t tworzenie i niszczenie obiektów,
t warunki,
t samowywoływanie,
t iteracje,
t rozgał zienia,
t fragmenty wyodr bnione i operatory interakcji,
t przywoływane wyst pienia interakcji,
t bramy;
opcjonalne sporz dzenie dla danego implementacyjnego diagramu sekwencji
wybranych wyst pieniowych diagramów sekwencji.
Podobnie jak inne diagramy, równie diagram sekwencji podlega regułom iteracyjno-
przyrostowego cyklu ycia systemu.
6WXGLXP GLDJUDPX VHNZHQFML
Niniejsze studium zawiera zło one przykłady diagramów sekwencji. Zaprezentowa-
no na nich zasady u ytkowania elementów diagramu i współzale no ci mi dzy nimi.
Poszczególne kategorie całej gamy elementów zostały szczegółowo omówione w punk-
tach 7.1  7.3. Poni ej przeanalizowano i zaprezentowano diagramy sekwencji:
t diagram implementacyjny   Generowanie raportu o kosztach realizowanych
projektów (rysunek 7.38),
t diagram wyst pieniowy   Rejestracja sprzedaj cego na aukcji internetowej
(rysunek 7.39).
Dynamicznie rozwijaj ce si firmy bardzo szczegółowo monitoruj i analizuj koszty
zwi zane z prowadzonymi projektami. W tym celu system informatyczny powinien
dostarczać kadrze mened erskiej aktualnych danych o poniesionych nakładach. Zamiesz-
czony na rysunku 7.38 diagram sekwencji przedstawia generowanie raportu o kosztach
realizowanych projektów. Na przedstawionym diagramie DyrektorDziałuProdukcji
firmy oczekuje od systemu, e ten w pierwszej kolejno ci dostarczy mu informacji
o prowadzonych projektach. Dla zainicjowania analizy kosztów posługuje si on in-
terfejsem MenuRaportów, przekazuj c komunikat generujRaportKosztówProjektów.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 219
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
5\VXQHN Generowanie raportu o kosztach realizowanych projektów
220 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN Rejestracja sprzedaj cego na aukcji internetowej
Po otrzymaniu komunikatu generujRKP z instancji klasyfikatora MenuRaportów
analityczny obiekt steruj cy GenerowanieRaportuKosztów wywołuje operacj po-
bierzDaneProjektu analitycznego obiektu przechowuj cego Projekt. Operacja ta jest
realizowana w p tli i polega na pobieraniu podstawowych danych o projektach: id,
nazwy, datyStart. Po wykonaniu opisanej p tli analityczny obiekt steruj cy Genero-
wanieRaportuKosztów tworzy poprzez komunikat stereotypowany �create interfejs
 obiekt graniczny KosztProjektu. Interfejsowi przekazywane s parametry id, nazwa,
dataStart.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 221
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Nast pnie DyrektorDziałuProdukcji wybiera projekty do analizy finansowej kosztów
osobowych tych przedsi wzi ć za po rednictwem komunikatu zatwierd Zakres. Zleca
on nast pnie przeprowadzenie analizy finansowej tych projektów za po rednictwem
komunikatu zatwierd Zakres wyliczKoszty. Dla wyselekcjonowanych projektów sys-
tem kolejno:
t iteracyjnie wybiera pracowników przypisanych do projektu za po rednictwem
komunikatu pobierzDanePracownika;
t nast pnie iteracyjnie pobiera przypisan do wybranego Pracownika stawk
z instancji klasyfikatora Koszt za po rednictwem komunikatu
pobierzStawk Pracownika;
t alternatywnie:
t dla ka dego z tych projektów wylicza stawk redni i wy wietla j
na formatce KosztProjektu,
t wylicza całkowite nakłady na poszczególne projekty i wy wietla je
na wspomnianej formatce.
Wskazana wy ej kolejno ć interakcji poszczególnych operandów nie mo e ulec zmia-
nie. Przed zamkni ciem projektu DyrektorDziałuProdukcji mo e opcjonalnie wydru-
kować zestawienie kosztów. Posługuje si w tym celu komunikatem drukuj wysyła-
nym do Drukarki.
Zaprezentowane dot d diagramy sekwencji miały charakter albo konceptualnych, albo
implementacyjnych diagramów sekwencji. Diagram zamieszczony na rysunku 7.39
stanowi przykład wyst pieniowego diagramu sekwencji słu cego do rejestracji sprze-
daj cego na aukcji internetowej.
Sprzedanie artykułu na aukcji internetowej musi zostać poprzedzone rejestracj Sprze-
daj cego oraz rejestracj artykułu b d cego przedmiotem licytacji. W celu zarejestro-
wania Sprzedaj cego wykorzystywana jest strona główna aukcji IOfertaAukcji. Za po-
rednictwem obiektu klasy steruj cej Rejestracja wywoływany jest interfejs rejestracji
danych osobowych IFormularz. Nast pnie Sprzedaj cy wprowadza wymagane dane
osobowe i wywołuje operacj walidujDane, która weryfikuje poprawno ć danych oso-
bowych wprowadzonych do IFormularza. Nast pnie obiekt steruj cy wysyła komunikat
utwórz, tworz c obiekt klasy Sprzedaj cy. Jako parametr w postaci tablicy przekazy-
wane s dane osobowe, b d ce atrybutami utworzonego obiektu. Utworzenie obiektu
klasy Sprzedaj cy skutkuje wy wietleniem komunikatu z potwierdzeniem rejestracji,
który po krótkiej chwili wy wietlania zostaje wykasowany z pami ci komputera. Takie
zachowanie systemu jest realizowane przez komunikaty wy wietl z parametrem Dane
osobowe zarejestrowane oraz zamknij.
W momencie zniszczenia interfejsu IFormularz instancja klasyfikatora Rejestracja two-
rzy za po rednictwem komunikatu utwórz interfejs IAutoryzacja. Interfejs wy wietla
pobran jako parametr tre ć Wprowad login i hasło. Kolejnym krokiem rejestracji wy-
magaj cej aktywno ci aktora Sprzedaj cy jest wprowadzenie przez niego loginu oraz
hasła. Obydwa parametry s niezb dne do autoryzowanego korzystania z pełnej oferty
aukcji internetowej. Przekazanie parametrów autoryzacji odbywa si za po rednictwem
222 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
komunikatu zatwierd z parametrami login oraz hasło, wysyłanego przez Sprzedaj -
cego do interfejsu IAutoryzacja. Parametry autoryzacji zostaj zapisane jako atrybuty
obiektu klasy Sprzedaj cy po wywołaniu przez instancj klasyfikatora IAutoryzacja
operacji zapiszDane z parametrami login oraz hasło (a w konsekwencji operacji za-
pisz z tymi samymi parametrami). W odpowiedzi obiekt klasy Rejestracja wysyła
komunikat wy wietl z parametrem Login i hasło zarejestrowane. Czekaj na aktywacj ,
który powoduje wy wietlenie parametru operacji.
Nast pnie obiekt klasy Rejestracja pobiera kod poprzez wysłanie do obiektu prze-
chowuj cego Sprzedaj cy komunikatu generujkodSprzeda y. Wygenerowany i u yty
pó niej kod pozwoli na dost p do odpowiednich modułów aukcji internetowej, które
umo liwiaj tworzenie licytacji i dokonywanie transakcji online. Wygenerowany kod-
Sprzeda y jest przekazywany jako parametr SystemowiPocztyElektronicznej, który wy-
konuje operacj wy lijWiadomo ć. Odbywa si to za po rednictwem interfejsu Poczta.
Po wykonaniu operacji na interfejsie IAutoryzacja wy wietlana jest nast puj ca tre ć:
Aktywacja uko czona pomy lnie. Tre ć ta jest przekazywana jako parametr b d cy
cz ci komunikatu wy wietl przesłanego od obiektu klasy Rejestracja. Osoba rejestru-
j ca si na aukcji mo e teraz  maj c pewno ć poprawnej rejestracji z prawami sprze-
daj cego  zamkn ć interfejs IAutoryzacja. Robi to, klikaj c odpowiedni element
interfejsu, co na diagramie przedstawione jest jako przesłanie przez Sprzedaj cego
komunikatu zamknij do interfejsu IAutoryzacja.
3RGVWDZRZH SRM�FLD
Brama Fragment interakcji
Formalna Fragment wyodr bniony
Wła ciwa Przywoływane wyst pienie interakcji
Wyra eniowa Generator kodu ródłowego
CASE Interakcja
Diagram sekwencji Iteracja
Definicja Klasyfikator
Implementacyjny Aktor
Konceptualny Artefakt
Pentagram Interfejs
Proces tworzenia Klasa
Rama Analityczna
Wyst pieniowy Komponent
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 223
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Pakiet Operator interakcji
Przypadek u ycia alt
Sygnał assert
W zeł break
Współdziałanie consider
Komunikat critical
Asynchroniczny ignore
Oczekuj cy loop
Opcjonalny neg
Synchroniczny opt
Utracony par
Znaleziony seq
Zwrotny strict
Linia ycia O rodek sterowania
Obiekt Aktywacja
Niszczenie Dezaktywacja
Tworzenie Sterowanie
Operacja Parametr
Operand interakcji Rozgał zienie
Samowywoływanie
Warunek
3\WDQLD L ]DGDQLD
Wyja nij zwi zek pomi dzy diagramami przypadków u ycia a diagramami
sekwencji.
Dlaczego diagramy sekwencji ci le odzwierciedlaj koncepcj obiektowego
modelowania systemów informatycznych?
Uzasadnij potrzeb zró nicowania poziomów uogólnienia diagramów sekwencji.
Jakie grupy zawodowe powinny być zainteresowane tworzeniem i u ytkowaniem
diagramu konceptualnego?
Który z rodzajów diagramów sekwencji jest podstawow dokumentacj
programistyczn ? Dlaczego?
224 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
Jakie s uwarunkowania przej cia z diagramu implementacyjnego
do wyst pieniowego?
Tabela 7.1 wskazuje, e poszczególne rodzaje diagramów sekwencji
wykorzystuj ró ny zakres kategorii poj ciowych odnosz cych si
do diagramów sekwencji. Wyja nij, które dokładnie kategorie poj ciowe
stosowane s na diagramach poszczególnych rodzajów.
Wyja nij istot poszczególnych kategorii poj ciowych konceptualnego
diagramu sekwencji.
Które z kategorii poj ciowych diagramu sekwencji maj podstawowe
znaczenie i dlaczego?
Jaki rodzaj klasyfikatorów najcz ciej wyst puje w praktyce na diagramach
sekwencji i dlaczego? Wska inne powszechnie u ywane na tych diagramach
rodzaje klasyfikatorów.
Dlaczego klasyfikator jest konstrukcj abstrakcyjn ?
Wska , jaka jest zale no ć pomi dzy komunikatem a operacj . W odniesieniu
do rysunku 7.3 naszkicuj klas reprezentuj c IBankomat, uwzgl dniaj c
operacje i przykładowe atrybuty.
Opisz za pomoc konceptualnego diagramu sekwencji interakcje w systemie
obsługi wy cigów konnych. Uwzgl dnij obstawienie konkretnego konia przez
gracza zawieraj cego zakład i wysoko ć stawki zakładu. Doł cz inne interakcje,
które uznasz za istotne dla funkcjonowania systemu.
Opisz trzy sposoby graficznego oznaczania obiektów na diagramach sekwencji.
Jakie informacje o klasie, której instancj jest dany obiekt, wi si
z poszczególnymi sposobami oznaczania?
Jaka jest rola o rodka sterowania? Jaki jest jego zwi zek z lini ycia?
Jak nale y interpretować aktywacj i dezaktywacj ?
Uzupełnij rysunek 7.3 o o rodki sterowania. Zastanów si , na których liniach
ycia wyst pi wi cej ni jeden o rodek sterowania.
Jakie s powody wzbogacenia podstawowego zestawu poj ć na diagramach
sekwencji o kategorie zaawansowane?
Nazwij poni sze typy komunikatów:
Które z komunikatów okre lić mo na jako kompletne?
Wyja nij ró nic pomi dzy komunikatami utraconymi a komunikatami
znalezionymi.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 225
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Jako u ytkownik portalu internetowego zilustruj poszczególne rodzaje
komunikatów wyst puj ce w trakcie jego u ytkowania. Skorzystaj z notacji
zaprezentowanej na rysunkach 7.7  7.13.
Dlaczego umieszczanie przez projektanta komunikatów zwrotnych
na diagramach sekwencji nie jest obligatoryjne?
Jakim stereotypem oznaczamy komunikat tworz cy obiekt? Podaj przykład
z zakresu u ytkowania komunikatorów internetowych.
Jakie dwa oznaczenia wprowadzane s do diagramu sekwencji w celu
poinformowania o zako czeniu istnienia danego obiektu?
Przedstaw składni komunikatów warunkowych oraz komunikatów
wykonywanych na zasadzie iteracji.
Podaj przykład warunku w odniesieniu do systemu obsługi dziekanatu.
Zaproponuj komunikat z kilkoma warunkami.
Jakim mianem okre la si wywołanie operacji przez instancj klasyfikatora,
je eli ta operacja jest jednym z elementów składowych tej instancji?
Naszkicuj implementacyjny diagram sekwencji dla przypadku u ycia  Generuj
list studentów . Funkcjonalno ć tego przypadku u ycia pozwala prowadz cemu
przedmiot wydrukować list studentów, którzy zdali egzamin w pierwszym
obowi zkowym terminie i uzyskali wynik powy ej 4.0.
Wyja nij poj cie rozgał zienia. Jakiego rodzaju rozgał zienia mo na wyró nić?
W jakich sytuacjach si je stosuje?
W systemie stypendialnym uczelni przyznaje si stypendia w zale no ci
od wysoko ci redniej ocen uzyskanej w danym roku akademickim. Opracuj
diagram sekwencji z rozgał zieniami opisuj cy ten system stypendialny
dla twojego wydziału.
Wyja nij zale no ci pomi dzy kategoriami:
t diagram sekwencji,
t interakcja,
t fragment wyodr bniony,
t operand interakcji.
W jaki sposób identyfikowane s fragmenty wyodr bnione?
Podaj składni nagłówka fragmentu wyodr bnionego.
Wymie operatory interakcji charakteryzuj ce fragmenty wyodr bnione.
Zinterpretuj podstawowe reguły tworzenia i u ytkowania operandów interakcji
w odniesieniu do konkretnych operatorów.
W odniesieniu do których operatorów interakcji zasadne jest zastosowanie
separatorów? Dlaczego?
Wska w niniejszym rozdziale rysunek ilustruj cy sytuacj analogiczn
do przedstawionej na rysunku 7.40, lecz z wykorzystaniem innej, równoznacznej
notacji. Oce podobie stwa i ró nice pomi dzy tymi notacjami.
226 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
sd ReaIizacja Kontraktu Terminowego
�system
KontraktTerminowy
Nabywca BiuroMaklerskie Bank
realizujKontrakt
ustalWarto ćBie c
wykonajKontrakt
aIt
transferujZysk
[wBie > wNom]
[wBie <= wNom]
potr ćStrat ZDepozytu
transferujDepozyt
potwierd Realizacj Kontraktu
5\VXQHN Realizacja kontraktu terminowego
Opracuj trzy diagramy wyja niaj ce zastosowanie operatora interakcji opt
w bran y telekomunikacyjnej.
Oce , czy nast puj ce sytuacje mog być udokumentowane przez operatory
interakcji break, critical czy te neg:
t wykrycie wirusa w systemie,
t pojawienie si zagro enia terrorystycznego na stadionie miejskim w kontek cie
systemu ratownictwa miejskiego,
t zidentyfikowanie włamania do systemu bankowego.
Firma posiada system CRM, który pozwala inicjować i monitorować programy
lojalno ciowe. Aby wykorzystać t funkcjonalno ć, nale y, przyjmuj c kryterium
rocznego obrotu, podzielić klientów firmy na trzy segmenty:
t powy ej miliona ,
t pomi dzy 200 tys. a milionem ,
t poni ej 200 tys. .
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 227
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Do pełnego wdro enia systemu niezb dne jest uporz dkowanie klientów
firmy w kolejno ci malej cej w ramach poszczególnych przedziałów wielko ci
obrotów. Na podstawie operatora interakcji loop opracuj diagram sekwencji
realizuj cy powy sze zało enia w systemie CRM.
Posługuj c si ródłami internetowymi, wska wyj tki standardowo obsługiwane
w j zyku programowania VB .NET. Zobrazuj je, stosuj c odpowiedni operator
interakcji.
Wykorzystuj c operator interakcji neg, przedstaw reakcje serwera poczty
elektronicznej na przesłanie wiadomo ci z bł dnie wpisanym adresem odbiorcy.
Du a biblioteka uniwersytecka u ytkuje zautomatyzowany system obsługi
wypo ycze . W systemie wyst puj nast puj ce instancje klasyfikatorów:
t aktor  Czytelnik;
t interfejsy  IZamówienieKsi ki, IKatalog;
t klasy  Czytelnik, Egzemplarz, Ksi ka, Wypo yczenie.
Wska interakcje wykonywane równolegle w tym systemie, stosuj c adekwatne
operatory interakcji.
Wykorzystuj c dane publikowane przez Eurostat (http://europa.eu.int/comm/
eurostat/), zaproponuj wska niki internetyzacji mierz ce poziom rozwoju
społecze stwa wiedzy w regionie. Wykorzystuj c j zyk UML, zdefiniuj te
wska niki na diagramie sekwencji, wykorzystuj c adekwatny operator interakcji.
Wyja nij zale no ci pomi dzy operatorami interakcji consider oraz ignore.
Zilustruj je na przykładzie oprogramowania komunikatora internetowego.
Które z interakcji zaprezentowanych na rysunku 7.17, przedstawiaj cym
wewn trzn rekrutacj pracowników do konkretnych projektów, powinny być
scharakteryzowane operatorem seq, a które strict?
Jak mo na okre lić zale no ć pomi dzy poszczególnymi operandami
zamieszczonymi na rysunku 7.41? Sprawd diagram pod k tem poprawno ci.
Popraw ewentualne bł dy.
Jakie jest uzasadnienie stosowania bram w diagramach sekwencji?
Czym uwarunkowane jest zró nicowanie bram?
Wska i wyja nij sposoby nazywania bram. Zmodyfikuj diagram
zaprezentowany na rysunku 7.31 poprzez dodanie bram i nadanie im nazw.
W jaki sposób rozwi zuje si problem dokumentowania zło onych
diagramów sekwencji?
Czy poprawne jest umieszczanie przywoływanych wyst pie interakcji
wewn trz fragmentów wyodr bnionych?
Uzasadnij twierdzenie, e przywoływanie wyst pie interakcji pozwala
na zst puj ce modelowanie systemów informatycznych.
228 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc
5R]G]LD� 0 'LDJUDP VHNZHQFML
5\VXQHN
sd Oprogramowanie Narz dziowe Serwera
Oprogramowanie
narz dziowe serwera
Administrator Czas Serwer
par
uruchomSkanerAntywirusowy
odbierzPoczt
wy lijPoczt
archiwizujDane
usu PlikiTymczasowe
Wykorzystuj c instancje klasyfikatorów z rysunku 7.28, opracuj dwa
przywoływane wyst pienia interakcji  pierwsze inicjowane za po rednictwem
komunikatu, a drugie uwzgl dniaj ce czynnik czasu.
Analityk modeluje interakcje w systemie nadzoru pomieszcze kompleksu
kinowego. Mened erowie kompleksu kinowego chc , aby w sytuacji zagro enia
projektowany system informował odpowiednie słu by publiczne w celu
umo liwienia szybkiej interwencji. Analityk ustalił kompletn list instancji
klasyfikatorów bior cych udział w interakcji. Pi ć pierwszych instancji
klasyfikatorów to elementy składowe systemu wbudowanego, a wi c zestawu
sprz tu oprogramowanego. Firma specjalizuj ca si w monitorowaniu
bezpiecze stwa pomieszcze dostarczyła dokumentacj , na podstawie której
zidentyfikowano podstawowe operacje klas systemu wbudowanego. Analityk
nie zidentyfikował dotychczas dalszych komunikatów i operacji. Na podstawie
rysunku 7.42 zaproponuj dalsze interakcje i uzupełnij diagram o fragmenty
wyodr bnione.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc (05-11-10) 229
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
ModeIReakcji Sekcja Pomieszczenie IPaneI
Czujnik OperatorSystemuNadzoru SystemPolicji SystemStra y SystemPogotowia
pobierzStruktur
pobierzParametry
odczytajSygnał
sprawdzWyst pienie
uruchomAlarm
5\VXQHN System nadzoru pomieszcze kompleksu kinowego
230 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\07.doc