Kassensystem

Anforderungen

harte Anforderungen

Das soll das System unbedingt leisten

• Der Frundler soll eine Übersicht bekommen was er der Frunde schuldet / wieviel Restguthaben er noch hat

weiche Anforderungen

sind für die 1.x-Reihe nicht ganz so wichtig

• Das Getränk wird am Terminal per Barcode-Scan eingegeben
• Anstatt einer Frunden-geldkarte wird per RFID die Mensakarte genommen
• ...

Use cases

Der Warenverwaltungsaspekt fehlt hier noch völlig

Man sollte hier vielleicht sowas wie die (nummerierten) Haupt-Usecases rauspellen und unten dran eine Liste mit den Varianten stellen (die CLI-Fälle sind vermtl. alle Varianten der Kiosk-Fälle)

1. Frundler konsumiert:
   1. Der Frundler authentifiziert sich mittels Karte am System
   2. Der Frundler sagt dem System er kauft ein Getränk
   3. Das System belastet das Konto des Frundlers mit dem genommenen Getränk
2. Gast konsumiert:
   1. Der Gast sagt dem System er kauft ein Getränk.
   2. Der Gast legt den zum Getränk passenden Betrag in die Barkasse
   3. Der Gast nimmt sich das Getränk
3. Bucher laedt Frundlerkarte auf
   1. Der Frundler gibt dem Bucher $Geld Euro und die Geldkarte.
   2. Der Bucher steckt seine Buchungskarte in das System
   3. Er hebt den Betrag vom Buchungskonto ab
   4. Er steckt die Buchungskarte aus und steckt die Frundlerkarte ein
   5. Er laedt das Geld auf das Frundlerkonto
   6. Er Gibt die Karte dem Frundler
4. Bucher gibt Geld an Kassenwart weiter
   1. Der Bucher gibt dem Kassenwart das gewartete Geld.
   2. Der Kassenwart authentifiziert sich am System.
   3. Der Kassenwart steckt die Karte des Buchers ins System ein.
   4. Er entlastet das Konto des Buchers.
5. Bucher leeren Kasse
   1. Der Bucher authentifiziert sich am System
   2. Der Bucher nimmt das Geld aus der Kasse.
   3. Der Bucher bucht das Geld aus der Kasse heraus.

CLI-Fälle der obigen Varianten (alle?)

Ein neues Getränk anlegen

Den Preis eines Getränks verändern

Rollen

Es gibt also folgende Rollen: Rollen: Gast, Frundler, Bucher, Kassenwart

Modelle

Objekt: Karte, Konto.
Konto-Aspekte:

• Quota (von -x bis +y)
• Quota ist Attribut eines Kontos (einfacher als nach Kontentypen zu differenzieren)
• immer einer Karte zugeordnet (ist das im Fall des Master-Kontos angemessen?)
• jede Karte kann auf ein zugeordnetes Konto verweisen ("Konsumkonto")
• es gibt Karten die zusätzlich noch ein Bucherkonto haben
• intervall wieviel/welche getränke von letztem Zeitpunkt getrunken wurden angeben

Den letzten Punkt würde ich noch zurückhalten, bis das Getränkeproblem s.w.u. gelöst ist

Subtypen und so

Subtypen von Konto: Kasse, Frundler, Bucher, Gast

Es erscheint am einfachsten, im System nicht weiter zwischen verschiedenen Kontentypen zu differenzieren. Das Quota etwa kann ja ruhig wie oben geschrieben als Attribut am Konto kleben, beim Notifizieren wird uns sicher ähnliches einfallen. Um dennoch für uns zwischen den verschiedenen Zwecken der Konten zu unterscheiden, bekommt jedes Konto noch ein Namensattribut.

Getränke

Hier liegt noch einiges im Argen: Wir wollen mit Sicherheit die verschiedenen verfügbaren Getränketypen (Mate, Cola, ...) in einer Tabelle speichern, und daraus u.A. das manuelle Getränkemenü zu generieren etc. Da steht dann auch der Preis dran. Dann gibt es zwei Möglichkeiten:

• keine abgeschlossene Transaktion verweist auf ein solches Getränk (sonst ändert sich die Transaktion, wenn das Getränk einen anderen "Preis" bekommt)
• wenn wir den "Preis" für Mate erhöhen, legen wir mehrere Mate-Einträge an, einmal mit altem Preis, einmal mit neuem, und konsumieren kann man nur nach aktuellem Preis, die alte erscheint nicht im Menü

Beides ist irgendwie häßlich. Vorschläge?

• Warum nicht den Preis beim Erstellen der Transaktion ins Transaktionsobjekt kopieren?
• Getränkeobjekte und Preisobjekte getrennt anlegen. Preise sind einem Getränkeobjekt zugeordnet und haben nebem einem Preis ein Startdatum. Somit können alle Preisänderungen problemlos nachvollzogen werden und nichts wird redundant gespeichert. So habe ich das bei meiner Getränkekasse gelöst. (externer Kommentar von tblank@gmx.net)

weitere Aspekte

Logging

• Jede Transaktion, wer von wo nach wo wieviel und wann und aus welchem Anlass erscheint im System. (auch wenn welches getränk)
• löschen von transaktionen solange noch nicht commited ist (session nicht vorbei) ist möglich
• Wie sieht ein Commit in der Logik aus?
• sonstige löschvorgänge von transaktionen ist nicht möglich
• Frundler kann seine kürzlich gekauften Getränke einsehen.

Notification

• Kassenwart muss ueber Gelduebergabe an Bucher benachrichtigt
• Bei MaxBetrag in Kasse muss der Kassenwart benachrichtigt werden