📝 UML Übungsaufgaben

13 praxisnahe Aufgaben (UML 2.5.1 konform)

0 von 13 Übungen abgeschlossen

🎭 Use-Case-Diagramm

1 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:

Bibliothekssystem Benutzer (primär) Bibliothekar (sekundär) Buch suchen Buch ausleihen Anmelden Verlängerung beantragen Zurückbuchen Mahnung senden «include» «extend»

✨ 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).

2 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:

E-Learning-Plattform «abstract» Benutzer Studierender Dozent Kursmaterial ansehen Aufgabe abgeben Kurs erstellen Note vergeben Material hochladen «include»

✨ 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

3 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:

Geldautomat Kunde Geld abheben extension points quittungMöglich hoherBetrag PIN prüfen Kontostand abfragen Quittung drucken Zusätzliche Sicherheitsabfrage «include» «include» «extend» condition: {wünscht Beleg} ext.point: quittungMöglich «extend» condition: {Betrag > 500€} ext.point: hoherBetrag

✨ 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)

4 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:

Kino-Reservierungssystem Kunde (primär) Mitarbeiter (sekundär) Film suchen Ticket reservieren Einloggen Snacks vorbestellen Reservierung stornieren Rückerstattung «include» «include» «extend»

✨ 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

1 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:

Kategorie - id: int - name: String + getName(): String Produkt - id: int - name: String - preis: double + getPreis(): double Kunde - kundennr: int - name: String - email: String Bewertung - sterne: int - kommentar: String + getSterne(): int 1 * 1 * 1 *

✨ Wichtige Punkte:

  • Drei-Kammer: Name | Attribute | Methoden
  • Sichtbarkeit: - private, + public, # protected
  • Multiplizität: An beiden Enden der Assoziation

2 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:

«abstract» Fahrzeug # kennzeichen: String # marke: String + starten(): void Standort - adresse: String - kapazitaet: int PKW - anzahlSitze: int + getSitze(): int LKW - ladekapazitaet: double + beladen(kg: double) * 1

✨ 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

3 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:

Kellner - personalNr: int - name: String Bestellung - bestellNr: int - datum: Date - gesamtpreis: double + getTotal(): double Bestellposition - menge: int - einzelpreis: double + getSubtotal(): double Gericht - id: int - name: String - preis: double 1 * 1 1..* * 1

✨ 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

1 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:

:Kunde :WebInterface :Überweisungsservice :Konto überweisungStarten(daten) prüfeÜberweisung() prüfeDeckung(betrag) deckungOK bestätigung zeigeErgebnis() anzeige

✨ 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.

2 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:

:Benutzer :LoginController :Datenbank login(user, pass) prüfeCredentials() result alt [gültig] loginErfolgreich() [ungültig] loginFehlgeschlagen()

✨ Wichtige Punkte:

  • alt-Fragment: Alternative Abläufe (if-else)
  • Guard [Bedingung]: Steuert den Pfad
  • Weitere: opt (optional), loop (Schleife), par (parallel)

🔄 Aktivitätsdiagramm

1 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:

Artikel auswählen In Warenkorb legen weiter? [ja] [nein] Adresse eingeben Zahlung wählen Bestellung abschließen

✨ 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!

2 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:

Kunde Kundenservice Lager Reklamation melden Berechtigung prüfen berechtigt? [nein] Ablehnung erhalten [ja] Wunsch? [erstattung] Rückzahlung [umtausch] Ersatz versenden

✨ 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

1 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:

Neu Bezahlt In Bearbeitung Versendet Zugestellt Storniert zahlung_ok bearbeiten versenden zugestellt stornieren stornieren / rückerstattung()

✨ 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).

2 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:

Rot entry / fußgängerGrün() exit / fußgängerRot() Rot-Gelb Grün do / überwacheVerkehr() Gelb timer(30s) timer(2s) timer(25s) timer(3s) Aus ausschalten (ausschalten von jedem Zustand möglich)

✨ 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!