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ła
Technik Komputerowych, Warszawa
Wykład 8
Model obiektowy (5)
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 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
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 3
Abstrakcyjny typ danych
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).
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
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 4
Delegacja - alternatywa dla
dziedziczenia
Klasa “Stos” dziedziczy
niepotrzebne operacje 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
pop
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
pierwszy
następny
ostatni
dodaj
pobierz
pierwszy
następny
ostatni
dodaj
pobierz
Lista
Stos
...
...
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 5
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 6
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
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 7
Role
Student
jest
Osobą
Źle!
Osoba
staje się
Studentem
Osoba
staje się
Studentem
Osoba
Kowalski
Osoba
Kowalski
Właścicie
l
psa
Pracowni
k
Studen
t
Pacjen
t
Członek
klubu
golfowego
Kibi
c
Legi
i
Podatni
k
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.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 8
Role - przykład
NAZWISKO
ROK_UR
Wiek()
Kowalska: pracownik
Nowak:
pracownik+student
Abacka:
Nowacki: student
Rola importuje nie tylko inwarianty swojej klasy, lecz także wartości
atrybutów swojego obiektu oraz inwarianty jego klasy.
NAZWISKO = Nowacki
ROK_UR = 1940
NAZWISKO = Abacka
ROK_UR = 1948
NAZWISKO = Nowak
ROK_UR = 1951
ZAROBEK
DZIAŁ
ZarobekNetto()
ZmieńZarobek(...
)
NAZWISKO = Kowalska
ROK_UR = 1975
NR_INDEKSU
INDEKS
WpiszOcenę(...)
ObliczŚredniąOc
en()
:PRACOWNIK
ZAROBEK = 2000
DZIAŁ = zabawki
:PRACOWNIK
ZAROBEK = 2500
DZIAŁ = zabawki
NR_INDEKSU = 223344
INDEKS = ...
NR_INDEKSU = 556677
INDEKS = ...
rola
OSOBA
:OSOBA
:OSOBA
:OSOBA
:OSOBA
PRACOWNIK
STUDENT
:STUDENT
:STUDENT
{overlapping}
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 9
Podział poziomy klasy (podział
ekstensji klasy)
K1
K2
a1
a2
m1
m2
a
K21
a1 ?
a2 ?
m1 ?
m2 ?
K22
a1 ?
a2 ?
m1 ?
m2 ?
K1
a ?
a ?
Przykład
Osoba
imię
nazwisko
nazwa szkoły
wysokość emerytury
pensja
podaj nazwisko
podaj szkołę
zmień emeryturę
zmień pensję
Firma
nazwa
0..1
zatrudnia
*
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ę
Firma
nazwa
*
1
Osoba
imię
nazwisko
podaj nazwisko
zatrudnia
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 10
Podział pionowy klasy (podział
inwariantów klasy)
K1
K2
a1
a2
a3
m1
m2
m3
a
K21
a1
m2
m3
K22
a2
a3
m1
K1
Przykład
Firma
nazwa
adres firmy
telefon firmy [1..*]
imię dyrektora
nazwisko dyrektora
adres dyrektora
telefon dyrektora
zmień adres firmy
podaj telefon dyrektora
Klient
*
zlecił
1..*
Osoba
imię
nazwisko
adres
telefon
podaj telefon
Firma
nazwa
adres
telefon [1..*]
zmień adres
Klient
1..*
*
zlecił
np.
0..1
1
dyrektor
a
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 11
Realizacja struktur
generalizacji/specjalizacji (1)
Osoba
{abstrac
t}
Student
Pracownik
Osoba
Student
Pracownik
0..1
0..1
{xor}
perspektywa pojęciowa:
generalizacja/specjalizacja
perspektywa projektowa: dziedziczenie
perspektywa projektowa: kompozycja
Kowalski
Nowak
Nowak:Student
Kowalski:Pracownik
Nowak:Osoba
Nowak:Student
Kowalski:Osoba
Kowalski:Pracownik
Zamiast kompozycji można tu użyć
zarówno agregacji, jak i zwykłej
asocjacji.
Klasa Osoba jest klasą
abstrakcyjną.
Klasa Osoba przestaje
być klasą abstrakcyjną.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 12
Realizacja struktur
generalizacji/specjalizacji (2)
Osoba
{abstract}
Student
Pracownik
Kowalski
Nowak
{overlapping}
Abacki
perspektywa
pojęciowa
perspektywa
pojęciowa
czy
projektowa ?
Osoba
{abstract}
Student
Pracownik
Student/Pracownik
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
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 13
Realizacja struktur
generalizacji/specjalizacji (2)
Osoba
Student
Pracownik
0..1
0..1
Nowak:Osoba
Nowak:Student
Kowalski:Osoba
Kowalski:Pracownik
Abacki:Osoba
Abacki:Student
Abacki:Pracownik
Realizacja dziedziczenia {overlapping}: perspektywa projektowa
Osoba
{abstract}
Pracownik Student/Pracownik
Student
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 14
Realizacja struktur
generalizacji/specjalizacji (4)
Osoba
{abstract}
Projektant
Analityk
Menażer
«dynamic»
Osoba
Projektant
Analityk
Menażer
{xor}
0..1
0..1
0..1
Zachowując
realizację
z
wykorzystaniem dziedziczenia,
przy
każdej
zmianie
specjalizacji Osoby powstaje
nowy obiekt jednej z trzech
podklas: Menażer, Analityk
czy Projektant. Własności
odziedziczone z klasy Osoba są
każdorazowo przepisywane.
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ą.
perspektywa
pojęciowa
perspektywa
projektowa
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 15
Pracownik godzinowy nie emerytowany
Generalizacja wieloaspektowa
Osoba
status
płacowy
stosunek
do emerytury
Bywa konieczna, ale często komplikuje pielęgnację
oprogramowania.
Przykład:
Pracownik
godzinowy
Pracownik
etatowy
Pracownik
na zlecenie
Osoba nie
emerytowana
Osoba
emerytowana
Osoba
specjalizacje
wg płac
specjalizacje
wg emerytury
Pracownik
perspektywa
pojęciowa
Emeryt
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 16
Delegacja z użyciem ról
Osoba
Pracownik
Emeryt
Specjalizacje
wg płac
Specjalizacje
wg emerytury
Osoba
Pracownik
godzinowy
Pracownik
etatowy
Pracownik
na zlecenie
Osoba nie
emerytowana
Osoba
emerytowana
Pracownik
perspektywa projektowa
Emeryt
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 17
Użycie dziedziczenia i delegacji
Dziedziczenie
Delegacja
Osoba
Emeryt
Specjalizacje
wg płac
Specjalizacje
wg emerytury
Osoba
Pracownik
godzinowy
Pracownik
etatowy
Pracownik
na zlecenie
Osoba nie
emerytowana
Osoba
emerytowana
Pracownik
perspektywa projektowa
Emeryt
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 18
Zagnieżdżona generalizacja (1)
Pracownik
{abstract}
status płacowy
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
Pracownik
godzinowy
{abstract}
Pracownik
etatowy
{abstract}
Pracownik na
zlecenie
{abstract}
perspektywa projektowa
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 19
Zagnieżdżona generalizacja (2)
Pracownik
{abstract}
stosunek do
emerytury
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
Pracownik
emerytowany
{abstract}
Pracownik nie
emerytowany
{abstract}
perspektywa projektowa
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 8, Slajd 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.