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

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

Zastosowanie
dziedziczenia asocjacji
spowodowało, że część
informacji nie została
przeniesiona na nowy
diagram

(zmiany zostały

oznaczone czerwonym
kolorem

).

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ę powinna
zostać oznaczona jako
pochodna (albo usunięta
z diagramu).

Osoba

Miasto

Firma

mieszka

1

1..*

znajduje się

1

1..*

1..*

pracuje w

1

0..1 ? pracodawca

2) Jeśli liczność roli pracodawca
wynosi 0..1 to żadna asocjacja nie
będzie pochodna, ponieważ nie dla
wszystkich obiektów powiązania
będą mogły być wydedukowane.

Możliwe asocjacje pochodne:

/mieszka lub /znajduje się

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}

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

go

jest

ukierunkowane na rejestrowanie zmian
w czasie.

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 uwidacznia
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, a także 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ą

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ę, 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),

 kryterium fizycznej części.

Wszystkie kryteria zawiodły, a mimo to
zdecydowano się zastosować agregację,
ponieważ 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 (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 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 * ?

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)

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
stanowić więcej niż jeden
atrybut. Warunek - wartości
tych

atrybutów

muszą

pozwolić na jednoznaczną
identyfikację

obiektu

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, 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ę (nowa)

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, definiowana w oparciu o atrybuty zdefiniowane
w klasie, określa warunek, który musi być spełniony dla wszystkich
wystąpień klasy po 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ć jako kontrakt wiążący
daną operację i operacji wywołujących 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 pracownika są usuwane po 2 latach od daty…”

 warunek wstępny: minęło 2 lata,

 warunek końcowy: dane pracownika zostały usunięte z zasobów.

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 i końcowe 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
. . .

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

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

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.

Przykład

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 }

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

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

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 (“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 programowych.

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