Elemente eines Use Case Diagramms – Use Case Diagramme gehören zu den am häufigsten genutzten UML-Diagrammen in der Anforderungsanalyse. Sie helfen dabei, Anforderungen früh zu strukturieren, mit Fachbereichen zu diskutieren und einen gemeinsamen Blick auf das geplante System zu bekommen. Trotzdem bleiben viele Beschreibungen der Diagrammelemente recht abstrakt.
In diesem Artikel schauen wir uns die Elemente eines Use Case Diagramms im Detail an, ordnen sie fachlich ein und zeigen, wie du sie in der Praxis sauber einsetzt.
1. Was ist ein Use Case Diagramm?
Ein Use Case Diagramm beschreibt aus Sicht der Nutzer (Akteure), welche Funktionen ein System anbieten soll, ohne sich in technische Details zu verlieren.
Statt Klassen, Datenstrukturen oder Algorithmen stehen hier Fragen im Vordergrund wie:
- Wer interagiert mit dem System?
- Welche Ziele verfolgen diese Personen oder externen Systeme?
- Welche Systemfunktionen unterstützen diese Ziele?
Das Diagramm ist damit perfekt für frühe Projektphasen, weil es:
- Fachlichkeit visualisiert, statt Technik zu betonen,
- die Kommunikation zwischen Business und IT erleichtert,
- Anforderungen strukturiert und Lücken sichtbar macht,
- eine gute Ausgangsbasis für detailliertere Spezifikationen liefert.
2. Die zentralen Elemente im Überblick
Bevor wir ins Detail gehen, hier die wichtigsten Bausteine eines Use Case Diagramms:
- Akteure (Actors) – externe Rollen oder Systeme, die mit dem betrachteten System interagieren
- Anwendungsfälle (Use Cases) – Leistungen bzw. Funktionen, die das System aus Sicht der Akteure erbringt
- Systemgrenze (System Boundary) – der Rahmen, der das betrachtete System von seiner Umgebung trennt
- Beziehungen (Relationships) zwischen Elementen:
- Assoziation (Akteur ↔ Use Case)
- «include»-Beziehung
- «extend»-Beziehung
- Generalisierung von Akteuren oder Use Cases
- Erweiternde Elemente wie Notizen (Notes) und Pakete (Packages), um Struktur und Kontext zu verdeutlichen
Im Folgenden gehen wir jedes dieser Elemente einzeln durch und beleuchten typische Praxisfragen.
3. Akteure: Wer interagiert mit dem System?
Akteure stehen außerhalb des Systems und repräsentieren Rollen, die mit dem System interagieren. Das können Menschen sein, doch ebenso gut auch andere IT-Systeme, Geräte oder Organisationen.
3.1 Was definiert einen Akteur?
Ein Akteur:
- verfolgt ein Ziel im Zusammenspiel mit dem System,
- löst Use Cases aus oder nimmt an ihnen teil,
- existiert logisch unabhängig vom System (er ist nicht Bestandteil des Systems).
Wichtig: Ein Akteur ist keine konkrete Person, sondern immer eine Rolle.
Statt „Max Mustermann“ modellierst du z. B. „Kunde“ oder „Sachbearbeiter“.
Typische Beispiele für Akteure:
- Menschliche Rollen: „Kunde“, „Mitarbeiter“, „Administrator“
- Externe Systeme: „Zahlungsdienstleister“, „CRM-System“
- Geräte: „EC-Terminal“, „Sensor“
3.2 Arten von Akteuren
Du kannst Akteure weiter unterscheiden, um das Diagramm klarer zu strukturieren:
- Primäre Akteure
- haben ein direktes Ziel, das sie mit Hilfe des Systems erreichen,
- stoßen typischerweise Use Cases an.
- Beispiel: „Kunde“ nutzt einen Online-Shop, um eine Bestellung aufzugeben.
- Sekundäre Akteure
- unterstützen den Ablauf,
- stellen oft Dienste bereit, die das System nutzt.
- Beispiel: „Zahlungsdienstleister“ autorisiert Zahlungen.
- Menschliche vs. technische Akteure
- Menschlich: bedienen das System aktiv.
- Technisch: interagieren über Schnittstellen automatisiert.
Diese Differenzierung ist hilfreich, weil sie spätere Architektur- und Schnittstellendiskussionen vorbereitet.
3.3 So modellierst du Akteure sauber
Beim Modellieren von Akteuren helfen dir ein paar einfache Regeln:
- Verwende Rollennamen, keine Personennamen
- Wähle sprechende, fachliche Begriffe („Prüfer“, „Lieferant“, „Filialleiter“)
- Halte Akteure stabil: Wenn sich Oberflächen oder Prozesse ändern, bleibt die Rolle oft gleich
- Trenne fachliche Rollen bewusst von technischen Schnittstellen-Akteuren
4. Anwendungsfälle: Was leistet das System?
Anwendungsfälle (Use Cases) beschreiben in Form von Leistungen, was das System für einen Akteur tut. Sie sind das Herzstück des Diagramms.
4.1 Charakteristik eines Anwendungsfalls
Ein guter Use Case:
- unterstützt ein klar erkennbares Ziel eines Akteurs,
- liefert einen messbaren Mehrwert (z. B. Bestellung abgeschlossen, Vertrag angelegt),
- hat einen abgeschlossenen fachlichen Umfang,
- wird aus Sicht des Akteurs formuliert, nicht aus Sicht der internen Technik.
Beispiele:
- „Bestellung aufgeben“
- „Rechnung einsehen“
- „Mitarbeiterdaten verwalten“
4.2 Gute Namen für Use Cases
Die Namensgebung beeinflusst massiv, wie gut Fachbereiche das Diagramm verstehen. Achte darauf, dass du:
- Verben + Objekt verwendest, z. B.
- „Konto eröffnen“ statt „Kontoeröffnung“
- „Produkt suchen“ statt „Produktsuche“
- fachliche Begriffe nutzt, die im Unternehmen bereits etabliert sind
- technische Details vermeidest („SOAP-Service anstoßen“ ist kein sinnvoller Use Case-Name)
So kannst du auch Missverständnisse früh reduzieren, weil du dieselbe Sprache sprichst wie deine Stakeholder.
4.3 Typische Fehler bei Anwendungsfällen
Immer wieder tauchen ähnliche Fehler auf:
- Zu technische Use Cases
- Beispiel: „Datenbank aktualisieren“ – das interessiert den Nutzer in der Regel nicht direkt.
- Zu große Use Cases („Super-Use-Cases“)
- Beispiel: „Geschäftsprozess abwickeln“ – dadurch verschwimmen Grenzen und Verantwortlichkeiten.
- Zu kleine Use Cases
- Jede kleine Oberfläche oder jeder Button landet als eigener Use Case im Diagramm,
- dadurch entsteht Überlastung statt Klarheit.
Gute Use Cases findest du, indem du konsequent fragst:
„Welches konkrete Ziel versucht der Akteur zu erreichen?“
5. Systemgrenze: Was gehört zum System – und was nicht?
Die Systemgrenze (System Boundary) ist ein Rechteck, in dem alle Use Cases liegen. Sie zeigt auf einen Blick:
- Was ist Teil des betrachteten Systems?
- Was liegt außerhalb und wird nur über Akteure oder andere Schnittstellen berührt?
Typische Hinweise auf eine unsaubere Systemgrenze:
- Ein Akteur erscheint gleichzeitig innerhalb und außerhalb der Grenze.
- Fachbereiche diskutieren ständig darüber, „ob das noch unser System ist“.
- Use Cases greifen tief in Verantwortungsbereiche anderer Systeme hinein.
Eine sauber definierte Systemgrenze hilft dir, weil sie:
- Scope-Diskussionen strukturiert („Dieses Feature liegt außerhalb unserer Verantwortung.“),
- Schnittstellen klarer macht,
- Verantwortlichkeiten im Projekt besser abgrenzt.
6. Beziehungen zwischen Elementen
Use Case Diagramme leben nicht nur von Akteuren und Use Cases, sondern auch von den Beziehungen zwischen ihnen. Diese Verbindungen machen Abläufe und Wiederverwendung sichtbar.
6.1 Assoziation zwischen Akteur und Use Case
Die einfachste Beziehung ist die Assoziation (eine Linie) zwischen einem Akteur und einem Use Case.
Sie bedeutet:
„Dieser Akteur nimmt an diesem Use Case teil.“
Beispiele:
- „Kunde“ – „Bestellung aufgeben“
- „Mitarbeiter“ – „Kundenstammdaten pflegen“
Wichtige Praxispunkte:
- Ein Use Case kann mehrere Akteure haben (z. B. „Kunde“ und „Sachbearbeiter“).
- Ein Akteur kann an vielen Use Cases beteiligt sein.
- Zeichne nur die Beziehungen, die fachlich relevant sind, sonst leidet die Übersicht.
6.2 «include»-Beziehung: Gemeinsame Schritte auslagern
Die «include»-Beziehung modelliert verpflichtende, wiederverwendbare Teile eines Use Cases.
Typisches Muster:
- Mehrere Anwendungsfälle enthalten denselben Schritt,
- dieser Schritt ist fachlich sinnvoll eigenständig formulierbar,
- jeder der übergeordneten Use Cases führt den eingeschlossenen Use Case immer aus.
Beispiele:
- „Bestellung aufgeben“ include „Lieferadresse validieren“
- „Vertrag abschließen“ include „Bonität prüfen“
Vorteile:
- Du vermeidest Redundanz in Beschreibungen,
- du machst wiederkehrende fachliche Bausteine sichtbar,
- du erleichterst spätere Änderungen, weil du nur an einem Punkt anpassen musst.
6.3 «extend»-Beziehung: Optionale Erweiterungen
Die «extend»-Beziehung beschreibt optionale oder bedingte Erweiterungen eines Use Cases.
Typisches Szenario:
- Es gibt einen Basis-Use-Case,
- unter bestimmten Bedingungen kommen zusätzliche Schritte dazu,
- der Basis-Use-Case bleibt jedoch in seiner Grundform gültig.
Beispiele:
- „Bestellung aufgeben“ extended by „Rabatt gewähren“
- „Check-in durchführen“ extended by „Upgrade anbieten“
Wann nutzt du «extend» sinnvoll?
- Wenn du Sonderfälle oder optionale Abläufe abbilden möchtest,
- wenn diese Sonderfälle die Basissicht sonst unnötig verkomplizieren würden,
- wenn du verschiedene Varianten für spätere Detaillierung klar voneinander trennen willst.
6.4 Generalisierung: Vererbung von Akteuren und Use Cases
Generalisation (Vererbung) kennst du eventuell bereits aus Klassenmodellen. Im Use Case Diagramm nutzt du sie, um gemeinsame Eigenschaften von Akteuren oder Use Cases zu bündeln.
Generalisierung von Akteuren:
- „Benutzer“ als Oberbegriff, darunter
- „Privatkunde“
- „Geschäftskunde“
- Beide erben die Beziehungen des generischen „Benutzer“-Akteurs,
- zusätzliche, rollen-spezifische Use Cases kannst du an den Spezialisierungen ergänzen.
Generalisierung von Use Cases:
- Allgemeiner Use Case: „Bezahlung auslösen“
- Spezialisierungen:
- „Kreditkartenzahlung durchführen“
- „PayPal-Zahlung durchführen“
Generalisation eignet sich, wenn:
- du Varianten eines Verhaltens strukturieren möchtest,
- du gemeinsame Anteile bündeln willst,
- du die Übersichtlichkeit im Diagramm erhöhen willst, statt viele ähnliche Elemente nebeneinander zu legen.
7. Zusätzliche Diagrammelemente: Notizen und Pakete
Neben den Kern-Elementen unterstützen zwei zusätzliche Artefakte die Verständlichkeit größerer Modelle.
7.1 Notizen (Notes)
Notizen sind kleine Textfelder, die du an Elemente oder an das Diagramm als Ganzes hängen kannst. Sie dienen dazu, Erklärungen, Annahmen oder Einschränkungen direkt am Modell zu dokumentieren.
Sinnvolle Einsatzzwecke:
- Fachliche Klarstellungen, z. B. „Nur für registrierte Kunden relevant“
- Verweise auf andere Dokumente („Details siehe Fachkonzept Kapitel 4“)
- Offene Fragen, die noch geklärt werden müssen
Mit Notizen verbesserst du die Nachvollziehbarkeit deines Modells deutlich, weil Leser Kontext nicht erst in separaten Dokumenten suchen müssen.
7.2 Pakete (Packages)
Pakete gruppieren Use Cases thematisch. Das ist vor allem in größeren Systemen hilfreich, weil du:
- verwandte Anwendungsfälle zusammenfasst,
- fachliche Domänen sichtbar machst,
- Teilbereiche eines Systems getrennt diskutieren kannst.
Beispiele für Pakete:
- „Kundenverwaltung“
- „Bestellabwicklung“
- „Zahlungsabwicklung“
- „Reporting“
Pakete kannst du auch nutzen, um Verantwortungsbereiche verschiedener Teams abzubilden, damit klar bleibt, welches Team welche Use Cases verantwortet.
8. Praxisbeispiel: Use Case Diagramm für einen Online-Shop
Um die Elemente greifbarer zu machen, schauen wir uns ein vereinfachtes Beispiel an.
8.1 Akteure
- Kunde
- Mitarbeiter Kundenservice
- Zahlungsdienstleister
8.2 Zentrale Use Cases
Innerhalb der Systemgrenze „Online-Shop“ liegen Anwendungsfälle wie:
- „Produkte suchen“
- „Produkte in den Warenkorb legen“
- „Bestellung aufgeben“
- „Kundenkonto verwalten“
- „Bestellung stornieren“
- „Zahlung verbuchen“ (teilweise im Zusammenspiel mit dem Zahlungsdienstleister)
8.3 Beziehungen und Strukturierung
- Der Akteur „Kunde“ ist mit
- „Produkte suchen“,
- „Produkte in den Warenkorb legen“,
- „Bestellung aufgeben“
assoziiert.
- Der Akteur „Zahlungsdienstleister“ ist mit
- „Zahlung verbuchen“
verbunden.
- „Zahlung verbuchen“
- Der Use Case „Bestellung aufgeben“ include „Lieferadresse validieren“ und „Zahlung anstoßen“.
- „Zahlung anstoßen“ extended by „Rabatt gewähren“, wenn ein gültiger Rabatt-Code vorliegt.
- Das Paket „Bestellprozess“ enthält
- „Produkte in den Warenkorb legen“,
- „Bestellung aufgeben“,
- „Bestellung stornieren“.
Über ein einziges, klar strukturiertes Diagramm vermittelst du damit:
- welche Rollen beteiligt sind,
- welche Leistungen das System erbringen soll,
- wie sich wiederkehrende Schritte fachlich sinnvoll gruppieren lassen.
9. Fazit Elemente eines Use Case Diagramms: Use Case Diagramme als Brücke zwischen Fachlichkeit und Technik
Use Case Diagramme bieten eine klare, leicht verständliche Sicht auf ein System. Sie konzentrieren sich auf Ziele und Leistungen, statt sich in technischen Details zu verlieren.
Die wichtigsten Elemente lassen sich knapp zusammenfassen:
- Akteure beschreiben, wer mit dem System interagiert.
- Anwendungsfälle zeigen, welche Ziele diese Akteure mit Hilfe des Systems erreichen.
- Die Systemgrenze trennt klar, was Teil des Systems ist und was zur Umgebung gehört.
- Beziehungen wie Assoziation, «include», «extend» und Generalisierung strukturieren Abhängigkeiten und Varianten.
- Notizen und Pakete erhöhen die Lesbarkeit, insbesondere in größeren Modellen.
Wenn du diese Elemente bewusst einsetzt, stärkst du die Verständlichkeit deiner Modelle, reduzierst Missverständnisse und legst eine solide Grundlage für detaillierte Spezifikationen, Architekturentscheidungen und Tests.
Falls du möchtest, können wir im nächsten Schritt gemeinsam ein konkretes Use Case Diagramm für dein eigenes Projekt skizzieren – inklusive Formulierungen für die wichtigsten Anwendungsfälle.