Projektowanie systemw informacyjnych Wykad 4 Diagram klas cz

Projektowanie systemów informacyjnych Wykład 4 Diagram klas, cz. 2 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 1

Zagadnienia Atrybuty Operacje, metody, komunikaty Przesłanianie, przeciążanie Wiązanie dynamiczne Powiązania i asocjacje binarne Ekstensja klasy Typ Mocna kontrola typów Podtyp, własność zamienialności Typy masowe Rozszerzalność systemu typów Hermetyzacja, ukrywanie informacji ADT Delegacja Prototypy Dziedziczenie wielokrotne Role Dziedziczenie dynamiczne Klasy parametryzowane K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 2

Atrybuty (1) Atrybuty są nazwanymi wartościami przechowywanymi przez obiekty należące do danej klasy. nazwisko wiek atrybuty obiektów klasy Osoba Atrybut jest wartością, nie jest obiektem, co oznacza, że nie posiada tożsamości. Osoba nazwisko : string wiek : integer Klasa z atrybutami : Osoba Jan Nowak 53 Ewa Stycz 24 Obiekty (wystąpienia) z wartościami Atrybut unikalnie identyfikujący obiekt (klucz) nie jest wymagany, ponieważ każdy obiekt posiada tożsamość -. wewnętrzny unikalny identyfikator obiektu - automatycznie generowany przez system w momencie powoływania obiektu do życia i niewidoczny dla użytkownika. Zaleca się, by identyfikator nie miał znaczenia w dziedzinie problemu. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 3 Osoba Pesel : nr nazwisko : string wiek : integer

Atrybuty (2) Atrybuty mogą być: • proste - imię, nazwisko, płeć, wiek, stosunek do służby wojskowej • złożone - data ur. , adresy, lista poprz. miejsc pracy • opcjonalne - stosunek do służby wojsk, nazwisko panieńskie • powtarzalne - lista poprz. miejsc pracy • pochodne - wiek • klasy - adres firmy • atrybut będący obiektem - zdjęcie Atrybuty klasy należą do inwariantów danej klasy. Pracownik imię nazwisko panieńskie data ur. /wiek adres zamieszkania płeć stosunek do służby wojsk. [0. . 1] lista poprz. miejsc pracy [0. . *] adres firmy zdjęcie Kiedy z atrybutu warto zrobić klasę? W jakiej sytuacji atrybut adres firmy przestanie być atrybutem klasy? K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 4

Operacje, metody, komunikaty (1) Operacja jest funkcją lub transformacją, która może być zastosowana do obiektu. Jest ona własnością klasy obiektów. zatrudnij zwolnij wypłać dewidendę możliwe operacje na obiektach klasy Firma Wszystkie obiekty w ramach klasy podlegają tym samym operacjom. Dana operacja może być stosowana do obiektów wielu różnych klas => polimorfizm. Metoda jest implementacją operacji dla jednej klasy, czyli może być wiele metod implementujących daną operację. W momencie otrzymania komunikatu wywoływana jest metoda znajdująca się najbliżej obiektu, w sensie hierarchii dziedziczenia. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 5

Operacje, metody, komunikaty (2) Plik ASCII drukuj Plik postscript Jedna operacja drukuj, ale różne sposoby drukowania. Plik graficzny Plik {abstrakcyjna} Plik ASCII drukuj Plik postscript drukuj K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 6 Plik graficzny drukuj

Argumenty operacji Operacja/metoda może mieć argumenty (oprócz obiektu, który jest argumentem implicite). Sygnatura (specyfikacja) operacji włącza liczbę i typ argumentów + typ wyniku operacji. Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę (? ). Osoba nazwisko wiek zmień pracę zmień_adres operacje Plik nazwa_pliku długość w bajtach ostatnia_zmiana Obiekt geometryczny drukuj przesuń( delta: Wektor ) wewnątrz( p: Punkt ): Boolean obróć( kąt ) kolor pozycja Jeżeli argumenty nie są specyfikowane, to może ich być dowolnie dużo (również w ogóle). Brak specyfikacji argumentów na etapie analizy nie oznacza, że metoda ich nie posiada (być może tak jest), ale że w danym momencie nie interesujemy się nimi. zwolnij() - zero argumentów Cecha (własność) jest pojęciem ogólniejszym - obejmuje zarówno atrybut, jak i operację. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 7

Rodzaje metod Metody mogą być: • abstrakcyjne • obiektu - policz wiek, czy pracował w • klasy - znajdź najstarszego Klasa Pracownik nie posiada metod abstrakcyjnych, gdyż jako jedyna klasa na diagramie musi być klasą konkretną. Metody obiektu operują na atrybutach jednego obiektu, tego dla którego zostały wywołane. Obiekt stanowi argument domyślny dla tych metod. Metody klasy operują na ekstensji klasy, czyli na atrybutach wszystkich obiektów ekstensji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 8 Pracownik imię nazwisko data ur. /wiek adres zamieszkania płeć stosunek do służby wojsk. [0. . 1] lista poprz. miejsc pracy [0. . *] adres firmy policz wiek (imię, nazwisko) policz wiek czy pracował w (nazwa firmy) znajdź najstarszego

Przesłanianie (1) Przesłanianie (overriding) - metoda z klasy bardziej wyspecjalizowanej może przesłonić metodę z klasy bardziej ogólnej. Wybierana jest metoda znajdująca się najbliżej obiektu, w sensie hierarchii dziedziczenia. Pracownik nazwisko. . . zwolnij(). . . Decyzja o zwolnieniu w gestii dyrekcji Samodzielny prac. naukowy zwolnij() Decyzja o zwolnieniu w gestii sekretariatu PAN Metody mają identyczną sygnaturę (nazwa, argumenty, typ zwracanej wartości) ale mają inne implementacje (ciała). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 9

Przesłanianie (2) Bryła {abstrakcyjna} • Przesłanianie jest ściśle powiązane z polimorfizmem metod. • Przesłanianie jest ważnym elementem wspomagającym ponowne użycie. • Przesłanianie wymaga dynamicznego wiązania. pole podstawy wysokość {objętość = pole podstawy * wysokość} policz objętość {incomplete} Prostopadłościan Walec Stożek policz objętość {objętość = 1/3 pola podstawy * wysokość} 2 metody implementujące operację policz objętość. Metoda policz objętość w klasie Bryła nie może być metodą abstrakcyjną K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 10

Dynamiczne (poźne) wiązanie Wiązanie (binding): zamiana identyfikatora symbolicznego (nazwy) występującego w programie na wartość, adres lub wewnętrzny identyfikator elementu programistycznego (danej, zmiennej, procedury, . . . ) Wczesne (statyczne) wiązanie: przed uruchomieniem programu, podczas kompilacji i konsolid. Zalety: większa szybkość działania programu, możliwość pełnej statycznej kontroli typów. Wady: brak możliwości rozbudowy aplikacji podczas jej działania. Późne (dynamiczne) wiązanie: w czasie wykonania programu. Zalety: możliwość przesłaniania w trakcie działania aplikacji, możliwość komponowania programu w trakcie jego działania, szybkie przechodzenie od nowego pomysłu do efektu. Wady: wolniejsze działanie programu, utrudniona kontrola typów. Późne wiązanie jest nieodzownym warunkiem dla: • implementacji komunikatów (polimorfizmu) • dynamicznie tworzonych perspektyw • dynamicznie tworzonych procedur bazy danych • języków zapytań • migracji obiektów • ewolucji schematu BD K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 11

Przeciążanie (overloading) oznacza, że jakiś symbol (np. operatora czy funkcji) ma znaczenie zależne od kontekstu jego użycia, np. od składni lub ilości/typu argumentów. Np. przesuń (x, y), przesuń (x, y, z) - różna ilość argumentów przesuń (int, int), przesuń (float, float) - różne typy argumentów Powszechne jest przeciążanie operatora równości: = służy do porównania liczb całkowitych, liczb rzeczywistych, stringów, identyfikatorów, struktur, itd. Podobnie, operator + może oznaczać dodawanie lub konkatenację. Przeciążanie wymaga dynamicznego wiązania: znaczenie operatora można wydedukować na podstawie statycznej analizy tekstu programu. W odróżnieniu od przeciążania, przesłanianie jest własnością dynamiczną, nie zawsze da się wydedukować z tekstu programu. Niektórzy autorzy (np. Cardelli - propagator teorii typów polimorficznych) uważają, że przeciążanie jest polimorfizmem. Stwierdzenie “Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę”, leżące u podstaw idei polimorfizmu, jest sprzeczne z definicją przeciążania. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 12

Powiązania i asocjacje binarne Fizyczny lub pojęciowy związek między obiektami odpowiadający związkowi istniejącemu między bytami, w analizowanej rzeczywistości, modelowanymi przez te obiekty. Powiązanie Grupa powiązań posiadających wspólną strukturę i semantykę. Powiązanie jest wystąpieniem asocjacji. Asocjacja, która łączy dwie klasy nazywana jest binarną. Asocjacja Osoba imię pracuje_w : Osoba Ewa Kasia pracuje_w Firma rodzaj Klasy i asocjacja : Firma Krawiecka : Osoba Jasio pracuje_w : Firma Szewska Obiekty i powiązania Asocjacje mogą łączyć więcej niż dwie klasy (tzw. asocjacje n-arne), ale nie jest to zalecane. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 13

Liczność asocjacji Cecha o dużym znaczeniu informacyjnym w analizie (i modelowaniu w ogóle). Jeżeli asocjacja wiąże klasy A i B, to istotne jest: • jaka jest minimalna liczba obiektów B powiązana z jednym obiektem A, A -> B • jaka jest maksymalna liczba obiektów B powiązana z jednym obiektem A, A -> B • jaka jest minimalna liczba obiektów A powiązana z jednym obiektem B, B -> A • jaka jest maksymalna liczba obiektów A powiązana z jednym obiektem B, B -> A. Zwykle, minimalna liczba jest 0 lub 1, maksymalna zaś 1 lub * (dowolnie dużo). a) b) A A B A B A A B B B: min = 0, max = 1 A: min = 1, max = 2 a) A B K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 14 A B A A b) A 1, 2 A 2, 3 0. . 1 1. . 3 B B B: min = 1, max = 3 A: min = 2, max = 3 B

Asocjacja jako środek do modelowania związku generalizacji-specjalizacji Osoba {or} Student Pracownik 0. . 1 Student Osoba 0. . 1 Pracownik Osoba {overlapping} Student Pracownik 0. . 1 Student 0. . 1 Pracownik Kompozycja, jest znacznie lepszym środkiem niż asocjacja, do implementowania związku generalizacji -specjalizacji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 15

Ekstensja klasy (1) Termin ekstensja najczęściej oznacza specjalną strukturę danych, konkretny byt programistyczny dołączony do klasy. Ta struktura przechowuje wszystkie obiekty będące członkami danej klasy. Istnieje kilka definicji ekstensji klasy: I II jest to zbiór jedynie bezpośrednich wystąpień danej klasy, jest to zbiór wszystkich wystąpień danej klasy (bezpośrednich i pośrednich), ale obcięty do atrybutów wyspecyfikowanych w tej klasie, III jest to, jak poprzednio, zbiór wszystkich wystąpień danej klasy, ale bez obcinania atrybutów, które zostały wyspecyfikowane w podklasach tej klasy. K 1 {abstrakcyjna} I E 1 = {}, E 2 = {O 2}, E 3 = {O 3}, E 4 = {O 4} II E 1 = {O 2, O 3, O 4}, E 2 = {O 2}, E 3 = {O 3} E 4 = {O 4} K 2 K 3 K 4 O 2 O 3 O 4 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 16 III E 1 = {O 2, O 3, O 4}, E 2 = {O 2}, E 3 = {O 3} E 4 = {O 4}

Ekstensja klasy (2) Ekstensja klasy OSOBA NAZWISKO ROK_UR Wiek() : OSOBA NAZWISKO: Kowalska ROK_UR: 1975 OSOBA NAZWISKO: Nowak ROK_UR: 1951 OSOBA NAZWISKO: Abacki ROK_UR: 1948 OSOBA NAZWISKO: Nowacki ROK_UR: 1940 PRACOWNIK ZAROBEK DZIAŁ Zarobek. Netto() ZmieńZarobek(. . . ) Ekstensja klasy PRACOWNIK : PRACOWNIK NAZWISKO: Nowak ROK_UR: 1951 ZAROBEK: 2000 DZIAŁ: zabawki : PRACOWNIK NAZWISKO: Abacki ROK_UR: 1948 ZAROBEK: 2500 DZIAŁ: zabawki K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 17 : PRACOWNIK NAZWISKO: Nowacki ROK_UR: 1940 ZAROBEK: 3000 DZIAŁ: sprzedaż

Typ bytu programistycznego nakłada ograniczenia na jego budowę (lub argumenty i wynik) oraz ogranicza kontekst, w którym odwołanie do tego bytu może być użyte w programie. W wielu opracowaniach i językach (C++, Eiffel) typ jest utożsamiany z klasą. Wielu autorów uważa jednak te dwa pojęcia za różne. Klasa: przechowalnia inwariantów, implementacja metod. Typ: specyfikacja budowy obiektu, specyfikacja metod. Podstawowe zastosowanie klasy: modelowanie pojęciowe. Podstawowe zastosowanie typu: wspomaganie formalnej kontroli poprawności programów. Generalnie, na linii rozróżnień definicyjnych pomiędzy pojęciami: • klasa • typ • abstrakcyjny typ danych (ADT) • ekstensja panuje spore zamieszanie. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 18

Mocna kontrola typów oznacza, że każdy byt programistyczny (obiekty, zmienne, procedury, funkcje, metody, moduły, klasy, . . . ) podlega obowiązkowej specyfikacji typu. Każde odwołanie do tego bytu w programie jest sprawdzane na zgodność ze specyfikacją jego typu. Statyczna kontrola typu: kontrola tekstu programu (podczas kompilacji). Dynamiczna kontrola typu: kontrola typów podczasu wykonania. Zwykle mocna kontrola typu oznacza kontrolę statyczną. Kontrola dynamiczna jest znacznie mniej skuteczna, z dwóch powodów: • jest istotnym obciążeniem czasu wykonania, • błąd typu podczas wykonania jest takim samym błędem jak każdy inny, a rakieta przecież jest już w locie. . . Z drugiej strony, mocna statyczna kontrola typu powoduje znaczne zmniejszenie mocy języka programowania i jego elastyczności. (Np. jak napisać procedurę w Pascal’u, która mnoży dwie macierze o dowolnych rozmiarach? ) Własności takie jak: późne wiązanie, wartości zerowe, warianty, perspektywy, procedury bazy danych, dynamiczne klasy, etc. wymagają kontroli dynamicznej. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 19

Podtyp Dwie definicje: Ekstensja podtypu jest podzbiorem ekstensji typu. Np. zbiór liczb naturalnych jest podtypem zbioru liczb całkowitych. Typ B jest podtypem typu A, jeżeli B posiada więcej własności (atrybutów, metod, . . . ) niż A, innymi słowy B jest bardziej wyspecjalizowane niż A. struct Osoba {string Nazwisko; integer Rok_urodz; } struct Pracownik {string Nazwisko; integer Rok_urodz; integer Zarobek; }; Pracownik jest podtypem Osoba Innym (równoważnym) punktem widzenia na kwestię podtypowania jest założenie, że każdy obiekt może mieć wiele typów (swojej klasy podstawowej i wszystkich jej nadklas). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 20

Własność zamienialności Definiowanie relacji podtypu między typami posiada konkretny cel, który określa się jako zasadę zamienialności (substitutability): Jeżeli w jakimś miejscu programu (zapytania, . . . ) może być użyty byt typu A , to może tam być także użyty byt, którego typ jest podtypem typu A. Np. , jeżeli w jakimś miejscu programu może być użyty obiekt Osoba, to w tym samym miejscu może być użyty obiekt Pracownik. Wszędzie tam, gdzie może być użyta liczba całkowita można także użyć liczby naturalnej. Naturalnym uogólnieniem podanej definicji pojęcia podtypu jest uwzględnienie typu atrybutów. Jeżeli mamy dwa typy T 1 i T 2 zdefiniowane następująco: T 1 = struct {t 11 a 1; t 12 a 2; …; t 1 n an; } i T 2 = struct {t 21 a 1; t 22 a 2; …; t 2 m am; } gdzie m < n to warunkiem na to, by typ T 1 był podtypem typu T 2 jest, by: t 11 był podtypem t 21, t 12 był podtypem t 22, … (przy czym dowolny typ jest podtypem samego siebie). Ponieważ w modelu obiektowym składnikami typów nie są wyłącznie dane pasywne, ale i metody, podtypowanie obowiązuje również metody. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 21

Typy masowe Typy, dla których rozmiar bytu nie da się przewidzieć ani sensownie ograniczyć. Kolekcje (termin ODMG-93 przyjęty dla określenia typów masowych): Zbiory (sets): kolekcje elementów dowolnego, ale ustalonego typu, bez powtórzeń. Wielo-zbiory (multisets, bags): kolekcje elementów dowolnego ustalonego typu, elementy mogą się powtarzać. Sekwencje (sequences): uporządkowane kolekcje elementów dowolnego ustalonego typu; porządek ma znaczenie informacyjne, elementy mogą się powtarzać. Tablice dynamiczne (dynamic arrays): sekwencje, ale z dostępem poprzez indeks. Ortogonalność konstruktorów typu: typy masowe mogą być dowolnie kombinowane z dowolnymi innymi typami, np. zbiór sekwencji; obiekt, którego atrybutami są wielo-zbiory, itd. Popularne języki obiektowe nie mają typów masowych lub je ograniczają (Smalltalk, C++). Systemy przed-obiektowe nie są zgodne z zasadą ortogonalności konstruktorów typu. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 22

Rozszerzalność systemu typów ¨ Projektant ma do wyboru wiele konstruktorów typu (ortogonalna kombinacja). ¨ Nowy typ można zdefiniować na podstawie typu już istniejącego. Konstruktory typów: • typy atomowe: character, integer, float, string, boolean, bitmap, . . . • typy zapisów (records): struct {nazwa: string; waga: float; } • zbiory (sets): set of bitmap, set of struct {nazwa: string; waga: float; } • wielozbiory (bags): zbiory z powtórzeniami • sekwencje (sequences): wielozbiory uporządkowane • tablice (arrays): array of integer, array[5. . 30] of set of bitmap Definicja nowego typu na podstawie typu już zdefiniowanego: Typ. Części = struct {string nazwa; float waga; }; Typ. Relacji. Części = set of Typ. Części; Istotna możliwość ponownego użycia. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 23

Hermetyzacja, ukrywanie informacji Hermetyzacja: zgromadzenie elementów struktury i implementacji obiektu w postaci jednej manipulowalnej bryły; oddzielenie specyfikacji obiektu od jego implementacji. Hermetyzacja oznacza także ukrycie części struktury i implementacji obiektu. Tę własność określa się jako ukrywanie informacji. Hermetyzacja i ukrywanie informacji są różnymi pojęciami, ale mocno powiązanymi. Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o obiekcie programistycznym, ile mu trzeba, aby go efektywnie użyć. Wszystko, co może być przed nim ukryte, powinno być ukryte. Hermetyzacja i ukrywanie informacji jest podstawą pojęć modułu, klasy i ADT. Hermetyzacja ortodoksyjna (Smalltalk) Na zewnątrz są widoczne metody; atrybuty obiektu są ukryte. Ergo: prawie każdy atrybut atr jest obsługiwany przez dwie metody: czytaj_atr, zmień_atr K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 24 Hermetyzacja ortogonalna (C++) Dowolna własność obiektu (atrybut, metoda, . . . ) może być prywatna (ukryta) lub publiczna Specjalne środki do specyfikowanie własności prywatnych i publicznych.

Hermetyzacja ortogonalna Patrz Modula-2: dowolna własność może być prywatna, lub może być “wyeksportowana” do publicznego użytku. PRAC NAZWISKO Nowak ZAROBEK 2500 Zarobek. Netto() ROK_UR 1951 DZIAŁ Zabawki ZmieńZarobek(. . . ) Podatek() Wewnętrzna struktura obiektu Wiek() begin return Rok. Bież() - ROK_UR end; PRAC NAZWISKO Nowak ZAROBEK 2500 Zarobek. Netto() ROK_UR 1951 DZIAŁ Zabawki ZmieńZarobek(. . . ) Podatek() Wiek() - ROK_UR end; begin return Rok. Bież() K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 25 Zewnętrzna struktura obiektu

Abstrakcyjny typ danych Pojęcie udostępniane w niektórych językach programowania oparte na założeniu, że typ struktury danych jest skojarzony z operacjami działającymi na elementach tego typu. Nie istnieje potrzeba i możliwość używania operacji nie należących do oferowanego zestawu; operacje są kompletne i wyłączne. Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy. Abstrakcyjny typ danych jest bardzo bliski pojęciu klasy, której wystąpienia eksportują (niektóre) operacje, zaś ich struktura jest niedostępna dla operacji z zewnątrz. ADT ogranicza kontekst, w którym odwołanie do obiektu może być użyte w programie. ADT może odnosić się nie tylko do obiektów, ale również do wartości. Np. definiujemy typ abstrakcyjny Kamera. Wideo z operacjami: Włącz, Wyłącz, Nagrywaj, Stop, Bliżej, Dalej, PrzewińWTył, Odtwarzaj, . . . Zestaw tych operacji jest stosunkowo nieliczny, wewnętrzna budowa obiektu jest bardzo złożona (zawiera tysiące atrybutów), ale niezbyt interesująca z punktu widzenia operacji zewnętrznych. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 26

Delegacja - alternatywa dla dziedziczenia Operacje na obiekcie są oddelegowane do innego obiektu. Lista. . . pierwszy następny ostatni dodaj usuń Stos push pop Stos zawartość push pop Lista. . . pierwszy następny ostatni dodaj usuń Obiekt “Stos” niepotrzebnie dziedziczy operacje z klasy “Lista” K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 27 Obiekt klasy Stos składa się z podobiektu zawartość, członka klasy Lista. Anomalia dziedziczenia jest usunięta. Obsługa obiektu Stos jest (częściowo) oddelegowana do obiektu Lista. Delegacja to alternatywa dla dziedziczenia. Dziedziczenie (importowanie inwariantów) zachodzi w ramach wystąpień klas (obiektów) dynamicznie (w czasie działania programu). Część własności danego obiektu (np. metody) jest przechowywana w innej klasie.

Prototypy (1) Pojęcie ściśle powiązane z delegacją. Dowolny obiekt może stać się prototypem. Pod pojęciem prototypu rozumie się zarówno obiekt jako wzorzec dla innego obiektu (przy tworzeniu nowego obiektu jako kopii innego, już istniejącego) jak i to, że informacje z obiektu-prototypu są dynamicznie (w czasie działania programu) dostępne dla innych obiektów. W ten sposób uzyskuje się jednorodność i zminimalizowanie środków: potrzebne są wyłącznie obiekty oraz wskaźniki (powiązania) od obiektów do ich prototypów. Te powiązania między obiektami są przchodnie; obiekty mogą być powiązane w hierarchię. Koncepcja prototypów jest dość uniwersalna i pozwala modelować klasy, dziedziczenie wielokrotne i role. Koncepcja wizjerów idzie dalej - wskaźnik prowadzący do obiektu prototypu może być dodatkowo zaopatrzony w filtry, ustalające, co ma być importowane. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 28

Prototypy (2) Udostępnianie informacji z prototypu Ulubieniec Łapy: 4 Ogon: 1 Uszy: 2 Oczy: 2 Języki prototypowe (np. Self) nie wprowadzają pojęcia klasy. Obiekt może dziedziczyć cokolwiek z jakiegokolwiek innego obiektu. Szczepienie() Prototyp Kot Pies Wabi_się: Rex Wabi_się: Mrusia Rasa: nieznana Rasa: jamnik Płeć: M Płeć: Ż Uszy: 1 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 29 Podstawowym argumentem zwolenników prototypów jest zmniejszenie liczby pojęć. Koncepcja prototypów jest nieunikniona, jeżeli ktoś chciałby implementować dynamiczne role obiektów. Pojęcie klasy ma jednak ogromne znaczenie dla modelowania pojęciowego, stąd pojęcia prototypu i klasy uzupełniają się.

Wielokrotne dziedziczenie Klasa dziedziczy inwarianty z więcej niż jednej klasy, które nie są zależne Osoba Nazwisko Aga: Osoba Pracownik Student Zarobek Nr_indeksu Kazio: Osoba Jola: Osoba Pracujący_ student Adam: Osoba Basia: Osoba K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 30 Krzyś: Osoba Kasia: Osoba

Problemy wielokrotnego dziedziczenia Pojazd lądowy max_prędkość prędk_eksploat() Samochód {prędkość eksploatacyjna wynosi 50% prędkości maksymalnej} Pojazd wodny max_prędkość prędk_eksploat() Amfibia Jacht Konflikt nazw: Który atrybut max_prędkość ma odziedziczyć amfibia? Czy znaczenie metody prędk_eksploat() zależy od ścieżki dziedziczenia? (O 2: mechanizm zmiany nazwy dziedziczonej cechy; Eiffel: konflikt jest traktowany jako błąd. ) Kontrola typu: Jaki będzie wynikowy typ obiektów Amfibia? Najczęściej wielo-dziedziczenie jest konsekwencją braku koncepcji ról K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 31

Role Źle! Student jest Osobą Osoba staje się Studentem Każdy obiekt w czasie swojego życia może nabywać i tracić wiele ról, nie zmieniając swojej tożsamości. Role zmieniają się dynamicznie. Osoba Kowalski Właściciel psa Podatnik Pracownik Student Członek klubu golfowego Pacjent Kibic Legii • Rola importuje wartości atrybutów obiektu oraz inwarianty jego klasy • Rola może mieć własne (dodatkowe) atrybuty • Rola może należeć do własnej klasy K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 32

Role - przykład Kowalska: pracownik Nowak: pracownik+student Abacka: Nowacki: student OSOBA NAZWISKO ROK_UR Wiek() : OSOBA NAZWISKO: Kowalska ROK_UR: 1975 : OSOBA NAZWISKO: Nowak ROK_UR: 1951 PRACOWNIK ZAROBEK DZIAŁ Zarobek. Netto() ZmieńZarobek(. . . ) : PRACOWNIK ZAROBEK: 2000 DZIAŁ: zabawki : PRACOWNIK ZAROBEK: 2500 DZIAŁ: zabawki : OSOBA NAZWISKO: Abacka ROK_UR: 1948 : OSOBA NAZWISKO: Nowacki ROK_UR: 1940 STUDENT NR_INDEKSU INDEKS Wpisz. Ocenę(. . . ) ObliczŚredniąOcen() : STUDENT NR_INDEKSU: 223344 INDEKS: . . . rola : STUDENT NR_INDEKSU: 556677 INDEKS: . . . Rola importuje nie tylko inwarianty swojej klasy, lecz także wartości atrybutów swojego obiektu i inwarianty jego klasy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 33

Dziedziczenie dynamiczne Kobieta Mężczyzna <<dynamic>> zawód Manager Osoba Inżynier płeć {mandatory} Sprzedawca 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. Tu można by wykorzystać dynamiczne role. mandatory - obowiązujący, obowiązkowy dynamic - dynamiczny W ogólności, dyskryminator dynamiczny może być związany z dziedziczeniem nierozłącznym, (overlapping). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 34

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 <Pracownik> Aktualny parametr Zbiór wstaw (T) usuń (T) T <<bind>> <Pracownik> Zbiór Pracowników szablon Podstawowe zastosowanie klas parametryzowanych polega na wykorzystaniu ich do definiowania zbiorów (kolekcji). Każde wystąpienie klasy Zbiór Pracowników jest zbiorem. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 4, Folia 35