IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

UML. Wprowadzenie
Autor: Sinan Si Alhir
Tumaczenie: Adam Jarczyk
ISBN: 83-7361-327-7
Tytu oryginau: Learning UML
Format: B5, stron: 252

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

W ksice UML. Wprowadzenie Sinan Si Alhir przedstawia UML i jego znaczenie,

a nastpnie prowadzi w kierunku mistrzowskiego opanowania jzyka. Najpierw dowiesz
si, jak UML wykorzystywany jest do modelowania struktury systemu. W rozdziale
powiconym diagramom klas i diagramom obiektw przedstawiono wiele poj
zwizanych z UML-em: oglnych (klasy) i szczegowych (obiekty). Nastpnie dowiesz
si, jak za pomoc diagramw przypadkw uycia modelowa funkcjonalno systemu.
Na koniec zobaczysz, w jaki sposb za pomoc diagramw komponentw i wdraania
modeluje si sposb wdroenia systemu w rodowisku fizycznym.
Nauczysz si, jak posugiwa si diagramami sekwencji i kolaboracji, jak modelowa
interakcje pomidzy skadnikami systemu, jak za pomoc diagramw stanw opisywa
cykle yciowe skadnikw systemu i jak dokumentowa czynnoci przepyww
sterowania i zakresy odpowiedzialnoci.
Od pierwszej do ostatniej strony ksiki Sinan Si Alhir koncentruje si na UML-u jako
jzyku i unika zapltania si w metodologii. Jego wywody s jasne i zwize. Kady
rozdzia koczy si zestawem wicze, ktre pozwol Ci sprawdzi Twoj coraz
wiksz znajomo jzyka UML. Pod koniec ksiki (a nawet wczeniej), powiniene
zauway swoj rosnc sympati do prostego, acz wyrazistego jzyka, jakim jest UML
i zacz stosowa go do efektywnego i profesjonalnego przekazywania wszelkich
aspektw projektowania systemw.

5RKUVTGEK
Przedmowa .......................................................................................................................9

Cz I Podstawy .....................................................................................13
Rozdzia 1. Wprowadzenie ..........................................................................................15
Co to jest UML?......................................................................................................................................16
UML i proces ..........................................................................................................................................21
Nauka UML-a.........................................................................................................................................25

Rozdzia 2. Modelowanie obiektowe .........................................................................27

Wymogi systemu zarzdzania projektami ........................................................................................27
Alfabety, sowa i zdania .......................................................................................................................28
Paradygmat obiektowy.........................................................................................................................31
Akapity ....................................................................................................................................................38
Rozdziay.................................................................................................................................................51
Dokumenty .............................................................................................................................................52

Cz II Modelowanie strukturalne......................................................55
Rozdzia 3. Diagramy klas i obiektw......................................................................57
Klasy i obiekty........................................................................................................................................58
Asocjacje i powizania ..........................................................................................................................70
Typy, klasy implementacji i interfejsy................................................................................................83
Generalizacje, realizacje i zalenoci ..................................................................................................87
Pakiety i podsystemy ............................................................................................................................94
wiczenia..............................................................................................................................................100

Spis treci

Rozdzia 4. Diagramy przypadkw uycia ............................................................105

Aktorzy..................................................................................................................................................106
Przypadki uycia .................................................................................................................................108
Asocjacje komunikacyjne....................................................................................................................111
Zalenoci .............................................................................................................................................112
Generalizacje.........................................................................................................................................117
wiczenia..............................................................................................................................................120

Rozdzia 5. Diagramy komponentw i wdroenia................................................123

Komponenty .........................................................................................................................................124
Wzy .....................................................................................................................................................126
Zalenoci .............................................................................................................................................128
Asocjacje komunikacyjne....................................................................................................................131
wiczenia..............................................................................................................................................133

Cz III Modelowanie behawioralne ................................................135

Rozdzia 6. Diagramy sekwencji i kolaboracji ......................................................137
Role ........................................................................................................................................................138
Komunikaty i bodce ..........................................................................................................................143
Interakcje i kolaboracje .......................................................................................................................144
Diagramy sekwencji ............................................................................................................................145
Diagramy kolaboracji ..........................................................................................................................153
wiczenia..............................................................................................................................................159

Rozdzia 7. Diagramy stanw...................................................................................163

Stany ......................................................................................................................................................163
Przejcia.................................................................................................................................................165
Zaawansowane diagramy stanw ....................................................................................................168
wiczenia..............................................................................................................................................170

Rozdzia 8. Diagramy aktywnoci ...........................................................................173

Stany akcji .............................................................................................................................................173
Przejcia przepywu ............................................................................................................................175
Tory pywackie.....................................................................................................................................177
Decyzje...................................................................................................................................................178
Wspbieno......................................................................................................................................179
wiczenia..............................................................................................................................................180

Spis treci

Cz IV Wyj poza UML...................................................................183

Rozdzia 9. Mechanizmy rozszerzania ....................................................................185
Architektura jzyka .............................................................................................................................186
Stereotypy .............................................................................................................................................187
Wasnoci ..............................................................................................................................................189
Profile.....................................................................................................................................................192
wiczenia..............................................................................................................................................193

Rozdzia 10. Object Constraint Language ..............................................................195

Wyraenia .............................................................................................................................................195
Ograniczenia proste.............................................................................................................................198
Ograniczenia zoone..........................................................................................................................202
wiczenia..............................................................................................................................................205

Dodatki.....................................................................................................207
Dodatek A rda ........................................................................................................209
Dodatek B Rozwizania do wicze .......................................................................211
Skorowidz .....................................................................................................................243

Wprowadzenie
W tym rozdziale przedstawi jzyk UML (ang. Unified Modeling Language ujednolicony
jzyk modelowania). Omwi powody, dla ktrych UML jest wany, i jak mona si go
nauczy, koncentrujc si na paradygmacie obiektowym, technikach modelowania
strukturalnego i behawioralnego oraz innych moliwociach UML-a. Powodw do nauczenia si i korzystania z jzyka UML jest wiele. Krtko mwic, UML jest lingua franca
systemw informacyjnych i bran technologicznych. Bardziej formalnie, UML jest jzykiem oglnego zastosowania, a zarazem standardem branowym o szerokich zastosowaniach, powszechnie obsugiwanym przez narzdzia obecne na rynku.
Konstruowanie systemw polega na tworzeniu ich zgodnie z wymaganiami, z zastosowaniem przy ich rozwoju procesu cyklu ycia. Wymagania s zasadniczo problemami do
rozwizania, system jest rozwizaniem tych problemw, za konstruowanie systemu jest
procesem rozwizywania problemw, w skad ktrego wchodz: rozpoznanie problemu,
rozwizanie problemu i implementacja rozwizania. Do opisywania wymogw su jzyki
naturalne. Jzyki programowania, a w szerszym kontekcie oparte na technologii jzyki
implementacji, np. XML, SQL, Java, C# itp., su do przekazywania (opisywania) szczegw systemu. Poniewa jzyki naturalne s mniej precyzyjne od jzykw programowania,
w procesie rozwizywania problemw do przekraczania przepaci pomidzy wymogami
i systemem su jzyki modelowania, takie jak UML.
Jzyk oglnego zastosowania, np. UML, moe by stosowany w caym procesie tworzenia
systemu, od gromadzenia wymogw, a po implementacj systemu. Poniewa UML jest
jzykiem o szerokim zakresie zastosowa, mona go uywa w rnych typach systemw,
dziedzin i procesw. Moemy dziki temu uy UML-a do opisu systemw programowych
i nieprogramowych (tzw. systemw biznesowych) w rnych dziedzinach i branach,
np. w produkcji, bankowoci, handlu elektronicznym itd. Co wicej, moemy zastosowa
UML do dowolnego procesu lub metody rozwizania. Jzyk ten obsuguje wielu producentw narzdzi, ktre s standardami branowymi; nie jest to zastrzeony lub zamknity
jzyk modelowania.

16

Rozdzia 1. Wprowadzenie

Co to jest UML?
UML jest po prostu jzykiem wizualnym, sucym do modelowania i opisywania systemw za pomoc diagramw i dodatkowego tekstu. Na przykad, rysunek 1.1 przekazuje
nastpujce informacje:
Meneder przewodzi zespoowi, ktry wykonuje projekt.
Kady meneder ma imi i numer telefonu, i moe zainicjowa lub zakoczy
(przerwa) projekt.
Kady projekt ma nazw, dat rozpoczcia i dat ukoczenia.
Kady zesp ma opis, i tylko to nas w nim interesuje.
Prosz si nie przejmowa, jeli rysunek 1.1 jest nie do koca zrozumiay. Zajmiemy si tym
rysunkiem i UML-em bardziej szczegowo w rozdziale 2.

Rysunek 1.1. Menederowie, projekty i zespoy

Trzy aspekty UML-a

Jak ju wiemy, UML jest skrtem od Unified Modeling Language (ujednolicony jzyk modelowania). Kade z tych trzech sw mwi o innym wanym aspekcie UML-a. W kilku
nastpnych podpunktach omwimy te aspekty, rozwizujc skrt od koca.

Language (jzyk)
Jzyk pozwala nam porozumiewa si na temat danego podmiotu. W konstruowaniu systemu podmiotem moe by wymg lub system. Bez jzyka trudno o komunikacj pomidzy
czonkami zespou i o wspprac, pozwalajc z powodzeniem opracowa system.
Jzyki w oglnym znaczeniu nie zawsze skadaj si z zapisanych wyrazw. Na przykad,
powszechnie uywamy jzyka rachunkowego, aby uczy dzieci liczenia i arytmetyki.
Dziecko otrzymuje ile jabek, pomaraczy, kamykw lub innych obiektw, ktre reprezentuj sob liczb. Dla dziecka przedstawieniem liczby 5 moe by pi jabek. Dziaania

Co to jest UML?

17

dodawania i odejmowania sa reprezentowane przez fizyczn czynno dodawania lub

zabierania obiektw ze zbioru dziecka. My, doroli, preferujemy zamiast tego jzyk arytmetyki, w ktrym okrelon liczb reprezentuje acuch cyfr arabskich, a dodawanie i odejmowanie reprezentowane s przez operatory + i .
Rysunek 1.2 zestawia jzyk rachunkowy dziecka z bardziej abstrakcyjnym jzykiem
arytmetycznym, uywanym przez dorosych.

Rysunek 1.2. Warto pi w dwch jzykach

Wemy teraz moliwo przedstawienia w tych dwch jzykach okrelonej liczby dni
w projekcie. Do zamodelowania i wyraenia wartoci pi jzyk rachunkowy uywa
piciu obiektw, za jzyk arytmetyczny acucha 5. Do modelowania i wyraania
wikszych wartoci, np. 365, jzyk rachunkowy wymaga 365 obiektw (co moe by niepraktyczne), za jzyk arytmetyczny stosuje cig 365. Aby zamodelowa i wyrazi
warto cztery i p jzyk rachunkowy wymaga czterech i p obiektu (ponownie, p
obiektu niekoniecznie jest praktycznym rozwizaniem), za arytmetyczny uywa acucha
4,5. Poniewa arytmetyka pozwala atwiej i bardziej praktycznie ni jzyk rachunkowy
przedstawia wartoci z szerszego zakresu, mwimy, e jzyk arytmetyczny jest bardziej
ekspresywny od rachunkowego. Oprcz tego liczb moemy wyrazi za pomoc arytmetyki
bardziej cile ni w jzyku rachunkowym. Stosujc bardziej ekspresywne jzyki, moemy
przekazywa w sposb bardziej zwizy zoone informacje o zoonych podmiotach.
Formalizujc nieco, UML jest jzykiem sucym do specyfikacji, wizualizacji, konstrukcji
i dokumentacji artefaktw procesu zorientowanego na system. Proces zorientowany na system
oznacza podejcie koncentrujce si na systemie, cznie z etapami tworzenia i utrzymania
systemu, zgodnie z wymogami, jakie ten system musi speni. Specyfikacja obejmuje tworzenie modelu opisujcego system. W procesie wizualizacji model jest tworzony i opisywany
za pomoc diagramw (model jest ide, a diagramy wyraeniem tej idei). Konstrukcja
oznacza wykorzystanie tego wizualnego obrazu do zbudowania systemu, podobnie jak
plany techniczne s uywane przy wznoszeniu budynku. Dokumentacja wykorzystuje
modele i diagramy do zarejestrowania naszej wiedzy o wymogach i systemie w obrbie
caego procesu.
UML sam w sobie nie jest procesem. Proces polega na zastosowaniu zbioru krokw, opisanych przez metodologi, do rozwizania problemu i stworzenia systemu speniajcego
wymogi uytkownika. Metoda zajmuje si jedynie czci procesu tworzenia systemu, na

18

Rozdzia 1. Wprowadzenie

przykad gromadzeniem wymogw, analiz, projektowaniem itp., natomiast metodologia

dotyczy caego procesu, od gromadzenia wymogw a do udostpnienia systemu uytkownikom. Rnorodne metody gromadzenia i wykorzystywania wymogw, analizowania wymogw, projektowania systemu itp. nosz nazw technik. Artefakty (wytwory) s
produktami pracy, tworzonymi i wykorzystywanymi w procesie; naley do nich rwnie
dokumentacja suca do komunikacji pomidzy stronami pracujcymi nad systemem
i samym fizycznym systemem. Wszystkie typy diagramw UML nazywane s rwnie
technikami modelowania.

Model
Model jest reprezentacj podmiotu. Na przykad, jak ju wspomniano, do modelowania
i wyraenia wartoci pi jzyk rachunkowy uywa piciu obiektw, za jzyk arytmetyczny cigu 5. Model rejestruje zbir zwizanych z podmiotem idei, zwanych abstrakcjami. Bez modelu bardzo trudno jest osign porozumienie pomidzy czonkami
zespou na temat wymogw i systemu oraz analizowa wpyw zmian wprowadzanych
podczas tworzenia systemu.
Jeli przy tworzeniu modelu bdziemy prbowali przedstawi jednoczenie wszystkie
informacje o danym podmiocie, z atwoci przytoczy nas objto informacji. Wane
jest wic skoncentrowanie si na rejestrowaniu liczcych si informacji, niezbdnych do
zrozumienia danego problemu, znalezienia rozwizania tego problemu i zaimplementowania rozwizania, a zarazem wykluczaniu wszelkich nieistotnych informacji, ktre mog
spowolni nasze postpy. Decydujc, ktre abstrakcje skadaj si na model, ustalajc
poziom ich szczegowoci i etapy, na ktrych bd rejestrowane w procesie konstruowania systemu, moemy lepiej zapanowa nad ogln zoonoci tworzenia systemu.

Unified (ujednolicony)
Pojcie ujednolicony bierze si z faktu, i Object Management Group (OMG) organizacja tworzca standardy powszechnie przyjmowane w przemyle razem z Rational
Software Corporation stworzyy UML w celu poczenia ze sob najlepszych metod stosowanych w systemach informacyjnych i w brany technologicznej. Do praktyk tych zalicza
si stosowanie technik, ktre pozwalaj z wikszym powodzeniem konstruowa systemy.
Bez wsplnego jzyka, nowym czonkom zespow trudno jest szybko osiga produktywno i wnosi swj wkad do tworzenia systemu.

Zadania i zakres
Poznanie zada i zakresu stosowania UML, wytyczonych przez OMG, pozwoli nam lepiej
zrozumie motywy, ktre doprowadziy do powstania tego jzyka. Wedug zaoe OMG,
UML ma by:
gotowy do uytku,
ekspresywny,

Co to jest UML?

19

prosty,
precyzyjny,
rozszerzalny,
niezaleny od implementacji,
niezaleny od procesu.
Poniewa UML jest gotowy do uytku, ekspresywny, prosty i precyzyjny, jzyk ten mona
od razu zastosowa w projekcie rozwojowym. Aby umoliwi tworzenie precyzyjnych
modeli, organizacja OMG stworzya jzyk OCL (Object Constraint Language jzyk
zawania obiektw), ktry jest podjzykiem sucym do doczania warunkw, jakie
elementy modelu musz speni, aby model mona byo uzna za poprawny (inaczej well-formed poprawnie zbudowany). OCL zosta omwiony w rozdziale 10.
Jzyk rozszerzalny pozwala definiowa nowe pojcia, co przypomina wprowadzanie
nowych sw i rozszerzanie sownictwa jzyka naturalnego. Rozszerzalno zostaa omwiona w rozdziale 9. Jzyk niezaleny od implementacji moe by uywany niezalenie
od konkretnej technologii implementacji, takiej jak Java lub .NET. Jzyk niezaleny od
procesu moe by stosowany do rnych typw procesw.
Zdefiniowany przez OMG podczas tworzenia UML zakres stosowania tego jzyka obejmowa poczenie trzech najbardziej znaczcych metod konstruowania systemw: metody
Booch 93 Gradyego Boocha, metody Object Modeling Technique (OMT) -2 Jamesa Rumbaugha oraz metody OODE (ang. Object-Oriented Software Engineering) Ivara Jacobsona, z zalecanymi praktykami inynierskimi dla systemw informatycznych i brany technologicznej.
Oddzielnie s one jedynie metodami, lecz razem tworz do kompletn metodologi.

Historia
W historii UML-a moemy wyrni pi okresw. Poznanie tych okresw pozwoli nam
zrozumie, z jakich powodw powsta UML i jak wci ewoluuje.

Okres fragmentacji
Od poowy lat 70. do poowy lat 90. organizacje zaczy zdawa sobie spraw z tego, jak
cenne jest oprogramowanie dla biznesu, lecz dysponoway tylko niepenymi zbiorami
technik tworzenia i utrzymania oprogramowania. Spord rnych powstajcych wwczas technik i metod, koncentrujcych si na bardziej wydajnym tworzeniu i utrzymaniu
oprogramowania (kada miaa wasne jzyki modelowania), wyrniay si trzy:
Metoda Gradyego Boocha Booch 93 (powstaa z Booch 91) kada nacisk
na projektowanie i tworzenie systemw oprogramowania.
Metoda Jamesa Rumbaugha OMT-2 (ang. Object Modeling Technique technika
modelowania obiektw, powstaa z OMT-1) kada nacisk na analiz systemw
oprogramowania.

20

Rozdzia 1. Wprowadzenie

Metoda Ivara Jacobsona OODE (ang. Object-Oriented Software Engineering

obiektowa technika programowania) kada nacisk na modelowanie biznesowe
i analiz wymaga.
W miar ewoluowania metod strukturalnych w kierunku metod obiektowych brana
podzielia si, na zwolennikw tych trzech (i innych) metod. Wyznawcy jednej metody
mieli kopoty ze zrozumieniem produktw entuzjastw innych metod. Oprcz tego mieli
problemy z przenoszeniem si z jednej organizacji do drugiej, poniewa taki ruch czsto
oznacza konieczno nauczenia si nowej metody. Co wicej, obsuga przez narzdzia
wahaa si od zerowej do minimalnej, poniewa metod byo tak wiele. Z tych powodw
zbyt wysokie koszty uniemoliwiay czsto uycie jakiejkolwiek metody.

Okres jednoczenia
Od poowy lat 90. do roku 1997 wyoni si jzyk UML 1.0. James Rumbaugh, a po nim
Ivar Jacobson doczyli do Gradyego Boocha w firmie Rational Software Corporation, aby
poczy swoje metody podejcia. Wysiki na rzecz unifikacji przyniosy im okrelenie
Trzej Amigo. Gdy organizacje zaczy docenia warto UML-a, zesp Object Analysis
and Design Task Force z OMG wyda dokument RFP (ang. Request for Proposal) w celu
utworzenia standardu, definiujcego znaczenia poj technologii obiektowej dla narzdzi,
ktre obsuguj analiz i projektowanie zorientowane obiektowo. Razem z rnymi innymi organizacjami firma Rational Software Corporation utworzya UML Partners Consortium i partnerzy ci zgosili do OMG wersj 1.0 UML-a jako jedn z wielu wstpnych
odpowiedzi na dokument RFP.

Okres standaryzacji
W drugiej poowie 1997 roku pojawi si UML 1.1. Wszystkie odpowiedzi na RFP wczono
w t wersj UML-a. W listopadzie 1997 organizacja OMG zaadoptowaa UML i wzia na
siebie odpowiedzialno za dalszy rozwj standardu.

Okres korekt
Po przyjciu UML-a 1.1 pojawiy si rne wersj jzyka UML. OMG wyznaczya grup
zajmujc si korektami (RTF ang. revision task force), ktrej zadaniem byo przyjmowanie publicznych komentarzy dotyczcych UML-a i dokonywanie pomniejszych zmian
redakcyjnych i technicznych w standardzie. Wielu rnych dostawcw produktw i usug
zaczo wspiera i promowa UML poprzez narzdzia, usugi doradcze, ksiki itp.
Aktualn wersj UML-a jest 1.4, a OMG pracuje obecnie nad wersj UML 2.0.

Okres wdroenia
Rwnolegle z korektami OMG zgasza standard UML do przyjcia jako standard midzynarodowy poprzez organizacj ISO (ang. Organization for Standardization) w formie
dostpnej publicznie specyfikacji PAS (ang. Publicly Available Specification). Najbardziej
aktualna wersja specyfikacji UML jest dostpna w serwisie OMG http://www.omg.org.

UML i proces

21

UML i proces
Mimo e UML jest niezaleny od procesu, jego autorzy promuj proces, ktry jest sterowany przypadkami uycia, skoncentrowany na architekturze, iteracyjny i przyrostowy.
Poznajc relacje pomidzy UML-em i procesem oraz typem procesu promowanym przez
autorw UML-a, moemy lepiej zrozumie, jakie podejcie do nauki UML-a bdzie najlepsze. Mimo to z jzyka UML moe korzysta proces dowolnego typu, nawet nie posiadajcy
tych cech.
Oglnie mwic, proces cyklu ycia rozwoju kadego systemu obejmuje nastpujce czynnoci:
Gromadzenie wymogw definiujcych, co system powinien robi.
Analiz pozwalajc zrozumie wymogi.
Projektowanie ustalenie, w jaki sposb system bdzie spenia narzucone wymogi.
Implementacj budowanie systemu.
Testowanie weryfikacja, czy system spenia wymogi.
Wdroenie, udostpniajce system uytkownikom.
Do wykonania tych czynnoci w celu stworzenia systemu mona podchodzi na wiele sposobw. Tradycyjnie stosowana bya metoda kaskadowa (inaczej wodospadowa). W chwili
obecnej czciej spotyka si podejcie iteracyjne.

Stosowanie metody kaskadowej

Przy stosowaniu metody kaskadowej (ang. waterfall approach) czynnoci zwizane z cyklem
ycia systemu wykonywane s w pojedynczej, liniowej sekwencji dla wszystkich wymogw.
Prowadzi to czsto do odkrywania podczas testw, gdy integrowane s poszczeglne
fragmenty systemu, problemw zwizanych z jakoci, ktre pozostaway w ukryciu podczas czynnoci projektowania i implementacji. Poniewa problemy takie s odkrywane
na pnych etapach procesu rozwoju, moe by za pno na ich rozwizanie lub koszty
rozwizania mog by zbyt wysokie. Na przykad odkrycie, i dany system zarzdzania
baz danych ma za ma wydajno dla korzystajcych z niego aplikacji, gdy aplikacje
zostay ju opracowane, stanowi kolosalny problem.
Rozwamy projekt obejmujcy 10 wymogw, na przykad generowanie 10 rnych typw
raportw, z ktrych kady bierze si z innego wymogu. Przy podejciu kaskadowym
wszystkie wymogi s rejestrowane i analizowane, a cay system jest projektowany, implementowany, testowany i wdraany w jednej liniowej sekwencji. W takim przypadku
UML moe z atwoci posuy do przekazywania wymogw i opisu systemu. Poniewa
jednak czynnoci wykonywane s dla wszystkich wymogw w jednej liniowej sekwencji,
modele UML na kadym kolejnym kroku musz by do kompletne. Taki poziom kompletnoci czsto trudno jest zmierzy lub osign, poniewa wprawdzie UML jest bardziej

22

Rozdzia 1. Wprowadzenie

precyzyjny od jzykw naturalnych, lecz zarazem mniej precyzyjny od jzykw programowania. Zamiast wic koncentrowa si na systemie, zespoy korzystajce z UML-a
przy podejciu kaskadowym powicaj swj czas na ustalenie, czy ich modele UML s
wystarczajco kompletne.

Stosowanie metody iteracyjnej

Gdy stosujemy metod iteracyjn, wszystkie podzbiory czynnoci w cyklu ycia s wykonywane kilkakrotnie, aby lepiej zrozumie wymogi i stopniowo opracowa bardziej niezawodny system. Kade przejcie cyklu tych dziaa lub ich podzbioru nosi nazw iteracji,
a seria iteracji w kocu krok po kroku doprowadza do ostatecznego systemu. Pozwala
to lepiej zrozumie wymogi i stopniowo stworzy bardziej odpowiedni system przez
kolejne ulepszenia i przyrostowe zwikszanie szczegowoci w miar kolejnych iteracji.
Na przykad, moemy zbada wydajno okrelonego systemu zarzdzania bazami danych
i odkry, i bdzie niewystarczajca dla korzystajcych z niego aplikacji, jeszcze zanim
aplikacje te zostan w peni skonstruowane. Pozwoli to wprowadzi odpowiednie zmiany
w aplikacjach lub zbada inny system zarzdzania baz danych, zanim bdzie na to za
pno lub stanie si to zbyt kosztowne.
Rozwamy projekt, ktry obejmuje generowanie 10 rnych typw raportw. W podejciu iteracyjnym moliwy jest nastpujcy cig iteracji:
1. Identyfikujemy pi wymogw (nazwanych od W1 do W5) i analizujemy trzy z nich
(np. W1, W3 i W5).
2. Rejestrujemy pi kolejnych wymogw (nazwanych od W6 do W10), analizujemy
dwa nie przeanalizowane w poprzedniej iteracji (W2 i W4) oraz projektujemy,
implementujemy i testujemy system, ktry spenia trzy wymagania przeanalizowane
w poprzedniej iteracji (W1, W3 i W5) oraz dwa przeanalizowane w tej iteracji
(W2 i W4), lecz nie wdraamy systemu, poniewa w biecej iteracji
nie przeznaczylimy na t czynno wystarczajco duo czasu).
3. Wdraamy system speniajcy pi wymogw przetestowanych w poprzedniej
iteracji (od W1 do W5) i kontynuujemy prac nad pozostaymi (od W6 do W10).
4. Dalej pracujemy nad systemem, lecz musimy zaj si zmianami w jednym
z wdroonych ju wymogw (np. W3), zmianami w innych wymogach, ktre
nie zostay jeszcze wdroone (np. W6 i W10) oraz innymi technicznymi zmianami
w systemie.
Ten cig iteracji moe sprawia wraenie chaotycznego, jednake podejcie iteracyjne jest
tylko ide, a UML tylko jzykiem, wic do zastosowania UML-a w rzeczywistym projekcie
niezbdna jest metodologia. Iteracje wykorzystywane przez metodologi nie s chaotyczne,
lecz zorganizowane i do dynamiczne w ramach kontekstu tej metodologii.
Podejcie iteracyjne do konstruowania systemu przynosi nastpujce korzyci:

UML i proces

23

Moemy lepiej radzi sobie ze zoonoci, budujc system maymi przyrostowymi

porcjami, a nie cay od razu.
Moemy lepiej radzi sobie ze zmianami w wymogach, rozkadajc zmiany na cay
proces, a nie usiujc zarejestrowa i wprowadzi wszystkie zmiany na raz.
Moemy udostpnia uytkownikom fragmentaryczne rozwizania w trakcie procesu,
a nie kaza im czeka na ukoczenie procesu, kiedy otrzymaliby kompletny system
i by moe stwierdzili, e nie tego oczekiwali.
Moemy zwrci si do uytkownikw z prob o uwagi dotyczce opracowanych
ju czci systemu, co pozwoli wprowadza zmiany i tak kierowa postpami
w pracach, by stworzy bardziej solidny system speniajcy potrzeby uytkownikw.
Proces iteracyjny jest przyrostowy, poniewa nie przerabiamy jedynie raz za razem tych
samych wymogw w kolejnych iteracjach, lecz zajmujemy si w nich coraz wiksz liczb
wymogw. Oprcz tego w jednej iteracji mog odbywa si rwnolege czynnoci, jeli
koncentruj si na rnych czciach systemu i nie koliduj ze sob. Wobec tego, chocia
podejcie to okrelane jest czsto iteracyjnym i przyrostowym, w rzeczywistoci jest iteracyjne, przyrostowe i rwnolege. Poniewa w tej metodzie system tworzony jest przez
kolejne udoskonalenia i zwikszan przyrostowo liczb szczegw, atwiej jest nam
ustali wystarczajcy poziom kompletnoci modelu UML ni w podejciu kaskadowym.
Na przykad, jeli mamy pytanie lub problem, ktrym naley si zaj, i jeli nie jestemy
w stanie uy do tego posiadanego modelu UML, to by moe musimy rozbudowa model;
w przeciwnym razie moemy i dalej bez powicania dodatkowych nakadw czasu
i pracy na rozwj modeli UML.
Jak mona organizowa i motywowa dziaania w celu spenienia wymogw przy takim
dynamicznym podejciu, w ktrym iteracje odbywaj si rwnolegle a system jest tworzony
przyrostowo? Jak skupi si na systemie i unikn tworzenia systemu, ktry bdzie trudny
do utrzymania i rozbudowy, poniewa bdzie jedynie zbiorem elementw posklejanych
ze sob bez obejmujcego je schematu? Ktrymi wymogami mamy zaj si na pocztku,
i ktre czci systemu implementowa w pierwszej kolejnoci? Odpowiedzi na te pytania
s elementami podejcia iteracyjnego, w ktrych przypadki uycia, architektura i zarzdzanie ryzykiem s krytyczne.

Przypadki uycia
Przypadek uycia (ang. use case) jest wymogiem funkcjonalnym opisanym z perspektywy
uytkownikw systemu. Na przykad, do wymogw funkcjonalnych w wikszoci systemw zalicza si funkcjonalno zabezpiecze, pozwalajca uytkownikom logowa si
do systemu i wylogowywa, wprowadza i przetwarza dane, generowa raporty itd.
Przypadki uycia s tematem rozdziau 4.
Proces kierowany przypadkami uycia to taki proces, w ktrym moemy wykorzysta
przypadki uycia do planowania i przeprowadzania iteracji. Pozwala nam to zorganizowa dziaania i skoncentrowa si na implementowaniu wymogw wobec systemu.

24

Rozdzia 1. Wprowadzenie

Inaczej mwic, rejestrujemy i analizujemy przypadki uycia, projektujemy i implementujemy system speniajcy ich potrzeby, testujemy i wdraamy system oraz planujemy
nastpne iteracje. Wobec tego przypadki uycia wi ze sob wszystkie czynnoci w danej
iteracji.

Architektura
Architektura obejmuje elementy skadajce si na system i sposb, w jaki wsppracuj one
ze sob w celu zapewnienia wymaganej funkcjonalnoci systemu. Na przykad, wikszo
systemw zawiera elementy obsugujce funkcjonalno zabezpiecze, wprowadzania
i przetwarzania danych, generowania raportw itp. Elementy i relacje pomidzy nimi nosz
nazw struktury systemu. Modelowanie struktury systemu nosi nazw modelowania strukturalnego i jest tematem czci II niniejszej ksiki. Elementy, ich interakcje i wsppraca
nosz nazw zachowania systemu. Modelowanie zachowa systemu nosi nazw modelowania behawioralnego i jest tematem czci III niniejszej ksiki. Rne typy elementw
skadajcych si na architektur systemu, zarwno na struktur, jak i zachowanie, s
ustalane przez paradygmat obiektowy. Zasady i pojcia paradygmatu obiektowego bd
tematem rozdziau 2.
Proces architekturo-centryczny koncentruje si w kolejnych iteracjach na architekturze systemu. Dziki temu moemy z wiksz pewnoci zagwarantowa, e otrzymany system nie
bdzie mieszanin elementw, trudn do zintegrowania, utrzymania i ulepszania. Oznacza
to, e architektura wie ze sob wszystkie elementy systemu podczas jego konstruowania
w kolejnych iteracjach.

Ryzyko
Ryzyko oznacza dowoln przeszkod lub niewiadom, ktra moe zniweczy nasze wysiki.
Na przykad, ryzykiem przy konstruowaniu systemu mog by niewystarczajce fundusze,
nie przeszkoleni czonkowie zespou odgrywajcy krytyczn rol lub niestabilne technologie.
Aby ustali, jakie przypadki uycia powinny motywowa dan iteracj, i na ktrych elementach architektury mamy si w danej iteracji skoncentrowa, najpierw identyfikujemy
zagroenia dotyczce projektu. Nastpnie zajmujemy si tymi przypadkami uycia, ktre zwizane s z najwyszym ryzykiem i tymi elementami architektury, ktre po skonstruowaniu rozwi najpowaniejsze zagroenia. Podejcie takie czsto nazywane jest
konfrontowaniem ryzyka.
Wrmy jeszcze raz do projektu, w ktrym generowanych jest 10 typw raportw. Powiedzmy, e trzy z nich (np. W1, W3 i W5) wymagaj znaczcego dostpu do bazy danych,
a cztery (np. W3, W6, W8 i W10) wymagaj znaczcego wkadu uytkownika. Ryzyka
mog by np. dwa: brak wystarczajco intuicyjnego interfejsu uytkownika (o nazwie R1)
i niewystarczajco wydajny system zarzdzania baz danych (nazwane R2). Z powyszego opisu wiemy, e W1, W3 i W5 s zwizane z ryzykiem R1, a W3, W6, W8 i W10
z ryzykiem R2. Jeli ryzyko R1 jest bardziej krytyczne dla naszego projektu i ma wiksze

Nauka UML-a

25

prawdopodobiestwo wystpienia lub powaniejszy wpyw na projekt, w miar moliwoci powinnimy najpierw zaj si wymogami W1, W3 i W5 lub moliwie najwiksz
liczb z nich, poniewa spotykaj si z ryzykiem R1. Jeli ryzyko R2 jest dla naszego projektu bardziej krytyczne i ma wiksze prawdopodobiestwo wystpienia lub powaniejszy
wpyw na projekt, w miar moliwoci powinnimy najpierw zaj si wymogami W3,
W6, W8 i W10 lub moliwie najwiksz liczb z nich, poniewa spotykaj si z ryzykiem R2.
Jednake w obu przypadkach powinnimy zacz od W3, poniewa wie si z obydwoma ryzykami.
UML udostpnia techniki modelowania strukturalnego i behawioralnego, ktre mog by
uywane w procesie krokowym sterowanym przez wymogi, koncentrujcym si na stworzeniu systemu o zdrowej architekturze speniajcej nasze wymogi i pozwalajcym na
konfrontacje z ryzykami w caym procesie konstruowania systemu.

Nauka UML-a
Proces nauki UML-a moe by przytaczajcy, biorc pod uwag zakres i gbi tego jzyka
oraz brak procesu, jeli nie wiemy, na ktrej czci UML-a mamy si skoncentrowa. Lecz
jeli rozumiemy relacje pomidzy UML-em i procesem, to wiemy, e naley skupi si na:
Paradygmacie obiektowym, poniewa tworzy podstawy jzyka UML.
Modelowaniu strukturalnym i behawioralnym, poniewa pozwalaj zrozumie
wymogi i architektur.
Innych moliwociach UML-a.
Oprcz tego przy nauce UML-a wane jest, by skoncentrowa si na podstawach i zrozumie, jak skutecznie i z powodzeniem stosowa UML do modelowania systemw,
zamiast ugrz w nauce kadego z moliwych aspektw jzyka.
W caej ksice bd posugiwa si praktycznym przykadem systemu zarzdzania projektami, ktry pomoe Czytelnikowi w nauce odczytywania, pisania oraz skutecznego
stosowania jzyka UML. Celem nie jest tu stworzenie penego lub szczegowego modelu, na podstawie ktrego bdzie mona zaimplementowa system, lecz zapoznanie si
z praktycznym przykadem i nauka, jak efektywnie i z powodzeniem wykorzysta UML
do komunikacji podczas konstrukcji rzeczywistego systemu. Do rozdziaw doczyem
wiczenia, ktre pozwol na trening i sprawdzenie umiejtnoci Czytelnika.
Oglnie mwic, system zarzdzania projektami opisywany w przykadzie zapewnia
funkcjonalno zarzdzania projektami i zasobami oraz samym systemem. Zdefiniowane
s w nim nastpujce role:
Meneder projektu
Odpowiedzialny za zapewnienie, by projekt da produkt o odpowiedniej jakoci,
w ramach ustalonego czasu, kosztu i zasobw.

26

Rozdzia 1. Wprowadzenie

Meneder zasobw
Odpowiedzialny za udostpnienie dla projektu wykwalifikowanych i wyszkolonych
zasobw ludzkich.
Zasb ludzki
Odpowiedzialny za utrzymanie kwalifikacji i wykonanie dla projektu prac
o odpowiedniej jakoci.
Administrator systemu
Odpowiedzialny za udostpnienie dla projektu systemu zarzdzania projektem.
Dalsze szczegy przykadu praktycznego bd wprowadzane w stosownych miejscach
w pozostaej czci ksiki. Rozmylnie nie podaj wszystkich szczegw na raz, dziki
czemu Czytelnik bdzie mg zobaczy, jak rne informacje s uywane w rnych technikach modelowania UML-a. To z kolei pomoe zrozumie, kiedy naley poszukiwa
takich szczegw i dobrze ilustruje sposb, w jaki podejcie iteracyjne pozwala stopniowo
gromadzi informacje w miar tworzenia projektu.
Zamiast wprowadza jak nacigan pseudometodologi lub proces, skoncentruj si
na sposobach wykorzystania rnorodnych diagramw UML-a i ich elementw zalenie
od tego, co kady z diagramw ma przekaza i na co kadzie nacisk. Pozwoli to nam
skupi si na tym, jak poszczeglne elementy jzyka pasuj do siebie, a nie traktowa
UML-a jako zbioru rnorodnych typw diagramw, ktrych nie czy aden wsplny
schemat, dziki czemu Czytelnik bdzie mg skuteczniej i z wikszym powodzeniem
stosowa jzyk UML. Rozdzia 2. koncentruje si na paradygmacie obiektowym i zalenociach pomidzy rnymi elementami jzyka. Cz II skupia si na wymogach funkcjonalnych i modelowaniu struktury systemu zarzdzania projektami za pomoc technik
modelowania strukturalnego UML-a. Cz III koncentruje si na modelowaniu zachowa
systemu za pomoc technik modelowania behawioralnego UML-a. Cz IV przedstawia
pewne inne moliwoci UML-a, w tym OCL i mechanizmy rozszerzania jzyka.