Mit Google fortfahren
UML einfach erklärt: Diagramme lesen und erstellen
Die Unified Modeling Language (UML) ist eine standardisierte grafische Sprache für Modelle. Mit ihr beschreibst du ausgewählte Strukturen und Abläufe eines Systems, bevor oder während du es programmierst. UML ist weder eine Programmiersprache noch ein festes Vorgehensmodell.
Auf dieser Seite lernst du, für eine Frage ein passendes Diagramm auszuwählen, ein Klassendiagramm aus Anforderungen zu entwickeln und eine Interaktion als Sequenzdiagramm zu beschreiben.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Welches UML-Diagramm beantwortet deine Frage?
Ein Modell bildet nur die Merkmale eines Systems ab, die für eine bestimmte Frage wichtig sind. Deshalb zeichnest du nicht automatisch das gesamte System. Du entscheidest zuerst, was andere am Diagramm erkennen sollen.
UML umfasst 14 Diagrammarten. Für den Einstieg reichen häufig diese sechs:
| Frage | Passendes Diagramm |
|---|---|
| Welche Klassen gibt es und wie hängen sie zusammen? | Klassendiagramm |
| Aus welchen groben Softwarebausteinen besteht das System? | Komponentendiagramm |
| Welche Software läuft auf welcher Hardware? | Verteilungsdiagramm |
| Was möchte ein Akteur mit dem System erreichen? | Anwendungsfalldiagramm |
| Welche Aktionen, Entscheidungen und Wege gibt es? | Aktivitätsdiagramm |
| Wer sendet wann welche Nachricht? | Sequenzdiagramm |
Strukturdiagramme zeigen vor allem statische Bestandteile und Beziehungen. Verhaltensdiagramme zeigen Abläufe oder Zustandsänderungen. Interaktionsdiagramme wie das Sequenzdiagramm bilden eine besondere Gruppe für den Austausch zwischen Beteiligten.
Beginne nicht mit Kästchen und Pfeilen, sondern mit einer Frage. Ein kleines, zweckgebundenes Diagramm ist oft verständlicher als ein vollständiges, aber überladenes Modell.
Wie liest du eine Klasse?
Eine Klasse beschreibt gleichartige Objekte mit gemeinsamen Merkmalen und gemeinsamem Verhalten. Ein Objekt ist eine konkrete Instanz dieser Klasse mit eigener Identität und konkreten Attributwerten.
Ein Klassenrechteck kann drei Bereiche enthalten:
- den Klassennamen,
- die Attribute,
- die Operationen.
Ein Attribut speichert eine Eigenschaft oder einen Zustand. Eine Operation beschreibt eine angebotene Handlung. Bei der Programmierung wird eine Operation meist durch eine Methode umgesetzt.
Die wichtigsten Sichtbarkeitssymbole sind:
| Symbol | Bedeutung |
|---|---|
+ | öffentlich zugänglich (public) |
- | nur innerhalb der Klasse zugänglich (private) |
# | auch für Unterklassen zugänglich (protected) |
~ | innerhalb des Pakets zugänglich (package) |
Für ein Bibliothekssystem könnte eine Klasse textlich so notiert werden:
Buch
- titel: Text- ausgeliehen: Wahrheitswert+ ausleihen(): Wahrheitswert+ zurückgeben()
titel und ausgeliehen sind Attribute. ausleihen() und zurückgeben() sind Operationen. Das Minuszeichen schützt die Attribute vor direktem Zugriff von außen; das Pluszeichen kennzeichnet öffentlich nutzbare Operationen.
Das konkrete Objekt meinBuch: Buch könnte den Titel „Tschick“ und den Zustand ausgeliehen = wahr besitzen. Klasse und Objekt sind also nicht dasselbe: Die Klasse ist die Beschreibung, das Objekt eine konkrete Ausprägung.
Eine abstrakte Klasse fasst gemeinsame Merkmale für Unterklassen zusammen, wird aber nicht selbst instanziiert. Eine Schnittstelle legt einen ausgewählten, von außen sichtbaren Teil des Verhaltens fest. Eine Klasse kann mehrere Schnittstellen implementieren.
Wie unterscheiden sich Beziehungen und Multiplizitäten?
Eine Linie zwischen Klassen hat nicht immer dieselbe Bedeutung. Wähle die speziellere Beziehung nur, wenn die Anforderung ihre Bedeutung wirklich trägt.
Assoziation
Eine Assoziation ist eine allgemeine fachliche Beziehung zwischen Klassen. Rollen benennen die Funktion der Beteiligten. Ein Navigationspfeil kann zeigen, in welcher Richtung ein Objekt auf das andere zugreifen kann.
Aggregation und Komposition
Eine Aggregation beschreibt eine lockere Teil-Ganzes-Beziehung. Die leere Raute steht am Ganzen; ein Teil kann unabhängig vom Ganzen weiterbestehen.
Eine Komposition beschreibt eine starke, exklusive Teil-Ganzes-Beziehung. Die ausgefüllte Raute steht am Ganzen. Ein konkretes Teil gehört höchstens zu einem solchen Ganzen und ist von dessen Lebenszyklus abhängig.
Generalisierung
Eine Generalisierung beschreibt eine „Ist-ein“-Beziehung. Die Unterklasse erbt Merkmale der allgemeineren Oberklasse und kann sie ergänzen oder überschreiben. Der hohle Pfeil zeigt von der Unterklasse zur Oberklasse.
In einem Schulportal gelten folgende Anforderungen:
- Ein
Kurshat angemeldeteSchülerkonto-Objekte. Das ist zunächst eine Assoziation. - Ein
Kursraumenthält fest zugehörigeBeitrag-Objekte, die mit ihm gelöscht werden. Das kann als Komposition modelliert werden. LehrerkontoundSchülerkontosind besondere Arten vonBenutzerkonto. Das ist eine Generalisierung.
Eine Aggregation wäre nur dann passend, wenn eine echte Teil-Ganzes-Aussage gemeint ist und die Teile unabhängig fortbestehen. Eine bloße Zusammenarbeit zweier Klassen reicht dafür nicht.
Eine Multiplizität gibt an, wie viele Objekte an einem Ende einer Beziehung möglich sind:
| Schreibweise | Bedeutung |
|---|---|
1 | genau eins |
0..1 | kein oder ein Objekt |
* oder 0..* | beliebig viele, auch keines |
1..* | mindestens eins |
3..7 | mindestens drei, höchstens sieben |
Lies die Multiplizität immer an dem Ende, dessen mögliche Anzahl du bestimmen möchtest.
Anforderung: „Jedes Buch gehört genau zu einem Verlag. Ein Verlag veröffentlicht kein, ein oder mehrere Bücher.“
Daraus folgt:
- Am Ende
Verlagsteht aus Sicht eines Buches1. - Am Ende
Buchsteht aus Sicht eines Verlages0..*.
Die Multiplizität beschreibt die erlaubte Anzahl. Die tatsächlich vorhandene Anzahl in einem konkreten Zustand kann innerhalb dieses Bereichs liegen.
Wie entwickelst du ein Klassendiagramm aus Anforderungen?
Unterstreiche nicht einfach jedes Substantiv und mache daraus eine Klasse. Prüfe stattdessen, welche Verantwortung ein Begriff im System besitzt.
Gehe in fünf Schritten vor:
- Zweck festlegen: Formuliere die Frage, die das Modell beantworten soll.
- Klassenkandidaten suchen: Achte auf fachliche Objekte mit eigener Identität, Zustand oder Verantwortung.
- Merkmale zuordnen: Formuliere Eigenschaften als Attribute und Verhalten als Operationen.
- Beziehungen bestimmen: Entscheide über Beziehungstyp, Rollen und Multiplizitäten.
- Szenarien prüfen: Spiele konkrete Fälle durch und korrigiere fehlende oder widersprüchliche Stellen.
Anforderung: „Mitglieder einer Bibliothek können Bücher ausleihen. Ein Exemplar gehört genau zu einem Buch. Ein Mitglied kann gleichzeitig höchstens fünf Exemplare ausgeliehen haben. Zu jeder Ausleihe werden Ausleihdatum und Fälligkeitsdatum gespeichert.“
Schritt 1 – Zweck: Das Modell soll zeigen, wie Ausleihen verwaltet werden.
Schritt 2 – Klassen: Mitglied, Buch, Exemplar und Ausleihe besitzen eigene fachliche Aufgaben. Ausleihdatum ist dagegen ein Wert und daher ein Attribut.
Schritt 3 – Merkmale:
Mitglied: etwamitgliedsnummerBuch: etwatitelExemplar: etwainventarnummerAusleihe:ausleihdatum,fälligkeitsdatum
Schritt 4 – Beziehungen:
- Jedes
Exemplargehört zu genau1Buch. Wie viele Exemplare einBuchhaben darf, steht nicht in der Anforderung. Sind auch Bücher ohne Exemplar erlaubt, steht am EndeExemplardie Multiplizität0..*; andernfalls musst du die Untergrenze klären. - Ein
Mitgliedhat0..5aktuelle Ausleihen; jedeAusleihegehört zu genau1Mitglied. - Jede
Ausleihebetrifft genau1Exemplar.
Ausleihe ist eine eigene Klasse, weil Datum und Fälligkeit zur Verbindung eines bestimmten Mitglieds mit einem bestimmten Exemplar gehören.
Schritt 5 – Prüfung: Ein neues Mitglied ohne Ausleihe ist erlaubt. Die sechste gleichzeitige Ausleihe ist nicht erlaubt. Für eine Ausleihe muss genau ein Exemplar bekannt sein.
Wähle in jeder Lücke die passende Form und prüfe anschließend deine Antworten.
Ein fachliches Ding mit eigener Identität ist häufig eine . Eine gespeicherte Eigenschaft wird als modelliert. Die Angabe 0..5 ist eine . Daten, die zu einer Verbindung gehören, können eine begründen.
Wie prüfst du ein Modell mit Szenarien?
Ein formal aussehendes Diagramm kann fachlich trotzdem falsch sein. Teste es deshalb mit konkreten Szenarien, also beispielhaften Nutzungsfällen.
Für jedes Szenario fragst du:
- Lassen sich alle benötigten Objekte anlegen?
- Erlauben die Multiplizitäten den Fall?
- Ist klar, welches Objekt für eine Handlung verantwortlich ist?
- Fehlt ein Attribut oder eine Beziehung?
- Erlaubt das Modell einen fachlich verbotenen Zustand?
Prüfe das Bibliotheksmodell an drei Fällen:
- Neues Mitglied ohne Ausleihe:
0..5Ausleihen erlaubt den Fall. - Ein Mitglied leiht fünf Exemplare aus: Die Obergrenze 5 erlaubt den Fall.
- Ein Mitglied möchte ein sechstes Exemplar ausleihen: Das Modell weist auf einen unzulässigen Zustand hin.
Angenommen, im Diagramm stünde stattdessen 1..5. Dann wäre schon ein neues Mitglied ohne Ausleihe verboten. Das Szenario deckt den Modellfehler auf; die Untergrenze muss 0 sein.
Ein gutes Modell bildet nicht nur typische Erfolgsfälle ab. Prüfe auch leere Zustände, Grenzwerte und unerlaubte Fälle.
Wie beschreibst du den zeitlichen Nachrichtenaustausch?
Ein Klassendiagramm zeigt, welche Struktur möglich ist. Ein Sequenzdiagramm zeigt dagegen, wie Beteiligte in einem konkreten Szenario zeitlich zusammenarbeiten.
Die Beteiligten stehen nebeneinander. Von ihnen führen Lebenslinien nach unten. Nachrichten werden als waagerechte Pfeile dargestellt und von oben nach unten gelesen. Eine synchrone Nachricht wartet auf eine Antwort; eine asynchrone Nachricht blockiert den Sender nicht auf diese Weise.
Gehe so vor:
- Wähle genau ein Szenario, zum Beispiel „Exemplar ausleihen“.
- Bestimme die beteiligten Akteure und Objekte.
- Ordne die Nachrichten zeitlich.
- Benenne jede Nachricht mit einer konkreten Absicht oder Operation.
- Prüfe, ob die Empfänger die benötigte Verantwortung im Klassenmodell besitzen.
Szenario: Ein Mitglied leiht ein verfügbares Exemplar aus.
Beteiligte: Mitglied, Ausleihoberfläche, Ausleihdienst, Exemplar.
Zeitliche Folge:
Mitgliedsendetausleihen(exemplarnummer)an dieAusleihoberfläche.- Die
AusleihoberflächesendetausleihePrüfen(...)an denAusleihdienst. - Der
Ausleihdienstfragt beimExemplarmitistVerfügbar()nach. - Das
Exemplarliefert den Verfügbarkeitszustand zurück. - Bei verfügbarem Exemplar erzeugt der
Ausleihdienstdie Ausleihe. - Die
Ausleihoberflächemeldet dem Mitglied den Erfolg.
Das Sequenzdiagramm ergänzt das Klassenmodell: Wenn istVerfügbar() im Ablauf benötigt wird, sollte eine passende Verantwortung im Strukturmodell erkennbar sein.
Ein Sequenzdiagramm stellt einen bestimmten Pfad dar. Ein Erfolgsfall und ein Fehlerfall wie „Exemplar bereits ausgeliehen“ können getrennt modelliert werden, damit der Ablauf lesbar bleibt.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- UML-Modell
- beantwortet eine konkrete Frage
- Klassendiagramm zeigt Struktur
- Klasse enthält Attribute und Operationen
- Beziehungen erhalten Typ und Multiplizität
- Szenarien prüfen erlaubte und verbotene Fälle
- Sequenzdiagramm zeigt zeitliche Nachrichten
- Verständlichkeit verlangt einen begrenzten Ausschnitt
Abschluss-Check
Du kannst ein UML-Modell jetzt zielgerichtet entwickeln: Frage festlegen, passenden Diagrammtyp wählen, Begriffe und Beziehungen präzise modellieren und das Ergebnis an konkreten Szenarien prüfen.