Projektowanie systemów informacyjnych

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

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

3. Dziedziczenie asocjacji (1) K1 {incomplete} a K1 K2 K3 K4 a a K2 K3 K K 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 a z 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.

4. Dziedziczenie asocjacji (2) Termin godz. Termin godz. Termin Nazwa dla klasy asocjacji ? godz. Referat wygłaszany 1..* tytuł autorzy [1..*] 0..1 Sesja nazwa wygłaszany 0..1 Zwykły Zaproszony data ocena 1..* 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

5. Asocjacje pochodne Osoba Miasto mieszka 1..* 1 1..* 1 pracuje w ? 0..1 pracodawca 1 Firma znajduje się 1..* 1) Jeśli Osoba mieszka w mieście w którym pracuje, to któraś z asocjacji: mieszkalub znajduje się powinna zostać oznaczona jako pochodna (albo usunięta z diagramu). 2) Jeśli liczność roli pracodawca wynosi 0..1 asocjacja mieszkanie 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ę

6. Redukcja liczności K a1 a2 Osoba Firma 1..* * Zatrudnienie Zatrudnienie stanowisko stanowisko pensja pensja Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu K1 K2 K x y a1 K1 K2 1 y x 1 a2 gdzie: x, y oznaczają liczności wiele Przykład /pracodawca 1..* * 1 Osoba Firma 1 * 1..*

7. Role wielowartościowe (1) K1 K2 r1 r2 Rola wielowartościowa to taka rola, dla której górna granica liczności jest większa od 1. Przyjmuje się domyślnie: 1 * • 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 ». Rola r2 jest tu rolą wielowartościową. W sensie dosłownym, liczności obu końców asocjacji oznaczają liczności obu ról. Uwaga: a Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów opisującego daną rolę. :K2 a :K1 :K2 a {ordered} :K1 * 1..2 K1 K2 :K2 a

8. Role wielowartościowe (2) pracuje pracuje 0..1 * Nowak : Osoba Osoba IBM : Firma Firma 0..1 1 jest dyrektorem jest dyrektorem Y:Firma X:Osoba Zatrudnienie :Zatrudnienie :Zatrudnienie 01.01.1998 NULL analityk 5000 data zatrudnienia data zwolnienia stanowisko pensja 01.01.1990 15.12.1995 programista 2000 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. {subset} Ograniczenie: {bag} {bag} Osoba Firma * 1..*

9. Role wielowartościowe (3) :Firma :Osoba Zatrudnienie :Zatrudnienie :Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja 01.01.1990 15.12.1995 programista 2000 01.01.1998 NULL analityk 5000 Stereotyp: «history» dla oznaczenia roli pracodawca * Osoba Firma 1..* «history » pracodawca Stereotyp «history», podobnie jak ograniczenie {bag},pozwala na utworzenie więcej niż jednego powiązania o danej semantyce między dwoma obiektami, ale wykorzystywanie go jest raczej ukierunkowane na rejestrowanie zmian w czasie.

10. Role wielowartościowe (4) Firma Zatrudnienie * 1..* data zatrudnienia data zwolnienia stanowisko pensja Osoba :Zatrudnienie 01.01.1990 15.12.1995 programista 2000 :Firma :Osoba Zastosowanie klasy pośredniczącej Zatrudnieniewprawdzie pozwala na utworzenie wielu powiązań pracuje między dwoma tymi samymi obiektami, wystąpieniami klas Osobai Firma, ale nie uwidacznia tego faktu. :Zatrudnienie 01.01.1998 NULL analityk 5000

11. Agregacja (1) Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowaniezwią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. * 1..15 Grupa Student Termin od do • agregacja jest wykorzystywana do modelowania związku całość-część * 1..15 Grupa Student część całość

12. Agregacja (2) A B C B Inne nazwy dla ról agregacji: całość część Nazwa agregacji i nazwy jej ról, jako oczywiste, są pomijane ! • składa się z • zawiera • obejmuje, itp. • wchodzi w skład • należy • jest zawarta w, itp. Własności agregacji: • jest relacjąniesymetryczną, tzn. jeśli B jest częścią A, to A niejest częścią B • jest relacjąprzechodnią (tranzytywną), tzn. jeśli C jest częścią B i B jest częścią A, to C jest częścią A A

13. Agregacja (3) zmień plan Student zmień plan 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 * plan 1..15 plan zmień plan Termin od do Operacja zmień planzostał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).

14. Agregacja rekursywna (1) ? ? K 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 :K K 1 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ę?

15. Agregacja rekursywna (2) Oddział 0..1 :K K 2 * :K :K :K :K :K :K • Czy można tu zastosować liczność dokładnie 1zamiast 0..1i liczność 1..*zamiast liczności * ? I Część II 0..1 nazwa materiał rozmiary 1 0..1 * Firma * * • Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji wydaje się być bezdyskusyjna?

16. Agregacja rekursywna (3) Blok Instrukcja złożona Instrukcja prosta 0..1 * :K K 3 * :K :K :K :K :K :K Przykłady agregacji rekursywnych • Jak wyglądałby diagram obiektowy dla wyrażenia, np. (x + y/2) * (x/3 - y) I Program II 2-gi operand 1 1 * 1-szy operand 1 1..* Człon * Stała Wyrażenie Zmienna wartość nazwa operator binarny *

17. Asocjacja kwalifikowana (1) { nazwa pliku jest unikatowa w ramach katalogu } 1 Plik * Katalog nazwa 1 0..1 Katalog Plik nazwa pliku Perspektywa pojęciowa - plik jest w ramach katalogu jednoznacznie identyfikowany przez nazwę. 1 Perspektywa projektowa - wskazanie na to, że katalog plików można zorganizować jako tablicę asocjacyjną lub słownik (przeszukiwanie za pomocą nazwy pliku). 2

18. Asocjacja kwalifikowana (2) 1 Kwadrat 100 Tablica rząd kolumna 1 1 rząd kolumna Kwadrat Tablica Osoba Osoba Bank imię nazwisko imię nazwisko * * nazwa nr konta data założ. 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 należących do jednej konkretnej tablicy, czyli jednego obiektu klasy Tablica). Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty. Bank 0..1 * nr. konta nazwa data założ.

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 listastereotypów dla każdego rodzajuelementówmodelu (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.

20. Stereotypy - notacja «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) PióroŚwietlne 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). « lub »guillemets - jeden znak - używany w charakterze cudzysłowia w jęz. francuskim «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) (a) (b) ikona (c) PióroŚwietlne lokacja: Punkt uruchom (Tryb) (d) 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.

21. Stereotypy; przykłady «extend» «include» P4 P3 P1 P2 «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) 1 rodzaj elementów modelu: relacje między przypadkami użycia lista 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. 2 «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) Jednym stereotypem można opatrzyć całą listę elementów modelu. Koniec listy może być oznaczany przez «».

22. 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ść. 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}. 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.

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: 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). ograniczenie statyczne Pracownik Pracownik imię nazwisko pensja {<=10 000} imię nazwisko pensja {pensja <=10 000} {pensja nie wzrasta o więcej niż 300} zmień pensję (nowa) ograniczenie dynamiczne 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?

24. Ograniczenia; przykłady {Osoba.pracodawca = Osoba.szef.pracodawca} Symbole, takie jak - - - - oraz - - - - > mogą być używane do wskazywania elementów, na które zostały nałożone ograniczenia. 0..1 Firma * {xor} Konto * należy do Osoba 0..1 podwładny Osoba * 0..1 1..* Firma pracownik pracodawca 0..1 szef ograniczenie w komentarzu

25. 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} {xor} {albo} {ordered} {uporządkowane} {subset} {podzbiór} {bag} {wielozbiór} {history} {historia} {hierarchy} {hierarchia} {dag} {graf acykliczny skierowany} dag - directed acyclic graph

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.

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 kontraktwiążą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.

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 require not full; do . . . ensure not empty; top=x; nb_elements=old nb_elements + 1 end; - push . . .

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 «postcondition» Tablica {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 } sortuj

30. OCL - Object Constraint Language (1) B A 1 aA aB * rB rA mB mA 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 Przykład Niech OAoznacza pewien obiekt klasy A, wtedy: • wyrażenie OA. aAzwróci wartość atrybutu aA • wyrażenie OA. rBzwróci zbiór obiektów klasy B powiązanych z danym obiektem OA

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

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

33. Zasada zamienialności a ograniczenia B m 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 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, powinno być takie same, jak gdyby komunikat wysłano do obiektu klasy A. 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.

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.