Projektowanie systemw informacyjnych Wykad 7 Model obiektowy 4
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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 1
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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 2
Dziedziczenie asocjacji (1) K 1 a K 1 K 2 K 3 a K 4 a K 2 K 3 K K Aby obie asocjacje a (diagram po lewej stronie) mogły zostać zastąpione jedną asocjacją a poprowadzoną od nadklasy K 1 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 K 1 (? ). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 3
Dziedziczenie asocjacji (2) Termin godz. Referat Nazwa dla klasy asocjacji ? {abstract} 1. . * tytuł autorzy[1. . *] wygłaszany 0. . 1 Zaproszony wygłaszany Termin godz. wygłaszany Zwykły ocena 1. . * 0. . 1 Sesja nazwa data 1 Termin godz. Wykorzystanie faktu, że asocjacje są dziedziczone spowodowało, że część informacji nie została przeniesiona na nowy diagram (zmiany oznaczono czerwonym kolorem). Aby zapobiec utracie informacji, do diagramu należałoby wprowadzić odpowiednie ograniczenia. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 4
Asocjacje pochodne Osoba 1. . * mieszka 1 pracownik 1. . * 0. . 1 ? 1 1 pracodawca Firma Miasto znajduje się 1. . * Możliwe asocjacje pochodne: /mieszka lub /znajduje się E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 5 1) Jeśli Osoba mieszka w mieście, w którym pracuje, to jedna z asocjacji: mieszka lub znajduje się albo powinna zostać oznaczona jako pochodna albo powinna być usunięta z diagramu. 2) Jeśli liczność roli pracodawca zmienimy na 0. . 1, to asocjacja mieszka nie będzie pochodna, ponieważ nie dla wszystkich obiektów powiązania mieszka będą mogły być wydedukowane. Podobnie, jeśli liczność roli pracownik zmienimy na *, to asocjacja znajduje się nie będzie pochodna.
Redukcja liczności Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu K 1 x y K 2 K 1 1 K a 1 a 2 K a 1 y a 2 x 1 K 2 gdzie: x, y oznaczają liczności wiele Przykład: Osoba 1. . * * Firma 1. . * Zatrudnienie Osoba stanowisko pensja E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 6 Zatrudnienie 1 stanowisko * pensja 1 1. . * * /pracodawca Firma
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: 1 K 1 r 1 * r 2 K 2 Rola r 2 jest tu rolą wielowartościową. Uwaga: W sensie dosłownym, liczności obu końców asocjacji oznaczają liczności obu ról. Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów opisanego daną rolą. § 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 » . a źle K 1 a 1. . 2 K 2 dobrze E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 7 : K 2 a : K 2 : K 1 {ordered} * a : K 1 a : K 2
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. pracuje 0. . 1 * Osoba {subset} Firma Nowak : Osoba IBM : Firma 0. . 1 1 jest dyrektorem pracuje Ograniczenie: {bag} Osoba : Zatrudnienie pracuje 1. . * {bag} * Firma X: Osoba Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 8 01. 1990 15. 12. 1995 programista 2000 pracuje : Zatrudnienie 01. 1998 NULL analityk 5000 Y: Firma
Role wielowartościowe (3) Stereotyp: «history» dla oznaczenia roli pracodawca Osoba * 1. . * «history» pracodawca Firma pracuje : Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja : Osoba 01. 1990 15. 12. 1995 programista 2000 pracuje : Zatrudnienie Stereotyp «history» – podobnie jak ograniczenie {bag} – pozwala na utworzenie więcej niż jednego powiązania (o danej semantyce) między dwoma obiektami; wykorzystywanie tego stereotypu jest ukierunkowane na rejestrowanie zmian w czasie. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 9 01. 1998 NULL analityk 5000 : Firma
Role wielowartościowe (4) Zatrudnienie Osoba 1 * data zatrudnienia data zwolnienia stanowisko pensja 1. . * 1 Firma : Zatrudnienie 01. 1990 15. 12. 1995 programista 2000 : Firma : Osoba 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 pozwala na uwidocznienie tego faktu. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 10 : Zatrudnienie 01. 1998 NULL analityk 5000
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, ponadto (jak każda asocjacja) może mieć atrybuty, np. Grupa * 1. . 15 Student Termin od do Ø agregacja jest wykorzystywana do modelowania związku całość-część Grupa * całość 1. . 15 część E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 11 Student
Agregacja (2) Inne nazwy dla ról agregacji: całość część askłada się z azawiera aobejmuje, itp. awchodzi w skład anależy ajest zawarta w, itp. Nazwa agregacji i nazwy jej ról, jako oczywiste, są z reguły (? ) pomijane. Własności agregacji: A B § 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 12
Agregacja (3) Kryteria służące analitykowi pomocą w podjęciu decyzji czy do modelowania pojęciowego wykorzystać agregację/kompozycję, 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, w drugą stronę ta reguła nie obowiązuje), § kryterium fizycznej części. zmień plan Grupa * 1. . 15 plan zmień plan Termin od do Student plan zmień plan Wszystkie kryteria zawiodły, a mimo to zastosowano agregację, gdyż 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. 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 (tzw. propagacja operacji). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 13
Agregacja rekursywna (1) Agregacja rekursywna ? K Obiekt klasy K może zarówno wchodzić w skład innych obiektów klasy K, jak i może zawierać obiekty klasy K. ? K 0. . 1 : K : K a 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 ? a Jakie zmiany wprowadziłoby do powyższego diagramu zastosowanie zwykłej asocjacji zamiast agregacji ? a Czy można tu zastosować kompozycję? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 14
Agregacja rekursywna (2) K 0. . 1 : K * : K : K : K a Czy można tu zastosować liczność dokładnie 1 zamiast 0. . 1 i liczność 1. . * zamiast liczności * ? a Czy można tu zastosować kompozycję? I Część 0. . 1 nazwa materiał rozmiary II Firma * 1 * Oddział 0. . 1 * b 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 15
Agregacja rekursywna (3) * K : K Czy tu można zastosować kompozycję? * : K : K : K Przykłady agregacji rekursywnych I Program 1. . * Instrukcja 0. . 1 złożona II 1 2 -gi operand * 1 -szy operand 1 Blok Instrukcja prosta a Jak wyglądałby diagram obiektowy dla wyrażenia, np. * (x + y/2) * (x/3 - y) Człon Wyrażenie operator binarny * Gdzie można by tu zastosować kompozycję – w I czy w II ? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 16 1 Zmienna nazwa Stała wartość
Asocjacja kwalifikowana (1) Katalog 1 Katalog nazwa pliku * Plik nazwa 1 0. . 1 { nazwa pliku jest unikatowa w ramach katalogu } 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). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 17
Asocjacja kwalifikowana (2) 1 Tablica 100 rząd kolumna przypisany do rząd kolumna 1 1 Kwalifikator asocjacji może być określony przez więcej niż jeden atrybut. Warunek – wartości tych atrybutów muszą pozwolić na jednoznaczną identyfikację obiektu/ grupy obiektów w ramach pewnego zbioru obiektów (tutaj – w ramach zbioru kwadratów przypisanych do jednej konkretnej tablicy, czyli do jednego obiektu klasy Tablica). Kwadrat przypisany do Kwadrat Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty. Bank * * nazwa Osoba imię nazwisko nr konta data założ. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 18 Bank nazwa nr. konta * 0. . 1 data założ. Osoba imię nazwisko
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, w sytuacji, 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 19
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). Znak « (lub » ) używany jest w charakterze cudzysłowia w jęz. francuskim (guillemets). (a) (c) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) (b) PióroŚwietlne lokacja: Punkt uruchom (Tryb) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) Ikona dla stereotypu (d) PióroŚwietlne 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 20
Stereotypy; przykłady P 1 «include» P 3 P 2 «extend» P 4 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 punkt 1: Punkt punkt 2: Punkt «konstruktory» Prostokąt (p 1: Punkt, p 2: Punkt) «zapytania» obszar () : Real aspekt() : Real «zapytania» obszar () : Real aspekt () : Real . . . «aktualizacje» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) «» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 21 Jednym stereotypem można opatrzyć całą listę elementów modelu. Koniec listy można oznaczyć poprzez «» .
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ść. ü 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}. 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 22
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). ograniczenie statyczne Pracownik {<=10 000} imię nazwisko {pensja nie wzrasta o nazwisko pensja więcej niż 300} pensja {<=10 000} zmień pensję (pensja) ograniczenie dynamiczne 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 23
Ograniczenia; przykłady Symbole, takie jak - - oraz - - > są używane do wskazywania elementów, na które zostały nałożone ograniczenia. 0. . 1 Firma Konto * {xor} * należy do 0. . 1 podwładny * 0. . 1 szef Osoba 1. . * pracownik {Osoba. pracodawca = Osoba. szef. pracodawca} E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 24 Osoba 0. . 1 pracodawca Firma ograniczenie w komentarzu
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} (suma logiczna) {xor} {albo} (różnica symetryczna) {ordered} {uporządkowane} {subset} {podzbiór} {bag} {wielozbiór} {hierarchy} {hierarchia} {dag} dag - directed acyclic graph {graf acykliczny skierowany} E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 25
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, specyfikowana w oparciu o atrybuty zdefiniowane w klasie będącej właścicielem operacji, określa warunek, który musi być spełniony dla wszystkich wystąpień tej klasy po poprawnym 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 26
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ć jak kontrakt wiążący daną operację i operacje wywołujące 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 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: musi minąć 2 lata od daty zwolnienia, ü warunek końcowy: dane pracowników, których to dotyczy, muszą zostać usunięte. 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, końcowe i inwarianty 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 27
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. . . invariant Inwarianty mogą przybierać wartość = FALSE jedynie w trakcie wykonywania operacji. 0 nb_elements; nb_elements max_size; empty = (nb_elements = 0) end; - class STACK E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 28
Przykład asercji w języku Eiffel (cd. ) Przykład 1: 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 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} E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 29
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 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: A a. A m. A 1 r. A B * a. B r. B m. B Niech o. A oznacza pewien obiekt klasy A, wtedy: § 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 30
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 stanowi nazwę wbudowanej w OCL funkcji na zbiorze, np. select, reject, size zbiór->select (warunek) zwraca podzbiór elementów 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 31 spełniających
OCL – Object Constraint Language (3) Przykłady: samolot. pilot->select (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 1 1. . * Pracownik 1 tytuł E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 32 * Raport
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 (ang. “demand no more, promise no less”). A m 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. 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 33
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 programistycznych. Ø 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 34
- Slides: 34