Analyse- und Entwurfsdokument

Heinz Nixdorf Institut Fachgruppe Softwaretechnik Zukunftsmeile 1 33102 Paderborn Analyse- und Entwurfsdokument im Rahmen des Softwaretechnikpraktikums 2014 Team 04

Inhaltsverzeichnis 1 Analyse 1 1.1 Architektur....................................... 1 1.1.1 Modularer Aufbau............................... 1 1.1.2 Server-Client-Architektur........................... 2 1.1.3 Model-View-Controller............................. 3 1.1.4 Observer-Pattern................................ 3 1.1.5 Strategy-Pattern................................. 4 1.2 Werkzeuge....................................... 5 1.2.1 Eclipse..................................... 5 1.2.2 Android..................................... 5 1.2.3 Graphiti und Graphical Editing Framework ersetzt durch SWT und SVG.. 5 1.2.4 Eclipse Modeling Framework......................... 6 1.2.5 JavaScript Object Notation........................... 6 1.2.6 Plug-in Development Environment....................... 6 1.3 Gamekonfigurator.................................... 7 1.3.1 Konfiguration erstellen............................. 7 1.3.2 Analyse-Klassendiagramm........................... 7 1.4 GameEngine...................................... 7 1.4.1 Spiel erstellen.................................. 7 1.4.2 Spiel kontrollieren............................... 9 1.4.3 Zug überprüfen................................. 9 1.4.4 Analyse-Klassendiagramm........................... 12 1.5 Client.......................................... 13 1.5.1 Mit dem Server Verbinden........................... 13 1.5.2 Spiel abschließen................................ 14 1.5.3 Zug durchführen................................ 14 1.5.4 KI-Spieler.................................... 17 1.5.5 Analyse-Klassendiagramm........................... 17 2 Entwurf 20 2.1 Das Game Model.................................... 20 2.1.1 Game Model Mapping............................. 21 2.2 Der Spielkonfigurator.................................. 21 2.2.1 de.scrabblenauts.configurator.view....................... 22 2.2.2 de.scrabblenauts.configurator.controller.................... 23 2.2.3 de.scrabblenauts.gamemodel.......................... 23 2.3 Die Game Engine.................................... 23 2.3.1 de.scrabblenauts.server.view.......................... 23 2.3.2 de.scrabblenauts.server.servercontroller.................... 23 2.3.3 de.scrabblenauts.server.network........................ 25 2.3.4 de.scrabblenauts.server.gamecontroller.................... 25 II

2.4 Der Smartphone-Spieler................................ 26 2.4.1 de.scrabblenauts.player.controller....................... 26 2.4.2 de.scrabblenauts.player.view.......................... 27 2.4.3 de.scrabblenauts.player.network........................ 28 2.4.4 de.scrabblenauts.player.data.......................... 28 2.5 Der KI-Spieler..................................... 28 2.5.1 Klassendiagramm................................ 28 2.5.2 de.scrabblenauts.player.ai........................... 28 2.5.3 de.scrabblenauts.player.ai.movegenerator................... 29 2.5.4 de.scrabblenauts.player.ai.strategy....................... 30 Abbildungsverzeichnis 32 III

1 Analyse In der Analyse werden die im Pflichtenheft abgesegneten Aufgabenbereiche genauer untersucht. Zunächst wird die Softwarearchitektur für die Programmteile festgelegt und deren Konsequenz erläutert. Bewährte Design-Pattern werden vorgestellt, die sich für die spätere Implementierung nützlich erweisen werden. UML-Diagramme helfen eine Übersicht über die zu entwickelnden Komponenten und deren Zusammenspiel zu bekommen. Ein weiterer Abschnitt verschafft einen Überblick über die benötigten Werkzeuge, die in diesem Projekt Anwendung finden. Zum Schluss werden die aufgelisteten Komponenten in ihre Objektstruktur dekompositioniert. Dies bedeutet insbesondere, dass ihre Struktur analysiert und ihr Verhalten dargestellt wird. 1.1 Architektur In diesem Kapitel wird die Softwarestruktur des Projekts skizziert. Eine Softwarearchitektur beschreibt das Grundgerüst, in dem sich die einzelnen Implementationsklassen eingliedern und zu einer funktionstüchtigen Komponente werden. 1.1.1 Modularer Aufbau Wie dem Pflichtenheft zu entnehmen ist, besteht das Projekt aus insgesamt fünf Bestandteilen. Diese setzen sich aus Game Engine, Spielkonfigurator, Smartphone-Beobachter, Smartphone-Spieler (bereitgestellt als eine Smartphone-App) und KI-Spieler zusammen. Da diese alle unterschiedliche Schnittstellen bereitstellen bzw. konsumieren, bietet sich ein modularer Aufbau als Grundstruktur an. Dies bedeutet insbesondere, dass alle fünf Komponenten für sich alleine lauffähige Software darstellen, die ohne die restlichen Komponenten aber nur teilweise funktionstüchtig sind. Die nur in den Schnittstellen abhängigen Komponenten bieten die Möglichkeit, bei veränderten Anforderungen nur änderungsrelevante, also spezifische Teile austauschen zu müssen. Dabei wird nicht die ganze Anwendung verändert, sodass eine Wartung deutlich vereinfacht wird. Abbildung 1.1 zeigt eine beispielhafte Verteilung der fertigen Software auf die benötigten Geräte. Dabei wird wie bereits im Pflichtenheft eine Unterteilung der Geräte in Server und Client vorgenommen. So befindet sich die Game Engine Komponente als zentrale Steuereinheit auf dem Server, während Smartphone-Beobachter und -Spieler, als zusammengefügtes Paket, nur auf ein Android Gerät aufgespielt werden können. Sie stellen die Seite des Clients dar. Smartphone-Beobachter und -Spieler werden bei der Bereitstellung zu einer Anwendung (App) gebündelt, um Codestrukturen, die für beide Komponenten benutzt werden können, optimal wiederzuverwenden. Der Spielkonfigurator wurde hier exemplarisch auf der Seite des Servers platziert, da die von ihm zu erstellende Konfiguration des Spiels zunächst einmal die Game Engine betrifft. Es wäre aber auch denkbar, diese Komponente auf einem anderen PC auszuführen und die Konfigurationsdatei per Dateitransfer für die Game Engine zugriffsbereit zu machen. Näheres dazu befindet sich in Abschnitt 1.1.2. Ähnlich zum Spielkonfigurator, hat auch der KI-Spieler kein festes Gerät. Er könnte sich auch direkt auf dem Server ausführen lassen und damit keinen eigenen PC beanspruchen wie in Abbildung 1.1 dargestellt. Insgesamt zeigt dies den groben Grundaufbau des Systems. Wir unterscheiden zu jeder Zeit die Seite des Servers von der Seite des Clients. Somit ist die Hauptarchitektur in unserem modularen System eine Server-Client-Architektur. 1

Abbildung 1.1: UML-Verteilungsdiagramm der Komponenten 1.1.2 Server-Client-Architektur Bei der Server-Client-Architektur, oder auch Zwei-Schichten-Architektur genannt, handelt es sich um eine Softwarestruktur für verteilte Anwendungen. Dabei nimmt der Teil der den Serverteil repräsentiert eine eher nicht interaktive Rolle als Dienstleister ein. Er steuert den Ablauf und die Geschäftsprozesse und validiert sie nach Gültigkeit. Ihm kommt im Netzwerk die Aufgabe zu, die einzelnen Clients zu steuern. Der Teil der Clients ist in der Regel hoch interaktiv mit dem Benutzer des Systems. Hier werden Eingaben des Benutzers entgegen genommen und zur Validierung an den Server gesendet. Gibt dieser sein OK, so hat der Benutzer eine erlaubte Handlung vollzogen. Abbildung 1.2: UML-Komponentendiagramm der Scrabble-Variante Abbildung 1.2 bezieht diese Grundstruktur nun auf unsere Scrabble-Variante. Dabei sind insgesamt drei Schnittstellen geplant. IServer Die Komponente, die diese Schnittstelle bereitstellt, platziert sich auf der Serverseite des Systems. Sie ist in der Lage die Steuerung des Systems zu übernehmen. Sie entscheidet über gültige Spielzüge und fordert den Datenverkehr über das Netzwerk an. Komponenten, die diese 2

Schnittstelle konsumieren, sind dagegen auf der Client-Seite anzusiedeln. Sie können mit der bereitstellenden Komponente kommunizieren und ihre Anforderungen erfüllen. IViewer Komponenten, die diese Schnittstelle bereitstellen, sind in der Lage ein laufendes Spiel zu beobachten. Sie bekommen von der Serverkomponente die benötigten Informationen bereitgestellt und sind damit in der Lage das Spiel auf einem Ausgabegerät darzustellen. Die konsumierende Komponente nimmt den Wunsch ein Spiel zu beobachten auf und entscheidet, ob dies zugelassen wird. Sie stellt die benötigten Informationen für die Beobachtung bereit. IPlayer Ähnlich wie die IViewer-Schnittstelle, können bereitstellende Komponenten der IPlayer- Schnittstelle Spielen beiwohnen. Der Unterschied besteht im Wesentlichen darin, dass diese Komponenten nun interaktiv mit dem Server kommunizieren, um das eigentliche Spiel zu spielen. Die konsumierende Komponente kann, wie beim IViewer, den Wunsch des Mitspielens erlauben oder verweigern. Erlaubt sie den Zugriff muss sie die Spielzüge entgegennehmen und den aktuellen Status des Spiels mitteilen. Näheres zu den Schnittstellen befindet sich im Interface-Dokument. Abbildung 1.2 zeigt nun bereitstellende und konsumierende Komponenten des Systems. Dabei stellt die Game Engine die IServer-Schnittstelle bereit. Diese wird von allen Komponenten der Client- Seite konsumiert, welche wiederum entweder die Schnittstelle IViewer oder IPlayer bereitstellen. Diese Schnittstellen werden dann von der Game Engine konsumiert um die benötigten Informationen bereitzustellen. Als letztes zeigt Abbildung 1.2 die Komponente Spielkonfigurator. Sie zeichnet sich im Besonderen dadurch aus, dass sie keine Programmierschnittstelle anbietet. Ihre Ausgabe ist eine Spielkonfiguration im ECore-Format, welche als Datei exportiert und von der Game Engine importiert werden kann. 1.1.3 Model-View-Controller Mit dem Modell der Server-Client-Architektur ist nun der erste wichtige Baustein für das System gelegt. Trotzdem garantiert dieses Modell noch keine einfache Wartbarkeit und Testmöglichkeit. Darum erweitern wir die Grundarchitektur um das bewährte Modell der Model-View-Controller-Architektur. Diese Architektur soll in den einzelnen Komponenten Anwendung finden, die zunächst erst grob von der Server-Client-Architektur unterschieden worden waren. Das grundlegende Modell, welches in Abbildung 1.3 gezeigt wird, unterscheidet in drei Arten von Klassen: Model, View (später auch Boundary genannt) und Control. Dabei hat jeder Typ seine dedizierte Aufgabe. So hält eine Klasse vom Typ Model nur Daten, die von der View auf einem Ausgabegerät dargestellt werden können. Eine Klasse vom Typ Control kontrolliert den Zugriff auf die Daten und kann sie bei Aufforderung verändern. Dies führt, wie in Abbildung 1.3 dargestellt, zu einer Veränderung im Model, welches eine Klasse vom Typ View veranlasst, die Darstellung zu ändern. Um diese Architektur lauffähig und effizient zu halten, sollte jede Klasse auf ihren Typ reduziert werden und ihren Aufgabenteil erfüllen. Eine Vermischung von zwei, oder gar allen drei Typen, ist nicht vorgesehen. 1.1.4 Observer-Pattern Das Observer-Pattern, oder auch Beobachter genannt, ist ein bewährtes Design-Pattern aus der Softwaretechnik und gehört zu der Art der Verhaltensmuster. Zum Zweck des Observer-Patterns schrieben Gamma, Helm, Johnson & Vlissides (2004): Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so daß [sic] die Änderung des Zustands eines Objektes dazu führt, daß [sic] alle abhängigen Objekte benachrichtigt und automatisch aktualisiert werden. Es fügt sich nahtlos in die Architektur von Model-View-Controller ein, da auch hier dessen Typen exakt unterschieden werden müssen. 3

Abbildung 1.3: Modell des Model-View-Controller (von http://en.wikipedia.org/wiki/file:mvc- Process.svg [Zugriff am 13.05.2014]) Abbildung 1.4: Struktur des Observer-Pattern nach Gamma et. al. (2004) Abbildung 1.4 zeigt die Struktur des Observer-Patterns. Sie zeigt, dass sich jedes Model (Subject), welches sich beobachten lässt, sich seinen Zustand merkt und diesen bei Veränderungen all seinen Beobachtern mitteilt. Dabei unterscheidet man zwischen der abstrakten Definition eines Subjekts und dessen konkreter Implementierung. Dies ist auch auf der Seite des Beobachters der Fall. Erst dadurch ist die Beobachtung von 1-zu-n-Abhängigkeiten möglich. Das Observer-Pattern bietet eine gute Möglichkeit die Visualisierung für das Spielbrett zu verwalten. 1.1.5 Strategy-Pattern Das Strategy-Pattern ist ein bewährtes Design-Pattern aus der Softwaretechnik und gehört zu der Art der Verhaltensmuster. Zum Zweck des Strategy-Pattern schrieben Gamma, Helm, Johnson & Vlissides (2004): Definiere eine Familie von Algorithmen, kapsele jeden einzelnen und mache sie austauschbar. Das Strategiemuster ermöglicht es, den Algorithmus unabhängig von ihn nutzenden Klienten zu variieren. Abbildung 1.5 zeigt die Struktur des Strategy-Patterns. Sie zeigt, dass ein Context-Objekt mithilfe eines Strategy-Objektes ein bestimmtes Problem löst. Dabei werden die jeweiligen Strategien zur Problemlösung innerhalb der ConcreteStrategy-Klassen implementiert. Dabei dient die Strategy-Klasse als Schnittstelle, die von allen konkreten Strategien verwendet wird. 4

Abbildung 1.5: Struktur des Strategy-Pattern nach Gamma et. al. (2004) 1.2 Werkzeuge Die folgenden externen Werkeuge werden in Übereinstimmung mit dem Lastenheft genutzt, um das Projekt Implementierung eines verteilten Scrabble-Spiels umzusetzen. 1.2.1 Eclipse Eclipse ist eine Open-Source Entwicklungsumgebung, die ursprünglich für Java entwickelt wurde. Allerdings lässt sich Eclipse mit Hilfe von Plugins um eine Fülle an Funktionalität erweitern. Die im Softwaretechnik Praktikum verwendete Version 4.3.2 (Eclipse Kepler) beinhaltet keine eigene Funktionalität, sondern ist ausschließlich pluginbasiert. Dies bietet uns die Möglichkeit, die SwtPra- Komponente Spielkonfigurator einfacher den Vorgaben entsprechend als Eclipse-Plugin umzusetzen, da wir auf eine vorhandene und bewährte Plugin-Struktur namens Plug-in Development Environment (PDE) zurückgreifen können. Zur Java-Entwicklung werden wir das Plugin Java Devolpment Tools (JDT) verwenden, welches eine Vielzahl an nützlicher Funktionalität zur Java-Entwicklung bietet. Um die Entwicklung einfacher zu gestalten werden wir das Eclipse Software Development Kit (SDK) benutzen, welches bereits die Java Development Tools (JDT) und Plug-in Development Environment (PDE) enthält. Zusätzlich dazu werden wir wie vorgegeben das Java Development Kit (JDK) Version 1.7 und die Java Runtime Environment (JRE) Version 1.7 als Laufzeit-Umgebung nutzen. 1.2.2 Android Android ist ein Smartphone-Betriebssystem, welches auf dem Linux Kernel basiert. Für das Softwaretechnik Praktikum werden wir auf der Android-Version 4.0 (API-level 15) einen Smarphone-Spieler umsetzen. 1.2.3 Graphiti und Graphical Editing Framework ersetzt durch SWT und SVG Graphiti und das Graphical Editing Framework (GEF) sind Eclipse-Frameworks, welche für die Erstellung von graphischen Oberflächen und Editoren entwickelt wurden. Dabei bietet sich die Nutzung 5

von Graphiti und GEF deswegen an, weil diese Frameworks die Model-View-Controller (MVC) Architektur umsetzen. Der Empfehlung des Lastenheftes widersprechend werden wir nicht GEF und Graphiti benutzen. Diese Entscheidung haben wir nach reichlicher Überlegung getroffen, bei der folgende Gründe sich ergeben haben: Die Eclipse Frameworks Graphiti und GEF sind sehr mächtige, und deswegen auch sehr umfangreiche Werkzeuge. Um unsere graphischen Oberflächen zu entwickeln reichen uns die Möglichkeiten eines kompakteren Werkzeuges vollkommen aus. Außerdem entsteht durch die große Komplexität von Graphiti und GEF für unser Team, dass über höchstens oberflächliche Kenntnisse der Funktionsweise von Graphiti und GEF verfügt, ein nicht zu vernachlässigender Einarbeitungsaufwand, den wir so umgehen können. Alternativ werden wir das Standard Widget Tool (SWT) verwenden, um alle unsere Oberflächen zu entwickeln. Die Möglichkeiten des SWT sind für unsere Zwecke hervorragend geeignet, weil sich mit Hilfe des SWT auf einfache Weise produktive Oberflächen erstellen lassen. Zusätzlich dazu bietet die SWT-eigene Struktur, welche auf Event-Klassen und Listener-Methoden aufgebaut ist, bereits die Möglichkeit, die MVC Architektur umzusetzen. Ein weiterer Grund für diese Entscheidung war, dass bereits einige Mitglieder unserer SWTPra- Gruppe einige Erfahrung mit SWT gesammelt haben und so die anderen Gruppenmitglieder bei der Nutzung von SWT unterstützen können. Zusätzlich dazu haben wir beschlossen, sämtliche Graphiken für die graphischen Oberflächen entsprechend der Scalable Vector Graphics (SVG) - Spezifikation zu hinterlegen, um bei jeder Auflösung optimale Symbole zu erzeugen. 1.2.4 Eclipse Modeling Framework Das Eclipse Modeling Framework (EMF) ist ein Open Source Framework, welches die Möglichkeit bietet Quelltext und dynamische Instanzen aus Modellen zu generieren. Dieses Framework ist für das diesjährige Softwaretechnik Praktikum in doppelter Hinsicht wichtig, da auf der einen Seite die Netzwerk-Kommunikation und auf der anderen Seite die Syntax einer Spielkonfiguration über ein EMF-Modell geregelt ist. So wird eine Spielkonfiguration als dynamische Instanz der Wurzelklasse Configuration aus dem Spielkonfigurations-EMF-Modell entwickelt. Die fertige Spielkonfiguration liegt abschließend als xmi-datei vor. 1.2.5 JavaScript Object Notation JavaScript Object Notation (JSON) ist ein offener Standard zur Übermittlung von Informationen in Form von Key-Value Paaren. Innerhalb des diesjähren Softwaretechnik Praktikums wird JSON für die gesamte Netzwerkkommunikation genutzt. Jeder Befehl bzw. jede Information wird also durch eine JSON-Datei übermittelt. Die genaue Syntax der JSON-Dateien wird dabei durch ein EMF-Modell bestimmt, welches vom Interface-Komitee entworfen wurde. Durch das Erstellen eines Objektes einer Klasse aus dem Netzwerk-EMF-Modell und dem anschließenden genormten Serialisierungsprozess können so einheitliche, von jeder Gruppe interpretierbare JSON-Dateien erstellt werden. 1.2.6 Plug-in Development Environment Der Zweck des Plug-in Development Environment (PDE) ist die Entwicklung und Verwaltung neuer bzw. selbst-erstellter Eclipse-Plugins. Dabei ist PDE selbst als Plugin in Eclipse integriert. Mit Hilfe 6

der drei Hauptkomponenten Build, UI und API Tools von PDE ist es möglich, die Entwicklung, die Wartung, das Testen, die Erstellung und Nutzung von Plugins in einer einzigen Umgebung (PDE) durchzuführen. 1.3 Gamekonfigurator 1.3.1 Konfiguration erstellen Das Diagramm (Abbildung 1.6) beschreibt ein Szenario, indem der User eine Konfiguration für ein Spiel erstellt. Er muss durch die Haupt-GUI die Größe des Spielfelds, die Verteilung der Premiumfelder und eine Gewinn-Kondition festlegen. Zusätzlich muss er sich zwischen einer natürlichen Sprache und einer erstellten Kategorie entscheiden. Die Erstellung der Kategorien erfolgt über der Kategorie-GUI, in der man die Wörter der Kategorie, die Verteilung der Punkte der Buchstaben und ihre Anzahl im Beutel festlegt. Schließlich hat der User die Möglichkeit eine Konfigurations-Datei mit den angegebenen Einstellungen zu erstellen. 1.3.2 Analyse-Klassendiagramm Im folgenden werden die Aufgaben der in Abbildung 1.7 dargestellten Klassen erläutert. Boundary MainGui Die MainGUI (Haupt-Gui genannt) visualisiert die verschiedene Einstellungsoptionen zur Konfiguration. CategoryGui Die CategoryGui visualisiert die verschiedene Einstellungsoptionen zur einer bestimmte Kategorie. Control ConfigurationControl Die ConfigurationControl verwaltet die Anfragen zur Änderung der Einstellungen, überprüft sie und gibt sie dem ConfigurationModel weiter. Entity Die Klassen aus der Entity-Schicht haben nur die Aufgabe die Daten der Spiele zu speichern und sind somit Selbsterklärend. 1.4 GameEngine 1.4.1 Spiel erstellen Szenariobeschreibung Das Diagramm (Abbildung 1.8) beschreibt ein Szenario, indem der User sich entscheidet, ein Spiel zu erstellen. Er wird zunächst die GUI verwenden, um Spieler zu dem Spiel hinzuzufügen oder Spieler zu entfernen. Hat er sich für eine Aufstellung entschieden, kann er den Startspieler bestimmen. Dies kann entweder durch einen Zufallsgenerator der Spielsteuerung geschehen oder indem der User die 7

8 Abbildung 1.6: Der Host benutzt die GUI, um eine Konfiguration zu erstellen

Abbildung 1.7: Analyse-Klassendiagramm der GameEngine Reihenfolge manuell verändert. Nun hat der User die Möglichkeit, einen 5 Sekunden Timeout zu aktivieren. Tut er dies, werden alle KI Spieler aus dem Spiel gekickt, wenn sie länger als 5 Sekunden für eine Antwort brauchen. Anschließend schickt die GUI die Konfigurationsdaten an die Spielsteuerung, welche eine Datei daraus erstellt. Diese Datei wird von der Spielsteuerung an alle Teilnehmer des Spieles gesandt. Die Spielsteuerung wartet jetzt 10 Sekunden, bevor sie das Spiel letztendlich startet und den ersten Spieler auffordert, seinen Zug zu tätigen. 1.4.2 Spiel kontrollieren Das Szenario Spiel kontrollieren dient dazu, dass der Host das Spiel unterbrechen, fortsetzen und abbrechen kann. Hierzu wird nur eine Klasse, die den Befehl entgegen nimmt, benötigt. Diese prüft anschließend den Zustandes des Spieles, setzt es ggf. neu und informiert die Clients über den neuen Zustand bzw. informiert den Host darüber, dass das Spiel bereits im entsprechenden Zustand ist. Details über diesen Vorgang finden sich in Kapitel 3.1.3 des Pflichtenheftes oder der entsprechenden Abb. 3.4 eben dort. Da dieser Vorgang so einfach ist, wird hier bewusst auf ein Analysesequenzdiagramm verzichtet. 1.4.3 Zug überprüfen Das Diagramm (Abbildung 1.9) beschreibt ein Szenario, in dem ein Spielzug auf Gültigkeit überprüft wird. Zunächst übermittelt der Server der Spielsteuerung den nächsten Zug m des aktuellen Spielers. Für die Gültigkeitsüberprüfung ist BoardLogic zuständig. Abhängig von der Art des Spielzugs wird nun die Gültigkeit überprüft: pass Ein Spielzug, in dem der Spieler passt, ist immer gültig. exchange tiles Ein Wechseln von Spielsteinen mit dem Beutel ist genau dann gültig, wenn noch genügend Steine (mind. sieben) darin vorhanden sind. 9

Abbildung 1.8: Der Host benutzt die GUI, um ein Spiel zu erstellen play Damit das Legen eines Wortes gültig ist, muss das Wort einerseits im Dictionary sein, andererseits muss es die Legeregeln einhalten: angrenzend von bestehenden Steinen liegen, alle Steine in derselben Spalte/Zeile, etc. Ist dies alles erfüllt, werden die Steine auf dem Brett platziert. Ist der Spielzug ungültig, wird dem Spieler (über den Server) ein Fehler gemeldet und er wird zu einem neuen Zug aufgefordert. Ist der Spielzug hingegen gültig, wird allen Spielteilnehmern mitgeteilt, was geschehen ist, insbesondere werden sie über den neuen Zustand des Bretts informiert, sofern Steine gelegt wurden. Danach wird der nächste Spieler zum Spielzug aufgefordert. 10

Abbildung 1.9: Ein vom Spieler gemachter Zug wird auf Gültigkeit geprüft 11

Abbildung 1.10: Analyse-Klassendiagramm der GameEngine 1.4.4 Analyse-Klassendiagramm Im folgenden werden die Aufgaben der in Abbildung 1.10 dargestellten Klassen erläutert. Boundary GameEngineGUI Die GameEngineGUI visualisiert die GameEngine für den Benutzer und wird bei Veränderungen der darunter liegenden Kontrollklassen aktualisiert. Server Es existiert nur ein Objekt der Server Klasse. Der Server stellt Funktionalitäten bereit die von Clients über das Netzwerk aufgerufen werden. Diese werden durch die Methoden beschrieben. ClientConnection Diese Klasse repräsentiert die Verbindung zu den Clients die sich mit dem Server verbunden haben. Es kann sich dabei sowohl um (KI-)Spieler als auch um Beobachter handeln. Die Methoden der Klasse haben die Aufgaben Informationen weiter an den Client zu senden. 12

Control GameLobby Ein Objekt der GameLobby Klasse verwaltet ein Spiel, das von dem Host geöffnet wurde und in dem sich Spieler anmelden können. Haben sich genügen Spieler registriert und der Host hat entschieden wer mitspielen darf, dann kann er das Spiel starten. In diesem Fall wird ein GameControl Objekt erstellt und die Lobby geschlossen. GameControl Die GameControl Klasse kümmert sich um den Ablauf der Spiele. Es werden Daten an die Mitspieler gesendet und Züge ausgewertet. GameEngine Die GameEngine verwaltet sowohl die Lobbys als auch die laufenden Spiele und leitet Anfragen die über das Server Objekt gehen weiter. BoardLogic Die BoardLogic verwaltet die Spiellogik eines Spiels. Sie aktualisiert das Spielfeld und überprüft Züge auf ihre Gültigkeit. Entity Die Klassen aus der Entity-Schicht haben nur die Aufgabe die Daten der Spiele zu speichern und sind somit Selbsterklärend. 1.5 Client 1.5.1 Mit dem Server Verbinden Abbildung 1.11: Ein menschlicher Nutzer der App verbindet sich mit dem Server 13

Szenariobeschreibung In der Abbildung 1.11 ist ein mögliches Szenario zu sehen, wie die Verbindung eines menschlichen Users am Smartphone mit dem Server ablaufen kann. Dabei sind auf dem Smartphone die Klassen ConnectionGUI, AppLogic, ServerConnection, User und nach der erfolgreichen Registrierung die LobbyGUI beteiligt. Der Benutzer sieht nach dem Starten der App einen Connect to Server Button sowie ein Feld zur optionalen Eingabe eines Namens. Beim Klick des Buttons wird dem Server eine Anfrage übermittelt, dass ein Client sich am Server registrieren möchte. Diese Anfrage ist im Interface-Dokument festgelegt. Dabei wird dem Server mitgeteilt, welche Fähigkeiten dieser Client hat, also ob er zuschauen und ob er spielen kann. Nutzer der App können beides, daher wird hier für beide Werte true übermittelt, zusammen mit dem gewählten Namen. In unserem Beispiel gibt der User den Namen Bob ein. Sollte der Server nicht innerhalb einer festgelegten Zeitspanne antworten, so ruft die ServerConnection auf der AppLogic eine Methode zur Fehlerbehandlung auf. Dem Benutzer wird eine entsprechende Fehlermeldung angezeigt und ein Retry -Button um erneut die selbe Verbindungsanfrage zu senden. Bei erfolgreicher Verbindung fügt der Server den Benutzer zur Kontaktliste hinzu. Der Server sendet das ConfirmLoginCommand und übergibt eine Id, mit der der Client von da an vom Server identifiziert werden kann. Erst bei Erhalt dieses Wertes zeigt die App dem User eine entsprechende Erfolgsmeldung an. Die LobbyGUI wird gestart und die Oberfläche um die Verbindung zu starten wird nicht länger angezeigt. Eine KI schickt ebenfalls die im Interface-Dokument festgelegte Anfrage LoginCommand an den Server, um sich zu registrieren. Der Server sendet bei erfolgreicher Registrierung ConfirmLoginCommand, die die Id übergibt. 1.5.2 Spiel abschließen Szenariobeschreibung Das Diagramm (Abbildung 1.12) beschreibt ein Szenario, in dem der User sich entscheidet, ein Spiel zu verlassen. Der erste Abschnitt der Alternative bezeichnet dabei das Szenario, falls der User ein Observer ist. Er bekommt zum Abschluss die Ergebnisliste angezeigt. Der zweite Abschnitt der Alternative hingegen bezeichnet das Szenario, falls der User ein Spieler ist. Er meldet sich vorher beim Server ab, so dass dieser Prüfen kann, ob genug ( 2) Spieler verbleiben. Der Server kann ggf. das Spiel beenden, falls nur apple 1 Spieler verbleiben. Der User bekommt in jedem Fall zum Abschluss die Ergebnisliste angezeigt. 1.5.3 Zug durchführen Szenariobeschreibung Das Diagramm (Abbildung 1.13) beschreibt ein Szenario, in dem ein Spieler einen Zug durchführt. Der erste Abschnitt der Alternative bezeichnet dabei das Szenario, dass der Spieler seinen Zug aussetzen möchte. Dies wird vom Server in jedem Falle akzeptiert. Der zweite Abschnitt der Alternative bezeichnet das Szenario, dass der Spieler manche seiner Spielsteine austauschen möchte. Dabei wählt der Spieler aus, welche Spielsteine er tauschen möchte und wählt dann den Button zum Tauschen. Diese Spielsteine werden dem Server mitgeteilt, welcher in diesem Szenario neue Spielsteine zurückliefert. Diese Änderung wird auch im GameModel gespeichert. Der dritte Abschnitt der Alternative bezeichnet schließlich das Szenario, dass der Spieler manche seiner Spielsteine auf dem Spielbrett platziert. Nach dem Senden des Zuges an den Server, liefert 14

Abbildung 1.12: Szenario: Das Spiel abschließen 15

Abbildung 1.13: Szenario: Zug durchführen dieser hier eine Bestätigung, dass der Zug akzeptiert wurde, sowie die neuen Steine für den Spieler. 16

Auch hier wird die Änderung wieder im GameModel gespeichert. 1.5.4 KI-Spieler Der KI-Spieler funktioniert ähnlich wie ein normaler, menschlicher Spieler, denn er verwendet dieselben Schnittstellen. Anstelle einer GUI, über die ein Mensch seine Züge eingeben kann, existiert jedoch das AI-Modul, eine Komponente, welche das Verhalten der KI bestimmt und versucht, möglichst gute Züge zu finden. Dieses Modul wird mithilfe der Konsole angesteuert, wobei durch Kommandozeilenargumente folgende Optionen bestimmt werden: 1. Name des AI-Spielers 2. Spiele zu denen er sich registriert 3. Optional: Bestimmung des Verhaltens der KI Außerdem gibt der KI-Spieler Informationen zu den Zügen die er gemacht hat auf dieser Konsole aus. 1.5.5 Analyse-Klassendiagramm Das Klassendiagramm in Abbildung 1.14 ergibt sich aus den bereits genannten Szenarien. Im Folgenden werden die Aufgaben der dargestellten Klassen erläutert. 1.5.5.1 Boundary ConnectionGUI Die ConnectionGUI visualisiert den Verbindungsaufbau vom Client zum Server. Hier wird der Nutzer die Verbindung konfigurieren und verwalten können, wie beispielsweise neue Verbindungsversuche bei Fehlern während des Verbindungsaufbaus unternehmen. GameView Die GameView ist die GUI, die der Spieler während des Spieles sieht. Hier werden das Brett, die Punkte und die eigenen Steine angezeigt und die Möglichkeit gegeben, einen Zug durchzuführen oder das Spiel zu verlassen. LobbyGUI Die LobbyGUI visualisiert die Spiellobby, in der man sich für Spiele registrieren kann. Hier werden dem Nutzer die Spiele angezeigt, die der Server zur Verfügung stellt und man kann sich für sie anmelden oder die Verbindung beenden. ServerConnection Die ServerConnection ist die Boundary-Klasse, welche mit dem Server kommuniziert. Sämtliche Kommunikation, die der Client mit dem Server hat, läuft über diese Klasse. Ein entsprechendes Gegenstück wird es auf der Server-Seite geben. 1.5.5.2 Control AppLogic Die AppLogic verwaltet alle Aktionen der User und verwaltet die GUIs, sodass immer die richtige GUI angezeigt wird. Es gibt hier nur eine Klasse, da der Client eine sehr kleine Komponente ist, die letztlich nicht mehr kann, als mit dem Server zu kommunizieren und das Spiel, das der Server liefert anzuzeigen. Daher sind die Operationen in der Logik nicht viele und alle einfach zu realisieren. Eine Intelligenz ist hier kaum bis nicht vorhanden. 17