UML – Diagram klas

Diagram klas jest jednym ze sposobów reprezentacji zależności pomiędzy klasami, które mają być użyte do stworzenia kodu źródłowego. Jest to główny budulec OO modelu aplikacji, przydatny również do tworzenia technicznej dokumentacji projektu.

Diagram klas zawiera:

  • typ klasy
  • nazwa klasy
  • atrybuty klasy
  • metody klasy
  • rodzaje zależności pomiędzy klasami

W diagramie klasę reprezentuje się przy pomocy prostokąta podzielonego na trzy części, ktrórymi są:

  1. Górna część to nazwa klasy
  2. Środkowa część to lista atrybutów
  3. Dolna część to lista metod

Przykładowe okno klasy wygląda tak:


Zależnie od “typu klasy”, nad nazwą piszemy jej określenie. Rozróżniane są tutaj typy jak:

  • interface
  • auxiliary
  • enum
  • entity

Typ enum został pominięty w standardzie, gdzie zdefiniowanych jest kilka więcej typów, które dla uproszczenia pominąłem.

Typ klasy oznaczany jest w podwójnych znakach nierówności:

<<interface>>

Poniżej nazwa tej klasy.

 

W środkowej części okna wypisujemy listę atrybutów, na których ta klasa ma operować. Informacje tutaj podaje się w następującej kolejności:

<zakres atrybutu> nazwaAtrybutu : typ

co w przykładzie wygląda tak:

# age: int

Atrybuty w klasach mają swój zakres widoczności, więc trzeba to zaznaczyć też w oknie klasy. Proste reguły do zapamiętania:

+ atrybut typu public
atrybut typu private
# atrybut typu protected
~ atrybut o zakresie paczki
/ atrybut typu derived (odziedziczony)
_ atrybut typu static

Jeśli atrybutem jednej klasy jest inna klasa, sprawa wygląda tak samo jak z int’ami:

+ fur : Fur
+ breed : Breed
– owner : Person
– path : Path

 

Ostatnim elementem okna klasy jest lista metod. Zakres dostępności metod oznacza się tak samo jak w liście atrybutów. W ten sam sposób oznacza się ich typ:

+ eat(f : Food) : void
+ walk() : double
+ sleep() : void

 

Stwórzmy teraz prosty diagram, na którym pokażemy, że klasa Cat dziedziczy od klasy Mammal, a ta rozszerza infterface Animal. W interface wszystkie metody są publiczne, a metody są uzupełniane o ciało w Mammal, a następnie wywoływane w Cat.

 

Oczywiście w tym momencie instancja klasy Cat posiada atrybut age oraz implementacje metod zdefiniowanych w klasie Mammal.

Pomyślmy moment nad tym projektem. Czynności takie jak jedzenie, przemieszczanie się, spanie są takie same dla każdego osobnika typu zwierzę. Oczywiście inne będą dla konia (kłus, galop) oraz inne dla kota (przesuń się poprzez przewrócenie się na drugi bok) i inne dla żółwia (płyń). Dlatego też ta metoda zostanie w interface. W klasie Mammal mamy definicje metod określonych w interface. Tutaj dla takiego żółwia, który ssakiem nie jest, powinna powstać inna klasa, w której będzie inaczej zdefiniowana metoda snu i ruchu, gdyż koty ani konie jakoś specjalnie nie pływają pod wodą, a żółw nie za bardzo biega bo trawie czy lesie.

Informacje, takie jak właściciel, zdefiniowałem w klasie kota, by nie tworzyć klasy DomesticAnimals, w której można zdefiniować dane jak właściciel. Pominąłem ten etap projektu, by go uprościć. Delfin czy lew rzadko mają właścicieli, a ssakami są.

Nie każde zwierzę ma też sierść i nie każde chodzi swoimi ścieżkami. Nie za bardzo znam się na zwierzętach, więc i informacje o rasie zostawiłem w kocie.

W diagramie pominąłem również konstruktory, setttery i gettery.

 

 

Zależności na poziomie klasy:

UML posiada tutaj dwa typy zależności,

  1. generalizacja, w językach programowania nazywany inaczej dziedziczeniem. Ten typ zależności oznaczany jest zamkniętym, niezamalowanym trójkątem połączonym z klasą dziedziczącą nieprzerywaną linią
  2. realizacja, która jest inaczej nazywana implementacją, oznaczamy przez zamknięty niezamalowany trójkąt, połączony z klasą podrzędną przerywaną linią

Oba typy zależności zostały pokazane w diagramie powyżej.

 

Zależności na poziomie instancji:

  • link – najbardziej ogólny typ relacji, który informuje, że jedna klasa jest powiązana z drugą i oznaczona linią bez grotów, bez opisów
  • asocjacja – bardziej szczegółowy link (nieprzerywana linia bez grotów), przy tym typie należy poinformować o tym, jaką akcję wykonuje jeden obiekt na drugim, jak nazwane są instancje jednej klasy istniejące w instancji drugiej klasy oraz ich mnogość. Asocjacja występuje, gdy instancje mają “swoje życie” i żadna z klas asocjacyjnych nie ma właściciela pomiędzy sobą.
  • agregacja – metoda oznaczenia, że instancja jednej klasy posiada instancję innej klasy. Agregacja jest znacznie bardziej szczegółowa niż asocjacja i oznacza, że jeśli jedna instancja klasy jest dzieckiem innej instancji klasy, to dziecko nie może należeć do innego rodzica. Dajmy przykład powyższego kota. Kot ma w swojej książeczce wpisanego właściciela i może to być tylko jedna osoba. Jeśli jednak właściciel zniknie, kot nadal będzie żył, chociaż już bez właściciela. Typ relacji nazywany inaczej “a ma b” (to moje własne określenie). W diagramie klas oznacza się to niezamalowanym rombem (jak kto woli diamentem) i linią ciągłą od klasy właściciela.
  • kompozycja – jest bardziej szczegółową formą agregacji. Od agregacji różni się tym, że instancja klasy A (dziecko) nie może istnieć bez instancji klasy B (rodzica). Przykładem może być tasiemiec żyjący w wnętrznościach kota. Jeśli kot umrze, to tasiemiec razem z nim. Typ relacji oznaczany jest zamalowanym rombem i linią ciągłą od instancji klasy właściciela.

 

Ostatnim ważnym elementem jest opis liczebności instancji jednego typu w drugim.

Jest to bardzo proste, nad linkiem pokazującym zależność przy klasie A pisze się liczbę, która oznacza ilość instancji klasy A w klasie B. W naszym przykładzie kota i tasiemca, tasiemiec ma jednego kota, za to jeden kot może mieć wiele tasiemców.

Stosuje się poniższe oznaczenia:

  • * – jeśli liczba instancji jest nieokreślona
  • 1 – tylko jedna instancja
  • 0..1 – od zera do jednej instancji
  • 0..n – od zera do n instancji
  • 1 – tylko jedna
  • n – zawsze wystąpi n instancji

 

Jeśli narysuję teraz diagram, na którym przedstawię:

  • Person agreguje Cat, właściciel może mieć od zera do nieskończenie wielu kotów, ale kot jednego właściciela
  • Cat kompozytuje(!?) Tapeworm, tasiemiec ma jednego nosiciela, ale kot może mieć wiele tasiemców
  • Cat ma asocjację z klasą Mouse, którą instancją klasy się żywi
  • Mouse jest rodzajem klasy Mammal

to będzie wyglądało to tak:

[Total: 0    Average: 0/5]