Was ist ein Use Case-Diagramm?

Use Case-Diagramm. Die einfache Visualisierung von Anwendungsfällen.

Wozu dienen Use Case-Diagramme? Wie werden sie erstellt und welche Vorteile bieten sie?

tooltip text
1

Use Case-Diagramme visualisieren Anwendungsfälle eines oder mehrerer Akteure und Beziehungen zwischen den Anwendungsfällen. In diesem Beispiel beschreibt das Use Case-Diagramm eine App für eine Online-Essensbestellung.

2

Als Akteur agiert der hungrige Kunde, der mehrere Use Cases auslöst. Akteure können aber auch Objekte wie E-Mail-Systeme sein. Die 1 repräsentiert die Multiplizität, d.h. genau ein Akteur ist am Anwendungsfall beteiligt.

3

Zwischen den Akteuren und Use Cases können unterschiedliche Beziehungen herrschen, die ein Use Case-Diagramm mit speziellen Pfeilen und Beschriftungen darstellt.

Use Case-Diagramme visualisieren Anwendungsfälle eines oder mehrerer Akteure und Beziehungen zwischen den Anwendungsfällen.

“Eigentlich haben wir uns etwas ganz Anderes vorgestellt.” Kein Satz, den man gern vom Kunden hört. Doch gar nicht so selten. Denn die Realität beweist immer wieder, wie unterschiedlich Menschen kommunizieren und Dinge verstehen, die eigentlich gar nicht so gemeint waren – Herr Watzlawick , der bekannte österreichisch-amerikanische Kommunikationswissenschaftler, lässt grüßen. Wenn Anforderungen in Ihrem Software-Projekt falsch verstanden, ungenau mitgeteilt oder gar nicht erst vom Kunden genannt wurden, führt das nicht nur zu unangenehmen Konflikten, sondern es kostet Sie Zeit und Geld. Daher haben sich im Projektmanagement Use Cases und das Use Case-Diagramm bewährt: Eine grafische Visualisierung, die das Verhalten eines Systems aus der Sicht der Anwender durch definierte visuelle Mittel der Unified Modeling Language (UML) beschreibt. Es unterstützt Sie beim Finden und Definieren von Anforderungen.

Use Case-Diagramm: Eine kurze Definition

Ein Use Case-Diagramm (auch Anwendungsfalldiagramm genannt) ist ein Verhaltensdiagramm und visualisiert die von außen sichtbare Interaktion von Akteuren mit dem zu entwickelnden System. Das Diagramm besteht aus dem System, zugehörigen Anwendungsfällen und Akteuren und setzt diese miteinander in Beziehung:

System: Was wird beschrieben?

Akteur: Wer benutzt das System?

Use Case: Was machen die Akteure?

Was ist das Use Case-Diagramm nicht?

Ein Use Case-Diagramm beschreibt nicht, in welcher Reihenfolge Sie die Anwendungsfälle durchführen. Beispielsweise definieren Sie den Use Case Geld abheben. Diesen Vorgang würden Sie in mehreren Schritten durchführen wie EC-Karte einführen, PIN-Nummer eingeben, Betrag wählen, Betrag herausnehmen und EC-Karte herausnehmen. Natürlich sind das alles Aktivitäten aus der Sicht des Kunden – aber diese Abfolge soll das Use Case-Diagramm gar nicht abdecken. Dafür eignen sich andere Diagrammarten wie z.B. Aktivitätsdiagramme. In einem Use Case-Diagramm beschreiben Sie nur die gewünschte Funktionalität des Systems in Use Cases und setzen diese in Verbindung mit anderen Anwendungsfällen und/oder Akteuren. Auf diese Weise lässt sich darstellen, welche Sichtweisen es auf das System gibt und wie unterschiedlich sie interpretiert werden – erst so können Sie Anforderungen ganz verstehen.

Wie erstellen Sie ein Use Case-Diagramm?

Das System umrahmt die Use Cases. Die Akteure befinden sich außerhalb des Systems.

Der Akteur im Use Case-Diagramm

Akteur im Use Case-Diagramm

Für die Darstellung von Akteuren haben sich Strichmännchen etabliert. Obwohl als Mensch dargestellt, können Akteure nicht nur Personen repräsentieren, sondern auch nicht-menschliche Elemente wie z.B. ein E-Mail-System. Ein Akteur kann sowohl aktiv das System benutzen und dadurch Anwendungsfälle auslösen als auch passiv vom System benutzt werden, um Anwendungsfälle realisieren zu können. Wenn Sie einen Akteur definieren, muss dieser auch immer mit mindestens einem Anwendungsfall in Verbindung stehen. Ein Akteur repräsentiert stets eine Rolle und kann dadurch durch mehrere Personen bzw. Systeme besetzt sein. Wenn mehrere Akteure an einem Anwendungsfall beteiligt sind, lässt sich dies durch die Multiplizität ausdrücken. Ohne weitere Angabe entspricht sie standardmäßig 1. Um Akteure so spezifisch wie möglich zu beschreiben, empfiehlt es sich ebenfalls, diese mit Personas zu verbinden.

Überblick über die
Eigenschaften des Akteurs:

  • ist menschlich oder nicht-menschlich
  • repräsentiert Rollen
  • lässt sich mit einer Multiplizität angeben
  • kommuniziert mit dem System (steht mit mind. einem Anwendungsfall in Verbindung)
  • benutzt das System (löst Anwendungsfälle aus) oder
  • wird vom System benutzt (wird gebraucht, um Anwendungsfälle zu realisieren)

Der Use Case im Use Case-Diagramm

Use Case im Use Case-Diagramm

Use Cases werden in der Regel durch Ellipsen dargestellt. Ein Use Case repräsentiert eine Funktionalität des Systems aus der Sicht des Anwenders und beschreibt das Ziel seiner Handlung. Hier dürfen und sollten Sie auch die Abfolge der Handlung angeben – also z.B. EC-Karte einstecken, PIN-Nummer eingeben usw. – sowie Alternativ-Abläufe abdecken. Wenn ein Use Case nur ausführbar durch andere Anwendungsfälle ist, dann wird er als abstrakt bezeichnet und lässt sich im Use Case-Diagramm dementsprechend kennzeichnen. Auch für einen Anwendungsfall können Sie die Multiplizität angeben. Sie beschreibt, wie häufig ein Use Case gleichzeitig ausgeführt werden darf. Oft sind Use Cases sehr umfangreich – zu umfangreich für agile Projekte, die Sie in einem Sprint von wenigen Wochen umsetzen müssen. Daher wurde diese Idee als Use Case 2.0 weiterentwickelt.

Lesen Sie hier, um mehr über Use Cases zu erfahren »
Lesen Sie hier, um mehr über Use Cases 2.0 zu erfahren »

Überblick über die
Eigenschaften des Use Case:

  • auch Anwendungsfall genannt
  • beschreibt das Verhalten des zu entwickelnden Systems
  • repräsentiert die Perspektive des Anwenders
  • lässt sich mit einer Multiplizität angeben
  • betrachtet keine Details des Systemverhaltens
  • kann abstrakt sein (er selbst ist nicht ausführbar, sondern nur durch andere Anwendungsfälle)

So erstellen Sie einfach und schnell Use Case-Diagramme in der Praxis

Erfahren Sie hier mehr zu Requirements Modelling
mit objectiF RPM oder objectiF RM »

Wissen online: objectiF RPM und objectiF RM

Wie setzen Sie Akteure und Anwendungsfälle im Use Case-Diagramm in Beziehung?

Assoziation im Use Case-Diagramm

Kommunikationsbeziehung in einem Use Case Diagramm in objectiF RPM

Wenn ein Akteur an einem Anwendungsfall beteiligt ist – also z.B. eine Funktion des Systems startet – dann herrscht eine Kommunikationsbeziehung (auch Assoziation genannt). Sie ist durch einen einfachen Strich oder durch einen Strich mit Pfeilen an beiden Enden im Use Case-Diagramm gekennzeichnet.

Include-Beziehung im Use Case-Diagramm

Include-Beziehung im Use Case Diagramm

Die Enthält-Beziehung besteht immer zwischen Anwendungsfällen. Sie verbindet einen Use Case (Basis-Use Case) mit einem oder mehreren inkludierten Use Cases. Übersetzt heißt das: Ein Anwendungsfall braucht einen anderen Anwendungsfall, dem inkludierten Use Case, um seine Funktionalität im System bereitstellen zu können. Der inkludierte Use Case kann aber separat ausgeführt werden. Die Enthält-Beziehung ist in einem Use Case-Diagramm durch einen gestrichelten Pfeil und der Beschriftung include dargestellt. Der Pfeil zeigt immer auf den inkludierten Use Case.

Extend-Beziehung im Use Case-Diagramm

Extend-Beziehung in einem Use Case Diagramm

Die Erweiterungsbeziehung verbindet einen Anwendungsfall mit einem oder mehreren Anwendungsfällen. Die Funktionalität des erweiternden Use Case kann (muss aber nicht) im Basis-Use Case integriert werden – der Anwendungsfall erweitert also den Basis-Use Case um seine Funktionalität. Der Basis-Use Case entscheidet, ob der erweiternde Use Case ausgeführt wird. Beide Anwendungsfälle lassen sich separat ausführen. Eine Erweiterungsbeziehung wird in einem Use Case durch einen gestrichelten Pfeil mit der Beschriftung extend im Use Case-Diagramm dargestellt. Der Pfeil zeigt immer auf den Basis-Use Case.

Der Zeitpunkt, an dem das Verhalten eines Anwendungsfalls erweitert werden kann, ist ein Erweiterungspunkt. Eine Use Case darf mehrere solcher Erweiterungspunkte besitzen. Sie werden innerhalb des Anwendungsfalls angezeigt.

Erweiterungspunkt mit Extend-Beziehung in einem Use Case Diagramm in objectiF RPM

Generalisierungsbeziehung im Use Case-Diagramm

Eine Generalisierungsbeziehung (auch “ist eine Art”-Beziehung) kann zwischen Akteuren und zwischen Anwendungsfällen bestehen. In dieser Beziehung wird die Kommunikationsbeziehung vererbt: Ein allgemein beschriebener Use Case oder Akteur vererbt seine Kommunikationsbeziehung auf einen genauer definierten Use Case bzw. Akteur. Diese Spezialfälle lassen sich dann mit Use Cases verbinden, die nur für sie und nicht dem allgemein beschriebenen Akteur bzw. Use Case gelten. Die Generalisierungsbeziehung ist durch einen Pfeil im Use Case-Diagramm dargestellt, der auf den allgemein beschriebenen Anwendungsfall/Akteur zeigt.

… zwischen Use Cases

Eine Generalisierungsbeziehung zwischen Use Cases herrscht, wenn Sie einen allgemeinen Anwendungsfall (Use Case A) definieren, der durch einen oder mehreren Anwendungsfällen (Use Case B) spezifiziert wird.

Use Case A vererbt seine Kommunikationsbeziehung(en) an den spezifizierten Anwendungsfall B. B benötigt A, kann A aber überschreiben oder ergänzen und erbt alle Beziehungen von A. Use Case B entscheidet letztendlich, was von Use Case A ausgeführt wird.

Zum Beispiel haben Sie den Use Case Online bezahlen (Use Case A). Wie genau kann der Anwender des Systems online bezahlen? Per Kredit- oder EC-Karte beispielsweise. Dann spezifizieren diese genaueren Zahlungsarten im Use Case-Diagramm (Use Cases B, C).

Generalisierungsbeziehung zwischen Use Cases in einem Use Case Diagramm in objectiF RPM

… zwischen Akteuren

Eine Generalisierungsbeziehung zwischen Akteuren herrscht, wenn Sie unterschiedliche Akteure definieren (Akteur B und C), aber diese über gleiche Eigenschaften verfügen. Dann definieren Sie einen allgemeinen Akteur (Akteur A), auf den die beiden Akteure zeigen.

Die spezialisierten Akteure können mindestens die Rollen der allgemeinen Akteure übernehmen.

Zum Beispiel gibt es einen Sachbuch-Händler (Akteur B) und einen Unterhaltungsliteratur-Händler (Akteur C). Beide verfügen über Eigenschaften, die sie sich teilen. Also können Sie den allgemeinen Akteur Buchhändler (Akteur A) definieren, auf den B und C zeigen.

Generalisierungsbeziehung zwischen Akteuren in einem Use Case Diagramm in objectiF RPM

Download Use Case Handbuch Whitepaper

Wissen zum Mitnehmen

Alles zu Use Cases kompakt

PDF zum Download »

Mehr Downloads rund ums Thema

  • Whitepaper
  • Tipps & Tricks
  • Software

Zum Downloadcenter »

Vorteile von Use Case-Diagrammen zusammengefasst

Use Case-Diagramme sind hervorragende Mittel, um:

Systeme aus der Sicht der Anwender zu betrachten,

verschiedene Blickwinkel auf das System und die Anforderungen zu erhalten,

geeignete Anforderungen abzuleiten,

Testfälle abzuleiten

und dadurch das System für die Anwender richtig zu entwickeln.

Vorteile von Use Case-Diagrammen nutzen

Mit Use Case-Diagrammen schaffen Sie einen Blick auf Ihr System, der die ideale Grundlage für das Finden und Definieren Ihrer Anforderungen bildet. Denn Sie können sich damit besser in die Lage Ihrer Anwender versetzen und Lösungen für deren spezifischen Problemstellungen finden. Setzen Sie ein Tool ein, mit dem sich ganz einfach Anwendungsfälle erstellen und in einem Use Case-Diagramm mit Akteuren und anderen Use Cases verbinden lassen. Mit klaren visuellen Mitteln definieren Sie Kommunikations-, Generalisierungs-, include- und extend-Beziehungen oder spezifizieren die Erweiterungspunkte eines Anwendungsfalls. Und falls Sie gleich Personas mit Akteuren verbinden oder auch Testfälle für die Use Cases anlegen wollen, können Sie diese ebenfalls in Ihrem Use Case-Diagramm integrieren. So haben Sie alles auf einen Blick.