Bartosz Walter
UML cz. II
1
In
Ŝ
ynieria oprogramowania
UML cz. II
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
UML cz. II
1
In
Ŝ
ynieria oprogramowania
UML cz. II
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
UML cz. II
2
In
Ŝ
ynieria oprogramowania
UML cz. II (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 ten stanowi dalsz
ą
cz
ęść
przegl
ą
du najwa
Ŝ
niejszych elementów
j
ę
zyka modelowania UML.
Bartosz Walter
UML cz. II
3
In
Ŝ
ynieria oprogramowania
UML cz. II (3)
Agenda
1. Diagram komponentów
2. Diagram pakietów
3. Diagramy interakcji
4. Rodzaje komunikatów
5. Diagramy stanu i czynności
6. Mechanizm rozszerzeń UML
7. OCL
8. Narzędzia UML
Podczas bie
Ŝą
cego wykładu zostan
ą
przedstawione pozostałe diagramy
struktury: diagram komponentów oraz diagram pakietów. Nast
ę
pnie
omówione b
ę
d
ą
diagramy interakcji, prezentuj
ą
ce dynamiczny aspekt
modelu systemu, przede wszystkim – diagramy sekwencji i
współdziałania. Kolejna cz
ęść
wykładu b
ę
dzie po
ś
wi
ę
cona diagramom
czynno
ś
ci oraz stanu, opisuj
ą
cym wewn
ę
trzne zachowanie klas,
komponentów i podsystemów.
Po zako
ń
czeniu przegl
ą
du diagramów przedstawiony zostanie j
ę
zyk OCL
słu
Ŝą
cy do formalnego opisu ogranicze
ń
w UML. Mimo,
Ŝ
e jest
nieobowi
ą
zkowy, odgrywa on znacz
ą
c
ą
rol
ę
przy wykorzystaniu notacji
UML jako podstawy do generowania kodu wykonywalnego.
Ostatni
ą
cz
ęś
ci
ą
b
ę
dzie przedstawienie wybranych narz
ę
dzi UML,
zarówno komercyjnych, jak i darmowych.
Bartosz Walter
UML cz. II
4
In
Ŝ
ynieria oprogramowania
UML cz. II (4)
Diagram komponentów
Komponent
reprezentuje podsystem (grup
ę
powi
ą
zanych
klas), który wymaga pewnych interfejsów, a pewne interfejsy
implementuje.
Diagram komponentów
pokazuje zale
Ŝ
no
ś
ci pomi
ę
dzy
komponentami i interfejsami
Sortowalny
Katalog
Mened
Ŝ
er
kryteriów
Przeszukiwanie
komponent
korzysta z implementacji
dostarczonej przez Katalog
implementuje interfejs
Przeszukiwanie
Komponent to wymienny, wykonywalny fragment systemu o
hermetyzowanych szczegółach implementacyjnych. Komponenty z natury
słu
Ŝą
do ponownego wykorzystania poprzez poł
ą
czenie ich z innymi
komponentami, zwykle poprzez ich skonfigurowanie, bez potrzeby
rekompilacji.
Funkcjonalno
ść
oferowana przez komponent jest dost
ę
pna przez
interfejsy, które implementuje. Z drugiej strony, komponent mo
Ŝ
e
wymaga
ć
pewnych interfejsów, które musz
ą
by
ć
dostarczone przez inne
komponenty.
Diagram komponentów (ang. component diagram) przedstawia
komponenty, ich interfejsy oraz zale
Ŝ
no
ś
ci pomi
ę
dzy nimi.
Na powy
Ŝ
szym slajdzie komponent Katalog implementuje interfejsy
Sortowalny oraz Przeszukiwanie, natomiast interfejs Mened
Ŝ
er kryteriów
potrzebuje implementacji interfejsu Przeszukiwanie i korzysta w tym celu z
komponentem Katalog.
Przedstawiony diagram stosuje notacj
ę
znan
ą
z UML 1.x. W przypadku
UML 2.0 komponenty s
ą
przedstawiane w postaci prostok
ą
tów ze
stereotypem «component», natomiast interfejsy
Ŝą
dane przez komponent
w postaci otwartych "łapek" dopasowanych do "piłeczek"
reprezentuj
ą
cych implementowane interfejsy.
Bartosz Walter
UML cz. II
5
In
Ŝ
ynieria oprogramowania
UML cz. II (5)
Zale
Ŝ
no
ś
ci pomi
ę
dzy komponentami
Sortowalny
Katalog
Mened
Ŝ
er
kryteriów
Przeszukiwanie
Mened
Ŝ
er
wydawnictw
Baza danych
Mened
Ŝ
er
rozlicze
ń
Katalog zale
Ŝ
y od
Mened
Ŝ
era wydawnictw
Mened
Ŝ
er wydawnictw
zale
Ŝ
y od Bazy danych
Komponenty s
ą
mi
ę
dzy sob
ą
powi
ą
zane relacj
ą
zale
Ŝ
no
ś
ci, poniewa
Ŝ
wymagaj
ą
ich do realizacji własnej funkcjonalno
ś
ci. Zale
Ŝ
no
ść
mi
ę
dzy A i
B oznacza,
Ŝ
e komponent A korzysta z komponentu B i zmiana w
komponencie B mo
Ŝ
e spowodowa
ć
konieczno
ść
zmiany w A.
Ilo
ść
i jako
ść
tych zale
Ŝ
no
ś
ci ma du
Ŝ
e znaczenie dla oceny jako
ś
ci
modelu i projektu: du
Ŝ
a liczba powi
ą
za
ń
pomi
ę
dzy komponentami, a w
szczególno
ś
ci zale
Ŝ
no
ś
ci cykliczne, w znacznym stopniu utrudniaj
ą
wyznaczanie obszarów zmienno
ś
ci i ich hermetyzacj
ę
, a co za tym idzie –
podnosz
ą
koszt piel
ę
gnacji oprogramowania. W odró
Ŝ
nieniu od tego,
system o dobrze zdefiniowanych interfejsach komponentów pozwala na
ich wymian
ę
bez potrzeby modyfikacji pozostałej cz
ęś
ci systemu.
Przykład przedstawiony na powy
Ŝ
szym slajdzie pokazuje m.in., zale
Ŝ
no
ść
komponentu Katalog (który implementuje interfejs Sortowalny, jednak nie
jest w ten sposób przez
Ŝ
aden inny komponent wykorzystywany) od
Mened
Ŝ
era wydawnictw. Komponent Katalog posiada tak
Ŝ
e interfejs
Przeszukiwanie, który jest interfejsem wymaganym przez Mened
Ŝ
era
rozlicze
ń
i Mened
Ŝ
era kryteriów. Interfejs ten stanowi punkt ł
ą
cz
ą
cy
Katalog z tymi komponentami.
Bartosz Walter
UML cz. II
6
In
Ŝ
ynieria oprogramowania
UML cz. II (6)
Diagram pakietów
Pakiety w UML
słu
Ŝą
do przechowywania innych elementów
j
ę
zyka, przede wszystkim klas. Dzi
ę
ki nim mo
Ŝ
na
uporz
ą
dkowa
ć
struktur
ę
modelu.
Obsługa czytelników
Obsługa
wydawnictw
Powiadomienia
B aza danych
Katalog
Rozliczenia
GUI
Pakiet Obsługa czytelników::GUI
Diagramy pakietów (ang. package diagrams) słu
Ŝą
do modelowania
fizycznego i logicznego podziału systemu. Pakiety s
ą
elementem
strukturalizuj
ą
cym elementy UML i słu
Ŝą
do grupowania ich według
dowolnego kryterium. W pakiecie mo
Ŝ
na umie
ś
ci
ć
praktycznie dowolne
elementy: klasy, komponenty, przypadki u
Ŝ
ycia, a tak
Ŝ
e inne pakiety. W
ten sposób przedstawiaj
ą
one drzewiast
ą
struktur
ę
elementów modelu.
Pakiety doskonale nadaj
ą
si
ę
do wizualizacji podstawowych zale
Ŝ
no
ś
ci
pomi
ę
dzy cz
ęś
ciami systemu, dzi
ę
ki czemu łatwo oceni
ć
jako
ść
i stopie
ń
powi
ą
za
ń
pomi
ę
dzy nimi. Dobra struktura pakietów, w której zale
Ŝ
no
ś
ci s
ą
jasno uporz
ą
dkowane oraz nie wyst
ę
puj
ą
(lub wyst
ę
puj
ą
tylko na niskim
poziomie) zale
Ŝ
no
ś
ci cykliczne, wspiera pó
ź
niejsz
ą
rozbudow
ę
systemu.
W szczególno
ś
ci przydaj
ą
si
ę
w du
Ŝ
ych aplikacjach, podzielonych na
wiele podsystemów, poniewa
Ŝ
w prosty sposób obrazuj
ą
podstawowe
zale
Ŝ
no
ś
ci pomi
ę
dzy nimi.
Pakiet tworzy tak
Ŝ
e jednostk
ę
hermetyzacji: elementy z pakietu odwołuj
ą
si
ę
do elementów zewn
ę
trznych posługuj
ą
c si
ę
ich pełnymi
kwalifikowanymi (zawieraj
ą
cymi nazwy pakietów) nazwami, zgodnie z ich
zakresem widoczno
ś
ci, natomiast wewn
ą
trz pakietu elementy mog
ą
odwoływa
ć
si
ę
do siebie bezpo
ś
rednio.
Bartosz Walter
UML cz. II
7
In
Ŝ
ynieria oprogramowania
UML cz. II (7)
Diagram pakietów
Pakiety w UML
słu
Ŝą
do przechowywania innych elementów
j
ę
zyka, przede wszystkim klas. Dzi
ę
ki nim mo
Ŝ
na
uporz
ą
dkowa
ć
struktur
ę
modelu.
Obsługa czytelników
Obsługa
wydawnictw
Powiadomienia
B aza danych
Katalog
Rozliczenia
GUI
Pakiet Obsługa czytelników::GUI
Elementy wewn
ą
trz pakietu mog
ą
mie
ć
jeden z dwóch poziomów
widoczno
ś
ci: prywatny lub publiczny. Elementy publiczne s
ą
widziane i
mog
ą
by
ć
u
Ŝ
yte poza własnym pakietem, natomiast prywatne – nie. Aby
elementy pakietu mogły odwoła
ć
si
ę
do elementów prywatnych z innego
pakietu, musz
ą
go importowa
ć
. Oznacza to,
Ŝ
e elementy te staj
ą
si
ę
dla
importuj
ą
cego pakietu widoczne. Import pakietu oznaczany jest
zale
Ŝ
no
ś
ci
ą
ze słowem kluczowym «import».
Bartosz Walter
UML cz. II
8
In
Ŝ
ynieria oprogramowania
UML cz. II (8)
Diagram wdro
Ŝ
enia
Diagramy wdro
Ŝ
enia
przedstawiaj
ą
powi
ą
zania mi
ę
dzy
oprogramowaniem (artefaktami) i sprz
ę
tem (w
ę
złami). S
ą
stosowane przy modelowaniu du
Ŝ
ych systemów
S ystem
Serwer
Baza
danych
Usługi
katalogowe
Serwer baz danych
Serwer usługowy
Serwer
backup
aplikacja
m anual
w
ę
zeł
ś
cie
Ŝ
ka
komunikacyjna
artefakt
Diagram wdro
Ŝ
enia (ang. deployment diagram) odzwierciedla fizyczn
ą
struktur
ę
całego systemu, z uwzgl
ę
dnieniem oprogramowania i sprz
ę
tu.
Jednostki oprogramowania s
ą
reprezentowane przez artefakty (czyli
skompilowane wersje komponentu, który mo
Ŝ
na uruchomi
ć
), dane i
biblioteki. Stron
ę
sprz
ę
tow
ą
reprezentuj
ą
w
ę
zły, czyli poszczególne
urz
ą
dzenia obliczeniowe, komunikacyjne i przechowuj
ą
ce, powi
ą
zane
ś
cie
Ŝ
kami komunikacyjnymi (np. poł
ą
czeniem TCP/IP).
Diagramy te s
ą
rzadko u
Ŝ
ywane przy modelowaniu mniejszych i
ś
rednich
systemów, dlatego zwykle ich rola jest ograniczona. Poniewa
Ŝ
posługuj
ą
si
ę
zaledwie kilkoma symbolami, dlatego kluczow
ą
rol
ę
odgrywaj
ą
stereotypy nadawane poszczególnym elementom. Pozwalaj
ą
one
doprecyzowa
ć
znaczenie i funkcj
ę
oprogramowania oraz sprz
ę
tu.
Diagramy wdro
Ŝ
enia istotn
ą
rol
ę
odgrywaj
ą
przy wdra
Ŝ
aniu du
Ŝ
ych,
rozproszonych systemów.
Bartosz Walter
UML cz. II
9
In
Ŝ
ynieria oprogramowania
UML cz. II (9)
Diagramy interakcji
Diagramy interakcji
w UMLu opisuj
ą
komunikacj
ę
mi
ę
dzy
obiektami. Zwykle diagramy nale
Ŝą
do okre
ś
lonych obiektów.
Rodzaje diagramów interakcji w UML:
• diagram sekwencji
• diagram współdziałania (UML 1.x) lub diagram
komunikacji (UML 2.0)
• diagram przegl
ą
du interakcji
• diagram uwarunkowa
ń
czasowych
Opisywanie jedynie struktury logicznej systemu jest zwykle
niewystarczaj
ą
ce. Konieczne jest tak
Ŝ
e pokazanie, jak obiekty ze sob
ą
si
ę
komunikuj
ą
, jakie informacje przesyłaj
ą
, aby dostarczy
ć
okre
ś
lon
ą
funkcjonalno
ść
. Wszystkie wersje UML posiadaj
ą
bogaty wachlarz
diagramów dotycz
ą
cych tego aspektu modelowania.
Spo
ś
ród nich najbardziej znanym i najcz
ęś
ciej wykorzystywanym jest
diagram sekwencji, pokazuj
ą
cy przepływ komunikatów mi
ę
dzy obiektami
w kontek
ś
cie czasu. Pozostałe diagramy – komunikacji, przegl
ą
du
interakcji czy uwarunkowa
ń
czasowych – zwykle odgrywaj
ą
mniejsz
ą
rol
ę
,
ale warto o nich wspomnie
ć
.
Bartosz Walter
UML cz. II
10
In
Ŝ
ynieria oprogramowania
UML cz. II (10)
Diagram sekwencji
Diagram sekwencji
przedstawia sposób wymiany
komunikatów pomi
ę
dzy obiektami z zachowaniem ich
kolejno
ś
ci
c
z
a
s
: Wypo
Ŝ
yczaj
ą
cy
: Wypo
Ŝ
yczaj
ą
cy
: Bibliotekarz
: Bibliotekarz
: Karta
wydawnictwa
: Karta
wydawnictwa
: Katalog
: Katalog
1. zamówienie
1.2. sprawd
ź
1.2.1.
1.4. wyszukaj
1.4.1.
1.5.
1.1.
1.3.
sd
Diagramy sekwencji (ang. sequence diagrams) intuicyjnie prezentuj
ą
kolejno
ść
wywoła
ń
operacji, przepływ sterowania pomi
ę
dzy obiektami
oraz szablon realizowanego algorytmu. Pomijaj
ą
natomiast całkowicie
aspekt dost
ę
pu i operacji na danych, zwi
ą
zany z komunikacj
ą
.
Uczestnikami diagramów sekwencji s
ą
obiekty, opisane nazw
ą
obiektu i
jego klas
ą
, które wymieniaj
ą
mi
ę
dzy sob
ą
komunikaty.
Diagram sekwencji jest zapisany w prostok
ą
cie oznaczonym operatorem
sd (od angielskiej nazwy diagramu) i składa si
ę
z pionowych linii
Ŝ
ycia
(ang. lifelines) poszczególnych obiektów uczestnicz
ą
cych w interakcji oraz
wymienianych mi
ę
dzy nimi komunikatów (wywoła
ń
operacji). Białe
prostok
ą
ty umieszczone na linii
Ŝ
ycia obiektu oznaczaj
ą
,
Ŝ
e obiekt jest
zaj
ę
ty wykonywaniem pewnej czynno
ś
ci (natomiast nie maj
ą
bezpo
ś
redniego zwi
ą
zku z istnieniem obiektu). Czas jest reprezentowany
w postaci pionowej osi diagramu.
Linia
Ŝ
ycia obiektu to czas, w którym konkretna instancja obiektu jest w
stanie przyjmowa
ć
komunikaty i wysyła
ć
je. Innymi słowy, obejmuje ona
czas istnienia obiektu w systemie. Obiekt jest tworzony poprzez wysłanie
do niego komunikatu-konstruktora (Bibliotekarz tworzy obiekt klasy Karta
Wydawnictwa), natomiast niekoniecznie jest fizycznie usuwany na ko
ń
cu
linii
Ŝ
ycia – raczej przestaje by
ć
istotny. Fizycznie usuni
ę
cie obiektu
mo
Ŝ
na wprost oznaczy
ć
jako znak X na linii
Ŝ
ycia (na przykład obiekt
Karta wydawnictwa).
Bartosz Walter
UML cz. II
11
In
Ŝ
ynieria oprogramowania
UML cz. II (11)
Rodzaje komunikatów
wywołanie procedury
powrót z wywołania
wyw. asynchroniczne
UML 1.x
UML 2.0
Komunikat to forma kontaktu pomi
ę
dzy obiektami, której efektem ma by
ć
podj
ę
cie przez docelowy obiekt pewnej akcji. Otrzymanie komunikatu
przez obiekt wi
ąŜ
e si
ę
z wykonaniem przez niego jego własnego kodu lub
wysłaniem kolejnego komunikatu do innego obiektu w celu wykonania
przez niego pewnej akcji.
Komunikaty w UML s
ą
reprezentowane przez strzałki ł
ą
cz
ą
ce linie
Ŝ
ycia
poszczególnych obiektów. Ka
Ŝ
dy komunikat wewn
ą
trz interakcji opatrzony
jest kolejnym numerem, co pozwala na łatwe
ś
ledzenie jej przebiegu.
Istniej
ą
trzy podstawowe komunikaty, jakie mog
ą
zosta
ć
wymienione
pomi
ę
dzy obiektami: wywołanie procedury, powrót z niej oraz wywołanie
asynchroniczne.
Bartosz Walter
UML cz. II
12
In
Ŝ
ynieria oprogramowania
UML cz. II (12)
Bloki
Blok
definiuje grup
ę
komunikatów wspólnie posiadaj
ą
c
ą
pewn
ą
wła
ś
ciwo
ść
.
: Wypo
Ŝ
yczaj
ą
cy
: Wypo
Ŝ
yczaj
ą
cy
: Bibliotekarz
: Bibliotekarz
: Karta
wydawnictwa
: Karta
wydawnictwa
: Katalog
: Katalog
1. zamówienie
1.1. sprawd
ź
1.1.1.
1.2. wyszukaj
1.2.1.
1.3.
loop
(0, zamówienie.size)
Bardzo cz
ę
sto zachodzi konieczno
ść
wskazania specjalnej własno
ś
ci
pewnej cz
ęś
ci interakcji, np. oznaczenie sekcji krytycznej czy zwyczajnej
p
ę
tli. Na diagramach sekwencji tak
ą
grup
ę
operacji obejmuje si
ę
prostok
ą
tem, w którego lewym górnym naro
Ŝ
niku, w pi
ę
ciok
ą
cie
umieszcza si
ę
słowo kluczowe lub opis okre
ś
laj
ą
cy znaczenie danego
bloku (tzw. operator interakcji), np.:
•alt (od alternative) – okre
ś
laj
ą
cy warunek wykonania bloku operacji,
odpowiadaj
ą
cy instrukcji if-else; warunek umieszcza si
ę
wówczas
wewn
ą
trz bloku w nawiasach kwadratowych
•opt (od optional) – reprezentuj
ą
cy instrukcj
ę
if (bez else)
•par (od parallel) – nakazuj
ą
cy wykona
ć
operacje równolegle
•critical – oznaczaj
ą
cy obszar krytyczny
•loop – definiuj
ą
cy p
ę
tl
ę
typu for (o okre
ś
lonej z góry liczbie iteracji) lub
while (wykonywanej dopóki pewien warunek jest prawdziwy)
Bartosz Walter
UML cz. II
13
In
Ŝ
ynieria oprogramowania
UML cz. II (13)
Przykład
: Czytelnik
: Czytelnik
: Karta
: Karta
: Katalog
: Katalog
: Egzemplarz
wyszukaj
przedłu
Ŝ
ustawStatus
sprawd
ź
status
wyszukaj
Slajd przedstawia przykładowy diagram sekwencji dla przypadku u
Ŝ
ycia
'Przedłu
Ŝ
enie wypo
Ŝ
yczenia'. Czytelnik wyszukuje w Katalogu swoj
ą
kart
ę
biblioteczn
ą
. Po jej znalezieniu sprawdza jej status. Sprawdzenie statusu
polega m.in. na wyszukaniu w katalogu wszystkich egzemplarzy ksi
ąŜ
ek,
które Czytelnik aktualnie ma wypo
Ŝ
yczone. Nast
ę
pnie Czytelnik zleca
przedłu
Ŝ
enie okre
ś
lonego egzemplarza, co powoduje aktualizacj
ę
statusu
w klasie Egzemplarz.
Bartosz Walter
UML cz. II
14
In
Ŝ
ynieria oprogramowania
UML cz. II (14)
Diagram współdziałania
Diagram komunikacji
przedstawia sposób wymiany
komunikatów pomi
ę
dzy obiektami uczestnicz
ą
cymi w
interakcji. Jest rozszerzon
ą
wersj
ą
diagramu współdziałania.
: Czytelnik
: Bibliotekarz
: Katalog
: Ksiazka
1: wypo
Ŝ
ycz
2: wyszukaj
3: status
4: wypo
Ŝ
ycz
1.1: wyszukaj
1.2: status
1.2: wypo
Ŝ
ycz
Diagram komunikacji (ang. communication diagram) jest rozszerzon
ą
i
przemianowan
ą
wersj
ą
diagramu współdziałania znanego z UML 1.x.
Skupia si
ę
on na obiektach wchodz
ą
cych w skład interakcji i
wymienianymi przez nie komunikatach, natomiast w mniejszym stopniu
ni
Ŝ
diagram sekwencji (cho
ć
nadal obecnym) wskazuje na aspekt
czasowy. Z tego powodu obiekty na diagramie komunikacji s
ą
umieszczone tak, aby łatwo mo
Ŝ
na było opisa
ć
ich relacje pomi
ę
dzy sob
ą
.
Komunikacje s
ą
przedstawiane za pomoc
ą
linii ł
ą
cz
ą
cych obiekty,
natomiast przesyłane mi
ę
dzy obiektami komunikaty i dane s
ą
umieszczane obok tych linii. Ka
Ŝ
dy komunikat jest opatrzony etykiet
ą
liczbow
ą
, wskazuj
ą
c
ą
na kolejno
ść
ich wysyłania. Etykieta ta ma posta
ć
liczb oddzielonych kropkami. W przypadku rozdzielenia sterowania ka
Ŝ
dy
krok powoduje dodanie do etykiet kroków nast
ę
pnych kolejnych pól z
liczbami, np. krok 2 powoduje utworzenie kroków 2.1, 2.2 le
Ŝą
cych
bezpo
ś
rednio za nim. Krok 2.1 posiada kroki 2.1.1 i 2.1.2, itd.
W odró
Ŝ
nieniu od diagramów sekwencji, diagramy komunikacji nie mog
ą
przekaza
ć
wielu informacji dotycz
ą
cych interakcji, np. bloków
komunikatów. Z drugiej strony jednak prezentuj
ą
rzeczywiste powi
ą
zania
obiektów i ich relacji, co mo
Ŝ
e ułatwi
ć
zrozumienie interakcji.
Bartosz Walter
UML cz. II
15
In
Ŝ
ynieria oprogramowania
UML cz. II (15)
Diagram przegl
ą
du interakcji
Diagram przegl
ą
du interakcji
ł
ą
czy diagramy interakcji w
ogólny diagram czynno
ś
ci, przedstawiaj
ą
cy schemat
przepływu sterowania
:
Czytelnik
:
Czytelnik
:
Bibliotekarz
:
Bibliotekarz
: Katalog
: Katalog
: Ksiazka
: Ksiazka
wypo
Ŝ
ycz
wyszukaj
wypo
Ŝ
ycz
:
Czytelnik
:
Czytelnik
:
Bibliotekarz
:
Bibliotekarz
: Katalog
: Katalog
: Ksiazka
: Ksiazka
rezerwuj
wyszukaj
rezerwuj
[ksi
ąŜ
ka niedost
ę
pna]
[ksi
ąŜ
ka dost
ę
pna]
Diagram przegl
ą
du interakcji (ang. interaction overview diagram) słu
Ŝ
y do
przedstawiania ogólnego przepływu sterowania w interakcjach pomi
ę
dzy
obiektami, korzystaj
ą
c z uproszczonej notacji diagramu czynno
ś
ci. Na
jednym diagramie pokazany jest przepływ sterowania pomi
ę
dzy
interakcjami pokazanymi w postaci innych diagramów, np. sekwencji.
Diagram ten mo
Ŝ
e korzysta
ć
z wi
ę
kszo
ś
ci elementów obecnych na
diagramach czynno
ś
ci: punktu decyzyjnego, p
ę
tli, rozwidlenia i
synchronizacji, etc.
Bartosz Walter
UML cz. II
16
In
Ŝ
ynieria oprogramowania
UML cz. II (16)
Diagram uwarunkowa
ń
czasowych
Diagram uwarunkowa
ń
czasowych
koncentruje si
ę
na
zale
Ŝ
no
ś
ciach czasowych w interakcji pomi
ę
dzy grup
ą
obiektów
B
ib
lio
te
k
a
rz
C
z
y
te
ln
ik
re
z
e
rw
a
c
ja
w
e
ry
fi
k
a
c
ja
re
z
e
rw
a
c
ja
ro
z
ł
ą
c
z
{ 1 min }
Diagramy uwarunkowa
ń
czasowych (ang. timing diagrams) s
ą
specjaln
ą
form
ą
diagramów interakcji przeznaczon
ą
niemal wył
ą
cznie do
prezentowania zale
Ŝ
no
ś
ci zwi
ą
zanych z czasem wykonywania operacji
przez obiekt lub grup
ę
obiektów. Linia czasu jest reprezentowana przez
poziom
ą
o
ś
diagramu, natomiast o
ś
pionowa przedstawia kolejne obiekty
uczestnicz
ą
ce w interakcji oraz ich zmieniaj
ą
ce si
ę
stany wewn
ę
trzne.
Odległo
ś
ci pomi
ę
dzy momentami zmian stanów wyznaczaj
ą
uwarunkowania czasowe.
Diagram ten ma du
Ŝ
e znaczenie w modelowaniu systemów czasu
rzeczywistego.
Bartosz Walter
UML cz. II
17
In
Ŝ
ynieria oprogramowania
UML cz. II (17)
Diagram stanu
Diagram stanu
reprezentuje zachowanie obiektu o
sko
ń
czonej liczbie stanów i zdefiniowanych przej
ś
ciach
mi
ę
dzy nimi
Nabyta
Dost
ę
pna
Wypo
Ŝ
yczona
Zniszczona
Zgubiona
wypo
Ŝ
yczenie[ zarezerwowana ]
wypo
Ŝ
yczenie[ nie zarezerwowana ]
przegl
ą
d[ stan < 10% ] / dost
ę
pna = false ^zablokuj w katalogu
zwrot
zagubiebie[ time > do kiedy + 3 mies ]
przedłu
Ŝ
enie[ liczba przedłu
Ŝ
e
ń
< 3 ] / data oddania = teraz + 3 tygodnie
przegl
ą
d[ stan < 10% ] / dost
ę
pna = false ^zablokuj w katalogu
Diagramy stanu (ang. state machine diagram) reprezentuj
ą
zachowanie
systemu lub jego elementu (zwykle klasy), a w szczególno
ś
ci zmiany tego
zachowania.
Podstawowymi elementami diagramu s
ą
stany obiektu poł
ą
czone
strzałkami przej
ść
. Obiekt, reaguj
ą
c na nadchodz
ą
ce zdarzenia, je
Ŝ
eli
spełnione s
ą
okre
ś
lone warunki, zmienia swój stan i poło
Ŝ
enie na
diagramie stanu.
Bartosz Walter
UML cz. II
18
In
Ŝ
ynieria oprogramowania
UML cz. II (18)
Stan
Stan
jest etapem cyklu
Ŝ
ycia obiektu. Obiekt przebywaj
ą
cy w
danym stanie spełnia okre
ś
lony warunek.
entry
: w momencie wej
ś
cia do stanu
do
: wewn
ą
trz stanu
exit
: w momencie wyj
ś
cia ze stanu
event
: w momencie nadej
ś
cia
zdarzenia
Dost
ę
pna
entry/ rejestracja
do/ ^przegl
ą
d stanu
event inwentaryzacja/ zablokuj
Pojedynczy stan reprezentuje moment w zachowaniu obiektu, w którym
pewien warunek jest prawdziwy.
Stany s
ą
reprezentowane przez prostok
ą
ty z zaokr
ą
glonymi naro
Ŝ
nikami.
Ka
Ŝ
dy stan ma swoj
ą
nazw
ę
.
Ze stanem mog
ą
by
ć
zwi
ą
zane pewne akcje, wykonywane w okre
ś
lonym
momencie:
•entry: jest akcj
ą
wykonywan
ą
w momencie gdy obiekt przyjmuje dany
stan; akcja ta jest wykonywana jeden raz i niepodzielnie
•do: jest akcj
ą
wykonywan
ą
nieprzerwanie w czasie, gdy obiekt przebywa
w tym stanie
•exit: oznacza (analogicznie do entry) moment opuszczenia stanu;
podobnie, akcja taka jest wykonywana tylko raz.
•event: reprezentuje akcj
ę
wykonywan
ą
w momencie nadej
ś
cia zdarzenia
okre
ś
lonego typu
Wykonanie ka
Ŝ
dej z tych akcji mo
Ŝ
e równie
Ŝ
generowa
ć
zdarzenie.
Bartosz Walter
UML cz. II
19
In
Ŝ
ynieria oprogramowania
UML cz. II (19)
Pseudostany
Diagram zawiera tak
Ŝ
e grup
ę
stanów niezwi
ą
zanych z
dziedzin
ą
zastosowa
ń
, tzw.
pseudostanów
Nowa
Otwarta
Zamkni
ę
ta
Usuni
ę
ta
[ liczba < 4 ]
[ specjalna zgoda ]
[ liczba >=4 ]
/ sprawd
ź
dost
ę
pno
ść
synchronizacja
stan ko
ń
cowy
stan pocz
ą
tkowy
decyzja
Obok stanów reprezentuj
ą
cych własno
ś
ci wynikaj
ą
ce z dziedziny
zastosowa
ń
(np. Dost
ę
pna czy Wypo
Ŝ
yczona w przypadku Ksi
ąŜ
ki), UML
definiuje grup
ę
innych stanów pomocniczych, które pozwalaj
ą
na
łatwiejsze modelowanie rozmaitych maszyn stanowych. S
ą
to tzw.
pseudostany:
•pocz
ą
tkowy, który reprezentuje obiekt w momencie jego utworzenia.
Ka
Ŝ
dy diagram stanu mo
Ŝ
e zawiera
ć
tylko jeden taki stan. Do stanu
pocz
ą
tkowego nie dochodz
ą
Ŝ
adne przej
ś
cia.
•ko
ń
cowy, który reprezentuje usuni
ę
cie obiektu z systemu. Stan ten jest
opcjonalny (nie wszystkie obiekty s
ą
usuwane), w systemie tak
Ŝ
e mo
Ŝ
e
wyst
ę
powa
ć
wiele ró
Ŝ
nych stanów ko
ń
cowych. Ze stanów ko
ń
cowych nie
mo
Ŝ
na przej
ść
do innych stanów.
•decyzja, przedstawiaj
ą
ca wybór pomi
ę
dzy dwiema warto
ś
ciami
logicznymi pewnego wyra
Ŝ
enia. Warto zauwa
Ŝ
y
ć
,
Ŝ
e odpowiednio
korzystaj
ą
c z warunków przej
ść
mo
Ŝ
na pomin
ąć
ten pseudostan, jednak
cz
ę
sto jego u
Ŝ
ycie zwi
ę
ksza czytelno
ść
modelu
•zł
ą
czenie/rozwidlenie – powoduje synchronizacj
ę
stanów (wszystkie
dochodz
ą
ce do niego przej
ś
cia musz
ą
by
ć
wykonane)
•historia (reprezentowana przez literk
ę
H umieszczon
ą
w okr
ę
gu
wewn
ą
trz stanu) – zapewnia mo
Ŝ
liwo
ść
zapami
ę
tania poprzedniego stanu
obiektu i przywrócenie go.
Bartosz Walter
UML cz. II
20
In
Ŝ
ynieria oprogramowania
UML cz. II (20)
Przej
ś
cie mi
ę
dzy stanami
Przej
ś
cie
powoduje zmian
ę
stanu i wykonanie pewnych akcji
Dost
ę
pna
Zniszczona
przegl
ą
d[ stan < 10% ] / dost
ę
pna = false ^zablokuj w katalogu
wyzwalacz [dozór] / akcja ^ wysyłane zdarzenia
Zdarzenie
wyzwalaj
ą
ce przej
ś
cie
Warunek pozwalaj
ą
cy
na przej
ś
cie
Akcja wykonywana w
momencie przej
ś
cia
Wysyłane zdarzenia
Stany s
ą
powi
ą
zane ze sob
ą
przej
ś
ciami. Przej
ś
cia definiuj
ą
warunki,
jakie musz
ą
zaistnie
ć
, aby obiekt zmienił swój stan z
ź
ródłowego na
docelowy. Formalnie opis przej
ś
cia składa si
ę
z czterech elementów:
•wyzwalacza (ang. trigger) – zdarzenia, które mo
Ŝ
e spowodowa
ć
przej
ś
cie i zmian
ę
stanu
•dozoru (ang. guard condition) – warunku, jaki musi by
ć
spełniony, aby
przej
ś
cie zostało wykonane; warunek ten jest ewaluowany w momencie
pojawienia si
ę
wyzwalacza
•akcji (ang. action) – operacji wykonywanej w momencie przej
ś
cia ze
stanu do stanu; nawet je
Ŝ
eli akcja przej
ś
cia jest zło
Ŝ
ona z wielu akcji
elementarnych, jest ona wykonywana niepodzielnie
•zdarzenia (ang. event) – wysyłanego w momencie wykonania przej
ś
cia.
W podanym przykładzie, reprezentuj
ą
cym dwa stany klasy Ksi
ąŜ
ka,
zdarzenie Przegl
ą
d mo
Ŝ
e spowodowa
ć
zmian
ę
stanu z Dost
ę
pnej na
Zniszczon
ą
, je
Ŝ
eli jej stan zostanie oceniony na mniej ni
Ŝ
10%. Efektem
przej
ś
cia b
ę
dzie zmiana atrybutu dost
ę
pna na false oraz wysłanie
zdarzenia zablokowania ksi
ąŜ
ki w katalogu.
Bartosz Walter
UML cz. II
21
In
Ŝ
ynieria oprogramowania
UML cz. II (21)
Stany zło
Ŝ
one
Stany zło
Ŝ
one
posiadaj
ą
wewn
ę
trzn
ą
maszyn
ę
stanów.
Wej
ś
cie do stanu jest jej stanem pocz
ą
tkowym, a wyj
ś
cie –
ko
ń
cowym.
Otwarta
Wyszukanie
Aktualizacja
Weryfikacja
Wyszukanie
Aktualizacja
Weryfikacja
[ znaleziono ]
[ ju
Ŝ
zarezerwowana ]
[ nie zarezerwowana ]
[ nie znaleziono ]
Dotychczas była mowa o stanach prostych. S
ą
one niepodzielne –
znalezienie si
ę
obiektu w takim stanie ma zawsze taki sam efekt i pomija
ewentualne zmieniaj
ą
ce si
ę
zewn
ę
trzne okoliczno
ś
ci.
W niektórych sytuacjach wewn
ą
trz stanu mo
Ŝ
na jednak
Ŝ
e wyró
Ŝ
ni
ć
podstany. Innymi słowy, wewn
ą
trz stanu znajduje si
ę
inny diagram stanu.
Diagram podstanów jest przetwarzany w sposób zbli
Ŝ
ony do zwykłego
diagramu stanu. Jednak w ogólnym przypadku stan zło
Ŝ
ony dopuszcza
tak
Ŝ
e istnienie podstanów współbie
Ŝ
nych, co oznacza,
Ŝ
e obiekt znajduj
ą
c
si
ę
w jednym stanie jednocze
ś
nie znajduje si
ę
w kilku podstanach.
Wówczas podstany równoległe tworz
ą
niezale
Ŝ
ne regiony wewn
ą
trz stanu
zewn
ę
trznego, w których przej
ś
cia nast
ę
puj
ą
niezale
Ŝ
nie od siebie.
Wej
ś
cie do stanu powoduje tak
Ŝ
e wej
ś
cie wszystkich podstanów
pocz
ą
tkowych we wszystkich regionach. Nast
ę
pnie przej
ś
cia s
ą
realizowane równolegle i niezale
Ŝ
nie we wszystkich regionach, a
Ŝ
do
podstanów ko
ń
cowych. Przej
ś
cie do stanu ko
ń
cowego we wszystkich
regionach powoduje uruchomienie zdarzenia zako
ń
czenia stanu i
skojarzonych z nim wyzwalaczy.
Bartosz Walter
UML cz. II
22
In
Ŝ
ynieria oprogramowania
UML cz. II (22)
Stany zło
Ŝ
one
Stany zło
Ŝ
one
posiadaj
ą
wewn
ę
trzn
ą
maszyn
ę
stanów.
Wej
ś
cie do stanu jest jej stanem pocz
ą
tkowym, a wyj
ś
cie –
ko
ń
cowym.
Otwarta
Wyszukanie
Aktualizacja
Weryfikacja
Wyszukanie
Aktualizacja
Weryfikacja
[ znaleziono ]
[ ju
Ŝ
zarezerwowana ]
[ nie zarezerwowana ]
[ nie znaleziono ]
Przykład dotyczy stanu Otwarta, reprezentuj
ą
cego otwarty stan
Rezerwacji ksi
ąŜ
ek. Rezerwacja mo
Ŝ
e obj
ąć
do 4 ksi
ąŜ
ek jednocze
ś
nie.
Stan Rezerwacji pozostaje otwarty w trakcie dodawania kolejnych
ksi
ąŜ
ek, jednak wyró
Ŝ
niono w nim podstany: Wyszukanie informacji o
ksi
ąŜ
ce, Weryfikacj
ę
, czy danej ksi
ąŜ
ki ju
Ŝ
wcze
ś
niej nie zarezerwowano
oraz Aktualizacj
ę
danych Rezerwacji. Wszystkie podstany prowadz
ą
do
opuszczenia stanu przez Rezerwacj
ę
, co jest zwi
ą
zane np. z prób
ą
dodania do niej nowej ksi
ąŜ
ki.
Bartosz Walter
UML cz. II
23
In
Ŝ
ynieria oprogramowania
UML cz. II (23)
Przykład
Nabyta
Dost
ę
pna
Wypo
Ŝ
yczona
Zniszczona
Zgubiona
wypo
Ŝ
yczenie[ zarezerwowana ]
wypo
Ŝ
yczenie[ nie zarezerwowana ]
przegl
ą
d[ stan < 10% ] / dost
ę
pna = false ^zablokuj w katalogu
zwrot
zagubiebie[ time > do kiedy + 3 mies ]
przedłu
Ŝ
enie[ liczba przedłu
Ŝ
e
ń
< 3 ] / data oddania = teraz + 3 tygodnie
przegl
ą
d[ stan < 10% ] / dost
ę
pna = false ^zablokuj w katalogu
Diagram ten obejmuje przykładowy cykl
Ŝ
ycia obiektu Ksi
ąŜ
ka w
bibliotece. Ksi
ąŜ
ka zostaje Nabyta, a nast
ę
pnie (po rejestracji) staje si
ę
Dost
ę
pna. Jej Wypo
Ŝ
yczenie (niezale
Ŝ
nie od tego, czy była rezerwowana,
czy nie), przeprowadza j
ą
do stanu Wypo
Ŝ
yczonej. Ksi
ąŜ
ka mo
Ŝ
e
pozosta
ć
w tym stanie np. wskutek przedłu
Ŝ
enia (warunkiem jest,
Ŝ
e
liczba przedłu
Ŝ
e
ń
nie przekroczyła 3) – wówczas data oddania jest
przesuwana o 3 tygodnie. Zarówno ze stanu Dost
ę
pno
ś
ci, jak i
Wypo
Ŝ
yczenia ksi
ąŜ
ka mo
Ŝ
e przej
ść
do stanu Zniszczenia, o ile wskutek
zdarzenia Przegl
ą
d jej stan zostanie oceniony na mniej ni
Ŝ
10%. Je
Ŝ
eli tak
si
ę
stanie, atrybut Ksi
ąŜ
ki dost
ę
pna otrzymuje warto
ść
false oraz
wysyłane jest zdarzenie zablokowania dost
ę
pno
ś
ci Ksi
ąŜ
ki w katalogu.
Wypo
Ŝ
yczona ksi
ąŜ
ka, której nie oddano w terminie 3 miesi
ę
cy od terminu
zwrotu, jest uwa
Ŝ
ana za Zagubion
ą
.
Bartosz Walter
UML cz. II
24
In
Ŝ
ynieria oprogramowania
UML cz. II (24)
Diagram czynno
ś
ci
Diagramy czynno
ś
ci
przedstawiaj
ą
akcje wykonywane
w systemie oraz wynikaj
ą
ce z nich zmiany stanów.
wypełnienie
karty
wyszukanie
Rezerwacja
zło
Ŝ
ona
[ nie znaleziono ]
[ znaleziono ]
akcja
stan
stan pocz
ą
tkowy
Diagramy czynno
ś
ci (ang. activity diagrams) prezentuj
ą
przepływ
sterowania w systemie zwi
ą
zany z wykonaniem pewnej funkcji. Przepływy
ł
ą
cz
ą
czynno
ś
ci wykonywane przez poszczególne obiekty i stany
obiektów, w których znajduj
ą
si
ę
po wykonaniu czynno
ś
ci.
Wygl
ą
d tych diagramów przypomina diagramy stanu (w UML 1.x były to
diagramy pokrewne, blisko zwi
ą
zane ze sob
ą
), jednak ich przeznaczenie
jest inne. Diagramy stanu skupiaj
ą
si
ę
– jak nazwa wskazuje – na
stanach, a akcje zwi
ą
zane z ich zmian
ą
s
ą
elementem dodatkowym. W
diagramach czynno
ś
ci jest odwrotnie: akcje s
ą
na pierwszym planie, a
zmiany stanów s
ą
efektem ich wykonania. Dlatego diagramy czynno
ś
ci
dobrze nadaj
ą
si
ę
do opisu przepływu sterowania pomi
ę
dzy obiektami
(szczególnie w przypadku przetwarzania współbie
Ŝ
nego) oraz przepływu
danych pomi
ę
dzy nimi.
Diagram, podobnie jak diagram stanu, mo
Ŝ
e posiada
ć
punkt startowy i i
dowoln
ą
liczb
ę
stanów ko
ń
cowych. Najwa
Ŝ
niejszym jego elementem s
ą
akcje, reprezentowane przez prostok
ą
ty z zaokr
ą
glonymi naro
Ŝ
nikami
oraz przej
ś
cia (łuki) przedstawiaj
ą
ce przepływ sterowania. Łuki mog
ą
by
ć
opatrzone warunkami dozoru, które decyduj
ą
o wykonaniu przej
ś
cia oraz
zdarzeniami, które s
ą
generowane w momencie gdy przej
ś
cie jest
wykonywane. Diagramy czynno
ś
ci zawieraj
ą
tak
Ŝ
e stany, w jakich mo
Ŝ
e
znale
źć
si
ę
okre
ś
lony obiekt po wykonaniu akcji oraz elementy decyzyjne
czy synchronizuj
ą
ce.
Bartosz Walter
UML cz. II
25
In
Ŝ
ynieria oprogramowania
UML cz. II (25)
Diagram czynno
ś
ci
Diagramy czynno
ś
ci
przedstawiaj
ą
akcje wykonywane
w systemie oraz wynikaj
ą
ce z nich zmiany stanów.
wypełnienie
karty
wyszukanie
Rezerwacja
zło
Ŝ
ona
[ nie znaleziono ]
[ znaleziono ]
akcja
stan
stan pocz
ą
tkowy
Umieszczanie akcji w torach (ang. swimlanes) pozwala na pogrupowanie
ich według pewnego kryterium. Mo
Ŝ
e nim by
ć
np. obiekt, który wykonuje
dan
ą
akcj
ę
lub inna wspólna cecha akcji.
Obiekty umieszczone na diagramach czynno
ś
ci s
ą
podporz
ą
dkowane
przepływowi sterowania i reprezentuj
ą
parametry wej
ś
ciowe lub wyniki
działania czynno
ś
ci.
Bartosz Walter
UML cz. II
26
In
Ŝ
ynieria oprogramowania
UML cz. II (26)
Przykład
pusta
wyszukaj
lokalnie
poł
ą
cz
analiza
wyszukaj
zdalnie
wydawnictwo :
Wydawnictwo
[ true ]
[ false ]
katalog zdalny
katalog lokalny
czytelnik
Na powy
Ŝ
szym slajdzie przedstawiono przykład czynno
ś
ci zwi
ą
zanych z
wyszukaniem informacji w katalogu przez czytelnika.
Czytelnik jednocze
ś
nie uruchamia proces wykonywania lokalnego (w
katalogu lokalnym) i zdalnego (w katalogu zdalnym), które s
ą
realizowane
współbie
Ŝ
nie. Po zako
ń
czeniu obu operacji nast
ę
puje sprawdzenie, czy
lista wyników jest pusta. Je
Ŝ
eli tak, wówczas proces wyszukiwania jest
zako
ń
czony, w przeciwnym przypadku lista jest ł
ą
czona z dodatkowymi
informacjami prezentowanymi czytelnikowi, analizowana i zwracana
inicjatorowi przeszukiwania
Bartosz Walter
UML cz. II
27
In
Ŝ
ynieria oprogramowania
UML cz. II (27)
Mechanizm rozszerze
ń
UML
UML posiada
standardowy mechanizm rozszerze
ń
.
Pozwala on na obj
ę
cie nowych dziedzin zastosowa
ń
bez
potrzeby modyfikacji j
ę
zyka lub implementuj
ą
cych go
narz
ę
dzi.
Mechanizm obejmuje trzy elementy
• profile
• stereotypy
• metki
UML słu
Ŝ
y obecnie do opisu modeli w wielu dziedzinach zastosowa
ń
. Aby
umo
Ŝ
liwi
ć
obejmowanie kolejnych dziedzin bez potrzeby modyfikowania
lub rozszerzania j
ę
zyka, wprowadzono do niego mechanizm rozszerze
ń
.
Pozwala on redefiniowa
ć
poj
ę
cia i elementy oraz doprecyzowywa
ć
ich
znaczenie tak, aby odpowiadały potrzebom nowego obszaru zastosowa
ń
.
W skład mechanizmu rozszerze
ń
wchodz
ą
trzy elementy:
•profile, zawieraj
ą
ce rozszerzenia (stereotypy i metki) do modelowania
okre
ś
lonych dziedzin
•stereotypy, zmieniaj
ą
ce znaczenie poszczególnych elementów
•metki, opisuj
ą
ce dodatkowe wła
ś
ciwo
ś
ci elementów
Bartosz Walter
UML cz. II
28
In
Ŝ
ynieria oprogramowania
UML cz. II (28)
Profile UML
Profile UML
s
ą
narzeczami j
ę
zyka UML przystosowanymi do
modelowania pewnej dziedziny zastosowa
ń
.
Profil obejmuje zdefiniowane stereotypy, metki, ograniczenia.
W
ś
ród tych mechanizmów najwa
Ŝ
niejszym s
ą
profile, zawieraj
ą
ce
kompletny i spójny zestaw elementów dedykowanych do modelowania
okre
ś
lonej dziedziny, np. systemów czasu rzeczywistego, baz danych,
logiki biznesowej etc. Zdefiniowane i zaakceptowane profile pozwalaj
ą
unikn
ąć
kaskady ró
Ŝ
norodnych rozszerze
ń
dokonywanych przez
u
Ŝ
ytkowników na własn
ą
r
ę
k
ę
, co znacznie zmniejszało czytelno
ść
i
komunikatywno
ść
modeli.
Profile zawieraj
ą
zdefiniowany zestaw stereotypów i metek, z których
powinni korzysta
ć
analitycy działaj
ą
cy w dziedzinie zastosowa
ń
profilu. Na
przykład, profil do modelowania ziaren EJB definiuje stereotypy
EJBSessionBean, EJBPrimaryKey, EJBHomeInterface czy
EJBCreateMethod, oznaczaj
ą
ce odpowiednio klas
ę
ziarna sesyjnego,
atrybut b
ę
d
ą
cy kluczem podstawowym ziarna encyjnego, interfejs
domowy ziarna oraz metod
ę
tworz
ą
c
ą
instancj
ę
interfejsu ziarna.
Stereotyp EJBSessionBean definiuje m.in. metk
ę
EJBTransType,
natomiast ka
Ŝ
da operacja mo
Ŝ
e posiada
ć
metk
ę
EJBRoleNames,
okre
ś
laj
ą
c
ą
role, które musi odgrywa
ć
wywołuj
ą
cy t
ę
operacj
ę
element.
Bartosz Walter
UML cz. II
29
In
Ŝ
ynieria oprogramowania
UML cz. II (29)
Stereotypy
Stereotypy
słu
Ŝą
do zmieniania lub doprecyzowania
semantyki elementów modelu. Dzi
ę
ki nim mo
Ŝ
na dokładnie
okre
ś
li
ć
ich rol
ę
w systemie.
Stereotypy s
ą
reprezentowane przez ikon
ę
lub słowo
kluczowe uj
ę
te w "łapki":
«stereotyp»
RejestratorCzytelników
utwórz konto()
zmie
ń
dane()
<<EJBSession>>
RejestratorCzytelników
utwórz konto()
zmie
ń
dane()
S
Ró
Ŝ
ne sposoby przedstawienia stereotypu «EJBSession» w
klasie RejestratorCzytelników
Kolejnym elementem jest stereotyp, który historycznie był podstawowym
narz
ę
dziem rozszerzania i modyfikowania UMLa. Stereotypy dodaj
ą
do
znanych ju
Ŝ
elementów: klas, atrybutów, asocjacji, now
ą
semantyk
ę
. W
UML 1.x stereotypami były wszelkie dekoracje zmieniaj
ą
ce znaczenie
wybranego elementu. Wersja ta zawierała tak
Ŝ
e spor
ą
grup
ę
zdefiniowanych stereotypów standardowych. W UML 2.0 nazw
ę
t
ę
zarezerwowano wył
ą
cznie dla dekoracji wchodz
ą
cych w skład profili,
natomiast pozostałe u
Ŝ
ycia tego słowa zostały przemianowane na słowa
kluczowe. Stereotypy posiadaj
ą
specjaln
ą
notacj
ę
, polegaj
ą
c
ą
na
umieszczeniu nazwy stereotypu w specjalnych znakach guillemets
(«stereotyp»). Stereotypy, szczególnie te najcz
ęś
ciej u
Ŝ
ywane, posiadaj
ą
tak
Ŝ
e własn
ą
ikon
ę
, która jest umieszczana wewn
ą
trz stereotypowanego
elementu lub całkowicie go zast
ę
puje.
Bartosz Walter
UML cz. II
30
In
Ŝ
ynieria oprogramowania
UML cz. II (30)
Metki
Metki
(ang. tagged values) pozwalaj
ą
doł
ą
czy
ć
do elementu
dodatkowe wła
ś
ciwo
ś
ci
• Metki posiadaj
ą
posta
ć
par
klucz : warto
ść
• Stereotypy i profile definiuj
ą
własne zestawy metek
• Metki s
ą
zapisywane w postaci notatki doł
ą
czonej do
elementu, którego dotycz
ą
RejestratorCzytelników
utwórz konto() : void
zmie
ń
dane() : void
<<EJBSession>>
EJBTransType : container
metka EJBTransType
okre
ś
la sposób
zarz
ą
dzania
transakcjami w ziarnie
EJB
Wreszcie, na najni
Ŝ
szym poziomie znajduj
ą
si
ę
tzw. metki (ang. tagged
values), pozwalaj
ą
ce opisywa
ć
dodatkowe wła
ś
ciwo
ś
ci elementu, które
nie zostały przewidziane w UMLu. Metki s
ą
zapisywane w postaci par
klucz-warto
ść
w nawiasach klamrowych i doł
ą
czane do opisywanych
elementów w postaci notatek. W wi
ę
kszo
ś
ci narz
ę
dzi s
ą
one jednak
zapisywane w postaci metadanych, zawartych wewn
ą
trz elementu,
poniewa
Ŝ
tak łatwiej je przetwarza
ć
. Metki, podobnie jak stereotypy, s
ą
zasadniczo definiowane wewn
ą
trz profili (i znajduj
ą
cych si
ę
w nich
stereotypów), jednak istnieje tak
Ŝ
e mo
Ŝ
liwo
ść
ich definiowania przez
u
Ŝ
ytkowników.
Najprostszym przykładem metki mo
Ŝ
e by
ć
informacja o autorze modelu
{autor = "Jan Kowalski"}.
Bartosz Walter
UML cz. II
31
In
Ŝ
ynieria oprogramowania
UML cz. II (31)
Przykład: modelowanie baz danych
KLIENT
ID_KLIENTA : INTEGER
NAZWISKO : VARCHAR(8)
ADRES : VARCHAR(7)
DATA_ZGLOSZENIA : DATE
MIEJSC E_DZIALALNOSCI
ID_MIEJSCA : INTEGER
KOD_POCZTOWY : VARCHAR(6)
MIASTO : VARCHAR(30)
ULICA : VARCHAR(30)
DOM : VARCHAR(9)
LOKAL : VARCHAR(5)
ID_KLIENTA : INTEGER
0..*
1
<<Non-Identifying>>
dziala w
0..*
1
metoda
«constraint»
ograniczenie
atrybut
«FK»
klucz obcy
atrybut
«PK»
klucz podstawowy
klasa
«RelationalTable»
tabela
pakiet
«schema»
schemat
Na powy
Ŝ
szym slajdzie przedstawiono prosty przykład wykorzystania
jednego z profili UML, słu
Ŝą
cego do modelowania danych. Wprawdzie
relacyjne bazy danych posiadaj
ą
własn
ą
notacj
ę
, opart
ą
na diagramach
ERD (Entity Relationship Diagrams), jednak mo
Ŝ
liwo
ść
ich tworzenia w
UMLu jest wa
Ŝ
nym uzupełnieniem jego mo
Ŝ
liwo
ś
ci.
Profil ten definiuje stereotypy, które mo
Ŝ
na umieszcza
ć
na istniej
ą
cych
elementach UML w celu nadania im nowego znaczenia w dziedzinie
projektowania baz danych. Na przykład, schemat bazy danych jest
reprezentowany przez pakiet ze stereotypem schema, tabela jest
modelowana jako klasa ze stereotypem RelationalTable, a jej klucze
podstawowe i obce – jako atrybuty odpowiednio ze stereotypami PK i FK.
Ograniczenia integralno
ś
ciowe wewn
ą
trz relacji s
ą
metodami ze
stereotypem constraint.
Tak opisany schemat danych mo
Ŝ
e by
ć
u
Ŝ
yty do wygenerowania kodu w
j
ę
zyku definicji baz danych (np. SQL DDL), który nast
ę
pnie posłu
Ŝ
y do
utworzenia schematów i tabel zgodnych z nim.
Bartosz Walter
UML cz. II
32
In
Ŝ
ynieria oprogramowania
UML cz. II (32)
OCL
OCL (Object Constraint Language)
jest j
ę
zykiem
formalnego wyra
Ŝ
ania ogranicze
ń
w UML
Własno
ś
ci OCL
• wyra
Ŝ
a dowoln
ą
reguł
ę
logiczn
ą
: warunki wst
ę
pne,
ko
ń
cowe, niezmienniki, wyniki metod etc.
• nie mo
Ŝ
e modyfikowa
ć
modelu, jedynie go sprawdza
ć
• mo
Ŝ
na go zwi
ą
za
ć
z dowolnym elementem modelu (klas
ą
,
operacj
ą
, atrybutem, asocjacj
ą
etc.)
OCL jest formalnym j
ę
zykiem wyra
Ŝ
ania wszelkiego rodzaju ogranicze
ń
obecnych w UMLu. Cho
ć
u
Ŝ
ycie jego nie jest obowi
ą
zkowe (ograniczenia
mo
Ŝ
na równie dobrze specyfikowa
ć
w j
ę
zyku naturalnym), jednak jego
rola w dobie narz
ę
dzi generuj
ą
cych kod z diagramów, b
ę
dzie stale rosła.
Warto pami
ę
ta
ć
,
Ŝ
e OCL jest j
ę
zykiem potrafi
ą
cym jedynie weryfikowa
ć
elementy modelu, ale nie mog
ą
cym na ten model w
Ŝ
aden sposób
wpływa
ć
. Ewaluacja wyra
Ŝ
e
ń
OCL nast
ę
puje w sposób atomiczny
(niepodzielny), nie powoduj
ą
c nigdy zmiany stanu jakiegokolwiek obiektu.
OCL posiada zestaw wbudowanych operatorów, predykatów, ma
mo
Ŝ
liwo
ść
definiowania własnych funkcji, warunków i niezmienników.
Dzi
ę
ki nim mo
Ŝ
liwe jest u
Ŝ
ycie go przy niemal wszystkich elementach
wyst
ę
puj
ą
cych w UML
Bartosz Walter
UML cz. II
33
In
Ŝ
ynieria oprogramowania
UML cz. II (33)
Przykład
M
ąŜ
data
ś
lubu
ś
ona
data
ś
lubu
1
1
1
+
Ŝ
ona
1
+m
ąŜ
po
ś
lubieni
Dziecko
0..n
1
0..n
1
+dziecko
0..n
+matka
1
+dziecko
0..n
+ojciec
1
{matka.dziecko = matka.m
ąŜ
.dziecko}
{ojciec.dziecko = ojciec.
Ŝ
ona.dziecko}
{m
ąŜ
.data
ś
lubu =
Ŝ
ona.data
ś
lubu,
m
ąŜ
.
Ŝ
ona =
Ŝ
ona}
{self.wiek >= 21}
{self.wiek >= 18}
Diagram przedstawia rodzin
ę
. Obiekt klasy M
ąŜ
jest zwi
ą
zany z dokładnie
jednym obiektem klasy
ś
ona. Ka
Ŝ
de z nich jest zwi
ą
zane z obiektami
klasy Dziecko.
Sam rysunek bez ogranicze
ń
mógłby prowadzi
ć
do rozmaitych
interpretacji, tak
Ŝ
e nieprawdziwych. Dlatego wprowadzenie ogranicze
ń
w
OCL pozwala u
ś
ci
ś
li
ć
model.
Relacja pomi
ę
dzy M
ęŜ
em i
ś
on
ą
ma nało
Ŝ
one ograniczenie,
Ŝ
e data
ś
lubu obu obiektów musi by
ć
identyczna, a tak
Ŝ
e nawiguj
ą
c od M
ęŜ
a
poprzez zwi
ą
zany z nim relacj
ą
po
ś
lubieni obiekt
ś
ona, otrzymujemy
uczestnicz
ą
cy w tej relacji obiekt
ś
ona (zatem M
ąŜ
i
ś
ona s
ą
ze sob
ą
zwi
ą
zani relacj
ą
wzajemno
ś
ci).
Ponadto
ś
ona musi mie
ć
wiek powy
Ŝ
ej 18 lat, a M
ąŜ
– 21.
Aby zapewni
ć
,
Ŝ
e dzieci posiadane przez
ś
on
ę
były tak
Ŝ
e dzie
ć
mi M
ęŜ
a,
nało
Ŝ
ono odpowiednie ograniczenia na relacje mi
ę
dzy M
ęŜ
em i Dzieckiem
oraz
ś
on
ą
i Dzieckiem.
Bartosz Walter
UML cz. II
34
In
Ŝ
ynieria oprogramowania
UML cz. II (34)
Wybrane narz
ę
dzia: ArgoUML
ArgoUML
• open source, licencja BSD
• wsparcie dla UML 1.4
• mo
Ŝ
liwo
ść
stałej inspekcji modelu
• synchronizacja modelu z kodem
•
http://argouml.tigris.org
Przykładem darmowego i otwartego narz
ę
dzia do modelowania w UML
jest ArgoUML. Jest to program zaimplementowany w j
ę
zyku Java, który
mo
Ŝ
na uruchomi
ć
na dowolnej platformie programowej wyposa
Ŝ
onej w
interpreter tego j
ę
zyka.
Posiada on wsparcie dla wersji 1.4 UML, natomiast nie ma
zaimplementowanej obsługi
Ŝ
adnego z nowych diagramów, jakie pojawiły
si
ę
w wersji 2.0 j
ę
zyka. Posiada tak
Ŝ
e moduł inspekcji modelu, znajduj
ą
cy
najpopularniejsze bł
ę
dy popełniane przez analityków, zaimplementowane
w postaci reguł. Umo
Ŝ
liwia tak
Ŝ
e synchronizacj
ę
kodu z modelem dla
wybranych j
ę
zyków programowania.
Bartosz Walter
UML cz. II
35
In
Ŝ
ynieria oprogramowania
UML cz. II (35)
Wybrane narz
ę
dzia: Rational
Rational Rose, Rational Software Modeler
• narz
ę
dzia komercyjne
• integracja z innymi narz
ę
dziami Rational
• wsparcie dla UML 1.x (Rose) i UML 2.0 (Modeler)
• wsparcie dla modelowania wybranych dziedzin i
technologii
• modelowanie biznesowe
• synchronizacja modelu z kodem
•
http://www-306.ibm.com/software/rational/
Na drugim biegunie znajduj
ą
si
ę
narz
ę
dzia firmy Rational (obecnie
Rational Division wewn
ą
trz IBMa). Klasycznym narz
ę
dziem do
modelowania jest Rational Rose, natomiast nowsz
ą
lini
ę
produktow
ą
reprezentuje Rational Software Modeler. Ten ostatni produkt jest oparty
na
ś
rodowisku Eclipse i posiada wsparcie dla wersji 2.0 UML.
W
ś
ród mo
Ŝ
liwo
ś
ci obu
ś
rodowisk warto wymieni
ć
mo
Ŝ
liwo
ść
wykorzystania profili j
ę
zyka UML w postaci wtyczek dedykowanych do
rozmaitych technologii (modelowania danych, modelowania biznesowego
etc.). Narz
ę
dzia te łatwo integruj
ą
si
ę
z innymi produktami Rational i IBM,
posiadaj
ą
jednak tak
Ŝ
e mo
Ŝ
liwo
ść
współpracy z wybranymi innymi
narz
ę
dziami.
Bartosz Walter
UML cz. II
36
In
Ŝ
ynieria oprogramowania
UML cz. II (36)
Podsumowanie
• Diagramy komponentów i wdro
Ŝ
enia przedstawiaj
ą
logiczn
ą
i fizyczn
ą
struktur
ę
podsystemów
• Diagramy interakcji słu
Ŝą
do opisu komunikacji
pomi
ę
dzy obiektami
• Diagramy czynno
ś
ci definiuj
ą
algorytmy realizacji
funkcji, a diagramy stanu – zmian
ę
zachowania
obiektów
• Mechanizm rozszerze
ń
UML pozwala na
obejmowanie nowych obszarów zastosowa
ń
• OCL jest j
ę
zykiem formalnego opisu ogranicze
ń
Wykład zako
ń
czył krótkie wprowadzenie do modelowania z
wykorzystaniem j
ę
zyka UML. Przedstawiono najwa
Ŝ
niejsze rodzaje
diagramów i ich mo
Ŝ
liwo
ś
ci wyrazu, a tak
Ŝ
e rozszerzone mo
Ŝ
liwo
ś
ci
j
ę
zyka.