Analyse & Entwurf - Heinz Nixdorf Institut€¦ · Heinz Nixdorf Institut Fachgruppe...

Heinz Nixdorf InstitutFachgruppe Softwaretechnik

Zukunftsmeile 133102 Paderborn

Analyse & Entwurfim Rahmen des Softwaretechnikpraktikums 2012

Team 06

Betreuerin: Shari Fee LindoProjektleiter: Alexei Quapp

Verantwortlicher: Jan Bobolz

Paderborn, den 25. Mai 2012

Autoren:Jan Bobolz Christoph RüthingRichard Borkowski Tim VinkemeierDavid Brenken Monika WedelMarkus Jeromin Alexander WinklerAlexei Quapp Rebekka Wohlrab

Inhaltsverzeichnis

1 Analyse - Übersicht über Komponenten des Systems 11.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Hauptkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Beobachter/Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3 Bieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Externe Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.2 Plug-in Development Environment . . . . . . . . . . . . . . . . . . . 21.3.3 Rich-Client-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.4 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . 31.3.5 Standard Widget Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 31.3.6 Remote Method Invocation . . . . . . . . . . . . . . . . . . . . . . . 31.3.7 Graphical Editor Framework . . . . . . . . . . . . . . . . . . . . . . 3

2 Analyse - Komponenten des Servers 32.1 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Komponenten zur Spielverwaltung . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 ServerInterfaceControl . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 ServerTournamentControl . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 ServerTournamentView . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.4 ServerCreateGameControl . . . . . . . . . . . . . . . . . . . . . . . 52.2.5 ServerCreateGameView . . . . . . . . . . . . . . . . . . . . . . . . 52.2.6 ServerMainControl . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.7 TournamentManager . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Komponenten für die Spieldurchführung . . . . . . . . . . . . . . . . . . . . 62.3.1 ServerGameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 ServerGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Verwaltung der Client-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.1 ServerClientManager . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 ServerClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.3 ServerPlayerClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.4 ServerViewerClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.5 ServerBidderClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Verbindung zu den Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 ServerToClientConnectionManager . . . . . . . . . . . . . . . . . . 82.5.2 ServerToClientConnection und Unterklassen . . . . . . . . . . . . . 9

2.6 Komponenten für den Bieter . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.1 ServerBidderClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Inhaltsverzeichnis

2.6.2 ServerBidderControl . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.3 ServerToBidderConnectionManager . . . . . . . . . . . . . . . . . . 92.6.4 ServerToBidderConnection . . . . . . . . . . . . . . . . . . . . . . . 10

3 Analyse - Komponenten der Clients 103.1 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 ClientToServerConnection . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 PlayerClientConnection . . . . . . . . . . . . . . . . . . . . . . . . 113.2.3 ViewerClientConnection . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Clientsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.1 GameClientController . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.2 PlayerIdentity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Clientoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4.1 ViewerGuiController . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4.2 PlayerGuiController . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4.3 GameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 Computergegner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5.1 AIPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Analyse - gemeinsam genutzte Komponenten 124.1 LobbyView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 RuleChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 GameModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 CommonInterfaceConverter . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Analyse - Komponenten des Bieters 135.1 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2 Persistente Klassen und Verbindung . . . . . . . . . . . . . . . . . . . . . . 13

5.2.1 BidderService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2.2 BidderToServerConnection . . . . . . . . . . . . . . . . . . . . . . . 145.2.3 BidderAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.3 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3.1 BidderConnectionActivity . . . . . . . . . . . . . . . . . . . . . . . 155.3.2 BidderBetActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3.3 BidderMainActivity . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Allgemeines zum Entwurf 156.1 Struktur der Komponenten weiter detaillieren . . . . . . . . . . . . . . . . . 156.2 Abläufe innerhalb der Komponenten weiter verfeinern . . . . . . . . . . . . 16

III

Inhaltsverzeichnis

7 Entwurf - Komponenten des Servers 167.1 Sequenzdiagramm: Turnier einrichten/Spiel starten . . . . . . . . . . . . . . 167.2 Sequenzdiagramm: Spiel beenden . . . . . . . . . . . . . . . . . . . . . . . 177.3 Komponenten zur Spielverwaltung . . . . . . . . . . . . . . . . . . . . . . . 19

7.3.1 ServerInterfaceControl . . . . . . . . . . . . . . . . . . . . . . . . . 197.3.2 ServerTournamentControl . . . . . . . . . . . . . . . . . . . . . . . 207.3.3 ServerCreateGameControl . . . . . . . . . . . . . . . . . . . . . . . 207.3.4 ServerTournamentView . . . . . . . . . . . . . . . . . . . . . . . . . 207.3.5 ServerCreateGameView . . . . . . . . . . . . . . . . . . . . . . . . 207.3.6 ServerMainControl . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.3.7 TournamentManager . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.4 Komponenten für die Spieldurchführung . . . . . . . . . . . . . . . . . . . . 237.4.1 ServerGameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.4.2 ServerGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.5 Verwaltung der Client-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 247.5.1 ServerClientManager . . . . . . . . . . . . . . . . . . . . . . . . . . 247.5.2 ServerClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.6 Verbindung zu den Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.6.1 ServerToClientConnectionManager . . . . . . . . . . . . . . . . . . 257.6.2 ServerToClientConnection und Unterklassen . . . . . . . . . . . . . 26

7.7 Komponenten für den Bieter . . . . . . . . . . . . . . . . . . . . . . . . . . 297.7.1 ServerBidderClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.7.2 ServerBidderControl . . . . . . . . . . . . . . . . . . . . . . . . . . 297.7.3 ServerToBidderConnectionManager . . . . . . . . . . . . . . . . . . 307.7.4 ServerToBidderConnection . . . . . . . . . . . . . . . . . . . . . . . 31

8 Entwurf - Komponenten der Clients 318.1 Sequenzdiagramm: Angriff wurde ausgeführt . . . . . . . . . . . . . . . . . 318.2 Sequenzdiagramm: Angriff ausführen . . . . . . . . . . . . . . . . . . . . . 328.3 Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.3.1 ClientToServerConnection . . . . . . . . . . . . . . . . . . . . . . . 348.3.2 PlayerClientConnection . . . . . . . . . . . . . . . . . . . . . . . . 348.3.3 ViewerClientConnection . . . . . . . . . . . . . . . . . . . . . . . . 35

8.4 Clientsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.4.1 GameClientControl . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.4.2 PlayerIdentity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.5 ClientOberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.5.1 ViewerGuiControl . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.5.2 PlayerGuiControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.5.3 GameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.6 Computergegner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.6.1 AIPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

IV

8.6.2 Konzept für die Aufbauphase . . . . . . . . . . . . . . . . . . . . . 398.6.3 Konzept für die Angriffsphase . . . . . . . . . . . . . . . . . . . . . 40

9 Entwurf - gemeinsam genutzte Komponenten 419.1 RuleChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.2 GameModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

10 Entwurf - Komponenten des Bieters 4310.1 Persistente Klassen und Verbindung . . . . . . . . . . . . . . . . . . . . . . 43

10.1.1 BidderService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.1.2 BidderToServerConnection . . . . . . . . . . . . . . . . . . . . . . . 4310.1.3 BidderAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

10.2 Activitys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4410.2.1 BidderConnectionActivity . . . . . . . . . . . . . . . . . . . . . . . 4510.2.2 BidderBetActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Abbildungsverzeichnis 46

1 Analyse - Übersicht über Komponenten des Systems

1.1 Architektur

Das Schiffe-Versenken-System wird anhand des Entity-Control-Boundary Architekturmusters(ECB) analysiert und umgesetzt. Die Grundstruktur baut auf der 3-Schichten-Architektur undsomit folgenden drei Klassentypen auf:

• Entity - Klassen, die persistente Daten speichern und zur Verfügung stellen

• Control - Klassen, die Logik und Funktionalität repräsentieren

• Boundary - Klassen, die als Schnittstelle zwischen Actor und System bzw. Komponen-ten dienen

Auf den ersten Blick sehen sich ECB und das Model-View-Controller-Architekturmustersehr ähnlich (Entity = Model, Boundary = View, Control = Controller).Es besteht jedoch ein erheblicher Unterschied hinsichtlich der Rolle der Control/des Con-trollers. Bei MVC hat der Controller eine reine Steuerungsfunktion, während das Model dieFunktionalität übernimmt.Die Control bei ECB dagegen übernimmt sowohl Steuerung als auch Funktion. Dies liefertden Vorteil einer stabileren Datenhaltung in den Entitys und wartungsfreundlicheren Control-Objekten.

1.2 Hauptkomponenten

Das Schiffe-Versenken-System wird, dem Server-Client-Model entsprechend, in mehrerenHauptkomponenten realisiert. Eine Hauptkomponente wird dabei als Modul mit festgelegtemInterface gesehen und kann dementsprechend einfach ausgetauscht, gewartet und erweitertwerden. Eine Hauptkomponente kann dabei intern aus weiteren Unterkomponenten bestehen.

1.2.1 Server

Der Server als Komponente kommuniziert mit den Clients über eine festgelegte Schnittstelleund reagiert auf die Aktionen der Clients. Zur Hauptaufgabe des Servers gehört die Organisa-tion und Durchführung der einzelnen Spiele. Dabei überwacht dieser die einzelnen Spielzügeder Spieler-Clients und verwaltet die Konten der Bieter-Clients.

1.2.2 Beobachter/Spieler

Die Beobachter-/Spieler-Clients können sich an einem Server anmelden und an einem Spielteilnehmen. Der Unterschied zwischen Spieler und Beobachter besteht darin, dass ein Spielerzusätzlich zu den Funktionen des Beobachters aktiv am Spielgeschehen teilnehmen kann.

1

1 Analyse - Übersicht über Komponenten des Systems

1.2.3 Bieter

Der Bieter-Client wird als Android-Anwendung realisiert und daher als eigene Komponenteumgesetzt, weil sich dieser sowohl im Bezug auf die Schnittstellen, als auch im Bezug auf dieGUI vom Beobachter-/Spieler-Client unterscheidet.

1.3 Externe Komponenten

Durch die Forderung, das verteilte Schiffe-Versenken-System als Eclipse-Plugin zu entwickelnergibt sich die Nutzung der weiteren externen Komponenten.

1.3.1 Eclipse

Eclipse ist eine Java-basierte Open-Source-Entwicklungsumgebung und ermöglicht die Inte-gration von Plugins zur Erweiterung der Funktionalität. Daher bildet das Eclipse SDK zu-sammen mit der zugehörigen Java-Laufzeitumgebung (JRE) die Laufzeitumgebung für das zuentwickelnde Plugin. Solche Plugins können über so genannte Extension-Point-Funktionenandere Plugins nutzen oder selbst Funktionalität anbieten. Eclipse ist ab der Version 3.0 nurnoch der Kern, der weitere Plugins lädt, welche anschließend die eigentliche Funktionalitätzur Verfügung stellen. Dies hat den Vorteil, dass eine ausgereifte Architektur für die Plugin-Entwicklung, sowie viele allgemeine Funktionen auf die zurückgegriffen werden kann, bereitsgegeben sind und die Entwicklung von Plugins sich daher fast ausschließlich auf die Logikbeschränkt.

1.3.2 Plug-in Development Environment

Zur Entwicklung neuer Plugins wird das Eclipse-Plugin Plug-in Development Environment(PDE) verwendet, welches selbst als Plugin in Eclipse integriert ist und die Entwickler bei derErstellung eines neuen Plugins unterstützt. Es hilft somit bei der Entwicklung, dem Testenund Debuggen, sowie der Erstellung und Nutzung des neuen Plugins innerhalb von Eclipse,sodass der Arbeitsfluss nicht durch weitere Anwendungen gestört wird.

1.3.3 Rich-Client-Platform

Die Rich-Client-Platform (RCP) ermöglicht es, Anwendungen basierend auf dem Eclipse Fra-mework und unabhängig von der Eclipse-Entwicklungsumgebung zu entwickeln. Solch eineRich-Client-Anwendung besteht aus dem Eclipse-Kern und eigens entwickelten Plugins.Durch die Einbindung des zu entwickelnden Eclipse-Plugins in eine RCP-Anwendung gleichtdieses einer eigenständigen Anwendung und verhält sich dementsprechend.

2

1.3.4 Eclipse Modeling Framework

Das Eclipse Modeling Framework (EMF) ist ein Eclipse-Plugin welches aus strukturiertenDaten-Modellen Java-Code generieren kann. So erzeugte Java-Programme können Instanzendes Modells abfragen, auf Änderungen überwachen, manipulieren, validieren und serialisie-ren. Die Modelle lassen sich zudem dynamisch zur Laufzeit generieren. Ein wesentlicherBestandteil von EMF ist das Ecore-Metamodell, welches Vorgaben für die Erstellung vonModellen aufstellt.Im verteilten Schiffe-Versenken-System wird das Modell des Spielmodellierers ein EMF-Modell sein, darüber hinaus wird EMF nicht eingesetzt werden.

1.3.5 Standard Widget Toolkit

Das Standard Widget Toolkit (SWT) ist eine Bibliothek und Teil von RCP zur Erstellung vongrafischen Benutzeroberflächen in Java. Sie nutzt native grafische Elemente eines Betriebssy-stems um die zu erstellende Anwendung an die Optik des Betriebssystems anzupassen.

1.3.6 Remote Method Invocation

Remote Method Invocation (RMI) bietet eine Aufrufmöglichkeit einer Methode auf einementfernten Java-Objekt an und ist somit die Java-Implementierung des Remote Procedure Call.Das „entfernte“ Objekt kann sich in einer anderen Java-Laufzeitumgebung befinden, auchwenn diese auf einem entfernten Rechner ist. Für das aufrufende Objekt sieht es in jedem Fallwie ein lokaler Methoden-Aufruf aus.Mit Hilfe von RMI wird die Kommunikation zwischen dem Server und den Clients ermöglicht.

1.3.7 Graphical Editor Framework

Das Graphical Editor Framework (GEF) ist als ein Java-Framework Teil der Eclipse RCP. MitHilfe von GEF können umfangreiche grafische Editoren schnell und einfach erstellt werden,eine gewisse Einarbeitungszeit vorausgesetzt, da GEF dem Entwickler eine feste Struktur vor-schreibt und weitere komplexe Funktionalität bereitstellt.Vom Einsatz von GEF wird auf Grund der benötigten Einarbeitungszeit und der geringen Nut-zung der komplexen Funktionalität abgesehen.

2 Analyse - Komponenten des Servers

2.1 Klassendiagramm

Das Klassendiagramm in Abbildung 1 wird im Folgenden beschrieben.

3


«control»ServerMainControl

«entity»TournamentManager

«entity»GameModel

«entity»ServerClientManager

«boundary»ServerTournamentView

«boundary»ServerCreateGameView

«control»ServerCreateGameControl

«control»ServerTournamentControl

«control»ServerInterfaceControl

«entity»ServerClient

«entity»ServerPlayerClient

«entity»ServerViewerClient

«control»ServerBidderControl

«boundary»ServerToBidderConnectionManager

«boundary»ServerToBidderConnection

«entity»ServerBidderClient

«boundary»ServerGameView

«control»ServerGame

«entity»GameModel

«utility»RuleChecker

«control»ServerToClientConnectionManager

«boundary»ServerToClientConnection

«boundary»ServerToPlayerConnection

«boundary»ServerToViewerConnection

Bieter

Verbindung zu Clients

Komponenten für jedes Spiel

Server-Hauptinterface

«interface»IServer

<<implements>>

«interface»ServerClientIdentifier

<<implements>>

Abbildung 1: Klassendiagramm Server

4

2.2 Komponenten zur Spielverwaltung


2.2.1 ServerInterfaceControl

Die ServerInterfaceControl steuert das User-Interface des Servers, das nicht zu einem Spielgehört. Dies umfasst – je nach konkreter Ausprägung dieser abstrakten Klasse – die Erstellungeines einzelnen Spiels oder die Erstellung und Verwaltung eines Turniers.Die ServerInterfaceControl stellt also die Funktionalität zur Verfügung, die in beiden Fällenbenötigt wird. Dazu zählt das Einlesen einer Spielkonfiguration des Spielmodellierers unddas Erzeugen eines GameModels aus angegebenen Daten. Zusätzlich wird das Laden einesgespeicherten Spiels aus einer Datei ermöglicht, wobei auch hier wieder ein GameModel kon-struiert und an die ServerMainControl gegeben wird.

Das Ziel ist es, fertig konstruierte, vom Benutzer spezifizierte, GameModels an die Server-MainControl weiterzureichen.

2.2.2 ServerTournamentControl

Die ServerTournamentControl ist ein spezielles ServerInterfaceControl und erweitert diese,um die Eingaben des Benutzers auf der ServerTournamentView verwalten zu können. DerBenutzer konfiguriert Turniere über die ServerTournamentView. Die eigentliche Interpretationdieser Eingaben findet in der ServerTournamentControl statt.

2.2.3 ServerTournamentView

Die ServerTournamentView stellt die grafische Oberfläche zum Konfigurieren von Turnierendar. Hier kann der Benutzer auswählen, in welcher Reihenfolge welche Spiele mit welchenSpielkonfigurationen und welchen Spielern stattfinden. Es wird außerdem der Punktestand derverbundenen Spieler angezeigt. Die dafür nötigen Informationen bezieht die ServerTourna-mentView aus dem TournamentManager und dem ServerClientManager, die außerdem beidebei Aktualisierungen die ServerTournamentView benachrichtigen (Observer-Pattern).

2.2.4 ServerCreateGameControl

Die ServerTournamentControl ist eine spezielle ServerInterfaceControl und erweitert diese,um die Eingaben des Benutzers auf der ServerCreateGameView verwalten zu können. DerBenutzer konfiguriert einzelne Spiele über die ServerCreateGameView. Die eigentliche In-terpretation dieser Eingaben findet in der ServerCreateGameControl statt. Im Gegensatz zurServerTournamentControl wird zu jedem Zeitpunkt nur ein einzelnes zu spielendes Spiel imTournamentManager verwaltet.

2.2.5 ServerCreateGameView

Die ServerCreateGameView stellt die grafische Oberfläche zum Konfigurieren von einzelnenSpielen dar. Benutzer wählen hier die Spielkonfiguration und Spieler eines einzelnen Spiels

5


aus. Im Gegensatz zur ServerTournamentView werden hier keine Punktestände von Spielernangezeigt und keine Liste von konfigurierten Spielen. Die verbundenen Clients werden al-lerdings zwecks Zuordnung zum aktuell konfigurierten Spiel angezeigt. Diese Daten werdenvom ServerClientManager zur Verfügung gestellt.

2.2.6 ServerMainControl

Die ServerMainControl ist die „Hauptklasse“ des Servers und ist somit für die zentrale Ko-ordination aller Aktivitäten auf dem Server verantwortlich. Sie nimmt aber im Allgemeinennicht direkt an einer Aktivität teil, sondern delegiert Aufgaben, Benachrichtigungen und Be-kanntschaften an die entsprechenden Spezialklassen. Zusätzlich sorgt die ServerMainControlfür die Erzeugung aller für den Server benötigten Instanzen von Komponenten entweder beiProgrammstart oder bei entsprechendem Bedarf.Sie verwaltet direkt den TournamentManager und koordiniert den Ablauf eines Turniers, wo-bei ein einzelnes Spiel ebenfalls intern als Turnier realisiert wird.Beispiel: Endet ein Spiel während eines Turniers, so ist es die Aufgabe der ServerMainCon-trol – nachdem der Benutzer die Aufforderung dazu gegeben hat – das nächste Spiel in derTurnierfolge zu starten. Dies geschieht, indem sie eine neue Instanz des ServerGames mitden entsprechenden Informationen des TournamentManagers erstellt. Ab dort übernimmt diesoeben erzeugte Instanz des ServerGames die Aktivität.Die ServerMainControl nimmt vom Benutzer erstellte Spiele von der ServerInterfaceControlentgegen und reiht sie im TournamenManager ein. Außerdem wird nach einem Spiel durch dieServerMainControl eine Methode auf der ServerBidderControl aufgerufen, die die BidderAc-counts entsprechend des Ausgangs des Spiels aktualisiert und die Bieter darüber informiert.

2.2.7 TournamentManager

Der TournamentManager ist für die Verwaltung der Spiele innerhalb eines Turniers verant-wortlich. Darunter fallen sowohl die noch zu spielenden Spiele, als auch die bereits abge-arbeiteten Spiele, um eine Historie bereitzustellen. Die Spiele werden hierbei in Form vonGameModels verwaltet. Bei offenen Spielen sind diese initial, d.h. sie enthalten noch keineInformationen über vorgenommene Züge innerhalb des jeweiligen Spiels. Fragt die Server-MainControl nach dem nächsten Spiel in der Turnierreihenfolge, so wird das initiale Game-Model des nächsten zu spielenden Spiels zurückgegeben.

2.3 Komponenten für die Spieldurchführung

Die in diesem Abschnitt aufgeführten Komponenten werden jeweils für ein Spiel – gegebenen-falls aus einer Reihe von Turnierspielen – konstruiert und werden nach diesem Spiel nutzlos.

6

2.4 Verwaltung der Client-Daten

2.3.1 ServerGameView

Die ServerGameView ist die grafische Oberfläche des Servers während der Durchführung ei-nes Spiels. Sie reagiert auf Benutzereingaben, beispielsweise die Aufforderung das Spiel zupausieren oder vorzeitig abzubrechen, indem sie entsprechende Events an das ServerGameweiterleitet. Angezeigt werden von der ServerGameView Informationen über das laufendeSpiel aus dem GameModel, sowie über die verbundenen Bieter und ihre Wetten vom Server-ClientManager. Dabei wird die ServerGameView jeweils von diesen Komponenten – demObserver-Pattern entsprechend – über Änderungen informiert.

2.3.2 ServerGame

Die ServerGame-Klasse kapselt alle Funktionalität, die notwendig ist, um ein Spiel durchzu-führen. Ein ServerGame-Objekt wird von der ServerMainControl generiert, wenn ein Spieldurchgeführt werden soll. Hierzu wird ein entsprechendes GameModel übergeben. Das Ser-verGame erzeugt eine ServerGameView und tätigt über den ServerToClientConnectionMana-ger die im Spielverlauf notwendigen Aufrufe an die Clients. Diese beinhalten unter anderemdie Anforderung der Schiffaufstellungen, sowie das Anfragen von Angriffen. Dabei wird jedeAktion mit Hilfe des RuleCheckers überprüft, alle gültigen Aktionen in das GameModel re-flektiert, um die aktuelle Spielsituation abzubilden, und die teilnehmenden Clients über dieÄnderungen benachrichtigt.


Für jeden verbundenen Client (Spieler, Beobachter oder Bieter) gilt es Daten zu speichern.Dies wird durch die folgenden Klassen realisiert. Dabei soll es sich nur um die Datenhaltunghandeln, die so weit wie möglich von der dazugehörigen Verbindung entkoppelt sein soll –insbesondere bleibt ein ServerClient auch bei Verlust der Verbindung bestehen.

2.4.1 ServerClientManager

Der ServerClientManager verwaltet die Menge der ServerClients. Dabei stellt er Methodenzur Verfügung, um einen solchen Client zu erstellen und Methoden, die den Zugriff auf dieServerClient-Objekte erlauben – beispielsweise gefiltert nach noch verbundenen Clients fürdie Anzeige auf der ServerTournamentView oder ServerCreateGameView.

2.4.2 ServerClient

Die Grundklasse der verschiedenartigen Clients ist die abstrakte ServerClient-Klasse. Refe-renzen auf diese Objekte werden in anderen Klassen datenwertig genutzt (z.B. listenartig imGameModel, als Liste der Teilnehmer des Spiels). Ein anderes Beispiel der Nutzung ist dieIdentifikation der Teilnehmer im ServerToClientConnectionManager, wofür der ServerClient

7


das Interface ServerClientIdentifier implementiert. Dadurch wird von dem konkreten Daten-objekt ServerClient abstrahiert und die Änderbarkeit gewährleistet.

2.4.3 ServerPlayerClient

Speichert Turnierpunkte, Name, Spielerart (KI/menschlich) und ähnliche Daten, die zu einemSpielerclient gehören.

2.4.4 ServerViewerClient

Speichert den Namen des Beobachters. Wird hauptsächlich zur Zuweisung an ein zu beob-achtendes Spiel genutzt.

2.4.5 ServerBidderClient

Siehe Bieter-Komponenten (7.7.1)

2.5 Verbindung zu den Clients

Diese Komponente hat die Aufgabe, das Netzwerk-Kommunikationsprotokoll RMI und somitdie Verbindung zu allen Clients zu kapseln. Ausgenommen ist hier der Bieter-Client, wel-cher nicht über RMI kommuniziert. Verbindungen mit den Clients werden hier verwaltet undAnfragen bzw. Antworten an entsprechende Stellen weitergereicht.

2.5.1 ServerToClientConnectionManager

Diese Klasse verwaltet die Verbindungen zu Clients, indem sie neue Verbindungen entgegen-nimmt oder alte Verbindungen trennt. Dazu implementiert sie das Interface IServer, sodassden Clients z.B. die Methode addPlayer(...) zum Registrieren am Server zur Verfügung steht.Hat sich ein Client am Server registriert, wird für ihn eine Verbindung erstellt, welche durchein Objekt der Klasse ServerToClientConnection repräsentiert wird.

Das Starten der RMI-Registry, sowie die Registrierung des IServer-Services geschieht eben-falls durch diese Klasse.Der ServerToClientConnectionManager nimmt aber auch Nachrichten an spezielle Clients an,d.h. wenn z.B. eine Instanz des ServerGames eine Nachricht an einen Spieler senden möchte,dann wird diese Nachricht zuerst an den ServerToClientConnectionManager gesendet. Die-ser sendet die Anfrage dann an den Spieler weiter, indem die entsprechende ServerToClient-Connection für den Spieler verwendet wird.Der ServerToClientConnectionManager benachrichtigt die ServerMainControl über neue Cli-ents und Änderungen des Verbindungsstatus. Für die Zuordnung eines ServerClients zurentsprechenden ServerToClientConnection registriert die ServerMainControl das konstruierte

8

2.6 Komponenten für den Bieter

ServerClient-Entity-Objekt beim ServerToClientConnectionManager als ServerClientIdenti-fier. Bei Kommunikationsanfragen kann dann ein ServerClientIdentifier-Objekt zur Angabedes gewünschten Rezipienten genutzt werden, aber nur der ServerToClientConnectionMana-ger kennt die Zuordnung zwischen diesen und der entsprechenden Verbindung – falls nochbestehend. Dieses Vorgehen führt zur größtmöglichen Trennung von den Entity-Strukturen,die die internen Accounts der registrierten Clients darstellen, und der Verbindungskompo-nente, die einzig die Verbindungen verwalten soll.Weiterhin soll der ServerToClientConnectionManager Daten aus internen Strukturen anneh-men. Die Umwandlung in Klassen des vorgegebenen Kommunikationsinterfaces übernimmtdie ServerToClientConnection

2.5.2 ServerToClientConnection und Unterklassen

Die ServerToClientConnection ist für die Weiterleitung der Anfragen des Servers an die Cli-ents zuständig. Für jeden verbundenen Client besteht ein Objekt dieser Klasse. Nur der Server-ToClientConnectionManager kennt diese Objekte, sie werden zur konkreten Kommunikationgenutzt. Von der abstrakten Klasse ServerToClientConnection gibt es zwei Ausprägungen.Die ServerToPlayerConnection für Verbindungen zu Spielerclients und die ServerToViewer-Connection für Verbindungen zu Beobachterclients.Eine wichtige Aufgabe der ServerToClientConnection ist dabei die Entkopplung vom Kom-munikationsinterface, sodass Anfragen an Clients den aufrufenden Thread nicht für die Dauerder Kommunikation blockieren.



Der ServerBidderClient speichert Account-Daten von angemeldeten Bieter-Clients. Deshalbbesteht für jeden angemeldeten Bieter ein Objekt dieser Klasse, in dem der aktuelle Konto-stand, sowie ein eventuell abgegebenes Gebot zum aktuellen Spiel gespeichert sind.Die Verwaltung dieser Objekte erfolgt durch den ServerClientManager

2.6.2 ServerBidderControl

Die ServerBidderControl übernimmt die Steuerung der Bietervorgänge auf Serverseite. Siesorgt zudem dafür, dass alle Bieter über den Ausgang eines Spiels, sowie den aktuellen Kon-tostand informiert werden. Außerdem ist sie für die Erzeugung neuer Accounts zuständig,sobald sich ein neuer Bieter verbindet.

2.6.3 ServerToBidderConnectionManager

Der ServerToBidderConnectionManager stellt aus Sicht der ServerBidderControl die Schnitt-stelle zu den Bietern dar. Die Klasse nimmt neue Bieterverbindungen entgegen und erstellt

9

3 Analyse - Komponenten der Clients

dafür jeweils eine entsprechende ServerToBidderConnection.Analog zum ServerToClientConnectionManager benachrichtigt sie die ServerBidderControlüber neue Clients und Änderungen des Verbindungsstatus. Außerdem kann die ServerBidder-Control einen ServerBidderClient mit der entsprechenden Verbindung verknüpfen. Nur derServerToBidderConnectionManager kennt diese Beziehung.Von der initialen Verbindung abgesehen stellt der ServerToBidderConnectionManager zwarMethoden zur Kommunikation mit der Gesamtheit der Bieter zur Verfügung, delegiert die in-dividuelle Kommunikation mit den einzelnen Bietern aber an die jeweiligen ServerToBidder-Connection-Objekte. Die Kommunikation der internen Serverkomponenten mit den Bieternsoll ausschließlich über den ServerToBidderConnectionManager funktionieren, andere Kom-ponenten sollen keine Kenntnis von der ServerToBidderConnection haben.Anfragen der Bieter werden an die ServerBidderControl weitergegeben. Es werden außerdemMethoden bereitgestellt, die das Mitteilen eines Wettergebnisses an die Clients übernehmen.

2.6.4 ServerToBidderConnection

Die ServerToBidderConnection verwaltet eine einzelne Verbindung zu einem der Bieter-Clients.Sie übernimmt die Interpretation des JSON-Kommunikationsformats und die Generierung ei-ner Antwort aus übergebenen Daten.Änderungen des Verbindungsstatus werden dem übergeordneten ServerToBidderConnection-Manager mitgeteilt. Ebenso verhält es sich mit den Wettanfragen des Bieters.Für das Mitteilen des Wettergebnisses steht eine Methode zur Verfügung.

3 Analyse - Komponenten der Clients

3.1 Klassendiagramm


3.2 Verbindungsmanagement

Die Klassen des Verbindungsmanagement übernehmen als Boundary-Klassen die grundle-gende Kommunikation mit dem Server und verbergen netzwerkspezifische Details wie zumBespiel RMI oder die von der Projektleitung vorgegebenen Kommunikationsinterfaces.

3.2.1 ClientToServerConnection

Die ClientToServerConnection implementiert das Interface IClient, welches die entsprechen-den Methoden zur Kommunikation mit dem Server vorschreibt.Bei Anfragen vom Server, also zum Beispiel einer Änderung des Spielzustands, benachrichtigtsie den GameClientController. Außerdem nimmt sie zum Server zu sendende Daten entgegenund stellt die Methoden zum Herstellen und Beenden einer Verbindung mit dem Server bereit.

10

3.3 Clientsteuerung

«utility»RuleChecker

«boundary»ClientToServerConnection

«boundary»PlayerClientConnection

«boundary»ViewerClientConnection

«interface»IClient

«interface»IPlayerClient

«interface»IViewerClient

«control»GameClientControl

«entity»GameModel

«entity»PlayerIdentity

«control»AIPlayer

«control»PlayerGuiControl

«control»ViewerGuiControl

«boundary»GameView

<<implements>>

<<implements>> <<implements>>

Spieler/Beobachter-Client

Verbindungsmanagement

Computergegner

Abbildung 2: Klassendiagramm Clients

Die Klasse ClientToServerConnection ist abstrakt und es wird je nach Client eine der erbendenKlassen PlayerClientConnnection oder ViewerClientConnection realisiert.

3.2.2 PlayerClientConnection

Die PlayerClientConnection erbt von ClientToServerConnection und stellt zusätzlich zur grund-legenden Kommunikation spezielle Methoden für den Spieler-Client zu Verfügung, wie zumBeispiel makeAttack(...) oder arrangeShips(...). Sie implementiert das Interface IPlayerCli-ent.

3.2.3 ViewerClientConnection

Auch die ViewerClientConnection erbt von ClientToServerConnection und stellt zusätzlicheMethoden für den Beobachter-Client zur Verfügung, wie zum Beispiel arrangementFinis-hed(...). Sie implementiert das Interface IViewerClient.

3.3 Clientsteuerung

3.3.1 GameClientController

Der GameClientController beinhaltet die Schiffe-Versenken-Logik. Er nimmt Anweisungendes Servers entgegen und aktualisiert das GameModel entsprechend. Weiterhin leitet er dieAktionen des Spielers/der KI an den Server weiter, nachdem sie den RuleChecker durchlaufenhaben.

3.3.2 PlayerIdentity

Die PlayerIdentity hält einfache Informationen zum Spieler-Client wie zum Beispiel den Na-men oder die Information, ob es sich um einen menschlichen Gegner oder eine künstliche

11

4 Analyse - gemeinsam genutzte Komponenten

Intelligenz handelt.

3.4 Clientoberfläche

3.4.1 ViewerGuiController

Die Klasse ViewerGuiController beinhaltet die Reaktion auf Interaktionen, die vom Beob-achter oder Spieler ausgeführt wurden. In dieser Klasse wird nur auf Ereignisse reagiert, diebeobachtendes Verhalten wiederspiegeln. Dazu gehört beispielsweise das Spiel zu verlassen.Die interpretierten Aktionen werden an die Klasse GameClientController weitergereicht.

3.4.2 PlayerGuiController

Die Klasse PlayerGuiController erbt von ViewerGuiController und erweitert diese um Funk-tionalitäten, auf die ein Spieler zurückgreifen muss. Hier wird festgelegt, wie auf bestimmteInteraktionen von Spielern reagiert wird. Damit sind in erster Linie die Interaktionen gemeint,die nur ein Spieler und kein Beobachter ausführen kann. Die interpretierten Aktionen werdenan die Klasse GameClientController weitergereicht.

3.4.3 GameView

Die Klasse GameView beinhaltet die grafische Oberfläche des Beobachters oder Spielers. Sowird hier das Spielfeld gezeichnet und sämtliche Informationen dargestellt. Dazu gehörenunter anderem die Möglichkeit das Log anzuschauen, das eigene und das gegnerische Spiel-feld zu betrachten und Angriffe durchzuführen. Die dafür benötigten Informationen werdendirekt aus dem GameModel geholt. Bei Änderungen des GameModels wird die GameViewbenachrichtigt. Daraufhin wird die Oberfläche neu gezeichnet.

3.5 Computergegner

3.5.1 AIPlayer

Die Klasse AIPlayer beinhaltet die gesamte Logik für den Computerspieler, d.h. das Aufstel-len von Schiffen und ggf. Minen und das Durchführen von Angriffen. Zur Berechnung einesSpielzuges kann der AIPlayer auf die Informationen im GameModel des Clients zugreifen.

4 Analyse - gemeinsam genutzte Komponenten

4.1 LobbyView

Die LobbyView wird sowohl von Seiten des Servers, als von Seiten der Clients verwendet.Doch obwohl sie die erste Ansicht für alle Benutzer – ausgenommen der Bieter – nach Pro-grammstart des Schiffe-Versenken-Systems ist, besitzt sie nur wenige einfache GUI-Elemente

12

4.2 RuleChecker

und keine wesentliche dazugehörige Logik. Daher wird auf die weitere Modellierung im Ent-wurf verzichtet.

4.2 RuleChecker

Der RuleChecker prüft jede Aktion auf Korrektheit bezüglich der aktuellen Spielregeln. Die-ses Vorgehen sorgt dafür, dass die Clients keine fehlerhaften Aktionen an den Server senden.Weiterhin wird der RuleChecker beim Server eingesetzt, um die vom Client gesendeten Ak-tionen zu prüfen.

4.3 GameModel

Das GameModel ist für die Datenhaltung eines jeden Spiels da. Mithilfe dieser Klasse lässtsich der gesamte Spielverlauf samt Konfiguration, Spielern, ihren Aktionen und dem jewei-ligen Zustand des Spieles modellieren. Auf Grundlage des GameModels werden auch dieBenutzeroberflächen aktualisiert. Das GameModel wird sowohl beim Client als auch beimServer eingesetzt.

4.4 CommonInterfaceConverter

Der CommonInterfaceConverter ist eine Utility-Klasse (das bedeutet, dass sie aus einer Samm-lung von statischen Methoden besteht), die die Konvertierung zwischen den von der Projekt-leitung vorgegebenen Klassen und Interfaces zur Kommunikation und den intern verwendetenKlassen bewerkstelligt.Sie ist Teil der Boundary-Schicht, muss aber auch die Schiffe-Versenken-Logik kennen, umbeispielsweise beim serverseitigen Laden eines Spiels aus dem GameModel für jeden Teil-nehmer bestimmen zu können, welcher Teil der Informationen diesem zukommen darf.

5 Analyse - Komponenten des Bieters

5.1 Klassendiagramm


5.2 Persistente Klassen und Verbindung

5.2.1 BidderService

Der BidderService ist ein Android Service. Das bedeutet, dass dieser beim Beenden einerActivity erhalten bleibt und nebenläufig im Hintergrund laufen kann. Dies erlaubt es derBieterapplikation, eine Verbindung zum Server aufrecht zu erhalten, selbst wenn der Benut-zer die Activity beendet. Der Großteil der Logik wird in diesem Service realisiert, sodass

13

5 Analyse - Komponenten des Bieters

«boundary»BidderToServerConnection

«entity»BidderAccount

«control»BidderService

«control»BidderConnectionActivity

«control»BidderMainActivity

«control»BidderBetActivity

Abbildung 3: Klassendiagramm Bidder

die Benutzer des Services – nämlich die anzeigenden Activities – als Clients in einer Client-Server-Beziehung auf dessen Methoden zurückgreifen können.Dementsprechend soll der BidderService die Verbindung in Form eines BidderToServerConnec-tion-Objekts verwalten und aufrechterhalten. Der Service stellt Funktionen zur Verfügung umeine Verbindung herzustellen und Gebote zum Server zu leiten (diese Vorgänge werden andie BidderToServerConnection delegiert). Wird ein Wettergebnis empfangen, benachrichtigtder Service entweder die BidderBetActivity, falls diese gerade aktiv ist, oder generiert eineAndroid-Notification, um den Benutzer darüber zu unterrichten.Außerdem speichert der Service die Wettergebnisse, sodass diese zu jedem Zeitpunkt von ei-ner BidderBetActivity abgerufen und angezeigt werden können.Der Service beendet sich selber, sobald die Verbindung getrennt wird.

5.2.2 BidderToServerConnection

Die konkrete Verbindungslogik wird von der BidderToServerConnection implementiert. Dasbeinhaltet insbesondere die Interpretation und Generierung des JSON-Kommunikationsformats.Empfangene Kommunikation oder Änderungen des Verbindungsstatus werden an den Bidder-Service weitergereicht. Ausgehende Kommunikation geht alleine vom BidderService aus, dieBidderToServerConnection ist nur ausführende Instanz.

5.2.3 BidderAccount

Hält sämtliche bekannten Daten des Bieters. Darunter der Kontostand und abgeschlosseneWetten, sowie deren Ergebnisse. Die BidderBetActivity kann allein aus einem solchen Objektalle Informationen beziehen, die anzuzeigen sind.

14

5.3 Activities

5.3 Activities

Im Android-Framework ist eine Activity die Hauptkomponente eines Programms. Im Allge-meinen wird für jedes für den Benutzer sichtbare Interface eine Activity erstellt, so auch hier.Eine Activity ist im MVC-Modell sowohl Control-, als auch Viewklasse. Die Struktur desViews, also der sichtbaren Oberfläche, wird zwar größtenteils in einem XML-Format unab-hängig von der Activityklasse definiert, aber im laufenden Programm startet und verwaltet dieActivity dieses Interface und steuert sämtliches Verhalten.

5.3.1 BidderConnectionActivity

Der erste sichtbare Bildschirm fordert den Benutzer zur Eingabe der Server-IP-Adresse auf.Die BidderConnectionActivity ist diejenige Activity, die diesen Vorgang steuert und die ent-sprechende Oberfläche generiert.Dafür startet die BidderConnectionActivity den BidderService und delegiert den Verbindungs-aufbau an diesen. Dem User werden gegebenenfalls Informationen über den Misserfolg ange-zeigt. Im Erfolgsfall wird die BidderBetActivity gestartet.

5.3.2 BidderBetActivity

Die BidderBetActivity ermöglicht es dem Benutzer, Gebote abzugeben. Bekannte Daten undWettergebnisse, die vom laufenden BidderService bereitgestellt werden, werden hier ange-zeigt.

5.3.3 BidderMainActivity

Die BidderMainActivity ist der Einstiegspunkt für die Android-Applikation. Sie prüft beimAufruf, ob aktuell eine Verbindung besteht und startet entsprechend die BidderConnectionAc-tivity bzw. die BidderBetActivity.

6 Allgemeines zum Entwurf

Im Abschnitt Entwurf soll die Struktur der im Analyseabschnitt definierten Komponentenweiter detailliert, sowie wesentliche Abläufe innerhalb dieser Komponenten weiter verfeinertwerden.

6.1 Struktur der Komponenten weiter detaillieren

Um die Struktur der Komponenten zu detaillieren wird ihre innere Struktur verfeinert, indemihre wichtigsten Klassen und deren relevante Attribute, Methoden und Assoziationen spezifi-ziert werden. Die Darstellung erfolgt durch Klassendiagramme.

15

7 Entwurf - Komponenten des Servers

Zu diesen Diagrammen: Methoden von Interfaces werden aufgeführt, wenn deren Anwesen-heit betont werden soll, sind aber auf jeden Fall Teil der implementierenden Klasse.Klassen und Interfaces aus dem von der Projektleitung vorgegebenen Interface werden mitdem „Common.“-Präfix bezeichnet, alle anderen Bezeichner stehen für intern verwendeteKlassen und Interfaces.

6.2 Abläufe innerhalb der Komponenten weiter verfeinern

Zu jeder entworfenen Klasse wird das Verhalten textuell näher beschrieben, indem zum Bei-spiel auf das Verhalten einzelner Methoden eingegangen wird oder ein allgemeiner Überblicküber die typische Nutzung gegeben wird. Dabei werden ausdrücklich nicht sämtliche Sach-verhalte des Klassendiagramms, in dem bereits ausreichend detailliert die Struktur der Klassebeschrieben wird, wiederholt. Der Text dient stattdessen dazu, ergänzend nichttriviale Zusam-menhänge zu verdeutlichen.Zusätzlich werden die wesentlichen Abläufe der Komponenten dargestellt, indem Sequenzdia-gramme unter Berücksichtigung der zuvor definierten inneren Struktur erstellt werden. Da-bei wird sowohl inneres, als auch äußeres Verhalten zwischen den Komponenten beispielhaftdeutlich gemacht.


7.1 Sequenzdiagramm: Turnier einrichten/Spiel starten

Im Sequenzdiagramm „Turnier einrichten/Spiel starten“ in Abbildung 4 wird beschrieben,wie die Interaktionen zwischen internen Klassen stattfinden, wenn der Spielleiter sich in derTurnier-einrichten-Ansicht befindet und einem Turnier ein oder mehrere neue Spiele hinzu-fügen möchte. Dazu klickt er pro Spiel auf „Neues Spiel erstellen“. Die durch die MethodeBtCreateGameClick() benachrichtigte ServerTournamentContol erzeugt ein neues GameMo-del-Objekt mit Standardkonfiguration und gibt es per pushNewUpcomingGame(...) an denServerTournamentManager zum Einreihen in die Warteschlange der upcomingGames weiter.Da die ServerTournamentControl das soeben erzeugte GameModel kennt, könnte die (bis-her Standard-)Spielkonfiguration durch direkte Manipulation am Objekt geändert werden (istnicht in diesem Sequenzdiagramm abgebildet).Anschließend wird das in der GUI markierte Spiel über den Button „Spiel starten“ gestartet.Die ServerTournamentView leitet den Befehl über BtStartGameClick() an die ServerTourna-mentControl weiter, welche über startNextGame() der ServerMainControl mitteilt, dass dasnächste Spiel gestartet werden soll. Die ServerMainControl holt sich daraufhin das aktive Ga-meModel-Objekt um ein neues ServerGame-Objekt zu erstellen. Somit ist das Spiel fertig umgestartet zu werden, also kann die ServerBidderControl per gameStarted(...) hierüber benach-richtigt werden, sodass sie das Annehmen von neuen Bieter-Verbindungen vermeiden kann.Wenn dies geschehen ist, wir das Spiel per startGame() endgültig gestartet.

16

7.2 Sequenzdiagramm: Spiel beenden

setGameState(STARTED)

announceGameStarted(players, game)

Spielleiter

«control» : ServerTournamentControl

«entity»game : GameModel

Klick: Spiel einrichten

sd: Turnier einrichten/Spiel starten

Klick: Spiel starten

«boundary» : ServerTournamentView

«control» : ServerMainControl

BtStartGameClick()

startNextGame()

«control» : ServerGame

«entity» : TournamentManager

pushNewUpcomingGame(game)

new GameModel()BtCreateGameClick()

new ServerGame(game)

startGame()

announceOpponents(playerIDs:List<..>, p:ServerPlayerClient)

setPlayer(playerID,p:ServerPlayerClient, seconds)

nextTurn()

«boundary» : ServerToClientConnectionManager

Für alle einzeln

Für alle einmal, aber immer gleich

«control» : ServerBidderControl

gameStarted(game)

popNextUpcomingToCurrent()

getCurrentGame()

game:GameModel

Müsste vorher validiert werden (sind genügend

Spieler eingetragen, ist es möglich, alle Schiffe zu

platzieren, …)

Abbildung 4: Turnier einrichten/Spiel starten

Zu Anfang des ServerGames wird für jeden Spieler einzeln über setPlayer(...) eine playerIDzugewiesen und allen Spielern über announceOpponents(...) die Gegner mitgeteilt. Der Zu-stand des GameModel-Objekts wird vom ServerGame nun zu STARTED gewechselt, sodassnun die reguläre Rundenabarbeitung mittels nextTurn() beginnen kann. Diese Funktion starteteine (asynchrone) Anfrage an einen Spieler, sodass die Aktivität nach dem Absetzen der An-frage wieder bei der ServerMainControl liegt.Analog dazu kann ein einzelnes Spiel eingerichtet und gestartet werden, welches dann vonServerCreateGameView/-Control, statt ServerTournamentView/-Control verwaltet wird.

7.2 Sequenzdiagramm: Spiel beenden

Das Sequenzdiagramm „Spiel beenden“ in Abbildung 5 zeigt die Vorgänge, die stattfinden,wenn der Server einen Angriff anfordert und das Spiel zu Ende geht.Das ServerGame erzeugt zuerst ein ServerGameResultCallback-Objekt, welches über die Me-

17


«en

tity

»ga

me

: Gam

eMo

del

sd:

Spie

l bee

nd

en

«b

ou

nd

ary»

: Se

rver

Gam

eVie

w«

uti

lity»

: R

ule

Ch

ecke

r«

con

tro

l» :

Serv

erG

ame

req

ues

tAtt

ack(

pla

yer,

sgr

cb)

«b

ou

nd

ary»

: Se

rver

ToP

laye

rCo

nn

ecti

on

atta

ckFi

nis

hed

Cal

lbac

k(a_

2:A

ttac

k)

chec

kAtt

ack(

a_2

,gam

e)

pu

shA

ttac

k(a_

2)

retu

rn t

rue

setG

ameS

tate

(FIN

ISH

ED)

«co

ntr

ol»

: Se

rver

Mai

nC

on

tro

l

ann

ou

nce

Win

ner

(clie

nts

)

gam

eEn

ded

(win

ner

)

per

form

Att

ack(

a_2

)

«co

ntr

ol»

: Se

rver

Bid

der

Co

ntr

ol

«b

ou

nd

ary»

: Se

rver

ToB

idd

erC

on

nec

tio

nM

anag

er

ann

ou

nce

Res

ult

s(b

idd

ers:

Set<

..>)

«co

ntr

ol»

: Se

rver

ToC

lien

tCo

nn

ecti

on

Man

ager

req

ues

tAtt

ack(

sgrc

b)

«co

ntr

ol»

sgrc

b :

Serv

erG

ameR

esu

ltC

allb

ack

new

Ser

verG

ameR

esu

ltC

allb

ack(

)

a:IA

ttac

k

no

tify

Gam

eMo

del

Ch

ange

()

nex

tTu

rn()

no

tify

Gam

eMo

del

Ch

ange

()

gam

eEn

ded

(gam

e)

setW

inn

er(p

laye

r)

calc

ula

teA

cco

un

ts()

«en

tity

» :

Tou

rnam

entM

anag

er

pu

shC

urr

entT

oR

ecen

t()

mak

eAtt

ack(

)

ann

ou

nce

Att

ackP

erfo

rmed

(pla

yers

, a_2

)

ann

ou

nce

Att

ackP

erfo

rmed

(a_2

)

com

mo

n.A

ttac

kPer

form

ed(a

,res

ult

)

ann

ou

nce

Win

ner

(pla

yeri

d)

ann

ou

nce

Win

ner

(pla

yeri

d)

Abbildung 5: Spiel beenden

18


thode requestAttack(...) inklusive einem player-Parameter an den ServerToClientConnection-Manager übergibt. Dieser schickt die Aufforderung makeAttack() über die passende Server-ToPlayerConnection an den jeweiligen Spieler. Anschließend kommt ein Angriff a des Typscommon.IAttack über die ServerToPlayerConnection zurück. In der ServerToPlayerConnec-tion erfolgt eine Umwandlung des Angriffs zum Typ Attack und wird über das ServerGame-ResultCallback-Objekt an das ServerGame gereicht. Von dort aus, wird der Angriff mit demRuleChecker geprüft, auf dem GameModel ausgeführt und die restlichen Spieler per attack-Performed(...) über den Angriff informiert.Im nextTurn() ermittelt das ServerGame, dass das Spiel zu Ende ist und setzt den GameStateim GameModel auf FINISHED und trägt den Gewinner ein. Dieser wird den anderen Clientsüber den ServerToClientManager mitgeteilt. Das ServerGame meldet der ServerMainCon-trol das Spielende und übergibt dieser das GameModel, welcher der ServerBidderControl denGewinner mitteilt und anschließend die neuen Kontostände berechnet und über announceRe-sults(...) an den ServerToBidderConnectionManager schickt, die es an die jeweiligen Bieterweiterleitet. Zum Schluß wird das GameModel-Objekt von der ServerMainControl, als re-centgGame, in die Historie des TournamentManagers abgelegt.



+ ServerInterfaceControl

+navigateToLobby()+startGame()+addClientToGame(client:ServerClient)+loadGame()+loadConfiguration()+createConfiguration()+removeClientFromGame(client:ServerClient)

+ ServerTournamentControl

+ServerTournamentControl(mainControl:ServerMainControl,tm:TournamentManager)+notifyGameModelChange()

+ ServerCreateGameControl

+ServerCreateGameControl(mainControl:ServerMainControl,tm:TournamentManager)+notifyClientChange()

+ ServerMainControl + TournamentManager

+ ServerCreateGameView+ ServerTournamentView

Abbildung 6: ServerMainInterface

7.3.1 ServerInterfaceControl

Die ServerInterfaceControl ist die abstrakte Oberklasse von ServerTournamentControl undServerCreateGameControl. Sie bietet Methoden die beide Unterklassen benötigen, wie Na-vigateToLobby(...), was die GUI zur Lobby navigiert, oder startGame(...), was das gewählteSpiel startet, indem es die ServerMainControl entsprechend benachrichtigt. Zudem behandelt

19


sie die Events der entsprechenden Views mit Methoden wie loadConfiguration(...), die im ak-tuellen GameModel die entsprechende Konfiguration einträgt, nachdem diese vom Benutzererfragt wurde. Ähnlich gehen die Methoden für das Behandeln von Clients und Spielen vor.

7.3.2 ServerTournamentControl

Die ServerTournamentControl erbt von der ServerInterfaceControl und ist zuständig für dieKommunikation zwischen ServerTournamentView und ServerMainControl.

7.3.3 ServerCreateGameControl

Die ServerCreateGameControl erbt ebenfalls von der ServerInterfaceControl und ist zustän-dig für die Kommunikation zwischen ServerCreateGameView und ServerMainControl.

7.3.4 ServerTournamentView

+ ServerTournamentView

-TBLog:TextBox

-LBObserver:ListBox

-JTRanks:JTable

-CBTimePerPlayerTurn:Combo

-CBTimePerAITurn:Combo

-CBAllowedMistakes:Combo

+ServerTournamentView(controller:ServerTournamentControl,tm:TournamentManager,scm:ServerClientManager)

-redraw()

-BtStartGameClick()

+ ServerTournamentControl+ TournamentManager + ServerClientManager

Abbildung 7: ServerTournamentView

Die ServerTournamentView stellt die GUI für die Erstellung eines Turniers dar. Sie zeigtdie bereits erstellten Spiele listenartig an und ermöglicht deren Bearbeitung. Die redraw(...)Methode sorgt dafür, dass alle Oberflächenelemente mit den entsprechenden Daten aus demTournamentManager belegt werden.

7.3.5 ServerCreateGameView

Die ServerCreateGameView stellt die GUI für die Erstellung eines einzelnen Spiels dar. Siezeigt die gewählten Einstellungen aus dem GameModel an und ermöglicht die Bearbeitung.Die Click(...)-Methoden behandeln das Drücken von Buttons und leiten teilweise Events andie ServerCreateGameControl weiter, wie z.B. BtBackToLobbyClick(...), was den Benutzerzurück zur Lobby navigiert.

20


+ ServerCreateGameView




-BtBackToLobby:Button

-BtStartGame : Button

-BtLoadConfiguration : Button

-BtCreateConfiguration : Button

-BtLoadGame : Button

-BtAddClientToGame:Button

-BtRemoveClientFromGame:Button

+ServerCreateGameView(controller:ServerCreateGameControl)

+notifyGameModelChange()

-redraw()

-BtStartGameClick()

-BtLoadConfigurationClick()

-BtCreateConfigurationClick()

-BtLoadGameClick()

-BtAddClientToGameClick()

-BtRemoveClientFromGameClick()

-BtBackToLobbyClick()


Abbildung 8: ServerCreateGameView

7.3.6 ServerMainControl

Die ServerMainControl (siehe Abbildung 9) tritt an vier Punkten in Aktion. Der erste ist derProgrammstart, bei dem alle Komponenten des Servers initialisiert werden. Dabei werdenfolgende Komponenten werden von der ServerMainControl erzeugt:

• ServerBidderControl

• ServerToClientConnectionManager

• ServerClientManager

Wenn der Server initialisiert ist, endet die Aktivität der ServerMainControl. Sie wird erstwieder durch die Methode startNextGame(...) aktiviert, welche die ServerMainContol dazuveranlasst, das nächste Spiel zu initiieren. Dazu wird per TournamentManager das nächsteGameModel als current markiert und mit diesem GameModel eine Instanz des ServerGameerzeugt, welche sich dann um die weitere Ausführung des somit gestarteten Spiels kümmert.Nun verbleibt nur noch die Aufgabe, der ServerBidderControl Bescheid zu sagen, dass dasSpiel gestartet ist, und dann endet die Aktivität der ServerMainContol erneut. Zur Illustrationdieses Vorganges siehe das Sequenzdiagramm in Abbildung 4.

Der dritte Einsatz für die ServerMainContol findet statt, nachdem sie vom ServerGame pergameEnded(...) vom Spielende erfahren hat. Dann übernimmt sie das „Aufräumen“ des letz-ten ServerGame und leitet das Mitteilen der Gewinne an die Bieter ein. Hierzu siehe dasSequenzdiagramm in Abbildung 5.

Nachdem das Spiel beendet wurde, endet auch die Aktivität der ServerMainControl, selbstwenn noch ein weiteres Spiel im Turnier offen ist (upcomingGame). Dieses muss per start-NextGame() gestartet werden, außer der Automatik-Modus für das Abarbeiten eines Turniers

21


wurde per autoNextGame(...) aktiviert.

Eine weitere Aufgabe der ServerMainControl ist es, die Profile von Spielern zu verwalten.Dazu implementiert sie das Interface ServerConnectionListener, mit dem sie vom Server-ToClientConnectionManager über Änderungen des Verbindungsstatus der einzelnen Clientsinformiert wird. Dementsprechend ist es ihre Aufgabe, die Spielerkonten anzulegen bzw. zuaktualisieren (z.B. wenn eine Verbindung verloren geht).

+ ServerMainControl

<<control>>

-bidderControl : ServerBidderControl

-serverToClientConnectionManager : ServerToClientConnectionManager

-clientManager : ServerClientManager

-tournamentManager : TournamentManager

-GUI

-currentServerGame : ServerGame

-autNextGame : boolean

+startNextGame()

+gameEnded(game : GameModel)

+ServerMainControl()

+setAutNextGame(enabled : boolean)

+ ServerConnectionListener

<<implements>>

Abbildung 9: ServerMainControl

7.3.7 TournamentManager

Der TournamentManager (siehe Abbildung 10) gliedert sich intern in zwei Queues, nämlichupcomingGames zum Verwalten der Spiele, die noch nicht gespielt worden sind und recent-Games zum Nachhalten der bereits gespielten Spiele als Historie. Dabei können in upcoming-

+ TournamentManager

<<entity>>

-upcomingGames : List<GameModel>

-recentGames : List<GameModel>

-Listeners : Set<TournamentManagerListener>

-currentGame : GameModel

+pushNewUpcomingGame(game : GameModel)

+insertNewUpcomingGame(game : GameModel,position : Integer)

+dropUpcomingGame(game : GameModel)

+getNextUpcomingGame() : GameModel

+getUpcomingGamesList() : List<GameModel>

+getRecentGamesList() : List<GameModel>

+getCurrentGame()

+popNextUpcomingToCurrent()

+popCurrentToRecent()

+addListener(listener : TournamentManagerListener)

+removeListener(listener : TournamentManagerListener)

-notifyAllListeners()

+ TournamentManagerListener

<<interface>>

+notifyTournamentChanged()

Abbildung 10: TournamentManager

22


Games auch Spiele enthalten sein, welche nicht spielbar sind, weil ihnen noch keine Spielerzugewiesen wurden. Der Zustand, dass keine gültige Spielkonfiguration anliegt ist aber ausge-schlossen. Somit ist beim Aktivieren eines upcomingGames als aktuelles Spiel zu überprüfen,ob das ausgewählte Spiel spielbar ist. Dazu wird die Methode getNextUpcomingGame(...) be-reitgestellt. Diese liefert das GameModel, welches zum nächsten Spiel werden würde.Ansonsten ist der TournamentManager wie folgt definiert:

popNexUpcomingToCurrent()

popCurrentToRecent()

upcomingGames

recentGames

pushNewUpcomingGame()

currentGame

Abbildung 11: TournamentManager

Die GameModels werden aufgereiht als upcomingGames, dann einzeln aktiviert und gespieltals currentGame und landen schließlich in der Historie als recentGames. Das „Einreihen“funktioniert per pushNewUpcomingGame(...), bzw. per insertNewUpcomingGame(...), fallsan eine bestimmte Stelle in der Warteliste eingereiht werden soll Dabei bezeichnet Stelle 0 dieallervorderste Position, also diejenige, an der das nächste upcomingGame steht. Das „Weiter-schieben“ in dieser Schlange wird mit den Methoden popNextUpcomingToCurrent(...) undpopCurrentToRecent(...) ausgeführt, welche von der ServerMainControl aufgerufen werden.Außerdem bietet der TournamentManager einige Schnittstellen für die GUI. So stellt er eineMethode getUpcomingGamesList(...) bereit, damit diese von der GUI passend angezeigt wer-den kann. Außerdem erfüllt er die Rolle eines Subjekts im Observer-Pattern, sodass sich jedeKlasse als Listener eintragen kann, welche das zugehörige Interface ITournamentManagerLi-stener implementiert.


7.4.1 ServerGameView

Die ServerGameView stellt die GUI während eines laufenden Spiels dar. Im Wesentlichenzeigt sie die Informationen aus dem GameModel an. Die Click() Methoden ermöglichen überButtons das Pausieren und Beenden eines Spiels, was entsprechend an das ServerGame wei-tergeleitet wird.

23


+ ServerCreateGameView




-BtBackToLobby:Button

-BtStartGame : Button

-BtLoadConfiguration : Button

-BtCreateConfiguration : Button

-BtLoadGame : Button

-BtAddClientToGame:Button

-BtRemoveClientFromGame:Button

+ServerCreateGameView(controller:ServerCreateGameControl)


-redraw()

-BtStartGameClick()

-BtLoadConfigurationClick()

-BtCreateConfigurationClick()

-BtLoadGameClick()

-BtAddClientToGameClick()

-BtRemoveClientFromGameClick()

-BtBackToLobbyClick()


Abbildung 12: ServerCreateGameView

7.4.2 ServerGame

Das ServerGame (siehe Abbildung 13) kontrolliert die Spielausführung. Die Methode next-Turn() wird aufgerufen, wenn ein neuer Zug angestoßen werden soll. Dabei wird jeweilsgeprüft, ob sich durch einen Zug ein Spieler als Gewinner herausgestellt hat und dement-sprechend das GameModel geändert und der Vorgang des Beendens eingeleitet. Die MethodeperformAttack(...) wird, sobald ein Angriff zurückgeliefert wurde, von einem Objekt der inne-ren Klasse ConnectionResultHandler aufgerufen, welche das Interface ServerConnectionRe-sultCallback implementiert. Beim Aufruf von performAttack(...) wird nach dem Überprüfender Korrektheit des Angriffs durch den RuleChecker das GameModel aktualisiert und mithilfevon einem Aufruf von nextTurn(...) der nächste Zug angestoßen. Analog funktionieren ships-Positioned(...) und mistakeOccured(...). Die Klasse ServerGame implementiert zusätzlichdas Interface ServerConnectionListener, sodass auf einen Verbindungsabbruch zum einemder Clients reagiert werden kann.


7.5.1 ServerClientManager

Der ServerClientManager (Abbildung 14) besitzt ein Attribut idCount, welches beim Erstellenjedes neuen Clients erhöht wird, um eine eindeutige id zuweisen zu können. Zusätzlich bietetder ServerClientManager die Möglichkeit, Listen vom Typ ServerClient – nach bestimmten

24


+ ServerGame

<<control>>

+ServerGame(gameModel : GameModel,ss2ccm : ServerToClientConnectionManager)+startGame()+pauseGame()+closeGame()+resumeGame()-nextTurn()-performAttack(attack : Attack)-shipsPositioned(player : Player,ships : List<Ship>)-mistakeOccured(player : Player,mistake : Mistake)

+ GameModel

<<entity>>

+ ServerGameView

<<boundary>>

+ RuleChecker

<<utility>>

+ ServerGame.ConnectionResultHandler

<<control>>

-deadline : Date-deadlineThread : Thread

+ConnectionResultHandler(deadline : Date)+getDeadline() : Date

+ ServerConnectionResultCallback

<<interface>>

<<implements>>


<<interface>>

<<implements>>

+ ServerToClientConnectionManager

<<boundary>>

+ ServerMainControl

<<control>>

Abbildung 13: ServerGame

+wServerClientManager

-idCountw:wint

+getAllClients()w:wServerClient

+createPlayerClient(namew:wString,isHumanw:wboolean)w:wServerClient

+createViewerClient(namew:wString)w:wServerClient

+createBidderClient(ipw:wString)w:wServerClient

+deleteClient(clientw:wServerClient)

+getAllClients()w:wList<ServerClient>

+getAllConnectedClients()w:wList<ServerClient>

+getAllBidderClients()w:wList<ServerClient>

+ServerClientManager()

+wServerClient

Abbildung 14: ServerClientManager

Merkmalen gefiltert – ausgeben zu lassen.

7.5.2 ServerClient

Der ServerClient mit seinen Unterklassen stellt die Datenhaltung der Clients dar (siehe Abbil-dung 15).


7.6.1 ServerToClientConnectionManager

Wenn der ServerToClientConnectionManager konstruiert wird, wird die RMI-Registry durchinternen Aufruf von setAcceptNewConnections(true) gestartet und nimmt Verbindungen vonClients an. Beim Aufruf von setAcceptNewConnections(false) wird das Objekt aus der Regi-stry gelöscht, um zu verhindern, dass sich neue Clients registrieren können.Die Methoden des ServerToClientConnectionManagers haben im Allgemeinen keine Rückga-bewerte. Methodenaufrufe blockieren den Aufrufer nicht die gesamte Zeit der Kommunika-tion über die Netzwerkschnittstelle. Stattdessen wird bei einem Aufruf nur geringer Aufwand

25


+ ServerBidderClient

<<entity>>

-budget : int

+ServerBidderClient(ip : String)

+getBudget() : int

+addToBudget(value : int) : int

+setCurrentBet(b : Bet)

+getCurrentBet() : Bet

+ Bet

<<entity>>

-amount : int

-player : ServerClientIdentifier

-betWon : boolean

-round : int

-expectedResult : int

+Bet(p : ServerClientIdentifier,amnt : int,rnd : int,expResult : int)

+getAmount() : int

+getPlayer() : ServerClientIdentifier

+getBetWon() : boolean

+setBetWon(b : boolean)

+getRound() : int

+getExpectedResult() : int

currentBet

+ ServerClient

<<abstract>>

<<entity>>

-connected : boolean

-clientAddress : String

+ServerClient(address : String)

+setDisconnected()

+getConnected() : boolean

+ ServerViewerClient

<<entity>>

+ ServerPlayerClient

<<entity>>

-tournamentWins : int

-tournamentLoses : int

-gamesPlayed : int

+ServerPlayerClient()

+getTournamentWins() : int

+incrementTournamentWins()

+getGamesPlayed() : int

+incrementGamesPlayed()

+ ServerClientIdentifier

<<interface>>

<<implements>>

Abbildung 15: ServerClient

betrieben, nämlich das Verteilen der Anfrage an die Teilnehmer-ServerToClientConnections,bevor die Methode den Kontrollfluss zurückgibt. Im Falle einer Anfrage an einen verbunde-nen Client wird die Antwort durch Aufruf der passenden Methode im ServerConnectionRe-sultCallback an den Anfragenden zurückgeliefert. Die entsprechende Threading-Logik wirdin der ServerToClientConnection realisiert.Zur einfacheren Spezifizierung der Rezipienten ermöglicht der ServerToClientConnectionMa-nager es, einen ServerClientIdentifier an einen Client zu binden. Dazu wird den Listenern beieiner neuen Verbindung eine Verbindungs-ID mitgegeben, die dann zur Zuordnung genutztwerden kann. Nach Aufruf von mapClientToConnection(...) kann diese verworfen werden.

7.6.2 ServerToClientConnection und Unterklassen

Kommunikationsaufträge an die ServerToClientConnection (siehe Abbildung 17) werden imAllgemeinen in die tasks-Queue eingefügt und vom worker-Thread nach und nach asynchrondurchgeführt. Ein Aufruf einer der öffentlichen Methoden wird also ein Runnable-Objektmit dem gewünschten Verhalten erzeugen und dieses in die Queue einreihen. Bei dieser Er-zeugung findet insbesondere die Umwandlung in das vorgegebene Kommunikationsinterfacestatt, wobei dafür die Funktionalitäten vom CommonInterfaceConverter genutzt werden. EineAusnahme bilden getName() und isHuman().

26


+ ServerToClientConnection

<<boundary>>


<<boundary>>

-clientMap : Map<ServerClientIdentifier-ServerToClientConnection>

-clientMapInverse : Map<ServerToClientConnection-ServerClientIdentifier>

-connectionListenerManager : ListenerManager<ConnectionListener>

-acceptNewConnections : boolean

-nextConnectionId : int

+ServerToClientConnectionManager()

+mapClientToConnection(client : ServerClientIdentifier,connectionID : int)

+registerConnectionListener(listener : ServerConnectionListener)

+unregisterConnectionListener(listener : ServerConnectionListener)

+setPlayer(player : ServerClientIdentifier,id : PlayerID,attackSeconds : int,arrangeSeconds : int)

+announceOpponents(players : Set<ServerClientIdentifier>,List<PlayerID>)

+announceInvalidArrangement(recipients : Set<ServerClientIdentifier>,player : PlayerID)

+announceAttackPerformed(recipients : Set<ServerClientIdentifier>,attack : Attack)

+announceShipSunk(recipients : Set<ServerClientIdentifier>,ship : Ship)

+announceGameStarted(recipients : Set<ServerClientIdentifier>,initialModel : GameModel)

+announceGameStateChanged(recipients : Set<ServerClientIdentifier>,state : GameState)

+announceRoundStateChanged(recipients : Set<ServerClientIdentifier>,state : RoundState,player : PlayerID)

+announceWinner(recipients : Set<ServerClientIdentifier>,player : PlayerID)

+announceArrangementFinished(recipients : Set<ServerClientIdentifier>,playerShips : List<Ship>,player : PlayerID)

+requestShipArrangement(players : Set<ServerClientIdentifier>,callback : ServerConnectionResultCallback)

+requestMineArrangement(players : Set<ServerClientIdentifier>,callback : ServerConnectionResultCallback)

+requestAttack(player : ServerClientIdentifier,callback : ServerConnectionResultCallback)

+requestMineAttack(player : ServerClientIdentifier,callback : ServerConnectionResultCallback)

+setAcceptNewConnections(b : boolean)

-setupRMIRegistry()

+ Common.IServer

<<interface>>

+addPlayer(player : IPlayerClient)

+removePlayer(player : IPlayerClient)

+addViewer(viewer : IViewerClient)

+removeViewer(viewer : IViewerClient)

<<implements>>


<<interface>>

+notifyNewPlayerClient(name : String,ip : String,isHuman : boolean,connectionId : int)

+notifyNewViewerClient(name : String,ip : String,connectionId : int)

+notifyConnectionLost(client : ServerClientIdentifier)

+ ServerConnectionResultCallback

<<interface>>

+arrangementFinishedCallback(player : ServerClientIdentifier,arrangement : List<Ship>)

+attackFinishedCallback(player : ServerClientIdentifier,attack : Attack)

+connectionLostCallback(player : ServerClientIdentifier)

+ ServerToClientConnectionStatusHandler

<<interface>>

<<implements>>

Abbildung 16: ServerToClientConnectionManager

27


+ ServerToClientConnection

<<boundary>>

#tasks : BlockingQueue<Runnable>

#worker : Thread

#client : IClient

#statusHandler : ServerToClientConnectionStatusHandler

+ServerToClientConnection(id : int,client : IClient,handler : ServerToClientConnectionStatusHandler)

+announceInvalidArrangement(player : PlayerID)

+announceAttackPerformed(attack : Attack)

+announceShipSunk(ship : Ship)

+announceGameStarted(initialModel : GameModel)

+announceGameStateChanged(gameState : GameState)

+announceRoundStateChanged(roundState : RoundState,player : PlayerID)

+announceWinner(player : PlayerID)

+getName() : String


<<boundary>>

+ ServerToViewerConnection

<<boundary>>

+announceArrangementFinished(playerShips : List<Ship>,player : PlayerID)

+ ServerToPlayerConnection

<<boundary>>

+requestShipArrangement(callback : ServerConnectionResultCallback)

+requestMineArrangement(callback : ServerConnectionResultCallback)

+requestAttack(callback : ServerConnectionResultCallback)

+requestPositionDestroyedByMine(callback : ServerConnectionResultCallback)

+setPlayer(id : PlayerID,attackSeconds : int,arrangeSeconds : int)

+isHuman() : boolean

+announceOpponents(List<PlayerID>)

+ ServerToClientConnectionStatusHandler

<<interface>>

+handleDisconnect(connection : ServerToClientConnection)

Abbildung 17: ServerToClientConnection

28




Der ServerBidderClient ist im Abschnitt 7.5.2 enthalten und stellt die Bieter-Entitys und ihreaktuelle Wette dar.

7.7.2 ServerBidderControl

b,ServerBidderControl

<<control>>

bgameEndedpwinner,:,ServerPlayerClientF

bgameStartedpgame,:,GameModelF

bServerBidderControlpserverToBidderConnectionManager,:,ServerToBidderConnectionManager1clientManager,:,ServerClientManagerF

-calculateResultpamount,:,int1round,:,intF

-searchBetWinnerspF

b,ServerBidderListener

<<interface>><<implement>>

b,BetFormula

<<interface>>

bevaluatepamount,:,int1round,:,intF

b,DefaultBetFormula

<<utility>>

bevaluatepamount,:,int1round,:,intF

betFormula1

<<implement>>

b,ServerToBidderConnectionManager

<<boundary>>

serverToBidderConnectionManager

1

b,ServerClientManager

<<entity>> clientManager1

b,GameModel

<<entity>>gameModel

1

Abbildung 18: ServerBidderControl

Die ServerBidderControl (siehe Abbildung 18) kennt zwei Klassen, nämlich den ServerTo-BidderConnectionManager und den ServerClientManager. Diese werden ihr bereits im Kon-struktor mitgegeben. Außerdem trägt sie sich beim ServerToBidderConnectionManager alsServerBidderListener ein und reagiert somit auf die Notifications von diesem. Dazu ge-hört das registrieren neuer Bieter, wobei die ServerBidderControl über ServerClientMana-ger.createBidder(...) neue Bieter-Konten anlegt und das somit erzeugte Objekt als Callback-Antwort dem ServerToBidderConnectionManager perServerToBidderConnectionManager.mapClientToConnection(...) zurückgibt.

Wenn die ServerBidderControl durch gameStarted(...) benachrichtigt wurde, sorgt sie da-für, dass sich keine neuen Bieter mehr am Server anmelden können. Von dort an werden aberWettgebote angenommen, für die der zu erwartende Gewinn berechnet und schließlich mitanderen Daten im überlieferten ServerBidderClient gespeichert werden. Die Berechnung dererwarteten Gewinne erfolgt hierbei über die Klasse BetFormula. Dies ermöglicht ein Austau-schen der Gewinnformel, falls es gewünscht ist.Die Wettannahme-Phase wird wiederum durch gameEnded(...) unterbrochen. Nun werdenkeine Wettgebote mehr angenommen, sondern die Bieter über ihre Gewinne aus dem soebenbeendeten Spiel informiert. Dazu müssen nur die Bieter ermittelt werden, die in dem Spielauf den richtigen Spieler gesetzt haben, ihr Gewinn wurde bereits beim Absetzen der Wettenvorausberechnet und kann aus den ServerBidderClients ausgelesen werden.

Zur besseren Illustration dieser Prozesse dient das Sequenzdiagramm in Abbildung 19.

29


<<actor>>:Bidder

<<boundary>>:ServerToBidderConnectionManager

<<boundary>>:ServerToBidderConnection

<<control>>:ServerBidderControl

<<control>>:ServerMainControl

register()

(socket, statusHandler)

notifyNewBidder(ip,cid)

setAcceptNewConnections(true)

registerBidderListener(self)

<<entity>>:ServerClientManager

createBidderClient(ip)

GameStarted(game)setAcceptNewConnections(false)

Spiel wird gestartet

Wette abgeben

notifyNewBet(bidder, playerID, amount)

setCurrentBet(bet)

<<entity>>Bidder

:ServerBidderClient

Bet(amount)

Bieter über ihre Gewinne informieren nach Spielende

gameEnded(winner)

<<entity>>game:GameModel

searchBetWinners()

announceResults(clients:Set<ServerBidderClient)

sendBetResult(currentBudget, NewBudget, won:boolean))

bidder:ServerBidderClientmapClientToConnection(bidder, cid)

Bieter registrieren & mappen

getRoundNumber()

round:int

<<entity>>bet:Bet

new Bet(player, amount, round, expectedResult)

calculateBetResult(amount, round)

SD: Server-Bieter-Kommunikation

Abbildung 19: Sequenzdiagramm: Server-Bieter-Kommunikation

7.7.3 ServerToBidderConnectionManager

+ ServerToBidderConnectionManager

<<boundary>>

-serverSocket : ServerSocket

-acceptNewConnections : boolean

-clientMap : Map<ServerClientIdentifier-ServerToBidderConnection>

-clientMapInverse : Map<ServerToBidderConnection-ServerClientIdentifier>

-nextConnectionId : int

-betListeners : ListenerManager<ServerBidderListener>

+ServerToBidderConnectionManager()

+setAcceptNewConnections(b : boolean)

+registerBidderListener(listener : ServerBidderListener)

+unregisterBidderListener(listener : ServerBidderListener)

+announceResults(clients : Set<ServerClientIdentifier>)

-setupServerSocket()

+mapClientToConnection(client : ServerClientIdentifier,connectionID : int)

+ ServerToBidderConnection

<<boundary>>

+ ServerBidderListener

<<interface>>

+notifyNewBidderClient(ip : String,connectionId : int)

+notifyNewBet(bidder : ServerClientIdentifier,player : PlayerID,amount : int)

+notifyBidderConnectionLost(client : ServerClientIdentifier)

Abbildung 20: ServerToBidderConnectionManager

In Abbildung 20 befindet sich das Diagramm zur Klasse ServerToBidderConnectionMa-nager. Die Assoziation von einem ServerClientIdentifier mit einer Verbindung funktioniertanalog zum selben Vorgang beim ServerToClientConnectionManager.

30

7.7.4 ServerToBidderConnection

+ ServerToBidderConnectionManager

<<boundary>>

+ ServerToBidderConnection

<<boundary>>

-socket : Socket

-receiverThread : Thread

-connectionHandler : ServerToBidderConnectionHandler

+ServerToBidderConnection(socket : Socket,statusHandler : ServerToBidderConnectionHandler)

+sendBetResult(currentBudget : int,newBudget : int,won : boolean)

+destroyConnection()

-handleReceivedData(data : String)

+ ServerToBidderConnectionHandler

<<interface>>

+handleDisconnect(connection : ServerToBidderConnection)

+handleBet(connection : ServerToBidderConnection,player : int,betAmount : int)

Abbildung 21: ServerToBidderConnection

In Abbildung 21 befindet sich das Klassendiagramm zur ServerToBidderConnection. re-ceiverThread liest durchgängig auf dem socket. Bei vollständiger Übertragung ruft er hand-leReceivedData(...) auf, woraufhin das JSON-Format interpretiert wird, was im Erfolgsfallin einem Aufruf von handleBet(...) auf dem connectionHandler resultiert. sendBetResult(...)startet einen anonymen weiteren Thread, der das Senden der Daten übernimmt. Somit gibt dieMethode den Kontrollfluss direkt zurück, das Senden geschieht nebenläufig, aber im wechsel-seitigen Ausschluss zu anderen sendenden Threads.

8 Entwurf - Komponenten der Clients

8.1 Sequenzdiagramm: Angriff wurde ausgeführt

Das Sequenzdiagramm in Abbildung 22 zeigt die Interaktion zwischen internen Klassen, diemit der Ausführung der Methode attackPerformed(...) stattfindet.Diese beginnt mit dem Aufruf der Methode attackPerformed(...) vom Server auf der Client-ToServerConnection Klasse, welche daraufhin das Argument in ein Objekt vom Typ Attackumwandelt und attackPerformed(...) auf der Klasse GameClientController aufruft. Diese ruft

31


pushAttack(...) auf GameModel auf, um den aktuellen Spielstatus entsprechend zu ändern.Die Klasse GameModel informiert die GameView mit der Methode notifyGameModelChange(),dass eine Änderung am GameModel stattgefunden hat, welche den Benutzer über eine entspre-chend aktualisierte GUI über den abgeschlossenen Angriff informiert.Ist dieser Aufruf abgeschlossen wird der Kontrollfluss entsprechend des Sequenzdiagrammsin Abbildung 22 zurückgegeben.

«boundary» : ClientToServerConnection

«control» : GameClientControl

«entity» : GameModel

«boundary» : GameView

attackPerformed(a:commonIAttack)

attackPerformed(a_2:Attack)

pushAttack(a_2)

notifyGameModelChange()

SD: Angriff wurde ausgeführt

Abbildung 22: Angriff wurde ausgeführt

8.2 Sequenzdiagramm: Angriff ausführen

Das Sequenzdiagramm in Abbildung 23 zeigt die Interaktion zwischen internen Klassen, diemit der Ausführung der Methode makeAttack() stattfindet.Diese beginnt mit dem Aufruf von roundStateChanged() vom Server auf der ClientToSer-verConnection, welche daraufhin die gleiche Methode wiederum auf der GameClientControlaufruft.Diese ruft setAttackingPlayer(...) auf der Entity-Klasse GameModel auf, um den aktuellenSpielstatus entsprechend zu ändern.Das GameModel informiert dann GameView, um die GUI entsprechend zu aktualisieren.Ist dieser Aufruf abgeschlossen wird der Kontrollfluss entsprechend des Sequenzdiagrammsin Abbildung 23 zurückgegeben und im Anschluss vom Server makeAttack() auf der Ser-verToClientConnection aufgerufen. Klickt der Benutzer dann ein Feld an, wird dieses derPlayerGuiControl über recognizeGameFieldClick(...) mitgeteilt.PlayerGuiControl wandelt die Koordinate (x,y) in eine Position um und gibt diese über einen

32


Aufruf von attackHappened(...) an die Klasse GameClientControl weiter.Diese erzeugt ein Objekt der Klasse Attack. Dieses lässt die Einhaltung der Regeln durchAufruf von ruleCheck(...) auf dem RuleChecker überprüfen. Gibt ruleCheck(...) ein true andas Attack-Objekt zurück, wird durch dieses eine Rückgabe an GameClientControl gemacht.Durch den anschließenden Aufruf von sendAttack(...) auf ClientToServerConnection und dieRückgabe des Angriffs an den Server wird die Interaktion abgeschlossen.

«boundary» : ClientToServerConnection

«control» : GameClientController

«entity»game : GameModel

«control» : PlayerGuiController

«boundary» : GameView

roundStateChanged(...)

a

roundStateChanged(roundState, player)

setAttackingPlayer(player)

notifyGameModelChange()

Anzugreifendes Feld anklickenwait()

recognizeGameFieldClick(x,y,false)

playerMadeAttack(position, attackType)

«entity»a : Attack

new Attack(attacker, position, atackType)

«utility» : RuleChecker

checkAttack(a, model)

return true

sendAttack(a)

SD: Angriff ausführen

makeAttack()

Abbildung 23: Angriff ausführen


Das Verbindungsmanagement des Clients besteht aus den in Abbildung 24 abgebildeten Klas-sen und kapselt die gesamte RMI-Kommunikation mit dem Server.Die gesamte Kommunikation wird dabei – abgesehen vom Verbindungsauf- und -abbau – vomServer aus angestoßen, indem entsprechende Methoden beim Client aufgerufen werden. DerServer erhält die angeforderten Daten dann als Rückgabewerte dieser Funktionsaufrufe.Da die interne Darstellung der Daten im GameModel nicht mit der in den vorgeschriebenenInterfaces zur Kommunikation übereinstimmt, übernimmt das Verbindungsmanagement unterZuhilfenahme der Klasse CommonInterfaceConverter die Konvertierung, sodass der Clientintern auch nur mit der internen Darstellung arbeitet.

33


+ CientToServerConnection

<<boundary>>

+ClientToServerConnection()+announceInvalidArrangement(player : Common.PlayerID)+attackPerformed(attack : Common.IAttack,result : Common.AttackResult)+shipSunk(ship : Common.IShip)+gameStarted(area : int[],rules : int[])+gameStarted(area : int[],rules : int[],attacks : List<Common.IAttack>)+newOperation()+newOperation()+gameStateChanged(gameState : Common.GameState)+roundStateChanged(roundState : Common.RoundState,player : Common.PlayerID)+announceWinner(player : Common.PlayerID)+getName() : String+positionDestroyedByMine(pos : Common.IPosition)+connectToServer(serverIP : String)+disconnectFromServer()+abortOpenRequests()

+ IClient

<<interface>>

<<implements>>

+ PlayerClientConnection

<<boundary>>

-cachedAttack : Common.IAttack-cachedShipList : List<Common.IShip>-attackSent : Boolean-shipArrangementSent : Boolean

+arrangeShips() : List<Common.IShip>+arrangeMines() : List<Common.IMine>+makeAttack() : Common.IAttack+getPositionDestroyedByMine() : Common.IPosition+setPlayer(player : Common.PlayerID,attackSeconds : int,arrangeSeconds : int)+isHuman() : boolean+announceOpponents(opponents : List<Common.PlayerID>)+sendAttack(attack : Attack)+sendShipArrangement(ships : List<Ship>)

+ ViewerClientConnction

<<boundary>>

+arrangementFinished(playerShips : List<Common.IShip>,player : Common.PlayerID)

+ IViewerClient

<<interface>>

<<implements>>

+ IPlayerClient

<<interface>>

<<implements>>

attackResults : List<Common.AttackResult>,currentShips : List<Common.IShip>,sunkenShips : List<Common.IShip>,mines : List<Common.IMine>)

,

+ GameClientControl

<<control>>

Abbildung 24: Verbindungsmanagement des Clients

8.3.1 ClientToServerConnection

Die abstrakte Oberklasse ClientToServerConnection beinhaltet alle Methoden, die sowohl fürden Beobachter, als auch für den Spieler benötigt werden. Dies sind hauptsächlich die Metho-den, die lediglich über eine Änderung des Spielstandes informieren, wie zum Beispiel attack-Performed(...) für eine durchgeführte Attacke oder announceWinner(...) zum Bekanntgebendes Gewinners. Der generelle Ablauf bei diesen Methoden ist immer gleich: die Verbindungs-klasse leitet die Information an den GameClientController weiter, der dann entsprechend dasGameModel ändert.Weiterhin implementiert die ClientToServerConnection die Methoden zum Herstellen undTrennen der Verbindung mit dem Server.

8.3.2 PlayerClientConnection

Die Klasse PlayerClientConnection implementiert zusätzlich die für einen Spieler-Client be-nötigten Methoden, also hauptsächlich die, die für das Durchführen von Spielzügen benötigtwerden. Alle weiteren Methoden sind selbsterklärend und werden hier nicht weiter erläutert.

34

8.4 Clientsteuerung

Um die Funktionsweise der verschiedenen Methoden zu verstehen ist es zunächst notwen-dig, die Kommunikationsstruktur genauer zu betrachten. Da wie oben beschrieben jeglicheKommunikation vom Server ausgeht und auch die angeforderten Daten über Rückgabewerteübermittelt werden, liegt eine unidirektionale Kommunikation vor, d.h. der Client sendet nichtaktiv Daten an den Server. Aus Clientsicht ist dies allerdings wenig zufriedenstellend, es wärehingegen wünschenswert, Daten durch einen einfachen Methodenaufruf senden zu können.Deshalb simuliert die Verbindungsklasse eine bidirektionale Kommunikation, die eben dasaktive Senden von Daten ermöglicht. Erreicht wird dies durch zwei Typen von Methoden.Einmal die, die vom Server aufgerufen werden und die Daten über Rückgabewerte zurücklie-fern, also zum Beispiel makeAttack() oder arrangeShips(), und die Methoden, mit denen derClient Daten senden kann, wie sendAttack(...) oder sendShipArrangement(...).Ruft der Server zum Beispiel makeAttack(...) auf, um einen Angriff anzufordern, wartet dieseMethode, bis sie von sendAttack(...) wieder aufgeweckt wird. Um nun Daten zwischen diesenbeiden parallel laufenden Methoden austauschen zu können, besitzt die Klasse PlayerClient-Connection mehrere Attribute, in der beispielsweise der Angriff von sendAttack(...) gespei-chert wird und dann vom makeAttack()-Aufruf ausgelesen werden kann.

8.3.3 ViewerClientConnection

Die Klasse ViewerClientConnection implementiert zusätzlich die für einen Beobachter-Clientbenötigten Methoden. Dies ist lediglich arrangementFinished(...), die die Informationen überdie in der Aufbauphase positionierten Schiffe übergibt.

8.4 Clientsteuerung

8.4.1 GameClientControl

+ GameClientControl

<<control>>

-attackMade : boolean

+GameClientController(isHuman : boolean)+startGame(gameModel : GameModel)+gameStateChanged(gameState : GameState)+roundStateChanged(roundState : RoundState,player : PlayerID)+attackPerformed(attack : Attack)+shipSunk(ship : Ship)+arrangementFinished(playerShips : List<Ship>,player : PlayerID)+announceInvalidArrangement(player : PlayerID)+setPlayer(player : PlayerID,attackSeconds : int,arrangeSeconds : int)+announceOpponents(opponents : List<PlayerID>)+announceWinner(player : PlayerID)+playerMadeAttack(position : Position,attackType : InternalAttackType) : boolean+playerArrangedShip(positions : List<Position>,shipType : InternalShipType) : boolean+getName() : String+isHuman() : boolean

+ ClientToServerConnection

<<boundary>>

+ PlayerIdentity

<<entity>>

+ AIPlayer

<<control>>

+ RuleChecker

<<utility>>

+ GameModel

<<entity>>

+ ViewerGuiControl

<<control>>

Abbildung 25: GameClientControl

Die GameClientControl in Abbildung 25 besitzt auf der einen Seite Methoden, die dasVerbindungsmanagement bei entsprechenden Anfragen vom Server aufruft. Diese Methodenaktualisieren lediglich das GameModel und bedürfen keiner weiteren Erklärung.Auf der anderen Seite gibt es zwei Methoden, playerMadeAttack(...) und playerArranged-Ship(...), die von der GuiControl aufgerufen werden. Sie sind dafür zuständig zu überprüfen,

35


ob die Anfragen der GuiControl zulässig sind und die Anfrage gegebenenfalls an den Serverweiterzuleiten und das GameModel unter Umständen entsprechend zu ändern. Der Rückga-bewert gibt entsprechend an, ob die Anfrage akzeptiert wurde oder nicht.

8.4.2 PlayerIdentity

+ PlayerIdentity

<<entity>>

-name : String-id : PlayerID-isHuman : boolean

+PlayerIdentity(name : String,isHuman : boolean)+getName() : String+getID() : PlayerID+setID(id : PlayerID)+getIsHuman() : boolean

+ GameClientControl

<<control>>

Abbildung 26: PlayerIdentity

Abbildung 26 zeigt den Entwurf für die Klasse PlayerIdentity. Sie hält lediglich drei Infor-mationen, den Namen des Spielers, die aktuelle PlayerID und ob es sich um einen menschli-chen Gegner handelt.

8.5 ClientOberfläche

8.5.1 ViewerGuiControl

+ ViewerGuiControl

+leaveGame()+recognizeGameFieldClick(x : int,y : int,superweapon : boolean) : boolean+ViewerGuiController(gameClientControl : GameClientControl)+notifyRedrawField()

+ GameClientControl

Abbildung 27: ViewerGuiControl

36

8.5 ClientOberfläche

Die ViewerGuiControl (Abbildung 27) verwaltet mit der Funktion recognizeGameField-Click(...) Klicks, die ein Beobachter auf dem Spielfeld ausübt. In der Regel wird diese Funk-tion leer implementiert. Die von ViewerGuiControl erbende PlayerGuiControl wird dieseMethode überschreiben.

8.5.2 PlayerGuiControl

+ PlayerGuiControl

+recognizeGameFieldClick(x : int,y : int,superweapon : boolean) : boolean+recognizeArrangeShip(shiptype : ShipType,x : int,y : int,shipOrientation : orientation,arg5 : boolean)+recognizeArrangeMine(x : int,y : int) : boolean+PlayerGuiControl(gameClientControl : GameClientControl,gameModel : GameModel)

+ orientation

<<enumeration>>

+NORTH : Integer+EAST : Integer

+ GameClientControl

Abbildung 28: PlayerGuiControl

Die PlayerGuiControl (Abbildung 28) überschreibt die FunktionrecognizeGameFieldClick(...), sodass nun Klicks auch als Angriffe interpretiert werden kön-nen. Ob ein Angriff akzeptiert wird, entscheidet die GameClientControl. Die GameView ruftdie recognize(...) Funktionen auf und erhält durch die Rückgabewerte Auskunft über den Er-folg der entsprechenden Aktion.

8.5.3 GameView

+ GameView

-CBSuperWeapon:CheckBox

-LbGameTime:Label

+GameView(controller:ViewerGuiControl,model:GameModel)


-redraw()

-GameFieldClick()

+ ViewerGuiController + GameModel

Abbildung 29: GameView

Die GameView stellt die GUI für den Spieler bzw. Beobachter dar. Sie zeigt im Wesent-lichen die Inhalte des GameModels an. Des Weiteren ermöglicht sie die Durchführung vonAngriffen; hierzu wird beim Klick auf das Spielfeld die GameFieldClick(...)-Methode aufge-rufen, die die x- und y-Koordinaten des Klicks bestimmt und diese an den ViewerGuiCon-troller weiterleitet. Mit notifyGameModelChange(...) wird sie vom ViewerGuiController über

37


Änderungen im GameModel informiert, um diese bei der nächsten Ausführung von redraw()anzuzeigen.

8.6 Computergegner

Das Schiffe-Versenken-Spiel kann sowohl mit einem menschlichen Spieler, als auch mit einemcomputergesteuerten Spieler, der Künstlichen Intelligenz, gestartet werden. Da der compu-tergesteuerte Spieler keinerlei Interaktion mit einem menschlichen Benutzer benötigt, wirdlediglich die Klasse AIPlayer bereitgestellt, die eigenständig Angriffe durchführt und denSchiffsaufbau tätigt und hierbei bestimmte Muster verwendet, um die Chance auf einen Siegzu erhöhen. Die grundlegenden Vorgehensweisen dieser Algorithmen werden im Folgendennäher beschrieben. Hierbei wird zwischen der Phase des Spielaufbaus und der Phase des An-griffs unterschieden.

8.6.1 AIPlayer

+ AIPlayer

-attackSeconds : int

-arrangeSeconds : int

-nextAttackIsMine : boolean

+AIPlayer(gameClientControl : GameClientControl,gameModel : GameModel)

+setAttackSeconds(seconds : int)

+setArrangeSeconds(seconds : int)


-arrageShips()

-attack()

-destroyPositionByMine()

+ GameClientControl

+ Orientation

<<enumeration>>

+NORTH : int

+EAST : int+ Position + GameModel

+ GameModelListener

<<interface>>

<<implements>>

Abbildung 30: AIPlayer

Der AIPlayer (Abbildung 30) stellt den Computergegner dar. Damit dieser sich an die ge-gebenen Zeiten hält, werden ihm die entsprechenden Zeiten mithilfe von Settern (setAttackSe-conds(...), setArrangeSeconds(...)) gesetzt und in den dazugehörigen Attributen festgehalten.Ein weiteres Attribut ist das Flag nextAttackIsMine, das angibt ob der nächste Angriff einnormaler ist oder, ob aufgrund eines Minentreffers, ein eigenes Schiff angeschossen werden

38

8.6 Computergegner

muss. Über die Methode notifyGameModelChange() wird der AIPlayer darüber in Kenntnisgesetzt, dass sich das GameModel geändert hat und nun eine Aktion des Computergegnerserwartet wird. Je nachdem, was für eine Aktion erwartet wird, wird entweder arrangeShips()zum Aufbauen der Schiffe, attack() um einen Angriff auszuführen oder destroyPositionBy-Mine(), um ein eigenes Schiff anzuschießen, aufgerufen. Zusätzlich wird die EnumerationOrientation benutzt, um die Ausrichtung eines aufzustellenden Schiffs festzulegen und Li-sten mit Positions der gegnerischen getroffenen Schiffsbereiche zur Bestimmung des nächstenAngriffs.

8.6.2 Konzept für die Aufbauphase

Verfügbare Positionenzusammenstellen

Nicht gesetztesSchiff ermitteln

Schiffsausrichtungzufällig wählen

Verfügbare Positionzufällig wählen

Positionen entlang derSchiffsrichtung und Schiffslänge

auf Verfügbarkeit prüfen

Schiffsausrichtungdrehen

Schiff setzen

[nicht verfügbar]

[gedreht und nicht verfügbar]

[verfügbar]

[Schiff verfügbar]

[kein Schiff verfügbar]

Schiffsausrichtung:senkrecht oder waagerecht

Verfügbare Positionzufällig wählen

[Mine verfügbar]Mine setzen

[keine Mine Verfügbar]

Abbildung 31: Konzept der KI für die Aufbauphase

In der Aufbauphase (Abbildung 31) werden zunächst die verfügbaren Positionen auf demSpielfeld zusammengestellt. Anschließend werden die nicht gesetzten Schiffe der Größe nach,beginnend beim größten Schiff, ermittelt und eine Ausrichtung sowie eine Position zufällig ge-wählt. Ist die Position samt der für das Schiff benötigten Positionen verfügbar, wird das Schiffgesetzt. Ansonsten wird es erst gedreht bevor erneut eine Position zufällig gewählt wird. EineVerfeinerung des Konzepts für den Fall, dass sich ein Schiff mehrfach nicht aufstellen lässt,

39


erfolgt in der Implementierungsphase. Sind alle Schiffe gesetzt, werden – sofern vorhanden –die Minen einzeln und zufällig auf verfügbare Positionen gesetzt.

8.6.3 Konzept für die Angriffsphase

Suche nachangeschossenem Schiffen

zulässige Positionzufällig auswählen

Spezialwaffenutzen

Attackeausführen

Versuche Schiffsausrichtungzu bestimmen

gültige Nachbarpositionauswählen

Wähle Position an welcherSchiff vermutet wird

[angeschossenes Schiff vorhanden]

[angeschossenes Schiff nicht vorhanden]

[Nachbarposition beschossen]

[Nachbarpositionen nicht beschossen]

[Spezialwaffe verfügbar]

[Spezialwaffe nicht verfügbar]

[möglich]

[nicht möglich]

Abbildung 32: Konzept der KI für die Angriffsphase

Die Angriffsphase (Abbildung 32) gliedert sich in zwei Teilbereiche. Zum einen ist dies derAngriff auf ein bisher noch nicht beschossenes, zufällig ausgewähltes Feld und zum anderenist dies der Versuch, ein bereits teilweise beschossenes Schiff zu versenken.In der Phase des randomisierten Schusses auf ein gegnerisches Feld befindet sich der Compu-terspieler nur, wenn kein gegnerisches Schiff existiert, das getroffen aber nicht versenkt ist. Obdies der Fall ist, merkt sich die KI mithilfe von Positionslisten, die getroffene Schiffsbereicheenthalten. Für jeden Gegner wird eine solche Liste verwaltet, wobei nach jeder durchgeführtenAttacke auf ein gegnerisches Feld, sowohl selber durchgeführte Attacken als auch von anderenSpielern durchgeführte Angriffe, die entsprechende Liste aktualisiert wird. Wurde ein Schiffversenkt, so werden alle Positionen, die zu diesem Schiff gehören, aus der entsprechendenListe gelöscht. Wird die KI aufgefordert einen Angriff durchzuführen, prüft sie zunächst obangeschossene Schiffe existieren. Ist dies der Fall, versucht sie solch ein Schiff zu versenken,indem das direkte Umfeld des Schiffes betrachtet wird. Ist keine der Nachbarpositionen bisherbeschossen, so wird eine dieser Positionen attackiert. Wurden jedoch schon eine oder mehrereNachbarpositionen angegriffen, versucht die KI daraus die Schiffsrichtung zu bestimmen undgreift dort an, wo sie einen noch unversehrten Teil des betrachteten Schiffs vermutet.Die Spezialwaffe wird dafür eingesetzt, ein Schiff, von dem nur eine Position bekannt ist, zuerschließen, indem direkt neben das Schiff geschossen wird. Hierdurch werden drei angren-zende Positionen des Schiffs getroffen und die Ausrichtung kann eher bestimmt werden.

40

Wird bei einem Angriff eine gegnerische Mine getroffen und muss die KI infolgedessen ei-nes ihrer Schiffe anschießen, so wird ein Schiff ausgewählt, welches bereits angeschossen ist.Existiert solch ein Schiff nicht, wird je nach verwendetem Regelsatz das kleinste bzw. größtenoch vorhandene Schiff ausgewählt.

9 Entwurf - gemeinsam genutzte Komponenten

9.1 RuleChecker

Die Klasse RuleChecker (siehe Abbildung 33) dient zum Überprüfen von Aktionen, die durchSpieler durchgeführt werden sollen. Sie besteht aus drei statischen Methoden, die auf Basis ei-nes übergebenden GameModels und einer auszuführenden Attacke bzw. Schiffpositionierungüberprüfen, ob die Ausführung gültig ist. Der RuleChecker wird zum einen auf der Serverseiteverwendet, wo die Klasse ServerGame ihn benutzt, um Aktionen von Spielerclients auf Feh-ler zu überprüfen. Zum Anderen benutzt auch die GameClientControl den RuleChecker, umschon vor dem Senden der Aktion des Spielers über das Netzwerk Regelverstöße zu entdeckenund somit Fehler zu vermeiden.

+)RuleChecker

<<utility>>

+checkShipPositioning(ship):)Ship,gameModel):)GameModel)):)boolean

+checkShipPositioning(listOfShips):)List<Ship>,gameModel):)GameModel)):)boolean

+checkAttack(attack):)Attack,gameModel):)GameModel)):)boolean

Abbildung 33: RuleChecker

9.2 GameModel

Die Klasse GameModel (siehe Abbildung 34) mit ihren Unterklassen stellt die Datenhaltungfür jedes Spiel bereit. Ein Aufruf von GameModel() erzeugt ein Default-GameModel. Mit-hilfe der Methoden writeModel(...) und readModel(...) geschieht das Ein- und Auslesenvon GameModels über die Java Serialize Funktion. Die Methode registerGameModelListe-ner(...) und analog die Unregister-Methode bieten die Möglichkeit, interessierte Klassen, diedas GameModelListener-Interface implementieren, über die notifyGameModelChange() überÄnderungen im GameModel zu benachrichtigen. Ein ListenerManager koordiniert die Be-nachrichtigungen. Der Zugriff auf das GameModel findet nur synchronisiert statt, das heißtalle Zugriffsmethoden auf das GameModel geschehen im wechselseitigen Ausschluss. Somitbleibt die Datenintegrität erhalten.

41

9 Entwurf - gemeinsam genutzte Komponenten

+ G

ameM

odel

<<

entit

y>>

-rou

ndS

tate

: R

ound

Sta

te

-atta

ckin

gPla

yer

: Pla

yer

-sta

rtT

ime

: Dat

e

-sta

teO

fGam

eSin

ce :

int

-tur

nSin

ce :

int

-tim

eNot

Pla

yed

: int

-gam

eSta

te :

Gam

eSta

te

-gam

eMod

elLi

sten

ers

: Lis

tene

rMan

ager

<G

ameM

odel

List

ener

>

-win

ner

: Pla

yer

-rou

ndN

umbe

r : i

nt

+G

ameM

odel

()

+w

riteM

odel

(out

: O

utp

utS

trea

m)

+re

adM

odel

(in :

Inpu

tStr

eam

) : G

ameM

odel

+ge

tRou

ndS

tate

() :

Ro

undS

tate

+se

tRou

ndS

tate

(r :

Rou

ndS

tate

)

+ge

tAtta

ckin

gPla

yer(

) :

Pla

yer

+se

tAtta

ckin

gPla

yer(

p : P

laye

r)

+ge

tSec

onds

Pla

yed(

) :

int

+ge

tTur

nSin

ce()

: in

t

+is

Run

ning

() :

bool

ean

+ge

tGam

eSta

te()

: G

ameS

tate

+se

tGam

eSta

te(g

s : G

am

eSta

te)

+re

gist

erG

ameM

odel

List

ener

(list

ener

: G

ameM

odel

List

ener

)

+un

regi

ster

Gam

eMod

elL

iste

ner(

liste

ner

: Gam

eMod

elLi

sten

er)

+ge

tPla

yer(

id :

Pla

yerI

D)

: Pla

yer

+ge

tGam

eCon

figur

atio

n()

: Gam

eCon

figur

atio

n

+ge

tPos

ition

s(p

: Pla

yer)

: P

ositi

on[][

]

+ge

tPla

yers

() :

List

<P

laye

r>

+ge

tAtta

cks(

) : L

ist<

Att

ack>

+ge

tLog

Eve

nts(

) : L

ist<

LogE

vent

>

+ge

tShi

ps(p

: P

laye

r) :

List

<S

hip>

+se

tGam

eCon

figur

atio

n(gc

: G

ameC

onfig

urat

ion)

+ge

tAllo

wA

djoi

ning

Shi

ps(

) : b

oole

an

+ge

tAllo

wA

tBor

der(

) : b

oole

an

+ge

tAtta

ckR

ule(

) : A

ttack

Rul

e

+ge

tSpe

cial

Wea

pon(

) :

bool

ean

+ge

tGam

eCon

figur

atio

n()

: Gam

eCon

figur

atio

n

+se

tGam

eCon

figur

atio

n(gc

: G

ameC

onfig

urat

ion)

+se

tWin

ner(

s : P

laye

r)

+ge

tWin

ner(

) : P

laye

r

+pu

shD

isco

nnec

t(d

: Dis

conn

ect)

+pu

shA

ttack

(a :

Atta

ck)

+pu

shS

hip(

s : S

hip)

+pu

shP

laye

r(p

: Pla

yer)

+ge

tRou

ndN

umer

() :

int

+in

crem

entR

ound

Num

ber(

)

+ G

ameC

onfig

urat

ion

<<

entit

y>>

sieh

e vo

rgeg

eben

esec

ore

Mod

ell

+ A

ttack

<<

entit

y>>

-atta

ckR

es :

Atta

ckR

esul

t

-atta

ckT

ype

: Atta

ckT

ype

-pos

ition

: P

ositi

on

-atta

cker

: P

laye

r

+A

ttack

(a :

Pla

yer,

p : P

ositi

on,t

: Atta

ckT

ype)

+ge

tAtta

ckR

esul

t()

: Att

ackR

esul

t

+se

tAtta

ckR

esul

t(a

: Att

ackR

esul

t)

+ge

tAtta

ckT

ype(

) : A

ttack

Typ

e

+ge

tPos

ition

() :

Pos

itio

n

+se

tPos

ition

(p :

Pos

itio

n)

+ge

tAtta

cker

() :

Pla

yer

+se

tAtta

cker

(p :

Pla

yer)

+ L

ogE

vent

<<

entit

y>>

+ge

tDes

crip

tion(

) : S

trin

g

+ P

ositi

on

<<

entit

y>>

-fie

ldT

ype

: Fie

ldT

ype

-atta

cked

: A

ttack

Res

ult

-xP

os :

int

-yP

os :

int

+P

ositi

on(f

t : F

ield

Typ

e,x

: in

t,y :

int,o

wne

r : P

laye

r)

+ge

tFie

ldT

ype(

) : F

ield

Typ

e

+ge

tAtta

cked

() :

Atta

ckR

esul

t

+se

tAtta

cked

(ar

: Atta

ckR

esul

t)

+ge

tX()

: in

t

+ge

tY()

: in

t

+ge

tOw

ner(

) : P

laye

r

+ F

ield

Typ

e

<<

enum

erat

ion>

>

+W

AT

ER

+IS

LAN

D

+IN

VA

LID

+ A

ttack

Typ

e

<<

enum

erat

ion>

>

+M

INE

+N

OR

MA

L

+S

PE

CIA

L_W

EA

PO

N

+ S

hipT

ype

<<

enum

erat

ion>

>

+B

AT

TLE

SH

IP

+D

ES

TR

OY

ER

+C

RU

ISE

R

+S

UB

MA

RIN

E

+M

INE

+ P

laye

r

<<

entit

y>>

-num

berO

fMis

take

s : i

nt

-spe

cial

Wea

ponL

eft :

boo

lean

-max

Tur

nTim

e : i

nt

-pla

yerA

ccou

nt :

Ser

verP

laye

rClie

nt

-pla

yerI

D :

Pla

yerI

D

+P

laye

r(pl

ayer

Acc

ount

: S

erve

rPla

yerC

lient

,int :

max

Tur

nTim

e)

+P

laye

r(id

: P

laye

rID

)

+ge

tNum

berO

fMis

take

s()

: int

+in

crem

entM

ista

kes(

) :

int

+ha

sSpe

cial

Wea

ponL

eft(

) : b

oole

an

+se

tSpe

cial

Wea

ponL

eft(

b : b

oole

an)

+ge

tMax

Tur

nTim

e()

: in

t

+se

tMax

Tur

nTim

e(va

lue

: int

)

+ge

tPla

yerA

ccou

nt()

: S

erve

rPla

yerC

lient

+se

tPla

yerA

ccou

nt(s

: S

erve

rPla

yerC

lient

)

+ge

tPla

yerI

D()

: P

laye

rID

+ad

dShi

p(s

: Shi

p)

+re

mov

eShi

p(s

: Shi

p)

+ge

tPos

ition

s()

: Pos

itio

n[][]

+ge

tShi

ps()

: Li

st<

Shi

p>

+ S

hip

<<

entit

y>>

-typ

e : S

hipT

ype

-set

On

: Lis

t<P

ositi

on>

+S

hip(

type

: S

hipT

ype,

so :

List

<P

ositi

on>

)

+ge

tTyp

e()

: Shi

pTyp

e

+ge

tSet

On(

) : L

ist<

Pos

ition

>

+se

tSet

On(

List

<P

ositi

on>

)

+ge

tOw

ner(

) : P

laye

r

+ S

erve

rVie

wer

Clie

nt

<<

entit

y>>

+ G

ameS

tate

<<

enum

erat

ion>

>

+F

INIS

HE

D

+S

TA

RT

ED

+A

BO

RT

ED

+P

AU

SE

D

+R

ES

UM

ED

+IN

ITIA

L

+ M

ista

ke

<<

entit

y>>

-mis

take

Typ

e : M

ista

keT

ype

+ge

tMis

take

Typ

e()

: Mis

take

Typ

e

+M

ista

ke(m

t : M

ista

keT

ype,

play

er :

Pla

yer)

1

+ M

ista

keT

ype

<<

enum

erat

ion>

>

+A

TT

AC

K

+T

IME

OU

T

+S

HIP

_PO

SIT

ION

+ G

ameM

odel

List

ener

<<

inte

rfac

e>>

+no

tifyG

ameM

odel

Cha

nge(

)

+ D

isco

nnec

t

<<

entit

y>>

-pla

yer

: Ser

verP

laye

rClie

nt

+ge

tPla

yer(

) : S

erve

rPla

yerC

lient

1

1

+ R

ound

Sta

te

<<

enum

erat

ion>

>

+A

RR

AN

GE

+A

TT

AC

K

+M

INE

_AT

TA

CK

+ A

ttack

Res

ult

<<

enum

erat

ion>

>

+H

IT

+W

AT

ER

+IN

VA

LID

+M

INE

Abbildung 34: GameModel

42

10 Entwurf - Komponenten des Bieters

10.1 Persistente Klassen und Verbindung

10.1.1 BidderService

+ BidderToServerConnection

<<boundary>>

+ BidderService

<<control>>

-listener : BidderServiceListener

+onStartCommand(intent : Intent,flags : int,startId : int)

+placeBet(player : int,amount : int)

+getBidderAccount() : BidderAccount

+setBidderServiceListener(l : BidderServiceListener)

+unsetBidderServiceListener()

+connectToServer(ipAddress : String)

+isConnectedToServer() : boolean

+disconnectFromServer()

+onBind(intent : Intent) : IBinder

+ BidderAccount

<<entity>>

+ BidderService.BidderBinder

+getService() : BidderService

+ android.os.Binder+ android.app.Service

+ BidderServiceListener

<<interface>>

+notifyBetSent()

+notifyBetResult()

+notifyConnectionEstablished()

+notifyConnectionFailed(error : String)

Abbildung 35: BidderService

Die meisten Methoden des BidderService (siehe Abbildung 35) stellen die Funktionalitätendes BidderClients für die Activitys zur Verfügung. Die Kommunikation mit den Activityswird folgendermaßen geregelt:Die Activity bindet den (bereits gestarteten) Service durch Aufruf von bindService(...) an sich;dabei ruft das Android-System die Methode onBind(...) auf dem BidderService auf, die eineInstanz der inneren Klasse BidderService.BidderBinder zurückgibt. Darüber kann die Activitydann die Instanz des BidderService (getService()) anfragen und – da Service und Activity imselben Prozess laufen werden – direkt auf dessen Methoden zugreifen.Per setBidderServiceListener(...) kann die aktive Activity sich als BidderServiceListener ein-tragen, um über Ereignisse benachrichtigt zu werden. Durch unsetBidderServiceListener(...)kann (z.B. wenn die Activity in den Hintergrund gerät) diese Verbindung wieder getrennt wer-den. Ist kein BidderServiceListener im BidderService eingetragen, so wird der Benutzer übereine Android-Notification über neue Wettergebnisse (oder Ähnliches) benachrichtigt.

10.1.2 BidderToServerConnection

Der Aufbau dieser Klasse (Abbildung 36) ist sehr ähnlich zu ihrem Gegenstück, der Server-ToBidderConnection (7.7.4). Das Vorgehen mit dem Socket und den Threads verläuft analog.

43

10 Entwurf - Komponenten des Bieters

+ BidderToServerConnection

<<boundary>>

-socket : Socket

-receiverThread : Thread

-connectionHandler : BidderToServerConnectionHandler

+BidderToServerConnection(ipAddress : String,handler : BidderToServerConnectionHandler)

+sendBet(player : int,amount : int)

+destroyConnection()

-handleReceivedData(data : String)

+ BidderToServerConnectionHandler

<<interface>>

+handleConnectionEstablished()

+handleDisconnect(error : String)

+handleBetResult()

+handleBetSent()

Abbildung 36: BidderToServerConnection

10.1.3 BidderAccount

+ BidderAccount

<<entity>>

-budget : Integer

-previousBudget : Integer

-lastBetWasWon : Boolean

-currentBetAmount : Integer

-currentBetPlayer : Integer

-newResultToDisplay : boolean

+getBudget() : int

+isBudgetCertain() : boolean

+getPreviousBudget() : int

+applyBetResult(previousBudget : int,newBudget : int,won : boolean)

+applyBet(player : int,amount : int)

+setResultShown()

Abbildung 37: BidderAccount

Vom BidderAccount wird für jede hergestellte Verbindung ein neues Objekt erzeugt. Umdie Konsistenz der Daten zu wahren, sollen Methodenaufrufe auf dem BidderAccount imwechselseitigen Ausschluss stattfinden. Das newResultToDisplay-Flag dient der BidderBe-tActivity dazu, herauszufinden, ob das aktuelle Wettergebnis dem Benutzer bereits mitgeteiltwurde.

10.2 Activitys

Nicht aufgeführt wird hier die BidderMainActivity, da diese sehr einfach aufgebaut ist.

44

10.2 Activitys

+ BidderService

<<control>>+ BidderConnectionActivity

<<control>>

-ipInputView : TextView

-connectButton : Button

#onCreate(state : Bundle)

-checkIpAddressFormat(ip : String)

+issueConnection(ip : String)

+ android.app.Activity

Abbildung 38: BidderConnectionActivity

10.2.1 BidderConnectionActivity

In Abbildung 38 befindet sich das Klassendiagramm zur BidderConnectionActivity.

10.2.2 BidderBetActivity

+ BidderService

<<control>>

+ BidderBetActivity

<<control>>

-budgetView : TextView

-betAmountView : TextView

-betPlayerView : Spinner

-betButton : Button

-disconnectButton : Button

#onCreate(state : Bundle)

#onStart()

+disconnectFromServer()

+placeBet()

+showBetResult()

+ BidderServiceListener

<<interface>><<implements>>

+ android.app.Activity

Abbildung 39: BidderBetActivity

Wenn die Activity sichtbar wird, ruft das Android-System onStart(...) auf der Activityauf. Hier soll dabei zusätzlich überprüft werden, ob ein neues Wettergebnis vorliegt und indiesem Fall der Dialog konstruiert werden, in dem dies dem Benutzer mitgeteilt wird. Dies istbesonders relevant, falls die Activity nicht aktiv war, als das Ergebnis eingetroffen ist und dieBidderBetActivity durch die Notification gestartet wurde.

45

Abbildungsverzeichnis

Abbildungsverzeichnis

1 Klassendiagramm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Klassendiagramm Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Klassendiagramm Bidder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Turnier einrichten/Spiel starten . . . . . . . . . . . . . . . . . . . . . . . . . 175 Spiel beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 ServerMainInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 ServerTournamentView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 ServerCreateGameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 ServerMainControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2210 TournamentManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2211 TournamentManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2312 ServerCreateGameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2413 ServerGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2514 ServerClientManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2515 ServerClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2616 ServerToClientConnectionManager . . . . . . . . . . . . . . . . . . . . . . 2717 ServerToClientConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . 2818 ServerBidderControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2919 Sequenzdiagramm: Server-Bieter-Kommunikation . . . . . . . . . . . . . . 3020 ServerToBidderConnectionManager . . . . . . . . . . . . . . . . . . . . . . 3021 ServerToBidderConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122 Angriff wurde ausgeführt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3223 Angriff ausführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3324 Verbindungsmanagement des Clients . . . . . . . . . . . . . . . . . . . . . . 3425 GameClientControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3526 PlayerIdentity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3627 ViewerGuiControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3628 PlayerGuiControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3729 GameView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3730 AIPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3831 Konzept der KI für die Aufbauphase . . . . . . . . . . . . . . . . . . . . . . 3932 Konzept der KI für die Angriffsphase . . . . . . . . . . . . . . . . . . . . . 4033 RuleChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4134 GameModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4235 BidderService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4336 BidderToServerConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . 4437 BidderAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4438 BidderConnectionActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 4539 BidderBetActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

46

Analyse & Entwurf - Heinz Nixdorf Institut€¦ · Heinz Nixdorf Institut Fachgruppe...

Documents

Transcript of Analyse & Entwurf - Heinz Nixdorf Institut€¦ · Heinz Nixdorf Institut Fachgruppe...