Kapitel 2: Das Use-Case-Diagramm

Ziele setzen und klar definieren

Das Ziel jedes Softwareentwicklungsprozesses ist es, eine Software zu entwickeln, die ganz bestimmte Anforderungen erfüllt. Die Entwicklung einer Software fängt mit der Zielsetzung an: Die Software soll, wenn fertiggestellt, die zu Beginn des Entwicklungsprozesses festgelegten Anforderungen erfüllen. Niemand entwickelt Software grundlos und wartet darauf, dass zufällig eine für irgendetwas brauchbare Software vor seinen Augen entsteht. Es gibt immer Ziele, die erreicht werden sollen.

Leider sind diese Ziele nicht immer klar definiert. Man nimmt sich zum Beispiel vor, einen Online-Shop zu entwickeln, und stellt dann während des Entwicklungsprozesses fest, dass es unendlich viele unterschiedliche Funktionen in einem Online-Shop geben kann und man sich eigentlich nie klar gemacht hat, was man denn nun für Funktionen im Detail braucht. Man muss den Entwicklungsprozess daher wiederholt unterbrechen und inne halten, um sich zu überlegen, welche Funktionen, die einem bei der Entwicklung gerade eingefallen sind, notwendig sind und welche nicht.

Besonders schwierig wird die Situation, wenn der Auftraggeber des Entwicklungsprozesses nicht gleichzeitig der Entwickler ist. In diesem Fall kann der Entwickler nicht entscheiden, welche Funktionen notwendig sind - dies weiß nur der Auftraggeber. Dies führt zu einem ständigen Frage-Antwort-Spiel zwischen Entwickler und Auftraggeber, wenn der Entwickler nicht - noch schlimmer - die Entscheidungen selbst trifft und hofft, dies jeweils im Sinne des Auftraggebers zu tun.

Wenn Anforderungen an die zu entwickelnde Software nicht zu Beginn des Entwicklungsprozesses klipp und klar sind, wird der Entwicklungsprozess an sich unnötig erschwert. Denn das, was Sie entwickeln, richtet sich nach den bekannten Anforderungen. Jede Anforderung, die Ihnen oder Ihrem Auftraggeber später einfällt, führt dazu, dass Sie das, was Sie bisher entwickelt haben, ändern müssen. Denn die neue Anforderung hatten Sie logischerweise in Ihrer bisherigen Entwicklung nicht berücksichtigt. Grundsätzlich gilt, dass je später Anforderungen in einem Entwicklungsprozess bekannt werden, umso aufwändiger und daher teurer der Entwicklungsprozess wird. Anders gesagt: Wenn alle Anforderungen von Anfang an bekannt sind, bevor der Entwicklungsprozess gestartet wird, wäre das ideal.

In diesem Kapitel sehen wir uns an, wie wir mit Anforderungen umgehen und sie auf den Kopf stellen, um uns in eine ideale Ausgangsposition für die anschließende Entwicklung der Software zu bringen. Im Zusammenhang mit Anforderungen setzen wir als erstes Hilfsmittel Use-Case-Diagramme ein.

Der Akteur und das System

Aufgabe des Use-Case-Diagramms ist es, eine grobe Ordnung in die vielen zum Teil sehr detaillierten Anforderungen zu bringen. Das Use-Case-Diagramm soll uns einen Überblick über das verschaffen, was die zu entwickelnde Software eigentlich im Wesentlichen können muss. Es werden also wichtige Funktionen der Software herausgearbeitet und zueinander in Beziehung gesetzt. Die technische Implementierung spielt bei diesem Überblick keine Rolle - vergessen Sie alles, was irgendetwas mit Programmiersprachen zu tun hat. Es geht um das Was, nicht um das Wie.

Das Use-Case-Diagramm ist ein recht einfacher Diagrammtyp, der schön anschaulich ist. Im Folgenden sehen Sie die grundlegenden Bausteine, mit denen alle Use-Case-Diagramme aufgebaut sind.

Im Use-Case-Diagramm gibt es den Akteur und das System. Der Akteur ist der Anwender, das System die zu entwickelnde Software. Im System, das als Rechteck dargestellt wird, werden verschiedene wesentliche Anforderungen platziert. Man schreibt hierzu sehr knappe Funktionsbeschreibungen in Ellipsen, wobei jede Ellipse genau eine Funktion darstellt. Die Ellipsen sind die Use-Cases - daher hat das Use-Case-Diagramm seinen Namen. Wenn Sie einen deutschen Begriff verwenden möchten: Use-Case wird für gewöhnlich mit Anwendungsfall übersetzt.

Da es beim Use-Case-Diagramm um einen ersten groben Überblick geht, beschränkt man sich auf die Darstellung wesentlicher Funktionen - alles, was nicht zum Überblick beiträgt, wird weggelassen. Beim Erstellen eines Use-Case-Diagramms geht es also nicht darum, möglichst viele Ellipsen in das Rechteck zu malen. Es geht darum, wesentliche Anforderungen zu finden und diese zusammenhängend als Use-Cases in das System einzuzeichnen.

Die Zusammenhänge zwischen Use-Cases und dem Akteur als auch zwischen Use-Cases untereinander werden durch Verbindungslinien dargestellt.

Verbindungslinien in UML-Diagrammen werden Assoziationen genannt. Sie stellen Zusammenhänge zwischen Elementen an den Enden von Assoziationen dar. Welche Art von Assoziation ausgedrückt wird, hängt von der Darstellung der Verbindungslinie und von Schlüsselwörtern ab, die an der Verbindungslinie stehen können.

Im Use-Case-Diagramm gibt es zwei Arten von Verbindungslinien: Die durchgezogene Verbindungslinie stellt eine Assoziation zwischen dem Akteur und einem Use-Case dar. Sie bedeutet, dass der Akteur den Use-Case in irgendeiner Form anwendet. Der Akteur tauscht also Informationen mit dem Use-Case aus. Das kann zum Beispiel bedeuten, dass er eine Funktion des Systems startet oder ihm von einer Funktion des Systems Daten ausgegeben werden.

Die gestrichelte Verbindungslinie stellt eine Assoziation zwischen zwei Use-Cases dar. Da es zwei verschiedene Arten von Assoziationen zwischen Use-Cases gibt, wird neben die gestrichelte Verbindungslinie ein Schlüsselwort gesetzt. Schlüsselwörter in der UML, die zur Spezifizierung von Verbindungslinien oder anderen geometrischen Formen verwendet werden, werden immer zwischen doppelte spitze Klammern gestellt. Diese Schlüsselwörter werden in der UML Stereotypen genannt.

Eine include-Assoziation bedeutet, dass der Use-Case, von dem die Verbindungslinie ausgeht, den Use-Case einschließt, auf den die Verbindungslinie zeigt. Im obigen Beispiel wird also immer dann, wenn der Use-Case A ausgeführt wird, von diesem Use-Case ausgehend der Use-Case B gestartet. Das heißt, dass irgendwann mitten in der Ausführung des Use-Case A der Use-Case B zu laufen beginnt. Wenn der Use-Case B dann beendet ist, setzt die Ausführung des Use-Case A fort.

Eine extend-Assoziation bedeutet, dass der Use-Case, von dem die Verbindungslinie ausgeht, möglicherweise den Use-Case erweitert, auf den die Verbindungslinie zeigt. Der entscheidende Unterschied zwischen einer include- und extend-Assoziation ist also, dass bei der include-Beziehung der zweite Use-Case immer ausgeführt wird, bei der extend-Assoziation der zweite Use-Case in Abhängigkeit von Bedingungen im ersten Use-Case ausgeführt wird. Für das obige Beispiel bedeutet das, dass der Use-Case D dann ausgeführt wird, wenn bestimmte Bedingungen im Use-Case C wahr sind.

Da die Ausführung bei einer extend-Assoziation von Bedingungen abhängt, müssen diese in irgendeiner Form im UML-Diagramm angegeben werden können. Im Folgenden sehen Sie eine extend-Assoziation einschließlich einer Bedingung und eines sogenannten Erweiterungspunkts.

Im obigen Beispiel ist der Use-Case C um einen Erweiterungspunkt X ergänzt worden. Hinter X kann eine Beschreibung des Erweiterungspunkts angegeben werden. Ein Use-Case kann beliebig viele Erweiterungspunkte und daher auch beliebig viele extend-Beziehungen besitzen.

An extend-Verbindungslinien wird ein Notizzettel geklebt - das entsprechende Rechteck sieht in der UML dank Eselsohr tatsächlich wie ein Notizzettel aus. Auf diesem Notizzettel wird hinter Condition in geschweiften Klammern die Bedingung angegeben, die wahr sein muss, damit der verbundene Use-Case ausgeführt wird. Ob Sie die Bedingung mit wenigen Worten beschreiben oder mit einem Vergleichsoperator in einer Programmiersprache ausdrücken, bleibt Ihnen überlassen. Der Sinn aller UML-Diagramme ist es, übersichtlich und hilfreich zu sein. Verwenden Sie die Ausdrucksweise für Bedingungen, die für Sie am nützlichsten ist.

Im Notizzettel wird hinter Extension Point außerdem angegeben, mit welchem Erweiterungspunkt diese extend-Verbindungslinie zusammenhängt. Diese Angabe ist notwendig, da ein Use-Case wie beschrieben mehrere extend-Verbindungslinien besitzen kann. In der Praxis können Erweiterungspunkte und Bedingungen jedoch meist recht einfach zugeordnet werden, da Bedingungen häufig den Erweiterungspunkt in irgendeiner Form aufgreifen. Sie werden dies in einem der folgenden Beispiele sehen.

Damit sind die wichtigsten Bausteine des Use-Case-Diagramms erklärt, so dass sie nun im Zusammenhang mit der Entwicklung unseres Online-Shops eingesetzt werden können.

Der Online-Shop aus Sicht des Kunden

Aus den Anforderungen, die uns zum Online-Shop vorliegen, könnte man folgendes erstes Use-Case-Diagramm erstellen.

Obiges Use-Case-Diagramm enthält fünf Use-Cases. Die Use-Cases sind in einem Rechteck eingezeichnet, das die Beschriftung Online-Shop trägt. Dieses Rechteck stellt das System dar. Da man ein System aufteilen kann, um dann einzelne Subsysteme zu beschreiben, macht es Sinn, Rechtecke zu beschriften. Andernfalls haben Sie am Ende lauter Rechtecke und können nicht auf den ersten Blick erkennen, was sie eigentlich genau darstellen.

Links vom Rechteck befindet sich ein kleines Strichmännchen: Der Akteur. Akteure werden immer in Form eines Strichmännchens dargestellt. Da es verschiedene Akteure geben kann, wie Sie im Folgenden noch sehen werden, müssen wir auch die Akteure beschriften. Das Strichmännchen im obigen Use-Case-Diagramm stellt den Kunden dar. Das heißt also, dass obiges Use-Case-Diagramm den Online-Shop aus Sicht des Kunden beschreibt.

Beachten Sie, dass Akteure immer außerhalb von Rechtecken stecken. Sie gehören nicht zum System, sondern interagieren mit dem System. Sie tauschen in irgendeiner Form Informationen mit dem System aus und stehen daher außerhalb der Systemgrenzen.

Was sagt nun obiges Use-Case-Diagramm aus? Im obigen Use-Case-Diagramm wird der Online-Shop als ein System beschrieben, das einem Kunden fünf wesentliche Funktionen bietet: Ein Kunde kann für eine Bestellung Artikel auswählen, eine Anschrift eingeben, eine Zahlungsmethode wählen, Daten für die Bezahlung eingeben und die Bestellung absenden.

Ein Kunde kommt mit jedem dieser fünf Use-Cases in Kontakt, wie Sie an den Verbindungslinien zwischen dem Akteur und den fünf Ellipsen sehen können. Der Kunde gibt jeweils irgendwelche Daten ins System ein oder bekommt Daten vom System angezeigt.

Eine include-Assoziation zum Überprüfen der Anschrift

Dass es zwischen jedem Use-Case und dem Akteur Assoziationen gibt, muss nicht sein. Sehen Sie sich folgende Erweiterung unseres Use-Case-Diagramms an.

Das Use-Case-Diagramm umfasst nun zusätzlich eine Funktion, um die vom Kunden eingegebene Anschrift auf Vollständigkeit und Richtigkeit zu überprüfen. Wenn Sie sich die Beschreibung des Online-Shops ansehen, finden Sie eine entsprechende Anforderung: Kundendaten sollen auf Vollständigkeit und Richtigkeit überprüft werden. Wir könnten dort zum Beispiel überprüfen, ob die Postleitzahl zum Land passt: Wer sich seine Bestellung zum Beispiel nach Holland schicken lassen möchte, muss eine vierstellige Postleitzahl angeben.

Zwischen dem Akteur und der Ellipse mit der Beschriftung Anschrift überprüfen gibt es keine Verbindungslinie. Immerhin wird die Anschrift nicht dann überprüft, wenn der Kunde es wünscht und zum Beispiel auf eine entsprechende Schaltfläche im Online-Shop klickt. Die Anschrift wird immer dann automatisch vom System überprüft, wenn ein Kunde eine Anschrift eingegeben hat. Die Verbindungslinie wird daher zwischen den beiden Ellipsen Anschrift eingeben und Anschrift überprüfen gezogen.

Die Verbindungslinie wird mit dem Stereotyp include spezifiziert. Das bedeutet also, dass wann immer der Use-Case Anschrift eingeben ausgeführt wird, dies die Ausführung des Use-Case Anschrift überprüfen einschließt. Alle Anschriften, die Kunden im Online-Shop eingeben, werden also grundsätzlich immer überprüft.

Eine extend-Assoziation für den Bankeinzug

Sehen Sie sich folgendes erweiterte Use-Case-Diagramm an, das eine extend-Verbindungslinie enthält.

Der Use-Case Daten für Bezahlung eingeben ist nun nicht mehr mit dem Akteur verbunden. Stattdessen gibt es eine Verbindungslinie zum Use-Case Zahlungsmethode wählen. Diese Assoziation ist mit dem Stereotyp extend gekennzeichnet.

Wie Sie von den Anforderungen an den Online-Shop wissen, wählt der Kunde während des Bestellvorgangs eine Zahlungsmethode aus. Bisher sind wir im Use-Case-Diagramm davon ausgegangen, dass er nach seiner Wahl immer Daten für die Bezahlung eingeben muss. Das trifft aber genaugenommen nicht zu: Entscheidet sich der Kunde, die Bestellung per Nachnahme oder Vorauskasse zu bezahlen, benötigen wir keine weiteren Daten von ihm. Lediglich bei einem Bankeinzug müssen wir wissen, von welchem Konto eigentlich das Geld eingezogen werden soll. Das heißt, nur bei der Wahl des Bankeinzugs benötigen wir weitere Daten zur Bezahlung.

Use-Cases, die in Abhängigkeit bestimmter Bedingungen ausgeführt werden, werden durch eine extend-Assoziation an den Use-Case angehängt, in dem die entsprechenden Bedingungen überprüft werden. Das heißt für obiges Use-Case-Diagramm: Der Use-Case Daten für Bezahlung eingeben wird nur dann ausgeführt, wenn im Use-Case Zahlungsmethode wählen der Bankeinzug gewählt wurde. Der Use-Case Daten für Bezahlung eingeben erweitert in diesem Fall den Use-Case Zahlungsmethode wählen, weshalb die Pfeilspitze der Verbindungslinie auf den Use-Case Zahlungsmethode wählen zeigt.

Im Use-Case Zahlungsmethode wählen gibt es einen Erweiterungspunkt, der Bankeinzug heißt. Dieser Erweiterungspunkt ist mit dem einzig angehängten Use-Case Daten für Bezahlung eingeben verbunden. An der Verbindungslinie hängt ein Notizzettel, auf dem zwei wichtige Informationen stehen: Hinter dem Schlüsselwort Condition ist die Bedingung in geschweiften Klammern angegeben, die wahr sein muss, damit der Use-Case erweitert wird. Und hinter dem Schlüsselwort Extension Point ist der Erweiterungspunkt angegeben, mit dem diese Bedingung und der Use-Case zusammenhängen. Auf diese Weise soll die Übersicht nicht verloren gehen, wenn Sie mehr als einen Erweiterungspunkt haben und zahlreiche andere Use-Cases als Erweiterung genutzt werden.

Der Online-Shop aus Sicht des Distributors

Sehen Sie sich nun folgendes Use-Case-Diagramm an und versuchen Sie, es zu verstehen.

Dieses Use-Case-Diagramm stellt den Online-Shop aus Sicht des Distributors dar - also desjenigen, der die Bestellungen tatsächlich ausliefert. Um an die entsprechenden Kunden- und Bestelldaten zu kommen, muss er sich im Online-Shop erstmal anmelden: Der Use-Case Benutzernamen und Passwort eingeben beschreibt dieses Login.

Über eine include-Assoziation ist der Use-Case Zugriffsberechtigung überprüfen mit dem Use-Case Benutzernamen und Passwort eingeben verbunden. Das bedeutet, dass bei jedem Login die Zugriffsberechtigung überprüft wird - sonst würde das Login auch nicht viel Sinn haben.

Darüberhinaus kann der Distributor Kunden- und Bestelldaten herunterladen. Der entsprechende Use-Case schließt mit einer include-Assoziation den Use-Case Daten im richtigen Format bereitstellen ein. Wenn Sie sich die Anforderungen zum Online-Shop in Erinnerung rufen: Distributoren arbeiten mit unterschiedlichen Softwaresystemen, so dass Kunden- und Bestelldaten im jeweils geeigneten Format weitergegeben werden müssen, das der Distributor verarbeiten kann.

Anforderungen und ihre Zusammenhänge ohne Berücksichtigung der Reihenfolge

Use-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. Wie Sie nun gesehen haben, können im Use-Case-Diagramm wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen. Das geht im eingeschränkten Maße mit include- und extend-Assoziationen. Da ein Use-Case in diesen Fällen aber jeweils vom anderen Use-Case eingeschlossen wird - bei include immer, bei extend in Abhängigkeit einer Bedingung - handelt es sich nicht um eine strikte Reihenfolge: Ein Use-Case, der einen anderen mit include oder extend einschließt, läuft nach Beendigung des eingeschlossenen Use-Case weiter. Wir haben deswegen keine Möglichkeit, im obigen Use-Case-Diagramm anzugeben, dass Kunden- und Bestelldaten nur dann heruntergeladen werden dürfen, wenn die Zugriffsberechtigung gegeben ist. Eine extend-Assoziation zwischen den beiden Use-Cases Zugriffsberechtigung überprüfen und Kunden- und Bestelldaten downloaden einzufügen macht keinen Sinn, da Kunden- und Bestelldaten downloaden dann in den Use-Case Zugriffsberechtigung überprüfen eingeschlossen werden würde. Das Herunterladen von Kunden- und Bestelldaten hat aber grundsätzlich nichts mit dem Überprüfen einer Zugriffsberechtigung zu tun.

Dieser Nachteil des Use-Case-Diagramms ist an sich kein Nachteil, da Use-Case-Diagramme nicht für die Beschreibung einer Reihenfolge von Abläufen vorgesehen sind. Es ist also wichtig zu verstehen, dass jedes Diagramm bestimmte Aspekte eines Systems hervorhebt und beschreibt, aber nie alle. Es ist nicht die Aufgabe des Use-Case-Diagramms, die Reihenfolge einer Ausführung zu beschreiben. Zu diesem Zweck kann ein anderer Diagrammtyp verwendet werden, den Sie im nächsten Kapitel kennenlernen werden.