No Slide Title
Download
Report
Transcript No Slide Title
Projektowanie systemów informacyjnych
Wykład 7
Model obiektowy (4)
Ewa Stemposz, Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 1
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 2
Dziedziczenie asocjacji (1)
K1
a
K1
K2
K3
a
K4
a
K2
K3
K
K
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 3
Dziedziczenie asocjacji (2)
Termin
godz.
Referat
Nazwa dla klasy asocjacji ?
{abstract}
1..*
tytuł
autorzy[1..*]
wygłaszany
0..1
0..1
Zaproszony
wygłaszany
Termin
godz.
wygłaszany
Zwykły
ocena
1..*
0..1
Sesja
nazwa
data
1
Termin
godz.
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 4
Asocjacje pochodne
Osoba
1..*
mieszka
1
pracownik 1..*
0..1 ?
1 pracodawca
znajduje się
Firma
1..*
Możliwe asocjacje pochodne:
/mieszka lub /znajduje się
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 5
Miasto
1
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.
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.
Redukcja liczności
Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu
K1 x
y K2
K1 1
K
a1
a2
K
a1
y a2
x
1 K2
gdzie: x, y oznaczają liczności wiele
Przykład:
Osoba
1..*
*
Firma
1..*
Zatrudnienie
Osoba
stanowisko
pensja
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 6
*
Zatrudnienie
1
stanowisko
* pensja
1
1..*
/pracodawca
Firma
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:
1
K1 r1
*
r2 K2
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.
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 ».
a
Ograniczenie {ordered} pozwala na
uporządkowanie zbioru obiektów
opisanego daną rolą.
źle
K1
1..2
a
K2
dobrze
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 7
:K2
a
:K2
:K1
{ordered}
*
a
:K1
a
:K2
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.
pracuje
pracuje
0..1
*
Osoba
{subset}
Firma
Nowak : Osoba
IBM : Firma
0..1
1
jest dyrektorem
jest dyrektorem
pracuje
Ograniczenie: {bag}
Osoba
:Zatrudnienie
pracuje
*
1..*
{bag}
Firma
X:Osoba
01.01.1990
15.12.1995
programista
2000
pracuje
Zatrudnienie
data zatrudnienia
data zwolnienia
stanowisko
pensja
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 8
:Zatrudnienie
01.01.1998
NULL
analityk
5000
Y:Firma
Role wielowartościowe (3)
Stereotyp: «history» dla oznaczenia roli pracodawca
*
Osoba
1..*
Firma
«history»
pracodawca
pracuje
:Zatrudnienie
Zatrudnienie
data zatrudnienia
data zwolnienia
stanowisko
pensja
:Osoba
01.01.1990
15.12.1995
programista
2000
pracuje
:Zatrudnienie
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 9
01.01.1998
NULL
analityk
5000
:Firma
Role wielowartościowe (4)
Zatrudnienie
Osoba
1
* data zatrudnienia
data zwolnienia
stanowisko
pensja
1..*
1
Firma
:Zatrudnienie
01.01.1990
15.12.1995
programista
2000
:Firma
:Osoba
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 10
:Zatrudnienie
01.01.1998
NULL
analityk
5000
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.
*
1..15
Grupa
Student
Termin
od
do
agregacja jest wykorzystywana do modelowania związku całość-część
*
Grupa
całość
1..15
część
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 11
Student
Agregacja (2)
Inne nazwy dla ról agregacji:
całość
część
składa się z
zawiera
obejmuje, itp.
wchodzi w skład
należy
jest zawarta w, itp.
Nazwa agregacji i nazwy
jej ról, jako oczywiste, są
z reguły (?) pomijane.
Własności agregacji:
A
B
A
B
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 12
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.
zmień plan
Grupa
*
1..15
plan
zmień plan
Termin
od
do
Student
plan
zmień plan
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.
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).
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 13
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
:K
0..1
: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 14
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ę?
I
Część
0..1
nazwa
materiał
rozmiary
II
Firma
*
1
* 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 15
Agregacja rekursywna (3)
*
K
:K
Czy tu można zastosować kompozycję?
*
:K
:K
:K
:K
:K
:K
Przykłady agregacji rekursywnych
I
Program
1..*
II
1
2-gi operand
*
1-szy operand 1
1
Blok
*
Instrukcja
0..1 złożona
Jak wyglądałby
diagram obiektowy
dla wyrażenia, np.
Instrukcja
prosta
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 16
Człon
Wyrażenie
operator binarny
*
Gdzie można by tu zastosować kompozycję – w I czy w II ?
(x + y/2) * (x/3 - y)
Zmienna
nazwa
Stała
wartość
Asocjacja kwalifikowana (1)
Katalog
1
Katalog nazwa pliku
* Plik
nazwa
1
0..1
{ nazwa pliku jest unikatowa
w ramach katalogu }
Plik
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 17
Asocjacja kwalifikowana (2)
1
Tablica
Tablica
100
rząd
kolumna
przypisany do
rząd
kolumna
1
1
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).
Kwadrat
przypisany do
Kwadrat
Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty.
Bank
*
*
nazwa
Osoba
imię
nazwisko
nr konta
data założ.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 18
Bank
nazwa
nr. konta
*
0..1
data założ.
Osoba
imię
nazwisko
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 19
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).
Znak « (lub ») używany jest w charakterze cudzysłowia w jęz. francuskim (guillemets).
(a)
(c)
«sterowanie»
PióroŚwietlne
lokacja: Punkt
uruchom (Tryb)
(b)
PióroŚwietlne
lokacja: Punkt
uruchom (Tryb)
«sterowanie»
PióroŚwietlne
lokacja: Punkt
uruchom (Tryb)
Ikona dla
stereotypu
(d)
PióroŚwietlne
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 20
Stereotypy; przykłady
«extend»
«include»
P1
P3
P2
P4
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
«trwała» Prostokąt
punkt1: Punkt
punkt2: Punkt
punkt1: Punkt
punkt2: Punkt
«konstruktory»
Prostokąt (p1: Punkt, p2: Punkt)
«konstruktory»
Prostokąt (p1: Punkt, p2: Punkt)
«zapytania»
obszar () : Real
aspekt() : Real
«zapytania»
obszar () : Real
aspekt () : Real
...
...
«aktualizacje»
przesuń (delta: Punkt)
przeskaluj (współczynnik: Real)
«»
przesuń (delta: Punkt)
przeskaluj (współczynnik: Real)
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 21
Jednym stereotypem można
opatrzyć całą listę elementów
modelu. Koniec listy można
oznaczyć poprzez «».
Wartości etykietowane
Wartości etykietowane są używane do skojarzenia arbitralnej informacji z
pojedynczym elementem modelu.
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}.
Przykład:
{autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza}
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 22
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).
ograniczenie
statyczne
Pracownik
Pracownik
{<=10 000}
imię
imię
nazwisko
{pensja nie wzrasta o
nazwisko
pensja
więcej niż 300}
pensja {<=10 000}
zmień pensję (pensja)
ograniczenie
dynamiczne
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 23
Ograniczenia; przykłady
Symbole, takie jak - - - - oraz - - - - > są używane do wskazywania elementów, na
które zostały nałożone ograniczenia.
0..1
Firma
Konto
*
{xor}
*
należy
do
0..1
podwładny
*
0..1
szef
Osoba
1..*
pracownik
{Osoba.pracodawca =
Osoba.szef.pracodawca}
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 24
Osoba
0..1
pracodawca
Firma
ograniczenie
w komentarzu
Ograniczenia predefiniowane; przykłady
j. angielski
j. polski
{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}
dag - directed acyclic graph
{graf acykliczny skierowany}
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 25
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 26
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 27
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
require
not full;
do . . .
ensure
not empty;
top=x;
nb_elements=old nb_elements + 1
end; - push
...
invariant
Inwarianty mogą przybierać wartość = FALSE
jedynie w trakcie wykonywania operacji.
0 nb_elements; nb_elements max_size;
empty = (nb_elements = 0)
end; - class STACK
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 28
Przykład asercji w języku Eiffel (cd.)
Przykład 1:
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 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}
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 29
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:
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
element.selektor
Przykład:
Niech oA oznacza pewien obiekt klasy A, wtedy:
A
aA
mA
B
1
rA
* aB
rB
mB
wyrażenie oA.aA zwróci wartość atrybutu aA
wyrażenie oA.rB zwróci zbiór obiektów klasy B
powiązanych z danym obiektem oA
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 30
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
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 31
spełniających
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
1
1..*
Pracownik
1
tytuł
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 32
*
Raport
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
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.
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 33
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 34