UNIFIED MODEUNG LANGUAGE
Solidne podstawy budowania m odeli U M L -o w ych
Doskonałe przykłady p ro g ram o w an ia w Javie
Zawiera podręczny skrót notacji
Przedmowa , m i ' \ m u I in ¡iiA i i ” 1? f ldCe nat* Zunifikow anym Językiem Modelowania w skrócie i *l ™ ■ n i ~ > i ° 1° ^ an8 l,aKe)» niieliśmy nadzieję, że uda nam się stworzyć Mam .iu i c .zę z . o wyrażania projektów oprogramowania, które by nie tylko P /WICIC L ‘ ePs^.e osliUiiiięcia m lorm atyki, ale też „odczarowało” proces moi. owam a sys unovv m lonnatycznych. W ydaw ało się nam, że dostępność standardo wego ję z y k a m odelow ania zachęciłaby informatyków do modelowania systemów przed ich kod ow an iem . Szybka i szeroka akceptacja U M L -a pokazuje, że korzyści z m odelow ania są w rzeczy samej znane informatykom. T w o rz e n ie U M L - a było procesem iteracyjnym i przyrostowym podobnym do m o delow ania dużego systemu informatycznego. W efekcie otrzymaliśmy standard odzw ieic ied la ją cy p o m ysły w ie lu osób oraz w kład wielu osób i firm. M y rozpoczęliśmy prace nad U M L - e m , ale inni pom ogli je pomyślnie zakończyć; jesteśmy wdzięczni za ich w kład. O p ra co w a n ie i uzgodnienie standardowego języka modelowania jest samo w sobie znaczącym w y z w a n ie m . R ów nie znaczącym w yzwaniem jest upowszechnienie w iedzy 0 nim w środow isku in fo rm a ty k ó w w sposób, który' jest zarówno przystępny, ja k i osa dzony w kontekście procesu tworzenia oprogramowania. Udało się to M artin o w i F o w le ro w i w tej niedużej książce, zaktualizowanej po to, aby uwzględnić najnowsze zm ian y w U M L - u . M a rtin ja sn o i bez przybierania tonu mentora omawia najważniejsze elementy U M L - a , a także w y ra ź n ie pokazuje, ja k ą rolę odgrywa ję z y k modelowania w procesie tw orzenia o p ro g ra m o w an ia . Po drodze daje nam nieocenione w skazów ki dotyczące m o d e lo w an ia , oparte na je g o ponaddwunastoletnim doświadczeniu w projektowaniu 1 m o d e lo w a n iu system ó w inform atycznych. R e zu lta te m je s t książka, która w pro w ad ziła tysiące inform atyków w podstawy U M L - a , ro z b u d za ją c ich ciekaw ość i chęć poznania korzyści płynących z m o d elo w a nia w ty m s ta n d a rd o w y m obecnie ję z y k u m odelowania. P o le c a m y tę k sią żk ę w szystkim inform atykom , którzy są zainteresowani w p ro w a dzeniem do U M L - a i p ozn an iem w ażnej roli, ja k ą odgrywa on w projektow aniu opro g ram o w an ia. G rady Booch lv a r Jacobson James Rum baugh
Spis treści W s t ę p .................. Struktura k s i ą ż k i
13
Zm ian y w drugim wydaniu
.........................................................
Podziękowania za pierwsze wydanie
........................
15 16
16 I
W p r o w a d z e n ie ...........
1.2
C zy m jest U M L. Jak do tego doszło
1.3
Notacje i metamodele
11
19
‘
1.4.2
........ .....................................................
Nauka obiektowości .............
1.5
20 20
Po eo analizować i projektować 1 -4.1 Kom unikacja .................
1.4
...
" ^
.* ekSP' nan': “ 'I,r0 n > U ^
,,Wn,k*
f
S z k ic o w y proces tw o rze n ia o p r o g r a m o w a n ia ............................. 2.1........................ Opis procesu .......... 2 .2 ........................ Faza in i c j a c ji .............................
^
2.3
~
Faza r o z w in ię c ia ...................................... 2.3.1
Radzenie sobie z zagrożeniami zc strony wymagań
33
2 .3 .2
Radzenie sobie z zagrożeniami technicznym i
35
2.3.3
Radzenie sobie z zagrożeniami wynikającymi z niedostatecznych umiejętności zespołu
........................................
36
2 .3 .4
Radzenie sobie z zagrożeniami p o lity c zn y m i...................................
38
2 .3 .5
K ie d y można uznać fazę rozwinięcia za zakończoną ....................
38
2 .4
P lanow anie fazy budowy ......................................................................................
33
2.5
F aza b u d o w y ...............................................................................................................
40
2.5.1
G d y zbaczam y z p l a n u ...........................................................................
41
2 .5 .2
Stosowanie U M L - a w fazie budowy ..................................................
43
2 .6
Faza w d r o ż e n ia .............................................................................................................
44
2 .7
K ie d y u ży w a ć iteracyjnego procesu tworzenia oprogram ow ania
2 .8
D o d a tk o w e źródła
.......................................................................................................
P r z y p a d k i u ży c ia system u 3.1
D
.................................................................................................
47 49
................................................................
51
3 .1.1
A k t o r z y ...........................................................................................................
52
3 .1 .2
R elacje m ię d zy przypadkam i użycia sys te m u ....................................
53
i a
g
r a
m
p rzy p ad kó w użycia systemu
47
y
3.2
B
i system ow e przypadki użycia systemu .........................................
55
3.3
K ie d y p o sługiw ać się przyp ad kam i użycia s y s te m u .........................................
55
3 .4
D o d a tk o w e źród ła
i z n
e s o
w
e
........................................................................................................
9
D i,„ r a n ,, * 1 » - * * * * * .............
4.i
Perspektywy..................................................................
4.2
Asocjacje..................................................................................................
4.3
A try b u ty
4.4 4.5 4.6 4.7
Operacje ....................................................................................................
^
Uogólnienie
^
4.8
^ 6()
............................................................
Stosowanie o g ra n ic ze ń ...........................................................................
^
Kiedy stosować diagramy klas .......................................................
Dodatkowe źródła ...............................................................................
5.3
Diagramy sekwencji ............................................................. Diagramy współdziałania................................................... Porównanie diagramów sekwencji i diagramów współdzm l m,
5.4
Kiedy stosować diagramy interakcji..........................
5.2
" •
Diagram y’ "in te r a k c ji....................................................................................... Kr* #ł 5.1
■^
Diagram y klas - pojęcia złożone
70•.,
" •
•.,
.................................................
jj ^ 76
"
81
Ih I I H H
6.1 6.2 6.3
Stereotypy....................................................................... Diagram o b ie k tó w ............................. Operacje i atrybuty w zasięgu k l a s y ........................................................................
84
6.4
Klasyfikacja wielokrotna i dynam iczna .................................................................
84
6.5
Agregacja i zawieranie ..................................................................................................
87
6.6
88
6.7
Asocjacje i atrybuty p o c h o d n e .................................................................................... .................................................................... Interfejsy i klasy abstrakcyjne
6.8
Obiekty dostępne przez referencję i o b ie k ty dostępne p rz e z wartość . . . .
93
6.9
Zbiory dla wielokrotnych stron a s o c ja c ji................................................................
94
6.10
Z a m ro ż e n ie ........................................................................................................................
94
6.11
Klasyfikacja i uogólnienie ............................................................................................
95
6.12
Asocjacje kw alifikow ane ..............................................................................................
95
6.13
Klasy asocjacyjne ............................................................................................................
96
6.14
Klasy parametryzowalne
...............................................................................................
99
6.15
Zasięg w id o c z n o ś c i..........................................................................................................
101
P akiety 1 w s p ó łd z ia ła n ie ............................................................................................................
103
7.1
P a k ie ty ...........................................................
104
7.2
W s p ó łd zia ła n ia ......................................
109
7.3 7.4
Kiedy atoaować diagramy pakietów i diagramy współdziałania
90
»■
Dodatkowe źródła ......................
112
stanów ..................
,U
D ia g ra m y
S.l 2
.
s; v
Diagramy stanów współbieżnych ......................................................... Kiedy stosować diagramy stanów ................................. D odatkow e źródła .......... ......................................................
II* 1» 120
9
D ia g r a m y c z y n n o ś c i...................... 91 9.2
10
..................................................
’
l2 5
9.3
Współbieżność dynamiczna .................................................................................. 127 Dekom pozycja c z y n n o ś c i....................................................................................... 127
9.4
K ie d y stosować diagramy czynności
9.5
Dodatkowe źródła ....................
D ia g r a m y fizyczne
...
............................
128
130
....................................
131 132
10.2
D ia g ram y wdrożenia .......................................... D ia g ram y k o m p o n e n tó w .........................................................................................
10.3
Połączenie diagram ów wdrożenia z diagramami komponentów .................
132
10.4
K ie d y stosować diagramy fiz y c z n e ......................................................................
134
10.1
11
T o ry
o i
132
UML i programowanie ........................................................................... 135 11.1
O bserw acja pacjenta - model d z ie d z in y .............................................................
136
11.2
O bserw acja pacjenta —model s p ec y fik ac y jn y ................................................... Przechodzenie do kodu ............................................................................................
140 143
D o d a te k A : T e c h n ik i i ich stosowanie ......................................................................................
151
.....................................................................
153
............................................................................................................
'5 4
11.3
D o d a te k B: R ó ż n ic e m ię d z y w e rs ja m i U M L - a B .l
W e rs je U M L - a
B .2
W e rs je planow ane
......................................................................................................
155
B .3
Z m ia n y w e w znow ieniach tejk s i ą ż k i ....................................................................
155
B .4
R ó żn ic e m ięd zy U M L - e m 1.0 a1.1
.....................................................................
'5 6
B .4.1
T y p i klasa im p le m e n ta c y jn a ...................................................................
'5 6
B .4 .2
O graniczenia complete i incomplete z w y ró ż n ik ie m .......................
156
B .4 .3 B .4 .4
Z a w ie ra n ie ..................................................................................................... N iezm ienność i z a m r o ż e n ie .....................................................................
'5 7
B .4 .5
P o w ro ty na diagramach s e k w e n c ji........................................................
'5 7
B .5
3 4 .6 Stosowanie terminu r o l a ............................................................................ R ó ż n ic e m iędzy U M L - e m 1.2 (i 1.1) a1.3 (i 1 . 4 ) ............................................... B .5 .1 B .5 .2
P rzyp ad ki użycia systemu ........................................................................ / * D ia g ra m y czynności .................................................................................
157
'5 7 158
161 D o d a te k C : S ło w n ic z e k
..............................................................
.................................................................................. B i b l i o g r a f i a .......................................................................
167
..............................
171
Skorowidz
■ p
-
,
jc W „
un M u t i"
D„a lata tem>. ^ a" ści, jaką wtedyJ ,ylko z dokumentów g„ napisania ks.ązk. o go mo ktotk, przewodnik w k^Vekordów ,t.by ^ wskazówkt, zanim pojaw,ą * p o z „
N ie * * £
'£ %
^
3
a c
uważała,
£ * a '- r e g lo w y -
w
a
*
c
że J ^ f ^ b i o t ą podręcznik. M,„w że nawet w sytuacji, gdy dostane M ,
^ ^ ¡ “S b ę to e tó e js c e na tó t w moich na jśm iela J ręCDwa lata lata pozmej ¿óżn.ej mvzjw moje nadzieje spctn Y ^ .MnmMvemvm. Mimo >■ . rżeniach. U M L w kropelce stał się bestsellerem informatycznym. M i m o że pojawi, w iele dobrych podręczników , to ta książka d a lej d o b rz e się sprzedaje. Co więce ^ ja w iły się rów nież „chude” książki, u tw ie rd z a ją c mnie w p rz e k o n a n iu że w P '- P° ‘ • • n iili ę ifi licZ Y . ^¿form acją zw ięzło ść je d n a k . 1,
flecie
■ W porządku, ale czy pow inniście kup ie tę książką Zakładam , że słyszeliście o U M L - u . Jest to j u z s ta n d a rd o w a m e to d a rysowania d,aeram ów dla projektó w o b ie kto w yc h , któ ra ro z p rz e s trz e n iła się t e / na obszary niemające w iele wspólnego z obiektow ością. W s z y s tk ie w c z e ś n ie js z e , p iz e d u e m e lo w e metody w ym arły. U M L żyje i m a się zn a ko m ic ie. ' Jeśli chcecie poznać U M L , to je d n y m
ze sposobów je s t s k o rz y s ta n ie z tej książki G łó w n y m argum entem za ro zpo częciem n a u k i od tej k s ią ż k i je s t to, że jest ona krótka. D u ż y podręcznik da W a m w ięcej in fo r m a c ji, ale też je g o p r z e c z y ta n ie zajm ie więcej czasu. A b y ułatw ić W a m zadanie i o s zczęd zić w y s iłk u , na p o tr z e b y U M L u kropelce
wybrałem najw ażniejsze elem en ty U M L - a . D z i ę k i tej książce p o z n a c ie najistotniejsze elementy notacji i ich znaczenie. Jeśli b ę d z ie c ie chcieli p ó jś ć d a le j, to możecie sko rzystać potem z bardziej s zc ze g ó ło w y ch p o d r ę c z n ik ó w . Jeśli potrzebujecie dłuższego kursu, to p ro p o n u ję Unified Modeling Language User Guide [ 6 ], P odręcznik ten o b e jm u je z n a c z n ie w ię c e j materiału. Jest dobrze napisany i tak pomyślany, aby pokazać, jak zasto so w ać U M L w w i e l u p r o b le m a c h związanych z modelowaniem. Zarówno ta książka, jak i podręcznik użytkownika wspomniany wcześniej zakła dają, że już coś wiecie na temat programowania obiektowego. Minto ze wiele osób mówi mi. że ta książka jest dobrym wprowadzeniem do obiektowości, to nie to było moim celem przy jej pisaniu. Jeśli potrzebujecie wprowadzenia do o b ie k tó w z uży ciem UML-a, to zwróćcie uwagę na książkę Craiga Larmana [28], nałenlTiM i ^ Wl^ m tematem jest tu UM L, to uzupełniłem go dodatkowym matesobie rade z o b ? lt ° SUn uW0 CZa oprogramowania. U M L jest tak zapn pragnie; jedyne, co mówi U ^ u h o 0'1^ 111^ 0 Pr° CeSU- Możecic ™b'6' C° w z V > 0 to, jaka jest semantyka waszych diagramów.
lei same diagTamy, bez kontekstu 1 ,1 ze sam proces tw orzenia onm .rrT .'m pr0CeS’ znaczą niewie,e Wydaje mi się, skom plikow any. ■ mowania jest ważny i że dobry proces nie musi być Dlatego też opisałem nrostv • Lwego. Stanow i on kontekm ,n„ , , ow y Proces tworzenia oprogramowania obiektostosowania. 1 Wlelu omavvianych technik i pomaga w rozpoczęciu ich Inne om aw ian e spraw v to oprogram ow ania kontraktow ego T a m
r t r ^ “- ^
U M L - a , ale są one przydatne sam ich i e h często L ^ używam. * ‘V 1 jruauie i1 sam
samc,lcstW
" 'e
konstrukcja Częścią
Struktura książki R o zd zia ł 1 m ó w i o ty m , czym jest U M L , przedstawia historię jego powstawania 1 p o w o d y , dla których w arto go stosować. K R o z d z ia ł o m a w ia pioccs tworzenia oprogramowania obiektowego. M im o że U M L je s t n ie za le ż n y od procesu, to trudno mi omawiać techniki modelowania bez podania, g d zie stosu je się je w procesie tworzenia oprogramowania obiektowego. R o z d z ia ły od _v do 6 . w łącznie om aw iają trzy najważniejsze techniki U M L -a : przy padki u ży c ia system u, d iagram y klas i modele interakcji. U M L to duży język modelo w ania, ale nie trzeba u żyw ać go całego. Te trzy techniki stanowią jądro, którego zna jom ość p rzy d a je się praw ie każdemu. Zaczyna się od nich, a potem w miarę potrzeb dodaje pozostałe. (Z a u w a żc ie , że w zw iązku z tym. że diagramy klas są same w sobie dość zło ż o n e , ich o m ó w ie n ie rozbiłem na dwa rozdziały: rozdział 4. z technikami pod s ta w o w y m i i ro z d z ia ł 6 . z technikam i bardziej złożonym i.) R o zd ziały' od 7. do 10. w łącznie obejm ują pozostałe techniki. Wszystkie są ważne, ale nie k a ż d y p ro je k t potrzebuje ich wszystkich naraz. Dlatego też rozdziały te dają w ystarczająco d użo in fo rm a cji o nich, byście mogli się zorientować, czym są i czy ich p otrzeb ujecie. D la w s zy s tk ic h tech n ik podaję notację, wyjaśniam , co ona oznacza, i daję wska z ó w k i, j a k tych te c h n ik używ ać. M o ją filozofią jest jasne przekazanie tego, co mówi U M L . i je d n o c z e ś n ie d zie le n ie się doświadczeniem, ja k go najlepiej używać. Podaję też o d nośn iki do innych książek, które zaw ierają więcej szczegółów na dany temat. R o z d z ia ł 11. z a w ie ra m a ły przykład pokazujący, ja k U M L ma się do program owa nia (o c z y w iś c ie w J avie). V, • \\T N a d o d a tk o w e j w k ła d c e znajdu je się streszczenie notacji U M L -a . M o zę się W a m to przydać w tra k cie c z y t a n i a , je ś li będziecie chcieli sprawdzić notację dla pewnych pojeć z w ią z a n y c h z m o d e lo w a n ie m . . . . u Jeśli u zn a c ie , że k s ią żk a ta je s t c iekaw a, to dodatkow e inform acje dotyczące moich prac z w ią z a n y c h z U M L - e m , w zorcam i . refakto tyzacją zn a jd z te c e na m o.ch stronach W W W (z o b a c z strona 17.).
UMl-
,Vkropfltc
Zmiany w drugim wydaniu Wraz z ewolucją U M L -a i n.idchod/iicym . o p in ia m . o p.erw.szyn) aktualizow ałem materiał. C o dw a. trzy m iesiące p o ja w ia ło się k o |e|nc
an' 1' e,.-.,,.
prawie każde / nich było aktualizowane
/,u ,W|e||
staw iało to sroyie w y n la .,
wydawniczo-dmkarskim. Ia ProceSfl Przy przejściu od U M L -a 1.2 do 1.3 z d e c y d o w a liś m y się dokonać przeglądu materiału zm iany b y ły w ystarczająco d u że . a b y przy.r / 1 a^ni(;|s/ drugie. Z e względu na
popularność książki
starałem się n ie z m ie n i ić
lein się nie dodawać zbyt w iele i sprawdzać, c z y n ie m a rz e c z y k t ó lv r ^ ^ Uc^a" •Sis, ,£1 n się nie dodawać zoy« — . można by u^ '
dotycz) ły rozdziału 3. o p rzy p ad ka c h u ż y c ia systemu i ro łu 9. o diagramach czynności, które praktycznie nap isałem od n o w a . Do r o z d ^ / ^ h, 9. o diagramach c^ 7 oT współdziałam ^ ł i V a ł a n lach. Jeśli ch chodzi o resztę m ateriału, ateriału, "to skor/ dodałem także fragment ¿ich. Jeśli o d zi o icsztę m sk 11 ^1 Największe zmiany
dodałem także p n e n t o j w- iele m ałych ^ popraw k opartych / yte|nikfk - •• 6 $^--------w p o p ra week o partych na na opiniach o piniach cczyte|n°|^" stałem z okazji, aby zrotne w . i moich doświadczeniach z ostatnich
Podziękowania za pierw sze w yd an ie wymagało wiele pomocy ze stro ny ludzi, których wy. siłek wykroczył poza normalną pracę związaną z wydaniem k s tą zk . . spowodował przyspieszenie wszystkich czynności. Ważną rolę w zebraniu materiału oraz pracy nad tekstem i s tio n ą graficzną odegra! Kendall Scott. Podczas gdy ja nanosiłem poprawki i zmiany, K e n d a ll trzym ał wszyst ko w garści i w alczył zwycięsko z zadaniami, które pojawiały się nieoczekiwanie, i zawsze z niewykonalnym i terminami ich wykonania. „Trzej muszkieterowie’" — G rad y Booch, Ivar Jacobson i J im R u m b a u g h — wspie rali mnie swymi radami. S pędziliśm y wiele godzin na m ię d z y k o n ty n e n ta ln y c h rozmo wach, które bardzo ulepszyły książkę (i jednocześnie dały m i lepsze zrozumienie Tak szybkie wydanie książki
U M L -a ).
jest podstawą rzetelnej p ra c y nad k s ią ż k ą . N ie tylko re cenzenci w yrazili swoje opinie, ale też wyrazili je czasie krótszym niż jeden tydzień, abyśmy mogli dotrzymać naszych napiętych terminów. Podziękowania należą się Sim m i Kochhar Bhargavie z Netscape Communications Corporation. Ericowi Evansowi, Tom ow i H ad field o w i z E v o lv e Software, In c ., Ronaldowi E. Jeflriesowi, Joshm Kerievslcy emu z Industrial L o g ic , In c., H e le n Klein z Uniwersytetu M ic h ig a n JanieS0 'y i . , e 0WI "i, S algarow i / N etscap e Communications Corporation. Podwójne J im o w iO H p li a T , l a i , l ' c ld a ’ Ponieważ /recenzował książkę dwa razy1 prac orKanizacii°7aimMii a /Vm p0i,/1<' kowac za dwie rzeczy: pierwsza to koordynacja w skrócie OMG hm> Ma,u^ ' zac.i;\ vv dziedzinie technik obiektowych. który będzie wielkim krokien ,m‘IBCmem C,rouP). nad jednolitym standardem UM U naprzód dla informatyki; druga to zachęcenie mnie do Dobra grupa recenzentów
Po angielsku zwani three ;
amigos tprzyp. tłum.)
U
Watęn
przejrzenie k sią żk i!' Pr° Jek,owan,em obiektowym Aha, p r/y okazji, dziękuję też za jakby mnie nie było. ^ daw,lnie soble rady z tym, że nawet gdy byłem w domu, to tak Nawel nie mogę sobie wvnK i jego asystentka Angela B u e i m m T L l ™ ^ 08^ ^ ,UÓJ u ^ dawca J Cartcr Shanklin jak j ą w ydali N ależą im sic za P ło n ą c , aby wydać tę książkę lak szybko, rzone do dawania sobie rady z ksiażkam TJpodz,ęk(nvania Wydawnictwa me są stwo^
A ktualizując T ^ k s " ^ Stko’ aby
Conrad Bock, Iv ar Jacobson " c r i l ^ b m 7 baugh zaw sze p o m a p l i ,m zna,eżć rv ie s O V a tz h v t 7 ty, jest W as zbyt w ie le , aby
wynika ra ła re s z ta ^
^ ^
C"" «czegó łów U M L -a . ^
RU' " '
mlormacj e dotyczące różnych błędów , braków; niestewszystkich, ale dziękuję Wam
wymienić tutaj
R ° dZ,C° m 23 t0, Ze uzy ska,em dobre wykształcenie, z którego
Martin Fowler Melrose, Massachusetts kwiecień 1999 fow ler@ acm .org http://ourworld.compnservc.com/homepages/Martin_Fowler
Wprowadzenie
Rozdział
11
C zym j e s t U M L
w• »
w
I
,
Zunifikowany M
KAn/lvlowilii i ciy w skrócie v . ch metod analizy
U M l - (cing. U nified m . i projektowań,a, które 1 ' 8U . ^ ^ ¿ d z i e s i ą t y c h . M i m o ¿e j es, h .'M'Kv'ly
guage), jest następcą
^
na przełamie lat osi
Rumbaugha (technika
m o d e lo w a n ia obiektów ^ 0siH
1jacobso,;a'toW iego SUS a td *syM ramach organ.zacji Objec, O
r S S S - i - 1 *°** G r o u p 'i jest obecnie je j standardem .
U|'
a nie me odą. Większość metod się, przynajmniej w założeniach, zarówno z języka modelowania, jak , proCesu> modelowania jest, zw ykle graficzną, notacją, którą metody wykorzystują do Wvr ^ modeli, k ró c e j jest pomocą udzielaną przez metody, dotyczącą kroków projek’, , ^ U M L jest zwany językiem m o d elo w an ia,
i tworzenia oprogramowania.
dosyć szkicowo k w e s tie m e to d dotyczących Co więcej, zauważyłem , że w iele z osób, które mówią, że k o rz y s ta ją z jakieiś ^r°CesiJ tak naprawdę używ ają ję zy k a modelowania, a rzadko p o s tę p u ją zgodnie / ' proponowanym przez tę metodę. Tak więc w pewien sposób ję z y k modelow * ' ^ 111 najważniejszą częścią metody. N a pewno jest istotnym e le m e n te m komur T trzeba porozmawiać z kimś o m odelu, to jest potrzebny ję z y k m od elów ^ każdy rozumie, a nie proces, który b y ł potrzebny, aby u tw o r z y ć ten m odel ^ „T ize j m uszkieterow ie” u tw o rzy li także zunifikowany pro c es , k tó ry n nal Unified Process (w skrócie RUP). N ie trzeba u ż y w a ć RUP-u ibv ^ all°' U M L -a — są one w yraźnie niezależne. W tej książce j e d n a k p o w ie m ^ cesie, aby umieścić techniki ję z y k a m o d e lo w a n ia w pewnym k o n t e k s t w ° pr°' go om ówienia stosuję podstaw ow e k ro k i i terminy p o c h o d z ą c e z R U P me jes. opisem RUP-u. Sm używam widu różnych p r o c e s ó w z a i ż m e ^ l r klorego pracuję, , rodzaju oprogramowań,a, które buduję Mimo że k, ^ dowego języka modelowania uważam za bardzo cenne „ a s,a* poirzeby istnienia standardowego procesu aczlrol, ' i porównywalnej harmonizacji słownictwa. ' ‘ ek Przydałby się pewien stopie. W iele podręczników ujm uje
t-2
Jak do tego doszło
okrzh I P0CZynily P1* ™ * 'k r o k f w k ie ^ 'k ” Wychodzi';" z laboratoriów bad
Object Manaoemem rv w dziedzinie techmk u ?Up’ VV skrócie O M r ° lekiowych. Zobacz h ttn ■
H
H
B
•W M
-
. / / M ° rg a m z a c R
z a jm u ją c ą się standan-zaert
W f o w w . o m g . o r g (p r z y p . tłum .).
W p r o * *d¿en ic
Jak wiele postępów w nnr„ ¿yków program owania W i d u ; dn,O W an,u- ,ak ' obiekty były wynikiem r o /w 0)u jęoprogramowania będą pasó w ,lv‘ , anawia,° >ak " ,etody projektowania . tworzenia rżenia oprogram ow ania st-,łv , ^ ,a‘a oblektoweBO Metody projektowania i twooardzo popularne w latach siedemdziesiątych i osiemdziesiątych w różnvrh , 1-,;,, ■ popui! magające dobrą analizę i nr ‘ ?! h ^ s p o d a r k iW ie lu uważało, że techniki wspoobiektowym . P rojektow ań« b ę d , równie ważne przy projektowań,u
t
Podstawowe książki na w latach 1 988-1992się w iowantu; tre ś ć ^ y c h p ro je kto w a n ie m
metod analizy i projektowania obiektowego pojawiły
w ï r d t " ™ “ 1' f ” ' 0 'islązk' I 4 0 1 1 t4 l l ° anal,zle 1 Proł ek-
rekursywnym (ang recurehîe dMignJ^C]8' “
^
le k k ie ” i 'ukienm l ^ 11^ 0 0 również naP,sal' książki [9] i [10], w których rozwinęli ”, i ■ roi r . | | ovvanc na prototypowanie podejście Coada do metod Zobacz ró w n ież [oj i [ i | j. G rupa z Portland, w stanie Oregon, zajmująca się Smalltalkiem, wymyśliła p ró b k o w a n ie s erow ane zobow iązaniam i (ang. responsibility-driven design) [46] i karty k las a -zo b o w iązam e-w sp ó łd ziałan ie, w skrócie karty C R C (ang class-responsibility -c o lla b o ra tio n ) [3] •
G ra d y B ooch , pracując w Rational Software, zrobił wiele, tworząc systemy w A d z ie . Jego książki za w ie ra ły wiele przykładów i miały naftepsze. w swiecie książek o m etodach, ilustracje [ 4 ] i [ 5 ],
•
Jim R u m b a u g h p rz e w o d z ił zespołowi w laboratorium badawczym firmy General E lec tric , k tó ry napisał bardzo popularną książkę o metodzie O M T [36] Zob.icz ró w n ie ż [3 8 ].
•
K s ią ż k i Jim a O d e lla (pisane w raz z Jamesem M artinem ) bazują na bogatym do ś w iad czen iu
z d o b y ty m
podczas pracy z systemami informatycznymi przedsię
bio rstw i in ż y n ie r ią in fo rm acji (ang. information engineering). Rezultatem była n a jb ard zie j id e o w a z tych książek [29], •
Iv a r Jacobson o p ie ra ł swe książki na doświadczeniu z pracy nad centralami telefo n ic z n y m i
E ricssona
i w pierwszej ze swych książek [24] w prow adził pojęcie
p rz y p a d k u u ż y c ia s ys te m u 1. Z o b acz rów nież [25], G d y p r z y g o to w y w a łe m się w
1994 roku do w yjazdu na konferencję O O P S L A
w P ortland, ś w ia t m e to d b y ł p o d zielo n y i nastawiony na rywalizację. K ażdy z w yżej w y m ie n io n y c h a u to r ó w b y ł n ie fo rm a ln y m liderem grupy praktyków , któ rym podobały
się pomysły p r z y w ó d c y . M i m o że w szystkie te m etody były bardzo do siebie podobne, to jednak c zęsto iry tu ją c o r ó ż n iły się drobiazgam i. T e same podstawowe pojęcia p oja wiały się w b a rd z o ró ż n y c h notacjach, co siało zam ęt w głow ach motch k lie n tó w . Kweslie standaryzacji pojawiły się w czasre konferencji, ale jakoś nikt me był skłonny się n im , zająć. Część uczestników była przeciwna samemu pomyslow. stan dardów dla metod. Niektórym pomysł się podobał, ale nie chctało ,m stę włozyc w ,ę pracę trochę wysiłku. Gdy zespół z OMG spróbował bltzej przyjrzeć stę s ta n d o u t.
' Termin „przypadek użycia sytemu” będę niekiedy skracał do term,nu „ptzypadek użycia". Nie będzie to błędem a zwiększy czytelność (przyp. tłum.).
21
.^ y c h
________llBl o
. ^
J
m e" ,d
p r i e c ^ c o ^ a ć ° ad sL
* JU» B o o ^ f 1 ^y. SPó , z ° r: n ^ o W ^ P ^ > ) a y ^ NaStęP l,m o g ł°slU’
7i n i e ^ ą
Grad\ \ m ó w »^' zC)V, praW»yczn h tn e t o d o '° ę U
'
C > ' w ‘ /y m ............" * * * 5p o s o ^ stary doVi Ct'Aegoc} 0 NvaC I MłCł, ( ) ( )\*sv \ ').\ u ,v,
s i -sjis^sr tcrrv/Urlka
1
(.Ku\V UlHtóU
" ł e l ° p o r a n n c ł ka v> ' "
n C /o n c
. z0Stab ć
z^ , r v z a c K
t o o t ^ orzen
zasu^r0N' a x w
.9 5 G ^ d y « in n y tS » c ję 0 ° P S ^ 0 .8 dow un»
m as
»»»V
.\wUl.
^ - o b c n M ,u „ pv/cONV ł W W t
,
ii» P ' ^ s/N P"W k / " '
F z\ f \ llh Z n ' " / ' * ,n v ,,m 'M *»»»:- V mu, . ci» *NM< ‘ a S o ftw a re kuP 'k» Uu" k ( ' R ,u o n a \ ^
M n U, A K pu,
^°a|c>neli»»cl0^ tn»eis^e' 7uruf»k°NV 'n° “ ui/adzda P '/N 'cc' 'u k' svVOjCJav cojcszcze 'sU' przechodź d° '3ll0na\ s° m' ¡‘ ¡^ąuuuh pu>W>w.d sp,csvav:
................
^
^
1 nu n11c|t
... *3— ^ al ^ d i L«ramad. metod OMO utworzyła grup, rob«,
w celu osiągnięcia standaryzacj
rozWiązam a nagrom adzonych problemów.
Stanowiło to znacznie 0 MG w tym zakresu S zotem zespołu niż jakakolwiek wczesnie|SZ^n,„czvł Jim Odell 1 przejął przywództwo nad praeann stała Mary Loonus; potem aoiąJ zrezygnować ze swój 1 metody jako stanOdelł oświadczył wyraźnite, „ .L a n e g o przez Rational Software
^onaineJnoTacIi11S
?Software opublikowała wersj, 1 O dokuntenlac,, UMU
' P^ o t ^ lnas^apd'krótlk|0okre^p^epychanki, podczas gdy różne propozycjo były sc,
lane ' W rfdccifoMG przyjęta wersję 1.1 jako swój oticjaluy standard Od tego eta zespól ds zmian, w skrócie RTF (ang. Rev,slon Task Force). OMO prowadzony pr«t Crisa Kobryna. wprowadził kilka poprawek, O ile wersja 1.2 była wersją mlaskom loną kosmetycznie, o tyle wersja 1.3, opublikowana na początku 1999 roku. ma ju? większe znaczenie. RTF zamierza! zakończyć swoje prace na wiosnę 1999 roku i przy jąć wersję 1.3jako kolejną oficjalną wersję UML-a.
1.3
Notacje i metamodele
W swej obecnej postaci U M I Hp « , • • Notacja to elem en ty graficzne
kt *
¡ T T u '3' Na przykhd notacja dh (akiejnk klasa, asocjacja i krotność ™*
notac^
* m e t a m o ile l.
* modelach- i« ' >o symaklyk. 1 klasy definiuje jak elarremy .
* są rePrezentowane.
aI d i r P o w o l i '
d° ^ y,a" ‘t
w ie le osób
T . 10 dokladn,e ) « ' “ Ocjacja lub krolność. ■“ * I " * " » * *
* * —
* * ■ *
*
tbrmafnych^'w ^echn^kadf^' ,Językd'v Projektowania dominuje w dziedzinie metod pew nych w ers,, rachunku zdań t 7 ! ń spcc)' hkac|e sa P o ł a w i a n e przy użyciu czają do d w u z i i i f 7 nn • M definicje są matematycznie ścisłe i nie dopuszjeśli m o żn a dow ieść leslcty, wartość tych definicji nie jest uniwersalna. Nawet nego sposobu na m
pr° f ram sPcłnia specyfikację matematyczną, to nie ma żad-
w y m a g a n ia systemu ' V ^ o n ro m -u im w V n ! ' 0 s ic z e » ; I . . .
r
ZC specyfikacJa matematyczna spełnia rzeczywiste dostrzeżeniu podstawowych kwestii w trakcie tworzenia
V m ialne C2ęs,° P ° w °d u ją ugrzęźnięcie w masie drobnych 1 w ięcej, m etody formalne są trudne do zrozumienia i stosowania, czę-
u r T eJSZe m z ję z y k l Programowania. I nie można ich nawet w ykonyw ać'. tększosc m etod obiektow ych, w skrócie metod 0 0 (ang. Object O riented'), jest ma o sets a. c i notacja odw ołu je się bardziej do intuicji niż do formalnych definicji. . sum ie nie w y d a je się, aby to pow odow ało w iele szkód. M etody te są być może nie fo rm a ln e , ale w ie le osób uznaje je za przydatne — a o przydatność przecież tu chodzi. J ed n ak trzeba dodać, że osoby zajm ujące się metodami 0 0 szukają sposobów na dan ia im w ię k s z e j ścisłości bez poświęcania ich przydatności. Jednym ze sposobów o siąg an ia tego jest zd e fin io w a n ie metamodelu — diagramu, zw ykle diagramu klas, de fin iu ją c e g o notację. Rysunek
1.1 je s t m a ły m fragm entem metamodelu U M L - a pokazującym zw iązek
m ię d z y a s o c ja c ja m i i uogólnieniem . (Ten fragment ma tylko pokazać, ja k metamodel w y g lą d a . N ie będę tego objaśniał.) Jak d a lece m e ta m o d e l w p ły w a na u żytko w n ika notacji m odelowania? N o cóż, po m a g a z d e fin io w a ć , co to jest dobrze zbudow any model — to znaczy model, który jest s y n ta k ty c z n ie
p o p ra w n y .
S u p e ru żytko w n ik metod pownnien rozum ieć m etamodel.
J ed n ak a b y n o ta c ja U M L - a stanow iła w artościowe narzędzie, większość u ż y tk o w n i
ków
m e to d n ie m usi go rozum ieć.
N ie staram się w tej książce kłaść dużego nacisku na form alizm ; idę raczej tra d y
cyjną ścieżką
i o d w o łu ję się do intuicji czyteln ik ó w . C zy te ln ic y potrzebujący bardziej
s fo r m a liz o w a n e g o p o d ejścia p o w in n i przejrzeć podręcznik u ży tk o w n ika lub o fic jaln ą
dokumentację. Jak ściśle należy trzymać się języka modelowania? T o zależy od celu, w jakim bę dzie on używany. Jeśli korzysta się z narzędzia typu CASE, które generuje kod. to trzeba trzymać się interpretacji języka modelowania zaimplementowanej w tym narzę dziu. aby otrzymać żądany kod. Jeśli diagramy są używane tylko do porozumiewania się, jest więcej możliwości i swobody.
' To
Repository for Exe cutable S p e cific atio n Languages pod adresem w w . cas.asu.edu/~specinfo/(przyp. tłum ). •’ Tłumaczenie wyrażenia „object oriented" jako „zorientowane obiektowo" jest zarówno niepoprawne, jak i pozbawione sensu. Oznacza ono bowiem „do zastosowań w obiektach . Obiektowość nie jest tu celem — jest środkiem (przyp. red ). nie c a łk ie m praw da
— są w yko n y w a ln e
ję zy k i specyfikacji, por.
U M L w kropelce
• ntacii to inni programiści m o g ą nic vv . i„ .k od o««alncJ w ,k w y p a *'. kiedy “ »'“ 1» "'Mai,, ' ^
jeśli Odejdzie SWJ« przekazoe
S^ chnie obawiam sl« je j
naginać do
r r » ” S 't : r : Ł S » » “ * * K S S S iS -« « 1
''
-i
Cecha z 1w ią z a n a z zacho1w a n ie m
Cecha s tr u k tu r a ln a
i► {orderedj
0..I
*
Parametr Rysunek 1.1. Fragment metamodelu UML-a
1.4
Po co analizować i projektować
Jeśli się dobrze zastanowić to nrau/H,; „strzelaniu kodem” . Diagramy to w knńr ¡"n polrzebuje ładnych obrazów
< ***■
tN v o r /e n ' e
oprogramowania
polega
na nie
o 1 “ ! ^ ° Iad" e Żaden użelkounik i ' “ 8° Chcc R ó w n i k , to oprogramowanie, kiorc
Przed użyciem UML-a trzeb i du. Nie ma istotnych danych empirYcznlrh0^ ’ ^ ^ ^ z' e on pomocny w pisaniu ko".k. s, dobre albo złe _ / w dalsz S ' * «• kottkremo K * ■e h używam. ^ rozdziału omawiam powody, dla których M W lej części wspominam o technik u Są
dalej, jeśli pewne o d n .**
f częsc , wrócić do niei nóźmei.
Wprowadzenie
1.4.1
K o m u n ik a c ja
w aż u m o ż liw ia m i kommi ^ tyw y. Język naturalny jest
31113 U M L ' a Jesl komunikacja. Używ am U M L -a , ponie-
P.e wnych iclei 1 Pomysłów lepiej niż jego altema-
pojęciach. K o d jest ' S' e'C Zamęt' gdy mowa 0 bardzie.i złożonych potrzebuję pew nej dozv sciS szcze 8 ó,owy Zatem używam U M L -a . gdy że u n ik am s z c z e g ó łó w ° SC'' 3 mC chcv' “ grzęznąć w szczegółach. Nie znaczy to. Jako konsultant często' UŻywan? U M L *a« aby podkreślić ważne szczegóły, w raże n ie w bardzo krótk m ^SZ^ P°Ja w 'ć się na złożonym projekcie i sprawić dobre bo p o z w a la m i uzyskać Cf asic '-'M L jest dla mnie nieoceniony w takiej sytuacji, m oże m i p o w ie d zie ć jące dalszej pracy G d v
■ W' ZJę sys,eniu s P ° jn * n ie na diagram klas szybko ' 1 P° Jęc uzywa syslcm 1 gdzie są części wątpliwe, wymaga-
i proszę o d ia g ra m y i n t e n k c i n i S t “ J> a ^ tlowied7,ec’ -,ak klasy wsPółPracują. Jeśli cio , -T , CJ.' ‘lustrujące podstawowe zachowanie systemu. sn o ło w i 0so^ 'e z zewnątrz, takiej jak ja, to jest to równie przydatne ze-
A b y z b u d o w a ć m apę dużego systemu, należy skorzystać z diagramów pakietów (z o b a c z ro z d z ia ł 7 .), aby zobrazow ać główne składowe systemu i ich współzależności. D la k a ż d e g o p a kie tu m ożna narysować diagramy klas. Rysując diagram klasy, w tym
Rozdział 1
Z l Z r 2 e k " m ' T UW ielkil” p r0 |c ktic b l " '° Jesl 1* « ^ widzieć las. a spo. . i . . 0 P°Je Vncze drzewa. Z paroma dobrze dobranymi diagramami w ręce duzo ła tw ie j zo rie n to w ać się w złożonym systemie.
k o n te k ś c ie , n a le ż y spojrzeć na klasy z perspektywy specyfikacji. W tego typu pracy u k ry c ie im p le m e n ta c ji jest szczególnie ważne. Dla głównych interakcji w pakiecie na le ż y n a ry s o w a ć d ia g ra m y interakcji. W a ż n e k o n c ep c je i p o m y sły użyte w systemie, a występujące w wielu miejscach o p is u je się. u ż y w a ją c w zo rc ó w (zobacz strona 45.). W zorce pomagają wyjaśnić, dla c ze g o m o d e l je s t ta k i, ja k i jest. D o b rym pomysłem jest również opisanie rozwiązań, k tó re z o s ta ły o d rzu c o n e , i w yjaśnienie, dlaczego zostały odrzucone. Ciągle zapom i n a m o m o ty w a c h tych d e cyzji. P rz y ta k im p o s tę p o w an iu należy być zw ięzłym . Istotnym elementem kom unikacji je s t p o d k re ś le n ie w a ż n y c h rzeczy do przekazania. N ie trzeba pokazywać każdej skła d o w e j k a ż d e j z klas; lepiej skoncentrować się na elementach ważnych. Krótki doku m e n t p r z e k a z u je treść zn aczn ie lepiej niż długi — sztuką jest znajomość tego, czego nie trze b a z a m ie s z c z a ć .
1.4.2
N a u ka obiektowości
Wiele osób mówi o krzywej uczenia się związanej z obiektowości, - o osławionej zmianie paradygmatu. Pewne aspekiy przejścia do obiektowości są proste, inne zawie“ le przeszkód związanych z prac, z oblekłam,, a w szczególności z efektywnym ICV e k,esfwcaleC't ^ trudno nauczyć się programować w obiektowym języku propa• d ii nnliim na tym że potrzeba trochę czasu, aby nauczyc się wykorzy Ttowama Problem polega, P ^ ob żlj. K I ^
S
S
p iT z zmianę
ale ich mc dają. Aby w pełni z nich skorzys,ac. na,czy p a ra d y g m a tu ,
jednak trzeba przy tym uważać.
25
U M L w kr opel ce
_ E tem erity U M L - a b y 'y
d0
P
.toD nia
tak z a p ro je k to w a n e ,
ab\
p 0|Till
^ ez „ ic h m . in n e z a lc iy -
« p r u c i u do O b ie k to w o « :.. * * o b ie k to w o ś c i są k a r ły C RC (z o b a c z . fedną z najcenniejszych techn k w n a u ^ , „y b / ^ 7 x i które nie są częścią U M L - a , ■ U r1 /| p ra c y z o b ie k ta m i s . Używane Zostały one zaprojektow ane P ; w a n ia N a c i sk na zobow iązania one celowo inne n iż M d y c y J " ' “ht z c z e g ó ln ie w a rto ś c io w e n a rz ę d z ie . , brak złozonej notacji c z y n ią z men sz * ^ p rz y d a tn e, p o n ie w a ż uw ędatni.,. .
•
D iagram y interakcji (zobacz rozdział ., ją Strukturę kom unikatów . w ten sposob ekspo nia, w k tó ry c h je d e n o b ie k t w y k o n u je
^
D ia g ram y klas (zobacz rozdziały 4.
P
z b y t s c e n tr a liz o w a n e ro z w ,a / a . j*
e d s ta w i ają c e m o d e le k la s . n ia ią / a r o - . M o d e le k la s są b lis k ie m odelom
no dobre, ja k i złe strony w nauce
d a n v c h d o b r y m , z n a jd u je r ó w n ie ż /a si. -
danych -
wowy
w iele reguł, które “ y " V T d
p ro b le m w
użyciu
d ia g ra m ó w k, ,
opracow ać rnodel k b s y u k ie r u n k o w a n y n a dane z ,
•
m ia st na z o b o w ią z a n ia . n ie z b ę d n e w n a u c e o b ie k to w o ś c i. p0 Poiecie w zo rcó w (zobacz strona 4 5 .) staro się n i c ^ u i n iew aż użycie w zo rc ó w w ym u sza skupienie się na d o b r y c h r o z w t ą z a m a c h o b ie k to w ych , studiowanie p rz y k ła d ó w ja k o nauce. W y s t a r c z y ra z n a u c z y c stę p o d s ta w o w ych technik m odelow ania, takich ja k proste d ia g r a m y k la s i in t e r a k c ji, a następny
kro k polega już ty lk o na w y s zu k iw a n iu w z o rc ó w . •
Jeszcze je d n ą w ażn ą techniką jest p ro je k to w a n ie it e r a c y jn e
(z o b a c z o / 1 ai _ ,
Technika ta nie pom aga w bezpośredni sposób w n a u c z e n iu się o b ie k to w o s c i. ale jest kluczem do je j e fe ktyw n e g o w y k o rz y s ta n ia . J e ś li o d s a m e g o p o c z ą tk u u
suie
się projektow anie iteracyjne, to ła tw o n auczyć się w ła ś c iw y c h p ro c e s ó w p n ą c k i w ych w e w ła ś c iw y m kontekście i z ro z u m ie ć , d la c z e g o p r o je k t a n c i p r o je k t u ją lak. ja k projektują. G d y zaczyna się stosować p e w n ą te c h n ik ę , to z w y k le p o s t ę p u je się d o k ła d n ie tak ja k m ó w i podręcznik j ą opisujący. M o ja rada to za c zą ć o d p r o s t e j n o t a c j i , o k tó re j tu m ó w ię , a w szczególności od d ia g ra m ó w klas. Po o s w o je n iu s ię z p o d s t a w a m i m o żn a przejść w m iarę potrzeb do bardziej ro z b u d o w a n y c h te c h n ik , a t a k ż e r o z s z e r z y ć m e todę.
1.4.3
Komunikacja z ekspertam i ze strony u ż y tk o w n ik a
i * w łaś c iw e g o
^
oprogramowania jest zbudowanie
systemu to znaczy systemu, który spełnia potrzeby użytkownika przr rozsądnym koszcie budowy. Jest to tym trudniejsze, że m y , mając swój żargon z a w o d o w y . m u s im y się p o ro z u m ie w a ć z u ż y t k o w n ik a m i, k t ó r z y u ż y w a j ą w ła s n e g o
ic - w „
zrozunuenieświataużylkownikatolm,t;óbnn’0|W''|nym!) D ° bn> komunikacia 1 dohr Oczywistą techniką, która pomoże osiągnąć ten T ™ df reg° °P roSlamowama użycia systemu (zobacz rozdział 3 ) P r/y n -u L ! ' Jest korzystanie z jhzi/w,Han systemu. Suma wszystkich przvn nlkńu, 1 JeSt nilgawk:' ludnego aspekt tego systemu i dobrze wyjaśnia, co system M z f e rob l'" “
2 (>
ZeWnętrznym obraze'
W prowadzenie
Dobry zbió r przyn ułkńu, użytkownicy. Przyp uiki uzycia syste,nu -,csl Pods,awą do zrozumienia, czego chcą sterują iteracyjnym t w o i - J ^ 0' * ^ 162 d° brą poinoCi' w Planowan' 1' projektu, ponieważ bo u ży tk o w n icy r e a u iim ” " 9 " "Programowania, co samo w sobie jest cenną techniką, stemeni. Ie otrzy mują informację o tym, jak postępują prace nad syM in io że przypadki ii 7 vp to nie należy z a n ie d h v w -i/ V . laJą °m aw ianie zewnętrznych aspektów systemu, poznanie tego. jak ekśn .« .i pr2ejawow j e8 ° g ib s z y c h zachowań. To z kolei obejmuje Diagramy k h « t , o, 2e s,rony U2ytkow m ka pojm ują swoją dziedzinę. tw orzone z punktu w id z 2 r° z d z ,a ly . 4 1 6 ) mo 8 * Ul być wyjątkowo pomocne, o ile są traktow ana ja k o pewne nni * .p o ,ę ' ,owf & ° - lnny mi słowy< każda klasa powinna być diagram am i danych lub k i a ! ńt 2 ,ed* my “ ^ " w n i k a . Diagramy klas nie są zatem Szczepńlnio * raczej diagramami języka użytkownika w aia nrnee«v \-J-Uni |KnC’ W w yp adk a<-‘h gdy w świecie użytkownika dużą rolę odgryW z w ią z k u z rJ ° P y u u zadarh są diagramy czynności (ang. activity diagrams). ■ . n i\ ze n i°ż n a dzięki nim reprezentować działania i procesy równoległe, • U,V nicPo trzebnej sekwencyjności. Sposób, w jaki te diagramy odwrai
^
s.ę zaletą
?L aS' C° m oze b y t problemem na dalszych etapach projektowania, staje w koncepcyjnej fazie procesu tworzenia oprogramowania.
1.5
Dodatkowe
ź r ó d ła
Ta książka nie jest pełn ym i ścisłym w ykładem o U M L -u , a już na pewno nie jest podręcznikiem a n a liz y obiektow ej i projektowania obiektowego. Napisano już na te tematy morze s łó w i jest sporo rzeczy godnych przeczytania. W trakcie om awiania pov szczególnych zagadnień będę m ó w ił o książkach, do których należy zajrzeć po dodat kowe informacje na temat U M L - a , i ogólnie o analizie obiektowej i projektowaniu obiektowym. Oczywiście, p o tej książce pierw szą lekturą pow inny być książki „trzech m uszkie te ró w ” o UML-u. • G r a d y Booch przewodził pracom nad podręcznikiem użytkownika [6], który opisu j e sposoby, w jakich może być użyty UML do wykonania różnych zadań. • Jim Rumbaugh przewodził pracom nad raportem [37], Często korzystam z tego s z c z e g ó ło w e g o podręcznika. • Iv a r Jacobson przewodził pracom nad książką opisującą proces zharmonizowany z U M L - e m [23J. Powiem więcej o zagadnieniach związanych z procesem w roz d z ia le 2 . J e d n a k że , k s ią ż k i „trze c h m u s z k ie te ró w ” nie są je d y n y m i, które należy przeczytać, aby się d o w ie d z ie ć o a n a liz ie o b ie k to w e j i p rojektow aniu. M o ja lista polecanych ksią że k z m ie n ia się często, d la te g o w arto zajrzeć na m o ją stronę W W W po szczegóły. Jeśli p o ję c ia z zakre s u te c h n ik o b ie k to w y c h nie są w ystarczająco znane, to polecam m o je o b e c n ie u lu b io n e w p ro w a d z e n ie —
Larm an [2 8 ], A u to r stosuje podejście do
o b ie k to w o ś c i o p a rte na z o b o w ią z a n ia c h , które w arto sobie p rzysw o ić. A b y d o w ied zieć się czegoś w ię c e j o o b ie k ta c h z p u n k tu w id z e n ia p o ję c io w e g o , to w a rto zajrzeć do
27
UML-a Programiści systemów d/1;,. . • a i Odell, p * l P” l i 0 zawieraj., one materiał wydm. książki Martma yWistym P° 0 wz0rcach akończone, myślę, /c dzie. tajncycb « « • przeczytać k s t ^ meUK| zost. ieka„ s z c rzeczy o anai.zie Proponuję T raZ gdy , p o ja w » * się • « n o w e te c h n ik i analizy to c y poza P‘,dsT w m polem. ¿e ludzie " f f * * z U M L „em les,
sg ś-^ -
n0WVCh “
Szkicowy proces tworzenia oprogramowania i
Rozdział
— U M L jc s t j a k i e m
tworzenia oprogramow Tytllł teJ Nie w,ercęjed * ’
m
-
^ o ^ n o
y
.
w ttM L - u nie ma pojęcia procesu
^ nie metodą. ^ w ażną c z ę s tą
kropelce, mógłbym
z i g n o r o W a ć p n .e e
?
ja k iko lw ie k sens be/ /na-
technik mode o w ^ ^ l e m się om ów ić najp.e,, llia jo procesu. Dlatego tez z y ¡e 0biektow e i tworzenie
j0m0iCiS i i można było zobaczyć, jak dzl^ ^ t w o r z e n i a oprogram owania, pooprogramowania Nazywam go szk.cowym p ro c ^ ^ ^ ^ ^ ,|e pQ, , ahy zdac nieważzamiast wchodzie w szc“ f ° J /0^, dzony projekt stosujący te techm sobie spraw? z tego, jak jest zwykle pow adź J P nazWany RUP (ang. RatioTrzej muszkieterowie” utworzyli zuml ko y H proces ten został opisany nal Unified Process, który kiedyś rS 21| 1° b’eC W w książce Jacobsona, Boocha i Rumbaugi L J m term in o lo g ii i ogólnych ram W trakcie omawiania szkicowego P , 0 do tematu tej książki. Będę raRUP-u. Nie próbuje jednak opisać RU - . nrnces któ ry jest spó jny z proceczej opisywał ..odciążony' i mato s ortna RUP-u należy zajrzeć do książki sen! firmy Rational Software. Aby poznać szczegóły RUP u, należy trzech muszkieterów” [231 albo do omówienia Knichtena [27].
’ MinmTe RUP zaw/era inforniacje o tym, jakie rodzaje m odel, m ożna tw o rzyć na kolejnych etapach procesu, to ja me bedę wchodził w tak,e szczegóły. N ie będę tez specyfikował zadań, produktów końcowych i ról. M oja term in olo gia je st m n ie j setsła niż ta uż>fta w RUP-ie — jest to cena, jaką się płaci za zwięzłość opisu. Niezależnie od tego, jakie aspekty procesu opisuję, należy pamiętać, że m ożna sto sować razem z UML-em dowolny proces. U M L jest niezależny od procesu. W każdym wypadku należy wybrać to, co jest odpowiednie dla danego projektu. N iezależnie od tego, jaki proces będzie zastosowany, to i tak można użyć U M L -a do zapisu w y n ik ó w analizy i decyzji projektowych. Tak naprawdę to nie wydaje mi się, że może istnieć ty lk o jeden proces dla tw o rze nia oprogramowania. Wiele czynników związanych z tw orzeniem oprogram ow ania prowadzi do wielu różnych procesów. C zynniki te obejm ują rodzaj oprogram ow ania, jakie jest tworzone (oprogramowanie czasu rzeczywistego, system y inform acyjne, oprogramowanie dla komputerów osobistych), wielkość zespołu (jeden program ista, mały zespół, zespół ponadstuosobowy) itd. J 2 *bardziej “ ZCSp° ty dobrą P0T radę, nyJSI°P 1WOrzyć własne P w e s.v . traktu jąc te o p u b li kowane jako niżni0W0 standardy wymagałamn r,» wym agające przestrzegania.
2.1
OP's Procesu
«ramowania.
PrZeds,awia wVS(»hopoziomowe spojrzenie na proces tw o rz e n ia o!
r r ™ ^ « r a m o w a n i e nie statecznej na kon.ee p ro jektu , ale je s t raczej cios
S zkico w y proces t w o r / c n u oprogramowania
czane we fragmentach i k o l ii w każdej z nich jest t w o r z o i r ^ ' Wers,ac*1 Faza budowy składa się z wielu iteracji, lająca podzbió” podzbiór * ' CS,0Wana 1 »'«¡growana integrowana produkcyjna piouuhcyjna wersja oprograniowania spełniająca czane k lie n to w i zew nętrznem ' \ ma^an Pr°jcktn. Oprogramowanie może być dostarstane w y łą c zn ie w e w n e t r z ^ - Ul,’ ^ ^ o w n i k o m pilotażowym lub może być w ykorzyfazy tw orzenia oprogram ow - W la n ,a c *1 projektu. Każda z iteracji zawiera takie zw ykle nie. an,a J3*4 analiza. projektowanie, implementacja i teslowa-
R o z w in ię c ie
R ysunek 2.1. Szkicow y proces tworzenia oprogramowania
ia k a ś f u n k r i n m i • ; • U ow ac oprogram owanie, idąc od początku do końca: wybrać fiin lm in n itm / u n° SL ' / a i m P*tfmentować ją , potem wybrać jakiś inny zespół wym agań
Ianowanie
'
Z a illl^^ementovva^ ' ,ck W arto jednak poświęcić trochę czasu na
P ie r w s z y m i d w ie m a fazam i są in icja c ja i rozwinięcie. W czasie inicjacji należy określić c e lo w o s c p ro je k tu i je g o zakres. W tej właśnie fazie uzyskuje się poparcie
Rozdział 2
sponsora p ro je k tu i je g o decyzję o kontynuacji prac. W rozw inięciu zbiera się bardziej szczegółowe w y m a g a n ia , w y k o n u je w y sokopoziom ow ą analizę i tw orzy projekt pod stawowej a rc h ite k tu ry , aby opracow ać plan dla fazy budowy. Nawret przy p rz y ję c iu tego iteracyjnego procesu trochę pracy trzeba odłożyć na sam koniec, do fa z y w d ro ż e n ia . Praca ta obejm uje testowanie wersji beta. dostrajanie w y dajności systemu i s zk o le n ie u ży tk o w n ik ó w . Projekty różnią się stopniem fo rm a liz a c ji. Bardzo form alne projekty m a ją w iele produktów końcowych w fo rm ie papierow ej, w y m a g a ją w ielu spotkań i akceptacji. Mało formalne projekty m o g ą m ieć fazę inicjacji zło żo n ą z godzinnej pogaw ędki ze sponsorem projektu i p lan p racy w postaci arkusza kalkulacyjnego. O czyw iś cie , im w'iększy jest projekt, tym większa potrzeba jego form alizacji. Podstawowe elem enty faz pojawiają się nadal, ale na bardzo różne sposoby. Staram się w jak najmniejszym stopniu formalizow'ać pracę i ta książka to odzwier ciedla. W innych podręcznikach można znaleźć wiele bardzo sformalizowanych pro cesów do wyboru. Pokazałem iteracje tylko w fazie budowy. Chociaż iteracje mogą wystąpić w każdej z faz i warto je stosować, gdy faza jest rzeczywiście duża, to jednak faza budowy jest tą najistotniejszą fazą, w której należy je stosować. Tyle gwoli przeglądu. Teraz warto przejść do szczegółów, żeby zrozumieć, jak techniki omawiane w dalszej części książki pasują do ogólnego procesu. Omówię po krótce niektóre techniki i pokażę, kiedy należy ich używać. Niektóre z nich mogą być nowe i z tego powodu wydawać się niezrozumiałe, dlatego można pominąć ten frag ment i wrócić do niego później.
2.2
Faza inicjscji
• ' ' 7 np fo r m v W n ie k tó r y c h p r o je k t a c h jest to p o g a w ę d k a p r/N In ic ja c ja m o ż e m ie c ro ż n e f yu m jc ś c ić n a s z k a t a lo g u s łu g na M ro iu h j, k a w ie typu: „ Z o n c n tu j się, J. w y p a d k u w ię k s z y c h
WWW. W
h y c p e łn e , w i e l o n i i c s i ę c / n c
projektów może to oy
d iu m m o ż liw o ś c i.................
,
.
v
c e |o w o ść p r o je k t u —
i,
stu-
w p r z y b l i ż e n i u , dc Iw .
W czasie ta z y in ic ja c ji op J^ Należy również n a s z k ic o w a ć z a k re s prc). d zie k o s z to w a ć i |a k ie k o rz y ś c i przyniesie. N ależy ros w ie lk o ś ć , , „l „ je k tu M o ż e też być p o trz e b n a wstępna analiza w celu o s z a c o w a n ia I k o s t za d a n ia
Nie mam zamiaru robić z inicjacji czegoś większego, mz jest w
is to c ie
P o w u in a
ona za ją ć p arę d n i. a b y m ó c s tw ie r d z ić , c z y je s t w ą t ł o w l o z y c k i l k a m ie s ię c y pracy
w pogłębienie analiz w fazie rozwinięcia.
N a t y m e ta p ie s p o n s o r j e d y n i e
godz,
się, aby
sp o jrze ć na p ro je k t p o w a ż n ie j.
2.3
Faza rozwinięcia
Pojawiło się zielone światło od sponsora. N a r a z ie j e d n a k m a r n y tylko n ie ja s n e po jęcie na temat wymagań. Na przykład: Dla Watts Galore U tility Company zbudujemy system n o w e j g e n e r a c j i wspomaga jący kontakty z klientami. Zastosujemy technologie o b i e k t o w e , a b y u t w o r z y ć system bardziej elastyczny i taki, który jest ukierunkowany na k l i e n t ó w — w s z c z e g ó ln o ś c i zapewnimy klientom zbiorcze rachunki za świadczenia. Oczywiście, oficjalny opis wymagań będzie szerszy, ale n i e k o n i e c z n i e b ę d z i e mó w ił o wiele więcej. W tej chwili należy lepiej zrozumieć problem. • •
Co tak naprawdę będzie budowane? Jak to będzie budowane?
Decydując o tym, jakie zagadnienia obejmie ta faza, należy m i e ć n a u w a d z e z a g r o żenia dla projektu. Im większe zagrożenie, tym więcej u w a g i należy mu p o ś w i ę c i ć Moje doświadczenie każe mi klasyfikować zagrożenia w czterech k a t e g o r i a c h . 1. Zagrożenia ze strony wymagań. Jakie są wymagania dla systemu? Istnieje duże niebezpieczeństwo, że zostanie zbudowany zły system, tzn. taki, k t ó r y n i e ro b i tego, czego potrzebuje klient. 2. Zagrożenia techniczne. Jakie są zagrożenia techniczne? Czy wybierana technologia wystarczy, aby spetmc wymagania? Czy wszystkie elementy będą do siebie p a s o 3'
7 ’H* d° slaleczny ch umiejętności zespołu. Czy można znalezc odpowiednio wiele osob z odpowiednim doświadczeniem? w ^ h z a c ji projektu?'
^
Są jakles slly Po li«yczne, które m ogą przeszkodzić
czteiy kategorie, prawie zawsze występują6'' *
Zagr° Żenla’ k,óre zawiera«
Podane
2 .3 . 1
R a d z e n i e s o h i o -»
° ie z zagrożeniam i ze strony wym agań
Punkiem rta rto w y m 's a 'n rlW S^ ostaniu 1,11 'nogąpom óc odpowiednie techniki U M L -a coscm 1 yPadk> użycia systemu. Przypadki użycia sterują całym proP r/y p a d k i użycia svMti»nn. dynie, czyni one są um ówię szczegółowo w rozdziale 3.; tutaj wyjaśnię jc P r/yp a d c k użycia svstpm .1 s\stcincm , d zic ki ktrSrJ Jf st ° P lsem typowej interakcji między użytkownikiem i,.... . „ i . , 1-1 uz>'tko w n ik chce osiągnąć pewien cel. Przykładem może W ,eJ Chwm Z przypadków u ży c a W a ż n \ m eloi * ’ mn^m — ..utwórz indeks dokumentu” . / n i m 117 v i L . i . » . ° n em P ^ y p a d k ó w użycia jest to. że każdy z nich opisuje funkcję 111 ° U I 1 niajĄcą dla niego jakieś znaczenie. Programista na przypadek ^ Z h T f ° 'm Ć P° dam em “ O g ó ł ó w . Na przykład: ' ^ ..C tU nii ey SOWania zajm ie mi dwa miesiące. M am też do zrobienia przypadek u z}xu i a spj a u c -c in ia składni — to mi zajmie jakieś trzy miesiące. M am y tylko trzy m it s ią n ( o a on t l e n i a którego z przypadków użycia potrzebujesz bardziej? r /y p .u i u ży cia systemu stanow ią podstawę komunikacji między klientem a prog ra m is ta m i p rz y p la n o w an iu projektu.
T
{Q
Jedną / n a jw a żn ie js zy c h rzeczy, jaką należy zrobić w fazie rozwinięcia, jest w y krycie w s z y s tk ic h m o ż liw y c h przypadków użycia budowanego systemu. W praktyce, oezyw iście, w s z y s tk ic h w y c h w y c ić się nie da. N iem niej, trzeba w ykryć ich jak najw ię cej. a w s zczeg ó ln o ści te najw ażniejsze i stanowiące największe zagrożenie. Dlatego
} >
też w fazie ro z w in ię c ia , aby zebrać przypadki użycia systemu, należy przeprowadzić rozmowy z u ż y tk o w n ik a m i. Przypadki u ż y c ia nie m uszą być szczegółowe. M n ie wystarcza zw y k le od jednego do trzech akapitów opisu. O pis ten p ow inien być wystarczająco konkretny, aby u żyt kownicy zrozumieli, o co ch odzi, a programiści w ied zieli, co czai się w środku z punktu w idzenia p rz y s z łe j im plem en tacji. Jednak p r z y p a d k i u ży c ia systemu to nie wszystko. Innym w a żn y m zadaniem jest wymyślenie s z k ie le tu m o d e lu p ojęciow eg o dziedziny projektu. Z w y k le k ilk u u ży t k o w n ik ó w m a w g ło w a c h o braz tego, ja k działa ich przedsiębiorstwo. N a przykład: N a s i k lie n c i m o g ą m ie ć k ilk a o d d zia łó w i na rzecz każdego z nich możemy ś w ia d czyć k ilk a u sług . O b e c n ie k lie n t otrzym uje rachunek za wszystkie usługi dla danego o d d z ia łu . C h c e m y , a b y k lie n t o trz y m y w a ł rachunek za wszystkie usługi we wszystkich o d d z ia ła c h . N a z y w a m y lo ra c h u n k ie m zbiorczym .
Podany fragment zawiera słowa „klient , „oddział i „usługa. Co oznaczają ic terminy? Jak do siebie pasują? Model pojęciowy dziedziny jest pierwszym krokiem do tego aby zacząć odpowiadać na te pytania, i jednocześnie kładzie podwaliny pod mo del obiektowy który w dalszych fazach procesu będzie stosowany do reprezentowania obiektów w systemie. Używam terminu model dziedziny do nazwania dowolnego mo delu. którego podstawową rolą jest opis świata wspieranego przez komputei, niezależ nie od fazy procesu tworzenia oprogramowania. ... Warto zwrócić uwagę na to, że RUP
S zkicow y pioccs tw orzenia oprogram owania
2.3.1
Rddzenie sobie
z zagrożeniam i ze strony wym agań
W ym agania są ważne i w t n ,„ . P unktem s ta rto w y m są pnzypi.dkT " " mogąpomóc odPow 'ednie techniki U M L -a użycia systemu Przypadki użycia sterują całym procesem 7 jasntę je te, czym S^ stemu onK)VVfię szczegółowo w rozdziale 3.; tutaj wyjaśi dynie, czym one Przypade vsternem ^esl °P*seni typowej interakcji między użytkownikiem a systemem d zięki której użytkow nik chce być edytor tekstów, k t ó r e g ^ w ^ c h w i l ^ peWie" Cel Przykladem mOŻC byłoby ^ s p ra w d ź'o n o g ra fie " 0 , m n"' ChWi1' “f * " ™ 1 ,e d " ym Z PrzyPadków ^ » a innym — „utwórz indeks dokumentu \
m in a
P ^ P ^ k ó w użycia jest to, że każdy z nich opisuje funkcję
Ż v r ii n in 7 f* * * ° W' * d 'a meg ° lakieś znaczenie. Programista na przypadek użycia m oże zareagow ać podaniem szczegółów. Na przykład: Z ro b ie n ie indeksow ania zajm ie nu dwa miesiące. M am też do zrobienia przypadek liźycta o s p ra w z a n ia składni — to mi zajmie jakieś trzy miesiące! M am y tylko trzy miC\h -r jn Air'0 0ncze>uu którego z przypadków użycia potrzebujesz bardziej? rzy p a i u ży cia systemu stanowią podstawę komunikacji między klientem a pro gram istam i p rz y p lanow aniu projektu. Jedną z n a jw a żn ie js zy c h rzeczy, ja k ą należy zrobić w fazie rozwinięcia, jest w y krycie w s zy s tk ic h m o ż liw y c h przypadków użycia budowanego systemu W praktyce, oczywiście, w s zy s tk ic h w y c h w y c ić się nie da. Niem niej, trzeba w ykryć ich ja k n ajw ięc\
ceJ> a w szczególności te najważniejsze i stanowiące największe zagrożenie. Dlatego też w ia z ie r o z w in ię c ia , aby zebrać przypadki użycia systemu, należy przeprowadzić rozmowy' z u ż y tk o w n ik a m i.
0 v>
P rz y p a d k i u ż y c ia nie m uszą być szczegółowe. M n ie wystarcza zw y kle od jednego do trzech a k a p itó w opisu. O pis ten p o w in ien być wystarczająco konkretny, aby u żyt
1
k o w n ic y z r o z u m ie li, o co chodzi, a programiści w iedzieli, co czai się w środku
ko
z p u n k tu w id z e n ia p rzy s złe j im plem entacji. J ed n ak p r z y p a d k i użycia systemu to nie wszystko. Innym w a żn ym zadaniem jest
V
w y m y ś le n ie s z k ie le tu m o d e lu pojęciow ego dziedziny projektu. Z w y k le k ilk u u ż y t k o w n ik ó w m a w g ło w a c h obraz tego, ja k działa ich przedsiębiorstwo. N a przykład: N a s i k lie n c i m o g ą m ie ć k itka o d d zia łó w i na rzecz każdego z nicli możemy ś w ia d czyć k ilk a usług. O b e c n ie k lie n t otrzym uje rachunek za wszystkie usługi d la danego o d d z ia łu . C h c e m y , a b y k lie n t o trzy m y w a ł rachunek za wszystkie usługi we wszystkich o d d z ia ła c h . N a z y w a m y to ra c h u n k ie m zbiorczym .
fragment zawiera słowa „klient", „oddział’ i „usługa. Co oznaczają te te rm in y ? Jak d o siebie pasują? Model pojęciowy dziedziny jest pierwszym krokiem do tego a b y z a c z ą ć odpowiadać na te pytania, i jednocześnie kładzie podwaliny pod mo del o b ie k t o w y , k tó r y w dalszych fazach procesu będzie stosowany do reprezentowania o b ie k tó w w s y s te m ie . U ż y w a m te rm in u m o d e l dziedziny do nazwania dowolnego m o delu, k tó r e g o p o d s t a w o w ą ro lą jest opis ś w ia ta wspieranego przez komputer, niezależ Podany
nie od f a z y p ro c e s u tw o r z e n ia o p ro g ra m o w a n ia . W a r to z w r ó c ić u w a g ę na to, że R U P
Term in „m o d e l d z ie d z in y ” w ę z ie j
[2 3 ]. U ż y c ie te g o te r m in u w tej ksią żc e j ę l K f ó t f t a f e m
znanych mi
Jak “ ży w ® 8 ° w ię k s zo ś ć
o s ó b z e „ s p o łe c z n o ś c i o b ie kt
33
^ w k ro p e lc e
«zczesólnie cenne
• H M L a są dla 0111,6 Dwie technik« ^ -* jęciowego dziedziny. użyWani przy two
budowie modelu
m odcli t|/ lc t |/)n , to dwgi-amv , ■ , 4 }< Można stosować te dia.
ja k im o p e r u j ^
01
e
"
zadań |0 d0 oplsu używan, diagram ów czynność, jest u,,
dżina zawiera element
diagramówczynności (zobacz
p o l e g ł y c h , co .¡es, ważne przy usuwawykrywani a p m c e s o w o 2 prowadzeń,em dztalą,.
zachęcają one do niu niepotrzebnej sekwencyjnosc, w proce.
i
n° Niektórzy stosują d ia g ra m y interakcji (zobacz rozdział 5.), aby badać interakcje I różnych ról w przedsiębiorstwie. Myśląc o pracownikach i działaniach jednocześnie, łatwiej im zrozumieć cały proces. Wolę najpierw zastosować diagramy czynności, aby zrozumieć, co należy zrobić, a dopiero potem zastanawiać się, kto ma to ziobic. Modelowanie dziedziny może być świetnym uzupełnieniem przypadków użycia systemu. Gdy zbieram przypadki użycia, to korzystam z pomocy eksperta i spraw dzam, za pomocą koncepcyjnych diagramów klas i diagramów czynności, jakie iost jego wyobrażenie o dziedzinie. " w takiej sytuacji notację ograniczam do m inim um , nie m artwię się o form alizm i robię dużo notatek na diagramie. Nie staram się uchw ycić wszystkich szczegółów. Zamiast tego skupiam się na ważnych zagadnieniach i obszarach, które m ogą być źró dłem zagrożeń. Rysuję mnóstwo niepołączonych diagram ów i nie m artw ię się o spój ność i związki między nim i. Z doświadczenia wiem, że dzięki temu procesowi szybko zaczynam rozumieć dziedzinę. W ten sposób mogę łatw iej identyfikow ać przypadki użycia systemu dla różnych użytkowników. Po przejrzeniu wszystkich istotnych obszarów konsoliduję diagram y w jeden spoi ny model dziedziny. W tym celu korzystam z pomocy ekspertów ze strony u ży tk o w n i ka, którzy mają ochotę zagłębić się bardziej w m odelowanie. D alej utrzym uję perspek tywę pojęciową, ale jednocześnie staram się być bardziej ścisły. W efekcie model może być użyty ja ko punkt startowy do tw o rzen ia klas w fazie budowy. Jeśli model jest duży, to używam pakietów , aby go rozbić na m niejsze kawalki. Konsoliduję również diagramy klas i czynności i czasami rysuję parę diagramów stanów dla klas, które mają ciekawy cykl życia. Trzeba myśleć o tym wstępnym modelu ja k o szkielecie, a nie m odelu wysokopoztomowym. Term in
model w ysokopoziom ow y” sugeruje brak w ie lu szczegółów
W ielokrotnie w idziałem , ja k ten błąd popełniano, m ów iąc na p rzy k ła d : „ N ie pokazu, zro zu m ^ M d,agram ach. Re2U^ m był m odel za w ie ra ją c y m ało „esc, Łatwo zrozumieć, dlaczego programiści gardzą czym ś takim . ale m ° z a im u t d n f n T “ polega n n X i i u
przeciwstawnc P ^ e jś c ie i zbudow ać m odel szczegółowy,
ls m SU L “
*afW0. l,gr™
w
m asy detal,
Sztuka
gółów i tak trzeba się z a ją ć w tra k d e i em ' ?kUplen,U S'? " a n ic h ’ W i ?kszościil SZCZC" iteracyjnego tw o rzen ia o p ro g ram o w an ia. Dlatego
S /k ic o w y proces tw orzenia oprogram ow ania
też wolę myśleć o tym mo
° s/-k>elecie. Szkielet test podstawą dla reszty mo-
O czyw iście, w s ^ t l c o 10 aWler3' ' y llt0 a co nie — jest to zadaniem doh m ° W1, |ak odróżn>ć ziarno od plew — co jest istotne, trować w jednej kropelce ° anal‘tyl
e nie udało mi się tego skoncenM o d e lo w a n ie dziedziny w miarę ja k są one poznaw -ineStw ° Wnież sterowane przypadkami użycia systemu, men przyglądać się im aby o * 'Ch P0Jawiania si
byĆ ma,y (dw ie‘ cz,ery o s o b y )' skladać cd2m,e- NaJnin,eW rozsądny zespół to
r le li^ W ^ tv m ó t '1 p ra c o u a d in te n s y w n ie podczas fazy ro z w in ię c ia aż do d o m k n ię c ia «uyr72i 7 l w Q7 r 7 P »A* u ,mvvu piujeKiu powinno dbać o lo, aby zespół ani nie c ' i n oKii»r^^ aQ] ' an* n *e Pracowal na zbyt wysokim poziomie. Z chw ilą gdy ze.. i ° sU tatJczema, największym niebezpieczeństwem jest utknięcie w go ac atego w arto w yznaczyć krótki i nieprzekraczalny termin zakończe
nia prac.
E le m e n te m w ła ś c iw e g o zrozum ienia wymagań powinno być zbudowanie prototypu s k o m p lik o w a n y c h fra g m e n tó w przyp ad kó w użycia systemu. Prototypowanie jest cen ną te c h n ik ą w s p o m a g a ją c ą zro zum ien ie tego, |ak działa system w bardziej złożonych sytuacjach.
Prototypuję z a k a ż d y m razem , gdy nie jestem pewien, ja k złożona część systemu będzie naprawdę d ziałać. Prototypuję wystarczająco w iele, aby ocenić zagrożenie i oszacować, ile w y s iłk u będzie kosztowała implementacja. Z w y k le nie prototypuję wszystkiego — z a m ia s t tego korzystam z modelu dziedziny, aby określić obszary w y magające prototypowania. Moje d o ś w ia d c z e n ie m ó w i, że now icjusze U M L - a muszą więcej prototypować. Po m aga im to p o z n a ć , j a k d ia g ra m y U M L - a m ają się do rzeczywistego program owania. Stosując p r o to ty p o w a n ie , nie m ożna ograniczać się do środowiska, w któ rym jest tworzony system p ro d u k c y jn y . N a p rzy kła d bardzo pom ogły m i prototypy napisane w Smalltalku, mimo że system p ro d u k c yjn y pow staw ał w C + + . J e d n y m z najważniejszych elementów radzenia sobie z zagrożeniami ze strony w y m a g a ń jest dostęp do ekspertów w danej dziedzinie. Brak dostępu do ludzi, którzy zn ają d a n ą dziedzinę, jest najczęstszym powodem klęski projektów. Warto zainwesto wać czas i pieniądze, aby pozyskać do zespołu ludzi, którzy naprawdę znają daną d z ie d z in ę ja k o ś ć o p r o g r a m o w a n ia hęd/.ie wprost proporcjonalna do jakości eksper tó w E k s p e rc i p e łn o e t a t o w i nie są konieczni — ważne, aby mieli otwarte u m y s ły , p ra k ty c z n ie r o z u m ie li d z ie d z in ę i b y li dostępni, aby m óc odpowiadać na pytania. 2.3.2
R a d z e n ie sobie z zagrożeniam i technicznymi
Najważniejszą rzeczą w radzeniu sobie z zagrożeniami technicznymi jesl budowa prototypów weryfikujących te elementy techniczne, które będą użyte.
5
„
r+ + i relacyjnej ba/y danych, n a lc/y /.budów.,,' J ' y Jm yęh. War... wypróbować pa.y
Na przykład używając sta a p lik a c ję w C + + k o rzys ta ją*. . , sprawdzić, które z nich nadaj« „¡«bezpieczeństwo tcchn.c/nc kry|e Nie można zapomnieć o tym. « ^ jw it, ^ ^ m th samych Można /nac cl..|,IVc w dopasowaniu komponentów o s . v j„y m i bazami danych, ale polac/cnic i... | język C + + . świetnie radzić sobie z ret D |a(eg0 ,eż bardzo ważne ,est Al(, dwu elementów może byc ntespodziec ,p,.hnjcznych i dopasowanie ich do s „ h hycie wszystkich potrzebnych elemen ov już w tej wczesnej fazie procesu. . dotycząCym i architektury systemu |a W tej fazie należy tez zając się d y j zbudowane. Jest to szczególn,,. kie są główne elementy techniczne i jak mają oye ważne, jeśli planuje się w“ ' * , ^ ' en7 o S . c h . które w ydajn *•« trudne do W ramach tej pracy należy p system, tak aby później umożliwiał dyfi kowani a w przyszłości. Treebaproje sobie następujące pytania: względnie łatwą zmianę jego elementów, w an • •
Co się stanie, gdy dany element techniczny przestanie działać'. Co się stanie, gdy nie będzie można zintegrować dwu elem entów.
.
Jakie jest prawdopodobieństwo, że coś się popsuje? Co robic w takiej sytuacji
Podobnie jak w wypadku modelu dziedziny w miarę pojaw iania się pizypadków użycia systemu należy sięgać po nie, aby ocenić, czy nie zaw ie ia ją czegoś, co mogłoby zagrozić projektowi. Jeśli coś wskazuje na to, że przypadki użycia zaw ierają wirusa, który może objawić się później, to należy pogłębić analizę. W trakcie pracy stosuje się wiele technik U M L-a do notow ania p o in yslo w i doku mentowania dotychczasowych prób. Na razie nie trzeba obejm ow ać wszystkiego jest potrzebny jedynie ogólny zarys. • • •
Diagramy klas (zobacz rozdziały 4. i 6.) i diagramy in te rakcji (zobacz rozdział 5.) są pomocne w ilustrowaniu tego, ja k kom unikują się ze sobą elem enty składowe. Diagramy pakietów (zobacz rozdział 7.), na tym etapie, z ilu s tru ją w ysokopo/iom owy obraz elementów programistycznych. Diagramy implementacji (zobacz rozdział 10.) zapew nią przegląd tego, ja k są roz mieszczone wszystkie komponenty systemu na elementach sprzętow ych.
2.3.3
Radzenie sobie z zagrożeniami wynikającymi z niedostatecznych umiejętności zespołu M konferencjac,h stucham analiz ludzi, którzy w łaśnie z a k o ń c zy li projet
p o w ,e d 7„Powinniśmy p o tfn yn ^ n v byli I t h byc ” -?lepiej w^yszkoleni” naJw i«kszVm błędem ?" zaw sze pada od powieaz. . projekty ^obiektowe 'z n ik c im n ^ ^ ^ l0 ’-Że przeds"ib lo rstw a ro z p o c z y n a ją poważa zdobyć potrzebna wiedze i m b } MJOmostl:' tem atyki i m in im a ln y m pojęciem , jal sumę W miarę przeciągania się p r o j e k t u ^ ° k ° SZ,y Szkoleń- ale Potem P,ac;l kazd kiedyś je popełnili. Robienfe b M ó w n o ' n 11'6 b,ędÓW’ P ° n ie w a ż in s tru k to rzy już
san
*
' *
a .e b r a k
^
W
^
S z k ic o w y proces tw orze n ia oprogram ow ania
N ie jestem w ie lk im z w o i* u kursach i parę z nich n a w i kiem ,ol™alnych szkoleń. Sam nauczałem na wielu teczne w nauczaniu „ '„ ,,1 ^ z ^ otow a,em- Ciągle me jestem przekonany, ze są skuprzegląd tego, co m uszą 5 S z 7 ąza"Vch z obiektowością. D a ją one ludziom umiejętności, które są Dohv >h naprawdę nie przekazują tych istotnych pożyteczne, ale to ty lk o p o c z ą t e k *
P° WaZnym proJekcie 1Crólk,e s z k o l e n i e m o z e by c
i-tn m i \vie l 7 f> i r,;1,3 k lo ,k ie szkolenie, warto zwrócić uwagę na instruktora. Komuś, niego n auczyć M o ż n a T e T n o t e U ^ 0 Za.plac!ć w,ęce->' bo dllżo więce-' ,nożna się od mi m iarę n o trze h r w i . swoje szkolenie na części i potem korzystać z nich stosow ać w p r a k t y c e * m .sp
111 Poc*ejściu wiedzę ze szkoleń można od razu zacząć
S^ ° s? b e m na zdobycie w iedzy obiektowej jest wprowadzenie do zeośw iadczon ego programisty, biorącego udział w pracach projekto p ez uzszy czas. Ekspert pokazuje, jak coś zrobić, obserwuje, co robią inni, azuje \ \ s 'azow -i i daje krótki instruktaż. Ekspert, pracując nad konkretnym i za-
Rozdział 2
wy0 prze ga eniami p ro je tu. będzie w ie d zia ł, które techniki kiedy i ja k stosować. Począt kowo e spert je s t c z ło n k ie m zespołu pom agającym znaleźć rozwiązanie. W miarę upływu czasu c z ło n k o w ie zespołu sami n abyw ają coraz więcej umiejętności i ekspert stopniowo zajmuje się b ardziej w e ry fik a cją pracy niż samym jej w ykonyw an iem . Moim celem, jako eksperta, jest stanie się zbędnym. Można s p ró b o w a ć zn a leźć eksperta dla całego projektu lub też tylko dla w ybranych zagadnień E k s p e rc i m o g ą być pełnoetatow ym i lub niepełnoetatow ym i członkam i ze społu. Wielu z n ic h lu b i p ra co w a ć nad projektem przez tydzień w każdym miesiącu, inni wolą d łu ż e j. T rz e b a szukać eksperta z w ie d zą i takiego, k tó iy umie tę w iedzę przekazać. E k s p e rt m o ż e być n a jw a żn ie js zy m czyn n ikiem sukcesu projektu — warto zapłacić za jakość. Jeśli nie można z n a le ź ć eksperta, to w arto rozw ażyć przeprow adzanie co k ilk a m ie sięcy audytu projektu. W' ta k im w y p a d k u dośw iadczony specjalista przychodzi na k i l ka dni, aby przyjrzeć się ró ż n y m aspektom projekui. W tym czasie m oże on w skazać obszary budzące niepokój, podać dod atko w e pom ysły i naszkicow ać użyteczne techniki, których zespół projektowy m oże nie znać. M im o że nie m a to w szystkich zalet stałej obecności eksperta, to m oże być pożyteczne w e w skazaniu rzeczy, które można zrobić lepiej. Warto też uzupełnić wiedzę lekturą. Co najmniej raz na dwa miesiące należy prze czytać |eden solidny podręcznik techniczny lub jeszcze lepiej — przeczytać go w gru pie. Należy znaleźć paru chętnych, którzy chcą przeczytać tę samą książkę, ustalić, że będą czytali po kilka rozdziałów na tydzień, a potem dyskutować o tym, co przeczy tali. Postępując w ten sposób, można lepiej zrozumieć książkę, niż czytając ją samemu. Kierownik projektu powinien zachęcać członków zespołu do takiej wspólnej nauki, a także u m o ż l i w i ć podobne działanie, oferując pomoc, na przykład finansową, czy re zerwując na to czas w planie pracy .
Jest to podejście oparte na tak zwanych kółkach czytelniczych (ang. study groups) Joshuy Kenevsky’ego (zobacz http:/Mww.induslńallogicxvm/papirs/leiirnmg.html) i zastosowa nych do nauki wzorców (przyp tłum.).
37
m
, uznało czytanie w grupie za szczegół,„c j , ... wzorcami studiowaniem wzorcow Al, ^ r u “ « ^ w grupie, warto za,rzec na .....
k n T c k ^ ___
p
^
^
S
cnbie z z a g ro ż e n ia m i p o lity c z n y m i R a d z e n ie politykiem . Natomias, ■
2.3.4
¿
7
¡
35
s
s
t s
s
s
t &
z
*
-
*
-
m>ń f 3 7 e ro z w in ię c ia z a z a k o ń c z o n ą
Kiedy m ożna uznać fa zę roz . • , „r..h«ya na
c a le g ^ e iT
o k o ło
jedną piątą czasu trwania
które pozwala« uznać tę faz« » -ko ń czo -
" ą Proeramiści są w stanie podać z dokładnością do jednego osobotygodma koszt imnlementacii każdego przypadku użycia i są w miarę pewni swych oszacowań. . Zidentyfikowano wszystkie znaczące zagrożenia i o tych najważniejszych wiemy wystarczająco wiele, aby móc określić, jak sobie z mm, będziemy dawali radę.
2.4
Planowanie fazy budowy
Jest wiele sposobów na zaplanowanie projektu iteracyjnego. Samo opracowanie planu jest ważne, aby móc śledzić postęp prac i móc przekazać inform acje o nim zes połowi. Jeden ze sposobów planowania, który stosuję, jest oparty na technikach przed stawionych w [2]'. Istota budowy planu pracy polega na ustaleniu ciągu iteracji budow y i zdefiniowa niu funkcjonalności, którą należy dostarczyć w każdej z iteracji. N ie k tó rz y lu b ią zaj mować się niewielkimi przypadkami użycia systemu i w jednej ite ra cji dostarczać ich pełną funkcjonalność. Inni wolą zajmować się większym i przypadkam i użycia dostarczając funkcjonalność pewnych przypadków użycia w jednej ite ra c ji a in n y c h w póź niejszych iteracjach Podstawowy proces jest taki sam. Opiszę go w zastosowaniu do mniejszych przypadków użycia. Podczas planowania myślę o dwu grupach ludzi - klientach i program istach Klienci będą wykorzystywa ł system w swoiei firm ie n i , , nego. prosto z polki sklepowej, klientam i zw y e e ** oceniający lub kupujący ten system do lim ,,, i> i Zlalu m aiketm gu-
potrafią ocenić wartość im p le m e n to w a n e j' p ™ l°* ŻC kUcnC' przedsiębiorstwa. cwanego przypadku użycia z punktu widzenia
' Warto zajrzeć też na strony W W W - httn-n P
’w.ojctremeprogramHung.org (przyp. tłum )
j
S zklco» y Pr°c c * tw orzenia oprogramowani;
P rogram iści b u d u j, syslem M u s do im plem entacji p r z y p a d ł,
. »
. .
,
swlaŁ,oni1 kosztów i wysiłku potrzebnych
K ie ro w n ic tw o projektu z w y k le ni ^ ą też znać środowisko programistyczne, bieżącej znajom ości technologii \ m ° 2e spclmć leK° zadania, ponieważ wymaga ono P ierw szy krok polega na k h " S uWladczenia programistycznego, sposoby. ‘ nkacji przypadków użycia systemu. Są na to dwa w id zen ia w artości, ja k ą d E / *
przypadkl użycia systemu w trzy kategorie z punktu
klient spisuje zaw artość k a ż d ^ przedslawia-isl ~ w szystkich p rz y p a d k ó w użyci ^ i 7 Z k o le i p ro gram iści dzielą cyjne. N a p rz y k ła d przyn ad
wysoką, średnią i mską. Następnie
kategoru
Uwaga: nie należy umieszczać
" Wysoka wartoś^” ubycia ze względu na ryzyko im plem enta-
do im p le m e n ta c ji, m oże m ie ’ ^Zy.Cia u /n a n y za „wysokiego ryzyka” może być trudny prostu n ie z b y t ja s n y lub n i ^ r r ^ */ y ,W plyw na cał^ architekturę systemu albo |est po
_ ,
i.i
" ‘«zrozumiały.
czas, jata zajm ^im m ip tm e llrr ''1iT"'i' ^ Zrobiony’ Programiści powinni oszacować Wykonując to oszacowanie ml T g°.z mch’ z dokładnością do osobotygodn.a to w a n ie , k o d o w a n ie testo w an ie i n t e T ' ^ ’ “ ° n° obejmować anal,zę' Pro-,e k ' »n m i p w • • , ‘ integrację oraz przygotowanie dokumentacji Ponad. '. 2e Jest o dyspozycji całkow icie zm otyw ow any procramista pracu jący w p e ym s u p ie n iu nad tym zadaniem (w spółczynnik „niedoskonałości” zostanie dodany p o z m e j). I
i
° ^ z f c o w a n *a s5 g o to w e , m ożna ocenić, czy to wystarcza do przygotow ania Należy p rz e jrz e ć p rzy p a d k i użycia systemu oznaczone jako dużego ryzyka. Je
r z e c z y w is t y m i. M o ż n a ju ż oszacow ać, k o ś c ią p r o je k t u
Jest to
jak szybko będzie się posuwała praca n a z y w a m to p rę d p ra c a , k tó rą m o ż n a w y k o n a ć w trakcie jednej iteracji. Prędkość
p ro je k tu o b lic z a się, m n o ż ą c lic z b ę p ro g ra m is tó w p rze z długość iteracji i d zieląc w y n ik p r z e z w s p ó łc z y n n ik o b c ią ż e n ia . N a p r z y k ła d p rzy ośm iu p ro g ra m ista c h , tr z y ty g o d n io w e j d łu g o ś c i ite r a c ji i w s p ó łc z y n n ik u o b c ią ż e n ia r ó w n y m d w a je s t d w an aście id e a l n y c h p r o g r a m is t o t y g o d n i ( 8 * 3 * 1/ 2 ) p ra c y na k a ż d ą iterację.
Potem należy z s u m o w a ć czas potrzebny dla wszystkich przypadków użycia, po dzielić przez nakład pracy na każdą iterację i dodać jeden tak dla pewności. Będzie to pierwsze oszacowanie liczby iteracji w projekcie.
Rozdział 2
planu. śli dużo czasu p ro je k to w e g o zaw arto w tych przypadkach użycia, to należy je ro z w i nąć. Następny k r o k to określenie długości iteracji. Potrzebna jest stała długość iteracji, a b y zapewnić p r o je k t o w i reg u larn y rytm w dostarczaniu rozw iązań. Iteracja pow inna być wystarczająco długa, aby w je j trakcie móc zaim p lem entow ać parę p rzy p ad kó w użycia. Na przykład d la S m a llta lk a m oże to być nawet od dwóch do trzech tygodni; dJa C++ może to być aż do sześciu-ośm iu tygodni. Teraz można rozważyć, ile pracy wymaga każda iteracja. T r z e b a pamiętać, że oszacowania były robione przy założeniu, że jest do dyspozy c ji p r o g r a m is ta pracujący wyłącznie nad jednym zadaniem. Oczywiście, tak nigdy się nie d z ie je , dlatego modyfikuje się oszacowania współczynnikiem obciążenia, który w y r a ż a r ó ż n ic ę m ię d z y czasem idealnym a czasem rzeczywistym. Należy mierzyć w s p ó łc z y n n ik obciążenia w trakcie projektu, porównując oszacowania z wartościami
w kropelce
r 7voisanie przypadków ^ y « a Następny krok to pr . r kim priorytecie przypadkami użycia dać zagrozen Wisa najwcześniej- Nre m e ^< n a „rmajsz jakiej będą i«npIen»entoWW_ uwagę kolejność, w J ^ mgdy nie „alezy P
ryzyku nalc/y ,a,;U Mę jec! N ,„w ykluczone, ze U/cl,., cować jc na nowo biorąc p1Hl , ię zdarzyć, ż c M a c « « ,« ,
ć wykonan.a więcej ^ trz y d /,L.s,„ pl(.clu p„ , , om
PraK
y wdróżenta należy przeznaczyć ° d dz anie go do eksploatacji Natęż, t y budowy na dostrajanie sysmmu , P ^ / o .wiadczenia w dostrajaniu t przy*,,. u ż y w a ć w y ż s z e g o , o ^c o w a n . j e , ^ j e o t h n ^ w k ^ ^ ^ do c
z
a
s
u
.owywamu sys^^ba ^ współczynnik b^ pl^ zykow nie wygląda projekt 1en czas Stu orocent czasu budowy, zaleznte od tego ^ > ,anować dostarczenie systemu nateCzaplanować na koniec fazy wdrozema. datę zakończenia prac. ale bez tego współczynnika - to znaczyt mtec ólczynnikiem bezpieczeństwa. umawtać się na datę późniejsza, z u w ^ ę > nQŚcj pUm Po wykonaniu wszystkich optsanycn in. „ leJmentowane w każdej iteracji, powinien pokazujący, które przypadki użycia będą programis,ów . użytków tuków być już gotowy. Plan ten o d z w te tc ^ . dziewa się, że plan może ulec zmian,e Nie jest on jednak wykuty w skale y on zobowiązania programu
< i/jorizip na nip tak dużv nacisk.
T T M Tt
2.5
^ H
Faza budowy
W fazie budowy w ciągu iteracji jest budowany system. Każda iteracja jc^i miniprojektem, w którym są wykonywane: analiza, projektowanie, kodowanie, testowanie i integracja dla każdego z przypadków użycia przypisanego do iteracji. Iteracja kończy się demonstracją dla użytkownika i wykonaniem testów systemowych, aby potwier dzić, że przypadki użycia zostały zaimplementowane poprawnie. Celem tego procesu jest ograniczenie zagrożeń. Zagrożenia p o jaw iają się często, bo trudne zagadnienia są zazwyczaj odkładane na koniec projektu. W id zia łe m projekty, w których testy i integracja odbywały się na samym końcu. Testy i integracja są po ważnymi zadaniami i zawsze zajmują więcej czasu, niż można się spodziewać. Pozo stawione na sam koniec są trudne i mogą demotywować zespół projektow y. Dlatego też zawsze zachęcam swoich klientów, aby tw o rzyli oprogram owanie samotcstuiące (zobacz ramka na następnej stronie). Iteracje w trakcie fazy budowy są zarówno przyrostowe, ja k i iteracyjne. •
Iteracje są przyrostowe funkcjonalnie. Każda iteracja buduje na bazie przypadku« użycia zaimplementowanych we wcześniejszych iteracjach. oraoisanT* produkowane8 ‘> kodu. K ażda iteracja ohepmuc przepisanie od nowa kawałka ju ż istniejącego kodu. aby go uelastycznić.
S z k ic o w y proces tw o rz e n ia o p ro g ra m o w a n ia
R efakto ryzacja (zobacz ram ka n-, „jką stosowaną podczas zm ian k l ?a ępnej strome) Jest bardzo pożyteczną techiłości kodu w y rzu ca n e g o D r, v ° U; . W ° 8 óle dobrym pom ysłem jest kontrolowanie przypadkom u ży cia systemu
^azdej lteracJ>- Trzeba bacznie przyglądać się
dziesięć procent w cześnieiszego k *1 ' * * kaŻdym razem Jest w y rzucane m niej niż Integracja p o w in n a być nm - ° . ° ostatniego k ro k u każd ej iteracii ¡Vcsem ciltóły m - O czyw iście, integracja jest częścią ściej. D o b rą zasadą jest c o d z ie ie'11nieJ «ntegracja może i powinna odbywać się częsposób nie d o p u szcza sie do s cnne..klJm P,low anie ' integrowanie całego kodu. W ten
Programista nowuoen “ f
CJ'’ k'° rą trudn0 b?dz,e
pracy. P o n ad to w tra k cie
SW01 kod po "^ k o n a n iu każdej poważniejszej
testów je d n o s tk o w y c h abv m iPó " Jl p,o w ' nien by ć w y ko n yw an y pełny zestaw y pewność w ykonania pełnych testów regresyjnych.
O p ro g ra m o w a n ie sam otestujące n n w in n i h vr n
^
karc*z,cj slai^ s*? radykalny w kwestii testowania. Testowanie iflk o n n m » * * t r° Ce.Sem c ,i* £ ty m - Nie powinno się pisać żadnego kodu, dopóki nie wie się. , S ow ac* es * kod jest już napisany, to należy opracować do niego testy. Dopóki testy nie zadziałają, nie można uznać, że k o d o w a n ie jest ju ż zakończone. apisany kod testujący należy zachować. Należy go lak zorganizować, aby można go > o uruc amiac prostym poleceniem lub naciśnięciem przycisku. Kod testujący powinien zwracac komunikat „ O K lub listę błędów. Co więcej, wszystkie testy powinny sprawdzać własne w y n ik i. N ie m a nic gorszego, niż test zwracający jedną liczbę, nad której znacze niem trzeba łamać sobie głowę. W ykonuję zarówno testy jednostkowe, jak i funkcjonalne. Testy jednostkowe powinny być napisane przez programistów, zgrupowane na poziomie pakietów i zakodowane tak.
Testy funkcjonalne lub testy systemowe powinny być tworzone przez mały, osobny ze spół, którego je d y n y m zadaniem jest testowanie. Taki zespół powinien patrzeć na system ja k na czarne pudełko i odczuwać satysfakcję oraz przyjemność ze znajdowania błędów. (U c zło n kó w takiego zespołu złowrogo wyglądające wąsy i wybuchy złośliwego rechotu nie są o b o w ią zko w e , aczkolw iek są pożądane'.)
Rozdział 2
aby sprawdzać interfejsy wszystkich klas. Odkryłem, że pisanie testów jednostkowych tak naprawdę przyspiesza moje programowanie.
Istnieje prosty i stosunkowo wszechstronny, ogólnie dostępny" pakiet do testowania jed nostkowego: x U n it. Łącze do stron W W W ze szczegółami jest dostępne na mojej stronie:
http://ourworld.compuserve.com/homepages/Martin_Fowler.
2.5.1
G d y z b a c z a m y z planu
Jest pewne, że nikomu nie udaje się do końca postępować zgodnie z planem. Zarzą dzanie planem pracy to dawanie sobie rady ze zmianami. ' Do niektórych projektów są zatrudniane specjalne zespoły „morderców programów” (ang. program killers). których członkowie otrzymują premie za każdy znaleziony błąd (przyp. tłum.). Na zasadzie „kodu otwartego’ (ang. open source).
4 1
kropelce
--------------------
• ct
h , nodeiścia iteracyjnegojest
że iest ono ograniczone « a s ..« „
•
użyci a mogą hyc pr/c, u m o w y z k ,ie n ,e m
W t ó n ą s p r:" Vi'
użycia jest odkładanych na ,W » h, v , jU łf okaże Sic, ie zbył wiele P ^ P a“ anoWania pracy Na tym Capn- P, „ , Hl ueracje..o znaczy, że nadszedł czas prz I /eboWa|i Nalczy „ ę spodziewać z,,,,,,, powinni lepiej wiedzieć, ile czasu bęc 11 w planie co dwie-trzy iteracje.
R ifa k to r y z a c ja ^
,,
n ro e ra m y są p o c z ą tk o w o d o b rz e za p ro j ”
W edług zasady entropii oprogram ow ań p t wane i zbudowane, ale z czasem, gdy jest do nich doaa
n o w a fu n k c jo n a ln o ś ć , zaczynat
•I I
gramu ^ zło ż o n o ś c i p r o g r a m u Chaos wknidzenia u s p r a w , ----i/iariv J a L * się c if śledzić o n tro lo w a ć w s z y s tk ie z m ia n y w ko n sirukc,. da się nawet wtedy, kiedy próbuje śledzić i. k kontrolow P
Jednym z pow odów w ystępow ania entropii o p ro g ra m o w a n ia je s t to, ze w ti a k c ie d o d iT l
wania nowej funkcji do programu je s t ona d o b u d o w y w a n a
na
s z c z y c ie is tn ie ją c e g o kodu,
często w sposób nieprzew idziany w pierw otnych za ło że n ia c h . W t.ik ie j s y tu a c ji m o/n«i ulho całkow icie przeprojektować istniejący program , tak aby s ta n o w ił
le p s z y
lu iu ln m e n t dla
zm ian, albo obejść różne zm ia n y w trakcie do d aw an ia n o w e j fu n k c jo n a ln o ś c i.
program, zwykle p r o w a d z i to do do datkowej pracy, gdyż każde przepisanie pro g ram u wprowadza nowe b łę d y i p r o b le m y Jest takie powiedzenie: „Jeśli działa, to nie do tykaj te g o !” . Jednak jeśli program n ie b ę d z ie pi za p rojektow any, to je g o uzupełnienie o now e fu n k c je będzie trudniejsze, niż p o w i n n o być. Przeprojektow anie w ym aga d o d atko w ej pracy, ale daje długoterminowy z y s k . N ie s te ty , term iny, w ja k ic h ludzie pracują, często nie p o z w a la ją na przeprojektowanie. R efaktoryzacja jest to term in u ż y w a n y do opisania te c h n ik i umożliwiającej o g ra n ic z e n ie nakładów pracy przy p rze p ro je k to w y w a n iu o p ro g ra m o w a n ia . W trakcie refaktoryzacji nie zm ien ia się funkcjonalności program u — z m ie n ia się raczej j e g o strukturę wewnętrzną, tak M im o że teoretycznie jest lepiej p rze p ro jek to w a ć
aby b y ł ła tw ie js zy do zro zu m ie n ia i m o d y fik o w a n ia . Z m ia n y refakto ryzacyjn e
są z w y k le
m a ły m i k r o k a m i:
sienie pola z je d n e j klasy do d rug iej, s k o n s o lid o w a n ie d w u
zmiana nazwy metody, p r z e n ie podobnych metod w klasie pod-
ki0k J“ 'program. niCW'elki' ak Parę g° dzin wl0Ż0l’ycl' w ich wykonanie może wiele zrobić, aby uzdrowić W refaktoryzacji pomagają podane zasady. •
N ie
można równocześnie refaktoryzować i wzboeacać
ży rozgraniczyć rodzaje zmian
w
trakcie
p ra c y
• •
» £ £ £ £ £ ? * ?
vi i
T
'
« r r r ; s t a ;ir r k,J '
PrZCd r0ZP° £Zęcicm ^ o t y z a c j i należy d y ^ in i^ a ć T lo S u e s f a m i'1011" ' ^ 0 ^
, Nlcklórzy informatycy nazywają ten stan k„ I 1 , 1 Czasami nazywanej r ć w n
i
e
ż
>
.
S/ knowy proces tworzenia oprogramowania R e fa k to ry z a c ję n ależ_________________
— -__________________ -____________
z jL dncj kłusy do d ru g iej, potTm sonl'C ™a,ym krokani> Najpierw należy przenieść pole az ej z m ia n ie n ależy p rzep ro w 1 1 '*• W'° podobne nicl°dy w klasie podstawowej. Po d z tę k . te m u m o żn a u n Y n ^ S S S i L ^ - M ° ŻC » na pow olne tem po, ule
Refaktoryzow anie powinno h
“ ' J '° * efekcic P o s p ie s z a pracę u s u w a n y b łąd . N ie trz e b a r e z e r w o ! ? 80* 3"* ’ gdy Jest dodaw ana nowa funkcja albo jest nywac codziennie jakąś część n r a c v LZaSU sPccJaln,c ™ rcfaktoryzację — można wykoW ię c e j in fo rm a c ji o r e f . k , ! J ° ^ ta k to r y z a c j, zaw iera [19]
S t o s o w a n ie U M L - a w fa z ie budow y
2 .5 ^2
tu odnosił do tech n ik! i wrócić do n ie g o p ó źn ie i warto użyć rozdział 4.)
O M L -a . W zw iązku z tym. że będę się C ^ •|Cs/ł‘ / e n,e om ó w iłem , można pominąć ten fragment
g o ^ o ^ z w l i ^ k m ! ! ' m p lj-mentacj ‘ l e j n e g o przypadku użycia, najpierw
m oże pom óc z m d k u u ż v r in i cr.ro i • • ,
p , ® sP e
7
^ , 1
spraw dz,c- i« k W
KoncePcy,ny d,aSram klas (zobacz określić podstawowe pojęcia stosowane w przy-
i t <•» JUŻ zbudowanego oprogramowania.
a *e ^ ° P ° ^ l ^Povvania jest to, że można je stosować podczas współpracy u aneJ z ie d z in ie . Jak m ó w i Brad K a in 1: „ Z analizą mamy do czynienia y, g y w p o k o ju siedzi rów n ież ekspert w danej dziedzinie (inaczej jest to
rad Kain byl członkiem Komitetu Technicznego OMG pracującego nad standardem RBA (przyp. tłum.).
Rozdział 2
z ty o wte pseudoanaliza)” . Aby przejść do fa z y p ro je k to w a n ia , należy sprawdzić, ja k współpracują ze sobą klasy przy im p le m e n ta c ji funkcjonaln ości każdego z przypadków' użycia. W badaniu tego rodzaju w s p ó łd z ia ła n ia bardzo po m ag ają m i karty C R C i diagramy interakcji. Dzięki temu procesowi m o ż n a o dkryć zobo w iązania klas i operacje, które można po tem zapisać na d ia g r a m ie klas. Te projekty należy tra k to w a ć ja k o występne szkice i narzędzie do dyskusji z k o le gami na temat sposobu ro z w ią z a n ia . Po zbudowaniu oprogramowania można użyć UML-a jako narzędzia pomocni czego w dokumentowaniu tego, co zostało zrobione. Traktuję diagramy UML-a jako świetną pomoc w zrozumieniu ogólnej architektury systemu. Chciałbym tu jednak podkreślić, że nie wierzę w tworzenie szczegółowych diagramów całego systemu. Aby zacytować Warda Cunninghama [16]: Dobrze dobrane i dobrze napisane notatki mogą łatwo zastąpić tradycyjną, w szechstronną dokumentację projektową. Tylko niektóre fragmenty tej ostatniej wzno szą się ponad przeciętność. Zwróć uwagę na tefragmenty i... zapomnij o reszcie. Uważam że szczegółowa dokumentacja powinna być generowana z kodu (na przy kład JavaDoc) Dodatkową dokumentację należy pisać jedynie po to, aby uwydatnić ważniejsze pojęcia. Należy ją Irak.ować jako pterwszy krok dla czytelnika, zantm zagłębi się on w szczegóły kodu. Ja sam strukturyzuję dokumentację w postaci doku-
„ ,r z v ta ć nad filiża n ką kaw y, . u / „ M . - k 'h aby nttóc j e Pr men.6w w y ^ aj^ Mt - a ilustmjace opis^
pakietów (zobacz rozdział
7,
-£ 1 2 S ? £ gramy implementacji (zo czny systemu.
i najważniejsze atry ^
^ w idzema specyfikacji Nie p okazuję ly lk o powiązania
mieć diagram klas z I
‘ “ tresci. " f . fol graficznegos spisu
dZ1 e ś łU y k i™ c ia klasy jest ło ż o n y » .
aby g0 opisać. Robię ne co nie zdarza się zbyt częsio.
*
” “ ów (zobacz rozdział 8" ),
kl asy jest wystarczająco zlożo-
sa skomplikowane interakcje m iędzy klasa, y
mk dla których rysuj? diagramy mterakgn
^
w stylu bardziej liierac
często też zamieszczam w “ ne J złożonym algorytm em , to zastanawiam kim 1 Jeśli mam do czynienia « s z c z e g ó ły g ) a)e (ylko w wypadku, gdy się nad użyciem diagramu czynn ( potrafi on dać lepsze wyjaśnienie niż sam o Jeśli napotykam ciągle te same pojęć,a to stosuję nej stronie), aby wyrazić kluczowe pomysły.
2.6
(zobacz ram ka na następ-
Faza wdrożenia
Celem iteracyjnego tworzenia oprogramowania jest regularne przechodzenie całego procesu tworzenia, tak aby zespół przyzwyczaił się do regularnego dostarczania kodu. Niemniej jednak niektóre rzeczy nie powinny być robione zbyt wcześnie. Dobrym przykładem jest optymalizacja. Optymalizacja zmniejsza przejrzystość i rozszerzalność systemu, aby poprawić efektywność jego działania. Jest to sytuacja „coś za coś” — w ostatecznym rozra chunku system musi być wystarczająco sprawny, aby spełnić w ym agania użytkow ni ka. Zbyt wczesna optymalizacja utrudnia jednak budowę oprogram ow ania — dlatego też jest tą rzeczą, którą należy zostawić na sam koniec. W trakcie fazy wdrożenia nie doprogramowuje się już nowej fu n kcjo n a ln o ści sy stemu, o ile nie jest to absolutnie konieczne i nie zostanie ograniczone do m in im u m Programowanie jest związane wyłącznie z usuwaniem błędów . D o b ry m przykładem fazy wdrożenia jest czas między dostarczeniem w ersji beta oprogram ow ania a dostar czeniem jego wersji ostatecznej.
Mowa tu o programach dobrze skomentowanych (ang. literate program m ing) knutha zobacz Donald E. Knuth, Literate Programming, 1992 (przyp. tłum ).
S z k ic o w y proces tw o rz e n ia oprogram owania
W zorce UML mówi, jak wvrayul nikach procesu - - nrzvU . i , ' 1, ,owy Projekt systemu Wzorce zaś koncentruj;« się na wyWiele osób zw | m o d e l a c h , k o w ie zespołu p r o k k t n w ^ w ^ ’/W M?poty niektórych projektów wynikają z tego, zc czlonz większym doświadczeniem wicdz* wie,c ° modelach, które są dobrze znane ludziom rzy za uważaj po wt a r!n i^Tc' sie* Spos" by roblcn,a czc8 os S* one zbierane przez ludzi, któdy z tych motywów , o n L , ,V m° tywy w ProJ<*'ach systemów Ludzie ci podejmują kazstosować. k0, ł,hy ,nni mogli przeczytać wzorzec i zrozumieć, jak go za* w obrębie la k ie e o T ^ n /'V ' ’1 przykłai\,i Proxy.
P o d m io t
Podmiot rzeczywisty
żądanie()
Rozdział 2
żądań ie()
r ^ T Ć Ź e s t o używ aną nie tylko w si^u.ei, ----------------- -----' w .o n czy ch j « 1 tc c h n h .r k t ó w z a s tę p c z y c h j a k m o g ą hvV Stosowanie ob.eMow " stosowaniu o plcrnentować K s ią /k . o m ,i„ / g ł a d z o n o dużo u iv tt, jak.«
i i ak akie ja k la. n i .
j
*7acZęła * * * grom " * adzić . ™ doświadczenie *
to nie jest to tak pomocne j. d' ^
^
“ h
&
e
£ ' tyP tematem. M ó w ią o tym, j ilk c a l to przydatne > - u .......
w
i ^
z
, ^
X
“ w anych o pisyw aniem w zorców Lu.
praca - L ... dóbrc źródło wiedzy. • * zawiera dziesięć stron pośw ięconych
^
^
„ , 0
H
p o e d s u w ia ją c szczegóły icg o . , * rego w zorca, pospoh.e je g o w a m « ,
obiekty współpracują ze sobą. or7>. ^ , y jne dla Sm alltalka i C ++ i zastosowania oraz wskazówki « ^ ‘cmentecyjn technikę p ro je k to w ą W z o rc e mogą Proxy jest wzorcem projektowym, bo opisuj p ktow aniu sys, em u do zarządzania istnieć też w innych dziedzinach na przyk . ryzykiem na rynkach finansowych. I rzeba
P .
z m ic n ia się w artość portfela py akcji ich cenę i datę te, wyce-
akcji w czasie. Można to zrobić, i i t r z y m i ch hipo,etycznych (na p rz y k ła d co się nv. W arto jednak móc rozpatrywać ryzy .y j ć m o żn a u tw o rz y ć .u r n a n m z stanie, jeśli załamie się cena ropy naftowej).. to W g sccnariuszc d|a ccn ?o. zawierający cały zbiór ccn akcji.. Nas ępn
_
prognoz na następny ty d z ie ń uw zględm a-
szłotygodmowych. prognoz na n n P ) f w j jtd w z o r z e c scenariusza (zo b a c z rysujących hipotetyczne załamanie się cen r o p mo d c | 0 w a n ,a dzicdzm x nek 2 .3 ) jest wzorcem analitycznym, poniew aż opisuje kawaieK m o u
Rysunek 2.3. Struktura wzorca analitycznego S cenariusz
w c d ^ r T ^ S" ccKnnt\ ponicWaż “ '¡"wiają start, gdy zaczyna się pracować u no wej dziedzinie. Zacząłem zbierać wzorce analityczne, bo bytem wielokrotnie blokowany
!nakTza k S razem ™ musiałem f7 W icdzia,em 'żcn,ckanką by,empapieru. każdym zaczynać z czystą Angielskie Gang ot Four «trA™.,., o wzorach. Nazwa ta jest również często
ZeSp° lu' którV napisał podstawową pozycję racana jeszcze bardziej do GoF (przyp. tłum.)
S zkico w y pioccs tworzenia
R z e c z ą in teresu jącą we ~ ------nieoczekiwanych a n r,., ,C Wvorcach a'ta liiyCznvch i»et « p n y ty™ niezwvkivM iycn Jcst ¿c pojawiają się one w zupełnie finansowej firm y, w i e l i - » 7 Mych miejscach fiik# r«-» i r , „ u- ,111 sl„->K. , ką P°moc nrzvnióvi u y rozPoc2y" atem projekt z analizy • n THn/izdrOwia. przyn,ósl m. zb.or wzorców, które kiedyś odkryłem, praDodatkowe m fo m a c je „ „ ,cma, , r nf»«7r7iM^ l'-,ndi sce zamieszczone » w», |ru I Hn) . " ,c™ ' »«nar,uszy , ¡„„ych wzorców a„ahtycznych zos,aly
D ™wzorzec , T to cos rCeznacznie S* ' 3 k iewiece. n,-> jest taki, jaki jest. Często się mów, VVzorzcc musi zawierać powód, dla którego także wyjaśnić problem. wytlumacyvr , f >r/CCJCM r°związantcm problemu Wzorzec musi k.ch okolicznościach sprawdza s io « , a i * c z c S ° J « t rozwiązaniem problemu, a także w jaWzorce są istotne, ponieważ ! ’t J podstaw języka czy tcchn.k, m odeloT.w ? "a/S,ęf1ny.krok wykraczający ponad zrozumienie jest dobrym modelem i jak k o n s m .^ Wzorce dają wiele rozwiązań, a także mówią, co Kiedy rozpoczynałem nrace modcl- Uc2;t przykładami czego nie było podręczników kr aMavv si?' dlaczego muszę zaczynać od zera. Dlamujących *
wzorcam,
^
'« * ■
K ie d y u ż y w a ć w z o rc ó w zarządzania p ro ic k lm T n ? Zr° b'C C°u P°dcZas anaIizy* projektowania, kodowania czy też móc projektem, należy poszukać istniejących wzorców, które mogłyby w tym po-
D o d a tk o w e ź ró d ła Lektura książek, o których wspomniałem wcześniej, to dobry początek. Można też zaj rzeć na głów ną stronę wzorców: http://www.lullside.net/patterns. Strona ta zawiera najnow sze informacje o w zorcach.
2.7
Kiedy używać iteracyjnego procesu tworzenia oprogramowania pewność powodzenia projektu, to należy stosować iteracyjny oprogramowania.
Jeśli ch ce się m ie ć proces t w o r z e n ia
B y ć m o ż e to p rz e s a d a , ale im je s te m starszy, tym bardziej staję się ra d ykaln y, je ś li chodzi o it e r a c y jn y p ro c e s tw o rz e n ia o p ro g ra m o w an ia . D obrze przep ro w ad zo n y staje się n a jis to tn ie js z ą te c h n ik ą , k tó r ą m o ż n a stosować, aby o dkryć zagrożenia w ystarcza ją c o w c z e ś n ie i z a p e w n ić s o b ie lep szą k o n tro lę nad b u d o w ą op ro g ram o w an ia. N ie oznacza to, ż e n ik t n ie b ę d z ie z a rz ą d z a ł p ro je k te m (a c z k o lw ie k p rzy zn aję , że n ie k tó rz y stosow ali ten p ro c e s w ła ś n ie w ty m c e lu ), ale m usi być on dobrze za p lan o w a n y . Jest s p ra w d z o n y i k a ż d a k s ią ż k a o tw o rz e n iu o p ro g ra m o w a n ia o b ie k to w e g o zachęca do
jego
s to s o w a n ia .
l łMI
kropelce*
2.8
Dodatkowe źró d ła
, . . ii«ncvinyn> procesie tworzenia oprogramowania M Jest mnostwo książek o iteracyj ) p io Jc d w ie u lu b io n e to: awic UIUUIUI1C IV. . Cockbum [12], ponieważ d obrze opisuje podstawowe zagadnienia w krótk książce. Polecam tę pozycję jako pierwszą do pizecz, ania o zaizą zaniu projek tanii obiektowymi. • McConnell [31J, ponieważ daje pogłębiony przegląd najlepszych technik. Aby poznać lepiej RUP, należy przeczytać: • Kruchten [27] — jest zwięzłym przeglądem procesu. • Jacobson, Booch, Rumbaugh [23] — zawiera więcej szczegółów. Te same zagadnienia, ale w sposób przystępniejszy i systematyczniejszy, prezcn tuje książka o programowaniu ekstremalnym Kenta Becka [2]. Jest w niej przedstawić, na inna technika, kładąca nacisk na testowanie i ewolucyjną budowę oprogramowani, W arto także zajrzeć na stronę W W W http://www.armcities.com/extrenie htm i H,, , książki. ' teJ
Rozdział
cko Prze2 dłuższy czas, zaró\vn0 « zŻa^. llflowy H 0 W y oprogi“" o p r o g r a m^o................. w a n i a , lu — d z ie P,> Po.. , to in te re sjua je Przypadł' użycia systemum technikr.ch, b u j ki em a systemem, aby |e.
....
chwały Wara Jacobsona to zi
systemu, że stały się 0ne
* ^ tu g iw a ć ^ p M ilM m i użycia systemu. Co to jest przypadek użycia system" Nie odpowiem na to pytanie wprost, i j .
," » C
*“
J '“
« Ł S K
° d ChWili’ ^
ZaCZąlem *
opiszą scenariusz interakcję między użytkownikiem
'— “
—
•-
->■
p ™
Z a k a t a l o g i wkładatowarydo koszyka. Gdy e oadresudostawy,,karcie kredytowej i potwierdza zakup,, sprawdza autoryzację karty kredytowej ¡potwierdza sprzedaz natychmiastowo wysyłając pocztę elektroniczną.
. . . . . , A Ten scenariusz przedstaw ia jedną z sytuacji, jakie mogą się przsdaizęc i i\zacja karty kredytowej mogłaby się jednak zakończyć niepowodzeniem i byłby to wów czas oddzielny scenariusz. Zatem przypadek użycia systemu jest to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika. W podanej sytuacji został przedstaw ion\ przypadek użycia „Zakup towaru” z dwoma scenariuszami: pomyślnego zakupu i niepowodzenia autoryzacji. Inne, alternatywne ścieżki byłyby dalszymi scenariuszami. Często zdarza się, że przypadek użycia ma wspólną ścieżkę w sytuacji, gdy wszystko dzieje się pomyślnie, i wiele alternatyw, gdy coś się nie wiedzie, oraz alternatyw y. c dv wszystko dzieje się pomyślnie, ale w inny sposób. J Prosty format prezentacji przypadków użycia to opis scenariusza u ló w n e -o nko
- ^ s s a a s s s s Ł if ~uml“
* «•
przykład inożna dodać informacię o warunki i ’ mo2na dodać do opisu. Na zanim rozpocznie się paypadek „ ż y c C w l WStęPnych* t2» co ma być spełniono, przypadki użycia, i dodać te elementy któ rym do « * * . które omawiani raczy, które naprawdę będą pomocne.
* * Pr2ydać' N a l“ y uw zględnić lyl-
Przypadki użycia systemu
Zakup to w a ru
3 Klient prze^h° ^ |kdoa!
warunki d°s,a^ '
°
n,e CyffY numeru karty kredytowej potw,erdz'ć lub zmienić dane domyślne do scenariusza głównego w punkcie 6 Rysunek 3.1 Przykład przypadku użycia systemu
Należy z w ro c ie uw agę na to, ja k są dzielone przypadki użycia. Przykładem będzie taki scenariusz robien ia zaku p ó w w sklepie internetowym, w którym kupujący jest znany systemowi ja k o stały klient. N ie któ rzy potraktowaliby to jako trzeci scenariusz, podczas gdy in n i z r o b ilib y z tego osobny przypadek użycia. M ożna by jeszcze użyć jednej z relacji m ię d z y p rzy p ad ka m i użycia, o której powiem później. Szczegółowość opisu za le ży od ryzyka niesionego przez przypadek użycia: im bar dziej ryzykowny p rzy p a d e k , tym bardziej szczegółowy musi być opis. Często w fazie rozwinięcia s z c z e g ó ło w o opisuję tylko k ilk a przypadków użycia, a reszta pozostaje na poziomie szczegółowości n ie w ie le odbiegającym od przykładu na rysunku 3.1. W cza sie iteracji uszczegóławia się przypadki użycia w miarę potrzeb implementacyjnych. Nie trzeba zapisywać wszystkich szczegółów.
3.1
Diagramy przypadków użycia systemu
Rozdział 3
Oprócz wprowadzenia przypadków użycia systemu jako podstawowych elementów przy tworzeniu oprogramowania Jacobson [25] również wprowadził diagramy do ich wizualizacji. Diagram przypadku użycia jest obecnie częścią UML-a. Dla wielu osób diagram p rzy p a d k u użycia jest pomocnym narzędziem. Chciałbym tu jednak podkreślić, że nie trzeba rysować diagramów, aby móc posługiwać się przy padkami użycia Jeden z najlepszych projektów posługujących się przypadkami użycia systemu jakie znam przechowywał je na osobnych kartach katalogowych i sortował te karły, aby określić’, co ma być zbudowane w każdej z iteracji. Rysunek 3 2 przedstawia nieklńrc przypadki użycia dia systemu maklerskiego.
51
System k s ię g o w y K ie r o w n ik s a li
O k re ś l
\
w a rto ś ć
J
Z a w ie r a
Aktor
Uogólnienie
S p rze d a w c a /'''L im it
P rzy p a d e k użycia
(p rz e k ro c z o n y
Rysunek 3.2. Diagram przypadku użycia dla
3.1.1
systemu m aklerskiego
A k to rzy
Aktor jest to funkcja, którą użytkownik pełni w stosunku do systemu. Na rysun ku 3.2 jest czterech aktorów: kierownik sali, makler, sprzedawca i system księgowy. (Wiem, że lepiej byłoby używać po prostu słowa „rola” , ale ponoć były jakieś kłopoty w tłumaczeniu ze szwedzkiego, ojczystego języka Jacobsona.) W przedsiębiorstwie zapewne będzie wielu maklerów, ale z punktu widzenia sy stemu oni wszyscy grają tę samą rolę. Użytkownik może również grać kilka ról. Na przykład starszy makler może grać rolę kierownika sali i być także zw yk łym makle rem, makler może być także sprzedawcą. Zajmując się aktorami, jest ważne, aby my śleć w terminach ról, a nie ludzi lub stanowisk. Aktorzy wykonują przypadki użycia. Jeden aktor może występować w w ielu przy padkach użycia i na odwrót — przypadek użycia może być w ykonyw any przez wielu aktorów. W praktyce zauważyłem, że aktorzy są najbardziej przydatni, gdy trzeba wykryć przypadek użycia systemu. W wypadku dużego systemu często jest bardzo trudno w y myślić listę przydatnych przypadków użycia. W takiej sytuacji jest łatw iej określić najpierw listę aktorów, a potem opracować przypadek użycia dla każdego z nich Aktorzy me muszą byc ludźmi, mimo że są prezentowani na diagram ie przypadku użycia jako ludzkie figurki. Aktor może być również systemem zewnętrznym notrzeującym informacji od modelowanego systemu. Na rysunku 3 2 widać że system księ gowy musi zaktualizować rachunki y przypadku użycia. N ie M ó r/T n iy f d t przedstawiane Jako Llktor na diagramie y P odstawiają na nich wszystkie systemy zewnętrzne
P rzypadki użycia systemu
i u ż y tk o w n ik ó w , inni ograni przedstaw iam aktora, który z y w a ją go aktorem g łó w n y m .
d° przedstawi™ ia aktora inicjującego. Ja sam W Wyn' ku użycia - niektórzy na-
coś z przypadku u ż y c ia J nie z a ^ ' W ystarczy że widzę, iż system księgowy ma nia się system em k s ię g o w y m nawiam si? nad zyskiem w ynikającym z posługiwagowego. C h c ia łb y m zwrócić u w i °
? 02naczało modelowanie samego systemu księ-
z akto ram i s ys te m o w ym i snmh 8?’ ™ ^awsze na,eży kwestionować przypadk. użycia i w ziąć pod u w ag ę a lte m a tv u m » WaC ^ dkryc’ iakie Sił rzeczywiste cele użytkownika, Pracując nad a k to r a m M sP0soby osiągnięcia tych celów.
kładnie re la c je
za c h o d zą r n i e d ^ m m ^ r ' UŻyC'a sys,emu- nie niartwię się, jakie do-
cia. Praca nad akto ram i to tv lk n -k ?’ ° Zym S‘ę koncen,ru.Ń > 10 przypadki używ szystkie przypadki u ż v ri', dotarcia do nich. Jeśli jestem w stanie wykryć aktorów . ' ° nie m artw ,ę s‘? zbym io o szczegóły dotyczące samych Jest parę s ytu ac ji, w których warto się dalej zająć aktorami. k a ż d T ^ d z a i ny^ jego za d a n ia
! k 0 nfif r° Wany dla różnych użytkowników. W takim wypadku ' 0Nvnika jest aktorem i przypadki użycia systemu wyznaczają
9
S ie d z e n ie ^ g o , kto potrzebuje przypadków użycia, pomaga wynegocjować priory te ty ro ż n y c h a kto ró w . N ie k tó re z p rz y p a d k ó w użycia nie m ają zw iązku z konkretnymi aktorami Przykła dem b ę d zie p rzed sięb io rstw o użyteczności publicznej. Jest oczywiste, że jednym z p r z y p a d k ó w u ży c ia je s t „W y s ła n ie rachunku” . N ie jest jednak łatwo znaleźć aktora b ezp o śred n io z ty m p rzy p ad kie m stowarzyszonego. Żadna z konkretnych ról użyt k o w n ik a nie żą d a rachunku. Rachunek jest wysyłany do klienta a klient nie m iałby nic p rz e c iw k o te m u , g d y b y go nie dostał. Najlepszym kandydatem na aktora jest dział fi n an só w , p o n ie w a ż na ty m przypadku użycia coś zyskuje. A le z drugiej strony dział fin a n s ó w n ie je s t z w y k le zaangażow any w w ykonyw anie tego przypadku użycia. N ie k tó r e p rz y p a d k i u życia nie będą w ynikiem procesu rozpatiywania poszczegól nych a k to ró w . Jeśli do tego dojdzie, to nie należy się martwić. Najważniejsze jest zro z u m ie n ie p r z y p a d k ó w użycia systemu i celów użytkownika, które spełniają. D o b r y m ź ró d łe m id e n ty fik a c ji przyp ad kó w użycia są zdarzenia zewnętrzne. Pewne z d a rze n ia m o g ą p o w o d o w a ć reakcje systemu, które nie angażują żadnych u ży tk o w n i k ó w , lu b p r z e c iw n ie , m o g ą pow odow ać głów nie reakcje użytkow ników . Określenie tych z d a rz e ń , na k tó re n a le ż y reagować, pom oże określić przypadki użycia.
3.1.2
Relacje między przypadkami użycia systemu
O p ró c z z w ią z k ó w m ię d z y a k to ra m i i p rz y p a d k a m i u ż y c ia m o żn a ró w n ie ż pokazać
sekw en cie p o d o b n y c h k ro k ó w , której nie warto ciągle kopiow ać z jednego przypadku do d ru g ie g o
N a p rz y k ła d „P rz e a n a lizu j ry z y k o ” i „W y c eń kontrakt” w ym agają, aby
określić w arto ść k o n tra k tu . O p isa n ie określania wartości kontraktu w ym aga sporo pracy
a ja n ie zn o s zę k o p io w a n ia i w k le ja n ia tekstu. Dlatego utw orzyłem oddzielny
Rozdział 3
k ilk a r o d z a jó w z w ią z k ó w m ię d z y przyp ad kam i użycia. D o re la c ji z a w i e r a n i a docho dzi w tedy, gdy kilka przypadków użycia ma wspólną
, traktu” i odwołuję się do niego z mnych p1/y. ji Określ wartość- kontrakti przypadek uzyc < ♦. użycia icst podobny do in. Pat / ^ ™ , , SS yw a sie wówczas.* * * * * * ^eszcze jeden ze sp o s o b ó w uchwy. „ego, ale jesi nieco obszerniejszy. W tstoc cenią scenariuszy alternatywnych. użycia jest „Zarejestiuj tiansakcję W przykładzie podstawowym luacji gdy wszystko się powiodło Jest to pomyślny przypadek użycia sys;emu. ’ transakcji, „ a przykład przekrnCoś może jednak przeszkodzie w pomysl“ ■' ■' konkretnego kontrahenta. W takie, czenie limitu, który biuro maklerskie m u . ych z ,ym przypadkiem uzyc,;, sytuacji nie wykonuje się krokow zw . t y
p
o
w
y
c
h
systemu, lecz alternatywny przypadek uzyc przypadku użycia „Zarejestruj Można było umieścić ten w a r i a n t • nl wcześniej przypadku użycia transakcję” jako alternatywę, podobnie ja 1 ‘ Uernatywa jest na tyle różna, że „Zakup towaru” . Można jednak zdecydow , alternatywne umieszcza się zasługuje na osobny przypadek użycia, < . sję do podstawowego przyw specjalistycznych przypadkach użycia, może przesłonić dowolną częse padku użycia. Specjalistyczny przypa e ^ dotyczyć osiągnięcia tego >apodstawowego przypadku użycia, ale zawsze powimer aoiy )
mX
t ą^
“ n C o r a S r^ s u n k u 3.2, je st rozszerzenie. Jest ona
"
w istocie bardzo podobna do uogólnienia
™ o^odatkow e zachowania, ale
w r t u S ? H » o ^ S * k użycia musi określić pew ne p w k ly ro z s z e r-J l a; S e S % y p 7 d e k u ^ c ia może dodać nowe zachowama ty lk o w tych punktach (zobacz rysunek 3.3).
Stały klient
K u p to w a r p u n k ty rozszerzeń inform acja o płatności
\ ^ /« ro z s z e rz a » (informacja o płatności, informacja o dostawie)
in fo rm a c ja o d o s ta w ic
Rysunek 3.3. Relacja rozszerzenia
«as? ™ Zarowno uogólnienie lak i
- j i r r ż *s r n ..
i
•ypuuKamt użycia.
.
w fazie rozwinięcia często rozbijam przypadki u ż y c h ^ ' wane. W fazie budowy rozbijam przynadok „ż,,
.
T
.p reyPadku użycia Ją Sl? zbyt skt,mPllkl’-
zaimplementować całego w jednej iteracji W fr k ''’ 8 y . okazu->e si«- że nie mogV S" r/ę przypadek użycia, a potem jego wariantv " « b ija n ia najpierw zw ykły iwoNależy stosować podane reguły •
Gdy trzeba powtórzyć co»ś w k lk c. chce się uniknąć powtórzeń, należy1' Przypadkach użycia, a jednocześnie y zywac relacji zawierania.
________________________ r r
.
Gdy trzeba opisać w ariantv
.
“
K
p
tr
-> • —
Ji ^ s z e r z e n ia .
3.2
Biznesowe system u
°p *su ni=-
r eb" y rozszerzeń w przypadku podstawowym.
i c i,c +
em owe przypadki użycia
Nagminnym problemem, który cia, jest to. że koncentrując sie n /m t'^ L^ P'uy posłuS'waniu się przypadkami użylatwo można zaniedbać sytuacje w k. • u m'ędzy użytkownik.em a systemem, najlepszym sposobem poradzenia , ? Zm'ana Procesów biznesowych może bvć Można często usłyszeć Z Z 1 t \ kł°P°tami przypadkach użycia. Te terminv n ^ . u,ujących 0 systemowych bądź biznesowych interakcja z oprogramowaniem , i"” ^ precyzyJne> Systemowy przypadek użycia to siębiorsrwo reaguje ■ * » * « — "> cia toncentmlę się zagadn,eniami Wc wczesnych stadiach fazy rozwiniębardziei Drzvdatne s v l b'“ «»wych przypadkach użycia, ale do planowania są bardziej przydatne systemowe przypadki użycia. Biznesowe przypadki użycia pomagają m, w ro z p a tr y w a n iu alternatyw nych sposobów „ s ią g m ę c ia ^ u przez aktora swojej pracy ko ncentru ję się n ajpierw na biznesowych przypadkach użycia, a potem wymyślam spełniające je systemowe przypadki użycia. Na koniec fazy roz winięcia spodziewam się, że będę m ia ł co najmniej jeden zestaw systemowych p rzy padków użycia dla k a żd e g o w ychw yco nego biznesowego przypadku użycia — a w najgorszej sytuacji dla tych biznesow ych przypadków użycia, które zam ierzam za implementować w pierwszej wersji systemu.
3.3
Kiedy posługiwać się przypadkami użycia systemu
Nie mogę sobie wyobrazić sytuacji, w której nie stosowałbym przypadków użycia. Są one podstawowym narzędziem w uchwyceniu wymagań systemu oraz w planowa niu i zarządzaniu iteracyjnym projektem tworzenia oprogramowania. Zgromadzenie przypadków użycia jest jednym z zasadniczych zadań lazy tozwinięcia. Większość przypadków użycia powstanie w tej fazie projektu, ale w miarę postępu prac pojawią się nowe. Warto zwrócić na to uwagę. Każdy przypadek użycia jes, po tencjalnym wymaganiem, a dopóki nic określ, się wymagań,a, me można zaplanować. jak z nim postąpić. „. . . . . , Niektórzy najpierw spisują i omawiają p r z y p a d k i użycia, zanim przystąpią do mo delowania Odkryłem że wspólne z użytkownikiem modelowanie pojęciowe pomaga w wykryciu p r z y p a d k ó w u ż y c ia . Zatem z w y k le stosuję przypadki użycia razem z ntodelowaniem pojęciowym.
iii
I I I «
•
„ . „ r e z e n t u j ą s p o j r z e n i e / z e w ,,.,u ,
• * . „rzypadki uiyCia i , klasami wewnątrz systemu . «bv pamiętać. ze I między 111 i„,H w nci dyskusp panelów,.. " ,|e pizypadków ekspertów od P ^ watoby się kilkunastu na konferencji OG,’S . Jziesięciu osobolat 'I" „ ż y c i a — każdy ' » nroiektu wielkości rzędu p r z y p a d k u « ^ w i< b ia |c,n tak/e ków użycia - .o przypadków
Z Z S S & Z Z ¿ s S S f f lS - ,—
wszystkie wariantowe przypadki podobną liczbę.)
3.4
,uvvp»,|. ‘ ky projekiy Uczy %
« *•
.
Dodatkowe źródła
. • ¡.»ct n r i c a Schneider Dobrą książką o przypadkach użycia systemu jest pr
i
Wintersa
[391
Obecne wydanie posługuje sic relacjami UM L-a wersji I I — «« ' ais w dals ym c jes, io najlepsza książka, jaką znam, o tym ja k posługiwać sic przy. padkanu u ż y c i Moim drugim ulubionym źródłem jesi zb.or artykułów na stronach WWW Alistaira Cockburna: http://members.aol.com/acockhuni. Pierwsza książka lvara Jacobsona [24] rozpoczęła to wszystko, ale jesi juz nieco przestarzała. Druga książka Jacobsona [25] ciągle jest przydatna, dzięki temu, ze kładzie nacisk na biznesowe przypadki użycia systemu.
^•sęjfarny klas podstawy
Rozdział
.
iiea
metod obiektowych.
P r a k t y c z n i e k a A |,,
klas stały DiagramyV klas suiiy Się v centralną techniką , Ł i metoda siosiije jakiś wariant tej techn* a|e jest też elementem cale, g „my Diagram klas jest nie tylko szeroko tos woWych elem entów, ale bardzlej poleć modelowania. Każdy korzysta z eg i dziem em zagadnienia dotyczące złożone pojęcia są rzadziej używane, Dla teg , pojęcia złożone (rozdział 6.,. diagramów klas na dwie części: podstawy (te . rodzaje statycznych relacji Diagram klas opisuje typy obiektow >' t znych: między nimi. Są dwa główne rodzaje re acj w jdeo) • asocjacje (na przykład klient może wypożyczy . podtypy(na przykład pielęgniarka jest oso ^ ^ ^ iczenia , Diagram klas pokazuje również atrybuty i ope c aki sposób obiekty mogą być oyc powiązane. p u w i^ t.e . w jaki i n o r n na H a < ( _ . . . . . ._____ Rysunek 4 .1 przedstawia typowy Adiagram klas.
4.1
Perspektywy
Zanim rozpocznę opis diagramu klas, chciałbym zw rócić uwagę na pew ien ważny aspekt jego użycia, który jest zwykle nie dokumentowany, ale ma duży w p l\ w na in terpretację diagramu, ponieważ dotyczy tego, co opisuje się za pom ocą m odelu. Za Steve’em Cookiem i Johnem Danielsem [13] uważam, że są trzy perspekty wy, których można użyć przy rysowaniu diagramów klas — a nawet d o w o ln e g o innego modelu, chociaż jest to najbardziej widoczne w zw iązku z diagram am i klas. •
Pojęciowa. Jeśli przyjmuje się perspektywę pojęciową, to będą rysow ane diagramy reprezentujące pojęcia analizowanej dziedziny. Pojęcia te będą o c z y w iś c ie zwią zane z klasami je implementującymi, ale często nie będzie m ię d zy n im i pełne) odpowiedniości. Tak naprawdę model pojęciow y po w in ien być tw o rz o n y niezależnie od oprogramowania, które może implementować ten m odel, tak aby m ożna ao było traktować jako niezależny językowo. Cook i Daniels n a z y w a ją to perspektywą podstawową.
’
Ä Do* « y już oprogramowania, ale raczej in te rfe js ó w n iż implementa JI. Mtm o ze programowan.e obiektowe kładzie duży nacisk na ró żn ice nnedz^
interfejsem a implementacją, (o w praktvee często cie P V klasv w ie 7 vknrh nm iiram oi u- . cz^ sl° S,S 0 ty m za p o m in a , bo poięcie Kiasy w językach programowania obieklow eoo łn r7 v ; * rtacji. Nie powinno tak być ponieważ H ,„ ,
u
?
m t e r f e J s u 1 "nplemen-
obiektowego jest programowanie sterowane im T t ° e fe ^ w n e 8 ° program owania plemenlacji. Ten temat jest dobrze n m i JSem klasV- a m e sposobem nnGammy, Heima, Johnsona i Vüssidcsi I " n i" r * W P‘erW SZym ro zd zia le książki używane w omawianiu interfejsu k h ™ t Zęst0. m ° ż n a usłyszeć słow o „typ mentują, a klasa może implementnu/a c ’ n i° ŻC m *e(^ w ‘e ^‘ klas, któ re go imph’muwac w iele typów
Im plem entacyjna. T a Der<5n . praw dopodobnie m i , - i - p<' k,>'w a dokładni? .,u
ä s s t
pnyw * Z a m ó w ie n ie d ataO trzy m a m a
Krotność; obowiązkowe
przedpłata numer. S trin g cena: w a lu ta w yślij!) zam kntjO w iarygodność K redytow a)). Stnng 1
Uogólnienie
i « ' n i k a - ’i ä
Ä
Klasa
, ki iCnl ’" “ ^ " „ ¡ ¿ K r e d y t o w a r-c d p ,u ,0 „,„slhyc
Ograniczenie
K lie n t firm o w y osobaDoKontaktów
Atrybuty
K lient in d y w id u aln y nu me rKarty Kredy to wej
wiarygodnośćKredytowa limitKredytowy przypomnijO
O peracje
obciążZaMiesiąc( Integer)
{ wiarygodnośćKredytow a() == „niska"}
Nazwa roli
\
pozycje
*
<■
Krotność: wiele
przedstawiciel handlowy
0 ..I <
Krotność: opcjonalny
P o z y c ja z a m ó w i e n i a Integer waluta Boolean
R ysun ek 4.1. Diagram klas
u , • ct k o n ie c z n e z a ró w n o p rzy rysow aniu, ja k i czytaniu Zrozumienie p e r s p e k ty w je s t p e rs p e k ty w a m i nie są w yraźne i większość diagramów k la s . N ie s t e t y , g ra n ic e v .
UML w kropelce
' ,
, , —
. tvWV w tra k c ie rysow ania M inil, -
.....
* - u lc p r o ' i - - 1' techniki zalezy ou p i jM L-a. a' e a T . .i o .... w s z y s t k i c h trzech pu . Z e D^nekwww nie sa formalna.C| f U M L nioże być »żyiy można określić, o
a aby pokazać, że chodź, o persp J Z J L « .™ » (z anc. typ).
4.2
Asocjacje
Rysunek 4 1 p rz e d s ta w ia prosty
m o d e l k la s ,
który
zaskoczyłby nikogo, kio zaj. z . jego e l e m e n t ó w , powiem, jak
n ie
w a ^ s ię p iz e tw a r z a n ie m z a m ó w ie ń . Omówię k a ż d y m ow żn a co in te rp re to w a ć z ró ż n y c h p e r s p e k ty w . . . . można R o z p o c z n ę od asocjacji. A s o c ja c je r e p r e z e n t u ją zw iązki
•
.
f m s ta n c ja m .
,
m iędzy klas (o s o b a p ra c u je w p rz e d s ię b io rs tw ie ; p r z e d s ię b io r s tw o ma kilka biur). Z punktu widzenia perspektywy pojęciowej asocjacje reprezentują z w ią /k i poję ciowe między klasami. Diagram mówi, że Z a m ó w i e n i e musi przyjść od pojedynczego K l i e n t a i że k l i e n t może złożyć kilka Z a m ó w i e ń . Każde z Z am ów ień zawiera kilka P o z y c j i z a m ó w i e n i a , z których każda odnosi się do jednego X o w a ru . Każda asocjacja ma dwa punkty końcowe; każdy nich jest przytw ierdzony do jednej z klas w asocjacji. Punkt końcowy może być jawnie opisany za pom ocą etykiety, którą określa się nazwą roli. Punkty końcowe asocjacji są często nazywane rolam i. Na rysunku 4.1 punkt końcowy asocjacji Zam ów ienie-P ozycja zam ów ienia po stronie Pozycji zamówienia jest nazwany Pozycje. Jeśli nie ma etykiety, to punkt końcowy jest nazywany nazwą klasy docelowej — na przykład punkt końcowy aso cjacji Zamówienie-Klientpo stronie Klienta byłby nazywany K lie n te m . Punkt końcowy asocjacji ma również krotność, która wskazuje, ile obiektów może brać udział w danym związku. Na rysunku 4.1, gwiazdka (* ) po stronie Zamówienia w asocjacji Zamówienie-Klient mówi, że K lie n t może mieć zw iązanych z sobą wiele Zamówień, podczas gdy jedynka (1) po drugiej stronie m ów i, że dane Zamówienie może pochodzić tylko od jednego Klienta. Ogólnie rzecz biorąc, krotność wskazuje dolne i górne granice dla liczby obiektów K M ^ n f e mnśi
7 łW - aS° 7
w y / n a c z a m e e T ic ź b ^ 7
( *> repr<*entuje zakres ( L n U M c z o m *
aCJ,m m ,C ,r
' n 'e ™
,p rZ y n a " " " lc l w
* * * W praktyce naiczetóei n
,
k'adn'e
te o r ii!)
g ó r n e j g ra n io
Jedynka ( . , oznacza z ,
jednego K lie n ta
wystąpienie). Dla bardziej ogólnyThTrltnoścr0'3" 1' S,. , \ * oraz ° " 1 (najwyżej jol'»' •I dla liczby graczy w zesnnlp v \, 01 mozna U^YC jednej liczby (na przykł> V w zespole krykietowym), zakres (na przykład 2. 4 dla l i c *
graczy w
kanastę) lub k o m b in acji
lir
k
•
w suH^chodach p r ,e d p o ja w ie n ie m sie k o m 'h i T ™ ^ z punktu w id z e n ia perspektyw y snecvEL
ni» klas
y
przykład 2 - 4 dla liczby drzwi
acyJneJ asocjacje
reprezentują zobowiąza-
Z rysunku 4 .1 m o żn a w v z Klientem, które m o g ą określać la k ir Z a m ó w ie n ie z a w ie ra m eto dy które m
2e ,‘stn'ej e
kilka metod stowarzyszonych m ° Wlen,a zloży ‘ da"y K lien t. Analogicznie,
Zamówienie
i j a k i e Pożycie san-, ivn v odpow iedz¡ec, który K lie n t złożył dane G d y b y is tn ia ły p e w n e standardów Z a m o w ie n iu dobnie m ó g łb y m w y w n io s k o w a ć / ° T ° ¡COnvvenc-!e w nazywaniu metod, to prawdopokład może istnieć k o n w e n c ja , która ^ ram 0W ’ j ak nazy w a ją się te metody. Na przy-
wane za pomocą m e to d z w r a c a h c v r h krotnościach są implementowane
° W' Z° asoc-iac'e ° krotności 1 są implemento-
następujący ¡M ^ e ^ d ta
k° nwcnc'ą w Ja™ . mógłbym wywnioskować
class Zamówienie { public Klient pobierzKlienta(); public Zbiór pobierzPozycjeZamówienia();
O c z y w iś c ie , są ró ż n e k o n w e n c je program ow ania i nie wskażą one każdej metody, ale m o g ą być przydatne w z o rie n to w a n iu się w modelu. A s o c ja c ja im p lik u je ró w n ie ż p e w n ą odpowiedzialność za aktualizację relacji. Z a w sze p o w in ie n is tn ie ć sposób p o w ią z a n ia Z a m ó w ie n ia z K lie n te m . Szczegółów nie ma na ry s u n k u , m o ż n a je d n a k podać K lie n t a w konstruktorze Z a m ó w ie n ia . M o żn a też to uczynić w p e łn i j a w n i e , d o d ając operacje w ramce reprezentującej klasę. T e g o r o d z a ju o d p o w ie d z ia ln o ś c i nie im p lik u ją jednak struktury danych. N a pod stawie d ia g r a m u p o z io m u s p ec y fik ac ji nie m ożna robić żadnych założeń co do struk tury d a n y c h k la s . N i e m o ż n a p o w ie d z ie ć , czy klasa Z a m ó w ie n ie zaw iera w skaźnik do K lie n t a , c z y te ż k la s a Z a m ó w i e n i e spełnia swoje zobow iązania, w ykonując kaw ałek kodu, k tó r y p y ta k a ż d e g o K l i e n t a , c z y jest p o w iązan y z danym Z a m ó w ie n ie m . D ia gram m ó w i t y l k o o in te r fe js ie — i o n ic z y m w ięcej. . . . G d y b y to był m o d e l im p le m e n ta c y jn y , to im p lik o w a ło b y to, że m iędzy p o w ią żą -
nymi klasa,,,, istnieją wskaźnik, w obu kierunkach Diagram wskazywałby teraz, że Z a m ó w ie n i e ma pole. które jest kolekcją wskazntków do Pozycj, zamów,c n a , ma w s k a źn ik d o K l i e n t a . Dla Javy tnoźna wywnioskować dany Iragment. class Zamówienie { private Klient _klient; private Zbiór _ p o z y c j e Z a m ó w i e m a ;
*•# class Klient { private Zbiór
zamówienia;
. w kropelce
, • Linda również ¡sinienie o p e r a c j i d o s tę p ,, u W la k im w y p a d k u w iększość * * * » uzyskać, jedynie p a t r z ą c na o p e r ^ w iumi" ------ u/ność co do te8° atrybutów klasy, ale pewn ^ sam |a k ,-ysunck 4 ( " “ warto spojrzeć z Jednym & n a w ig o w a ł’ " ■
.
° ,“oż|iwość przejścia •
; L
y jn y m
^ z a m ó w ie n ie jest odpowiedz,,,|„c
o z n a c z a ło b y to ,
n(
is s f f lS f c .^ s r S iS *
me
ma
a n ;i|o g lc /
rr
~
możliwości podania swoich * - ^ ¿ ¡ ¡ 5 . implementacyjnym oznaczałoby bowiązanla tylko po jednej stron* * * * 8 ^ , n,e ma wskaźnika do i . , « , że Zamówienie ma wskaźnik do K la n . i ani entern diagramów implementacyjnych Jak widać, nawigowalność jest ważnym ei potrzeba podawania jej na i specyfikacyjnych. Nie wydaje mi się je n ia
diagramach pojęciowych. ^ nnieciowym bez specyfikacji nawigowałCzęsto można się spotkać z dmgian P• perspektyw specyfikacyjnych ności. Nawigowalność jest dodawana przyPrj ^ ! c1“ . ? feme„ta c ji. i implementacyjnych, ale może byc inna P k taką asocjację nazywa sąJeśli nawigowalność istnieje tylko w jednym ta m * .a . t ^ (| ; ■
jednokierunkową. Asocjacja Ranort notacii UML-a podaje, aby asocjacje reprezeniowiiiic ina
i ngram ach jako 1,„, b
S ^ k traktować jak asocjacje, k.ó^ch nawigowalność me jest znana, lub tak asocjacje dwukierunkowe. Zespól projektowy powinien w ybiac jedną z tych m a p « , tacji. Dla modeli specyfikacyjnych i implementacyjnych traktuję linie bez sti/nwk jako „nieokreślone” . ....................................... Asocjacje dwukierunkowe mają dodatkowe ograniczenie, m ówiące, ze jedna nawi gacja jest odwrotnością drugiej. Jest ono podobne do pojęcia odw rotności lunkcji w' matematyce. W kontekście rysunku 4.2 oznacza to, że każda z P o z y c ji związana z Zamówieniem jest związana z tym konkretnym Z am ów ieniem . A nalogicznie, jeśli weźmie się Pozycję zamówienia i spojrzy na Pozycje stowarzyszonego Zamówienia, to kolekcja Pozycji zamówienia powinna zawierać właśnie tę P ozycję zamówienia Ta zasada jest prawdziwa we wszystkich trzech perspektywach. Jest kilka sposobów nazywania asocjacji. Tradycyjnie w m odelow aniu danych do nazwania asocjacji stosuje się frazy czasownikowe, tak aby relacje m ożna b yło si stosować w zdaniach. Większość praktyków modelowania obiektowego w o li używać u \rzeczowników do nazwania roli jednej ze stron relacji, ponieważ pasuje to lepiej do pojęć zobowiązanie i operacja. kaŻdą asoc|acj ę- Ja nada)S nazwę asocjacji ty lk o wtedy, gdy
z nazw muvm,agmV-
T
*
^
W id zia łe m zbyt w iele asocjacj.
ma nazwy po^ednej stronie asochiciHo '' * nie. l|zywam nazwy klasy odpow iadaiącei tej 'die-
istnieje oni
przez cały « L ic h m,ędzy dw om a o b ie kta m i. Oznacza to. Jtiem czasu ulegać zmianie ialho i»1013’ m!l111<) Ze instancje ty e li o b ie k tó w mogą / t,lC ^P 3
11 as°c ja c ji op cjona lne j b yć puste) /a tc '11
D ia g ra m y klas - podstawy
odwołanie do o b ie ktu lub Jego u tw ó r modelowane zależnościam i (zobacz r o z S y T i T “ “ “
asocjacji — elem enty te są
Zam ówienie dataO trzym am a
przedpłata numer: String i: waluta wyślij!) zamknij!)
K lien t nazwa adres
Nawigowalność
wiarygodnośćKrcdytowa(): String
1 {jeśli Z am ow ienie.klicnt.w iai^godnośćK rcdytow a jest „niska %to Zamów lenie.przedpłata musi być prawdziwe 1 1
K lie n t fir m o w y osobaDoKontaktów
K lie n t in d y w id u a ln y numerKarty Kredytowej
wiarygodnośćKredytowa lim it kredytowy p rzypom nij) obciążZaMiesiącf Integer)
przedstawiciel handlowy
0..1
pozycje
R ysunek 4.2. Diagram klas
{ wiarygodnośćKredytowa!) == „niska” )
4.3
Atrybuty
są bardzo p o d o b n e d o k l a s i e K lie n t oznacza ty lk o tyle, A. N . poziomie » * * < * ? . aitybul ten wskazuje, ze Klienci mają nazwę. a pozit istnieje sposób jej ustawiania. Na p o /io im c A try b u ty
¿
i —
«
szczegółowości diagramu notacja dla atrybutu może zawierać atrybutu, typ i wartość domyślną. Syntaktyka U M L -a jest następująca.
W z a le ż n o ś c i od zw ę
*
• na
specyfikator-dostępu nazwa: typ —wartoścDomyslna gdzie specyfikator-dostępu jest taki sam jak dla operacji opisanych dalej. Jaka jest więc różnica między atrybutem a asocjacją? Z punktu widzenia pojęciowego nie ma żadnej różnicy. A try b u t niesie z sobą inny sposób notacji, którego można używać, jeśli jest to wygodne. A try b u ty są zw y k le jednowartościowe. Zwykle też diagram nie mówi, czy atrybut jest o p cjona lny, czy obo wiązkowy, aczkolwiek można to wyrazić, wypisując krotność za nazwą atrybutu w na wiasach kwadratowych — na przykład dataOtrzyniania[().. 1] : Data. Różnica pojawia się na poziomie specyfikacyjnym i im plem entacyjnym . A try b u t\ implikują nawigację wyłącznie od typu do atrybutu. Co więcej, typ zaw iera w yłącznie swoją własną kopię obiektu atrybutu, a to oznacza, że ja kiko lw ie k ty p u żyty jako atrvbut ma semantykę wartościową, a nie referencyjną1. I
4.4
Operacje
Operacje są to procesy, które klasa potrafi wykonać. Operacje w sposób oczywisty odpowiadają metodom klasy. N a poziomie s p e c y fi kacyjnym operacje odpowiadają metodom publicznym typu. Najczęściej nie w y m ie n ia się metod, które tylko manipulują atrybutami, bo zw ykle ich istnienie można w y w n io skować. Można jednak wskazać, czy dany atrybut jest tylko do odczytu, czy te ż jest „zamrożony” (to znaczy jego wartość nigdy się nie zm ienia). W modelu im p le m e n ta cyjnym można pokusić się również o pokazanie metod prywatnych i chronionych Pełna syntaktyka dla operacji jest następująca:
(U S ,a -p a r ‘" H e tr Ó " > : ^ ^ i e - t y p u - y t y n i k u
gdzie:
sPe
" P 0Sf« ln >0 o wartość atrybutu, a nic o w skaźnik w skaźnik do jego warto
u - . .
chro n io n y (ang. protected) P ry w a tn y (ang. p riv atc ) >'
„azw a to łańcuch a lfan u m eryczn y lis ta -p a ra m e tró w za w ie ra ciae „ syntaklyka je s t podobna do t e j ^ a
P a lo n y c h
przecinka,™. których
sposób -p rzekazyw an ia n a z w a - tvn = ° W: Jedynym d o d a tk o w y m e l e m l Î L T " “ " U m y ś l n a . “Pcrac' l: in — p rzez w artość,
J
U" a)
argumentów
o u t — p rz e z w y n ik ,
inout — przez wartość i wynik Jeśli s p o s ó b -p rz e k a z y w a n ia argum e p rz e k a z y w a n ie p rz e z wartość ( / „ ) ^ • .
U
w y ra ż e ń ie -ty p u -w y n ik n to ciae tvn szóści w y p a d k ó w stosuje sie ie d o n u U y łańcuch
- „ .la s n o ic ,
'
j ° St podany> 1(1 Przyjmuje się domyślnie “ P o d z ie lo n y c h przecinkami. W w ięk-
yP W yn,ku- ale " « « à » dopuszcza w,cle
Przykładową W m o d e la c h
* * pojęciowych
nie n o w in n n ^
+“
Z D m a (data: D ata)
Pieniądze.
terfejsu k las y . Z a m ia s t tego n a leży u ż y w ić fćh d n ^ i ” °Peracj.1 tl(> sPecynkowania indanei k la s y D o s łu m iia c sie nr-/, . * podania podstawowych zobowiązań bacz ro zd zia ł 5 .)
paroma słowami streszczającymi karty C R C (zo-
^ ^ ^ ^ o
m a m tru d n o ści z o d ró żn ie n ie m operacji, które zm ieniają stan klasy, od tych, tego stanu n ie z m ie n ia ją . U M L definiuje kwerendę (ang. query) jako operację,
które która pobiera w a rto ś ć z k la s y , m e zm ien iając je j stanu — innymi słowy me powoduje efektów ubocznych. M o ż n a ta k ą operację opatrzyć ograniczeniem {queryf. Operacje, które zmieniają stan k la s y , o k reślam term inem modyfikatory. Specjalne z a z n a c z e n ie k w e re n d pom aga m i w pracy. Podczas gdy kwerendy mogą być wykonane w d o w o ln e j k o lejn o ś c i, to kolejność w ykonania m odyfikatorów jest szczególnie istotna. W p ra k ty c e staram się unikać zwracania wartości m odyfikatoram i, aby odróżnić je od k w e r e n d . Jnne określenia, j a k i e m o ż n a spotkać, to m etody p o b ie ra n ia w artości1 i metody usta wiania wartości. M e t o d a p o b ie ra n ia wartości po prostu zwraca wartość pola. M etoda ustawiania wartości n a d a je p o lu w artość. N a zew nątrz klient nie pow inien być w stanie powiedzieć, czy kwerenda je s t m e to d ą pobierania wartości albo czy m odyfikato r jest metodą ustawiania wartości. Z n a jo m o ś ć tych m etod jest sprawą w ew n ętrzn ą klasy. Jest jeszcze jedno rozróżnienie - między a metodą. Operacja jest w y w o ływana dla obiektu (wywołanie procedury), podczas gdy metoda to ciało procedury. Obie te rz e c z y są różne, gdy w grę wchodzi polimorfizm. Jeśli jest dany typ podstawo wy o trzech typach pochodnych' i każdy z nich przeciąża pewną operację typu podsta wowego, to jes to wówczas jedna operacja z czteroma metodami ją implementującym,.
Niektórzy nazywaj, tak, metodę Num.).
Czasami nazywany supertypem (przyp tłum.). Czasami nazywane równieżpodtypami (przyp. tłum )
a e rc.o km sod angielskiego accessor method (przyp.
U M L w kropelce
m e t o d a z a m ie n n ie , a l e c z a s a m i p r z y d a j e S|ę
7 w v k ,e u ż y w a się określeń operacya
'
^ ^
s , n a z y w a n e f u n k c ja m i
, e r m i „ s k ł a d o w e k łu s y (a n g . m e,„.
n a z y w a o p e r a c j e m e to d a m i. C + + r o « m < *
of
a c la s s ) na
„ , u .„.
te rn n m
o p e r a c ji) i ciało metody k o n w e n c je n a z e w r u c z e W ( . + + o p e r a ,,, m e m b e r fu n c t io n s ) , p o d c z a s g d \ S n i a l l t a l k
precyzja w ich użyciu. N ie k ie d y r o / r t a m l m etody lub d e k la ra c ja Języki p ro g ra m o w a n ia m a ją s w i
b e rs
p o ję c ia , s t o s u j e
.
(J M L
używ a
t e r m , n u c e c h u ,,,
określenie o p e r a c j i
o k r e ś le n ie a tr y b u tu lu b o p e ra c ji
4.5
Uogólnienie
T yp o w y p rz y ,a d w T P1
ln
e
g
" y
b a z u je
p S n e
m o ż n a u m ie ś c ić w o g ó ln e j k la s ie K l i e n t ( u
firm owy mogą h y c
w o C m ) a K lie n t in d y w id u a ln y i K lie n t
ty p a m , p o c h o d n y m , p o z io n n u lt m n uo d e
U o g ó l n i e n i e je s t p r z e d m i o t e m r ó ż n y c h i n t e r p r e t a c j i n a r o ż n y c h lo w a n ia . W
\ -
.
m o d e lu p o ję c io w y m
___
7
—
m o ż n a p o w ie d z ie ć , z e
t y p i e p o d s .a -
K lie n t
fir m o w y
jk s
ty p e m
p o c h o d n y m K l i e n t a , o ile w s z y s tk ie in s ta n c je K l i e n t a f i r m o w e g o są , z d e l i m q i , r ó w n ie ż i n s t a n c j a m i K l i e n t a . K l i e n t f i r m o w y j e s t w ó w c z a s s p e c y f i c z n y m J e st w a ż n e , ż e w s z y s t k o , c o m o ż e m y p o w i e d z i e ć o
K lie n c ie
ty p e m
K lie n ta
uli \ b u ty .
a s o c ja c je ,
o p e ra c je — je s t r ó w n ie ż p r a w d z iw e w s t o s u n k u d o K l i e n t a f i r m o w e g o .
W
m o d e lu
s p e c y fik a c y jn y m
u o g ó ln ie n ie
oznacza,
że
in te r fe js
ty p u
pochodnego
m u s i z a w i e r a ć w s z y s t k i e e l e m e n t y i n t e r f e j s u t y p u p o d s t a w o w e g o . M ó w i s ię w ó w c z a s , że in te r fe js ty p u p o c h o d n e g o je s t z g o d n y z in t e r f e js e m t y p u p o d s t a w o w e g o . Jeszcze in n y s p o s ó b m y ś le n ia je s t o p a r ty
n a z a s a d z ie p o d m ie n ia ln o ś c i
P o w in n a
kawałku k o d u , k tó r y w y m a g a K l i e n t a , i w s z y s t k o p o w i n n o d a l e j d z i a ł a ć b e z problemu. W istocie z n a c z y to t y l k o t y l e , ż e j e ś l i k o d u j e s ię d l a K l i e n t a , t o m o ż n a p o t e m dowolnie s t o s o w a ć ja k i k o l w i e k j e g o t y p p o c h o d n y . K l i e n t f i r m o w y m o ż e r e a g o w a ć n a niektóre p o le c e n ia i n a c z e j n i ż i n n y K l i e n t ( w w y n i k u z a s t o s o w a n i a p o l i m o r f i z m u ) , a l e obiekt w y w o ł u b y ć m o ż liw a z a m ia n a K l i e n t a n a K l i e n t a
ją cy
fir m o w e g o w
każdym
n i e p o w i n i e n s ię k ł o p o t a ć t ą r ó ż n i c ą .
Uogólnienie w modelu im plem entacyjnym
je s t z w ią z a n e
kach programowania. Klasa pochodna1 dziedziczy stawowej i może przeciążać dziedziczone m etody.
z
d z ie d z ic z n o ś c ią
w s z y s tk ie m e to d y
,
p o la
w le w
klasv pod-
Zasadnicza jest lulaj różnica m iędzy u o g ó ln ie n ie m na p o z i o m , e s p e c y fik a c ji d y l " pochodne, dziedziczenie interfejsu) a dziedziezpnipm „ , ' , (klasy pochodne, dziedziczenie im p le m e n t^ fit ^ , ' ° Z,om,e ‘mpteme.uacji nym ze sposobów im plem entacji tv n ó w n J a T ? " ® pochodnych jest iedimpiementować za pomocą delegowania -
w ™
nych przez Gammę, Heim a, Johnsona i V lis s i l“
v u s s ia e s a
^
Tom T '
| Z w a n a r ó w n i e ż podktasą ( p r z y p . t h l m ,
wana rówmez hit
.s k p ą le a rm ul b
p 0 c h o d n e m ozna 1'ó " ' n,W
( p r z y p . t ł u m . ).
[ż ()|
dotyczy
* " T
te g o ,
p ik
*
K
u tw o rz y l
dwie Kiasy o potioonych interfejsach sposoby im p le m e n ta c ji ty p ó w nnrh i
ka-^ c d z ie d z ic z e n i- ! i
' N ie zale żn ie od
" **»
P° Ch° dnyCh'
peW„osc ze u o g ó ln ie n ie z p o zio m u k o S “ * * ' " S 61" * » » - » t ó j r mieć zawsze wypadku ła tw o n a razić się na k ło p o ty Pr/V pcyjne^ ° ^ zachowane. W przeciw nym " '“ >ab" ne-. . . Czasami m o ż n a się zetknąć z
y P n y ew enm al- l 2mianie -
uogóIruerue będzie
interfejs j a k je g o ^ P .P O d Sta w o w y ^ r r m r t i * , k' Ó,ych ^
P ° < * * l n y ma taki san,
wtedy m e p o k a z y w a ć typ u pochodnego „
w j" " y SP<*«> M ożna
zainteresowań, rym ż p o c h o d n y jest w y n ik ie m
użytkow nicy k la s y są robię tego, je ś li ty p
j||p r
"
e
” ,0delu sP<*y««cyjnego Jeśli Is lllie je - to 8 ° Pokazuję, ale nie I wnych wymogów implementacyjnych.
4.6
Stosowanie ograniczeń
J
Z ,e8° ' C° Sl? UmieSZCM na diasramie klasy, jest wskazywaniem na ograni-
T
D ia ^ t e t ó e 2i „ f o ^ e e; U £ £ £ £ , ^ ^ p*“ ł ^ Kli' " la na preykfad 40 brązowych ptzedmiotów. 4(! o i e b S ^ ^ T T ^ c h przed m io tó w , a nie 40 czerwonych, niebieskich i brązowych przedmiotów. Co więcej, diagram mou i, ze Klienci hi mowi mają ograniczenie kredytowe, a K lie n c i indvwidualni — nie. P o d s ta w o w e k o n s tru k c je, ta k ie ja k asocjacja, atrybut i uogólnienie, idą dość daleko
w stronę s p e c y fik a c ji o g ra n ic z e ń , ale nie m ogą objąć wszystkich. Ograniczenia te m u szą być jednak u c h w y c o n e , a d ia g ram klasy jest na to dobrym miejscem. UML u m o ż l i w ia s to s o w a n ie d o w o ln e g o narzędzia do opisu ograniczeń. Jedyną re gułą jest to, że o g r a n ic z e n ia m u szą być umieszczone w nawiasach klam row ych { } . Kładąc nacisk na c z y te ln o ś ć , z w y k le u ż y w a m nieform alnego opisu słownego. U M L udostępnia także f o r m a ln y jqzy>k opisu ograniczeń w skrócie O C L (ang. Object C o n straint Language); z o b a c z W a r m e r i K le p p e [4 5 ]. W sytuacji idealnej r e g u ły i o g ra n icze n ia p o w in n y być im plem entow ane ja k o asercje w danym języku p r o g r a m o w a n ia . O d p o w ia d a ją one pojęciu n ie zm ie n n ik ó w w ko n strukcji oprogramowania k o n tra k to w e g o (zo b a c z ram ka poniżej). Konstrukcja oprogramowania kontraktowego Konstrukcja oprogram ow ania kontraktowego jest 10 technika opracowana pizez Bor-
1331 Jest
tanda M eyera
gramowania Eiffel na do języka Eiflcl
ona kamieniem węgielnym utworzonego przez mego języka pro
Konstrukcja oprogramowania kontraktowego mejest jednak ogtamczo-
i m oże być stosowana w dowolnym języku programowania. Podstawą konstrukcji oprogramowań,a kontraktowego jes, merejo. Asercjnjest ,o zda-
; r
r
*
r
»
“
*in ie n
zakładać, żc asercje są sprawdzane.
■ ■—
-
*
—
un-
p rz y k la d jeśli nic ,uy.Lv.„t , j u . . j - t w y » dla liczb, to w aru nek k o ń c o w y mógłby zdefiniujemy operację „pierwiast w y n ik ie m o p e rac ji, a u ty .ś o r jest przyjąć postać wejście = wy/i/A m jw * . gdz osobcm w y ra ż e n ia lego, co jest daną wejśc.ową operacji. W arunek końcow y j robione, bez mówienia, ja k to jest robione inny
ry
o d d zie len ia in te rfe js u od im pleY
menW a iu n c k początkowy jest stwierdzeniem, ja k pow inno w y g lą d a ć ś ro d o w is k o p rzed w y
konaniem operacji! Dla o ^ n t e ji „pierwiastek k w a d ra to w y " m o ż n a z d e h m o w a w rt.ne początkowy następująco: ie c > w ś j -T .0 ak, w arunek p o c z ą tk o w y m o w . Ze W y d c m jes, w y w o ły w a n ie operacji „pierwiastek kw adratow y" dla liczb u je m n y c h , ze k o n s e k w e n c je takiego działania są nieokreślone. Na pierwszy rzut oka takie postępowanie nie w y d a je się d o b ry m p o m y s łe m , p o n te w a ż należy gdzieś sprawdzić, że „pierwiastek k w ad rato w y
je s t w ła ś c iw ie w y w o ły w a n y
W aż-
nym pytaniem jest zatem, kto odpowiada za to sprawdzenie. W arunek początkowy w yraźnie m ó w i, że to w y w o łu ją c y jest o d p o w ie d z ia ln y za s p ia w dzenie. Bez takiego jaw nego stwierdzenia odpow iedzialności m o ż n a w y k o n a ć
za m ało
sprawdzeń (bo obie strony zakładają, że to ta druga jest o d p o w ie d z ia ln a ) a lb o zb y t w iele (obie strony sprawdzają). Zbyt w iele sprawdzeń prow adzi do d u p lik o w a n ia k o d u do s p ra w dzania, co może znacznie zw iększyć złożoność program u. N ie b e z p ie c z e ń s tw o , że w y w o ł u ją c y zapom ni sprawdzić warunek początkow y, redukuje się z w y k le , s p r a w d z a ją c asercję w trakcie uruchamiania i testowania programu. Z tych definicji warunku początkow ego i końcow ego m o żn a w y p r o w a d z ić d e fin ic ję wy ją tk u , do którego dochodzi, kiedy w y w o ła n ie operacji ro zp o c zy n a się ze s p e łn io n y m w a ru n k iem początkow ym , ale nie kończy się ze spełnionym w a ru n k ie m k o ń c o w y m . N ie z m ie n n ik jest to asercja dotycząca klasy. N a p rz y k ła d klasa R a c h u n e k m o ż e m ieć niezm iennik m ów iący, że saldo = = s u m a fp o zy c je .w a rto ś ć Q ).
N i e z m i e n n i k je s t
zaw sze
p ra w d z iw y dla wszystkich instancji klasy. Tutaj te rm in „ z a w s z e ” o z n a c z a , że „ o b ie k t istnie j e i m ożna na nim w y w o ła ć operację” .
jest dodawany do warunków p o c z ą t k o w y c h i końcow ych w szystkich operacji publicznych danej klasy. Niezmiennik w o b i e k c i e ' , noże nie byc p ra w d z iw y w trakcie w y k o n y w a n ia mciody. ale powinien b y ć o d t w o r z o n y , z a n im jakik o lw te k in n y obiekt będzie chciał skorzystać z tego o b ie k tu lub zmienić c o A sercje o d g ry w a ją w y ją tk o w ą rolę p rzy tw o rz e n iu klas pochodnych ' O znacza to w istocie, że n ie zm ie n n ik
Jednym z niebezpieczeństw p o lim o rfiz m u jest to żc m o ż n a I w t - .i i K racje klasy pochodnej, aby nie b y ły spójne z oncrae. im , u , P r e d e f i n i o w a ć opc-
puszczają do lego. Niezmienniki i warunki końcowe I również dla je j klas pochodnych K hsv nnrlt i '
i P ^ w o w e j . A sercje me doolneJ k l' ,sY muszą byc prawdziwe
ich osłabić. Z drugiej s tro n y ifm n k l z a k WZmocnić lc ^ nie .nos. nianc. 1 WanmluP a k o w e mogą b y ć ty lk o o s ła b ia n e , a nigdy w zm tic N a p ie rw s z y rz u t o k a m o ż e w y g lą d a ć u
i
ma dynamicznego operacji. Należy ziws 7o t a*° wa* ne Jest tu zapewnienie wiąza° n ,nslancW klasy podstawowej ^ ° bickl klasy Pochodnej, jak gdyby był wzmocniła warunek p o c z ą t k o ^ i ^ l ^ podmic"i*1nośei). Jeśli Llasa pochodna '/ostanie użyta dla obiektu klasy pochodne ° |Xr;iCJa
Podstavv(>wej może zawieść,
D ia g ra m y klas
Asercje mogą tylko z w i ę k s z y ć i____________ _____ ______________________ kowe są stwierdzeniem o nrzeka-L P° Wlc
l ln
™ « » -mchami,"„“ ' p T o ^ " ^ w X ^ Można s.osowac w T I rdzTych P «*ątko w c s , „ajlaliszym ^
Kiedy sto so w a ć konstrukcje kon^aktowego?
Technika ta jest pomocna przy
Tylko Eiffeł zawiera a s e r c j c 7 “ nyc!’. *“ • ' « * * * szechnic używany. Dodanie do innych Kvvkó CZęsc języka- ale " ie J<*t niestety zbyt powcych asercjc jest proste (acz dość niezręczne) * pr° 8ramowania mechanizmów obslugująU M L nie zawiera wiele informacji • • kłopotu. N iezm ienniki są zw ykle r t w n o w i / v ! a'C m° /na Jc s,osować bcz żadnego mów klas i należy je ja k najszerzej stosować w ^ " T ° pisu'ącym ograniczenia dla diagrawinny być d o k u m e n t o w a n e 'w d S cX o £ r a ^ T
•» « *
Dodatkowe źródła Książka M eyera [3 3 ] to ju ż klasyka (aczkolwiek dosyć gruba) dotycząca konstrukcji oprogramowania o b ie k to w e g o , poświęca wiele stron ascrcjom K im Waldcn . iean-Marc g g J ę * i J 4 4 ] oraz Steve C o o k i John Daniels [13] dokładnie opisują technikę konstrukcji oprogramowania przez ko n tra kt w swoich książkach. Można także uzyskać dodatkow e inform acje ze stron W W W firm y ISE (firm a Bertranda Meyera) pod adresem: http://w>ww,eijfeicom\
4.7
Kiedy stosować diagramy klas
Diagramy k la s to k rę g o s łu p p ra w ie ciągle u ż y w a n e . W ty m r o z d z ia le zostały dziale 6 . będą p o k a z a n e b a rd z ie j z ło żo n e ,
w szystkich metod obiektow ych, dlatego są o m ó w io n e tylko pojęcia podstawowe, w roz
D ia e r a m v k la s sa tak b ogate, że czasami m ożna m ieć problem z ich używ aniem i dlatego d o b r z e j e s t s to s o w a ć się do podanych w skazów ek. •
Nie należy u ż y w a ć c a łe j d o stępnej notacji. W a rto zaczynać od rzeczy prostych o p i
•
sanych tutaj: k la s , a s o c ja c ji, a try b u tó w , uogólnień . ograniczeń. N otacja z rozdz.alu 6 powinna być w p ro w a d z o n a ty lk o w ted y, k te d y je s t r z e c z y w .s c e potrzebna. Model który j e s t t w o r z o n y , p o w in te n być dostosow any do etapu projektu. • Na etanie analizy należy rysować modele pojęciowe. Na etapie analizy na,eży skoncentrować się na modelach specy• Pracując nad o p r o g r a m o w a n i , fikacyjnych. Także
TT T 7 Rprfranda M eyera w piśmie IE E E Computer (przyp. do n ie d aw n a z felictono
podstaw y
U M L w kropelce
*
.
ni*
n a le ż v r y s o w a ć M o d e le im plem entacyjne n a le ży ry.
tylko wtedy, gdy
trz e b a
z.lustrouaL
jakąś ic-chnikę iniple,nentacwn^
.
warto się skoncentr, c,;, Nic należy rysować model dla wszy tk e g o ,_ ^ dmgramów kló n Me u /. na najważniejszych obszarach Lc[ I . , Drzestarzałych modeli wa , które się uaktualnia, niż stertę zapo,.imanych , przest. y
niebezpieczeństwem związanym * ^ „ „ « n t r o w a H .T ? w szczegółach implementacyjnych. Aby temu zapo i . . modelach pojęciowych i specyfikacyjnych. Jeśl. jednak problemy s,ę pojawią. ,o bęc N a jw ię k s z y m
może pomocne staną się wtedy karty CRC (zobacz strona
4.8
Dodatkowe źródła
Każda ze wspomnianych przeze mnie w rozdziale 1. książek o U M L-u omawia dia gramy klas bardziej szczegółowo. Ze starszych podręczników ciągle podoba mi się książka Cooka i Danielsa [ 13j ponieważ dobrze omawia perspektywy modelowania i próbuje fom ializować te z a e a d W »•z»ri*rx
»
Diagramy interakcji
• • « iak w s p ó łp r a c u ją z e s o b ą g r u p y o b ie k ic e k ta n jro m o d e le o p ts u ją ce , j a k w s p P
D ia g r a m y
systemu
tó w . . n rz e d s ta w ia z a c h o w a n ie Z w y k le d ia g ra m in te ra k c ji p rz e d s ta w ia
d o t y c z ą c e je d n e g o h o b i e k t 0 w . k o m u n ik a ty
p rzy p a d k u U życia. D ia g r a m p o k a z u je k ilk a p r z y * p rze z nie w y m ie n ia n e w ram ach przypadK U
y
zachow am a systemu
.
Z ilu s tru ję to p ro s ty m p rz y p a d k ie m u z y c a d to n - W W
8
do
.
O k n o w p r o w a d z a n i a z a m ó w ie n ia w y s y ła k o m u n ik a t „ p r z y g
•
n ia , izot n i w u o t u i ” d o k a ż d e j Z a m ó w ie n i e następnie w y s y ła k o m u n ik a t „ p > Sr w ic n ia na Z a m ó w ie n i u .
•
P o z y c ji za m ó
m<ł„ a r v n i e
K a ż d a P o z y c ja z a m ó w ie n ia s p raw d za
ow ar
.
Jeśli w y n ik s p raw d ze n ia je st
•
z io m T o w a r u w m a g a z y n ie o o d p o w ie d n ^ Jeśli p o z io m T o w a ru w m a g a z y n ie spad |
z a m ó w i e n i a z m n i e j s z a pop o z y c ję d o s ta w y . . w a rto ś c i g r a n i c z n e j , to T o w a r
w m a g a z y n ie w y m a g a o d n o w ie n ia z a p a s ó w . Is tn ie ją d w a ro d za je d ia g ra m ó w in te ra k c ji -
d ia g r a m y
s e k w e n c ji
, d ia g r a m y
w s p ó łd z ia ła n ia .
5.1
Diagramy sekwencji
Na diagramach sekwencji obiekt jest przedstawiany jako pudełko nad p i o n o w ą , przerywaną linią (zobacz rysunek 5.1). Linia pionowa jest nazywana linią życia obiektu i reprezentuje życie o b ie k tu w trakcie interakcji. Ta forma została spopularyzowana po raz pierwszy p rz e z Jacobsona Jacobsona T241. [Z4J. Każdy komunikat jest reprezentowany za pomocą strzałki między liniami ż y c ia dwu obiektów. Chronologia wysyłania komunikatów jest określona sposobem c z y t a nia, od góry do dołu strony. Każdy komunikat jest oznaczany co najmniej s w o j ą n a zwą można także dołączyć tu argumenty i nieco informacji sterującej. Komunikat, który obiekt wysyła do siebie samego, czyli tak zwane samowywołanie można p r z e d stawić, rysując strzałkę z powrotem do linii życia obiektu w y s y ła n e g o . Aby pokazać, ze obiekt jest aktywny (dla interakcji proceduralnej oznacza to, ze procedurajea na stosie wywołań), rysuje się pudełko aktywnej,. Można nie stosować z r o z u m i e n i a WaCJ* ~
d'agra" ’ ^
^
* * * * * do " ^ o w a n t a . ale
t r u d n i e j s z y do
Są ważne dwa elementy informacji sterującej. przykład [potraebaUzupełnTe^^
komunikat jest wysyłany (na
nek jest prawdziwy. Warunki są przydatne J Wysyłany tVlko wtedy< ^ waru‘ W bardziej z ło ż o n y c h sytuacjach w o le ni* Prostych sytuacjach, takich jak ten dego przypadku użycia. wrysować osobne diagramy sekwencji dla każ-
D ia g r a m y in te ra k c ji
Drugim p o m o c n y m elem entem steruia
,
komunikat jest w y s y ła n y w ie lo k ro tn ie d T í l ¡ ? ' ? a ™ i k U e r a c * ^ r y wskazuje żc 0» przyk*ad w w y p a d k u przechodzenia ciąm, elem ' e^ ow - ° db,orców , jak to się dz.eje ka/ao w naw iasach k w a d ra to w y c h , na p ^ y M a ^ n . Podsta^ G ra c ji można p>„ial
P
Vkład 'dla
Rysunek 5.1 zawiera powm j■ ^ munikat. Powroty różnią się ot y pr/erywaną. Niektórzy rysują powroty u
wszystkich pozycji zam ów ię-
komunikat6 w tym, ż kaidcg0 komunikatu
i ' j ----------u w a żam , że za-
73
śm iecą to ty lk o rysunek i d la te g o stosuję je t y lk o w t e d y , g d y u z n a m , że w n o s z ą CUs istotnego. J e d y n y m p o w o d e m , d la k tó re g o n a ry s o w a łe m p o w r ó t n a r y s u n k u 5. |
je^
chęć p o k a za n ia notacji. Jeśli zostanie u s u n ię ty , to d ia g r a m p o z o s ta n ie la k p i z e j r / y s,v jak był. T o je st p o d s ta w o w y test na s to s o w a n ie p o w r o tó w . Jak w id a ć , rysu n ek 5.1 jest b a rd zo p ro s ty i w i z u a l n i e p r z e k o n u ją c y ,
fo
|cst
w ie lk ą zaletą. Jedną z n a jtru d n ie js z y c h rz e c z y do z r o z u m ie n ia w p r o g r a m a c h o b ie k t o w y c h |Cs( o g ó ln y p r z e p ły w sterow ania. D o b r z e z a p r o je k t o w a n y s y s te m o b i e k t o w y m a m n ó s tw 0 m a ły c h m e to d w ró żn y c h klasach i c zas a m i jest k ł o p o t l i w e o d k r y c i e o g ó ln e g o c i,(uu je g o z a c h o w a ń . M o ż n a p rze g lą d a ć ko d p r o g ra m u , a le r o b i ą to n a jc z ę ś c ie j t y l k o n o w i cjusze p ro je k to w a n ia o b ie k to w e g o . D ia g r a m y s e k w e n c ji u ł a t w i a j ą z o r i e n t o w a n ie
mv
w c ią g u za c h o w a ń . N a rysunku 5 .2 w id a ć k ilk a o b ie k tó w s p r a w d z a ją c y c h t r a n s a k c ję b a n k o w ą .
K o m u n ik a t a s y n c h r o n ic z n y
nowa
transakcji
/
P ie rw s z y
w eryfikator transakcji
A ktyw acja nowy
D ru g i
w e ry fik a to r tr a n s a k c ji
V wszystko zrobione?
Dalsze
\
przetwarzanie pominięte.
Obiekt sam się usuwa.
R y s u n e k 5 .2 . P r0 C (lsy
współbieżne I aktywacje
tworzenia transakcji jest także tw cynował jej sprawdzanie. Koordynator t w n ^ ° ? y„ k° 0rdynator tran ^ k c ji. aby kol atora transakcji, z których każdy ,est odnn a (tUtaj dwa) obiektów weryProfes ^n ułatwia dodawanie różnych n m . )W,edzialny 2a konkretną weryfikację, u—— -j - , wywoływany " — M O-yil^llIu nic2nie i d ib m . ii ła ^"ó łh ^ '’ b° ^ wciynKiuor transakcjijest asynchronicznie weryfikator Po a k o ń c z e n iu działania sPołbiezme. P° zzakonczęnm dz,ałania weryfikator weiyfikator tr t r a n sk S ; W ^? ° ‘b,^ n,ekoordynator sprawdza, czy wszystkie weryfikt* ? 1 mt° rmu-)e koordynatora transakcji. |]lC robi nic. Jeśli działanie zakończyło sie nnmJu on,czyły d2 'ałame. Jeśli nie, to mUje transakcję, że wszystko jest w porządku ’ J W ^ wyPadku’ 10 infor' W c h w ili
j
W trakcie iworzenia transakcji
nowa
T r a n s a k c j i!
jest tworzony.. koordynator do zarządzania weryfikacją.
now y
K o o rd y n a to r t r a n s a k c ji
P ierw szy w e r y fik a to r tra n s a k c ji
nowy
koordynator tworzy dla każdego testu osobny weryfikator. Weryfikatory w ykonują testy jako osobne procesy.
nowy
D ru g i
w e ry fik a to r tr a n s a k c ji niepowodzenie
Jeśli dany test nic powiedzie się, to koordynator usuwa pozostałe weryfikatory...
usunięcie weryfikatorów
NJS, /V
X usun
niepoprawna U s u n ię c ie
i przekazuje d o transakcji komunikat, ze jest niepoprawna.
in n e g o
X
o b ie k tu .
I— I R y s u n e k 5.3. D ia g ra m s e k w e n c ji: n ie zw e ryfiko w a n .e czeku
at a s y n c h r o n i c z n y m e b l o k u j e w y luować s w o j e w ł a s n e p r z e t w a r z a n i
i trzech funkcji.
a s y n c h ro n ic z n y m o że w y k o n a .
O.
.. .. , • n t/w u s tr z a łe k o z n a c z a ją k o m u n ik a ty a s y n c h ro n ic zn e . K o d ia g r a m ie p o ł o w k , g r o t o w i ' w y w o łu ją c e g o , ta k że m o ż e on
LJMI w kropelce
... ,n ika tu p r o w a d z i d o s z c z y t« a k t y w a c „ ) nowy wątek (strzałka o im
•
Utworzyć
• .
U tw o rzy ć now y obiekt. n v w a n v m w ą tk ie m Skomunikować się z ju z w yKony * j . O b i e k t y m o g ą się u s u n ą ć s .tme Usunięcie obiektu jest oznaczane
in n y k o m u n ik a t (z o b a c z ry Ml.
(zobacz rysunek 5 .2 ) albo m ogą zos ac nek 5.3). „ r iiK 7 e z p r z y p a d k u u ż y c ia „ S p r a w d z a n y Rysunki 5.2 i 5.3 przedstaw iają d w a sc^ oS obno. Is t n ie ją te c h n ik i dołączam;, transakcji” K ażd y ze scenariuszy naiyso _ w a ru n k ó w log.cznych na je d n y m rysunku, ale się w tedy zbyt złożony. Na 5.3 z a s to s o w a łe m b a r r
y
s
u
n
k
u
s to s o w a ć , bo ry s u n e k staje
wolę
n rz v datną te c h n ik ę — po le w e j stronie dia| y Q sxę d z ie je . W y m a g a to usia-
graniu sekw encji zro b iłe m w s ta w k i teks o w w ie n ia i w yró w n a n ia każdej w s t a w z g o ^
F 0 (lp o w i'e d n j m k o m u n ik a te m na diagra^
^
cgnę d o d a tk o w e j p r a c y . Stosuję u,
mie. Pomaga to lepiej zrozum ieć g z m i e r z a m z a c h o w a ć , a n ie n a d szkicam i je d y n ie pracując nad d okum entam i, któ re z a m ie rz a m z a c n o w a , i hm H nnnisam i.
5.2
Diagramy współdziałania
D ru g im rodzajem diagram u in terakcji je st d ia g ra m w s p ó łd z ia ła n ia . N a diagram ie w spółdziałania p rz y k ła d o w e o b ie k ty są r e p r e z e n t o w a n e p r z e z ikony. T a k jak na diagram ach sekw encji tak i tutaj s trza łk i o z n a c z a ją k o m u n i k a t y przesyłane w ramach przypadku użycia. N a diagram ach w s p ó łd zia ła n ia n u m e ro w a n ie k o m u n i k a t ó w u t r u d n i a z o r ie n to w a n ie się w ciągu zachow ań w p rz e c iw ie ń s tw ie do ich u s z e r e g o w a n ia o d g ó r y d o d o łu strony tak j a k na diagram ach sekw encji. Jednak ten u k ła d p r z e s tr z e n n y u m o ż l i w i a ła tw ie js ze , zaobserw o w anie innych rzeczy. D z ię k i n ie m u m o ż n a p o k a z a ć , ja k o b i e k t y są ze sobą p o w ią zan e , i m ożna składać je d n a na d ru g ie j w a r s tw y p a k i e t ó w i in n e i n f o r m a c j e .
jeden z wielu s y s t e m ó w n u m e ro w ania. N a jp ro stszy system je st p o k a z a n y na ry s u n k u 5.4. Inne podejście, korzystające z System u K la s y fik a c ji D z ie s ię tn e j, je st p rz e d s ta w io n e na rysunku 5.5. N a diagram ach w s p ó łd zia ła n ia m o ż n a stosow ać
numerowania M i m o ze system d zie się tn y utru d n ia z o r ie n to w a n ie się w o g ó l n y m c ią g u zachowań to U M L stosuje go, p o n ie w a ż u m o ż liw ia on jasne o k re ś le n ie , k tó r a operacja woła k t ó r ą Niezależnie od zastosowanego systemu numerowania komunikatów m o ż n a u /u W przeszłości p o w s ze c h n ie b y ł s to s o w a n y p ro s ty s y s te m
wertćji
r3m WSp° ,dzlalan,a 0 '« sami> infonnacj« sterującą jak na diagramach sek-
Na rysunkach 5.4 i 5.5 są pokazane różne fo rm y nazewnictwa obiektów w U M t -u Ogólna reguła nazewnictwa obiektów ma n o s t-ir zw ODIŁ»«ow w UM nazwa obiektu lub nazwa klasy może być p o m in T e ta T T gdzie trzeba pozostawić dwukropek tak i h v l • opuści się nazwę obiektu, to
sy. Zatem nazwa wienia zwaną Macallan. Zwykle w nazwach
76
C° > < " • i es* nazwą kia, ° Znacza ,nstancję Pozycji zatno obiektów używani stylu smalltalkowcgo.
jftk «0 widać na diagram ach sekwencji
,
. * " ° bjeC' Jest d o b rą n a zw ą d|a obiektu1.
popraw,,c w U M L -u , ho
Obiekt
K o m u n ik a t
: Z a m ó w ie ń
ip
N um er kolejny
/5. potrzcbaUzupcłnicnia
2 :*[D la wszystkich pozyqi zamówienia]: p rz y g o tu j)
irzcbnUzupcłmci) 3: wMagazynic := sprawdzi) 4: [wMagazynic]: usuń()
Samowywołame
frlacallan: Pożycie zamńu i,*mfa
7:[w M agazynic]:
6:[potrzcbaUzupcłmcm.i|
: Towar d o s ta rc zo n y R ysunek 5.4. D iagram w spółdziałania z prostym numerowaniem komunikatów
5.3
Porównanie diagramów sekwencji i diagramów współdziałania
Różni p ro g ra m iś c i m a ją ró żn e preferencje, jeśli chodzi o w ybór jednej z form dia
gramu
in te ra k c ji. Z w y k l e stosuję d ia g ra m y sekw encji, poniew aż podoba mi się spo-
Sób. w
jaki
a k c e n tu ją c ią g z a c h o w a ń -
ła tw o w tedy spostrzec co zac!hodz,, w j a t e j
kolejności. In n i w o l ą d ia g r a m y w s p ó łd z ia ła n ia , po n iew aż dzięki ich układow i prze strzennemu m o ż n a z o b a c z y ć s tatyczn e p o w ią za n ia m ię „roslota W ystarczy Jedna z n ł ń w i w c h cech obu ty c h fo rm diag ram u interakcji jest prostota. W ystarczy
^
8S
haby zorientować się
P o s t a w i ć „ a d ia g r a m ie coś do prostych w a r u n k ó w s te ru ją c y c h i dera j ,
Z
U
.
r r " T 7 7 T " ~ ~ L t W iezyku polskim praktycznie niem ożliwy, bo me • en styl n a z e w n ic tw a o b ie k to w jest JV y stnieją w nim ro d z a jn ik i (p rzy p . tłu m .).
I: p rz y g o tu jO
N u m e r k o le j n y
I
• Z a m ó w ie n ie
| ‘ ( D l a w szy stkic h pozycji z a m ó w runął
1 1.2.1: potrzebaUzupelmenia := trzebaUzupelnićj)
I . I . P w M .g a z y n ie :" s p r iiw d ź i)
1.1.2: [wMagazynicJ: usunn
M a c a lla n : P o zy cje z a m ó w ie n ia
1. 1,2.2:[potrzebaUzupelnienia] I . I 3:[w M agazym c]: nowy
: nowy
R ysunek 5.5. D iagram w s p ó łd z ia ła n ia z k o m u n ik a ta m i n u m e ro w a n y m i zg o d n ie z S y s te m e m K la s y fik a c ji D z ie s ię tn e j
nieporęczne przy p r o w a d z i d o nadmiernego d o b a d a n i a zachowań bar
J ed n ym z p r o b le m ó w d ia g r a m ó w in te r a k c ji je s t to , ż e p o t r a f i ą b y ć próbach b ad an ia a lte rn a ty w . W y p r ó b o w y w a n i e a l t e r n a t y w w y m a z y w a n ia i p r z e r y s o w y w a n ia d ia g r a m ó w . D la t e g o te ż d zo są p rzy d a tn e k a rty C R C .
Karty CRC Pod koniec lal osiemdziesiątych je d n y m z n a jw ię k s zy c h o ś ro d k ó w te c h n o lo g ii obiekto wych były laboratoria badawcze firm y T c k iro n ix w Portland w s tan ie O regon. W laboratoriach tych pracowali jedni z głównych u ż y tk o w n ik ó w S m a llta lk a i n a r o d z iło się
tam wiele
ważnych pomysłów technologii obiektow ych. Pracowało la m le ż d w u z n a n y c h proeramtstow smalltalkowych — W ard Cunningham i Kent Beck.
. J O T + r ' Bcck byli. ' *ą.nadal “ interesowani tym, ja k p rz e k a z a ć s w o ja z n a jo m o * k t e a z o t o w d a ^ n h . 7 a h ‘?' iJ obicklow» « i. wyłoniła się prosta technika kart ra u o n T ń r SP a ’IC' * ^ CRC
iak t o p r o p o n ° w a ' a cali. C o Więcej, zamiast opisywać alnrhtitu , k a d l o 6 o w y c h o w y m ia r a c h c z te ry na szc* P y aC a" > bu,> ' 1 m c l0 l|y. zapisywał z o b o w ią z a n ia klasy.
Czym zatem je s t zobowiązanie?
jZ
T!
~
----------------------------------------
teniu. aby uciec od opisu fragm en tó w danych M r ° k° POZiomowy °P IS zadań klasy Służy * ki'ku zdaniach na zadaniach klasy. W y bór karty t l T 3 2amiast ,e^ s k o n c e n tr o w a ć napisać w ięcej, m z się zm ieści na takiej karcie (zobacz Ć n
* 5 ó f ^ Cd° Wy' N ' C m° Żn3
Z o b o w ią z a n ie
Nazwa klasy
W spółdziałanie
Zamówienie S p r a w d ź , c z y to w a r je s t w m agazynie
t Pozycje zamówienia
Ustal cenę
Z w e r y f i k u j p łatn o ść
Wyślij na w s k a z a n y
K lien t
adres
R y s u n e k 5.6. Karta klasa-zobow iązanie-w spoldzialanle (karta CRC)
Drugie C w n azw ie karty odnosi się do jej współpracowników. Są to inne klasy, z który mi dana klasa musi współdziałać. Daje to pewne pojęcie — w dalszym ciągu wysokopoziomowe — o zw iązkach m iędzy klasami. Jedną z głów nych zalet kart C R C jest to, że skłaniają programistów do burzliwych dys kusji. Podczas pracy nad przypadkiem użycia systemu i prób zorientowania się. jak klasy będą go im plem entow ały, stosowanie diagramów interakcji przedstawionych w tym rozd zia le ^ o że okazać się zbyt żmudne i powolne. Zwykle należy rozpatrzyć wiele alternatyw nych rozwiązań, a w y m a zy w a n ie i rysowanie alternatywnych diagramów interakcji trwa zbyt długo. O d p o w ie d n io układając karty C R C modeluje się interakcje. Umożliwia to szybką 3\V t r a k d e t e g o p o ja w ia ją się i są zapisywane na kanach pomysły dotyczące zobowiązań klas Rozważanie zob ow iązań jesl ważne, bo odciąga od myślenia o klasie jak o pojemniku na dan eTuiatw ia zro zu m ie n ie przez członków zespołu wysokopoziomowyc zachowa,, k i sy t ^ w i ą L T l z c odpowP,ad,,e operacji, a,rybo,owi albo (eojes, bardziej prawdopodobne) nieokreślonej zbitce atrybutówri' ° P c^ ] u lud?j Pospolitym ^ . ' 7 c ln ' 7 (o Ph oltó ż io m o w y c h zobow iązań . I u nie to •
lworzcnic długiej listy niskopo-
zobowiązania zawsze powinny ^ ^
łatwo zmieścić |r2Cma d o w ią z a n ia m i,
^
nc na jednej karcie. K w e s lio n o w a lb y n j. ą Wario z a w s z e zadaw ać sobie pylam e. c z y klasa me powinn zama nie p o w i n n y b y ć określono bardziej ogólnym zapisem.
rozbita albo czy zobow iąy
- I
CRC
Kiedy stosować karty Warto stosować kartę C
R U «
zać. ja k jest implemcntow udokumentować za p o m o c ą d.agra
m iedzy
klasami
i w ten sposób pok.i
badać »nterak?/C • . ^k współdziałają klasy. * . ^ po okres|cm u. ja k interakcji
^
^
.y u z y w a c
zo b o w ią za ń . Są one ponioUK.
D o streszczenia głoW" ^ ,as . , , k zeSp o łu gra rolę kilku klas w wykrywaniu zagraconyc których każdy cz :łiiż v to n iczem u W ,d e osób zwraca uwagę na g * . « ' ku r y ^ . . u w a ża m . ze nte ś lu zy to Nigdy nie widziałem , aby W ard
G d z ie s z u k a ć d o d a t k o w y c h in , °T L Ź n ie napisali k s ią żk i o C R C . a le w Internecie Niesiety. an, Cunnmgham. an, Beck « 8 ^ ™ " z n a lc ić ich o ry g .n u ln y artykuł pod adresem k«p://c2.com /doc/oopsiaS 9/paperk tc c h n jk ę _ i stosow a n ,e zobowiązań na ten lemat [3J. Książką, która jest W irft-B ro c k [46]. Jest to książka napisana do.
5.4
a le c ią g le a ktu aln a ,
Kiedy stosować diagramy interakcji
spojrzeć na zachowanie kilku obiektów w ra m a c h je d n e g o p r z y p a d k u u ż y c ia s y s te m u . Diagramy interakcji są użyteczne do p rz e d s ta w ia n ia w s p ó łp ra c y o b ie k t ó w — n ie są jednak najlepsze do podawania ścisłe] N a le ż y stosow ać d ia g ra m y in te r a k c ji, a b y
d e fin ic ji za c h o w a ń .
obiektu na przestrzeni kilku p r z y p a d k ó w u ż y c ia system u , to n a le ż y u ż y ć d ia g r a m u stanu (zobacz rozdział 8.). Jeśli zaś trz e b a s p o jrzeć na z a c h o w a n ie p o je d y n c z e g o o b ie k t u na przestrzeni kilku przypad k ó w u ż y c ia lu b w ie lu w ą t k ó w , to w a r t o z a s to s o w a ć diagram czynności (zobacz roz Jeśli trze b a s p o jrzeć na z a c h o w a n ie p o je d y n c z e g o
d z ia ł 9 .).
Diagramy klas Pojęcia złożone
3$>
'-r
I* /
A
y 1"U r
i
fl
k
Rozćz\a\
U M L w kropelce
B B p K M # ? ''
. . ■ ¡stotnym elementom notacji
P o jęcia o p isane w ro z d z ia le 4. o d p o w i^
. . 2 r 0 Z u m lc ć . poniew aż ^
.j
m6w klas. Pojęcia te są p ie r w s z y m i. J - w o r a e n i 3 d j a g r a m ó w k l a s stosow ane w 9 0 procen tach w y p a H zies iatki dalszych notacji T e c h n ik a d ia g r a m ó w klas m a j e d n a k u -^ w o d p o W ie d n ic h po ję ć. N i e u ż y w a m ic h stale, ale
*
Należy j e d n a k p a rn ię ,a, s t o s o w a ć diagramy k la s równicy
z a g a d n i e n ia .
w ię je po k o le i i w s k a żę z w ią z a n e z ich uzy że te d o d a tk o w e e le m e n ty są o p c jo n a ln e i z e m o z n bez Ten nich.ro z d z ia ł o m a w ia
dla d o d a tk o w y c h sytuacjach. o lru,
. ■ trudne zagadnienia.
J na ak Je ed an
p rzy H
p ie rw s z y m
c z y t a n iu
iq
k s ią ż k i m o ż n a co p o m in ą ć i w r ó c ić do m e g o pj zi
6.1
Stereotypy
są podstawowym mechanizmem rozszerzania U M L-a. Jeśli o k a ż e się ze jest potrzebny mechanizm modelowania, który me istnieje w U M L -u a c je s t podobny do czegoś, co już istnieje, to można potraktować nowy mechanizm ja ko s te r e o t y p m e S te re o ty p y
chanizmu UML-a. Przykładem tego jest in te rfe js . Interfejs w U M L-u jest klasą, któia m a wyłącznie operacje publiczne (tzn. ogólnodostępne) bez ciał metod i atrybutów. O d p o w i a d a to interfejsowi w Javie, COM-ie i CORBIE. W związku z tym, że jest to specjalny rodzaj klasy, jest on zdefiniowany jako stereotyp klasy (więcej inform acji na ten t e m a t znaj duje się w podrozdziale „Interfejsy i klasy abstrakcyjne" na stronie 90.). Stereotypy są zwykle oznaczane tekstem w podwójnych nawiasach k ą t o w y c h (na przykład «interface»), ale można je również reprezentować, definiując dla n i c h s p ecjal ną ikonę. Wiele rozszerzeń podstawowego UML-a można określić jako zb ió r stereotypów W ramach diagramów klas mogą to być stereotypy klas, asocjacji lub uogólm en.M oż na myśleć o stereotypach jak o podtypach metamodelowych typ ó w K lasa Asocjacja i Uogólnienie Zauważyłem że ludzie stosujący U M L mają skłonność do m ylenia ograniczeń ze stereotypami. Jeśli oznaczy się klasę jako abstrakcyjną, to jest to o , n , c z t , 'tcreotyp? Obecna, oficjalna dokumentacja n a z y w a ' ' • dziec, ze rozgraniczenie między ograniczeniem a stereotypem
jest to dziwne, zwazywszy, że podtVD iest stawowy.
7 v w L i,
^
e
w
'u Nc
k ^ ■ 1 wyraźne ink bardziej re strykcyjn y niż typ pod-
UM L-a i rozszerzająo^re^lony^ Profil koi^ sta z częSC‘ jektowama systemów czasu rzeczywiste • rozpoczęła ocł profilów dla pro(ang. Interface Definition Lanuuaimt definicji interfejsu w skrócie U1!ich Więcej. feUatl) “'“ dard,, C O R B A . Jestem pewien, że powstanie
Diagram y klas - pojęcia złożone
6.2
D ia g ra m o b ie k tó w
Diagram
obiektów jest o b ra ze m
o b ie k tó w
k“ ' r ;instancji. = dS,aW'a inS'anCJC kbs' a * l a t "często ° kreŚl0neJ Chwili' W «**=• ^nem * kklasy, jest też nazywany diiD ia g ra m instancji m o ż e być u ż y ty do n i tów (zobacz ry s u n e k 6. | , p o k a z u ją c y z b i ń ^ k l a T T ™ konfiguracji o b iekuyszony z b ió r o b ie k t o w ). Jes, bardzo
« 2- p r z e d s t a w * , * ; « „ « t
obiektami są s k o m p lik o w a n e .
1
yaaln>'- Sdy możliwe powiązania
m iędzy
Rysunek 6.1. Diagram klas elementów struktury organizacyjnej
d z ia ł oprogram ow ania: Oreaniznc ją
n a rz ę d z ia . O n » an iza c ja 1 »!
s ie d z ib a = "P o zn an
Rozdział 6
sied zib a = "W arszaw a"
aplikacje: O ream zacia siedziba = "Paryż"
rodzic
Anna:
Jan: O soba
Osoba
siedziba = "Kraków"
siedziba = " K r a k ó w "
Rysunek 6.2. D ia g ra m o b ie k tó w p o k a z u ją c y in sta n cje e le m e n tó w struktury organizacyinei
W td a ć
le v
•j
że elementy na r y s u n k u V
y .
6.2
są instancjami, ponieważ ich nazwy są podkreś
,i,t v t /m c ii' n a z w a K la s y . O b ie części n a zw y są op
11 K a ż d a n a z w a m a p o s ta ć n a z w a ln s ta n c ji. n u z n u *
83
JM L w kropelce
„ aW11vn,i « K tw a m i. W a rto ś c i atrybutów być ^ I n ag ran i
^
“ ^ j S o d S i a n . w sp ó ld zia la m u . ale ^
obiektów m o ż n a rowmez
k o m u n ik a tó w .
6.3
Operacje i atrybuty w zasięgu klasy
'|P * Ł U M L o k re ś la
>
operację
k tó ry c h lu b a try n u
obszar d z ia ła n ia ^
to k la s a , a m c i„. r ó w n o w a ż n e s t a t y c z n y m skła
stancja tej klasy ja ko będące w zas^ t o d o m kla sy w S m a l l t a l k u . E l e m e n t y lv dow yni w lub Javie oraz zm ienny qc|, k iis y ( z o b a c z rysunek 6.3). dące w zasięgu klasy są podkreślane na diagramach klasy
Zamówienie Z a s ię g in s t a n c ji
pobierzN um er
Zasięg klasy
p n h ip r 7 N a s t e n n v N o \ v v N u m c r
R ysu n e k 6.3. N o ta c ja e le m e n tó w w zasięgu klasy
6.4
Klasyfikacja wielokrotna i dynamiczna
K la s y fik a c ja dotyczy zw iązku m iędzy obiektem i je g o typ e m .
Większość metod projektow ania obiektow ego zaw iera pew ne z a ło ż e n ia w stosunku do tego typu zw iązków — założenia te są ró w n ie ż obecne w g łó w n y c h ję z y k a c h pro gram owania obiektowego. Zostały one zakw e stio n o w a n e p rz e z J im a O d e lla , który uważał, że były zbyt restrykcyjne dla m ode lo w a n ia p o ję c io w e g o . Z a ło ż e n ia te dotyczą pojedynczej, statycznej kla s y fik a c ji o b ie k tó w — O d e ll z a p ro p o n o w a ł w modelach pojęciow ych kla s y fik a c ji w ie lo k ro tn e j i d y n a m ic z n e j.
stosowanie
W klasyfikacji pojedynczej obiekt należy do je d n e g o ty p u , k tó r y m o że b yć dziedzi czony z typu podstawowego. W klasyfikacji wielokrotnej o b ie k t m o ż e b y ć opisan) k ilk o m a typam i, które niekoniecznie są zw iązane re la c ją d z ie d z ic z e n ia . N ależy zauważyć, żc k la s y fik a c ja w ie lo k ro tn a ró ż n i się o d d z ie d z ic z e n ia wielo krotnego. D ziedziczenie w ie lo k ro tn e m ó w i, że ty p m oże m ie ć w ie le ty p ó w podstawo w ych (supertypów ), ale dla każdego o b ie k tu m usi b y ć z d e fin io w a n y pojedynczo typ K la syfika cja w ie lo k ro tn a zezw ala na to, aby o b ie k t m ia l w ie le t y p ó w bez d e fin io w a nia konkretnego lyp u dla obiektu. lek !!v
f * ! ? ' Z P° d ty Pa m i ta k ™
l« k kobieta a lb o m ę /c z y a « -
¡ i k a c , a t Z l ^ r b,Pk ? C i Zdr0W y (ZObaCZ * » » » * 6 .4 ). W ie lo k ro tn a klasy hinacji Z in n y m i, bez potrzeby d ?rZyplsany dowolny z tych typów w d o w o ln e ) kom P y definiowana typów d la w s z y s tk ic h p o p r a w n y c h korni'1 nacji,
D ia g ra m y klas
Wyróżnik L e k a rz
<1-
Pielęgniarz
F iz jo te ra p cu ta
Rv sunek 6.4 Klasyfikacja wielokrotna
stosuje s ię k la s y fik a c ję w ie lo k ro tn ą , to należy jasno „kreślić, które kombtnac,e s, poprawne. R o b , się to, dopisując p rzy lin ii relacji „ogólnie,,,a ,n m i m * w ska zujący podstawę d la tw o r z e n ia podlyp u . K ilk a jrodlypów może mieć ten sam w y ró żnik. Wszystkie p o d t y p y z ty m sam ym w y ró ż n ik ie m są rozłączne — to znaczy każda instancja typu p o d s ta w o w e g o m o że być instancją tylko jednego z podtypów z tym samym wyróżnikiem. D o b r ą zasadą jest zgrupow anie wszystkich podklas używających Jeśli
¡ego samego w y r ó ż n ik a w je d n o p o d d rze w o , ja k pokazano na rysunku 6.4. A lterna tywnie
można mieć
k ilk a s trza łe k z taką sam ą etykietą.
P rzydatnym o g r a n ic z e n ie m je s t za ło żen ie , że ja k a k o lw ie k instancja klasy podsta wowej
musi być
in s ta n c ją je d n e g o z p o d ly p ó w grupy. Klasa podstawowa jest wówczas
klasą ab strak c yjn ą . O b e c n ie w standardzie U M L - a panuje pewne zamieszanie w tej
kwestii, ale wiele osób stosuje o g ra n ic z e n ie {com plete} (z ang. kom pletne), aby to wyrazić' M ożna to zilustrować, rozważając następujące dopuszczalne kom binacje podtypów n« rysunku (Kobieta, Pacjent, Pielęgniarz); (Mężczyzna, Fizjoterapeuta); (Kolue,a P a c je n t) oraz (Kobieta, Lekarz, Chirurg). K o m b in a c je takie ja k (Pacjent, LeVir') i (Mężczyzna, Lekarz, Pielęgniarz) są niepoprawne. Pierwszy zbiór jest mepoPfauny, ponieważ me zawiera typu z grupy wyróżnika Pleć {com plete}. Drugi zbiot
u u.m l«m.j
»
-
» ■» »
—
“
—
156 ,prayp-
pojęcia złożone
Uważam ze przydaje się ona w trakcie m odelow ania pojęciow ego. M o ż n a ją s to s o w a ć w mo l ou.mm spcc y fik a cy jn y m , ale trzeba dobrze znać techniki j e j im p le m e n ta c ji. Sztuka polega na tym , aby zaim plem entow ać j ą tak, aby w y g lą d a ła tak sam o jak tworzenie podklas z in terfejsu ja k o typu podstawowego i żeby u ż y tk o w n ik k la s y n ie b y ł w stanie zoriento wać się, której im plem entacji używ a. (N ie k tó re z te c h n ik są opisane u [18].) Jednak, ja k w większości spraw, w y b ó r za leży od o k o lic zn o ś c i i s a m o d z ie ln ie trzeba zdecydo wać o j e j użyciu. Przekształcenie w ie lo k ro tn e g o in te rfe js u dynamicznego na pojedyn C z y n a le ż y stosować w ie lo k ro tn ą klas y fika c ję d y n a m ic z n ą ?
czą im plem entację statyczną m oże być n iew arte zacho du.
dynamicznej dla zawodu osoby, który m oże ulec zm ianie. T o podejście m o że być właściwe, ale podtypy potrze b u ją dodatkow ych zachowań i nie p o w in n y być p ro s ty m i etykietami. W takich wy padkach często opłaca się utw orzenie o d d zie ln ej k la s y d la zawodu i połączenie z mą osoby asocjacją. N apisałem w zorzec a n a lity c z n y o n a z w ie R o l e (ang. Role Models). k tó ry zajm u je się tym zagadnieniem . In fo rm a c je o ty m w z o r c u i inne informacje uzu Rysunek 6.5 przedstawia p rzy kła d użycia k la s y fik a c ji
pełniające m o ją książkę [ 18] są na m oich stronach W W W .
K ie r o w n ik
Kobieta Zawód «dynamiczna»
Osoba T e c h n ik
Płeć I___ fcomplele,'
Sprzedawca
^
6 5
K' ^ a c , a
dvnamraia
D iagram y klas
6.5
Agregacja i zawieranie
jedną z m oich najw iększych zm ór |Cst „
S m u j a k a j e s . r ó i n i c a m i ^ ^ 8 ™ ;......... W czasach przed U M L - c m z w v u
.
K 0 € ' a tW
P
1
"
jes, agregacją. « co asocjacją. Nrgdv U W f e “k “ ! ™ * “ 0 * * m « * • . co „,ku lego k a żd y z p ro je k ta n tó w , ączkolwtck ° " ^ okr« ' ' ™ < * spójność, \ t „ y . jest ważna. T a k w ię c U M L zaw iera anrcaac' , t * P°""
'
Wlele “ W temat jak l 37)
(ang. com position). W za w ie ra n iu obiekt h S ! wers>? ™ a n ą zawieraniem jednej całości — co w ięc e j, oczekuje sie ^Zęsc'.ą moze należeć wyłącznie do Zwykle zakład a się, że usunięcie cnłnśr. Ł/;ęsci ,zyj,ą 1 umierają wraz z całością części. 11 " h uje kaskadowe usunięcie wszystkich n
To kaskadow e usuw anie ie
i t
‘J
s
z
ą
,
a , testtóż im p lik o w a n e p r z e i d o w ^ ttsunąc K l i e n t a
n a leży usunąć ież Z a m ó w ie n i, ,a zatem , Poiycjc z a m l i r m
Rysunek 6 .6 p o k a z u je p rzy k ła d y tych konstrukcji. Zaw ,eram i w k,en,„k" Punktu oznacza, ze d o w o ln a instancja P u n k tu może należeć albo do W ie lo k ą ta , albo do koła. ale m e do obu jednocześnie. Z drugiej strony instancja Stylu może być dzielona przez w iele W i e l o k ą t ó w i K o ! C o więcej, oznacza to, że usunięcie W ie lo k ą ta powoduje usunięcie sto w a rzy s zo n y ch z nim P u n k tó w , ale nie stowarzyszonego z nim Sty
lu. Zaw ieranie
W ie lo k ą t
A g reg acja
R ysunek 6.6. Agregacja i zawieranie
^
Ograniczenie, że
• .„-.¡nu/ić tvlko w jednym W ie lo ką cie albo K ole P u n k t n io ze się p »J J pomocą samych krotności. Oznacza
* tym sam ym czasie, n ie m o że bye tez, ze P u n k t jest o b ie k t e m - w a r t o s u ą ( rcterencję
i obiekty
d ostępne p rze z wartość ,
podrozdzial „O biekty dostępne przez M o ż n a dodać k ro tn o iić
n
.
pojęcia /łożone
• n
a.e zwykle się tym me prze,mmc C,
1 d o s iro n v -c z e ś c i re la c ji z a w ie ra n ia ,
rom b w yraża wszystko, co jest do vV^ r^ Rysunek 6 .7 p ok azu je je s z c z e je d n ą
” ^ cj ę d la z a w ie ra n ia . W t y m w y p a d k u część no W^ ^ c z c u . e -t . , P l.
jesl w kładana do całości. N a z w a klasy skiao
j
w ’
wana w postaci nazw a R o li: n a z w a li os .
m
g ó r n y m ro g u ,e>i ,
• w a r to ś c i m o ż n a r. w n :. ż uzyc
pisana krotność. D la prostej składow ej o a try b u tu .
Rysunek 6.7. A lte rn a tyw n a n o ta c ja d la z a w ie ra n ia
sytuacjach J o *. ¿>oc zawierania o i e r o ■ - .o o d o zawierania. . . co
R óżne notacje dla za w ie ra n ia stosuje się w r ó ż n y c h innych i praw dę p o w ie d z ia w s z y , lic zb a n o ta c ji d la U M L - a je s t ogrom na. N o ta c je te stosuje się w y łą c z n ie
c \
.
jo 1.-
cji.
6.6
Asocjacje i atrybuty pochodne
Asocjacje i atrybuty pochodne mogą być wyliczone z innych asoc* c at^butów u m ieszczo n ych na d ia g ra m ie klas. Na przykład a tr y b u t w iek osobv może bvc wyli czony, o ile zna się datę urodzenia tej osoby. K a ż d a p e rs p e k ty w a
S S t a e wska/un ns » je a
modelowania przynosi ze sob;\ inną in ie m re ti
W#żne zd* ni« « * “ z teco. ze element) między wart°ściami, a n.e są sm .eta. ea.en, iege.
rachunków z modelu s p e c y fik a c je ^ wieranie) [20j.
ucnie*
M odeU
6'8
P° k" UK hler'u '" ' c- nJ
Model używa wzorca Composite
ang
1
Diagramy klas-pojęcia złożone {saldo - suma wartości komponenty / hierarchy} *
ZaPISÓW |
Rachunek /7'in /saldo: Walutą
y
wartość:Waluta A try b u t p o c h o d n y
Asocjacja pochodna
Rachunek
Rachunek
s k ró c o n y
szczegółowy
Rola zapisów pochodzi z komponenty.zapisy
U waga
R ysunek 6.8. Asocjacje i atrybuty pochodne
NaJeży
zwrócić
u w a g ę na to, że:
•
O b ie k ty Z a p i s są d o w ią z a n e do rachunków szczegółowych.
•
Saldo ra c h u n k u je s t w y lic z a n e ja k o suma wartości zapisów.
•
Zapisy r a c h u n k u s k ró c o n e g o są zapisam i jeg o składowych, określonych rekurencyjnie. P oniew aż r y s u n e k 6 .8 je s t ilu s tra c ją m odelu specyfikacyjnego, to nie m ów i, że Ra
chunki m a ją p o la d o p r z e c h o w y w a n ia sald. Taka pamięć podręczna może rzeczywiś cie istnieć, a le je s t u k r y t a p rz e d k lie n ta m i klasy R a c h u n e k . Sposób, w j a k i e le m e n ty p o c h o d n e w y ra ż a ją ograniczenia, można pokazać na przy kładzie k la s y O k r e s ( z o b a c z ry s u n e k 6 .9 ).
O k re s p o c / 4 t e k : D u ta
komec.Data
R ysunek 6.9. Klasa O k re s
•hoeiaż sugeruje on, że początek i konKc ^ Jeśli jest to diagram specyltkaeyiny, ^ ' U) pr0gramista może zaimplcmeim, przechowywane, a czasTrwania jest . - ’ c h o w a n ie zewnętrzne. Na p i/y k l;u| wać tę klasę w dowolny sposob zac to j< . wyliczanie końca jest całkowicie d« przechowywanie początku i czasu trwania, a puszczalne. «^rtości pochodne są cenne przy oznac/a,mi Na diagramach implementacyjny^ Ł j awienia wydajności. O z n a c z a j i, pól używanych jako pamięć: podręczna. zorientować się, co rob. pamięć pod pola . zapisując sposób wyhczen.a es * j cache (z ang pamięć podręczręczna. Często akcentuję to w kodzie, u/y ‘ .M na) w nazwie (na przykład balanceCache). pochodnych, aby pamięta Na diagramach pojęciowych stosuję znaczn f i_c_Artnn,: 7 i gdzie znajdują się elementy pochodne, i aby potwierdzić z ekspcilami danej dziedżiny, że rzeczywiście one istnieją. Mogą one byc potem skorelowane z ich odpowiednikami na diagramach specyfikacyjnych.
6.7
Interfejsy i klasy abstrakcyjne
Jedną z zalet projektowania obiektowego jest to, że można zmieniać intei tejsy klas niezależnie od ich implementacji. Leży to u źródeł mocy projektowania obiektowego Niestety, niewielu potrafi z tego skorzystać. Języki programowania mają jeden mechanizm — klasę — zawierający zarazem i interfejs, i implementację. Gdy tworzy się podklasę, dziedziczy się oba te elementy Rzadko stosuje się interfejs jako osobny mechanizm, a szkoda. Czysty interfejs, taki jak w Javie, jest klasą bez implementacji i w związku z tym ma deklaracje operacji, ale nie zawiera ciał metod i pól. Interfejsy są często deklaro wane za pomocą klas abstrakcyjnych. Klasy takie mogą dostarczyć część implementa cji, ale często ich podstawowym zadaniem jest deklaracja interfejsu. Polega to na tym, że w trakcie tworzenia podklasy klasy abstrakcyjnej — lub stosując jakiś inny mecha nizm — zostanie podana implementacja, ale klienci nigdy je j nie ujrzą, bo dla nich wi doczny będzie tylko interfejs. Edytor tekstów przedstawiony na rysunku 6.10 jest tego typow ym przykładem. Aby uzyskać przenośność edytora, została zdefiniowana niezależna od platfornw sprzętowej klasa abstrakcyjna Okno. Klasa ta nie zawiera cial metod — definiuje ona jedyme interfejs dla edytora tekstów. W konkretnym wypadku można użyć zależno,h od sprzętu podklas tej klasy. w U M L -u nazwy klas lub metod abstrakcyjnych pisze się kursywą. Mpżna też sto-
r Zeme i t r ' " ,Z ang- »»«rakcyjne) - również zamiast zap.su n a m recznie kursów,1 ?ed * S,0SU^ °i!rai>iczenie {abstract}, bo nie potrafię pisa,’ odZ
Z
kursywę
7
“ZyWaJąC nar2?dzia d0 'w orzenia diagram ów , wolę
stosować
m ech an izm ^n terfeis^aY n m n j'!' ‘mplemen,acj'- ,ava daje do dyspozycji saniois»" implementacje wszystkich j ego ^
^
* W‘b a ’ C /y klasa 8 ° implementująca zawiera
O k n o >v W i n d o w s
pierwszyPlan() ostatniPlanO
O kno { abstract,1
Edytor m tekstów
PierwszyP la n 0
pierwszyPlan()
ostatniPlanQ
ostatniPlanO
Zależność O k n o w M a c ln to s h u
pierwszyPlan() ostatniPlanO
R ysunek 6.10. Okno jako klasa abstrakcyjna
rysunku 6.11 w id a ć InputStream, Datalnput. DatalnputStream1 (zdefiniowane w standardowym p a k ie c ie j a v a . i o ) . InputStream jest klasą abstrakcyjną a Data Input je st interfejsem. Na
« in te rfac e » In p u tS tre a m
CzytelnikZamówień
Datalnput
A Zależność
U ogó lnienie
DatalnputStream
Realizacja
R ysunek 6
T . ngielskiego
.11. In te rfe js y I klasy a b s tra kcyjn e -
•
i .ń wejściowy, dane wejściowe, strumień danych
o d p o w ie d n io : strum ień
•owych (p rz y p .
tłu m ).
przykład z Javy
M L w k ro p e lc e
D a ta ln p u t, jak . rJ n Z u
D a ta in p u tS tre a m ■
R ealizacjaJest c e lo w o P
p le m e n tu je z a c h o w a n ie podane
prz«
^
ż ' jed n a klas,
f j e s f d o p u s z c z a l n e , a b y j e d n a k la s a im p le.
^
dm gth
musl byc zgodna z
fejTem^iTnTemusi korzys'ać z dzie^ ‘C“ "ńtey między realizacją a tworzeniem podW modelu s p e c y fik a c y jn y m me ma rozn • n.it iIh d iiI to zuleznosc. W tym P o w ią z a n ie m ię d z y C z y t e l n i k i e m / . a n - ó n j c " a ^ s ję t 0 CzytelnikZaw y p a d k u z a le ż n o ś ć o k re ś la , ze je ś li in te r r h ^ projektowania j e s t o g ra n ic ze n ie mówień r ó w n ie ż m o ż e u le c z m ia n ie . Jeo y maksymalnłe efekty z m ia n . (W ię c e j lic z b y z a le ż n o ś c i d o m in im u m , a b y o g c o za leżn o ściach w ro zd zia le 7 .) 7w ie z le is z ą R y s u n e k 6 .1 2 p rze d s ta w ia a lb .rn a ty w n ą , * * * ^
notację.
T u t a j in te r fe js y m r
m
reth
p re ze n to w a n e za p o m o c ą m a ły c h k o łe k (c zę sto z w a n y z klas j e im p le m e n tu ją c y c h . Interfejs
Datalnput
Z a leżn o ś ć
InputStrcam R ysunek 6.12. N o ta c ja „liz a k o w a " d la in te r fe js ó w
Stosowanie „lizaków" zaciera różnicę między realizacją interfejsu a podklasą klass abstrakcyjnej. Mtmo że notacja jest bardziej zwięzła, to me można pokazać tu operacji interfejsu ani żadnych relacji uogólnień między interfejsami Klasy abstrakcyjne i interfejsy są podobne, ale jest między n im i pewna różnica d
■ "
&
!
n ektónfchTiod
niektórych metod -
“
T . T ' Jcfini0wanie in< ^ «
i przełożenie ,eno „npletnettt.t-
r yjne UmoŻ,iwi* « j ednak do .mplementac interfejs wymusza odłożenie implementacji wszystkich m e t o d .
v M 'ie
p
r z
y
e
z
w a rto ś ć informuje, że m ają one „ uJe się, że tożsamość ,est ważna kila
---------------------
dOS,ęP" yCh ^ ' * " » < * . a niezbyt is,„t„ , , Obiekty dostępne p rz e z referen cję to na „
dla
D iagram y kia
d o j n y c h przez
ponieważ zwykle żądamy, aby r L * ,“ K i i , , , . Tutaj to żs » » * j « e2 jeden obiekt systemowy. Każdy obiekt o d t™ ,^ ' kfcm byl prezentowany dae 10 robił przez relerencję lub wskaźnik nM Ją°y sl? do obieklu Klienta besję Jo Klienta będą się odwoływały do teCo'sa™ e "'s2ys,kl° '.btekry odwołujące sób ja k ie k o lw ie k zmiany Klienta będą widzi-,„ , systemowego. W len spoJeśli istnieją dwa odwołania do Klienta u ° ?rZezjeg0 uży*owników. tego samego obiektu, to zwykle sprawdza i ! ? , sprawdz,ć>czy są to odwołania do kopii obiektu może być zabronione. Jeśli ies! l y(;Znosc lych odwołań1. Tworzenie ¿20 ważna,
kład w celach a r c h iw iz a c y jn y c h lub r e p l ik a c j i p r / e / ue Y ’ ‘ ^ ^ kopii o b ie k tó w je s t d o p u s z c z a ln e to trzeb-, m komputerową Jeśli istnienie O biekty d o s tę p n e p rz e z wnrtość „biektow d o s tę p n y c h Pn j z w artość reprezentuje ten san, „b.ekt świata ™
,s T e l
Na pnrykład r z e c z ą z w y k ł ą są setki o b ie k tó w reprezentujących date , stycznia 1909 ro ku. W szystko to są k o p ie z a m ie n n e . N o w e daty s , tworzone i usuwane bardzo często
Jeśli są d w ie
d a ty
i
trze b a sp raw d zić, czy są takie same, to nie sprawdza się ich toż
samości, ale w a rto ś c i, k tó re one reprezentują. Oznacza to zw ykle konieczność napisa nia operatora ró w n o ś c i, k tó ry dla dat badałby równość wartości reprezentujących rok, miesiąc i d z ie ń ( lu b c z e g o k o lw ie k innego — zależnie od reprezentacji wewnętrznej daty')- Z w y k l e każdy' o b ie k t o d w o łu ją c y się do 1 stycznia 1999 roku ma swój własny obiekt re p re z e n tu ją c y tę datę, ale m o żn a też obiekty daty współdzielić. O b i e k t y d o s tę p n e p rz e z w artość p o w in n y pozostawać niezmienne (powinny być z a m ro ż o n e , z o b a c z p o d r o z d z ia ł „ Z a m ro ż e n ie ” na następnej stronie). Innymi słowy', nie p o w in n a b y ć m o ż l i w a z m ia n a o b ie k tu 1 stycznia 1999 roku w ten sam obiekt 2 stycz nia 1 9 9 9 ro k u . N a l e ż y u tw o r z y ć n o w y obiekt 2 stycznia 1999 roku i dowiązać go do
jego u ż y tk o w n ik a , p o n ie w a ż g d y b y data była współdzielona, to łatwo można by w nie oczekiwany s posó b z a k t u a liz o w a ć datę innego obiektu. Kiedyś r ó ż n ic a m ię d z y o b ie k ta m i dostępnym i przez referencję a obiektami dostęp nym, pnrez w a r to ś ć b y ła w y ra ź n ie js z a . O b ie k ty dostępne przez wartość były wartoteam, w b u d o w a n y m , s y s te m u (y p ó w . T e ra z system typów ™ klasy, a co za t y m
idzie,
c a łe to
wierania
może byc
w y k o r z y s ta n a
wartość. R o z ró ż n ia n ie m i ę d z y o b ie k ta m i Jest istotne
w
“ “ £
przedstawienia o b i e k t ó w d o s tę p n y ch prac pr/edstawierna o b i e k t ó w d o s tę p n y c
™
^
p .
d .
ow anja obick ió w dostępnych przez
I
dostępny '
m o d e l o w a n i u p o ję c io w y m .
asocjacji Rów nież relacja za-
•
w-irtość i przez referencje nie ( 0 moj c spowodować zam ie-
.^ c
* nreZcntow ania relacji m iędzy obiekta-
«anie p rzy p r z y p i s y w a n iu * s ‘ s(ronic m> stosuję asocjację, to z w y k l e k ro i I . M l oznaczam , o ile nie m a innej r e g u ły dotyczą j BUnier k o le jn y ), gwiazdką (*)-
o b ic ktu
u żytko w n ika - - w arto-
unikatow ości obiektu (na pr/>
O z n a c z y p o ró w n u je się w s k a ź n ik i lub re le re n c jc (p r /y f
>u
6.9
■ łnv,rh stron asocjacji Zbiory dla wielokro
•• . której «¿me ograniczenie kroim.se, ,es, Stronawielokrotna asocjacji to ^ traktujemy jak zbiory ( łbu-k.y niż 1 (na przykład •) Zwykle « « W żłdną relacją i nie występ,ną w stronie wielokrotnej nie są u p o rz ą :en;^ te z a ło ż e n ia , d o łą c z a ją c o d p n w ia lm c Więcej niż jeden raz. Można jednak zmier ograniczenia. n r v i d k o w a n v ) o z n a c z a , że obiekty po tci Mmine O g r a n ic z e n ie {o rd e re d } ( z ang- up
znaczy
a so cjacji w y s tę p u ją w ja k im ś p o rz ą u m o g ą pojawić się najwyżej raz na liście.
je
1
o g ra m c z e n ia {h ie ra rc h y , (z : ang_ c h ię , i o g ra n ic z e n ia {d a g } , a b y p o k a z
lis tę . O b i e k t y te il.d q
p o w i e d z i e ć , z e o b ie k t y mog.,
O g r a n ic z e n ia {b a g } ( z ang. w o r e k ) s t o s u je ^ ę ^ p o ja w ić się w z b io rz e w ię c e j n iz
tworzą
.
^
u p o rz ą d k (n v a n e
pokazać, że obiekty
lJ /y u ;m , ^ t w o r z ą hicrar-
’t W o r z ą a c y k l i c z n y g r a f s k ie r o w a n y (ang.
d ire c te d a c y c lic g raph).
6.10
Zamrożenie które U M L d e f i n i u j e j a k o p i / e / n a z a u w a ż y ł e m , że można je r ó w n i e ż zastosow ać
Z a m r o ż e n ie (an g. fro z e n ) je s t to o g r a n ic z e n ie , c z o n e d l a a tr y b u tó w lu b a s o c ja c ji, a le
d o klas. K i e d y u ż y w o się go do a try b u tu lu b a s o c ja c ji,
oznacza to, ż i w aitosc a ti^ b u t u lub a s o c ja c ji n ie m o ż e się z m ie n ić z a ż y c ia o b ie k t u źródła tego atiybutu lub asocjacji W a r to ś ć ta m u s i b y ć ustalo n a w tr a k c ie t w o r z e n i a obiektu i potem nie m o ż e się ju ż z m ie n ić . W a rto ś ć p o c z ą tk o w a m o ż e b y ć pusta. Oczywiście, jeśli jest pusta w trakcie tw o r z e n ia o b ie k tu , to p o z o s ta n ie ta k a , d o p ó k i te n o b i e k t żyje. W ynika s tą d . ze z w y k le k o n s tr u k to r o b ie k tu m a a rg u m e n t d la tej w a r to ś c i i że nie ma operacji, która b y tę w ar tość a k t u a liz o w a ła . Jeśli to o g r a n ic z e n ie je s t z a s to s o w a n e d o k la s y ,
oznacza to,
ż e w s z y s t k i e a trv b u t\
tej k la s y i a s o c ja c je w y c h o d z ą c e z n ie j s ą z a m r o ż o n e .
tylko-do-odczytu ( a n g . re a d only). m o ż e b y ć zmieniona b e z p o ś r e d n i o , ale m o in n e j w a r t o ś c i . N a przykład j e ś l i o s o b a ma m o ż e b y ć atrybutem tylko do o d c z y t u , ale
Z a m r o ż e n i e n ie je s t t y m s a m y m co o g r a n ic z e n ie T y l k o d o o d c z y tu o z n a c z a , że w a rto ś ć n ie ż e u le c z m i a n ie w w y n ik u z m i a n y p e w n e j p r z y p is a n ą d a tę u r o d z e n ia i w i e k , to w i e k n ie m o ż e b y ć z a m r o ż o n y .
Zamrożenie oznaczam ograniczeniem { f r o z e n } , a wartości tylko do odczytu ograni czeniem { r e a d - o n ly } . Należy zauważyć, że { r e a d - o n l y } nie jest określone w standar dzie UML-a. Zamrażając daną wartość, należy zachować ostrożność. Jeśli na przykład zamro/i się atrybut „data urodzenia”, to w razie wystąpienia błędu nie będzie można go popia-
WIC.
' Czyi. tworzą tzw. zbiór z powtórzeniami lub m u ltiz b ió r (przyp. tłu m ).
Ł>iagramy klas
6.11
pojęć la złożone
Klasyfikacja i uogólnienie
C z ę s to S łyszę lu d z i m ó w ią c y c h Ostrzegam przed tym spusobem
„,oze na.ec wiele znaczeń.
7_ , pochodny
samo co rc|
tma- ' ™»lem jest w lyn, że
£
W a rto r o z w a z y c n a s tę p u ją c e z d a n ia -
jest Owczarkiem. Owczarek jest Psem. Psy są Zwierzętami. Owczarek to Rasa. Psy są Gatunkiem.
|. A z o r
2. 3. 4. 5.
Teraz można składać te zdani.. i / . tA zor jest Psem” ; 2. i 3. razem dają „Owczarki !!-?/""" /d a n 'e !. ' 2 ’ t0 otrzy™a się „Azoi „A zor jest Zwierzęciem” Na razie w J u wlclA ‘tami . Natomiast I., 2 . i 3. dają daj i Rasa” . Złożenie zdania 2. i 5. t o ^ O w S ^ s a ^ ï ^ ' ^ M “ ^ U 4 " A zor to Dlaczego można składać tylko niektóre zdańhTniT , naJlePiej kacja (obiekt A z o r je s t in stancją typu O w c z u e k) a c? /C C/f f ° ' IMch t0 klt,syft' i • *. «. i i 3 część to unuo nieme (tvn O w czarek jest typem pochodnym typu Pies). Uogólnienie jest przechodnie, klasyfikacja^me kllęjności0 ^ 0 yhkaC'ę Z U0 KÓłnieniem, ale nie można tego zrobić w odwrotnej Kładę na to nacisk, p o n ie w a ż n a le ż y z n ie zw y k łą ostrożnością podchodzić do relacji „jest . Jej u ż y c ie m o ż e d o p ro w ad zić do niewłaściwego zastosowania typów po chodnych i zamieszania w zo b o w ią za n ia c h klas. Lepszym i testami na poprawność ty pów pochodnych w tym w y p a d k u b y ły b y zdania „Psy są rodzajem Zw ierząt" i „Każda instancja Owczarka jest instancją Psa” . Rozdział 6
6.12
Asocjacje kwalifikowane
A s o c ja c ja k w a lif ik o w a n a je s t U M L - o w y m odpow iednikiem pojęcia tablic asocja cyjnych, m a p lu b s ło w n ik ó w . R y s u n e k 6 13 p r z e d s ta w ia p rz y k ła d asocjacji stosującej kw alifikację Z a m ó w ie n ie -
-Pozycja z a m ó w i e n i a . K w a lif ik a c ja m ó w i, że dla Pozycja z a m ó w i e n i a d la k a ż d e j instancji I o w a r u .
Z a m ó w ie n ia może istnieć jedna
P ozycja z a m ó w ie n ia »..1 ilość: Liczba
Zamówienie
Towar
Pozycja
Rysunek 6 13. Asocjacja kwalifikowana
05
'M L w krop elce
,
mów d w ó c h Pozycji z a m ó w ie n ia d la le t ia asocjacja kwalifikowana implikuje K o n c e p c y jn ie p r /y k la d
.en
,
*-
w ra m a c h
Z a m ó w ie n ia
^
mc
„
z p u n k .« w i e r n a
w stylu:
class Z a m ó w ie n ie { , p „ , vn e ( T o w a r t o w a r ) ; public P ° r y c la Z a m o w ,e n ia p o b i e r z P o z y j e (r ^ p u b lic v o id d o d a jP o z y c ję ( L ic
' ¡„„¡a wvmaga Tow aru jako argumentu. Krotnuse i Zatem dostęp do Pozycji zamówi Pozycja zam ó w ien ia, g w ia z d k a ( * , o zn a c za , że d la k a ż d e g o T o w a r u z a m 6 w i e n i a dla k a ż d e g o T o w a r u , ale że o z n a c z a ła b y , że m o ż e istnieć w ie le P ^ ę j i
T o w a rc m .
do przechowywania
dostęp do Pozycji
z a m ó w ie n i a je s na . UZy Cje Z p u n k tu w id z e n ia im p le m e n ta c ji s u g e ru je to u / y
p o /y qi i zycj,
ta b lic y a s o c ja c y jn e j lub p o d o b n e j s tru k tu ry t a n y c
class Z a m ó w ie n ie { p riv a te M a p a _ p o zy cje ;
W c z e n ia
stosuję tylko p o to , aby w y r a z i e ograni t y l k o j e d n a Pozycja zam ówienia na dany
m o d e lo w a n iu p o ję c io w y m k w a lif ik a c ję
w
T o w a r".
s ty lu
W
„w
Z a m ó w ie n iu m oże być
zaznaczenia w in te rfe js ie do użyciem kwalitikow anej i z w y
m o d e la c h s p e c y f i k a c y j n y c h u ż y w a m jej d o
stępu p rz e z k lu c z . N i e m a m p r o b le m u z je d n o c z e s n y m k łe j a s o c ja c ji, je ś li re p re z e n tu ją w ła ś c iw y in te rfe js .
W
aby zaznaczyć danych.
m o d e la c h im p le m e n ta c y jn y c h stosuję k w a l i f i k a c j ę ,
s ło w n ik ó w i ta b lic a s o c ja c y jn y c h lu b p o d o b n y c h s t r u k t u r
6.13
u ż y c ie map,
Klasy asocjacyjne
Klasy asocjacyjne umożliwiają dodanie atrybutów, operacji i innych elementów do asocjacji, jak pokazano na rysunku 6 .14. Nd rysunku widać, żc Osoba może pracować w jednym Przedsiębiorstw ie Dodíitkowo jest potrzebne przechowywanie informacji o okresie zatrudnienia każdej Osobv w każdym z Przedsiębiorstw. Można to zrobić, dodając atrybut »kres do asocjacji. M ożna by leż dodać ten atri buí do klasy Osoba, ale je « to lak naprawdę informacja określająca stosunek Osoby Rv^nck ó°,rr t ’ 0,7 S,ę Zmieni’ jeŚli zmieni si* pracodawca Osoby n ie 7 k l ^ ¿ r u ^ t ,M JeJCSZCZeJef n SP° SÓb rePrezcntac,i tej mfbrmacn ucA»k-
zw rócić
na ,0- ,ak zlT ;
krotny koniec asocjacji po strome klasv 7 » i Z.P ,erwotnuJ asocjacji ma icdiuchwili rolą pochodną ale nie iast k Z atru d n ien ie. Rola Pracodaw ca ¡esl « 11 laka je « k o r ® tego. wnosi dodatkowe ograniczenie nej między dowolnymi dwoma
przykładem.
‘
,MmeniJ klas asocjacyjnych1' Klasa asociacM"'1 n!()/c 'stn,e¿ tylko jedna instancja klasy asocf‘lNl sektam i połączonymi asocjacją. W arto posłu/W ^
O soba
Z a tru d n ie n ie
Klasa asocjacyjna
°k res :za k re s D a t
R ysunek 6.14. Klasa asocjacyjna
R y s u n e k 6.15. Awansowanie klasy asocjacyjnej na samoistną klasę
Na rysunku 6 . 1 6 p r z e d s ta w io n o d w a diagram y. Są one bardzo podobne. Można susobiejednak wyobrazić s y tu a c ję , w k tó re j Osoba pracuje dla tego samego Przedsiębior stwa w różnym czasie — tzn. p ra c o w n ik odchodzi, a potem wraca do firmy. Oznacza to, że Osoba z czasem mogłaby m ie ć k ilk a asocjacji Zatrudnienie z Przedsiębior stwem. Jeśli chodzi o klasy Osoba i Umiejętności, to trudno by znaleźć powód, dla czego Osoba mogłaby mieć kilka p o z io m ó w Kwalifikacji dla tej samej Umiejętności — w istocie m o ż n a b y to tr a k to w a ć j a k o błąd.
W UML-u tylko ten drugi w y p a d e k jest po p raw n y. D la każdej kom binacji O soby 1Umiejętności może istnieć tylko jeden poziom K w a l if ik a c j i G ó rn y d ia g r a m na r y s u n k u 6 . 1 6 nic daje Osobie możliwości drag,ego etatu (Zatrudnienia) w t y m s a m y m Przedsiębiorstwie. Jeśli jes, potrzebna taka mozltwosc, 'o klasa Z a t r u d n ie n i e m u s , b y ć s a m o is tn ą k ia s ą .w s ty lu te, z .r ^ u n k u 6 J W p rz e s z ło ś c i w i e l e o s ó b r o b iło ra ź n e za o ze m a na
l y |ko unikatow e
:Xinej w ty c h o k o lic z n o ś c ia c h . N l e k j o r / y 'd aj, ,,dy ¡n n j „ je p rz y jm o w a li takich ‘»mbinacje, t a k ie j a k p o z i o m K w a l i f i k a c j i , podczas g d y 1 3graniczeń.
,
.
W ie lu w o g ó le o t y m n ie m y ś la ło i w je ny ,ie S to s u ją c UM L, należy p a m ię t a ć , ż e to o g r
ro b iło założenia, a w innych .
istnieje.
I MI w kropelce
Przedsiębiorstwo
* Osoba
Zatrudnienie okres: zakresDat
Umiejętności
________________________ i ________________________
K w a lifik a c je p o zio m
Rysunek 6.16. A s p e k ty klas a s o c ja c y jn y c h
historycz n e j, ta k ie j j a k na p rz y k ła d w o m ó w io n y m w y p a d k u Z a t r u d n i e n i a Pomocnym wzor cem jest tu o d w z o ro w a n ie h isto ryczn e (ang. H is to r ie M a p p i n g ) o p is a n e w [1 9 ]. Wzor C zęsto tego rodzaju ko n stru kcja p o ja w ia się w m o d e l o w a n i u i n f o r m a c ji
ca tego m o ż n a użyć, definiu jąc stereotyp « h is to r y » ( z o b a c z r y s u n e k 6 . 1 7 ) .
R ysunek 6.17 . S te re o ty p « h isto ry» dla asocjacj
Model ten mówi, że w dowolnym czasie Osoba może pracować t y l k o w jedn P r z e d s ię b io r s t w ie W miarę upływu czasu Osoba może zmieniać p r a c ę i praco' w kilku Przedsiębiorstwach. Sugeruje to podany interfejs. class Osoba { //pobierz bieżącego pracodawcę Przedsiębiorstwo pobierzPracodawcę(); //pracodawca w danym czasie Przedsiębiorstwo pobierzPracodawcę(Data); vo!d opuićP^codawcę(D«a^dauZmiany);n° W',^ raCOC'aWCa ^
dataZn’ ,any’'
Diagramy klas - pojęcia złożone
Stereotyp
« h is to ry » n ie je s t częścią U M t
o0vvodów Po p ie rw s ze , je st to notacja k tń r*
3'e WsP°nunam o nim
U P° d m g ie ’ P° ka2M je- j »k 614
W
* *
a
• u
w“
K lasy P a ra m e try z o w a ln e
Kilka j ę z y k ó w , a w szczeg ó ln o ści C + + 7 albo wzorca (ang. te m p la te ). ’ aw,era P°j { void w s t a w ( T n o w y E le m e n t); void u s u ń (T e le m e n t);
t e T k o ^ r m y ? h T l e m e m ó r yS' aJ,C * ° gÓI'KJ defi" iCji' " * 0 ,Z y i klasy zb,orcze bar' Z b ió r < P r a c o w n ik > z b ió r P r a c o w n ik ó w ; Klasę p a ra m e try z o w a ln ą d e k la ru je się w U M L - u , używając notacji przedstawionej na rysunku 6 . 18.
Z b ió r
Klasa w z o rc o w a
P a ra m e tr w z o rc a
w s ta w (T ) u s u ń (T )
R y su n e k 6.18. Klasa param etryzow alna
T na rysunku zastępuje p a r a m e tr ty p u . ( M o z ę byc ich ^ im jak Smalltalk, to z a g a d n ie n ie m e istnieje, a w y
^ L to -
S° ^ nie'. . • t.kiP iak na oreykład Z b ió r < P r a c o w n ik > , jest naUżycie klasy p a r a m e t r y z o w a l n e j , takie j 1 elementem związanym. dwa by pierwszy jesl odbiciem Element związany można przedstawi *yntaktyki C++ (zobacz rysunek 6 .19).
nii spotyka się również nazwę
s z a b lo n
(przyp- tłum.). 99
Z b ió r < P r a c o w n ik >
ii
.i-
-------
R ysunek 6.19. E lem ent z w ią z a n y (p ie rw s z y s p o s ó b )
N o ta c ja a lte rn a ty w n a (z o b a c z ry s u n e k 6 . 2 0 ) a k c e n tu je z w i ą z e k / w z o r c e m i u m o ż l i w i a z m ia n ę e le m e n tu z w ią z a n e g o .
Klasa w zorcow a
W ią z a n ie d la p a ra m e tru Elem ent związany
R ysunek 6.20 . E le m e n t z w ią z a n y (d ru g i s p o s ó b )
Stereotyp «bind» (z ang. wiązanie) jest stereotypem relacji uszczegółow iania, rela cja ta wskazuje, że ZbiórPracowników będzie zgodny z interfejsem Z b io ru W termi nach poziomu specyfikacji ZbiórPracowników jest typem pochodnym Z b io ru Jest to inny sposób definiowania zbiorów dla elementów konkretnych typów zamiast de klaracji wszystkich koniecznych podtypów. Element związany to jednak nie to samo co typ pochodny. Nie wolno uzupełniać elementu związanego całkowicie określonego przez jego wzorzec o dodatkowe ele menty; można dodawać tylko informacje ograniczające. Jeśli trzeba dodać d o d a tk o w e elementy, to należy utworzyć typ pochodny.
Klasy parametry/owalne umożliwiają używanie mechanizmów typów p o c h o d n y 1 Pisząc ciało wzorca klasy, można wywoływać operacje parametrów Kiedy pomei deklaruje się element związany, kompilator próbuje sprawdzić, czy dostarczam p>l! 1 metr ma operacje wymagane przez wzorzec Komniht! ™ec^an,/™ pochodnych, bo nie trzeba definiować typu parametm Kompilator sam próbuje ustalić, czy wiązanie jc.sl możliwe, patrząc na kod żródlo«'
---------------------------------------------- d ia g r a m )
^orca. Jest to języka t + +
b a rd z o w a ż n e p r z y U/VA. s ^ hr iZmU klas P ^ e t r y z o w a l n y c h k la s ty c h m o ż n a też u ż y w a ć do m m i 8 Slandard Tem plate L ib ra ry)
Stosowan,e klas parametryzowalnych ych c,ekawych trików 0„e spowodować eksplozję kodu ¿ ró d lo w T g o T rw ’’^ ' ~ "* -togą „adko stosuję klasy p a r a m e tr y z o w a ln c , ,0 „ m odel° ™ " » ' pojęciow ym wania zbiorow wynikających z asocjacii n S leg0' że sluż:>onc d° ' » ° d
klasy parametryzowalne tylko
w te d y jeśli s, ^
program ow ania, k tó r e g o u ż y w a m
6.15
Cyjnym 1 im plem entacyjnym stosuję ezposredni°'m p le m e n to w a ln e w ję zy k u
Z a s ię g w id o c z n o ś c i
Muszę przyznać,
ze m a m trochę o b a w , je ś li chodzi o ten podrozdział
w d o c z n o s c i je s t to jeden z tych tem atów , które w zasadzie są proste, ale tylko P a r n i e . P ro s ta za s a d a je s t taka, że każda klasa ma składowe publiczne i p ry
Składowe p u b lic z n e m o g ą być u ż y w a n e przez dow olną inną klasę, natomiast składowe prywatne m o g ą b y c u ż y w a n e je d y n ie przez klasę ich właściciela. Niestety, każdy język m a w ła s n e re g u ły . M i m o że w w ie lu ję zy k a c h używ a się term inów takich jak „publiczny , „ p r y w a t n y i „ c h ro n io n y \ to są im nadawane różne znaczenia. R ó ż nice znaczeniowe są m a łe , ale w p r o w a d z a ją zamieszanie, szczególnie jeśli używ a się watne.
kilku ję zy k ó w ' p r o g r a m o w a n ia .
UML próbuje poradzić sobie z ty m problem em . W U M L - u można etykietować k a ż dy atrybut lub operację w s k a ź n ik ie m zasięgu widoczności. M o żn a stosować dow olny znacznik — jego semantyka je s t zależn e od ję z y k a programowania. N iem niej U M L zapewnia specyfikatory dostępu skróty dla określenia zasięgu widoczności: + (p u b lic z ny), - (prywatny) i # (chroniony). Mam ochotę na tym p o p rze s tać , ale niestety, ludzie rysują diagramy stosujące z a sięg widoczności w s z c z e g ó ln y sposób. Z a te m aby naprawdę zrozumieć niektóre z częstych różnic istniejących m ię d z y m o d e la m i, należy zrozum ieć reguły stosowania zasięgu w id o czn o ści w r ó ż n y c h ję z y k a c h program ow ania. W arto z a c z ą ć
od
C + + , p o n ie w a ż jest on p odstaw ą standardowego użycia zasięgu
widoczności w UML-u. . , , . • Składowa publiczna jest widoczna wszędzie w programie , może byc wywołana .
używana lylko przez klasę, w kJórej zosJala zdefi-
• S Z a chroniona może być uży.a przez klasę, k.óra ją definiuje albo pizez klasę pochodną lej klasy. indywidualny, a obiekt MarPrzykladowo klasa Klient ma klasę pj c , może „żywać dowolnej publicz k i jest in s ta n c ją klasy Klient indyw,dualny. Maren |— I WZOrców w C++: dla każdego typu użytego Jcst to spowodowane sposobem inlP*cn|lcnl?.^n:a ^odii źródłowego (przyp- tłum.), argument wzorca jest tworzona osobna kopia 101
U M L w kropelce , . . łtt c v , te m u nej s k ła d o w e j k a ż d e g o o b ie k tu sys d o w e j p r y w a tn e j k la s y K l,e n t in d y s k ła d o w e j z d e fin io w a n e j w K h e n c ie ,
M a r c i n m o ż e także używać d o w o ln e , skla^ może używać ż a d n e j p ry w a tn e , . ' n a t o m iast u ż y w a ć c h r o n io n y c h K . ie n ta i n d y w i d u a l n e g o .
w ych K lie n ta i ch ro n io n ych sk a o w y c ^ _ ^ W
p r y w a tn e , a w s z y s t k i e o p e ra c je pu.
0 Co tP .m s sa am me eg co co w w C++. C++. W W systemach s y s te m a c h sm sm alialinie oznacza gfc ^ sw woojje o b ie k tu -— niezależnie niezależna m e oznaczat ^ e gg o obiektu
S m a llta lk u w s z y s tk ie a try
bliczne. Jednak b lic z n e . J ed n ak „„prywatne p r y w a tn e
^
skład.,-
ty la
dowolneg [> d v w id „ . dowo'neg kliencie, czy też w Kliencie Kliencie in tndywiduod uu teco icgu, czv atrybut duyuui ten .tu został zdefiniowany \ S m a l l t a l k u test p o d o b n y d o „ c h ro n io alnym. Zatem w pewnym sensie „prywatny w b m am aiK uj F y
ttalkowych a lk o w y c h M a r c in m a do stęp d o Marctn ma dostęp do
nego” w C++. Niestety, nie jest to takie proste. . Na przykład, wracając do C++, można założyć, ze jest jeszcze jedna instancja Klienta indywidualnego o nazwie Krzysztol. K r z y s z t o ł m a 0St?P 0 ° ^ ° neJ s + dowej Marcina, która została zdefiniowana j a k o s k ła d o w a k la s y le n t mc \ w i ua ny, niezależnie od tego, czy jest publiczna, prywatna, czy te ż c h r o n i o n a . K r z y s z t o l m a też dostęp do dowolnej składowej publicznej i c h r o n io n e j M a i c i n a , k t ó i a byda z d e fin io wana w Kliencie. Jednak w Smalltalku Krzysztof n ie m a d o s tę p u d o p r y w a t n y c h a tiy butów Marcina, lecz jedynie do jego operacji p u b lic z n y c h . W C++ dostęp do składowych innych obiektów tej samej k la s y j e s t ta k i sam jak dostęp do własnych składowych. W Smalltalku nie m a z n a c z e n i a , c z y o b i e k t jest tej samej klasy, czy nie — istnieje dostęp tylko do jego s k ł a d o w y c h p u b l i c z n y c h . Java jest podobna do C++, ponieważ oferuje s w o b o d n y d o s tę p d o s k ł a d o w y c h in nych obiektów tej samej klasy. Java dodaje r ó w n i e ż je s z c z e j e d e n o b s z a r z a s ię g u wi doczności zwany pakietem. Składowa o zasięgu w id o c z n o ś c i p a k i e t u j e s t d o s tę p n a dla instancji klas zdefiniowanych w tym pakiecie. Jednak w Javie jest nieco inaczej zdefiniowany d o s tę p c h r o n i o n y . S k ł a d o w a chro niona jest dostępna z klas pochodnych, ale również je s t d o s t ę p n a z d o w o l n e j innej klasy tego samego pakietu co klasa, w której ta s k ła d o w a je s t z d e f i n i o w a n a . O zn a c za to, że w Javie bycie chronionym jest bardziej publiczne n i ż z a s i ę g p a k i e t u . Ja\a umożliwia także oznaczenie klas jako dostępne publicznie lub w pakiecie Publiczne składowe klasy publicznej mogą być używane przez dowolną klasę importu jącą pakiet do ktorego ta klasa należy. Klasa o zasięgu pakietu może bvć tylko użvwana przez klasy tego pakietu. C++ daje jeszcze jedną możliwość. Metoda lub klasa C++ może być oznaczona jako. przyjaae (ang. fr,end) tnnej klasy. Przyjaciel ma pełny dostęp do wszystktch składowych klasy — stad zdanie* W C++ i . \ nych części” ” Przyjaciele mogą d o t y k a ć s w o ic h p ry w a tw a n t ^ k ló ^ je s r u ż y w a n y . ^ e ś i^ p r a a ii^ s ie * 1' 02^ S K' ° S° WaĆ re g u ly ięzyka Pro8 ram0;
być oslrożnym w kwestii semantyki znaczników ° C5™ modelem w U M L -u , nalo/' może Się ono zmieniać zależnie od języka ^ '
warto koncentrować się ztym io w miar,? Prac nad kodei" V ytnto na mm w początkowych fazach pracy
102
D la te g 0
nie
Pakiety współdziałanie
'I ffs w
m
U Jedno z najstarszych pytań
d z ie d z in ie m e to d p r o g r a m o w a n ia d o t y c z y te g o |ak J* p je t0 je s l z a d a w a n e , p o n ie w a ż w ,n,arc
ro zb ić d u ż y system na m n ie js ze syster iy . P y j a k system y stają się coraz w ię k s z e , stają
^
i w p ro w a d z e n ia zm ia n .
cQ raz tn ld n ie )S z e do
zrozumienia
f u n k c jo n a ln ą , w k tó r e j system bvl
M e lo d y strukturalne stosow ały na p o d f Un k c je . k tó r e z k o le i hyly o d w z o r o w y w a n y na fu n k c ję, a następnie ro zb j ^ , . n r z v n a r ik ó w 117 , ’ d alej ro z b ija n e na p o d p o d fu n k c je itd. F u n k c je te b y ły p o d o b n e d o p r / y p a d k o w uzycia s ystem u w s y s te m a c h o b ie k to w y c h w ty m sensie, że r e p r e z e n t o w a ł y cos. co sy .„en, W yr
c^
h
k;
l f
s ira k lu ra in y c h dane i proces b y t y o d
o p ró c z d e k o m p o z y c ji fu n k c jo n a ln e j is tn ia ły też s tr u k tu ry
s ie b ie
a n y c i.
r o z d z ie io o e ra > one
mgu.
s k rzy p c e, m im o że niektó re te c h n iki in ż y n ie rii in f o r m a c y jn e j g r u p o w a > rc or \ can y c h w obszary p rz e d m io to w e i tw o r z y ły m a c ie rz e , a b y p o k a z a ć z w i ą z k i i interakcje m ię d z y fu n k c ja m i a d an ym i. D o p ie ro teraz w id ać n a jw ię k s ze z m ia n y , do ja k i c h d o p r o w a d z i ł y
techniki o b iek
to w e . N i e ro z d z ie la się ju ż procesów i d a n y c h , nie stosuje się d e k o m p o z y c j i funkcjo n a ln e j, ale stare pytanie pozostaje nadal a ktu aln e . Jedną z o d p o w ie d z i na nie jest z g ru p o w a n ie k las w je d n o s t k i w y ż s z e g o poziom u. P o m y s ł ten, dość sw obodnie za sto s o w a n y , p o ja w ia się w
w ie lu
m e to d a c h
o b iekto
w y c h . W U M L - u m e c h a n izm g ru p u ją c y n a z y w a się p a k ie te m .
7.1
P a k ie ty
ale także do d o w o ln e g o e le m e n tu m od elu . B e z zastosow ania w g r u p o w a n iu k la s j a k i e j ś heurystyki, g ru p o w a nie to staje się arbitralne. H e u ry s ty k a , k tó ra n a jb a r d z ie j m i się przydaje i na k tó r ą naj większy nacisk k ła d z ie U M L , to zależność. T e r m in d ia g ra m p a k ie tó w stosuję d la d ia g r a m u , który' pokazuje pakiety klas i zależności m ię d z y n im i. Ściśle m ó w ią c , d ia g ra m p a k ie t ó w to diagram klasy p o k a zu ją c y tylko pakiety i zależności. Tak często stosuję te d i a g r a m y , że n a z y w a m je diagramami pakietów, ale trzeba pamiętać, że jest to m o je w ła s n e o k r e ś le n ie , a nie oficjalna nazwa UML-a. P o jęc ie pakietu m oże być zastosow ane n ie t y lk o d o k la s ,
Między dwoma elementami istnieje zależność, jeśli zmiany d e fin ic ji jednego ele mentu mogą spowodować zmiany drugiego. W wypadku klas zależność, is tn i« z wie u powodow jedna klasa wysyła komunikat do drugiej; jedna klasa zawiera drugą jako częsc swoich danych; jedna klasa wymienia drugą jako parametr operac., prawny
^
^
' ° k° mUn,ka'
"ją wysyłany mc
Elementem sztu^Tprojeklowam^wwsok011^ 311 kbSy powinny w pływ ać na inne klasy
w ten sposób efektv 7 mia °kopoziomowego jest m i n i m a l i z a c j a zależno.** > wysiłku y " Są zmmej szane. a ich wprowadzanie w y m a g a mniejszego
U M L w y m ie n ia w ie le ró żn y ch zależności ? w •
u
i stereotyp. Jeśli chodzi o m n ie , to łatw iej ,„i ,es. kaŻda ma własną semantykę „ereotypu, a dopiero p ó źn ie j, w m iarę ootrzeh * 2aczyn.ac ° d ogólnych zależności bez Na rysunku 7.1 są pokazane klasy m o d e l u h c e T ' ^ bardzie-' wyrafinowane. wane w dw u pakietach: z a m ó w ie n ia i klienci Ol • . nę Przedsiębiorstwa, zgrupomodelowanej d z ie d z in y . A p lik a c ja zbierania /•>m ^
V SąCZ,ęŚcią ° 8Ólne« 0 Pakietu
modelujących d z ie d z in ę . Interfejs u ży tk o w n ik i
1081 “
; ilkacJ, zbierania z a ,n ó w ,e n , A W
In te rfe js uży tkownika z b i e r a n i a zamówień
t
C
>
^ G
U
i
I i ^ a
*
In te rfe js u ży tk o w n ika listy adresowej
AWT
P a k ie t
r
° d ° bu Pakietów
Zależność
v
1 V
A p lik a c ja z b i e r a n i a z a m ó w ie ń
A p lik a c ja lista adresowa
i
----------------------------------------
/
IĆ> K lien ci
R ysunek 7 1 Diagram pakietów
Zależność
między
itniMi* w iiłilv i>dv istnieic jakakolw iek zależd w o m a pa •,^ ali' 11 ' . jctów N;| p r ’ y k |;u| jeśli jakakolw iek klasa
ić m iędzy d o w o ln y m i k las a m i y t lakiecie lista a d re s o w a je s t z a le /n a ■s istnieje z a le ż n o ś ć
między
lw je k klwsy pakietu klienci, to w ó w J
ty m ' I’-' IL J r
anv,„ zależnościami a zależnościami
Istnieje o c z y w is ty z w ią z e k m ię i zy n p ila cy jn ym i. A l e je s i le ż p o d s ia w o w a ró ż n ic *
IC
G d A b g tn u t W ir u ío w T o o lk it iprzyp* tłurn*)
zależności pakietów nic są prze-
,
^
hvć
to
ż e je ś li J im m a b u j n i e j s z y b ro d ę m / m o ż e m y w y w n i o s k o w a ć , /c
Przykładem relacji przechodniej m mn bujniejszą buinieisza brodę niz War, to z tegc Grady, a Grady ma Jimi ma bujniejszą brodę mz niż War ivai zależności jest ważna, należy spójAby zrozumieć, dlaczego p r z e ć o d ^ ^ " ^ , , lń w ,cnla ulegnie zmian,'. rzec powtórnie na rysunek 7 . 1. t e l l k l a w P zbieranja zamówień leż należy zmie nię oznacza to, ze pakiet interfejs uzytkown zbierania zamówień, aby nić. Oznacza to jedynie, że należy s p m w d z ^ k i e ^ U ^ > d o w ie d z ie ć Się, c z y te n p a k ie t w y m a g a a p lik a c ja z b ie r a n ia z a m ó w ie ń
ik o w n i ki a
i
J
jen|C.
u le g a z m ia n ie , n a ic y
• • - nr
k ie t
in t e r f e js
llż
„ „ . „ a , , , ; - , ; „i
u/vnaHku anlikacia zbierania zamówień chrom j
z b ie ra n ia z a m ó w ie ń . W ty m wypacucu apuie
in te rfe js u ż y t k o w n ik a z b ie ra n ia z a m ó w ie ń p rz e d z m i a n a m i w z a m o w i e m a c
stosowania arc 1 e U l> ' ' a i s t w o w e j. Jest to p o d o b n e do s e m a n ty k i in s tru k c ji i m p o r t w Javie, a e ju z m e o tp o w i.rj s e m a n ty c e d y r e k t y w y in c lu d e w C/C++. W C/C++ „include” jest przechodnie, co z n a c z y , że in te rfe js u ż y t k o w n ik a z b ie ra n ia z a m ó w ie ń byłby zależny od zamów ień. Z a l e ż ność p r z e c h o d n ia u tru d n ia w k o m p ila c ji o g r a n ic z e n ie z a k re s u zmian. M im o ze w i ę k szość z a le ż n o ś c i nie jest p rz e c h o d n ia , to m o ż n a samodzielnie utworzyć za p o m o c ą U z y s k a n ie ta k ie g o e fe k tu je s t k la s y c z n y m c e le m
s te r e o ty p ó w z a le ż n o ś ć p rz e c h o d n ią .
publiczne, prywatne lub c h r o n i o n e . Z a t e m p a z a le ż n y od p u b lic z n y c h metod publicznych k la s p a k ie t u k lie n c i m e to d a p ry w a tn a lub metoda publiczna k la s y p r y w a t n e j , to ża d n a
K l a s y w ra m a c h p a k ie tu m o g ą b y ć k ie t z a m ó w ie n ia jest Jeśli z m ia n ie u le g n ie
z k la s p a k ie tu z a m ó w ie n ia n ie m u s i b y ć z m ie n ia n a .
pakietu do niewielkiego p o d z b i o r u o p e ra c ji k la s p u b lic z n y c h . M o ż n a to o s iąg n ą ć , n a d a ją c wszystkim klasom p r y w a t n y zasięg w id o c z n o ś c i, ta k a b y b y ły one w id z ia n e tylko przez inne klasy tego p a k i e t u , i d o r z u c a j ą c d o p a k ie tu d o d a tk o w e k la s y p u b lic z n e d la definicji zachowania p u b l i c z n e g o T e d o d a tk o w e k la s y , z w a n z fasadami (w z o r z e c Facades [20]), zlecają w y k o n a n i e o p e ra c ji p u b lic z n y c h ich p r y w a t n y m p a rtn e ro m w ra m a c h pakietu. P a k ie ty j a k o ta k ie n ie d a ją o d p o w ie d z i na p y ta n ie , jak zredukować liczbę z a le ż n o ści w e w n ą t r z s ys te m u , ale p o m a g a ją z o r ie n t o w a ć się, jakie zależności w y s t ę p u ją w s y s te m ie re d u k o w a ć lic z b ę z a le ż n o ś c i m o ż n a ]edynie wtedy, gdy wie się iakie są te z a le ż n o ś c i i g d z ie one w y s tę p u ją . D i a g r a m y p a k i e t ó w s ą dla mnie istotnym n a rz ę D o b r ą p r a k t y k ą je s t o g ra n ic z e n ie in te rfe js u
d z ie m w z a r z ą d z a n iu o g ó ln ą a r c h ite k tu r ą
systemu.
R y s u n e k 7 .2 p rz e d s ta w ia b a rd z ie j z ł o ż o n y d ia g r a m p a k i e t ó w , k o w e m e c h a n iz m y .
zawierający
d o d a t
Po pierwsze, widać że dodałem pakiet dziedzina zawierający pakiety zamówienia i klienci. Takie Zagnieżdżenie jeal przydatne, bo można rysować zależności p.i-
k“
' = ; n'kT T 1C" SP° SÓb ' yS0Wania Wlel" » ^ z ie ln y c h zależność, azując zawartość pakietu, nazwę pakietu piszemy w matei ramce (zakładce) na górze, a właściwą zawartość w ramce izłówiud 7 .,., I d i . (zakładce) na w wypadku pakietu wspólne; innym paldcicm h kSawartosc.,moze bVc list* klas' ,ak diagramem klas (nie pokazanym na r y s u n k u - a £ T ó l oczywisty). *e
.dziedz,na,' '¡' schemat jest już chyba
Jim Rumbaugh, Grady Booch i Ivnr i», u Jacobson naprawdę są b r o d a c z a m i
( p r z y p . tłu m ł
Pakiety
In terfejs u ż y t k o w n i k a z b ie ra n ia z a m ó w ie ń
AVVT
Interfejs użytkownika listy adresowej
A p lik a c ja z b ie ra n ia z a m ó w ie ń
A p lik a c ja lista adresowa
D z ie d z in a
Z a m ó w ie n ia
----------------------->
K lien ci
Rysunek 7.2. Złożony diagram pakietów
Mim o że w w ię k s z o ś c i w y p a d k ó w ^ StarC^ ^ , ' ^ | Cn a ^ s u n t u pokazałem , że o ile 0,1 P*ydaJ4 się d o d a t k o w e d ia g r a m y . W ty m w y p a d k u na rysu
............................ , aIeżna od całej dziedziny, to aphkac,a l.su , aplikacja zbierania zamówień |e-s sowa icst zależna tylko od pakietu U i e n c i . z a W lc r a ją c e g o i n n e p a k i e t y ? ( i g o l , . ., Co to znaczy, że istnieje z a le ż n o ś ć o o p z a ie ż n o ś c i n i ż s z e g o p o z i o m u C z y i, oznacza to, że z a le ż n o ś ć ta n ie ja k o s re zszeg0 p o z i o m u , a le je s t p o t r /e b n y istnieje zależność od pewnego elementu pa dokładne reguły zalezą od kond o d a t k o w y d ia g r a m , a b y p o z n a ć s z c z e g ó ły . Znowu. k r e tn e g o ty p u z a le ż n o ś c i.
oznaczony
jako «global».
R y s u n e k 7 .2 p r z e d s t a w , a p a k i e t p a k t e t u .
wszystkie pakiety w systemie są z a le z n e leży nadużywać te g o m e c h a n iz m u , ale
fc k l a s y . “ takie
O z n a c z a to,
/e
O c z y w i ś c i e , m e na
jak waluta,
są używ ane
pr
w s z ę d z ie . „oańlmenia Oznacza to, że k o n k r e t n y p a kie t D o p a k ie t ó w m o ż n a s to s o w ać re la c ję u o g o lm ■ , . . m u s i b y ć z u o d n y z in te rfe js e m p a k ie tu p o d s t a w o w e g o . Jest to a n a l o g u z m u ż y c ia , v Pó w 'p o c h o d n y c h z d ia g ram ó w " k la s w m o d e la c h s p e c y t i k a c y j n y c h ( z o b a c z r o z d z ,a l
danych może k o r z y s t a ć z .n te rfe js u O r a c le a lb o in te r fe js u S yb ase. W s y tu a c ja c h ta k ic h jak ta pakiet p o d s t a w o w y m o z k hyc o z n a c z o n y j a k o {c ib s tra c t/, a b y p o d k r e ś lić , ż e d e f i n i u j e jedynie i n t e r f e j s , k t o i y m a hyc 4.5. Z a t e m , z g o d n ie z r y s u n k ie m 7 .2 . in te r fe js b a z y
z a i m p le m e n t o w a n y p r z e z k o n k r e tn y p a k ie t.
pochodnego od typu p o d s t a w o w e g o . ( i ej d o d a t k o w e j z a le ż n o ś c i n ie trz e b a p o k a z y w a ć ; wystarcza samo u w i d o c z n i e n i e uogól n i e n i a . ) U m ie s z c z e n ie k las a b s tr a k c y jn y c h w p a k ie c ie podstawowym j e s t dolnym p o m y s łe m na u n ik n ię c ie z a le ż n o ś c i c y k l i c z n y c h w całej strukturze z a l e ż n o ś c i . W n a s z y m w y p a d k u p a k ie t y in te r fe js u d o b a z y danych są o d p o w i e d z i a l n e z a p o b ie r a n ie i z a p a m ię t y w a n ie o b ie k t ó w d z i e d z i n y w b a z ie danych. M u s z ą o n e z a t e m znać o b i e k t y d z ie d z i n y . Z k o le i o b ie k t y d z i e d z i n y s a m e muszą u r u c h o m i ć f u n k c j e p o b ie r a U o g ó l n i e n i e i m p l i k u j e z a le ż n o ś ć ty p u
n ia i z a p a m i ę t y w a n i a w b a z ie d a n y c h .
interfejsów uruchamiania operacji pobierania i z a p a m i ę t y w a n i a w b a z ie d a n y c h w pakiecie interfejsu bazy danych. Operacje te są n a s tę p n ie i m p le m e n t o w a n e p r z e z k la s y w pakietach pochodnych. N ie ma zatem z a le ż n o ś c i m i ę d z y p a k ie t e m in te r fe js u b a z y d a n y c h a pakietem interfejsu Oracle, mimo ż e w c z a s ie w y k o n y w a n i a to e le m e n t y p a k i e t u pochodnego są w yw oływ ane p r z e z e le m e n t y d z i e d z i n y . D z i e d z i n i e w y d a j e się, że korzysta z (prostszego) pakietu interfejsu b a z y danych. P o l i m o r f i z m je s t p r z y d a t n y z a r ó w n o w wypadku pakietów, jak i k la s . Dobrym zwyczajem jest usuwanie cykli ze struktury zależności. Nie jestem prze konany, czy należy starać się usunąć wszystkie cykle, ale na pewno należy próbować ograniczyć ich liczbę. Jeśli mimo wszystko występują na diagramie, to należy je umiesctc w jednym pakiecie wyższego poziomu. W praktyce m iałem w yp adki gdv me uda wało mi Się umknąć cykli między pakietami dziedziny, z drugiej strony staram się z a wsze je usunąć z interakcji między dziedziną a intertejsami zew nętrznym i. Uogólnienie jest ważnym mechanizmem pomagającym to zrobić U o g ó l n i e n i e u m o ż l i w i a w s t a w ie n ie
to
można w yw nioskow ać, badając klasy. Jest
bardzo mi nomata H T * WSPiera« ceg ° projektowanie. A naliza zależność, etap polega na L m n o w " w udoskonallc strukturę istniejącego systemu. Pierwszy mmi. Następnie refaktorez11111 ? * Pak'e,y ' Przeanalizowaniu zależności między stępnie retaktoryzuję pakiety, aby ograniczyć liczbę zależności.
Pakiety i w spółdziałanie
7.2
W spółdziałania
sekwencj i
Rysunek 7.3. Diagram sekwencji dla Sprzedaży W s p ó łd z ia ła n ie to m o ż e o p is y w a ć im plem entację operacji lub realizacje przypadku aa. W s p ó ł d z i a ła n i e m o ż e być m o d e lo w an e , zanim zdecyduje się. k.ora operacja W s p ó łd z ia ła n ie ^ m o ż e b y ć opisane k ilk o m a diagram am i interakcji z których każdy L
r “
S
'
biorV eu d z la l
.
M o ż n a do tego j e s z c z e dołączyć diagram klas. aby pokazać
rysum ™ożna
w in t e r a k c ji (z o b a c z
o in te ra k c je z b a z ą d a n y c h
n je g 0
ko.
p R e k r a czające granice pakietów. Jeśli kłoś ' |uczone że lrccba g0 skierować do w ielu «7
zachodzą -
-tó w i k la s , a b y z o r ie n t o w a ł s i t , .
^
Rozdział 7
»prócz s to s o w a n ia ac, a b y p o k a z a ć w s p ó ln e z a c h
ró w n ie ż z
przy czym interakcja z bazą p ociejście to można udoskona-
ch to t y lk o j e d e n z a s p e k t ó w t y c i P a‘
sobne w spółdziałanie. W ramach tego
ie fin iu ją c d la o d w o ła ń do b a z y i any
..
k(óre w tym wypadku są istotne,
Zdziałania pokazuje się ^ ' ' “ l^ ^ m iz a c h o d z , diagramy interakcji pokazując ,J
109
O fe rta
kupując} sprzedający 1 R ysunek 7.4. D iagram klas d la w s p ó łd z ia ła n ia w tra k c ie s p rz e d a ż y
ze/ różne klasy. Z a k a ż d y m ra zem e le m e n ty p o d s ta w o w e w s p ó łd z ia ła n ia klas są takie same, je d y n ie n a z w klas i operacji są inne oraz is tn ie ją ja k ie ś d ro b n e r ó ż n ic e w implementacji. C zęsto o k a z u je się, że ten sam m o d e l w s p ó łd z ia ła n ia je s t s to s o w a n y pi
M o ż n a to zilu s tro w a ć , p a ram e try żu ją c w s p ó łd z ia ła n ie .
role, które g ra ją różne o b ie kty. (K la s y na ty m d ia g ra m ie n ie są r z e c z y w i s t y m i klasami systemu, lecz ro la m i, j a k ie g ra ją w e w s p ó łd z ia ła n iu .) P o te m d o d a je się d i a g r a m y interakcji, aby N a jp ie r w rysuje się d ia g ra m taki j a k na ry s u n k u 7 .5 , p o k a z u ją c y ró ż n e
p o kazać in terakcje tych ról.
Rysunek 7.5. Sparametryzowane wspótózialanie Sprzedaż
K o le jn ą c z y n n o ś c ią je st n a r y zać, ja k w s p ó łd z ia ła ją k o n k r e t y 0 ™“ "
takiego ja k lysunek 7.6, aby poka-
Rysunek 7.6. Użycie współdziałania Sprzedaz Jako s y n o n im sparam etryzo w an ego współdziałania U M L stosuje również termin w zorzec. N a z y w a n ie sparam etryzow anego współdziałania wzorcem jest kontrowersyj ne, p o n ie w a ż w z o rc e to coś więcej — niem niej ta notacja może służyć do pokazania, gdzie w' k o n k r e tn y m system ie w ystępują wspólne wzorce. N o ta c ji tej m o ż n a r ó w n ie ż użyć w' modelowaniu opartym na rolach, gdzie najpierw m odeluje się w s p ó łd z ia ła n ia i role, a następnie określa klasy implementujące te role. W ięcej o ty m s ty lu m o d e lo w a n ia m ożna przeczytać w [35],
7.3
Kiedy stosować diagramy pakietów i diagramy współdziałania
P ak ie ty są n ie z b ę d n e dla dużych projektów . D iagram y pakietów należy stosować zawsze
g d y d ia g r a m klas o b e jm u ją c y cały system siaje są- m eczyłeluy po umiesz
czeniu go n a je d n e j k a n c e fo n n a ,u A 4
^
M ,m 0 że czasam, plszę ,esty d |a
P a k ie ty p r z y d a ją się szczeg >1 tes(0Wanie m odułow e pakiet po pakiecie. P ojedynczych k la s , to w o lę p t / e * , tgs testująCą jego zaK ażdy p a k ie t p o w in ie n z a w ie ra ć co najm niej jc
kowanie.
trzcba odw ołać się do konkretnej mterakW s p ó łd z ia ła n ie p r z y d a je się v\ t y, . ■ d w Sy Stenne jest kilka podobCJ1. W s p ó łd z ia ła n ia s p a ra n ie lry z o w a n e p rz y d a ją s,«, t y nych w s p ó łd z ia ła li
.
7.4
Dodatkowe źródła
znajduje się w książce Roberta Martina [3 0 ] . k tó ra d a je k ilk a p r z y k ła d ó w , stosu jąc notację Boocha [4] i C++ oraz zwracając u w a g ę na o g ra n ic z e n ie lic z b y za le żn o ś c i. W i e l e wartościowych informacji można tak że z n a le ź ć w [ 4 6 ] ; g łó w n y a u to r n a z y w a pakiety podsystemami. W s p ó łd z ia ła n ia to s to s u n k o w o n o w y temat i jego omówienie można znaleźć w Har d z ie j s z c z e g ó ło w y c h k s ią żk a c h o UML-u. N a jle p s z e z n a n e m i o m ó w ie n ie p a k ie tó w
Diagramy stanów
U ML w kropelce
o D is u z a c h o w a n ia
s y te m u
O
D ia g ra m y s u m m M m o że przejść d a n y o b ie k t , a także wszystkie możliwe stany, do k n ie g o d o c ie r a ją c y c h . YV w ię k / * stan obiektu pod w p ły w e m z d a r * » * • » £ > „ k|as obiektowych diagramy stanu są rysowane i cykl życia pojedynczego ° biekt^ każda z n ieCo i n n ą semant;. Istnieje wiele postaci diagramów stanu, k . wana w U M L - u jest oparta na m apat i stano z a m ó w ie n ia u Rysunek 8.1 przedstawia diagram stanów U M L - a d la z a m ó w ie n ia u
^ >* _ cały f uz ..
\ pr?e
twarzama zamówień, w prow adzonym prceze m n ie w c z e ś n ie , w książce. Diagram pokazuje różne stany zamówienia.
P o czą tek
/pobierz pierwszą pozycję [Nic wszystkie pozycje sprawdzone] /pobierz następny pozycję
______V _______ " 7 " . S p ra w d z a n ie
[Wszystkie pozycje sprawdzone & & wszystkie są dostępne]
Wysyłka • w
do/sprawdź pozycję
[Wszystkie pozycje sprawdzone &<& niektórych pozycji brak w magazynie] Pozycja otrzymana [niektórych pozycji brak w magazynie]
t i Pętla
Stan Rysunek 8 1 D iagram s ta n ó w
Każdy diagram ma początek i ni* Sprawdzanie Przejście t o jest o z n a c z o ^ / n ^ h ™ ^ 0 ' 6 ~ « *>» s padku *> * » Syntaktyka etykiety przejścia składa * |) lc r " « H p o z y c ję nalna. erfur.-e/iie Idozar) / akcju w j ‘ J '^ech części, z k t ó r y c h k a ż d a tc-t e(V|0p o z y c ję o wykonaniu te, akcj, przccl,„dz P le s , j c d >'n i c a k c ' a pobierz pier»«« ;
M ę li( > s ia n u S p r a w d z a n i e
Z ty m s i » * 1
' Inlbnnacje na ten temat m„ , „ a “ o *
w w ydane,
'Pr/yp tłuni.) 114
p„
polsku W c c
„ a u d ., R *
eSt związane w y k o n a n ie p e w n ej czynności
v
„ ^ c z y n n o ś ć . W ty m w y p a d k u ta czynność ,1 “ ^ U żyłe m terminu akcja dla przejścia i te
“
P° mocą e,>'k ' « y o «yM atay-
? sPr*wdź pozycję oznaczają procesy zwykle im p le m e n to w a n e j dla stanu Mimo że oba io są traktowane różnie. Akcje są związane z n n f met° dy klasy Namówienia, szybkie i meprzerywalne (atomowe). Czynności ' lraklUJe się Je iako Procesy dhiżej. Czynność może zostać przerwana ;a? ZWl1 ą2ane 2e slanami »mogą trwać Należy zwrócić uwag,, że znaczę,ue stowa Szvhk T " " systemu. W terminach systemu czasu rzeczywi , ^ ° d imPlementowanego kilku instrukcji maszynowych” , natomiasi hu eg° ,Szybko może oznaczać „w ciągu szybko m oże o z n a c za ć „ w ciągu k ilk u sekund” f f i i t z p rz e jś c ie m n ic je st stow arzyszona
ZWy
80 s>'s,eniu informatycznego ■
mego natychm iast po za k o ń c ze n iu czynności z w ia z a n Y ^ 02™ 02* ' ° ’ ŻC dochodzi do wypadku oznacza to, że do przejścia do n a s t e n n J « .» J h ,z e .stanem. W omawianym i f i T e ^ F ^ c js c ia 0 0 następnego stanu dochodzi wówczas i?dv tvl ko zakończy s t , s p ra w d z a n ie p o zy c ji Ze stanu S p ra w d z e n ie s , możl we ,R y p « e sc,a W s z y s t k ie m a ją ty lk o d o z o ty w etykietach.
jest
warunek lo g io n y zw ra
cający jed n ą z d w u w a rto ś ć , - p ra w d a lub taisz. D o dozorowanego przejść,a dochodzi tylko w te d y , g d y d o z o r z w ra c a wartość prawda. Z danego stanu m o ż n a w y b ra ć ty lko je d n o przejście', tak więc dozory dla zdarzeń powinny w z a je m n ie się w y k lu c z a ć . N a rysunku 8.1 są trzy warunki. |. Jeśli me zostały s p ia w d z o n e w szystkie pozycje, to należy pobrać następną pozycję i wrócić do stanu S p r a w d z a n i e , aby j ą sprawdzić. 2. Jeśli zostały' s p ra w d z o n e w s zys tk ie pozycje i wszystkie są dostępne w magazynie, to należy' p rzejść do stanu W y s y łk a 3. Jeśli zostały s p ra w d z o n e w szystkie pozycje, ale nie wszystkie są dostępne w maga zynie, n a le ży p rze jść do stanu O c z e k iw a n ie . Warto p rz y jrz e ć się n a jp ie r w stanowi O c z e k iw a n ie . N ie w ykonuje się w nim żad nych czynności, tak w ię c z a m ó w ie n ie czeka na zdarzenie. Oba przejścia z tego stanu poznaczone z d a r z e n ie m P o z y c ja o tr z y m a n a . Oznacza to. że zam ówienie czeka na to zdarzenie. W c h w ili n a d e jś c ia tego zdarzenia są w yliczane wartości dozorów na przej ęciach i z a m ó w ie n ie p rz e c h o d z i albo do stanu W y s y łk a , albo z powrotem do O c z e k i wania W stanie W v s v ł k a jest czyn n o ść, która inicjuje dostawę. Jest też jedno niedozoro*ane przejście w y z w a la n e p rz e z zd arzen ie D o s ta rc z o n e Oznacza to, że do przejść,a
me dochodź, po zakończeń,u inicjującej dostawę zam ów,cm e
Nachodzi zaw sze po ty m z d a rz e n iu . Jednak do przejścia czynności; p r z e c iw n ie -
p o z a k o ń c z e n iu czynności
“’zostaje w stanie W v s y l k a , a ż do nadejścia zdarzenia D o s ta rc za n e r\ . , i • w i n r ti) nrzeiscie oznaczone etykietą anulowane. Ostatnią rzeczą, k tó r ą n a le ż y się c h w il, p m d nadejściem %
miec m o ż liw o ś ć a n u lo w a n ia z a m
każdego ze stanów S p ra w d z a n ie .
J j * - W y n a ry s o w a ć o d d z te ln c ^ k i w a n i e , Wysyłka. In n y m sposobem jest u t w o r u
tanu złożonego składają-
śCiś,e * — * oryginale u ż y w a tu słowa ^ * ° k ,cgo. w zględnie w yższego, poziom u (p«
zl oi onych ,„b sT
rS “t Z Z n a
. s tin 6 w a następnie n a ry s o w a ć pojcd> nc/c cego się ze w sizystkich z y s iiu ^ '
{ n zsic ^ z ąi przejścia l ń 7 ,c za p rzejścia d zied
stanu z ło ż o n e g o . t * e j « , „ w
ii go stanu. Podstany p o p r o « “ “ w |aki sposób te d w a p o d e jś c ia o d z w ie u a e d»l.,,., , R ysunki 8.2 i 8.3 pokazują, 1110 zachowanie systemu
[N ie wszystkie pozycje sprawdzone] /pobierz następną pozycję
[W s z y s tk ie pozycje spraw dzone && w szystkie
S p r a w d z a n ie
są dostępne],
/
/
~~
Wysyłka do/inicjuj dostawę
do/spraw dź pozycję
[W szystkie pozycje sprawdzone & & niektórych pozycji hrak w magazynie]
Pozycja otrzymana [niektórych pozycji brak w magazynie]
Oczekiwanie
A nulow ane
V
A n u lo w a n e
D ostarczone
J
V
Rysunek 8.2. Diagram stanów. bez os ta ów w z¿ lo ia ini u lu zz oo n n yy cc h n N a w e t p rzy ty lko trzech p o w tó rz o n y c h n „
7
•
L
zagracony. Rysunek 8.3 przedstawia inć JSC rysunek 8 .2 wygMd«« 11 pomaga nie zgubić zdarzeń anulowania meJSZy ° braz ‘ w w >'Pddku p ó źn ie is. \ch Na razie pokazałem czynności wvk, do/czynność. Oprócz czynności m n . nywane w d a n y m s ta n ie o p is y w a n e w l rzeczy. zna jednak umieścić w s ta n ie jeszcze pa>C 1 Jeśli stan reaguje na pewne J . m ożna to pokazać, um ieszczając u
nazwaAkcji.
^a n *e m n *e p o w o d u ją c y m p i / c o
J4C w W b o lu stanu opis w postaci
\
Nazwa stanu złożonego A k tv w n fNic wszystkie pożycie Lawdzone] /pobierz
następna P ^ CN W y s y łk a do/inicjuj dostawę [W szystkie pozycje sprawdzone & & niektórych p o z y c ji brak w m agazynie]
Pożycia otrzymana [niektórych p o zycji brak w magazynie]
Oczekiwanie
Anulowane
Dostarczone
A n u lo w a n e
Rysunek 8.3. Diagram stanów ze stanem złożonym Jest
jeszcze
p a rę in n y c h ro d z a jó w zdarzeń oprócz nazwanych zdarzeń zewnętrz
nych. • Z d ą ż e n ie m o ż e b y ć w y g e n e ro w a n e po upływ ie pewnego czasu. <>zl' a“ “ suj 10 słowem k lu c z o w y m a f i c r ( z ang. po). N a p rzykład można naprsac a fte r 12 0 m m u-
• ^ „ T e m o z i b y c ^ t e n - w a n e po spełnieniu pewnego warunku.
.0 stowem Iduczowym when <* « "* t a p H
Z S ,” '“ '
»
> 1 0 0 d e g r e e s ) , [z ang gdy (tem peratura > 100 s . o p n , . — c n tr v (Z ant?, wejście) i exit (z ang. Oprócz le g o są d w a z d a r z e n ia specja c |CS| w ykonyw ana przy każ*»scie). K a ż d a a k c ją s to w a rz y s z o n a ze . t"» wejściu do stanu. A k c j a s .o w a rz y s z o n a ze z d a « e iem
'»dyn, wyjściu ze stanu Jeśli jest to W (pyr/n). t o wówczas najpierw bp| ze stanu (tzn. ze zdarzeniem exit),
^
w ykonyw ana przy j
y
^ c j . stowarzyszona z wyjjc ,,kcJa związana z przejściem, a na
_________________ H c ie m do stanu (tzn. ze zdarzeniem entry, j Csl) A końcu akcja związana z wej iakaś czynność, t o b ę d z i e ^ j W w y U n jes, s t o w a r z y s z o n o - jeszcze ja k a ś c z y n n o .,akcji zw iązanej z wejściem
ll'l"lcni Pu
o stanu
Diagram y stanów w s p ó łb ie ż n y c h
8.1
O prócz stanów zwtązanych z dostępnością p o z y c ji z a m ó w ie n ia is tm ej, „• stany związane z autoryzacją płatności P rz y g lą d a ją c stę t y m stanom , można ^ diagram podobny do tego z rysunku 8.4.
A u to r y z a c ja
[płatność niepotwierdzona)
d o /s p ra w d ź płatność
[p ła tn o ś ć p o tw ie rd z o n a )
r P o tw ie rd z o n e
O d rzu c o n e
D o s ta rc zo n e
Rysunek 8.4. Potwierdzenie płatności
w ierne czeka w stanie
Potwierdzon • I
c iw n y m w yp a d ku zam ów iem o u /rh
i
z a ch o w a ń ,e Z a m ó w ," ^ 7 ^ 1 8.1 i 8.4. S tow arzyszone z n im str
f i ™ * * '" “ T '; kT [ p ła tn o ś ć p o w io d ła się. to z
i
°
n v i*‘ n a tie jś c ia z d a r z e n ia d o s ta w a W w s t a " O d rz u c o n e
na cl4
zachowań
p r z e d s t a w i o n y c h na rysun
hyć połączone w d ia g ra m ie s t a n ć m , ^ ' ?»a.n ^ n u * ° " a n e , om ów iony wcześniej. ' w spo ń e ż n y c h (zobacz r y s u n e k 8 .5 )
I rx . . m.
-
_
' Dav,d Harel u*y w a tu bardziej ocóln
e80
terminu sumów ortogoualnn h [ przyp tlllll
Diagram y stanów
Na ry s u n k u 8.5 opuściłem SZC2egójy stanów wewnętrznych
\ m iło w a n e
►
'4
Dostarczone
koniec
Odrzucone Rysunek 8.5. Diagram stanów współbieżnych
W spółbieżne s k ła d n ik i stanu na diagramie są to miejsca, w których dane zamówie nie może p rz e b y w a ć w d w u różnych stanach — każdym z innego składnika. W chwili opuszczania p rz e z z a m ó w ie n ie stanów współbieżnych trafia ono do pojedynczego stanu. W id a ć że z a m ó w ie n ie rozpoczyna s w o ją d r o g ę jednocześnie od stanów S p ra w dżinie . A u t o r y z a c j a . Jeśli czynność p ła tn o ś ć c z e k ie m w stanie A u to ry z a c ja zakoń
czy s,ę sukcesem, to z a m ó w ie n ie znajdzie się w stanach S p ra w d z a n ie ■ P o tw .e rd /o ne Jeśl. p o ja w i się zd a rze n ie anulow ane, to zam ówienie tral. tylko do stanu A n u lo " " W a r n y s la n ó w w s p ó łb ie żn y c h p i z y d ^ i * w
pewne z b io ry n ie z a le ż n y c h
zachow ań. J
.
Jeśli dla jednego obiektu jest k il-
» 'p o lh ic ż n y c h z a ch o w a ń d la ^ s|,ń |b,cżnych. to należałoby się zastanowić te s ko m p lik o w a n y c h d ia g ra m ó w stan I ’ ad rozbiciem tego o b ie k tu na k ilk a prostszych.
d a n y c h też o r t o g o n a l n y m i fprzyp tłum.). 114
Kiedy s t o s o w a ć diagram y stanów
8.2
a
cii* Hn opisywania zach o w an ia obiektu o b c i , k
D iagram y stanów przyda a kilk a przypadków ^ c|a s y a t e ^ . D t obejmujących współdziałanie w ielu c t e
c
h
n
i k
ę
stan6 w nic n a d a ją się do opisu tak ,c h w y p a d k a c h lepie,
diagram ów stanów z innym i techru ann.
4Uyc
Hnhre Ho nnic
N a przykład diagramy interakcji (zobacz r o z d chowan.a kilku obiektów w pojedynczym przyp ad ku u ż y c ia
z ^ y s tu u, ,, d,agrllmy
czynności (zobacz rozdział 9.) przydają się w przedstaw ianiu ogo nego ciągu c / ynno. ści dla kilku obiektów i przypadków użycia. , ... N ie wszystkim diagramy stanów w ydają się czym ś n a tu ra ln y m , a r t o przyjrzeć się temu, ja k inni je stosują. M oże się zdarzyć, że zespól uzna, iz d ia g ra m y stanów nie sj przydatne w pracy. N ie stanowi to w ielkieg o problem u
ja k zw y
t t i z e b a pamiętać
o stosowaniu kilku różnych technik, które akceptują w szyscy. Stosując diagramy stanów, nie należy rysować ich dla każdej k l a s y s y s t e m u Mimo że jest to czasami stosowane, to prawie zawsze jest stratą czasu. D i a g r a m y s ta n ó w sto suje się tylko dla tych klas, które m a ją ja k ie ś interesujące z a c h o w a n ie , i t a m . gdzie na rysowanie diagramu stanów pomoże zrozum ieć, co się dzieje. W ie le osob uważa, ze zachowanie obiektów interfejsu u żytkow nika i o b ie k tó w sterujących w a r t o przedsta w ić na diagramach stanów.
8.3
Dodatkowe źródła
Zarów no podręcznik użytkow nika [6], ja k i p o d ręczn ik U M L - a [3 7 ] zawierają wię
czasu rzeczywistego bardzo często stosują diagramy stanów, tak w ięc nic d z iw n e g o , że Douglass [17] ma w iele do powiedzenia na ten temat i pokazuje, ja k im p le m e n to w a ć diagramy. cej informacji na temat diagram ów stanów. Projektanci s ys te m ó w
Jeśli ktoś często stosuje diagramy stanów, to p o w in ie n p rze c zy ta ć ich omówienie w książce Cooka i Damelsa [13]. M im o że są pew ne ró żn ic e sem a n ty c zn e między ma pami stanów z tej książki a diagram am i stanów w U M L - u , to a u to rz y o m a w ia ją szcze góły, o których należy wiedzieć, używ ając d ia g ra m ó w
czynności
Rozdział
je d e n z n a jb a rd z ie j n ie o c z e k iw a n y c h e le m e n t ó w U M L -a
lic z b ą ró w n o le g ły c h czyn n o śc i. . . . D ia g r a m y stanu opiszę w tej książce n ie c o d o k ła d n ie j, n iz n a
,
to napiawu, /as uguj ą , d la te g o że są one je d n y m z n a jsła b iej r o z u m ia n y c h o b s z a r o w i -a, a ostatnie k s ią ż k i o U M L - u p o ś w ię c a ją im s zc z e g ó ln ie m a ło m ie js c a . N a ry s u n k u 9.1 p o d s ta w o w y m s y m b o le m je s t s ta n c z y n n o ś c i lu b
po piostu czyn ność. C z y n n o ś ć jest to stan d z ia ła n ia lub d z ia ła ln o ś c i: w y k o n y w a n i e pewnego rze czy w is te g o procesu, na p rz y k ła d pisanie listu, lu b w y k o n y w a n i e piocedury piogramis ty c z n e j, na p r z y k ła d w y k o n y w a n ie m e to d y k las y . D ia g r a m czyn n o śc i op isuje, jak są u s z e re g o w a n e d z ia ła n ia ,
otaz daje możliwość o p is u c zyn n o śc i w a r u n k o w y c h lub w s p ó łb ie ż n y c h . D ia g r a m c z y n n o ś c i jest weisją dia g r a m u s ta n ó w , w k tó r y m w ię k s zo ś ć s tan ó w to stany c z y n n o ś c i. Dlatego też większość te r m in o lo g ii p o c h o d zi z d ia g r a m ó w stanów . Proces w a r u n k o w y jest o k re ś lo n y za p o m o c r o z g a łę z ie n ia i s c a le n ia .
T y lk o jedno wyjście m o ż e b y ć w y b ra n e , tak w ię c d o z o ry p o w in n y się w z a je m n i e w y k l u c z a ć . Użycie prede fin io w a n e g o d o z o ru [e ls e j (z ang. w p r z e c iw n y m w y p a d k u ) j a k o dozoru oznacza, że je ś li w s z y s tk ie inne d o z o ry są fa łs z y w e , to n a le ż y w y b r a ć w y jś c i e odpowiadające do R o z g a ł ę z i e n i m a je d n o w e jś c ie i k ilk a d o z o r o w a n y c h w y jś ć .
z o r o w i [else].
jest p iln e , to d o s ta w a je st re a liz o w a n a w c ią g u 2 4 g o d z in ; w p r z e c i w n y m w y p a d k u jest do N a ry s u n k u 9.1 po re a liz a c ji z a m ó w ie n ia je s t r o z g a łę z ie n ie . Jeśli z a m ó w ie n ie
s ta w ą z w y k łą . S c a le n ie m a w ie le w e jś ć i je d n o w y jś c ie . S c a le n ie
oznacza koniec
p ro c e s ó w w a
r u n k o w y c h ro z p o c z ę ty c h r o z g a łę z ie n ie m .
scalenia. S ta n czynności, j a k k a ż d y in n y stan, m o ż e m ie ć w ie le d o z o r o w a n y c h w e jś ć i wyjść. R o m b y można s to s o w a ć , g d y ro z g a łę z ie n ia i scalen ia na d ia g ra m a c h m a j ą b y ć wyraźnie w id o c z n e . P ro c e s y w s p ó łb ie ż n e są o k re ś la n e za p o m o c ą rozwidleń i złączeń. N i e trz e b a ry s o w a ć r o m b ó w , a b y o z n a c z y ć r o z g a łę z ie n ia i
, to są wybierane rownoiegie wszysucte wyjścia. Zatem na rysunku 9.1, p o przyjęciu nia, jednocześnie jest realizowane zamówienie i wysyłana faktura
z a m ó w ie
p °czątek
C zyn n o ść
D o zó r
-> S c a le n ie
JL-JL«— —
i
Złączenie
Zam knięcie zam ów ienia
□
K o n ie c
R ysunek 9.1. Diagram czynności
Można le ż w y k o n y w a ć te c zyn n o śc i, przeplatając je d n ą z drugą - w ziąć pierw szą pozycje z a m ó w ie n ia z m a g a z y n u , w ypisać fakturę, w ziąć drugą pozycję, w tozyc lukycj«,. zamówieniu . b . niektóre te czynności jednocześnie — turę do k o p e rty itd. M o ż n a t e / w y k y • kazdy z ,ych sposobów jest * fakturę i sięg ać d o m a g a z y n u . W e d łu g diagram u y
Prawny
,•
■
po-
rzeczy do zrobienia. Innymi słowy konywłnie czynności. To jest właśnie schematem przepływu sterowania
„uA r kolejności
Diagram czynności umożliwia y określa podstawowe reguły porzą J4 foznica między diagramem czynno.se
pi-
- schematy są zw ykle ograniczone do procesów sekw encyjnych. p o d c z a T g d y j . H eramy czynność, potrafią ująć dodatkowo procesy w s p ó łb ie ż n y Jest ,o w a żn e p r z y m o d e lo w a n iu p r o c e s ó w b iz n e s o w y c h . P r z e d s ię b io r s tw a częsu, n ie p o trz e b n ie m a ją s e k w e n c y jn e p ro cesy. T e c h n ik a z a c h ę c a ją c a d o s to s o w a n ia w sp„ |. b ie z n o ś c i je s t b a rd z o cenna, b o z w r a c a u w a g ę n a m o ż l i w o ś c i w y k o n y w a n i a pew nych c z y n n o ś c i ró w n o le g le . M o ż e to p o p r a w ie w y d a jn o ś ć i s z y h k o s t p r o c e s ó w b i/n e s o .
wych. Diagram y czynności przydają się także w p r o g r a m o w a n i u w s p ó ł b ie ż n y m , w a zż um ożliw iają graficzne pokazanie w ą t k ó w i ich p o tr z e b s y n c h r o n iz a c y jn y c h Zawsze przy procesach współbieżnych je s t p o tr z e b n a s y n c h i o n i z a c j a . N ic zamknąć zamówienia, dopóki nie d o s z ło d o d o s ta w y i n ie z a p ł a c o n o za nią. zilustrować to złączeniem zaraz przed c z y n n o ś c ią Z a m k n ię c ie z a m ó w i e n i a padku złączenia do wyjścia ze stanu d o c h o d z i t y l k o w t e d y , g d y n a w e jś c iu
pome-
można M o żn a
W wy z a ko ń
czono wszystkie działania'. Rozwidlenia i złączenia muszą b y ć s p a ro w a n e . W n a jp r o s t s z y m w y p a d k u oznacza to, że za każdym razem, g d y jest r o z w id le n ie , to je s t p o t r z e b n e z łą c z e n ie łączące wszystkie wątki zapoczątkowane ty m r o z w id le n ie m . ( R e g u ł a ta w y n i k a stąd, że dia gram czynności jest rodzajem diagramu s ta n ó w .) Reguła ta ma jednak kilka rozszerzeń. • •
•
Wątek pochodzący z rozw idlenia sam może się r o z w i d l i ć , a n o w e w ą t k i m o g ą sic złączyć, zanim zostanie osiągnięty docelow y punkt z łą c z e n ia . Jeśli wątek pochodzący z rozw idlenia p r o w a d z i b e z p o ś r e d n io d o in n e g o r o z w id le nia, to drugie rozwidlenie może b y ć u s u n ięte, a w ą t k i z n ie g o w y p r o w a d z o n e mogą wychodzić z pierwotnego rozwidlenia. W ten s p o só b na r y s u n k u 9 .2 usunąłem rozw idlenie między czynnościami p r z y g o t o w y w a n i a j e d z e n i a a p i e r w s z y m r o z w i dleniem. Analogicznie, je śli z jednego z łą c z e n ia d o c h o d z i s ię b e z p o ś r e d n io do in nego, to można osunąć pierwsze złączenie i d o p r o w a d z i ć w ą t k i d o dru gieg o Dzięki temu skrótowi notacyjnemu ry s u n e k je s t b a r d z ie j p r z e j r z y s t y ; s e m a n ty c z n ie nic się nie zmienia. Bardziej złożona konstrukcja, nazywana s ta n e m s y n c h r o n iz a c y jn y m (a n g . synch state), um ożliw ia synchronizację w sytuacjach, w których reguła p a r o w a n i a ro zw idleń i złączeń zw ykle to uniem ożliw ia. Szczegóły zn a jd u ją się w p o d rę c z n ik u U M L -a [37] i standardzie U M L-a.
m ówiącej, że w szystkie stany w e jścio w e muszą zostać z a k o ń c z o n e , z a n i m d o j d z i e d o z ł ą c z e n i a . M ożna dodać w arunek do w ątku w y c h o d z ą c e g o z r o z w i d l e n i a . W e f e k c i e o t r z y m a się w ą te k w a r u n k o w y . W trakcie w y k o n y w a n ia , j e ś l i w a r u n e k w w ą t k u w a r u n k o w y m jest fa łszyw y, zakłada się, że z punktu w i d z e n i a z ł ą c z e n i a w ą t e k t e n j e s t z a k o ń c z o n y . Na rysunku 9.2, nawet jeśli nie mam o c h o t y n a w i n o , t o w d a l s z y m c i ą g u b ę d ę m ó g ł z j e ś ć spaghetti carbonara. (T utaj muszę p r z y z n a ć , z e w p o s t ę p u j ą c z g o d n i e z t y m d i a g r a m e m , n ig d y jeszcze nie testowałem tej Jest je d e n w y ją te k o d r e g u ły
W term inach sieci Petriego oznacza to, że z o s ta ły s p e łn io n e w s z y s tk ie w a r u n k i w e jś c ia zdarzenia (p rzy p . tłu m .).
9.1
Tory
D ia g r a m y c z y n n o ś c i m ó w ią , co się d zieje, ale nie m ó w ią, kto co robi. W w y p ad k u p ro g ra m o w a n ia o z n a c z a to, że d ia g ra m nie z a w ie ra inform acji, która klasa jest o d p o
wiedzialna z a
d a n ą czynność.
W w y p a d k u m o d e l o w a n i a d z ie d z in y oznacza to, że diagram nie zaw iera in fo rm a cji, kto je s t o d p o w i e d z i a l n y z a d a n e czyn n o śc i. Jednym ze sposobów obejścia tego jest oznaczenie k a ż d e j c z y n n o ś c i e ty k ie tą z a w ie ra ją c ą klasę lub osobę o d p o w ie d zia ln ą za czynność. Jest to s k u te c z n e , a le n ie d a je tej sam ej jasnosc, co d iag ram y interakcji ( z o bacz r o z d z ia ł 5 .) w w y p a d k u k o m u n ik a c ji m ię d z y o b iektam i.
Radą na
to s ą t o / y . A b y s k o rz y s ta ć z o ro w ,
ro zm ie ś c ić e le m e n t y d ia g r a m u w p i o n o w y c h s tr e .y
^
, o r d ia B r a m u r e p r e z e n t u je o d p o w i e -
fach przedzielonych iniam t ( pokazano na rysunku 9.3, konkretnego wydzialność konkretnej klasy lub, tak jak to poKaz. działu . t nnp rpnrezentację logiki procesu z diagramów czynZaletą torów je st to, ze łączą £ diagramów interakcji. M o g ą jednak byc ności z reprezentacją odpow ie / i niektórych diagramów. C zasam i stoirudne do narysowania ze wzglę 11 • ^ C zasam i po prostu nie udaje się sowałem nie całkiem proste tory ^ QI7rnmje umieścić w ielu in fo rm a cji n a jednym mg 7
T T . .. ń \w im la n e s łub sw im m er lanes ^ języku angielskim używa się okres c.
dosłownie to ry
P fy *tc k le (przyp. tłum.). 125
Niektórzy, rysując diagramy czynności, starają się od r a z u p r z y p i s a ć czynności obiektom. Inni wolą najpierw narysować diagram czynności, a b y m i e ć p o j ę c i e o całym procesie, a dopiero później przypisują czynności obiektom. Widziałem, ja k c i , którzy dokonują przypisania odpowiedzialności natychmiast, żywo r e a g u j ą n a t y c h . którzy odkładają to przypisanie na później potralią oni oskarżyć tych d r u g i c h o „n ie w y starczająco obiektowe podejście” .
P rzyzn aję,
że ja sam często rysuię „
przyp^uję odpowiedzialność obiektom. R o b r . i “ 8™"? « ^ » o fc i, a dopiero potem aeluję jakąś dziedzinę , zachęcam eksperta d „ P,''2Cde 'vszys>kit„ wtedy, gdy m ” TaklJest moj styl pracy. Niektórzy 0 now* ch * « < * * * U y . Naiezy samemu zdecydować, co jes, w l S o b i e k t o m natychmiast. saroym końcu mtec przypisane czynności aby na interakcji (zobacz rozdział 5.). som- Do tego wolę używać diagramów
9.2 J
Współbieżność dynamiczna Ć dy" “ " ' i C U m 0 Ż I ™ ia 2" " “
: P£ “
iteracji bez konieczności two-
9.4 czynność Realizacja pozycji zamówienia jest wykonywana no jednym ra z ie dla każdej pozycji zamówienia. Znacznik iteracji (*) oznacza zć czyn ność ,a je s t w ykonyw ana wtelokrotnie Przejście do Dostaw y jes, uruchamiane tylko wtedy, gd> z o s ta n ą \\\ko n a n e wszystkie pozycje zamówienia. Jeśli trzeba wykonać kilka c z y n n o ś c i naraz, to można to oznaczyć, tworząc z R e alizacji pozycji z a m ó w ie N a ry s u n k u
nia czynność z ło ż o n ą .
W s p ó łb ie ż n o ś ć d y n a m ic z n a
.
.
P rzyjęcie z a m ó w ie n ia
. . R ealizacja j--------- p o zycji I
\
* Dostawa
z a m ów ien ia
Rysunek 9.4. W spółbieżność dynamiczna
9.3
D e k o m p o z y c ja czynności
Czynność
h i t * n a n o d c z y n n o ś c i . Jest to z b liż o n e d o p o ję c ia s ta n ó w m o ż e byc r o z b ita n a p y M o ż n a pokazać stan złożony osobno na
łożonych i p o d s ta n o w na d ia g r a n c ‘lagranne w y ż s z e g o p o z io m u a n o 'nętrznym i, ta k j a k to z r o b iłe m
dj .
ram ie czynności w raz z elementami weq 5 . W om aw ian ym wypadku czynno-
na I7-»
ciom z w ią z a n y m z d o s ta w ą p r z y p ‘s‘‘ e
(ek , ko nicc. M o żn a także narysować '
niższego. Z a le tą jaw n ych początków
wejścia b e z p o ś r e d n io d o i z d ia g ran1’-' ^ j 0StavVą m ogą być używane w innych k o ń c ó w je s t to, ż e c z y n n o ś c i z w ią z a
Astach,
a
diagram
oziomu n iż s z e g o .
w y ż s z e g o p o z io m
on-
un jezależn io n y od zawartości diagram
U M L w k ro p e lc e
Rysunek 9.5. Zastosowanie czynności zlozonych d o d o s ta w y
9.4
Kiedy stosować diagramy czynności
Jak większość technik modelowania procesów diagram y czynności mają s w o je słast be i mocne strony, dlatego najlepiej ich używać wraz z in n y m i technikam i M ocną stroną diagramów czynności jest to, że u m o ż liw ia ją stosowanie procesów współbieżnych i zachęcają do tego. C zyni to z nich idealne narzędzie m o d e lo w a n ia
2*
D iagram y czynności
przepływu zadań i program owania w iel
^ « d z ia ln o fc i. mach interakcji (z o b a c z ro z d z ia ł 5 .) z teuo n
!
Jakl można "zyskać na diagra-
diagram ów c zy n n o ś c i nie j est W y s ta rc z tó c o I f y
” *
*
’ *
Uważam je d n a k , że ta tech n ika jest bardzo „ ° b'ektow e' 3 “ > 33 tym idzie, jest zle. datnych n a rz ę d z i. 1 20 P ł a t n a i że nie należy odrzucać przyL u b ię sto so w ać d ia u ra in v cyynnr^A'
.
^
,
l y
i T
z
akcji o b ie k to m — po prostu chce 7 r
z
-
kie są z a le ż n o ś c i
"
!
sy,uaqach:
t z i
zainteresowany przypisaniem
J * 1* akcJe mus^ być wykonane , ja -
p rzy p is a n ia za p o m o c ą d ia g ra m ó w interakcj!’ ™ " ' ° b'ekt° m pozniej ' P1* 32")? te Z r o z u m ie n ie p r z e p ł y w z a d a ń .Zanim nawet zajmę *
przypadkami użycia stosuje
d,agrarny c z y n n o ś c i, aby zro zu m ie ć procesy biznesowe. Ptóniej latwo^uż n T ry T wac, pracu jąc u r a z z ekspertem w danej dziedzinie, jaka jest sekwencja czynności i ja k j ą m o ż n a zrm e n ic . •
O p is a n ie s k o m p lik o w a n e g o algo rytm u sekwencyjnego. W tym wypadku diagram
Rozdział 9
.
czynności n ie je s t n ic z y m w ięcej niż zgodnym z notacją U M L - a diagramem opisu ją c y m a lg o r y tm
schem atem p rzepływ u sterowania. M a ją tu zastosowanie z w y
c zajo w e za i p r z e c iw dotyczące opisu algorytmu diagramem. •
A p lik a c je w ie lo w ą tk o w e . Osobiście nie stosowałem diagramów czynności w tym celu, ale s ły s z a łe m , że je st to przydatne. N ie n a le ż y u ż y w a ć d ia g ra m ó w czynności, aby:
•
Z o r ie n to w a ć się, j a k w s p ó łd z ia ła ją obiekty. Diagram interakcji jest prostszy i da
•
ja ś n ie js zy o b ra z w s p ó łd z ia ła n ia . Z o r ie n to w a ć się. j a k i j e s t c ykl życia obiektu. W tym celu należy skorzystać z dia
•
gram u s ta n ó w (z o b a c z r o z d z ia ł 8.). Z ilu s tr o w a ć z ło ż o n e w a ru n k i. N a le ż y zastosować tablicę decyzyjną. D ia g ra m y c z y n n o ś c i uściślono i doprecyzowano w w yniku prac nad wersją U
U M L -a
T o je d n o c z e ś n ie d obra i z ła wiadom ość. Problem p o le g a m , łym, *
diagramy są s to s o w a n e w m o d e lo w a n iu ^ o n c e jK jjn y jn , po prostu p rz e s z k a d z a . W ta k ic h W ponieważ w y s ta r c z y w ie d z ie ć , co
3
je z ę h K
stuprocemowo dokładnym.
N ic z a |eżnie od nastawienia i wysiłków
ę
J •
jest m ało p r a w d o p o d o b n e , a b y to, c o j .
^ m0£je|owaniu koncepcyjnym, było w v konać i przetestować samych dia-
°d razu p o p r a w n e , o ile o c z y w iś c ie mc
j ‘
z ^ „k ó w
nie »padają« tak jak
gramów. Jak m ó w i ł B e rtra n d M e y e r . „P r Prawdziwe s y s te m y ” .
k m ie ie standard dla diagramów stanów i dia-
2 drugiej s tro n y w z w ią z k u z ty m , gramów c z y n n o ś c i, tw ó r c y n a rzęd zi m a ją
P
podstawy do tworzenia narzę zi ż ljw i w y k o nywanie i testowanie
^ k o n y w a n . a ty c h d ia g r a m ó w . N a rz ę d z ia takie diagram ów
12*»
9.5
Dodatkowe źródła
Jest m a ło in fo r m a c ji o d ia g ra m a c h czynn ości. P o d rę c z n ik U M L - a [ 3 7 ] p o d a je wiele s zc z e g ó łó w , ale nie je s t p o d rę c z n ik ie m o p is u ją c y m , jak one d z ia ła ją . P o d rę c zn ik u żyt k o w n ik a [6 ] nie o d p o w ia d a na p y ta n ia , któ re są z w y k l e z a d a w a n e p r z y korzystaniu z tej te c h n ik i. P e w n ie ktoś n ie d łu g o w y p e łn i tę lukę.
Diagramy fizyczne
Rozdział
UML
udostępnia d w a ro d za je d ia g ra m ó w
fiz y c z n y c h '
-
d ia g r a m y
u < ó v ,,„ „ ,
i d ia g ra m y kom ponentów .
10.1
Diagramy wdrożenia
D ia g r a m w d ro ż e n ia p rzed staw ia fiz y c z n e p o w ią z a n ia
między
s k ła d o w y m i | , ( V ‘l
m is ty c z n y m i i s p rz ę to w y m i w d ostarczan ym system ie. D ia g r a m w u o z u i i a m iejsce na to, aby p okazać, ja k skła d o w e i o b ie k ty p o ru s z a ją s k po s.
o c o ik
km w
m
K a ż d y w ę zeł na d ia g ra m ie w d ro że n ia re p reze n tu je p e w ie n ro d z a j je d n o s tk i o b lic z e n io w e j —
w w iększości w y p a d k ó w e le m e n t s p rz ę to w y . S p r z ę te m m o ż e b y c proste
u rzą d ze n ie , c z u jn ik lub k o m p u te r centralny. R y s u n ek lO .l przedstaw ia k o m p u te r osobisty p o d łą c z o n y do s e iw e ia uni
sow i.go
za p o m o c ą p ro to k o łu T C P /IP . P o łą c z e n ia m ię d z y w ę z ła m i p o k a z u ją ś c ie ż k i k o m u n i k a c ji, które będ ą s łu ż y ły e le m e n to m system u do in te ra k c ji.
10.2
Diagramy komponentów
D ia g r a m k o m p o n e n tó w p o k a zu je ró żne s k ła d o w e s y s te m u i ich p o w ią z a n ia . K o m p o n e n t rep rezentuje je d e n fiz y c z n y m o d u ł k o d u s y s te m u . C zę sto k o m p o n e n t to je d e n p a kie t, ale zd arza się, że nie m a takiej je d n o z n a c z n e j o d p o w ie d n io ś c i, p o n ie w a ż k o m p o n e n ty re p re ze n tu ją fiz y c z n e m o d u ły k o d u. Jako ta k a je d n a k la s a m o ż e w ystępo w ać w w ie lu k o m p o n e n ta ch , natom iast m o ż e b y ć z d e fin io w a n a t y l k o w j e d n y m p a k ie cie. N a p rz y k ła d w ję z y k u Java klasa S t r i n g je s t c zę ś c ią p a k ie tu ja v a .la n g , ale p o ja w ia się w w ie lu ko m p o n e n ta ch . Z a le ż n o ś c i istniejące m ię d z y k o m p o n e n ta m i p o k a z u ją , j a k z m i a n y d o ty c z ą c e |edn eg o k o m p o n e n tu w p ły w a ją na inne. M o ż n a u ż y w a ć tu c a ł k i e m s z e r o k ie j g a m y z a le ż ności, w ty m zależn o ści k o m u n ik a c y jn y c h i k o m p ila c y jn y c h . Ja s a m c zę s to stosuję te z a le ż n o ś c i, aby p o k a za ć , któ re k o m p o n e n ty k o m u n i k u j ą się w z a j e m n i e .
10.3
Połączenie diagramów wdrożenia z diagramami komponentów
M i m o ze m o ż n a ry s o w a ć o d d z ie ln ie d ia g r a m y w d r o ż e n i a i d i a g r a m y k o m p o n e n tó w
to m o ż n a tez u m ie s z c z a ć d ia g r a m y k o m p o n e n t ó w na d ia g r a m a c h w d r o ż e ń , tak
w ę z ła c h
1 0 * 1, a b y P o k a z a ć , k tó r e k o m p o n e n t y d z i a ł a j ą w których
dręcznik notacji U M L - a n a zyw a d ia g ra m y fiz y c z n e im p le m e n ta c y jn y m i (p rz y p . tłum.)-
D iagram y fizyczne
T C P /ip
SaD^ ^ ź i ą l iL4akażn,-.n •Obiektowa baza danvrh Połączenie ^Dziedziną Ochrony Zdrow ia
/
fierwer D ziału d i a g n o s t y k i w . li,_,,h^ ¡Obiektowa baza danych
«komunikacja» Konfiguracja Działu diagnostyki wątroby ¡skonfiguruj wtcdrc medyczna iskanfiaiBii
— Konfiguracja
u ż y t k o w n ik ó w
O b ie k t w k o m p o n e n c ie
W ęzeł
1 i
1asada Klienta pziału dfjignnffiylci wal roby
Ai
Komponent
------—
¡Inlcrfeis LfżvtkQ wnika Dziahi diapnostvki watrohY
R ysunek
10.1. Diagram wdrożenia
p u w u w u Ł . ,v j
r» ;n v /.u « .iv ,
*
---------
ochrony zdrow ia: każda ze s k ła d o w y c h „ w i e ” , że k o m u n ik u je się z in n y m kom ponentem d zie d zin y o c h ro n y z d r o w ia , tak w ię c zależn ość k o m u n ik a c y jn a je s t tu taj dwustronna. Co w ię c e j, obie
je s t w k o m u n ik a c ji m ię d z y d w o m a k o m p o n e n ta m i d z i e d z i n y
s k ła d o w e d z ia ła ją na o d d z ie ln y c h w ę z ła c h . K o m p o n e n t m o że m ieć k ilk a in te rfe js ó w — w t a k im
w ypadku można z o i ic n to w a ć się, k tó ry k o m p o n e n t k o m u n ik u je się za p o m o c ą k tó r e g o in terlejsy. N a r y s u n k u 10.1 a p lik a c ja D z ia łu d ia g n o s tyk i w ą tro b y m a d w a in te rfe js y . Jeden z n ich j e s t w y k o r z y s t y w a n y p rz e z fasadę a p lik a c ji d z ia ła ją c ą na k o m p u te r z e osobistym , a d r u g i — p rz e z k o m p o n e n t k o n fig u ra c y jn y d z ia ła ją c y na s erw e rze.
ochrony zdrow ia, j e s t n ie w id o c z n e d la j e j k lie n tó w . K a ż d y k o m p o n e n t d z ie d z in y ochrony zd ro w ia ma lo ka ln ą bazę T o , że stosuje się k ilk a k o m p o n e n tó w d z ie d z in y
danych.
sym boli p r z y p o m i n a j ą c y c h p o s zc ze g ó ln e e le m e n ty . N a p rz y k ła d stosuje się s p e c ja ln e iko ny dla s e r w e r ó w , k o m p u t e C zę s to te d ia g ra m y są ry so w a n e z w y k o r z y s ta n ie m
r ó w osobistych i baz danych. U M L to d o p u s zc za , bo k a ż d ą ik o n ę m o ż n a tr a k tó w ić
są bardziej z r o z u m i a l e Jed n a k nie w y g lą d a to n a jle p ie j, je ś li na je d n y m d ia g r a m ie przedstawia się z a r ó w n o w ę
j a k o stereotyp e lem e n tu d ia g ra m u i d z ię k i te m u d ia g r a m y
z ły , j a k i k o m p o n e n ty , tak j a k to z r o b iłe m na ry s u n k u 1 0 .1 .
10.4
Kiedy stosować diagramy fizyczne
W ię k s z o ś ć lu d z i rysu je d ia g r a m y , n ie stosując o k r e ś lo n y c h z a s a d , a le
' */ t/0/>
•
i
A ” **'* _ —i ' ‘
•
•
r t » * r
»
powodują z b y tn ie g o p r z e ła d o w a n ia d ia g ra m u .
UML i programowanie
Rozdział 11
• , ń w iłe m o notacji. Pozostaje pytanie, w j a k . sposob program isl, Dotychczas w iele m ó w iłe m o p ra cy ? Mogę je d y n ie p o w ie d zie ć . ,.lk tak naprawdę używ a U M L - a v.
m a ły c h p r o g r a m cnv
N ie będę wxh(Kl/i|
u ży w am U M L - a w trakcie m o żna z r o b i ć z U M L - e m . w szczegóły, ale p°k^ac> e z a p r o je k to w a n y do zbierania Przykładem mech będzie system Komp in s
p
r
ó
b
u
j ę
form acji o pacjentach szpitala
obserw a c je d o ty c z ą c e pacjen tów . System
W ie lu pracow ników szpita a za^ L “
z
k l a pa^ k t d
d a n y c h .
. Qsobie d o ta rc ¡e d o ty c h inforinacu i do że jest ,o k ró tk a
książka, n ie M v o m aw ia, ime
In te rfe js ó w u ż y tk o w n ik a itp.. t y l k o z a jm ę s,ę p o d s t a w o w y
teńTest tak prosly,
że m a ty lk o je d e n p rz y p a d e k u ż y c ia p r z e j r z y j i
pełnij obserwacje dotyczące pacjenta. Można go
ro z s z e rzy ć o k ilk a scenariuszy.
•
Poproś o najnowsze dane o pulsie pacjenta.
• • •
Poproś o grupę krw i pacjenta. Z aktu alizu j stan przytomności pacjenta. Z a ktu alizu j puls pacjenta. System k lasyfiku je puls j a k o s z y b k i, m u m a ln \ lub wol ny, zależnie od wbudow anych zakresów. M o im pierw szym krokiem jest w y m y ś le n ie m o d e lu k o n c e p c y jn e g o opisującego
pojęcia dziedziny. N a tym etapie nie m yślę, j a k b ęd zie d z ia ła ło o p ro g ra m o w a n ie , lecz koncentruję się na organizacji pojęć, k tó ry m i o p e ru ją le k a rz e
i p ie lę g n ia r k i Rozpoczy
n am od m odelu opartego na k ilk u w zorcach a n a lity c z n y c h z [ 1 8 ] : O b s e r w a c ja , Ilość, Z a k r e s oraz Z ja w is k o z Z a k r e s e m
11.1
Obserwacja pacjenta - model dziedziny
Rysunek l l . l pokazuje wstępny m odel d z ie d z in y d la o m a w ia n e g o systemu. Jak te pojęcia reprezentują in fo rm acje z d z ie d z in y ?
Należy zacząć od prostych pojęć Ilość, Jednostka . Z a k re s Ilość reprezentuic wartość w pewnych jednostkach, na przykład 180 centym etrów - wartość ISO. jed nostka: centymetr Jednostki są po prostu kategoriami m iary. Z a k re s umożliwia po 'In tZ T r ó w V
centymetra
3 ir«n em Jh ° PT
do 180
dyncZy m P ° - * c ie m na p r z y k ł a d zakres od I2( centymetrów jest re p re z e n to w a n y j a k o je d e n o b ie k t Z a kre
CCnr
C,rÓW 1 d0,ny'” ograniczeniem .20 centymem*
nywać, stosując relacje < > <= > ™ ^ = d? T ° lnyCh o b ie k t6 w ’ które można Poró'v kresu są wielkościami. Ilość' jest radzą,cm w i e lk n I T ^ ^ °S raniczenia U Każda czynność dokonana przez lę k a m l S ^ ............................................... serwacja i jest albo P o m ia r e m alh n i, P , e *ę g n ta rk ę je st in s ta n c ją pojęcia 01' osoby o imieniu i nazwisku Martin F serwac ją k a te g o rii. Zatem pomiar wzrost zentowany jako instancja Pom iaru / ^ U Z w y n ' k ' em 180 centym etrów będzie reprc tym pomiarem jest z w i ą z a n a w ie lk o ś ć ISO cci
U M L i programowanie
g e t r ó w . T y p z ja w is k a wzrost oraz P acicnt
Tvpv * j « w is k
f = P « “ n tu ją rzeczy, które raoEa bvć
™‘" ” U '
na2wisku M * t m Fowler. mierzone: wzrost, wnon m .ic ....
-----• I, . T y p z ja w is k a
Z ja w isko
-—■
0..1
■
--------★
zakres: Zakres
i
P o m ia r
O bserw acja kategorii
O b s e rw a c ja
i>
ilość: Ilość
<
istnieje: Boolean
kategoria «dynamiczna»
pomiar
P a c je n t
Je d n o stk a
Z a k re s
Ilość ańra* Wielkość tlośc: L iczb a
dół: Wielkość
jednostka: Jednostka
. , , . M o d e l dziedziny o b s e rv e d ! paciente R ysunek
137
* ,,r „ n e k rw i O, będzie re p re ze n to w a n e |a k o OI>sm v T o , że M artin F o w le r ma g rip ę Ro a k rw i 0 Z ja w is k o to Jest , k l ) ‘ k a te g o r ii, z którą związane jes j
związane z T y p e m z ja w is k a g ru p «
^ A b y w pełni zrozum ieć tę sytuację, w«u
sp0,rzeć na d ia g ra m o b ie któ w , lvsun r
ku 1 1.2.
trnipa k r w ii ly ^ z ią y n s k ą gruna k rw i 0 Z ja w is k o
PÖE liar ilość = 180 cm M a rtin Fow ler: Pacient
Rysunek 11.2. Diagram obiektów do obserwacji pacjenta
Rysunek 11.3 pokazuje, że O b s e r w a c j ę m o żn a tra k to w a ć z a r ó w n o ja k o Pomiar, j a k i O b s e r w a c j ę k a t e g o r i i , zakładając, że P o m i a r pu ls 9 0 na m i n u t ę m oże być tak że O b s e r w a c j ą k a t e g o r i i , z k tó rą je s t stow arzyszone Z j a w i s k o p u ls s z y b k i . N a tym etapie przyglądałem się w y łą c zn ie rep rezen tacji p o ję ć ; nie poświęcałem dużo czasu m yśleniu o procesie. N ie zawsze to robię, ale w y d a je się, że jest to właści w y p u nkt startowy w w ypadku problem u z w ią z a n e g o g łó w n ie z p rz e tw a rz a n ie m infor m acji. N a razie ciągle o m a w ia m p o ję c ia dotyczące o b s e rw a c ji p a c je n ta , tak jak robi to le k a rz lub pielęgniarka. ( W rzeczywistości te m o d e le k o n c e p c y jn e zo s ta ły zbudowane p rz e z paru lekarzy i pielęgniarkę
ja ty lk o p o m a g a łe m .) A b y d o k o n a ć przejścia do
p ro g ra m u obiektow ego, muszę zd e cy d o w a ć,
jak
p o tr a k to w a ć
m odel
koncepcyjny
w term inach oprogram ow ania. Do tego w y b ra łe m j ę z y k p r o g r a m o w a n ia Java. W ię k szo ś ć z tych pojęć dobrze tłu m a c zy się na k las y J a v y
P a c j e n t T v p zjaw iska.
Zjawisko. Jednostka
przy
i Ilość nie s p ra w ia ją ża d n y c h k ło p o tó w . K ł o p o t y p o ia w .a j, * Z a k r e s ie i O b s e r w a c ji.
b
byC P r0 b le m e m ’ P ° n ,e w a ż chcę m ie ć z a k re s y w ie lk o ś c i dla Z ja w i ska. M ó g łb y m to osiągnąć, tw orząc interfejs wielkość i m ówiąc że Ilość im plem entu je ten interfejs, ale to s p o w o do w ałob y l. » y w ią e , ze u u s c t się w S m a llta lk u , a w C + + m ożna s t o s o w i
° nWCrSJI t y p o w ' P r o b le m ten nie P° '
m a w o lę u żyć klasy Ilo ś ć Z a k re s k o rz v s ta h ^ S p a ra m e try z o w a n e Korzystającej z w z o r c a Z a k r e s .
D o teg0
" K
Rysunek 11-3. Jeszcze ¡eden
d i a g r a m
obiektów d0 obserwac'' P3^®013
O b s e r w a c j ą p o le g a na ty m . że O b s e rw a c ja mozc byc M o j p ro b le m z O t o n « « » P m ^zobacz rysunek I I .3). W ^
O bserw acją k a t e g o r i i i Pom języków p r o g r a m o w a n ia
je s
k | a s y fikacja pojedyncza. y
Po_
j j m ie ć stowarzyszone "
lem e n tację obu pojec -
tyce umożliwia k la s ie O b s e r w a J<
J
c o w p r a k\
i O b ser-
O b s e rw a c j ny m i kom prom i
są p r a g m * ^ " * ™ ramowania. Decyzje te nie prowadzą do s a ^ na|cży . Nie trzeba zgodnie z mo*»"« um ożliwiającym i zrobienie b . l ocyjny. Należy tylko pos *,p toóre dokładnie pokryw a mode ° dostępne narzędzia. ^lem k o n c e p c y jn y m i b ra ć po 11w ta c ja k a t e g o r ii.
j
, nll do sko nałego, ale
Rozdział 11
sob,e z ty m . p o z w a la ją c kazdeJa
.
¡o n a c i e n t a -
1 1 .2
O b s e rw a c ja p3 i
m odel specyfikacyjny
■ • « , zmiany, które zro b iłe m w modelu dziedziny, aby Rysunek U . 4 odzwierciedla / n docelo w eg o języka programowania m odeiem na p o z io m ie specyfikac,. Akcent niektóre z elementów związanycn z y M odel obserwacji pacjenta |ts jest położony na interfejsy klas a
^
k ,asy j a ko takie. M ó g łb y m zachować nu,dcl bardziej p ra w d op o do bn e, ze od tej chwil,
koncepcyjny na wszelki w W ade* ' V;n vm staram się nie p o słu g iw ać zbyt wielonia będę pracował z modelem spetyfi . yj ^ bieżąco uaktualniać jakiegoś mo. modelami naraz.. Stosuję regułę, ze jeśli delu, to go po prostu wyrzucam.
Rysunek 11 .4 . Model specyf,kacy,ny obserwacji p a c ie n ta
Spojrzę teraz na z a c h o w a n ie zw iazan pierwszy scenariusz żąda podań,a a k t u a l ^ ' ™
określ,c.
które
d o ty c z . T y p u Z j a w i ć
“ b“ ™ acji pacjenia
sP»irzeć „a w s z y T k i e T b a e ™ ^ '
„siągnąc. będę m u siał dodać punk, w
,
iic również do innych o b serw acji, dodam „o Podobne z o b o w ią z a n ie p o ja w ia sie ii y
■ 1 P«lac najświeższą wartość. Aby to PonkM™ 4 0 ° bserw acji.
kategorii, która dla danego T y p u z j a >vi, L
^
toodno-
N iw ie ż s z ą Obserwację
Rysunek ,1 .5 p o k a z u je operacje, które
Z ja w is k o
Obserwacja 0..1
* punktWCzasie
zakres: llo ś ć Z a k re s
ostatnit Idczyl (Typ Zjawiska): llosc znaw iakoTypu (T yp Zjawiska): Zjaw islw
H y s u m * 1 i 5 O p e ra c ,. o bse iw a cll P a c |.n ta
Nie warto na silę w y m y ś l opera^ 1, 00 ¿ ^ j e ^ r L i ć w p o ł a c i operacji, u, s u ^ ,' rzeczą jest określenie zobowiązań. Jesl definiujący, me: w przeciwnym wypadku wystarczy
o
'
„ tw o rz e n ia now ej O bserw acji z w y k le w y b ie ra Z j a w i s k .............
Aktualizacja stanu
z ia ,,is k a
tmpltkowane za pom oc, * o c ,a c ,i ^
.
S
K
S
i
p o m ia r t
Ł
~
i o s i 10
P o ja w ,a się tu dodatkowa
c / y istnieje Z ja ss isk tt. które ,„o z,,........
przypisać. W tym wypadku P om iar może zaządac od zw ią z a n e g o i
pu ¿ ja w ,-
ska znalezienia odpowiedniego Z ja w is k a . Można powiedzieć, że w pewnym sensie o b ie k t\ w spo pra«. m.i okazja do tego, aby użyć diagramu sekwencji (zobacz rysune
).
Czy trzeba rysować wszystkie te diagramy? Niekoniecznie. Wiele zależv nH u ^ * k o w n i k p o tra fi w y o b r a z ić sobu- k .1 Pr«>sramowania. W Sm alltalku w w ielu w y p a d k *
sytuację i przełożyć j ą na iezvk n m
y )ł
Język
’ ^
U M L i program ow anie
fówTiie łatwo pisze się kod, ja k rysuje diagranw w 4 się diagramyy' wypadku Diagramy nie m uszą być dziełami sztuki Zwvki. b|icy. Przenoszę j e p o te m d o p r o g r a m u u r a f ir ™ , 7, Sf “
s,ę. ze w a r t o j e u a k t u a ln ia ć . N a Z
Opnisanych w tym
11.3
S ie
" f
u-
C++ bardziej przydają
• Uę -,e na PaPierze lub na ta-
' b " arZ* d M C A S E | - ^
" y **
r o z d z ia le , s to s u ję te z k a n y t R C 'z o S S o n a ^ s T '“ ' d “ ®n " " 6 w
Przechodzenie do kodu
My Zna {eTnń T P° jreeC na i ° d ’ klÓry imPlementuje pomysły przedstawione wcześ niej. Zacznę od T y p u z ja w is k a i Z ja w is k a , bo są one dość ściśle powiązane Pierwsza rzecz to asocjacja między nimi - czy interfejs powinien dopuszczać przej ść,a w obu kierunkach W tym wypadku myślę, że tak, bo będą one potrzebne, a poza tym są dość ściśle pow iązane pojęciowo. Nie sprawia mi kłopotu implementowanie asocjacji za pom ocą dw ukierunkow ych wskaźników. Z lej jednak uczynię asocjację niezmienną, poniew aż obiekty' w niej występujące są utworzone i potem nie zmieniają się często — je śli zm ian a jest potrzebna, to obiekty można utworzyć na now'o. Często p o w iązania w obu kierunkach sprawiają problem. Dla mnie nie są kłopo tliwe, o ile zatroszczę się o to, aby jedna klasa przejęła na siebie zobowiązanie aktuali zacji powiązania, w m iarę potrzeb z pomocą przyjaciół lub metod pomocniczych. Warto przyjrzeć s ię deklaracjom. public class T y p Z jaw is ka extends ObiektDziedziny { public T y p Z ja w is k a (String nazwa) { super (nazw a); }; void d od a jZ jaw is ko (Z jaw is ko noweZjawisko) { / / O G R A N I C Z E N I E : m e t o d a u ż y w a n a w y łą c z n ie p rz e z Z ja w is k o z ja w i s k a . a d d E le m e n t ( n o w e Z ja w is k o ) ,
}:
“
public void ustaw Zjaw iska/StringQ nazwy) { fo r (in t i = 0; i . nazwy.length; i+ + ) n e w Z ja w is k o (n a zw y [i], this);
public E n u m e ra tio n p h e n o m e n a/) { re tu rn zjaw iska.elem ents/), }; private V e c to r_ z ja w is k a = n e w V e c to r/), private
HoicZakres_poprawnyZakres;
}
141
S to s u ję , u k o n w e n c ję d o d a w a ń ,a znaku podkreślenia p r z e d n a z w a m i p 6 l . ^
mi to ro ze z n a ć się w n a z w a c h p u b lic class Z ja w is k o e x te n d s O b ie k c D z ie d z ^ y { public Zjawisko(String nazwa, TypZ|awiska yp s u p e r (n a zw a ); _ t y p = ty p ;
_typ.doda|Zjawisko(this); }; private TypZjawiska _typ; p r iv a t e llo ś ć Z a k r e s _ z a k re s ;
} p acka ge o b s e rw a c je ; p u b lic class O b ie k t D z ie d z in y { p u b lic O b ie k t D z ie d z in y ( S t r in g n a z w a ) { _ n a z w a = nazw a;
}: p u b lic O b i e k t D z i e d z i n y ( ) {}; p u b lic S trin g n a z w a () { re tu rn _ n a z w a ;
}; p u b lic S tr in g to S t r in g Q { r e tu r n _ n a z w a ;
};
p ro te c te d String__nazwa = "bez nazwy"; }
m agane od wszystkich klas dziedziny.
Zna n a z w y 1 im p le m e n tu je zacho w anie wy
Teraz mogę utwotzyć obiekty, stosując kod podobny d o p o d a n e g o . T y p Z ja w is k a pleć = n e w T y p Z ja w is k a C p łe O .z a p a m ie ta iO S tr .n g Q p łc i = { m ę z c z y z n a " , " k o b i e t a " } ; s e x . s e t P h e n o m e n a ( p lc i) ;
ra o ^T się *d o ^i^g ^o d w o la ^D Ó ^n ?^ ^ TyP zja w iska w obiekcie-rejestrze, tak ab) góły pominę. Ie * za P°mocą s ta ty c z n e j m e t o d y pobier/O
Dalej wstawiam kod dodający obscrwacc ,„ r
"
—
P public O b a e r w a c ją ^ ^ ^ ° b^ ' D2'edziny { Pacjent pacjent. D a ta data) { -ziaw isko = d an eZ jaw isko-
I
*°-
^ o k d 0 d a i0 b s e T O a c i ^ « ) ; _ d a ta O b s e r w a c ji = data*
p riv a te Z ja w is k o _ z ja w is k o ;
p riv a te D a t a _ d a ta O b s e r w a c ji;
} public class P a c je n t e x te n d s O b .e ktD zie d zin y { public P a c je n t(S trin g n azw a) { s u p e r(n a z w a ): }; void d o d a jO b s e r w a c |e (O b s e r w a c ja nowaObserwacja) { _ o b s e rw a c je .a d d E le m e n t(n o w a O b s e rw a c ja )}: p riv ate V e c t o r _ o b s e r w a c je = n e w V e c to r(); } M ając to, m o g ę u tw o r z y ć obserw acje, new P a c je n t(" A d a m s k i" ).z a p a m ię ta j(); new O b s e r w a c ja (T y p Z ja w is k a .p o b ie r z ( płeć ). z j a w i s k o O N a z w i e f m ę ż c z y z n a " ) . P a c je n t . p o b ie r z ( " A d a m s k i )
n e w D a ta ( 9 6 , 3. 1 ) ) ;
class T y p Z ja w is k a {
.
p u b lic Z j a w i s k o z j a w i s k o O N a z w i e ( S t r i n g n a z w a ) { E n u m e r a tio n e = z ja w is k a (); w h ile ( e .h a s M o r e E le m e n ts O )
{
Z ja w is k o
if
kolejne = (Zjawlsko)e.nextElement();
(kolejne.nazwa().equals(nazwa)) return kolejne;
-------- -
re tu rn null; } P o u tw o rz e n iu obserw acji p o w i n i e n e m m ó c z n a l e ź ć n a jn o w s z e z ja w is k o ,
c la s s P a c je n t p u b l i c Z j a w i s k o z ja w is k o T y p u (T y p Z ja w is k a t y p Z j a w i s k a )
{
r e t u r n ( n a jn o w s z a O b s e r w a c ja ( ty p Z ja w is k a ) = = n u ll ? n e w Z j a w i s k o P u s t e ( ) : n a jn o w s z a O b s e rw a c ja (ty p Z ja w is k a ) .z |a w is k o ( ) );
} p r iv a te O b s e rw a c ja n a jn o w s z a O b s e rw a c ja (ty p Z |a w is k a w a r to ś ć ) { r e t u r n n a j n o w s z a O b s e r w a c j a N a L i ś c i e ( o b s e r w a c j e T y p u (w a r to ś ć ));
} p r i v a t e E n u m e r a t i o n o b s e r w a c j e T y p u ( t y p Z j a w i s k a w a rto ś ć ) { V e c t o r w y n ik = n e w V e c to r( ) ; E n u m e r a tio n e = o b s e rw a c je () ; w h ile (e .h a s M o re E le m e n ts O )
{ O b s e r w a c j a k o l e j n a = ( O b s e r w a c j a ) e .n e x tE le m e n t(); if ( k o l e j n a . t y p Z j a w i s k a ( ) = = w a r t o ś ć ) w y n ik .a d d E le m e n t(k o le jn a );
}; r e t u r n w y n ik .e le m e n ts ();
} p r i v a t e O b s e r w a c j a n a j n o w s z a O b s e r w a c j a N a L i ś c i e ( E n u m e r a t i o n lis ta O b s e rw a c ji) { if ( !lis ta O b s e r w a c ji.h a s M o r e E le m e n ts ( ) ) r e t u r n n u li; O b s e rw a c ja w y n ik = ( O b s e r w a c ja ) lis ta O b s e r w a c ji.n e x tE le m e n t( ) ; if ( !lis ta O b s e r w a c ji.h a s M o r e E le m e n ts ( ) ) r e t u r n w y n ik ;
do { O b s e r w a c ja k o lejn a - ( O b s e r w a c j a ) l i s t a O b s e r w a c j i . n e x t E l e m e n t ( ) ; if (k o le jn a .d a ta O b s e r w a c ji().p ó ź n ie js z a (w y n ik .d a ta O b s e r w a c ji()))
w y n ik = kolejna; }
w h ile (lis ta O b s e rw a c ji.h a s M o re E le m e n ts Q );
return wynik; }
U M L i programowanie
dass O b s e r w a c ja public T y p Z ja w is k a ty p Z ja w is k a () { r e t u r n _ z ja w is k o .ty p Z ja w is k a ();
Aby to osiągnąć, trz e b a p o s łu ż y ć sie kilir pan. aby to p o k a z a ć , a le z w y k l e ,eg0 „ ie Z * ™
*
*
■
"
*
"
*
■
'
*
*
«
“ “
* * -
i™
M o żn a narysować dla
.
public class P o m ia r e x te n d s O b s e r w a c ia { p u b lic P o m ia r (Ilość ilość, TypZjawiska typZ,aw,ska
Pacjent pacjent, Data data) { in ic ju j (p a c je n t, data); ilo ś ć = ilo ś ć ; _ ty p Z ja w is k a = ty p Z ja w is k a () { }:
p u b lic T y p Z ja w is k a ty p Z ja w is k a () { r e tu r n _ ty p Z ja w is k a ; }:
p u b lic S trin g to S tr in g ( ) { r e tu r n _ ty p Z ja w is k a +
" + J lo ś ć ;
};
p riv a te Ilo ś ć ilo ś ć ; p riv a te TypZjaw iska_typZjaw iska, }
class O b s e r w a c ja
. . p r o te c te d v o id in ic ju j( P a c je n t pacjent, Data data) (
pacjent.dodajObserwacje(this); d a ta O b s e r w a c ji = data;
im klasy bardzo pomag omiar. Mc Z
ić osutnlOdczytiTypZjąwiska w a r » ś ć ) {
r e t u r n ( ( o s ta tn iP o m ta r r w n r to s c n e w P u s ta llo ś ć ( ) :o s ta tn iP o m ia r ( w a r t
,
p riv a te P o m ia r o s ta tm P o m ia r(T y p Z ja w is k a w a r to ś ć ) { if (n a jn o w s z a O b s e rw a c ja (w a rto ś ć ) = = n u ll) r e tu r n n u ll; if (!n a jn o w s z a O b s e rw a c ja (w a rto ś ć ).je s tP o m ia re m ()) r e tu r n n u ll; r e t u r n (P o m ia r)n a jn o w s z a O b s e rw a c ja (w a rto ś ć ); } W o b u w y p a d k a c h d ia g r a m k la s y p o d p o w ia d a p o d s t a w o w ą s tru k tu rę . I rz e b a dodać k o d , a b y m ó c w y k o n a ć b a rd z ie j z ło ż o n e z a p y ta n ia . N a t y m e ta p ie m o ż n a b y opisać to , co się d z ie je ze s p e c y f ik a c y jn y m d ia g ra m e m k la s , t a k im j a k n a ry s u n k u 11.7. le n
d ia g r a m
f a w o r y z u je in te rfe js k o s z te m im p le m e n t a c ji.
R o lę o d s tro n y
Iy p u
z ja w is k a z a m o d e lo w a łe m j a k o ro lę k w a l i f i k o w a n ą , p o n i e w a ż je s t to p o d s ta w o w y in te r fe js I y p u zja w iska . A n a lo g ic z n ie z a z n a c z y łe m , ż e O b s e r w a c j a je s t p o w ią z a n a z T ypem zja w iska , p o n ie w a ż is tn ie je in te rfe js m ię d z y n i m i , m i m o że p o m i a r jest j e d y n y m o b ie k t e m , k tó r y m a b e z p o ś re d n i w s k a ź n ik do Z j a w i s k a . P a trz ą c na ten d ia g ra m , m o ż n a z a u w a ż y ć , że j e d y n ą r ó ż n i c ą m i ę d z y
P o m ia re m
t O b s e rw a c ją je s t to, że P o m ia r m a m ia rę w ie lk o ś c i. M o ż n a b y c a ł k o w i c i e usunąć k la s ę P o m ia r z m o d e lu s p e c y fik a c y jn e g o , d o p u s z c z a ją c d o te g o , a b y d o w o l n a o b s e r w a c j a m ia ła ( b y ć m o ż e p u s tą ) m ia r ę w ie lk o ś c i. M o ż n a b y te ż z a c h o w a ć o s o b n ą k las ę
P o m ia r w r a z z p o l a m i ilo ś ć i ty p z ja w is k u .
a le ta k , a b y n ik t sp o za p a k ie tu n ie w i e d z i a ł o j e j is tn ie n iu . W ó w c z a s do O b s e r w a c j i a lb o d o
P acjenta n a le ż a ło b y d o d a ć m e to d y w z o r c a F a c to r y [ 2 0 ] , ta k a b y u m o ż l i w ić
u t w o r z e n i e o d p o w ie d n ie j k la s y . Z m i a n y te p o z o s ta w ię j a k o ć w ic z e n ia d la C z y t e l n i k a i p r z e jd ę d o a u to m a ty c z n e g o p r z y p is a n ia
Z ja w is k a do P o m ia ru .
R y s u n e k 11.7 ilu s tru je o g ó ln ie c a ły p roces. N a j p i e r w tr z e b a d o d a ć w y w o ł a n i e k o n s tr u k to r a
P o m ia ru .
class P o m ia r p u b lic P o m ia r (Ilo ś ć ilo ś ć , T y p Z ja w is k a ty p Z ja w is k a , P a c je n t p a c je n t. D a ta d a ta ) { in ic ju j (p a c je n t, data); J l o ś ć = ilo ść ; „ t y p Z ja w is k a = ty p Z ja w is k a ; _ z ja w is k o = z n a jd ź Z ja w is k o D la ( J lo ś ć ) ;
Zadanie to je st delegowane T y p o w i z ja w is k a . c la s s P o m i a r
p u b lic Z ja w is k o z n a jd ź Z ja w is k o D la ( llo ś ć a rg ) {
return _typZjawiska.zjawiskoZawierające(arg);
P o m ia r ilość: Ilość
0..1 V Z ja w is k o O b s e rw a c ja
zakres; IlośćZ akres punkt w czasie
0..1
P a c je n t
o s ta tn iO d c z y t ( T y p Z ja w is k a ): Ilość Z ja w is k o ( T y p Z ja w is k a ): Z ja w is k o
R y s u n e k 1 1 .7 . A lte rn a ty w n y m o d e l s p e c y flk a c y in y o b s e rw a q i paciania
T y p z j a w i s k a p r z e c h o d ź le r a z p o k o le i w s z y s lk ie z ja w is k a .
class T y p Z ja w is k a
... . . , p u b lic Z ja w is k o z ja w is k o Z a w ie r a ją c e ( os
v
,
E n u m e r a t io n e = z ja w is k a (), w h ile ( e .h a s M o r e E le m e n ts O ) ^
, •
/ r i a w i s k o ) e . n e x t E le m e n t ( ) ;
Z ja w is k o k o le jn e - (Z ja w is K i f ( k o le jn e . z a w ie r a ( a r g ) )
j
re tu rn kolejne; }: r e tu r n nuli; } class Z ja w is k o public b o o le an z a w ie ra (Ilość arg) { r e tu r n (_ za k re s = = nuli ? false: _ za k re s .z a w ie ra (a rg )); } K o d ła tw o w y n ik a z d ia g ra m u s ekw encji. N a co d zie ń stosuję d ia g ra m y sekw encji do n a s z k ic o w a n ia z grubsza in te rak c ji, do k tó ry ch p o tem w p r o w a d z a m
kon ieczn e
z m ia n y w tra k cie k o d o w a n ia . Jeśli interakcja jest w a ż n a , to je d n o c z e ś n ie u a k tu a ln ia m d ia g ra m s e k w e n c ji, k tó ry staje się częścią d o k u m e n ta c ji. Jeśli w y d a je m i się, że d ia g ra m s e k w e n c ji nie w nosi nic specjalnego do w y ja ś n ie n ia k o d u , to o d k ła d a m je g o szk ic na p ó łk ę. T e n k ró tk i p rz y k ła d p o k a zu ją c y , j a k stosować U M L w p o łą c z e n iu z j ę z y k i e m p ro g r a m o w a n ia , p o w in ie n dać n iezłe pojęcie o c a ły m procesie. N i e trze b a brać u d zia łu w w y s o c e s fo rm a liz o w a n y m p ro je k c ie , aby o d k ryć z a le ty te c h n ik U M L - a . N ie trzeba stosow ać całego U M L - a , w y s ta rc z ą ty lk o te e le m e n ty , które są n a p r a w d ę p rz y d a tn e N a s z k ic o w a n ie całego p ro je ktu za p o m o c ą d ia g ra m ó w klas i d ia g r a m ó w in te ra k c ji m o ż e p o m ó c u p o rz ą d k o w a ć m y ś li i u ła tw ić k o d o w a n ie . T r a k tu ję te szkic e j a k s zyb k ie d o w y k o n a n ia p ro to ty p y . N i e trzeba p o tem trz y m a ć się ściśle d ia g r a m ó w , ale m o g ą się one p rz y d a ć p rz y p ró b ie z ro z u m ie n ia kodu. N i e p o trze b a też w y ra fin o w a n e g o i d ro g ie g o n a rz ę d z ia ty p u C A S E . T a b lic a i e d y to r g r a fic z n y w z u p e łn o ś ci w ystarczą. O c z y w iś c ie , is tn ie ją p rz y d a tn e n a r z ę d z ia C A S E i je ś li b ie rz e się u d z ia ł w w ię k s z y m p ro je k c ie , to m o ż n a r o z w a ż y ć ich za s to s o w a n ie . Jeśli b ę d z ie trzeba użyć n a rzę d zia C A S E , to n a le ż y p o r ó w n a ć j e z s y s te m e m p o d s ta w o w y m z ło ż o n y m z e d yto ra g ra fic zn e g o i e d y to ra te k s tó w . ( N a p r z y k ła d z a s k a k u ją c o w ie le m o ż n a osiągnąć z V is io i W o r d e m .) Jeśli w y b r a n e n a r z ę d z ie m a g e n e ra to r k o d u , to w a rto p r z y jrz e ć się d o k ła d n ie , j a k ten k o d jest g e n e r o w a n y . G e n e r o w a n ie k o d u w y m u s z a na n a rzę d zia c h C A S E b a rd z o s p e c y fic zn e in te rp re ta c je d ia g r a m ó w , co w p ł y w a na sposób, w j a k i są one ry s o w a n e , i na ich s e m a n ty k ę . W ię c e j in fo r m a c ji
o tym przykładzie można znaleźć na moich s tro n a c h W W W
( h t t p : / / o u r w o r l d . c o m p its c rv e .c o m /h o m e p a g e s /M a r t in _ F o w le r ).
W e r s ja
ta m
p rze d s ta
niektóre zagadnienia dotyczące różnych w a r s t w m o d e lu i d o p r o w a d z e n ia g o do p o z io m u interfejsu użytkow nika systemu. w io n a o m a w ia d o k ła d n ie j
Techniki i ici stosowanie
Technika
Cel
D ia g ra m czynności
P o k a z u je proces w r a z ze s tr u k tu r a m i s te r u ją c y m i. M o ż e z ilu s tr o w a ć k ilk a o b ie k t ó w w r a m a c h k i l k u p r z y p a d k ó w u ż y c ia , k ilk a o b ie k t ó w w ra m a c h je d n e g o p r z y p a d k u u ż y c ia lub im p le m e n ta c ję m e to d y .
D ia g ra m klas
P o k a z u je s ta ty c z n ą s tru k tu rę p o ję ć , t y p ó w i klas. P o ję c ia r e p re z e n tu ją d z ie d z in ę u ż y t k o w n ik a ; t y p y p o k a z u ją in te r fe js y k o m p o n e n tó w s y s te m u ; k la s y p o k a z u j ą im p le m e n ta c je k o m p o n e n tó w . t
K a r ty C R C
P o m a g a ją d o trz e ć do is to tn y c h z a d a ń k la s y . Ś w ie t n e do b a d a n ia im p le m e n ta c ji p r z y p a d k u u ż y c ia . W a r t o j e s to s o w ać p rz y z a g łę b ia n iu się w s z c z e g ó ły lu b p r z y n a u c e p o d e jś c ia o b ie k to w e g o do p r o je k to w a n ia .
D ia g ra m w drożenia
P o k a z u je fiz y c z n e r o z m ie s z c z e n ie k o m p o n e n t ó w w w ę z ła c h s p rz ę to w y c h .
K o n s tru k c ja o p ro g ra m o w a n ia k o n tra k to w e g o
u r u c h a m ia n ie system u.
D ia g ra m in te ra k c ji
P o k a z u je , j a k k ilk a o b ie k t ó w w s p ó łd z ia ła w r a m a c h j e d n e
P o d a je ścisłą d e fin ic ję c e lu o p e ra c ji i s ta n u p o p r a w n o ś c i k las y . W a r to z a k o d o w a ć te d e fin ic je w k la s ie , a b y w s p o m ó c
go p r z y p a d k u u ż y c ia .
D ia g ra m p a kie tó w
P o k a z u je g ru p y klas i z a le ż n o ś c i m i ę d z y n im i.
W zo rce
P rz y d a tn e fr a g m e n ty te c h n ik a n a liz y , p r o j e k t o w a n i a i k o d o w a n ia . D o b r e p r z y k ła d y do n a u k i; p u n k t s t a r t o w y d o p r o je k t o w a n ia .
R e fa k to ry z a c ja
P o m a g a z m ie n ia ć d z ia ła ją c y p r o g r a m , a b y p o p r a w i ć je g o s tru k tu rę . N a l e ż y j ą s to s o w a ć , g d y k o d u t r u d n ia r e a liz a c ję p r o je k tu .
D ia g ra m stanów
Pokazuje, ja k jeden o b ie k t z a c h o w u je się w k i l k u p r z y p a d kach użycia.
P rz y p a d e k użycia
Pomaga poznać wym agania u ż y t k o w n i k ó w w e f r a g m e n tach Planowanie ia z y b u d o w y o p ie r a się n a im p le m e n t a c ji przypadków użycia w każdej iteracji. P o d s ta w a te s to w a n ia systemu. T a b e la A .1. T e c h n ik i i Ich s to s o w a n ie
R óżnice między w ersjam i UML-a
Dodatek
I UM L w kropelce
K ie d y p o ja w iło się p ie rw s ze w y d a n ie tej k s ią ż k i, is tn ia ła t y l k o w e rs ja 1 0 U M L - a W i e l e z je g o e le m e n tó w w y d a w a ło się ju ż trw a le u s ta lo n y c h , a sam U M L b yl w trak cie procesu a k c e p ta cji p rze z O M G . i z m ia n
Od
tego czasu p o j a w ił o
się w ie le
p o p raw ek
W ty m d o d a tk u opiszę istotne z m ia n y w stosu nku do w e r s ji 1.0 i p o k a żę , ja k i
w p ł y w m a ją one na zaw artość tej k sią żk i. D o d a te k ten streszcza w s zys tk ie z m ia n y , tak a b y p r z e d s ta w ić stan b ie żą c y ję z y k a ty m , k tó r z y m a ją w cześn iejsze w y d a n ie k s ią ż k i'. D o te g o w y d a n i a w p r o w a d z iłe m z m ia n y , a b y być na b ieżąco z U M L - e m . K s ią ż k a ta p r z e d s ta w ia stan U M L - a z sierpnia 1 9 9 9 roku.
B.1
Wersje UML-a
N a jw c z e ś n ie js z a o p u b lik o w a n a w ersja p ie r w o w z o r u U M L - a , to w e rs ja 0 .8 M e to d y Z u n if ik o w a n e j
(ang.
U n ifie d
M e th o d ).
Z o s ta ła
ona
p r z y g o to w a n a
na
k o n fe re n c ję
O O P S L A , k tó ra o d b y ła się w p a ź d z ie rn ik u 1995 ro ku . B y ło to d z ie ło B o o c h a i R u m baugha — W
Jacobson ro zp o c zą ł pracę w firm ie R a tio n a l S o ftw a r e d o p ie r o p ó źn ie j
1 9 9 6 ro k u R a tio n a l S o ftw a re w y d a ła w e rs je 0 .9 i 0 . 9 1, k tó r e z a w i e r a ł y j u ż w k ła d
Jacobsona. Po w e rs ji 0 . 9 1 R a tio n a l S o ftw a re z m ie n iła n a z w ę s p e c y fik a c ji na U M L W s ty c z n iu 1997 roku R a tio n a l S o ftw a re p r z e d s ta w iła w e rs ję l .0 U M L - a g ru p ie ro b o c z e j O M G — A n a ly s is a n d D e s ig n Task F o rc e . N a s tę p n ie w e w r z e ś n iu 1 9 9 7 ro ku . łą c z ą c tę w e rs ję U M L - a z d o d a tk o w y m i e le m e n ta m i, R a tio n a l S o ftw a r e p r z e d s ta w iła s k o n s o lid o w a n y tekst, teraz w e rs ji l . I , j a k o p r o p o z y c ję s ta n d a rd u O M G . k tó r y został p r z y j ę t y p o d k o n ie c 1 9 9 7 roku. N ie s te ty , O M G n a d a ła w e r s ji s ta n d a r d o w e j n u m e r 1.0. T a k w ię c U M L istniał teraz w w e rs ji l.O O M G i w w e rs ji l . l
R a t io n a l —
n ie m y lić
z w e r s ją l .0 R a tio n a l. W p ra k ty c e , k a ż d y n a z y w a tę w e rs ję s ta n d a r d o w ą w e r s j ą l l U M L l . l m ia ł k ilk a m n ie j isto tn ych , ale w id o c z n y c h r ó ż n ic w s to s u n k u do 1.0. P r z y jm u ją c U M L
l . l j a k o standard, O M G u t w o r z y ła z e s p ó l ds. z m i a n ( R T F ) , k tó
r e m u p r z e w o d n ic z y ł C ris K o b r y n , a b y d o p ra c o w a ć p arę e le m e n t ó w . W e w n ę t r z n a p u b lik a c ja wrers|i l .2 O M G m ia ła m ie js c e w lip c u 19 9 8 r o k u . P u b l i k a c ja w t y m sensie b y ła w e w n ę tr z n a , że o f ic ja ln y m s ta n d a rd e m p o z o s ta w a ła d a le j w e r s ja M o ż n a tr a k to w a ć w e rs ję
1.2 ja k o beta. W
l.l
U M L -a .
r z e c z y w is to ś c i to r o z r ó ż n ie n ie n ie m ia ło
ż a d n e g o z n a c z e n ia , p o n ie w a ż w ię k s z o ś ć z m ia n w s ta n d a rd z ie d o t y c z y ł a o r to g r a fii, b łę d ó w g r a m a t y c z n y c h itp.
p o ja w iły się wraz z wersją 1.3. Z n o w u jest to w e r s |u w e w n ę tr z n a O M G , tak w ię c n ie jest ona o ficja ln ym standardem. Z m i a n y s ą t y m r a z e m b a r d z ie j z n a c z ą c e i dotyczą w szczególności przypadków użycia systemu i d ia g ra m ó w c z y n n o ś c i W 1 9 9 9 ro k u „ tr z e j m uszkieterow ie” o p u b lik o w a li p o d ręcznik U M L - a 137] i p o d r ę c z n ik u ż y t k o w n i k a [ 6 ] ; k s ią ż k i te om aw iały wersję 1 .3 , zanim z o s t a ł a ona o p u b l i k o w a n a , co s p o w o d o w a ło n ie c o zamieszania. P o w a ż n ie js z e z m ia n y
' U w a g i te d o ty c zą w y d a ń an g iels k ic h (p r z y p tłu m .)
154
3.2
Wersje planowane
Treści z a w a r te w k s ią ż k a c h ta k ic h ia k t , „raszani do odw iedzenia m oich S
'Z a g a j ą C2esl_. .
$ ^ a g e s / M a m n _ F o w le r ) , na których zna^ W W
dotyczące w ersji I 3 s, i, , " ''iląsię wszelkienowośd W kwietniu 1999 ro ku zespól ds zn I PUbllcznie O o s t e p n e T ^ K
diale8o z,. rve-co” '/
Dokum enty-
dr>e o z n a c z o n y num erem 1.4 O M G . U ! wersją 1.3 a 1.4 będą kosmetyczne O n gd2ieś w 2000 roku O M G przyjm ie
,
^ « W k o r n n y Um I ^ T T ' Zmian sP°
chwUi kontrolę nad UML-em i jego przyszłości-1" "<" Vy- ofic-|al"y 4*an
Tost F o rc e .
B.3
Zmiany we wznowieniach tej książki
W kolejnych w z n o w i e n i a c h starałem się uaktu a ln ić . . u - -, wersjami U M L -a . K orzystałem przy tym z ok-izii -ih„ V V ,z. ę " raz z »owymi wyjaśnienia. ' * V aby koW >wac błędy i poprawiać w zn o w ie ń było opartycli na U M L-u 1.0. Różnice w U M L -a c h między tym , w zn ó w ,e n ,a m i b yły znikome. Wznowienie szóste było oparte na UM Cu P ie rw s z y c h p i ę ć
1.1
j e d n a k z p o w o d u c h o c h lik a d ru k a rs k ie g o strony w ew nętrzne okładek dalei pokazywały n o ta c ję w e r s j i 1.0. W z n o w ie n ia o d s ió d m e g o d o d z ie s ią te g o b y ły oparte na U M L - u 1.2; wznowienie jedenaste b y ło p i e r w s z y m
o p a r t y m na U M L - u
1.3. W z n o w ie n ia oparte na wersjach
późniejszych n i ż 1 .0 m a j ą n u m e r w e rs ji w y p is a n y na okładce. (Niestety, znowu z po wodu b łę d u d r u k a r s k i e g o n ie k t ó r e e g z e m p la rz e w z n o w ie n ia dziesiątego były ozna czone n u m e r e m w e r s ji 1.3 — p r z e p r a s z a m z a to.) Pierwszy' n a k ł a d d r u g i e g o w y d a n ia je s t o party na wersji 1.3. N ie jestem jednak a
stanie p o w i e d z i e ć , j a k i e j w e r s ji b ę d ą d o ty c z y ły dalsze w z n o w ie n ia tego wydania.
W dalszej c z ę ś c i te g o d o d a tk u streszczę d w ie g łó w n e z m ia n y U M L - a przejście )d wersji 1.0 d o 1.1 i o d 1.2 d o 1.3. N i e będę o m a w ia ł w szystkich zm ian, ograniczę się edynie do tych, k t ó r e z m i e n i a j ą coś, o c z y m m ó w iłe m w tej książce, albo reprezentują Vażne elementy U M L - a , k tó r e c h c ia łb y m o m ó w ić .
c a 'szystkie r a d y w y n i k a j ą z m o i c h
«
^
^ l e ż y ' s t o s o w a ł s i^ d o zaTeceń^znaj duj ą-
—
* -
-
°
sy,u;,ciach'
pomogą m i one p o p ra w ie . )6wne blędy , braki poprzednich wznoSkorzystałem także z o k a z ji, aby wskazać gr "=»- Dziękuję C z y te ln ik o m , k tó rz y z w ró c ili na me uwagę.
B.4
Różnice m iędzy U M L -em 1.0 a 1.1
B.4.1
Typ i klasa im plem entacyjna
W p ie rw s z y m w y d a n iu tej k s ią ż k i m ó w iłe m o p e rs p e k ty w a c h o raz o ty m , j a k z m ie n iły one sposób ry s o w a n ia i in te rp re to w a n ia m o d e li — a w s zcze g ó ln o ś c i d ia g ra m ó w klas. U M L z a k ła d a teraz, że w s zy s tk ie klasy na d ia g ram a c h klas m o g ą być tra k to w an e j a k o ty p y a lb o klasy im p lem e n ta c yjn e . K la s a im p le m e n ta c y jn a o d p o w ia d a klasie ze ś ro d o w isk a p ro g ra m is ty c z n e g o , w k tó r y m p o w s ta je o p ro g ra m o w a n ie . Typ je s t czym ś b a rd ziej n ie u c h w y tn y m ; rep rezentuje on ab strakcję słabiej z w ią z a n ą z k o n k re tn ą im p lem e n ta c ją . M o ż e to być ty p interfejsu C O R B A , p e rs p e k ty w a s p ec y fik ac y jn a klasy lub p e rs p e k ty w a p o ję c io w a . Jeśli to k o n ie c z n e , to m o ż n a skorzystać ze s tereotyp ów , aby lepiej ro z ró ż n ić te d w a e le m e n ty . M o ż n a p rzy ją ć d la k o n k re tn e g o d ia g ra m u , że w s z y s tk ie k la s y są z g o d n e z p e w n y m stereo typ e m . M o ż n a tak z ro b ić , rysując d ia g ram z k o n k re tn e j p e r s p e k ty w y . W
pers
p e k t y w ie im p le m e n ta c y jn e j stosuje się klasy im p le m e n ta c y jn e , p odczas g d y w pers p e k ty w a c h s p ec y fik ac y jn ej i p o ję c io w e j stosuje się typy A b y z a z n a c z y ć , że klasa im p le m e n ta c y jn a im p le m e n tu je k ilk a ty p ó w , stosuje się re la c ję re a liza c ji. Is tn ie je ró żn ic a m ię d z y typ em a interfejsem . In te rfe js m a z a d a n ie b e z p o ś re d n io o d p o w ia d a ć in te rfe js o w i Javy lub C O M . Stąd interfejsy m a ją ty lk o o p e ra c je , n a to m iast n ie m a ją a try b u tó w . W w y p a d k u klas m o żn a stosować ty lk o je d n ą , statyczn ą k la s y fik a c ję , po d czas gdy w' w y p a d k u ty p ó w m o ż n a stosować k la s y fik a c ję w ie lo k r o tn ą i d y n a m ic z n ą . ( P r z y p u s z c z a m , że tak je st, p o n ie w a ż g łó w n e j ę z y k i p r o g r a m o w a n ia o b ie k t o w e g o stosują p o je d y n c z ą k la s y fik a c ję statyczną. T o o g ra n icze n ie nie b ę d zie p o trz e b n e p r z y k o r z y staniu z ję z y k a , w k tó r y m w y s tę p u je k la s y fik a c ja w ie lo k ro tn a lu b d y n a m ic z n a .)
B.4.2 We
O graniczenia com plete i incom plete z w yró żn ikiem w c z e ś n ie js z y c h w z n o w ie n ia c h
UML
w k ro p e lc e m ó w i ł e m , że o g ra n ic z e n ie
{c o m p le te } na re la c ji u o g ó ln ie n ia ozn acza, że w s z y s tk ie in s ta n cje ty p u p o d s ta w o w e g o m u s z ą być ta k ż e in s ta n cja m i p o d ty p u w ram ach je d n e g o p o d z ia łu (z o b a c z r o z d z ia ł 6 .) u s ta lo n eg o p rz e z w y r ó ż n ik . Z a m ia s t tego U M L l . l o k re ś la , że / c o m p le te } o z n a c z a , iż w s z y s tk ie p o d ty p y w ram ach tego p o d z ia łu m u s z ą b y ć w y s p e c y f ik o w a n e — co nie jest t y m s a m y m . O d k r y łe m p e w n ą niesp ójn ość w in te rp re ta c ji te g o o g r a n ic z e n ia —
tak
w ię c n a le ż y być tu o s tro ż n y m . A b y z a z n a c z y ć , że w s z y s tk ie in s ta n c je ty p u p o d s ta w o w e g o p o w in n y b y ć in s ta n cją je d n e g o z p o d ty p ó w , d la u n ik n ię c ia z a m ie s z a n ia p ro p o n u ję u ż y w a ć in n e g o o g ra n ic z e n ia . Ja na ra z ie u ż y w a m { m a n d a t o r y } ( z ang. o b o w ią z k o w e ).
B.4.3 W
Zawieranie U M L -u
o b ie k t a m i
b y ło
l.O s to s o w a n ie re la c ji z a w ie r a n ia n ie z m ie n n e
(lu b
implikowało,
z a m r o ż o n e ) co n a jm n ie j
że p o w ią z a n ie m ię d z y
d la je d n o w a r to ś c io w y c h
(p r o s ty c h ) s k ła d o w y c h . T o o g ra n ic z e n ie n ie je s t j u ż c z ę ś c ią d e fin ic ji.
0.4.4
Niezmienność i zamrożenie
U M L d e fin iu je o g r a n ic z e n ie
f t r o z ,.,,,
,
T a k j a k je s t to o b e c n ie z d e fin io w a n e
n i« ' » i e „ „ „ śl;i ró,
¿ k l a s . Stosuję te r m in f r o z e n z a m ia s t o k r e ś li j|cze„,a do a s o c ja c ji, r ó l, k la s i a try b u tó w
B.4.5
ydaje si« ° " ° s t o s u « / ? W n ' « ™ e n n o ś c i , Ll* w^ ° ^
“ tów
Powroty na diagramach sekwencji
W U M L - u 1.0 p o w r ó t na d ia g r a m ie sekw enci, bv, komunikat (porow naj p o p r z e d n ie w z n o w i e n i a ? n 1 oznaczany l a k , samą s tr2 a lk l... „two było się pom ylić. U M L 1.1 do o z m c •' V 10 doś' kłopotliwe 1,-ią p rz e ry w a n a , c o b a r d z o m i się p o d o b P a r o l ó w używa s t r a l k i ^ o « ” R o c z n e . T o , c o j e s t z w r a c a n e w tra k cie po w ro tu ™ * b v f * d° skonale ei. ughStock: - c h e c k (). lU’ moze bYc nazwane, na przykład
B.4.6
Stosowanie terminu rn|a
C,i. is tm e je t a k z e r o l a w e w s p ó łd z ia ła n iu , ,o znaczy rola, j a k ą L .a n c ,a ° k ^ o d g " » we w s p ó łd z ia ła n iu . U M L
1.1 k ła d z ie znaczn ie w iększy nacisk na współdziałania i w v-
nd to , ze to z a s to s o w a n ie te rm in u rola stanie się podstawowe.
B.5
Różnice między UML-em 1.2 (i 1.1) a 1.3 (i 1.4)
B.5.1
Przypadki użycia systemu
Z m ia n y w d e f i n i c j i p r z y p a d k ó w u ż y c ia systemu dotyczą nowych relacji między nimi. U M L 1.1 o k r e ś la ł d w i e re la c je m ię d z y p rzy p a d k a m i użycia — «używ a» i «rozsze
rza»— b ę d ące s t e r e o t y p a m i u o g ó ln ie n ia . U M L 1.3 proponuje trzy relacje. •
« Z a w ie ra » (a n g . i n c l u d e ) je s t s te reo typ e m zależności. O znacza to, że wątek jedne go p r z y p a d k u u ż y c i a je s t z a w a r t y w tn nym . Z d a tz a się to z w y k le gdy kdka przy„ i , . . c«A in a rv p ść N a z a w a rty przypadek użycia składa się wspólne padkow u ż y c i a m a w s p ó ln ą ^ kładem z dziedziny bankomazach o w an ie k i l k u i n n y c h p r z y p a d k ó w uzy . . y T n m f e r nieniedzy za.ÓW m o ż e b y ć to , ż e p r ż y p a d k , u ż y c ia w ierają p r z y p a d e k u ż y c i a S p r a w d z e n ie k lie n ta . Zastępuje relacji
«używa» (a n g . uses).
' U o g ó ln ie n ie p r z y p a d k u
.
.
,
* użvcia iest odmianą
u ż y c ia o z n “ z a ' j “ ^ u ż y cja dla W y p ła ty pieniędzy (pod-
lnnego. M oże is tn ie ć z a t e m j e d e n p
yp
n h cłin n iiacv sytuację odm owy w y-
staw ow y) , i n n y . o d d z i e l n y p r z y p a d e PłalY z p o w o d u b r a k u p i e n i ę d z y n a
^ d ł u ż o n a ja k o on
Ptżypadek u ż y c ia u s z c z e g ó ł o w i a ją c y w y P
n ie n ie d zy . (M o ż n a j ą również po , p r / yp ad ku użycia W yplmn
’takto w ać j a k o a l t e r n a t y w n y s c e n a riu s z w ra m a c h |
y|
l’R
. . .I*>vcia taki ia k ten, m o ż e zm ien ić dowolny m ę d zy .) U szczegółow iający pizypadck > •
aspekt przypadku podstawowego , zal eżności . U m o ż l i w i a ono h a u l / , , , «R ozszerzenie» (ang. extends) jest stere■ 1 w u ż y c ia n iż re |acja „ogólntem ., kontrolow ane podejście do rozszerzeń i ^ J ^ d e k ,.lnMC k ro /. W tym rozw iązaniu podstaw ow y przypacieK > . n n ric r m tn ,,, szerzeń Rozszerzający przypadek użycia m oże z m ie n ić z a c h o u anto p o dstaw ow ego przypadku użycia £ l k o w ściśle określonych punktach ro zszerzeń . Z a ,c m k u p u „ c coś przez Internet
m o żn a u żyw ać ogólnego p rzy p ad ku uzyetn Z a k u p u towaru
z punktam i rozszerzeń na zbieranie in fo rm a cji o w a ru n k a c h d o s ta w y ■ o w arunkach płatności. T a k i przypadek użycia m oże być naslępnte ro z s z e rz o n y , aby objąć / w y k łych k lie n tó w , dla których inform acje te będą zbierane w m in ^
'
Jest trochę zam ieszania co do z w ią z k u m ię d zy starym i i n o w y m i re la c ja m i W iększo ść stosuje relację « u ży w a » w taki sposób, w jaki w w e is ji
icst stoso
w ana relacja « zaw ie ra» — stąd można p o w iedzieć, że « z a w ie in » zastępuje « u ; \ \ \ a Ponadto, większość stosuje relację «rozszerzenie» z w ersji 1.1 z a r ó w n o w scisle o k re ślony sposób wersji 1.3, ja k i ja k o m etody ogólnego p rze c ią ż a n ia p r z y p a d k ó w użycia w stylu relacji uogólnienia wersji 1.3. T a k w ięc m o ż n a p rz y ją ć , że le la c ja « io zsze rze n ie» wersji 1.1 została w w ersji 1.3
B.5.2
z a s tą p io n a
p rzez « ro z s z e rz e n ie » i uo gó ln ieniu.
Diagramy czynności
G d y U M L p o ja w ił się w wersji 1.2, pozostało sporo o tw a rty c h k w e s tii d o ty c ząc y ch sem antyki d ia g ram ó w czynności. Stąd w ie le w y s iłk u w pracach nad w e r s ją 1.3 p o św ięcono uściśleniu tej sem antyki. D la procesu w a ru n k o w e g o w w ersji 1.3 U M L - a na d ia g ra m a c h c z y n n o ś c i m ożna stosować ro m b za ró w n o do oznaczenia ro zg a łę zie n ia , j a k i scalenia. M i m o że ani ro z g a łęzie n ie, ani scalenie nie są ko nieczne do opisu p ro cesó w w a r u n k o w y c h , to coraz częściej się j e stosuje, aby móc w' naw iasach k w a d ra to w y c h w y s p e c y f ik o w a ć w a ru n k i G ru b ą kreskę s yn c h ro n iza cy jn ą n a z y w a się obecnie r o z w id le n ie m ( w w y p a d k u r o z g a łę z ie n ia na p o d czyn no ści) i złą c ze n ie m ( w w y p a d k u s y n c h ro n iz a c ji s te ro w a n ia ). N ie m o ż n a j u ż stawiać d o w o ln y c h w a ru n k ó w na złą c ze n ie . C o w ię c e j, trz e b a stosow ać re g u ły za p e w n ia ją c e pełne sparow anie ro z w id le ń i złą cze ń . O z n a c z a to w p ra k ty c e , że d la k a żd e g o ro z w id le n ia musi istnieć o d p o w ia d a ją c e m u z łą c z e n ie , k tó re scala w ą tk i ro zp o c zę te ty m ro z w id le n ie m . Jednak ro z w id le n ia i z łą c z e n ia m o ż n a z a g n ie ż d ż a ć , jak r ó w n ie ż m o ż n a usuw ać z d ia g ra m ó w r o z w id le n ia i z łą c z e n ia id ą ce b e z p o ś re d n io od je d n e g o r o z w id le n ia do d ru g ieg o (lu b od je d n e g o z łą c z e n ia do
drugiego).
P rze z z łą c z e n ie m o ż n a przejść je d yn ie w ó w c z a s , g d y w s z y s tk ie w c h o d z ą c e doń w ą tk i się z a k o ń c z y ły . M o ż n a je d n a k , dla w ą tk u w y c h o d z ą c e g o z r o z w id le n ia , mieć o k re ś lo n y w a ru n e k . Jeśli w a ru n e k ten je st fa łs z y w y , to z p u n k tu w i d z e n ia z łą c z e n ia u w a ż a się taki w ą te k za z a k o ń c z o n y . Z a m ia s t w ie lo k r o tn e g o w y z w a la n ia p o d p ro c e s ó w w p r o w a d z o n o w e w n ą t r z p ro c e s ó w w s p ó łb ie ż n o ś ć d y n a m ic z n ą 1 [o z n a c z a n ą g w i a z d k ą ( * ) w
ramce
c z y n n o ś c i]. P ro c e s
taki m o ż e być w ie lo k r o tn ie w y w o ła n y r ó w n o le g le . W s z y s t k ie je g o w y w o ł a n i a muszn
W U M L N o ta tio n G u id e wersji 1.3 określana (ako w y w o ła n ie d y n a m ic zn e (ang. dynamie invocation) (przyp. tłum .).
P
liczyć* z a n im m o ż n a p r z e jś ć d o następnej czynności. Jest to m niej więcej rów -
5i $ * * ° n aie m n ie j e la s ty c z n e n iż w ie lo k r o t n e w y z w a la n ie i o d p o w iad ający m u w aru■ E c h r o n iz a c y jn y .
' V, |y te o g r a n ic z a ją n ie c o e la s ty c zn o ś ć d ia g ra m ó w czynności, ale też gwarantują, ^ ¿ s z c z e g ó l n y m i w y p a d k a m i d ia g r a m ó w stanów . Z w ią z e k m ięd zy diagram am i d ia g ra m a m i c z y n n o ś c i b y ł p r z e d m io te m p e w n e g o sporu w zespole ds. zmian,
przyszłe
wersje U M L - a (p o 1 .4 ) m o g ą u c z y n ić z d ia g ra m ó w czynności zupełnie inny
jyp diagram u.
Słow niczek
Dodatek
UML v> kropelce
T erm in a n g ie ls k i
T e r m in p o ls k i a c y k lic z n y g r a f skiero w an y a g r e g a c j a ...........................................
directed a c y c lic graph a g g reg atio n
a kcja ....................................................
action
a k t o r ....................................................
actor
a k ty w a c ja
a ctiv a tio n
........................................
a lte rn a ty w a ....................................
altern a tiv e flo w
a rg u m en t .........................................
actual p a ra m e te r
a rg u m en t ...........................................
a rg u m en t
asercja
assertion
.............................................
asocjacja
.........................................
asocjacja k w a lifik o w a n a
.........
association q u a lifie d association
a tryb u t ..............................................
attribute
budowa
construction
...........................................
c h ro n io n y
.......................................
protected
czynn ość .........................................
a c tiv ity
d e k o m p o z y c ja c z y n n o ś c i.........
d e c o m p o s in g an a c tiv ity
d e k o m p o z y c ja fu n k c jo n a ln a . .
fu n c tio n a l d e c o m p o s itio n
d ia g ra m
d ia g ra m
............................................
d ia g ra m c z y n n o ś c i.......................
a c tiv ity d ia g ra m
d ia g ra m in te rak c ji .......................
interactio n d ia g r a m
d ia g ra m k l a s ..................................
class d ia g ra m
d ia g ra m k o m p o n e n t ó w ..............
c o m p o n e n t d ia g ra m
d ia g ra m o b ie k tó w
o b ject d ia g r a m
.......................
d ia g ra m p r z y p a d k ó w u ż y c ia . .
use case d ia g r a m
d ia g ra m s e k w e n c j i .......................
sequence d ia g r a m
d ia g ra m stan ó w
state d ia g r a m
............................
d ia g ra m s ta n ó w w s p ó łb ie ż n y c h
c o n c u rre n t state d ia g ra m s
d ia g ra m w d ro ż e n ia .....................
d e p lo y m e n t d ia g r a m
d ia g r a m w s p ó ł d z i a ł a n i a ............
c o lla b o r a tio n d ia g r a m
dozór
guard c o n d itio n im plem entation in h e rita n c e interface inheritance m ultiple inheritance inheritance bound element phase member functions im plem entation inception instance interaction
.................................................
d z ie d z ic z e n ie im p le m e n ta c ji . . d z ie d z ic z e n ie in terfejsu
............
d z ie d z ic z e n ie w ie lo k r o tn e — d z i e d z i c z n o ś ć ................................. e le m e n t z w i ą z a n y
........................
f a z a ....................................................... fu n k c je s k ł a d o w e .......................... im p le m e n ta c ja
...............................
i n i c j a c j a ............................................. i n s t a n c j a ............................................. i n t e r a k c j a ...........................................
, ............................. • • •................... inierfcjS • informacJi ......................................... .......................................................... jterac3a ' ' ’.... ........................................................
interface information engineering iteration iterative
i(eracyJn^ interfejsu (1DL)........................... język ograniczeń (O C L )........................... j ę z y k ^ a r t a klasa-zobow iązanie-.............. k3rtaC Zdziałanie) -^SP.............. ................................................... klasa . ’ ’ ino................................................. klasa abstr .......... .............................................. ^ “ “niementacyjna . ...................................... klasa ""P’ v aln a...................................... klasap a lm e to "
Interface Definition Language Object Constraint Language CRC card (Class-Responsibility -Collaboration card) class abstract class association class implementation class parameter,zed class classification
Wpf*
sn
klasyfikacja......... . klasyfikacja dynanuczn Egyfikacja statyczna
dynamic classification ................ static classification ................ component
kotnponent ............................ ................... komunikat............... ............................ ......... komunikat asynchroniczny . . . • • • • • • • • • ........... krotność................... .................. kwerenda ........................ .................... tjoa iycia obiektu....................... metamodel ....................................... . ........... ......................... metooa metoda zunifikow ana............... .................... model......................................... .......................... mode! dziedz.ny......................... ........................... modyfikator ............... ........................ .................. MWigowalność ........................... fr . .............................. « " ? ............... ...........................................
message asynchronous message multiplicity query object lifeline meta-model method u model unified method d0T fie rr na'siuability naviig notation note obiect
................... ....................................... proxy object obiekt zastępczy ........... ...................................... ........................ ................................... receiver object oriented obiektowe................... .............................. historic mapping ^ l0fCa • • ‘ historyc/n h storvczne ................................. ’............................... opcratioix constraint odwzorowanie ograniczenie.................
"....................................
g r a c ja .............................
package
.............................. parameter
Pt o ................................ Parametr ......................... .................................. ............................ perspektywa . . . . . . , cy)na ........................ perspektywa implement yj ........................
view . .evv implementation substitutabiW substate
podraiemalność
subsystem
p H y ite m ...........
...............................
|* y
p
....................
........................
subclass
c o n n e ctio n process n rn fil
.........................
p ro file o b ject o rie n te d p r o g r a m m in g r e s p o n s ib ility -d r iv e n design . I recu rs ive d esig n
p ro je k to w a n ie sterowane z o b o w ią z a n ia m i
p riv a te w o r k f lo w p rz y p a d e k u ż y c i a .......................................................
use case
p rz y ro s to w y
in c re m e n ta l
................................................................
p u b l i c z n y .......................................................................
..
focus o f c o n tro l
p u d e łk o a k t y w a c j i .................................................... p u n k ty rozszerzen ia
p u b lic
................................................ . . .
e x ten s io n p o in ts
re a liz a c ja .......................................................................
re a liz a tio n
r e f a k t o r y z a c j a .............................................................. . . . ro la .................................................................................. . . .
re fa c to rin g
ro z rs a łę z ie n ie ................................................................ . . . ro zs ze rze n ie ................................................................ . . .
branch
r o z w i d l e n i e .................................................................. . . .
fo rk
r o z w in ię c ie .................................................................. . . .
e la b o ra tio n
s a m o w y w o ł a n i e ......................................................... . . .
re fle x iv e m essage
scalenie
.......................................................................... . . .
role exten d
m erg e
scenariusz ..................................................................... . . .
flo w o f even ts
scenariusz g ł ó w n y ..................................................... . . .
basic flo w
s k ła d o w e k l a s y ............................................................ . . .
m e m b e rs o f a class
s p e c y fik a to r d o s t ę p u ................................................ . . .
v is ib ility
stan ................................................................................... . . . state stan s y n c h ro n iz a c y jn y
............................................ . . .
s ta n d a rd o w a b ib lio te k a w z o r c ó w ( S T L ) s te reo typ
...
synch state S ta n d a rd T e m p l a t e L i b r a r y
........................................................................ . . .
s te re o ty p e
stopień f o r m a l i z a c j i ................................................... . . .
cerem o n y
s u p e r t y p ........................................................................... . . .
superclass
s z k i e l e t ............................................................................. . . .
fra m e w o rk
te c h n ik a m o d e lo w a n ia o b ie k tó w ( O M T )
O b je c t M o d e l i n g T e c h n iq u e
...
to r ....................................................................................... . . .
s w im la n e
t y p ........................................................................................ . . . ty p p o d s t a w o w y ............................................... ... u o g ó l n i e n i e ....................................................... ...
ty p e
u s u n ię c ie ..................................................
...
d e le tio n
w a r u n e k .............................................
...
c o n d itio n
w ą te k
...
ttill hrpü/1 LtlU
...
transition
...
nnrlf» I1UUL
...
b in d i n g
...
lin k
......................................
w d r o ż e n ie w ęzeł
.................................
.................................
w i ą z a n i e ............................... w ią z a n ie ..........................
superclass g e n e r a liz a t io n
-pólbieżność d ynam iczna .............. *sp0|dzialanie.................................; ; ' ; ; ; ...........
dynamic concurrency
^Yiąiek .....................................................................
c o ,laboration
" "
K a g a m e ...............................................' ............. exception requirement
g o r z e ć ................................................................ .............. rtleżnośc................................................................ ................
Pattern
g ro ż e n ie
dependency
................................................
..............
¿ « g .............................................................. : : : ..................V ,v e "
scope
t e r a n ie
^ i - I I ! I ! ! ! ! .......................
U c z e n ie .............................................
.................
¿ ¡ U .k ite ra c ji............................ jpbowiązame................................
............. .........
¿unifikowany j ę z y k
m o d e lo w a n ia ( U M L ) . ! ! ! ! !
visibili,y com position
iteration marker u
S
tS l.n ,
Language
A I J M L w k ro p e lc e
[ I] [2]
[3 ]
[4]
Kent Beck : S m a llta lk Best P r a c tic e P a tte rn s . P re n tic e H a ll, I >96. Kent Beck: E x tre m e P r o g r a m m in g E x p la in e d : E m b r a c e C h a n g e A d d is o n -W e s ley, 2000. ( W y d a jn e p r o g r a m o w a n ie - e x tre m e P r o g r a m m i n g , thim . S tefan Uss, M IK O M , Warszawa 2001) . Kent Beck i Ward Cunningham: „ A L a b o r a to r y fo r Teaching O b je c t-O r ie n te d T h in kin g ” . P ro c e e d in g s o f O O P S L A S9. S IG P LAN Notices, V o l . 24, ni 10, s. 1-6 Zobacz < h ttp ://c 2 .c o m /d o c /o o p s la 8 9 /p a p e r.h tm l>. Grady Booch: O b je c t-O r ie n te d A n a ly s is a n d D e s ig n w ith A p p lic a tio n s , Second E d itio n . Addison-Wesley, 1994.
[5]
Grady Booch: O b je c t S o lu tio n s : M a n a g in g th e O b je c t - O r ie n t e d I to /e c t. A d d i
[6]
son-Wesley, 1996. Grady Booch, Janies Rumbaugh i Ivar Jacobson [trz e j m u s z k ie t e r o w ie ] : The U n ifie d M o d e lin g L a n g u a g e U s e r G u id e . A d d is o n - W e s le y , 1 9 9 9 .
[7]
Frank Buschmann, R e g in e Meunier, H a n s R o h n e rt, P e te r Sommerlad i Michael Stal: P a t t e r n - O r ie n t e d S o ftw a re A rc h ite c tu re : A System o j P a tte r n s . John W ile y & Sons, 1996. [8] Peter Coad i Jill Nicola: O b je c t-O r ie n te d P r o g r a m m in g . Y o u r d o n , 1 9 9 3 . ( P r o g ra m o w a n ie o b ie k to w e , tłum. Danuta S z c z e p a ń s k a -W a s e r s z tn u n i Ratal S zte n ce l, Read Me, Warszawa 1994) [9] Peter Coad i Edward Yourdon: O b je c t- O r ie n te d A n a ly s is . Y o u r d o n , 1 9 9 1 a ( A n a liz a o b ie k to w a , tłum. Danuta S z c z e p a ń s k a -W a s e rs z tru m i Rafal S z te n c e l, R e a d Me, Warszawa 1994) [10] Peter Coad i Edward Yourdon: O b je c t - O r ie n t e d D e s ig n . Y o u r d o n , 1 9 9 1 b . ( P r o g ra m o w a n ie o b ie k to w e , tłum. Danuta S z c z e p a ń s k a -W a s e r s z tr u m i R a f a ł S z te n c e l. Read Me, Warszawa 1994) [11] Peter Coad, David North i M ark M ayfield: O b je c t M o d e l s : S tr a te g ie s , P a tte rn s a n d A p p lic a tio n s . Prentice H all, 1995. [ 12] A l i s t a i r C o c k b u rn : S u rv iv in g O b je c t-O rie n te d P r o je c ts . A d dison-W esley, 1998. [13] Steve Cook i John Daniels: Designing Object Systems: O b j e c t - O r i e n t e d M o d e lin g w ith S y n tro p y . Prentice H all, 1994.
168
[14]
James O. Coplien: „ A Generative Development Process Pattern Lanm ia^e” W [15], s. 183-237. * *
[15]
James O. Coplien i Douglas C. Schmidt, w yd.: P a tte rn L a n g u a g e s o f P r o g r a m D e s ig n [P L o P D l], Addison-W esley, 1995.
[16]
W ard Cunningham: „EPISO DES: A Pattern Language o f C o m p e titive Develop m ent” W [43], s. 371-388.
[17]
Bruce Powel Douglass: R e a l-T im e U M L . A ddison-W esley, 1998.
[1 8 ]
M a rtin Fowler. A n a ly s is P a tte rn s : R e u s a b le O b je c t M o d e ls . A ddison-W esley, 1997.
[1 9 ]
M a rtin F ow lei, R e fa c to r in g : Im p r o v in g th e D e s ig n o f E x is tin g P r o g r a m s . A d d i son-W esley, 1999.
nO]
E rich G a m m a , R ic h a rd H e lm D e s ig n P a tte rn s : W e s le y , 1995.
Ralnh i u
E lem ents o f R e u s e n , ‘ ^ V1,SS,des l b™da czworgaleUS(,b,e O bject-O riented Software. Ad S '
[21]
A d e le G o ld b e r g i K e n n e th S. R ubin
[22]
w orks f o r P r o je c t M a n a g e m e n t. A d d is 'o n -W e s ty * ' * ° bjectS: D ^ D a v id H a re l: „S tatecharts: A V is u a l F n ™ . . r 5‘ ce o f C o m p u te r P r o g r a m m in g , V o l 8
[23]
W
/•
1987
1
Iv a r Jacobson, G r a d y B o o c l n James R „ m k ,
n
Fram e-
C o m Plex Systems”. W Scien-
u r
f i e d S o ftw a r e D e v e lo p ,,,,,,, Process A d d i s o n ^ e s t e ?
” * V n i'
[24]
Iv a r Jacobson, M a g n u s Christerson PntnR I « . ^ ~ - O r ie n te d S o ftw a re E n g in e e rin g 4 Use C n ‘ 0 v e rgaard: Object1992. S t e e r i n g . A Use Case D riven Approach. Add.son-Wesley,
[25]
Iv a r Jacobson
ness
M a r ia Ericsson , A gnela Jacobson: The Ohjee, Advamaee M BusiP cso reRc c n g u ie c rin g u,V /i O h je Add.son-VVetlcy “ 9 , 5
A n d r e w Koenig . B a r b a r a M o o Rum inations on C + + ; a Decade o f P rogram m in g In s ig h t a n d E x p e rie n c e . A d d is o n -W e s le y 1997
,[2 6 ] [27]
P h ilip p e K ru c h te n : W e s le y , 1999.
77,e
U Addison-
[28]
C ra ig L a rm a n : A p p ly in g U M L a n d Patterns. Prentice H all, 1998.
[29]
James M a r t i n i Jam es J. O d e ll: O b je c t-O rie n te d Methods: A Foundation (U M L E d itio n ). P re n tic e H a ll, 1998.
[30]
Robert C e c il M a r tin : D e s ig n in g O b je c t-O rie n te d C + + Applications: Using the B o o ch M e th o d . P re n tic e H a ll, 1995.
[31]
Steve M c C o n n e l l : R a p id D evelo p m en t: Tam ing W ild Software Schedules. M ic ro soft Press, 1 9 9 6 .
Steve M c C o n n e l l : S o ftw a re P r o je c t S u rv iv a l Guide. M icrosoft Press, 1998. [33] Bertrand M e y e r : O b je c t-O r ie n te d S o ftw a re Construction. Prentice Hall, 1997. [34] W illiam F. O p d y k e : „ R e fa c to rin g O b ject-O rien ted Frameworks". Praca doktorska. U n iv e r s it y o f Illin o is at U rb a n a -C h a m p a ig n , 1992. Zobacz
e d u /p u b /p a p e r s /r e ja c t o r i n g /o p d yke-th es is:ps. Z > .
[35]
Trygve Reenskaug: W o rk in g w ith Objects. Prentice H a ll, 1996. [36] James Rumbaugh: O M T I n s i g h t s . SIGS Books, 1996. [37] James Rumbaugh, Ivar Jacobson i Grady Booch [trzej muszk.eterow.e]: The Unif i e d M o d e l i n g L a n g u a g e R e fe re n c e M a n u a l. Addison-Wesley. 1999. 138] James Rumbaugh, Michael Blaha. W illiam Premerlanl, Frederick Eddy , Will,am Lorenzen: O b je c t- O r ie n te d M o d e lin g a n d Design. Prentice Hall, 199 ^ [39]
C e ri S c h n e id e r , Jason P. W in te rs :
[40]
SaUy^htaer i 's t e p h e n J. M e l l o n O b je c t-O rie n te d Systems Analysis: M odel,,,g the
141]
s“
. a ^ r s t l p h e n ' j n ^Meflor: O b je c t Lifecycles: M o d e lin g the W orld in Staies.
Y o urd o n ,
142]
A p p Use Cases: A P rac U c a l Guide.
1991.
.
^
arm lication Indepen-
Sally Shlaer i Stephen J. M e llo n „Recursive Design of an Apphcat dent A rc h ite ctu re ” .
IEEE Software,
V o l. 14, nr 1,
UM L w kropelce
[43J
John M . V lis s id e s , Jam es O . C o p lie n i N o r m a n L . K e i t h , w y d . . / a t t e i n L a n g u a g e s o f P r o g r a m D e s ig n 2 [ P L o P D 2 ] .
[4 4 ]
K im
Addison- W e s l e y ,
1996.
W a ld e n i J e a n - M a r c N e rs o n : S e a m le s s O b j e c t - O r i e n t e d S o f t w a r e A r c h i t e c
t u r e : A n a ly s is a n d D e s ig n o f R e li a b l e S ystem s. P r e n tic e H a l l , 1 9 9 5 . [4 5 ]
Jos W a r m e r i A n n e k e K le p p e : T h e O b je c t C o n s t r a in t L a n g u a g e : P r e c is e M o d e l i n g w ith U M L . A d d i s o n - W e s l e y , 1 9 9 8 .
[4 6 ]
Rebecca
W irfs -B ro c k ,
B r ia n
W ilk e r s o n
- O r i e n t e d S o ftw a r e . P re n tic e H a l l , 1 9 9 0 .
i
L au ren
W ie n e r:
D e s ig n in g
O h je e t -
UML w kropelce
A
D
i a b s t r a c t ograniczenie 90, I OX agregacja 87 akcesor 65 akcja 115 aktor 52 notacja 52 śledzenie 53 argument 65 ascrcja definicja 67 rola w klasach pochodnych 6X asocjacja definicja 60 dwukierunkowa 62 ja ko zobowiązanie 61 jednokierunkow a 62 kw alifikow ana 95 nawigowalność 62 nazewnictwo 62 pochodna, definicja 88 pochodna, przykład 89 porównanie z podtypem 58 atrybut pochodny 64 definicja 88 przykład 89
(d a g i, ograniczenie 94 Daniels, John 58, 6 9 ,7 0 , 120 dekompozycja funkcjonalna 104 diagramy czynności 27, 34, 44, 80, 152 definicja 122 przykłady 125, 126. 128 stosowanie 129 diagramy fizyczne stosowanie 134 diagramy implementacji 36.44 diagramy instancji definicja 83 przykłady 83 diagramy interakcji 25, 26, 34. 36, 43. 44, 79, 125.129.152 definicja 72 przykłady 73. 77, 78, 142 stosowanie 80 typy 72 diagramy klas 25, 26, 27, 34, 36, 43, 44. 45, 1 0 4 .1 0 6 .1 4 7 .1 5 2 definicja 58 perspektywy 58 przykłady 45, 46, 59, 83. 85. 86. 89. 91, 9 5 ,9 7 , 98, 100, 110, U l , 137, 140, 141, 149 stosowanie 69 diagramy kom ponentów definicja 132 w ramach diagramu wdrożenia 132 diagramy obiektów definicja 83 przykłady 83, 138. 139 diagramy pakietów 25. 36, 43, 152 definicja 104 przykłady 105, 107 stosowanie 111 diagramy przypadków użycia systemu 51 diagramy sekwencji 72, 109, 150 definicja 72 przykłady 73, 74. 75, 109, 142 diagramy stanów 44, 80, 129, 152 definicja 114 p rzykła d y 114, 116, 117, 118, 119 stosowanie 120 związek z diagramami czynności 122 diagram y stanów współbieżnych definicja 118 p rzykła d y 119
B / bag} , ograniczenie 94 Beck, Kent 21, 78, 80 «bind», stereotyp 100 biznesow y przypadek użycia 55 Booch, Grady 16, 20, 2 1, 22, 27, 47
c cecha 66 c h ro n io n y zasięg widoczności w C + + 101 Javie 102 Coad, Peter 2 1 C ockburn. A lis ta ir 47, 56 / com plete/ , ograniczenie 85, 156 Com posite, wzorzec p ro jekto w y XX C ook, Steve 5 8 ,6 9 .7 0 , 120 C unningham , W ard 21, 43, 78, 80 czynność w diagramach czynności 122 stanów 1 15
172
diagramy wdrożenia 152 definicja 132 przykłady 133 diagramy współdziałania 72 definicja 76 porównanie z diagramami obiektów 84 porównanie z diagramami sekwencji 77 przykłady 77, 78 pouglass. Bruce Powel 28, 120 dozór na diagramach czynności 122 stanów 115 dwukierunkowa asocjacja 62
H iffcl 67 , 6 9 ekspert 37
element związany 99, 100
Facades, wzorzec p ro je kto w y 106 fasada 106 faza budowy definicja 3 1 opis 40 planowanie 38 U M L 43 faza inicjacji definicja 3 1 opis 32 faza rozwinięcia definicja 3 1 kategorie zagrożeń 32 opis 32 w ychw ytyw anie przypadków użycia 33, 55 zakończenie 38 faza wdrożenia definicja 3 1 opis 44 formalizacja 3 1 {/rożen/, ograniczenie 94, 157
G ''global», stereotyp 108
• wzorzec analityczny Rh «implementation class» I interfejs ’ slcre°typ 60 czysty 90 Porównanie z klasą abstrakcyjna 92 Porównanie ze stereoivn* J ą UM L82 e0typem « ^ e » 156 inżynieria informacyjna 104 iteracja natura 40 przypisywanie przypadków użycia 39 przyrostowa natura 40 składniki 31 ustalanie czasu trwania 39 ustalanie liczby 39 iteracyjne tworzenie oprogramowania 26 stosowanie 47
Jacobson, lvar 16,20,21,22.47.50.51 56 72 jednokierunkowa asocjacja 62 język modelowania 20
K Kain, Brad 43 karty CRC 21. 26, 43. 70. 143, 152 definicja 78 przykład 79 stosowanie 79, 80 klasa paramctryzowalna 99 pochodna 66, 68, 90, 92 podstawowa 66 klasa abstrakcyjna notacja 90 porównanie z interfejsem 92 klasa asocjacyjna definicja 96 jako samoistna klasa 96 przykłady 97 szczegóły 97 klasyfikacja definicja 84 dynamiczna 86 pojedyncza 84, 86
li
przykłady 95 statyczna 86
Hadfield, T o m 16, 25
typy 84, 86 wielokrotna 84
^ c l , D a v id 1 14 ■’h ie ra rc h y }' o g ra n ic z e n ie 94
"history», ste re o typ 98
Klcppc. Annckc 67
Kobryn, Cns 22 komunikat asynchroniczny 75 konstrukcja oprogramowania kontraktowego 152 definicja 67 stosowanie 69 krotność 60 kruchten, Philippe 30, 47 kwerenda 65
L linia życia 72 Loonus, M ary 22
M ¡m andatory!. ograniczenie 156 M artin, James 21, 28 M artin, Robert I 12 McConnell, Steve 47 M c llo r, Steve 2 1 nietamodcl 23 metoda pobierania wartości 65 ustawiania wartości 65 wzorca Factory 148 Metoda Zunifikowana 22 Meyer, Bertrand 67 model dziedziny budowa 34 definicja 33 i diagramy czynności 125 stosowanie z przypadkami użycia 34 wskazówki 34 zespół 35 m odyfikator 65
N nadklasa 66 nawigowalność definicja 62 przykłady 63 nazwa ro li 60 Ncrson, Jean-Marc 69 niezm iennik 68 notacja 22 lizakow a 92 O o b ie k t d o stę p n y przez re fe re n cję 93 w a rto ść 93
Objcctory 22. 30, 50 O bserwacja, wzorzec analityczny 136 O CL (Object Construint Languagc) 67 Odell. Jim 16, 2 1 ,2 2 .2 8 . 122 odwzorowanie historyczne, wzorzec 98 ograniczenia abstract/ 90, 108 {bagl 94 /coniplete} 85, 156 {dag} 94 (frozen! 94, 157 ¡hierarchy! 94 {mandatory! 156 {ordered} 94 {ąueryf 65 read-only} 94 język opisu 67 OMG (Object Management Group) 16, 2 1, 22 operacja definicja 64, 65 notacja 64 różnica między metodą a 65 optymalizacja 44 {ordered}, ograniczenie 94
P pakiet 104 perspektywa implementacyjna asocjacje 6 1 asocjacje kw alifikow ane 96 asocjacje pochodne 90 atrybuty 64 atrybuty pochodne 90 definicja 59 nawigowalność 62 stosowanie 70 uogólnienie 66 perspektywa pojęciowa asocjacje 60 asocjacje kw alifikow ane 96 asocjacje pochodne 90 atrybuty 64 atrybuty pochodne 90 definicja 27, 58 operacje 65 przykład 136 stosowanie 69 uogólnienie 66 perspektywa spccyfikacyjna asocjacje 61 asocjacje kwalifikowane 96 asocjacje pochodne 90 atrybuty 64 atrybuty pochodne 90
definicja 58 nawigowalność 62 operacje 64 podtypy 92 przykłady 140. 141. 149 realizacja 92 stosowanie 25, 70 typy pochodne 92. 108 uogólnienie 66 pętla 117 plan dostarczania systemu 40 zarządzanie 4 1 podklasy 66, 90, 92 podmienialność definicja 66 i asercje 68 podtyp 65, 66, 100 pole 64 połączenie 132 powrót 73 prędkość projektu 39 proces definicja 20 fazy 30 przegląd 30 projektowanie rckursy wme 21 sterowane zobow iązaniam i 21 prototypowanie 35 Proxy, w-zorzec p ro je k to w y 45. 46 prywatny zasięg w idoczności w' C++ 101 Smalltalk u 102 przepływ sterowania 74. 123, 129 zadań 27, 122, 129 przykłady kodu (Java) 61, 96, 98, 99, 143, 144, 145, 146, 147, 148, 149 przypadki użycia systemu definicja 26, 33, 50 i zagrożenia techniczne 36 kategoryzacja 39 na diagramach czynności 129 na diagramach interakcji 72 przykładowy tekst 5 1 przypisywanie do ite ra cji 39 stosowanie 55 stosowanie kart C R C 79 stosowanie techniki 152 w ychw ytyw anie 53 Publiczny zasięg w idoczności w C + + 101
•lavie 102 Smalltalku 102
Punkty końcowe asocjacji 60 Q ' W y / , ograniczenie 65 R Rational Software 21, 22 {read-only/, ograniczenie 94 realizacja 92 refaktoryzacja 40, 147, 152 definicja 42 zasady 42 relacja 54, 55 przechodnia 106 rozszerzania 54 relacja zawierania definicja 53 przykład 52 stosowanie 54 rola 60, 157 w asocjacji 157 Role, wzorzec analityczny 86 rozgałęzienie definicja 122 przykłady 123 rozwidlenie definicja 122 przykłady 123, 125 Rumbaugh, Jim 16, 20, 21,22, 27, 47, 87 RUP (Rational Unified Process) 20, 30. 33,47
samowywołanie definicja 72 przykłady 73, 74 scalenie definicja 122 przykłady 123 scenariusz 50 . ... .« schemat przepływu sterowania 123. 12 SDL, technika modelowania 122 Shlaer, Sally 2 1 sieci Petricgo 122 słowo kluczowe a fte r 117 when 117 stan czynności 122 złożony 115, 117 stereotypy
«bind» 100
«history» 98 «im plem cntation class» 60 «type» 60 na diagramach fizycznych 134 S TL (Standard Tem platc L ibrary) 101 strona w ielokrotna 94 superklasa 66 supertyp 65 system ow y przypadek użycia 55
T technika m odelow ania obiektów 20 technika m odelow ania SDL 122 testowanie 41, I I I to ry d e fin icja 125 p rz y k ła d y 126 typ pochodny 65, 66, 100 podstaw ow y 65 «type», stereotyp 60, 156
U u o g ó ln ien ie p rz y k ła d y 95 stosowanie w pakietach 108 u o g ó ln ien ie przypadku użycia d e fin ic ja 54 p rz y k ła d 52 U R L 17, 38. 47, 48. 56, 69, 80, 150, 155
W Walden, K im 69 W arm er, Jos 67 warunek 72 końcowy 68 początkowy 68 wątek warunkowy 124 węzeł 132 W irfs-Brock, Rcbecca 80 współbicżność dynamiczna definicja 127 współdziałanie definicja 109 parametryzowanic 110 stosowanie 111 wyjątek 68 w yróżnik 85 wzorce 25, 26, 28, 44, 152 definicja 44 i współdziałanie 111 stosowanie 47
odwzorowanie historyczne 98 Scenariusz 46 wzorce analityczne definicja 46 Ilość 136 O b serw acja 136 Role 86 Z a k re s 101, 136, 138 Z ja w is k o z zakresem 136 wzorce projektow e 46 Composite 88 definicja 46 Facades 106 Proxy 46
Y Yourdon, Ed 21 t
Z zagrożenia kategorie 32 radzenie sobie z 33, 35, 36, 38 zagrożenia polityczne 32 radzenie sobie z 38 zagrożenia techniczne 32 radzenie sobie z 35 zagrożenia w ynikające z niedostatecznych umiejętności zespołu 32 radzenie sobie z 36 zagrożenia ze strony w ym agań 32 radzenie sobie z 33 Z a k re s , wzorzec a n a lityczn y 101, 136, 138 zależność 104 i komponenty 132 na diagramach klas 92 porównanie z asocjacją 63 zasięg klasy 84 zasięg widoczności definicja 101 pakietu 102 w C + + 101 w Javie 102 w Smalltalku 102 zawieranie definicja 87, 156 notacja 87, 88 przykład 87 zdarzenie I 17 złączenie definicja 124 przykłady 123, 125 znacznik iteracji 73 zobowiązanie 61, 79
M a rtin Fowler, K en d all Scott
UHL w kropelce M a r tin Fow ler i Kendall Scott są specjalistami od technik o b ie k to w ych w systemach k o m p u te ro w y c h oraz a u to ra m i o p ra co w a ń na ten te m a t. W książce U M L w kropelce autorzy w sposób przys tę p n y d zie lą się sw oim b o g a ty m d ośw iad czen iem w zastosowa niach praktycznych. Książka jest przeznaczona dla osób. k tó ry m nieobce są p o d s ta w y analizy o b ie k to w e j i p ro je k to w a n ia o b ie k to w e g o . W sposób zro zu m ia ły o m a w ia : ■a
historię języka, je g o rozw ój i p o w o d y jeg o powstania:
4>
in te g ro w a n ie U M L -a z procesami tw o rz e n ia o p ro g ra m o w a n ia o b ie k to w e g o :
o
p rz y p a d k i użycia systemu:
•2
d ia g r a m y klas. interakcji, s tan ó w i czynności;
»
p a k ie ty i w s p ó łd zia ła n ie:
•13> tech niki n ie -U M L - o w e . na p rzykład karty CRC i wzorce. O f ic y n a W y d
U M L (U n ified M o d e lin g Language - z u n ifik o w a n y język m o d e lo w a n ia ). o b e c n ie p o w szech n ie stosow any standard de facto, stanow i n o tację, k tó ra p o w in n a być zn a n a i ro zu m ia n a przez wszystkich p ro g ra m is tó w . To w y d a n ie jest z w ię z ły m p rz e w o d n ik ie m po n a j istotniejszych z a g a d n ie n ia c h U M L -a w z b o g a c o n y m o in fo rm a cje n a te m a t p o s łu g iw a n ia się d ia g ra m a m i p r z y p a d k ó w użycia i p o s łu g iw a n ia się d ia g r a m a m i czynności, a także o d o k ła d n e o m ó w ie n ie w s p ó łd z ia ła n ia o ra z s ta n o w i n ie z w y k le skuteczną p o m o c ą d la osób chcących szybko za p o zn a ć się z n o w y m ję z y k ie m .
LTP
biuro handlowe ul. Puławska 94 02-620 Warsza' tel. (022) 646-1 faks (022) 646 biuro@ltandp.< www Itandp co
Kim je s t Martin Fowler - autor książki „UML w kropelce”? M a r t i n F o w l e r je s t s z e fe m zespo łu b a d a w c ze g o w firm ie T h o u g h tW o rk s . W c z e ś n ie j ja k o
niezależny
k o n s u lta n t z a jm o w a ł k lie n tó w k o m e r c y jn y c h .
się p rz e p ro w a d z a n ie m
prac a n a lity c z n o -p ro je k to w y c h
dla
Czym je st UML ? N i e z b ę d n y m c z y n n ik ie m p rz y b u d o w ie system ów in fo rm a ty czn y c h jest dobro ro z u m ie n ie się w s p ó łp r a c u ją c y c h stron. D la te g o też U M L stał się k o n ie c zn y m n arzęd ziem w tym procesie i je s t u ż y w a n y do: •Jfi* w i z u a l i z a c j i
sp ecyfikacji
»12* konstrukcji
»12* d o k u m e n to w a n ia
K o n c e p c ja j ę z y k a U M L p ow stała w firm ie Rational S o ftw a re C o rp o ratio n z in ic ja ty w y jej trz e c h g łó w n y c h k o n s u lta n tó w : G r a d y 'e g o Boocha, Ivara Jacobsona. Jamesa R u m b a u g h a o r a / M ic h a e la D e v lin a - j e j prezesa. U M L zyskał p o w szech n ą akceptację w bran ży in fo rm a ty c z n e j
Czym je s t Rational Software Corporation? R a tio n a l
S o ftw a r e
C o rp o ra tio n jest c z o ło w y m
dostaw cą infrastruktury
in fo rm a ty c z n e j,
k tó ra w s p o m a g a proces w y tw ó r c z y o p ro g ram o w an ia, skraca czas je g o p o w s ta w a n ia i p r z y
czynia się d o p o p ra w ien ia je g o ja k o ś c i.
Czy oprogramowanie firmy Rational Software można kupić w Polsce? W y ł ą c z n y m d y s try b u to re m o p ro g ra m o w an ia firm y Rational S o ftw are w Polsce jest firm a P r e m iu m T e c h n o lo g y z W a rs z a w y .
Czy firma Prem ium Technology zajmuje się tylko dystrybucją oprogramowania? P r e m iu m T e c h n o lo g y d ysp o nu je zespołem c e rty fik o w a n y c h tren eró w , k tó rz y służą w s z e c h s tron ną p o m o c ą u ż y tk o w n ik o m o p ro g ra m o w a n ia oraz z a p e w n ia ją pom oc te c h n ic zn ą w ram ach usługi u trz y m a n ia .
Czy w Polsce można odbyć szkolenie z zakresu UML-a? S z k o le n ia
z
za kresu
U M L , ja k
ró w n ie ż
z w szystkich
p ro d u k tó w
o fe ro w a n y c h
p rzez
R a tio n a l S o ftw a r e są p ro w a d z o n e w P rem iu m T e c h n o lo g y p rzez c e rty fik o w a n y c h trenerów . S z k o le n ia są o p arte na o ry g in a ln y c h m ateriałach firm y R ational S o ftw a re , co w p o łączeniu z w ie d z ą osób s z k o lą c y c h g w a ra n tu je n a jw y ż s z ą ich jakość.
Gdzie m ożna więcej dowiedzieć się o technologii Rational? Z a p ra s z a m y do o d w ie d z e n ia stron w w w .P re m iu m T e c h n o lo g y .p l oraz w w w .R a tio n a l com. U d z ie la m y r ó w n ie ż in fo rm a c ji
telefonicznych pod n um erem : M 8 ( 2 2 ) 5 3 5 6 8 2 0.
R ation al unified p a r t n e r
Słowniczek P ro c e s p o w s ta w a n ia s ło w n ic t w a d o n o w e j d z ie d z in y je s t n i e z w y k l e ż m u d n y i tr u d n y . O p r ó c z tłu m a c z e ń z a p r o p o n o w a n y c h u
k s ią ż c e są u ż y w a n e , w
c o d z ie n n e j p r a c y i na
s z k o le n ia c h w f ir m ie P r e m iu m T e c h n o lo g y , in n e - s y n o n im ic z n e t e r m in y . P r e z e n tu je m y je tu ta ), a b y p r z y b liż y ć te n p r o b le m i z a c h ę c ić d o d y s k u s ji n a d tą t e r m in o lo g ią . T e r m in a n g ie ls k i T e r m i n k s i ą ż k o w y ............. I n n e u ż y w a n e t e r m i n y a c tiv ity ................................. c z y n n o ś ć ........................................ a k ty w n o ś ć , d zia ła n ie , fu n k c ja a c tiv ity d ia g ra m ................ d ia g ra m c z y n n o ś c i......................d ia g ra m a k ty w n o ś c i a lte rn a tive f lo w ................. a lte rn a ty w a ................................... scenariusz alternatyw ny, scenariusz poboczny a rg u m e n t............................ a rg u m e n t........................................ p a ra m e tr a k tu a ln y a s s o c ia tio n .........................a s o c ja c ja ........................................ zw ią ze k a s s o c ia tio n c la s s ............. klasa a s o c ja c y jn a ........................ klasa zw ią za na , klasa a s o c ja c ji b a s ic f lo w ........................... sce na n usz g łó w n y ...................... sce n a riu sz p o d s ta w o w y b in d in g ................................w ią z a n ie ......................................... d o w ią z a n ie c o lla b o ra tio n ...................... w s p ó łd z ia ła n ie ............................. w s p ó łp ra c a c o lla b o ra tio n d ia g ra m .....d ia g ra m w s p ó łd z ia ła n ia d ia g ra m w s p ó łp ra c y c o m p o s itio n ....................... z a w ie ra n ie ......................................k o m p o z y c ja , a g re g a c ja c a łk o w ita c o n s tr u c tio n ...................... b u d o w a ...........................................k o n s tru k c ja d e p lo y m e n t d ia g r a m ...... d ia g ra m w d ro ż e n ia ..................... d ia g ra m m o n ta ż o w y , d ia g ra m w d ro ż e n io w y d ia g r a m ...............................d ia g ra m ...........................................m o d e l w iz u a ln y e la b o r a tio n .........................ro z w in ię c ie .....................................o p ra c o w a n ie flo w o f e v e n ts ....................s c e n a riu s z ......................................p rz e p ły w zd arzeń fo c u s o f c o n t r o l................ p u d e łko a k ty w a c ji....................... o ś ro d e k s te ro w a n ia , s k u p ie n ie s te ro w a n ia g e n e ra liz a tio n ....................u o g ó ln ie n ie ................................... gen e ra liza cja , d z ie d z ic z e n ie in c e p tio n ..............................in ic ja c ja ...........................................w y p ro w a d z e n ie in h e rita n c e .......................... d z ie d z ic z n o ś ć .............................. d zie d zicze n ie in s ta n c e ............................... in s ta n c ja ......................................... e g ze m p la rz, o b ie k t lin k ........................................ w ią z a n ie .......................................... p o w ią z a n ie m u ltip le in h e rita n c e ......... d zie d zicze n ie w ie lo k ro tn e d z ie d z ic z e n ie w ie lo b a z o w e m u ltip lic ity ......................... k ro tn o ś ć .......................................... lic z n o ś ć n a v ig a b ility ......................... n a w ig o w a ln o ś ć ............................ k ie ru n k o w o ś ć n o t e ......................................n o ta tk a ............................................. n o tk a p a ra m e te riz e d c la s s klasa p a ra m e try z o w a ln a sza b lo n re a liz a tio n ...........................re a liz a c ja ......................................... w y k o n a n ie re fle xive m e s s a g e s a m o w y w o la n ie ..........................a u to k o m u n ik a t r e s p o n s ib ility ...................... z o b o w ią z a n ie ............................... o d p o w ie d z ia ln o ś ć s c o p e .................................... z a s ię g ............................................... za kre s s u b c la s s .............................. p o d ty p .............................................. s p e c ja liz a c ja s u b s t a t e ............................... p o d s ta n .......................................... sta n z a g n ie ż d ż o n y s u p e rc la s s ........................... ty p p o d s ta w o w y ......................... n a d k la s a , k la sa b a z o w a tr a n s ,t,o n .............................w d r o ż e n ie .......................................p rze k a z a n ie v ls ib lll,y ..................................s p e c t a t o r d o s tę p u ................ s p e c y fik a to r w id o c z n o ś c i
Klasa
N a zw a kla sy a try b u t.T y p = w a rto ś ć P o c z ą tk o w a o p e r a c ja ( lis t a a r g . ) : t y p w y n i k u
Uogólnienie
Ograniczenie
Stereotyp
{o p is ograniczenia)
« n a z w a s te re o ty p u »
Uwaga
Obiekt
te k s t
Asocjacja
Krotność asocjacji i
0..1
m..n
K la sa
d o k ia d n ie je d e n
K lasa
wiele (zero lu b w ięcej)
K lasa
o p c jo n a ln ie (zero lub je d e n )
K lasa
o k r e ś lo n a liczbow o
Rodzaj asocjacji Klasa
a g r e g a c ja
. o
z a w ie r a n ie _ uporządkowany;
• ro la u p o r z ą d k o w a n a
Asocjacja kwalifikowana
Nawigowalność n azw a roli
kwalifikator
Cel
Zależność
Diagram klas: Interfejsy
Diagram klas: Klasa parametryzowana Klasa asocjacyjna klasa w z o rc o w a
Z b ió r
elem ent z w ią z a n y
Diagram współdziałania n a z tta o b n A r» . kom unikai asynchroniczny 1 prcHJTi i ;irn n 1^1 >
I * komunikat iterowanyt) ---------- ►
nazwa roli
n a z w a o b ie k t u
Diagram stanów
N a / w a s u aa jrkuwReęo
Nazwa stanu entry akcja do ez\ nnosc exit akcja /darzenie akcja (argumenty)
z d a r a ’ m t i t a r g ’- r a c r C k \ « » a ru n e k ] a k c ja
Nazwa stanu
Stany w s p ó łb ie ż n e N a /w a stanu
/lo/o ne^o
Diagram pakietów N a/w a p a k ie tu
r klasa I
V i / « a pakietu klasa 3
zależność
klasa 2
Diagram wdrożenia
W y*/cl
kom ponent 2
f
---1 kom ponent I
Diagram przypadku użycia
C Aktor
