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

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 8

Model obiektowy (5)


Zagadnienia

ADT DelegacjaProtytypyRoleTransformacje 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 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).

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.

Przykłady ADT

stos (z operacjami: pop, push, top, empty), pakiety obsługujące: mysz, CD ROM, grafikę, heap


Delegacja - alternatywa dla dziedziczenia

Obiekt “Stos” dziedziczy niepotrzebne muoperacje z klasy “Lista”

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.

push pop

zawartośćpush poptop

Operacje na obiekcie są oddelegowane do innego obiektu.

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

Lista

pierwszynastępnyostatnidodajusuń

pierwszynastępnyostatnidodajusuń

Lista Stos


Prototypy (1)

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.

Pojęcie ściśle powiązane z delegacją.

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)

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

Prototyp

Łapy: 4 Ogon: 1

Uszy:2 Oczy:2

Ulubieniec

Szczepienie()

Wabi_się: Rex

Rasa: jamnik

Płeć: M

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


Role

Student jest Osobą Źle! Osoba staje się Studentem

OsobaKowalski

Właściciel

psa

Pracownik Student Pacjent

Członek klubu

golfowegoKibicLegii

Podatnik

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

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.


Role - przykład

NAZWISKOROK_URWiek()

Kowalska: pracownikNowak: pracownik+studentAbacka:Nowacki: student

Rola importuje nie tylko inwarianty swojej klasy, lecz także wartości atrybutów swojego obiektu oraz inwarianty jego klasy.

NAZWISKO: NowackiROK_UR: 1940

NAZWISKO: AbackaROK_UR: 1948

NAZWISKO: NowakROK_UR: 1951

ZAROBEKDZIAŁZarobekNetto()ZmieńZarobek(...)

NAZWISKO: KowalskaROK_UR: 1975

NR_INDEKSUINDEKSWpiszOcenę(...)ObliczŚredniąOcen()

:PRACOWNIKZAROBEK: 2000DZIAŁ: zabawki

:PRACOWNIKZAROBEK: 2500DZIAŁ: zabawki NR_INDEKSU:223344

INDEKS:......NR_INDEKSU:556677INDEKS:......

rola

OSOBA

:OSOBA:OSOBA :OSOBA :OSOBA

PRACOWNIKSTUDENT

:STUDENT :STUDENT


Podział poziomy klasy (podział ekstensji klasy)

K1

K2a1a2m1m2

aK21

a1 ?a2 ?m1 ?m2 ?

K22a1 ?a2 ?m1 ?m2 ?

K1a ? a ?

Przykład

Osobaimięnazwiskonazwa szkoływysokość emeryturypensjapodaj nazwiskopodaj szkołęzmień emeryturęzmień pensję

Firmanazwa 0..1

zatrudnia

*

Uczeńimięnazwiskonazwa szkoły

podaj nazwiskopodaj szkołę

Emerytimięnazwiskowysokość emeryturypodaj nazwiskozmień emeryturę

Pracownikimięnazwiskopensja

podaj nazwiskozmień pensję

Firmanazwa

*

1

Osobaimięnazwisko

podaj nazwisko

zatrudnia


Podział pionowy klasy (podział inwariantów klasy)

K1

K2a1a2a3m1m2m3

aK21

a1m2m3

K22a2a3m1

K1

Przykład

Firmanazwaadres firmytelefon firmy [1..*]imię dyrektoranazwisko dyrektoraadres dyrektoratelefon dyrektorazmień adres firmypodaj telefon dyrektora

Klient*

zlecił

1..*

Osobaimięnazwiskoadrestelefonpodaj telefon

Firmanazwaadrestelefon [1..*]

zmień adres

Klient

1..*

* zlecił

np.

0..11dyrektor

a


Obejście dziedziczenia typu disjoint

Osoba

Student Pracownik

Osoba

Student Pracownik0..1 0..1{xor}

perspektywapojęciowa

perspektywaprojektowa

Kowalski

Nowak

Nowak:Student

Kowalski:Pracownik

Nowak:Osoba

Nowak:Student

Kowalski:Osoba

Kowalski:Pracownik


Obejście dziedziczenia typu overlapping

Osoba

Student Pracownik Osoba

Student Pracownik0..1 0..1

Kowalski

Nowak

Nowak:Osoba

Nowak:Student

Kowalski:Osoba

Kowalski:Pracownik

{overlapping}

Abacki

Abacki:Osoba

Abacki:Student

Abacki:Pracownik

Zamiast kompozycjimożna tu użyć zarównoagregacji, jak i zwykłejasocjacji.


Obejście dziedziczenia typu dynamic

Osoba{abstract}

ProjektantAnalitykMenażer

{dynamic}

Osoba

ProjektantAnalitykMenażer

{xor}0..1 0..1 0..1

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.

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


Obejście dziedziczenia wielokrotnego

Osoba

Student Pracownik

Student/PracownikOsoba

Student Pracownik0..1 0..1


Pracownik godzinowy nie emerytowany

Dziedziczenie wielokrotne i wieloaspektowe

Osobastatuspłacowy

stosunekdo emerytury

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:

Pracownikgodzinowy

Pracowniketatowy

Pracownikna zlecenie

Osoba nieemerytowana

Osobaemerytowana

Osoba

specjalizacjewg płac

specjalizacjewg emerytury

Pracownik Emeryt


Delegacja z użyciem ról

Osoba

Pracownik Emeryt

Specjalizacjewg płac

Specjalizacjewg emerytury

Osoba

Pracownikgodzinowy

Pracowniketatowy



Osobaemerytowana

Pracownik Emeryt


Użycie dziedziczenia i delegacji

Dziedziczenie Delegacja

Osoba

Emeryt

Specjalizacjewg płac

Specjalizacjewg emerytury

Osoba

Pracownikgodzinowy

Pracowniketatowy



Osobaemerytowana

Pracownik Emeryt


Zagnieżdżona generalizacja

Pracownik

statuspłacowy




Pracownik godzinowy nieemerytowany

Pracownikgodzinowy

emerytowany

Pracownik etatowy nie

emerytowany

Pracowniketatowy

emerytowany

Pracownik nazlecenie nie

emerytowany

Pracownik nazlecenie

emerytowany

Pracownikgodzinowy

Pracowniketatowy


Permutacja klas


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.

Projektowanie systemów informacyjnych

Documents

Transcript of Projektowanie systemów informacyjnych