5R]G]LD
=QDF]HQLH GLDJUDPŃZ NODV
Diagramy klas, obok diagramów przypadków u ycia, zaliczyć nale y do najcz ciej
stosowanych i zarazem kluczowych rodzajów diagramów w j zyku UML. S one po-
nadto powszechnie rozpoznawanym elementem najpopularniejszych metodyk i tech-
nik obiektowych. Przedstawiaj statyk systemu, stanowi c przede wszystkim pod-
staw przyszłej obiektowej bazy danych. Główne elementy diagramów klas maj
znaczny wpływ na układ i zawarto ć innych diagramów UML.
'LDJUDP NODV WR JUDILF]QH SU]HGVWDZLHQLH VWDW\F]Q\FK GHNODUDW\ZQ\FK HOHPHQWŃZ
G]LHG]LQ\ SU]HGPLRWRZHM RUD] ]ZLń]NŃZ PLG]\ QLPL
3RGVWDZRZH NDWHJRULH SRMFLRZH
RUD] QRWDFMD JUDILF]QD
Paradygmat podej cia obiektowego opiera si na zasadniczych poj ciach obiektu (ang.
object) i klasy.
2ELHNWHP MHVW ND G\ E\W v SRMFLH OXE U]HF] v PDMńF\ ]QDF]HQLH Z NRQWHN FLH UR]
ZLń]\ZDQLD SUREOHPX Z GDQHM G]LHG]LQLH SU]HGPLRWRZHM
Wszystko, co wiadomo o obiekcie, jest reprezentowane przez warto ci atrybutów
czyli cech statycznych tego obiektu. Natomiast zachowanie obiektu wyra one jest
w operacjach okre laj cych usługi, które oferuje obiekt. Zainicjowanie operacji skutkuje
u ytkowaniem i (lub) modyfikacj danych reprezentowanych przez warto ci atrybutów.
Obiekty charakteryzuj si unikatow to samo ci , jest wi c mo liwe ich jednoznaczne
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 61
&] Ł , 0 3RGVWDZ\ M]\ND 80/
wyodr bnienie ze zbiorowo ci innych obiektów, nawet gdy wszystkie warto ci prze-
chowywane przez te obiekty s identyczne. W istocie obiekt jest wyró niany poprzez
samo istnienie, a nie cechy opisowe.
Jednocze nie mo na powiedzieć, e dowolny obiekt jest instancj abstrakcyjnego poj -
cia, jakim jest klasa (ang. class) obiektu. Podstaw identyfikacji klasy stanowi grupy
obiektów charakteryzuj ce si :
t identyczn struktur danych, tj. takimi samymi atrybutami;
t identycznym zachowaniem, tj. takimi samymi operacjami;
t identycznymi zwi zkami;
t identycznym znaczeniem w okre lonym kontek cie.
.ODVD MHVW XRJŃOQLHQLHP ]ELRUX RELHNWŃZ NWŃUH PDMń WDNLH VDPH DWU\EXW\ RSHUDFMH
]ZLń]NL L ]QDF]HQLH
Ka da klasa zawiera wi c zestaw informacji istotnych z punktu widzenia kontekstu
systemu. Zestaw atrybutów, operacji i zwi zków z innymi klasami mo e być szerszy
lub w szy w zale no ci od wymaga dotycz cych przyszłego systemu. W diagramach
tych klas standardowo przedstawia si jako prostok t zło ony z trzech sekcji:
t nazwy klasy,
t zestawu atrybutów,
t zestawu operacji.
Rysunek 3.1 ujmuje mo liwe kombinacje graficznej prezentacji klas:
t sama nazwa klasy,
t nazwa klasy z zestawem atrybutów,
t nazwa klasy z zestawem operacji,
t nazwa klasy z zestawem atrybutów i operacji.
W zwi zku z ró norodno ci mo liwych sposobów specyfikowania klas nale y wy-
ró nić nast puj ce opcje ich prezentacji graficznej:
a) sama nazwa klasy umieszczona w jednosekcyjnym bloku oznacza, e sekcje
atrybutów i operacji zostały wyspecyfikowane, lecz nie s w sposób jawny
zamieszczone na diagramie klas (rysunek 3.2a);
b) alternatywnie, klas przedstawia si jako blok zło ony z trzech sekcji
z nazw w pierwszej sekcji i niewyspecyfikowanymi atrybutami
i operacjami (rysunek 3.2b);
c) je li liczba atrybutów lub operacji jest wi ksza, to ich wyliczanie
w odpowiednich sekcjach mo na przerwać wielokropkiem, co nale y
interpretować jako przypisanie klasie jeszcze innych atrybutów i operacji
niewymienionych bezpo rednio w specyfikacji (rysunek 3.2c).
62 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
5\VXQHN
a)
Przykłady opisu klas
KIient
Rezerwacja
c)
złó Rezerwacj ()
b)
anulujRezerwacj ()
weryfikujKlienta()
KontraktTerminowy
ilo ćKontraktów:
cenaNabycia:
cenaSprzeda y:
waluta:
d)
KartaKredytowa
typ:
numer:
dataWa no ci:
autoryzuj()
zablokuj()
5\VXQHN
a)
Opcje specyfikacji klas
Harmonogram
b)
Pracownik
c)
Projekt
nrProjektu:
opisProjektu:
dataRozpocz cia:
dataPlanowanegoZako czenia:
:
...
Liczb sekcji w ka dej klasie mo na zwi kszać, dodaj c np. sekcje zawieraj ce zo-
bowi zania (punkt Zaawansowane składniki diagramu) b d wyj tki. Sekcje te mo na
dodawać opcjonalnie w przypadkach, gdy jest to niezb dne dla podniesienia precyzji
diagramu klas, jednak nadmierne stosowanie dodatkowych sekcji mo e obni yć przej-
rzysto ć diagramu.
Klasy obiektów podobnie jak inne elementy j zyka UML powi zane s ró nego
rodzaju zwi zkami. W diagramach klas powszechnie stosuje si wszystkie cztery ro-
dzaje zwi zków j zyka UML, czyli:
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 63
&] Ł , 0 3RGVWDZ\ M]\ND 80/
t asocjacje,
t uogólnienia,
t zale no ci,
t realizacje.
Podstawowe cechy zwi zku asocjacji w uj ciu diagramu klas zostały scharakteryzo-
wane poni ej, podczas gdy pozostałe rodzaje zwi zków omówiono w punkcie Zaawan-
sowane składniki diagramu.
$VRFMDFMD
Głównym rodzajem zwi zków mi dzy klasami s asocjacje. Definicj asocjacji przed-
stawiono w rozdziale drugim. Asocjacja opisuje zbiór powi za pomi dzy obiektami,
tak jak klasa obiektu zbiór obiektów stanowi cych jej instancje. Wyró nia si dwa
rodzaje asocjacji:
t binarne,
t n-arne.
W praktyce dominuj asocjacje binarne (ang. binary associations), dlatego po wi co-
no im główn cz ć rozwa a na temat zwi zków asocjacji. Rysunek 3.3 przedstawia:
t asocjacj binarn harmonogramowania projektu (rysunek 3.3 a).
t asocjacj n-arn systemu kinowego (rysunek 3.3 b).
5\VXQHN
a)
Mened er
Projekt
Asocjacje
pomi dzy klasami
SystemD wi kowy
b)
SaIaKinowa
Repertuar
RezerwacjaMiejsc
64 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Asocjacje n-arne mo na równie nazwać asocjacjami n-argumentowymi, a wi c trój-
argumentow , czteroargumentow itd. Zilustrowane na rysunku 3.3 asocjacje opisuj
w sposób elementarny zwi zki mi dzy klasami. Pełna semantyczna interpretacja zwi z-
ku wymaga wprowadzenia szeregu dodatkowych elementów opisu. Tak wi c asocja-
cj mo na dokładnie sprecyzować poprzez zdefiniowanie jej nast puj cych cech:
t nazwy,
t ról powi zanych klas,
t nawigacji,
t liczebno ci,
t agregacji.
Wymienione cechy maj charakter podstawowy. Mo liwe jest rozszerzanie ich listy
w zale no ci od specyfiki projektu i potrzeb zespołu projektowego.
1D]Z\ DVRFMDFML
Istniej ró ne sposoby charakteryzowania asocjacji. Podaj c nazw asocjacji, okre la si
istot danego zwi zku. W celu unikni cia nieporozumie przy nazwie asocjacji mo -
na podać kierunek jej odczytu. Istnieje szereg mo liwo ci oznaczania nazw asocjacji.
Mog one być:
t nienazwane (rysunek 3.3);
t nazwane, z opcjonalnym zamieszczeniem znacznika wskazuj cego kierunek
interpretacji asocjacji (rysunek 3.4);
5\VXQHN
jest dokonywane
RozIiczenie KorespondencjaEIektroniczna
Asocjacja nazwana
t scharakteryzowane poprzez role klas pełnione w asocjacji (rysunek 3.5);
5\VXQHN
Repertuar
SeansFiImowy
Asocjacja
zestawienie pozycja
z wyspecyfikowanymi
rolami
t nazwane i równocze nie scharakteryzowane przez role (rysunek 3.6).
5\VXQHN
zarz dza
Pracownik
Projekt
Asocjacja nazwana
kierownik zlecenie
z wyspecyfikowanymi
rolami
Rysunek 3.4 wskazuje, e poszczególne transakcje finansowe reprezentowane przez
obiekty klasy Rozliczenie powi zane s z odpowiednimi dokumentami elektronicznymi,
które s instancjami klasy KorespondencjaElektroniczna. Dokumenty te stanowi pod-
staw dokonania transakcji.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 65
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5ROH
Ka d asocjacj mo na równie interpretować dwustronnie poprzez podanie ról (ang.
roles) pełnionych przez powi zane ze sob klasy. Rola asocjacji w zwi zku binarnym
jest powinno ci pełnion przez jedn klas obiektu wobec drugiej klasy. W asocjacji
n-arnej role mo na przypisać ka dej z powi zanych klas.
Nazwy ról umieszcza si po obydwu stronach asocjacji. Rola spełniana przez dan
klas lokowana jest bezpo rednio przy klasie okre lanej. Przykład asocjacji opisanej
wył cznie za pomoc ról przedstawiono na rysunku 3.5. Kompleksowy opis asocjacji
zawieraj cy jej nazw i role zaprezentowano na rysunku 3.6.
Poszczególne seanse, b d ce instancjami klasy SeansFilmowy, powi zane s z bie -
cym Repertuarem kinowym. Repertuar w istocie jest sumarycznym zestawieniem se-
ansów a wi c dany seans stanowi jedn z pozycji repertuaru.
Na powy szym rysunku zaprezentowano wycinek diagramu klas systemu harmono-
gramowania projektów informatycznych. Pracownik działu IT firmy, z którym bezpo-
rednio powi zano Projekt, automatycznie klasyfikowany jest jako jego kierownik.
Projekt potraktowano w kategoriach zlecenia zarz dzanego przez kierownika.
1DZLJDFMD
Do wykonywania operacji na obiektach poszczególnych klas niezb dne jest przesyłanie
komunikatów pomi dzy nimi. Dla ka dej asocjacji istniej cej pomi dzy klasami ko-
munikowanie domy lnie odbywa si w obydwu kierunkach asocjacji. Jest to nawiga-
cja dwukierunkowa. W praktyce wyst puj sytuacje, w których wskazanie kierunku
nawigacji zwi ksza efektywno ć komunikowania si (rysunek 3.7). Mamy wtedy do
czynienia z nawigacj jednokierunkow .
5\VXQHN
KIient Rachunek
Asocjacja z kierunkiem
nawigacji
Asocjacja ze wskazanym kierunkiem nawigacji nie oznacza bezwzgl dnego zabloko-
wania przej cia pomi dzy klasami w dwu kierunkach. Dwukierunkowo ć mo e być
bowiem osi gni ta w sposób mniej efektywny dzi ki wykorzystaniu asocjacji pomi dzy
innymi, wzajemnie powi zanymi klasami, zamieszczonymi na diagramie pomi dzy
klas docelow a ródłow .
/LF]HEQR Ł
Klasom odpowiadaj okre lone liczby obiektów. Liczebno ć to specyfikacja zakresu
dopuszczalnej liczby obiektów danej klasy bior cych udział w danym zwi zku. A zatem
jest to okre lenie liczby obiektów jednej klasy, które wi si z jednym obiektem
drugiej klasy znajduj cym si po przeciwnej stronie tej samej asocjacji. Tabela 3.1 przed-
stawia notacj liczebno ci asocjacji stosowan w j zyku UML.
66 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
7DEHOD Oznaczanie liczebno ci asocjacji
2]QDF]HQLH 2SLV 3U]\NDG
A
1 dokładnie jeden
1
B
1..* jeden lub wiele
1..*
C
0..1 zero lub jeden
0..1
D
* wiele
*
E
0..* zero lub wiele
0..*
dokładnie n
F
n
(n > 1) 4
G
1..n od 1 do n
1..7
H
0..n od 0 do n
0..5
od n do m
I
n..m
(n, m > 1) 6.11
J
n..* wi cej ni n
3..*
K
n, m, o..p, q liczebno ć zło ona
1, 4, 7..9, 12
Poprzez n rozumie si okre lon , znan liczb naturaln . Natomiast w przypadku ch ci
zasygnalizowania, e w okre lonej asocjacji bierze udział znaczna, lecz nieznana liczba
obiektów, u ywa si symbolu gwiazdki (*).
Rysunek 3.8 przedstawia diagram klas ze wskazaniem liczebno ci asocjacji.
Interpretacja liczebno ci asocjacji polega na ka dorazowym rozpatrzeniu sytuacji, gdy
po jednej jej stronie znajduje si jeden obiekt, natomiast liczba obiektów, które od-
powiadaj mu w drugiej klasie, jest ustalana. I tak wskazana na rysunku 3.8 asocjacja
kupuje ł cz ca klasy Klient i AparatTelefoniczny oznacza, e jeden Klient mo e kupić
jeden lub wiele AparatówTelefonicznych, natomiast jeden AparatTelefoniczny mo e
być zakupiony tylko przez jednego Klienta.
$JUHJDFMD
Kolejn cech asocjacji jest agregacja (ang. aggregation), która opisuje zwi zek ca-
ło ć-cz ć pomi dzy klasami. W rzeczywisto ci istnieje wiele zło onych obiektów skła-
daj cych si z cz ci, które w poł czeniu stanowi spójn cało ć. Wyró nia si dwa
rodzaje agregacji:
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 67
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN Zastosowanie liczebno ci asocjacji
t agregacj całkowit kompozycj ;
t agregacj cz ciow .
Dla wymienionych poj ć u ywa si alternatywnych nazw. Kompozycja nazywana jest
równie agregacj siln lub składow , natomiast agregacja cz ciowa agregacj
słab lub współdzielon . Agregacja całkowita jest oznaczona przez wypełniony romb,
natomiast cz ciowa przez pusty romb.
W obydwu rodzajach agregacji wyst puj dwa podstawowe poj cia:
t agregat, czyli obiekt stanowi cy cało ć;
t segment, czyli cz ć.
W przypadku agregacji całkowitej obiekty-segmenty b d ce cz ciami agregatów nie
mog samodzielnie i niezale nie funkcjonować. Usuni cie agregatu powoduje auto-
matyczn likwidacj wszystkich segmentów b d cych jego cz ciami. Natomiast agre-
gacja cz ciowa wskazuje na asocjacj , w której usuni cie obiektu b d cego agregatem
nie powoduje likwidacji obiektów b d cych jego cz ciami, czyli obiektów-segmentów.
Obiekty współdzielone mog zatem funkcjonować samodzielnie, niezale nie od agre-
gatu. Rysunek 3.9 przedstawia agregacj całkowit (rysunek 3.9a) i agregacj cz cio-
w (rysunek 3.9b).
Rysunek 3.9 prezentuje elementy obiektowych baz danych systemów informatycznych
firmy ubezpieczeniowej oraz kompleksu kinowego. Na jego podstawie mo na stwier-
dzić, e Składka jest niezb dnym elementem PolisyUbezpieczeniowej i nie mo e w ad-
nym wypadku poprawnie funkcjonować w oderwaniu od niej. Potraktowanie Seansów-
Filmowych w kategoriach agregacji cz ciowej wskazuje jednak, e s one integraln
cz ci Repertuaru, ale przykładowo w razie jego zast pienia nie zostan utracone, lecz
mog zostać zaadaptowane do jego nast pcy.
68 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
5\VXQHN
a) b)
Agregacja całkowita
PoIisaUbezpieczeniowa Repertuar
a agregacja cz ciowa
1 1
1..* 0..*
Składka SeansFiImowy
Rysunek 3.10 przedstawia diagram klas zaprezentowany na rysunku 3.8, rozbudowa-
ny o dodatkowe kategorie modelowania, w tym agregacje.
5\VXQHN Diagram klas z uwzgl dnieniem agregacji
Na pierwszy rzut oka warto ć informacyjna przekazywana przez uaktualniony diagram
nie jest zasadniczo zwi kszona. Wci centralnym elementem bazy danych pozostaje
klient sieci telefonii komórkowej, o którym gromadzone s informacje w postaci obiek-
tów klasy Klient. Do ka dego zarejestrowanego Klienta przyporz dkowano przynajm-
niej jedn Kart SIM, któr Klient w praktyce u ytkuje. Taryfa wykorzystywana przez
Klienta przypisywana jest oddzielnie do ka dej KartySIM, aby w przypadku posiada-
nia przez danego Klienta kilku AparatówTelefonicznych w danej sieci umo liwić mu
niezale ne stosowanie ró nych Taryf na przykład taryfy o niskim stałym abona-
mencie dla telefonu wykorzystywanego prywatnie, natomiast dla telefonów słu bowych
tej charakteryzuj cej si wysokim abonamentem i niskimi kosztami zmiennymi. Mog
istnieć KartySIM bez przyporz dkowanej Taryfy sytuacja ta ma miejsce chocia by
w przypadku rozwi zania umowy przez Klienta. Zwa ywszy, e najcz stszym sposo-
bem rozpocz cia korzystania z usług danej sieci telefonii komórkowej jest transakcja
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 69
&] Ł , 0 3RGVWDZ\ M]\ND 80/
wi zana kupno nie tylko KartySIM, lecz tak e zawieraj cego j AparatuTelefonicz-
nego sieć dla celów marketingowych i ksi gowych przechowuje informacje o do-
st pnych modelach AparatówTelefonicznych oraz ich przypisaniu do własnych Klien-
tów. Sprzeda dokonywana jest przez SalonyFirmowe. Wskazanie na uaktualnionym
diagramie kierunku nawigacji pomi dzy klasami SalonFirmowy oraz AparatTelefoniczny
informuje, e do odpowiedzialno ci SalonuFirmowego nale y wskazanie wszystkich
sprzedanych przez t placówk AparatówTelefonicznych, natomiast zale no ć ta nie funk-
cjonuje w drug stron na podstawie danych reprezentowanych przez klas Aparat-
Telefoniczny nie mo na stwierdzić, który salon dokonał sprzeda y. Jednocze nie Salon-
Firmowy musi oferować minimum 10 AparatówTelefonicznych.
Rysunek 3.10 uporz dkowuje ponadto kwestie zwi zane z Korespondencj docieraj -
c do Klienta. Klient otrzymuje wiele zestawów dokumentów traktowanych jako
obiekty klasy Korespondencja. W praktyce dokonywane jest to okresowo, najcz ciej
co miesi c. Opisywany diagram klas jednoznacznie wskazuje, e elementem takiej Ko-
respondencji standardowo jest Billing, a zatem zestawienie poł cze , oraz Faktura. Li-
czebno ci dotycz ce opisywanych asocjacji wskazuj , e pojedyncza Korespondencja
mo e zawierać kilka Billingów b d Faktur. Przykładowo ma to miejsce, je li Klient
posiada w danej sieci kilka aktywnych AparatówTelefonicznych rozliczanych oddziel-
nie. W przypadku wprowadzonych do systemu druków okoliczno ciowych Faktury oraz
zestawienia poł cze nie s oczywi cie doł czane, st d wskazanie tego zwi zku jako
opcjonalnego w postaci liczebno ci 0..*. Usuni cie z systemu zapisów dotycz cych prze-
słanej Korespondencji poci ga za sob jednoczesne usuni cie wpisów dotycz cych
Billingów i Faktur. Poniewa Faktura, poza wykonanymi poł czeniami, mo e opie-
wać tak e na inne produkty b d usługi (cena aparatu telefonicznego, koszt aktywacji,
opłata za modyfikacj planu taryfowego itd.), jej poszczególne pozycje przechowy-
wane s w obiektach osobnej klasy Pozycja. Warto zaznaczyć, e Pozycja powi zana
jest z Faktur za pomoc silnej odmiany zwi zku agregacji (kompozycji), co wska-
zuje, i usuni cie z systemu wpisu dotycz cego Faktury zlikwiduje wszystkie jej cz ci
reprezentowane przez obiekty klasy Pozycja.
=DDZDQVRZDQH VNDGQLNL GLDJUDPX
Diagram klas charakteryzuje si znaczn liczb zaawansowanych elementów i koncep-
cji modelowania. Obejmuj one:
t rodzaje diagramów klas;
t zobowi zania;
t widoczno ć;
t atrybuty i operacje statyczne;
t nazwy klas, atrybutów i operacji;
t notacj atrybutów i składni operacji;
t klasy asocjacyjne;
70 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
t asocjacje zwrotne i wielokrotne;
t kwalifikacj ;
t uogólnienia, klasy abstrakcyjne oraz konkretne;
t zale no ć;
t realizacj .
5RG]DMH GLDJUDPŃZ NODV
Diagramy klas, ze wzgl du na znaczn liczb elementów, jakie potencjalnie mog na
nich wyst pić, cechuj si zró nicowanym poziomem szczegółowo ci. W celu uzyska-
nia odpowiedniej efektywno ci oraz skuteczno ci procesu tworzenia SI nale y rozró nić
ci le powi zane ze sob dwa poziomy tworzenia diagramów klas:
t poziom konceptualny,
t poziom implementacyjny.
Pomi dzy wyró nionymi poziomami mo liwe s rozwi zania po rednie, b d ce wy-
nikiem kolejnych iteracji tworzenia systemu. Konceptualny diagram klas zawiera wy-
ł cznie podstawowe elementy, cechuj c si przyst pno ci nazewnictwa klas, atrybu-
tów i operacji. Jest zrozumiały dla u ytkownika i wynika bezpo rednio z analizy
dziedziny przedmiotowej. Z kolei implementacyjny diagram klas jest stopniowo wzbo-
gacany o elementy opisu niezb dne dla prawidłowej specyfikacji modelu, takie jak typy
danych, zobowi zania, widoczno ć, statyczno ć, klasy asocjacyjne, kwalifikacje, uogól-
nienia, zale no ci czy te realizacje. Dobór tych elementów modelu jest uzale niony
od specyfiki danego projektu. Klasy na poziomie implementacyjnym mo na dodat-
kowo oznaczyć stereotypem implementation class.
=RERZLń]DQLD
Elementy techniki diagramów klas mog posłu yć do okre lenia zobowi za (ang.
responsibilities) klas, poprzedzaj cego opracowanie pełnego projektu. Najcz ciej mo -
liwo ć t wykorzystuje si w celu wypracowania koncepcji realizacji scenariuszy przy-
padków u ycia, głównie za pomoc diagramów interakcji (rozdziały 6. 10.). Zobo-
wi zania klasy mo na nakre lić na podstawie wyników modelowania biznesu czy te
definiowania wymaga systemu. A zatem zobowi zanie jest kontraktem lub odpowie-
dzialno ci klasy. Klas ModelReakcji zawieraj c sekcj zobowi za przedstawia
rysunek 3.11.
5\VXQHN
ModeIReakcji
Sekcja zobowi za
w klasie
responsibiIities
adekwatne reagowanie na odebranie sygnału z czujnika
współpraca z systemami Policji, Stra y Po arnej oraz Pogotowia Ratunkowego
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 71
&] Ł , 0 3RGVWDZ\ M]\ND 80/
System nadzoru pomieszcze przechowuje w klasie ModelReakcji operacje, które s
wykonywane w przypadku odebrania przez jeden z czujników zainstalowanych w mo-
nitorowanych pomieszczeniach sygnału wskazuj cego na zagro enie. Innym zobowi -
zaniem zamieszczonej na rysunku klasy jest automatyczne informowanie odpowied-
nich słu b publicznych o zaistniałym zagro eniu.
Specyfikacja zobowi za pełni rol pomocnicz w procesie projektowania diagramów
klas, gdy dostarcza wysokopoziomowego opisu zada poszczególnych klas. W ten
sposób, unikaj c koncentrowania si na wyszczególnianiu obszernej listy atrybutów
i operacji danej klasy, twórca systemu mo e rozwa yć, czy nie jest ona obarczona
nadmiarow list . Klasy ze zobowi zaniami s w naturalny sposób przekształcane
w diagram klas z pełn specyfikacj atrybutów i operacji. Klas , której podstawow
zawarto ć stanowi zobowi zania oraz lista współpracuj cych klas, nazywa si kar-
t CRC (Class-Responsibility-Collaboration card).
:LGRF]QR Ł
Istniej zró nicowane wymagania wzgl dem dost pu do poszczególnych atrybutów
i operacji ró nych klas w systemie. W systemie musi być zapewniona mo liwo ć peł-
nej ochrony niektórych danych czy te zapewnienia ich dost pno ci tylko dla pewnej
cz ci obiektów innych klas składaj cych si na statyk danej aplikacji. Uwarunkowa-
nia te spełniane s przez cech widoczno ć (ang. visibility), która oznacza poziom do-
st pno ci atrybutów i operacji dla innych klas. Tabela 3.2 przedstawia stosowane
w j zyku UML poziomy widoczno ci.
7DEHOD Poziomy widoczno ci
3R]LRP 6\PERO &KDUDNWHU\VW\ND
Publiczny + obiekty wszystkich klas w systemie maj dost p do atrybutu lub operacji
Prywatny tylko obiekty danej klasy maj dost p do atrybutu lub operacji
Chroniony # wył cznie obiekty klas dziedzicz cych z danej klasy maj dost p
do atrybutu lub operacji
Pakietowy ~ tylko składowe pakietu, do którego dana klasa nale y, maj dost p
do atrybutu lub operacji
Istnieje reguła wskazuj ca, by atrybuty klas definiować jako prywatne w celu mini-
malizacji zagro enia utraty kontroli nad dost pem do atrybutów i operacji poszcze-
gólnych klas systemu. Dost p do nich z zewn trz umo liwia si za po rednictwem pu-
blicznych operacji.
Sposób oznaczania poziomów widoczno ci atrybutów i operacji w ramach klas przed-
stawia rysunek 3.12.
72 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
5\VXQHN
Licytacja
Oznaczenie
widoczno ci w klasie + dataRozpocz cia:
+ czasTrwaniaLicytacji:
+ cenaWywoławcza:
~ dostawa:
- idLicytacji:
+ utwórzLicytacj ()
+ zamknijLicytacj ()
+ wy wietlOpisArtykułu()
# przypiszKupuj cego()
- modyfikujOpis()
$WU\EXW\ L RSHUDFMH VWDW\F]QH
Ka dy obiekt klasy przechowuje zazwyczaj własne, odmienne, modyfikowalne warto ci
atrybutu b d operacji. Jednocze nie wszystkie instancje danej klasy mog przecho-
wywać pewne stałe, identyczne warto ci np. stały mno nik, rodzaj waluty, opera-
cj tworzenia lub usuwania. W przypadku zmiany takiej warto ci w jednym obiekcie
zmiana ta jest automatycznie wprowadzana w innych obiektach tej klasy. Opisan cech
atrybutów i operacji nazywa si statyczno ci . Tak wi c zarówno atrybuty, jak i ope-
racje mog być:
t egzemplarzowe indywidualne dla ka dego obiektu danej klasy;
t statyczne to same we wszystkich obiektach klasy.
Atrybuty i operacje statyczne podkre la si lini ci gł .
1D]Z\ NODV DWU\EXWŃZ L RSHUDFML
Wyja nienie poj cia widoczno ci pozwala na sprecyzowanie reguł nadawania nazw
klasom, atrybutom i operacjom. Nazwa samej klasy na poziomie konceptualnym naj-
cz ciej jest wyra eniem rzeczownikowym. Z kolei na poziomie implementacyjnym
przybiera ona postać ła cucha znaków z wyszczególnieniem pocz tku ka dego wyrazu
składowego za pomoc wielkiej litery. Przykładami poprawnych nazw klas s Aukcja,
SesjaGiełdowa, PochodnyInstrumentFinansowy. Równie nazewnictwo atrybutów i ope-
racji jest zró nicowane dla poziomu konceptualnego i implementacyjnego diagramu
klas. Przykładowe nazwy obu kategorii zawieraj tabele 3.3 i 3.4.
7DEHOD Konwencja nazewnictwa atrybutów
1D]ZD QD SR]LRPLH 1D]ZD QD SR]LRPLH
$WU\EXW
NRQFHSWXDOQ\P LPSOHPHQWDF\MQ\P
pojemno ć karty SIM Pojemno ć Karty pojemno ćKarty
adres salonu firmowego Adres Salonu adresSalonu
numer telefonu komórkowego Nr Telefonu Komórkowego nrTelefonuKomórkowego
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 73
&] Ł , 0 3RGVWDZ\ M]\ND 80/
7DEHOD Konwencja nazewnictwa operacji
1D]ZD QD SR]LRPLH 1D]ZD QD SR]LRPLH
2SHUDFMD
NRQFHSWXDOQ\P LPSOHPHQWDF\MQ\P
zablokowanie karty SIM Zablokuj Kart zablokujKart ()
zmiana aktualnych stawek Zmie Stawki Taryf zmie StawkiTaryf()
wszystkich taryf
wysłanie krótkiej wiadomo ci Wy lij SMS wy lijSms()
tekstowej
1RWDFMD DWU\EXWŃZ L VNDGQLD RSHUDFML
Specyfikacja typów danych okre laj cych poszczególne atrybuty jest pozornie nie-
skomplikowan czynno ci . Istotnie, nie nastr cza trudno ci pod warunkiem bycia
wiadomym tego, e typy danych uzale nione s od struktury j zyka programowa-
nia, w którym nast pi wdro enie. Dlatego te narz dzia CASE ró nych producentów
udost pniaj niejednolity ich zestaw. Podsumowanie najpowszechniej u ywanych ty-
pów danych przedstawia tabela 3.5.
7DEHOD Standardowe typy danych
7\S\ GDQ\FK 1DU]G]LH 5DWLRQDO 5RVH 3ODWIRUPD 1(7
Logiczne Boolean Boolean
Stałoprzecinkowe Byte Byte
Integer Short
Long Integer
Long
Zmiennoprzecinkowe Single Single
Double Double
Decimal
Znakowe String String
Char
Inne Date Date
Object Object
Currency
Variant
Notacja atrybutów na poziomie implementacyjnym charakteryzuje si standardow
składni . Ich prezentacja na diagramie odbywa si wg nast puj cej formuły:
::= [] [ / ] [ : ]
[ [ ] ] [ = ] [ { -wła ciwo ci> } ]
74 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Analogicznie, równie dla operacji istnieje formuła składniowa:
::= [] [ ( ) ]
[ : ]
Lista parametrów wskazuje parametry operacji oddzielone przecinkami. Składnia pa-
rametru jest analogiczna do składni atrybutu, z t ró nic , e przed jego nazw zamiast
opcjonalnej widoczno ci oraz symbolu uko nika (wskazuj cego atrybuty pochodne)
umieszcza si przedrostek wskazuj cy kierunek przekazywania parametru. Jest to rów-
nie element opcjonalny, domy lnie przyjmuj cy warto ć in.
Liczba uwzgl dnianych parametrów mo e być dowolna. Charakterystyczne kombinacje
informacji dotycz ce atrybutów przedstawia tabela 3.6, podczas gdy najcz ciej spoty-
kane elementy składni operacji zawarto w tabeli 3.7.
7DEHOD Przykłady zastosowania typów danych i domy lnych warto ci atrybutów
3U]\NDG ,QWHUSUHWDFMD
Wył cznie nazwa atrybutu ze wskazaniem widoczno ci
Płatno ć
# suma:
Nazwa atrybutu wraz ze wskazaniem jego typu
Płatno ć
i widoczno ci
# suma: Integer
Nazwa atrybutu (ze wskazaniem typu i widoczno ci)
Płatno ć
oraz jego liczebno ć
# suma: Integer [0..*]
Zaprezentowana powy ej sytuacja, poszerzona o warto ć
Płatno ć
pocz tkow atrybutu
# suma: Integer [0..*] = 750
Chroniony atrybut typu Integer o liczebno ci 0 lub wiele,
Płatno ć
maj cy warto ć pocz tkow 750 z przypisan wła ciwo ci
# suma: Integer [0..*] = 750 {changable}
changeable
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 75
&] Ł , 0 3RGVWDZ\ M]\ND 80/
7DEHOD Przykłady zastosowania składni operacji
3U]\NDG ,QWHUSUHWDFMD
Nazwa operacji ze wskazaniem
Płatno ć
widoczno ci
+ obliczPłatno ć()
Nazwa operacji wraz ze wskazaniem
Płatno ć
widoczno ci i wła ciwo ci, która
wskazuje typ wyniku
+ obliczPłatno ć() : Long
Nazwa operacji (ze wskazaniem
Płatno ć
widoczno ci) poszerzona o list
parametrów ze wskazaniem ich typów
+ obliczPłatno ć(pozycja :Byte, obni ka :Boolean)
Płatno ć
+ obliczPłatno ć(in pozycja :Byte = 50, obni ka :Boolean) : Long
Publiczna operacja zwracaj ca wynik typu Long zawieraj ca atrybuty: pozycja typu Byte
(o pocz tkowej warto ci 50) oraz obni ka typu Boolean uzupełniona o jawne wskazanie
kierunku przekazywania parametru (in).
Omówione w niniejszym podrozdziale elementy opisu atrybutów i operacji zawarto
na rysunku 3.13.
5\VXQHN
OpcjaFinansowa
Zło ona reprezentacja
atrybutów i operacji
premiaOpcyjna: Single = 10 000
wielko ćKontraktu: Double = 1 000 000
tick: % = 0,01
warto ćTicku: Byte = 25
liczTicki(cenaSprzeda y :Double, cenaNabycia :Double) : Single
realizuj(ilo ćTicków :Single, warto ćTicku :Byte, ilo ćKontraktów :Integer) : Double
Powy szy rysunek przedstawia klas OpcjaFinansowa, która zawiera cztery atrybuty
i dwie operacje. Klasa ta powstała na wczesnym etapie tworzenia systemu zaprezen-
towanego w punkcie Studium diagramu klas. Warto ć pojedynczych kontraktów ter-
minowych, których przykładem jest opisywana opcja, jest rz du miliona USD, zatem
atrybut wielko ćKontraktu domy lnie przyjmuje t wła nie warto ć. Ze wzgl du na mo -
liwo ć przypisywania do niego znacznych kwot zdecydowano si na typ danych Double.
Tak samo wyra ony w procentach atrybut tick przyjmuje domy lnie warto ć 0,01,
natomiast kolejny atrybut niezb dny w opisie kontraktu terminowego, warto ćTicku,
25 USD. Zwa ywszy, e warto ciTicków to niewielkie liczby, w tym przypadku wy-
starczaj cy jest typ Byte. PremiaOpcyjna, suma istotnie wi ksza, lecz nigdy nie tak
76 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
du a jak wielko ćKontraktu, jest atrybutem typu Single. W tym przypadku prawdopo-
dobnie wystarczaj cy byłby typ Integer w wi kszo ci j zyków programowania ogra-
niczony z góry liczb 65 536 lecz przyj cie pojemniejszego typu danych ma na celu
zabezpieczenie si przed ewentualnym wyst pieniem bł du przepełnienia zmiennej.
Nale y podkre lić, e zamieszczona na opisywanym rysunku klasa jest rezultatem jed-
nej z pocz tkowych iteracji tworzenia dokumentacji statyki systemu, zatem nie uwzgl d-
niono na nim wszelkich niezb dnych w tej sytuacji atrybutów i operacji oraz znaczni-
ków widoczno ci, typowych dla tego poziomu szczegółowo ci. Tak samo atrybutowi
premiaOpcyjna przypisano pocz tkowo warto ć domy ln w wysoko ci 10 000 USD,
z której w kolejnych iteracjach zrezygnowano. Powodem było to, e warto ć pre-
miiOpcyjnej jest ró na w niemal ka dym przypadku zale y ona bowiem od ryzyka
zwi zanego z transakcj i zazwyczaj znacznie ni sza ni na wskazanym przykła-
dzie. Operacja liczTicki zwraca liczb ticków czyli w istocie podaje zmian ceny
instrumentu bazowego kontraktu terminowego na podstawie cen nabycia oraz cen sprze-
da y tego instrumentu. Ponownie w ramach rodków ostro no ci przyj to bardziej po-
jemny typ danych dla zwracanej warto ci. Operacja realizuj, zawieraj ca trzy parame-
try, oblicza zysk albo strat z tytułu zawarcia kontraktu terminowego. Ze wzgl du na
to, e ten rodzaj instrumentów finansowych niesie ze sob znaczne ryzyko, a ich na-
bywca rzadko ogranicza si do zawarcia pojedynczych kontraktów, zarówno potencjal-
ne zyski, jak i straty s olbrzymie, wi c do ich wyra enia przewidziano bardzo po-
jemny typ danych Double.
J zyk UML umo liwia obliczanie warto ci atrybutów pochodnych (ang. derived attri-
butes). Poprzedzone s one znakiem uko nika / . Ich warto ć ustala si na zasadzie
przypisania okre lonej formuły obliczeniowej, która korzysta z warto ci innych atry-
butów na diagramie klas. Formuła zazwyczaj jest zapisywana jako notatka odnosz ca
si do atrybutu pochodnego. W odniesieniu do scharakteryzowanego przykładu opcji
finansowej atrybutem pochodnym mo e być atrybut /warto ćTransakcji, który jest ilo-
czynem atrybutu wielko ćKontraktu z klasy OpcjaFinansowa oraz atrybutu przecho-
wuj cego liczb zawartych kontraktów, umieszczonego w tej samej klasie b d do-
wolnej klasie powi zanej.
.ODV\ DVRFMDF\MQH
Klasa asocjacyjna (ang. association class) umo liwia bardziej precyzyjny opis zwi z-
ku mi dzy klasami. Słu y do przedstawiania asocjacji w postaci klas. Zawiera zatem,
podobnie jak inne klasy, nazw , atrybuty i operacje. Liczb sekcji mo na zwi kszać.
Ka dej asocjacji mo na przypisać co najwy ej jedn instancj tego rodzaju klasy. Na
diagramie klas klas asocjacyjn wprowadza si poprzez cie k asocjacyjn w postaci
linii przerywanej (rysunek 3.14).
I tak RezerwacjaMiejsc jest klas asocjacyjn dokumentuj c asocjacj pomi dzy Reper-
tuarem a Projekcj Seansu. Z jednym Repertuarem zwi zanych jest wiele Projekcji-
Seansu. Przewidziano mo liwo ć tworzenia kilku Repertuarów, np. dziennego, wieczor-
nego, weekendowego. Wst pnie przyj to ograniczenie liczby ró nych repertuarów (5).
Przedstawianie asocjacji w postaci klasy dotyczy tak e asocjacji n-arnych (rysunek 3.15).
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 77
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN
1..5 1..*
Repertuar ProjekcjaSeansu
Asocjacyjna
klasa obiektów
RezerwacjaMiejsc
FazaProjektu
- idFazy:
- opisFazy:
- nazwaFazy:
- numerFazy:
- stopie Zło ono ci:
- wytworzoneArtefakty:
+ dodajFaz ()
+ usu Faz ()
+ dodajArtefakt()
+ usu Artefakt()
+ modyfikujArtefakt()
+ grupujArtefakty()
struktura
1..*
realizacji
Projekt
Osoba - idProjektu:
- opisProjektu:
- idOsoby:
- dataRozpocz cia:
- opisDo wiadczenia:
1..* 0..* - dataPlanowanegoZako czenia:
- dataZatrudnienia:
- dataZako czenia:
pracownik zlecenie
- specjalizacja:
- zleceniodawca:
- ryzykoWykonania:
+ dodajOsob ()
+ aktualizujDo wiadczenie()
+ dodajProjekt()
+ aktualizujDaneProjektu()
Harmonogram
- idHarmonogramu:
- dataPrzypisania:
- osobaOdpowiedzialna:
- opisHarmonogramu:
- czasObowi zywania:
+ przypisz()
5\VXQHN Zwi zek n-arny i klasa asocjacyjna
78 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Opisywany rysunek dotyczy harmonogramowania projektu. I tak klasa asocjacyjna Har-
monogram specyfikuje asocjacj ł cz c trzy inne klasy:
t Osob ,
t Projekt,
t Faz Projektu.
Klasy te s szczegółowo scharakteryzowane poprzez swoje atrybuty, operacje oraz wi-
doczno ci. Na diagramie wyspecyfikowano ponadto role oraz liczebno ci.
$VRFMDFMH ]ZURWQH L ZLHORNURWQH
Powi zane klasy mog pełnić wzgl dem siebie kilka odmiennych ról. Tym samym
klasy te mog być poł czone kilkoma asocjacjami. Asocjacje takie nazywa si aso-
cjacjami wielokrotnymi. Ka da z tych asocjacji winna być nazwana lub scharaktery-
zowana na podstawie ról, jak na rysunku 3.16.
5\VXQHN jest kupuj cym
Asocjacje wielokrotne
mi dzy klasami
Aukcja
Uczestnik
jest sprzedaj cym
Istnieje mo liwo ć przedstawiania asocjacji wi cej dan klas z sam sob . Asocja-
cja taka nazywana jest asocjacj zwrotn . Przykład asocjacji zwrotnej zamieszczono
na rysunku 3.17.
5\VXQHN 1
Pojazd
Asocjacja zwrotna
platforma
osobowy 1..10
transportuje
.ZDOLILNDFMD
Ostatni omawian cech asocjacji jest kwalifikacja. Umo liwia ona wyszukiwanie
obiektów zwi zanych z dan asocjacj . Kwalifikacji dokonuje si za pomoc kwalifi-
katora (ang. qualifier) atrybutu lub listy atrybutów, których warto ci porz dkuj
zbiór obiektów tej klasy wyst puj cych w danej asocjacji. Przykład kwalifikatora za-
mieszczono na rysunku 3.18.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 79
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN
1..* 0..*
Licytacja artykuł Sprzedaj cy
Asocjacja
kwalifikowana
8RJŃOQLHQLD NODV\ DEVWUDNF\MQH RUD] NRQNUHWQH
W hierarchiach klas powi zanych zwi zkami uogólnienia wyst puj klasy abstrak-
cyjne oraz konkretne. Klasy abstrakcyjne nie maj konkretnych instancji obiektów, lecz
stanowi uogólnienie obiektów konkretnych znajduj cych si na ni szych poziomach
hierarchii. Nazwy klas abstrakcyjnych podobnie jak innych abstrakcyjnych kategorii
poj ciowych pisane s kursyw . Klasom abstrakcyjnym mo na przypisywać atry-
buty i operacje podlegaj ce dziedziczeniu zgodnie z hierarchi klas.
Klasy na najni szym poziomie hierarchii nazywane s li ćmi (oznaczenie {leaf}), na-
tomiast na najwy szym klasami podstawowymi albo korzeniami (oznaczenie
{root}). Jawne wskazanie klas b d cych korzeniami i li ćmi zastosowano na ry-
sunku 3.19.
5\VXQHN
Osoba
Dziedziczenie klas
{root}
PracownikObsługiKina
PracownikInformacjiRezerwacji Kasjer KinoOperator
PracownikKasGastronomicznych PracownikKasBiIetowych
{leaf} {leaf}
Zwi zkom uogólnienia, wyst puj cym pomi dzy klasami obiektów znajduj cych si
w danej hierarchii klas, przypisać mo na cztery podstawowe ograniczenia. Obej-
muj one:
80 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
t {complete} zawiera pełen zestaw podklas dla danej klasy (rysunek 3.20);
Raport
{complete}
UI Control
UI Control
Dzienny Tygodniowy Miesi czny KwartaIny
Roczny
5\VXQHN Ograniczenie typu {complete}
t {incomplete} oznacza, e zestaw podklas przypisanych danej klasie nie
jest pełny (rysunek 3.21); wiadomo, e istnieje wi cej klas specjalizowanych
nie maj cych istotnego znaczenia w rozpatrywanym kontek cie;
Odbiornik
{incomplete}
UI Control
UI Control
TeIewizor Radio Modem Mikrofon
5\VXQHN Ograniczenie typu {incomplete}
t {disjoint} domy lny rodzaj uogólnienia, oznaczaj cy, e ka da podklasa
w hierarchii klas jest rozdzielna (rysunek 3.22), tzn. posiada tylko jedn klas
bezpo rednio nadrz dn ;
t {overlapping} oznacza, e w hierarchii klas okre lone klasy mog mieć
wspólne podklasy (rysunek 3.22); sytuacja taka okre lana jest mianem
dziedziczenia wielokrotnego.
Ograniczenia te odnosz si do zwi zków uogólnienia wyspecyfikowanych pomi dzy
klasami.
Ze zwi zkiem uogólnienia wi e si poj cie dyskryminatora (ang. generalization set),
który jest okre leniem kryterium dokonania klasyfikacji w uogólnieniu. Na ogół jest
to kryterium domy lne, lecz mo na je wyrazić wprost.
Dyskryminator stwarza mo liwo ć systematyzowania zwi zków uogólnie . Dyskrymi-
natory wskazuj ce kryterium formy płatno ci (Gotówka, Przelew, KartaPłatnicza) oraz
kryterium terminu płatno ci (Nale no ć, Wpływ) zawiera rysunek 3.23 przedstawiaj cy
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 81
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN
Zasilacz
Ograniczenia
typu {disjoint}
i {overlapping}
Stabilizowany Niestabilizowany
{overlapping}
AnaIogowy Impulsowy
{disjoint}
Przetwornica
5\VXQHN Diagram klas systemu płatno ci
diagram klas systemu płatno ci. Poj cie dyskryminatora mo na poł czyć ze stosow-
nymi ograniczeniami, wprowadzaj c np. klasyfikacje nie tylko typu {disjoint}, lecz tak-
e {overlapping}, {complete} oraz {incomplete}.
82 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Podsumowuj c zwi zki uogólnienia, nale y zaznaczyć, e istniej dwie konwencje gra-
ficznej prezentacji zwi zków uogólnienia (rysunek 3.24). S one znaczeniowo to same.
5\VXQHN
A
Konwencje graficznej
prezentacji uogólnie
B C D
A
D
B C
=DOH QR Ł
Mniejsze znaczenie w diagramach klas odgrywa zwi zek zale no ci, zdefiniowany
w poprzednim rozdziale. Zwi zek ten oznacza, e niezale na klasa obiektów wyko-
rzystuje klas zale n , jak przedstawiono na rysunku 3.25. Istnieje szereg rodzajów
zale no ci; ich opis mo na uszczegółowić poprzez podanie stereotypów dost pnych
w j zyku UML i znajduj cych zastosowanie w odniesieniu do diagramów klas. Klasa
niezale na jest tak e nazywana docelow , natomiast zale na ródłow .
5\VXQHN
Dostawa Artykuł
Zwi zek zale no ci
- rodekTransportu: - waga:
- termin: - rozmiar:
- : - :
... ...
5HDOL]DFMD
Klasy mog brać równie udział w zwi zkach realizacji. Jak zaznaczono w rozdziale
drugim, jedna strona tego zwi zku wskazuje klasyfikator okre laj cy kontrakt, natomiast
druga klasyfikator zapewniaj cy wywi zanie si z niego. W opisywanym kontek cie
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 83
&] Ł , 0 3RGVWDZ\ M]\ND 80/
realizacja wskazuje na zwi zek pomi dzy interfejsem a klas . Identyfikuje interfejsy
(ang. interfaces), które zapewniaj realizacj usługi klasy (rysunek 3.31).
,QWHUIHMV WR ]HVWDZ RSHUDFML NWŃUH Z\]QDF]DMń XVXJL RIHURZDQH SU]H] NODV OXE
NRPSRQHQW
Istnieje szereg konwencji przedstawiania interfejsów na diagramach klas (rysunek 3.26a,
rysunek 3.26b). Interfejsy szerzej omawia rozdział jedenasty.
a)
Ksi ka
- autor: String
- tytuł: String
Koszyk
- wydawca: String
- ISBN: Variant
- warto ć: Double
- dataWydania: Date
- cenaNetto: Single
+ dodajPozycj ()
- stawkaVAT: Byte
realize
+ usu Pozycj ()
+ przeka Pozycj ()
+ dodajPozycj ()
+ kalkulujCen Brutto()
+ usu Pozycj ()
+ opró nijKoszyk()
+ przeka Pozycj ()
+ kalkulujCen Brutto()
+ opró nijKoszyk()
+ wyszukaj()
b)
Ksi ka
- autor: String
Koszyk
- tytuł: String
- wydawca: String
- ISBN: Variant
- dataWydania: Date
- cenaNetto: Single
- stawkaVAT: Byte
+ dodajPozycj ()
+ usu Pozycj ()
+ przeka Pozycj ()
+ kalkulujCen Brutto()
+ opró nijKoszyk()
+ wyszukaj()
5\VXQHN Zwi zek realizacji i interfejs
Poszczególne usługi oferowane przez interfejs Koszyk w postaci operacji dodajPozycj ,
usu Pozycj itd. s realizowane poprzez klas Ksi ka.
84 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
'LDJUDP RELHNWŃZ
W celu ułatwienia zrozumienia diagramu klas o wysokim stopniu zło ono ci mo na
posłu yć si diagramami obiektów.
'LDJUDP RELHNWŃZ WR Z\VWńSLHQLH GLDJUDPX NODV RGZ]RURZXMńFH VWUXNWXU V\VWH
PX Z Z\EUDQ\P PRPHQFLH MHJR G]LDDQLD
Diagramy obiektów z reguły zawieraj wył cznie elementarne informacje. I tak rysu-
nek 3.27 przedstawia odwzorowanie obiektów systemu aukcji internetowej podczas
wstawiania artykułu na aukcj przez sprzedaj cego. Diagram klas tego systemu jest
tematem cz ci studialnej niniejszego rozdziału (rysunek 3.31).
JoIanta :
Piotr :Kupuj cy 1500 :Kwota 1420 :Kwota
Kupuj cy
PhiIips170S4 :
Licytacja
Konrad :
Sprzedaj cy
9234 :Artykuł
MonitoryLCD :
KataIog
PrzekazPocztowy :
Płatno ć
TransakcjaOnIine :
Płatno ć
5\VXQHN Przykład diagramu obiektów
Z kolei na rysunku 3.28 oraz 3.29 zamieszczono odpowiednio: diagram klas systemu
elektronicznej ksi garni oraz diagram obiektów opisuj cy struktur tego systemu w mo-
mencie dokonywania zakupu z u yciem karty kredytowej.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 85
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN Przykład klas systemu ksi garni elektronicznej
3URFHV WZRU]HQLD GLDJUDPX NODV
W procesie tworzenia diagramu klas wyró nić mo na nast puj ce etapy:
zidentyfikowanie i nazwanie klas;
opcjonalne okre lenie zobowi za klas;
86 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
5\VXQHN Diagram obiektów systemu ksi garni elektronicznej
poł czenie poszczególnych klas z wykorzystaniem zwi zków asocjacji;
zidentyfikowanie oraz nazwanie atrybutów i operacji;
wyspecyfikowanie asocjacji z u yciem wszystkich jej cech (nazwy, ról,
nawigacji, liczebno ci, agregacji, kwalifikacji);
opracowanie innych rodzajów zwi zków, tj. uogólnie , zale no ci i realizacji;
pełne, precyzyjne wyspecyfikowanie atrybutów i operacji zgodnie ze składni
opisan w niniejszym rozdziale;
opcjonalne opracowanie diagramów obiektów.
Nale y zaznaczyć, e zgodnie z istot iteracyjno-przyrostowego procesu TSI etapy te
s realizowane wielokrotnie, stosownie do przyrostu dokumentacji i zwi kszania jej
szczegółowo ci.
6WXGLXP GLDJUDPX NODV
Rysunek 3.30 podsumowuje omówione we wcze niejszych punktach podstawowe oraz
zaawansowane elementy diagramu klas.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 87
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN Diagram klas finansowego systemu transakcyjnego
Rol systemu finansowego pokazanego na zamieszczonym ni ej diagramie klas jest
obsługa elektronicznego obrotu pochodnymi instrumentami finansowymi. Przedmio-
tem transakcji s PochodneInstrumentyFinansowe (PIF). S to instrumenty, których
cena zale y od innych instrumentów finansowych (np. kursu wybranej waluty czy te
kursu akcji). Istot transakcji jest nabycie albo zbycie instrumentu finansowego za
okre lon cen w okre lonym dniu, a nast pnie zbycie albo odkupienie go w przy-
szło ci równie po wcze niej ustalonej cenie i w okre lonym dniu. Zysk albo strata
na transakcji jest wynikiem waha kursu w czasie b d ceny instrumentu, na którym
PochodnyInstrumentFinansowy bazuje.
88 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
W systemie obsługiwane s poszczególne rodzaje PIF: KontraktyTerminowe oraz tzw.
OpcjeFinansowe. Ze wzgl du na konieczno ć rozró niania kontraktów terminowych
typu forward oraz futures, w klasie KontraktTerminowy zaimplementowano atrybut typ,
przy czym warto ć domy ln tego atrybutu stanowi kontrakt typu futures. Cech szcze-
góln OpcjiFinansowych jest mo liwo ć niezrealizowania transakcji w przypadku nie-
korzystnego układu cen. Dodatkowym kosztem płaconym przez klienta za to ubez-
pieczenie jest tzw. premia opcyjna opłata manipulacyjna uiszczana dodatkowo
w momencie dokonania transakcji. Jej wysoko ć jest ró na (atrybut premiaOpcyjna
klasy OpcjaFinansowa). Transakcje obejmuj ce PIF s zazwyczaj standaryzowane (kla-
sa StandardLokalny), przy czym standardem mog być np. regulacje danej giełdy pro-
wadz cej obrót PIF. Atrybut tick opisuje minimaln zmian ceny instrumentu bazowego,
natomiast atrybut warto ćTicku finansow warto ć tej minimalnej zmiany. Wszyst-
kie osoby zarejestrowane w systemie reprezentowane s przez obiekty klasy Nabywca,
przy czym w systemie wyró nia si Nabywców b d cych osobami fizycznymi (Klient-
Indywidualny) oraz firmami (KlientKorporacyjny). Dowolny klient mo e posiadać
szereg zarejestrowanych Adresów korespondencyjnych (maksymalna liczba obsłu-
giwanych adresów wynosi 7). Klasa Transakcja reprezentuje operacj obrotu PIF.
Z ka d Transakcj zwi zane s przynajmniej dwie kopie Faktury (faktura dla klienta
oraz jej kopia, pozostaj ca w jednostce prowadz cej obrót PochodnymiInstrumentami-
Finansowymi) oraz Płatno ć. Płatno ci mo na dokonać jednorazowo b d w kilku
transzach. Fakt całkowitego opłacenia Faktury odnotowywany jest w systemie (ope-
racja odznaczPłatno ć klasy Faktura). Istnieje mo liwo ć fizycznego dokonania Płat-
no ci z wykorzystaniem KartyPłatniczej, Przelewu b d Gotówki w przypadku tzw.
wirtualnych PIF (niewymagaj cych fizycznego dostarczenia towaru oraz rodka płatni-
czego) stosuje si tzw. WyrównaniePozycji. W tej sytuacji transfery rodków pieni -
nych składaj cych si na transakcj w praktyce nie wyst puj , rozliczeniu podlega
wył cznie zysk albo strata na transakcji.
Z kolei diagram zaprezentowany na rysunku 3.31 przedstawia schemat bazy danych
systemu aukcji internetowej. Wyszczególnione klasy (np. klasa Artykuł) opisuj wszyst-
kie obiekty, które maj takie same atrybuty, operacje, zwi zki i znaczenie. Zilustrowany
diagram klas poza samymi klasami i zwi zkami pomi dzy nimi przedstawia
interfejsy, które reprezentuj usługi oferowane przez klas . Przykładami interfejsów,
których usługi s realizowane podczas przypadku u ycia Dokonaj rejestracji , s :
IRejestracjaSprzedaj cego oraz IPanelSteruj cy.
3RGVWDZRZH SRMFLD
Agregacja Atrybut
Agregat Chroniony
Całkowita Pakietowy
Cz ciowa Prywatny
Segment Publiczny
Asocjacja Statyczny
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 89
&] Ł , 0 3RGVWDZ\ M]\ND 80/
5\VXQHN Model konceptualny bazy danych systemu aukcji internetowej
90 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Diagram klas Operacja
Definicja Chroniona
Implementacyjny Pakietowa
Konceptualny Prywatna
Proces tworzenia Publiczna
Diagram obiektów Statyczna
Dyskryminator Rola
Dziedziczenie Widoczno ć
Interfejs Zobowi zanie
Karta CRC Zwi zek
Klasa Asocjacja
Abstrakcyjna Binarna
Asocjacyjna N-arna
Konkretna Wielokrotna
Kwalifikacja Zwrotna
Kwalifikator Realizacja
Liczebno ć Uogólnienie
Nawigacja Zale no ć
Obiekt
Ograniczenie
{complete}
{disjoint}
{incomplete}
{overlapping}
3\WDQLD L ]DGDQLD
Uzasadnij znaczenie diagramu klas.
Jakie kategorie poj ciowe decyduj o stanie obiektu, a jakie o jego zachowaniu?
Wyja nij relacje pomi dzy klas a obiektem.
Jakie elementy mo e zawierać symboliczny opis danej klasy? Wymie
najcz ciej stosowane kombinacje tego opisu. Podaj przykłady.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 91
&] Ł , 0 3RGVWDZ\ M]\ND 80/
Przedstaw atrybuty, operacje i inne elementy klasy obiektu Licytacja.
W jaki sposób oznacza si fakt pomini cia w opisie klasy mniej istotnych
atrybutów i (lub) operacji?
Wymie rodzaje asocjacji. Jaka jest podstawowa ró nica pomi dzy nimi?
Wymie cechy asocjacji. Oce ich praktyczne znaczenie.
W jaki sposób na diagramach klas oznacza si nawigacj dwukierunkow ,
a w jaki jednokierunkow ?
Jakie oznaczenia liczebno ci s twoim zdaniem absolutnie niezb dne do opisu
diagramu klas na poziomie konceptualnym? Jakie widzisz zagro enia stosowania
oznaczenia * na poziomie implementacyjnym?
Wska podstawow ró nic pomi dzy agregacj a kompozycj .
Powi zana ze ZintegrowanymSystememInformatycznym BazaDanych jest
niezb dnym elementem takiego systemu i nie mo e w adnym wypadku
poprawnie funkcjonować w oderwaniu od niego. Przedstaw to powi zanie
na diagramie klas.
Jak inaczej nazywana jest kompozycja?
Zidentyfikuj klasy systemu obsługi rezerwacji hotelowych. Poł cz je
zwi zkami, tworz c konceptualny diagram klas.
W jaki sposób uzasadniłby zasadno ć ró nicowanie diagramów klas
wzgl dem poziomów?
Wyja nij poj cie zobowi zania klasy. Jak nazywa si klas , której podstawow
zawarto ć stanowi zobowi zania oraz lista współpracuj cych klas?
Wymie i scharakteryzuj poziomy widoczno ci wyst puj ce w j zyku UML.
Porównaj je z poziomami widoczno ci wyst puj cymi w obiektowych j zykach
programowania, takich jak C++ oraz JAVA.
Wyja nij koncepcj statyczno ci.
Wyja nij konwencj nazywania klas odpowiednio na:
t konceptualnych diagramach klas,
t implementacyjnych diagramach klas.
Omów składni atrybutów oraz operacji w j zyku UML.
Wzbogać przykładowe klasy zamieszczone na rysunku 3.1 o typy danych,
domy lne warto ci atrybutów, listy parametrów operacji oraz oznaczenia
widoczno ci.
Wska podobie stwa i ró nice pomi dzy asocjacjami wielokrotnymi
i zwrotnymi. Podaj przykład zastosowania asocjacji zwrotnej w dziedzinie
przedmiotowej funkcjonowania ksi garni.
92 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
5R]G]LD 0 'LDJUDP NODV
Przedstaw asocjacj pomi dzy klasami Osoba oraz Projekt w postaci klasy
asocjacyjnej Harmonogram. Uzupełnij opis o atrybuty, operacje, liczebno ci
oraz nazwy ról.
Wyja nij relacje pomi dzy poj ciami:
t dziedziczenie,
t klasa konkretna,
t obiekt,
t dyskryminator,
t uogólnienie.
Jak graficznie odró nia si klas abstrakcyjn od klasy konkretnej? O jakie
informacje wzbogacaj model oznaczenia {root} i {leaf}?
Zilustruj zastosowanie kategorii poj ciowej dyskryminatora w odniesieniu
do dwóch kryteriów dokonania klasyfikacji w uogólnieniu klasy KontoBankowe.
Opisz konwencje graficznej prezentacji zwi zków uogólnienia.
Zaproponuj klasy, od których zale na byłaby klasa Rachunek opisuj ca
rachunek telefoniczny.
Wyja nij poj cie kwalifikatora.
Przekształć konceptualny diagram klas systemu obsługi rezerwacji hotelowych
w implementacyjny diagram klas, poprzez zastosowanie zwi kszaj cych
warto ć informacyjn tego diagramu zaawansowanych kategorii poj ciowych.
Zaproponuj interfejsy najistotniejszych klas systemu zaprezentowanego
na rysunku 3.30.
Jak rol spełniaj diagramy obiektów?
Podaj przykładowe obiekty klas systemu obsługi rezerwacji hotelowych.
Opracuj diagram obiektów odpowiadaj cy diagramowi klas zamieszczonemu
na rysunku 3.10.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc (05-11-10) 93
&] Ł , 0 3RGVWDZ\ M]\ND 80/
94 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\03.doc
Wyszukiwarka
Podobne podstrony:
TI 02 03 20 T B pl(1)
06 03 20 pra
1916 03 20 Rozkaz dzienny nr 50 Naczelnika Milicji Miejskiej w Środzie
TI 03 03 20 T pl(2)
2013 03 20 Informacje o Cookiesid(347
2013 03 20 Informacje o Cookiesid(347
07 EDC Revised 1 20 03
Ustawa z dnia 20 03 2009 o bezpieczeństwie imprez masowych
Zaćmienie Słońca 20 03 2015 rok
Cennik TelefonĂłw w Ofercie Biznes od 20 03 2012
Informatyka 20 03 2012
20 03 10 A
więcej podobnych podstron