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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
Das wichtigste Diagramm der objektorientierten Modellierung. In 13/15 SE-Klausuren tauchen Klassendiagramme auf — entweder zu lesen oder zu zeichnen.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Das wichtigste Diagramm der objektorientierten Modellierung. In 13/15 SE-Klausuren tauchen Klassendiagramme auf — entweder zu lesen oder zu zeichnen.
Klassendiagramm: Statische Sicht auf das System — Klassen, ihre Attribute, Methoden und die Beziehungen zwischen ihnen.
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 │
└──────────────────────────┘
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 |
Hier wird's spannend — und klausur-relevant.
Kunde ────── Bestellung
Bedeutung: "Kunde kennt Bestellung" oder umgekehrt.
Mit Multiplizität:
Kunde 1 ──── 0..* Bestellung
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 |
Bibliothek ◇──── Buch
Bedeutung: "Bibliothek BESITZT Bücher", aber Bücher können auch ohne Bibliothek existieren (Teil-Ganzes, aber lose).
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 |
Person ◁───── Student
△
└───── Mitarbeiter
Bedeutung: "Student IST EIN Person" (is-a-Beziehung).
<<interface>>
Drucker ◁┄┄┄┄ Laserdrucker
Bedeutung: "Laserdrucker implementiert das Interface Drucker".
Auftrag ┄┄→ Rechnungsdienst
Bedeutung: "Auftrag verwendet Rechnungsdienst" (nutzt Methoden davon, aber speichert keine Referenz).
┌─────────────────┐
│ <<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 │
└─────────────────┘ └─────────────────┘
<<abstract>>-Stereotyp.<<interface>>, <<abstract>>, <<utility>>): erweitern UML.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.
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.
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.
6 Aufgaben zu Sichtbarkeit, Beziehungen, Multiplizitäten und Lese-Verständnis.
Klausurfragen mit Lösungen (6)
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.
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.
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen zu Sichtbarkeit, Beziehungen, Notation.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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