Use Case

Use Case
Modellierungsheuristiken und Checklisten
Konstruktiv 1/2

Wer ist Akteur?
z
z
z
z
z
z
z

Use Cases kategorisieren
z

Welche Personen führen diese Aufgaben zur Zeit durch?
Welche Personen führen diese Aufgaben zukünftig durch?
Wer gibt Daten in das SW-System ein?
Wer erhält Ausgaben des Systems?
Bedienen die Akteure das System direkt oder indirekt?
Welche Schnittstellen besitzt das System?
Werden zeitliche Ereignisse modelliert? Akteur „Zeit“ einführen!
Primäre, sekundäre und optionale (Priorität!) Use Cases sowie deren
Stabilität unterscheiden
Standardfall eines Use Cases spezifizieren
Was ist der Standardfall?
z Welche Verarbeitung ist in 80% der Fälle durchzuführen?
z Was ist die einfachste Verarbeitung des Use Cases?
z Welches Ergebnis will der Akteur in den meisten Fällen erhalten?
z

Ablauf eines Use Cases
Wann beginnt der Use Case?
z Welches Ergebnis löst den Arbeitsablauf aus?
z
2
Use Case
Modellierungsheuristiken und Checklisten
Konstruktiv 2/2

Ablauf eines Use Cases
Welche Eingabedaten werden benötigt?
z Ist eine Reihenfolge der Schritte festgelegt?
z Welche Zwischenergebnisse werden erstellt?
z Welche Endergebnisse werden erstellt?
z

Zerlegung kompexer Use Cases
Optionale Teile eines Use Cases (extend-Beziehung)
z Alternative Möglichkeiten (extend-Beziehung)
z Aufgaben, die nur selten durchgeführt werden (extend-Beziehung)
z Gemeinsamkeiten von Use Cases (include-Beziehung)
z

Generalisierung von Use Cases
Ähnliche Use Cases als Spezialisierung eines Basis-Use Cases
z Generalisierung nicht mit extend verwechseln: Spezialisierte Use
Cases sind vollständige Use Cases, extend-Use Cases enthalten nur
zusätzliche Aufgaben
z

Generalisierung von Akteuren
Kommunizieren mehrere Akteure mit dem gleichen Use Case?
z Gilt die ISA-Beziehung zwischen diesen Akteuren?
z
3
Use Case
Modellierungsheuristiken und Checklisten
Analytisch

„Gute“ Beschreibung
Verständlich für den Auftraggeber
z Ein bis maximal zehn Seiten
z

Use Case-Namen
z

Enthalten ein Substantiv (Singular) + Verb
Namen für Akteure
Intuitiv verständlich und der Terminologie des Domains entnommen
z Substantiv im Singular
z Keine konkreten Namen
z

Akteure und Use Cases
Jeder Akteur soll mit mindestens einem Use Case kommunizieren
z Use Cases, die über include oder extend eingebunden sind müssen nicht
direkt mit Akteuren kommunizieren
z

Umfang Use Case-Diagramm
z

Maximal 15-20 Use Cases – bei höherer Anzahl Pakete verwenden
Fehlerquellen
Zu kleine und damit zu viele Use Cases
z Verwechseln von Generalisierung und extend-Beziehung
z Gefahr, dass in einem Use Case-Digramm Abläufe beschrieben werden
z
4
Use Cases
Modellierungsheuristiken und Checklisten
Analytisch - Tests für „nützliche“ Use Cases

Zwei Faustregeln:
z
Der Boss-Test bzw. EBP (Elementary Business Process)-Test
{
{
z
Der Größentest
{
{

Besteht der Use Case nur aus einem einzelnen Schritt?
Häufig benötigt ein vollständig ausgearbeiteter Use Case 3-10 Textseiten!
Beispiel: Welcher dieser Use Cases ist tatsächlich nützlich?
z
Einen Liefervertrag aushandeln
{
z
z
Boss u. EBP u. Größe OK
Anmelden
{
z
Länger und umfangreicher als EBP
Rückgaben abwickeln
{
Boss unglücklich
Eine Figur auf einem Spielfeld verschieben
{

Liefert Use Case Ergebnisse mit messbarem oder beobachtbarem
(geschäftlichen) Wert?
Bleibt ein konsistenter Zustand des Systems bzw. der Daten erhalten?
Einzelner Schritt – Größe nicht OK
Vernünftige Verstöße gegen die Tests
z
Falls z.B. ein vermeintlicher Use Case beim Größentest durchfällt,
allerdings von vielen anderen Use Cases verwendet wird
5

Download Report