W inżynierii oprogramowania, Język modelowania zintegrowanego (UML) diagram klas to statyczny diagram strukturalny który opisuje strukturę systemu poprzez pokazanie jego klas, ich atrybutów, operacji (lub metod) oraz relacji między obiektami.

Zastosowania diagramów klas
- Wyświetlanie struktury statycznej klasifikatorów w systemie
- Stanowi podstawową notację dla innych diagramów strukturalnych UML
- Wysoko przydatne dla programistów i innych członków zespołu
- Analitycy biznesowi mogą używać diagramów klas do modelowania systemów z perspektywy biznesowej
Diagramy klas UML składają się z:
- Zbiór klas
- Zbiór relacji między klasami
Co to jest klasa?
Opis grupy obiektów o podobnych rolach, w tym:
- Cechy strukturalne (atrybuty): definiują, co obiekty klasy „wiedzą”
- Reprezentuje stan obiektu
- Opisuje strukturę lub cechy statyczne klasy
- Cechy behawioralne (operacje): definiują, co obiekty klasy „mogą robić”
- Określają, jak obiekty się oddziałują
- Opisują zachowanie lub cechy dynamiczne klasy
Notacja klasy
Notacja klasy składa się z trzech części:
- Nazwa klasy
- Nazwa klasy pojawia się w pierwszym kompartymencie.
- Atrybuty klasy
- Atrybuty są wyświetlane w drugim kompartymencie.
- Typ jest wyświetlany po dwukropku.
- Atrybuty odpowiadają zmiennym członkowskim (zmiennym danych) w kodzie.
- Operacje klasy (metody)
- Operacje są wyświetlane w trzeciej komórce. Odpowiadają usługom oferowanym przez klasę.
- Typ zwracany pojawia się po dwukropku na końcu sygnatury metody.
- Typy parametrów pojawiają się po dwukropku po nazwie parametru.
- Operacje odpowiadają metodom klasy w kodzie.

Wyświetlenie graficzne klasyMojaKlasa jak pokazano powyżej:
- MojaKlasa ma 3 atrybuty i 3 operacje
- Parametr p3 metody op2 ma typ int
- metoda op2 zwraca wartość typu float
- metoda op3 zwraca wskaźnik (oznaczony przez *) do klasy6
Relacje klas
Klasa może być zaangażowana w jedną lub więcej relacji z innymi klasami. Relacje mogą mieć następujące typy: (Zobacz obrazek po prawej stronie dla przedstawień graficznych).
| Typ relacji | Diagram |
|---|---|
Dziedziczenie (lub uogólnienie):
|
![]() |
Prosta asocjacja:
|
![]() |
Agregacja:
|
![]() |
Kompozycja:
|
![]() |
Zależność:
|
![]() |
Nazwy relacji
- Nazwy relacji są pisane w środku linii związku.
- Dobre nazwy relacji mają sens, gdy są czytane na głos:
-
- „Każdy arkusz zawiera pewne komórki”
<li>Wyrażenie daje wartość wartość”
-
- Często mają małą strzałkę wskazującą kierunekczytania, np. wyrażenie daje wartość, ale wartość nie daje wyrażenia.

Relacja – Role
- Rola określa cel kierunku w związku.
- Rola jest zapisywana na końcu linii związku i opisuje rolę, jaką klasa pełni w tym związku.
- Na przykład, Cell jest związany z Expression. Naturą związku jest to, że Expression jest formułąkomórki.
Widoczność członków klasy
W projektowaniu obiektowym widoczność atrybutów i operacji jest reprezentowana. UML definiuje cztery typy widoczności: publiczna, chroniona, prywatna, oraz pakietu.
Symbole +, -, # i ~ przed nazwami atrybutów i operacji wskazują widoczność:
- + wskazuje atrybut lub operację publiczną
- – wskazuje atrybut lub operację prywatną
- # wskazuje atrybut lub operację chronioną
- ~ wskazuje atrybut lub operację pakietu
Przykład widoczności klasy

W powyższym przykładzie:
- attribute1 i op1 klasy MyClassName są publiczne
- attribute3 i op3 są chronione
- attribute2 i op2 są prywatne
Uprawnienia dostępu dla różnych członków klasy są pokazane poniżej:
| Poziom dostępu | Publiczny (+) | Prywatny (-) | Chroniony (#) | Pakiet (~) |
|---|---|---|---|---|
| Członkowie tej samej klasy | Tak | Tak | Tak | Tak |
| Członkowie klas pochodnych | Tak | Nie | Tak | Tak |
| Członkowie dowolnej innej klasy | Tak | Nie | Nie | Tylko ten sam pakiet |
Wielokrotność
Wielokrotność wskazuje, ile obiektów klasy uczestniczy w relacji. Może być wyrażona jako:
- Dokładnie 1 – 1
- Zero lub jeden – 0..1
- Wiele – 0..* lub *
- Jeden lub więcej – 1..*
- Dokładna liczba – np. 3..4 lub 6
- Złożona relacja – np. 0..1, 3..4, 6* oznacza dowolną liczbę z wyjątkiem 2 lub 5
Przykład wielokrotności
- Wymóg: Student może zapisywać się na wiele kursów, a wiele studentów może zapisywać się na jeden kurs.
- W poniższym przykładzie diagram klas (po lewej) opisuje model statyczny powyższego wymogu, podczas gdy diagram obiektów (po prawej) przedstawia zrzut stanu rejestracji kursów (instancję diagramu klas) dla kursów inżynierii oprogramowania i zarządzania bazami danych.

Przykład agregacji – Komputer i elementy
- Agregacja to szczególny przypadek związku reprezentujący hierarchię „zawiera”.
- Agregacja jest klasą nadrzędną, a component jest klasą potomną.

Przykład dziedziczenia – Klasyfikacja komórek
- Dziedziczenie to inny szczególny przypadek związku reprezentujący hierarchię „rodzaj”.
- Dziedziczenie upraszcza model analizy poprzez wprowadzenie taksonomii.
- Klasy potomne dziedziczą atrybuty i operacje od klasy nadrzędnej.

Diagram klas – Przykład narzędzia do rysowania diagramów
Diagramy klas mogą zawierać notatki przypisane do klas lub relacji. Notatki są wyświetlane w odcieniach szarości.

Na podstawie powyższego przykładu możemy zinterpretować diagram następująco:
- Shape jest klasą abstrakcyjną. Jest wyświetlana kursywą.
- Shape jest klasą nadrzędną. Circle, Rectangle i Polygon dziedziczą po Shape. Innymi słowy, Circle jest Shape. Jest to relacja uogólnienia/dziedziczenia.
- Istnieje relacja między DialogBox i DataController.
- Shape jest częścią Window. Jest to relacja agregacji. Shape może istnieć bez Window.
- Point jest częścią Circle. Jest to relacja kompozycji. Point nie może istnieć bez Circle.
- Window zależy od Event. Ale Event nie zależy od Window.
- Atrybuty Circle to radius i center. Jest to klasa konkretnej.
- Metody Circle to area(), circum(), setCenter() i setRadius().
- Parametr radius w Circle jest typu float.
- Metoda area() w Circle zwraca wartość typu double.
- Atrybuty i metody Rectangle są ukryte. Niektóre inne klasy na diagramie również ukrywają swoje atrybuty i metody.
Obsługa systemów złożonych – wiele czy jedna diagram klas?
Podczas modelowania dużych systemów lub dużych dziedzin biznesowych należy uwzględnić wiele encji. Czy powinniśmy używać wielu czy jednej diagramu klas? Odpowiedź brzmi:
- Lepszym rozwiązaniem jest użycie wielu diagramów klas zamiast modelowania każdej jednostki i jej relacji na jednym diagramie.
- Podział systemu na wiele diagramów klas ułatwia jego zrozumienie, zwłaszcza gdy każdy diagram jest wizualnym przedstawieniem konkretnego elementu systemu.
Perspektywa diagramów klas w cyklu życia rozwoju oprogramowania
Diagramy klas mogą być wykorzystywane w różnych etapach Cyklu życia rozwoju oprogramowania (SDLC), a zazwyczaj modelowane są trzy różne poziomy szczegółowości (perspektywy), które są stopniowo rozwijane:
Perspektywa koncepcyjna: Diagram jest interpretowany jako opis rzeczywistych obiektów. Zatem, jeśli zaczynasz od perspektywy koncepcyjnej, rysujesz diagram przedstawiający koncepcje w badanym dziedzinie. Te koncepcje naturalnie są powiązane z klasami, które je implementują. Ta perspektywa jest uważana za niezależną od języka.
Perspektywa specyfikacji: Diagram jest interpretowany jako opis abstrakcji oprogramowania lub komponentów z określonymi specyfikacjami i interfejsami, bez zobowiązywania się do konkretnego wykonania. Zatem, jeśli podejdziesz od perspektywy specyfikacji, jesteś badając interfejsy oprogramowania zamiast jego implementacji.
Perspektywa implementacji: Diagram jest interpretowany jako opis konkretnej technologii i językaimplementacji oprogramowania. Zatem, jeśli podejdziesz od perspektywy implementacji, jesteś badając implementację oprogramowania.
Spróbuj narysować diagram klas UML teraz
Pobierz bezpłatnie




