Celem tego rozdziału jest zaprezentowanie podstawowej techniki projektowania, najczęściej stosowanej w modelach projektowych.

Diagram klas – definicja i zastosowanie

Diagram klas obrazuje pewien zbiór klas, interfejsów i kooperacji oraz związki między nimi. Jest on grafem złożonym z wierzchołków (klas, interfejsów, kooperacji) i łuków (reprezentowanych przez relacje). Diagram klas stanowi opis statyki systemu, który uwypukla związki między klasami, pomijając pozostałe charakterystyki. Najsilniej prezentuje on więc strukturę systemu, stanowiąc podstawę dla jego konstrukcji. W modelowaniu złożonych systemów nie mamy obowiązku przedstawiania ich struktury na jednym diagramie. Powinniśmy pamiętać o tym, że złożenie wszystkich diagramów, a właściwie ich elementów
i relacji, stanowi kompletny model. Możemy zatem przyjąć, że podzbiory zbioru klas użyte na diagramach klas są wybierane celowo i stanowią wynik decyzji zarówno analitycznych, jak i projektowych. Tak na przykład, diagramy klas stanowiące wynik decyzji analitycznych tworzą tzw. widoki klas biorących udział w realizacji danego przypadku użycia (ang. view of participating class – VOPC)
i powiązania między nimi.

Zasadniczo jednak diagramy klas służą do zobrazowania statycznych aspektów perspektywy projektowej, w której bierze się pod uwagę wymagania funkcjonalne systemu – usługi, jakie system powinien udostępniać swoim użytkownikom.

Diagram klas – notacja i semantyka

Klasa

najczesciej_stosowana_notacja_UML_2011_html_7d52edab

Rysunek 34. Klasa – notacja

Klasa stanowi opis wybranego podzbioru obiektów, w którym każdy z obiektów posiada takie same atrybuty, operacje, metody, związki i znaczenie.
Z określenia tego wynika założenie dotyczące inwariantności (niezmienności) cech i zachowań obiektów, którym przypisano wspólny klasyfikator w postaci nazwy klasy.

Niezmienniki klasy stanowią więc zarówno jej strukturę określoną przez atrybuty zachowania wyrażone przez operacje, zdarzenia, wyjątki, etc., jak i ograniczenia, którym podlegają obiekty tworzone na podstawie wzorca zawartego w definicji klasy (np. dotyczące reguł widoczności atrybutów
i operacji).

Ponieważ klasa stanowi wzorzec dla tworzonych obiektów, nie jest celowe, aby każdy z nich przechowywał kopię tego samego opisu operacji; wszystkie utworzone obiekty powinny zatem odwoływać się do wspólnej definicji operacji zawartych w klasie. Możemy więc założyć, że klasa nie stanowi jedynie prostego opisu zbioru obiektów, ale zawiera jeden egzemplarz definicji operacji, które działają na wielu egzemplarzach atrybutów, unikatowych dla każdego obiektu.

Atrybut to nazwana właściwość klasyfikatora, określająca zestaw wartości, które mogą przyjmować jego instancje.

Atrybuty klas charakteryzują pojedyncze obiekty lub grupy obiektów, tworząc dla każdego z nich niezależną ich instancję. Jeżeli atrybut klasy może istnieć niezależnie od obiektu, to często lepszym rozwiązaniem jest zbudowanie
z niego nowej klasy, np. atrybut Adres dla klasy Klient.

Operacja to funkcja dostarczana przez obiekt, która manifestuje się przez odpowiednie jego zachowanie. Operacja ma sygnaturę, która określa jej dopuszczalne parametry i sposób wywołania. Operacje klasy działają
na pojedynczych obiektach lub ich zbiorach. W odróżnieniu od atrybutów, zwykle tworzona jest jedna instancja operacji klasy (przechowywana w klasie), wspólna dla wszystkich obiektów tej klasy. W niektórych sytuacjach operację lepiej jest przedstawić jako klasę (np. operacja wypożyczSamochód jako działanie może być operacją klasy lub może być klasą wypożyczSamochód z własnymi atrybutami: dataWypożyczenia, dataZwrotu, etc.).

Klasa może używać interfejsów do definiowania zestawu operacji oferowanych jej środowisku.

najczesciej_stosowana_notacja_UML_2011_html_3906f465 najczesciej_stosowana_notacja_UML_2011_html_m1036800d

Rysunek 35. Elementy składowe klasy

Metoda to implementacja operacji. Określa algorytm lub procedurę, która dostarcza wynik operacji.

Odpowiedzialność stanowi kontrakt lub zobowiązanie do spełnienia odpowiednich warunków przez typ lub klasę. (Odpowiedzialność jest pojęciem metodycznym niedefiniowanym w języku UML).

najczesciej_stosowana_notacja_UML_2011_html_m348bab4c

Interfejs

Rysunek 36. Interfejs – notacja

Interfejs (ang. interface) to zestaw operacji, które wyznaczają usługi oferowane przez komponent (lub klasę). Interfejsy służą do prezentowania komunikacji pomiędzy komponentami.

image

Rysunek 37. Dodatkowa notacja interfejsów

Język UML w wersji 2.0 rozszerza notację interfejsów o dwa interfejsy zwane łącznikami (ang. connector), z których korzysta komponent Serwis
(rys. 37). Pierwszy z nich, Protokół z wykonania naprawy, należy do grupy interfejsów dostarczających (ang. provided interface) i wskazuje na fakt, że może dostarczyć innym komponentom interfejs Protokołu z wykonania naprawy. Drugi z zaprezentowanych interfejsów, Lista usterek, należy do grupy interfejsów wymaganych (ang. required interfaces), to znaczy takich, które są wymagane
do funkcjonowania komponentu.

Szczegółowo interfejsy zostały opisane w rozdziale dotyczącym komponentów.

Związek asocjacji (powiązania)

najczesciej_stosowana_notacja_UML_2011_html_m2e7d3cd9

Rysunek 38. Związek asocjacji – notacja

Związek asocjacji to semantyczna relacja (związek) pomiędzy dwoma bądź większą liczbą klas, która ustanawia powiązania (wiązania) pomiędzy instancjami klasyfikatorów. W szczególności asocjacja może zachodzić pomiędzy dwoma lub większą liczbą klas. Często do powiązania dodawane są nazwy ról i liczebności.

image

Rysunek 39. Przykład użycia asocjacji wraz z rolą

Na rysunku 39 zamieszczono przykład zastosowania asocjacji wraz z rolą. Rola to swego rodzaju „oblicze”, które klasa przy jednym końcu powiązania prezentuje klasie przy drugim końcu.

Związek agregacji

najczesciej_stosowana_notacja_UML_2011_html_m9cd5d51

Rysunek 40. Związek agregacji – notacja

Związek agregacji to rodzaj asocjacji pomiędzy klasyfikatorami, która określa relację „całość-część” pomiędzy agregatem (całością) a jego częściami; egzemplarz należący do klasyfikatora reprezentującego „całość” zawiera – jako swoje komponenty – elementy należące do klasyfikatora reprezentującego „część”. W przypadku klas, wartościami atrybutów obiektu zagregowanego mogą być obiekty należące do klas reprezentujących „części”.

najczesciej_stosowana_notacja_UML_2011_html_2c55333d

Rysunek 41. Przykładowe zastosowanie agregacji

Na rysunku 41 pokazano przykładową agregację, która oznacza,
że ubezpieczenie jest częścią wypożyczenia samochodu.

Silna agregacja (kompozycja)

najczesciej_stosowana_notacja_UML_2011_html_m6b11a4e6

Rysunek 42. Silna agregacja – notacja

Związek silnej agregacji (kompozycja, agregacja całkowita) to rodzaj agregacji z przynależnością elementów składowych do elementu macierzystego oraz z powiązanym okresem życia elementów składowych z ich elementami macierzystymi. Elementy składowe mogą być kreowane po utworzeniu elementu macierzystego. Raz utworzone istnieją i są kasowane wraz ze swoim elementem macierzystym. Mogą też być kasowane przed momentem kasowania elementu macierzystego. Kompozycja może być rekursywna.

najczesciej_stosowana_notacja_UML_2011_html_m6d250acb

Rysunek 43. Przykładowe użycie kompozycji

Na rysunku 43 przedstawiono przykładowy związek kompozycji, który wskazuje na fakt, że Dział obsługi klienta, Warsztat i Garaż są częściami budynku Wypożyczalni samochodów. Działy te są całkowicie uzależnione od okresu życia budynku wypożyczalni samochodów, gdyż jego zburzenie automatycznie pociąga za sobą zniszczenie Działu obsługi klienta, Warsztatu i Garażu.

Związek zależności

image

Rysunek 44. Związek zależności notacja

Zależność (ang. dependency) to związek pomiędzy dwoma elementami modelowania, polegający na tym że zmiana w jednym – niezależnym elemencie, pociąga zmianę w drugim – zależnym elemencie.

Uściślenie takie można przedstawić w różny sposób, najlepiej przez powiązanie związku z odpowiednim stereotypem. Najważniejsze stereotypy zaprezentowano w tabeli 1.

Na rysunku 45 zaprezentowano typowe zastosowanie zależności typu <<use>>. Wynika z niego, że do prawidłowego działania klasy Serwis potrzebne jest użycie klasy Usługa.

najczesciej_stosowana_notacja_UML_2011_html_m67aa2a08

Rysunek 45. Zależność ze słowem kluczowym <<use>> – przykład

Wybrane typy związku zależności

<<call>> – Źródło wywołuje cel

<<create>> – Źródło tworzy obiekt docelowy

<<deriver>> – Źródło  można wyznaczyć na podstawie celu

<<import>> – Zawartość publiczna celu zostaje dołączona do obszaru nazw źródła

<<instantie>> – Źródło  tworzy egzemplarz klasy

<<permit>> – Cel pozwala źródłu na dostęp do swoich cech prywatnych

<<realize>> – Źródło jest implementacją specyfikacji lub interfejsem definiowanym przez cel

<<refine>> – Źródło jest na doskonalszym poziomie abstrakcji niż cel

<<substitute>> – Źródło jest substytutem celu

<<trace>> – Cel jest historycznie przodkiem źródła

<<use>> – Źródło wymaga celu do swojego funkcjonowania

Związek generalizacji

najczesciej_stosowana_notacja_UML_2011_html_2043b1ce

Rysunek 46. Związek generalizacji – notacja

Związek generalizacji (uogólnienie) to związek pomiędzy elementem ogólnym (nadklasa lub przodek), a jego specyficznym rodzajem zwanym podklasą lub potomkiem. Element specyficzny jest całkowicie zgodny z elementem ogólnym i zawiera dodatkową informację. Egzemplarz elementu specyficznego może być użyty wszędzie tam, gdzie dopuszcza się egzemplarz elementu ogólnego. Związek generalizacji określa powiązanie pomiędzy dwoma elementami, w szczególności klasami – klasą ogólną i klasą specyficzną. Obiekty klasy specyficznej dziedziczą własności strukturalne i behawioralne – atrybuty
i operacje – obiektów klasy ogólnej.

najczesciej_stosowana_notacja_UML_2011_html_m72b83a01

Rysunek 47. Przykładowe użycie związku generalizacji

Jak widać na rysunku 47, uogólnienie polega na tym, że może wystąpić wszędzie tam, gdzie spodziewany jest przodek; nie na odwrót. Potomek zawsze może zastąpić przodka. W naszym przykładzie oznacza to, że każdy sprzedawca może być pracownikiem, ale nie każdy pracownik może być sprzedawcą. Należy pamiętać, że potomek dziedziczy wszystkie właściwości przodka, w szczególności jego atrybuty i operacje. Potomek może mieć swoje cechy, których nie odziedziczył po przodku. Klasa może nie mieć żadnego przodka, ale może również mieć jednego lub więcej. Klasę bez przodków nazywamy korzeniem, a klasę bez potomków liściem. Jeśli klasa ma jednego przodka, to mówimy o dziedziczeniu pojedynczym, jeżeli ma ich więcej, mówimy o wielodziedziczeniu.

Związek generalizacji jest wykorzystywany głównie na etapie tworzenia modelu. Pozwala on na usystematyzowanie tworzenia modelu metodą zstępującą, z drugiej zaś strony na wykorzystywanie wcześniej zbudowanych modeli.

Liczebność

Liczebność (krotność) (ang. multiplicity) jest elementem stosowanym
do specyfikowania zależności. Specyfikacja ta polega na określeniu liczby wystąpień klasy w danym związku. Liczebność może być ustalona na np. (1), zero lub jeden (0..1), dowolnie wiele (0..*), co najmniej 1 (1..*).

Na rysunku 48 przedstawiono typowe zastosowanie liczebności, która wskazuje, że na jedno rozliczenie z wykonanego serwisu samochodu składa
się minimum jedna pozycja/ wykonana usługa (np. sprzątanie wnętrza, mycie karoserii, itp.).

najczesciej_stosowana_notacja_UML_2011_html_77ac17f9

Rysunek 48. Przykładowe użycie liczebności

Diagram klas – przykładowe zastosowanie

Poniżej zaprezentowano przykładowy diagram klas, w którym zastosowano wszystkie opisane w niniejszym rozdziale techniki.

image

Rysunek 49. Przykładowy diagram klas

Pozostałe diagramy UML:

Close