E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 1/18 Wykład 6 Model obiektowy (4) dr inż. Ewa Stemposz

Prezentacja na temat: "E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 1/18 Wykład 6 Model obiektowy (4) dr inż. Ewa Stemposz"— Zapis prezentacji:

1 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 1/18 Wykład 6 Model obiektowy (4) dr inż. Ewa Stemposz ewag@ipipan.waw.pl

2 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 2/18 Zagadnienia Design by Contract OCL Zasada zamienialności a ograniczenia Mechanizmy rozszerzalności:  Stereotypy  Wartości etykietowane  Ograniczenia

3 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 3/18 Rodzaje mechanizmów rozszerzalności 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 (?). Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne. Stereotypy rozszerzają semantykę metamodelu.

4 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 4/18 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Świetlne lokacja: Punkt uruchom (Tryb) PióroŚwietlne lokacja: Punkt uruchom (Tryb) PióroŚwietlne «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) ikona (a)(a)(b)(b) (c)(c) (d)(d) Znak « (lub ») używany jest w charakterze cudzysłowia w jęz. francuskim (guillemets).

5 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 5/18 Stereotypy; przykłady P1P2 « include » P3P4 « extend » rodzaj elementów modelu (kategoria modelowania): relacja między przypadkami użycia lista stereotypów dla tego rodzaju: «include», «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 długość : Odcinek szerokość : Odcinek «konstruktory» Prostokąt (p1: Punkt, p2: Punkt) «zapytania» obszar () : Real środek () : Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) « trwała » Prostokąt punkt1 : Punkt punkt2 : Punkt długość : Odcinek szerokość : Odcinek «konstruktory» Prostokąt (p1: Punkt, p2: Punkt) «zapytania» obszar () : Real środek () : Real... «» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) Jednym stereotypem można opatrzyć całą listę elementów modelu. Koniec listy można oznaczyć poprzez «».

6 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 6/18 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.

7 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 7/18 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 w pobliżu tego elementu, którego dotyczą. Ograniczenia można też umieszczać w komentarzu. {<=10 000} {pensja nie wzrasta o więcej niż 300} 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? ograniczenie statyczne ograniczenie dynamiczne Pracownik imię nazwisko pensja {<=10 000} Pracownik imię nazwisko pensja zmień pensję (nowa)

8 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 8/18 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..* pracownikpracodawca podwładny szef 0..1 * {osoba.pracodawca = osoba.szef.pracodawca} Osoba ograniczenie w komentarzu

9 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 9/18 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. angielskij. polski

10 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 10/18 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 oznacza błąd. Zwykle asercje są testowane jedynie podczas debuggowania. Design by Contract używa 3 rodzajów asercji:  warunek wstępny (ang. precondition) – definiuje, co powinno być spełnione, aby dana operacja wykonała się poprawnie (jak powinien wyglądać “świat sprzed”),  warunek końcowy (ang. 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 (ang. exception): wyjątek zachodzi przy spełnionym warunku wstępnym i niemożności spełnienia warunku końcowego.

11 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 11/18 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 operacje ją wywołujące. 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: minęło 2 lata od daty zwolnienia, warunek końcowy: dane zwolnionych pracowników 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.

12 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 12/18 Przykłady 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... 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.

13 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 13/18 Przykłady asercji na diagramach UML 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} 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 1:

14 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 14/18 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: element.selektor  selektor może być nazwą atrybutu (opisującego element) – wtedy zwracana jest albo pojedyncza wartość albo zbiór wartości atrybutu  selektor może być nazwą roli (celu) – wtedy zwracany jest zbiór powiązanych obiektów A aAaA mAmA B aBaB mBmB 1 * rArA rBrB  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:

15 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 15/18 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ść-zbioruwł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->sizezwraca liczność zbioru selfspecyfikuje aktualnie rozważany obiekt (może być opuszczony, gdy kontekst jest znany) operatornp.=,, =, <>, +, -, *, /, not, and, or, xor

16 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 16/18 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 Firma Pracownik tytuł Raport 1..* * 11

17 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 17/18 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, powinno być takie same, jak gdyby komunikat wysłano do obiektu klasy A.

18 E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 18/18 Podsumowanie  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.