Use-Case-Diagramme: Ein praktischer Leitfaden

Ein Use-Case-Diagramm ist ein UML-Verhaltensdiagramm, das zeigt, wie externe Benutzer oder Systeme mit einem System interagieren. Es konzentriert sich auf was das System aus der Sicht eines Akteurs tut, nicht auf interne Implementierungsdetails.

Use-Case-Diagramme sind insbesondere während der Anforderungsanalyse nützlich, da sie eine hochlevelige Übersicht über die Systemfunktionalität und den Umfang bieten.

1. Was ein Use-Case-Diagramm zeigt

Ein Use-Case-Diagramm enthält typischerweise:

• Systemgrenze — definiert, was sich innerhalb des zu modellierenden Systems befindet.

• Akteure — externe Benutzer, Organisationen, Geräte oder Systeme, die damit interagieren.

• Use Cases — Ziele oder Dienste, die das System bereitstellt.

• Assoziationen — Kommunikationsverbindungen zwischen Akteuren und Use Cases.

• Beziehungen zwischen Use Cases — wie zum Beispiel <<include>> und <<extend>>.

• Verallgemeinerung — Vererbung zwischen Akteuren oder Use Cases.

Ein Use-Case-Diagramm zeigt normalerweise nicht:

• Algorithmusschritte

• Datenbanktabellen

• Programmklassen

• Interne Workflows

• Detaillierte Benutzeroberflächen-Layouts

• Nachrichtenabläufe über die Zeit

Diese Details werden besser durch Aktivitäts-, Klassen-, Sequenz- oder Zustandsdiagramme dargestellt.

2. Schlüsselkonzepte

Systemgrenze

Die Systemgrenze ist ein Rechteck, das die zum System gehörenden Anwendungsfälle umgibt.

Zum Beispiel in einem Online-Shopping-System:

+--------------------------------------+
|        Online-Shopping-System        |
|                                      |
|  (Produkte durchsuchen)              |
|  (Bestellung aufgeben)               |
|  (Zahlung leisten)                   |
+--------------------------------------+

Akteure bleiben außerhalb der Grenze, da sie extern zum System sind.

Die Grenze hilft, den Umfangdes Systems zu verdeutlichen. Wenn eine Fähigkeit außerhalb der Grenze liegt, wird sie nicht vom zu modellierenden System implementiert.

Akteure

Ein Akteur ist alles Externe, das mit dem System interagiert, um ein Ziel zu erreichen.

Akteure können umfassen:

• Menschliche Benutzer

• Externe Anwendungen

• Hardware-Geräte

• Andere Organisationen

• Zeitpunkte oder geplante Ereignisse, wenn sie als externe Auslöser modelliert werden

Beispiele:

• Kunde

• Bibliothekar

• Zahlungs-Gateway

• Administrator

• E-Mail-Dienst

Ein Akteur repräsentiert eine Rolle, nicht notwendigerweise eine bestimmte Person. Zum Beispiel ist „Kunde” in der Regel besser als „Alex“.”

Akteure können sein:

• Primäre Akteure — initiieren Interaktionen, um ein Ziel zu erreichen.

• Unterstützende Akteure — erbringen Dienstleistungen für das System.

Zum Beispiel kann ein Kunde „Bestellung aufgeben

Anwendungsfälle

Ein Anwendungsfall stellt ein sinnvolles Ziel oder einen vom System erbrachten Dienst dar.

Gute Namen für Anwendungsfälle folgen normalerweise diesem Muster:

Verb + Objekt

Beispiele:

• Konto registrieren

• Katalog durchsuchen

• Antrag einreichen

• Bericht erstellen

• Reservierung stornieren

• Zahlung verarbeiten

Ein Anwendungsfall sollte ein beobachtbares Ergebnis beschreiben und nicht einen internen Implementierungsschritt.

Bevorzugen Sie:

Bestellung aufgeben

statt:

Bestellungsobjekt validieren

Das zweite beschreibt eine interne Operation und nicht ein Benutzerziel.

Assoziationen

Eine Assoziation ist eine Kommunikationsverbindung zwischen einem Akteur und einem Anwendungsfall.

Sie zeigt an, dass der Akteur am Anwendungsfall teilnimmt oder ihn initiiert.

Kunde ---- (Bestellung aufgeben)

Assoziationen zeigen normalerweise keine Reihenfolge, Kontrollfluss oder Richtung an. Wenn die Reihenfolge der Interaktionen von Bedeutung ist, verwenden Sie ein Sequenz- oder Aktivitätsdiagramm.

3. Beziehungen zwischen Anwendungsfällen

<<include>>

Verwenden Sie <<include>> wenn ein Anwendungsfall immer verwendet einen anderen Anwendungsfall.

Beispielsweise kann das Aufgeben einer Bestellung immer eine Authentifizierung erfordern:

(Bestellung aufgeben) ..> (Kunden authentifizieren) : <<include>>

Der Basis-Anwendungsfall ist vom eingebetteten Anwendungsfall abhängig.

Verwenden Sie include wenn:

• Das Verhalten ist verpflichtend.

• Das Verhalten wird von mehreren Anwendungsfällen wiederverwendet.

• Die Auslagerung des Verhaltens verbessert die Übersichtlichkeit.

Beispiel:

(Bargeld abheben) ..> (Karte authentifizieren) : <<include>>
(Kontostand prüfen) ..> (Karte authentifizieren) : <<include>>

Beide Anwendungsfälle erfordern immer eine Kartenauthentifizierung.

<<extend>>

Verwenden Sie <<extend>> wenn zusätzliches Verhalten optional ist oder bedingt in einen Basis-Anwendungsfall eingefügt wird.

(Rabatt anwenden) ..> (Bestellung aufgeben) : <<extend>>

Das Rabattverhalten tritt nur ein, wenn die Berechtigungskriterien erfüllt sind.

Verwenden Sie extend wenn:

• Das Verhalten ist optional.

• Es tritt nur unter einer Bedingung auf.

• Der Basisfall ist ohne ihn vollständig.

Beispiele:

• „Geschenkverpackung hinzufügen“ erweitert „Bestellung aufgeben“.

• „Rückerstattung beantragen“ erweitert „Abonnement kündigen“.

• „Werbe-E-Mail senden“ erweitert „Registrierung abschließen“.

Der Pfeil zeigt vom erweiternden Fall zum Basisfall.

Verallgemeinerung

Verallgemeinerung stellt eine „ist-ein“-Beziehung zwischen Akteuren oder Anwendungsfällen dar.

Zum Beispiel:

Premium-Kunde --|> Kunde

Ein Premium-Kunde ist eine Art Kunde und erbt die Interaktionen des Kunden.

Akteur-Verallgemeinerung kann nützlich sein, wenn mehrere Akteure gemeinsames Verhalten aufweisen:

Administrator --|> Mitarbeiter
Bibliothekar --|> Mitarbeiter

Verwenden Sie Verallgemeinerungen sparsam. Wenn die Beziehung lediglich „verwendet“ oder „nimmt an“ bedeutet, ist eine Assoziation meist angemessener.

4. Primäre und unterstützende Akteure

Betrachten Sie ein Online-Zahlungsszenario:

• Der Kunde ist der primäre Akteur, da er den Kauf initiiert.

• Der Zahlungs-Gateway ist ein unterstützender Akteur, da er die Zahlung auf Anfrage des Systems verarbeitet.

Ein einfaches Modell könnte so aussehen:

Kunde ---- (Bestellung aufgeben)
(Bestellung aufgeben) ---- Zahlungs-Gateway

Die Unterscheidung ist nützlich, da sie klärt, wer vom Anwendungsfall profitiert und welche externen Systeme beteiligt sind.

5. Wie man Anwendungsfälle identifiziert

Ein praktischer Weg, Anwendungsfälle zu entdecken, ist zu fragen:

1. Wer verwendet das System?

2. Welches Ziel möchte jeder Akteur erreichen?

3. Welche Dienste bietet das System an?

4. Welche Ereignisse lösen das Systemverhalten aus?

5. Mit welchen externen Systemen muss das System interagieren?

6. Welches Verhalten ist immer erforderlich?

7. Welches Verhalten ist optional oder bedingt?

Listen Sie für jeden Akteur deren Ziele auf:

Das Ziel sollte für den Akteur sinnvoll sein. Vermeiden Sie, jede kleine Systemoperation in einen Anwendungsfall zu verwandeln.

6. Benennungsrichtlinien

Verwenden Sie klare, zielorientierte Namen.

Gute Beispiele:

• Konto erstellen

• Profil aktualisieren

• Antrag einreichen

• Sendung verfolgen

• Antrag genehmigen

• Rechnung erstellen

Vermeiden Sie vage Bezeichnungen:

• Systemverarbeitung

• Daten verarbeiten

• Benutzerfunktion

• Vorgang ausführen

Vermeiden Sie übermäßige technische Details:

• SQL-Abfrage ausführen

• REST-Endpunkt aufrufen

• PaymentService instanziieren

Dies können gültige Implementierungsschritte sein, aber sie sind in der Regel nicht als hochstufige Anwendungsfälle nützlich.

7. Beispiel: Bibliotheksverwaltungssystem

Nehmen wir an, ein Bibliothekssystem unterstützt:

• Mitglieder suchen nach Büchern

• Mitglieder leihen Bücher aus

• Mitglieder geben Bücher zurück

• Bibliothekare verwalten den Katalog

• Erinnerungen bei Überziehung

• Zahlungsabwicklung für Bußgelder

Mögliche Akteure:

• Mitglied

• Bibliothekar

• Benachrichtigungsdienst

• Zahlungsdienst

Mögliche Anwendungsfälle:

• Katalog durchsuchen

• Buch ausleihen

• Buch zurückgeben

• Gebühr berechnen

• Gebühr bezahlen

• Katalog verwalten

• Überfällige Benachrichtigung senden

Beziehungen:

• Buch ausleihen beinhaltet Mitgliederverifizierung.

• Buch ausleihen beinhaltet Prüfung der Buchverfügbarkeit.

• Buch zurückgeben beinhaltet Gebührenberechnung.

• Gebühr bezahlen interagiert mit dem Zahlungsdienst.

• Überfällige Benachrichtigung senden interagiert mit dem Benachrichtigungsdienst.

8. PlantUML-Beispiel

Der folgende PlantUML-Code erstellt ein Use-Case-Diagramm für das Bibliothekssystem:

@startuml
left to right direction

title Bibliotheksverwaltungssystem - Use-Case-Diagramm

actor Mitglied
actor Bibliothekar
actor "Benachrichtigungsdienst" as Notification
actor "Zahlungsdienst" as Payment

rectangle "Bibliotheksverwaltungssystem" {

  usecase "Katalog durchsuchen" as UC_Search
  usecase "Buch ausleihen" as UC_Borrow
  usecase "Buch zurückgeben" as UC_Return
  usecase "Mitgliederverifizierung" as UC_CheckMember
  usecase "Buchverfügbarkeit prüfen" as UC_CheckAvailability
  usecase "Gebühr berechnen" as UC_CalculateFine
  usecase "Gebühr bezahlen" as UC_PayFine
  usecase "Katalog verwalten" as UC_ManageCatalog
  usecase "Überfällige Benachrichtigung senden" as UC_Notify
}

Member --> UC_Search
Member --> UC_Borrow
Member --> UC_Return
Member --> UC_PayFine

Librarian --> UC_ManageCatalog
Librarian --> UC_Borrow
Librarian --> UC_Return

Payment --> UC_PayFine
Notification --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>
UC_Return ..> UC_CalculateFine : <<include>>

UC_Notify ..> UC_Return : <<extend>>

@enduml

9. Erklärung des Beispiels

Akteure

actor Mitglied
actor Bibliothekar
actor "Benachrichtigungsdienst" as Notification
actor "Zahlungsdienst" as Payment

Das Diagramm modelliert zwei menschliche Akteure und zwei externe Dienste.

Aliasnamen wie as Notification machen lange Namen später einfacher referenzierbar.

Systemgrenze

Rechteck "Bibliothek-Verwaltungssystem" {
    ...
}

Das Rechteck definiert den Umfang des Systems. Die innerhalb des Rechtecks befindlichen Anwendungsfälle werden vom Bibliothekssystem bereitgestellt.

Akteurs-Assoziationen

Mitglied --> UC_Suche
Mitglied --> UC_Ausleihen

Diese Assoziationen zeigen, dass ein Mitglied den Katalog durchsuchen und Bücher ausleihen kann.

Die Pfeilrichtung ist in einem grundlegenden Anwendungsfalldiagramm normalerweise semantisch nicht von Bedeutung. Sie dient primär dazu, das Diagramm lesbar zu machen.

Include-Beziehungen

UC_Ausleihen ..> UC_MitgliedPrüfen : <<include>>
UC_Ausleihen ..> UC_VerfügbarkeitPrüfen : <<include>>

Das Ausleihen eines Buches erfordert stets eine Mitglied- und Verfügbarkeitsprüfung, daher werden diese als included Anwendungsfälle modelliert.

Extend-Beziehung

UC_Benachrichtigen ..> UC_Rückgabe : <<extend>>

Dies zeigt an, dass das Verhalten der Mahnbenachrichtigung bei Überziehung eine zusätzliche Verhaltensweise ist, die mit der Rückgabe eines Buches verbunden ist.

In einem realen Anforderungsmodell wäre ein natürlicherer Entwurf jedoch möglicherweise, „Mahnbenachrichtigung senden“ einem geplanten Prozess oder einem Akteur wie „Bibliotheksterminplaner“ zuzuordnen. Die beste Beziehung hängt von den tatsächlichen Geschäftsregeln ab.

10. Eine detailliertere Anwendungsfallspezifikation

Ein Diagramm gibt einen Überblick, aber jeder wichtige Anwendungskasus sollte normalerweise eine textliche Spezifikation haben.

Anwendungskasus: Buch ausleihen

Ein Use-Case-Diagramm sollte nicht versuchen, all diese Details zu enthalten. Das Diagramm liefert die Karte; die Spezifikation liefert das Verhalten.

11. PlantUML-Syntaxreferenz

Akteure deklarieren

actor Kunde
actor "Zahlungs-Gateway" als Gateway

Use Cases deklarieren

usecase "Bestellung aufgeben" als PlaceOrder
usecase "Zahlung verarbeiten" als ProcessPayment

Erstellen einer Systemgrenze

rectangle "Online-Shop" {
    usecase "Produkte durchsuchen" as Browse
    usecase "Bestellung aufgeben" as Order
}

Verknüpfung von Akteuren und Anwendungsfällen

Kunde --> Browse
Kunde --> Order

Einschließen

Bestellung ..> Zahlung verarbeiten : <<include>>

Erweitern

Gutschein anwenden ..> Bestellung : <<extend>>

Akteur-Generalisierung

Premiumkunde --|> Kunde

Paket-Gruppierung

Pakete können verwandte Anwendungsfälle visuell gruppieren:

rectangle "Bankensystem" {
  package "Kontoverwaltung" {
    usecase "Konto eröffnen" as OpenAccount
    usecase "Konto schließen" as CloseAccount
  }

  package "Zahlungen" {
    usecase "Geld überweisen" as TransferFunds
    usecase "Rechnung bezahlen" as PayBill
  }
}

Notizen

note rechts von PlaceOrder
  Der Kunde muss authentifiziert sein,
  bevor er eine Bestellung aufgeben kann.
end note

12. Verbessern des Diagramm-Layouts

PlantUML legt Diagramme automatisch an, doch mehrere Techniken verbessern die Lesbarkeit.

Richtung steuern

Richtung von links nach rechts

Dies ist oft nützlich, wenn Akteure an den Seiten und Anwendungsfälle in der Mitte erscheinen sollen.

Weitere gängige Richtungen sind:

Richtung von oben nach unten

Aliasnamen verwenden

Anstatt lange Namen zu wiederholen:

usecase "Kundenidentität überprüfen" als VerifyIdentity

Dann verweisen Sie auf:

RegisterAccount ..> VerifyIdentity : <<include>>

Verwandte Anwendungsfälle gruppieren

Verwenden Sie Pakete oder verschachtelte Rechtecke, um Funktionsbereiche zu trennen:

package "Auftragsverwaltung" {
    usecase "Auftrag erstellen" as CreateOrder
    usecase "Auftrag stornieren" as CancelOrder
}

Übermäßige Kreuzungen vermeiden

Ein Diagramm wird schwer lesbar, wenn zu viele Linien sich kreuzen. Sie können es verbessern durch:

• Verwandte Akteure in der Nähe ihrer Anwendungsfälle platzieren

• Anwendungsfälle in Pakete gruppieren

• Ein großes Diagramm in mehrere kleinere Diagramme aufteilen

• Verwendung von Aliasen für klare Referenzen

• Unnötige Beziehungen vermeiden

13. Häufige Fehler

Interne Funktionen als Anwendungsfälle modellieren

Dies ist meist zu technisch:

Datenbankverbindung validieren
Anfrage serialisieren
Zahlungs-API aufrufen

Bevorzugen Sie extern sinnvolle Ziele:

Zahlung leisten
Antrag einreichen
Bericht erstellen

Jeden Akteur als Person behandeln

Externe Systeme und Geräte können ebenfalls Akteure sein:

• Zahlungs-Gateway

• Identitätsanbieter

• Lagersystem

• Barcode-Scanner

• Benachrichtigungsdienst

Verwendung von includefür optionales Verhalten

Wenn Verhalten optional ist, verwenden Sie erweitern statt einklammern.

Falsch:

Bestellung aufgeben ..> Gutschein anwenden : <<einklammern>>

Wenn das Anwenden eines Gutscheins optional ist, verwenden Sie:

Gutschein anwenden ..> Bestellung aufgeben : <<erweitern>>

Verwendung von erweitern für zwingendes Verhalten

Wenn ein Verhalten immer auftritt, sollte es im Allgemeinen mit einklammern.

Bestellung aufgeben ..> Kunden authentifizieren : <<einklammern>>

Direkte Verbindung von Use Cases ohne Bedeutung

Eine Linie zwischen zwei Use Cases sollte eine gültige UML-Beziehung darstellen. Vermeiden Sie willkürliche Verbindungen, die lediglich andeuten, dass die Use Cases irgendwie miteinander verbunden sind.

Erstellung eines einzigen riesigen Diagramms

Ein Use-Case-Diagramm sollte auf hoher Ebene klar kommunizieren. Wenn es Dutzende von Akteuren und Use Cases enthält, erstellen Sie mehrere Diagramme, die nach Subsystem oder Geschäftsbereich organisiert sind.

Darstellung von Sequenzen

Ein Use-Case-Diagramm zeigt nicht, dass ein Use Case vor einem anderen stattfindet. Für Sequenzen verwenden Sie ein Sequenzdiagramm oder ein Aktivitätsdiagramm.

14. Wann andere UML-Diagramme zu verwenden sind

Use-Case-Diagramme eignen sich am besten für Systemumfang und Benutzerziele. Kombinieren Sie sie mit anderen Diagrammen, wenn mehr Details erforderlich sind:

15. Empfohlener Modellierungsprozess

1. Definieren Sie die Systemgrenze.

2. Identifizieren Sie alle externen Akteure.

3. Identifizieren Sie die Ziele jedes Akteurs.

4. Konvertieren Sie diese Ziele in Anwendungsfälle.

5. Verbinden Sie die Akteure mit den Anwendungsfällen, an denen sie teilnehmen.

6. Identifizieren Sie zwingend wiederverwendbares Verhalten und modellieren Sie es mit <<include>>.

7. Identifizieren Sie optionales oder bedingtes Verhalten und modellieren Sie es mit <<extend>>.

8. Fügen Sie Verallgemeinerungen nur dort hinzu, wo eine echte „ist-ein“-Beziehung besteht.

9. Überprüfen Sie das Diagramm mit den Beteiligten.

10. Fügen Sie textliche Spezifikationen für wichtige Anwendungsfälle hinzu.

11. Teilen Sie das Diagramm auf, wenn es überladen wird.

16. Kompakte PlantUML-Vorlage

Sie können dies als Ausgangspunkt verwenden:

@startuml
left to right direction

title System Use Case Diagram

actor User
actor "External System" as ExternalSystem

rectangle "System Name" {
  usecase "Main User Goal" as MainGoal
  usecase "Required Shared Behavior" as RequiredBehavior
  usecase "Optional Behavior" as OptionalBehavior
}

User --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

Das zentrale Prinzip besteht darin, nach außen sichtbare Ziele, nicht interne Implementierungsdetails. Ein starkes Anwendungsfalldiagramm macht die Systemgrenze, Akteure, Fähigkeiten und wichtige Abhängigkeiten sofort verständlich.

Referenz

Der Artikel ist auch in English, Español, فارسی and Français verfügbar.