IMGf34

24 Zeksmośn rnipfcy jm**ami : trykx>r2v*tanirm

Dziedziczenie pakietów

IWom dnndLncrąor z innych zwykle mc korzystaj ze stereotypów a kh dnaiame jest podobne do dziedziczenia klas Dziedzi-obw pakietów jest reprezentowane za pomocą tej samej relacji gmeraJizacti. wykcaryatywanej do innych typów elementów, co jBortało przedstawione na rysunku 25

Pakiety mogą zastępować publiczne (public) elementy swoich pakietów bazowych własnymi elementami, o ile elementy te są zgodne z założeniami tego samego interfejsu co zastępowane ełementy Elementy zabezpieczone (protectcd) pakietu są dostępne

dl a pikłttGw dziedziczących. Jednak elementy prywatne [private) są nadal ograniczone do zawierającego je pakietu

Pakiety mn|ą takie same wymagania dotyczące możliwości wy. mlany jak klasy. Oznacza to, te jeżeli pakiet B dziedziczy z pakietu A. można skorzystać z pakietu B wszędzie tam, gdzie można użyć pakietu A 7. powodu ograniczonej obsługi przez języki programowania, dziedziczenie pakietów jest rzadko wykorzystywane

Stereotypy pakietów

Dostępnych jest pięć predefiniowanych stereotypów UMK specyficznych dla pakietów:

Pacade

Wykorzystywany do wskazania, że pakiet nie jest kompletny, ale raczej jest reprezentacją innego, większego pakietu Relacja pomiędzy pakietem fasadowym i większym pakietem jest podobna do relacji pomiędzy interfejsem i klasą implementującą ten interfejs, jak również inne interfejsy.

Framework

Wykorzystywany do oznaczenia pakietu zawierającego klasy i interfejsy definiujące wzorce projektu aplikacji. Te klasy i interfejsy są często wykorzystywane do imp!ementaqi podsystemów w większej aplikacji.

Stub

Wykorzystywany do zaznaczenia, że pakiet nie zawiera pełnej implementacji określonego zbioru funkcji; pakiet zawiera jedynie minimalne wymagane funkcje do zdefiniowania usługi. Zazwyczaj pakiet stub zawiera interfejsy, klasy abstrakcyjne lub klasy pośredniczące (proxy). Pakiety stub są często instalowane po stronie klienta usług CORBA lub EJB.

Subsystem

Wykorzystywany do oznaczenia, ze pakiet zawiera niezależny zbiór funkcji. Pełny system często składa się z kilku

UML lAaykon klctwnkowy

Diagramy kiai

iii