Projektowanie systemów informacyjnych Wykład 8 Model obiektowy (5) Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Zagadnienia ADT Delegacja Protytypy Role Transformacje diagramu klas: Podział poziomy klasy Podział pionowy klasy Obejście dziedziczenia typu: disjoint overlapping dynamic Obejście dziedziczenia wielokrotnego i wieloaspektowego

Abstrakcyjny typ danych Abstrakcyjny typ danych (ADT) - 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. Z drugiej strony, ADT może być uważane za pojęcie znacznie węższe lub ortogonalne w stosunku do pojęcia klasa. W czystej postaci, ADT nie uczestniczy w związkach dziedziczenia, wystąpienia ADT nie posiadają tożsamości, nie można ich wzajemnie łączyć (powiązaniami), ani wykonywać operacji na zbiorze wystąpień ADT (brak odpowiednika metody klasy). Przykłady ADT stos (z operacjami: pop, push, top, empty), pakiety obsługujące: mysz, CD ROM, grafikę, heap

Delegacja - alternatywa dla dziedziczenia Lista Operacje na obiekcie są oddelegowane do innego obiektu. zawartość push pop top Stos pierwszy następny ostatni dodaj usuń 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. Lista pierwszy następny ostatni dodaj usuń push pop Stos Delegacja to alternatywa dla dziedziczenia: w tym przypadku dziedziczenie, czyli importowanie inwariantów zachodzi dynamicznie (w czasie działania programu) w ramach wystąpień klas (obiektów). Część własności danego obiektu (np. metody) jest przechowywana w innej klasie. Obiekt “Stos” dziedziczy niepotrzebne mu operacje z klasy “Lista”

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), 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ą przechodnie; obiekty mogą być powiązane w hierarchię. Koncepcja prototypów jest dość uniwersalna i pozwala modelować klasy, dziedziczenie, 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.

Prototypy (2) Prototyp Łapy: 4 Ogon: 1 Uszy:2 Oczy:2 Ulubieniec Szczepienie() Wabi_się: Rex Rasa: jamnik Płeć: M Pies Wabi_się: Mrusia Rasa: nieznana Płeć: Ż Kot Uszy:1 Języki prototypowe (np. Self) nie wprowadzają pojęcia klasy. Obiekt może dziedziczyć cokolwiek z jakiegokolwiek innego obiektu. 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, jako przechowalni inwariantów, ma jednak ogromne znaczenie dla modelowania pojęciowego, stąd pojęcia prototypu i klasy uzupełniają się.

Role Osoba staje się Studentem Student jest Osobą Źle! 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 Członek klubu golfowego Kibic Legii Podatnik Pracownik Student Pacjent 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

Role - przykład NAZWISKO ROK_UR Wiek() OSOBA Kowalska: pracownik Nowak: pracownik+student Abacka: Nowacki: student NAZWISKO: Kowalska ROK_UR: 1975 :OSOBA NAZWISKO: Nowak ROK_UR: 1951 :OSOBA NAZWISKO: Abacka ROK_UR: 1948 :OSOBA NAZWISKO: Nowacki ROK_UR: 1940 :OSOBA ZAROBEK DZIAŁ ZarobekNetto() ZmieńZarobek(...) PRACOWNIK NR_INDEKSU INDEKS WpiszOcenę(...) ObliczŚredniąOcen() STUDENT rola :PRACOWNIK ZAROBEK: 2000 DZIAŁ: zabawki :PRACOWNIK ZAROBEK: 2500 DZIAŁ: zabawki NR_INDEKSU:223344 INDEKS:...... :STUDENT NR_INDEKSU:556677 INDEKS:...... :STUDENT Rola importuje nie tylko inwarianty swojej klasy, lecz także wartości atrybutów swojego obiektu oraz inwarianty jego klasy.

Podział poziomy klasy (podział ekstensji klasy) Osoba imię nazwisko nazwa szkoły wysokość emerytury pensja podaj nazwisko podaj szkołę zmień emeryturę zmień pensję Firma nazwa 0..1 zatrudnia * Przykład Osoba imię nazwisko podaj nazwisko Firma 1 zatrudnia nazwa Uczeń imię nazwisko nazwa szkoły podaj nazwisko podaj szkołę Emeryt imię nazwisko wysokość emerytury podaj nazwisko zmień emeryturę Pracownik imię nazwisko pensja podaj nazwisko zmień pensję *

Podział pionowy klasy (podział inwariantów klasy) np. a1 a2 a3 a K1 K21 K22 a1 a2 a3 m1 m2 m3 m2 m3 m1 Przykład Klient * zlecił * Klient zlecił Firma nazwa adres firmy telefon firmy [1..*] imię dyrektora nazwisko dyrektora adres dyrektora telefon dyrektora Osoba imię nazwisko adres telefon podaj telefon Firma nazwa adres telefon [1..*] zmień adres 1..* 1 0..1 dyrektor 1..* zmień adres firmy podaj telefon dyrektora

Obejście dziedziczenia typu disjoint Osoba Nowak Osoba Kowalski 0..1 {xor} 0..1 Student Pracownik Student Pracownik perspektywa projektowa perspektywa pojęciowa Nowak:Student Nowak:Osoba Kowalski:Osoba Kowalski:Pracownik Nowak:Student Kowalski:Pracownik

Obejście dziedziczenia typu overlapping Zamiast kompozycji można tu użyć zarówno agregacji, jak i zwykłej asocjacji. Nowak Osoba {overlapping} Kowalski Osoba Student Pracownik Abacki 0..1 0..1 Student Pracownik Abacki:Osoba Nowak:Osoba Kowalski:Osoba Abacki:Student Nowak:Student Kowalski:Pracownik Abacki:Pracownik

Obejście dziedziczenia typu dynamic Osoba {abstract} Przy zmianie specjalizacji Osoby powstaje nowy obiekt z którejś z trzech podklas: Menażer, Analityk czy Projektant. Własności odziedziczone z klasy Osoba są każdorazowo przepisywane. {dynamic} Menażer Analityk Projektant W drugim przypadku, usuwany jest obiekt związany ze starą specjalizacją, tworzony jest obiekt przechowywujący własności związane z nową specjalizacją oraz tworzone jest powiązanie między nowym obiektem a obiektem klasy Osoba, przechowującym dane osobowe. W tym przypadku klasa Osoba nie może być klasą abstrakcyjną. Osoba {xor} 0..1 0..1 0..1 Menażer Analityk Projektant

Obejście dziedziczenia wielokrotnego Osoba Student Pracownik Student/Pracownik Osoba 0..1 0..1 Student Pracownik

Dziedziczenie wielokrotne i wieloaspektowe Są konieczne, ale często komplikują pielęgnację oprogramowania. Obejście ich braku może odbyć się jeszcze na poziomie modelu obiektowego. Można też bezpośrednio zastosować metody zaproponowane dla obejścia braku dziedziczenia. Przykład: Pracownik Osoba Emeryt status płacowy stosunek do emerytury Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Pracownik godzinowy nie emerytowany Osoba specjalizacje wg płac specjalizacje wg emerytury

Delegacja z użyciem ról Pracownik Osoba Emeryt Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Osoba Pracownik Emeryt Specjalizacje wg płac Specjalizacje wg emerytury

Użycie dziedziczenia i delegacji Dziedziczenie Delegacja Pracownik Osoba Emeryt Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Osoba Emeryt Specjalizacje wg emerytury Specjalizacje wg płac

Zagnieżdżona generalizacja Permutacja klas Pracownik status płacowy Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie stosunek do emerytury stosunek do emerytury stosunek do emerytury Pracownik godzinowy nie emerytowany Pracownik godzinowy emerytowany Pracownik etatowy nie emerytowany Pracownik etatowy emerytowany Pracownik na zlecenie nie emerytowany Pracownik na zlecenie emerytowany

Zalecenia Jeżeli klasa ma kilka nadklas, wszystkie jednakowo ważne, najlepiej użyć delegacji, która zachowuje symetrię modelu. Jeżeli jedna nadklasa wyraźnie dominuje, ma zdecydowanie więcej cech niż pozostałe lub może powodować wąskie gardło w wydajności, zaś inne wydają się być mniej ważne, tę jedną zaimplementować poprzez dziedziczenie, zaś pozostałe przez delegację. Jeżeli liczba kombinacji klas jest mała, można rozpatrywać zagnieżdżoną generalizację (permutację klas). Przy zagnieżdżonej generalizacji, najważniejszy czynnik powinien być pierwszym kryterium podziału; pozostałe dalej, w hierarchii ważności. Unikać zagnieżdżonych generalizacji, jeżeli duża ilość kodu musi być powtórzona. Te zalecenia mogą okazać się nieistotne o ile zdecydujemy się bezpośrednio obejść brak dziedziczenia wielokrotnego i wieloaspektowego metodami takimi samymi, jak dla obejścia dziedziczenia.