Use-Case-Diagramm
In Lektion 1 haben wir gelernt, dass funktionale Anforderungen beschreiben, was das System tun soll. Aber wie bringt man dutzende oder hunderte solcher Anforderungen in eine übersichtliche, kommunizierbare Form? Eines der wichtigsten Werkzeuge ist das Use-Case-Diagramm – ein Diagrammtyp aus der UML (Unified Modeling Language).
Use-Case-Diagramme sind extrem populär in der deutschen IT-Ausbildung und in IHK-Prüfungen – aus gutem Grund: sie sind einfach zu lesen, kommen mit nur 4–5 Symbolen aus, und zeigen auf einen Blick, wer mit dem System interagiert und was er damit tut. Diese Lektion lehrt dich, sie zu lesen, zu zeichnen und in Klausuraufgaben zu verwenden.
1) Was ist ein Use-Case?
Ein Use-Case (deutsch: Anwendungsfall) beschreibt eine zusammenhängende Interaktion zwischen einem externen Akteur und dem System, die für den Akteur einen erkennbaren Nutzen erzeugt. Beispiel: „Buch bestellen" – mehrere Schritte vom Login bis zur Bezahlung, aber für den Kunden ein zusammenhängender Vorgang mit klarem Ergebnis.
Ein Use-Case beantwortet drei Fragen: Wer macht etwas? Was macht er? Welches Ergebnis bekommt er? Im Diagramm wird das visualisiert. Die Detail-Beschreibung – Vorbedingungen, Ablauf, Ausnahmen – wird in einer ergänzenden Textform (Use-Case-Spezifikation) festgehalten.
2) Die fünf Grundsymbole
Bevor wir komplette Diagramme bauen, hier die Symbol-Galerie. Ein Use-Case-Diagramm braucht nur fünf Elemente – das macht es so zugänglich:
3) Ein komplettes Beispiel: Webshop
Genug Theorie – schauen wir uns ein vollständiges Use-Case-Diagramm an. Stell dir einen kleinen Webshop vor mit zwei Akteurs-Rollen: Kunde und Admin. Beide nutzen unterschiedliche Funktionen:
4) Akteure: nicht jeder Mensch ist ein Akteur
Ein häufiges Missverständnis: ein Akteur ist nicht eine Person, sondern eine Rolle. Eine Person kann mehrere Rollen einnehmen, dieselbe Rolle können viele Personen ausfüllen. Wenn Hans privat im Shop einkauft, ist er „Kunde". Wenn er im selben System als IT-Mitarbeiter Datenpflege macht, ist er „Admin". Im Diagramm ist Hans dann zwei Akteure – nicht weil er zwei Personen ist, sondern weil er zwei Rollen einnimmt.
Akteure sind außerdem nicht nur Menschen. Andere Software, Hardware, Zeitgeber (Cronjobs!) und externe Schnittstellen sind ebenfalls Akteure. Im Beispiel oben ist der Bezahldienst ein externer Akteur. Klassisch kennzeichnet man solche „nicht-menschlichen" Akteure mit dem Stereotyp «system», «external» oder «time».
5) Beziehungen zwischen Use-Cases: include, extend, generalize
Use-Cases können nicht nur mit Akteuren verbunden sein, sondern auch untereinander. Drei Beziehungstypen sind UML-Standard und IHK-prüfungsrelevant:
Bestellung aufgeben «include» Anmelden – ohne Anmelden keine Bestellung. Wiederverwendung von gemeinsamen Schritten.Bestellung aufgeben kann durch Gutscheincode einlösen erweitert werden – aber nicht zwingend. Bei optionalen oder Spezialfällen.Bezahlen kann generalisiert werden in Per Kreditkarte bezahlen und Per PayPal bezahlen. Auch bei Akteuren: Kunde generalisiert Premium-Kunde.6) Use-Case textuell beschreiben
Das Diagramm zeigt nur die Übersicht. Die Details eines Use-Cases werden in einer textuellen Use-Case-Spezifikation festgehalten. Es gibt verschiedene Schablonen – hier eine bewährte Form, die sich in Praxis und Klausur gut macht:
| Name | Bestellung aufgeben |
|---|---|
| Akteur | Kunde (primär), Bezahldienst (sekundär) |
| Ziel | Eine Bestellung wird angelegt und ist bezahlt. |
| Vorbedingung | Kunde ist angemeldet. Mindestens 1 Produkt im Warenkorb. |
| Nachbedingung | Bestellung ist im System gespeichert, Bestätigungs-Mail wurde versendet. |
| Normaler Ablauf | 1. Kunde öffnet den Warenkorb 2. System zeigt Übersicht der Produkte mit Gesamtpreis 3. Kunde klickt „zur Kasse" 4. System fragt Lieferadresse ab 5. Kunde wählt Zahlungsmethode 6. System leitet zum Bezahldienst weiter 7. Bezahldienst bestätigt Zahlung 8. System speichert Bestellung 9. System sendet Bestätigungs-Mail an Kunden |
| Alternative Abläufe | A1 (Schritt 6): Bezahldienst antwortet nicht → System zeigt Fehlermeldung, Bestellung bleibt offen A2 (Schritt 7): Zahlung abgelehnt → System zeigt Hinweis, Kunde kann andere Methode wählen |
| Auslöser | Kunde klickt „Bestellen" im Warenkorb. |
| Häufigkeit | Ca. 500-mal täglich (Erwartung) |
7) Use-Case-Diagramm in der Praxis erstellen
Wie geht man konkret vor, wenn man aus einer Liste von Anforderungen ein Use-Case-Diagramm baut? Hier ein bewährter Prozess in fünf Schritten:
8) Granularität: nicht zu viel, nicht zu wenig
Eine der häufigsten Fragen: wie groß soll ein Use-Case sein? Zu klein (z.B. „Passwort eingeben") führt zu unübersichtlichen Diagrammen mit 50+ Bubbles. Zu groß (z.B. „Webshop bedienen") sagt nichts aus.
Faustregeln für gute Granularität:
- Sichtbarer Nutzen: der Use-Case sollte für den Akteur ein erkennbares Ergebnis liefern. „Bestellung aufgeben" → Ergebnis: bestellt. „Auf Button klicken" → kein erkennbares Ergebnis.
- Eine Sitzung: ein Use-Case ist meist das, was eine Person in einer durchgehenden Interaktion erledigt – Minuten bis Stunden, nicht Sekunden.
- Aktiv formulieren: Verb + Objekt. „Bestellung aufgeben", nicht „Bestellung" oder „Bestellsystem".
- Faustzahl: ein Use-Case-Diagramm sollte typischerweise 5–15 Use-Cases haben. Mehr → in mehrere Diagramme aufteilen (z.B. ein Diagramm pro Subsystem).
9) Häufige Fehler in Klausuren
Typische Stolperfallen, die in IHK-Klausuren Punktabzug bringen:
10) Stärken und Grenzen
Use-Case-Diagramme sind ein wunderbares Werkzeug für den Anfang – aber kein Allheilmittel. Hier eine ehrliche Bilanz:
Stärken: sehr leicht zu lesen, jeder Stakeholder versteht es. Gut für Workshops mit Fachbereich. Zeigt auf einen Blick den Umfang des Systems. Bewährter Einstieg in die UML-Welt.
Grenzen: nichts über zeitliche Abläufe, keine Datenstrukturen, keine technische Architektur, keine Geschäftsregeln. Für all das braucht es andere Diagramme – siehe Folgelektionen: Aktivitätsdiagramme (L3), Sequenzdiagramme (L4), Zustands- und Komponentendiagramme (L5).
Use-Case-Diagramme sind also der Einstieg, nicht das ganze Bild. In großen Projekten werden sie oft nur in der frühen Anforderungsphase verwendet und später durch detailliertere Modelle ergänzt.
Zusammenfassung
Das Use-Case-Diagramm ist ein UML-Diagrammtyp, der die funktionalen Anforderungen eines Systems visualisiert. Es zeigt, wer mit dem System interagiert (Akteure) und was sie damit tun (Use-Cases / Anwendungsfälle). Es ist eines der einfachsten und meistgenutzten Modelle in der deutschen IT-Ausbildung. Symbole: Strichmännchen (Akteur, eine Rolle nicht Person), Ellipse (Use-Case, mit Verb), Rechteck (Systemgrenze), Linie (Assoziation), gestrichelter Pfeil mit Stereotyp («include» / «extend»). Akteure stehen außerhalb der Systemgrenze und können Menschen oder andere Software sein («external»). Beziehungen zwischen Use-Cases: «include» (A enthält zwingend B), «extend» (B erweitert A optional), Generalisierung (Spezialisierung mit Dreieckspfeil). Pfeilrichtungen: «include» zeigt zur eingeschlossenen Aktivität, «extend» zur erweiterten – Vorsicht, oft verwechselt. Granularität: jeder Use-Case sollte einen sichtbaren Nutzen für den Akteur liefern, als Aktiv-Verb formuliert sein, typische Diagramme haben 5–15 Use-Cases. Textuelle Use-Case-Spezifikation ergänzt das Diagramm: Name, Akteur, Ziel, Vorbedingungen, Nachbedingungen, normaler Ablauf, alternative Abläufe. Häufige Fehler: Personen statt Rollen, Substantive statt Verben, Datenflüsse darstellen, Akteure innerhalb der Systemgrenze, falsche Pfeilrichtungen, technische Innenleben modellieren. Vorgehensweise zur Erstellung: 1) Akteure identifizieren, 2) Use-Cases sammeln, 3) Systemgrenze ziehen, 4) Beziehungen zeichnen, 5) Detailspezifikation schreiben. Use-Case-Diagramme sind die Übersicht – Details kommen in den weiteren UML-Diagrammen: Aktivitätsdiagramm (L3), Sequenzdiagramm (L4), Zustands- und Komponentendiagramme (L5).