Use-Case-Diagramm
Online-Bibliothek
Szenario: Eine Stadtbibliothek möchte ihr Ausleihsystem digitalisieren.
Anforderungen:
- Benutzer können Bücher suchen und ausleihen
- Vor jeder Ausleihe muss sich der Benutzer zwingend anmelden
- Der Benutzer kann bei Bedarf eine Verlängerung beantragen
- Bibliothekare können zusätzlich Bücher zurückbuchen und Mahnungen versenden
✅ Musterlösung:
Wichtige Punkte (UML 2.5.1):
- Primärakteur (links): Benutzer initiiert die Interaktion
- Sekundärakteur (rechts): Bibliothekar unterstützt das System
- «include»: Gestrichelt + offene Spitze → ZUM eingebundenen UC (Anmelden ist IMMER nötig)
- «extend»: Gestrichelt + offene Spitze → ZUM Basis-UC (Verlängerung ist OPTIONAL)
- Kein Akteur am extend-UC! Der Benutzer greift über den Basis-UC ("Buch ausleihen") auf die Verlängerung zu — KEINE direkte Assoziation zum extending UC
- Assoziation: Durchgezogen OHNE Pfeilspitze
UML 2.5.1 Hinweis
Vereinfachtes «extend»: Diese Darstellung zeigt nur die Beziehung ohne Details. Nach UML 2.5.1 sollte entweder ein Extension Point (EP) im Basis-UC oder eine Condition [...] angegeben werden. Für die vollständige, prüfungskonforme Notation siehe Aufgabe 3 (Geldautomat mit Extension Points).
E-Learning mit Generalisierung
Szenario: E-Learning-Plattform mit Akteur-Generalisierung.
Anforderungen:
- Abstrakter Akteur "Benutzer" mit Kursmaterial ansehen
- Studierender und Dozent erben von Benutzer
- Studierender kann Aufgabe abgeben
- Dozent kann Kurs erstellen (dabei muss immer Material hochgeladen werden) und Note vergeben
✅ Musterlösung:
Wichtige Punkte (UML 2.5.1):
- Abstrakter Akteur: Gestrichelte Linien + «abstract» + kursiver Name
- Generalisierung: Durchgezogene Linie + LEERES Dreieck △ → zum Allgemeinen
- Vererbte Assoziationen: Studierender und Dozent erben "Kursmaterial ansehen"
- «include»: "Kurs erstellen" bindet IMMER "Material hochladen" ein
Geldautomat mit Extension Points
Szenario: Ein Geldautomat mit optionalen Erweiterungen und bedingten Abläufen.
Anforderungen:
- Kunde kann Geld abheben
- Beim Abheben muss IMMER die PIN geprüft werden
- Der Kunde kann auf Wunsch eine Quittung drucken lassen
- Bei Beträgen über 500€ erfolgt eine zusätzliche Sicherheitsabfrage
- Kunde kann Kontostand abfragen
- Auch beim Kontostand ist die PIN-Prüfung erforderlich
Hinweis: Verwende Extension Points und Notizzettel-Notation!
✅ Musterlösung:
Wichtige Punkte (UML 2.5.1):
- Extension Points im Use Case: Unter Trennlinie, mit sprechenden Namen (quittungMöglich, hoherBetrag)
- Notizzettel (Note): Rechteck mit Eselsohr, per gestrichelter Linie am «extend»-Pfeil
- condition: Gibt an WANN die Erweiterung ausgeführt wird
- ext.point: Referenziert den Extension Point im Basis-UC (WO wird erweitert)
- «include» wiederverwendet: Beide Haupt-UCs nutzen "PIN prüfen"
IHK-Prüfungstipp
Extension Point Namen: Kurz, prägnant, camelCase oder mit Unterstrich
Notizzettel: Immer condition UND extension point angeben für Vollständigkeit
Farben: Include-UCs oft grün, Extend-UCs oft orange (zur Unterscheidung)
Ticket-Reservierung
Szenario: Ein Kino bietet Online-Ticketreservierung an.
Anforderungen:
- Kunden können Filme suchen und Tickets reservieren
- Vor der Reservierung muss der Kunde eingeloggt sein
- Nach der Reservierung kann der Kunde optional Snacks vorbestellen
- Mitarbeiter können Reservierungen stornieren und Rückerstattungen veranlassen
- Bei Rückerstattung muss immer storniert werden
✅ Musterlösung:
Wichtige Punkte (UML 2.5.1):
- «include» (Ticket → Einloggen): Kunde MUSS eingeloggt sein
- «include» (Rückerstattung → Stornieren): Rückerstattung erfordert IMMER Stornierung
- «extend» (Snacks → Ticket): Snacks sind OPTIONAL nach Reservierung
- Pfeilrichtungen: include → ZUM Eingebundenen | extend → ZUM Basis-UC
UML-Hinweis
Vereinfachtes «extend»: Hier ohne Condition/Extension Point dargestellt. Vollständige Notation würde angeben: "condition: {möchte Snacks}" und Extension Point im Basis-UC.
Klassendiagramm
Online-Shop
Szenario: Datenmodell für die Produktverwaltung eines Online-Shops.
Anforderungen:
- Produkte (id, name, preis) sind jeweils einer Kategorie zugeordnet
- Eine Kategorie enthält beliebig viele Produkte
- Kunden können Bewertungen (sterne, kommentar) zu Produkten abgeben
- Ein Produkt kann mehrere Bewertungen haben
✅ Musterlösung:
Wichtige Punkte:
- Drei-Kammer: Name | Attribute | Methoden
- Sichtbarkeit: - private, + public, # protected
- Multiplizität: An beiden Enden der Assoziation
Fahrzeugverwaltung
Szenario: Ein Fuhrparkmanagement-System für verschiedene Fahrzeugtypen.
Anforderungen:
- Es gibt eine allgemeine Fahrzeug-Klasse mit kennzeichen und marke (protected)
- PKW und LKW sind spezielle Fahrzeugtypen mit eigenen Attributen
- Fahrzeuge können einem Standort zugewiesen werden
- Fahrzeuge können aber auch ohne Standort existieren (z.B. unterwegs)
✅ Musterlösung:
Wichtige Punkte:
- Abstrakte Klasse: «abstract» + kursiver Name + kursive Methoden
- Vererbung: Durchgezogene Linie mit LEEREM Dreieck △ zur Oberklasse
- Aggregation: LEERE Raute ◇ am "Ganzen" (Standort)
- Protected: # = von Unterklassen zugreifbar
Restaurant-Bestellsystem
Szenario: Datenmodell für die Bestellverwaltung in einem Restaurant.
Anforderungen:
- Kellner nehmen Bestellungen auf (1 Kellner, mehrere Bestellungen)
- Jede Bestellung enthält mindestens eine Bestellposition
- Bestellpositionen gehören fest zu einer Bestellung - werden gelöscht, wenn die Bestellung gelöscht wird
- Jede Bestellposition verweist auf ein Gericht aus der Speisekarte
✅ Musterlösung:
Wichtige Punkte:
- Komposition (◆): GEFÜLLTE Raute am "Ganzen" (Bestellung)
- Bedeutung: Bestellpositionen können NICHT ohne Bestellung existieren
- Unterschied: Aggregation ◇ (Teil lebt weiter) vs. Komposition ◆ (Teil stirbt mit)
- Multiplizität 1..*: Mindestens eine Bestellposition pro Bestellung
Sequenzdiagramm
Online-Banking Überweisung
Szenario: Ein Kunde führt eine Online-Überweisung durch. Das System muss die Deckung prüfen.
Anforderungen:
- Beteiligte Objekte: Kunde, WebInterface, Überweisungsservice, Konto
- Der Kunde startet die Überweisung über das WebInterface
- Der Überweisungsservice prüft die Deckung beim Konto
- Nach erfolgreicher Prüfung erhält der Kunde eine Bestätigung
✅ Musterlösung:
Wichtige Punkte (UML 2.5.1):
- Synchrone Nachricht: Durchgezogen + GEFÜLLTES Dreieck (▶)
- Rückgabe: GESTRICHELT + OFFENE Spitze (>)
- Keine Nummerierung nötig! Die zeitliche Reihenfolge ergibt sich aus der Leserichtung (oben → unten)
Nicht verwechseln: Sequenz- vs. Kommunikationsdiagramm
Im Kommunikationsdiagramm (ehem. Kollaborationsdiagramm) sind Nachrichten nummeriert (1:, 1.1:, 2: …), weil die räumliche Anordnung dort KEINE zeitliche Ordnung zeigt. Im Sequenzdiagramm ergibt sich die Reihenfolge automatisch aus der vertikalen Position — Nummerierung wäre hier redundant.
Login mit Alternativen
Szenario: Ein Benutzer meldet sich an. Je nach Ergebnis gibt es unterschiedliche Abläufe.
Anforderungen:
- Beteiligte Objekte: Benutzer, LoginController, Datenbank
- Der Benutzer gibt seine Credentials ein
- Die Datenbank prüft die Credentials
- Bei gültigen Credentials: Erfolgsseite anzeigen
- Bei ungültigen Credentials: Fehlermeldung anzeigen
✅ Musterlösung:
Wichtige Punkte:
- alt-Fragment: Alternative Abläufe (if-else)
- Guard [Bedingung]: Steuert den Pfad
- Weitere: opt (optional), loop (Schleife), par (parallel)
Aktivitätsdiagramm
Online-Bestellprozess
Szenario: Ein Kunde bestellt in einem Online-Shop Artikel.
Anforderungen:
- Der Kunde wählt Artikel aus und legt sie in den Warenkorb
- Am Warenkorb kann der Kunde entweder weiter shoppen oder zur Kasse gehen
- An der Kasse gibt der Kunde Adresse und Zahlungsdaten ein - diese können gleichzeitig erfolgen
- Nach Eingabe aller Daten wird die Bestellung abgeschlossen
✅ Musterlösung:
Wichtige Punkte:
- Start: ● | Ende: ◉
- Merge-Raute (◇): Führt Start und [ja]-Schleifenpfad zusammen
- Entscheidung (◇): "weiter?" mit [ja]/[nein] Guards
- Fork (▬): Startet parallele Pfade (Adresse + Zahlung)
- Join (▬): Synchronisiert parallele Pfade
- Regel: Jede Entscheidungs-Raute braucht eine Merge-Raute!
Reklamationsprozess
Szenario: Ein Kunde reklamiert ein defektes Produkt. Verschiedene Abteilungen sind involviert.
Anforderungen:
- Beteiligte Abteilungen: Kunde, Kundenservice, Lager
- Der Kunde meldet die Reklamation
- Der Kundenservice prüft die Berechtigung
- Bei berechtigter Reklamation: Kunde kann zwischen Umtausch und Erstattung wählen
- Bei unberechtigter Reklamation: Ablehnung
✅ Musterlösung:
Wichtige Punkte:
- Swimlanes: Zeigen WER die Aktivität ausführt
- 2 Entscheidungen → 2 Merge-Rauten:
- ◇ "Wunsch?" → ◇ Merge 1 (Rückzahlung + Ersatz)
- ◇ "berechtigt?" → ◇ Merge 2 (Ablehnung + [ja]-Pfad)
- Regel: Jede Entscheidungs-Raute braucht ihre eigene Merge-Raute!
Zustandsdiagramm
Bestellung - Lebenszyklus
Szenario: Eine Online-Bestellung durchläuft verschiedene Zustände von der Erstellung bis zur Zustellung.
Anforderungen:
- Eine neue Bestellung wird nach Zahlungseingang als bezahlt markiert
- Bezahlte Bestellungen werden bearbeitet, dann versendet und schließlich zugestellt
- Neue Bestellungen können storniert werden
- Bezahlte Bestellungen können auch storniert werden - dabei muss eine Rückerstattung erfolgen
✅ Musterlösung:
Wichtige Punkte:
- Übergang: Ereignis [Guard] / Aktion
- / Aktion: Wird beim Übergang ausgeführt
- Zwei Endknoten ◉: UML erlaubt mehrere Endknoten! Hier endet der Lebenszyklus entweder durch Zustellung oder durch Stornierung
Mehrere Endknoten im Zustandsdiagramm
Anders als beim Aktivitätsdiagramm (ein Endknoten empfohlen) sind im Zustandsdiagramm mehrere Endknoten (FinalState) üblich und UML-konform. Jeder Endknoten repräsentiert ein anderes Terminierungsszenario des Objekts (z.B. erfolgreich zugestellt vs. storniert).
Ampelsteuerung
Szenario: Eine Verkehrsampel mit verschiedenen Phasen und Aktionen für Fußgänger.
Anforderungen:
- Die Ampel durchläuft die Phasen: Rot → Rot-Gelb → Grün → Gelb → Rot
- Bei Rot: Fußgängerampel auf Grün schalten (beim Eintreten) und auf Rot (beim Verlassen)
- Bei Grün: Kontinuierlich den Verkehr überwachen
- Die Phasenwechsel werden durch Timer-Ereignisse ausgelöst
- Die Ampel kann jederzeit ausgeschaltet werden (Endzustand)
✅ Musterlösung:
Wichtige Punkte:
- entry /: Beim Eintritt ausführen
- exit /: Beim Verlassen ausführen
- do /: Während des Zustands (unterbrechbar)
- Endzustand: "Aus" → Endknoten ◉
Übergangsbeschriftung:
Ereignis [Guard] / Aktion - alle drei Teile sind optional!