IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

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

Zrozumie UML 2.0.

Metody modelowania
obiektowego
Autor: Micha miaek
ISBN: 83-7361-918-6
Format: B5, stron: 296
Usprawnij proces tworzenia oprogramowania, stosujc modelowanie w jzyku UML
Poznaj podstawy modelowania obiektowego
Zamodeluj rodowisko, wymagania i architektur systemu
Zaprojektuj system w oparciu o model UML
Tworzenie zoonego systemu informatycznego wymaga przygotowania projektu.
Naley okreli w nim rodowisko dziaania systemu, wymagania uytkownikw,
procesy realizowane przez system i jego elementy skadowe. Opis sowny, przydatny
w trakcie zbierania zaoe funkcjonalnych, moe okaza si zbyt skomplikowany
i niejednoznaczny na pozostaych etapach opisywania powstajcego systemu.
Niezbdny jest taki sposb opisu, ktry byby jednakowo interpretowany i zrozumiay
dla wszystkich czonkw zespou projektowego. W tym celu opracowano jzyk UML
notacj umoliwiajc zamodelowanie systemu w sposb graficzny, w postaci
diagramw. Modele zapisane w jzyku UML s jednakowo interpretowane przez
wszystkie osoby zaangaowane w dany projekt. S te niezwykle uniwersalne.
Mona je stosowa we wszystkich fazach projektowania i budowy oprogramowania.
Ksika Zrozumie UML 2.0. Metody modelowania obiektowego to podrcznik
modelowania systemw informatycznych z wykorzystaniem notacji UML 2.0.
Przedstawia podstawy modelowania obiektowego i najwaniejsze pojcia zwizane
z obiektowoci. Opisuje sposoby modelowania otoczenia systemu, jego zakresu
funkcjonalnego oraz struktury. W ksice opisano rwnie proces przejcia z modelu
do kodu rdowego systemu oraz metodyki projektowe oparte na jzyku UML.
Kady, kto bierze udzia w procesie wytwarzania oprogramowania, znajdzie w tej
ksice przydatne dla siebie informacje.
Zasady modelowania obiektowego
Formuowanie i realizacja wymaga
Modelowanie otoczenia systemu oraz jego funkcjonalnoci
Projektowanie architektury systemu
Realizacja systemu w oparciu o projekt
Metodyki wytwarzania oprogramowania
Przekonaj si, jak bardzo UML moe uatwi proces tworzenia oprogramowania

Spis treci
Rozdzia 1. Wstp .............................................................................................. 5
1.1. Czym jest ta ksika? ................................................................................................ 5
1.2. Dla kogo jest ta ksika? ........................................................................................... 6
1.3. Dlaczego modelowanie? ............................................................................................ 7
1.4. Dlaczego jzyk UML? ............................................................................................... 8
1.5. Co dalej w ksice? ................................................................................................... 9
1.6. Oznaczenia typograficzne ........................................................................................ 12
1.7. Podzikowania ........................................................................................................ 13

Rozdzia 2. Wprowadzenie do modelowania ....................................................... 15

2.1. Trudna sztuka modelowania .................................................................................... 15
2.2. Zoono oprogramowania. Jak j pokona? ......................................................... 17
2.3. Metodyka wytwarzania oprogramowania ................................................................ 20

Rozdzia 3. Podstawy modelowania obiektowego .............................................. 25

3.1. Jak modelowa wiat obiektowo? ........................................................................... 25
3.2. Obiekty .................................................................................................................... 27
3.3. Klasy obiektw ........................................................................................................ 32
3.4. Modelowanie struktury ............................................................................................ 37
3.5. Modelowanie dynamiki ........................................................................................... 43
3.6. Ktre modele musz dobrze pozna? ..................................................................... 50

Rozdzia 4. Od opisu rodowiska do kodu .......................................................... 53

4.1. Jak zapewni zgodno kodu ze rodowiskiem? ..................................................... 53
4.2. cieka od opisu rodowiska do kodu ..................................................................... 57
4.3. Tworzenie systemw sterowane modelami ........................................................... 60
4.4. Formuowanie wymaga ......................................................................................... 63
4.5. Realizacja wymaga ................................................................................................ 65
4.6. Modele, narzdzia, jako ....................................................................................... 67

Rozdzia 5. Modelowanie rodowiska ................................................................ 71

5.1. Jak opisa rodowisko? ........................................................................................... 71
5.2. Struktura aktorzy, jednostki organizacyjne i pojcia .......................................... 77
5.3. Dynamika procesy, czynnoci i stany ................................................................. 87
5.4. Spjno modeli rodowiska ................................................................................. 100
5.5. Przykadowe problemy .......................................................................................... 102

Zrozumie UML 2.0. Metody modelowania obiektowego

Rozdzia 6. Modelowanie wymaga ................................................................. 105

6.1. Jak okreli zakres funkcjonalny systemu oprogramowania? ................................ 105
6.2. Struktura aktorzy, klasy .................................................................................... 108
6.3. Dynamika przypadki uycia, scenariusze, czynnoci, stany ............................. 124
6.4. Spjno modelu wymaga i zgodno ze rodowiskiem ..................................... 145
6.5. Przykadowe problemy .......................................................................................... 148

Rozdzia 7. Tworzenie architektury .................................................................. 151

7.1. Co to jest i z czego si skada architektura systemu oprogramowania? ................. 151
7.2. Struktura komponenty, interfejsy, klasy, wzy ................................................ 155
7.3. Dynamika interakcje, czynnoci ....................................................................... 177
7.4. Spjno architektury i zgodno z wymaganiami ................................................ 189
7.5. Przykadowe problemy .......................................................................................... 193

Rozdzia 8. Projektowanie i realizacja systemu ................................................ 195

8.1. Jak stworzy szczegowy projekt systemu? ......................................................... 195
8.2. Struktura interfejsy, klasy ................................................................................. 197
8.3. Dynamika interakcje, czynnoci ....................................................................... 205
8.4. Spjno projektu i zgodno z architektur ......................................................... 219
8.5. Przykadowe problemy .......................................................................................... 222

Rozdzia 9. Modelowanie w procesie wytwrczym ........................................... 225

9.1. Nowoczesne metodyki wytwarzania oprogramowania .......................................... 225
9.2. Proces techniczny oparty na modelach w jzyku UML ......................................... 232
9.3. Podsumowanie: czy modelowanie to srebrna kula? ........................................... 239

Dodatek A Podsumowanie skadni jzyka UML 2.0 ......................................... 241

Dodatek B Organizacja modeli w narzdziu CASE ............................................ 259
Dodatek C Krtki sownik metod obiektowych i jzyka UML ............................ 267
Literatura ..................................................................................... 287
Skorowidz ..................................................................................... 295

Rozdzia 3.

Podstawy modelowania
obiektowego
3.1. Jak modelowa wiat obiektowo?
Z poprzedniego rozdziau wiemy, e system oprogramowania powinien by jak najwierniejszym modelem otaczajcego wiata. Powstaje zatem pytanie, w jaki sposb
skonstruowa ten model, aby spenia to podstawowe wymaganie wiernoci? Mamy
bowiem do czynienia z dwoma rnymi punktami widzenia na oprogramowanie. Z jednej
strony stoj zamawiajcy, ktrzy maj pewne wymagania w stosunku do systemu. Z drugiej strony mamy programistw, ktrzy wiedz, jak konstruowa systemy. Zamawiajcy
znaj dziedzin problemu i potrafi o niej opowiada za pomoc specjalistycznego
sownictwa. Nie s to zazwyczaj osoby skonne do czytania, a tym bardziej tworzenia,
technicznych opisw systemu. Zamawiajcy chc opisa system w sposb jak najprostszy
i jak najbardziej zrozumiay w kontekcie swoich codziennych obowizkw. Wynika
to oczywicie z tego, e system powinien im pomaga w pracy, ktr wykonuj. Z drugiej
strony programici tworz system z bardzo precyzyjnych konstrukcji odpowiedniego
jzyka programowania. S oni najczciej dokadnie zorientowani w szczegach platformy sprztowej lub programowej, czy te w niuansach okrelonej biblioteki kodu.
Nie s natomiast zazwyczaj ekspertami w dziedzinie, dla ktrej tworz system. Ich
sownictwo jest zasadniczo rne od sownictwa zamawiajcych. Wymagaj zatem
bardzo dokadnego opisu sposobu konstrukcji systemu.
eby byo jeszcze trudniej, zarwno zamawiajcy, jak i programici musz panowa
nad systemem, ktry zwykle skada si z tysicy rnych wymaga, dziesitkw moduw czy setek tysicy wierszy kodu. Podkrelalimy to ju w poprzednim rozdziale.
Jak zatem pogodzi sprzeczne spojrzenia zamawiajcych i programistw? Jak zapanowa nad zoonoci problemu? Czy istnieje jaka moliwo porozumienia? Czytelnik
zapewne ju si domyla, e sposobem na wzajemne zrozumienie, ktry bdziemy chcieli
zaproponowa w tej ksice, jest modelowanie za pomoc technik obiektowych.

26

Zrozumie UML 2.0. Metody modelowania obiektowego

Elementem, ktry w modelowaniu obiektowym pozwala pogodzi jzyk uytkownika

z jzykiem programisty oraz pokona problem zoonoci systemu, jest obiekt. Obiekty
znajdujce si w rodowisku ustalaj wsplny jzyk w zespole odpowiedzialnym za
powstanie systemu oprogramowania (rysunek 3.1). Z jednej strony obiekty odpowiadaj
pojciom z modelowanej dziedziny problemu. Z drugiej strony s podstaw implementacji realizowanego systemu. Jest to moliwe dziki istnieniu obiektowych jzykw
programowania. Obiekty umoliwiaj realizacj zasady abstrakcji, gdy mog reprezentowa skomplikowane struktury (skadajce si z wielu elementw, ktre znowu
skadaj si z wielu elementw itd.). Dziki temu obiekty na danym poziomie abstrakcji
ukrywaj informacje nieistotne dla czytelnika modelu. Obiekty s zatem pewnego rodzaju
czarnymi skrzynkami (rysunek 3.7). Dopiero po otwarciu takiej czarnej skrzynki i wejciu
w gb odkrywamy dalsze szczegy.
Rysunek 3.1.
Obiekty wsplny
jzyk dla rnych
rl projektowych
modelarz

zamawiajcy

programista

Na bazie obiektw powstaj obiektowe modele (ang. model), czyli tak jak ju
mwilimy w poprzednim rozdziale kopie rzeczywistych systemw. Modelowanie
obiektowe (ang. object modeling) polega zatem na:
znajdowaniu obiektw w otoczeniu,
opisywaniu struktury i dynamiki dziaania obiektw,
klasyfikacji obiektw,
opisywaniu struktury powiza klas obiektw oraz
opisywaniu dynamiki wsppracy obiektw podczas funkcjonowania systemu.

Moemy te powiedzie, e modelowanie obiektowe polega na rysowaniu diagramw

opisujcych struktur i dynamik systemu skadajcego si z obiektw. Diagramy ukazuj
system na rnym poziomie abstrakcji.
Modele obiektowe bdziemy tworzy za pomoc jednolitej notacji. Bdzie ni graficzny
jzyk UML. W rozdziale przedstawimy podstawowe pojcia modelowania obiektowego
i ich notacj w jzyku UML: obiekty, klasy, diagramy opisu struktury i diagramy opisu
dynamiki. Bdzie to podstawowy jzyk porozumiewania si. Zostanie on wykorzystany
i rozbudowany w nastpnych rozdziaach do ustanowienia cieki od wymaga do kodu.

Rozdzia 3. Podstawy modelowania obiektowego

27

3.2. Obiekty
Jak ju powiedzielimy, obiekty wystpuj w rodowisku, ale rwnie mog by elementami systemu oprogramowania. Obiekty mog zatem by przedmiotami (urzdzeniami technicznymi, budynkami, tworami przyrody), osobami, ale rwnie rnego
rodzaju jednostkami organizacyjnymi, zdarzeniami lub dokumentami. W systemie
oprogramowania, oprcz obiektw odpowiadajcych elementom rodowiska, mog
wystpowa np. ekrany, interfejsy, bazy danych, zarzdcy aplikacji czy komunikacji.
Zwrmy uwag, e obiekty zwizane z opisem systemu s zalene od wykorzystywanej
technologii, a nie od modelowanego rodowiska. Takie obiekty techniczne pojawiaj
si w momencie, kiedy zaczynamy projektowa system wraz z jego architektur.
Zastanwmy si teraz nad tym, w jaki sposb naley opisywa obiekty. Obiekt
(ang. object) w rozumieniu modelowania obiektowego moe by opisany za pomoc
trzech elementw: tosamoci, stanu i zachowania. Kady obiekt ma zatem indywidualn
tosamo odrniajc go od innych obiektw. Obiekty zawieraj rwnie elementarne
skadniki o zmieniajcych si wartociach, ktre okrelaj ich stan. Potrafi te zachowywa si w odpowiedni sposb w rnych sytuacjach w odpowiedzi na komunikaty
wykonuj okrelone usugi na rzecz innych obiektw.

UML2.0

W jzyku UML obiekt jest reprezentowany za pomoc prostokta, ktry

zawiera podkrelon nazw obiektu (rysunek 3.2).

Rysunek 3.2.
UML: Podstawowa
notacja obiektu

mj_samochd

samochd_kolegi

Zanim przedstawimy bliej wymienione powyej elementy opisu obiektw, rozwamy

krtki przykad. Poniewa najatwiej jest chyba operowa na przykadzie znanych nam
urzdze technicznych, wemiemy pod uwag nasz samochd1 (rysunek 3.3). Ma on
niewtpliwie indywidualn tosamo, rn od tosamoci samochodu naszego ssiada.
Nie ma tutaj znaczenia fakt, e obydwa samochody wygldaj na pierwszy rzut oka
identycznie. atwo jest rozrni tosamo samochodw, jeeli widzimy je obok siebie.
Ten samochd jest nasz, a tamten naszego ssiada. S to przecie rne przedmioty,
nawet jeli wygldaj tak samo. Nasz samochd jest oczywicie w okrelonym stanie:
jest koloru brzowego, ma silnik pojemnoci 1200 cm3, silnik jest wyczony, hamulec
jest zacignity, numer nadwozia to ABC-3597564 itd. Samochd moe si te w okrelony sposb zachowywa moe uruchomi silnik, moe te skrci w lewo lub
w prawo albo pojecha do tyu. Musimy tylko go o to poprosi przekrci kluczyk
w stacyjce, skrci kierownic czy wrzuci wsteczny bieg. Na bazie tego przykadu
sprbujmy teraz formalnie zdefiniowa poszczeglne elementy opisu obiektu.

Zwrmy uwag, e bierzemy pod uwag nasz samochd, a nie oglnie jakikolwiek samochd.

28

Zrozumie UML 2.0. Metody modelowania obiektowego

Rysunek 3.3.
Tosamo, stan
i zachowanie
samochodu

y
564
597
zow
y
3

r
b
zon
BC
c
lor=
=A
wy
Ko
zia
=
o
ka
adw
ilni
nr n
ns
s ta

ss

iada

wcz silnik!

j
m

Stan (ang. state) obiektu to zbir wartoci (cech charakterystycznych) wszystkich

jego waciwoci. Wartoci waciwoci obiektu moe by np. jaka liczba, napis lub
element innego typu. Kady obiekt ma przypisany zbir waciwoci, ktre go charakteryzuj. S one nierozerwalnie zwizane z danym obiektem s jego skadowymi.
Zwrmy te uwag, e waciwoci s tak naprawd obiektami, ktre s w caoci
kontrolowane przez obiekt gwny. W czasie swojego ycia obiekt ma zawsze ten sam
zestaw waciwoci. Jednake waciwoci obiektu mog w trakcie ycia obiektu przyjmowa rne wartoci. Te rne wartoci wyznaczaj stan obiektu w danym momencie.

UML2.0

Stan obiektu okrelamy, podajc wartoci jego waciwoci (ang. property), ktre umieszczamy w przegrdce (ang. compartment) poniej nazwy
obiektu (rysunek 3.4). Po nazwie waciwoci umieszczamy znak =, a nastpnie
warto waciwoci. Oczywicie taka notacja jest moliwa dla waciwoci,
ktre przybieraj wartoci typw elementarnych (wartoci liczbowe, napisy itp.).
W przypadku gdy waciwo obiektu jest obiektem zoonym, wewntrz przegrdki waciwoci umieszczamy zazwyczaj jedynie nazw obiektu skadowego.
Stan waciwoci skadowej moemy pokaza, umieszczajc obok obiekt odpowiadajcy tej waciwoci i okrelajc wartoci waciwoci tego obiektu skadowego. Dodatkowo czymy obiekt gwny i obiekt skadowy cznikiem
(ang. link) wskazujcym na obiekt podrzdny. Na rysunku 3.4 obiektem gwnym jest mj_samochd. Jak widzimy, jedn z waciwoci tego obiektu jest
silnik. Aktualny stan silnika okrela obiekt o tej samej nazwie jak odpowiednia
waciwo mojego_samochodu.
mj_samochd
numer nadwozia="ABC-3597564"

silnik

kolor=brz
kierunek_skrtu=30

numer="HH22123"

silnik

pojemno=1200
status=wyczony

Rysunek 3.4. UML: Przykad notacji dla waciwoci elementarnych i zoonych

Rozdzia 3. Podstawy modelowania obiektowego

29

Tosamo (ang. identity) obiektu wyrnia obiekt wrd innych obiektw jako
osobn jednostk. Mona j okreli jako wyrnion cech obiektu, ktra pozostaje
niezmienna przez cay czas ycia tego obiektu. Co wicej, warto tej cechy powinna
by unikalna wrd wszystkich obiektw, ktre otaczaj nasz obiekt. W najprostszym
przypadku cech obiektu, ktra stanowi o jego tosamoci, jest umiejscowienie obiektu
(np. w pamici systemu). Moe si jednak okaza, e obiekt zmienia swoje pooenie
albo znajduje si w zbiorze nieuporzdkowanych obiektw o swobodnym dostpie
(np. w bazie danych). Wtedy tosamo obiektu powinnimy okreli poprzez dodanie
wyrnionej waciwoci (np. nadajc jej wyrnik identity). Naley tu podkreli,
e taka dodatkowa waciwo nie moe stanowi elementu stanu obiektu. Jako
taka powinna zatem przybiera wartoci cakowicie abstrakcyjne niezalene od
dziedziny problemu (ang. problem domain), czyli od otaczajcej rzeczywistoci.
Jeeli tosamo nie byaby cech abstrakcyjn obiektu, to mogaby ulec zmianie
w trakcie ycia obiektu w miar zmian dziedziny problemu. Warto te podkreli,
e oczywicie moliwe jest rozrnienie tosamoci obiektw za pomoc ich stanu
(np. stwierdzajc, jaki kolor ma samochd). Moe si jednak zdarzy, e w systemie
wystpi dwa rne obiekty o identycznym stanie. Wtedy jedyn moliwoci rozrnienia obiektw bdzie ich abstrakcyjna tosamo.

UML2.0

Najbardziej oczywiste rozrnienie tosamoci obiektw to po prostu

umieszczenie na diagramie rnych obiektw, ktre w szczeglnoci posiadaj
rne nazwy (mj samochd i samochd kolegi na rysunku 3.5). Wtedy
rozrnienie i dostp do stanu obiektw nastpuje poprzez odwoanie si
do ich unikalnego pooenia. Problem pojawia si wtedy, gdy obiekty chcemy
zapisa np. w bazie danych. W takiej sytuacji musimy do kadego obiektu
doczepi dodatkow metk odrniajc go od innych. Na rysunku 3.5 tak
metk jest dodatkowa waciwo o nazwie num. Aby zaznaczy, e ta waciwo nie jest elementem stanu obiektu, nadalimy jej wyrnik identity2.
Zwrmy te uwag, e obiekty na rysunku 3.5 s w identycznym stanie.
Wszystkie wartoci ich waciwoci s takie same. Dotyczy to nawet numerw nadwozi, ktre s (zapewne przez pomyk) identycznymi napisami.
Gdybymy zapisali te dwa obiekty w bazie danych bez wyrnika, to niemoliwe byoby ich rozrnienie.
mj _samochd

samochd_kolegi

<<identity>> num=sX000001

<<identity>> num=sX000002

numer_nadwozia="ABC-3597564"

numer_nadwozia="ABC-3597564"

kolor=brz

kolor=brz

kierunek_skrtu=30

kierunek_skrtu=30

Rysunek 3.5. UML: Przykad notacji dla rozrnienia tosamoci obiektw

Takie wyrniki umieszczone w podwjnych nawiasach ukonych nazywamy w jzyku UML

stereotypami. Zostan one omwione dokadniej w dalszych rozdziaach ksiki.

30

Zrozumie UML 2.0. Metody modelowania obiektowego

Na koniec zauwamy, e wyrnik identity jest wartoci, ktra powinna

by generowana automatycznie, tak aby zapewni jego unikalno (zwrmy
uwag na wyrniki obiektw na rysunku 3.5 bdce kolejnymi unikalnymi
wartociami w cigu).
Zachowanie (ang. behavior) obiektu to zbir usug, ktre obiekt potrafi wykonywa
na rzecz innych obiektw. Zachowanie ustanawia bardzo istotny element dynamiki
modelu (tzn. sposobu dziaania systemu). W ramach tej dynamiki obiekty mog prosi
inne obiekty o wykonanie odpowiednich usug. Obiekt reaguje na tak prob, jeeli
usuga jest w zbiorze obsugiwanych przez niego usug. Proby obiektw o wykonanie
usug bdziemy nazywali komunikatami (ang. message). W ramach wykonania
usugi obiekt przeprowadza odpowiednie dla usugi przetwarzanie danych. Jego efektem
moe by zmiana stanu obiektu albo dostarczenie drugiemu obiektowi odpowiedniego rezultatu przetwarzania. Efekt wykonania usugi zaley od trzech rzeczy: a) stanu
obiektu, b) parametrw komunikatu, c) stanu innych obiektw, z ktrych usug korzysta
obiekt podczas przetwarzania. Zaleno od stanu obiektu jest oczywista. Inaczej si
bdzie zachowywa np. samochd ze stanem paliwa rwnym 100%, a inaczej przy
stanie paliwa rwnym zero. Parametry (ang. parameter) komunikatu to lista wartoci
obiektw, ktre pozwalaj na sterowanie zachowaniem usugi. Usuga moe si zatem
zachowywa rnie w zalenoci od wartoci parametrw. Na przykad parametrem
usugi skr powinien by kt skrtu. W trakcie wykonywania usugi obiekt moe
rwnie poprosi inne obiekty o pomoc. Wtedy wysya do nich odpowiednie komunikaty. Dlatego te przetwarzanie usugi moe by zalene od stanu innych obiektw.
Po zakoczeniu wykonania usugi czsto nastpuje komunikat zwrotny od obiektu,
ktry wykona usug (wykonawcy), do obiektu proszcego o wykonanie usugi
(klienta). Przekazywane s w nim wartoci obiektw, ktre s rezultatem przetwarzania i na ktre oczekuje klient usugi.

UML2.0

Na rysunku 3.6 widzimy opis fragmentu zachowania si obiektu mj samochd. Jest to diagram sekwencji (ang. sequence diagram) pokazujcy
wymian komunikatw podczas jednego z wykona usugi uruchom si.
Komunikaty wymieniane s midzy kolumnami nazywanymi liniami ycia
(ang. lifeline). Kada kolumna odpowiada jednemu obiektowi. Kolejno wymienianych komunikatw jest liczona od gry do dou diagramu. Komunikat
wywoujcy usug jest zaznaczony poziom strzak o penym grocie, skierowan od obiektu klienta do obiektu wykonawcy. Na rysunku rozpoczcie
dziaania usugi uruchom si nastpuje poprzez skierowanie komunikatu
uruchom si do obiektu mj samochd. Zauwamy, e komunikat ten ma
parametr kod klucza. Nazwa parametru umieszczona jest w nawiasach
po nazwie komunikatu. Gdyby parametrw byo wicej, moglibymy je umieci rozdzielone przecinkami wewntrz nawiasu.
Po uruchomieniu usugi (przesaniu komunikatu) nastpuje wykonanie usugi
(ang. execution occurence). Zaznaczane jest jako wski prostokt umieszczony
na linii ycia. Z diagramu moemy wywnioskowa, e po wywoaniu usugi
samochd sprawdza, czy kod klucza jest odpowiedni. Prawdopodobnie sprawdzany jest rwnie stan paliwa w zbiorniku. W tym konkretnym przypadku

Rozdzia 3. Podstawy modelowania obiektowego

31

stan_paliwa=53%
ja

mj _samochd

silnik

stan_oleju=0%
uruchom_si(kod_klucza)
[kod klucza O.K.]: wcz_si
"zepsuty"
"zepsuty silnik"

Rysunek 3.6. UML: Przykad sekwencji komunikatw podczas realizacji usugi

zarwno stan paliwa, jak i kod klucza byy prawidowe. W zwizku z tym
samochd przesya do silnika komunikat wcz si. Zwrmy uwag, e
przesanie komunikatu nastpuje pod pewnym warunkiem (ang. condition).
Jest on umieszczony w nawiasach prostoktnych. Moemy si domyla, e
gdyby ten warunek nie by speniony (kod klucza nie byby O.K.), nastpiaby
jaka inna akcja (np. wysanie innego komunikatu).
Po otrzymaniu komunikatu wcz si silnik zapewne prbuje si uruchomi.
Z diagramu wynika, e mu si to nie udao. Wysya zatem komunikat zwrotny,
sygnalizujcy, e silnik jest zepsuty. Komunikat zwrotny zaznaczany jest przerywan lini. Przyczyn zepsucia silnika wyjania notatka (ang. note)
przyczepiona do obiektu brakuje oleju. Notatki umieszczone na rysunku 3.6
zawieraj w sobie opis aktualnych wartoci niektrych waciwoci poszczeglnych obiektw (czyli fragmenty stanw tych obiektw). Po otrzymaniu
komunikatu od silnika samochd wysya komunikat zwrotny sygnalizujcy
zepsucie silnika. Zwrmy uwag, e komunikat zwrotny koczy wykonanie
usugi. Wykonanie usugi zawarte jest zatem midzy komunikatem wywoujcym
usug a komunikatem zwrotnym.
Podsumowujc rozwaania na temat cech obiektw, naley stwierdzi, e bardzo
istotn wasnoci modelowania obiektowego jest to, e obiekty stanowi pewnego
rodzaju czarne skrzynki. Obiekt pokazuje na zewntrz tylko te swoje waciwoci
lub usugi, ktre s potrzebne innym obiektom. Inne szczegy s ukryte. Umoliwia
to realizacj zasady abstrakcji, o ktrej bya mowa w rozdziale 2. Moemy sobie zatem
wyobrazi obiekt jako czarn skrzynk z przyciskami (rysunek 3.7). Nacinicie
przycisku oznacza uruchomienie odpowiedniej usugi obiektu. Wynikiem wykonania
usugi jest rezultat, ktry otrzymuje ten, kto nacisn przycisk. Dla naciskajcego nie
jest natomiast wane, jak usuga jest w rodku wykonywana i kto jeszcze w jej wykonaniu
uczestniczy. Wane jest jednak, aby przyciski byy dobrze opisane, tak aby naciskajcy
wiedzia, co dostanie po naciniciu przycisku.

32
Rysunek 3.7.
Obiekt jako
czarna skrzynka
z przyciskami

Zrozumie UML 2.0. Metody modelowania obiektowego