Rysunek 1: Przykłady graficznej prezentacji klas.

Transkrypt

1 4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez ilustrację struktury klas i zależności między nimi. Diagram klas przedstawia klasy (typy) obiektów w programie, w odróżnieniu od diagramu obiektów, który pokazuje jedynie egzemplarze (instancje) obiektów i ich zależności istniejące w konkretnym momencie. Diagram klas pokazuje określony fragment struktury systemu. Diagramów klas używa się do modelowania statycznych aspektów perspektywy projektowej. Wiąże się z tym silnie modelowanie słownictwa systemu, kooperacji lub schematów. Diagramy klas pozwalają na sformalizowanie specyfikacji danych i metod. Mogą także pełnić rolę graficznego środka pokazującego szczegóły implementacji klas. Klasa w modelu UML programu obiektowego jest reprezentowana przez prostokąt z umieszczoną wewnątrz nazwą klasy (rys. 1). Oddzielona część prostokąta pod nazwą klasy może zawierać atrybuty klasy, czyli metody (funkcje), właściwości (properties) lub pola (zmienne). Każdy atrybut pokazywany jest przynajmniej jako nazwa, opcjonalnie także z typem, wartością i innymi cechami. Metody klasy mogą znajdować się w osobnej części prostokąta. Każda metoda jest pokazywana przynajmniej jako nazwa, a dodatkowo także ze swoimi parametrami i zwracanym typem. Rysunek 1: Przykłady graficznej prezentacji klas. O ile dana klasa nie definiuje atrybutów (odp. metod) wówczas drugie (odp. trzecie) pole jest puste. Trzecie pole może być pominięte. Atrybuty (zmienne i właściwości) oraz metody mogą mieć też oznaczoną widoczność (zakres znaczenia ich nazw) jak następuje: + dla public - publiczny, dostęp globalny # dla protected - chroniony, dostęp dla pochodnych klasy (wynikających z generalizacji) - dla private - prywatny, dostępny tylko w obrębie klasy (przy atrybucie statycznym) lub obiektu (przy atrybucie zwykłym) - dla package - pakiet, dostępny w obrębie danego pakietu, projektu. Diagram klas pokazuje klasy w postaci pewnych oznaczeń graficzno-językowych powiązanych w sieć zależnościami należącymi do trzech kategorii: 1

2 4.2 Asocjacje. 4 DIAGRAMY KLAS. ˆ Dziedziczenie (inheritance), czyli ustalenie związku generalizacji/specjalizacji pomiędzy klasami. ˆ Asocjacja (association), czyli dowolny związek pomiędzy obiektami dziedziny przedmiotowej, który ma znaczenie dla modelowania. ˆ Agregacja (aggregation) / kompozycja (composition), czyli szczególny przypadek asocjacji, odwzorowujący stosunek całość-część pomiędzy obiektami z modelowanej dziedziny przedmiotowej. 4.2 Asocjacje. Oznaczenia klas w UML mogą być połączone liniami oznaczającymi asocjacje, czyli powiązania pomiędzy obiektami tych klas. Rysunek 2 pokazuje specyfikację asocjacji Pracuje dla pomiędzy obiektami klasy Osoba i obiektami klasy Firma. Czarny trójkącik określa kierunek wyznaczony przez nazwę powiązania (w danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby). Asocjacje mają nazwy, takie jak Pracuje dla, które wyznaczają znaczenie tej asocjacji w modelu pojęciowym. Jeżeli to znaczenie jest oczywiste, wówczas nazwę asocjacji można pominąć. Zatem asocjacje mogą być: ˆ nienazwane: Rysunek 2: Przykład asoscjacji. Rysunek 3: Asocjacja nienazwana. ˆ nazwane z opcjonalnym umieszczeniem znacznika wskazującego kierunek interpretacji asocjacji: Rysunek 4: Asocjacja nazwana. ˆ scharakteryzowane poprzez role klas pełnione w asocjacji: Rysunek 5: Asocjacja z rolami. ˆ nazwane i równocześnie scharakteryzowane przez role: 2

3 4.2 Asocjacje. 4 DIAGRAMY KLAS. Rysunek 6: Asocjacja nazwana z rolami. Asocjacje mogą też być binarne (dwie klasy): i n-arne (więcej klas niż dwie): Rysunek 7: Asocjacja binarna. Rysunek 8: Asocjacja n-arna. Asocjacje mogą być wyposażone w oznaczenia liczności. Jak zwykle, liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy; zwykle określa się to poprzez parę liczb (znaków) oznaczającą minimalną i maksymalną liczbę takich obiektów. Zapis liczności w UML jest naturalny i nie wprowadza specjalnych symboli graficznych. Oznaczenie 0..* oznacza liczność od zera do dowolnie wielkiej liczby; może być skrócone do pojedynczej gwiazdki. Analogicznie, 1..* oznacza liczność od jeden do dowolnie wielkiej liczby, zaś 0..1 oznacza liczność zero lub jeden. Generalnie, oznaczenia liczności mogą być zapisem dowolnego podzbioru liczb całkowitych nieujemnych, gdzie podwójna kropka oznacza od...do..., zaś gwiazdka oznacza dowolną liczbę. 3

4 4.3 Dziedziczenie. 4 DIAGRAMY KLAS. Rysunek 9: Liczności. 4.3 Dziedziczenie. Strzałka (z białym trójkątnym grotem) prowadzi od pod-klasy do jej bezpośredniej nadklasy. Zakłada się, że obiekt pod-klasy automatycznie dziedziczy wszystkie atrybuty, metody, asocjacje i agregacje z wszystkich jej nadklas. Użytkownik może explicite zadeklarować aspekt, według którego specjalizuje się dany obiekt (np. napęd lub teren), oraz określić fakt niepustego przecięcia zakresów znaczeniowych - zbiorów obiektów (overlapping). Rysunek 10: Przykład dziedziczenia. Klasy Ciężarówka i Żaglówka (rys. 11) zostały zdefiniowane z użyciem wielokrotnego dziedziczenia. Na rysunku zilustrowano również możliwość określania faktu, że podklasy są rozłączne (disjoint) i nie przykrywają całego zakresu znaczeniowego ich nadklasy (incomplete). 4

5 4.4 Agregacje i kompozycje. 4 DIAGRAMY KLAS. Rysunek 11: Dodatkowe elementy specyfikacji dziedziczenia. 4.4 Agregacje i kompozycje. Agregacja jest szczególnym przypadkiem asocjacji wyrażającym zależność część-całość. W praktyce wyróżniamy dwa rodzaje agregacji: ˆ agregację całkowitą kompozycja ˆ agregację częściową W obydwu rodzajach agregacji występują dwa podstawowe pojęcia: ˆ agregat obiekt stanowiący całość ˆ segment obiekt stanowiący część W przypadku agregacji całkowitej obiekty-segmenty będące częściami agregatów nie mogą samodzielnie i niezależnie funkcjonować. Usunięcie agregatu powoduje automatyczną likwidację segmentów będących jego częściami. Natomiast agregacja częściowa wskazuje na asocjację, w której usunięcie obiektu będącego agregatem nie powoduje likwidacji obiektów będących jego częściami, czyli obiektów-segmentów. Obiekty współdzielone mogą zatem funkcjonować niezależnie od agregatu. Rysunek 12 przedstawia obie te relacje. 5

6 4.5 Przykładowe diagramy klas. 4 DIAGRAMY KLAS. Rysunek 12: Agregacja: a) całkowita (kompozycja), b) częściowa 4.5 Przykładowe diagramy klas. Dwa kolejne rysunki (rys. 13 oraz rys. 14) przedstawiają przykładowe diagramy klas. Rysunek 13: Diagram klas z uwzględnieniem agregacji. 6

7 4.6 Proces tworzenia diagramu klas. 4 DIAGRAMY KLAS. Rysunek 14: Przykładowy diagram klas. 4.6 Proces tworzenia diagramu klas. W procesie tworzenia diagramu klas wyróżnić można następujące etapy: 1. Zidentyfikowanie i nazwanie klas. 2. Opcjonalnie określenie zobowiązań klas. 3. Połączenie poszczególnych klas z wykorzystaniem związków asocjacji. 4. Zidentyfikowanie oraz nazwanie atrybutów i operacji. 5. Wyspecyfikowanie asocjacji z użyciem jej cech (nazwy, ról, liczebności, agregacji i in.) 6. Opracowanie innych rodzajów związków (uogólnień, zależności, realizacji). 7. Pełne i precyzyjne wyspecyfikowanie atrybutów i operacji zgodnie ze składnią UML. 4.7 Praca domowa. Przygotować na następne zajęcia diagram klas swojego systemu w postaci pliku / wydruku. Przygotować się merytorycznie z tematu Diagramy interakcji. 7