Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Das wichtigste Diagramm der objektorientierten Modellierung. In 13/15 SE-Klausuren tauchen Klassendiagramme auf, entweder zu lesen oder zu zeichnen.
Die Idee in einem Satz
Klassendiagramm: Statische Sicht auf das System, Klassen, ihre Attribute, Methoden und die Beziehungen zwischen ihnen.
Aufbau einer Klasse
Eine Klasse wird als Rechteck mit 3 Abschnitten dargestellt:
┌──────────────────────────┐
│ Konto │ ← Klassenname (oben)
├──────────────────────────┤
│ - kontonummer: String │ ← Attribute (Mitte)
│ - kontostand: double │
│ - inhaber: Person │
├──────────────────────────┤
│ + einzahlen(b: double) │ ← Methoden (unten)
│ + auszahlen(b: double): bool│
│ + getKontostand(): double │
└──────────────────────────┘
Sichtbarkeits-Modifizierer
Vor jedem Attribut/Methoden-Namen steht ein Symbol:
| Symbol | Sichtbarkeit | Bedeutung |
|---|---|---|
| + | public | überall zugreifbar |
| − | private | nur in derselben Klasse |
| # | protected | in derselben Klasse + Subklassen |
| ~ | package | im selben Paket |
Beziehungen zwischen Klassen
Hier wird's spannend, und klausur-relevant.
1. Assoziation (einfache Verbindung)
Kunde ────── Bestellung
Bedeutung: "Kunde kennt Bestellung" oder umgekehrt.
Mit Multiplizität:
Kunde 1 ──── 0..* Bestellung
- "Ein Kunde hat 0 oder mehr Bestellungen"
- "Jede Bestellung gehört zu genau 1 Kunden"
Multiplizitäten:
| Notation | Bedeutung |
|---|---|
1 | Genau 1 |
0..1 | 0 oder 1 (optional) |
* oder 0..* | Beliebig viele (0 bis ∞) |
1..* | Mindestens 1 |
2..5 | Zwischen 2 und 5 |
2. Aggregation (offene Raute ◇)
Bibliothek ◇──── Buch
Bedeutung: "Bibliothek BESITZT Bücher", aber Bücher können auch ohne Bibliothek existieren (Teil-Ganzes, aber lose).
3. Komposition (gefüllte Raute ◆)
Auto ◆──── Motor
Bedeutung: "Auto HAT Motor, Motor lebt + stirbt mit Auto" (existenzielle Abhängigkeit).
Aggregation vs. Komposition (Klausur-Klassiker):
| Aggregation | Komposition | |
|---|---|---|
| Symbol | ◇ (leer) | ◆ (gefüllt) |
| Lifecycle | unabhängig | gebunden |
| Beispiel | Bibliothek-Buch | Auto-Motor |
| Wenn Container weg? | Teile leben weiter | Teile sterben mit |
4. Vererbung / Generalisierung (Pfeil mit weißer Spitze △)
Person ◁───── Student
△
└───── Mitarbeiter
Bedeutung: "Student IST EIN Person" (is-a-Beziehung).
5. Realisierung / Interface-Implementierung (gestrichelt + △)
<<interface>>
Drucker ◁┄┄┄┄ Laserdrucker
Bedeutung: "Laserdrucker implementiert das Interface Drucker".
6. Abhängigkeit (gestrichelter Pfeil)
Auftrag ┄┄→ Rechnungsdienst
Bedeutung: "Auftrag verwendet Rechnungsdienst" (nutzt Methoden davon, aber speichert keine Referenz).
Beispiel-Klassendiagramm
┌─────────────────┐
│ <<interface>> │
│ Bezahlbar │
│─────────────────│
│ + bezahle() │
└────────△────────┘
│ (realisiert)
│
┌─────────────────┐ ┌─────────────────┐
│ Bestellung │ 1 * │ Position │
│─────────────────│◆────────│─────────────────│
│ - id: int │ │ - menge: int │
│ - status │ │ - preis: double │
│─────────────────│ │─────────────────│
│ + bezahle() │ │ + summe() │
└────────┬────────┘ └────────┬────────┘
│ * │ *
│ ────── enthält ────────→ │
│ 1 │ 1
┌────────┴────────┐ ┌────────┴────────┐
│ Kunde │ │ Produkt │
│─────────────────│ │─────────────────│
│ - name: String │ │ - name: String │
│ - email: String │ │ - preis: double │
└─────────────────┘ └─────────────────┘
Wichtige Notations-Details
- abstract Klasse: Klassenname kursiv oder
<<abstract>>-Stereotyp. - abstract Methode: Methodenname kursiv.
- static Member: unterstrichen.
- Stereotypen (
<<interface>>,<<abstract>>,<<utility>>): erweitern UML.
Wann Klassendiagramme verwenden?
- Vor Implementierung: als Skizze, was gebaut wird.
- Während Implementierung: als lebendes Dokument der Architektur.
- Nach Implementierung: als Übersicht für Onboarding neuer Entwickler.
- In Code-Reviews: zur Diskussion struktureller Änderungen.
Klausur-Faustregeln
1. 3 Abschnitte: Klassenname / Attribute / Methoden.
2. Sichtbarkeit: + public / − private / # protected / ~ package.
3. Aggregation (◇) vs. Komposition (◆): offene Raute = lose, gefüllte = existenzielle Bindung.
4. Vererbung: Pfeil mit dreieckiger weißer Spitze, ZEIGT AUF Oberklasse.
5. Multiplizitäten: 1 / 0..1 / * / 1..* / 2..5.
6. Stereotypen wie <<interface>> immer in Guillemets schreiben.
Häufige Stolpersteine
1. Aggregations- und Kompositions-Symbol verwechseln. ◇ = leer = Aggregation. ◆ = gefüllt = Komposition. Eselsbrücke: gefüllt = "fest gebunden" = Komposition.
2. Vererbungs-Pfeil falsch herum. Pfeil zeigt IMMER auf die OBERKLASSE (von Spezial zu Allgemein). "Student → Person", nicht "Person → Student".
3. Interface-Beziehung nicht gestrichelt. Realisierung (implements) ist eine gestrichelte Linie mit Dreieck. Normale Vererbung (extends) ist durchgezogen.
4. Multiplizität als Beziehung lesen. Multiplizität gilt am END der Linie für die KLASSE auf dem anderen Ende. "Kunde 1, 0..* Bestellung" heißt: 1 Kunde hat 0..* Bestellungen, eine Bestellung hat genau 1 Kunden.
5. Sichtbarkeit weglassen. Klausur: IMMER + / − / # angeben. Ohne ist es nicht klar, Default ist je nach Sprache verschieden.
6. Methoden-Parameter und -Rückgabe vergessen. + einzahlen(b: double) ist korrekt, NICHT nur + einzahlen. Bei Rückgabewert: : typ ans Ende.
Interaktiv verstehen
UML-Beziehungen interaktiv
Wähle Beziehungs-Typen und sieh, wie sie zwischen Klassen dargestellt werden. Mit Live-Beispielen für jede Beziehungs-Art.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei der Frage "welche Beziehung modelliere ich hier?" frag dich: Lebt das Teil OHNE den Container? → Aggregation. Stirbt es mit? → Komposition. Ist es eine IS-A-Beziehung? → Vererbung. Werden nur Methoden aufgerufen, aber keine Referenz gespeichert? → Abhängigkeit.
Praxis-Übung
UML-Klassendiagramm, Praxis-Übung
6 Aufgaben zu Sichtbarkeit, Beziehungen, Multiplizitäten und Lese-Verständnis.
Klausurfragen mit Lösungen (6)
- F1.Was bedeutet das Minus-Zeichen (−) vor einem Attribut in UML?
Antwort: private
Erklärung: Das Minus-Zeichen (−) steht für private, nur innerhalb der Klasse zugreifbar. Plus (+) = public (überall), Hash (#) = protected (Klasse + Subklassen), Tilde (~) = package (gleiches Paket). Statische Member werden unterstrichen, NICHT mit Symbol.
- F2.Wie unterscheidet sich Aggregation (◇) von Komposition (◆)?
Antwort: Aggregation: Teile leben unabhängig vom Ganzen; Komposition: Teile sterben mit dem Ganzen
Erklärung: Aggregation (◇ offene Raute) = lose Teil-Ganzes-Beziehung. Teile leben weiter, wenn Container weg ist. Beispiel: Bibliothek-Buch, Buch existiert auch ohne Bibliothek. Komposition (◆ gefüllte Raute) = existenzielle Abhängigkeit. Beispiel: Auto-Motor, Motor stirbt, wenn Auto verschrottet wird. Klassischer Klausur-Klassiker.
- F3.Ordne die UML-Beziehungen ihren Symbolen zu.
Zuordnungen:
- Aggregation → ◇ (offene Raute)
- Komposition → ◆ (gefüllte Raute)
- Vererbung → △ (dreieckige Spitze, durchgezogen)
- Realisierung → △ (dreieckige Spitze, gestrichelt)
Erklärung: Symbol-Cheatsheet: Aggregation ◇ (offen) / Komposition ◆ (gefüllt), beide an der GANZEN-Seite. Vererbung △ durchgezogen / Realisierung △ gestrichelt, beide zeigen auf Oberklasse/Interface. Abhängigkeit ist gestrichelter Pfeil ohne Dreieck.
Typ: Zuordnung
- F4.Was bedeutet die Notation Kunde 1 ──── 0..* Bestellung?
Antwort: Ein Kunde hat genau 0 oder mehr Bestellungen, eine Bestellung hat 1 Kunden
Erklärung: Multiplizität lesen: `Kunde 1, 0..* Bestellung` bedeutet, am Kunden-Ende steht 1 (= jede Bestellung gehört zu genau 1 Kunden), am Bestellung-Ende steht 0..* (= ein Kunde kann 0 oder mehr Bestellungen haben). Multiplizität gilt am Ende der Linie für die Klasse auf der GEGENÜBERLIEGENDEN Seite.
- F5.Eine abstrakte Klasse wird in UML durch Anführungszeichen um den Klassennamen markiert.
Antwort: Falsch
Erklärung: FALSCH. Abstrakte Klassen werden durch KURSIVEN Klassennamen oder durch das Stereotyp `<<abstract>>` markiert. Anführungszeichen sind keine UML-Notation. Statische Member werden unterstrichen. Interfaces durch Stereotyp `<<interface>>`.
Typ: Wahr/Falsch
- F6.Du modellierst ein Auto, einen Motor und einen Reifen. Welche Beziehungen sind angemessen?
Antwort: Auto-Motor: Komposition; Auto-Reifen: Aggregation
Erklärung: Klassiker: Motor und Auto bilden EINE Einheit (Komposition ◆), der Motor wird im Werk eingebaut, gehört zu DIESEM Auto, wird mit dem Auto verschrottet. Reifen dagegen sind separat: man kann sie wechseln, sie passen auf verschiedene Autos, leben länger als das Auto eventuell. Daher Aggregation ◇. Achtung: in der Praxis gibt es kein 'eindeutig richtig', kommt auf die Modellierungs-Intention an.
Klausur-Quiz
UML-Klassendiagramm, Klausur-Quiz
6 typische Klausurfragen zu Sichtbarkeit, Beziehungen, Notation.
Klausurfragen mit Lösungen (6)
- F1.Welche Sichtbarkeit hat ein Attribut mit # (Hash) in UML?
Antwort: protected
Erklärung: Der Hash # steht für PROTECTED, zugreifbar in der Klasse selbst und in allen Subklassen, aber nicht von außen. Wichtige Sichtbarkeits-Symbole: + public, − private, # protected, ~ package. Alle 4 im Schlaf können.
- F2.In welche Richtung zeigt der Vererbungs-Pfeil (△)?
Antwort: Von der Unterklasse zur Oberklasse
Erklärung: Vererbungs-Pfeil zeigt von der UNTERKLASSE zur OBERKLASSE (Spezialisierung zu Generalisierung). 'Student → Person' (Student ist eine spezielle Person). Eselsbrücke: der Pfeil zeigt in die Richtung des 'IST EIN', Student IST EIN Person.
- F3.Bei Aggregation steht eine {{1}} Raute an der Container-Klasse, bei Komposition eine {{2}} Raute. Interfaces werden mit dem Stereotyp <<{{3}}>> markiert.
Lösungen pro Lücke:
- {{1}}: offene / leere
- {{2}}: gefüllte / schwarze / ausgefüllte
- {{3}}: interface
Erklärung: Aggregation = ◇ (offen/leer), lose Bindung. Komposition = ◆ (gefüllt/schwarz), existenzielle Bindung. Interfaces werden in UML mit <<interface>> Stereotyp gekennzeichnet, da die Klassen-Notation sonst gleich aussieht. Stereotypen kommen IMMER in Guillemets (« »).
Typ: Lückentext
- F4.Du modellierst ein Auto. Bringe die Beziehungen in absteigender Stärke (von stärkster zu schwächster Bindung).
Richtige Reihenfolge:
- Vererbung (IST EIN)
- Komposition (besitzt existenziell)
- Aggregation (besitzt lose)
- Abhängigkeit (verwendet)
Erklärung: Stärke der Bindung (stärkste zuerst): 1) Vererbung (IS-A, Subklasse erbt alles), 2) Komposition (Teile leben/sterben mit Container), 3) Aggregation (Teile gehören dazu, aber unabhängiges Leben), 4) Abhängigkeit (nutzt nur Methoden, keine Referenz). In der Praxis: lieber lose Kopplungen wählen (DIP-Prinzip).
Typ: Reihenfolge
- F5.Eine Klasse hat folgendes Attribut: - _id: int_. Was bedeutet die Notation (unterstrichen + Minus)?
Antwort: private statisches Attribut
Erklärung: Minus (−) = private; Unterstreichung = static. Also: privates statisches Attribut. Statische Member gehören zur Klasse selbst, nicht zur Instanz. Beispiel: `private static int counter` in Java. Wichtig: Unterstreichung ist eine TYPOGRAFISCHE Notation, nicht ein Symbol.
- F6.Im UML-Klassendiagramm können sowohl Attribute als auch Methoden statisch (unterstrichen) sein.
Antwort: Wahr
Erklärung: RICHTIG. Beides ist möglich: statische Attribute (z.B. `private static int counter`) UND statische Methoden (z.B. `public static int getCounter()`). Beide werden in UML unterstrichen. Statische Member gehören zur KLASSE, nicht zur INSTANZ, sie werden über den Klassennamen aufgerufen (z.B. `Math.PI`, `Logger.getInstance()`).
Typ: Wahr/Falsch
