Untitled

Werbung
1
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
2
Es werden mit dem Use Case Diagramm aber keine Abläufe und kein Verhalten
beschrieben.
Use Cases
3
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
4
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
5
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 (HilfsAufgaben).
Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung
passieren kann und abstrahiert von konkreten technischen Lösungen.
Use Cases
6
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 SpezialisierungsBeziehungen 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
7
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
8
Fehlen die Multiplizitätsangaben, geht man von den Default-Werten 1 beim Akteur
und 0..1 beim Anwendungsfall aus.
Use Cases
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
Es empfiehlt sich zuerst festzulegen, welche der vorhin aufgelisteten Punkte in
unserer Use Case Beschreibung verwendet werden sollen.
Use Cases
17
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 (BenutzerInteraktion).
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
18
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
19
20
Use Cases
21
Use Cases
22
Use Cases
23
Use Cases
24
Use Cases
25
Herunterladen
Explore flashcards