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

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

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,

jedna

asocjacji:  mieszka  lub
znajduje  się  powinna
zostać  oznaczona  jako
pochodna  (albo  usunięta
z diagramu).

Osoba

Miasto

Firma

mieszka

1..*

znajduje się

1..*

pracuje w

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

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}

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

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.

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 !

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

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

Obiekt klasy K może zarówno wchodzić w skład
innych obiektów klasy K, jak i 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 * ?

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)

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

atrybutów

muszą

pozwolić na jednoznaczną
identyfikację

obiektu

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

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)

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

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

 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

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

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.

Document Outline