Use Case Model - Roggeweck.net

Use Case Model
<Projekt>
Use Case Model ............................................................................................................. 1
<Projekt> ................................................................................................................... 1
1 Überarbeitungen ..................................................................................................... 1
2 Use Cases ............................................................................................................... 1
2.1
Beispiel für „brief format use case“ ............................................................... 1
2.2
Beispiel für „casual format use case“ ............................................................ 1
2.3
Beispiel für „fully dressed use case“ ............................................................. 2
3 System Sequence Diagrams ................................................................................... 7
3.1
UC1: „Abwicklung Verkauf“ ........................................................................ 7
1 Überarbeitungen
Version
Initialer
Entwurf
1.0
Datum
Beschreibung
25.3.2004 Erster Entwurf.
12.4.2004 Erweiterung um System Sequence
Diagrams
Autor
Volkan
Yavuz
Volkan
Yavuz
2 Use Cases
2.1 Beispiel für „brief format use case“
[[Ein Use Case beschreibt in der Sprache/dem Vokabular des Anwenders,
wie eine typische Nutzung des Systems verläuft, mit der Absicht, ein
business goal zu erreichen.]]
Abwicklung Verkauf:
[[Die Verwendung des aktiv stellt sicher, dass Aussagen hinreichend
spezifisch sind; also „Das System erstellt den Beleg“ statt „Ein Beleg
wird erstellt.“]]
Ein Kunde erscheint mit Einkäufen an der Kasse. Der Kassierer verwendet das POSSystem um jeden Artikel zu erfassen. Das System zeigt eine laufende Summe sowie
Details für jeden Artikel an. Der Kunde gibt Zahlungsinformationen an, die das
System überprüft und Festhält. Das System aktualisiert den Bestand. Der Kunde
erhält einen Beleg vom System und verlässt mit den Artikeln das Geschäft.
2.2 Beispiel für „casual format use case“
Abwicklung Rückgabe
Main Success Scenario:
Ein Kunde möchte Artikel zurückgeben. Der Kassierer verwendet das POS system um
jeden Artikel, der zurückgegeben werden soll, zu erfassen...
Alternate Scenarios:
Falls mit EC-Karte bezahlt wurde, und die Rückvergütungstransaktion fehlschlägt,
wird der Kunde informiert und Bar ausgezahlt.
Falls der Artikel über die Artikelnummer im System nicht identifiziert werden kann,
den Kassierer benachrichtigen und die manuelle Eingabe (Preis) ermöglichen.
Falls das System Fehler in der Kommunikation mit dem externen
Buchhaltungssystem feststellt, ...
2.3 Beispiel für „fully dressed use case“
Use Case UC1: Abwicklung Verkauf
Primary Actor:
Kassierer
[[Ein Akteur legt ein Verhalten an den Tag, z.B. eine Person (in einer
bestimmten Rolle), ein Computer System, eine Organisation, etc.]]
[[Der primärer Akteur, der die Systemdienste nutzt, um ein business goal
zu erreichen.]]
[[Der Use Case wird aus der Perspektive des primären Akteurs
beschrieben.]]
Stakeholders and Interests:
[[Identifikation der Stakeholders vor dem Schreiben der Szenarien ist
methodisch sinnvoll um sicherzustellen, dass tatsächlich alle
Anforderungen berücksichtigt sind. Sehr wahrscheinlich wäre die
Protokollierung der Verkaufsprovision in einem ersten Schritt vergessen
worden, wenn „Vertrieb/Vertreter“ nicht in der Liste der Stakeholder
wäre. Details dürfen nur insofern berücksichtigt werden, wie diese zur
Erreichung der Interessen der Stakeholder relevant sind. Dadurch wird
verhindert, dass innerhalb eines Szenarios technische oder
Implementierungsdetails einfließen. ]]
 Kassierer:
o Möchte akkurate und schnelle Erfassung der Artikel und keinerlei
Berechnungsfehler, da fehlende Kassenbeträge von seinem Lohn
abgezogen werden.
 Vertrieb/Vertreter:
o Möchte Verkaufprovision aktualisiert.
 Kunde:
o Möchte Einkauf zügig und mit möglichst geringem Aufwand.
o Möchte Kaufbeleg für eventuelle Rückgaben.
 Geschäft:
o Möchte Verkäufe akkurat dokumentiert und Kundenwünsche
befriedigt.
o Möchte Zahlungsbestätigungen des Payment Authorization Service
protokolliert.
o Möchte Fehlertoleranz, damit Verkaufsvorgänge auch bei nicht
erreichbaren Server-Komponenten (z.B. entfernte Kartenprüfung)
abgeschlossen werden können.
o Möchte automatische und schnelle Aktualisierung der Buchhaltung
und Bestandsverwaltung.


Steuerbehörden:
o Möchte Steuern von allen Verkäufen.
Payment Authorization Service:
o Möchte Zahlungsanfragen im richtigen Format und Protokoll.
o Möchte Zahlungen akkurat protokollieren.
Auslöser (Trigger):
Kunde möchte Artikel kaufen.
Vorbedingung (Preconditions):
[[Relevante Vorbedingungen werden innerhalb des Use Cases nicht
geprüft; es wird davon ausgegangen, dass diese (evtl. als
Nachbedindungn in einem anderen Use Case) erfüllt werden.
Offensichtliche Vorbedingungen wie „Das System ist eingeschaltet“ sind
nicht anzugeben.]]
Kassierer ist identifiziert und authentifiziert.
Ergebnis (Result):
Verkauf ist abgewickelt.
Nachbedingungen (Success Guarantee, Postconditions):
[[Nach durchlaufen eines Szenarios müssen alle Nachbedingungen erfüllt
sein. Diese sind der „Vertrag“ , der die Interessen der Stakeholder
erfüllt.]]
1. Verkaufsvorgang ist protokolliert.
2. Steuern sind korrekt berechnet.
3. Buchhaltung und Bestand sind aktualisiert.
4. Provisionen sind protokolliert.
5. Beleg ist erstellt.
6. Zahlungsbestätigungen sind protokolliert.
Main Success Scenario (or Basic Flow):
[[Ein Szenario beschreibt eine bestimmte Abfolge von
Aktionen/Interaktionen zwischen Akteuren und dem zu erstellenden
System.]]
[[Das Main Success Scenario beschreibt die optimale/ideale/“normale“
Abfolge von Schritten, ohne Berücksichtigung evtl. Fehler oder optionaler
Verzweigungen.]]
1. Kunde erscheint mit Einkäufen am POS
2. Kassierer startet neuen Verkaufsvorgang.
3. Kassierer erfasst Artikelnummer.
4. System erfasst Posten und stellt Artikelbeschreibung, Preis und laufende
Summe dar. Der Preis wird anhand bestimmter Regeln errechnet.
Kassierer wiederholt die Schritte 3 bis 4.
5. System stellt Summe mit Steuern dar.
6. Kassierer nennt Kunden die Summe und fordert Zahlung.
7. Kunde bezahlt; System führt Zahlung durch.
8. System protokolliert den abgeschlossenen Zahlungsvorgang und sendet
Verkaufs- und Zahlungsinformationen an das externe Buchhaltungssystem
(zwecks Buchhaltung und Provisionen) und die externe Bestandsverwaltung
(zwecks Aktualisierung der Bestände).
9. System erzeugt Beleg.
10. Kunde verlässt das Geschäft mit Beleg und Artikeln.
Extensions (or Alternative Flows):
*a.
Jederzeit bei Systemfehlern: Zwecks Fehlerbeseitigung (recovery) and
korrekter Buchhaltung, stelle sicher, dass aus sämtlichen
Transaktionsbehafteten Zuständen und Ereignissen heraus ein recovery
möglich ist.
1. Kassierer startet das System neu, führt Log-In durch und fordert
recovery des vorherigen Zustands an.
2. System rekonstruiert vorherigen Zustand
a. System stellt Fehler fest, die ein recovery verhindern:
i. System signalisiert den Fehler an den Kassierer,
protokolliert den Fehler, und wechselt in einen
definierten Zustand
ii. Kassierer startet einen neuen Verkaufsvorgang
3a.
Ungültige Artikelnummer:
1. System signalisiert Fehler und verweigert Eingabe
3b.
Derselbe Artikel wird mehrfach erfasst, und es ist nicht erforderlich, dass
einzelne Artikel verwaltet werden:
1. Kassierer erfasst die Anzahl des Artikels
3-6a. Kunde bittet den Kassierer, einen Artikel aus dem Einkauf zu entfernen:
1. Kassierer erfasst Artikelnummer zum Entfernen
2. System stellt aktualisierte Summe dar
3-6b. Kunde bittet den Kassierer, den Einkauf abzubrechen:
1. Kassierer bricht Einkauf ab.
3-6c. Kassierer „suspendiert“ den Einkauf:
1. System speichert Einkauf, so dass dieser auf einem anderen POS
abgerufen werden kann.
4a.
Der vom System ermittelte Preis ist nicht gewünscht (z.B. Beschwerde des
Kunden, Preisnachlass wg. Mängel):
1. Kassierer erfasst gewünschten Preis, überschreibt den vom System
ermittelten Preis.
2. System stellt neuen Preis dar.
5a.
System stellt Fehler in der Kommunikation mit externem Service zur
Berechnung der Steuer fest.
[[Zu Beachten ist hier die Formulierung „System stellt Fehler... fest“ statt
„Externer Service funktioniert nicht“.]]
1. System starten den Service auf dem POS neu und fährt fort.
a. System stellt fest, dass der Service nicht neu startet.
i. System signalisiert Fehler.
ii. Kassierer kann entweder den Steuerbetrag manuell
berechnen und erfassen, oder den Verkauf abbrechen.
iii.
5b.
Kunde fordert Rabatt ein (z.B. Mitarbeiter- oder Kundenrabatt).
1. Kassierer erfasst Rabatt-Wunsch
2. Kassierer erfasst Kundenidentifikation
3. System stellt rabattierte Summe dar, unter Berücksichtigung der
Rabatt-Regeln
5c.
Kunde möchte vorhandenes Guthaben auf seinem Kundenkonto anrechnen
1. Kassierer erfasst Verrechnungs-Wunsch
2. Kassierer erfasst Kundenidentifikation
3. System berücksichtigt Guthaben, vermindert das vorhandene Guthaben
und stellt die aktualisierte Summe dar.
6a.
Kunde wollte ursprünglich Bar zahlen, hat aber nicht ausreichend Bargeld
bei sich
1a. Kunde wählt alternative Zahlungsart
1b. Kunde möchte Einkauf abbrechen. Kassierer bricht Verkauf am
System ab.
7a.
Barzahlung
1. Kassierer erfasst den Gegeben-Betrag
2. System stellt den Rückgeld-Betrag dar and öffnet Geldfach.
3. Kassierer hinterlegt Bargeld in Geldfach und gibt dem Kunden das
Wechselgeld.
4. System protokolliert Barzahlung.
7b.
Zahlung per Kreditkarte
[[Diese komplexe Verzweigung ist ein Kandidat für einen gesonderten
Use Case.]]
1. Kunde erfasst Kreditkarten Informationen
2. System sendet Zahlungsanforderung an externes Payment
Authorization Service System und fordert Zahlungsfreigabe an.
2a. System stellt Fehler in der Kommunikation mit dem externen
System fest.
1. System signalisiert Fehler an Kassierer
2. Kassierer fragt Kunde nach alternativer Zahlungsart
3. System erhält Zahlungsfreigabe und signalisiert dies dem Kassierer.
3a. System erhält Ablehnung der Zahlungsanforderung.
1. System signalisiert Ablehnung der Zahlungsanforderung an
Kassierer
2. Kassierer fragt Kunde nach alternativer Zahlungsart
4. System protokolliert Kreditkartenzahlung, einschließlich der
Zahlungsfreigabe.
5. System ermöglich Unterschreiben der Kreditkartenzahlung.
6. Kassierer bittet Kunden um Unterschrift, Kunde unterschreibt
7c.
Zahlung per Scheck...
7d.
Zahlung per Rechnung...
7e.
Kunde hat Coupons
1. Vor Abwicklung der Zahlung erfasst der Kassierer die Coupons, das
System reduziert entsprechend die Summe. System protokolliert die
verwendeten Coupons zwecks Buchhaltung.
9a.
9b.
1a. Erfasster Coupon ist für keinen der Artikel des Verkaufs
anwendbar.
1. System signalisiert Fehler an Kassierer
Auf einzelne Artikel gibt es Rabatt
1. System stellt Rabatt (Wert und Art) für jeden einzelnen Artikel dar.
Kunde wünscht einen Geschenk-Beleg (ohne Darstellung der Preise)
2. Kassierer fordert einen Geschenk-Beleg an; System erstellt GeschenkBeleg.
Special Requirements:
 Touch-Screen Benutzungsschnittstelle auf einem Flat-Screen Monitor. Text
muss aus einem Meter Entfernung sichtbar und lesbar sein.
 Freigabe der Kreditkartenzahlung muss in 90% der Fälle innerhalb von 30
Sekunden erfolgen.
[[Qualitative Anforderungen wie diese Anforderung bzgl. Der Antwortzeit
werden oftmals primär in einem Use Case ermittelt. Es empfiehlt sich,
solche Anforderungen, die nicht nur einen spezifischen Use Case betreffen
in der Supplementary Specification zu konsolidieren.]]
 Robuste Fehlerbehandlung (wie auch immer) ist erforderlich für den Fall, dass
entfernte externe Systeme (z.B. Bestandsverwaltung) nicht verfügbar sind.
 Mehrsprachigkeit der dargestellten Texte.
 Anpassbare, kundenspezifische business rules an den Schritten 3 (Eingabe
Artikel) und 7 (Zahlung).
 ...
Technology and Data Variations List:
3a.
Artikelidentifikation erfasst durch Laser Bar-Code Scanner oder per
numerischer Tastatur.
[[Oftmals finden sich hier Vorgaben (d.h. keine Anforderungen) hier.
Diese sind mit Vorsicht zu behandeln, da ansonsten eine frühzeitige
Festlegung auf Details der technischen Umsetzung erfolgt. In der Realität
sind solche Vorgaben aber nicht immer zu vermeiden oder zumindest
nachvollziehbar.]]
3b.
Artikelidentifikation kann eine beliebige UPC, EAN, JAN, oder SKU sein.
7a.
Kreditkarten-Informationen können per Kartenlesegerät oder per
numerischer Tastatur erfasst werden.
7b.
Unterschrift wird auf Papierbeleg erfasst. Es ist davon auszugehen, dass
innerhalb von zwei Jahren bevorzugt eine digitale Erfassung gewünscht
sein wird.
Frequency of Occurence:
 Es wird erwartet, dass dieser Use-Case so gut wie ständig/fortlaufend auftritt.
Frequency of Change:
 Es ist zu erwarten, dass Rabattregelungen sich fortlaufend und zusätzlich für
jede Filiale stark variieren.
Open Issues:
 Was sind die Unterschiede in der Besteuerung?




Die Fehlerbehebung/recover bei der Nutzung externer entfernter Services ist
genauer zu Untersuchen.
Welches Customizing ist für die verschiedenen Branchen notwendig?
Muss ein Kassierer das Geldfach beim Log-Out aus dem POS entnehmen?
Kann ein Kunde das Kartenlesegerät selbst bedienen, oder muss das der
Kassierer tun?
3 System Sequence Diagrams
3.1 UC1: „Abwicklung Verkauf“
system as black box
the name could be "NextGenPOS" but "System" keeps it simple
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
external actor to
system
Process Sale Scenario
:System
: Cashier
makeNew Sale()
box may enlose an
iteration area
the * [...] is an iteration
marker and clause
indicating the box is for
iteration
enterItem(itemID, quantity)
description, total
* [more items]
endSale()
return value(s)
associated w ith the
previous message
an abstraction that
ignores presentation
and medium
the return line is
optional if nothing is
returned
total w ith taxes
makePayment(amount)
change due, receipt
a message w ith
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
some mechanism