Projektowanie systemów informacyjnych

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)

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

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 (?).

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 ?

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

0..1 ? 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ę

Redukcja liczności

K1

K a1a2

1 y ^x 1 K2

K1 K2

K a1a2

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

Role wielowartościowe (1)

Rola wielowartościowa to taka rola, dla której górna granica liczności jest większa od 1.

K1 r1 r2 K2

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 ^* _a ^1..2 K2

{ordered}

Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów opisanego daną rolą.

a

źle

dobrze

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

* {bag}

X:Osoba Y:Firma

:Zatrudnienie 01.01.1990 15.12.1995 programista 2000

:Zatrudnienie 01.01.1998 NULL analityk {subset}

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.

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

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 ^{* 1..15} Student

całość część

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

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

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

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 ^{1 *} Oddział

*

0..1

 Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji wydaje się być bezdyskusyjna?

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)

Asocjacja kwalifikowana (1)

Katalog Plik

nazwa

1 * { nazwa pliku jest unikatowa

w ramach katalogu }

Katalog nazwa pliku 1 0..1 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).

Asocjacja kwalifikowana (2)

Tablica ^rząd Kwadrat

kolumna

1

1

Tablica 1 ₁₀₀ 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

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.

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Świetlne 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).

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 «include» P2

P3 «extend» 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

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

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

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

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

1..* 0..1

pracownik pracodawca podwładny

szef 0..1

*

{Osoba.pracodawca = Osoba.szef.pracodawca}

Osoba

ograniczenie w komentarzu

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

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.

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.

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

. . .

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 }

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

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

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

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.

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.