Umfassende Anleitung zu UML-Klassendiagrammen (Diagramm als Code)

💡 Hinweis: Alle Diagramme werden in PlantUML Format bereitgestellt. Sie können sie sofort mithilfe von Visual Paradigm Diagramm als Code.

🔹 Einführung in UML

Was ist UML?

„Die Unified Modeling Language (UML) ist eine allgemein verwendbare visuelle Modellierungssprache, die verwendet wird, um Spezifikationen, Visualisierungen, Konstruktionen und Dokumentationen der Artefakte eines Software-Systems zu erstellen.“ — Rumbaugh usw., 1999

Wichtige Merkmale:

• 🎨 Visuelle Notation: Grafische Syntax zur Modellierung von Systemen

• 📐 Standardisiert: OMG-Standard seit 1997

• 🔧 Sprache, keine Methode: Definiert Notation, nicht Prozess

• 🌐 Breites Spektrum: Modelliert Geschäftsprozesse, Systemfunktionen, Code-Strukturen und Datenbank-Schemata

Was UML NICHT ist

🔹 Geschichte und Standardisierung

Entwicklungszeitlinie

1965–1970: Simula-67 (erste objektorientierte Sprache)
     ↓
1970er–1980er Jahre: Smalltalk am Xerox PARC
     ↓
1984: C++ von Bjarne Stroustrup vorgestellt
     ↓
1988–1992: Verbreitung objektorientierter Methoden (Booch, OMT, OOSE usw.)
     ↓
1994: Rumbaugh tritt bei Rational bei Booch an → Beginn der Vereinheitlichung
     ↓
1995: Entwurf von UML 0.8 veröffentlicht
     ↓
1996: OMG veröffentlicht RFP für eine Standard-Modellierungssprache
     ↓
1997: UML 1.1 wird von der OMG übernommen (14. November)
     ↓
2000: UML 1.3 formell veröffentlicht
     ↓
2003: UML 1.5 veröffentlicht; UML 2.0-Superstruktur angenommen

Warum UML den „Methodenkrieg“ gewann

• Konsolidierte über 50 konkurrierende objektorientierte Methoden zu einer einzigen Standardisierung

• Unterstützt von großen Branchenakteuren (IBM, Microsoft, Oracle, HP)

• Bietet Erweiterungsmöglichkeiten zur Anpassung

• Wurde der de-facto-Standard für objektorientierte Modellierung

⚠️ Kritischer Blick: Einige argumentieren, dass UML „eine Monster-Sprache ist, die von einem Gremium entworfen wurde“ und in frühen Versionen ungenaue Semantik aufweist.

🔹 Klassen und Attribute

Klassenstruktur

Eine UML-Klasse wird als Rechteck mit bis zu drei Feldern dargestellt.

@startuml
class Student {
  firstName: String
  lastName: String
  email[0..1]: String
  encryptedPW: String
  + totalPoints(): Integer
  + setPassword(pw: String)
  + checkPW(pw: String): Boolean
}
@enduml

Syntax zur Attributdeklaration

[Sichtbarkeit] name[Mehrfachheit]: Typ [= Standardwert] {Eigenschaften}

PlantUML-Beispiele:

@startuml
class Student {
  + ProgramOfStudy[0..2]: String = "MIS"
  - encryptedPW: String {frozen}
  # internalID: Integer
  ~ packagePrivateData: String
}
@enduml

Attributbereich

• Instanzbereich (Standard): Jedes Objekt hat seinen eigenen Wert

• Klassenbereich (statisch): Ein einziger Wert, der von allen Instanzen geteilt wird

@startuml
class Student {
  name: String
  {static} count: Integer
}
@enduml

Schlüssel in UML ⚠️

Wichtige Einschränkung: UML verfügt nicht über eine eingebaute Vorstellung von Schlüsseln. Verwenden Sie Stereotypen oder markierte Werte als Workarounds.

@startuml
class Student {
  {pk} id: Integer
  {ak1} email: String
  - name: String
}
@enduml

🔹 Assoziationen und Beziehungen

Grundlegende Assoziation und Vielzahl

@startuml
class Exercise
class Chapter
Exercise "0..*" -- "1..1" Chapter : BelongsTo
@enduml

Interpretation: Jede Übung gehört genau einem Kapitel an; ein Kapitel kann null oder mehr Übungen enthalten.

Rollenbezeichnungen

Verwenden Sie anstelle (oder zusätzlich) von Assoziationsnamen Rollenbezeichnungen an den Enden der Assoziation:

@startuml
class Person
class Company
Person "0..*" --> "0..1" Company : Employee/Employer
@enduml

Implementierung: Die Person Tabelle hätte einen Fremdschlüssel Arbeitgeber verweisend auf Firma.

Navigierbarkeit

Richtung der Durchquerung mit Pfeilen angeben:

@startuml
class Exercise
class Chapter
Exercise "0..*" --> "1" Chapter
@enduml

• Pfeil zeigt Richtung der effizienten Durchquerung an

• In OODBs: implementiert als Zeiger in nur eine Richtung

• In RDBMS: Joins funktionieren unabhängig in beide Richtungen

Sammlungstypen mit {geordnet}


@startuml
class Chapter
class Exercise
Chapter "1" -- "0..*" Exercise : {geordnet}
@enduml

• {geordnet}: Reihenfolge beibehalten (Liste, nicht Menge verwenden)

• Implementierung in RDBMS: Attribut für Reihenfolgenummer hinzufügen

AUFGABEN (
    id PRIMARY KEY,
    kapitel_id VERWEIST AUF KAPITEL,
    sort_reihenfolge INTEGER,
    EINDEUTIG (kapitel_id, sort_reihenfolge)
)

Qualifizierer

Qualifizierer teilen verwandte Objekte mithilfe eines schlüsselähnlichen Mechanismus:

@startuml
class Chapter
class Exercise
Chapter "1" --> "0..1" Exercise : <<Qualifizierer>> no: Integer
@enduml

Bedeutung: Gegeben ein Kapitel und eine Übungsnummer, wird höchstens eine Übung zurückgegeben.

Assoziationsklassen

Wenn eine Assoziation Attribute oder Operationen hat:

@startuml
class Student
class Exercise
class Solution {
  date: Datum
  points: Integer
}
Student "0..*" -- "0..*" Exercise : hat gelöst
Solution .. Student
Solution .. Exercise
@enduml

• Eine Lösung Objekt pro (Student, Übung)-Paar

• Erfordert: Derselbe Student kann nicht zwei Lösungen für dieselbe Übung einreichen

Komposition vs. Aggregation

@startuml
class Chapter
class Exercise
Chapter *-- "0..*" Exercise : Zusammensetzung
Chapter o-- "0..*" Exercise : Aggregation
@enduml

🔹 Operationen und Methoden

Syntax für Operationsdeklaration

@startuml
class Calculator {
  + getTotal(studID: Integer, inclExtra: Boolean = true): Float {isQuery=true}
  + {static} getInstance(): Calculator
  + {constructor} Calculator(initialValue: Float)
  - recalculate(): void
}
@enduml

Parameterangabe:

[Richtung] name: Typ [= Standardwert]

• Richtungen: in (Standard), out, inout

• Standardwerte ermöglichen optionale Parameter

Spezielle Operations-Stereotypen

Operationen im Datenbankkontext

Der kulturelle Konflikt: OO betont Kapselung; relationale Systeme betonen direkten Datenzugriff.

Implementierungsstrategien:

🔹 Verallgemeinerung und Vererbung

Grundlegende Verallgemeinerung

@startuml
class Person
class Student
class Professor
Person <|-- Student
Person <|-- Professor
@enduml

Abstrakte Klassen und Operationen

@startuml
abstrakte Klasse Account {
  - balance: Float
  + deposit(amount: Float): void
  + {abstrakt} withdraw(amount: Float): void
}
@enduml

Verallgemeinerungsbeschränkungen

@startuml
class Person
class Student
class Professor
class OtherPerson
Person <|-- Student : <<{disjunkt, vollständig}>>
Person <|-- Professor : <<{disjunkt, vollständig}>>
Person <|-- OtherPerson : <<{disjunkt, vollständig}>>
@enduml

Mehrfachklassifikation / Diskriminatoren

@startuml
class Employee
class Staff
class Faculty
class HMO
class NonHMO
Employee <|-- Staff : <<Art>>
Employee <|-- Faculty : <<Art>>
Employee <|-- HMO : <<Versicherung>>
Employee <|-- NonHMO : <<Versicherung>>
@enduml

• Diskriminatoren gruppieren wechselseitig ausschließliche Spezialisierungen

• Objekte können je Diskriminatordimension einen Wert haben

🔹 Erweiterungsmechanismen

UML bietet drei Erweiterbarkeitsmechanismen:

1. Stereotypen<< >>

Erweitern Sie die UML-Semantik, indem Sie neue „Untertypen“ von Metamodell-Elementen erstellen.

@startuml
class Customer <<Entität>> {
  - id: Integer
  - name: String
}
class MathLibrary <<Hilfsklasse>> {
  + sin(x: Float): Float
  + cos(x: Float): Float
}
@enduml

2. Tag-Werte{Schlüssel=Wert}

Fügen Sie benutzerdefinierte Eigenschaften zu Modell-Elementen hinzu.

@startuml
class Student {
  {author=sb, version=1.0, persistence=beständig}
  - id: Integer
}
@enduml

3. Einschränkungen {...}

Fügen Sie semantische Einschränkungen mithilfe von freier Textform, OCL oder vordefinierten Abkürzungen hinzu.

@startuml
class Exercise {
  - no: Integer
  - points: Integer {value >= 0}
  {points <= maxPoints}
}
@enduml

🔹 UML für die Datenbankgestaltung: Wichtige Überlegungen

UML in relationales Schema übersetzen

Kritische Unterschiede: OO vs. relational

Praktische Empfehlungen für Datenbankdesigner

1. Schlüssel explizit modellieren: Verwenden Sie {pk}, {ak1} Stereotypen, da UML keine native Schlüsselunterstützung bietet

2. Persistenz markieren: Verwenden Sie {persistent} gekennzeichneten Wert, um Datenbankklassen von transienten Anwendungsklassen zu unterscheiden

3. Operationen vereinfachen: Abbilden von Abfrageoperationen auf Ansichten; komplexe Operationen auf gespeicherte Prozeduren

4. Vererbung sorgfältig behandeln: Mapping-Strategie basierend auf Abfragemustern wählen

5. Einschränkungen dokumentieren: OCL oder klare Texteinschränkungen für Geschäftsregeln verwenden

6. Assoziationsklassen maßvoll verwenden: Nur wenn die Beziehung bedeutende Attribute hat

🎯 Schnellreferenz-Übersicht

PlantUML-Klassendiagramm-Notation Zusammenfassung

@startuml
class <<Stereotyp>> KlassenName {
  {gekennzeichnet=Wert}
  [+/-/#/~] name[mult]: Typ [= val] {Eigenschaften}
  [+/-/#/~] name(Parameter): Rückgabe {Eigenschaften}
}
@enduml

Assoziationsnotation

@startuml
KlasseA "multA" -- "multB" KlasseB : AssoziationsName
KlasseA *-- KlasseB  ' Zusammensetzung
KlasseA o-- KlasseB  ' Aggregation
KlasseA --> KlasseB  ' Navigierbar
@enduml

Sichtbarkeitssymbole

• + Öffentlich

• - Privat

• # Geschützt

• ~ Paket

Allgemeine Eigenschaften & Beschränkungen

• {statisch} / {istAbfrage=true} / {abstrakt}

• {Wert >= 0} / {exklusivOder} / {geordnet} / {pk}

💡 Letzte Überlegung: UML-Klassendiagramme sind für die konzeptuelle Modellierung leistungsstark, aber denken Sie daran, dass sie hauptsächlich für die Softwaretechnik entwickelt wurden. Wenn Sie UML für die Datenbankgestaltung verwenden, seien Sie darauf vorbereitet, die Notation (mit Stereotypen, markierten Werten, Beschränkungen) zu erweitern, um relationale Konzepte wie Schlüssel, Normalisierung und deklarative Beschränkungen zu erfassen, die nicht ursprünglich in der objektorientierten Grundlage von UML enthalten sind.

Leitfaden zusammengestellt aus „Teil 6: UML-Klassendiagramme“ von Stefan Brass, Universität Halle, 2003. Alle Diagramme im PlantUML-Syntaxformat für Kompatibilität mit modernen Werkzeugen.