5 Zagadnienia dotyczące asocjacji

5 Zagadnienia dotyczące asocjacji 5. Wstęp Wykład przedstawia kolejny waŝny związek pomiędzy klasami asocjację. Asocjacja jako bardzo poŝyteczne narzędzie jest wykorzystywana w inŝynierii oprogramowania od wielu lat. Obiektowość rozwija tę ideę dodając wiele nowych pojęć, takich jak m.in. role, kompozycja, klasa asocjacji, asocjacja kwalifikowana. Jak będzie się moŝna przekonać, asocjacja i związane z nią pojęcia pozwalają w zwięzły sposób opisać wiele cech dziedziny problemowej. 5.2 Powiązania i asocjacje Jedną z podstawowych cech omawianego w wykładzie poświęconym obiektom i klasom powiązania jest jego arność, określająca liczbę obiektów, które łączy. Powiązania łączące n obiektów, będących członkami niekoniecznie róŝnych klas, nazywane są powiązaniami n-arnymi; szczególnym przypadkiem powiązań n-arnych są powiązania binarne, których arność wynosi 2. Powiązanie posiada nazwę odpowiadającą charakterowi związku między bytami. Dla powiązań binarnych nazwa jest umieszczana na linii (oznaczającej powiązanie) mniej więcej w jednakowej odległości od obu obiektów. Na poziomie implementacyjnym powiązania są odwzorowywane najczęściej jako wskaźniki/referencje prowadzące od obiektów do obiektów. Grupy powiązań posiadających wspólną strukturę i semantykę są modelowane w postaci związków asocjacyjnych, zwanych w skrócie asocjacjami, podobnie jak grupy obiektów o wspólnej strukturze i semantyce są modelowane w postaci klas; nazwy asocjacji są nazwami odpowiadających im powiązań. W ten sposób powiązanie jest traktowane jako wystąpienie (instancja) asocjacji. Rys. ilustruje zaleŝność pomiędzy powiązaniami pracuje w na diagramie obiektów (diagram ) i odpowiadającą im asocjacją pracuje w na diagramie klas (diagram ). : : : name = Kasia name = Ewa name = Jasio works for works for works for : Firm kind = marketing : Firm kind = services Objects and links on an object diagram name works for Firm kind Classes and association on a class diagram Rys.. Ilustracja zaleŝności między pojęciami powiązanie i asocjacja W języku UML wprowadzono symbol czarnego trójkąta dla oznaczania kierunku czytania nazwy asocjacji binarnej (odpowiadającej asocjacji binarnej). Symbol jest opcjonalny jeŝeli nie został uŝyty, wówczas obowiązuje kierunek

czytania od lewej strony do prawej i z góry na dół diagramu. Na Rys. 2 wykorzystanie trójkąta spowodowało zmianę kierunku czytania nazwy asocjacji: to osoba pracuje dla firmy, a nie firma dla osoby. Podobna reguła obowiązuje dla powiązań. works for Rys. 2. Wyznaczenie kierunku czytania za pomocą symbolu czarnego trójkąta Nadawanie nazwy dla asocjacji nie jest obowiązkowe w sytuacji, gdy klasy łączy tylko jedna asocjacja i informacja przez nią modelowana wynika z kontekstu, czyli nazw połączonych klas. Przykładem jest asocjacja z Rys. 3, gdzie nazwy klas sugerują, Ŝe pracownik jest zatrudniony w firmie. Porównując diagramy na Rys. 2 i Rys. 3 widać jednak, Ŝe oczywistość nazwy asocjacji moŝe być subiektywna. Dlatego generalnie zalecane jest nazywanie wszystkich asocjacji, tak by prezentowana informacja była interpretowana jednoznacznie... Employee Rys. 3. Asocjacja bez nazwy łącząca klasy Firma i Pracownik W sytuacji, gdy dwie klasy łączy więcej niŝ jedna asocjacja, nazywanie asocjacji jest zawsze obowiązkowe (Rys. 4). is a member is a chairman Committee Rys. 4. Dwie asocjacje łączące klasy Osoba i Komitet Liczność asocjacji Oprócz nazwy, podstawową informacją opisującą asocjację jest jej liczność. Dla asocjacji binarnych określa ona liczbę obiektów pewnej klasy, z którymi moŝe być powiązany jeden obiekt naleŝący do tej samej bądź innej klasy. Informacja ta jest zazwyczaj opisywana przez parę ciągów znaków alfanumerycznych, oznaczających minimalną i maksymalną liczbę takich obiektów. Liczność jest oznaczana dla wszystkich końców asocjacji. Na Rys. 5 dla asocjacji łączącej klasy A i B liczność określa: minimalną i maksymalną liczbę obiektów klasy B powiązanych z jednym obiektem klasy A, co zostało poglądowo oznaczone jako A > B: min, max; ta para jest zapisywana przy klasie B; minimalną i maksymalną liczbę obiektów klasy A powiązanych z jednym obiektem klasy B, co zostało poglądowo oznaczone jako B > A: min, max; ta para jest zapisywana przy klasie A.

A A A A A A,2 B B B 0.. A B: min = 0, max = B A: min =, max = 2 B A A A A A A 2,3 B B B A B: min =, max = 3 B A: min = 2, max = 3 B..3 Rys. 5. Określanie liczności asocjacji Na przykład, dla jeden obiekt klasy A jest powiązany z 0 lub obiektem klasy B (specyfikowane przy klasie B), natomiast jeden obiekt klasy B jest powiązany z lub 2 obiektami klasy A (specyfikowane przy klasie A). Przykładowe oznaczenia liczności asocjacji uŝywane w UML przedstawia Tab.. Przykładowa liczność w UML.. 2.. 3..5 2, 4, 8 brak 0.. 0.. Znaczenie, 2, 3,... 2, 3, 4,... 3, 4, 5 2, 4, 8 nie oznaczono liczności albo 0, 0,, 2,... 0,, 2,... Tab.. Oznaczenia dla liczności asocjacji w UML ZauwaŜmy, Ŝe brak specyfikacji liczności moŝe oznaczać zarówno liczność, jak i to, Ŝe jeszcze nie została ona określona, co jest dozwolone w początkowym okresie tworzenia modelu. JednakŜe generalnie zalecane jest zaznaczanie liczności w sytuacji, gdy jest juŝ określona. Cztery przykładowe diagramy zawierające specyfikacje liczności asocjacji są przedstawione na Rys. 6: diagram kaŝde państwo posiada dokładnie jedną stolicę; kaŝda stolica jest stolicą dokładnie jednego państwa; diagram firmy zatrudniają dowolną liczbę pracowników, przy czym mogą nikogo nie zatrudniać; pracownik pracuje w dokładnie jednej firmie; diagram (c) osoba moŝe, ale nie musi, mieć przypisany adres; do danego adresu moŝe być przypisanych wiele osób, jednak moŝe nikt nie być przypisany;

diagram (d) w firmie pracuje co najmniej jedna osoba; osoba pracuje dla dokładnie jednej firmy. Country Capital Employee (c) 0.. 0.. Address (d) works for.. Rys. 6. Przykłady diagramów z wyspecyfikowaną licznością asocjacji Role asocjacji Dodatkową informacją specyfikującą asocjację są nazwy ról (w skrócie: role). Rola określa zarówno funkcję, jaką klasa pełni w asocjacji, jak i kierunek nawigowania w wyraŝeniach ścieŝkowych poprzez specyfikowanie klasy cel. Na przykład, na Rys. 7 rola pracodawca jako cel wyznacza kierunek nawigowania od obiektu klasy Osoba do powiązanych z nim obiektów klasy Firma. W konsekwencji wyraŝenie ścieŝkowe: osoba.pracodawca określa zbiór pracodawców danej osoby. works for.. employer employee subordinate 0.. boss Rys. 7. Przykładowe role asocjacji Role asocjacji są opcjonalne. Niemniej jednak, gdy powiązanie łączy obiekty tej samej klasy (jest to powiązanie rekursywne i odpowiadająca mu asocjacja rekursywna), to wówczas naleŝy specyfikować role, ewentualnie uŝywać symbolu czarnego trójkąta. Przykładowo, na Rys. 7 asocjacja łącząca klasę Osoba z nią samą ma zdefiniowane dwie role: szef i podwładny. Role (jedną lub więcej) moŝna wykorzystać, podobnie jak nazwę asocjacji, do specyfikowania asocjacji. PoniewaŜ jednak z załoŝenia z diagramów powinno się usuwać wszelką informację redundantną w celu zwiększenia ich czytelności jednoczesne uŝywanie nazwy asocjacji i ról asocjacji nie jest zalecane. Wydaje się, Ŝe diagram na Rys. 7 byłby wystarczająco dobrze opisany, gdyby do oznaczenia asocjacji pomiędzy klasami Firma i Osoba wykorzystano wyłącznie nazwę albo jedną z ról (np. pracodawca). Ponadto, co nie jest bez znaczenia w przypadku języka polskiego, często łatwiej jest określić rolę (jedną lub dwie) niŝ znaleźć krótką, ale oddającą charakter związku między klasami, nazwę dla asocjacji. Atrybuty asocjacji Dla asocjacji, podobnie jak dla klasy, moŝna zdefiniować opisujące ją atrybuty, tzw. atrybuty asocjacji. W języku UML atrybuty asocjacji są umieszczane w specjalnej klasie, zwanej klasą asocjacji, która jest połączona z asocjacją za pomocą przerywanej linii. Oprócz atrybutów, klasa asocjacji, tak jak kaŝda zwykła klasa, moŝe posiadać takie własności, jak asocjacje, metody itd. Przykładem klasy asocjacji jest klasa Zatrudnienie na Rys. 8 klasa ta przechowuje informacje o stanowisku zajmowanym przez osobę zatrudnioną w firmie oraz o pobieranym przez nią wynagrodzeniu. Asocjacja i klasa asocjacji są traktowane jako jeden, a nie dwa elementy modelu.

boss 0.. surname personal id address employs.. Employment 0.. name addres salary position Performance rating rating Rys. 8. Diagram zawierający klasy asocjacji Jeśli klasa asocjacji nie zawiera metod ani asocjacji, jej nazwa moŝe zostać opuszczona dla podkreślenia faktu, Ŝe nie jest to klasa w pełnym tego słowa znaczeniu (Rys. 9). File accessible to access User { access means: reading or reading-writing } Rys. 9. Diagram z klasą asocjacji bez nazwy Zalecane jest, aby przypisywać do klasy tylko te atrybuty, które są dla niej stabilne. Pomocne w podjęciu decyzji o tym, gdzie umieścić atrybut tzn. w klasie asocjacji czy teŝ w zwykłej klasie moŝe być następujące rozumowanie: co się stanie w sytuacji, gdy liczność asocjacji się zmieni? Wówczas dość często okazuje się, Ŝe atrybut jest atrybutem asocjacji, a nie klasy. Diagram na Rys. 0 pokazuje sposób rozmieszczenia atrybutów, który nie jest zalecany, poniewaŝ po zmianie liczności asocjacji na wiele-do-wielu konieczna jest zmiana połoŝenia atrybutów zarobek i stanowisko; wady tej nie posiada diagram na Rys.. works for surname personal id address salary position.. 0.. name address Rys. 0. Diagram ilustrujący potencjalnie nieelastyczne rozmieszczenie atrybutów works for surname personal id address.. 0.. name address Employment salary position Rys.. Diagram ilustrujący elastyczne rozmieszczenie atrybutów Asocjacje skierowane Na diagramach UML za pomocą grotu moŝna oznaczać kierunek nawigowania wzdłuŝ danej asocjacji definiując asocjację skierowaną. W takim przypadku na poziomie implementacji asocjacja zostanie odwzorowane tylko w jedną

stronę. Na przykład, na Rys. 2 moŝliwa jest nawigacja od obiektów klasy Zamówienie do obiektów klasy Klient, podczas gdy nawigacja w przeciwnym kierunku nie jest moŝliwa. Innymi słowy, moŝna zbudować wyraŝenie ścieŝkowe zamówienie.klient, ale nie moŝna zbudować wyraŝenia klient.zamówienie. Na poziomie implementacyjnym będzie to oznaczało, Ŝe obiekt klasy Zamówienie będzie posiadał atrybut przechowujący identyfikator obiektu klasy Klient, podczas gdy drugi kierunek nawigowania nie będzie w ogóle implementowany. Order order date is it paid total amount send () close () Client surname address reliability () Orders element quantity price is it sent Product Rys. 2. Diagram z asocjacjami skierowanymi NaleŜy podkreślić, Ŝe oznaczenie kierunku asocjacji jest czynnością wykonywaną zazwyczaj dopiero w fazie projektowania, a nie analizy, w oparciu o zapytania kierowane do systemu. Przykładowy diagram klas Rys. 3 przedstawia przykładowy, nieco większy niŝ prezentowane dotychczas, diagram klas, odpowiadający poniŝszym wymaganiom uŝytkownika: System ma za zadanie przechowywać informacje o pracownikach (w tym profesorach), studentach oraz przeprowadzonych kursach. Kurs moŝe być poprzedzony innym kursem; sam takŝe moŝe poprzedzać inne kursy. KaŜdy kurs składa się z co najmniej jednego wykładu. Wykład wchodzi w skład tylko jednego kursu. NaleŜy pamiętać informacje o tym, na które wykłady był zapisany kaŝdy ze studentów. Student moŝe być zapisany na wiele wykładów (co najmniej jeden). Na jeden wykład moŝe być zapisanych wielu studentów (co najmniej jeden). Wykład jest prowadzony przez jednego profesora. Profesor moŝe prowadzić wiele wykładów; moŝe teŝ nie prowadzić Ŝadnego wykładu. previous enlisted in.. Student Employee 0.. next Course Professor includes prowadzacy.. Lecture.. Rys. 3. Przykładowy diagram klas

Dziedziczenie asocjacji Asocjacje, podobnie jak inne własności klasy (np. atrybuty i metody), są dziedziczone przez podklasy. W celu ilustracji zagadnienia rozwaŝmy diagram z Rys. 4, gdzie dwie asocjacje o nazwach asoc i asoc2 łączą klasę K z klasami K2 i K3, będącymi podklasami klasy K. Aby, w oparciu o mechanizm dziedziczenia, te dwie asocjacje mogły być zastąpione przez jedną asocjacją prowadzącą od K do K (Rys. 4 ), asocjacje z diagramu muszą spełniać co najmniej dwa pierwsze z trzech następujących warunków:. muszą posiadać taką samą semantykę; 2. muszą posiadać taką samą strukturę, tzn. muszą mieć takie same atrybuty lub taką samą klasę asocjacji; 3. muszą łączyć klasę K z wszystkimi podklasami klasy K, przy czym w przypadku róŝnych liczności asocjacji naleŝy zdefiniować odpowiednie ograniczenia. K K2 K3 K association association_ K association_2 K2 K3 K Rys. 4. Schemat dziedziczenia asocjacji Przykład przedstawiony na Rys. 5, Rys. 6 i Rys. 7 ilustruje problem opisany w ostatnim z powyŝszych warunków: dwie róŝniące się licznościami asocjacje wygłaszany z Rys. 5, prowadzące od klasy Sesja do klas Zaproszony i Zwykły, zostały na Rys. 6 zastąpione jedną asocjacją wygłaszany prowadzącą od Sesja do Referat. PoniewaŜ zgodnie z Rys. 5 w trakcie kaŝdej sesji jest wygłaszany co najmniej jeden referat, zatem na Rys. 6 liczność asocjacji po stronie klasy Referat wynosi..; podobnie dla drugiego końca asocjacji. Zwróćmy uwagę, Ŝe te liczności, chociaŝ generalnie odpowiadają sytuacji z diagramu wyjściowego, sprawiają, iŝ z Rys. 6 nie moŝna wywnioskować, po ile referatów kaŝdego rodzaju jest wygłaszanych w trakcie sesji. Informację tę naleŝy nanieść na diagram w inny sposób, na przykład w postaci odpowiednio zdefiniowanych ograniczeń (Rys. 7). Paper {abstract} title authors [..] 0.. Invited Regular paper paper mark presented at presented at.. 0.. Paper/Session hour Session name date Paper/Session hour Rys. 5. Asocjacja wygłaszany łączy klasę Sesja z podklasami

Paper {abstract} title authors [..].. Paper/Session hour presented at Invited paper Regular paper mark 0.. Session name date Rys. 6. Asocjacja wygłaszany łączy klasę Sesja z nadklasą {during each session, at least one regular paper and maximally one invited paper could be presented} Paper {abstract}.. title authors [..] Invited Regular paper paper mark Paper/Session hour presented at 0.. Session name date {regular paper may not be presented during any session} Rys. 7. Zdefiniowano brakujące ograniczenia dla diagramu z Rys. 6 Sytuacja przedstawia się inaczej, gdy asocjacje posiadają nie tylko identyczne semantykę i strukturę, ale równieŝ liczności. Przykład diagramu zawierającego takie asocjacje przedstawiony jest na Rys. 8 ; równowaŝny mu diagram zilustrowany jest na Rys. 8. Jak łatwo zauwaŝyć, w tym przypadku nie istnieje potrzeba zdefiniowania ograniczeń dotyczących liczności asocjacji. Vehicle owns Car is owned by purchase date Samochód Truck is owned by purchase date Vehicle purchase date Firma Car Truck Rys. 8. Przykład dziedziczenia asocjacji dla przypadku, gdy liczności asocjacji są identyczne

Asocjacja pochodna Asocjacja pochodna jest to asocjacja, której istnienie moŝna wywnioskować z faktu istnienia innych asocjacji. ZauwaŜmy, Ŝe zgodnie z tą definicją asocjacja pochodna nie wprowadza Ŝadnej nowej informacji. W związku z tym zaleca się, aby w celu minimalizacji wielkości modelu i zwiększenia jego czytelności nie zaznaczać na nim tego typu asocjacji, chyba Ŝe z pewnych względów naniesienie jej na diagram jest korzystne, np. w celu skrócenia drogi nawigowania. W takim przypadku wymaga się jednak, aby asocjacja została explicite oznaczona jako pochodna, za pomocą ukośnika umieszczonego przed jej nazwą. PowyŜszy problem zilustrowany jest na Rys. 9: jeŝeli osoba, modelowana za pomocą klasy Osoba, mieszka w tym samym mieście, w którym pracuje, to jedna z dwóch asocjacji: mieszka w (diagram ) albo znajduje się w (diagram ) jest pochodna. Sytuacja ulegnie zmianie, gdy osoba będzie mogła nie pracować, czyli liczność roli pracodawca dla klasy Firma będzie wynosić 0.., a nie dokładnie... /lives in City.. works for employer.. is in.. lives in City.. works for employer.. /is in Rys. 9. Przykłady asocjacji pochodnych PoniewaŜ główną motywacją dla specyfikowania asocjacji pochodnych jest poprawa efektywności działania systemu informatycznego, czynność ta wykonywana jest raczej w fazie projektowania niŝ w fazie analizy. Obejście klasy asocjacji JeŜeli środowisko implementacji nie wspiera pojęcia klasy asocjacji, to w fazie projektowania naleŝy kaŝdą klasę asocjacji i związaną z nią asocjację przekształcić na równowaŝny semantycznie fragment diagramu, który takich klas nie zawiera. Niestety, związane jest to z częściową utratą informacji, gdyŝ jedna asocjacja binarna (z własnościami zawartymi w klasie asocjacji) zostaje zamieniona na dwie wzajemnie niezaleŝne asocjacje. Schemat postępowania przedstawiony jest na Rys. 20, gdzie klasę asocjacji K i związaną z nią asocjację (diagram ) zamieniono na zwykłą klasę K i dwie asocjacje (diagram ). Zwróćmy uwagę, Ŝe przyjmując, iŝ x i y oznaczają liczności wiele, zastosowane przekształcenie moŝe słuŝyć do redukcji liczności wiele-do-wielu: jedna asocjacja wiele-do-wielu jest zastępowana przez dwie asocjacje jeden-do-wielu.

K x K y K2 K K a y x K2 a2 a a2 Rys. 20. Schemat obejścia klasy asocjacji Na Rys. 2 przedstawiono przykład zastosowania omawianej techniki. Zwróćmy uwagę, Ŝe w celu zilustrowania faktu, iŝ dzięki licznościom równym dokładnie przy klasach Osoba i Firma pomiędzy tymi klasami istnieje pośredni związek, wprowadzono pochodną rolę 2 pracodawca wraz z asocjacją łączącą te klasy... Employment position salary Rys. 2. Przykład obejścia klasy asocjacji Role wielowartościowe Employment.. position salary.. /employer Rola wielowartościowa jest to rola, dla której górna granica liczności (innymi słowy, górna granica liczności danego końca asocjacji) jest większa od. Na Rys. 22 wielowartościowa rola r2 oznacza, Ŝe kaŝdy obiekt klasy K posiada przypisany do siebie zbiór obiektów klasy K2 występujących w tej roli w związku; liczność przy r2 informuje, Ŝe nie wprowadzono ograniczenia na rozmiar tego zbioru. K r r2 K2 Rys. 22. Rola wielowartościowa Generalnie, dla ról przyjmuje się, Ŝe: Dany obiekt pojawia się tylko jeden raz w zbiorze obiektów opisującym rolę; Rys. 23. Zbiór obiektów opisujący daną rolę jest nieuporządkowany. Specjalne, predefiniowane w UML, ograniczenie {ordered} pozwala na jego uporządkowanie; Rys. 23. 2 Pochodna rola jest pojęciem analogicznym do pojęcia pochodnej asocjacji.

a incorrect diagram :K a :K2 correct diagram :K a a :K2 :K2 Rys. 23. Interpretacja roli wielowartościowej..2 K K2 a {ordered} Oczywiście pomiędzy dwoma tymi samymi obiektami moŝe wystąpić więcej niŝ jedno powiązanie, ale nie mogą to być powiązania o tej samej semantyce, czyli powiązania będące instancjami tej samej asocjacji (Rys. 24). works for 0.. is a company manager 0.. works for Nowak : IBM : is a company manager Rys. 24. Przykład dwóch asocjacji/powiązań łączących te same klasy/obiekty Na poziomie implementacyjnym rola wielowartościowa jest odwzorowywana w zbiór obiektów danej klasy, które są powiązane z jednym obiektem klasy znajdującej się na drugim końcu asocjacji. Ograniczenie {bag} Zgodnie z tym, co powiedzieliśmy wcześniej, przyjmuje się, Ŝe tylko jeden raz dany obiekt moŝe pojawić się w zbiorze obiektów opisującym rolę. JeŜeli potencjalnie takich obiektów moŝe być więcej, naleŝy wykorzystać ograniczenie {bag}; ograniczenie to, mimo Ŝe dotyczy obu ról, jest oznaczane tylko przy jednym z końców asocjacji. Przykład zaprezentowany jest na Rys. 25, gdzie część przedstawia pewien diagram klas zawierający asocjację z ograniczeniem {bag}, natomiast część przedstawia odpowiadający mu pewien diagram obiektów.

.. {bag} Employment employment date dissmisal date position salary : Employment X : 0.0.990 5.2.995 programmer 2000 Y : : Employment 0.0.998 NULL analyst 5000 Rys. 25. Przykład zastosowania ograniczenia {bag} Stereotyp «history» Stereotyp «history» podobnie jak ograniczenie {bag} pozwala na utworzenie więcej niŝ jednego powiązania o danej semantyce pomiędzy dwoma obiektami. Stereotyp ten stosowany jest przede wszystkim do rejestrowania zmian w czasie. Przykład z Rys. 26 pokazuje zastosowanie «history» do ewidencjonowania historii zatrudnienia osób w firmach.

.. «history» employer Employment employment date dissmisal date position salary : Employment 0.0.990 5.2.995 : programmer 2000 : Rys. 26. Przykład zastosowania stereotypu «history» : Employment 0.0.998 NULL analyst 5000 Efekt podobny do zastosowania {bag} czy «history» moŝna uzyskać wprowadzając klasę pośredniczącą, tak jak na Rys. 27. Zwróćmy jednak uwagę, Ŝe klasa pośrednicząca Zatrudnienie pozwala wprawdzie na utworzenie wielu powiązań pomiędzy dwoma wystąpieniami klas Osoba i Firma, ale nie uwidacznia tego faktu w sposób jawny. Employment Osoba employment date dissmisal date position salary.. Firma : Employment 0.0.990 5.2.995 programmer 2000 : Osoba : Firma : Employment 0.0.998 NULL analyst 5000 Rys. 27. Zastosowanie klasy pośredniczącej zamiast {bag} bądź «history»

Agregacja Agregacja jest specjalnym rodzajem asocjacji wykorzystywanym przede wszystkim do modelowania związku częśćcałość. Przykładem agregacji jest związek pomiędzy silnikiem a samochodem, którego ten silnik jest częścią. Niestety, nie istnieje jedna powszechnie akceptowana definicja agregacji; w szczególności, P. Coad podaje jako przykład agregacji związek pomiędzy firmą a jej pracownikami, podczas gdy J. Rumbaugh twierdzi, Ŝe firma nie jest agregacją jej pracowników. W wielu przypadkach związki agregacji są oczywiste, jednakŝe wątpliwości powstają nawet w przypadku samochodu i silnika, poniewaŝ silnik moŝe być towarem w sklepie nie związanym z Ŝadnym konkretnym samochodem. Powstaje ponadto pytanie, czy rozwaŝamy konkretny samochód i konkretny silnik, czy teŝ typ samochodu i typ silnika? Mętlik wokół pojęcia agregacji wynika równieŝ z tego, Ŝe jest ono naduŝywane w celu usprawiedliwienia niektórych ograniczeń obiektowych modeli danych. Na przykład, popularne wyjaśnienie powodu braku wielokrotnego dziedziczenia podaje, Ŝe moŝna je obejść przez agregację, co jest nonsensem z punktu widzenia modelowania pojęciowego, podobnie jak zdanie: asocjacje są zbędne, bo moŝna je obejść przez atrybuty. Przykład agregacji pokazany jest na Rys. 28 (pusty romb oznaczający agregację jest umieszczany po stronie obiektucałości, nazywanego czasami agregatem): w skład grupy wchodzi od jednego do piętnastu studentów, przy czym student moŝe naleŝeć do dowolnej liczby grup; dla kaŝdego studenta przechowywana jest informacja o tym, w jakim okresie naleŝał do danej grupy. Group..5 Student Student/Group assigned since assigned to Rys. 28. Przykład agregacji PoniewaŜ agregacja słuŝy do modelowania związku część-całość, role kaŝdego uczestnika takiego związku są ściśle określone: o całości mówi się, Ŝe: składa się z, zawiera, obejmuje itp.; o części mówi się, Ŝe: wchodzi w skład, naleŝy do, jest zawarta w itp. W związku z tym zarówno nazwy ról, jak i nazwy agregacji są zazwyczaj opuszczane, zgodnie z regułą, Ŝe dla poprawy czytelności diagramów wszystkie elementy redundantne powinny być z nich usuwane. Wyjątek mogą stanowić sytuacje, gdy Ŝadna z wyŝej wymienionych nazw nie jest w pełni zgodna z semantyką relacji zachodzącej między analizowanymi bytami w dziedzinie problemowej, a chcemy podkreślić fakt istnienia silnej formy asocjacji, jak często nazywana jest agregacja, np. w celu wykorzystania propagacji operacji (patrz dalej). Agregacja charakteryzuje się następującymi waŝnymi własnościami: jest relacją asymetryczną, co oznacza, Ŝe obiekt nie moŝe wystąpić zarówno w charakterze całości, jak i w charakterze części w stosunku do innego obiektu; jest relacją przechodnią (tranzytywną), tzn. jeśli obiekt klasy C wchodzi w skład obiektu klasy B, a obiekt klasy B wchodzi w skład obiektu klasy A, to pośrednio obiekt klasy C wchodzi w skład obiektu klasy A. W literaturze wyróŝnia się kilka podstawowych kryteriów, którymi powinien kierować się analityk podejmując decyzję o tym, czy w danym przypadku zastosować agregację czy teŝ zwykłą asocjację: kryterium istnienia byt-część nie istnieje samodzielnie bez bytu-całości, co na poziomie implementacyjnym oznacza, Ŝe obiekt implementujący część zawsze musi być powiązany z obiektem modelującym całość; kryterium wstawiania 3 byt-część nie moŝe pojawić się, jeŝeli jeszcze nie istnieje byt-całość; kryterium usuwania usuwanie bytu-całości powinno skutkować usunięciem wszystkich powiązanych z nim bytów-części; kryterium fizycznej części byt-całość i byt-część są ze sobą nierozerwalnie związane; kryterium to rozwaŝaliśmy na początku podrozdziału. PoniewaŜ agregacja lepiej niŝ zwykła asocjacja modeluje silny związek pomiędzy bytami dziedziny problemowej, w niektórych przypadkach warto zastosować agregację nawet wówczas, gdy Ŝadne z powyŝszych kryteriów nie jest spełnione. Takie postępowanie jest uzasadnione m.in. w sytuacji, gdy chcemy skorzystać z propagacji operacji, czyli z 3 ZbliŜone do kryterium istnienia.

automatycznego wywołania w bytach składowych tej samej operacji, która została wywołana w stosunku do całości. Przykład przedstawiony jest na Rys. 29, gdzie strzałka etykietowana nazwą operacji zmień plan wskazuje na to, Ŝe operacja ta będzie wykonana automatycznie dla wszystkich części składowych agregatu, czyli dla wszystkich studentów grupy. Group plan change plan Rys. 29. Przykład propagacji operacji change plan..5 Student/Group assigned since assigned to Student plan change plan Agregacja rekursywna Agregacja rekursywna jest specjalnym rodzajem agregacji, dla której obiekt-całość i obiekty-części są instancjami tej samej klasy. Przykład agregacji rekursywnej pokazany jest na diagramie z Rys. 30 : obiekt klasy K moŝe zarówno wchodzić w skład innego obiektu klasy K, jak i zawierać inny obiekt klasy K, natomiast Rys. 30 przedstawia przykładowy diagram obiektów dla schematu. :K 0.. K 0.. :K :K Rys. 30. Agregacja rekursywna z dwoma licznościami 0.. Ze względu na to, Ŝe agregacja modeluje związek część-całość, naleŝy zwrócić szczególną uwagę na liczności, a zwłaszcza na to, Ŝe kaŝda z liczności musi dopuszczać opcjonalność połączenia. Na diagramie z Rys. 30 kaŝda instancja klasy K moŝe, ale nie musi, być całością lub częścią dla innej instancji tej klasy. JeŜeli jednak którakolwiek z liczności zostałaby zamieniona z opcjonalnej na, diagram przestałby być poprawny. W celu ilustracji problemu rozwaŝmy tego typu zmianę na obu końcach agregacji. Odpowiedni diagram klas i zgodny z nim przykładowy diagram obiektów są przedstawione na Rys. 3. Aby udowodnić niepoprawność diagramów, przeanalizujmy dwa przykładowe obiekty: o i o3. Bezpośrednie powiązanie tych obiektów za pomocą agregacji oznacza, Ŝe o wchodzi w skład o3. Z drugiej strony, na mocy własności przechodniości, o występuje w charakterze całości w stosunku do o3 (o zawiera o2, o2 zawiera o3, a więc pośrednio o zawiera o3). Podobne rozwaŝania moŝna przeprowadzić dla dowolnej pary obiektów i zawsze otrzymamy ten sam wynik kaŝdy obiekt klasy K występuje zarówno w charakterze całości, jak i w charakterze części w stosunku do innego obiektu tej klasy, co jest sprzeczne z zasadą asymetrii dla agregacji. Diagram jest więc niepoprawny; innymi słowy, kaŝda z liczności musi dopuszczać opcjonalność połączenia.

o : K K o2 : K o3 : K K 0.. (c) 0.. Rys. 3. Agregacje rekursywne z co najmniej jedną licznością Na mocy powyŝszej dyskusji diagramy klas z Rys. 3 i Rys. 3 (c) są takŝe niepoprawne. K Diagram klas i zgodny z nim przykładowy diagram obiektów dla sytuacji, w której liczność roli po stronie części wynosi wiele, są przedstawione odpowiednio na Rys. 32 i Rys. 32. Tak jak poprzednio, obie role muszą dopuszczać opcjonalność połączenia. :K K 0.. :K :K :K :K :K :K Rys. 32. Agregacja rekursywna z licznościami 0.. i wiele Dwa kolejne przykładowe diagramy klas dla schematu z Rys. 32 przedstawia Rys. 33: diagram informuje o tym, Ŝe część moŝe składać się z pewnej liczby innych części, natomiast diagram modeluje sytuację, w której w skład kaŝdego z oddziałów firmy mogą wchodzić inne oddziały tej samej firmy. Część nazwa materiał wymiary 0.. Firma Oddział 0.. Rys. 33. Przykładowy diagram klas dla schematu z Rys. 32 Rys. 34 ilustruje sytuację, gdy obie liczności agregacji są typu wiele. W ten sposób pojedynczy obiekt klasy K moŝe składać się z dowolnej liczby innych obiektów klasy K oraz moŝe sam wchodzić w skład dowolnej liczby innych obiektów klasy K (Rys. 34 ).

:K K :K :K :K :K :K :K Rys. 34. Agregacja rekursywna z dwoma licznościami wiele Rys. 35 przedstawia dwa nieco bardziej złoŝone przykłady wykorzystania agregacji rekursywnych. Diagram jest modelem programu komputerowego, który składa się z bloków programowych, czyli instrukcji prostych oraz instrukcji złoŝonych będących agregacją bloków programowych. Z kolei diagram przedstawia schemat wyraŝenia algebraicznego, którym jest: pojedyncza stała, pojedyncza zmienna albo kombinacja stałych i zmiennych połączonych operatorami. Zwróćmy uwagę na to, Ŝe w tej odmianie agregacji rekursywnej liczność po stronie części nie dopuszcza opcjonalności nie jest to jednak błąd, gdyŝ klasa modelująca część posiada przynajmniej jedną podklasę, która nie uczestniczy w agregacji. Program.. Blok 0.. Instrukcja złoŝona Instrukcja prosta 2-gi operand -szy operand Człon WyraŜenie Zmienna Stała operator binarny nazwa wartość Rys. 35. Przykłady złoŝonych agregacji rekursywnych Agregacja a kompozycja Podstawowym zadaniem agregacji, jak było omawiane wcześniej, jest modelowanie relacji część-całość występującej pomiędzy bytami świata rzeczywistego. Niemniej jednak agregacja moŝe być uŝyta takŝe jako pomocniczy środek do modelowania dowolnej innej sytuacji, np. gdy istnieje potrzeba połączenia pary bytów związkiem nierozerwalnym, o dowolnej semantyce, nie wykluczając semantyki część-całość. Związek ten jest nierozerwalny w tym znaczeniu, Ŝe nie ma sensu samodzielne istnienie bytu podrzędnego byt podrzędny moŝe być rozpatrywany wyłącznie w relacji z pewnym bytem nadrzędnym, np. pracownik i jego polisa ubezpieczeniowa. W UML dla modelowania tego rodzaju sytuacji wprowadzono silną formę agregacji zwaną kompozycją. Przyjęto, Ŝe aby w procesie modelowania moŝna było wykorzystać kompozycję, powinny być spełnione dwa poniŝsze warunki:

cykl Ŝyciowy składowej zawiera się w cyklu Ŝyciowym całości; kryterium: byt podrzędny nie moŝe istnieć, gdy nie istnieje byt nadrzędny; byt podrzędny musi zostać usunięty, gdy usuwany jest byt nadrzędny 4 ; poniewaŝ byt podrzędny jest usuwany razem z bytem nadrzędnym, nie moŝe być powiązany z więcej niŝ jednym bytem nadrzędnym. Kompozycja jest oznaczana za pomocą zaczernionego rombu umieszczanego po stronie klasy modelującej całość. Tak jak w przypadku zwykłej agregacji, dla kompozycji z reguły nie specyfikuje się nazwy, ról itd., choć i tutaj, podobnie jak dla agregacji, moŝliwe są wyjątki. Na przykład, w sytuacji jak na Rys. 36, dotyczy wydaje się być nazwą bardziej naturalną niŝ nazwa domyślna dla kompozycji ( wchodzi w skład, zawiera, obejmuje itp.). Pracownik dotyczy 0.. Ubezpieczenie Rys. 36. Przykład nazwanej kompozycji Liczność jest licznością domyślną, w związku z czym nie oznacza się jej na diagramie. Specyfikowana jest jedynie liczność 0.. w sytuacji, gdy obiekty danej klasy mogą być elementami składowymi róŝnych klas (oczywiście nie jednocześnie). Diagram na Rys. 37 prezentuje popularny przykład dyskusyjnego zastosowania kompozycji do specyfikowania wieloboków za pomocą uporządkowanego ciągu punktów. Przedstawione rozwiązanie posiada zarówno wady, jak i zalety. Główną wadą jest to, Ŝe punkt na płaszczyźnie, w którym przecinają się wierzchołki wielu Wieloboków, jest odwzorowywany w wiele obiektów klasy Punkt. Dla agregacji powyŝsza sytuacja nie miałaby miejsca, gdyŝ składowa mogłaby być współdzielona, tak jak to ma miejsce dla związku między klasami Wielobok i Styl. Zaletą rozwiązania jest to, Ŝe dzięki kompozycji mniej problemów nastręcza usuwanie wieloboków, związane z usuwaniem opisujących je punktów. Dla agregacji kaŝde usunięcie wieloboku, powiązane z usunięciem opisujących go punktów, wymagałoby sprawdzenia, czy będący potencjalnym kandydatem do usunięcia punkt nie opisuje takŝe innego wieloboku. 3.. {ordered} Punkt Wielobok Styl kolor czy wypełniony Rys. 37. Przykład wykorzystania kompozycji i agregacji ZauwaŜmy, Ŝe w tym przykładzie liczność kompozycji po stronie całości musiałaby być oznaczona jako 0.. w sytuacji, gdyby obiekty klasy Punkt mogły wchodzić w skład nie tylko obiektów klasy Wielobok, ale takŝe na przykład w skład obiektów klasy Linia. Wówczas naleŝałoby na obie kompozycje nałoŝyć ograniczenie {xor}. Delegacja alternatywa dla dziedziczenia Delegacja jest koncepcją projektowania struktur danych, zgodnie z którą operacje, które moŝna wykonać na danym obiekcie, są własnością innego obiektu; innymi słowy, są oddelegowywane do innego obiektu. Delegację moŝna uwaŝać za alternatywę dla klasycznego mechanizmu dziedziczenia, gdyŝ w przypadku delegacji mamy do czynienia z omawianym w wykładzie poświęconym generalizacji-specjalizacji dziedziczeniem dynamicznym. Przeanalizujmy przykład z Rys. 38, gdzie do implementacji stosu wykorzystana jest implementacja listy. Na diagramie klasa Stos jest podklasą klasy Lista, w związku z czym dziedziczy jej wszystkie własności. Nie jest to jednak sytuacja poŝądana, poniewaŝ stos powinien udostępniać uŝytkownikowi tylko właściwe dla siebie operacje, takie jak push, pop, top itd., podczas gdy udostępnia takŝe operacje charakterystyczne dla listy. Alternatywne rozwiązanie posiadające tę cechę przedstawia diagram, gdzie klasa Stos zawiera atrybut zawartość typu Lista w ten sposób obiekt klasy Stos składa się z podobiektu będącego wystąpieniem klasy Lista, w wyniku czego obsługa obiektu modelującego stos jest (częściowo) oddelegowana do obiektu modelującego listę. Na poziomie implementacyjnym takie rozwiązanie oznaczałoby wywołanie w ciele metod push, pop i top odpowiednich metod zdefiniowanych w klasie Lista. Bezpośredni dostęp do metod klasy Lista dla wystąpień klasy Stos, jak na schemacie, nie jest tu moŝliwy. 4 Uwaga: usunięcie bytu podrzędnego nie pociąga za sobą konieczności usunięcia bytu nadrzędnego.

... Lista ustaw na pierwszy ustaw na następny ustaw na ostatni dodaj pobierz usuń zawartość top push pop Stos «instanceof» zawartość top push pop Stos... Lista ustaw na pierwszy ustaw na następny ustaw na ostatni dodaj pobierz usuń Rys. 38. Przykład delegacji Asocjacja kwalifikowana Dla kaŝdego końca asocjacji moŝna zdefiniować kwalifikator, czyli zbiór atrybutów (co najmniej jednoelementowy), których zadaniem jest jednoznaczna identyfikacja obiektów klasy połoŝonej po drugiej stronie tej asocjacji. Asocjacja, dla której określono kwalifikator, nazywana jest asocjacją kwalifikowaną. Kwalifikator jest umieszczany w małym prostokącie przyległym do symbolu klasy. Przykład zastosowania kwalifikatora jest przedstawiony na Rys. 39. Diagram modeluje dwie klasy, Katalog i Plik, połączone asocjacją. ZałóŜmy, Ŝe dla klasy Plik zdefiniowano ograniczenie na wartości jej atrybutu nazwa pliku, zgodnie z którym pliki przechowywane w danym katalogu muszą róŝnić się między sobą nazwami. RównowaŜny semantycznie diagram klas wykorzystujący asocjację kwalifikowaną przedstawia diagram, na którym informacja o tym, Ŝe nazwa pliku w sposób jednoznaczny identyfikuje plik w danym katalogu, jest przedstawiona za pomocą: kwalifikatora nazwa pliku po stronie klasy Katalog; liczności 0.. po stronie klasy Plik. Dolna granica liczności (czyli 0) oznacza, Ŝe dopuszcza się wystąpienie takiej wartości kwalifikatora, która nie identyfikuje Ŝadnego obiektu. Katalog Plik nazwa pliku Katalog nazwa pliku 0.. Plik Rys. 39. Przykład asocjacji kwalifikowanej Rys. 40 przedstawia przykład kwalifikatora, w skład którego wchodzi więcej niŝ jeden atrybut. Kwalifikatorem tym jest zbiór atrybutów {rząd, kolumna}, który pozwala jednoznacznie zidentyfikować kwadrat w tablicy zbudowanej ze stu kwadratów.

Tablica 00 Kwadrat rząd kolumna Tablica rząd kolumna 0.. Kwadrat { tablica zawiera dokładnie 00 kwadratów } Rys. 40. Przykład kwalifikatora składającego się z dwóch atrybutów Asocjacja kwalifikowana, tak jak kaŝda asocjacja, moŝe posiadać atrybuty. Na przykład, dla asocjacji z Rys. 4 i Rys. 42 zdefiniowana została klasa asocjacji Konto przechowująca pewne informacje o koncie. Zwróćmy uwagę, Ŝe numer konta w powiązaniu z nazwą banku jednoznacznie identyfikuje jego właściciela (Rys. 4) lub właścicieli (zgodnie z Rys. 42 konto moŝe mieć nawet trzech właścicieli), w związku z czym atrybut nr konta jest de facto kwalifikatorem. Opcjonalność po stronie klasy Osoba oznacza, Ŝe bank moŝe posiadać wolne numery kont. Bank nazwa Konto Osoba imię nazwisko nr konta data załoŝ. { do konta jest przypisana dokładnie osoba } Bank nazwa nr konta 0.. Osoba imię nazwisko Konto data załoŝ. Rys. 4. Asocjacja kwalifikowana z licznością 0..

Bank nazwa Konto Osoba imię nazwisko nr konta data załoŝ. { do konta są przypisane co najwyŝej 3 osoby } Bank nazwa nr konta 0..3 Osoba imię nazwisko Konto data załoŝ. Rys. 42. Asocjacja kwalifikowana z licznością 0..3 Przesłanki, którymi kierowano się wprowadzając do dziedziny modelowania pojęciowego konstrukcję taką jak asocjacja kwalifikowana, moŝna scharakteryzować następująco: z perspektywy pojęciowej asocjacja kwalifikowana informuje, Ŝe pewien zbiór atrybutów pozwala na identyfikację grup obiektów; z perspektywy projektowej asocjacja kwalifikowana stanowi wskazanie na moŝliwość zaimplementowania danego elementu modelu przy wykorzystaniu takich struktur danych, które pozwolą na bardziej efektywny dostęp, np. ułatwią przeszukanie duŝego zbioru obiektów. Przykładami są słownik czy tablica asocjacyjna, gdzie przechowywane są pary (kwalifikator, zbiór obiektów identyfikowanych przez wartość kwalifikatora). Asocjacja n-arna Asocjacja n-arna to asocjacja, której wystąpienia łączą n obiektów będących instancjami co najwyŝej n klas: asocjacja 3-arna łączy 3 obiekty (inna nazwa dla tej asocjacji to asocjacja ternarna), asocjacja 4-arna łączy 4 obiekty itd. Asocjacja n-arna rysowana jest w postaci rombu, od którego odchodzą linie ciągłe do klas, które łączy, oraz opcjonalnie linia przerywana do klasy asocjacji. Nazwa jest umieszczana w pobliŝu rombu. Podobnie jak w przypadku asocjacji binarnych, nazwa moŝe być opuszczona (chociaŝ nie jest to zalecane), jeŝeli w sposób oczywisty wynika z kontekstu, tzn. z nazw łączonych klas i z własności klasy asocjacji. JeŜeli dana klasa uczestniczy w asocjacji więcej niŝ jeden raz, czyli moŝe pojawić się na więcej niŝ jednej pozycji w asocjacji, np. klasa K na Rys. 43, to wówczas dla tej klasy naleŝy zdefiniować role asocjacji. rola2 K rola K3 K2 Rys. 43. Przykładowa asocjacja 4-arna Asocjacja binarna ze swoją uproszczoną notacją i pewnymi dodatkowymi własnościami, np. moŝliwością posiadania kwalifikatora, jest specjalnym rodzajem asocjacji n-arnej (dla n = 2). Asocjacja binarna i 2-arna są równowaŝne, nie istnieje między nimi róŝnica semantyczna, nieco inny jest tylko sposób reprezentowania. Liczności asocjacji n-arnej Specyfikowanie liczności dla asocjacji n-arnych nie jest tak oczywiste, jak w przypadku asocjacji binarnych, a ponadto róŝni autorzy wygłaszają na ten temat róŝne opinie. W UML przyjęto zasadę, Ŝe liczność roli dla danej klasy (liczność danego końca asocjacji) oznacza liczbę obiektów tej klasy będących w związku z obiektami pozostałych (n ) klas. Na przykład, dla asocjacji ternarnej łączącej klasy A, B i C liczność roli dla klasy C specyfikuje liczbę obiektów klasy C powiązanych z kaŝdą moŝliwą parą obiektów klas A i B. ZauwaŜmy, Ŝe reguła ta jest uogólnieniem reguły przyjętej

dla specyfikowania liczności asocjacji binarnych. Niestety, w przeciwieństwie do asocjacji binarnej, asocjacja n-arna jest trudna do implementacji. Przykład zilustrowany jest na Rys. 44, gdzie asocjacja ternarna łączy dwie klasy: Zespół oraz Osoba, przy czym obiekty klasy Osoba występują w dwóch rolach: sędziego i zawodnika. Dodatkowo, dla asocjacji została zdefiniowana klasa asocjacji Zapis, która przechowuje jej atrybuty. Zespół mecz zawodnik sędzia Osoba Zapis data stadion gole gospodarzy gole gości Rys. 44. Przykład asocjacji 3-arnej z wyspecyfikowanymi licznościami oraz klasą asocjacji Obejście asocjacji n-arnej Zastosowanie asocjacji n-arnej ma sens przede wszystkim wówczas, gdy do identyfikacji n-arnego powiązania potrzebne są wszystkie obiekty, tzn. gdy liczność kaŝdej z ról jest wiele. W pozostałych przypadkach asocjację n-arną warto jest zastąpić przez n asocjacji binarnych i klasę pośredniczącą; podejście to jest łatwiejsze w implementacji i pozwala wykorzystać takie własności asocjacji binarnych, jak np. kwalifikator. Niestety, tego rodzaju wprowadzenie niezaleŝnych związków binarnych prowadzi do utraty informacji o n-arnym związku istniejącym w obrębie grupy obiektów. Rys. 45 ilustruje, na przykładzie asocjacji ternarnej, sposób zamiany asocjacji n-arnej na pojedynczą klasę i n asocjacji binarnych. K2 A K2 K a a2 KA K3 K a a2 m A K3 m Rys. 45. Schemat zamiany asocjacji ternarnej na asocjacje binarne Interfejs, zaleŝność, realizacja Interfejs jest to nazwany zbiór operacji specyfikujący pewien wycinek zachowania danego elementu modelu. Interfejs zawiera jedynie specyfikacje metod, bez implementacji. Do oznaczenia interfejsu w UML stosuje się stereotyp «interface», który na diagramie klas poprzedza (jak kaŝdy interfejs) nazwę klasy. W UML wszystkie metody zdefiniowane w interfejsie są publiczne. Pojęcie interfejsu jest uŝywane takŝe przez diagramy implementacyjne (omówione w innym wykładzie). Diagram na Rys. 46 przedstawia przykładowy interfejs o nazwie IPracownik oraz przykładową klasę Pracownik, która zawiera implementacje metod wyspecyfikowanych w tym interfejsie. Związek pomiędzy interfejsem a klasą implementującą metody tego interfejsu zaznaczany jest za pomocą symbolu realizacji przerywanej linii zakończonej pustym trójkątem. Z kolei związek pomiędzy interfejsem a klasą, która korzysta z tego interfejsu (zwaną klientem), zaznaczany jest za pomocą symbolu zaleŝności, czyli przerywanej linii zakończonej grotem związek pomiędzy interfejsem IPracownik a klasą Firma.

Osoba {abstract} imię nazwisko data urodzenia policz wiek «interface» IPracownik + zmień pensję Firma Pracownik pensja stanowisko zmień pensję Rys. 46. Przykład interfejsu, zaleŝności i realizacji Dla diagramu z Rys. 46 moŝna zastosować równowaŝną, bardziej zwięzłą notację przedstawioną na Rys. 47. Klasa abstrakcyjna i interfejs zostały tutaj potraktowane w podobny sposób, jako definicje interfejsów do klasy Pracownik. Jedyna róŝnica polega na tym, Ŝe klasa abstrakcyjna, w przeciwieństwie do interfejsu, moŝe zawierać atrybuty i implementacje metod. IPracownik Firma Pracownik Osoba Rys. 47. Inny sposób przedstawiania interfejsów 5.3 Podsumowanie W wykładzie szczegółowo omówiono asocjację wraz z takimi bliskimi jej pojęciami, jak role, kompozycja, klasa asocjacji, asocjacja kwalifikowana. ChociaŜ sama idea asocjacji jest bardzo prosta, to jednak w przypadku obiektowości została ona znacznie rozbudowana. Dzięki temu obiektowość oferuje analitykowi znacznie silniejsze narzędzie opisu tego rodzaju związków niŝ to ma miejsce w przypadku innych podejść. 5.4 Przykładowe pytania i problemy do rozwiązania. Jaka jest róŝnica pomiędzy powiązaniem a asocjacją? 2. Co opisuje liczność asocjacji? 3. Jakie znasz rodzaje asocjacji? Podaj przykłady. 4. Kiedy konieczne jest specyfikowanie ról? Odpowiedź zilustruj przykładem. 5. Dlaczego agregacja nazywana jest silną formą asocjacji? 6. Podaj przykład asocjacji n-arnej. 7. Diagram klas dla wypoŝyczalni płyt DVD (rozdział 2, podrozdział 2.2) uzupełnij o związki asocjacyjne.