Was ist ein Klassendiagramm?
Ein Klassendiagramm ist ein strukturelles UML-Diagramm das die statische Architektur eines objektorientierten Softwaresystems visualisiert. Als unverzichtbares UML-Diagrammtyp, zeichnet die einzelnen Klassen, Schnittstellen und Datenmodelle innerhalb Ihrer Anwendung auf und dokumentiert explizit deren interne Felder (Attribute), operativen Funktionen (Methoden) sowie die strukturellen Beziehungen, die sie verbinden. Diese Baupläne sind für Softwareingenieure von entscheidender Bedeutung, die hochgradige Domänenkonzepte in saubere, wartbare Objektstrukturen umsetzen müssen.
Mit Mermaid.js, können Sie Ihre Datenmodelle und Systemdienste mit intuitiven, textbasierten Definitionen darstellen. Der Layout-Engine werden automatisch Boxgrößen berechnet, standardmäßige UML-Datenkammern strukturiert und relationale Pfeile über Ihre Leinwand hinweg ausgerichtet, ohne dass manuelle Formatierungsarbeiten erforderlich sind.
Grundlagen der Syntaxanleitung: Elemente und Konstrukte
Um ein genaues, standardskonformes UML-Klassendiagramm in Mermaid zu erstellen, müssen Sie Mitgliedsdeklarationen, Zugriffsmodifizierer und strukturelle Beziehungspfeile beherrschen.
1. Klassen und Klassenkammern deklarieren
Sie können eine Klasse mit zwei gültigen Formatvorlagen definieren. Für eine einfache Klasse verwenden Sie das classSchlüsselwort gefolgt vom Klassennamen. Wenn Sie Felder und Methoden sofort einbeziehen möchten, verwenden Sie abschließende geschweifte Klammern, um einen klaren Körperteil zu erstellen:
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. Sichtbarkeit / Zugriffsmodifizierer hinzufügen
Um die Standard-UML-Encapsulation-Regeln zu dokumentieren, platzieren Sie ein spezifisches Symbol direkt vor dem Namen Ihres Attributs oder Ihrer Methode, um deren Sichtbarkeitsstufe zu definieren:
+**Öffentlich:** Von jeder anderen Klasse zugänglich.-**Privat:** Nur innerhalb der deklarierenden Klasse zugänglich.#**Geschützt:** Innerhalb der Klasse und ihrer Unterklassen zugänglich.~**Paket / Intern:** Innerhalb derselben Paketgrenze zugänglich.
classDiagram
class Bankkonto {
-double saldo
#String kontoinhaber
+getSaldo() double
}
3. Beherrschen von Beziehungspfeilen und Vererbungsverbindungen
Um darzustellen, wie Klassen innerhalb Ihres UML-Diagrammmodells interagieren, verbinden Sie ihre IDs mithilfe spezialisierter Beziehungszeichenketten. In Mermaid ist die Richtung der Linie entscheidend: die Pfeilspitze zeigt auf die übergeordnete oder Container-Klasse.
- Vererbung / Verallgemeinerung (gestrichelter oder fester Pfeil):
Kind --|> Elternteil(Stellt eine „ist-ein“-Beziehung dar). - Realisierung / Implementierung:
Klasse ..|> Schnittstelle(Stellt eine Klasse dar, die einen Schnittstellenvertrag erfüllt). - Zusammensetzung (fester Diamant):
Kind --* Elternteil(Stellt strenge Eigentumsverhältnisse dar; wenn der Elternteil stirbt, stirbt auch das Kind). - Aggregation (klarer Diamant):
Kind --o Elternteil(Stellt eine lose Sammlungsbeziehung dar; das Kind kann unabhängig existieren). - Abhängigkeit:
KlasseA ..> KlasseB(Stellt einen zeitweiligen Laufzeitverweis dar).
classDiagram
Auto --|> Fahrzeug : "Erbt von"
Motor --* Auto : "Ist Teil von"
Best Practices für saubere Klassenarchitekturlayouts
- Klassenmember visuell gruppieren: Gruppieren Sie Ihre Klassenvariablen immer am Anfang des Körpers und Ihre Funktionen am Ende. Dieses Layout entspricht den Standard-IDE-Klassenstrukturen und macht Ihre Diagramme sofort lesbar.
- Geben Sie Rückgabetypen an: Wenn Sie Methoden deklarieren, fügen Sie den Rückgabetyp am Ende der Methodenzeile an (z. B.
+fetchData() DataSet). Dadurch erhalten Ihr Ingenieurteam präzise Implementierungskontextinformationen. - Halten Sie die Vielzahl klar: Um Arrayanzahlen oder Sammlungsgrößen anzugeben, fügen Sie Vielzahl-Textzeichenfolgen direkt an die Beziehungslinienhülle an (z. B.
Kunde "1" --o "viele" Bestellung).
Realitätsnahe Mermaid.js-Klassendiagramm-Beispiele
Beispiel 1: Zahlungs-Gateway-Domänen-Unter-Subsystem (Kapselung & Schnittstellen)
Dieser funktionale Entwurf modelliert einen Online-Kassen-Domänen-Service. Er zeigt, wie man Zugriffsmodifizierer verwendet, Klassenmember gruppiert und Schnittstellenbeziehungen sauber implementiert.
classDiagram
class Zahlungsprozessor {
<<interface>>
+processPayment(betrag) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(betrag) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(betrag) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> Zahlungsprozessor : "Implementiert"
PayPalGateway ..|> Zahlungsprozessor : "Implementiert"
Syntax-Aufschlüsselung: Das <<interface>> -Tag markiert `Zahlungsprozessor` eindeutig als hochrangigen architektonischen Vertrag. Die beiden konkreten Gateway-Implementierungsklassen verwenden private Felder (-apiKey) für sensible Anmeldeinformationen, während öffentliche Zahlungsprozeduren (+processPayment) über die Realisierungs-Pfeil (..|>).
Beispiel 2: Unternehmens-Order-Verarbeitungs-Engine (Zusammensetzung & Vielzahl)
Dieser fortgeschrittene Systementwurf modelliert ein komplexes E-Commerce-Order-Management-Schema und zeigt, wie man strukturelle Eigentumsverhältnisse und Objektanzahlen über mehrere miteinander verbundene Klassen dokumentiert.
classDiagram
class Kunde {
+int customerId
+String name
+placeOrder() Bestellung
}
class Bestellung {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class Bestellposition {
+int itemId
+int quantity
+double pricePerUnit
}
class Adresse {
+String street
+String city
+String postalCode
}
Kunde "1" --o "viele" Bestellung : "besitzt"
Bestellposition "1..*" --* "1" Bestellung : "besteht aus"
Adresse "1" --> Bestellung : "wird zugestellt an"
Syntaxanalyse: Dieses Beispiel veranschaulicht den Unterschied zwischen Aggregation und Komposition. Der feste Diamantpfeil (--*) zeigt, dass ein `OrderItem` eng mit einem `Order` verknüpft ist (wenn eine Bestellung gelöscht wird, werden auch ihre einzelnen Zeilenartikel zerstört). Umgekehrt zeigt der klare Diamantpfeil (--o) zeigt an, dass ein `Customer` mehrere Bestellungen besitzt, aber beide Entitäten unabhängig voneinander existieren können. Vielfachkeitszeichen (wie "1..*") definieren die relationalen Anforderungen des Systems.