Bartosz Walter
UML cz. I
1
In
Ŝ
ynieria oprogramowania
UML cz. I
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
UML cz. I
1
In
Ŝ
ynieria oprogramowania
UML cz. I
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
UML cz. I
2
In
Ŝ
ynieria oprogramowania
UML cz. I (2)
Plan wykładów
Zasady skutecznego działania
Specyfikacja wymagań (przypadki uŜycia)
Przeglądy artefaktów (inspekcje Fagana)
Język UML, cz. I
Język UML, cz. II
Metody formalne (sieci Petriego)
Wzorce projektowe
Zarządzanie konfiguracją (CVS)
Wprowadzenie do testowania
Automatyzacja wykonywania testów (jUnit)
Programowanie Ekstremalne
Ewolucja oprogramowania i refaktoryzacja
Wykład jest pierwszym z dwóch, po
ś
wi
ę
conych j
ę
zykowi modelowania
UML.
Bartosz Walter
UML cz. I
3
In
Ŝ
ynieria oprogramowania
UML cz. I (3)
Agenda
1.Historia i geneza UMLa
2.Koncepcja modeli UML
3.Modelowanie funkcjonalności
4.Diagram klas
5.Diagram obiektów
6.Przykład
Podczas tego wykładu zostanie przedstawione wprowadzenie do j
ę
zyka
UML, jego geneza oraz struktura. Omówione b
ę
d
ą
tak
Ŝ
e dwie
perspektywy UML: przypadków u
Ŝ
ycia oraz logiczna.
Bartosz Walter
UML cz. I
4
In
Ŝ
ynieria oprogramowania
UML cz. I (4)
Historia UML
ok.1990
1995 1996
wł
ą
czenie si
ę
do
prac OMG
UML 1.0
(Rational
Software)
i
UML 1.1
(OMG)
UML 1.5
1997
2000
2004
UML 2.0
UML 1.3
niezale
Ŝ
ne notacje
modelowania:
Booch, Coad/Yourdon,
OMT, OOSE, Fusion
OOPSLA 1995: wersja
0.8
Metody Zunifikowanej
(Booch & Rumbaugh,
Rational Software),
doł
ą
cza Jacobson
2003
2006
UML 2.1
(plan)
W latach 80-tych i na pocz
ą
tku lat 90-tych istniało na rynku wiele notacji i
metodyk modelowania, stosuj
ą
cych elementy o zbli
Ŝ
onej semantyce (np.
klasy), ale całkowicie ró
Ŝ
ni
ą
ce si
ę
sposobem ich reprezentacji. Cz
ęść
z
nich, z uwagi na wcze
ś
niejsze do
ś
wiadczenia ich autorów, zdobyły
wi
ę
ksz
ą
popularno
ść
(np. OOAD, OOSE, OMT, Fusion, metoda Shlaera-
Mellora czy Coada-Yourdona), jednak nadal brak było jednego standardu,
który zaspokajałby wszystkie potrzeby. W wi
ę
kszo
ś
ci były to notacje
niekompletne, obejmuj
ą
ce cz
ęść
problematyki modelowania, i nie
definiuj
ą
ce szczegółowo wielu poj
ęć
.
Dlatego, na pocz
ą
tku lat 90-tych G. Booch (twórca metody OOAD,
kład
ą
cej nacisk na kwestie projektowania i implementacji) i J. Rumaugh
(autor metody OMT, skupiaj
ą
cej si
ę
na modelowaniu dziedziny
przedmiotowej), pracuj
ą
cy dla Rational Software (dzisiaj Rational jest
własno
ś
ci
ą
IBMa) dostrzegli mo
Ŝ
liwo
ść
wzajemnego uzupełnienia swoich
metod i rozpocz
ę
li prace nad Metod
ą
Zunifikowan
ą
, która miała obj
ąć
elementy dotychczas oddzielnych metodyk. Na konferencji OOPSLA w
1995 roku zaprezentowali oni wersj
ę
0.8 Metody Zunifikowanej, a krótko
potem doł
ą
czył do nich inny metodolog - I. Jacobson (twórca metody
OOSE, posiadaj
ą
cej elementy zwi
ą
zane z modelowanie funkcjonalno
ś
ci,
u
Ŝ
ytkowników i cyklu
Ŝ
ycia produktu). W ten sposób powstała "masa
krytyczna", która dawała szans
ę
na opanowanie rynku przez
nowopowstał
ą
metod
ę
. W roku 1996 do prac wł
ą
czyła si
ę
niezale
Ŝ
na
organizacja OMG, której udział dawał szans
ę
na wpływ na UML tak
Ŝ
e
innym firmom, nie tylko Rational Software.
Bartosz Walter
UML cz. I
5
In
Ŝ
ynieria oprogramowania
UML cz. I (5)
Historia UML
ok.1990
1995 1996
wł
ą
czenie si
ę
do
prac OMG
UML 1.0
(Rational
Software)
i
UML 1.1
(OMG)
UML 1.5
1997
2000
2004
UML 2.0
UML 1.3
niezale
Ŝ
ne notacje
modelowania:
Booch, Coad/Yourdon,
OMT, OOSE, Fusion
OOPSLA 1995: wersja
0.8
Metody Zunifikowanej
(Booch & Rumbaugh,
Rational Software),
doł
ą
cza Jacobson
2003
2006
UML 2.1
(plan)
Efektem prac była najpierw wersja 1.0 UML opublikowana przez Rational,
a kilka miesi
ę
cy pó
ź
niej – wersja 1.1, wydana ju
Ŝ
pod egid
ą
OMT. Kolejne
wersje pojawiały si
ę
w odst
ę
pach kilkuletnich, pozwalaj
ą
c na stosowanie
nowych diagramów, uspójniaj
ą
c notacj
ę
i umo
Ŝ
liwiaj
ą
c na modelowanie
nowych dziedzin. Najnowsza wersja UML to 2.0.
Wraz z rozwojem UML zdobył dominuj
ą
c
ą
pozycj
ę
na rynku – poza nim
pozostaj
ą
jedynie notacje zwi
ą
zane z narz
ę
dziami 4GL.
Bartosz Walter
UML cz. I
6
In
Ŝ
ynieria oprogramowania
UML cz. I (6)
Trzej amigos
G. Booch
I. Jacobson
J. Rumbaugh
metoda Boocha
przypadki u
Ŝ
ycia
OMT
Trzej autorzy UMLa: Booch, Jacobson i Rumbaugh zunifikowali swoje
notacje, tworz
ą
c jedn
ą
metod
ę
. Z poszczególnych notacji przej
ę
to
najlepsze rozwi
ą
zania.
Bartosz Walter
UML cz. I
7
In
Ŝ
ynieria oprogramowania
UML cz. I (7)
Czym jest UML?
UML jest
UML nie jest
metodyk
ą
– UML nie okre
ś
la metody
modelowania
– zaleca jedynie stosowanie
podej
ś
cia przyrostowego
narz
ę
dziem
– UML to specyfikacja dla
narz
ę
dzi
notacj
ą
graficzn
ą
– UML okre
ś
la sposób
zapisu modeli
j
ę
zykiem programowania
– generowanie kodu z
modelu stosowane obecnie
na niewielk
ą
skal
ę
Bartosz Walter
UML cz. I
8
In
Ŝ
ynieria oprogramowania
UML cz. I (8)
Konstrukcja UML
notacja
• elementy graficzne
• składnia j
ę
zyka
modelowania
• istotna przy
szkicowaniu modeli
metamodel
• definicje poj
ęć
j
ę
zyka
i powi
ą
zania pomi
ę
dzy
nimi
• istotny przy graficznym
programowaniu
Z punktu widzenia modelowania wa
Ŝ
niejsza jest notacja.
Z punktu widzenia generacji kodu – metamodel.
UML składa si
ę
z dwóch podstawowych elementów:
UML definiuje dwie podstawowe składowe: notacj
ę
poszczególnych
elementów u
Ŝ
ywanych na diagramach, a z drugiej strony – ich semantyk
ę
,
czyli tzw. metamodel. Z punktu widzenia analityka istotniejsze jest
czytelne i jednoznaczne opisanie modelu tak, aby inne osoby mogły
zrozumie
ć
jego znaczenie. Zatem wa
Ŝ
niejsza dla niego jest notacja, za
ś
metamodel powinien by
ć
zrozumiały intuicyjnie. Z kolei przy generowaniu
kodu i przej
ś
ciu do implementacji wa
Ŝ
niejsze jest
ś
cisłe rozumienie
znaczenia poszczególnych elementów, tak, aby mo
Ŝ
liwa była
automatyczna konwersja modelu do innego formalizmu.
Bartosz Walter
UML cz. I
9
In
Ŝ
ynieria oprogramowania
UML cz. I (9)
Perspektywy 4+1
Implementacyjna
Przypadków u
Ŝ
ycia
Logiczna
Procesowa
Wdro
Ŝ
enia
Model
Modelowanie zło
Ŝ
onych systemów jest zadaniem trudnym i anga
Ŝ
uje
wiele osób o ró
Ŝ
nym sposobie postrzegania systemu. Aby uwzgl
ę
dni
ć
te
punktu widzenia, UML jest cz
ę
sto okre
ś
lany jako j
ę
zyk modelowania z
4+1 perspektyw
ą
. Cztery pierwsze opisuj
ą
wewn
ę
trzn
ą
struktur
ę
programu na ró
Ŝ
nych poziomach abstrakcji i szczegółowo
ś
ci. Ostatnia
perspektywa opisuje funkcjonalno
ść
systemu widzian
ą
przez jego
u
Ŝ
ytkowników. Ka
Ŝ
da perspektywa korzysta z własnego zestawu
diagramów pozwalaj
ą
cych czytelnie przedstawi
ć
modelowane
zagadnienie. S
ą
to:
•Perspektywa przypadków u
Ŝ
ycia – opisuje funkcjonalno
ść
, jak
ą
powinien
dostarcza
ć
system, widzian
ą
przez jego u
Ŝ
ytkowników.
•Perspektywa logiczna – zawiera sposób realizacji funkcjonalno
ś
ci,
struktur
ę
systemu widzian
ą
przez projektanta
•Perspektywa implementacyjna – opisuje poszczególne moduły i ich
interfejsy wraz z zale
Ŝ
no
ś
ciami; perspektywa ta jest przeznaczona dla
programisty
•Perspektywa procesowa – zawiera podział systemu na procesy
(czynno
ś
ci) i procesory (jednostki wykonawcze); opisuje wła
ś
ciwo
ś
ci
pozafunkcjonalne systemu i słu
Ŝ
y przede tak
Ŝ
e programistom i
integratorom
•Perspektywa wdro
Ŝ
enia – definiuje fizyczny podział elementów systemu i
ich rozmieszczenie w infrastrukturze; perspektywa taka słu
Ŝ
y integratorom
i instalatorom systemu
Bartosz Walter
UML cz. I
10
In
Ŝ
ynieria oprogramowania
UML cz. I (10)
Diagramy UML
UML obejmuje 13 rodzajów diagramów:
• diagram pakietów
• diagram klas i diagram obiektów
• diagram struktur zło
Ŝ
onych
• diagram komponentów
• diagram wdro
Ŝ
enia
• diagram przypadków u
Ŝ
ycia
• diagram czynno
ś
ci
• diagram maszyny stanowej
• diagramy interakcji (sekwencji,
komunikacji, przegl
ą
du interakcji)
• diagram uwarunkowa
ń
czasowych
modelowanie
strukturalne
modelowanie
behawioralne
W UML zdefiniowano 13 rodzajów diagramów podzielonych na dwie
główne grupy: opisuj
ą
cych struktur
ę
systemu i opisuj
ą
cych zachowanie.
Nie wszystkie s
ą
i musz
ą
by
ć
u
Ŝ
ywane jednocze
ś
nie – zale
Ŝ
y to od
rodzaju i zło
Ŝ
ono
ś
ci modelowanego systemu. Cz
ęść
z nich słu
Ŝ
y do
modelowania tego samego aspektu, jednak uj
ę
tego nieco inaczej, dlatego
dobór rodzajów diagramów zale
Ŝ
y tak
Ŝ
e od preferencji analityka.
Bartosz Walter
UML cz. I
11
In
Ŝ
ynieria oprogramowania
UML cz. I (11)
Diagram przypadków u
Ŝ
ycia
Diagram przypadków u
Ŝ
ycia
• definiuje
granice
modelowanego systemu
• okre
ś
la jego
kontekst
• wymienia
u
Ŝ
ytkowników
systemu i jednostki
zewn
ę
trzne
• przedstawia
funkcje
dost
ę
pne dla
u
Ŝ
ytkowników
• okre
ś
la
powi
ą
zania
i zale
Ŝ
no
ś
ci
pomi
ę
dzy nimi
Rejestracja czytelnika
Bibliotekarz
Przedłu
Ŝ
enie
Zw rot
Wypo
Ŝ
yczenie do czytelni
Wypo
Ŝ
yczenie
Rezerw acja
Wyszukanie
<<include>>
<<include>>
<<inc lude>>
Czytelnik
Diagram przypadków u
Ŝ
ycia (ang. use-case diagram) słu
Ŝ
y do
modelowania aktorów (u
Ŝ
ytkowników systemu, odbiorców efektów pracy
systemu, systemów zewn
ę
trznych) i ich potrzeb w stosunku do
tworzonego systemu. Przypadki u
Ŝ
ycia prezentowane na tym diagramie to
sekwencje czynno
ś
ci, które prowadz
ą
do spełnienia celu przypadku
u
Ŝ
ycia (zaspokojenia pewnej potrzeby u
Ŝ
ytkownika).
Bartosz Walter
UML cz. I
12
In
Ŝ
ynieria oprogramowania
UML cz. I (12)
Aktor
Aktor
• inicjuje wykonanie funkcji systemu
• wymaga dost
ę
pu do systemu
• reprezentuje punkt widzenia na system
• jest osob
ą
fizyczn
ą
, rol
ą
w systemie lub systemem
zewn
ę
trznym
Bibliotekarz
Czytelnik
Zegar
Aktor jest osob
ą
(lub dowoln
ą
inn
ą
jednostk
ą
), która w jaki
ś
sposób
wymienia informacje z systemem, cho
ć
pozostaje poza jego zakresem.
Jest wi
ę
c w szerokim znaczeniu u
Ŝ
ytkownikiem tego systemu, tzn.
Ŝą
da
od systemu wykonania pewnych funkcji i/lub odbiera efekty ich
wykonania. Aktor opisuje rol
ę
, a nie konkretn
ą
osob
ę
lub jednostk
ę
.
Aktorzy mog
ą
by
ć
powi
ą
zani ze sob
ą
relacj
ą
uogólnienia/uszczegółowienia: w ten sposób zachowanie bardziej
ogólnego aktora jest dziedziczone przez aktora bardziej szczegółowego.
Ponadto s
ą
powi
ą
zani z przypadkami u
Ŝ
ycia, z których korzystaj
ą
.
Aktor jest reprezentowany na diagramie przypadków u
Ŝ
ycia w ró
Ŝ
noraki
sposób: jako sylwetka z nazw
ą
aktora, jako prostok
ą
t ze słowem
kluczowym «actor» lub z ikon
ą
.
Przykładami aktorów w systemie bibliotecznym mog
ą
by
ć
Bibliotekarz i
Czytelnik, reprezentuj
ą
cy fizyczne osoby korzystaj
ą
ce z tego systemu, ale
tak
Ŝ
e Zegar, który cyklicznie wysyła komunikat powoduj
ą
cy wyszukanie
ksi
ąŜ
ek o przekroczonym terminie zwrotu.
Bartosz Walter
UML cz. I
13
In
Ŝ
ynieria oprogramowania
UML cz. I (13)
Przypadek u
Ŝ
ycia
Przypadek u
Ŝ
ycia reprezentuje
kompletn
ą
funkcj
ę
dost
ę
pn
ą
dla
aktora.
Przypadki u
Ŝ
ycia mog
ą
by
ć
powi
ą
zane zale
Ŝ
no
ś
ciami:
• Uszczegółowienie
:
specjalizowana wersja
przypadku u
Ŝ
ycia
• Rozszerzanie
: dodatkowa
funkcjonalno
ść
przypadku
u
Ŝ
ycia
• Zawieranie
: wykonanie
jednego przypadku u
Ŝ
ycia
przez drugi
uszczegółowienie
Powiadomienie
Czytelnik
Wyszukanie
Rezerwacja czasopisma
Rezerwacja
<<extend>>
<<include>>
Rezerwacja ksi
ąŜ
ki
zawieranie
rozszerzanie
Przypadek u
Ŝ
ycia reprezentuje zamkni
ę
t
ą
i kompletn
ą
funkcjonalno
ść
dost
ę
pn
ą
dla aktora. Zgodnie z definicj
ą
, przypadek u
Ŝ
ycia w UML jest
zdefiniowany jako zbiór akcji wykonywanych przez system, które
powoduj
ą
efekt zauwa
Ŝ
alny dla aktora.
Przypadki u
Ŝ
ycia zawsze musz
ą
by
ć
inicjowane (bezpo
ś
rednio lub przez
zale
Ŝ
no
ś
ci) przez aktora i wykonywane w jego imieniu. Ponadto,
przypadek u
Ŝ
ycia musi dostarcza
ć
pewn
ą
warto
ść
u
Ŝ
ytkownikowi oraz
musi by
ć
kompletny, to znaczy w pełni realizowa
ć
podan
ą
funkcjonalno
ść
oraz dostarcza
ć
wyniki aktorowi.
Przypadki u
Ŝ
ycia komunikuj
ą
si
ę
z aktorami poprzez powi
ą
zania,
pokazuj
ą
ce, który aktor ma dost
ę
p do podanego przypadku u
Ŝ
ycia.
Ponadto mog
ą
by
ć
powi
ą
zane pomi
ę
dzy sob
ą
: relacj
ą
uogólnienia,
rozszerzenia i zawierania.
Bartosz Walter
UML cz. I
14
In
Ŝ
ynieria oprogramowania
UML cz. I (14)
Przykład
Przedłu
Ŝ
enie
Zwrot
Wypo
Ŝ
yczenie do czytelni
Wypo
Ŝ
yczenie
Rezerwacja czasopisma Rezerwacja ksi
ąŜ
ki
Rezerwacja
Bibliotekarz
Rejestracja czytelnika
Czytelnik
Wyszukanie
<<include>>
<<include>>
<<include>>
Zegar
Powiadomienie
<<extend>>
Przykład przedstawia diagram przypadków u
Ŝ
ycia. Wyst
ę
puje w nim
trzech aktorów: Czytelnik, Bibliotekarz i Zegar. Pierwsi dwaj reprezentuj
ą
role u
Ŝ
ytkowników systemu, natomiast Zegar słu
Ŝ
y do generowania
cyklicznych Powiadomie
ń
.
Czytelnik i Bibliotekarz korzystaj
ą
z przypadków u
Ŝ
ycia. Niektóre z nich,
np. Zwrot lub Wypo
Ŝ
yczenie do czytelni, s
ą
przez nich współdzielone,
natomiast Rejestracja czytelnika i Przedłu
Ŝ
enie s
ą
dost
ę
pne tylko dla
jednego albo drugiego aktora.
Przypadek u
Ŝ
ycia Wyszukanie jest wł
ą
czany do kilku innych przypadków
u
Ŝ
ycia: Rezerwacj
ę
, Wypo
Ŝ
yczenie i Wypo
Ŝ
yczenie do czytelni. W ten
sposób jest on wywoływany w sposób po
ś
redni przez aktora, a
bezpo
ś
rednio przez inny przypadek u
Ŝ
ycia.
Przypadek u
Ŝ
ycia Rezerwacja jest rozszerzany przez Powiadomienie.
Oznacza to,
Ŝ
e Powiadomienie mo
Ŝ
e uczestniczy
ć
w realizacji funkcji
Rezerwacji. Ponadto Rezerwacja posiada dwa szczegółowe przypadki:
Rezerwacj
ę
ksi
ąŜ
ki i Rezerwacj
ę
czasopisma.
Bartosz Walter
UML cz. I
15
In
Ŝ
ynieria oprogramowania
UML cz. I (15)
Diagram klas
Diagram klas
przedstawia klasy wyst
ę
puj
ą
ce w systemie
i statyczne relacje pomi
ę
dzy nimi wraz z ograniczeniami.
Jest podstawowym diagramem struktury logicznej systemu.
Katalog alfabetyczny
Sortowanie()
Znajd
ź
()
Katalog autorow
Sortowanie()
Znajd
ź
()
Katalog rzeczowy
Sortowanie()
Znajd
ź
()
Ksi
ąŜ
ka
Autor : String
Tytuł : String
ISBN : String
Czasopismo
Katalog
wydawnictwa : List
...
...
Hi storia
data
operacja
status
do kiedy
Numer w katalogu
Czy tel nik
Pesel : String
Nazwisko : String
Adres : String
Identyfikator : Integer
Imi
ę
: String
Data zapisu : Date
SZABLON IDENTYFIKATORA : String
Rezerwuj()
Wypo
Ŝ
ycz()
(from Use Ca se View)
<<Actor>>
1.. n
1
1.. n
1
Karta wydawni ctwa
Numer w katalogu : String
Autor : String
Tytuł : String
ISBN : String
Data rejestracji : Date
Data usuni
ę
cia : Date
**
0..n
1
0..n
1
Rezerwacja
id_karty
Nr w katalogu
od kiedy
do kiedy
0..n
1
0..n
1
Egzemplarz
Numer w katalogu : String
Identyfikator : String
Wydanie : String
Stron : Integer
1
1
1
1
0..n
1
0..n
1
Diagram klas (ang. class diagram) jest najcz
ęś
ciej u
Ŝ
ywanym diagramem
UML. Z reguły zawiera tak
Ŝ
e najwi
ę
ksz
ą
ilo
ść
informacji i stosuje
najwi
ę
ksz
ą
liczb
ę
symboli.
Na diagramie s
ą
prezentowane klasy, ich atrybuty i operacje, oraz
powi
ą
zania mi
ę
dzy klasami. Diagram klas przedstawia wi
ę
c podział
odpowiedzialno
ś
ci pomi
ę
dzy klasy systemu i rodzaj wymienianych
pomi
ę
dzy nimi komunikatów. Z uwagi na rodzaj i ilo
ść
zawartych na tym
diagramie danych jest on najcz
ęś
ciej stosowany do generowania kodu na
podstawie modelu.
Bartosz Walter
UML cz. I
16
In
Ŝ
ynieria oprogramowania
UML cz. I (16)
Klasa i obiekt
Czyt elnik
Pesel : String
Nazwisk o : String
Adres : String
Identyfikator : Integer
Imi
ę
: String
Data zapisu : Date
SZABLON IDENTYFIKATORA : String
Rezerwuj(wyd : Wydawnictwo)
Wypo
Ŝ
ycz(egz : Egzemplarz)
(from Use Case View)
n
a
z
w
a
o
p
e
ra
c
je
a
tr
y
b
u
ty
Klasa jest reprezentowana przez prostok
ą
t z wydzielonymi przedziałami:
nazw
ą
, atrybutami i operacjami. W celu zwi
ę
kszenia czytelno
ś
ci, dowolny
z nich mo
Ŝ
na ukry
ć
b
ą
d
ź
doda
ć
nowy (np. przechowuj
ą
cy zdarzenia lub
wyj
ą
tki), cho
ć
zwykle s
ą
to wła
ś
nie trzy przedziały. Tradycyjnie nazwa
klasy zaczyna si
ę
z du
Ŝ
ej litery, jest wytłuszczona, a w przypadku klasy
abstrakcyjnej – tak
Ŝ
e pochyła.
Obiekt jest instancj
ą
klasy, podobnie jak w przypadku programowania
obiektowego. Nazwa obiektu jest umieszczana przed nazw
ą
klasy i
oddzielana od niej dwukropkiem.
Cechy klasy reprezentuj
ą
informacj
ę
, jak
ą
klasa przechowuje. Mog
ą
zosta
ć
zapisane w postaci dwóch, w zasadzie równowa
Ŝ
nych notacji: jako
atrybuty klasy (umieszczane w przedziale atrybutów) lub jako relacje
pomi
ę
dzy klasami (zapisywane w postaci linii ł
ą
cz
ą
cej klasy). Zwykle
pierwsza notacja jest stosowana do typów prostych lub obiektów
reprezentuj
ą
cych warto
ś
ci, natomiast druga do typów zło
Ŝ
onych.
Operacje reprezentuj
ą
usługi, jakie klasa oferuje. Ich realizacje – metody
– dostarczaj
ą
implementacji tych usług.
Bartosz Walter
UML cz. I
17
In
Ŝ
ynieria oprogramowania
UML cz. I (17)
Atrybuty klasy
Cechy klasy s
ą
zapisywane w postaci
atrybutów klasy
lub
asocjacji
z innymi klasami. Atrybuty reprezentuj
ą
warto
ś
ci
proste lub niewielkie obiekty, asocjacje – obiekty zło
Ŝ
one
widoczność
nazwa
:
typ
[krotność] {ograniczenia} = wartość dom.
Sk
ą
d atrybut jest
widoczny?
Ile obiektów trzeba i ile
mo
Ŝ
na umie
ś
ci
ć
w
atrybucie?
Jakie dodatkowe warunki
spełniaj
ą
warto
ś
ci atrybutu?
Jaka jest warto
ść
atrybutu, gdy nie
podano jej wprost?
Zwykle atrybut jest opisywany tylko przez dwa elementy: nazw
ę
i typ.
Jednak pełna definicja obejmuje tak
Ŝ
e widoczno
ść
atrybutu, definiuj
ą
c
ą
,
z jakich miejsc systemu atrybut jest dost
ę
pny, krotno
ść
, która okre
ś
la ile
obiektów mie
ś
ci si
ę
w atrybucie, dodatkowe ograniczenia nało
Ŝ
one na
atrybut, i warto
ść
domy
ś
ln
ą
. Elementom, których w definicji atrybutu nie
podano warto
ś
ci, przypisywane s
ą
warto
ś
ci domy
ś
lne (widoczno
ść
prywatna, krotno
ść
1) lub pomija si
ę
je.
Bartosz Walter
UML cz. I
18
In
Ŝ
ynieria oprogramowania
UML cz. I (18)
Poziomy widoczno
ś
ci
UML definiuje
4 poziomy widoczno
ś
ci
cech i metod
• + publiczny
– element jest widoczny z ka
Ŝ
dego miejsca
w systemie
• # chroniony
– element jest widoczny we własnej klasie i
jej podklasach
• – prywatny
– element jest widoczny tylko we własnej
klasie
• ~ publiczny wewn
ą
trz pakietu
– element jest widoczny
tylko wewn
ą
trz własnego pakietu
Podobnie jak w wielu wysokopoziomowych j
ę
zykach programowania,
UML posiada 4 poziomy widoczno
ś
ci: publiczny, chroniony, prywatny i
publiczny wewn
ą
trz pakietu. Poziomy te zwykle słu
Ŝą
do opisywania
widoczno
ś
ci cech (atrybutów i asocjacji) oraz operacji, jednak dotycz
ą
tak
Ŝ
e np. klas pakietów etc.
Bartosz Walter
UML cz. I
19
In
Ŝ
ynieria oprogramowania
UML cz. I (19)
Krotno
ść
Krotno
ść
pozwala okre
ś
li
ć
minimaln
ą
i maksymaln
ą
liczb
ę
obiektów, jakie mo
Ŝ
na powi
ą
za
ć
z dan
ą
cech
ą
:
• dolna granica..górna granica
– przedział od-do
• 1
– dokładnie jeden obiekt
• 0..1
– opcjonalnie jeden obiekt
• 1..*
- przynajmniej jeden obiekt
• 1, 3, 5
– konkretne liczby obiektów
• *
- dowolna liczba obiektów
Krotno
ść
cechy wskazuje, ile obiektów mo
Ŝ
na, a ile trzeba w niej zawrze
ć
.
Krotno
ść
mo
Ŝ
na okre
ś
la
ć
jako ograniczenie dolne i górne, jednak
oczywiste lub powtarzaj
ą
ce si
ę
warto
ś
ci graniczne mo
Ŝ
na pomija
ć
, np..
zapis 0..* jest skracany do *, a zapis 1..1 do 1.
W praktyce programowania istotna jest krotno
ść
0, 1 i dowolna, natomiast
warto
ś
ci dyskretne s
ą
mniej wa
Ŝ
ne, jako szczególne przypadki
wymienionych trzech. W UMLu 2.0 dlatego formalnie usuni
ę
to mo
Ŝ
liwo
ść
podawania dowolnych liczb b
ę
d
ą
cych ograniczeniami, np. 2..4, jednak z
uwagi na czytelno
ść
tego zapisu u
Ŝ
ycie go nie stanowi wielkiego bł
ę
du.
Bartosz Walter
UML cz. I
20
In
Ŝ
ynieria oprogramowania
UML cz. I (20)
Wła
ś
ciwo
ś
ci i ograniczenia atrybutów
Z atrybutem mog
ą
by
ć
zwi
ą
zane dodatkowe
ograniczenia, które okre
ś
laj
ą
jego wła
ś
ciwo
ś
ci, np.:
• {ordered}
– obiekty wewn
ą
trz cechy s
ą
uporz
ą
dkowane
• {unordered}
– obiekty s
ą
nieuporz
ą
dkowane
• {unique}
– obiekty wewn
ą
trz cechy nie powtarzaj
ą
si
ę
• {nonunique}
– obiekty wewn
ą
trz cechy mog
ą
si
ę
powtarza
ć
• {readOnly}
– warto
ść
atrybutu słu
Ŝ
y tylko do odczytu
• {frozen}
– warto
ść
atrybutu nie mo
Ŝ
e by
ć
zmodyfikowana po jej przypisaniu
Niemal ka
Ŝ
dy element w UML mo
Ŝ
e posiada
ć
dodatkowe wła
ś
ciwo
ś
ci i
ograniczenia, które szczegółowo opisuj
ą
jego zachowanie i
przeznaczenie. S
ą
one zapisywane w nawiasach klamrowych. Atrybuty
klasy mo
Ŝ
na oznaczy
ć
jako uporz
ą
dkowane za pomoc
ą
ograniczenia
{sorted}, co oznacza,
Ŝ
e s
ą
one w jaki
ś
sposób (zwykle rosn
ą
co,
leksykograficznie) posortowane. Ograniczenie {unique} wymaga, aby
obiekty pami
ę
tane wewn
ą
trz atrybutu nie powtarzały si
ę
. Wła
ś
ciwo
ść
{readOnly} oznacza atrybut, którego warto
ść
jest przeznaczona wył
ą
cznie
do odczytu, natomiast {frozen} – którego warto
ść
po zdefiniowaniu nie
mo
Ŝ
e by
ć
zmieniona.
Bartosz Walter
UML cz. I
21
In
Ŝ
ynieria oprogramowania
UML cz. I (21)
Wypo
Ŝ
yczenie
Data pocz
ą
tku : Date
Data ko
ń
ca : Date
/ Przekroczone : Boolean
MAX_WYPO
ś
YCZENIE : int
zako
ń
cz()
Atrybuty pochodne
Atrybut pochodny
(wywiedziony) mo
Ŝ
e zosta
ć
obliczony na
podstawie innych atrybutów. Atrybutów pochodnych nie
trzeba implementowa
ć
.
przekroczone = (Data ko
ń
ca.Dni() – Data pocz
ą
tku.Dni()) >
MAX_WYPO
ś
YCZENIE
Atrybuty pochodne (ang. derived) s
ą
zale
Ŝ
ne od innych atrybutów i ich
warto
ś
ci mo
Ŝ
na obliczy
ć
na podstawie tych atrybutów. Cz
ę
sto w fazie
implementacji s
ą
przekształcane w metody lub ich warto
ść
jest obliczana
na bie
Ŝą
co. Nie ma zatem potrzeby ich zapami
ę
tywania w klasie.
Atrybuty pochodne s
ą
oznaczane znakiem '/' umieszczonym przed nazw
ą
atrybutu.
Bartosz Walter
UML cz. I
22
In
Ŝ
ynieria oprogramowania
UML cz. I (22)
Składowe statyczne
Składowe (atrybuty i operacje) statyczne
s
ą
widoczne
tak
Ŝ
e wewn
ą
trz klasy, nie tylko wewn
ą
trz obiektów.
Wypo
Ŝ
yczenie
Data pocz
ą
tku : Date
Data ko
ń
ca : Date
/ Przekroczone : Boolean
MAX_WYPO
ś
YCZENIE : int
zako
ń
cz()
Wypo
Ŝ
yczenie
MAX_WYP O
ś
YCZENIE : int
«instantiates»
W klasie widoczny tylko atrybut statyczny
W obiekcie widoczne wszystkie atrybuty
Klasa
Obiekt
Składowe statyczne w klasie s
ą
widoczne zarówno w klasie, jak i w jej
instancji. Składowe niestatyczne s
ą
widoczne jedynie w obiektach danej
klasy, zatem wymagaj
ą
utworzenia jej instancji.
Składowe statyczne klasy s
ą
oznaczane podkre
ś
leniem jej sygnatury.
Bartosz Walter
UML cz. I
23
In
Ŝ
ynieria oprogramowania
UML cz. I (23)
Operacje
widoczność
nazwa(parametr1, parametr2,...)
:
typ
{ograniczenia}
kierunek
nazwa typ
[krotno
ść
] = warto
ść
dom.
kierunki parametrów:
• in
: wej
ś
ciowy
•
out
: wyj
ś
ciowy
•
inout
: wej
ś
ciowo-wyj
ś
ciowy
•
return
: zwracany z metody
Operacja
to proces, który klasa potrafi wykona
ć
.
Operacje s
ą
opisywane w UMLu podobnie jak atrybuty, oczywi
ś
cie, z
uwzgl
ę
dnieniem listy parametrów i pomini
ę
ciem warto
ś
ci domy
ś
lnej.
Parametry s
ą
zapisywane identycznie jak atrybuty klasy, jednak s
ą
poprzedzone informacj
ą
o kierunku jego przekazania: in, out, inout i
return. Domy
ś
lnym kierunkiem jest wej
ś
ciowy.
Bartosz Walter
UML cz. I
24
In
Ŝ
ynieria oprogramowania
UML cz. I (24)
Wła
ś
ciwo
ś
ci i ograniczenia operacji
Operacje, podobnie jak atrybuty, mog
ą
posiada
ć
dodatkowe wła
ś
ciwo
ś
ci i ograniczenia
:
• {query}
– operacja nie modyfikuje stanu obiektu – jest
zapytaniem
•
«exception»
– metoda mo
Ŝ
e zgłasza
ć
wyj
ą
tek
Definicja operacji wewn
ą
trz klasy przewiduje, podobnie jak w przypadku
atrybutów, mo
Ŝ
liwo
ść
umieszczenia dodatkowych informacji i ogranicze
ń
.
Spo
ś
ród nich najwi
ę
ksze znaczenie ma słowo kluczowe {query}
oznaczaj
ą
ce,
Ŝ
e metoda jedynie zwraca fragment stanu obiektu,
natomiast go nie modyfikuje (czyli nie ma efektu ubocznego). Informacja
taka ma bardzo du
Ŝ
e znaczenie w fazie implementacji.
Podobnie metoda mo
Ŝ
e zgłasza
ć
wyj
ą
tki. Wprawdzie UML nie definiuje
sposobu, w jaki powinna by
ć
oznaczona taka metoda, jednak
powszechnie stosowane jest słowo kluczowe exception wraz z nazw
ą
wyj
ą
tku jako opis klasy wyj
ą
tku, oraz informacja o mo
Ŝ
liwo
ś
ci zgłoszenia
wyj
ą
tku skojarzona z metod
ą
.
Bartosz Walter
UML cz. I
25
In
Ŝ
ynieria oprogramowania
UML cz. I (25)
Warunki wst
ę
pne i ko
ń
cowe
wyszukaj(tytuł: String) : Wydawnictwo[]
post:
wynik != null
wynik instanceof Wydawnictwo[]
pre:
tytuł != null
Warunki wst
ę
pne
• opisuj
ą
stan systemu
wymagany przed
wykonaniem operacji
Warunki ko
ń
cowe
• gwarancje dotycz
ą
ce
stanu systemu po
wykonaniu operacji
Operacj
ę
mo
Ŝ
na tak
Ŝ
e opisywa
ć
przez dwa rodzaje warunków: wst
ę
pne
(ang. preconditions) i ko
ń
cowe (ang. postconditions). Opisuj
ą
one
wymagany i oczekiwany stan fragmentu systemu wymagany odpowiednio
przed i po wykonaniu operacji. Pozwala to na precyzyjniejsze opisane
zadania realizowanego przez metod
ę
, jej wymaga
ń
i efektów jej
wykonania. Projektant ma mo
Ŝ
liwo
ść
wyra
Ŝ
enia poprzez nie, jakie warunki
musz
ą
by
ć
spełnione w celu poprawnego wykonania zadania przez
operacj
ę
.
W tym przykładzie warunkiem wst
ę
pnym poprawnego wykonania operacji
wyszukaj() jest przekazanie niepustego parametru reprezentuj
ą
cego tytuł
wydawnictwa, a warunkiem ko
ń
cowym – zwrócenie warto
ś
ci ró
Ŝ
nej od null
b
ę
d
ą
cej tablic
ą
typu Wydawnictwo. Operacja wyszukaj() nie gwarantuje
okre
ś
lonego rozmiaru zwracanej tablicy.
Bartosz Walter
UML cz. I
26
In
Ŝ
ynieria oprogramowania
UML cz. I (26)
Zale
Ŝ
no
ść
Zale
Ŝ
no
ś
ci
s
ą
najprostszym i najsłabszym rodzajem relacji
ł
ą
cz
ą
cych klasy. Oznaczaj
ą
,
Ŝ
e zmiana jednej z nich w
pewien sposób wpływa na drug
ą
, np.
• «call»
- operacje w klasie A wywołuj
ą
operacje w klasie B
• «create»
- klasa A tworzy instancje klasy B
«instantiate»
- obiekt A jest instancj
ą
klasy B
• «use»
- do zaimplementowania klasy A wymagana jest
klasa B
A
B
«call»
Zale
Ŝ
no
ść
mi
ę
dzy klasami jest najsłabszym typem relacji, jaka mo
Ŝ
e
mi
ę
dzy nimi zaistnie
ć
. Ma ona miejsce wówczas, gdy zmiana definicji
jednej klasy mo
Ŝ
e spowodowa
ć
zmian
ę
drugiej. Oznacza to zwykle,
Ŝ
e
zale
Ŝ
no
ść
jest jednokierunkowa.
Zale
Ŝ
no
ś
ci cz
ę
sto opisuje si
ę
fraz
ą
"...korzysta z...", "...oddziałuje na...",
"...ma wpływ na...", "...tworzy...". Z uwagi na ró
Ŝ
ny rodzaj zale
Ŝ
no
ś
ci,
stosuje si
ę
tzw. słowa kluczowe, które doprecyzowuj
ą
znaczenie
zale
Ŝ
no
ś
ci. Du
Ŝ
a liczba zale
Ŝ
no
ś
ci w nawet niewielkim systemie
powoduje,
Ŝ
e nie warto przedstawia
ć
wszystkich, koncentruj
ą
c si
ę
jedynie
na nieoczywistych, znacz
ą
cych dla zrozumienia diagramu.
Zale
Ŝ
no
ś
ci s
ą
oznaczane lini
ą
przerywan
ą
, a o rodzaju zale
Ŝ
no
ś
ci
decyduje słowo kluczowe umieszczone nad lini
ą
.
Bartosz Walter
UML cz. I
27
In
Ŝ
ynieria oprogramowania
UML cz. I (27)
Asocjacja
Asocjacja
reprezentuje czasowe powi
ą
zanie pomi
ę
dzy
obiektami dwóch klas. Obiekty zwi
ą
zane asocjacj
ą
s
ą
od
siebie niezale
Ŝ
ne.
Asocjacja jest te
Ŝ
u
Ŝ
ywana jako alternatywny (obok
atrybutu) i równorz
ę
dny sposób zapisu cech klasy.
Rezerwacja
id_karty
Nr w katalogu
od kiedy
do kiedy
Czytelnik
Pesel : String
Nazwisko : String
Adres : String
Identyfikator : Integer
Imi
ę
: String
Data zapisu : Date
SZABLON IDENTYFIKATORA : String
Rezerwuj()
Wypo
Ŝ
ycz()
(from Use Case View)
1
0..n
+składa
1
0..n
{od kiedy < do kiedy}
Asocjacje s
ą
silniejszymi relacjami ni
Ŝ
zale
Ŝ
no
ś
ci. Wskazuj
ą
,
Ŝ
e jeden
obiekt jest zwi
ą
zany z innym przez pewien okres czasu. Jednak czas
Ŝ
ycia obu obiektów nie jest od siebie zale
Ŝ
ny: usuni
ę
cie jednego nie
powoduje usuni
ę
cia drugiego.
Relacje asocjacji s
ą
zwykle opisywane frazami "...posiada...", "...jest
wła
ś
cicielem...", jednak ich znaczenie cz
ę
sto jest mylone z inn
ą
relacj
ą
–
agregacj
ą
. W przypadku asocjacji
Ŝ
aden obiekt nie jest wła
ś
cicielem
drugiego: nie tworzy go, nie zarz
ą
dza nim, a moment usuni
ę
cia drugiego
obiektu nie jest z nim zwi
ą
zany. Z drugiej strony, obiekt powi
ą
zany
asocjacj
ą
z drugim posiada referencj
ę
do niego, mo
Ŝ
e si
ę
do niego
odwoła
ć
etc. Asocjacje mog
ą
posiada
ć
nazwy, zwykle w postaci
czasownika, który pozwala przeczyta
ć
w j
ę
zyku naturalnym jej znaczenie,
np. „A posiada B”. Cz
ę
sto pomija si
ę
jedn
ą
z nazw asocjacji
dwukierunkowej, je
Ŝ
eli jest ona jedynie stron
ą
biern
ą
drugiej nazwy, np.
„przechowuje” – „jest przechowywany”.
Asocjacja jest równowa
Ŝ
na atrybutowi: UML nie rozró
Ŝ
nia obiektu, który
jest polem klasy od obiektu i jest z ni
ą
zwi
ą
zany asocjacj
ą
. Warto jednak
przyj
ąć
konwencj
ę
, w której obiekty reprezentuj
ą
ce warto
ś
ci (np. daty)
oraz typy proste (liczby, napisy, znaki) s
ą
modelowane jako atrybuty,
natomiast obiekty dost
ę
pne poprzez referencje – s
ą
przedstawiane
poprzez asocjacje.
Bartosz Walter
UML cz. I
28
In
Ŝ
ynieria oprogramowania
UML cz. I (28)
Nawigowalno
ść
asocjacji
Rezerwacja
Czytelnik
(from Use Case View)
1
0..n
+składa
1
0..n
{od kiedy < do kiedy}
Czytelnik
(from Use Case View)
Rezerwacja
*
1
+dotyczy
+składa
1
*
{do kiedy > od kiedy}
Nawigowalno
ść
okre
ś
la wiedz
ę
o sobie nawzajem
obiektów uczestnicz
ą
cych w relacji.
Czytelnik wie o swoich rezerwacjach.
Rezerwacja nie odwołuje si
ę
do czytelnika
Oba obiekty pozwalaj
ą
na nawigacj
ę
do siebie nawzajem
Asocjacje modeluj
ą
wzgl
ę
dn
ą
równowag
ę
pomi
ę
dzy poł
ą
czonymi nimi
obiektami, jednak nie oznacza to,
Ŝ
e ich wiedza o sobie jest taka sama.
Informacj
ę
o kierunku relacji (czyli który obiekt mo
Ŝ
e odwoła
ć
si
ę
do
drugiego) opisuje kierunek asocjacji (czyli jej nawigowalno
ść
).
Nawigowalno
ść
pomi
ę
dzy klas
ą
A i klas
ą
B oznacza,
Ŝ
e od obiektu klasy
A mo
Ŝ
na przej
ść
do obiektu klasy B, ale nie odwrotnie. Nawigowalno
ść
dwukierunkowa oznacza,
Ŝ
e nawiguj
ą
c od obiektu klasy A do obiektu
klasy B, a nast
ę
pnie z powrotem, w zbiorze wyników mo
Ŝ
na znale
źć
pocz
ą
tkowy obiekt klasy A.
Nawigowalno
ść
oznaczana jest na diagramach strzałk
ą
. W przypadku
nawigowalno
ś
ci dwukierunkowej strzałki pomija si
ę
.
Bartosz Walter
UML cz. I
29
In
Ŝ
ynieria oprogramowania
UML cz. I (29)
Klasa asocjacyjna
Klasy asocjacyjne
s
ą
zwi
ą
zane z relacj
ą
asocjacji i opisuj
ą
jej wła
ś
ciwo
ś
ci.
Maj
ą
dost
ę
p do innych obiektów uczestnicz
ą
cych w relacji
Czytelnik
(from Us e Case View)
Rezerwacja
*
1
+dotyczy
+składa
1
*
Zamówienie
data
kanał
opisuje dat
ę
zło
Ŝ
enia rezerwacji
i kanał (telefon, www)
Klasa asocjacyjna umo
Ŝ
liwia opisanie za pomoc
ą
atrybutów i operacji nie
obiektu, ale wła
ś
nie samej asocjacji pomi
ę
dzy klasami. Informacje
przechowywane w klasie asocjacyjnej nie s
ą
zwi
ą
zane z
Ŝ
adn
ą
z klas
uczestnicz
ą
cych w asocjacji, dlatego wygodnie jest stworzy
ć
dodatkow
ą
klas
ę
i powi
ą
za
ć
j
ą
z relacj
ą
.
Klasy asocjacyjne s
ą
reprezentowane graficznie jako klasy poł
ą
czone lini
ą
przerywan
ą
z relacj
ą
asocjacji, której dotycz
ą
.
Bartosz Walter
UML cz. I
30
In
Ŝ
ynieria oprogramowania
UML cz. I (30)
Asocjacja kwalifikowana
Asocjacja kwalifikowana
pozwala wskaza
ć
, który atrybut
jednej z klas słu
Ŝ
y do zapewnienia unikatowo
ś
ci zwi
ą
zku
(jest jego kwalifikatorem).
Czytelnik
(from Use Case View)
Rezerwacja
id wydawnictwa
*
1
1
*
id wydawnictwa
Czytelnik
(from Use Case View)
Rezerwacja
*
1
1
*
Asocjacja kwalifikowana jest rozszerzeniem zwykłej asocjacji o mo
Ŝ
liwo
ść
okre
ś
lenia, który z atrybutów jednej z klas decyduje o zwi
ą
zku mi
ę
dzy
nimi. Na przykład, składaj
ą
c Rezerwacj
ę
, Czytelnik podaje list
ę
Wydawnictw, które chciałby po
Ŝ
yczy
ć
. Innymi słowy, mi
ę
dzy Rezerwacj
ą
a Czytelnikiem wyst
ę
puje relacja typu wiele-jeden. Jednak w danym
momencie Czytelnik mo
Ŝ
e zarezerwowa
ć
dane Wydawnictwo tylko jeden
raz – i dlatego atrybut id wydawnictwa jest kwalifikatorem tej relacji. W
efekcie pomi
ę
dzy instancj
ą
Czytelnika a instancj
ą
Rezerwacji wyst
ę
puje
relacja jeden-jeden, poniewa
Ŝ
konkretny Czytelnik rezerwuje konkretne
Wydawnictwo w danym momencie tylko raz.
Bartosz Walter
UML cz. I
31
In
Ŝ
ynieria oprogramowania
UML cz. I (31)
Agregacja
Agregacja
reprezentuje relacj
ę
typu cało
ść
-cz
ęść
, w której
cz
ęść
mo
Ŝ
e nale
Ŝ
e
ć
do kilku cało
ś
ci, a cało
ść
nie zarz
ą
dza
czasem istnienia cz
ęś
ci.
Karta wydawnictwa
Numer w katalogu : String
Autor : String
Tytuł : String
ISBN : String
Data rejestracji : Date
Data usuni
ę
cia : Date
Katalog
Sortowanie()
Znajd
ź
()
**
Katalog zawiera karty wydawnictw,
ale nie tworzy ich. Nie jest ich
wył
ą
cznym wła
ś
cicielem
Agregacja jest silniejsz
ą
form
ą
asocjacji. W przypadku tej relacji
równowaga mi
ę
dzy powi
ą
zanymi klasami jest zaburzona: istnieje
wła
ś
ciciel i obiekt podrz
ę
dny, które s
ą
ze sob
ą
powi
ą
zane czasem
swojego
Ŝ
ycia. Wła
ś
ciciel jednak nie jest wył
ą
cznym wła
ś
cicielem obiektu
podrz
ę
dnego, zwykle te
Ŝ
nie tworzy i nie usuwa go.
Relacja agregacji jest zaznaczana lini
ą
ł
ą
cz
ą
c
ą
klasy/obiekty, zako
ń
czon
ą
białym rombem po stronie wła
ś
ciciela
Bartosz Walter
UML cz. I
32
In
Ŝ
ynieria oprogramowania
UML cz. I (32)
Kompozycja
Kompozycja
jest relacj
ą
typu
cało
ść
-cz
ęść
, w której
cało
ść
jest wył
ą
cznym wła
ś
cicielem cz
ęś
ci, tworzy je
i zarz
ą
dza nimi.
Ksi
ąŜ
ka
Autor : String
Tytuł : String
ISBN : String
Tom
Liczba stron
Numer : Integer
n
n
Ksi
ąŜ
ka składa si
ę
z tomów. Tom nie
mo
Ŝ
e istnie
ć
bez poj
ę
cia ksi
ąŜ
ki, ani
ksi
ąŜ
ka bez tomów.
Kompozycja jest najsilniejsz
ą
relacj
ą
ł
ą
cz
ą
c
ą
klasy. Reprezentuje relacje
cało
ść
-cz
ęść
, w których cz
ęś
ci s
ą
tworzone i zarz
ą
dzane przez obiekt
reprezentuj
ą
cy cało
ść
. Ani cało
ść
, ani cz
ęś
ci nie mog
ą
istnie
ć
bez siebie,
dlatego czasy ich istnienia s
ą
bardzo
ś
ci
ś
le ze sob
ą
zwi
ą
zane i pokrywaj
ą
si
ę
: w momencie usuni
ę
cie obiektu cało
ś
ci obiekty cz
ęś
ci s
ą
równie
Ŝ
usuwane.
Typowa fraza zwi
ą
zana z tak
ą
relacj
ą
to "...jest cz
ęś
ci
ą
...".
Kompozycja jest przedstawiana na diagramie podobnie jak agregacja,
przy czym romb jest wypełniony.
Bartosz Walter
UML cz. I
33
In
Ŝ
ynieria oprogramowania
UML cz. I (33)
Uogólnienie
Uogólnienie
tworzy hierarchi
ę
klas, od ogólnych do
bardziej szczegółowych. Pozwala wył
ą
czy
ć
cz
ęś
ci
wspólne klas.
Katalog
wydawnictwa : List
Sortowanie()
Znajd
ź
()
Katalog alfabetyczny
Sortowanie()
Znajd
ź
()
Kat alog aut orow
Sortowanie()
Znajd
ź
()
Kat alog rzeczowy
Sortowanie()
Znajd
ź
()
Klasa ogólna
Klasy szczegółowe
Uogólnienie posiada ró
Ŝ
ne interpretacje. Na przykład, w modelu
poj
ę
ciowym Katalog jest uogólnieniem Katalogu rzeczowego, je
Ŝ
eli ka
Ŝ
da
instancja Katalogu rzeczowego jest tak
Ŝ
e instancj
ą
Katalogu. Inn
ą
interpretacj
ą
jest zastosowanie zasady podstawiania Liskov (LSP – Liskov
Substitution Principle): w zamian za typ uogólniony mo
Ŝ
na podstawi
ć
typ
pochodny bez konieczno
ś
ci zmiany reszty programu.
Uogólnienie w przypadku klas cz
ę
sto jest traktowane jako synonim
dziedziczenia, podczas gdy dziedziczenie jest tylko mo
Ŝ
liw
ą
technik
ą
uogólniania. Inn
ą
jest np. wykorzystanie interfejsów, które pozwalaj
ą
utworzy
ć
relacj
ę
uogólnienia/uszczegółowienia pomi
ę
dzy typami
(dziedziczenie interfejsu) lub klas
ą
i interfejsem (implementacja interfejsu).
Bartosz Walter
UML cz. I
34
In
Ŝ
ynieria oprogramowania
UML cz. I (34)
Klasyfikacja
Klasyfikacja
okre
ś
la zwi
ą
zek mi
ę
dzy obiektem a jego
typem (klas
ą
).
Obiekt mo
Ŝ
e nale
Ŝ
e
ć
jednocze
ś
nie do wielu typów.
Ksi
ąŜ
ka
Wydawnictwo
Czasopismo
Ogólne
Specjalizowane
{overlapping, incomplete}
{disjoint, complete}
{overlapping}
– obiekt mo
Ŝ
e
nale
Ŝ
e
ć
do kilku klas
{disjoint}
– obiekt mo
Ŝ
e nale
Ŝ
e
ć
tylko do jednej klasy
{complete}
– nie istnieje wi
ę
cej
podklas
{incomplete}
– mog
ą
powsta
ć
kolejne podklasy
Klasyfikacja obiektu reprezentuje (w odró
Ŝ
nieniu od relacji
uogólnienia/uszczegółowienia) zwi
ą
zek pomi
ę
dzy obiektami a klasami.
Klasyfikacja obiektu okre
ś
la, z którymi typami (klasami) jest powi
ą
zany –
poprzez dziedziczenie, interfejsy etc. Poniewa
Ŝ
obiekt mo
Ŝ
e jednocze
ś
nie
uczestniczy
ć
w wielu niezale
Ŝ
nych klasyfikacjach (a zatem posiada
ć
wiele
typów, niekoniecznie poprzez dziedziczenie), dlatego do szczegółowego
okre
ś
lenia klasyfikacji stosowane s
ą
u
ś
ci
ś
laj
ą
ce słowa kluczowe:
•{overlapping} oznacza,
Ŝ
e obiekt mo
Ŝ
e jednocze
ś
nie nale
Ŝ
e
ć
do kilku
klas/posiada
ć
wiele typów. Na przykład Wydawnictwo, mimo
Ŝ
e posiada
dwie podklasy: Ksi
ąŜ
ka Czasopismo, mo
Ŝ
e wyst
ą
pi
ć
w postaci ł
ą
cz
ą
cej
obie te cechy. Przeciwie
ń
stwem jest słowo kluczowe {disjoint}, które
narzuca rozł
ą
czno
ść
typów danych
•{complete} oznacza,
Ŝ
e wymienione dotychczas podklasy w ramach
jednej specjalizacji s
ą
wyczerpuj
ą
ce i nie istnieje kategoria, która
znalazłaby si
ę
poza nimi. W przykładzie Wydawnictwo mo
Ŝ
e by
ć
Ogólne
lub Specjalizowane, i nie przewiduje si
ę
istnienia nowej podklasy.
{Incomplete} przewiduje tak
ą
mo
Ŝ
liwo
ść
.
Bartosz Walter
UML cz. I
35
In
Ŝ
ynieria oprogramowania
UML cz. I (35)
Interfejsy i klasy abstrakcyjne
Klasa abstrakcyjna
deklaruje wspóln
ą
funkcjonalno
ść
grupy
klas. Nie mo
Ŝ
e posiada
ć
obiektów i musi definiowa
ć
podklasy.
Interfejs
deklaruje grup
ę
operacji bez podawania ich
implementacji.
wymagany
interfejs
implementowany
interfejs
Katalog
wydawnictwa : List
Sortowanie() : void
Znajd
ź
() : Wydawnictwo
Porównaj()
Sortowalny
Porównaj()
Katalog alfabetyczny
Sortowanie()
Znajd
ź
()
Narz
ę
dzia
sortuj()
<<realizes>>
Celem tworzenia klas abstrakcyjnych i interfejsów jest identyfikacja
wspólnych zachowa
ń
ró
Ŝ
nych klas, które s
ą
realizowane w ró
Ŝ
ny od
siebie sposób. U
Ŝ
ycie tych mechanizmów pozwala na wykorzystanie
relacji uogólniania do ukrywania (hermetyzacji) szczegółów implementacji
poszczególnych klas.
Klasa abstrakcyjna reprezentuje wirtualny byt grupuj
ą
cy wspóln
ą
funkcjonalno
ść
kilku klas. Posiada ona sygnatury operacji (czyli
deklaracje,
Ŝ
e klasy tego typu b
ę
d
ą
akceptowa
ć
takie komunikaty), ale nie
definiuje ich implementacji.
Podobn
ą
rol
ę
pełni interfejs. Ró
Ŝ
nica polega na tym,
Ŝ
e klasa
abstrakcyjna mo
Ŝ
e posiada
ć
implementacje niektórych operacji, natomiast
interfejs jest czysto abstrakcyjny (cho
ć
, oczywi
ś
cie interfejs i klasa w pełni
abstrakcyjna s
ą
poj
ę
ciowo niemal identyczne).
Poniewa
Ŝ
klasy abstrakcyjne nie mog
ą
bezpo
ś
rednio tworzy
ć
swoich
instancji (podobnie jak interfejsy, które z definicji nie reprezentuj
ą
klas, a
jedynie ich typy) dlatego konieczne jest tworzenie ich podklas, które
zaimplementuj
ą
odziedziczone abstrakcyjne metody. W przypadku
interfejsu sytuacja jest identyczna.
Przyj
ę
tym sposobem oznaczania klas i metod abstrakcyjnych jest
zapisywanie ich pochył
ą
czcionk
ą
lub opatrywanie słowem kluczowym
{abstract}.
Bartosz Walter
UML cz. I
36
In
Ŝ
ynieria oprogramowania
UML cz. I (36)
Interfejsy i klasy abstrakcyjne
Klasa abstrakcyjna
deklaruje wspóln
ą
funkcjonalno
ść
grupy
klas. Nie mo
Ŝ
e posiada
ć
obiektów i musi definiowa
ć
podklasy.
Interfejs
deklaruje grup
ę
operacji bez podawania ich
implementacji.
wymagany
interfejs
implementowany
interfejs
Katalog
wydawnictwa : List
Sortowanie() : void
Znajd
ź
() : Wydawnictwo
Porównaj()
Sortowalny
Porównaj()
Katalog alfabetyczny
Sortowanie()
Znajd
ź
()
Narz
ę
dzia
sortuj()
<<realizes>>
W przykładzie Katalog jest klas
ą
abstrakcyjn
ą
posiadaj
ą
c
ą
abstrakcyjne
metody Sortowanie() i Znajd
ź
(). Metody te posiadaj
ą
implementacje w
podklasie Katalog alfabetyczny.
Katalog implementuje interfejs Sortowalny (z metod
ą
Porównaj()), który z
kolei jest wymagany przez klas
ę
pomocnicz
ą
Narz
ę
dzia.
Bartosz Walter
UML cz. I
37
In
Ŝ
ynieria oprogramowania
UML cz. I (37)
Szablony klas
Szablon klasy
okre
ś
la, z jakimi innymi klasami (nie obiektami!)
mo
Ŝ
e współpracowa
ć
podana klasa. Klasy te s
ą
przekazywane
jako jej parametry.
Klasa b
ę
d
ą
ca uszczegółowieniem takiej klasy jest
klas
ą
zwi
ą
zan
ą
.
parametr klasy Lista
ListaWydawnictw
T
Lista
sortuj()
pierwszy()
ostatni()
długo
ść
()
szablon klasy Lista
klasa zwi
ą
zana
«bind»
Szablony klas to poj
ę
cie wywodz
ą
ce si
ę
z j
ę
zyka C++. Oznaczaj
ą
one
klasy, których definicja wymaga podania argumentów b
ę
d
ą
cych innymi
klasami. W ten sposób szablon klasy jest swego rodzaju niepełn
ą
klas
ą
,
która dopiero po ukonkretnieniu mo
Ŝ
e zosta
ć
u
Ŝ
yta. Na przykład, klasa
Lista mo
Ŝ
e przechowywa
ć
obiekty pewnego typu. Typ ten mo
Ŝ
e sta
ć
si
ę
parametrem tej klasy: w ten sposób utworzony zostanie szablon listy dla
potencjalnie dowolnego typu. Klasa stanowi
ą
ca ukonkretnienie szablonu
(ListaWydawnictw) została sparametryzowana (zwi
ą
zana) typem
Wydawnictwo, dzi
ę
ki czemu mo
Ŝ
e by
ć
ju
Ŝ
wykorzystana do tworzenia
obiektów.
Podobn
ą
koncepcj
ę
wprowadzono tak
Ŝ
e do innych j
ę
zyków
programowania, np. Java, pod nazw
ą
typów generycznych.
Bartosz Walter
UML cz. I
38
In
Ŝ
ynieria oprogramowania
UML cz. I (38)
Diagram obiektów
Diagram obiektów
przedstawia mo
Ŝ
liw
ą
konfiguracj
ę
obiektów wyst
ę
puj
ą
cych w systemie.
Relacje pomi
ę
dzy obiektami s
ą
bardziej dynamiczne ni
Ŝ
w
przypadku klas.
Cichy Don: Ksiazka
Autor = M. Szołochow
Egz876: Egzemplarz
Numer w katalogu = 876
Numer wydawnictwa
Rez123 : Rezerwacja
od kiedy = 13-05-2006
do kiedy = 27-05-2006
1
0..n
1
0..n
Kowalski: Czytelnik
PESEL = 65020212345
Nazwisko = Kowalski
Adres = Nijaka 2
OplatyKarne = 10.50
(from Us e Cas e View)
<<Actor>>
1
0..n
1
0..n
Diagram obiektów (ang. object diagram) prezentuje mo
Ŝ
liw
ą
konfiguracj
ę
obiektów w okre
ś
lonym momencie, jest pewnego rodzaju instancj
ą
diagramu klas, w której zamiast klas przedstawiono ich obiekty.
Diagram ten posługuje si
ę
identycznymi symbolami co diagram klas,
jednak, dla odró
Ŝ
nienia obiektów od klas, nazwy instancji s
ą
podkre
ś
lone.
Ponadto, nazwa składa si
ę
z nazwy obiektu i nazwy klasy, oddzielonych
dwukropkiem. Obie cz
ęś
ci nazwy mo
Ŝ
na pomin
ąć
, wi
ę
c aby unikn
ąć
nieporozumie
ń
, jedna cz
ęść
nazwy oznacza nazw
ę
obiektu, a sama
nazwa klasy musi by
ć
zawsze poprzedzona dwukropkiem.
Diagramy obiektów przydaj
ą
si
ę
w przypadku szczególnie
skomplikowanych zale
Ŝ
no
ś
ci, których nie mo
Ŝ
na przedstawi
ć
na
diagramie klas. Wówczas przykładowe konfiguracje obiektów pomagaj
ą
w
zrozumieniu modelu.
Bartosz Walter
UML cz. I
39
In
Ŝ
ynieria oprogramowania
UML cz. I (39)
Diagram struktur zło
Ŝ
onych
Diagram struktur zło
Ŝ
onych
przedstawia wewn
ę
trzn
ą
struktur
ę
obiektu oraz punkty interakcji z innymi obiektami w
systemie.
Katalog
Wyszukiwarka
Baza danych
«defines»
«defines»
Wyszukiwanie
Zarz
ą
dzanie danymi
obiekt zło
Ŝ
ony
cz
ęść
port
interfejs
Diagram struktur zło
Ŝ
onych (ang. composite structure diagram)
przedstawia hierarchicznie wewn
ę
trzn
ą
struktur
ę
zło
Ŝ
onego obiektu z
uwzgl
ę
dnieniem punktów interakcji z innymi cz
ęś
ciami systemu.
Obiekt składa si
ę
z cz
ęś
ci, które reprezentuj
ą
poszczególne składowe
obiektu realizuj
ą
ce poszczególne funkcje obiektu. Komunikacja pomi
ę
dzy
obiektem, a jego
ś
rodowiskiem przebiega poprzez port (oznaczany jako
mały prostok
ą
t umieszczony na kraw
ę
dzi obiektu). Porty s
ą
poł
ą
czone z
cz
ęś
ciami obiektu, które s
ą
odpowiedzialne za realizacje tych funkcji.
Diagramy struktur zło
Ŝ
onych mog
ą
tak
Ŝ
e zawiera
ć
interfejsy wewn
ę
trzne
(równowa
Ŝ
ne klasom w pełni abstrakcyjnym) i interfejsy udost
ę
pnione
(widoczne na zewn
ą
trz obiektu; dziel
ą
si
ę
na interfejsy wymagane i
oferowane).
Bartosz Walter
UML cz. I
40
In
Ŝ
ynieria oprogramowania
UML cz. I (40)
Podsumowanie
• UML powstał w wyniku poł
ą
czenia ró
Ŝ
nych notacji i
metodyk modelowania
• UML opisuje system w postaci 4 perspektyw
wewn
ę
trznych i 1 zewn
ę
trznej
• Diagram przypadków u
Ŝ
ycia opisuje funkcje
systemu i jego u
Ŝ
ytkowników
• Diagram klas okre
ś
la statyczn
ą
struktur
ę
logiczn
ą
systemu
• Diagram obiektów pokazuje mo
Ŝ
liw
ą
konfiguracj
ę
obiektów w systemie
Podczas wykładu przedstawiono genez
ę
j
ę
zyka UML, jego struktur
ę
, oraz
trzy typy diagramów: przypadków u
Ŝ
ycia, klas, obiektów i struktury
zło
Ŝ
onej.