W dziedzinie inżynierii oprogramowania i projektowania obiektowego (OOD), Diagram klas UMLsłuży jako fundament modelowania systemu. Jest to diagram struktury statycznej, który opisuje architekturę systemu poprzez przedstawienie jego klas, ich atrybutów, operacji (metod) oraz złożonych relacji między obiektami. Niezależnie od tego, czy tworzysz model domeny, czy szczegółowo opisujesz specyfikację oprogramowania, zrozumienie diagramów klas jest niezbędne do przekształcania koncepcyjnych projektóww kod działający.
Zrozumienie budowy klasy
W centrum diagramu znajduje się Klasa, która pełni rolę szablonu dla obiektów. Podczas gdy obiektysą użytecznymi instancjami zawierającymi dane i zachowanie, klasa definiuje zasady dla tych obiektów. W notacji UML, klasa jest przedstawiana jako prostokąt podzielony na trzy określone sekcje:
- Nazwa klasy:Znajduje się w pierwszej (górnym) sekcji. Jest to wymagane. Klasy abstrakcyjne zazwyczaj są pisane kursywą.
- Atrybuty:Znajduje się w drugiej sekcji. Odpowiadają one stanowi lub cechom strukturalnym klasy (zmienne członkowskie).
- Operacje (metody):Znajduje się w trzeciej sekcji. Definiują one cechy zachowania lub usługi, które klasa oferuje.
Widoczność i kontrola dostępu
Aby zdefiniować hermetyzację, UML używa określonych symboli przed nazwami atrybutów i operacji, aby oznaczyć widoczność. To decyduje, które inne klasy mogą uzyskać dostęp do tych członków.
| Symbol | Typ widoczności | Opis |
|---|---|---|
| + | Publiczna | Dostępna dla każdej innej klasy. |
| – | Prywatna | Dostępny tylko w obrębie samej klasy. |
| # | Chronione | Dostępne dla klasy oraz jej podklas (klas pochodnych). |
| ~ | Pakiet | Dostępne dla każdej klasy w tym samym pakiecie. |
Rozszyfrowywanie relacji między klasami
Siła diagramu klas UML polega na tym, jak przedstawia interakcje między klasami. Podobnie jak implementacja kodu opiera się na logice, UML opiera się na określonych połączeniach, aby przekazać intencję. Poniżej znajdują się główne typy relacji:
1. Dziedziczenie (generalizacja)
Dziedziczenie reprezentuje relację „JEST-TO” relację. Jest to relacja taksonomiczna, w której konkretny klasyfikator (dziecko) dziedziczy cechy od ogólnego klasyfikatora (rodzica). Na przykład Koło jest Figurą.
- Oznaczenie: Pełna linia z pustym zakończeniem strzałki wskazującą od klasy potomnej do klasy nadrzędnej.
- Zastosowanie:Używane do uproszczenia modeli analizy poprzez wprowadzenie wspólnych cech w klasie nadrzędnej.
2. Powiązanie
Jest to strukturalne połączenie między klasami równorzędnymi, często opisywane czasownikiem (np. „Nauczyciel uczy ucznia”). Oznacza to, że dwie klasy są ze sobą powiązane, ale tworzy ono luźne sprzężenie.
- Oznaczenie: Pełna linia łącząca dwie klasy.
- Wielokrotność:Wskazuje, ile obiektów uczestniczy (np.
1,0..1,1..*).
3. Agregacja
Agregacja to specjalna forma związku reprezentująca „CZĘŚĆ-CAŁOŚCI” relację. Jednak oznacza ona słabe prawo własności. Część może istnieć niezależnie od całości. Na przykład Samochód ma Opony, ale jeśli samochód zostanie zniszczony, opony mogą nadal istnieć.
- Oznaczenie: Linia ciągła z pustym (pustym) diamentem na końcu połączonym z klasą agregującą (rodzicielską).
4. Kompozycja
Kompozycja to bardziej rygorystyczna forma agregacji. Reprezentuje silne prawo własności, w którym część nie może istniećbez całości. Jeśli obiekt rodzicielski zostanie zniszczony, obiekty potomne również zostaną zniszczone. Przykładem jest Dom i jego Pokoje.
- Oznaczenie: Linia ciągła z wypełnionym (pełnym) diamentem na końcu połączonym z klasą kompozytową (rodzicielską).
5. Zależność
Oznacza to relację „używa”. Istnieje wtedy, gdy jedna klasa interakcjonuje z drugą konkretnie jako parametr w metodzie lub zmienna lokalna, a nie jako pole. Zmiany w definicji klasy dostawcy mogą wpływać na klasę klienta.
- Oznaczenie: Przerywana linia z otwartym strzałką wskazującą na zależność.
Zasady tworzenia skutecznych diagramów klas
Tworzenie czytelnego i dokładnego diagramu wymaga przestrzegania określonych zasad.
- Używaj standardowych zasad nazewnictwa: Nazwy klas powinny być rzeczownikami (np. Klient, Zamówienie), zazwyczaj z wielkiej litery. Nazwy powiązań powinny być czasownikami (np. umieszcza, zawiera).
- Określ perspektywę: Zanim narysujesz, zdecyduj, czy modelujesz koncepcyjnąwidok (koncepcje domeny), specyfikację widok (interfejsy) lub implementację widok (specyficzny dla kodu).
- Zarządzaj złożonością: Nie próbuj modelować całego systemu na jednym diagramie. Podziel system na wiele diagramów, skupiając się na konkretnych modułach lub obszarach biznesowych.
- Jasno oznacz wielokrotność: Zawsze jasno określ, czy relacja jest jedna-do-jednej, jedna-do-wielu, czy wiele-do-wielu, aby upewnić się, że logika bazy danych lub kodu odzwierciedla wymagania biznesowe.
Przykład z rzeczywistego świata: system przetwarzania zamówień
Rozważ typowy scenariusz e-commerce z udziałem Klienta, Zamówienia i Produktu. Oto jak relacje przekładają się na strukturę struktury diagramu klas:
- Klient i Zamówienie (powiązanie): Klient zamawiaZamówienie. Mnożność to
1Klient do0..*Zamówień. - Zamówienie i pozycja zamówienia (kompozycja):Zamówienie składa się z pozycji zamówienia. Jeśli zamówienie zostanie usunięte, pozycje zamówienia tracą sens i są niszczone. Jest to wypełniony romb skierowany w stronę Zamówienia.
- Pozycja zamówienia i Produkt (powiązanie/agregacja):Pozycja zamówienia odnosi się do produktu. Jednak produkt istnieje niezależnie od pozycji zamówienia (utrzymuje się w magazynie). Jest to standardowe powiązanie lub słaba agregacja.
- Płatność (realizacja):Interfejs o nazwie IPłatnośćmoże być zrealizowany przez klasy PłatnośćKartąKredytową oraz PłatnośćPayPal.
Wskazówki i triki optymalizacyjne
Zastosuj te wskazówki, aby podnieść Twoje diagramy z prostych rysunków do profesjonalnych artefaktów technicznych:
- Test „czytania na głos“:Przeczytaj swoje relacje na głos. „Samochód składa się z koł. Jeśli brzmi to niezręcznie, sprawdź, czy używasz poprawnego kierunku strzałki lub typu relacji.
- Kierunkowość parametrów:W sekcji operacji możesz określić kierunek parametru za pomocą
wej,wyjście, lubwejście-wyjścieprzed nazwą parametru, aby wyjaśnić przepływ danych. - Kursywa dla klas abstrakcyjnych: Jeśli klasa nie może być bezpośrednio instancjonowana (jest abstrakcyjna), upewnij się, że jej nazwa jest pochylona. Jest to subtelny, ale kluczowy sygnał dla programistów.
- Unikaj przecięć linii: Choć nowoczesne narzędzia takie jak Visual Paradigm dobrze obsługują routowanie, ale stwórz ręcznie układ klas, aby zmniejszyć liczbę przecięć linii, co znacznie poprawia czytelność.
Kontrolna lista sprawdzania diagramu klas
Zanim zakończysz tworzenie diagramu klas UML, przejdź przez tę działającą listę kontrolną:
- [ ] Pełność: Czy wszystkie niezbędne klasy dla danego modułu są obecne?
- [ ] Widoczność: Czy atrybuty i operacje są oznaczone poprawnymi symbolami widoczności (+, -, #)?
- [ ] Dokładność relacji: Czy poprawnie rozróżniłeś agregację (pusty romb) i kompozycję (wypełniony romb)?
- [ ] Mnożność: Czy liczba elementów została określona na obu końcach powiązań (np. 1..*)?
- [ ] Kierowalność: Czy strzałki jasno wskazują, która klasa może uzyskać dostęp do drugiej?
- [ ] Nazewnictwo: Czy nazwy klas są rzeczownikami i unikalne? Czy czasowniki relacji są jasne?
- [ ] Ogólnienie: Czy hierarchia dziedziczenia ma sens (relacja „jest rodzajem”)?