Klassendiagramm

Ein Klassendiagramm ist ein Diagramm der UML, mit dem du die statische Struktur eines objektorientierten Systems beschreibst. Es zeigt, welche Klassen es gibt, welche Daten und Operationen sie besitzen und wie diese Klassen miteinander verbunden sind.

In der IT-Ausbildung ist das Klassendiagramm besonders wichtig für Fachinformatiker Anwendungsentwicklung. Es taucht in Aufgaben zu Softwareentwurf, objektorientierter Programmierung, Datenmodellierung und Projektdokumentation auf. In der Prüfung musst du häufig ein vorhandenes Klassendiagramm lesen, ein kleines Modell aus einer Beschreibung ableiten oder Beziehungen fachlich begründen.

Wofür ein Klassendiagramm genutzt wird

Ein Klassendiagramm beantwortet nicht die Frage, in welcher Reihenfolge ein Programm abläuft. Dafür eignen sich zum Beispiel Aktivitätsdiagramme, Sequenzdiagramme oder Pseudocode. Das Klassendiagramm beschreibt die Struktur:

• Welche fachlichen Objekte gibt es?
• Welche Attribute speichern diese Objekte?
• Welche Methoden oder Operationen stellt eine Klasse bereit?
• Welche Klassen kennen oder besitzen andere Klassen?
• Gibt es Vererbung, Schnittstellen oder abstrakte Klassen?
• Wie viele Objekte dürfen miteinander verbunden sein?

Damit ist das Klassendiagramm ein Bindeglied zwischen fachlicher Analyse und Implementierung. Aus einem guten Klassendiagramm lässt sich oft erkennen, welche Klassen später im Code entstehen, welche Verantwortlichkeiten sie tragen und welche Beziehungen besonders wichtig sind.

Aufbau einer Klasse

Eine Klasse wird in UML als Rechteck dargestellt. Dieses Rechteck ist meistens in drei Bereiche unterteilt:

Attribute und Methoden können mit Sichtbarkeiten gekennzeichnet werden:

Ein einfaches Beispiel wäre eine Klasse Artikel mit den Attributen artikelnummer, name und preis. Eine Methode könnte preisBerechnen() sein, wenn Rabatte, Steuern oder Varianten berücksichtigt werden.

Beziehungen im Klassendiagramm

Die Beziehungen zwischen Klassen sind der wichtigste Teil eines Klassendiagramms. Sie zeigen, wie Objekte zusammenarbeiten oder voneinander abhängen.

In Prüfungsaufgaben ist vor allem die Unterscheidung zwischen Assoziation, Aggregation und Komposition relevant. Eine Komposition ist nur dann sinnvoll, wenn das Teilobjekt ohne das Ganze nicht eigenständig bestehen soll. Wenn beide Objekte unabhängig existieren können, ist meist eine Assoziation oder Aggregation passender.

Multiplizitäten richtig lesen

Multiplizitäten beschreiben, wie viele Objekte einer Klasse mit Objekten einer anderen Klasse verbunden sein dürfen. Sie stehen an den Enden der Verbindungslinien.

Beispiel: Ein Kunde kann 0..* Bestellungen haben. Eine Bestellung gehört zu genau 1 Kunde. Diese Aussage ähnelt einer Kardinalität im Entity-Relationship-Modell, ist aber im UML-Kontext objektorientiert zu lesen.

Beispiel: Online-Shop

Ein einfaches Klassendiagramm für einen Online-Shop könnte diese Klassen enthalten:

Eine passende Modellierung wäre:

• Kunde zu Bestellung: Assoziation mit 0..* Bestellungen pro Kunde und 1 Kunde pro Bestellung
• Bestellung zu Bestellposition: Komposition, weil Positionen ohne Bestellung fachlich keinen Sinn ergeben
• Bestellposition zu Artikel: Assoziation, weil Artikel unabhängig von einer konkreten Position existieren

Damit erkennst du schon vor dem Programmieren, welche Objekte eigene Identität haben und welche eher Teil eines größeren Objekts sind.

Klassendiagramm vs. ER-Modell

Klassendiagramme und ER-Modelle sehen auf den ersten Blick ähnlich aus, haben aber unterschiedliche Schwerpunkte.

In der Praxis hängen beide Modelle oft zusammen. Ein Kunde kann sowohl Klasse im Code als auch Entität in einem Datenmodell sein. Trotzdem solltest du in der Prüfung sauber unterscheiden: Ein ER-Modell beschreibt Datenstrukturen, ein Klassendiagramm beschreibt objektorientierte Strukturen.

Typische Prüfungsaufgaben

In der AP Teil 1 und AP Teil 2 können Klassendiagramme auf verschiedene Arten vorkommen.

Typische Aufgaben sind:

• aus einer textuellen Beschreibung Klassen ableiten
• Attribute und Methoden passend zuordnen
• Multiplizitäten eintragen oder korrigieren
• Vererbung erkennen und modellieren
• Komposition von Aggregation unterscheiden
• ein Klassendiagramm in Programmcode übertragen
• Fehler in einem bestehenden Diagramm erklären
• ein Modell für die Projektdokumentation fachlich begründen

Besonders häufig wird nicht perfekte UML-Notation erwartet, sondern nachvollziehbares Modellieren. Die Prüfer wollen sehen, dass du Fachobjekte, Verantwortlichkeiten und Beziehungen sinnvoll strukturieren kannst.

Häufige Fehler

Viele Klassendiagramme werden unklar, weil zu viel oder zu wenig modelliert wird.

Häufige Fehler:

• Datenbanktabellen werden eins zu eins als Klassen übernommen, ohne objektorientierte Verantwortung zu prüfen.
• Jede Klasse bekommt nur Attribute, aber keine sinnvollen Methoden.
• Multiplizitäten fehlen oder stehen am falschen Linienende.
• Komposition wird verwendet, obwohl die Teilobjekte unabhängig existieren können.
• Vererbung wird genutzt, obwohl eine einfache Assoziation reichen würde.
• Klassen heißen wie technische Masken oder Seiten statt wie fachliche Objekte.
• Getter und Setter werden in Prüfungsdiagrammen unnötig breit ausgeschrieben.

Ein gutes Klassendiagramm ist nicht möglichst groß, sondern fachlich sauber. Für Prüfungen reicht oft ein reduziertes Modell, das die geforderten Beziehungen klar zeigt.

Checkliste für dein Klassendiagramm

Nutze diese Fragen, bevor du ein Klassendiagramm abgibst:

• Sind alle wichtigen Fachobjekte als Klassen vorhanden?
• Haben Klassen sprechende Namen im Singular?
• Sind Attribute mit sinnvollen Datentypen angegeben?
• Sind Methoden nur dort eingetragen, wo Verhalten relevant ist?
• Sind Beziehungen beschriftet, wenn die Bedeutung sonst unklar wäre?
• Stimmen die Multiplizitäten an beiden Enden?
• Ist Vererbung nur dort verwendet, wo eine echte “ist ein”-Beziehung besteht?
• Ist Komposition nur dort eingesetzt, wo Teilobjekte abhängig vom Ganzen sind?
• Kannst du jede Modellierungsentscheidung im Fachgespräch erklären?

Wenn du diese Fragen beantworten kannst, ist dein Klassendiagramm meist solide genug für Prüfung und Projektdokumentation.