Die Kunst der Modellierung 7 Sections64 Lessons6 Quizzes8 Weeks
Zusammenfassung: Klassendiagramme
Klassendiagramme – Begriffe, Bedeutung und Stolpersteine
🚀 Worum geht’s hier?
Diese Lektion ist eine vollständige Referenztabelle über alle Elemente eines UML-Klassendiagramms – zum Nachschlagen und Wiederholen. Zu jedem Begriff findest du eine kurze Erklärung und ein Diagrammbeispiel; die häufigsten Stolpersteine stehen jeweils gesammelt unter der Tabelle.
1. Grundbausteine
| Name | Beschreibung | Beispiel |
|---|---|---|
| Klasse | Der Bauplan, aus dem beliebig viele Objekte entstehen können. |
Hund
-name : String
+bellt()
|
| Objekt | Ein konkretes Exemplar einer Klasse mit festen Attributwerten. | Bello : Hund -name = „Bello“ |
| Attribut | Eine Eigenschaft, die den Zustand eines Objekts beschreibt. | -name : String |
| Methode | Eine Fähigkeit bzw. Aktion, die ein Objekt ausführen kann. | +bellt() |
⚠️ Stolpersteine
- Klasse: im Plural benennen („Hunde“ statt „Hund“) – jede Klasse beschreibt genau einen Bauplan.
- Objekt: mit der Klasse verwechseln – Bello ist das Exemplar, Hund der Bauplan, nicht umgekehrt.
- Attribut: Klammern () anhängen – dann sieht es aus wie eine Methode.
- Methode: den Doppelpunkt bei Rückgabetyp mit dem Doppelpunkt bei Attribut-Datentypen verwechseln.
2. Die vier Grundpfeiler der Objektorientierung
| Name | Beschreibung | Beispiel |
|---|---|---|
| Abstraktion | Unwichtige Details weglassen, nur das Wesentliche/Gemeinsame betrachten. | Bello (Objekt) → Hund (Klasse) |
| Vererbung | Eine Unterklasse übernimmt automatisch Attribute/Methoden ihrer Oberklasse. |
Tier
Hund
|
| Kapselung | Daten vor unkontrolliertem Zugriff schützen; Attribute privat, Methoden öffentlich. |
-kontostand : float
+einzahlen(betrag: float)
|
| Polymorphie | Gleicher Methodenname, unterschiedliches Verhalten je nach Klasse (Overriding). | Hund.fortbewegen() → „rennt“ Vogel.fortbewegen() → „fliegt“ |
⚠️ Stolpersteine
- Abstraktion: zu sehr ins Detail gehen, statt die Gemeinsamkeiten mehrerer Objekte herauszuarbeiten.
- Vererbung: Pfeilrichtung vertauscht (zeigt zur Unterklasse statt zur Oberklasse) oder Ober-/Unterklasse selbst vertauscht.
- Kapselung: Attribute versehentlich public lassen, sodass sie von außen direkt verändert werden könnten.
- Polymorphie: Overriding (Methode überschreiben) und Overloading (Methode mit anderen Parametern überladen) verwechseln.
3. Sichtbarkeiten
| Name | Beschreibung | Beispiel |
|---|---|---|
| public (+) | Von überall zugreifbar. Meist bei Methoden. | +bellt() |
| protected (#) | Zugreifbar innerhalb der Klasse und ihrer Unterklassen. | #alter : int |
| private (-) | Nur innerhalb der eigenen Klasse zugreifbar. Meist bei Attributen. | -name : String |
⚠️ Stolpersteine
- public (+): bei fehlendem Symbol nicht automatisch public annehmen – ohne Angabe gilt: Attribute privat, Methoden public.
- protected (#): mit privat verwechseln – Unterklassen dürfen bei protected direkt zugreifen, bei privat nicht.
- private (-): denken, private Attribute seien von außen gar nicht nutzbar – der Zugriff läuft nur über öffentliche Methoden.
4. Klassendetails-Notation
| Name | Beschreibung | Beispiel |
|---|---|---|
| Datentyp | Legt fest, welche Art von Wert ein Attribut speichern darf. | -alter : int |
| Standardwert | Anfangswert, den ein Attribut ohne weitere Angabe besitzt. | -alter : int = 0 |
| Parameter | Information, die eine Methode beim Aufruf entgegennimmt. | +laufen(distanz: float) |
| Rückgabewert | Wert, den eine Methode nach Ausführung zurückliefert. | +gewicht(): float |
⚠️ Stolpersteine
- Datentyp: den Doppelpunkt bei Attributen (Name : Typ) mit dem bei Methoden (Parameter): Rückgabetyp) verwechseln.
- Standardwert: ihn mit dem tatsächlichen späteren Wert eines konkreten Objekts verwechseln.
- Parameter: Parameter (in den Klammern) und Rückgabewert (nach den Klammern) vertauschen.
- Rückgabewert: die Klammern bei parameterlosen Methoden vergessen – auch ohne Parameter bleiben () stehen.
5. Abstrakte Klassen & Schnittstellen
| Name | Beschreibung | Beispiel |
|---|---|---|
| Abstrakte Klasse | Gemeinsamer Bauplan mehrerer Klassen; wird selbst nie instanziiert. |
Säugetier
{abstract}
|
| Schnittstelle (Interface) | Beschreibt nur gemeinsames Verhalten; keine Attribute, nur Methodensignaturen. |
<<interface>>
Beweglich
|
| Realisierung | Eine Klasse setzt eine Schnittstelle um. Gestrichelte Linie + hohler Pfeilkopf. |
<<interface>>
Beweglich Hund
|
⚠️ Stolpersteine
- Abstrakte Klasse: trotzdem versuchen, direkt ein Objekt davon zu erzeugen – geht nur über die Unterklassen.
- Schnittstelle: ihr versehentlich ein Attribut geben – Schnittstellen dürfen nur Methodensignaturen besitzen.
- Realisierung: eine durchgezogene statt gestrichelte Linie zeichnen oder von „erbt“ statt „realisiert“ sprechen.
6. Beziehungstypen zwischen Klassen
| Name | Beschreibung | Beispiel |
|---|---|---|
| Vererbung | „Ist ein“. Durchgezogene Linie, hohler Pfeilkopf zur Oberklasse. | Hund ──▷ Tier |
| Assoziation | Dauerhafte Beziehung. Durchgezogene Linie, meist als Attribut gespeichert. | Hund ──────── Besitzer |
| Abhängigkeit | Vorübergehende Nutzung, z. B. als Methodenparameter. Gestrichelte Linie. | Hund – – – ▶ Tierarzt |
| Aggregation | Lockere Teil-Ganzes-Beziehung; Teile existieren auch ohne das Ganze. Weiße Raute. | Hund ◇── Halsband |
| Komposition | Starke Teil-Ganzes-Beziehung; Teile existieren nicht ohne das Ganze. Schwarze Raute. | Hund ◆── Herz |
⚠️ Stolpersteine
- Vererbung: einen ausgefüllten (schwarzen) statt hohlen Pfeilkopf zeichnen.
- Assoziation: mit Abhängigkeit verwechseln – entscheidend ist: dauerhaft gespeichert oder nur kurz genutzt?
- Abhängigkeit: die gestrichelte Linie vergessen – sieht dann aus wie eine normale (dauerhafte) Assoziation.
- Aggregation: weiße und schwarze Raute verwechseln – dreht die Existenzabhängigkeit ins Gegenteil um.
- Komposition: denken, eine Multiplizität wie 0..* mache sie automatisch zur Aggregation – die Raute allein entscheidet.
7. Multiplizitäten
| Name | Beschreibung | Beispiel |
|---|---|---|
| Kann-Beziehung | Beginnt mit 0 – die Beziehung ist optional. | Hund ──── Spielzeug 0..* |
| Muss-Beziehung | Beginnt mit 1 – mindestens ein Objekt ist erforderlich. | Hund ──── Mikrochip 1 |
| Beliebiger Bereich | UML erlaubt beliebige Wertebereiche, nicht nur 1/n wie im ER-Modell. | 2..5, 1..*, 0..1 … |
⚠️ Stolpersteine
- Kann-Beziehung: die führende 0 vergessen und dadurch versehentlich eine Pflichtbeziehung modellieren.
- Muss-Beziehung: die „1“ als „genau einmal im Leben“ statt als „zu jedem Zeitpunkt mindestens eins“ lesen.
- Beliebiger Bereich: denken, UML sei wie ER-Modelle auf 1 und n beschränkt – UML erlaubt beliebige Zahlen und Bereiche.
💡 Merksatz
Ein UML-Klassendiagramm besteht aus Klassen (mit Attributen und Methoden), Sichtbarkeiten, und Beziehungen zwischen Klassen. Die meisten Fehler entstehen an denselben Stellen: vertauschte Pfeilrichtungen, verwechselte Rautenfarben und vergessene gestrichelte Linien. Wer diese Tabelle im Kopf hat, hat die häufigsten Stolpersteine bereits im Blick.