Przewodnik po składni diagramu klas PlantUML

Co to jest diagram klas?

Diagram UML Diagram klas jest podstawowym strukturalnym szkicem modelowania obiektowego. Wizualizuje system oprogramowania poprzez przedstawienie jego klas, ich wewnętrznych atrybutów (pól danych), metod (funkcji) oraz strukturalnych relacji między nimi. Choć bazy kodu mogą stać się rozległe i trudne do przeanalizowania, czytelny diagram klas zapewnia inżynierom natychmiastowy wizualny punkt odniesienia, jak obiekty kodu wzajemnie się oddziałują, dziedziczą zachowania i zarządzają granicami danych.

Korzystając z VPasCode, możesz tworzyć szczegółowe układy klas całkowicie w postaci zwykłego tekstu, pozostawiając inżynierię układu, rozmiar pola i odstępy między liniami całkowicie naszym zintegrowanym silnikom w chmurze.

Podstawowy przewodnik składniowy: elementy i konstrukcje

Aby tworzyć wysokiej jakości diagramy klas, musisz zrozumieć trzy podstawowe znaczniki strukturalne: definiowanie ciała klasy, przypisywanie modyfikatorów widoczności do członków oraz mapowanie relacji między obiektami.

1. Deklarowanie klas i członków

Deklarujesz standardowy szablon obiektu za pomocą słowa kluczowego classSłowo kluczowe. Wewnątrz końcowych nawiasów klamrowych wymieniasz swoje pola i metody w osobnych liniach:

class CustomerAccount {
    String accountId
    String emailAddress
    Boolean isActive()
}

2. Modyfikatory widoczności (kontrola dostępu)

PlantUML mapuje standardowe zasady hermetyzacji obiektowej (publiczne, prywatne, chronione oraz pakietowe/prywatne w pakiecie) przy użyciu prostych prefiksów tekstowych umieszczonych bezpośrednio przed nazwą pola lub metody:

• + Jasne dostęp publiczny (dostępny dla dowolnej innej klasy)
• - Ściśle prywatny dostęp (dostępny tylko wewnątrz tej konkretnej klasy)
• # Dostęp chroniony (dostępny wewnątrz tej klasy i jej podklas)
• ~ Dostęp pakietowy/wewnętrzny (dostępny tylko w obrębie lokalnego modułu kodu)

3. Definiowanie relacji między obiektami

Łączenie klas wymaga określonych oznaczeń strzałek, aby wskazać zależność strukturalną lub kompozycję kodu aplikacji:

• Dziedziczenie / Ogólnienie (Jest-A): Używa otwartego wierzchołka strzałki wskazującego na klasę nadrzędna: KlasaPochodna --|> KlasaNadrzędna
• Realizacja / Implementacja: Używa kreski kropkowanej z otwartym trójkątem, aby pokazać wykonanie interfejsu: KlasaKonkretna ..|> IInterfejs
• Kompozycja (ściśle posiadana): Używa pełnego diamentu, aby pokazać, że obiekt potomny nie może istnieć bez kontenera nadrzędnego: Nadrzędny *-- Potomny
• Agregacja (udostępniona kolekcja): Używa otwartego diamentu, aby pokazać tymczasową relację kolekcyjną: Dział o-- Pracownik

Najlepsze praktyki dla praktycznych map klas

• Oddzielaj układy za pomocą klas abstrakcyjnych: Użyj klasy abstrakcyjnejlubinterfejsu słów kluczowych, aby wizualnie odróżnić granice strukturalne od konkretnych modeli baz danych.
• Wczesne oznaczanie wielokrotności: Zawsze dodawaj liczbowe wielokrotności (np. "1"lub"0..*") na obu końcach strzałek relacji, aby jasno wyrazić ograniczenia danych dla programistów.
• Kontroluj odstępy pionowe: Diagramy klas mogą być bardzo wysokie. Jeśli układ się zbyt bardzo rozciąga w pionie, zastąp podwójny myślnik (--) pojedynczym myślnikiem (-) wewnętrznie w strzałkach relacji, aby wymusić poziome ułożenie obok siebie.

Przykłady diagramów klas PlantUML z rzeczywistego świata

Przykład 1: Model domeny e-commerce (widoczność i hermetyzacja)

Ten szkic demonstruje standardowe modyfikatory dostępu, podstawowe obiekty danych oraz podstawowe mapowania wielokrotności danych między kluczowymi jednostkami zakupów online.

@startuml
class User {
    - String userId
    - String hashedSecret
    + Boolean verifyLogin(String input)
}

class Order {
    + String orderId
    + Date timestamp
    - Double calculateTotal()
}

User "1" --> "0..*" Order : "umieszcza i posiada"
@enduml

Analiza składni: W - prefiks utrzymuje wrażliwe pola, takie jak dane logowania, ściśle prywatne wewnątrz bloku klasy User klasy, podczas gdy funkcje publicznego dostępu używają znaku + marker. Ciąg połączenia jasno wskazuje, że jeden użytkownik może bezproblemowo wyszukać zero lub wiele zamówień.

Przykład 2: Zaawansowany bramka płatności (dziedziczenie i interfejsy)

Ten kompleksowy schemat inżynierii oprogramowania pokazuje, jak organizować interfejsy, pętle dziedziczenia klas oraz złożone kompozycje w jednolitym ramach.

@startuml
interface IPaymentProcessor {
    + Boolean authorizeAmount(Double cash)
    + void captureFunds()
}

abstract class BaseGateway {
    # String merchantApiKey
    # String endpointUrl
    + void logTransaction(String payload)
}

class StripeGateway {
    - String stripeToken
    + Boolean authorizeAmount(Double cash)
    + void captureFunds()
}

class PayPalGateway {
    - String paypalEmail
    + Boolean authorizeAmount(Double cash)
    + void captureFunds()
}

class ShoppingCart {
    - List items
    + void checkout(IPaymentProcessor engine)
}

' Deklaracje relacji strukturalnych
BaseGateway ..|> IPaymentProcessor
StripeGateway --|> BaseGateway
PayPalGateway --|> BaseGateway
ShoppingCart *-- IPaymentProcessor
@enduml

Analiza składni: W ..|> notacja ustala, że klasa abstrakcyjna implementuje nasz główny interfejs główny. Linie trójkątne (--|>) prowadzą dziecięce bramki czysto do ich podstawowej klasy nadrzędnej, podczas gdy pełny romb (*--) deklaruje, że Koszyk zakupów w sposób istotny posiada swój procesor silnika płatności podczas cyklu życia sesji.