search

anhapu / SDFplay

3 stars 0 forks source link

Konzept Büchertausch #20

Closed fabiankirstein closed 10 years ago

fabiankirstein commented 10 years ago

Notwendige Models/Tabellen:

Trade Model (Wunschzettel): ID Owner (User, der Tausch initialisiert) Recipient (User, an den Anfrage gerichtet ist) State (Enum der verschiedene Zustände der Transaktion) Comment (Kommentar des Wunschzettels)

TradeBook Model (Zuordnung Wunschzettel zu Bücher) : ID TradeID BookID

Ablauf eines Büchertauschs:

Sicht User 1:

Sicht User 2:

Sicht User 1 - Ablehung:

Sicht User 1 - Antwort:

Sicht User 2 - Ablehung

Sicht User 2 - Bestätigung:

Sicht Betroffene User:

ghost commented 10 years ago

Was Du vorschlägst, hört sich sehr gut an. Kleinere Änderungsvorschläge habe ich dennoch:

(1) Momentan ist ja so, dass man in der Tabelle "TradeBook" nicht auseinannderhalten kann, ob das entsprechende Buch von einem Owner oder einem Recipient stammt. Das weiss man erst, wenn man mit der BookID eine weitere Anfrage an die Datenbank stellt. Aus diesem Grund würde ich die "TradeBook"-Tabelle in 2 getrennte Tabellen teilen. Eine Tabelle für Owner und eine für Recipient.

(2) Wenn ein Nutzer ein Tauschangebot ablehnt, dann möchte er gegebenenfalls auch noch etwas dazu sagen. Aus diesem Grund würde ich noch ein zweites Kommentarfeld in die Tabelle TradeTransaction einfügen.

(3) Man kann auch noch eine Spalte InitTime (Date) in die Tabelle TradeTransaction einfügen, um den Zeitpunkt eines Tauschangebots festzuhalten. Über diese Spalte lassen sich Tauschangebote in der Useransicht nach dem Erstellungszeitpunkt sortieren. (Das wäre allerdings auch über die ID möglich.)

ghost commented 10 years ago

play_datenbank

ghost commented 10 years ago

Tabelle: TradeTransaction
Spalte: State

In der Spalte State würde ich nur 3 Zustände eintragen. (RESPONSE habe ich weggelassen.) (1) INIT --> Ein Büchertausch von User 1 an User 2 wurde vorgeschlagen. (2) ACCEPT --> Dem Büchertausch wurde von User 2 zugestimmt. Die Bücher werden nun den neuen Besitzern zugeordnet. (3) REFUSE --> Der Büchertausch wurde von User 2 abgelehnt. Hier kann der User 2 in sein Kommentarfeld z.B. noch schreiben, dass er einen Gegenvorschlag machen wird oder auch dass User 1 keine Bücher besitzt, die Ihn interessieren.

Einträge aus der Tabelle TradeTransaction würde ich zu keinem Zeitpunkt löschen. Der Zustand 1 (INIT) zeigt ein aktives Tauschangebot. Zustand 2 (ACCEPT) und Zustand 3 (REFUSE) zeigen abgeschlossene Tauschangebote. Wird ein Tauschangebot abgelehnt, so kann der User 2 ein neues Tauschangebot an User 1 unterbreiten. Dafür würde ich einen neuen Eintrag in der TradeTransaction-Tabelle einfügen und alles läuft von vorn ab, wie zuvor beschrieben.

Mir ist bewußt, dass Fortenbacher in seiner Aufgabenbeschreibung etwas von einem zweistufigen Verfahren geschrieben hat. Aber meines Erachtens macht das die gesamte Angelegenheit unnötig komliziert. Aus diesem Grund würde, ich auf dem Userinterface des Users 2 bei Erhalt einer Tauschanfrage die Möglichkeiten, ACCEPT, REFUSE und NEW anbieten. NEW würde sich die Bücher der alte Tauschanfrage holen und dann eine neue Anfrage eröffnen. Diese Möglichkeit steht dem Nutzer dann allerdings immer (d.h. bei jeder Tauschanfrage) zur Verfügung und nicht nur als RESPONSE. Müssen wir ggf. mal fragen, ob das ok für die Aufgabenstellung wäre.

fabiankirstein commented 10 years ago

Vielen Dank für die das Feedback und das Erstellen des ERM. Deine Änderung mit der zusätzlichen Tabelle macht Sinn. Mann könnte alternativ auch ein zusätzliches Flag für die Zugehörigkeit setzen. Aber schnellen Zugriff auf die Trennung zu haben ist schon praktisch. Wie man mit nur drei Zuständen auskommt ist mir allerdings nicht ganz klar. Ich denke wir sollten das nachher im Scrum-Meeting nochmal mit allen durchsprechen. Vielleicht haben wir unterschiedliche Vorstellungen wie das abläuft. Hier nochmal meine Vorschläge im Überblick, die Namen sind natürlich alle willkürlich und nicht immer passend:

INIT -> Wunschzettel mit einem! Buch angelegt CONFIRM -> Wunschzettel fertig, ggf. mit mehr als einem Buch (Also Bücher die User 1 von User 2 haben will) REFUSE -> Wunschzettel sofort abgelehnt RESPONSE -> Wunschzettel vervollständigen (Welche Bücher möchte User 2 von User 1 im Gegenzug) (Vielleicht bräuchte man hier noch ne INIT_RESPONSE) APPROVE -> User 1 nimmt kompletten Wunschzettel an! FINAL_REFUSE -> User 1 lehnt Angebot ab INVALID -> Durch andere Transaktionen als unmöglich markiert

Die scharfe Trennung habe ich mit gedacht, dass man jederzeit über den genauen Zustand Bescheid weiß und gut Meldungen abgeben kann. Man könnte den Wunschzettel mit den mehreren Büchern auch über Cookies etc. halten bis er fertig ist, aber ich denke das ist aufwendiger und fehleranfälliger.

ganddev commented 10 years ago

Um die ganzen Zustände nachvollziehen zu können, ist es vllt Sinnig ein Zustandsdiagramm zu machen.

ghost commented 10 years ago

Das folgende Diagramm soll Fabis Zustandsmodell veranschaulichen. D.h. die Spalte State in der Tabelle TradeTransaction: play_buchtausch_states_01

ghost commented 10 years ago

Den Zustand INVALID könnte man über einen Datenbankentrigger setzten, der bei Update der Tabelle TradeTransaction ausgelöst wird.

Auch das neue Zuordnen der getauschten Bücher könnte der Trigger übernehmen.

stubb commented 10 years ago

Ich denke Trigger entsprechen nicht der Aufgabenstellung. Theoretisch könnte man die ganze Validierung etc. mit Triggern lösen, aber wir sollen ja das FW nutzen.

ghost commented 10 years ago

Da hast Du Recht...

ganddev commented 10 years ago

Perfekt! erstmal danke für das Zustandsdiagramm, so wird es doch gleich viel klarer! :) +1

fabiankirstein commented 10 years ago

Also jetzt mit Diagram denke ich, dass wir auf dem richtigen Weg sind. Wir sollten das am Mittwoch dann nochmal durchspielen. Vielleicht mit verteilten Rollen. :)

ghost commented 10 years ago

State Modell aktualisiert:

play_buchtausch_states_02