Pflichtenheft

1. Zielbestimmung

Es ist ein Software-Agent zu entwickeln, der das Spiel „4 gewinnt“ autonom gegen einen anderen Spieler spielen kann. Die Kommunikation beider Spieler soll dabei über einen zwischengeschalteten Server stattfinden, mit dem beide Spieler verbunden sind. Die Spielzüge des Agenten sowie des Gegners sollen über ein graphisches Spielfeld nachverfolgt werden können. Spielzüge sowie Punkte sollen automatisch in einer Datenbank abgelegt werden und können durch den User beliebig aufgerufen und angezeigt werden.

1.1 Musskriterien

Agent:

• Der Agent muss eigenständig ohne Userinteraktion das Spiel „4 gewinnt“ spielen können
• Die Programmierung ist durch Java SE 8 und JavaFX zu realisieren
• Die Kommunikation zwischen Agent und Server muss über zwei Schnittstellen (Dateisowie Pusher-Schnittstelle) stattfinden können
• Ein Wechsel zwischen den beiden Schnittstellen soll zwischen den Sätzen möglich sein
• Die Datei-Schnittstelle muss über Dateien auf Basis von Streams mit dem Server kommunizieren können
• Die Pusher-Schnittstelle muss über Events auf Basis von Websockets mit dem Server kommunizieren können
• Der Agent muss auf die Zugfreigabe durch den Server warten
• Der nächste Zug des Agenten ist autonom durch diesen zu berechnen und an den Server über die entsprechende Schnittstelle zu übermitteln

Spiel:

• Es muss ein fehlerfreier Ablauf eines Satzes eines Spiels gespielt werden können

Graphische Oberfläche:

• Es ist eine graphische Oberfläche zu gestalten, die den Satzstatus, den Spielstand sowie das Spielfeld anzeigt
• Auf der graphischen Oberfläche sollen alle Züge des aktuellen Satzes dargestellt werden

Datenhaltung:

• In der Datenbank HSQLDB sind die Daten Gegner, Startspieler, Sieger, Punkte, Spiele, Sätze und Züge kontinuierlich zu speichern
• Es müssen drei Abfragevarianten implementiert werden, die eine Nachverfolgung des Spielverlaufs eines beliebigen Spiels ermöglichen

1.2 Wunschkriterien

• Der Spielzug des Agenten muss in einer manuell einzustellenden Zugzeit errechnet und dem Server übermittelt werden, um dem Timeout des Servers zu entgehen
• Es kann mehr als ein Satz eines Spiels gespielt werden
• Es kann ausgewählt werden, ob der User manuell gegen einen Gegner oder der Agent autonom das Spiel spielt
• Der Agent erkennt eigenständig, wer der Gewinner ist
• Bei einem vorzeitigen Beenden des Servers, das zu einem abgebrochenen Satz führt, kann der Agent ein nachträgliches Editieren von Ergebnissen ermöglichen. Dies geschieht, indem alle eigenen und gelesenen Züge bis zum Abbruch automatisch gespeichert werden, das Spiel allerdings fortgeführt werden kann.

1.3 Abgrenzungskriterien

• Das Spiel ist vorerst nur in deutscher Sprache erhältlich
• Eine Steuerung über die Konsole ist nicht vorgesehen
• Die Kommunikation zwischen beiden Mitspielern findet nicht direkt, sondern immer nur über den Server statt

2. Produkteinsatz

Das Produkt dient zum autonomen Spiel des Spiels „4 gewinnt“ gegen andere Mitspieler.

2.1. Anwendungsbereich

Die Anwendung soll im Rahmen eines Turniers gegen Anwendungen anderer Entwickler im Spiel „4 gewinnt“ antreten. Sie wird auf einem Rechner im Computerlabor der DHBW Mannheim installiert. Eine kommerzielle Verwendung ist vorerst nicht vorgesehen.

2.2. Zielgruppen

Zielgruppe der Anwendung sind der Dozent sowie die Studenten des Kurses WWI14SCA. Dem Dozenten soll es dabei möglich sein die Anwendung eigenständig zu bedienen sowie zu installieren, um die Anwendung bewerten zu können. Unerfahrene Benutzer erhalten über eine mitgelieferte Dokumentation, die eine Übersicht über den Aufbau sowie die Pflege der Anwendung liefert sowie einer Benutzeranleitung die Möglichkeit, die Anwendung zu bedienen.

2.3. Betriebsbedingungen

Die Anwendung soll auf jedem beliebigen Desktoprechner des Computerlabors der DHBW Mannheim lauffähig sein. Voraussetzung ist dabei, dass sie entsprechend der mitgelieferten Importanleitung installiert wurde.

3. Produktübersicht

Das folgende Anwendungsfalldiagramm (Abbildung 1) stellt die Funktionen sowie Akteure der Anwendung dar. Es gibt in dem System „4 gewinnt“ drei Akteure – den User, den Agenten sowie den Server. Da hier lediglich die eigens entwickelte Anwendung dargestellt wird, ist der gegnerische Agent nicht aufgeführt. Für eine weitere Übersichtlichkeit wurden ebenfalls die Datenbank sowie die graphische Oberfläche als Akteure nicht aufgeführt.

4. Produktfunktion

Es ist anzumerken, dass der Server bereits implementiert wurde und über eine der beiden Schnittstellen kontaktiert wird. Sämtliche Funktionen des Servers sind demnach bereits vor-handen und sollen daher an dieser Stelle keine weitere Erwähnung finden.

4.1. Benutzerfunktionen

/F100/

• Geschäftsprozess: Konfiguration des Spiels
• Vorbedingung: Anwendung ist auf dem Rechner installiert und gestartet
• Nachbedingung Erfolg: User kann das Spiel starten
• Nachbedingung Fehlschlag: User kann das Spiel nicht starten
• Akteure: User
• Auslösendes Ereignis: Anwendung wurde gestartet
• Beschreibung: Eingabe der Zugzeit in das entsprechende Eingabefenster

/F110/

• Geschäftsprozess: Spiel starten
• Vorbedingung: Das Spiel ist konfiguriert (/F100/)
• Nachbedingung Erfolg: Warten auf die Zugfreigabe durch den Server
• Nachbedingung Fehlschlag: Spiel startet nicht
• Akteure: User
• Auslösendes Ereignis: User drückt auf „Spiel starten“
• Beschreibung: User drückt auf „Spiel starten“, Agent wartet auf Spielfreigabe durch den Server

/F120/

• Geschäftsprozess: Daten anzeigen
• Vorbedingung: Der Agent hat bereits Spiele gespielt (/F110/)
• Nachbedingung Erfolg: gewünschte Daten werden angezeigt
• Nachbedingung Fehlschlag: es werden keine Daten angezeigt
• Akteure: User, Datenbank
• Auslösendes Ereignis: User gibt an, welches vergangene Spiel er nachverfolgen will
• Beschreibung: User gibt ein, welches Spiel er nachverfolgen will, Suche in der Datenbank, Datenbankabfrage wird auf der graphischen Oberfläche dargestellt

/F130/

• Geschäftsprozess: Thema der graphischen Oberfläche ändern
• Vorbedingung: Der Agent wurde geöffnet
• Nachbedingung Erfolg: Die graphische Oberfläche wird angepasst
• Nachbedingung Fehlschlag: die graphische Oberfläche ändert sich nicht
• Akteure: User, graphische Oberfläche, Agent
• Auslösendes Ereignis: User gibt an, welches graphische Thema er sehen möchte
• Beschreibung: User gibt ein, welche Oberfläche er sehen möchte, Spielfeld sowie Spielsteine werden entsprechend angepasst

4.2. Agentfunktionen

/F200/

• Geschäftsprozess: Spielzug generieren
• Vorbedingung: Spiel ist gestartet (/F110/), Agent ist an der Reihe, Gegnerischer Zug wurde empfangen (/F220/)
• Nachbedingung Erfolg: Zug ist berechnet und wird dem Server mitgeteilt (/F210/)
• Nachbedingung Fehlschlag: Time-Out durch den Server
• Akteure: Agent
• Auslösendes Ereignis: Zugfreigabe durch den Server
• Beschreibung: Auf Basis der implementierten Logik und vorheriger Züge wird neuer möglicher Spielzug generiert

/F210/

• Geschäftsprozess: Zug mitteilen
• Vorbedingung: Der Spielzug wurde berechnet (/F200/)
• Nachbedingung Erfolg: Warten auf die Antwort des Servers, Speicherung der Daten

(/F230/)

• Nachbedingung Fehlschlag: Time-Out durch den Server
• Akteure: Agent
• Auslösendes Ereignis: Zug wurde generiert (/F200/)
• Beschreibung: Auf Basis der entsprechenden Schnittstelle wird die Information über den nächsten Zug an den Server übermittelt

/F220/

• Geschäftsprozess: Zug empfangen
• Vorbedingung: Der Gegner hat gezogen
• Nachbedingung Erfolg: Der nächste Zug kann berechnet werden (/F200/)
• Nachbedingung Fehlschlag: Time-Out durch den Server
• Akteure: Agent, Server
• Auslösendes Ereignis: Server sendet über entsprechende Schnittstelle den gegnerischen Zug
• Beschreibung: Je nach Schnittstelle wird der Zug des Gegners ausgelesen

/F230/

• Geschäftsprozess: Daten speichern
• Vorbedingung: Zug an Server übermittelt (/F210/)
• Nachbedingung Erfolg: Daten werden in der HSQLDB abgelegt
• Nachbedingung Fehlschlag: Daten können nicht gespeichert werden
• Akteure: Agent, Datenbank
• Auslösendes Ereignis: Agent sendet Zug an den Server und ist nicht an der Reihe
• Beschreibung: Daten des Spiels werden in der Datenbank abgelegt

/F240/

• Geschäftsprozess: Spielzüge graphisch anzeigen
• Vorbedingung: Zug an Server übermittelt (/F210/) bzw. gegnerischen Zug empfangen (/F220/) bzw. Daten werden angezeigt (/F120/)
• Nachbedingung Erfolg: Spielsteine werden in der graphischen Oberfläche angezeigt
• Nachbedingung Fehlschlag: Spielsteine werden nicht korrekt positioniert
• Akteure: Agent, graphische Oberfläche, Datenbank
• Auslösendes Ereignis: Agent sendet Zug an den Server bzw. Agent empfängt gegnerischen Zug durch den Server oder Daten eines vergangenen Spiels werden aufgerufen
• Beschreibung: Spielsteine werden an der korrekten Position im graphischen Spielfeld angezeigt

5. Produktdaten

Es sind folgende Daten persistent zu speichern:

/D10/ Spieldaten Spiel-ID, Spieler1, Spieler2, Gewinner

/D20/ Satzdaten Satz-ID, Satznummer, Spiel-ID, Punktestand

/D30/ Zugdaten Zug-ID, Satz-ID, Spieler, Zeile, Spalte

6. Produktleistung

/L10/ Die Zugzeit des Agenten auf den Gegnerzug darf maximal 2 Sekunden betra-gen, kann aber niedriger bis auf 0,5 Sekunden eingestellt werden.

/L20/ Das Laden vorangegangener Spiele darf nicht länger als 20 Sekunden dauern

/L30/ Die Startkonfiguration darf nicht länger als eine Minute dauern, da sonst die Userfreundlichkeit signifikant leidet.

/L40/ Es müssen 0,3 Sekunden zwischen den Zugriffen des Agenten auf den Kontakt-pfad liegen

7. Qualitätsanforderungen

8. Benutzeroberfläche

An dieser Stelle sei ein erster Oberflächenprototyp mit zugehöriger Dialogstruktur darge-stellt.

8.1. Dialogstruktur

Im Folgenden wird die grobe Dialogstruktur einer fehlerfreien bzw. konfliktfreien Benutzung des Systems gezeigt. Die Hauptseite ist dabei die Seite, die nach Start des Agenten angezeigt wird. Auf der Haupt-seite ist es dem User möglich das Spiel zu konfigurieren sowie ein Spiel zu starten. Er kann außerdem aus einer Menge von vier verschiedenen graphischen Oberflächen wählen. Es ist zudem möglich das Spiel in Echtzeit auf der graphischen Oberfläche anhand des dargestell-ten Spielfelds zu verfolgen. Ferner kann sich der User eine Liste der vergangenen Spiele an-zeigen lassen und anschließend die Spielzüge eines dieser vergangenen Spiele nachverfol-gen.

8.2. Bildschirmlayout

Es soll ein erster Prototyp der Benutzeroberfläche dargestellt werden, in dem sich die in Ka-pitel 8.1 erwähnte Dialogstruktur wiederspiegelt. Der Hauptbildschirm ist durch Abbildung 3 dargestellt. Neben dem angezeigten Spielfeld können hier erste Konfigurationen durchgeführt werden. Es werden zudem der Spielstand sowie der Satzstatus angezeigt. Auf dem Spielfeld ist anschließend in Echtzeit das Setzen der Chips zu verfolgen. Der Hauptbildschirm inkorporiert zusätzlich ein Menüband mit Reitern, in denen weitere Funktionen eingebettet sind (Abbildung 4-5). Unter dem Reiter „Themen“ lässt sich dabei die graphische Oberfläche des Spielfeldes anpassen, während der Reiter „Optionen“ die Mög-lichkeit ein neues Spiel zu starten sowie bereits gespielte Spiele nachzuverfolgen bietet.

9. Nichtfunktionale Anforderungen

• Das Regelwerk des Spiels „4 gewinnt“ ist zu beachten
• Der Agent darf den ordnungsgemäßen Serverbetrieb sowie den Betrieb des gegneri-schen Agenten nicht beeinträchtigen/beeinflussen.
• Der Agent soll auf den Plattformen Windows sowie Mac OS laufen

10. Technische Produktumgebung

10.1. Software

• Betriebssystem Windows (ab Windows 7) oder Mac OS (ab Mac OS X)
• Laufzeitumgebung ab Java SE 7 (dementsprechend mit laufendem JavaFx-Framework)
• Datenbank HSQLDB (Version 2.3.4)
• Eclipse Neon

10.2. Hardware

*Herkömmlicher PC (z.B. Pentium 2 266 MHz oder schnellerer Prozessor mit einem physikalischen RAM von mindestens 128 MB)

• Maus & Tastatur
• Monitor

10.3. Orgware

• Netzwerkverbindung, damit über die Pusher- oder die Datei-Schnittstelle mit dem Server interagiert werden kann.

10.4. Produktschnittstellen

Es existieren keine Produktschnittstellen.

11. Spezielle Anforderungen an die Entwicklungsumgebung

11.1. Software

• Betriebssystem Windows (ab Windows 7) oder Mac OS (ab Mac OS X)
• Laufzeitumgebung ab Java SE 7 (dementsprechend mit laufendem JavaFx-Framework)
• Datenbank HSQLDB (Version 2.3.4)
• Eclipse Neon
• Zum Editieren und Überprüfen der erzeugten ASCII-Text-Dateien durch Kommunika-tion über die Datei-Schnittstelle ist der Windows-Editor ausreichend.

11.2. Hardware

siehe 10.2 Hardware

11.3. Orgware

Siehe 10.3 Orgware

11.4. Entwicklungsschnittstellen

keine

12. Ergänzungen

Die Anwendung soll zunächst in einer Basisversion erscheinen, die die hier spezifizierten Funktionen bedient. Weitere Erweiterungen wie eine englische Sprachausgabe könnten in Version 2 inkorporiert werden.

Um die Anzeige bereits gespielter Spiele ausreichend nachvollziehen zu können, wird die Applikation zusammen mit Testdaten dreier Spiele ausgeliefert.

13. Testfälle

Um eine qualitativ hochwertige Anwendung abliefern zu können, sind folgende Testfälle vor Abgabe zu realisieren:

• /T010/ Der Agent spielt ein Spiel gegen einen anderen Agenten (/F110/, /F200/, /F210/, /F220/, /F230/, /F240/)
• /T020/ Der User verfolgt die Züge eines beliebigen vergangenen Spiels (/F120/, /F240/)
• /T030/ Der User lässt sich alle gespielten Spiele anzeigen (/F120/)
• /T040/ Der Server stürzt während des Spiels ab
• /T050/ Das Spiel wird vorzeitig abgebrochen
• /T060/ Der User ändert das Thema der graphischen Oberfläche (/F130/)
• /T070/ Ein abgebrochenes Spiel wird nachverfolgt (/F120/, /F240/)
• /T080/ Die Schnittstelle wird zwischen den Sätzen gewechselt (/F210/, /F220/)
• /T090/ Es wird ein ganzes Spiel (alle drei Sätze) gespielt (/F110/, /F200/, /F210/, F220/, /F230/, /F240/)

14. Glossar

Agent:

• Anwendung, die autonom als Spieler am Spiel „4 gewinnt“ teilnimmt
• Berechnet die Züge eigenständig und teilt sie dem Server mit

Datei-Schnittstelle:

• Kommunikation von Server und Agent über Dateien auf der Basis von Streams
• Der Zug des Agenten wird in einem definierten Pfad als Textdatei abgelegt

Hauptseite:

• Wird nach Start des Agenten angezeigt
• Erlaubt die Konfiguration sowie das Starten des Spiels
• Auf der Hauptseite lässt sich das Spiel anhand eines Spielfelds verfolgen

HSQLDB:

• Hyper Structured Query Language Database
• Freie und vollständig in Java programmierte relationale SQL-Datenbank
• HSQL lässt sich als eingebettetes Datenbanksystem in andere Applikationen integrie-ren

Pusher-Schnittstelle:

• Kommunikation von Server und Agent über Events auf der Basis von WebSockets

Satz:

• Ein Agent spielt gegen einen anderen Agenten über den Server.
• Der Sieger erhält einen Punkt.
• Gibt es keinen eindeutigen Sieger, ermittelt der Server einen Sieger per Zufall

Spiel:

• Das Spiel heißt „4 gewinnt“
• Ein Spiel setzt sich aus drei Sätzen zusammen
• Es gibt einen Hinsatz, den Spieler O beginnt, einen Rücksatz, der von Spieler X begon-nen wird sowie einen Zufallssatz, in dem der beginnende Spieler zufällig ausgewählt wird

Spielfeld:

• Das Spielfeld setzt sich aus 7 Spalten und 6 Zeilen zusammen und bietet einen Rah-men, in dem die Spielsteine platziert werden können

Spielstand:

• Angabe der jeweils gewonnenen Punkte im aktuellen Spiel (jeder gewonnene Satz gibt einen Punkt)
• z. B. 1:2, 0:2 etc.

Thema:

• Beschreibt das Aussehen und die stilistische Gestaltung der graphischen Oberfläche
• Lässt sich über das Menüband der Hauptseite ändern

Zugzeit:

• Zeit, die der Server nach einem Zug eines Agenten wartet
• Datei-Schnittstelle: Nach dem Ablauf der Zugzeit prüft der Server, ob die Textdatei im spezifischen Pfad beschrieben wurde.
• Push-Schnittstelle: Der Server wartet bis zum Ablauf der Zugzeit und prüft dann, ob er ein Event vom Client empfangen hat.

15. Referenzen

• Balzert, H. (2000): Lehrbuch der Software-Technik, Software-Entwicklung.(2. Aufl.), Spektrum Akademischer Verlag.
• Lauterbach, M. (2015): Anforderungsbeschreibung Auftrag zum Bau eines Anwendungssys-tems in Form eines Software-Agenten (Version V6.00), DHBW Mannheim.