Use Cases
- Definition:
- Strukturiertes Beschreibungsmittel um Informationen rund um fachliche Abläufe rund um ein System zu sammeln
- Sind immer in Aktiv-Form geschrieben ( X tut Y )
- Schritte werden der Reihenfolge nach nummeriert
- Alternativen werden mit Xa. / Xb. / Ya. / Yb. benannt –> Xa1., Xa2., Xa3., etc.
- Bei Alternativen den nächsten Schritt am Ende nicht vergessen!!
- Die Vollständige Sammlung der Use-Cases beschreibt nicht alle Requirements.
- Ein Use-Case sollte niemals mehr als 10 Schritte haben ( ggf. in aufteilen )
- Exakte Formulierungen verwenden (Fachterme anstelle Beschreibung)
- GUI spielt keine Rolle bei dem Entwurf eines Use-Case
- Jeder Use-Case hat die Enden: Erfolg und Misserfolg
- Ein System kann hunderte Use-Cases haben
- Akteure
- Jeder Use-Case hat einen Primary-Actor (interagieren mit dem Case)
- Der Primary-Actor tut die erste Aktion, der Use-Case dreht sich um ihn
- Stakeholder haben berechtigtes Interesse an dem Use-Case ( Geld-abhebender, Kontoinhaber, Bank selbst, Fachabteilung, etc. )
- Bankräuber gehören z.B. nicht dazu
- Primary-Actor ist nicht automatisch Stakeholder ( Call-Center mit System )
- Interessen der Stakeholder sind wichtig bei der Umsetzung der Cases und dem Funktionieren des Systems
- Namen:
- Der Name des Cases umschreibt das Ziel ( bzw. was dabei getan wird )
- Use Case Namen beschreiben immer ein tun „Geld abheben“, „Auto fahren“
- Namen sollten prägnant sein
- Success Guarantees:
- Garantierte Zustände und Ergebnisse nach erfolgreichem Durchlaufen eines Szenarios ( Karte nach Geld abheben zurück bekommen )
- Minimal Guarantees
- Garantierte Zustände und Tätigkeiten bei jedem Durchlaufen des Szenarios
- Trigger
- Auslöser der Use-Cases –> Basic Course folgt
Auslagerung von Teilen bei langen Use-Cases
- Mittel:
- Include ( wie Präprozessodirektiven #include <xyz> )
- Extend ( optionale Komponenten bzw. Abweichung vom Main-Weg )
- Behandlung:
- Beide Mittel werden wie normale Use-Cases behandelt und formuliert
- Müssen in sich stimmig und abgeschlossen sein
- Extend:
- Extended Use-Cases werden mittels Bedingung, Extension Point ( mit Label ) und Rücksprung definiert
- Main-Use Case „weiß“ von der Erweiterung nichts
- Include:
- Wird mittels Verweis hinein geschrieben
- Use-Cases bauen aufeinander auf
- „Ablauf von A geht nicht ohne B“
- Es werden erst die ausgelagerten Teile geschrieben ( z.B.: Authentifizierung )
UML
- Definition:
- Standardisierte Figuren und Vorlagen verwenden
- Abweichungen (z.B.: „Röckchen an Figur malen“) sind verboten!
- Aufbau:
- Rechteck = Komplettes System
- Ellipse = Einzelner Use-Case
- Strich = Verbindung und Zugehörigkeit ( Assoziation )
- Strichfigur = Akteur
- Akteure erhalten eine Beschriftung, die die Rolle darstellt
- Regeln:
- Die Abstraktion trennt den Mensch und die Rolle voneinander ab
- Ein Mensch kann mehrere Rollen haben
- Eine Rolle kann von mehreren Menschen ausgeübt werden
- Der Akteur wird von der Rolle, nicht vom Menschen ausgeführt
Beispiel für Extension/Condition/Return
Arbeitsablauf zur Use-Case-Findung
- Bestimme die Grenzen des Systems (Was geht rein?Was geht raus?)
- Brainstorme und liste die Aktoren
- Brainstorme und liste die Ziele der Aktoren in Bezug auf das System
- Modelliere Use Cases, die das Gefundene zusammenfassen
- Überdenke und verbessere die Use Cases. Füge Ziele hinzu, entferne Ziele und fasse zusammen
- Füge die Stakeholder und deren Interessen hinzu, formuliere Vorbedingungen und Garantien. Überprüfe sie doppelt.
- Schreibe das Haupterfolgsszenario (main success scenario). Vergleiche es mit den Interessen und Garantien
- Brainstorme und liste die möglichen Fehlerbedingungen und die alternativen Erfolgsbedingungen
- 9. Beschreibe wie die Aktoren und das System sich in den Erweiterungen (Extensions / Alternative Courses) verhalten sollen
- Breche jeden Unter Use Case heraus, der eine eigenständige Funktionalität bietet und der von anderen Use Cases benötigt wird
- Beginne vom Anfang und verbessere die Use Cases. Füge hinzu, entferne oder fasse zusammen wenn angebracht. Überprüfe Vollständigkeit, Lesbarkeit und Fehlerbedingungen.
Hausaufgabe:
- Will er über die Ferien zuschicken
- Zuhause zu bearbeiten
- Am besten digital erstellen, damit man es vorstellen kann
Ende Seite 97