Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. [phone]

e-mail: [e-mail]

UML 2.0.
Wprowadzenie

Najtrudniejszym etapem ka¿dego procesu tworzenia systemu informatycznego jest
wykonanie odpowiedniego projektu. Umiejêtnoœæ pogodzenia wymagañ u¿ytkowników
i osób finansuj¹cych system z mo¿liwoœciami oferowanymi przez technologiê jest
kluczowym elementem sukcesu. Im bardziej z³o¿ony system, tym bardziej zawi³y staje
siê projekt. Koniecznoœæ ustandaryzowana technik projektowania systemów zaowocowa³a
powstaniem narzêdzi, dziêki którym nawet najbardziej skomplikowany projekt mo¿na
przedstawiæ w prosty i czytelny sposób. Takim narzêdziem jest notacja UML — zestaw
ikon tworz¹cych diagramy opisuj¹ce system i jego elementy.

Ksi¹¿ka „UML 2.0. Wprowadzenie” w praktyczny sposób przedstawia techniki
modelowania systemów informatycznych za pomoc¹ jêzyka UML 2.0. Czytaj¹c j¹,
nauczysz siê graficznie przedstawiaæ otoczenie systemu, wymagania stawiane przez
u¿ytkowników i metody ich implementacji w systemie. Utworzysz diagramy klas,
interakcji, komponentów, wdro¿enia i inne, które opisuj¹ projekt w jednoznaczny oraz
prosty sposób. Dowiesz siê tak¿e, jak zaplanowaæ proces wdro¿enia produktu za
pomoc¹ UML.

• Elementy jêzyka UML
• Modelowanie wymagañ za pomoc¹ przypadków u¿ycia
• Diagramy czynnoœci i sekwencji
• Modelowanie klas i powi¹zañ pomiêdzy nimi
• Diagramy komponentów
• Podzia³ modelu na pakiety
• Modelowanie wdro¿enia systemu

Poznaj nowoczesne metody projektowania systemów informatycznych

Russ Miles, Kim Hamilton
T³umaczenie: Rafal Szpoton
ISBN: 978-83-246-0632-0
Tytu³ orygina³u:

Learning UML 2.0

Format: B5, stron: 280

3

Spis tre

ļci

Przedmowa .....................................................................................................................7

1. Wst

ýp ..............................................................................................................................11

2. Modelowanie wymaga

ħ: przypadki użycia ................................................................29

Wychwytywanie wymagaþ systemowych

31

ZaleĔnoĈci pomiödzy przypadkami uĔycia

39

Przeglñdowe diagramy przypadków uĔycia

47

Co dalej?

49

3. Modelowanie przep

ĥywu czynnoļci w systemie: diagramy aktywnoļci .................. 51

Podstawy diagramów aktywnoĈci

52

CzynnoĈci a akcje

54

Wözäy decyzyjne oraz poäñczenia

55

Jednoczesne wykonywanie wielu zadaþ

58

Zdarzenia czasowe

59

Wywoäywanie innych czynnoĈci

60

Obiekty

61

Nadawanie oraz odbieranie sygnaäów

63

Rozpoczynanie czynnoĈci

65

Koþczenie czynnoĈci oraz przepäywów

65

Partycje (tory päywackie)

67

Zarzñdzanie zäoĔonymi diagramami czynnoĈci

68

Co dalej?

70

4. Modelowanie struktury logicznej systemu: klasy oraz ich diagramy ........................ 71

Czym jest klasa?

71

Podstawy klas w jözyku UML

74

WidocznoĈè

75

Stan klasy: atrybuty

79

4

_

Spis tre

ļci

Zachowanie klasy: operacje

83

Statyczne czöĈci klas

85

Co dalej?

88

5. Modelowanie struktury logicznej systemu: zaawansowane diagramy klas ............89

Zwiñzki pomiödzy klasami

89

Ograniczenia

97

Klasy abstrakcyjne

98

Interfejsy

100

Szablony

103

Co dalej?

104

6. Powo

ĥywanie klas do istnienia: diagramy obiektów ............................................... 107

Instancje obiektów

107

Poäñczenia

109

Wiñzanie szablonów klas

111

Co dalej?

112

7. Modelowanie uporz

édkowanych interakcji: diagramy sekwencji ...........................113

Uczestnicy na diagramie sekwencji

114

Czas

115

Zdarzenia, sygnaäy oraz komunikaty

116

Belki aktywacji

117

Komunikaty zagnieĔdĔone

118

Strzaäki komunikatów

119

OĔywianie przypadku uĔycia za pomocñ diagramu sekwencji

123

Zarzñdzanie zäoĔonymi interakcjami za pomocñ fragmentów sekwencji

129

Co dalej?

133

8. Po

ĥéczenia opisujéce interakcjý: diagramy komunikacji .......................................... 135

Uczestnicy, poäñczenia oraz komunikaty

135

Uzupeänianie interakcji za pomocñ diagramu komunikacji

139

Diagramy komunikacji a diagramy sekwencji

142

Co dalej?

145

9. Harmonogramowanie interakcji: diagramy czasowe .............................................. 147

Jak wyglñdajñ diagramy czasowe?

147

Tworzenie diagramu czasowego na podstawie diagramu sekwencji

149

Umieszczanie uczestników na diagramie czasowym

150

Stany

150

Czas

151

Linia stanu uczestnika

153

Zdarzenia i komunikaty

155

Spis tre

ļci

_

5

Ograniczenia czasowe

156

Rozmieszczanie uczestników na diagramie czasowym

158

Notacja alternatywna

159

Co dalej?

163

10. Uzupe

ĥnianie obrazu interakcji: przeglédowe diagramy interakcji ........................ 165

CzöĈci przeglñdowego diagramu interakcji

165

Modelowanie przypadku uĔycia za pomocñ przeglñdowego diagramu interakcji

167

Co dalej?

173

11. Modelowanie struktury wewn

ýtrznej klasy: struktury zĥożone ............................. 175

Struktury wewnötrzne

176

Prezentacja sposobu uĔycia klasy

182

Prezentacja wzorców przy uĔyciu diagramów wspóäpracy

183

Co dalej?

187

12. Zarz

édzanie czýļciami systemu oraz ich wspóĥużytkowanie:

diagramy komponentów ............................................................................................ 189

Czym jest komponent?

189

Prosty komponent w jözyku UML

190

Udostöpniane oraz wymagane interfejsy komponentu

191

Prezentacja wspóädziaäania komponentów

193

Klasy realizujñce komponent

194

Porty oraz struktura wewnötrzna

196

Widoki czarnej oraz biaäej skrzynki

199

Co dalej?

200

13. Porz

édkowanie modelu: pakiety ...............................................................................201

Pakiety

202

Przestrzenie nazw oraz klasy odwoäujñce siö do siebie

204

WidocznoĈè elementów

206

ZaleĔnoĈci pomiödzy pakietami

206

Importowanie oraz uĔywanie pakietów

207

Zarzñdzanie zaleĔnoĈciami pomiödzy pakietami

210

Stosowanie pakietów do porzñdkowania przypadków uĔycia

211

Co dalej?

212

14. Modelowanie stanu obiektów: diagramy maszyny stanowej ................................. 213

Podstawy

214

Stany

215

PrzejĈcia

216

Stany programu

219

Zaawansowane zachowanie stanu

220

6

_

Spis tre

ļci

Stany zäoĔone

222

Zaawansowane pseudostany

223

Sygnaäy

224

Maszyny stanowe protokoäu

225

Co dalej?

225

15. Modelowanie wdro

żenia systemu: diagramy wdrożenia .......................................227

WdraĔanie prostego systemu

227

WdraĔanie oprogramowania: artefakty

229

Czym jest wözeä?

232

Wözäy sprzötowe oraz Ĉrodowiska uruchomieniowego

232

Komunikacja pomiödzy wözäami

234

Specyfikacje wdroĔenia

235

Kiedy stosowaè diagram wdroĔenia?

236

Co dalej?

237

A J

ýzyk ograniczeħ obiektowych ..................................................................................239

B Dostosowywanie UML-a: profile ...............................................................................247

C Historia UML-a ............................................................................................................253

Skorowidz ....................................................................................................................259

51

ROZDZIA

Ĥ 3.

Modelowanie przep

ĥywu czynnoļci

w systemie: diagramy czynno

ļci

Przypadki uĔycia pokazujñ, co powinien robiè system. Diagramy czynnoĈci umoĔliwiajñ okreĈle-
nie tego, w jaki sposób system bödzie osiñgaä swoje zamierzone cele. Diagramy czynnoĈci przed-
stawiajñ akcje zamodelowane na wysokim poziomie oraz poäñczone razem w äaþcuch, repre-
zentujñce procesy zachodzñce w systemie. I tak na przykäad diagram czynnoĈci moĔe zostaè
uĔyty do zamodelowania czynnoĈci koniecznych do utworzenia konta pamiötnika internetowego.

Diagramy czynnoĈci sñ szczególnie przydatne w modelowaniu procesów biznesowych. Proces tego
rodzaju jest zestawem skoordynowanych zadaþ, które trzeba wykonaè, aby osiñgnñè cel bizne-
sowy, na przykäad dostarczenie zamówieþ do klientów. Niektóre z narzödzi do zarzñdzania
procesami biznesowymi (ang. business process management, w skrócie BPM — przyp. täum.) umoĔ-
liwiajñ zdefiniowanie procesów biznesowych przy uĔyciu diagramów czynnoĈci lub teĔ podob-
nej notacji graficznej, a nastöpnie ich wykonanie. Pozwala to na przykäad zdefiniowaè oraz
wykonaè przy uĔyciu prostej notacji graficznej zawierajñcej diagramy czynnoĈci proces zatwier-
dzania päatnoĈci, którego jeden z etapów stanowiè bödzie wywoäanie usäugi sieciowej zatwier-
dzajñcej transakcje wykonane przy uĔyciu kart kredytowych.

Diagramy czynnoĈci sñ jedynym diagramem UML-a w widoku procesu modelowanego sys-
temu, co wynika z rysunku 3.1.

Rysunek 3.1. Widok procesu przedstawia wysoko poziomowe procesy w systemie, do modelowania których
bardzo dobrze nadaj

ñ siö diagramy czynnoĈci

Diagramy czynnoĈci sñ jednymi z najbardziej zrozumiaäych diagramów UML-a, poniewaĔ
uĔywajñ symboli podobnych jak powszechnie stosowana notacja przepäywu (ang. flowchart
— przyp. täum.). Dlatego teĔ przydajñ siö one do opisywania procesów dla szerszego audytorium.

52

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

W rzeczywistoĈci diagramy czynnoĈci, podobnie jak diagramy stanów, pochodzñ od diagramów
przepäywów.

Podstawy diagramów czynno

ļci

Przyjrzyjmy siö podstawowym elementom diagramów czynnoĈci, modelujñc przy okazji proces
napotkany wczeĈniej w tej ksiñĔce, to znaczy czynnoĈci zdefiniowane w przypadku uĔycia opi-
sujñcym tworzenie konta pamiötnika internetowego. Tabela 3.1 zawiera opis przypadku uĔycia
o nazwie

Utwórz nowe konto pami

Ătnika

(oryginalnie byäa to tabela 2.2). Proces tworzenia

konta pamiötnika internetowego opisujñ sekcje „Gäówny przepäyw wykonania” oraz „Rozsze-
rzenia”.

Tabela 3.1. Opis przypadku u

Ĕycia o nazwie Utwórz nowe konto pamiötnika

Nazwa przypadku u

życia

Utwórz nowe konto pami

ýtnika

Powi

ézane wymagania

Wymaganie A.1.

Kontekst zadaniowy

Nowy lub ju

ż istniejécy autor żéda od administratora utworzenia nowego konta pamiýtnika

internetowego.

Warunki wst

ýpne

System dost

ýpny jest dla rozpoznanych autorów. W zwiézku z tym autor musi dysponowaë

odpowiednim potwierdzeniem to

żsamoļci.

Warunek pomy

ļlnego zakoħczenia

Dla autora tworzone jest nowe konto pami

ýtnika.

Warunek niepomy

ļlnego zakoħczenia

Wniosek o nowe konto pami

ýtnika jest odrzucany.

Aktorzy g

ĥówni

Administrator.

Aktorzy drugoplanowi

Baza danych z danymi autorów.

Wyzwalacz

Administrator

żéda od systemu CMS utworzenia nowego konta pamiýtnika internetowego.

Krok

Akcja

1.

Administrator prosi system o utworzenie nowego konta pami

ýtnika.

2.

Administrator wybiera rodzaj konta.

3.

Administrator wprowadza szczegó

ĥowe dane autora.

4.

Szczegó

ĥowe dane autora sé weryfikowane przy użyciu informacji pobranych

z bazy danych autorów.

5.

Tworzone jest nowe konto pami

ýtnika.

G

ĥówny przepĥyw wykonania

6.

Podsumowanie informacji o nowym koncie pami

ýtnika jest przesyĥane

do autora poczt

é elektroniczné.

Krok

Rozga

ĥýziona akcja

4.1.

Informacje uzyskane z bazy danych nie pozwalaj

é na potwierdzenie danych

autora.

Rozszerzenia

4.2.

Wniosek o utworzenie nowego konta pami

ýtnika jest odrzucany.

Na rysunku 3.2 przedstawiony zostaä proces tworzenia konta pamiötnika internetowego zapi-
sany przy uĔyciu notacji diagramu czynnoĈci. Diagram czynnoĈci przydaje siö w tej sytuacji,
poniewaĔ pozwala w lepszy sposób zobrazowaè akcje opisane w przypadku uĔycia (w porów-
naniu z notacjñ tablicy zastosowanñ w opisie przypadku uĔycia), a szczególnie te rozgaäözione,
które zaleĔñ od tego, czy dane autora zostanñ zweryfikowane.

Podstawy diagramów czynno

ļci

_

53

Rysunek 3.2. Diagramy czynno

Ĉci modelujñ dynamiczne zachowanie systemu, koncentrujñc siö na procesach.

Podstawowe elementy diagramów czynno

Ĉci przedstawione zostaäy na podstawie procesu tworzenia konta

pami

ötnika internetowego

Z rysunku 3.2 wynika, Ĕe wykonanie czynnoĈci rozpoczyna siö w jej wöĒle poczñtkowym (ang. ini-
tial node — przyp. täum.) przedstawionym pod postaciñ wypeänionego koäa. Wözeä poczñtkowy
oznacza najzwyczajniej poczñtek czynnoĈci. Na drugim koþcu diagramu wystöpuje wözeä koþ-
cowy czynno

Ĉci (ang. activity final node — przyp. täum.) oznaczajñcy jej koniec i przedstawiony

pod postaciñ dwóch koncentrycznych kóä, z których Ĉrodkowe jest wypeänione.

Pomiödzy wözäem poczñtkowym a koþcowym czynnoĈci wystöpujñ akcje (ang. actions) obra-
zowane za pomocñ prostokñtów o zaokrñglonych naroĔnikach. Akcje sñ waĔnymi krokami
w danej czynnoĈci, np.

Wybierz rodzaj konta

,

Wprowad

ş dane autora

itd. Akcjñ moĔe byè

wykonane dziaäanie, obliczenie lub dowolny kluczowy krok procesu.

Przepäyw czynnoĈci przedstawiony jest przy uĔyciu strzaäek nazywanych krawödziami (ang. edges)
lub ĈcieĔkami (ang. pathes). Strzaäka na koþcu wskazuje kierunek przepäywu od jednej akcji do
kolejnej. Linia przychodzñca do danego wözäa nazywana jest krawödziñ wchodzñcñ (ang. inco-
ming edge), zaĈ wychodzñca z niego nazywana jest krawödziñ wychodzñcñ (ang. outgoing edge).

54

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Krawödzie äñczñ akcje ze sobñ, okreĈlajñc caäkowity przepäyw czynnoĈci. Na poczñtku aktywny
staje siö wözeä poczñtkowy, nastöpnie ten o nazwie

Popro

Ł system o utworzenie nowego konta

pami

Ătnika internetowego

i tak dalej.

Pierwszy z wözäów zaprezentowanych w postaci rombu nazywany jest decyzyjnym (ang. decision)
i odpowiada blokowi instrukcji typu if-else w kodzie programu. NaleĔy zauwaĔyè, Ĕe od wözäa
decyzyjnego na rysunku 3.2 odchodzñ dwie krawödzie wychodzñce, z których kaĔda nazwana
jest zgodnie z wynikiem warunku logicznego. W rzeczywistoĈci wykonywana jest tylko jedna
krawödĒ w zaleĔnoĈci od tego, czy dane autora zostanñ potwierdzone, czy nie. Drugi wözeä
w postaci rombu nazywany jest poäñczeniem (ang. merge). Poäñczenie äñczy ze sobñ krawödzie
wychodzñce z wözäa decyzyjnego, oznaczajñc w ten sposób koniec zachowania warunkowego.

Säowo „przepäyw” zostaäo juĔ poprzednio uĔyte kilkukrotnie i czytelnik moĔe sobie zadaè pyta-
nie, co w takim razie päynie. OdpowiedĒ zaleĔy od kontekstu. Zazwyczaj jest to przepäyw ste-
rowania od jednej akcji do kolejnej. Kiedy jedna akcja koþczy dziaäanie, wtedy sterowanie jest
przekazywane do drugiej. W kolejnych podrozdziaäach przekonamy siö jednak, Ĕe wraz ze ste-
rowaniem w danej czynnoĈci mogñ przepäywaè równieĔ obiekty.

Czynno

ļci a akcje

Akcje sñ aktywnymi krokami niezbödnymi do ukoþczenia procesu. Akcja moĔe byè obliczeniem,
na przykäad

Oblicz podatek

, lub zadaniem, jak na przykäad

Sprawd

ş dane autora

.

Säowo „czynnoĈè” jest bardzo czösto bäödnie uĔywane zamiast wyrazu „akcja” w celu opisania
kroku na diagramie czynnoĈci. Nie sñ one jednak toĔsame. CzynnoĈè jest modelowanym proce-
sem, jak chociaĔby mycie samochodu. Akcja jest krokiem w danej czynnoĈci, jak na przykäad

U

šycie piany

,

Sp

Īukanie

,

Wysuszenie

.

Akcje wystöpujñce w tej prostej czynnoĈci mycia samochodu przedstawione zostaäy na ry-
sunku 3.3.

Rysunek 3.3. Trzy akcje: U

Ĕycie piany, Späukanie oraz Wysuszenie tworzñ na diagramie czynnoĈè o nazwie

Umyj samochód

Na rysunku 3.3 caäa czynnoĈè umieszczona jest wewnñtrz zaokrñglonego prostokñta nazywa-
nego ramkñ czynnoĈci (ang. activity frame — przyp. täum.). Ramka czynnoĈci wykorzystywana
jest do umieszczania w niej akcji czynnoĈci i przydaje siö w sytuacji, gdy na jednym diagramie

W

ýzĥy decyzyjne oraz poĥéczenia

_

55

chcemy przestawiè wiöcej niĔ jednñ czynnoĈè. Nazwa czynnoĈci powinna zostaè umieszczona
w lewym górnym rogu ramki.

Ramka czynnoĈci jest opcjonalna i czösto moĔe byè pomijana na diagramie czynnoĈci, tak jak
ma to miejsce na alternatywnym diagramie Umyj samochód, zaprezentowanym na rysunku 3.4.

Rysunek 3.4. Ramka czynno

Ĉci moĔe zostaè pominiöta

ChociaĔ w ten sposób tracimy nazwö czynnoĈci prezentowanej na diagramie, to jednak opusz-
czenie ramki jest czösto wygodne w przypadku tworzenia prostych diagramów.

W

ýzĥy decyzyjne oraz poĥéczenia

W

özäy decyzyjne (ang. decisions — przyp. täum.) uĔywane sñ w przypadku, gdy w zaleĔnoĈci od

warunku chcemy wykonaè innñ sekwencjö akcji. Wözäy tego rodzaju sñ przedstawiane w postaci
rombu z jednñ krawödziñ wchodzñcñ oraz wieloma wychodzñcymi, tak jak pokazane zostaäo to
na rysunku 3.5.

Rysunek 3.5. Z w

özäa decyzyjnego sterowanie przekazywane jest tylko wzdäuĔ jednej krawödzi

KaĔda rozwidlona krawödĒ zawiera warunek (ang. guard condition — przyp. täum.) zapisany
w nawiasach kwadratowych. Warunki okreĈlajñ, która krawödĒ zostanie wybrana w wöĒle
decyzyjnym.

Warunki przyjmujñ wartoĈci logiczne prawda lub faäsz, na przykäad:

[Autoryzacja]

JeĔeli zmienna

authorized

ma wartoĈè true, podñĔaj zgodnie z krawödziñ wychodzñcñ

umieszczonñ przy warunku.

[wordCount >= 100]

JeĔeli zmienna

wordCount

ma wartoĈè wiökszñ lub równñ 1000, wtedy podñĔaj zgodnie

z krawödziñ wychodzñcñ umieszczonñ przy warunku.

56

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Rozwidlone przepäywy äñczñ siö ponownie w wöĒle poäñczenia (ang. merge node — przyp. täum.)
sygnalizujñcym koniec warunkowego zachowania rozpoczötego wczeĈniej w wöĒle decyzyjnym.
Poäñczenia sñ równieĔ przedstawiane przy uĔyciu rombu, ale majñ wiele krawödzi wchodzñ-
cych i tylko jednñ wychodzñcñ, co widaè na rysunku 3.6.

Rysunek 3.6. Je

Ĕeli liczba säów wynosi przykäadowo 1200, wtedy wykonywana jest akcja o nazwie

Poinformuj,

Ĕe wpis do pamiötnika jest zbyt däugi

Diagramy czynnoĈci sñ najbardziej przejrzyste, jeĔeli warunki w wözäach decyzyjnych sñ kom-
pletne oraz wzajemnie rozäñczne. Sytuacja, w której ĈcieĔki nie sñ wzajemnie rozäñczne, przed-
stawiona zostaäa na rysunku 3.7.

Rysunek 3.7. Uwaga na diagramy z wieloma warunkami przyjmuj

ñcymi wartoĈè prawda

JeĔeli towar jest w magazynie i zamówienie jest ekspresowe, wtedy dwa warunki majñ wartoĈè
logicznñ prawda. Która wiöc krawödĒ powinna zostaè wybrana? Wedäug specyfikacji UML-a
w przypadku, gdy wiele róĔnych warunków przyjmuje wartoĈè prawda, wybierana jest tylko
jedna krawödĒ, a jej wybór jest przypadkowy, chyba Ĕe okreĈli siö uporzñdkowanie krawödzi.
Wystñpieniu tej skomplikowanej sytuacji moĔna zapobiec, tworzñc warunki wzajemnie roz-

äñczne.

W

ýzĥy decyzyjne oraz poĥéczenia

_

57

Innñ sytuacjñ, której naleĔy zapobiec, sñ warunki niekompletne. Na przykäad gdyby na rysunku
3.7 nie byäo warunku okreĈlajñcego przypadek braku towaru w magazynie, wtedy w razie
zaistnienia takiej sytuacji nie moĔna by byäo wybraè Ĕadnej krawödzi wözäa decyzyjnego. Ozna-
cza to, Ĕe dana czynnoĈè zostanie zamroĔona w wöĒle decyzyjnym. Osoby modelujñce system
niekiedy pozbywajñ siö warunków, jeĔeli dana sytuacja nie wystöpuje (lub teĔ jeĔeli chcñ siö
nad niñ zastanowiè póĒniej). JednakĔe aby zminimalizowaè ryzyko nieporozumienia, powinno
siö zawsze umieszczaè warunki pokrywajñce wszystkie moĔliwe sytuacje. JeĔeli jest to moĔliwe
w danej czynnoĈci, wtedy przydatne bywa nadanie jednej ze ĈcieĔek etykiety else

1

(jak pokazano

na rysunku 3.7), co pozwoli upewniè siö, Ĕe wszystkie sytuacje sñ obsäugiwane.

JeĔeli czytelnik ma doĈwiadczenie w pracy z jözykiem UML w wersji 1.x, moĔe uwaĔaè, Ĕe
przedstawianie wözäów poäñczeþ nie jest konieczne. W jözykach z rodziny UML 1.x bardzo
czösto moĔna byäo ujrzeè wiele krawödzi rozpoczynajñcych siö w wöĒle decyzyjnym i biegnñ-
cych bezpoĈrednio do akcji, tak jak ma to miejsce na rysunku 3.8. Oznaczaäo to, Ĕe przepäywy
byäy äñczone niejawnie.

Rysunek 3.8. W UML 2.0 lepiej jest stosowa

è jak najbardziej przejrzysty zapis i jawnie zapisywaè wözäy

po

äñczenia

Poczñwszy od wersji UML 2.0, w przypadku gdy wiele krawödzi prowadzi bezpoĈrednio do
akcji, kontynuacja wszystkich wchodzñcych przepäywów jest wstrzymywana. MoĔna uniknñè
nieporozumieþ, jawnie przedstawiajñc wözäy poäñczeþ.

1

KrawödĒ oznaczona etykietñ else, tak jak w przypadku konstrukcji bloku warunkowego if-else wystöpujñcego
w wielu jözykach programowania, wybierana jest w przypadku, gdy Ĕaden z warunków nie przyjmuje wartoĈci
logicznej prawda. Tak wiöc krawödĒ ta obsäuguje domyĈlnie wszystkie sytuacje nieprzewidziane na diagra-
mie — przyp. täum.

58

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Jednoczesne wykonywanie wielu zada

ħ

RozwaĔmy przepäyw czynnoĈci zwiñzanych z montaĔem komputerów i obejmujñcych nastö-
pujñce kroki:

1.

Przygotuj obudowö.

2.

Przygotuj päytö gäównñ.

3.

Zainstaluj päytö gäównñ.

4.

Zainstaluj napödy.

5.

Zainstaluj kartö graficznñ, dĒwiökowñ oraz modem.

Jak dotñd opisaliĈmy juĔ wystarczajñco duĔo notacji diagramu czynnoĈci, aby moĔliwe byäo
zamodelowanie tego sekwencyjnego przepäywu zdarzeþ. ZaäóĔmy jednak, Ĕe caäy przepäyw
mógäby zostaè przyspieszony poprzez jednoczesne przygotowanie obudowy oraz päyty gäów-
nej, poniewaĔ obie te akcje nie zaleĔñ od siebie wzajemnie. Kroki, które zachodzñ w tym samym
czasie, sñ nazywane wspóäbieĔnymi (ang. concurrent) lub równolegäymi (ang. parallel).

Równolegäe akcje prezentowane sñ na diagramach przy uĔyciu rozwidleþ (ang. forks) oraz scaleþ
(ang. joins), w sposób zaprezentowany na fragmencie diagramu czynnoĈci przedstawionym
na rysunku 3.9.

Rysunek 3.9. Obie kraw

ödzie wychodzñce przetwarzane sñ w wöĒle rozwidlenia, w przeciwieþstwie do wözäów

decyzyjnych, które u

Ĕywajñ jedynie jednej krawödzi wychodzñcej

Po rozwidleniu na rysunku 3.9 nastöpuje rozdzielenie na dwa lub wiöcej równoczesnych prze-
päywów i akcje z nich wykonywane sñ równoczeĈnie. Na rysunku 3.9 akcje

Przygotuj obudow

Ă

oraz

Przygotuj p

ĪytĂ gĪównî

rozpoczynane sñ jednoczeĈnie.

Scalenie oznacza, Ĕe wszystkie wchodzñce akcje muszñ zakoþczyè siö, zanim bödzie mógä byè
przetwarzany dalej przepäyw za scaleniem. Rozwidlenia oraz scalenia wyglñdajñ identycznie
(oba sñ rysowane przy uĔyciu grubych linii), jednakĔe moĔna je rozróĔniè, poniewaĔ te pierw-
sze majñ wiele przepäywów wychodzñcych, podczas gdy drugie — wchodzñcych.

W szczegóäowym modelu projektu rozwidlenia mogñ zostaè uĔyte w celu reprezentacji
wielu procesów lub wielu wñtków programu.

Zdarzenia czasowe

_

59

Rysunek 3.10 przedstawia dokoþczony diagram dla przepäywu czynnoĈci zachodzñcych pod-
czas montaĔu komputerów.

Rysunek 3.10. Przep

äyw czynnoĈci zachodzñcych podczas montaĔu komputerów demonstruje, w jaki sposób

rozwidlenia oraz scalenia dzia

äajñ w kompletnym diagramie

JeĈli akcje zachodzñ równolegle, nie musi to koniecznie oznaczaè, Ĕe skoþczñ siö równoczeĈnie.
W rzeczywistoĈci jedno z zadaþ najprawdopodobniej zakoþczy siö przed innym. JednakĔe sca-
lenie nie pozwoli na kontynuacjö przepäywu zdefiniowanego za nim do czasu, aĔ wszystkie
wchodzñce przepäywy nie zostanñ zakoþczone. Na przykäad na rysunku 3.10 akcja wystöpujñca
po scaleniu o nazwie

Zainstaluj p

ĪytĂ gĪównî

zostanie wykonana jedynie po zakoþczeniu obu

wczeĈniejszych akcji —

Przygotuj obudow

Ă

oraz

Przygotuj p

ĪytĂ gĪównî

.

Zdarzenia czasowe

Niekiedy równieĔ czas jest czynnikiem w danej czynnoĈci. MoĔna chcieè zamodelowaè okres
oczekiwania, na przykäad na chociaĔby trzy dni, które muszñ upäynñè po wysäaniu towaru,
zanim bödzie mógä zostaè wysäany rachunek. MoĔe równieĔ zaistnieè koniecznoĈè zamodelo-
wania procesów, które uruchamiane sñ w regularnych odstöpach czasu, jak chociaĔby cotygo-
dniowe tworzenie kopii roboczej systemu.

Zdarzenia czasowe (ang. time events — przyp. täum.) przedstawiane sñ przy uĔyciu symbolu klep-
sydry. Rysunek 3.11 prezentuje, w jaki sposób zdarzenie czasowe moĔe zostaè uĔyte do zamo-
delowania okresu oczekiwania. Tekst umieszczony obok klepsydry (

Czekaj 3 dni

) okreĈla iloĈè

czasu, jaki musi upäynñè. KrawödĒ wchodzñca do zdarzenia czasowego oznacza, Ĕe jest ono
aktywowane tylko raz. Z rysunku 3.11 wynika wiöc, Ĕe rachunek jest wysyäany jedynie raz, a nie
co trzy dni.

Rysunek 3.11. Zdarzenie czasowe z wchodz

ñcñ krawödziñ reprezentuje oczekiwanie

Zdarzenie czasowe bez wchodzñcych przepäywów jest cykliczne (ang. recurring — przyp. täum.),
co oznacza, Ĕe jest aktywowane w odstöpach czasu podanych obok symbolu klepsydry. Z ry-
sunku 3.12 wynika, Ĕe opisywany na nim pasek postöpu jest uaktualniany co sekundö.

NaleĔy zauwaĔyè, Ĕe na rysunku 3.12 brakuje wözäa poczñtkowego. Zdarzenie czasowe jest
alternatywnym sposobem rozpoczöcia czynnoĈci. Notacja ta powinna byè uĔywana do mode-
lowania czynnoĈci wykonywanej cyklicznie.

60

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Rysunek 3.12. Zdarzenie czasowe bez wchodz

ñcych przepäywów modelu reprezentuje zdarzenie cykliczne

Wywo

ĥywanie innych czynnoļci

W miarö dodawania szczegóäów do diagramu czynnoĈci moĔe staè siö on zbyt duĔy lub teĔ ta
sama sekwencja akcji moĔe wystöpowaè na nim wiöcej niĔ raz. W takiej sytuacji moĔna zwiök-
szyè czytelnoĈè diagramu gäównego poprzez udostöpnienie szczegóäów akcji na oddzielnym
rysunku. UmoĔliwi to mniejsze zaĈmiecenie diagramu wysokiego poziomu.

Na rysunku 3.13 przedstawiony zostaä przepäyw czynnoĈci, które zachodzñ podczas montaĔu
komputerów, przeniesionych z rysunku 3.10. JednakĔe tym razem obok akcji o nazwie

Przy-

gotuj p

ĪytĂ gĪównî

umieszczony jest odwrócony do góry nogami symbol wideä sygnalizujñcy,

Ĕe jest to wözeä wywoäania czynnoĈci (ang. call activity node). Wywoäuje on czynnoĈè powiñzanñ
z jego nazwñ. Przypomina to wywoäywanie procedury w programie.

Rysunek 3.13. Aby szczegó

äy akcji Przygotuj päytö gäównñ nie zaĈmiecaäy diagramu ogólnego, zostaäy

przedstawione na kolejnym diagramie czynno

Ĉci

Wözeä o nazwie

Przygotuj p

ĪytĂ gĪównî

umieszczony na rysunku 3.13 wywoäuje czynnoĈè

Przygotuj p

ĪytĂ gĪównî

przedstawionñ na rysunku 3.14. Wözeä wywoäania czynnoĈci moĔe

zostaè skojarzony z wywoäywanñ przez niego czynnoĈciñ dziöki nadaniu im tej samej nazwy.
Wywoäanie czynnoĈci zasadniczo rozbija danñ akcjö na bardziej szczegóäowñ bez koniecznoĈci
przedstawiania wszystkich szczegóäów na jednym diagramie.

Rysunek 3.14. Diagram czynno

Ĉci o nazwie Przygotuj päytö gäównñ rozwija proces przygotowywania

p

äyty gäównej

Diagram czynnoĈci o nazwie

Przygotuj p

ĪytĂ gĪównî

dysponuje swoim wäasnym wözäem

poczñtkowym oraz koþcowym czynnoĈci. Ten ostatni wözeä oznacza koniec czynnoĈci o nazwie

Przygotuj p

ĪytĂ gĪównî

, lecz nie oznacza zakoþczenia wywoäujñcej go czynnoĈci. W momen-

cie zakoþczenia czynnoĈci o nazwie

Przygotuj p

ĪytĂ gĪównî

sterowanie zwracane jest do

Obiekty

_

61

czynnoĈci wywoäujñcej, która kontynuuje swoje dziaäanie. To kolejny powód, dla którego wywo-

äanie czynnoĈci przypomina wywoäywanie procedur w programie.

Pominiöcie ramki jest moĔliwe do zaakceptowania dla czynnoĈci ogólnych. Powinna
ona jednak byè zawsze uĔywana dla czynnoĈci wywoäywanych. Nazwa czynnoĈci
umieszczona w ramce pomoĔe skojarzyè czynnoĈci wywoäywane z wywoäujñcñ.

Obiekty

Niekiedy waĔnym aspektem modelowanego procesu sñ obiekty. PrzypuĈèmy, Ĕe firma czytelnika
zdecydowaäa o sprzedaĔy systemu CMS jako produktu komercyjnego, a on chciaäby zdefinio-
waè proces akceptacji napäywajñcych zamówieþ. KaĔdy krok w procesie akceptacji zamówieþ
bödzie potrzebowaä informacji o zamówieniu, takich jak dotyczñce päatnoĈci oraz kosztów trans-
akcji. Informacje tego rodzaju mogñ zostaè zamodelowane na diagramie czynnoĈci przy uĔyciu
obiektu

Order

, który zawieraè bödzie informacje o zamówieniu wymagane w kolejnych krokach.

Diagramy czynnoĈci oferujñ szereg sposobów modelowania obiektów w procesach.

Obiekty nie muszñ byè programowe. Na przykäad w przypadku czynnoĈci niezauto-
matyzowanego montaĔu komputerów wözeä obiektu moĔe byè uĔywany do reprezen-
towania zamówienia pracy, które rozpoczyna caäy proces.

Obrazowanie obiektów przekazywanych pomi

ýdzy akcjami

W celu ukazania danych przepäywajñcych przez czynnoĈè moĔna uĔyè na diagramach czynno-

Ĉci tak zwanych wözäów obiektów (ang. object nodes). Wözeä obiektu reprezentuje obiekt, któ-
ry jest dostöpny w okreĈlonym miejscu czynnoĈci. MoĔe on zostaè uĔyty w celu zaprezentowania
faktu, Ĕe dany obiekt jest uĔywany, tworzony lub modyfikowany przez dowolnñ z otacza-
jñcych go akcji.

Wözeä obiektu reprezentowany jest jako prostokñt, co zostaäo pokazane na diagramie przed-
stawiajñcym proces zatwierdzania zamówienia na rysunku 3.15. Wözeä obiektu

Order

sygnali-

zuje fakt jego przepäywu od akcji

Pobierz zamówienie

do

Zatwierd

ş pĪatnoŁð

.

Rysunek 3.15. W

özeä obiektu o nazwie Order podkreĈla, Ĕe jest on istotnñ informacjñ w tej czynnoĈci,

a tak

Ĕe pokazuje, które akcje go wykorzystujñ

Bardziej precyzyjny opis modelowania akcji

Pobierz zamówienie

w postaci wözäa odbioru

sygnaäu zostaä umieszczony w podrozdziale zatytuäowanym „Nadawanie oraz odbieranie
sygnaäów”.

62

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Prezentacja danych wej

ļciowych oraz wyjļciowych akcji

Rysunek 3.16 przedstawia poprzedniñ czynnoĈè z innej perspektywy, wykorzystujñcej przekaĒ-
niki danych (ang. pins). PrzekaĒniki danych sygnalizujñ, Ĕe obiekt stanowi danñ wejĈciowñ lub
wyjĈciowñ akcji.

Rysunek 3.16. Przeka

Ēniki danych w tym procesie zatwierdzania zamówienia pozwalajñ na dokäadniejszñ

specyfikacj

ö parametrów wejĈciowych oraz wyjĈciowych

Przeka

Ēnik danych wejĈciowych (ang. input pin) oznacza, Ĕe okreĈlony obiekt to dane wejĈciowe

akcji. PrzekaĒnik danych wyjĈciowych (ang. output pin) oznacza, Ĕe okreĈlony obiekt to dane
wyjĈciowe z akcji. Na rysunku 3.16 obiekt

Order

oznacza dane wejĈciowe dla akcji

Zatwierd

ş

p

ĪatnoŁð

. Jest on równieĔ danñ wyjĈciowñ akcji

Pobierz zamówienie

.

Na rysunku 3.15 oraz 3.16 przedstawione sñ analogiczne sytuacje, jednak uĔycie przekaĒników
danych pomaga uwypukliè fakt, Ĕe obiekt stanowi wymagane dane wejĈciowe oraz wyjĈciowe.
UĔycie wözäa obiektu oznacza zwyczajnie, Ĕe obiekt jest dostöpny w konkretnym punkcie czyn-
noĈci. Niemniej wözäy obiektu posiadajñ swojñ wäasnñ mocnñ stronö — pomagajñ w uwypukle-
niu przepäywu danych w czynnoĈci.

JeĔeli akcja

Zatwierd

ş pĪatnoŁð

wymaga jedynie czöĈci obiektu

Order

, a nie caäego, wtedy

moĔna uĔyè przeksztaäcenia (ang. transformation) w celu pokazania, które czöĈci sñ wymagane.
Przeksztaäcenia pozwalajñ na pokazanie, w jaki sposób dane wyjĈciowe z jednej akcji stanowiñ
dane wejĈciowe dla innej.

Z rysunku 3.17 wynika, Ĕe akcja o nazwie

Zatwierd

ş pĪatnoŁð

wymaga jako danej wejĈciowej

obiektu reprezentujñcego koszt o nazwie

Cost

, który uzyskiwany jest z obiektu

Order

, co sygna-

lizuje przeksztaäcenie okreĈlone w notatce.

Rysunek 3.17. Przekszta

äcenie pokazuje, skñd pochodzñ parametry wejĈciowe

Prezentacja zmiany stanu obiektów w czynno

ļci

Istnieje równieĔ moĔliwoĈè ukazania zmiany stanu obiektu w trakcie jego przepäywu przez
czynnoĈè. Z rysunku 3.18 wynika, Ĕe obiekt o nazwie

Order

jest w stanie nazwanym

oczekuje

przed akcjñ

Zatwierd

ş pĪatnoŁð

oraz zmienia swój stan na

zatwierdzone

zaraz po niej. Stan

obiektu przedstawiany jest w nawiasach kwadratowych.

Nadawanie oraz odbieranie sygna

ĥów

_

63

Rysunek 3.18. Ten diagram koncentruje si

ö na opisie zmiany stanu obiektu Order w trakcie procesu

zatwierdzania zamówienia

Prezentacja danych wej

ļciowych oraz wyjļciowych czynnoļci

Oprócz stanowienia danych wejĈciowych oraz wyjĈciowych akcji wözäy obiektów mogñ byè
równieĔ danymi wejĈciowymi oraz wyjĈciowymi czynnoĈci. Dane wejĈciowe oraz wyjĈciowe
czynnoĈci przedstawiane sñ w postaci wözäów obiektów leĔñcych na granicy jej ramki, tak jak
to widaè na rysunku 3.19. Tego rodzaju notacja przydatna jest do podkreĈlenia faktu, Ĕe caäa
czynnoĈè wymaga danych wejĈciowych oraz udostöpnia wyjĈciowe.

Rysunek 3.19 przedstawia obiekt

Order

w charakterze danych wejĈciowych oraz wyjĈciowych

czynnoĈci o nazwie

Zatwierd

ş pĪatnoŁð

. W sytuacji gdy przedstawiane sñ parametry wejĈciowe

oraz wyjĈciowe, wözeä poczñtkowy oraz koþcowy czynnoĈci jest usuwany z jej diagramu.

Rysunek 3.19. W

özäy obiektów mogñ byè stosowane w celu podkreĈlenia danych wejĈciowych oraz wyjĈciowych

z czynno

Ĉci

Nadawanie oraz odbieranie sygna

ĥów

CzynnoĈci mogñ wymagaè interakcji z zewnötrznymi osobami, systemami lub procesami. Na
przykäad w momencie dokonywania päatnoĈci przy uĔyciu karty kredytowej konieczne jest
sprawdzenie danych karty przy uĔyciu usäugi jej autoryzacji udostöpnianej przez jej wystawcö.

Na diagramach czynnoĈci sygnaäy (ang. signals) reprezentujñ interakcje z zewnötrznymi uczest-
nikami. Sygnaäy sñ komunikatami, które mogñ byè nadawane oraz odbieranie, tak jak ma to miej-
sce w nastöpujñcych sytuacjach:

x

Program wysyäa Ĕñdanie do wystawcy karty kredytowej w celu zaakceptowania transakcji
przy jej uĔyciu, a nastöpnie odbiera od niego odpowiedĒ (sygnaä zostaä wysäany oraz ode-
brany z punktu widzenia czynnoĈci okreĈlajñcej akceptacjö karty päatniczej).

x

Otrzymanie zgäoszenia zamówienia powoduje rozpoczöcie procesu jego obsäugi (z punktu
widzenia czynnoĈci obsäugi zamówienia sygnaä zostaä odebrany).

x

Klikniöcie przycisku powoduje wykonanie skojarzonego z nim kodu (z punktu widzenia
czynnoĈci obsäugi zdarzenia naciĈniöcia przycisku sygnaä zostaä odebrany).

x

System informuje klienta, Ĕe jego zamówienie jest opóĒnione (z punktu widzenia czynnoĈci
obsäugi zamówienia sygnaä zostaä wysäany).

64

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

W

özeä sygnaäu odbieranego (ang. receive signal node) moĔe spowodowaè uruchomienie akcji przed-

stawionej na diagramie czynnoĈci. Odbiorca sygnaäu wie, w jaki sposób ma na niego zareago-
waè, i oczekuje nadejĈcia sygnaäu w pewnym momencie, choè nie wie, kiedy to dokäadnie na-
stñpi. Wözeä sygnaäu nadawanego (ang. send signal node) wysyäa go do zewnötrznych uczestników.
W chwili gdy zewnötrzny (w stosunku do systemu — przyp. täum.) czäowiek lub system otrzyma
komunikat, w odpowiedzi na niego wykona prawdopodobnie pewnñ czynnoĈè, która nie jest
jednak modelowana na diagramie.

Rysunek 3.20 zawiera uszczegóäowione kroki z rysunku 3.19 w celu pokazania, Ĕe akcja autory-
zacji karty kredytowej wymaga komunikacji z zewnötrznym programem. Wözeä sygnaäu wycho-
dzñcego oznacza, Ĕe sygnaä jest wysyäany do zewnötrznego uczestnika. W tym przykäadzie
sygnaä jest Ĕñdaniem zatwierdzenia karty kredytowej. Sygnaäy nadawane sñ w sposób asyn-
chroniczny, co oznacza, Ĕe czynnoĈè nie musi oczekiwaè na odpowiedĒ, lecz po wysäaniu sygnaäu
kontynuuje natychmiast dziaäanie, poczñwszy od kolejnej akcji.

Rysunek 3.20. W

özäy sygnaäu nadawanego oraz odbieranego wskazujñ na interakcjö z zewnötrznymi

uczestnikami

Wözeä sygnaäu odbieranego wskazuje, Ĕe sygnaä odbierany jest z zewnötrznego procesu. W tym
przypadku system oczekuje na odpowiedĒ od wystawcy karty kredytowej. Po napotkaniu wözäa
sygnaäu odbieranego akcja oczekuje do czasu odbioru sygnaäu, a czynnoĈè jest kontynuowana
jedynie w przypadku jego otrzymania.

NaleĔy zauwaĔyè, Ĕe äñczenie sygnaäów nadawanych oraz odbieranych powoduje
w rezultacie zachowanie podobne do wywoäania synchronicznego lub oczekujñcego
na odpowiedĒ. Sygnaäy nadawane oraz odbierane sñ bardzo czösto äñczone na diagra-
mach czynnoĈci, poniewaĔ bardzo czösto zachodzi potrzeba uzyskania odpowiedzi na
te pierwsze.

JeĔeli napotkamy wözeä sygnaäu odbieranego bez przepäywu wchodzñcego, oznacza to, Ĕe
w przypadku gdy czynnoĈè zawierajñca wözeä jest aktywna, on zawsze oczekuje na sygnaä.
W przypadku przedstawionym na rysunku 3.21 czynnoĈè jest wykonywana zawsze po otrzy-
maniu zamówienia.

Rysunek 3.21. Czynno

Ĉè rozpoczynajñca siö od wözäa sygnaäu odbieranego, zastöpujñcego wystöpujñcy

zazwyczaj w

özeä poczñtkowy

Taki wözeä róĔni siö od wözäa sygnaäu odbieranego z wchodzñcñ krawödziñ, jak chociaĔby tego
o nazwie

Odbierz odpowied

ş

z rysunku 3.20. Taki wözeä sygnaäu odbieranego z wchodzñcñ

krawödziñ zaczyna oczekiwanie dopiero po zakoþczeniu poprzedniej akcji.

Ko

ħczenie czynnoļci oraz przepĥywów

_

65

Rozpoczynanie czynno

ļci

Najprostszym oraz najczöstszym sposobem rozpoczynania czynnoĈci jest uĔycie pojedynczego
wözäa poczñtkowego. WiökszoĈè diagramów, które dotñd widzieliĈmy, uĔywa tej notacji. Istniejñ
jednak równieĔ inne sposoby rozpoczynania czynnoĈci majñce specjalne znaczenie:

x

CzynnoĈè rozpoczyna siö od odebrania danych wejĈciowych, co zostaäo omówione wcze-

Ĉniej, w podrozdziale zatytuäowanym „Prezentacja danych wejĈciowych oraz wyjĈciowych
czynnoĈci”.

x

CzynnoĈè rozpoczyna siö w odpowiedzi na zdarzenia czasowe, co zostaäo omówione wcze-

Ĉniej, w podrozdziale zatytuäowanym „Zdarzenia czasowe”.

x

CzynnoĈè rozpoczyna siö w wyniku wzbudzenia przez sygnaä.

Aby zasygnalizowaè, Ĕe czynnoĈè rozpoczyna siö w wyniku wzbudzenia przez sygnaä, naleĔy
zamiast wözäa poczñtkowego uĔyè wözäa sygnaäu odbieranego. Wewnñtrz tego wözäa naleĔy okre-

Ĉliè rodzaj sygnaäu, który bödzie rozpoczynaè danñ czynnoĈè. Na rysunku 3.21 przedstawiona
zostaäa czynnoĈè rozpoczynana po otrzymaniu zamówienia.

Ko

ħczenie czynnoļci oraz przepĥywów

Do tej pory wözäy koþcowe czynnoĈci nie byäy zbyt interesujñce. W rzeczywistoĈci nie byäy one
uĔywane jako nic innego niĔ zwykäe znaczniki koþca. W realnych sytuacjach moĔna napotkaè
znacznie bardziej zäoĔone zakoþczenia procesów. Przepäywy na przykäad mogñ byè przery-
wane, ale mogñ siö teĔ koþczyè bez przerywania caäej czynnoĈci.

Przerywanie czynno

ļci

Na rysunku 3.21 przedstawiony zostaä typowy diagram czynnoĈci z pojedynczym zakoþczeniem.
NaleĔy zauwaĔyè, Ĕe istnieje tylko jedna ĈcieĔka prowadzñca do koþcowego wözäa czynnoĈci.
KaĔda akcja na tym diagramie ma szansö zakoþczenia.

Niekiedy istnieje koniecznoĈè zamodelowania procesu, który moĔe byè przerwany przez zda-
rzenie. Taka sytuacja mogäaby siö zdarzyè, gdybyĈmy na przykäad mieli däugo wykonujñcy
siö proces, który mógäby zostaè przerwany przez uĔytkownika. Natomiast w czynnoĈci obsäugi
zamówienia systemu CMS mogäaby zachodziè koniecznoĈè zaksiögowania odwoäanego za-
mówienia. Tego rodzaju przerwania mogñ byè przedstawiane przy uĔyciu obszarów przerwaþ
(ang. interruption regions).

Obszar przerwaþ oznaczany jest przy uĔyciu zaokrñglonego prostokñta narysowanego za
pomocñ linii przerywanej, otaczajñcego akcje, które mogñ zostaè przerwane, oraz zdarzenie
mogñce powodowaè przerwanie. Ze zdarzenia przerywajñcego wychodzi linia przypominajñca
bäyskawicö. Rysunek 3.22 rozszerza rysunek 3.21 poprzez dodanie obsäugi moĔliwoĈci wyco-
fania zamówienia.

JeĔeli w sytuacji przedstawionej na rysunku 3.22 proĈba wycofania zamówienia zostanie otrzy-
mana w chwili, gdy akcja o nazwie

Przetwórz zamówienie

jest aktywna, wtedy akcja ta zosta-

nie przerwana, a aktywna stanie siö

Wycofaj zamówienie

. Obszary przerwaþ odnoszñ siö jedy-

nie do zawartych w nich akcji. JeĔeli wycofanie zamówienia zostanie otrzymane w chwili, gdy
aktywna jest akcja

Dostarcz zamówienie

, wtedy nie zostanie ona przerwana, poniewaĔ nie

znajduje siö w obszarze przerwaþ.

66

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

Rysunek 3.22. Obszar przerwa

þ sygnalizuje moĔliwoĈè przerwania procesu

Niekiedy moĔna napotkaè diagramy z wieloma koþcowymi wözäami czynnoĈci,
w odróĔnieniu od takiego z wieloma przepäywami wchodzñcymi do pojedynczego
koþcowego wözäa czynnoĈci. Taki diagram jest dopuszczalny i moĔe pomóc w upo-
rzñdkowaniu wielu linii na diagramie z wieloma rozgaäözieniami. Niemniej jednak
diagramy czynnoĈci sñ zazwyczaj äatwiejsze do zrozumienia, jeĔeli zawierajñ poje-
dynczy koþcowy wözeä czynnoĈci.

Ko

ħczenie przepĥywu

Nowñ funkcjñ wersji UML 2.0 jest moĔliwoĈè pokazania koþca przepäywu bez koniecznoĈci
koþczenia caäej czynnoĈci. Wözeä koþcowy przepäywu (ang. flow final node) koþczy jedynie wäa-
snñ ĈcieĔkö, a nie caäñ czynnoĈè. Jest on oznaczany przy uĔyciu symbolu koäa z wpisanym zna-
kiem X, jak to zaprezentowano na rysunku 3.23.

Rysunek 3.23. W

özeä koþcowy przepäywu koþczy jedynie wäasnñ ĈcieĔkö, a nie caäñ czynnoĈè

Rysunek 3.23 przedstawia mechanizm wyszukiwania dla systemu CMS, z dwu sekundowym
oknem do tworzenia najlepszych moĔliwych wyników wyszukiwania. Po wystñpieniu dwu-
sekundowego opóĒnienia wyniki wyszukiwania sñ zwracane i caäa czynnoĈè, wäñczajñc akcjö

Popraw wyniki wyszukiwania

, koþczy siö. JednakĔe jeĔeli akcja

Popraw wyniki wyszukiwania

zakoþczy siö przed upäywem dwusekundowego czasu oczekiwania, wtedy nie spowoduje to
zakoþczenia caäej czynnoĈci, poniewaĔ przepäyw koþczy siö wözäem koþcowym przepäywu.

Partycje (tory p

ĥywackie)

_

67

UĔywajñc wözäa koþcowego przepäywu po rozgaäözieniu, naleĔy zachowaè ostroĔ-
noĈè. Po napotkaniu wözäa koþcowego zakoþczñ siö wszystkie inne akcje w danej
czynnoĈci (równieĔ te przed wözäem koþcowym). JeĔeli chcemy, aby wszystkie roz-
widlone akcje zakoþczyäy caäkowicie swoje dziaäanie, wtedy naleĔy dodaè scalenie.

Partycje (tory p

ĥywackie)

W czynnoĈci mogñ braè udziaä róĔni uczestnicy, jak chociaĔby róĔne grupy lub role w organi-
zacji lub systemie. PoniĔsze scenariusze wymagajñ do dokoþczenia czynnoĈci udziaäu wielu
uczestników (nazwy uczestników napisane sñ czcionkñ pochyäñ):

Czynno

Ĉè przetwarzania zamówienia

Wymaga od dziaäu logistyki dostarczenia produktu oraz od dziaäu ksiögowoĈci wystawienia
rachunku dla klienta.

Proces obs

äugi technicznej

Wymaga róĔnych poziomów obsäugi, do których naleĔñ wsparcie pierwszego poziomu, wspar-
cie rozszerzone oraz dziaä rozwoju produktu.

Aby pokazaè, za które akcje sñ odpowiedzialni dani uczestnicy, moĔna uĔyè partycji (ang. parti-
tions). Partycje dzielñ diagram na wiersze oraz kolumny (w zaleĔnoĈci od usytuowania diagramu
czynnoĈci) i zawierajñ akcje, które sñ wykonywane przez odpowiedzialne za nie grupy. Kolumny
oraz wiersze sñ niekiedy okreĈlane mianem torów päywackich (and. swimlanes).

Na rysunku 3.24 przedstawiony jest proces obsäugi technicznej uwzglödniajñcy trzy rodzaje
uczestników: wsparcie pierwszego poziomu, wsparcie rozszerzone oraz dziaä rozwoju produktu.

Rysunek 3.24. Partycje pomagaj

ñ w organizacji diagramu czynnoĈci, okreĈlajñc strony odpowiedzialne

Czytaj dalej...

68

_

Rozdzia

ĥ 3. Modelowanie przepĥywu czynnoļci w systemie: diagramy czynnoļci

OdpowiedzialnoĈè moĔe byè równieĔ zasygnalizowana przy uĔyciu adnotacji (ang. annotations).
Warto zauwaĔyè, Ĕe w takim przypadku nie istniejñ juĔ tory päywackie. W zamian nazwa
odpowiedzialnej strony jest umieszczona w nawiasach w samym wöĒle, jak pokazano to na ry-
sunku 3.25. Tego rodzaju notacja zazwyczaj sprawia, Ĕe diagram jest bardziej zwiözäy, jednakĔe
uczestnicy sñ przedstawieni mniej przejrzyĈcie niĔ w przypadku torów päywackich.

Rysunek 3.25. U

Ĕywanie adnotacji zamiast torów päywackich jest sposobem przedstawienia odpowiedzialnoĈci

bezpo

Ĉrednio w akcji

Zarz

édzanie zĥożonymi diagramami czynnoļci

Diagramy czynnoĈci posiadajñ wiele dodatkowych symboli säuĔñcych do modelowania szero-
kiego zakresu procesów. Przedstawione poniĔej podrozdziaäy zawierajñ niektóre z wygodnych
skrótów upraszczajñcych diagramy czynnoĈci.

Ĥéczniki

JeĔeli diagram czynnoĈci zawiera duĔo akcji, efektem tego moĔe byè umieszczenie na nim wielu
däugich, przecinajñcych siö linii, co spowoduje, Ĕe bödzie go trudniej odczytaè. W takiej sytu-
acji pomagajñ wäaĈnie äñczniki (ang. connectors — przyp. täum.).

ãñczniki pomagajñ uproĈciè diagramy, äñczñc krawödzie z symbolami, a nie z konkretnymi li-
niami. ãñcznik oznaczany jest za pomocñ kóäka z wpisanñ nazwñ. Nazwy äñczników przyjmujñ
najczöĈciej postaè jednoliterowñ. W przypadku rysunku 3.26 nazwñ äñcznika jest litera

n

.