1

2. Use Cases

Anwendungsfälle, Szenarien

Anwendungsfall-Beschreibungen

2

Definition

Ein Use Case (Anwendungsfall)

beschreibt einen einzelnen Arbeitsgang eines oder mehrerer Akteure mit einem System aus der Sicht des Anwenders

hat als Namen möglichst ein aktives Verb, welches die Tätigkeit beschreibt

wird mit Hilfe einer Ellipse grafisch dargestellt.

Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt).Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel „Daten erfassen“, „Adresse ändern“, „Auto reservieren“, „Konto löschen“, … (oder Verb/Subjekt in anderen Sprachen: „change address“).Häufig sind die (System-) Anwendungsfälle die computerunterstützten Teile der Geschäftsprozesse.

Use Cases

3

Verwendung

Use Case Diagramme werden sehr früh im Analyse Prozess verwendet um

die verschiedenen Benutzerrollen/Anwender und deren Aufgaben (Wünsche, Rechte) auf hohem Abstraktionsniveau festzulegen

mit dem Kunden die (Haupt-)Aufgaben des Systems zu skizzieren

mit dem Kunden die Systemgrenzen zu definieren

Schnittstellen

was ist nicht Aufgabe des Systems

Es werden mit dem Use Case Diagramm aber keine Abläufe und kein Verhalten beschrieben.

Use Cases

4

Use Case Diagramm

stellt Beziehungen zwischen Akteuren und Anwendungsfällen aus Sicht der Akteure dar

beschreibt grob, was das System leisten soll

beschreibt einen Ablauf, ist aber keine Ablaufbeschreibung

Black Box Sicht

es wird keine Reihenfolge definiert

kann ev. später verfeinert, präzisiert werden

Die einzelnen primären Use Cases sind möglichst unabhängig voneinander

Die einzelnen Use Cases können später noch verfeinert und aufgegliedert werden.Kunde erfassen --> Name erfassen, Geburtsdatum erfassen, Rechnungs-Adresse erfassen, Liefer-Adresse erfassen, …Das Use Case Diagramm beschreibt nicht, wie die Umsetzung oder Realisierung dieser Use Cases geschehen soll. Zur Ablaufbeschreibung von Use Cases dienen Verhaltens- oder Interaktionsdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, …)

Use Cases

5

Use Cases dienen nicht

… zum Beschreiben der Benutzeroberfläche

… zum Festlegen der System Architektur

… zum Erklären von komplizierten Abläufen

… zum Definieren von Objekten oder Zuständen

… zum Definieren von nicht funktionalen Anforderungen

Das Use Case Diagramm ist vorwiegend ein Hilfsmittel zur Anforderungsermittlung mit dem Anwender

Es dient nicht der Verhaltensbeschreibung oder dem Systemdesign

Das Use Case Diagramm kann helfen, die verschiedenen benötigten Masken anzudenken. Diese werden aber nicht hier definiert. Es sollen keine Details der Benutzeroberfläche (wie z.B. eine Save-Taste, welche zum Speichern gedrückt werden soll) vorweggenommen werden.

Im Zentrum steht allein der Nutzen des Systems für den Benutzer.

Use Cases

6

Typen von Anwendungsfällen

Business Use Case (Geschäftsanwendungsfall)

Ferien planen, Filme verleihen, Event organisieren, …

Primärer Use Case (Systemanwendungsfall)

Kunden, Bestellungen, Informationsmaterial, Kosten, … erfassen, ändern, löschen, berechnen, …

Sekundärer Use Case

Kunde suchen, Lagerbestand prüfen, Rechnungs-Ausstände auflisten, …

Ein Geschäftsanwendungsfall beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders. Aus einem fachlichen Geschäftsanwendungsfall (Ferien planen) können sich mehrere konkrete Systemanwendungsfälle ergeben (Hotelzimmer reservieren, Flug buchen, Informationsmaterial bereitstellen, …) Der Systemanwendungsfall bündelt alle möglichen Fälle (Szenarien), die eintreten können, wenn ein Akteur versucht, ein bestimmtes Ziel zu erreichen (Kundendaten erfassen, Konto eröffnen, Bestellung bearbeiten, …). Man spricht hier oft auch von einem primären Anwendungsfall.Sekundäre Anwendungsfälle sind normalerweise Teil eines anderen Systemanwendungsfalls und haben keine eigenes unabhängiges Ziel (Hilfs-Aufgaben).Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen.

Use Cases

7

Akteure

Akteure sind beteiligte Personen oder Systeme

Anwender, Kunde, Mieter, Uhr, System, …

Man unterscheidet

Primäre Akteure

die eigentlichen Benutzer des Systems

Sekundäre Akteure

welche das System überwachen oder warten

oder den Primärakteur bei seiner Arbeit unterstützen

Akteure werden mit ihrer Rolle beschriftet

<< Actor>>

PrintingSystem

Ein Akteur (actor) ist eine an verschiedenen Use Cases beteiligte, aber außerhalb des zu realisierenden Systems agierende Einheit. Normalerweise ist ein Akteur ein Mensch, ein technisches System oder ein Ereignis.Akteure werden nicht personifiziert, relevant ist nur ihre Rolle in diesem Umfeld.Akteure können untereinander Generalisierungs- oder Spezialisierungs-Beziehungen haben.

Akteure werden normalerweise als Strichmännchen, Zeitereignis-Akteure manchmal auch als Uhr, Fremdsystem Akteure als Würfel oder als Box gezeichnet.

Akteure können eine Multiplizität haben. Diese gibt an, wie viele Akteure der angegebenen Rolle am Anwendungsfall beteiligt sein müssen (Default Wert: 1).Auf der Seite des Anwendungsfalls gibt die Multiplizität an, wie oft dieser Anwendungsfall gleichzeitig ausgeführt werden darf (Default Wert: 0..1).

Use Cases

8

Systemgrenzen /Systemkontext

Die Systemgrenze, bzw. der Systemkontext zeigt auf, welche Aufgaben zum System gehören und welche Aufgaben durch Fremdsysteme realisiert werden, bzw. welche Schnittstellen realisiert werden müssen.

Jeder Akteur und jedes Fremdsystem benötigt eine Schnittelle zum System. Bei menschlichen Akteuren braucht es ein User Interface, andernfalls muss das nötige technische Interface bestimmt werden.

Use Cases

9

Assoziation

Eine Assoziation beschreibt eine Relation zwischen dem Akteur und einem Anwendungsfall

Die Multiplizität beim Akteur gibt an, wie viele Akteure beteiligt sein müssen oder können

Die Multiplizität beim Anwendungsfall gibt an, wie oft dieser vom Akteur gleichzeitig ausgeführt werden darf

Ein Richtungspfeil zeigt an, dass der Waiter der «Empfänger» des Anwendungsfalls ist (gerichtete Assoziation)

Fehlen die Multiplizitätsangaben, geht man von den Default-Werten 1 beim Akteur und 0..1 beim Anwendungsfall aus.

Use Cases

10

Include Beziehung

Ein Anwendungsfall kann (logischer) Teil eines anderen Anwendungsfalls sein

Die Pfeilrichtung zeigt auf den enthaltenen Anwendungsfall, die Beziehung wird mit «include» bezeichnet.

Der enthaltene Anwendungsfall ist oft ein sekundärer Anwendungsfall (vgl. Beispiel oben). Sekundäre Anwendungsfälle werden nur indirekt, durch einen primären Anwendungsfall benutzt.Ein Systemanwendungsfall kann aber ebenfalls in einer Include Beziehung zu einem anderen Anwendungsfall stehen.Beispiel: Der Gast möchte etwas essen (und trinken) oder nur etwas trinken.

Use Cases

11

Extend Beziehung

Diese drückt aus, dass ein Anwendungsfall unter gewissen Bedingungen durch einen anderen Anwendungsfall erweitert wird

Die Pfeilrichtung zeigt auf die zu erweiternde Basisanwendung und wird mit «extend» bezeichnet

Die Erweiterung ist von einer Bedingung abhängig, diese muss angegeben werden. Die Bedingung (Erweiterungspunkt, extension point) wird als Notiz neben den Anwendungsfall geschrieben.Vorsicht! Die umgekehrte Pfeilrichtung im Diagramm gibt oft zu Fehlern Anlass.

Eine andere Schreibweise erlaubt das Anbringen der Bedingungen im Use Case selber. Dies ist aber unübersichtlich und darum nicht empfehlenswert.

Use Cases

12

Vererbung/Spezialisierung

Beispiele

Mittagessen einnehmen

Vorspeise/Hauptspeise/Dessert essen

Kundendaten ändern

Name, Adresse, Kundenstatus ändern

Eine Generalisierung oder Vererbung (engl. Generalization) kann in Anwendungsfalldiagrammen zwischen Akteuren oder Anwendungsfällen modelliert werden und definiert eine Beziehung zwischen einem spezifischen (spezialisierten) und einem allgemeinen (abstrakten) Element.

Use Cases

13

Vererbung/Spezialisierung

Die Mitarbeiter einer Firma mit deren verschiedenen Rollen (und Rechten).

Die Vererbung von Use Cases wird relativ selten verwendet. Häufiger findet man die Vererbung/Spezialisierung auf der Seite der Akteure, um damit die Rechte der Akteure (welche Rolle darf was) zu spezifizieren.

Use Cases

14

Checkliste für Use Cases

Ist bei jedem Use Case mindestens ein Akteur beteiligt?

Repräsentiert der Akteur eine klare Rolle oder ein klar definiertes technisches System?

Enthält der Name des Anwendungsfalls ein Substantiv und ein Verb

Ist der Name des (primären) Anwendungsfalls aus Sicht des Akteurs formuliert?

Sind die Abhängigkeiten (Include, Extend) korrekt?

Ist die Anwendungsfall Beschreibung vollständig?

Jeder Anwendungsfall braucht (direkt oder indirekt) einen Akteur, welchen den Anwendungsfall anstösst.Ein Akteur darf nicht eine konkrete Person sein, sondern muss eine Rolle oder ein System repräsentieren (Customer, Consultant, Assistant, Accountant, …).Der Name des Anwendungsfalls sollte von der Art „Verb Subjekt“ sein, also zum Beispiel „create Account“, „send Message“, „print Report“, …Der Name des Anwendungsfalls sollte so formuliert sein, dass man ihn im der Ablaufbeschreibung direkt benutzen kann: „The system has to create an account, send a message, and print a report“,

Use Cases

15

Use-Case Beschreibung

Eine Anwendungsfall Beschreibung besteht mindestens aus

Name des Anwendungsfalls

Kurzbeschreibung

Akteur

Vorbedingung, Auslöser

Nachbedingung, Resultat, Invarianten

Essenzieller Ablauf, Ausnahmen, Fehler

Offene Punkte

Versionierung (Autor, Datum, Status, …)

Sonstiges, Bemerkungen

Diese Auflistung ist nicht vollständig und nicht Teil von UML. Es bewährt sich, bei der Anwendungsfall Beschreibung gewisse Formalismen einzuhalten, damit nichts Wichtiges vergessen geht.• Ein Auslöser ist eine äusseres Ereignis, das den Anwendungsfall auslöst (z.B. ein Gast möchte etwas Essen). • Eine Vorbedingung beschreibt den Zustand des Systems, bevor der Anwendungsfall eintritt (eintreten kann).• Nachbedingung, Resultat (Ergebnis) ist das, was dem Akteur geliefert wird (z.B. die Bedienung hat die Bestellung entgegen genommen).• Essentielle Schritte sind die einzelnen Ablaufschritte, welche eventuell genauer mit Hilfe eines Verhaltensdiagramms (Zustandsdiagramm, Aktivitätsdiagramm, …) beschrieben werden ( Verweis auf entsprechendes Diagramm).• Ausnahmen, Fehlersituationen (Anwenderfehler, fachliche Fehler, z.B. fehlende Berechtigung, Eingabedaten fehlen, …).

Weitere mögliche Angaben sind:• Invarianten (Bedingungen, welche stets erfüllt sind/sein müssen).• Nicht funktionale Anforderungen (Plattform Voraussetzungen, qualitative/ quantitative Aussagen, Antwortzeiten, Prioritäten, Häufigkeitsschätzungen, Benutzbarkeit, Änderbarkeit, …).•Eingabedaten wie ID des Gastes oder des Tisches.

Use Cases

16

Beispiel: Use-Case Beschreibung

Ein Use-Case Diagramm enthält zwar rudimentäres Wissen über das System und seine Akteure. Allerdings beschränkt sich die Information bei Use-Case Diagrammen hauptsächlich auf den Namen des Use-Case und die beteiligten Akteure. Für detailliertere Informationen über die Use-Cases benutzt man die Use-Case Beschreibungen. Diese werden üblicherweise in einer Tabelle aufgelistet. Der Inhalt der Use-Case Beschreibung, also die auszufüllenden Felder in der Tabelle können dabei (je nach gewünschtem/nötigem Detaillierungsgrad) variieren.

Im diesem Beispiel sind die essentiellen Inhalte einer Use-Case Beschreibung enthalten. Es zeigt das empfohlene Minimum an Informationen in einer Use-Case Beschreibung.

Use Cases

Beschreibung mit Systemverhalten

Name Geld am Bankomat abheben Systemverhalten

Akteur Kunde

Auslösendes Ereignis

Der Kunde benötigt Bargeld

Kurz-beschreibung

Der Kunde gibt die EC Karte und seinen Pincodeein, dann wählt er den Geldbetrag.

Der gewählte Geldbetrag wird ausgegeben.

Vorbedingung Der Kunde hat eine EC Karte, den Pincode und genügend Kredit auf der Karte.

Der Automat ist in Betrieb

Ablauf - Der Kunde schiebt die Karte ein- Der Kunde gibt den Pincode ein- Der Kunde gibt den Geldbetrag ein

- Der Kunde entnimmt die Karte- Der Kunde entnimmt das Geld

- Die Karte wird geprüft- Der Pincode wird geprüft- Der Geldbetrag wird geprüft- Die Karte wird zurückgegeben- Der Betrag wird ausbezahlt

Ausnahme-verhalten

- Pincode ist falsch

- Zu wenig Kredit für den gewählten Geldbetrag

- Der Automat gibt eine Fehler-meldung aus (max drei Versuche)- Der Automat gibt eine Fehler-meldung aus (max Betrag anzeigen)

172. Use Cases

Beschreibung mit Systemverhalten

Name Getränk am Automat kaufen Systemverhalten

Akteur Kunde

Auslösendes Ereignis

Der Kunde hat Durst

Kurz-beschreibung

Der Kunde wirft Geld in den Automaten ein und wählt ein Getränk aus.

Das gewählte Getränk wird ausgegeben.

Vorbedingung Der Kunde hat Geld (oder Kredit) Das Getränk ist vorhanden und der Automat in Betrieb

Ablauf - Der Kunde wählt das Getränk- Der Kunde bezahlt das Getränk

- Kunde verlangt das Wechselgeld

- Der Betrag wird angezeigt- Der Geldbetrag wird geprüft- Das Getränk wird ausgegeben- Der ev. Differenzbetrag wird ausbezahlt.

Ausnahme-verhalten

- Zu wenig Geld für die Wahl eingegeben - Der Automat gibt eine Fehler-meldung aus

182. Use Cases

Beschreibung mit SystemverhaltenName Getränke nachfüllen Systemverhalten

Akteur Administrator

Auslösendes Ereignis

Sensor meldet leeres Gerät

Kurz-beschreibung

Der Administrator öffnet das Gerät, stellt den Alarm zurück und füllt die leeren Behälter.

Vorbedingung Der Administrator hat die Zugriffsrechte und Ersatz-Getränke (-Pulver).

Der Automat ist in Betrieb

Ablauf - Der Administrator schiebt den Badge ein

- Der Administrator öffnet die Getränke-Behälter- Der Administrator füllt die Behälter - Der Administrator schliesst die Behälter

- Der Administrator schliesst die Türe

- Die Türe wird entriegelt- Der Alarm wird zurückgestellt

- Ein Sensor prüft jeweils den Füllstand

Ausnahme-verhalten

- Ein Füllstand-Sensor zeigt immer noch leer - Der Automat gibt eine Fehler-meldung aus

192. Use Cases

20

Use Case Description in Astah

Wir können die Use Case Beschreibung direkt in Astah erfassen und später in ein Excel Sheet exportieren lassen.

Es empfiehlt sich zuerst festzulegen, welche der vorhin aufgelisteten Punkte in unserer Use Case Beschreibung verwendet werden sollen.

Use Cases

21

Use-Case Szenarien

Ein Szenario beschreibt eine Abfolge von Schritten, die vom Use Case zu durchlaufen sind.

Normalabläufe zeigen auf, wie der Anwendungsfall "normalerweise" (erfolgreich) abläuft.

Alternativabläufe zeigen "andere" Wege zum Ziel auf, als dies im Normalablauf dargestellt wird.

Ausnahmeabläufe führen nicht zum Ziel, z.B. infolge eines "fachlichen Fehlers" oder bei einem Abbruch durch den Akteur.

Als Test werden für jeden Anwendungsfall sogenannte Szenarien erstellt. In diesen wird ein konkreter Vorgang (mit konkreten Werten) detailliert beschrieben, und zwar so wie der Benutzer ihn am Ende im System durchführen wird (Benutzer-Interaktion). Es kann für einen Anwendungsfall mehrere Szenarien (für alle Varianten von Abläufen) geben. Szenarien dienen dazu, den Anwendungsfall detailliert und aus verschiedenen Perspektiven zu betrachten. So wird verhindert, dass wichtige Funktionen des Systems übersehen werden. Aus den Szenarien können auch direkt die Test-Fälle für diesen Use Case abgeleitet werden.

Use Cases

22

Use-Case Szenarien

Gast Peter Muster möchte gerne im Restaurant etwas konsumieren.

Actor Precondition Post condition Result

Guest Peter

Peter is sitting at a table in the restaurant and is hungry

Peter has placed his meal order with the waiter

success

Guest Peter

Peter is sitting at a table in the restaurant and is not hungry

Peter has placed his beverage order with the waiter

success

Guest Peter

Peter is sitting at a table in the restaurant and is hungry. One of the selected menu points is not available.

Peter has not placed his order.

detour

Use Case Szenarien dienen als Grundlage für Ablauf-Tests. Falls hier alle möglichen Ablaufe genau dokumentiert sind, kann der Tester daraus die Testfälle ablesen und entsprechend implementieren/durchführen.

Use Cases

23

Beispiel: Bank

Erster Schritt: Mind Map und Use Cases

24

Anforderungen

Eine Person wird Kunde, indem sie ein Privatkonto eröffnet. Ein Kunde kann beliebig viele weitere Privat-oder Sparkonten eröffnen.

Für jeden neuen Kunden werden dessen Name, Vorname, Geburtstag und seine Adresse erfasst.

Beim Eröffnen des ersten Privatkontos werden dem Neukunden darauf CHF 10.- gutgeschrieben.

Bei jeder weiteren Kontoeröffnung muss der Kunde sofort eine Einzahlung darauf vornehmen.

Privatkonten dürfen bis zu einem bestimmten Betrag überzogen werden. Sparkonten dürfen nicht überzogen werden.

Use Cases

25

Anforderungen

Für jeden Kontotyp wird ein Habenzins, für Privatkonten ein Sollzins festgelegt. Ausserdem besitzt jedes Konto eine eindeutige Kontonummer.

Jedes Sparkonto hat einen Typ: Jugend, Senioren, Festgeld oder normales Sparkonto.

Ein Kunde kann Geld abheben oder einzahlen oder Überweisungen auf andere Konten vornehmen.

Die Bank kann ein Privatkonto, dessen Saldo zu stark negativ ist, sperren.

Es werden bei allen Konten Habenzinsen gutgeschrieben und bei Privatkonten Sollzinsen abgebucht.

Use Cases

26

Anforderungen

Um die Zinsen berechnen zu können, muss für jede Kontobewegung das Datum und der Betrag notiert werden.

Die Gutschrift / der Abzug der Zinsen erfolgt bei den Sparkonten jährlich und bei den Privatkonten quartalsweise.

Ein Kunde kann jedes seiner Konten wieder auflösen.

Bei der Auflösung des letzten Kontos wird der Kunde inaktiv und nach einiger Zeit aus dem System gelöscht.

Use Cases

27

Banken Applikation: Mind-Map

Use Cases

28

Banken Applikation: Use Cases

Use Cases