Die Bilder des Beitrags sind mit KI generiert.
Code beschreibt, wie ein System arbeitet. Ein Diagramm beschreibt, wie es aufgebaut ist. Genau diese zweite Sicht fehlt in vielen Projekten, sobald mehrere Personen an derselben Anwendung entwickeln oder ein neues Teammitglied sich einarbeiten soll. Die Unified Modeling Language liefert dafür eine Notation, die seit Jahrzehnten etabliert und weitgehend werkzeugunabhängig ist. Besonders das Klassendiagramm hat sich gehalten, weil es Struktur und Beziehungen auf einer Seite sichtbar macht. Dieser Beitrag zeigt, wie ein sauberes Klassendiagramm entsteht, welche Beziehungen es gibt und wie sich der Aufwand in einem sinnvollen Rahmen halten lässt.
Wofür UML in der Praxis noch taugt
Die große Zeit umfassender Modellierung ist vorbei, das Werkzeug selbst aber keineswegs. In agilen Teams wird UML heute punktuell eingesetzt, dort wo eine Skizze schneller erklärt als eine lange Beschreibung. Typische Anlässe sind der Entwurf eines neuen Moduls, die Dokumentation gewachsener Strukturen, die Übergabe an ein anderes Team und die Abstimmung mit Fachbereichen, die keinen Code lesen.
Der Nutzen entsteht durch die gemeinsame Sprache. Wenn alle Beteiligten wissen, dass eine gefüllte Raute eine Komposition bedeutet, entfällt die Diskussion darüber, was der Zeichner gemeint haben könnte. Genau deshalb lohnt es sich, bei der Notation genau zu bleiben, auch wenn nur eine Handvoll Elemente verwendet wird.
Die wichtigsten Diagrammarten
Der Standard umfasst über ein Dutzend Diagrammtypen, im Alltag reichen jedoch wenige:
- Klassendiagramm für die statische Struktur mit Klassen, Attributen und Beziehungen
- Sequenzdiagramm für den zeitlichen Ablauf von Aufrufen zwischen Objekten
- Anwendungsfalldiagramm für die Abstimmung mit Fachbereichen und Auftraggebern
- Aktivitätsdiagramm für Abläufe mit Verzweigungen und Parallelität
- Zustandsdiagramm für Objekte mit klar unterscheidbaren Zuständen
- Komponentendiagramm für den Zuschnitt größerer Systeme und ihrer Schnittstellen
Das Klassendiagramm im Detail
Eine Klasse wird als Rechteck mit drei Bereichen dargestellt. Oben steht der Name, in der Mitte stehen die Attribute, unten die Operationen. Attribute werden mit Typ notiert, Operationen mit Parametern und Rückgabetyp. Vor jedem Element steht ein Zeichen für die Sichtbarkeit, wobei das Pluszeichen für öffentlich, das Minuszeichen für privat, die Raute für geschützt und die Tilde für paketweit sichtbar steht.
Abstrakte Klassen werden kursiv gesetzt, statische Elemente unterstrichen. Schnittstellen erhalten den Zusatz in doppelten spitzen Klammern. Diese Konventionen wirken kleinlich, sie sparen aber Rückfragen, weil sich der Zweck einer Klasse ohne Blick in den Code erschließt.
Ein häufiger Streitpunkt ist die Detailtiefe der Attribute. Für den Entwurf genügt es, die fachlich bedeutsamen Felder aufzuführen und technische Hilfsattribute wegzulassen. Wer aus dem Diagramm später Code erzeugen möchte, braucht dagegen die vollständige Angabe mit Typ und Standardwert. Diese Entscheidung sollte am Anfang fallen, weil ein halb ausgefülltes Modell für beide Zwecke unbrauchbar bleibt und beim nächsten Blick niemand mehr weiß, ob eine Lücke Absicht war.
Beziehungen richtig zeichnen
Die Aussagekraft eines Klassendiagramms steckt in den Verbindungslinien. Eine einfache Assoziation bedeutet, dass zwei Klassen voneinander wissen. Die Aggregation mit der leeren Raute beschreibt eine Teil-Ganzes-Beziehung, bei der die Teile auch ohne das Ganze bestehen können. Bei der Komposition mit der gefüllten Raute ist das Teil vom Ganzen abhängig und verschwindet mit ihm. Vererbung wird durch einen Pfeil mit geschlossener Spitze zur Oberklasse dargestellt.
Ergänzt werden die Linien um Multiplizitäten an beiden Enden, etwa 1, 0..1 oder 1..*. Erst diese Angaben machen aus einer Skizze eine überprüfbare Aussage, denn sie legen fest, wie viele Objekte auf jeder Seite beteiligt sind. Fehlen sie, bleibt das Diagramm eine unverbindliche Anordnung von Kästen.
Online erstellen und im Team teilen
Für die Erstellung reicht Papier für den ersten Entwurf, danach beginnt die Pflege. Wer ein UML Diagramm online anlegt, arbeitet direkt im Browser, nutzt fertige Notationsformen für Klassen und Beziehungen und kann je nach Plattform sogar ein UML Diagramm mit Code oder Markup automatisch erstellen, und am Ende das Ergebnis mit einem Link teilen. Praktisch ist die gleichzeitige Bearbeitung durch mehrere Personen, weil Entwurfsentscheidungen so im Diagramm selbst diskutiert werden, statt in einem Nachrichtenverlauf zu versanden.
Für die tägliche Arbeit zählen drei Eigenschaften. Das Diagramm sollte sich als Bild oder PDF exportieren lassen, damit es in Dokumentation und Präsentationen passt. Es sollte eine Versionshistorie geben, um Entwurfsstände zu vergleichen. Und die Notationsformen sollten dem Standard entsprechen, damit das Ergebnis auch außerhalb des eigenen Teams lesbar bleibt.
Begriffe und Standard
Wer sich unsicher ist, welches Element wofür steht, findet eine kompakte Einordnung im Informatiklexikon der Gesellschaft für Informatik. Der Eintrag zur Unified Modeling Language beschreibt Herkunft, Aufbau und Einsatzgebiete der Sprache und ordnet sie in die Modellierung von Software- und Informationssystemen ein. Als gemeinsame Referenz eignet er sich gut, weil er unabhängig von einzelnen Werkzeugen formuliert ist.
Wie viel Modell genug ist
Die häufigste Frage im Alltag betrifft den Umfang. Bewährt hat sich die Regel, nur das zu modellieren, was ohne Diagramm schwer zu erklären wäre. Für eine Anbindung an eine fremde Schnittstelle genügt oft ein Diagramm mit fünf Klassen, das Datenfluss und Zuständigkeiten zeigt. Wie eine solche Integration im Detail aussieht, zeigt der Praxisbeitrag zur Claude API mit Architektur und Endpunkten. Ein Modell, das jede Hilfsklasse abbildet, veraltet dagegen innerhalb weniger Wochen.
Für den Einstieg lohnt es sich, zunächst ein bestehendes Modul nachzuzeichnen, statt bei einem neuen Entwurf zu beginnen. Der Abgleich mit dem Code deckt Missverständnisse sofort auf. Wer parallel die Grundlagen vertiefen möchte, findet im Leitfaden zum Thema Programmieren lernen eine Struktur, die von den Sprachgrundlagen bis zu eigenen Projekten führt.
Typische Fehler
- Multiplizitäten fehlen, das Diagramm bleibt unverbindlich
- Aggregation und Komposition werden vertauscht
- Zu viele Klassen auf einem Blatt, niemand liest das Ergebnis
- Das Modell wird nach dem Entwurf nie wieder aktualisiert
- Eigene Symbole ersetzen die Standardnotation
- Sichtbarkeiten werden weggelassen, obwohl sie die Kapselung zeigen
Fazit
Ein Klassendiagramm ist schnell gezeichnet und liefert genau dann Wert, wenn es klein bleibt und gepflegt wird. Wer die Notation korrekt verwendet, Multiplizitäten angibt und sich auf die erklärungsbedürftigen Teile beschränkt, spart in jeder Übergabe und in jeder Entwurfsdiskussion Zeit. Für Skizzen genügt Papier, für alles, was länger lebt und mit anderen geteilt wird, lohnt ein Werkzeug mit Versionierung und Standardnotation.