# UML-Grundlagen: Klassendiagramm und Use Cases

> UML ist eine standardisierte grafische Sprache, um Software zu modellieren, bevor sie programmiert wird. Am wichtigsten für die Ausbildung sind das Klassendiagramm, das den statischen Aufbau aus Klassen, Attributen und Beziehungen zeigt, und das Anwendungsfalldiagramm, das aus Nutzersicht darstellt, wer welche Funktionen nutzt. UML ist sprachunabhängig und dient der Verständigung im Team.

**Autor:** Mr. Benjamin · **Beruf:** IT-Grundlagen
**Veröffentlicht:** 2026-07-25 · **Aktualisiert:** 2026-10-28
**Quelle:** https://yellowbluetech.de/blog/uml-diagramme-grundlagen

---

Bevor ein Haus gebaut wird, gibt es einen Bauplan. Für Software ist UML dieser Bauplan: eine Zeichnung, die zeigt, wie das System aufgebaut ist und wer es wie nutzt – verständlich für alle im Team, egal in welcher Programmiersprache später gearbeitet wird.

## Was ist UML?

UML (*Unified Modeling Language*) ist eine **standardisierte grafische Sprache** zur Modellierung von Software. „Standardisiert" heißt: Die Symbole bedeuten überall dasselbe, sodass ein Diagramm ohne Erklärung lesbar ist.

> **Merksatz**
>
> UML ist **sprachunabhängig** und beschreibt das *Was* und *Wie* eines Systems, nicht den fertigen Code. Es dient der **Verständigung** – zwischen Entwicklern, mit dem Kunden und mit dem eigenen späteren Ich.

UML kennt viele Diagrammtypen. Für die Ausbildung sind zwei zentral: das Klassendiagramm und das Anwendungsfalldiagramm.

## Das Klassendiagramm

Es zeigt den **statischen Aufbau**: aus welchen [Klassen](/blog/oop-grundlagen) das System besteht und wie sie zusammenhängen. Jede Klasse ist ein Kasten mit drei Feldern:

```text
┌─────────────────────┐
│      Kunde          │   ← Name
├─────────────────────┤
│ - name: String      │   ← Attribute (Daten)
│ - kundennummer: int │
├─────────────────────┤
│ + bestellen()       │   ← Methoden (Verhalten)
│ + adresseAendern()  │
└─────────────────────┘
```

Das `-` bedeutet **privat** (nur innerhalb der Klasse sichtbar), das `+` **öffentlich** (von außen nutzbar) – das ist die [Kapselung](/blog/oop-grundlagen) aus der objektorientierten Programmierung.

### Beziehungen und Multiplizität

Zwischen Klassen bestehen Verbindungen, beschriftet mit der **Multiplizität** (wie viele hängen zusammen):

| Notation | Bedeutung |
| --- | --- |
| `1` | genau eins |
| `0..1` | keins oder eins |
| `1..*` | mindestens eins |
| `*` | beliebig viele |

Beispiel: Ein `Kunde` hat `1..*` `Bestellungen`, jede `Bestellung` gehört zu genau `1` `Kunde`.

### UML-Verbindungstypen: Assoziation, Aggregation, Komposition, Vererbung

Neben der einfachen Verbindung kennt UML mehrere Beziehungstypen, die du an der Linie erkennst:

| Verbindungstyp | Darstellung | Bedeutung | Beispiel |
| --- | --- | --- | --- |
| **Assoziation** | einfache Linie | Klassen kennen einander | Kunde – Bestellung |
| **Aggregation** | Linie mit **leerer Raute** am Ganzen | Teil-Ganzes, das Teil kann allein existieren | Abteilung – Mitarbeiter |
| **Komposition** | Linie mit **gefüllter Raute** am Ganzen | Teil-Ganzes, das Teil existiert nicht ohne das Ganze | Rechnung – Rechnungsposition |
| **Vererbung** (Generalisierung) | Linie mit **leerem Dreieck** an der Oberklasse | „ist ein“-Beziehung | Auto – Fahrzeug |
| **Abhängigkeit** | **gestrichelter Pfeil** | eine Klasse nutzt eine andere | Bericht – Drucker |

Merke: **leere Raute = lose Verbindung, gefüllte Raute = feste Verbindung.** Wird bei der Komposition das Ganze gelöscht, verschwinden auch seine Teile. Mehr zur Vererbung steht im Beitrag [Vererbung und Polymorphie](/blog/vererbung-polymorphie).

## Das Anwendungsfalldiagramm

Es zeigt aus **Nutzersicht**, wer welche Funktionen nutzt – ohne jede technische Details. Ausführlich mit Beispiel, include und extend erklärt es der Beitrag [Anwendungsfalldiagramm erklärt: Use Cases](/blog/anwendungsfalldiagramm-erklaert).

- **Akteur** (Strichmännchen): eine Rolle, die mit dem System arbeitet, etwa „Kunde" oder „Administrator".
- **Anwendungsfall** (Ellipse): eine Funktion, etwa „Ware bestellen".
- **Linien** verbinden, wer was tut.

> **Prüfungstipp**
>
> Ein häufiger Prüfungspunkt ist der Unterschied der beiden Diagramme: Das **Klassendiagramm** ist **technisch und statisch** – es zeigt den inneren Aufbau. Das **Anwendungsfalldiagramm** ist **fachlich** – es zeigt aus Anwendersicht, *was* das System leistet, nicht *wie*. Merke außerdem: Ein **Akteur** ist eine **Rolle**, keine konkrete Person – dieselbe Person kann Kunde und Administrator sein.

## Wozu der Aufwand?

> **Hinweis**
>
> Ein Modell zu zeichnen kostet Zeit, spart aber mehr. Fehler im Entwurf fallen auf dem Papier auf, wo sie billig zu ändern sind, statt später im Code. Das Diagramm ist zugleich die Sprache, in der Team und Kunde über das System reden, ohne aneinander vorbeizureden. Und es dokumentiert die Struktur für alle, die später am Projekt weiterarbeiten. Man modelliert dabei bewusst nur so viel, wie zum Verständnis nötig ist – ein UML-Diagramm ist kein Kunstwerk, sondern ein Werkzeug.

## Selbstkontrolle

**Frage:** In einem Klassendiagramm steht vor einem Attribut ein Minuszeichen. Was bedeutet das?

- [x] Das Attribut ist privat, nur innerhalb der Klasse sichtbar.
- [ ] Das Attribut ist öffentlich zugänglich.
- [ ] Das Attribut ist eine Methode.
- [ ] Das Attribut darf nicht verändert werden.

**Erklärung:** Das Minuszeichen kennzeichnet die Sichtbarkeit privat: Das Attribut ist nur innerhalb der eigenen Klasse zugänglich. Das Pluszeichen stünde für öffentlich, also von außen nutzbar. Diese Sichtbarkeiten setzen die Kapselung der objektorientierten Programmierung im Diagramm um.

## Häufige Fragen

### Muss ich UML-Diagramme auswendig können?

Die beiden wichtigsten, Klassen- und Anwendungsfalldiagramm, solltest du lesen und in Grundzügen selbst zeichnen können, weil sie in Prüfungen und in der Projektdokumentation vorkommen. Die genaue Notation aller vierzehn Diagrammtypen muss niemand auswendig können. Wichtiger ist, zu verstehen, welches Diagramm welche Frage beantwortet.

### Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition?

Alle drei sind Beziehungen zwischen Klassen mit zunehmender Bindung. Die Assoziation ist eine einfache Verbindung. Die Aggregation ist eine Teil-Ganzes-Beziehung, bei der das Teil auch allein existieren kann, etwa Student und Hochschule. Die Komposition ist eine stärkere Form, bei der das Teil ohne das Ganze nicht existiert, etwa Rechnung und Rechnungsposition. In der Prüfung reicht meist, die Aggregation von der Komposition unterscheiden zu können.

### Wann nutze ich welches Diagramm?

Das Anwendungsfalldiagramm steht am Anfang, wenn es darum geht, mit dem Kunden zu klären, was das System aus Nutzersicht leisten soll. Das Klassendiagramm kommt später im Entwurf, wenn der innere Aufbau festgelegt wird. Grob gesagt: erst das fachliche Was, dann das technische Wie.

### Brauche ich spezielle Software für UML?

Für die Prüfung reicht Papier und Bleistift, und auch im Betrieb entstehen viele Skizzen zunächst am Whiteboard. Für saubere, teilbare Diagramme gibt es Werkzeuge, von einfachen Zeichenprogrammen bis zu textbasierten Generatoren, die aus einer kurzen Beschreibung ein Diagramm erzeugen. Das Werkzeug ist zweitrangig – entscheidend ist, dass die Notation stimmt.

**Weiterlesen:** [Anwendungsfalldiagramm erklärt: Use Cases](/blog/anwendungsfalldiagramm-erklaert) · [ER-Modell erklärt: Entity-Relationship-Modell](/blog/er-modell-datenbanken-planen) · [Vererbung und Polymorphie in der OOP](/blog/vererbung-polymorphie) · [Softwaretests: von Unit-Test bis Abnahme](/blog/softwaretests-grundlagen) · [Lastenheft und Pflichtenheft: der Unterschied](/blog/lastenheft-pflichtenheft)

## Das Wichtigste in Kürze

- **UML** ist eine standardisierte, **sprachunabhängige** grafische Modellierungssprache.
- Das **Klassendiagramm** zeigt den **statischen Aufbau**: Klassen, Attribute, Methoden, Beziehungen.
- **Sichtbarkeit**: `-` privat, `+` öffentlich; **Multiplizität** gibt die Anzahl an.
- Das **Anwendungsfalldiagramm** zeigt aus **Nutzersicht**, wer welche Funktion nutzt.
- Ein **Akteur** ist eine **Rolle**, keine konkrete Person.