UML-Klassendiagramme

Eine Klasse ist ein Rechteck mit bis zu drei übereinander gestapelten Abschnitten. Nur der erste ist Pflicht.

• Name. Der Typname, zentriert und fett. Ist die Klasse abstrakt, steht der Name kursiv. Ein Schlüsselwort in Guillemets darüber - «interface», «enumeration» - engt ein, um welche Art Klassifizierer es sich handelt.
• Attribute. Eines pro Zeile, geschrieben als Sichtbarkeit Name: Typ [Multiplizität] = Vorgabe. Ausser dem Namen ist alles optional.
• Operationen. Eine pro Zeile, geschrieben als Sichtbarkeit Name(Parameter): Rückgabetyp.

Das führende Zeichen an jedem Element ist seine Sichtbarkeit: + öffentlich, - privat, # geschützt und ~ Paket. Ein unterstrichenes Element ist statisch - es gehört der Klasse, nicht einer Instanz.

Fast die gesamte Bedeutung eines Klassendiagramms steckt in den Linien, und nur sechs lohnen das Auswendiglernen. Das Ende, das die Verzierung trägt, ist in jedem Fall entscheidend.

Die Zahl am Ende einer Linie sagt, wie viele Instanzen beteiligt sind. Sie steht am entfernten Ende von der Klasse, die sie einschränkt, und genau das verwirrt: liest man Merchant 1 —— 0..* Payment, bedeutet 0..* neben Payment, dass ein Händler null oder mehr Zahlungen hat.

• 1 - genau eine. Die Vorgabe, wenn nichts dasteht, auch wenn es klarer ist, sie hinzuschreiben.
• 0..1 - optional. Das ist die Notation für eine Referenz, die leer sein darf.
• * oder 0..* - beliebig viele, auch keine.
• 1..* - mindestens eine. Eine sinnvolle und häufig vergessene Einschränkung.
• 2..4 - ein expliziter Bereich.

Multiplizität ist der billigste Korrektheitsgewinn der ganzen Notation. „Darf das leer sein?“ und „kann es mehr als eines geben?“ sind die beiden Fragen, die in einem Entwurfsreview echte Meinungsverschiedenheiten hervorholen, und die Antwort braucht drei Zeichen.

Diese drei sind dieselbe Beziehungsform in drei Stärken, und der Unterschied betrifft den Lebenszyklus, nicht wie stark sich die beiden Dinge zusammengehörig anfühlen.

Eine schlichte Assoziation behauptet nichts über Eigentum. Zwei Dinge sind verbunden. Das ist alles, und es ist die richtige Vorgabe.

Aggregation - die hohle Raute - behauptet eine Ganzes-Teil-Beziehung, bei der das Teil unabhängig ist. Ehrlicher Rat: Aggregation trägt in UML 2.5.1 fast keine formale Semantik, und die Leser sind sich uneins, was sie impliziert. Sind Sie zwischen Assoziation und Aggregation unsicher, zeichnen Sie die Assoziation.

Komposition - die gefüllte Raute - ist die, die etwas Starkes und Prüfbares sagt. Das Teil gehört genau einem Ganzen und wird mit ihm zerstört. Im Zahlungsmodell existiert ein Refund nur als Teil eines Payment; eine frei schwebende Erstattung gibt es nicht. Das ist eine echte Einschränkung, die es zu notieren lohnt, und sie bildet sich direkt auf ein kaskadierendes Löschen oder eine besessene Collection im Code ab.

Die nützlichsten Klassendiagramme sind in der Praxis klein. Sieben bis zwölf Klassen, Attribute nur bei denen, über die gerade gesprochen wird, überall sonst weggelassen, und jede Linie trägt eine Multiplizität. So ein Diagramm wird in einer Besprechung gelesen und beendet Streit. Ein Klassendiagramm mit hundert Kästen ist ein Artefakt, keine Kommunikation.

1. Pfeile in die falsche Richtung. Generalisierung und Realisierung zeigen auf die Abstraktion. Sitzt Ihr Dreieck an der Unterklasse, sagt das Diagramm das Gegenteil von dem, was Sie meinten.
2. Komposition für „stark verwandt“. Die gefüllte Raute ist eine Aussage über den Lebenszyklus. Nehmen Sie sie nur, wenn das Zerstören des Ganzen das Teil wirklich zerstört.
3. Keine Multiplizitäten. Eine Linie mit nichts an beiden Enden hat die wertvollste Information weggeworfen, die das Diagramm tragen könnte.
4. Höhen vermischt. Domänenklassen und Framework-Klassen auf einer Fläche. Teilen Sie auf; jedes Diagramm sollte für ein Publikum lesbar sein.
5. Jeden Getter modelliert. Operationen gehören ins Diagramm, wenn sie Bedeutung tragen. getName() tut das nicht.

Wollen Sie ein Klassenmodell gegen die Wirklichkeit prüfen, zeichnen Sie ein Objektdiagramm - eine einzige konkrete Momentaufnahme von Instanzen. Multiplizitäten, die abstrakt in Ordnung aussahen, fallen erfahrungsgemäss sofort um, sobald man sie mit echten Werten füllen will.