Sprint 0: Anwendungsfalldiagramm

[hexahepta]

Created and commited Use Case Diagram

[HoferAnton]

Reviewer: @HoferAnton Die Verbindung von Role User zum Usecase besser layouten

[HoferAnton]

Nach @phiebl ist der Anwendungsfall start Game Session für eine ganze Spielpartien zuständig. Gibt es einen Anwendungsfall für den Fall das nach den aktuellen eingestellten Parametern für die Spielsession auch eine einzelne Runde im Spiel gestartet wird? Wo startet der Game Admin eine neue oder die nächste Runde. Ohne alle Parameter neu einzugeben?

So wie sich das Diagramm in Verbindung mit der Beschreibung liest müsste für jede einzelne Runde eine komplett neue Game Session gestartet werden.

[HoferAnton]

Ich fände einen zusätzlichen Anwendungsfall "Credits" bei dem halt wir als Entwickler genannt werden nicht schlecht. Was haltet Ihr so davon?

[OneToughMonkey]

Den Anwendungsfall "Set value change function" würde ich eigentlich weglassen, und stattdessen so damit umgehen, dass man Alexa unabhängig vom Spiel immer sagen kann, dass es die Punkte eines Spielers um X erhöhen, um X erniedrigen, oder auch auf X setzen soll. Damit sollten denke ich alle Möglichkeiten abdeckbar sein, für viele Spiele gibt es ja gar keine begrenzte Anzahl an möglichen Punkteveränderungen und man kann z.B. auch eine voreilig getätigte fehlerhafte Punkteeingabe nachträglich noch korrigieren.

Den Nachteil, dass damit nicht oder schwerer überprüfbar ist, ob die eingegebene Punktezahl legal ist, wiegen die Vorteile meiner Ansicht nach auf.

Oder versteh ich falsch was du damit gemeint hast?

Nach @phiebl ist der Anwendungsfall start Game Session für eine ganze Spielpartien zuständig. Gibt es einen Anwendungsfall für den Fall das nach den aktuellen eingestellten Parametern für die Spielsession auch eine einzelne Runde im Spiel gestartet wird? Wo startet der Game Admin eine neue oder die nächste Runde. Ohne alle Parameter neu einzugeben?

So wie sich das Diagramm in Verbindung mit der Beschreibung liest müsste für jede einzelne Runde eine komplett neue Game Session gestartet werden.

Ich halte es für sinnvoll hier noch einen neuen Anwendungsfall für "Neue Runde (mit gleichem Spielprofil) spielen", und evtl. auch noch einen für das "manuelle" beenden einer Runde einzuführen.

Ich fände einen zusätzlichen Anwendungsfall "Credits" bei dem halt wir als Entwickler genannt werden nicht schlecht. Was haltet Ihr so davon?

Kann man machen, würde ich aber sehr niedrig priorisieren.

Ich denke es wäre wichtig, dass wir das Issue hier bald mal zum Abschluss bringen, damit wir die vielen anderen Issues, die direkt oder indirekt von dessen Ergebnis abhängig sind, auch noch rechtzeitig fertig kriegen.

[hexahepta]

Wir können das ganze System auch gerne so bauen das es nur diese drei Funktionen zum verändern von Spieler Punkten gibt. Allerdings bin ich bei erstellen des Diagramms von einem allgemeinen System ausgegangen das möglichst erweiterbar ist. Z. B. dürfte eine Runde Kniffel nur mit Inkrement, Dekrement und Festlegung eines Wertes kaum umsetzbar sein. Dazu fiel mir leider keine bessere Kurzbeschreibung als "Set value change function" ein. Sollten wir ein solches allgemeineres System bauen wollen, könnte ich noch ein Anwendungsfall Diagram für einen spezifischeren Fall (wie etwa Schafkopf) erstellen.

Ich weiß nicht wie @phiebl Spielrunde definiert, für mich ist mit dem Fall "Start Game Session" der Beginn einer in sich geschlossenen Spiel Session gemeint. Sprich werden die Punkte in mehrere Zyklen (üblicherweise als Spielrunden bezeichnet) geändert, findet dies innerhalb einer solchen Session statt. Ich halte einen Anwendungsfall zum erneuten starten einer Session mit dem selben Regelsatz wie in der vorhergehenden überflüssig da dafür entweder einfach das selbe Profil gestartet wird oder die entsprechenden Standard Werte bereits gesetzt sind. Somit scheint mir zwischen dem starten der ersten und einer weiteren Session kein Unterschied in der Funktionalität zu bestehen. Das explizite beenden einer Spielrunde sehe ich auch als sinnvoll und werde einen solchen Anwendungsfall sofort ergänzen.

Zum Thema Credits gehe ich mit @OneToughMonkey d'accord und würde es niedrig priorisieren aber der Verfügbarkeit halber füge ich es gern hinzu.

[hexahepta]

Bei der Erstellung von Use Cases zu Schafkopf bräuchte ich etwas Hilfe, stellt sich heraus ist deutlich zu lange her das ich mal darin unterwiesen wurde und es scheint nichts hängen geblieben zu sein. Aus Internetfunden wurde ich bis jetzt auch nur bedingt schlau. Commit

[OneToughMonkey]

Wir können das ganze System auch gerne so bauen das es nur diese drei Funktionen zum verändern von Spieler Punkten gibt. Allerdings bin ich bei erstellen des Diagramms von einem allgemeinen System ausgegangen das möglichst erweiterbar ist. Z. B. dürfte eine Runde Kniffel nur mit Inkrement, Dekrement und Festlegung eines Wertes kaum umsetzbar sein. Dazu fiel mir leider keine bessere Kurzbeschreibung als "Set value change function" ein.

Ich glaube sämtliche Punkte-Regeln für ein Spiel wie Kniffel per Spracheingabe zu definieren würde jeden Nutzer an die Grenzen seiner Geduld bringen. Ganz zu schweigen vom Programmierer der die Spieldefinition so allgemein ermöglichen soll.

Bei sowas wie Kniffel hätte ich gedacht, dass das (wenn überhaupt) nur vorprogrammiert verfügbar gemacht wird.

Ich weiß nicht wie @phiebl Spielrunde definiert, für mich ist mit dem Fall "Start Game Session" der Beginn einer in sich geschlossenen Spiel Session gemeint. Sprich werden die Punkte in mehrere Zyklen (üblicherweise als Spielrunden bezeichnet) geändert, findet dies innerhalb einer solchen Session statt. Ich halte einen Anwendungsfall zum erneuten starten einer Session mit dem selben Regelsatz wie in der vorhergehenden überflüssig da dafür entweder einfach das selbe Profil gestartet wird oder die entsprechenden Standard Werte bereits gesetzt sind. Somit scheint mir zwischen dem starten der ersten und einer weiteren Session kein Unterschied in der Funktionalität zu bestehen.

So wie ich das verstanden hatte, geht es eher darum, dass man oft nach Ende eines Spiels, in dem Sinne, dass ein Sieger feststeht, nochmal das gleiche Spiel, mit zurückgesetzten Punkten, spielen will. Aktuell müsste man dann halt erst wieder das entsprechende Profil auswählen, damit man dann das Spiel wieder starten kann. Kann vielleicht etwas nervig sein.

Man könnte das sonst evtl. auch dadurch bewältigen, dass Alexa generell beim Start einer Game Session vom zuletzt gesetzten Spielprofil ausgeht.

Bei der Erstellung von Use Cases zu Schafkopf bräuchte ich etwas Hilfe, stellt sich heraus ist deutlich zu lange her das ich mal darin unterwiesen wurde und es scheint nichts hängen geblieben zu sein. Aus Internetfunden wurde ich bis jetzt auch nur bedingt schlau.

Hab da leider auch keine Ahnung mehr, ist mehr als 10 Jahre her dass ich das mal gelernt hab.

[hexahepta]

So wie ich das verstanden hatte, geht es eher darum, dass man oft nach Ende eines Spiels, in dem Sinne, dass ein Sieger feststeht, nochmal das gleiche Spiel, mit zurückgesetzten Punkten, spielen will. Aktuell müsste man dann halt erst wieder das entsprechende Profil auswählen, damit man dann das Spiel wieder starten kann. Kann vielleicht etwas nervig sein.

Man könnte das sonst evtl. auch dadurch bewältigen, dass Alexa generell beim Start einer Game Session vom zuletzt gesetzten Spielprofil ausgeht.

Ja finde ich auch vernünftig wenn man ein eingestelltes Profil nicht erneut auswählen muss bei start einer neuen Session.

Ich glaube sämtliche Punkte-Regeln für ein Spiel wie Kniffel per Spracheingabe zu definieren würde jeden Nutzer an die Grenzen seiner Geduld bringen. Ganz zu schweigen vom Programmierer der die Spieldefinition so allgemein ermöglichen soll.

Bei sowas wie Kniffel hätte ich gedacht, dass das (wenn überhaupt) nur vorprogrammiert verfügbar gemacht wird.

Genau das wollte ich damit ausdrücken, die Möglichkeit der expliziten Wahl einer "Change value function" ist nur zur Nutzung von Funktionen für ein Spiel gedacht das nicht als (programmiertes) Profil vorliegt. So dass etwa ein Kniffel gespielt werden könnte wenn jemand dafür Software schreibt und diese in das System einbindet. Ich wollte damit nur sagen das wenn wir nur fest definierte Funktionen (z.B. inkrement, dekrement, set) erstellen nicht die Möglichkeit besteht komplexeres Regelwerk in unserem System abzubilden.

Sprich ich habe versucht das System erweiterbar zu modelieren so das etwa Kniffel nachträglich noch als Profil programmiert werden kann. Die Funktionen zum verarbeiten von Punkten sollen innerhalb des Systems nur von einem Entwickler erstellt werden können und von dem "Game Admin" ausgewählt werden.

[hexahepta]

Anstelle des Subsystems zu Schafkopf habe ich jetzt erst einmal ein Grund Profil mit den Funktionen Punkte zu setzen, addieren und subtrahieren erstellt.

[OneToughMonkey]

Ja finde ich auch vernünftig wenn man ein eingestelltes Profil nicht erneut auswählen muss bei start einer neuen Session.

Ok, dann werde ich das so in mein Review der Anwendungsfallbeschreibung eingehen lassen.

Genau das wollte ich damit ausdrücken, die Möglichkeit der expliziten Wahl einer "Change value function" ist nur zur Nutzung von Funktionen für ein Spiel gedacht das nicht als (programmiertes) Profil vorliegt. So dass etwa ein Kniffel gespielt werden könnte wenn jemand dafür Software schreibt und diese in das System einbindet. Ich wollte damit nur sagen das wenn wir nur fest definierte Funktionen (z.B. inkrement, dekrement, set) erstellen nicht die Möglichkeit besteht komplexeres Regelwerk in unserem System abzubilden.

Sprich ich habe versucht das System erweiterbar zu modelieren so das etwa Kniffel nachträglich noch als Profil programmiert werden kann. Die Funktionen zum verarbeiten von Punkten sollen innerhalb des Systems nur von einem Entwickler erstellt werden können und von dem "Game Admin" ausgewählt werden.

Hm... ich bin mir immer noch nicht ganz sicher, ob ich dich richtig verstehe.

Ich hatte mir das so vorgestellt, dass ein "Game Profile" entweder vollständig (also inklusive default value und ggf. komplexeren "change value" Funktionen) vordefiniert ausgewählt wird, oder mit eingeschränkter Freiheit selbst definiert werden kann.

In meinem getstoryline-Prototyp habe ich folgende Schritte für ein Mindestmaß an Flexibilität in der Definition eigener Spielprofile im Rahmen "simpler" Regelwerke durch den Nutzer identifiziert:

• Startpunktezahl festlegen
• Siegpunktezahl festlegen oder Siegpunktezahl offenlassen und dafür zusätzlich definieren, ob es um Punktemaximierung oder Punkteminimierung geht

Nach diesem Modell würde sich nicht nur die Implementation sondern auch die Auswahl entsprechender "Value change" Funktionen zur Umsetzung komplexerer Regelwerke rein in den (zukünftigen) Verantwortungsbereich der Entwickler verlagern.

[hexahepta]

Genau deshalb habe ich im Diagram neben der Auswahl des Profils auch die beiden Use Cases zum setzten der Start Punkte und Auswahl der Funktion zur Veränderung dieser. Ziemlich genau wie du es beschreibts. Das ist durchaus so gedacht das du entweder ein Profil wählst oder das durch nutzen dieser Funktionen selbst definierts.