Projektowanie systemów informacyjnych

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

2. Zagadnienia ADT Delegacja Protytypy Role Transformacje diagramu klas: • Podział poziomy klasy • Podział pionowy klasy • Realizacja struktur generalizacji/specjalizacji typu: disjoint overlapping dynamic • Generalizacja wieloaspektowa

3. 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 nie jest dostępna bezpośrednio 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 ekstensji i metody klasy). Przykłady ADT stos (z operacjami: pop, push, top, empty), pakiety obsługujące: mysz, CD ROM, grafikę, heap

4. Delegacja - alternatywa dla dziedziczenia Operacje na obiekcie są oddelegowane do innego obiektu. Lista Stos zawartość push pop ... pierwszy następny ostatni dodaj pobierz Obiekt klasy Stosskł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 pobierz 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. Stos push pop Klasa “Stos” dziedziczy niepotrzebne operacje z klasy “Lista”

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

6. Prototypy (2) Ulubieniec Łapy: 4 Ogon: 1 Uszy:2 Oczy:2 Szczepienie() Prototyp Kot Pies Wabi_się: Mrusia Wabi_się: Rex Rasa: nieznana Rasa: jamnik Płeć: Ż Płeć: M 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ę.

7. Role Źle! Osoba staje sięStudentem Student jest Osobą 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 Pacjent Student Pracownik • 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

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

9. Podział poziomy klasy (podział ekstensji klasy) K2 a1 a2 m1 m2 Firma nazwa 0..1 Osoba imię nazwisko zatrudnia Osoba imię nazwisko nazwa szkoły wysokość emerytury pensja podaj nazwisko Uczeń Emeryt Pracownik imię nazwisko nazwa szkoły imię nazwisko pensja imię nazwisko wysokość emerytury * podaj nazwisko podaj szkołę zmień emeryturę zmień pensję podaj nazwisko podaj szkołę podaj nazwisko zmień pensję podaj nazwisko zmień emeryturę K1 a ? a ? K21 K22 a K1 a1 ? a2 ? a1 ? a2 ? m1 ? m2 ? m1 ? m2 ? Przykład Firma zatrudnia 1 nazwa *

10. Podział pionowy klasy (podział inwariantów klasy) Osoba Firma nazwa adres telefon [1..*] imię nazwisko adres telefon zmień adres podaj telefon K1 a K2 np. a1 a2 a3 a K1 K21 K22 a2 a3 a1 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 1..* 0..1 1 dyrektor 1..* zmień adres firmy podaj telefon dyrektora

11. Realizacja struktur generalizacji/specjalizacji (1) Student Pracownik Student Pracownik perspektywa pojęciowa: generalizacja/specjalizacja perspektywa projektowa: dziedziczenie perspektywa projektowa: kompozycja Zamiast kompozycji można tu użyć zarówno agregacji, jak i zwykłej asocjacji. Osoba {abstract} Nowak Kowalski Osoba Klasa Osobaprzestaje być klasą abstrakcyjną. 0..1 0..1 {xor} Klasa Osobajest klasą abstrakcyjną. Nowak:Osoba Kowalski:Osoba Nowak:Student Nowak:Student Kowalski:Pracownik Kowalski:Pracownik

12. Realizacja struktur generalizacji/specjalizacji (2) Student Student Pracownik Pracownik Student/Pracownik Osoba {abstract} perspektywa pojęciowa perspektywa pojęciowa czy projektowa ? Nowak Kowalski {overlapping} Osoba {abstract} Abacki Sytuację, gdy klasa będąca efektem wielokrotnej specjalizacji (termin ?) (tu: Student/Pracownik) sama nie posiada klas specjalizowanych, prawdopodobnie byłoby lepiej modelować poprzez wykorzystanie ograniczenia {overlapping}, nie wywołując dzięki temu zbyt mocnego skojarzenia z dziedziczeniem wielokrotnym, czyli perspektywą projektową. Student/Pracownik na zlecenie

13. Realizacja struktur generalizacji/specjalizacji (2) Student Pracownik Realizacja dziedziczenia {overlapping}: perspektywa projektowa Osoba {abstract} 1 Osoba 2 Student Pracownik Student/Pracownik 0..1 0..1 Abacki:Osoba Nowak:Osoba Kowalski:Osoba Abacki:Student Nowak:Student Kowalski:Pracownik Abacki:Pracownik

14. Realizacja struktur generalizacji/specjalizacji (4) Osoba {abstract} perspektywa pojęciowa Zachowując realizację z wykorzystaniem dziedziczenia, przy każdej zmianie specjalizacji Osobypowstaje nowy obiekt jednej z trzech podklas: Menażer, Analitykczy Projektant. Własności odziedziczone z klasy Osobasą każdorazowo przepisywane. «dynamic» Menażer Analityk Projektant perspektywa projektowa W przypadku realizacji z wykorzystaniem kompozycji, 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. Klasa Osoba nie może być klasą abstrakcyjną. Osoba {xor} 0..1 0..1 0..1 Menażer Analityk Projektant

15. Generalizacja wieloaspektowa Bywa konieczna, ale często komplikuje pielęgnację oprogramowania. Pracownik Osoba Emeryt Przykład: 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 perspektywa pojęciowa

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

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

18. Zagnieżdżona generalizacja (1) perspektywa projektowa Pracownik {abstract} status płacowy Pracownikgodzinowy {abstract} Pracowniketatowy {abstract} Pracownikna zlecenie {abstract} 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

19. Zagnieżdżona generalizacja (2) perspektywa projektowa Pracownik {abstract} stosunekdo emerytury Pracownikemerytowany {abstract} Pracowniknie emerytowany {abstract} status płacowy status płacowy Pracownik emerytowany godzinowy Pracownik emerytowany etatowy Pracownik emerytowany na zlecenie Pracownik nie emerytowany godzinowy Pracownik nie emerytowany etatowy Pracownik nie emerytowany na zlecenie

20. 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, inne wydają się być mniej ważne lub może powodować wąskie gardło w wydajności, tę klasę najlepiej zaimplementować poprzez dziedziczenie, zaś pozostałe przez delegację. • Jeżeli liczba kombinacji klas jest mała, można rozpatrywać zagnieżdżoną generalizację. • Przy zagnieżdżonej generalizacji, najważniejszy czynnik - o czym może zaświadczać np. zdecydowanie większa liczba cech - 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.