Kompleksowy przewodnik po diagramie klas UML

Przykład klasy

Pies ma stany – kolor, imię, rasę oraz zachowania – machanie, szczekanie, jedzenie. Obiekt jest instancją klasy.

Notacja klas UML

Klasa reprezentuje koncepcję, która enkapsuluje stan (atrybuty) i zachowanie (operacje). Każdy atrybut ma typ. Każda operacja has a sygnaturę. Nazwa klasy jest jedyną obowiązkową informacją.

Nazwa klasy:

• Nazwa klasy pojawia się w pierwszej sekcji.

Atrybuty klasy:

• Atrybuty są pokazane w drugiej sekcji.
• Typ atrybutu jest pokazany po dwukropku.
• Atrybuty odpowiadają zmiennym członkowskim (danym członkowskim) w kodzie.

Operacje klasy (metody):

• Operacje są pokazane w trzeciej sekcji. Są to usługi, które klasa świadczy.
• Typ zwracany metody jest pokazany po dwukropku na końcu sygnatury metody.
• Typ zwracany parametrów metody jest pokazany po dwukropku po nazwie parametru. Operacje odpowiadają metodom klasy w kodzie.

Relacje klas

Klasa może być zaangażowana w jedną lub więcej relacji z innymi klasami. Relacja może być jednym z następujących typów: (Zobacz rysunek po prawej stronie dla graficznej reprezentacji relacji).

Typ relacji	Reprezentacja graficzna
Dziedziczenie (lub generalizacja): Reprezentuje relację „jest-a”. Nazwa klasy abstrakcyjnej jest pokazana kursywą. SubClass1 i SubClass2 są specjalizacjami klasy nadrzędnej. Solidna linia z pustą strzałką wskazującą od klasy podrzędnej do klasy nadrzędnej
Prosta asocjacja: Link strukturalny między dwiema klasami równorzędnymi. Istnieje asocjacja między Class1 a Class2 Solidna linia łącząca dwie klasy
Agregacja: Specjalny typ asocjacji. Reprezentuje relację „część z”. Class2 jest częścią Class1. Wiele instancji (oznaczonych przez *) Class2 może być powiązanych z Class1. Obiekty Class1 i Class2 mają oddzielne cykle życia. Solidna linia z niewypełnionym rombem na końcu asocjacji połączona z klasą złożoną
Kompozycja: Specjalny typ agregacji, w którym części są niszczone, gdy całość jest niszczona. Obiekty Class2 żyją i umierają z Class1. Class2 nie może istnieć samodzielnie. Solidna linia z wypełnionym rombem na końcu asocjacji połączona z klasą złożoną
Zależność: Istnieje między dwiema klasami, jeśli zmiany w definicji jednej mogą powodować zmiany w drugiej (ale nie odwrotnie). Class1 zależy od Class2 Linia przerywana z otwartą strzałką

Nazwy relacji

• Nazwy relacji są zapisane w środku linii asocjacji.
• Dobre nazwy relacji mają sens, gdy się je głośno czyta:
  • „Każdy arkusz kalkulacyjny zawiera pewną liczbę komórek”,
  • „wyrażenie ocenia się na wartość”
• Często mają małą strzałkę, aby pokazać kierunek w którym kierunku czytać relację, np. wyrażenia oceniają się na wartości, ale wartości nie oceniają się na wyrażenia.

Relacja – Role

• Rola to kierunkowy cel stowarzyszenia.
• Role są zapisane na końcach linii stowarzyszenia i opisują cel, jaki ta klasa odgrywa w relacji.
  • Np. Komórka jest związana z wyrażeniem. Natura relacji polega na tym, że wyrażenie jest formułą komórki.

Nawigowalność

Strzałki wskazują, czy w przypadku jednej instancji uczestniczącej w relacji możliwe jest określenie instancji innej klasy, które są z nią związane.

Diagram powyżej sugeruje, że,

• Mając arkusz kalkulacyjny, możemy zlokalizować wszystkie komórki, które zawiera, ale że
  • nie możemy określić z komórki, w jakim arkuszu jest zawarta.
• Mając komórkę, możemy uzyskać powiązane wyrażenie i wartość, ale
  • mając wartość (lub wyrażenie), nie możemy znaleźć komórki, której te są atrybutami.

Widoczność atrybutów i operacji klasy

W projektowaniu obiektowym istnieje notacja widoczności dla atrybutów i operacji. UML identyfikuje cztery typy widoczności: publiczny, chroniony, prywatny, oraz pakiet.

Symbole +, -, # i ~ przed nazwą atrybutu i operacji w klasie oznaczają widoczność atrybutu i operacji.

• + oznacza publiczne atrybuty lub operacje
• – oznacza prywatne atrybuty lub operacje
• # oznacza chronione atrybuty lub operacje
• ~ oznacza atrybuty lub operacje pakietu

Przykład widoczności klasy

W powyższym przykładzie:

• atrybut1 i op1 klasy MyClassName są publiczne
• atrybut3 i op3 są chronione.
• atrybut2 i op2 są prywatne.

Dostęp dla każdego z tych typów widoczności jest pokazany poniżej dla członków różnych klas.

Wielokrotność

Ile obiektów każdej klasy bierze udział w relacjach, a wielokrotność można wyrazić jako:

• Dokładnie jeden – 1
• Zero lub jeden – 0..1
• Wiele – 0..* lub *
• Jeden lub więcej – 1..*
• Dokładna liczba – np. 3..4 lub 6
• Lub złożona relacja – np. 0..1, 3..4, 6.* oznaczałaby dowolną liczbę obiektów, z wyjątkiem 2 lub 5

Przykład wielokrotności

• Wymaganie: Student może brać udział w wielu kursach, a wielu studentów może być zapisanych na jeden kurs.
• W poniższym przykładzie, diagram klas (po lewej), opisuje treść wymagania powyżej dla modelu statycznego, podczas gdy diagram obiektowy (po prawej) pokazuje migawkę (instancję diagramu klas) rejestracji kursów dla kursów Inżynieria Oprogramowania i Zarządzanie Bazami Danych odpowiednio)

Przykład agregacji – Komputer i części

• Agregacja to szczególny przypadek stowarzyszenia oznaczający hierarchię „składa się z”
• Agregat to klasa nadrzędna, a komponenty to klasy podrzędne

Przykład dziedziczenia – Taksonomia komórek

• Dziedziczenie to kolejny szczególny przypadek stowarzyszenia oznaczający hierarchię „rodzaj”
• Dziedziczenie upraszcza model analizy poprzez wprowadzenie taksonomii
• Klasy podrzędne dziedziczą atrybuty i operacje klasy nadrzędnej.

Diagram klas – Przykład narzędzia diagramowego

Diagram klas może również mieć notatki dołączone do klas lub relacji. Notatki są pokazane na szaro.

W powyższym przykładzie:

Możemy zinterpretować znaczenie powyższego diagramu klas, czytając punkty w następujący sposób.

1. Kształt to klasa abstrakcyjna. Jest pokazana kursywą.
2. Kształt to klasa nadrzędna. Okrąg, prostokąt i wielokąt pochodzą z Kształtu. Innymi słowy, Okrąg jest Kształtem. To jest relacja uogólnienia / dziedziczenia.
3. Istnieje stowarzyszenie między DialogBox a DataController.
4. Kształt jest częścią Okna. To jest relacja agregacji. Kształt może istnieć bez Okna.
5. Punkt jest częścią Okręgu. To jest relacja kompozycji. Punkt nie może istnieć bez Okręgu.
6. Okno jest zależne od Wydarzenia. Jednak Wydarzenie nie jest zależne od Okna.
7. Atrybuty Okręgu to promień i środek. To jest klasa encji.
8. Nazwy metod Okręgu to area(), circum(), setCenter() i setRadius().
9. Parametr promień w Okręgu jest parametrem wejściowym typu float.
10. Metoda area() klasy Okrąg zwraca wartość typu double.
11. Atrybuty i nazwy metod Prostokąta są ukryte. Niektóre inne klasy w diagramie również mają swoje atrybuty i nazwy metod ukryte.

Radzenie sobie z złożonym systemem – wiele czy jeden diagram klas?

Niezbędnie, jeśli modelujesz duży system lub dużą dziedzinę biznesową, będzie wiele podmiotów, które musisz wziąć pod uwagę. Czy powinniśmy używać wielu czy jednego diagramu klas do modelowania problemu? Odpowiedź brzmi:

• Zamiast modelować każdy podmiot i jego relacje na jednym diagramie klas, lepiej jest używać wielu diagramów klas.
• Podział systemu na wiele diagramów klas ułatwia zrozumienie systemu, szczególnie jeśli każdy diagram jest graficzną reprezentacją konkretnej części systemu.

Perspektywy diagramu klas w cyklu życia rozwoju oprogramowania

Możemy używać diagramów klas w różnych fazach rozwoju cyklu życia rozwoju oprogramowania i zazwyczaj modelując diagramy klas w trzech różnych perspektywach (poziomach szczegółowości) w miarę postępu:

Perspektywa koncepcyjna: Diagramy są interpretowane jako opisujące rzeczywistość. Zatem, jeśli przyjmiesz perspektywę koncepcyjną, rysujesz diagram, który reprezentuje koncepcje w badanym obszarze. Te koncepcje będą naturalnie odnosić się do klas, które je implementują. Perspektywa koncepcyjna jest uznawana za niezależną od języka.

Perspektywa specyfikacji: Diagramy są interpretowane jako opisujące abstrakcje lub komponenty oprogramowania z specyfikacjami i interfejsami, ale bez zobowiązania do konkretnej implementacji. Zatem, jeśli przyjmiesz perspektywę specyfikacji, my patrzymy na interfejsy oprogramowania, a nie na implementację.

Perspektywa implementacji: Diagramy są interpretowane jako opisujące implementacje oprogramowania w konkretnej technologii i języku. Zatem, jeśli przyjmiesz perspektywę implementacji, my patrzymy na implementację oprogramowania.