Co to jest diagram klas?
Diagram klas to strukturalny diagram UML który wizualizuje statyczną architekturę systemu oprogramowania zorientowanego obiektowo. Jako niezastąpiony typ diagramu UML, mapuje indywidualne klasy, interfejsy i modele danych w Twojej aplikacji, jasno dokumentując ich wewnętrzne pola (atrybuty), funkcje operacyjne (metody) oraz strukturalne relacje łączące je ze sobą. Ten szkic jest kluczowy dla inżynierów oprogramowania, którzy muszą przekształcać wysokie poziomy projektów domenowe w czyste, utrzymywalne struktury obiektowe.
Za pomocą Mermaid.js, możesz wykonać szkic swoich modeli danych i usług systemowych za pomocą intuicyjnych definicji opartych na tekście. Silnik układu automatycznie oblicza rozmiary pól, strukturu standardowych komórek danych UML i wyrównuje strzałki relacyjne na Twoim płótnie bez konieczności ręcznego formatowania.
Podstawowy przewodnik składniowy: elementy i konstrukcje
Aby stworzyć dokładny, zgodny z normami diagram klas UML w Mermaid, musisz opanować deklaracje członków, modyfikatory dostępu oraz strzałki relacji strukturalnych.
1. Deklarowanie klas i komórek klas
Możesz zdefiniować klasę za pomocą dwóch poprawnych formatów. Dla prostej klasy użyj słowa kluczowego classa następnie nazwę klasy. Jeśli chcesz od razu uwzględnić pola i metody, użyj kończących się klamr klamr, aby stworzyć jasny blok ciała:
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. Dodawanie widoczności / modyfikatorów dostępu
Aby zarejestrować standardowe zasady hermetyzacji UML, umieść określony symbol bezpośrednio przed nazwą atrybutu lub metody, aby określić poziom jej widoczności:
+**Publiczne:** Dostępne z dowolnej innej klasy.-**Prywatne:** Dostępne wyłącznie wewnątrz deklarującej klasy.#**Chronione:** Dostępne w klasie i jej podklasach.~**Pakiet / Wewnętrzny:** Dostępny w obrębie tej samej granicy pakietu.
classDiagram
class BankAccount {
-double balance
#String accountHolder
+getBalance() double
}
3. Opanowanie strzałek relacji i łączy dziedziczenia
Aby pokazać, jak klasy wzajemnie się oddziałują w modelu diagramu UML, połącz ich identyfikatory za pomocą specjalnych ciągów relacji. W Mermaid kierunek linii ma znaczenie: główka strzałki wskazuje klasę nadrzędna lub kontenerową.
- Dziedziczenie / Ogólnienie (przerywana lub pełna strzałka):
Child --|> Parent(Reprezentuje relację „jest rodzajem”). - Realizacja / Zaimplementowanie:
Class ..|> Interface(Reprezentuje klasę spełniającą kontrakt interfejsu). - Kompozycja (pełny diament):
Child --* Parent(Reprezentuje ściśle przynależne właścicieństwo; jeśli rodzic umiera, to dziecko również umiera). - Agregacja (przezroczysty diament):
Child --o Parent(Reprezentuje luźną relację zbiorową; dziecko może istnieć niezależnie). - Zależność:
ClassA ..> ClassB(Reprezentuje przejściowy odniesienie czasu działania).
classDiagram
Car --|> Vehicle : "Dziedziczy z"
Engine --* Car : "Jest częścią"
Najlepsze praktyki dla czystych układów architektury klas
- Wizualne grupowanie członków klasy: Zawsze grupuj zmienne klasy na początku bloku ciała i funkcje na końcu. Ten układ odpowiada standardowym strukturom klas w IDE i sprawia, że Twoje diagramy są od razu czytelne.
- Określ typy zwracane: Podczas deklarowania metod, dodaj typ zwracany na końcu linii metody (np.
+fetchData() DataSet). Dzięki temu twój zespół inżynieryjny otrzymuje dokładne informacje o kontekście implementacji. - Utrzymuj jasność wielokrotności: Aby wskazać liczby tablic lub rozmiary kolekcji, dodaj ciągi tekstowe wielokrotności bezpośrednio do otoczki linii relacji (np.
Klient "1" --o "wiele" Zamówienie).
Przykłady rzeczywistych diagramów klas Mermaid.js
Przykład 1: Podsystem domeny bramy płatności (enkapsulacja i interfejsy)
Ten funkcjonalny szablon modeluje usługę domeny płatności online. Pokazuje, jak używać modyfikatorów dostępu, grupować członków klasy oraz czysto implementować relacje interfejsów.
classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(amount) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> PaymentProcessor : "Implementuje"
PayPalGateway ..|> PaymentProcessor : "Implementuje"
Analiza składni: Znacznik <<interface>> jasno oznacza `PaymentProcessor` jako kontrakt architektoniczny najwyższego poziomu. Dwie konkretne klasy implementacji bramki używają pól prywatnych (-apiKey) do przechowywania poufnych danych uwierzytelniających, podczas gdy udostępniają publiczne procedury płatności (+processPayment) połączone strzałką realizacji (..|>).
Przykład 2: Silnik przetwarzania zamówień w przedsiębiorstwie (kompozycja i wielokrotność)
Ten zaawansowany szablon systemu modeluje skomplikowaną strukturę zarządzania zamówieniami e-commerce, pokazując, jak dokumentować własność strukturalną i liczbę obiektów między wieloma połączonymi klasami.
classDiagram
class Customer {
+int customerId
+String name
+placeOrder() Order
}
class Order {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class OrderItem {
+int itemId
+int quantity
+double pricePerUnit
}
class Address {
+String street
+String city
+String postalCode
}
Klient "1" --o "wiele" Zamówienie : "posiada"
OrderItem "1..*" --* "1" Zamówienie : "komponuje"
Address "1" --> Zamówienie : "dostarczane do"
Rozbicie składni: Ten przykład ilustruje różnicę między agregacją a kompozycją. Strzałka z pełnym rombem (--*) pokazuje, że `OrderItem` jest silnie powiązany z `Order` (jeśli zamówienie zostanie usunięte, jego poszczególne pozycje również zostaną usunięte). Z kolei strzałka z pustym rombem (--o) wskazuje, że `Customer` posiada wiele zamówień, ale obie encje mogą istnieć niezależnie. Ciągi wielokrotności (takie jak "1..*") definiują wymagania relacyjne systemu.