Diagramy klas UML do modelowania danych z użyciem PlantUML

Diagram klas UML opisuje strukturę systemu: elementy, które modeluje, ich właściwości oraz sposób, w jaki są ze sobą powiązane. dla modelowania danych może przechwytywać koncepcje domenowe i ograniczenia zanim przystąpisz do tworzenia tabel lub kodu aplikacji.

PlantUML sprawia, że diagram jest powtarzalny: piszesz tekst, generujesz go, przeglądasz zmiany w systemie kontroli wersji i aktualizujesz go wraz z ewolucją modelu. Uzupełnia on – nie zastępuje – schematów baz danych, migracji oraz szczegółowych reguł biznesowych.

1. Wybierz poziom modelowania

Przydatny diagram modelowania danych zazwyczaj skupia się na jednym poziomie naraz:

• Koncepcyjny: koncepcje biznesowe i relacje, z minimalnym szczegółem technicznym. Przykład: Klient składa Zamówienie.

• Logiczny: atrybuty, identyfikatory, mnożności i reguły, bez powiązania modelu z konkretną bazą danych.

• Fizyczny: szczegóły implementacyjne, takie jak typy kolumn SQL, indeksy i ograniczenia specyficzne dla bazy danych.

Poniższy przykład to logiczny model domenowy. Typy takie jak UUID, Money, oraz DateTime są przykładowe; zdecyduj o ich konkretnych reprezentacjach przy wyborze technologii.

2. Podstawy PlantUML

Klasa ma nazwę i może wymieniać atrybuty oraz operacje:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Markery widoczności są opcjonalnymi wskazówkami modelowania:

• + public

• - private

• # protected

• ~ widoczność pakietu

Dla diagramu domenowego lub danych najważniejsze są atrybuty. Dołączaj operacje tylko wtedy, gdy wyjaśniają istotne zachowanie; unikaj zamieniania diagramu w pełny listing kodu.

3. Relacje i mnogość

Najbardziej przydatne notacje relacji do modelowania danych to:

Etykiety mnogości znajdują się blisko końców asocjacji:

• 1 — dokładnie jeden

• 0..1 — opcjonalnie, najwyżej jeden

• * lub 0..* — zero lub więcej

• 1..* — jeden lub więcej

• 2..5 — ograniczony zakres

Na przykład:

Klient "1" -- "0..*" Zamówienie : umieszcza

Uważnie przeczytaj etykiety na obu końcach: jeden klient może złożyć zero lub więcej zamówień; każde zamówienie jest powiązane dokładnie z jednym klientem. Etykiety opisują relację, a niekoniecznie implementację klucza obcego w konkretnej bazie danych.

4. Przykład praktyczny: sklep internetowy

Ten model obejmuje klientów, zamówienia, pozycje zamówień, produkty i zapisy płatności. Ilustruje identyfikatory, typy podobne do wartości, wyliczenia, kompozycję i mnożności.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

Dlaczego modelowaćOrderLine jawnie? Relacja między zamówieniem a produktem posiada własne dane — ilość i cenę w momencie zakupu. Sprawia to, że jest to koncepcja domenowa, a nie zwykłe połączenie.

Dlaczego kompozycja odOrder doOrderLine? Przykład zakłada, że pozycja zamówienia należy do jednego zamówienia i nie ma samodzielnego znaczenia. Używaj kompozycji tylko wtedy, gdy reguła własności i cyklu życia jest prawdziwa w Twojej domenie; notacja UML nie wymusza tego w bazie danych.

Dlaczego rozróżniać ceny bieżące i historyczne?Cena produktu może się zmienić po złożeniu zamówienia. Przechowywanie ceny z momentu zakupu na pozycji zamówienia zachowuje historyczną kwotę.

5. Decyzje modelowania, które mają znaczenie

Identyfikatory: Oznaczaj identyfikatory konsekwentnie, np.customerId luborderId. UML nie definiuje jednej uniwersalnej notacji dla kluczy głównych, więc wybierz konwencję i udokumentuj ją. Stereotyp lub notatka mogą to uczynić jawnym:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Wartości opcjonalne: Użyj [0..1] dla atrybutu opcjonalnego, gdy jest to jasne dla Twoich odbiorców, lub zaznacz regułę. Na przykład płatność może nie mieć paidAt znacznika czasu, dopóki nie zostanie zakończona pomyślnie.

Obiekty wartościowe: Typ taki jak Money lub EmailAddress może reprezentować koncepcję z własną walidacją lub semantyką. Zdecyduj, czy powinien pojawić się jako osobna klasa, typ atrybutu, czy struktura bazy danych, w zależności od odbiorców i poziomu szczegółowości.

Wyliczenia i wartości kontrolowane: Użyj wyliczenia, gdy dopuszczalny zbiór jest mały i względnie stabilny. Jeśli wartości wymagają niezależnych opisów, cyklu życia lub administracji, modeluj je jako klasę.

Normalizacja i implementacja: Diagram klas komunikuje koncepcje i reguły; nie rozstrzyga on każdego szczegółu relacyjnego. Na przykład, czy Money stanie się dwoma kolumnami, osobną tabelą czy typem specyficznym dla bazy danych, jest decyzją implementacyjną.

Utrzymuj czytelność diagramów: Podziel duży obszar na skoncentrowane diagramy – takie jak zamówienia, magazyn i tożsamość – i używaj pakietów do grupowania powiązanych klas. Pokazuj tylko atrybuty istotne dla pytania, na które ma odpowiadać diagram.

6. Zbuduj model na podstawie wymagań

1. Wyodrębnij kandydujące koncepcje z języka domenowego: rzeczowniki często sugerują klasy; czasowniki często sugerują relacje lub zachowanie.

2. Uściślij reguły z konkretnymi pytaniami: Czy zamówienie może istnieć bez klienta? Czy może mieć zero pozycji? Czy płatność może zostać ponowiona?

3. Wybierz poziom modelowania i utrzymuj techniczne decyzje dotyczące bazy danych poza diagramem koncepcyjnym.

4. Dodaj atrybuty i identyfikatory tylko wtedy, gdy pomagają wyjaśnić model.

5. Ustal mnożności z reguł biznesowych, sprawdzając oba końce każdej relacji.

6. Przejrzyj przypadki brzegowe: usuwanie, rekordy historyczne, pola opcjonalne, powtarzane próby i zmieniające się wartości.

7. Wygeneruj i przeanalizuj diagram z ekspertami domenowymi i implementatorami. Traktuj go jako model do walidacji, a nie jedynie jako obrazek do zatwierdzenia.

7. Użyj VPasCode i Visual Paradigm

VPasCode to przeglądarkowy edytor tekstu do diagramu z obsługą PlantUML oraz podgląd na żywo. Jego opis funkcji wymienia również generowanie i modyfikację kodu diagramu przy użyciu AI, a także pomoc w składni. Praktyczny przepływ pracy wygląda następująco:

1. Otwórz VPasCode i wybierz lub wprowadź PlantUML.

2. Wklej powyższy przykład i sprawdź wygenerowany diagram.

3. Iteruj nad źródłem PlantUML; zachowaj tekst jako wersjonowalny artefakt.

4. Użyj asystenta AI, jeśli jest dostępny w Twoim środowisku pracy, aby przygotować lub poprawić pierwszą wersję.

5. Sam zweryfikuj każdą wygenerowaną klasę, relację, mnożność i regułę biznesową.

Narzędzia do diagramów wspomagane przez AI w Visual Paradigm mogą generować edytowalne diagramy na podstawie opisów w języku naturalnym. Opublikowany przepływ pracy opisuje generowanie diagramu klas na podstawie polecenia, a następnie dopracowanie jego elementów i relacji. Traktuj wynik AI jakoszkic: może on wnioskować o nieprawidłowym własności, brakujących ograniczeniach lub nieuzasadnionych klasach. Poprawność modelu nadal zależy od jego walidacji względem wymagań.

Na przykład, podaj asystentowi AI polecenie:

Stwórz logiczny diagram klas UML dla sklepu internetowego. Klienci składają zamówienia. Każde zamówienie zawiera jedną lub więcej pozycji zamówienia. Każda pozycja zamówienia odnosi się do jednego produktu i przechowuje ilość oraz cenę jednostkową w momencie zakupu. Zamówienia mogą mieć wiele prób płatności. Uwzględnij identyfikatory, mnożności oraz wyliczenia statusu zamówienia i płatności. Wygeneruj wyłącznie kod PlantUML.

Następnie przeanalizuj wynik pod kątem wymagań przed jego zaakceptowaniem. Aby uzyskać lepsze wyniki, określ założenia wprost – na przykład, czy zamówienia mogą być szkicami bez pozycji oraz czy płatności mogą być zwracane.

Visual Paradigm opisujeVPasCode jako edytor obsługujący PlantUML z podglądem na żywo i generowaniem lub modyfikacją wspieraną przez AI. Dostępność i narzędzia mogą się różnić w zależności od wersji produktu lub środowiska pracy.

8. Zwięzła lista kontrolna przeglądu

Przed udostępnieniem lub wdrożeniem diagramu klas sprawdź:

• Czy każda klasa reprezentuje znaczącą koncepcję domenową?

• Czy identyfikatory i istotne atrybuty są jasne?

• Czy etykiety relacji i mnożności są poprawne na obakońcach?

• Czy kompozycja odzwierciedla rzeczywistą zależność cyklu życia?

• Czy fakty historyczne są zachowane tam, gdzie wartości bieżące mogą się zmieniać?

• Czy wartości opcjonalne i ograniczenia biznesowe są widoczne?

• Czy diagram jest wystarczająco skupiony na odbiorcach?

• Czy wygenerowana treść została sprawdzona względem rzeczywistych wymagań?

Najlepszy przepływ pracy diagram-as-code to AI do stworzenia szkicu, PlantUML do precyzyjnych edycji i historii wersji oraz recenzja ludzka pod kątem poprawności domenowej.

Ten post dostępny jest również w Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Portuguese, Việt Nam, 简体中文 and 繁體中文