K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 12, Folia 1
Projektowanie systemów informacyjnych
description
Transcript of Projektowanie systemów informacyjnych
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łaTechnik Komputerowych, Warszawa
Wykład 7
Model obiektowy (4)
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 2
Zagadnienia
Dziedziczenie asocjacjiAsocjacje pochodneRedukcja licznościRole wielowartościoweTrochę więcej o agregacjiAgregacja rekursywnaTrochę więcej o asocjacji kwalifikowanejTrochę 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
aa
{incomplete}
K1
K2 K3 K
a
Aby 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) obie asocjacje az diagramu po lewej stronie muszą spełniać następujące warunki:
muszą mieć tą samą semantykę, muszą mieć tą samą strukturę, asocjacja a musi łączyć klasę K z wszystkimi podklasami klasy K1.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 4
Dziedziczenie asocjacji (2)
Referattytułautorzy [1..*]
Zaproszony Zwykłyocena
Sesjanazwadata
Termingodz.
Termingodz.
wygłaszany
1..* 0..1
wygłaszany
1
0..1
Termingodz.
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ściew którym pracuje, to któraś z asocjacji: mieszka lub znajduje siępowinna zostać oznaczona jakopochodna (albo usunięta z diagramu).
Osoba Miasto
Firma
mieszka 11..*
znajduje się
1
1..*
1..*
pracuje w
10..1? pracodawca
2) Jeśli liczność roli pracodawcawynosi 0..1 asocjacja mieszka niebędzie pochodna, ponieważ nie dlawszystkich 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
Ka1a21 y K21x
K1 K2
K
a1a2
x y
Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu
Przykład
Zatrudnienie
stanowiskopensja
Osoba1..*
Firma*
Osoba*
Firma1..*
Zatrudnienie
stanowiskopensja
1
1
/pracodawca1..* *
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 K2r1 r2
Przyjmuje się domyślnie:
zbiór obiektów, opisujący daną rolę, jest nieuporządkowany, dany obiekt pojawia się tylko jeden raz w w zbiorze obiektów opisującym 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 K21..2a
*
{ordered}
Ograniczenie {ordered} pozwalana uporządkowanie zbioru obiektów opisującego daną rolę.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 8
Role wielowartościowe (2)
Dwa powiązania między dwoma tymi samymi obiektami występują też w sytuacji,jak poniżej, ale nie są to powiązania o tej samej semantyce, jak w przykładzie poprzednim.
Osoba Firma
pracuje
jest dyrektorem0..1
0..1
1
*
Nowak : Osoba IBM : Firma
pracuje
jest dyrektorem
Ograniczenie: {bag}
Zatrudnienie
data zatrudnieniadata zwolnieniastanowiskopensja
Osoba1..*
Firma*
{bag}
X:Osoba Y:Firma
:Zatrudnienie
01.01.199015.12.1995programista2000
:Zatrudnienie
01.01.1998NULLanalityk5000
{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 zatrudnieniadata zwolnieniastanowiskopensja
Osoba1..*
Firma*
«history »pracodawca
:Osoba :Firma
:Zatrudnienie
01.01.199015.12.1995programista2000
:Zatrudnienie
01.01.1998NULLanalityk5000
Stereotyp «history», podobnie jak ograniczenie {bag}, pozwala na utworzenie więcej niż jednegopowiązania o danej semantyce między dwoma obiektami, ale wykorzystywanie go jest raczejukierunkowane na rejestrowanie zmian w czasie.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 10
Role wielowartościowe (4)
Zatrudnienie
data zatrudnieniadata zwolnieniastanowiskopensja
Osoba1..*
Firma*
:Osoba :Firma
:Zatrudnienie
01.01.199015.12.1995programista2000
:Zatrudnienie
01.01.1998NULLanalityk5000
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
Terminoddo
* 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ę zzawieraobejmuje, itp.
część
wchodzi w składnależyjest 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 modelujezwiązek część-całość - pewne operacje można wykonywać na całości, a nie na każdej z częścioddzielnie.
Grupa
Terminoddo
* 1..15
zmień plan
Student
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).
planplan
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.
K0..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)
K0..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ęśćnazwamateriał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
Instrukcjaprosta0..1
1
*
I II
Człon
*Wyrażenie
operator binarny
Zmiennanazwa
1
Staławartość
*
12-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)
KatalogPlik
nazwa
1 * { nazwa pliku jest unikatowa w ramach katalogu }
Katalog Pliknazwa pliku0..11
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ą lub słownik (przeszukiwanie za pomocą nazwy pliku).
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 18
Asocjacja kwalifikowana (2)
TablicaKwadratrząd
kolumna
11
TablicaKwadrat
rządkolumna
1 100Kwalifikator 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 należących do jednej konkretnej tablicy, czyli jednego obiektu klasy Tablica).
Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty.
nr kontadata założ.
* *Bank
nazwa
Osobaimięnazwisko
data założ.
* 0..1Bank
nazwa
Osobaimięnazwiskonr. konta
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, klasa czy
metoda) może mieć co najwyżej jeden stereotyp.
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 symbolu stereotypu (c, d) lub razem z nim (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Świetlnelokacja: Punkturuchom (Tryb)
PióroŚwietlnelokacja: Punkturuchom (Tryb)
PióroŚwietlne
«sterowanie» PióroŚwietlnelokacja: Punkturuchom (Tryb)
ikona
(a) (b)
(c) (d)
« lub » guillemets - jeden znak - używany w charakterze cudzysłowia w jęz. francuskim
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 21
Stereotypy; przykłady
«trwała» Prostokątpunkt1: Punktpunkt2: Punkt
«konstruktory»Prostokąt (p1: Punkt, p2: Punkt)
«zapytania»obszar () : Realaspekt() : Real...
«aktualizacje»przesuń (delta: Punkt)przeskaluj (współczynnik: Real)
P1 P2 «include»
P3 P4 «extend»
rodzaj elementów modelu: relacje między przypadkami użycialista stereotypów dla tego rodzaju: «include» i «extend»
Każda relacja między przypadkami użycia (element modelu) jest opatrzona jednym z dwóch stereotypów z powyższej listy.
«trwała» Prostokątpunkt1: Punktpunkt2: Punkt
«konstruktory»Prostokąt (p1: Punkt, p2: Punkt)
«zapytania»obszar () : Realaspekt () : Real...
«»przesuń (delta: Punkt)przeskaluj (współczynnik: Real)
Jednym stereotypem można opatrzyć całą listęelementów modelu. Koniec listy może byćoznaczany przez «».
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ść.
Dowolny łańcuch znaków może być użyty jako słowo kluczowe.
Są słowa kluczowe predefiniowane, ale użytkownik może też definiować własne.
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ązanychz 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żeniajęzyka naturalnego czy języka formalnego (np. OCL w UML), mogą też przyjmować postaćformuły matematycznej lub fragmentu kodu (czy też pseudokodu).
Notacja: są zawarte wewnątrz {} i umieszczane za elementem w klasie, lub poza klasą. Mogąteż być umieszczane w komentarzu (przykład na następnej folii).
Pracownik
imięnazwiskopensja {<=10 000}
Pracownik
imięnazwiskopensja {pensja <=10 000}
{pensja nie wzrasta o więcej niż 300}
ograniczeniestatyczne
ograniczeniedynamiczne
zmień pensję (nowa)
Ograniczenie dynamiczne - tu interesuje nas poprzedni stan elementu, na który jest nałożone ograniczenie.
Czy powiedzie się próba zmiany pensji z 2500 na 5500?
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 - - - - > mogą być używane do wskazywania elementów, na które zostały nałożone ograniczenia.
Firma0..11..*
pracownik pracodawca
podwładny
szef0..1
*
{Osoba.pracodawca = Osoba.szef.pracodawca}
Osoba
ograniczeniew 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}
{xor} {albo}
{ordered} {uporządkowane}
{subset} {podzbiór}
{bag} {wielozbiór}
{history} {historia}
{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 dla klas posiadających dane, które nie powinny ulec zmianie po wykonaniu operacji; ten warunek musi być zawsze spełniony dla wszystkich wystąpień danej klasy.
Na bazie definicji warunków wstępnego i końcowego można sformułować definicję wyjątku (exception) - 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] exportnb_elements,empty, full, push, pop, topfeaturenb_elements : INTEGER;. . .push(x : T) is
- Add on top
not full;do . . .
require
ensure
not empty;top=x;nb_elements=old nb_elements + 1end; - 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 wykonalnego.
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
AaA
mA
BaB
mB
1 *rA
rB
• 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
Przykład
Niech OA 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
lot.pilot.godziny_treningowe >= lot.samolot.min_godz
może być wykorzystane do zwrócenia zbioru pilotów, którzy wylatali odpowiednią dla danego samolotu liczbę godzin
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 komunikatwywołujący metodę m, 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.