E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 1

Projektowanie systemów

informacyjnych

Ewa Stemposz, Kazimierz Subieta

Instytut Podstaw Informatyki PAN,
Warszawa

Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa

Wykład 7

Model obiektowy (4)

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 2

Zagadnienia

Dziedziczenie asocjacji
Asocjacje pochodne
Redukcja liczności
Role wielowartościowe
Trochę więcej o agregacji
Agregacja rekursywna
Trochę więcej o asocjacji kwalifikowanej
Trochę więcej o mechanizmach rozszerzalności

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 3

Dziedziczenie asocjacji (1)

K1

K2

K3

K4

K

a

a

K1

K2

K3

K

a

Aby obie asocjacje a (diagram po lewej stronie) mogły zostać
zastąpione jedną asocjacją a poprowadzoną od nadklasy K1 do klasy K
(diagram po prawej stronie), asocjacje a z diagramu po lewej stronie
powinny spełniać następujące warunki:

 powinny mieć tę samą semantykę,

 powinny mieć tę samą strukturę,

 byłoby dobrze, gdyby asocjacja a łączyła klasę K z wszystkimi podklasami klasy K1 (?).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 4

Dziedziczenie asocjacji (2)

Referat

{abstract}

tytuł

autorzy[1..*]

Zaproszony Zwykły

ocena

Sesja

nazwa

data

Termin

godz.

Termin

godz.

wygłaszany

1..*

0..1

wygłaszany

1

0..1

Termin

godz.

0..1

1..*

Wykorzystanie faktu, że asocjacje są dziedziczone
spowodowało, że część informacji nie została
przeniesiona na nowy diagram

(zmiany oznaczono

czerwonym kolorem

). Aby zapobiec utracie

informacji, do diagramu należałoby wprowadzić
odpowiednie ograniczenia.

wygłaszany

Nazwa dla klasy asocjacji ?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 5

Asocjacje pochodne

1) Jeśli Osoba mieszka w
mieście, w którym pracuje,
to

jedna

z

asocjacji:

mieszka lub znajduje się
albo

powinna

zostać

oznaczona jako pochodna
albo powinna być usunięta
z diagramu.

Osoba

Miasto

Firma

mieszka

1

1..*

znajduje się

1

1..*

1..*

1

0..1 ?

pracodawca

2)

Jeśli

liczność

roli

pracodawca zmienimy na
0..1, to asocjacja mieszka
nie

będzie

pochodna,

ponieważ

nie

dla

wszystkich

obiektów

powiązania mieszka będą
mogły być wydedukowane.
Podobnie, jeśli liczność roli
pracownik zmienimy na *,
to asocjacja znajduje się
nie będzie pochodna.

Możliwe asocjacje pochodne:

/mieszka lub /znajduje się

pracownik

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 6

Redukcja liczności

K1

K

a1

a2

1

y

K2

1

x

K1

K2

K

a1

a2

x

y

Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu

Przykład:

Zatrudnienie

stanowisko

pensja

Osoba

1..*

Firma

*

Osoba

*

Firma

1..*

Zatrudnienie

stanowisko

pensja

1

1

/pracodawca

1..*

*

gdzie: x, y oznaczają liczności wiele

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 7

Role wielowartościowe (1)

Rola wielowartościowa to taka rola, dla której górna granica liczności jest większa od 1.

K1

K2

r1

r2

W UML przyjmuje się domyślnie, że:

 zbiór obiektów, opisywany daną rolą, jest
nieuporządkowany,

 dany obiekt pojawia się tylko jeden raz w
w zbiorze obiektów opisanym rolą,

 powyższe reguły mogą zostać zmienione
dzięki ograniczeniom {ordered}, {bag} i
stereotypowi «history ».

*

1

Rola r2 jest tu rolą wielowartościową.

Uwaga:

W sensie dosłownym, liczności
obu końców asocjacji oznaczają
liczności obu ról.

:K1

:K1

:K2

:K2

:K2

a

a

a

K1

K2

1..2

a

*

{ordered}

Ograniczenie

{ordered}

pozwala na uporządkowanie
zbioru obiektów opisanego
daną rolą.

a

źle

dobrze

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 8

Role wielowartościowe (2)

Między dwoma tymi samymi obiektami może wystąpić więcej niż jedno
powiązanie (np. jak na diagramie poniżej), ale nie mogą to być – jak
poprzednio – powiązania o tej samej semantyce.

Osoba

Firma

pracuje

jest dyrektorem

0..1

0..1

1

*

Nowak : Osoba

IBM : Firma

pracuje

jest dyrektorem

Ograniczenie: {bag}

Zatrudnienie

data zatrudnienia
data zwolnienia
stanowisko
pensja

Osoba

1..*

Firm

a

*

{bag}

X:Osoba

Y:Firma

:Zatrudnienie

01.01.1990
15.12.1995
programista
2000

:Zatrudnienie

01.01.1998
NULL
analityk
5000

{subset}

pracuje

pracuje

pracuje

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 9

Role wielowartościowe (3)

Stereotyp: «history» dla oznaczenia roli pracodawca

Zatrudnienie

data zatrudnienia
data zwolnienia
stanowisko
pensja

Osoba

1..*

Firma

*

«history»

pracodawca

:Osoba

:Firma

:Zatrudnienie

01.01.1990
15.12.1995
programista
2000

:Zatrudnienie

01.01.1998
NULL
analityk
5000

Stereotyp «history» – podobnie jak
ograniczenie {bag} – pozwala na
utworzenie

więcej

niż

jednego

powiązania (o danej semantyce) między
dwoma obiektami; wykorzystywanie tego
stereotypu

jest

ukierunkowane

na

rejestrowanie zmian w czasie.

pracuje

pracuje

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 10

Role wielowartościowe (4)

Zatrudnienie

data zatrudnienia
data zwolnienia
stanowisko
pensja

Osoba

1..*

Firma

*

:Osoba

:Firma

:Zatrudnienie

01.01.1990
15.12.1995
programista
2000

:Zatrudnienie

01.01.1998
NULL
analityk
5000

Zastosowanie

klasy

pośredniczącej

Zatrudnienie

wprawdzie

pozwala

na

utworzenie wielu powiązań
pracuje między dwoma tymi
samymi

obiektami

(wystąpieniami klas Osoba i
Firma), ale nie pozwala na
uwidocznienie tego faktu.

1

1

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 11

Agregacja (1)

Agregacja jest rodzajem asocjacji; zadaniem agregacji jest
modelowanie związku całość-część.

 agregacja jest asocjacją: dla obu jej końców są określane
liczności, ponadto (jak każda asocjacja) może mieć atrybuty, np.

Grupa

Student

Termin

od
do

*

1..15

 agregacja jest wykorzystywana do modelowania związku całość-część

Grupa

Student

*

1..15

całość

część

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 12

Agregacja (2)

Inne nazwy dla ról agregacji:

całość

składa się z

zawiera

obejmuje, itp.

część

wchodzi w skład

należy

jest zawarta w, itp.

Nazwa agregacji i
nazwy jej ról, jako
oczywiste,

są

z

reguły

(?)

pomijane.

A

B

Własności agregacji:

 jest relacją niesymetryczną, tzn. jeśli B jest częścią
A, to A nie jest częścią B

A

B

C jest relacją przechodnią (tranzytywną), tzn. jeśli C jest

częścią B i B jest częścią A, to C jest częścią A

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 13

Agregacja (3)

Kryteria służące analitykowi pomocą w podjęciu decyzji czy do
modelowania pojęciowego wykorzystać agregację/kompozycję,
czy też zwykłą asocjację:

 kryterium istnienia (część nie istnieje samodzielnie bez całości),

 kryterium wstawiania (nie ma sensu wstawianie części do systemu,
jeśli nie wstawiono do niego całości),

 kryterium usuwania (usuwanie całości powinno skutkować
usunięciem wszystkich powiązanych z tą całością części, w drugą
stronę ta reguła nie obowiązuje),

 kryterium fizycznej części.

Wszystkie kryteria zawiodły, a mimo
to zastosowano agregację, gdyż
lepiej niż zwykła asocjacja modeluje
związek

część-całość:

pewne

operacje można wykonywać na
całości, a nie na każdej z części
oddzielnie.

Grupa

Termin
od
do

*

1..15

zmień plan

zmień plan

Operacja zmień plan została oznaczona jako ta,
która będzie automatycznie wykonana dla
wszystkich części, wtedy gdy zostanie wywołana
dla całości (tzw. propagacja operacji).

plan

Student

zmień plan

plan

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 14

Agregacja rekursywna (1)

Agregacja rekursywna

K

?

?

Obiekt klasy K może zarówno wchodzić w skład
innych obiektów klasy K, jak i może zawierać
obiekty klasy K.

K

0..1

0..1

:K

:K

:K

 Co by było, gdyby któryś z końców tej agregacji (lub oba końce) oznaczyć licznością
dokładnie 1 zamiast liczności opcjonalnej 0..1 ?

 Jakie zmiany wprowadziłoby do powyższego diagramu zastosowanie zwykłej asocjacji
zamiast agregacji ?
 Czy można tu zastosować kompozycję?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 15

Agregacja rekursywna (2)

K

0..1

*

:K

:K

:K

:K

:K

:K

:K

 Czy można tu zastosować liczność dokładnie 1 zamiast 0..1 i liczność 1..* zamiast
liczności * ?

 Czy można tu zastosować kompozycję?

Część

nazwa
materiał
rozmiary

0..1

*

I

II

Firma

Oddział

1

*

*

0..1

 Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji
wydaje się być bezdyskusyjna?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 16

Agregacja rekursywna (3)

K

*

*

:K

:K

:K

:K

:K

:K

:K

Przykłady agregacji rekursywnych

Program

1..*

Blok

Instrukcja

złożona

Instrukcja

prosta

0..1

1

*

I

II

Człon

*

Wyrażenie

operator binarny

Zmienna

nazwa

1

Stała

wartość

*

1

2-gi operand

1-szy operand

 Jak wyglądałby
diagram obiektowy
dla wyrażenia, np.
(x + y/2) * (x/3 - y)

Gdzie można by tu zastosować kompozycję – w I czy w II ?

Czy tu można zastosować kompozycję?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 17

Asocjacja kwalifikowana (1)

Katalog

Plik

nazwa

1

*

{

nazwa pliku jest unikatowa

w ramach katalogu }

Katalog

Plik

nazwa pliku

0..1

1

Perspektywa pojęciowa – plik jest w ramach katalogu jednoznacznie
identyfikowany przez nazwę.

Perspektywa projektowa – wskazanie na to, że katalog plików można
zorganizować jako tablicę asocjacyjną (słownik)
(przeszukiwanie za pomocą nazwy pliku).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 18

Asocjacja kwalifikowana (2)

Tablica

Kwadrat

rząd
kolumna

1

1

Tablica

1

100

Kwadrat

rząd
kolumna

Kwalifikator asocjacji może
być określony przez więcej
niż jeden atrybut. Warunek –
wartości

tych

atrybutów

muszą

pozwolić

na

jednoznaczną

identyfikację

obiektu/ grupy obiektów w
ramach

pewnego

zbioru

obiektów (tutaj – w ramach
zbioru

kwadratów

przypisanych

do

jednej

konkretnej tablicy, czyli do
jednego

obiektu

klasy

Tablica).

Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty.

nr konta
data założ.

*

*

Bank

nazwa

Osoba

imię
nazwisko

data założ.

*

0..1

Bank

nazwa

Osoba

imię
nazwisko

nr. konta

przypisany do

przypisany do

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 19

Mechanizmy rozszerzalności w UML

W UML istnieją trzy rodzaje mechanizmów rozszerzalności:

 stereotypy,

 wartości etykietowane,

 ograniczenia.

Stereotypy

 Stereotypy umożliwiają meta-klasyfikację elementów modelu.
 Istnieje lista stereotypów dla każdego rodzaju elementów
modelu (elementu metamodelu UML), np. relacji między
przypadkami użycia, klas czy metod.
 Dany element modelu (np. jedna relacja między przypadkami
użycia, jedna klasa czy metoda) może być oznaczona co
najwyżej jednym stereotypem, w sytuacji, gdy stereotyp
występuje na diagramie w postaci ikony.
 Są stereotypy predefiniowane, ale użytkownicy mogą też
definiować własne.
 Stereotypy rozszerzają semantykę metamodelu.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 20

Stereotypy - notacja

Notacja: zwykle «nazwa stereotypu» lub ikona, ale można też używać
koloru czy tekstury, choć z różnych względów nie jest to polecane
(ograniczenia ludzkie lub sprzętu).

Ikona może być używana na 2 sposoby: zamiast nazwy stereotypu (c, d) lub
razem z nią (b).
W przypadkach a, b, c zawartość elementu modelu opatrzonego
stereotypem (tu: klasy Pióro Świetlne) jest widoczna. W przypadku d
została opuszczona.

«sterowanie
»

PióroŚwietl
ne
lokacja:
Punkt
uruchom
(Tryb)

PióroŚwietlne
lokacja: Punkt
uruchom (Tryb)

PióroŚwietlne

«sterowanie»
PióroŚwietlne
lokacja: Punkt
uruchom (Tryb)

Ikona dla
stereotypu

(a)

(b)

(c)

(d)

Znak « (lub ») używany jest w charakterze cudzysłowia w jęz. francuskim (guillemets).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 21

Stereotypy; przykłady

«

trwała

»

Prostokąt

punkt1: Punkt
punkt2: Punkt

«konstruktory»
Prostokąt (p1: Punkt, p2:
Punkt)

«zapytania»
obszar () : Real
aspekt() : Real

...

«aktualizacje»
przesuń (delta: Punkt)
przeskaluj (współczynnik:
Real)

P1

P2

«

include

»

P3

P4

«

extend

»

rodzaj elementów modelu (element metamodelu): relacja między przypadkami użycia
lista stereotypów dla tego rodzaju: «include» i «extend»

Każda relacja między przypadkami użycia w konstruowanym modelu
musi być opatrzona jednym z dwóch stereotypów z powyższej listy.

«

trwała

»

Prostokąt

punkt1: Punkt
punkt2: Punkt

«konstruktory»
Prostokąt (p1: Punkt, p2:
Punkt)

«zapytania»
obszar () : Real
aspekt () : Real

...

«»
przesuń (delta: Punkt)
przeskaluj (współczynnik:
Real)

Jednym

stereotypem

można opatrzyć całą
listę

elementów

modelu. Koniec listy
można

oznaczyć

poprzez «».

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 22

 Wartość etykietowaną stanowi ciąg znaków o postaci: słowo
kluczowe = wartość.
 Są słowa kluczowe predefiniowane, ale użytkownik może też
definiować własne.
 Dowolny łańcuch znaków może być użyty jako wartość słowa
kluczowego.
 Listę wartości etykietowanych (oddzielonych przecinkami)
umieszcza się w {}.
 Dowolny element modelu może być skojarzony nie tylko z listą
wartości etykietowanych – ale w bardziej ogólnym sensie – z
łańcuchem własności w postaci: {dowolny łańcuch znaków}.

Wartości etykietowane

Wartości etykietowane są używane do skojarzenia arbitralnej
informacji z pojedynczym elementem modelu.

{autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza}

Przykład:

Wartości etykietowane są szczególnie przydatne do przechowywania informacji związanych
z zarządzaniem projektem (jak w przykładzie powyżej) czy szczegółów implementacyjnych.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 23

Ograniczenia

Ograniczenia specyfikują restrykcje nakładane na elementy modelu. Mogą stanowić wyrażenia
języka naturalnego czy języka formalnego (np. OCL w UML), mogą też przyjmować postać
formuły matematycznej lub fragmentu kodu (czy też pseudokodu).

Notacja: Ograniczenia są zawarte wewnątrz {} i umieszczane za
elementem w klasie, lub poza klasą. Z reguły są umieszczane w
komentarzu (przykład na następnej folii).

Pracownik

imię
nazwisko
pensja {<=10 000}

Pracownik

imię
nazwisko
pensja

{<=10 000}

{pensja nie wzrasta o
więcej niż 300}

ograniczenie

statyczne

ograniczenie

dynamiczne

zmień pensję (pensja)

W przypadku ograniczenia dynamicznego – w przeciwieństwie do
ograniczenia statycznego – interesuje nas poprzedni stan elementu, dla
którego wyspecyfikowano ograniczenie.
Czy powiedzie się próba zmiany pensji z 2500 na 5500, przy
ograniczeniach jak powyżej?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 24

Ograniczenia; przykłady

Konto

Firma

Osoba

{xor}

należy do

0..1

0..1

*

*

Symbole, takie jak - - - - oraz - - - - > są używane do wskazywania elementów, na
które zostały nałożone ograniczenia.

Firma

0..1

1..*

pracownik

pracodawca

podwładny

szef

0..1

*

{Osoba.pracodawca =
Osoba.szef.pracodawca}

Osoba

ograniczenie
w komentarzu

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 25

Ograniczenia predefiniowane;

przykłady

{complete}

{podział całkowity}

{incomplete}

{podział nie całkowity}

{disjoint}

{podział rozłączny}

{overlapping}

{podział nierozłączny}

{or}

{lub} (suma logiczna)

{xor}

{albo} (różnica symetryczna)

{ordered}

{uporządkowane}

{subset}

{podzbiór}

{bag}

{wielozbiór}

{hierarchy}

{hierarchia}

{dag}

{graf acykliczny skierowany}

dag - directed acyclic graph

j. angielski

j. polski

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 26

Design by Contract (1)

W idealnym przypadku ograniczenia powinny być implementowane
jako asercje w docelowym języku programowania. Asercje są sercem
metody projektowania Design by Contract zastosowanej przez
Bertranda Meyer’a w języku Eiffel. Design by Contract nie jest metodą
specyficzną dla tego tylko języka – może i powinna być wykorzystana w
każdym.

Asercja – to wyrażenie typu Boolean (warunek), którego wartość = FALSE prowadzi do błędu.
Zwykle asercje są testowane jedynie podczas debuggowania.

Design by Contract używa 3 rodzajów asercji:

 warunek wstępny (precondition) – definiuje, co powinno być
spełnione, aby dana operacja wykonała się poprawnie (jak powinien
wyglądać “świat sprzed”),

 warunek końcowy (postcondition) – określa, co będzie po
poprawnym wykonaniu operacji (“świat po”),

 inwariant – asercja, specyfikowana w oparciu o atrybuty
zdefiniowane w klasie będącej właścicielem operacji, określa warunek,
który musi być spełniony dla wszystkich wystąpień tej klasy po
poprawnym wykonaniu danej operacji.

Na bazie definicji warunków wstępnego i końcowego można sformułować
definicję wyjątku (exception): wyjątek zachodzi przy spełnionym warunku
wstępnym i niemożliwości spełnienia
warunku końcowego.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 27

Design by Contract (2)

Warunki, jak powyżej, mają kluczowe znaczenie dla wykonania się
operacji i są zupełnie niezależne od kontekstu, w jakim operacja jest
wywoływana. Bertrand Meyer stwierdza, że
obecność tych warunków należy traktować jak kontrakt wiążący daną
operację i operacje wywołujące ją. Operacja gwarantuje: “jeśli
wywołasz mnie ze spełnionym warunkiem wstępnym, to obiecuję
doprowadzić do stanu, w którym będzie spełniony warunek końcowy”
[Meyer 1988,1992]. Warunki nie narzucają konkretnej implementacji w
języku programowania.

Przykład: “dane pracowników są usuwane po 2 latach od daty
zwolnienia” (a nie „usuń dane pracowników po 2 latach od daty
zwolnienia”)

 warunek wstępny: musi minąć 2 lata od daty zwolnienia,

 warunek końcowy: dane pracowników, których to dotyczy, muszą zostać usunięte.

Kto powinien być odpowiedzialny za poprawność warunków (aby uniknąć nadmiaru
kontroli) – w idealnym przypadku:

 za warunek wstępny – operacja wywołująca,

 za warunek końcowy i inwarianty – operacja wywoływana.

Warunki wstępne, końcowe i inwarianty powinny być dokumentowane
łącznie z dokumentowaniem operacji. W idealnym przypadku powinny
stanowić część kodu definiującego interfejs.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 28

Przykład asercji w języku Eiffel

Class STACK[T] export
nb_elements,empty, full, push, pop, top
feature
nb_elements : INTEGER;
. . .
push(x : T) is

- Add on top

not full;
do . . .

require

ensure

not empty;
top=x;
nb_elements=old nb_elements + 1
end; - push
. . .

invariant

0  nb_elements; nb_elements  max_size;

empty = (nb_elements = 0)
end; - class STACK

Inwarianty mogą przybierać wartość = FALSE
jedynie w trakcie wykonywania operacji.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 29

Przykład asercji w języku Eiffel (cd.)

Przykład 2:

Tablica

sortuj

«postcondition»

{po sortowaniu: nie zmienia się liczba
elementów; każda wartość pojawia się
tyle samo razy, co przed sortowaniem;
dla kolejnych wartości x i y zachodzi x
<= y}

Pracownik

dane osobowe
. . .
data zatrudnienia
data zwolnienia

usuń zwolnionych

«precondition»

{minęło

2

lata

od

daty

zwolnienia}

«postcondition»

{dane

zwolnionych

pracowników

zostały usunięte z zasobów}

Przykład 1:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 30

OCL – Object Constraint Language (1)

OCL jest językiem o notacji tekstowej służącym do specyfikowania
warunków, ograniczeń, asercji i zapytań (zapisu wyrażeń
ścieżkowych). OCL zawiera pewien zestaw predefiniowanych
operatorów do operowania na elementach kolekcji czy na typach
podstawowych, ale nie jest przeznaczony do zapisywania kodu.

Podstawowe elementy składni OCL:

element

.

selektor

 selektor może być nazwą atrybutu
(opisującego element) – wtedy zwracana
jest albo wartość albo zbiór wartości
atrybutu

 selektor może być nazwą roli (celu) –
wtedy zwracany jest zbiór powiązanych
obiektów

A

a

A

m

A

B

a

B

m

B

1

*

r

A

r

B

 wyrażenie o

A

.a

A

zwróci wartość atrybutu a

A

 wyrażenie o

A

.r

B

zwróci zbiór obiektów

klasy B powiązanych z danym obiektem
o

A

Przykład:

Niech o

A

oznacza pewien obiekt klasy A, wtedy:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 31

OCL - Object Constraint Language (2)

element.selektor (lista arg)

selektor

jest

nazwą

operacji

wywoływanej dla elementu, wartością
wyrażenia jest tu wynik zwracany przez
operację

element.selektor (kwalifikator) selector

specyfikuje

asocjację

kwalifikowaną; element plus wartość
kwalifikatora jednoznacznie identyfikują
zbiór powiązanych obiektów

zbiór-> własność-zbioru

własność-zbioru

stanowi

nazwę

wbudowanej w OCL funkcji na zbiorze,
np. select, reject, size

zbiór->select (warunek)

zwraca

podzbiór

elementów

spełniających

wyspecyfikowany

warunek

zbiór->reject (warunek)

zwraca

podzbiór

elementów

nie

spełniających

wyspecyfikowanego

warunku

zbiór->size

zwraca liczność zbioru

self

specyfikuje aktualnie rozważany obiekt
(może być opuszczony, gdy kontekst jest
znany)

operator

np .=, <, >, <=, >=, <>, +, -, *, /, not, and, or, xor

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 32

OCL – Object Constraint Language (3)

Przykłady:

samolot.pilot->select (godziny_treningowe >= samolot.min_godz)

może być wykorzystane do zwrócenia zbioru pilotów, dla
których liczba godz. treningowych jest co najmniej równa
minimalnej liczbie godz. wymaganych dla danego samolotu

firma.pracownik->select (tytuł = “szef” and self.raport->size >10)

zwróci zbiór pracowników będących szefami, którzy
dostarczyli więcej niż 10 raportów

Firma

Pracow

nik

tytuł

Raport

1..*

*

1

1

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 33

Zasada zamienialności a ograniczenia

Zasada zamienialności (byt programistyczny typu B może
zastąpić byt typu A, o ile B jest podtypem A) przenosi się na
ograniczenia

w

sposób

wyrażony

poniższym

potocznym

stwierdzeniem:

Nie żądaj więcej, nie obiecuj mniej (ang. “demand no more, promise no less”).

A

m

B

m

Warunek wstępny dla metody m w klasie B – powinien
być nie silniejszy niż dla metody m w klasie A; warunek
końcowy – nie słabszy niż w klasie A.

Obiekt klasy B może zastąpić obiekt klasy A, co
oznacza, że jego zachowanie z punktu widzenia obiektu
wysyłającego komunikat wywołujący metodę m na
obiekcie klasy B, powinno być takie same, jak gdyby
komunikat wysłano do obiektu klasy A.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 7, Slajd 34

Podsumowanie mechanizmów

rozszerzalności

 UML dostarczyła kilku mechanizmów rozszerzalności, aby umożliwić
projektantom wprowadzanie modyfikacji bez konieczności zmiany
samego języka modelowania. Twórcy UML starali się w ten sposób
(chociażby w pewnym stopniu) zaspokoić potrzeby specyficznych
dziedzin problemowych czy środowisk programistycznych.

 Narzędzia mogą przechowywać wprowadzone modyfikacje oraz
manipulować nimi bez konieczności wnikania w ich semantykę –
modyfikacje z reguły są przechowywane w postaci łańcuchów
znakowych.

 Narzędzia mogą ustanowić własną składnię i semantykę dla obsługi
mechanizmów rozszerzalności.

 Należy pamiętać, że rozszerzenia stanowią z definicji odstępstwo od
standardów UML, i że w naturalny sposób prowadzą do utworzenia
pewnego dialektu UML, a to z kolei może prowadzić do problemów z
przenaszalnością. Trzeba zawsze dobrze rozważyć zyski i straty
możliwe do poniesienia dzięki korzystaniu z tych mechanizmów,
szczególnie wtedy, gdy “stare” standardowe mechanizmy pracują
wystarczająco dobrze.