No Slide Title

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 3

Dziedziczenie asocjacji (1)

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

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

asocjacji:

mieszka lub znajduje się
albo

powinna

zostać

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

Osoba

Miasto

Firma

mieszka

1..*

znajduje się

1..*

0..1 ?

pracodawca

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

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

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

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

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

:K2

1..2

{ordered}

Ograniczenie

{ordered}

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

ź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

Nowak : Osoba

IBM : Firma

pracuje

jest dyrektorem

Ograniczenie: {bag}

Zatrudnienie

data zatrudnienia
data zwolnienia
stanowisko
pensja

Osoba

1..*

Firm

{bag}

X:Osoba

Y:Firma

:Zatrudnienie

01.01.1990
15.12.1995
programista
2000

:Zatrudnienie

01.01.1998
NULL
analityk
5000

{subset}

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

rejestrowanie zmian w czasie.

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

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

obiektami

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

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ą

reguły

(?)

pomijane.

Własności agregacji:

 jest relacją niesymetryczną, tzn. jeśli B jest częścią
A, to A nie jest częścią 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

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

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

0..1

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

0..1

 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

Firma

Oddział

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)

Przykłady agregacji rekursywnych

Program

1..*

Blok

Instrukcja

złożona

Instrukcja

prosta

0..1

Człon

Wyrażenie

operator binarny

Zmienna

nazwa

Stała

wartość

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

{

nazwa pliku jest unikatowa

w ramach katalogu }

Katalog

Plik

nazwa pliku

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

Tablica

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ć

jednoznaczną

identyfikację

obiektu/ grupy obiektów w
ramach

pewnego

zbioru

obiektów (tutaj – w ramach
zbioru

kwadratów

przypisanych

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

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)

include

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

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

lata

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

 wyrażenie o

zwróci wartość atrybutu a

 wyrażenie o

zwróci zbiór obiektów

klasy B powiązanych z danym obiektem
o

Przykład:

Niech o

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

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

sposób

wyrażony

poniższym

potocznym

stwierdzeniem:

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

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.

Document Outline