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

Slides:



Advertisements
Podobne prezentacje
Związki w UML.
Advertisements

Modelowanie klas i obiektów
Wzorce.
Projektowanie systemów informacyjnych
Wykład 10 Metody Analizy Programów Specyfikacja Struktur Danych
Projektowanie systemów informacyjnych
Sposoby obejścia dziedziczenia
Mapowanie dziedziczenia z UML do Java
Elementarne struktury danych Piotr Prokopowicz
Programowanie obiektowe w Javie
Bartosz Walter Prowadzący: Bartosz Walter
08: ERD – podencje, łuki i pułapki
Mapowanie różnych typów dziedziczenia do Javy
C++ wykład 2 ( ) Klasy i obiekty.
Zasady zaliczenia Warunki uzyskania zaliczenia:
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
Unified Modeling Language Wykład 3 Diagram klas
Mechanizmy dziedziczenia
Projektowanie systemów informacyjnych
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 8, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Projektowanie - klasy i związki
Infrastruktura języka UML w wersji 2.2
Nadstruktura języka UML w wersji 2.2
Źródła: podręcznikopracował: A. Jędryczkowski.
Jakub Wołczko W obiektowym świecie… Jakub Wołczko
OMT - Model obiektów, cz.1.
Programowanie obiektowe III rok EiT
Dziedziczenie Maciek Mięczakowski
Programowanie obiektowe Wykład 6 dr Dariusz Wardowski, Katedra Analizy Nieliniowej, WMiI UŁ 1/14 Dariusz Wardowski.
Języki i środowiska programowania systemów rozproszonych, Wykład 03, Slajd Języki i środowiska programowania systemów rozproszonych Wykładowca:
Programowanie obiektowe – język C++
OMT - Model obiektów, cz.2.
Notacja w UML Klasy.
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
2 Odizolowanie danych od kodu może prowadzić do przypadkowych zmian danych przez funkcje, które nie są z nimi logicznie związane. Ponadto modyfikacja.
Modelowanie obiektowe Diagramy klas
Programowanie w języku C++
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Model obiektowy bazy danych
Diagram przypadków użycia
Diagram klas Kluczowymi elementami są: klasy (class)
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 8, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.
Geneza obiektowości Obiektowość jest stosunkowo nową ideologią, która wynika z zaobserwowanych wad istniejącego świata i podaje jakąś receptę, jak te wady.
Programowanie Zaawansowane
Modelowanie model związków encji
Partnerstwo dla Przyszłości 1 Lekcja 28 Dziedziczenie i rodzaje dziedziczenia.
Wstęp do systemów informatycznych Diagramy klas. Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie 
E. Stemposz. UML i Analiza Obiektowa, Wykład 4, Slajd 1/20 Wykład 4 Model obiektowy (2) dr inż. Ewa Stemposz
E. Stemposz. UML i Analiza obiektowa, Wykład 6, Slajd 1/18 Wykład 6 Model obiektowy (4) dr inż. Ewa Stemposz
E. Stemposz. Wprowadzenie do UML, Wykład 1, Slajd 1/24 Wykład 1 Wprowadzenie do UML dr inż. Ewa Stemposz
E. Stemposz. UML, Diagramy komponentów i wdrożeniowe, Wykład 11, Slajd 1/24 Wykład 11 Diagramy komponentów i wdrożeniowe dr inż. Ewa Stemposz
Projektowanie systemów informacyjnych
Programowanie Obiektowe – Wykład 6
Klasy, pola, obiekty, metody. Modyfikatory dostępu, hermetyzacja
(według:
Zbiory rozłączne.
Projektowanie systemów informacyjnych
Programowanie Obiektowe – Wykład 2
Projektowanie systemów informacyjnych
PGO Interfejsy Michail Mokkas.
PGO Dziedziczenie Michail Mokkas.
PGO Przeciążanie metod i konstruktorów
Zapis prezentacji:

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

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

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:

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

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.

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

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

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»

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

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

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}

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

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

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

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?

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

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.

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