Io 6 Język UML, cz II

background image

Bartosz Walter

UML cz. II

1

In

ż

ynieria oprogramowania

UML cz. II

Prowadz

ą

cy:

Bartosz Walter

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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».

background image

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.

background image

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

ć

.

background image

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).

background image

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.

background image

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)

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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

ą

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.

background image

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.

background image

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.

background image

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.

background image

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

ą

.

background image

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.

background image

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.

background image

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

background image

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

background image

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.

background image

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

ż

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.

background image

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"}.

background image

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.

background image

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

background image

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.

background image

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.

background image

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.

background image

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.


Wyszukiwarka

Podobne podstrony:
Io 5 Język UML, cz I
socjologia cz II
BADANIA DODATKOWE CZ II
Wykład 5 An wsk cz II
AUTOPREZENTACJA cz II Jak w
Podstawy Pedagogiki Specjalnej cz II oligo B
jezyk C skrypt cz 1
Język Angielski Poziom II Sprawdziany Kompetencji dla klas IV VI
J Poreda Ewangelia zdrowia, cz II
mmgg, Studia PŁ, Ochrona Środowiska, Chemia, fizyczna, laborki, wszy, chemia fizyczna cz II sprawka
!Spis, ☆☆♠ Nauka dla Wszystkich Prawdziwych ∑ ξ ζ ω ∏ √¼½¾haslo nauka, hacking, Hack war, cz II
UE szczepienia i racjonalne stosowanie antybiotyków, Zdrowie publiczne, W. Leśnikowska - Ścigalska -
Dziady cz. II jako dramat, j.polski - gimnazjum

więcej podobnych podstron