4 Związek generalizacji-specjalizacji

Podobne dokumenty
3 Obiekt a klasa. 3.1 Wstęp. 3.2 Obiekt ToŜsamość obiektu a jego identyfikator

Po lewej przykłady klas. Stereotypy zostały tu wykorzystane do metaklasyfikacji metod.

Rysunek 1: Przykłady graficznej prezentacji klas.

Paweł Kurzawa, Delfina Kongo

MAS dr. Inż. Mariusz Trzaska. Realizacja różnych modeli dziedziczenia w obiektowych językach programowania

Programowanie obiektowe

Podstawy Programowania Obiektowego

1. Mapowanie diagramu klas na model relacyjny.

Modelowanie i Programowanie Obiektowe

Charakterystyka oprogramowania obiektowego

Inżynieria oprogramowania. Część 5: UML Diagramy klas

hierarchie klas i wielodziedziczenie

Programowanie 2. Język C++. Wykład 3.

Diagramy klas. dr Jarosław Skaruz

Programowanie obiektowe

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Kompozycja i dziedziczenie klas

Programowania w Javie

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

MAS dr. Inż. Mariusz Trzaska

Dziedziczenie jednobazowe, poliformizm

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów

TECHNOLOGIE OBIEKTOWE. Wykład 3

Modelowanie obiektowe

Klasy abstrakcyjne i interfejsy

Laboratorium nr 10. Temat: Połączenia relacji

Programowanie obiektowe

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie C++ - DZIEDZICZENIE.

PHP 5 język obiektowy

Dziedziczenie. dr Jarosław Skaruz

.NET Klasy, obiekty. ciąg dalszy

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Instrukcja warunkowa i złoŝona.

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

MODELOWANIE OBIEKTOWE

Bazy Danych 2008 Część 1 Egzamin Pisemny

Diagramy klas. WYKŁAD Piotr Ciskowski

Modelowanie danych, projektowanie systemu informatycznego

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

1 Projektowanie systemu informatycznego

Gramatyki, wyprowadzenia, hierarchia Chomsky ego. Gramatyka

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Laboratorium nr 5. Temat: Funkcje agregujące, klauzule GROUP BY, HAVING

UML. zastosowanie i projektowanie w języku UML

UML w Visual Studio. Michał Ciećwierz

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Szablony funkcji i szablony klas

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Programowanie i projektowanie obiektowe

Programowanie Obiektowe i C++

Mechanizm dziedziczenia

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

MAS dr. Inż. Mariusz Trzaska

Programowanie obiektowe - 1.

Programowanie obiektowe

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest

Dziedziczenie. Zadanie 1

PARADYGMATY PROGRAMOWANIA Wykład 4

Aplikacje w środowisku Java

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla studentów

Podstawy projektowania systemów komputerowych

Program 6. Program wykorzystujący strukturę osoba o polach: imię, nazwisko, wiek. W programie wykorzystane są dwie funkcje:

Dziedziczenie. Tomasz Borzyszkowski

Wykład 8: klasy cz. 4

dziedziczenie - po nazwie klasy wystąpią słowa: extends nazwa_superklasy

Dziedziczenie. Streszczenie Celem wykładu jest omówienie tematyki dziedziczenia klas. Czas wykładu 45 minut.

Definiowanie własnych klas

Laboratorium z przedmiotu Programowanie obiektowe - zestaw 04

Tablice, DataGridView

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Programowanie deklaratywne

10. Programowanie obiektowe w PHP5

Polimorfizm, metody wirtualne i klasy abstrakcyjne

Programowanie obiektowe

Programowanie obiektowe

Programowanie deklaratywne

XV. Wskaźniki Odczytywanie adresu pamięci istniejących zmiennych Wskaźniki pierwsze spojrzenie.

Programowanie 2. Język C++. Wykład 9.

PODEJŚCIE OBIEKTOWE. Przykład 1 metody i atrybuty statyczne

Przepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)

Typy klasowe (klasy) 1. Programowanie obiektowe. 2. Założenia paradygmatu obiektowego:

Modelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1)

Wykład 7: Pakiety i Interfejsy

JAVA W SUPER EXPRESOWEJ PIGUŁCE

5 Zagadnienia dotyczące asocjacji

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016

Wzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski

Dokumentacja do API Javy.

Język UML w modelowaniu systemów informatycznych

Konstruktory. Streszczenie Celem wykładu jest zaprezentowanie konstruktorów w Javie, syntaktyki oraz zalet ich stosowania. Czas wykładu 45 minut.

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

Faza analizy (modelowania) Faza projektowania

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Transkrypt:

4 Związek generalizacji-specjalizacji 4.1 Wstęp Wykład omawia jeden z podstawowych związków pomiędzy klasami związek generalizacji-specjalizacji. Generalizacja-specjalizacja jest bardzo silnym narzędziem obiektowości, dzięki któremu analityk jest w stanie skonstruować model pojęciowy, który nie tylko znacznie lepiej opisuje dziedzinę problemową, ale takŝe, a moŝe przede wszystkim, lepiej nadaje się do modyfikacji, niŝ to ma miejsce na przykład w podejściu relacyjnym. Wykład stara się oddać całą złoŝoność problemu, prezentując wszystkie najwaŝniejsze zagadnienia. 4.2 Generalizacja-specjalizacja W perspektywie pojęciowej, generalizacja-specjalizacja (w skrócie zwana generalizacją lub specjalizacją) jest związkiem łączącym pewną klasę, tzw. nadklasę, z innymi klasami, tzw. podklasami, przy czym nadklasa modeluje byty bardziej ogólne niŝ byty modelowane przez podklasy 1. W perspektywie projektowej, ze związkiem generalizacji ściśle związany jest mechanizm dziedziczenia 2, dzięki któremu inwarianty są importowane z nadklasy do podklas. Oznacza to, Ŝe podklasa posiada wszystkie własności swojej nadklasy; poza tym podklasa moŝe posiadać (i zazwyczaj posiada) takŝe pewne dodatkowe własności. Dziedziczenie inwariantów jest tranzytywne (przechodnie). Struktury związków generalizacji tworzą drzewa klas (lub inne struktury bez pętli) zwane hierarchiami generalizacji (specjalizacji, dziedziczenia). Rys. 1 ilustruje dwa równowaŝne sposoby przedstawiania hierarchii klas, gdzie klasa Zwierzę jest nadklasą klasy Zwierzę hodowlane, która z kolei jest nadklasą dla klas Krowa, Świnia, Struś i Kura. generalization specjalization Animal Breed animal Cow Pig Ostrich Hen Animal Breed animal Cow Pig Ostrich Hen Rys. 1. RównowaŜne sposoby przedstawiania hierarchii klas 1 O nadklasie mówi się czasami, Ŝe jest generalizacją podklasy, natomiast o podklasie mówi się, Ŝe jest specjalizacją nadklasy. 2 PoniewaŜ terminy generalizacja-specjalizacja i dziedziczenie są silnie powiązane, często uŝywa się ich zamiennie.

Tak jak powiedzieliśmy, hierarchia generalizacji nie moŝe zawierać pętli (Rys. 2). MoŜe jednak być kratą (Rys. 3), która modeluje dziedziczenie wielokrotne (omawiane w podrozdziale 4.2.6). K1 K2 K3 Rys. 2. Hierarchia niepoprawna ze względu na pętlę K1 K2 K3 Rys. 3. Hierarchia typu krata K4 Jednym z często popełnianych błędów jest konstruowanie hierarchii klas w oparciu wyłącznie o podobieństwo atrybutów. Tworząc hierarchię naleŝy mieć na uwadze to, Ŝe klasy w hierarchii muszą posiadać zbliŝoną semantykę i charakteryzować się następującą własnością: obiekt podklasy jest szczególnym przypadkiem (rodzajem) obiektu nadklasy, ale zaleŝność odwrotna nie jest prawdziwa. Przykład przedstawiony jest na Rys. 4, gdzie klasa Indeks została niesłusznie uznana za podklasę klasy Osoba. Co prawda, indeks jest opisywany przez takie atrybuty jak imię, nazwisko i rok urodzenia, jednak w sposób oczywisty nie jest szczególnym rodzajem osoby. Person name surname birth date Student semester Index index No. Rys. 4. Przykład nieprawidłowej specjalizacji 4.2.1 Wystąpienie klasy a związek generalizacji-specjalizacji W literaturze wyróŝnia się dwa rodzaje wystąpień klasy: wystąpienia bezpośrednie, wystąpienia pośrednie.

KaŜdy obiekt jest wystąpieniem bezpośrednim tej klasy, której jest członkiem, oraz wystąpieniem pośrednim wszystkich jej nadklas. Na przykład, dla klasy Student i jej nadklasy Osoba: Obiekt klasy Osoba jest bezpośrednim wystąpieniem tej klasy i nie jest pośrednim wystąpieniem Ŝadnej innej klasy, poniewaŝ Osoba nie jest podklasą Ŝadnej innej klasy. Obiekt klasy Student jest bezpośrednim wystąpieniem klasy Student i pośrednim wystąpieniem klasy Osoba. 4.2.2 Ekstensja klasy a związek generalizacji-specjalizacji W literaturze moŝna spotkać następujące trzy szczegółowe definicje ekstensji: Ekstensja klasy K jest to zbiór wszystkich wystąpień K (bezpośrednich i pośrednich) i jej podklas, przy czym wystąpienia te zawierają jedynie atrybuty klasy K. Ekstensja klasy K jest to zbiór, jak poprzednio, wszystkich wystąpień K i jej podklas, ale brane są pod uwagę wszystkie atrybuty. Ekstensja klasy K jest to zbiór bezpośrednich wystąpień K. W niniejszym wykładzie będziemy posługiwać się pierwszą z powyŝszych definicji. Przykładowa ekstensja dla klasy Osoba i jej podklasy Pracownik zgodna z tą definicją przedstawiona jest na Rys. 5. extent of the Person class :Person : Osoba name = Teofil surname = Jeleń Person name surname age () name = Wanda surname = Niemiec name = Zenon surname = Nowak name = Barbara surname = Wyka Student index No. grades grades avg () : Student : Student name = Wanda name = Zenon surname = Niemiec surname = Nowak index No. = 43789 index No. = 44564 grades = 4, 5, 5, 3 grades = 3.5, 4, 4 extent of the Student class : Student name = Barbara surname = Wyka index No. = 44333 grades = 5, 4.5, 5, 3.5 Rys. 5. Przykładowa ekstensja klasy Osoba i jej podklasy Student 4.2.3 Klasa abstrakcyjna a klasa konkretna Klasa abstrakcyjna jest to klasa, która nie ma i nie moŝe posiadać wystąpień bezpośrednich. Klasa abstrakcyjna słuŝy zatem wyłącznie jako nadklasa dla innych klas, stanowiąc swego rodzaju wspólną część definicji grupy klas o podobnej semantyce. UML pozwala na oznaczenie bytu abstrakcyjnego (klasy czy metody abstrakcyjnej) za pomocą wartości etykietowanej {abstract = TRUE} (lub w skrócie {abstract}; patrz wykład poświęcony mechanizmom rozszerzalności) lub poprzez napisanie nazwy bytu kursywą (co jednak jest mało praktyczne dla diagramów rysowanych ręcznie).

W odróŝnieniu od klasy abstrakcyjnej, klasa konkretna moŝe mieć (ma prawo mieć) wystąpienia bezpośrednie. Jest moŝliwe, Ŝe w danej chwili klasa konkretna nie posiada Ŝadnych instancji. Przykłady klas abstrakcyjnych i konkretnych są przedstawione na Rys. 6. Zwróćmy uwagę na stereotyp «instanceof» oznaczający związek pomiędzy klasą a jej wystąpieniem. Legal person {abstract} Natural person Firm «instanceof» «instanceof» «instanceof» :Natural person :Firm :Firm Sequence first next Int sequence... implementations Char sequence... implementations Rys. 6. Klasa abstrakcyjna a klasa konkretna PoniewaŜ klasa abstrakcyjna pełni rolę nadklasy dla innych klas (równieŝ dla innych klas abstrakcyjnych), nie moŝe być liściem w hierarchii dziedziczenia. ZastrzeŜenie to nie dotyczy oczywiście klasy konkretnej, która moŝe występować w dowolnym miejscu hierarchii. RozwaŜmy diagram z Rys. 7: tylko klasy K1 i K3 mogą potencjalnie być klasami abstrakcyjnymi; kaŝda z klas moŝe być klasą konkretną. K1 K2 K3 K4 K5 Rys. 7. Diagram dla ilustracji zagadnienia klas abstrakcyjnych i konkretnych

4.2.4 Metoda abstrakcyjna Jak juŝ wspomnieliśmy w wykładzie poświęconym obiektom i klasom, metoda abstrakcyjna posiada sygnaturę, ale nie posiada implementacji. Klasa zawierająca przynajmniej jedną metodę abstrakcyjną jest klasą abstrakcyjną, gdyŝ nie moŝna tworzyć obiektów, dla których brakuje implementacji pewnych operacji. Definicja implementacji metody abstrakcyjnej musi znajdować się w którejś z podklas klasy abstrakcyjnej. Dla przykładu rozwaŝmy Rys. 8: sygnatura operacji oblicz wypłatę znajduje się w klasie abstrakcyjnej Pracownik, natomiast kaŝda z jej podklas (będących klasami konkretnymi) zawiera właściwą dla siebie implementację tej operacji. Employee {abstract} earned in current year birth date calculate salary (){abstract} calculate age () Wage employee regular wage holiday wage calculate salary () Full-time employee week s wage calculate salary () Contractor month s wage calculate salary () Rys. 8. Przykład metody abstrakcyjnej Klasa abstrakcyjna moŝe zawierać abstrakcyjne metody, ale nie musi. Natomiast klasa konkretna musi zawierać implementacje tych metod abstrakcyjnych, które nie zostały zaimplementowane w Ŝadnej z jej nadklas. 4.2.5 Specjalizacja jednoaspektowa i wieloaspektowa Podklasy danej klasy są wyróŝniane na podstawie pewnego kryterium (pewnej własności) zwanego aspektem specjalizacji (lub dyskryminatorem); zazwyczaj takim kryterium jest rodzaj. Dyskryminator jest elementem opcjonalnym, co oznacza, Ŝe moŝe, ale nie musi, być specyfikowany na diagramie; jeŝeli występuje, to jest umieszczany przy symbolu specjalizacji. Przykład przedstawia diagram na Rys. 9, który identyfikuje róŝne rodzaje wyposaŝenia, róŝne rodzaje pomp oraz róŝne rodzaje zbiorników (dla uproszczenia podklasy klas Pompa i Zbiornik nie zostały umieszczone na diagramie). Equipment name manufacturer price specjalization aspect (discriminator) equipment type Pump suction pressure expression pressure flow pump type Radiator surface pipe diameter typ zbiornika Tank volume pressure Rys. 9. Przykład specjalizacji jednoaspektowej

Alternatywną metodę 3 zamodelowania specjalizacji z Rys. 9, zgodnie z którą jest definiowana tylko jedna klasa, ilustruje Rys. 10. Zwróćmy uwagę na ograniczenie oraz na to, Ŝe atrybuty specyficzne dla poszczególnych rodzajów wyposaŝenia są tutaj atrybutami opcjonalnymi. Ponadto, w celu łatwego określenia rodzaju wyposaŝenia wprowadzono atrybut rodzaj wyposaŝenia. Dla diagramu z Rys. 9 atrybut ten nie jest potrzebny, poniewaŝ rodzaj wyposaŝenia jest wyraŝany poprzez przynaleŝność obiektu do ekstensji odpowiedniej klasy. Equipment name manufacturer price suction pressure expression pressure flow surface pipe diameter volume pressure equipment type attributes specific for particular type of equipment: pump: suction pressure, expression presure, flow radiator: surface, pipe diameter tank: volume, pressure Rys. 10. Zamodelowanie specjalizacji za pomocą jednej klasy z atrybutami opcjonalnymi i dodatkowym atrybutem Identyfikowanie podklas na podstawie aspektu specjalizacji tworzy podział podklas, przy czym nie istnieje ograniczenie na liczbę tego rodzaju podziałów, które moŝna potencjalnie utworzyć; innymi słowy, nie istnieje ograniczenie na liczbę aspektów, według których moŝna identyfikować podklasy. W przykładzie przedstawionym na Rys. 9 dla klas WyposaŜenie, Pompa i Zbiornik podklasy zostały zidentyfikowane na podstawie tylko jednego aspektu (odpowiednio: rodzaj wyposaŝenia, rodzaj pompy oraz rodzaj zbiornika), czyli dla tych klas został ustanowiony tylko jeden podział ich podklas. Tego rodzaju przypadek określa się terminem specjalizacja jednoaspektowa w odróŝnieniu od specjalizacji wieloaspektowej, która oznacza utworzenie co najmniej dwóch podziałów. Przykład specjalizacji wieloaspektowej przedstawiony na Rys. 11 obrazuje sytuację, gdy utworzono dwa podziały podklas klasy Pojazd według następujących aspektów: napęd wykorzystywany do ich poruszania zidentyfikowano pojazdy napędzane siłą wiatru oraz pojazdy silnikowe; teren, po którym się poruszają zidentyfikowano pojazdy lądowe oraz pojazdy wodne. Vehicle {overlapping} propulsion terrain terrain {overlapping} Wind vehicle Engine vehicle Land vehicle Sea vehicle Rys. 11. Przykład specjalizacji wieloaspektowej NiezaleŜnie od klasyfikacji specjalizacji na jednoaspektową i wieloaspektową, UML wyróŝnia następujące rodzaje podziałów (w nawiasach podane są ich oznaczenia w języku angielskim, stosowane w niniejszym wykładzie): podział rozłączny (disjont), kiedy przecięcie zbiorów obiektów podklas jest zbiorem pustym; podziałem dualnym jest podział nierozłączny (overlapping); podział rozłączny jest podziałem domyślnym, dlatego nie musi być oznaczany na diagramie; podział kompletny (complete), kiedy zidentyfikowano wszystkie podklasy; podziałem dualnym jest podział niekompletny (incomplete); podziałem domyślnym jest podział kompletny. Oznaczenie rodzaju podziału jest umieszczane na diagramie przy symbolu specjalizacji, której dotyczy. 3 Metoda ta jest stosowana przede wszystkim w fazie projektowania w sytuacji, gdy środowisko implementacji nie wspiera pojęcia specjalizacji.

Zwróćmy uwagę, Ŝe na Rys. 11 Ŝaden z obu podziałów nie jest rozłączny, co oznacza, Ŝe istnieją pojazdy, które posiadają silnik i mogą być poruszane siłą wiatru oraz pojazdy, które mogą poruszać się zarówno po wodzie, jak i po lądzie. Zazwyczaj dla specjalizacji jednoaspektowej dyskryminator jest opuszczany, poniewaŝ zakłada się, Ŝe nazwy podklas dostarczają wystarczającej informacji o tym, co stanowiło kryterium podziału. W przypadku specjalizacji wieloaspektowej przedstawienie dyskryminatora jest obowiązkowe. Elipsa Nie naleŝy mylić słowa kluczowego incomplete, które oznacza podział niekompletny, z innym elementem składniowym, tzw. elipsą (inaczej: opuszczeniem), specyfikowanym w postaci wielokropka (... ). RóŜnica polega na tym, Ŝe incomplete oznacza podział niekompletny, czyli w rozwaŝanej dziedzinie problemowej zostały zidentyfikowane równieŝ takie podklasy, dla których nie określono jeszcze kompletnej definicji. Dla odróŝnienia elipsa oznacza, Ŝe niektóre z zidentyfikowanych klas (w pełni zdefiniowanych) ale np. nieistotnych dla aktualnie rozwaŝanego problemu, zostały pominięte, czyli nie są przedstawione na danym diagramie. Przykład zastosowania elipsy pokazuje Rys. 15. 4.2.6 Specjalizacja wielokrotna Specjalizacja wielokrotna 4 modeluje sytuację, w której dana klasa jest specjalizacją więcej niŝ jednej klasy, czyli dziedziczy bezpośrednio z więcej niŝ jednej nadklasy. RozwaŜmy przykład z Rys. 12: podklasami klasy Osoba są klasy Pracownik oraz Student; w celu zamodelowania faktu istnienia osób, które jednocześnie pracują i studiują, utworzona została klasa Pracujący student, która jest jednocześnie specjalizacją klasy Pracownik (na oznaczenie tego, Ŝe osoba pracuje) i specjalizacją klasy Student (na oznaczenie tego, Ŝe osoba studiuje). Person surname Employee salary Student index No. Rys. 12. Przykład specjalizacji wielokrotnej Working student Mimo iŝ specjalizacja wielokrotna moŝe być w pewnych sytuacjach bardzo przydatna, koncepcja ta jest przedmiotem krytyki ze strony niektórych specjalistów. NajpowaŜniejszą ze wskazywanych przez nich wad jest to, Ŝe specjalizacja wielokrotna łączy w jednym miejscu definicje kilku niezaleŝnych i przez to zazwyczaj niekompatybilnych bytów. Jedną z konsekwencji jest konflikt nazw, czyli sytuacja, kiedy w dwóch lub więcej nadklasach danej klasy istnieją inwarianty o dokładnie takich samych nazwach. Poprzez dziedziczenie inwarianty te stają się własnościami jednej klasy, podczas gdy klasa nie moŝe posiadać kilku róŝnych własności o takich samych nazwach. Klasyczny juŝ przykład konfliktu nazw przedstawiony jest na Rys. 13: klasa Amfibia dziedziczy od swoich nadklas dwa atrybuty i dwie metody o takich samych nazwach. Powstaje wobec tego konflikt nazw, który prowadzi do następujących pytań: Który z atrybutów max prędkość powinna odziedziczyć klasa Amfibia? Czy znaczenie metody prędkość eksploat () zaleŝy od wybranej ścieŝki dziedziczenia? 4 Odpowiednikiem występującej w perspektywie pojęciowej specjalizacji wielokrotnej jest w perspektywie projektowej tzw. wielodziedziczenie (wielokrotne dziedziczenie).

Vehicle { recomended speed equals 50% of max speed } Land vehicle max speed recomended speed () Sea vehicle max speed recomended speed() Car Amphibia Yacht Rys. 13. Przykład konfliktu nazw Problem ten jest rozwiązywany róŝnie w róŝnych środowiskach implementacyjnych. Na przykład w języku Eiffel konflikt nazw jest traktowany jako błąd, czyli twórca diagramu musi zadbać o to, aby do konfliktu nie dochodziło. 4.2.7 Dziedziczenie dynamiczne Dotychczas niejawnie zakładaliśmy, Ŝe obiekt jest wystąpieniem danej klasy przez cały okres swojego istnienia. Jak łatwo zauwaŝyć, załoŝenie to ma powaŝną wadę, gdyŝ uniemoŝliwia zamodelowanie w prosty sposób sytuacji, w której rodzaj danego bytu moŝe się zmieniać w trakcie jego Ŝycia. RozwaŜmy następujący przykład: osoba pracuje jako menedŝer, inŝynier albo sprzedawca, ale moŝe, jeŝeli zechce, zmienić swój zawód. Tego rodzaju informację wygodnie jest przedstawić za pomocą dziedziczenia dynamicznego, które dopuszcza, aby obiekt w trakcie swojego istnienia zmieniał klasę, której jest członkiem, bez zmieniania swojej toŝsamości 5. Dziedziczenie dynamiczne wymaga, aby podklasa importowała inwarianty ze swoich nadklas w czasie działania programu. Hierarchię dziedziczenia dynamicznego dla rozwaŝanego przykładu przedstawia Rys. 14. Zwróćmy uwagę na dyskryminator zawód, który został opatrzony stereotypem «dynamic» na oznaczenie dziedziczenia dynamicznego. Stereotyp ten został wprowadzony przez znanego metodologa M. Fowlera, nie jest jednak stereotypem predefiniowanym w UML. Oznacza to, Ŝe chcąc umieścić go na diagramie, naleŝy podać jego definicję w dokumentacji projektu 6. Woman Person «dynamic» occupation Manager Engineer Man gender Shop assistant Rys. 14. Przykład dziedziczenia dynamicznego Pojęcie dziedziczenia dynamicznego, mimo Ŝe wydaje się być poŝytecznym środkiem w modelowaniu pojęciowym, jak dotąd nie zostało w pełni zaimplementowane w Ŝadnym z popularnych języków modelowania lub programowania. 4.2.8 Rozszerzenia i ograniczenia w podklasie Jak juŝ powiedzieliśmy wcześniej, podklasa posiada oprócz swoich własności takŝe wszystkie własności swoich nadklas. Co prawda podklasa nie moŝe omijać lub zmieniać atrybutów nadklasy, moŝe jednak wprowadzać pewne zmiany do innych własności, m.in.: Podklasa moŝe zmodyfikować ciało metody z nadklasy, jednak bez zmiany specyfikacji tej metody jest to tzw. przesłanianie metod (patrz podrozdział 4.2.9). Modyfikacja moŝe polegać na całkowitej zmianie metody 5 Informację tę moŝna takŝe zamodelować za pomocą specjalnego dodatkowego atrybutu. Rozwiązanie to okazuje się być jednak nieefektywne, jeŝeli podklasy uczestniczące w dynamicznym dziedziczeniu bardzo się między sobą róŝnią, co zazwyczaj ma miejsce. 6 Uwaga ta dotyczy oczywiście kaŝdej niestandardowej konstrukcji uŝywanej na diagramie.

bądź tylko na jej rozszerzeniu. W przypadku rozszerzenia niektóre środowiska implementacji dostarczają środki umoŝliwiające wykorzystanie przesłanianej metody z nadklasy w ciele metody z podklasy. Podklasa moŝe dowolnie dodawać nowe atrybuty i metody, czyli rozszerzać zbiór posiadanych własności. Podklasa moŝe ograniczać wartości atrybutów, np. Koło jest podklasą klasy Elipsa, gdzie obie średnice elipsy są sobie równe. NaleŜy jednak pamiętać, Ŝe ograniczenia mogą spowodować, iŝ część metod przestanie być poprawna; na przykład, dozwolona dla obiektu klasy Elipsa zmiana jednej średnicy jest niedopuszczalna w obiekcie podklasy Koło, gdyŝ w jego przypadku obie średnice muszą być zmieniane jednocześnie. 4.2.9 Przesłanianie metod Przesłanianie metod jest mechanizmem, zgodnie z którym metoda z klasy bardziej wyspecjalizowanej moŝe przesłonić metodę z klasy bardziej ogólnej. Mechanizm przesłaniania wykorzystywany jest w sytuacji, gdy metoda implementująca daną operację w podklasie wymaga uŝycia innego algorytmu niŝ ten, na którym oparto implementację operacji w nadklasie. Przesłanianie pozwala rozbudować hierarchię bez konieczności wprowadzania zmian do struktur juŝ istniejących, dlatego jest waŝnym mechanizmem wspierającym ponowne uŝycie. Przesłanianie jest ściśle powiązane z polimorfizmem metod i wymaga dynamicznego wiązania. Zagadnienie przesłaniania metod jest zilustrowane na Rys. 15, gdzie dwie metody implementują operację obliczania objętości bryły: Metoda policz objętość () w klasie abstrakcyjnej Bryła oblicza objętość bryły według wzoru (1). Metoda ta, nie będąc metodą abstrakcyjną, jest dziedziczona przez podklasy Prostopadłościan i Walec, które nie posiadają własnych implementacji operacji obliczania objętości. PoniewaŜ objętość stoŝka jest obliczana inaczej niŝ objętość prostopadłościanu czy walca (wzór (2)), metoda policz objętość () w klasie StoŜek przesłania metodę zdefiniowaną w nadklasie Bryła. Solid figure {abstract} base s area hight calculate volume () equation (1) volume = bases s area * hight } Cuboid Cylinder Cone... calculate volume () equation (2) volume = 1/3 of base s area * hight Rys. 15. Przykład ilustrujący przesłanianie metod Dyskutowany diagram klas moŝe zostać zbudowany takŝe w inny sposób: metoda abstrakcyjna w klasie Bryła i dwie metody implementujące operację obliczania objętości w podklasach Prostopadłościan i Walec; implementacja operacji w podklasie StoŜek bez zmian. Jednak z uwagi na moŝliwość ponownego uŝycia, którego jedną z podstaw stanowi idea budowy hierarchii klas, to rozwiązanie jest w sposób oczywisty gorsze od rozwaŝanego powyŝej. 4.2.10 PrzeciąŜanie metod PrzeciąŜanie jest to mechanizm, zgodnie z którym znaczenie danego symbolu (np. operatora czy funkcji) zaleŝy od kontekstu jego uŝycia, czyli na przykład od liczby i/lub typu argumentów: metody przesuń (x, y) i przesuń (x, y, z) róŝnią się liczbą argumentów; metody przesuń (int, int) i przesuń (float, float) róŝnią się typami argumentów; metody przesuń (int, float, int) i przesuń (float, int) róŝnią się zarówno liczbą, jak i typami argumentów.

W praktyce programistycznej powszechne jest przeciąŝanie operatora równości = (oczywiście jeŝeli pozwala na to środowisko implementacyjne), który moŝe słuŝyć do porównania liczb całkowitych, liczb rzeczywistych, napisów, identyfikatorów, struktur itd. Podobnie operator dodawania + moŝe oznaczać dodawanie liczb lub konkatenację napisów. PrzeciąŜanie, w odróŝnieniu od przesłaniania, nie wymaga dynamicznego wiązania, gdyŝ znaczenie operatora moŝna wywnioskować na podstawie statycznej analizy tekstu programu. 4.3 Podsumowanie Generalizacja-specjalizacja to obok obiektu i klasy jeden z najwaŝniejszych wyróŝników podejścia obiektowego. Związek ten pozwala oddać w wygodny sposób bardzo waŝną informację jaką jest istnienie w dziedzinie problemowej bytów bardziej i mniej ogólnych. Sam problem jest na tyle złoŝony, Ŝe termin generalizacja-specjalizacja kryje w sobie takŝe inne bliskie pojęcia, jak np. metoda abstrakcyjna, specjalizacja jedno- i wieloaspektowa oraz przesłanianie metod. Co więcej, wciąŝ opracowywane są nowe idee powiązane z generalizacją-specjalizacją, aby związek ten uczynić jak najbardziej wygodnym w uŝyciu; przykładem moŝe być dziedziczenie dynamiczne. 4.4 Przykładowe pytania i problemy do rozwiązania 1. Krótko scharakteryzuj koncepcję związku generalizacji-specjalizacji. 2. Co to jest metoda abstrakcyjna i w jakim celu jest wykorzystywana? 3. Czy klasa abstrakcyjna moŝe być liściem w hierarchii dziedziczenia klas? 4. Jaka jest róŝnica pomiędzy specjalizacją jednoaspektową a specjalizacją wieloaspektową? Odpowiedź zilustruj przykładami. 5. Diagram klas dla wypoŝyczalni płyt DVD (Wykład 2, podrozdział. 2.12) uzupełnij o związki generalizacjispecjalizacji i metody abstrakcyjne.