UML-Klassendiagramme für die Datenmodellierung mit PlantUML

Ein UML-Klassendiagramm beschreibt die Struktur eines Systems: die Dinge, die es modelliert, deren Eigenschaften und wie sie miteinander in Beziehung stehen. Für die Datenmodellierung kann es Domänenkonzepte und Einschränkungen erfassen, bevor Sie sich für Tabellen oder Anwendungscode entscheiden.

PlantUML macht das Diagramm reproduzierbar: Sie schreiben Text, rendern ihn, prüfen Änderungen in der Versionskontrolle und aktualisieren ihn, während sich das Modell weiterentwickelt. Es ergänzt – ersetzt nicht – Datenbankschemata, Migrationsvorgänge und detaillierte Geschäftsregeln.

1. Wählen Sie die Modellierungsebene

Ein nützliches Datenmodellierungsdiagramm konzentriert sich in der Regel auf eine Ebene nach der anderen:

• Konzeptionell: Geschäftskonzepte und Beziehungen mit minimalem technischem Detail. Beispiel: Kunde legt Bestellung.

• Logisch: Attribute, Bezeichner, Multiplizitäten und Regeln, ohne das Modell an eine spezifische Datenbank zu binden.

• Physisch: Implementierungsdetails wie SQL-Spaltentypen, Indizes und datenbankspezifische Einschränkungen.

Das Beispiel unten ist ein logisches Domänenmodell. Typen wie UUID, Money, und DateTime sind illustrativ; entscheiden Sie sich für ihre konkreten Darstellungen, wenn Sie eine Technologie auswählen.

2. Grundlagen von PlantUML

Eine Klasse hat einen Namen und kann Attribute und Operationen auflisten:

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

Sichtbarkeitsmarker sind optionale Modellierungshinweise:

• + public

• - private

• # protected

• ~ Paket-Sichtbarkeit

Für ein Domänen- oder Daten-Diagramm sind Attribute am wichtigsten. Fügen Sie Operationen nur hinzu, wenn sie wichtiges Verhalten verdeutlichen; vermeiden Sie es, das Diagramm in eine vollständige Code-Auflistung zu verwandeln.

3. Beziehungen und Multiplizität

Die nützlichsten Beziehungsnotationen für die Datenmodellierung sind:

Multiplizitätsbeschriftungen befinden sich in der Nähe der Assoziationsenden:

• 1 — genau eines

• 0..1 — optional, höchstens eines

• * oder 0..* — null oder mehr

• 1..* — eines oder mehr

• 2..5 — ein begrenzter Bereich

Zum Beispiel:

Kunde "1" -- "0..*" Bestellung : legt an

Lesen Sie die Beschriftungen an beiden Enden sorgfältig: Ein Kunde kann null oder mehr Bestellungen aufgeben; jede Bestellung ist genau einem Kunden zugeordnet. Die Beschriftungen beschreiben die Beziehung, nicht notwendigerweise die Fremdschlüssel-Implementierung einer bestimmten Datenbank.

4. Durchgerechnetes Beispiel: Online-Shop

Dieses Modell umfasst Kunden, Bestellungen, Positionszeilen, Produkte und Zahlungsaufzeichnungen. Es veranschaulicht Bezeichner, wertähnliche Typen, ein Enum, Komposition und Multiplizitäten.

@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

Warum modellieren OrderLine explizit? Die Beziehung zwischen einer Bestellung und einem Produkt verfügt über eigene Daten – Menge und Preis zum Zeitpunkt des Kaufs. Dies macht sie zu einem Domänenkonzept und nicht nur zu einer einfachen Verbindung.

Warum Komposition von Order zu OrderLine? Das Beispiel geht davon aus, dass eine Positionszeile zu einer Bestellung gehört und nicht eigenständig sinnvoll ist. Verwenden Sie Komposition nur, wenn diese Eigentums- und Lebenszyklusregel in Ihrer Domäne zutrifft; die UML-Notation erzwingt dies nicht in der Datenbank.

Warum zwischen aktuellen und historischen Preisen unterscheiden? Der Preis eines Produkts kann sich nach Aufgeben einer Bestellung ändern. Die Beibehaltung eines Preises zum Kaufzeitpunkt auf der Positionszeile bewahrt den historischen Betrag.

5. Modellierungsentscheidungen, die wichtig sind

Bezeichner: Markieren Sie Bezeichner konsistent, z. B. customerId oder orderId. UML definiert keine einzelne universelle Notation für Primärschlüssel, wählen Sie also eine Konvention und dokumentieren Sie diese. Ein Stereotyp oder eine Notiz kann dies explizit machen:

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

Optionale Werte: Verwenden Sie [0..1] für ein optionales Attribut, wenn dies für Ihre Leser klar ist, oder notieren Sie die Regel. Ein Beispiel: Eine Zahlung hat möglicherweise keinen paidAt Zeitstempel, bis sie erfolgreich ist.

Wertobjekte: Ein Typ wie Money oder EmailAddress kann ein Konzept mit eigener Validierung oder Semantik darstellen. Entscheiden Sie je nach Zielgruppe und Detaillierungsgrad, ob es als separate Klasse, als Attributtyp oder als Datenbankstruktur erscheinen soll.

Enums und kontrollierte Werte: Verwenden Sie ein Enum, wenn die zulässige Menge klein und relativ stabil ist. Wenn Werte unabhängige Beschreibungen, Lebenszyklen oder eine Verwaltung benötigen, modellieren Sie sie stattdessen als Klasse.

Normalisierung und Implementierung: Ein Klassendiagramm vermittelt Konzepte und Regeln; es regelt nicht jedes relationalen Detail. Ob beispielsweise Money zu zwei Spalten, einer separaten Tabelle oder einem datenbankspezifischen Typ wird, ist eine Implementierungsentscheidung.

Halten Sie Diagramme lesbar: Teilen Sie ein großes Domänenmodell in fokussierte Diagramme auf – z. B. Bestellung, Lagerbestand und Identität – und verwenden Sie Pakete, um verwandte Klassen zu gruppieren. Zeigen Sie nur Attribute, die für die Frage relevant sind, die das Diagramm beantworten soll.

6. Erstellen Sie ein Modell aus Anforderungen

1. Extrahieren Sie Kandidatenkonzepte aus der Domänensprache: Substantive deuten oft auf Klassen hin; Verben deuten oft auf Beziehungen oder Verhalten hin.

2. Regeln klären mit konkreten Fragen: Kann eine Bestellung ohne einen Kunden existieren? Kann sie null Positionen haben? Kann eine Zahlung wiederholt werden?

3. Modellierungsebene wählen und halten Sie technische Datenbankentscheidungen von einem konzeptionellen Diagramm fern.

4. Attribute und Bezeichner hinzufügen nur wenn sie dazu beitragen, das Modell zu erklären.

5. Multiplizitäten festlegen aus den Geschäftsregeln, wobei beide Enden jeder Beziehung zu prüfen sind.

6. Randfälle überprüfen: Löschung, historische Datensätze, optionale Felder, wiederholte Versuche und sich ändernde Werte.

7. Darstellen und überprüfen das Diagramm mit Domänenexperten und Umsetzern. Betrachten Sie es als ein zu validierendes Modell, nicht bloß als ein zu genehmigendes Bild.

7. Verwenden Sie VPasCode und Visual Paradigm

VPasCode ist ein browserbasierter Text-zu-Diagramm-Editor mit PlantUML-Unterstützung und eine Live-Vorschau. Die Funktionsbeschreibung listet zudem die KI-Generierung und -Modifikation von Diagrammcode sowie Syntax-Hilfe auf. Ein praktischer Arbeitsablauf ist:

1. Öffnen Sie VPasCode und wählen Sie oder geben Sie PlantUML ein.

2. Fügen Sie das obige Beispiel ein und prüfen Sie das gerenderte Diagramm.

3. Iterieren Sie an der PlantUML-Quelle; behalten Sie den Text als versionierbares Artefakt bei.

4. Verwenden Sie den KI-Assistenten, falls in Ihrem Arbeitsbereich verfügbar, um einen ersten Entwurf zu verfassen oder zu überarbeiten.

5. Überprüfen Sie jede generierte Klasse, jede Beziehung, jede Multiplizität und jede Geschäftsregel selbst.

Die KI-gestützten Diagrammwerkzeuge von Visual Paradigm können bearbeitbare Diagramme aus natürlichen Sprachbeschreibungen generieren. Der veröffentlichte Arbeitsablauf beschreibt die Generierung eines Klassendiagramms aus einer Eingabeaufforderung und anschließendes Verfeinern seiner Elemente und Beziehungen. Betrachten Sie KI-Ausgaben alsEntwurf: Es können falsche Zuordnungen, fehlende Einschränkungen oder nicht gerechtfertigte Klassen abgeleitet werden. Die Korrektheit des Modells hängt weiterhin von der Validierung gegen die Anforderungen ab.

Beispielsweise geben Sie dem KI-Assistenten folgende Eingabeaufforderung:

Erstellen Sie ein logisches UML-Klassendiagramm für einen Online-Shop. Kunden geben Bestellungen auf. Jede Bestellung enthält eine oder mehrere Bestellpositionen. Jede Bestellposition verweist auf ein Produkt und speichert die Menge sowie den Einheitspreis zum Kaufzeitpunkt. Bestellungen können mehrere Zahlungsversuche haben. Fügen Sie Bezeichner, Multiplizitäten und Enums für Bestell- und Zahlungsstatus hinzu. Geben Sie ausschließlich PlantUML aus.

Überprüfen Sie dann die Ausgabe gegen die Anforderungen, bevor Sie sie akzeptieren. Für bessere Ergebnisse geben Sie Annahmen explizit an – beispielsweise, ob Bestellungen als Entwürfe ohne Positionen existieren können und ob Zahlungen erstattet werden können.

Visual Paradigm beschreibtVPasCode als Editor mit PlantUML-Funktionalität mit Live-Vorschau und KI-gestützte Erstellung oder Modifikation. Die verfügbaren Tools und Funktionen können je nach Produktversion oder Arbeitsbereich variieren.

8. Eine kompakte Überprüfungsliste

Bevor Sie ein Klassendiagramm freigeben oder implementieren, prüfen Sie Folgendes:

• Stellt jede Klasse ein sinnvolles Domänenkonzept dar?

• Sind Bezeichner und wichtige Attribute klar definiert?

• Sind Bezeichnungen und Multiplizitäten der Beziehungen an beiden Enden korrekt?

• Spiegelt die Komposition eine echte Lebenszyklusabhängigkeit wider?

• Sind historische Fakten dort erhalten, wo aktuelle Werte sich ändern können?

• Sind optionale Werte und Geschäftsbeschränkungen sichtbar?

• Ist das Diagramm für seine Zielgruppe ausreichend fokussiert?

• Wurde der generierte Inhalt gegen die tatsächlichen Anforderungen geprüft?

Der beste Diagramm-as-Code-Arbeitsablauf ist KI für einen ersten Entwurf, PlantUML für präzise Bearbeitungen und Versionshistorie sowie menschliche Prüfung für die fachliche Korrektheit.

Der Artikel ist auch in English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文 verfügbar.