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

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

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

2 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 2/18 Zagadnienia Rozszerzenia i ograniczenia w podklasie Interfejs, zależność, realizacja Klasa parametryzowana Klasa Dziedziczenie:  jednoaspektowe  wieloaspektowe  jednokrotne  wielokrotne  kompletne  niekompletne  elipsa  dynamiczne

3 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 3/18 Klasa; notacja (1) Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości. Okno rozmiar czy widoczne Okno rozmiar czy widoczne wyświetl schowaj Okno Rozmiar : Obszar czy widoczne : Boolean wyświetl() schowaj() stereotyp nazwa_ klasy lista_wart_etyk Pole atrybutów: stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etyk Pole metod: stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykt Pole nazwy klasy:

4 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 4/18 Klasa; notacja (2) gdzie: rodzaj definiuje sposób, w jaki metoda korzysta z danego argumentu: in: metoda może czytać argument, ale nie może go zmieniać out: może zmieniać, nie może czytać inout: może czytać i zmieniać Wszystkie elementy specyfikacji klasy, za wyjątkiem nazwy klasy, są opcjonalne. Nazwa klasy to z reguły rzeczownik w liczbie pojedynczej. dostępność jest określana przez trzy symbole: + publiczna - prywatna # chroniona lista_arg: rodzaj nazwa_arg : typ = wart_początkowa

5 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 5/18 Przykłady klas Okno {abstrakcyjna, autor=Kowalski status=przetestowane} +rozmiar: Obszar = (100,100) #czy_widoczne: Boolean = false +rozmiar_domyślny: Prostokąt #rozmiar_maksymalny: Prostokąt -xwskaźnik: XWindow* +wyświetl() +schowaj() +utwórz() -dołączXWindow(xwin: XWindow*) « trwała » Prostokąt punkt1: Punkt punkt2: Punkt «konstruktor» Prostokąt(p1: Punkt, p2: Punkt) «zapytania» obszar(): Real aspekt(): Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real) Stereotypy zostały tu użyte do metaklasyfikacji klas i metod.

6 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 6/18 Dziedziczenie (1) Dziedziczenie pozwala na tworzenie drzewa klas lub innych struktur bez pętli. specjalizacja generalizacja Pracownik Osoba AsystentAdiunkt ProfesorDocentAsystentAdiunkt ProfesorDocent Pracownik Osoba

7 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 7/18 Dziedziczenie (2) Struktura typu pętla Jest zabroniona Struktura typu krata jest dopuszczalna K2K2 K1K1 K3 Student Osoba Student_asystent Pracownik

8 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 8/18 Dziedziczenie (3) NAZWISKO ROK_UR Wiek() ZAROBEK DZIAŁ FOTO ZarobekNetto() ZmieńZarobek(...) NR_INDEKSU WYDZIAŁ WstawOcenę(...) ZaliczSemestr() JPEG GIF GRAFIKA ROZMIAR Wyświetl(...) Atrybut PRACOWNIKa FOTO jest obiektem należącym do klasy JPEG. Atrybut PRACOWNIKa FOTO jest obiektem należącym do klasy JPEG. OSOBA STUDENTPRACOWNIK «instanceOf»

9 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 9/18 Dziedziczenie (4) powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie typ wyposażenia typ pompy typ zbiornika aspekt specjalizacji (dyskryminator) Wyposażenie nazwa wytwórca koszt Dyskryminator jest atrybutem opcjonalnym Wymiennik ciepła ciśnienie ssania ciśnienie tłoczenia przepływ Pompa

10 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 10/18 Dziedziczenie (5) Wyposażenie nazwa wytwórca koszt ciśnienie ssania ciśnienie tłoczenia przepływ powierzchnia wymiany średnica rury objętość ciśnienie typ wyposażenia ciśnienie ssania ciśnienie tłoczenia przepływ powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie typ wyposażenia Wyposażenie nazwa wytwórca koszt PompaWymiennik ciepła

11 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 11/18 Dziedziczenie wieloaspektowe Drzewo Dąb BrzozaSosna gatunek drzewa {disjont} (domyślne) – podział rozłączny {overlapping} – podział nierozłączny, przecięcie zbiorów obiektów klas, np. Pojazd lądowy i Pojazd wodny, nie jest zbiorem pustym; {complete} – podział całkowity {incomplete} (domyślne) – podział niecałkowity; niektóre klasy, np. te nieistotne dla rozważanego problemu, nie zostały jeszcze zdefiniowane; elipsa, opuszczenie (notacja... ) – podklasy, nieistotne dla rozważanego problemu, zostały pominięte na diagramie (nie narysowane); Dla dziedziczenia wieloaspektowego aspekty dziedziczenia nie mogą być opuszczane. Pojazd {overlapping, complete} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny napęd teren {overlapping, complete} 2 aspekty: napęd i teren... {disjoint, incomplete}

12 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 12/18 Dziedziczenie wielokrotne; wielodziedziczenie Dziedziczenie wielokrotne ma miejsce, gdy klasa dziedziczy inwarianty z więcej niż jednej nadklasy. Nazwisko Osoba Pracownik Zarobek Student Nr_indeksu Pracujący student

13 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 13/18 Problemy dziedziczenia wielokrotnego Kontrola typu: Jaki będzie wynikowy typ obiektów Amfibia? Konflikt nazw: Który atrybut max_prędkość ma odziedziczyć amfibia? Czy znaczenie metody prędk_eksploat() zależy od ścieżki dziedziczenia? (O2: mechanizm zmiany nazwy dziedziczonej cechy; Eiffel: konflikt jest traktowany jako błąd.) Pojazd {prędkość eksploatacyjna wynosi 50% prędkości maksymalnej} max_prędkość prędk_eksploat() AmfibiaSamochódJacht prędk_eksploat() Pojazd lądowyPojazd wodny

14 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 14/18 Dziedziczenie dynamiczne Osoba Manager Inżynier Sprzedawca Kobieta Mężczyzna {mandatory} płeć «dynamic» Osoba może zmieniać zawód, co można modelować poprzez tzw. dziedziczenie dynamiczne. Przydatne dla modelowania koncepcyjnego, ale może być trudne w implementacji. mandatory – obowiązujący, obowiązkowy W ogólności, dyskryminator dynamiczny może być związany z dziedziczeniem nierozłącznym (overlapping). zawód Dyskryminator zawód został tu opatrzony stereotypem « dynamic ».

15 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 15/18 Rozszerzenia i ograniczenia w podklasie Podklasa nie może omijać lub zmieniać atrybutów nadklasy. Podklasa może zmienić ciało metody z nadklasy, ale bez zmiany jej specyfikacji. Podklasa może dowolnie dodawać nowe atrybuty i metody (rozszerzać zbiór własności nadklasy). Podklasa może ograniczać wartości atrybutów. Np. Koło jest podklasą klasy Elipsa, gdzie obie średnice elipsy są sobie równe. Ograniczenia mogą spowodować, że część metod przestanie być poprawna. Np. zmiana jednej ze średnic obiektu – dozwolona dla obiektu klasy Elipsa – jest niedopuszczalna w obiekcie podklasy Koło, gdyż muszą tam być zmienione obie średnice. Czy Koło powinno być podklasą klasy Elipsa czy też powinno być odwrotnie?

16 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 16/18 Interfejs, zależność, realizacja (1) Notacja dla realizacji (ang. realization) jest podobna do notacji dla dziedziczenia. Stereotyp « interface » poprzedza nazwę klasy, która zawiera jedynie specyfikacje metod, bez ich implementacji. W UML interfejs nie zawiera atrybutów, a wszystkie metody są publiczne. Implementacje metod wyspecyfikowanych w interfejsie Ipracownik zawiera klasa Pracownik. Zależność (ang. dependency) wskazuje na klasę, która korzysta z danego interfejsu. Osoba {abstract} Pracownik IPracownik « interface » Firma

17 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 17/18 Interfejs, zależność, realizacja (2) Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. Pracownik IPracownik Osoba Firma Klasa abstrakcyjna i interfejs zostały tu potraktowane w podobny sposób – jako definicje interfejsów do klasy Pracownik. Jednakże, istnieje między nimi pewna różnica: klasa abstrakcyjna, w przeciwieństwie do interfejsu, może zawierać atrybuty i implementacje metod.

18 E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 18/18 Klasa parametryzowana Klasy parametryzowane, posiadające duży potencjał ponownego użycia, są użyteczne z dwóch powodów: podnoszą poziom abstrakcji i wpływają na zmniejszenie długości kodu źródłowego programu. Klasa parametryzowana może być wstawiana do diagramów UML na dwa sposoby: Zbiór wstaw (T) usuń (T) T Zbiór Pracowników «bind» Zbiór Podstawowe zastosowanie klas parametryzowanych polega na wykorzystaniu ich do definiowania zbiorów (kolekcji). Każdy obiekt klasy Zbiór Pracowników jest zbiorem. aktualny parametr szablon