Embed Size (px)
Citation preview
Heinz Nixdorf InstitutFachgruppe Softwaretechnik
Zukunftsmeile 133102 Paderborn
Analyse-&Entwurfsdokumentfür die Umsetzung eines verteilten Schiffe-Versenken-Spiels
Team 04 - ITanic Software
Betreuer: Claudia Schumacher
Paderborn, den 23. Mai 2012
Autoren:Markus Dollmann Daniel ErdmannMustafa Güven Jeanette KaiserSimon Kessler Johannes LangschmidtMarco Lobo Andre MengerSimon Pieper Torben Sauerland
Inhaltsverzeichnis
1 Einleitung 1
2 Analyse 12.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1.1 Eclipse (RCP + Plug-ins) . . . . . . . . . . . . . . . . . . . . . . . . 12.1.2 SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.3 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.4 EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.5 GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.6 RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.7 Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.8 Modellierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.9 KI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.10 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Interaktion zwischen den Komponenten . . . . . . . . . . . . . . . . . . . . 72.3 Komponentenschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Entwurf 123.1 Modellierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Verfeinerung der Architektur . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Struktur der Komponente . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3 Abläufe innerhalb der Komponente . . . . . . . . . . . . . . . . . . 15
3.2 Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 Verfeinerung der Architektur . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Struktur der Komponente . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Abläufe innerhalb der Komponente . . . . . . . . . . . . . . . . . . 19
3.3 KI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1 Verfeinerung der Architektur . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Struktur der Komponente . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3 Abläufe innerhalb der Komponente . . . . . . . . . . . . . . . . . . 24
Abbildungsverzeichnis 30
1 Einleitung
Das Analyse- & Entwurfsdokument beschreibt zum einen die Analyse der Anforderungen andie zu entwickelnde Software. Hier wird der Ist – Zustand der einzelnen Plug-ins erläutert,woraufhin dann die Interaktionen zwischen den grafischen Komponenten dargestellt undanschließend die Komponentenschnittstellen veranschaulicht werden.Im zweiten Teil wird der Entwurf der technischen Umsetzung erstellt. Es soll der Übergangdes Ist – Zustands in den Soll – Zustand dargestellt werden. Das heißt, dass die Struktur derAnalyse verfeinert wird und die Entscheidungen für die Implementierungen getroffen werden.Der Entwurf geht auf die einzelnen Komponenten näher ein und erläutert abschließend dasVerhalten der wichtigsten Methoden und Algorithmen.
2 Analyse
In der Analyse untersuchen und präzisieren wir die Anforderungen an das Schiffe-Versenken-System. In diesem Kapitel gehen wir auf die Grundlegende Architektur der Komponenten, aufdie Interaktion zwischen den Komponenten und auf die Komponentenschnittstellen ein. Zielder Analyse ist der Gewinn von Strukturen für die Implementierung.
2.1 Architektur
Dieser Abschnitt beschreibt die grundlegenden Komponenten und deren Zusammenspiel imProjekt. Da die Software auf Eclipse aufgebaut wird, werden zunächst die einzelnen Plug-insanalysiert. Außerdem wird auf das Modell-View-Controller Entwurfsmuster näher eingegangen.
2.1.1 Eclipse (RCP + Plug-ins)
Für die Programmierung des Schiffe-Versenken-Systems benutzen wir die Entwicklungsumge-bung Eclipse. Eclipse ist ein plattformunabhängiges Programmierwerkzeug zur Entwicklungvon Software. Eclipse ist durch Plug-ins um neue Funktionalitäten erweiterbar und bietetaußerdem die Rich Client Platform (RCP), welche es Entwicklern basierend auf dem Eclipse-Framework ermöglicht, von der Eclipse-Plattform unabhängige Anwendungen zu schreiben.Wir werden unseren Modellierer und unseren Beobachter auf Basis der RCP realisieren. DieRich Client Platform ist ein Framework zur Entwicklung von Plug-in-basierten Anwendungen.Plug-ins sind Software-Module, die nach dem Prinzip eines Baukastens mit anderen Modulenkombinierbar sind. Durch die starke Modularisierung von Anwendungen durch Plug-ins istgewährleistet, dass mehrere Entwickler, ohne sich gegenseitig zu behindern, parallel arbeitenkönnen und die Menge an Quellcode überschaubar bleibt. Auch die Wiederverwendung vonbereits vorhandenem Quellcode wird durch die Modularisierung vereinfacht. Ebenso lassensich Anwendungen dadurch kontinuierlich erweitern, ohne in bestehenden Code eingreifen zumüssen. RCP stellt viele allgemeine Basisfunktionalitäten für die Realisierung von beliebigen
1
2 Analyse
Programmen auf Basis der Programmiersprache Java bereit. Eclipse ist selbst eine Anwendungder Rich Client Platform. Die Rich Client Platform ist als Open Source Projekt frei verfügbarund Anwendungen welche auf der RCP basieren funktionieren Betriebssystemunabhängig.
2.1.2 SWT
Das Standard Widget Toolkit (SWT) ist das GUI-Framework der Eclipse-Plattform. Diesesnutzt Projekt SWT, da es eine Java API bietet mit der man mit den nativen UI-Widgets arbeitenkann. Dadurch wird ein plattformabhängiges Look&Feel erreicht. Von Eclipse werden u.a. diegroßen Plattformen Windows, Linux und Mac OS X unterstützt, sodass möglichst viele Nutzerdas Schiffe-Versenken-System im Design ihres Betriebssystems sehen. Wir nutzen SWT fürz.B. für unsere Buttons der GUI - Oberfläche.
2.1.3 MVC
MVC (Model-View-Controller) ist ein Architekturmuster zur Softwareentwicklung. Der Codewird in 3 Schichten aufgeteilt.
• Die Model-Schicht enthält die Daten und die Geschäftslogik. Es wird das Beobachter-Entwurfsmuster(?) genutzt, um den Controller über Änderungen zu informieren.
• Die View-Schicht ist für das Darstellen der Oberfläche zuständig. Dazu fordert sie dieDaten vom Model an. Im View getätige User-Inputs werden an die Controller-Schichtweitergegeben.
• Die Controller-Schicht behandelt den User-Input und übernimmt die Programmsteue-rung. Dadurch ist sie in gewisser Weise die Schnittstelle zwischen der Model- undView-Schicht, da sie den User-Input von der View-Schicht annimmt und ggf. Datenände-rungen an die Model-Schicht weiterleitet.
Ein großer Vorteil von MVC ist, dass problemlos für eine Datenbasis mehrere Outputs(Views)erstellt werden können. Ein weiterer Vorteil ist, dass die verschiedenen Schichten von ver-schiedenen Entwicklern entwickeln lassen können,wenn die Schnittstellen vorher definiertwurden. Ebenfalls ist die leichte Erweiterbarkeit/Wartbarkeit ein großer Vorteil, da einzelneKomponenten problemlos ausgetauscht bzw. verändert werden können ohne das die anderenKomponenten angepasst werden müssen.
2.1.4 EMF
Das Eclipse Modeling Framework (EMF) ist ein Open Source Plug-in für Eclipse mit demJAVA-Quellcode erstellt werden kann. Dieser JAVA-Quellcode basiert so auf dem erstelltenModell. EMF kann den erstellen Quellcode abfragen, manipulieren, serialisieren, validieren undauf Änderungen überwachen. EMF kann im Model-Teil des Model-View-Controller-Konzepts
2
2.1 Architektur
verwendet werden. Nach der Generierung ist es möglich den Quellcode abzuändern oder auchFunktionalitäten hinzuzufügen. Anschließend kann der geänderte Code mit dem ursprünglichenModell zusammengeführt werden, sodass wieder ein konsistentes strukturiertes Modell entsteht.
2.1.5 GEF
Abbildung 1 erklärt die Abhängigkeiten im Graphical Editing Framework (GEF). Sie bieteteine Umgebung um grafische Editoren und Views in der Eclipse Plattform zu implementieren.Es nutzt dazu ein SWT-Canvas, das mit einer draw2d-Oberfläche initialisiert wird. Darinlädt die GEF-Komponente anschließend die Ansicht. Als Entwurfsmuster benutzt GEF dasMVC-Prinzip. Das Model ist dabei losgelöst von den anderen Komponenten und hat keineVererbungsbeziehungen mit Klassen aus der GEF-Komponente. Somit bietet sich an das Modelmittels EMF zu erstellen. Die Controller-Klassen heißen in der GEF-Komponente EditParts.Diese lesen die Daten aus den Model-Klassen aus und erstellen so genannte Figures. DieFigures bilden somit die View-Komponente. GEF wird für unser Projekt im Beobachter undim Modellierer verwendet. In diesen Komponenten wird GEF zur Anzeige der Spielflächegenutzt. Die Spielflächen werden in den Editor-Bereich der RCP geladen. Das nachfolgendeDiagramm veranschaulicht die Abhänigkeiten von GEF zu den anderen Komponenten derEclipse-Umgebung und des Schiffe-Versenken-Systems.
<<component>>org.eclipse.core.runtime
<<component>>org.eclipse.swt
<<component>>org.eclipse.draw2d
<<component>>org.eclipse.gef
<<component>>org.eclipse.ui.views
<<component>>org.eclipse.ui.workbench
<<component>>org.eclipse.ui.jface
Abhängigkeiten von GEF
<<component>>de.itanic.modellierer
<<component>>de.itanic.beobachter
Abbildung 1: GEF Komponentendiagramm
3
2 Analyse
2.1.6 RMI
Abbildung 2: RMI-Aufbau
Die Remote Method Invocation(RMI) bezeichnet ein Prinzip und dessen Java-Umsetzungzur vereinfachten Netzwerkkommunikation. Die Funktionsweise von RMI sieht vor, dass einoder mehrere Clients Methoden eines Servers aufrufen können, welcher unter Umständenauf einem anderen System liegt, also über ein Netzwerk angesprochen werden muss. RMIübernimmt für den Programmierer die aufwendige Netzwerkkommunikation und ermöglicht essomit Anwendungscode zu verteilen, ohne tiefer in die Netzwerkprogrammierung einsteigen zumüssen. Der Aufbau von RMI ist auch in Abbildung 2 visualisiert. Der Programmierer erstellthier nur noch Klassen für Server und Client(s)und startet eine RMI Registry, bei welcher sichder Server anmeldet, sodass er von den Clients dort gefunden werden kann. Den restlichenVerwaltungsaufwand übernimmt RMI.Innerhalb unseres Schiffe-Versenken-Systems wird RMI verwendet, um es mehreren Clients(Beobachter, Spieler, KI, Bieter) zu ermöglichen, sich an einem Server anzumelden und dort aneiner Runde Schiffe-Versenken teilzunehmen, bzw. diese zu beobachten.
2.1.7 Beobachter
Mit Hilfe der Beobachter-Komponente kann eine aktuelle Runde Schiffe-Versenken angezeigtwerden. Die Besonderheit hierbei ist, dass nicht aktiv in das Spielgeschehen eingegriffenund das Spiel gesteuert werden kann. Dem Beobachter wird die Spielfläche der aktuellenRunde samt der vorher durch den Modellierer festgelegten Regeln gezeigt. Weiterhin bestehtdie Möglichkeit sich einen anderen Spieler als den gegenwärtigen anzeigen zu lassen. DieSpielfläche für den Beobachter wird mittels des Grapical Editing Frameworks (GEF) visualisiert.Allgemein basiert die Komponente auf der Rich Client Platform (RCP) und wird als Eclipse-Plug-in implementiert.
4
2.1 Architektur
2.1.8 Modellierer
Durch den Spiel-Modellierer können Spielflächen modelliert werden. Ebenfalls ist es möglicheine Spielkonfiguration zu erstellen, welche vor Beginn eines Spiels durch den Server geladenwird. Die Spielkonfiguration beinhaltet in unserem Schiffe-Versenken-System sowohl dieGröße als auch die Form der Spielfläche und die genauen Koordinaten der Inseln. Weiterhinbestimmt man mit dem Modellierer die zur Verfügung stehenden Schiffe und die Auswahl vonSonderregeln. Die Visualisierung der Spielflächen wird mit dem Graphical Editing Framework(GEF)und die Ausgabe des Spiel-Modellierers mittels des Eclipse Modeling Framework (EMF)realisiert.
2.1.9 KI
Die KI (Künstliche Intelligenz) kann innerhalb eines Schiffe-Versenken-System gegen anderemenschliche Spieler als Computergegner oder gegen andere Computergegner Schiffe-Versenkenspielen. Ihre wesentlichen Funktionen sind das Schiffe setzen zu Beginn eines Spiels und dasVersenken von gegnerischen Schiffen während des Spielverlaufs. Zusätzliche stellt die KI zuBeginn eines jeden Spiels die erforderliche Verbindung mit dem Server her.
5
2 Analyse
2.1.10 Komponentendiagramm
Wir entwickeln für unsere Software drei Komponenten. Diese Komponenten bestehen wieder-um aus kleineren zum Teil schon bestehenden Komponenten (z.B. RMI). Der ViewerClient(de.itanic.viewerclient) besteht aus den drei Komponenten RMI, Rulesview und Board. RMIdient zur Kommunikation mit dem Server, Rulesview enthält die Spielregeln der aktuellenRunde und Board stellt die Spielfläche dar. Der KIClient besteht ebenfalls aus 3 Komponenten.Er enthält wie der ViewerClient die Komponente RMI, dazu Shipsetting und Move. RMI dientwie beim ViewerClient zur Kommunikation mit dem Server, Shipsetting dient zum Setzen derSchiffe und Move ist für die Angriffe zuständig. Der Modeler besteht aus der vom ViewerClientbekannten Komponente Rulesview, ebenfalls enthält es die Gameconfig und den Mapeditor. DieGameconfig-Komponente dient zum Anlegen/Aufrufen der .gameconfig Dateien, der Mapeditorstellt eine Oberfläche zur Verfügung, in der die Spieleinstellungen eingestellt werden können.
Schiffe-Versenken-System
<<component>>de.itanic.modeler
<<component>>de.itanic.kiclient
<<component>>de.itanic.viewerclient
<<component>>de.itanic.modeler.mapeditor
<<component>>de.itanic.modeler.rulesview
<<component>>de.itanic.kiclient.rmi
<<component>>de.itanic.viewerclient.rmi
<<component>>de.itanic.kiclient.shipsetting
<<component>>de.itanic.viewerclient.board
<<component>>de.itanic.viewerclient.rulesview
<<component>>de.itanic.modeler.gameconfig
<<component>>de.itanic.kiclient.move
Abbildung 3: Komponentendiagramm: Übersicht des Gesamtsystems
6
2.2 Interaktion zwischen den Komponenten
2.2 Interaktion zwischen den Komponenten
In Abbildung 4 ist ein Sequenzdiagramm für einen beispielhaften Spielablauf dargestellt.Hierbei treten zwei KI-Clients gegeneinander an. Zu Beginn kann der Benutzer den Serverund den Modellierer starten. Im Modellierer kann er anschließend eine Spielkonfigurationenerstellen und diese als Datei im Dateisystem speichern. Nach dem Start des KI und Viewer-Clients können sich beide am Server registrieren. Vom Server wird anschließend der Namedes KI-Clients erfragt. Nun kann der Benutzer am Server eine Spielkonfiguration auswählen,welche der Server dann aus dem Dateisystem ausliest. Im Anschluss zeigt der Server dieregistrierten Clients an. Der Benutzer kann daraufhin Clients für eine Runde auswählen und derServer fügt die Client dann der Runde hinzu. Anschließend kann der Benutzer am Server dieRunde starten, welche dieser dann initialisiert. Hierüber informiert der Server alle beteiligtenClients, wobei den nicht-passiven Clients eine ID und ihre Gegner mitgeteilt werden. DesWeiteren fordert der Server die Clients auf, ihre Schiffe auf der Spielfläche anzuordnen, undinformiert die passiven Mitglieder über das Beenden des Anordnens. Jetzt beginnt die Rundeund der Server fordert den ersten teilnehmenden Client auf einen Angriff auszuführen. Wennder Client die Daten des Angriffs zurückgegeben hat, informiert der Server die angemeldetenViewer-Clients. Dies wiederholt sich so lange bis ein Client die Runde gewonnen hat. ZumSchluss informiert der Server die KI-Clients und Viewer-Clients wer gewonnen hat und dieRunde ist beendet.
7
2 Analyse
Beobachter KI Server DateiSystem Modellierer
start()
start()
start() save(x.gameconfig)
register()
getName(): String
name
choseConfig(x)loadConfig(x)
x.gameconfig
showClients()
start()
choseClients()
addPlayer()
register()
startRound()gameStarted(x.gameconfig)
gameStarted(x.gameconfig)
setPlayer(int)
announceOpponents(name[])
arrangeShips()
arrangementFinished()
makeAttack(): IAttack
attack
attackPerformed(): IAttack, AttackResult
attack, result
announceWinner(): PlayerID
announceWinner(): PlayerID
createConfig()
X XX
X
startRound()
loop
<<component>>de.upb.swt.swtpra2012.server
<<component>>Dateisystem
<<component>>de.itanic.modeler
<<component>>de.itanic.kiclient
<<component>>de.itanic.viewerclient
save()
Abbildung 4: Sequenzdiagramm
8
2.3 Komponentenschnittstellen
2.3 Komponentenschnittstellen
<<component>>org.eclipse.gef
Schiffe-Versenken-System
<<component>>de.itanic.Modeler
<<component>>de.itanic.KiClient IServer
<<component>>de.itanic.ViewerClient
<<component>>Dateisystem
<<component>>de.upb.swt.swtpra2012.Server *.gameconfig
IServer
IViewerClient
<<component>>java.rmi
IPlayerClient
Abbildung 5: Komponentendiagramm: Übersicht des Gesamtsystems
Server
Die Server-Komponente bietet das Interface IServer an. Dieses ermöglicht es den Clients sichauf dem Server zu registrieren und wieder abzumelden. Weiterhin werden die Methoden derInterfaces IClient und IViewer in jeder Runde durch den Server aufgerufen. Zusätzlich wird dieSpielkonfiguration welche als Datei vorliegt und vom Modellierer erstellt worden ist geladen.
Modeler
Die Modeler-Komponente selbst bietet bzw. nutzt keine der verfügbaren Interfaces. Die Aufgabebesteht darin eine Datei zu erstellen und zu speichern, die die Spielkonfiguration enthält. Diesewird wie in der Server-Komponente beschrieben vom Server angefordert.
9
2 Analyse
ViewerClient
Die ViewerClient-Komponente ruft Methoden des IServer-Interfaces auf, um sich an einemServer an- und wieder abzumelden. Außerdem wird das IViewerClient-Interface implementiert.Hier wird über die verschiedenen Statusänderungen des Spiels informiert. So werden demViewerClient über diese Schnittstelle der Spielbeginn, die Angriffe, aktuelle Runden-Detailsund auch wichtige Statusänderungen des Spiels übertragen.
KIClient
Die KI-Komponente meldet sich über das IServer-Interface an einen Server an und wieder ab.Zur Sicherstellung eines korrekten Spielablaufs implementiert die KIClient-Komponente nochdas IPlayerClient-Interface. Das IPlayerClient-Interface teilt dem Client z.B. mit das er an derReihe ist und einen Angriff starten darf oder seine Schiffe platzieren soll.
Interfaces
Die folgende Grafik bildet die für den Modellierer, den Beobachter und die KI notwendigenvorgegebenen Schnittstellen ab.
Abbildung 6: Interfaces
• IAttackIAttack ist das Interface welches Information über die Angriffe bereitstellt. Es werdenMethoden zur Verfügung gestellt um die Position, den Angreifer und den Typ des Angriffszu erfahren.
10
2.3 Komponentenschnittstellen
• IPositionDas IPosition-Interface gibt Auskunft über die Positionsdaten auf der Spielfläche füreinzelne Felder.
• IShipIShip verwendet die Positionsdaten aus IPosition um Schiffe zu lokalisieren. Außerdemkann man mittels der Methode getShipType() erfahren um welchen Schiffstyp es sichhandelt.
• IServerIServer ist das Bindeglied zwischen den Clients und dem Server. Über das IServer-Interface können sich die Clients an einem Server an- und wieder abmelden.
• IClientDas IClient-Interface dient zur Übermittlung des Spielbeginns, der Angriffe, der aktuellenRunden-Details und wichtigen Statusänderungen des Spiels. Es wird z.B. der Gewinnerverkündet oder mitgeteilt, ob ein Schiff bereits gesunken ist.
• IPlayerClientDas Interface IPlayerClient erweitert das IClient Interface. Die Spieler-Clients imple-mentieren dieses Interface. Daher hat es neben den Methoden die das Interface IClientanbietet auch spielerspezifische Methoden.
• IViewerClientDas Interface IViewerClient erweitert ebenfalls das IClient Interface. Die ViewerClient-Komponente implementiert dieses Interface. Durch die zusätzliche Methode arrangement-Finished wird die ViewerClient-Komponete informiert, wenn die Spieler ihre Schiffegesetzt haben und bekommt diese als Parameter in Form einer Liste von IShip-Objektenübergeben.
11
3 Entwurf
3 Entwurf
Im Entwurf sollen alle wichtigen Implementierungsentscheidungen getroffen werden. Hierwird der Übergang vom Ist-Zustand (Analyse) in den Soll-Zustand dargestellt. Es soll die in derAnalyse entwickelte Struktur weiter verfeinert und eine vollständige Struktur- und Verhaltensbe-schreibung der einzelnen Komponenten entwickelt werden. Erst soll die Architektur verfeinertwerden, woraufhin dann die einzelnen Komponenten näher erläutert werden. Abschließendwird das Verhalten für die wichtigsten Komponenten das Verhalten beschrieben.
3.1 Modellierer
In diesem Abschnitt wird die Modellierer-Komponente verfeinert und die Struktur nähererläutert.
3.1.1 Verfeinerung der Architektur
de.itanic.modeler: Pakete
de.itanic.modeler.controller
de.itanic.modeler.figurede.itanic.modeler.model
de.itanic.modeler.mapeditor
de.itanic.modeler.rulesview
de.itanic.modeler.save
Abbildung 7: Paketdiagramm Modellierer
In Abbildung 7 ist die Struktur der Pakete des Modellierers dargestellt. Genauere Darstel-lungen mit den einzelnen Klassen sind in Abschnitt 3.2 zu finden. Wie oben zu sehen bestehtder Modellierer aus 6 Paketen im Namensraum de.itanic.modeler (exklusive externer Pakete).Die drei Pakete model (Model), figure (View) und controller (Controller) werden durch dasvon der GEF-Komponente vorgeschriebene MVC-Konzept, auf das auch schon in Kaptitel2.1.3 näher eingegangen wird, zur Darstellung und Verwaltung der Grafikoberfläche umgesetzt.Hierbei greift der Controller auf die View und das Model zu. Der Controller überwacht undverändert das Model und gibt die Änderungen, die die View betreffen weiter. Zur Umsetzungder konfigurierbaren Spielfläche nutzt das Paket mapeditor den Controller. Zum Speichern
12
3.1 Modellierer
der Variationsregeln nutzt das Paket rulesview das Model. Das save Paket erstellt aus demEMF-Model im model Paket eine Datei und schreibt diese ins Dateisystem. Außerdem kanndas save Paket Dateien lesen und daraus das interne Modell erstellen.
3.1.2 Struktur der Komponente
In Abbildung 8 wurde die Paketstruktur des Namensraums de.itanic.modeler weiter aufge-schlüsselt.Das (de.itanic.modeler.)save Paket enthält eine Klasse, welche das Laden und Speichern vonSpielkonfigurationen ermöglicht. Dazu nutzt sie die von EMF bereitgestellten Methoden. DieseKlasse hat somit eine Referenz auf die zentrale Klasse GameConfiguration des model Paketes.Das rulesview Paket besteht ebenfalls aus genau einer Klasse, welche durch Interaktion desBenutzers die Variationsregeln in der Klasse RuleConfig des model Paketes festlegt. DieseKlasse ist eine Unterklasse von Viewpart aus dem org.eclipse.ui.part Paket. Die Klasse wirdsomit als View-Extensionpoint in die RPC-Anwendung eingebettet. Dies wird in der Dateiplugin.xml eingestellt.Das model Paket bildet die vollständige Spielkonfiguration mit der Hauptklasse GameConfigu-ration ab, um aus diesem Modell später die Konfiguration zu speichern. Von dieser Klasse aussind alle Elemente der Spielkonfiguration zu lesen. Die Spielkonfiguration besteht aus Angabenzu den Variationsregeln in der Klasse RuleConfig, sowie dem Aufbau der Spielfläche und denAnzahl Schiffen, die jeder Spieler platzieren kann. Das Model wurde als EMF-Modell von demAuftraggeber zur Verfügung gestellt und wird unmodifiziert genutzt, um die Kompatibilitätzu der Server-Komponente, die das Modell als XML wieder einließt, zu gewährleisten. Derinhaltliche Aufbau und die daraus resultierenden Objekte orientieren sich an der Beispieldateidefault.gameconfig, die ebenfalls vom Auftraggeber zur Verfügung gestellt wurde.Das Paket controller verwaltet die internen Abläufe des Spielflächeneditors, insbesondere ver-waltet es die Klassen Field aus model und FieldNode aus figure. Initiiert wird die Komponenteüber die MapEditorPartFactory, die über das FactoryPattern die benötigten EditParts zu demmodel Paket erstellt. Die EditPart-Klassen haben eine Beziehung zu den Modelklassen umdiese bei Eingaben des Benutzers zu ändern und bei gegebenen Änderungen am Model dies derView mitzuteilen.Das Paket figure stellt nun die visuelle Spezifikation der Felder in den Klassen FieldNodeund FieldRectFigure dar. FieldNode entspricht einen Feld und benutzt als Zeichenelement dieFieldRectFigure-Klasse um die Felder zu zeichnen. Über den Controller wird FieldNode nurmit dem für das Zeichnen der Spielfläche relevanten Informationen versorgt. Somit ist eineklare Trennung zwischen Datenhaltung und Datendarstellung möglichEingebettet werden die drei MVC-Pakete in einem MapEditor. Der MapEditor ist ein Editor-Extensionpoint der Rich Client Plattform der eclipse-Umgebung. Die MapEditor-Klasse bietetdie Basis für ein Draw2D-Canvas in dem die GEF-Umgebung geladen wird. Da jede Editor-Komponente mit einer Datei assoziiert werden muss, wird die File-Klasse erstellt, die zurInitialisierung genutzt wird.
13
3 Entwurf
de
.ita
nic
.mo
de
ler:
Kla
sse
n
de
.ita
nic
.mo
de
ler.
co
ntr
olle
r
de
.ita
nic
.mo
de
ler.
fig
ure
de.ita
nic
.mo
de
ler.
mo
de
l
de
.ita
nic
.mo
de
ler.
ma
pe
dit
or
de
.ita
nic
.mo
de
ler.
rule
sv
iew
de
.ita
nic
.mo
de
ler.
sa
ve
11
◄re
ads
11
dra
ws►
Fie
ldN
od
e
-x:i
nt
-y:i
nt
+F
ield
No
de
(x:i
nt,
y:i
nt)
:Fie
ldN
od
e
Fie
ldR
ec
tFig
ure
-ty
pe
:Fe
ldT
yp
e
+s
etT
yp
e(F
ield
Ty
pe
):v
oid
+p
ain
t(G
rap
hic
s):
vo
id
Ma
pE
dit
or
-ty
pe
:Fe
ldT
yp
e
+re
fre
sh
():v
oid
+s
etI
np
ut(
e:I
Ed
ito
rIn
pu
t):v
oid
File
-id
: in
t
+e
xis
ts()
:bo
ole
an
+g
etA
da
pte
r(C
las
s):
Ob
jec
t
+h
as
hC
od
e()
:in
t
Ma
pE
dit
Pa
rtF
ac
tory
+c
rea
teE
dit
Pa
rt(e
:Ed
itp
art
,o:O
bje
ct)
Fie
ldE
dit
Pa
rt
+is
Se
lec
tab
le()
:bo
ole
an
#c
rea
teE
dit
Po
lic
ies
():v
oid
#c
rea
teF
igu
re()
:IF
igu
re
#re
fre
sh
Vis
ua
ls()
:vo
id
Are
aE
dit
Pa
rt
#c
rea
teE
dit
Po
lic
ies
():v
oid
#c
rea
teF
igu
re()
:IF
igu
re
#g
etM
od
elC
hild
ren
():L
ist
1
1
crea
tes►
1
1…
*
crea
tes►
Va
ria
tio
nR
ule
sV
iew
-cm
bx
Ax
is:C
om
bo
-cm
by
Ax
is:C
om
bo
-co
un
tBa
ttle
sh
ip:C
om
bo
bo
x
-co
un
tCru
ise
r:C
om
bo
bo
x
-co
un
tDe
str
oy
er:
Co
mb
ob
ox
-co
un
tSu
bm
ari
ne
:Co
mb
ob
ox
-cb
xC
ollis
ion
:Bu
tto
n
-cb
xIs
lan
ds
:Bu
tto
n
-cb
xS
up
erw
ea
po
n:B
utt
on
-cb
xM
ine
:Bu
tto
n
-rd
b1
hit
:Bu
tto
n
-rd
bT
illw
ate
r:B
utt
on
-rd
bT
hre
es
ho
ts:B
utt
on
-rd
bS
ls:B
utt
on
+c
rea
teP
art
Co
ntr
ol(
c:C
om
po
sit
e):
vo
id
File
Sa
ve
r
+F
ile
Sa
ve
r(g
:Ga
me
Co
nfi
gu
rati
on
)
+s
av
eF
ile
()
+lo
ad
File
()
Are
a
Isla
nd
Isla
nd
Fie
ldW
ate
rFie
ld
Fie
ld
x_
Po
s:i
nt
y_
Po
s:i
nt
Ga
me
Co
nfi
gu
art
ion
Min
e
Sh
ip
Ba
ttle
sh
ipC
ruis
er
De
str
oy
er
Su
bm
ari
ne
Ru
leC
on
fig
allo
wA
djo
inin
gS
hip
s:
bo
ole
an
allo
wA
tBo
rde
r: b
oo
lea
n
att
ac
kR
ule
: A
tta
ck
Ru
le
sp
ec
ialW
ea
po
n:
bo
ole
an
isla
nd fi
eld
s
0..
*
10..
*is
lan
ds
1area
0..
*m
ines
0..
*sh
ips
0..
1fi
eld
fiel
ds
0..
*
1
rule
Co
nfi
g
1
1
mo
dif
icat
es►
1
1
de
fin
es►
11 con
tro
ls►
1
1Is
Par
ent
of►
0..
*fi
eld
s 1
1
Ch
eck fo
r ch
an
ge
s ◄
1
1
Ch
eck fo
r ch
an
ge
s ◄
Abbildung 8: Klassendiagramm Modellierer
14
3.1 Modellierer
3.1.3 Abläufe innerhalb der Komponente
de.upb.swt.swtpra2012.serverde.itanic.modeler
*.gameconfig
save load
Abbildung 9: Datenfluss Modellierer - Server
Der Ablauf im Modellierer ist im Vergleich zu den anderen Komponenten nicht durch Sequen-tialität geprägt. Wie in Abbildung 9 dargestellt, kann der Benutzer den Modellierer starten undeine Spielkonfiguration, bestehend aus der gewünschten Spielfläche und den Variationsregeln,erstellen und als XML-Datei speichern. Diese Datei kann anschließend vom Server geladenwerden, um die Spielkonfiguration auf eine Runde Schiffe-Versenken anzuwenden.
15
3 Entwurf
3.2 Beobachter
In diesem Abschnitt wird die Beobachter-Komponente verfeinert und die Struktur näher erläu-tert.
3.2.1 Verfeinerung der Architektur
de.itanic.viewerclient: Pakete
de.itanic.viewerclient.controller
de.itanic.viewerclient.figurede.itanic.viewerclient.model
de.itanic.viewerclient.mapeditor
de.itanic.viewerclient.rulesview
de.itanic.viewerclient.viewerclient
Abbildung 10: Paketdiagramm Beobachter
Abbildung 10 zeigt eine grobe Einteilung der zu entwickelnden Pakete für den Beobachter.Eine detailliertere Aufschlüsselung der einzelnen Pakete ist in Abbildung 11 zu finden. DerBeobachter besteht insgesamt aus 6 Paketen exklusive externer Pakete wie GEF- und Eclipse-Pakete. Das von der GEF-Komponente vorgeschriebene MVC-Konzept wird mittels der dreiPakete model (Model), figure (View) und controller (Controller) analog zum Modellierer fürdie Darstellung und Verwaltung der Grafikoberfläche verwendet. Die Anzeige der festgelegtenRegeln wird im Paket rulesview behandelt. Aufgabe des Pakets viewerclient besteht darinAktualisierungen des Spielbeginns, der Angriffe, der aktuellen Runden-Details und wichtigenStatusänderungen des Spiels an das Paket MapView weiterzugeben.
3.2.2 Struktur der Komponente
Es folgt nun eine detailliertere Beschreibung der einzelnen Pakete für den Beobachter ausAbbildung 10.Das rulesview Paket besteht aus zwei Klasse, wobei die Klasse RulesView zum Start desBeobachter-Plug-ins die mitgeteilten Regeln in der GUI darstellt und die Klasse Penaltiesverwaltet die vom Client begangenen Regelverstöße. Die Regeln werden in dem Paket viewer-client durch die einzige enthaltene Klasse ViewerClient mit Hilfe der Methode gameStarted()
16
3.2 Beobachter
mitgeteilt. Die Klasse ViewerClient enthält Methoden, die vom Server aufgerufen werden umdem Client wichtige Änderungen im Spiel mitzuteilen. Das Paket mapview enthält ebenfallsnur eine Klasse. MapView empfängt die Befehle der ViewerClient Klasse und visualisiert dieVeränderungen auf der Spielfläche. Das model Paket bildet die zu visualisierenden Felder derSpielfläche ab. In der Klasse Area werden die Beziehungen unter den Feldern gespeichert. Inder Klasse Field werden Eigenschaften über die einzelnen Felder gespeichert. Felder habeneinen Typ (Island, Water, Nothing, Ship). Ship stellt ein Teil eines Schiffes (Shippart) auf derSpielfläche dar. Außerdem werden in Shipparts die Schiffe weiterhin unterteilt in Submarine,Destroyer, Battleship und Cruiser. Charakterisiernd für ein Shippart ist zusätzlich die Stelle(partOfShip) des Shipparts im Schiff. Die Pakete controller und figure verwalten identisch wiebeim Modellierer. Die zusätzlichen Objekte wie Minen oder Schiffe bildet ebenfalls die KlasseFieldNode ab. Das Zeichnen wird mit Hilfe der FieldRectFigure-Klasse realisiert. Eingebettetwerden die drei MVC-Pakete in einem MapViewer. Der MapViewer ist ein Extensionpointder Rich Client Plattform der eclipse-Umgebung. Die MapViewer-Klasse bietet ähnlich wiebeim Modellierer bei der MapEditor-Klasse die Basis für ein Draw2D-Canvas in dem dieGEF-Umgebung geladen wird.
17
3 Entwurf
de
.ita
nic
.vie
we
rclie
nt:
Pak
ete
de
.ita
nic
.vie
we
rclie
nt.
mo
de
l
de
.ita
nic
.vie
we
rclie
nt.
ma
pv
iew
de
.ita
nic
.vie
we
rclie
nt.
rule
sv
iew
de
.ita
nic
.vie
we
rclie
nt.
vie
we
rclie
nt
Vie
we
rClie
nt
-pla
ye
r: P
lay
erI
D
+ a
tta
ck
Pe
rfo
rme
d (
att
ac
k:
IAtt
ac
k,
res
ult
: A
tta
ck
Re
su
lt)
+ s
hip
Su
nk
(s
hip
: IS
hip
)
+ g
am
eS
tart
ed
(a
rea
: in
t[],
ru
les
: in
t[])
+ g
am
eS
tart
ed
(a
rea
: in
t[],
ru
les
:
int[
]>,
att
ac
ks
: L
ist<
IPo
sit
ion
>,
sh
ips:
Lis
t<IS
hip
>)
+ g
am
eS
tate
Ch
an
ge
d (
ga
me
Sta
te:
Ga
me
Sta
te)
+ r
ou
nd
Sta
teC
ha
ng
ed
(ro
un
dS
tate
:
Ro
un
dS
tate
,
pla
ye
r: P
lay
erI
D)
+ a
nn
ou
nc
eW
inn
er(
pla
ye
r: P
lay
erI
D)
+ g
etN
am
e (
): S
trin
g
+ p
os
itio
nD
es
tro
ye
dB
yM
ine(p
os:
IPo
sit
ion
)
+ a
rra
ng
em
en
tFin
ish
ed
(sh
ips:
Lis
t<IS
hip
>,
pla
ye
r: P
lay
erI
D)
Are
a
Fie
ld
-x_
Po
s:i
nt
-y_
Po
s:i
nt
-ty
pe
:Str
ing
{is
lan
d,
wa
ter,
no
thin
g,
sh
ip}
-is
Att
ac
ke
d:b
oo
lea
n
-sh
ip:S
hip
pa
rt
Sh
ipp
art
-pa
rtO
fSh
ip:i
nt
{0,1
,2,3
,4}
-ty
pe
:Fie
ldty
pe
{su
bm
ari
ne
, d
es
tro
ye
r,
ba
ttle
sh
ip,
cru
ise
r}
-is
ve
rtik
al:
bo
ole
an
0..
*fi
eld
s
Ma
pV
iew
+re
fre
sh
():v
oid
Ru
les
Vie
w
+s
etR
ule
s(r
ule
s:i
nt[
])
+s
etX
an
dY
(x:i
nt,
y:i
nt)
is►
de.i
tan
ic.v
iew
erc
lie
nt.
co
ntr
olle
r
de
.ita
nic
.vie
we
rclie
nt.
fig
ure
11
dra
ws►
Fie
ldN
od
e
-x:i
nt
-y:i
nt
+F
ield
No
de(x
:in
t,y
:in
t):F
ield
No
de
Fie
ldR
ec
tFig
ure
-ty
pe
:Fie
ldT
yp
e
+s
etT
yp
e(F
ield
Ty
pe
):v
oid
+p
ain
t(G
rap
hic
s):
vo
id
Ma
pE
dit
Pa
rtF
ac
tory
+c
rea
teE
dit
Pa
rt(e
:Ed
itp
art
,o:O
bje
ct)
Fie
ldE
dit
Pa
rt
+c
rea
teF
ield
s(a
rea
: in
t[])
:vo
id
#c
rea
teE
dit
Po
lic
ies
():v
oid
#c
rea
teF
igu
re()
:IF
igu
re
#re
fre
sh
Vis
ua
ls()
:vo
id
Are
aE
dit
Pa
rt
#c
rea
teE
dit
Po
lic
ies
():v
oid
#c
rea
teF
igu
re()
:IF
igu
re
#g
etM
od
elC
hild
ren
():L
ist
1
1
crea
tes►
1
1…
*
crea
tes►
11 con
tro
ls►
1..
*
1
1
1
sho
ws ►
sho
ws ►
Is P
aren
t o
f ►
1
1
Ch
eck
for
chan
ges ◄
1
1
11
Pe
na
ltie
s
+s
etP
en
alt
y(p
lay
er:
Pla
ye
rID
)
Abbildung 11: Klassendiagramm Beobachter18
3.2 Beobachter
3.2.3 Abläufe innerhalb der Komponente
Im Analyse-Sequenzdiagramm 12 wird ein exemplarischer sequenzieller Ablauf in einemSchiffe-Versenken-System dargestellt dabei möchte ein Spieler ein Spiel beobachten. Zu Anfangstellt der Benutzer über die Oberfläche die Verbindung mit dem Server her. Der ViewerClientmeldet den Viewer beim Server an. Der Server fragt anschließend den ViewerClient nachseinem Namen. Diese Anfrage wird mit der Rückgabe “ITanic-Beobachter” abgeschlossen.Sobald ein Spiel gestartet worden ist, werden die Spielfläche wie auch die Spielregeln demViewerClient übergeben. Nachdem alle Spieler ihre Schiffe aufgestellt haben wird die MethodearrangementFinished aufgerufen, diese übergibt die aufgestellten Schiffe zusammen mit demdazugehörigen Spieler. Nach einer Aktualisierung auf Seiten des ViewerClients wird auf dieAusführung eines Angriffs durch einen der Spieler gewartet. Sobald dies geschehen ist werdenDaten über die ausgeführten Angriffe gespeichert. Optional kann es vorkommen, dass einSpieler eine Feldposition angegeben hat auf der sich eine Mine befindet. Über die MethodeshipSunk(ship) teilt der Server mit, dass ein Schiff gesunken ist. roundStateChanged undgameStateChanged teilen dem ViewerClient Änderungen während des Spielverlaufs mit. NachAbschluss eines Spiels verkündet der Server mit der Methode announceWinner den Gewinnerder aktuellen Runde. Selbstverständlich gibt es für den User die Möglichkeit sich vom Serverzu trennen. Dazu meldet sich der ViewerClient durch removeViewer vom Server ab. In unseremBeispiel erfolgt dies nach Ende des Spiels.
19
3 Entwurf
s: ServerStubp: ViewerClientUser
connectToServer(HostName)connectToServer(HostName)
addViewer(v)
:success
getName()
saveAttackResult(result)
disconnect()
uI: ViewerUI g: Model
attackPerformed(attack, result)
PositionDestroyedByMine()
shipSunk(ship)
removeViewer(client)
disconnect()
announceWinner(player)
XX X
:"ITanic-Beobachter"
refresh()
refresh()
gameStateChanged(gameState)
roundStateChanged(roundState)
arrangementFinished(ships, player)
refresh()
gameStarted(area, rules)
Abbildung 12: Analyse-Sequenzdiagramm Beobachter20
3.3 KI
3.3 KI
In diesem Abschnitt wird der KI-Client verfeinert und die Struktur näher erläutert.
3.3.1 Verfeinerung der Architektur
de.itanic.kiclient: Pakete
de.itanic.kiclient.move
de.itanic.kiclient.shipsetting
de.itanic.kiclient.controllerde.itanic.kiclient.rmi
Abbildung 13: Paketdiagramm KI
Die Abbildung 13 stellt eine grobe Struktur der zu entwickelnden KI Pakete dar. Diese Strukturwird im Abschnitt 3.2 genauer dargestellt und beschrieben. Die externen exklusiven KI Pakete(de.itanic.kiclient) setzen sich insgesamt aus 4 Paketen zusammen. Das Controller-Paketde.itanic.kiclient.controller kontrolliert das Paket de.itanic.kiclient.rmi und benötigt gleichzeitigdie Pakete de.itanic.kiclient.move und de.itanic.kiclient.shipsetting. Das Move-Paket wird dabeivom RMI-Paket genutzt um gezielt Angriffe ausüben zu können. Das Shiptsetting-Paket wirddagegen vom RMI-Paket benötigt um zu Beginn des Spiels die Schiffe zu platzieren.
3.3.2 Struktur der Komponente
Die Abbildung 14 gibt eine detaillierte Beschreibung der einzelnen Pakete für die KI. Das RMI-Paket enthält die Klassen PlayerClient, KIAttack und KIShip. Die Klasse PlayerClient erweitertdie Interfaces IPlayerClient und IClient. Daher dient die PlayerClient Klasse zur Übermittlungdes Spielbeginngs, der Angriffe, der aktuellen Rundendetails und wichtigen Statusänderungendes Spiels. Darüber hinaus bietet die PlayerClient Klasse durch die Erweiterung des IPlayer-Client Interfaces weiterer spielerspezifische Methoden wie z.B. arrangeShips oder setPlayer.Außerdem enthält das RMI-Paket die Klassen KIAttack und KIShip. Die Klasse KIAttackstellt Informationen über die Angriffe bereit und stellt Methoden zur Verfügung um die Positio-nen, die Angreifer und den Typ des Angriffs zu erfahren. Die KIShip Klasse verwendet die
21
3 Entwurf
Positionsdaten um Schiffe zu lokalisieren und dient ebenfalls der Schiffstyp-Erkennung. Dieletzte der zum RMI-Paket gehörenden Klassen ist die Connect Klasse, welche zur einmaligenVerbindung zum Server benötigt wird. Das Controller Paket enthält die Klassen PlayerUI undController. Die Controller Klasse dient als Hauptklasse der KI Pakete und ruft die gesamtenMethoden aller Klassen der KI Pakete auf. Die PlayerUI dient zur Benutzereingabe für denVerbindungsaufbau und -abbruch zu bestimmten Servern. Das Move Paket beinhaltet die KlasseShotControl, welche von der Klasse KIAttack benötigt wird um Angriffe ausführen zu könnenund Informationen an die Klasse PlayerClient liefert. Das Letzte der exklusiven KI Paketet istdas shipsetting Paket, welches aus der Klasse ShipControl besteht. Die Klasse ShipControldient der Klasse KIShip aus dem RMI-Paket um Schiffe zu platzieren und Formationen an denServer zu versenden.
22
3.3 KI
de
.ita
nic
.kic
lien
t: K
lass
en
de
.ita
nic
.kic
lie
nt.
co
ntr
olle
r
de
.ita
nic
.kic
lie
nt.
sh
ips
ett
ing
de
.ita
nic
.kic
lie
nt.
rmi
Sh
ipC
on
tro
l
-fie
ld:A
rra
y[i
nt]
-fo
rma
tio
n:A
rra
y [
int]
[in
t]
+s
etS
hip
s()
:vo
id
-co
mp
ute
Fo
rma
tio
n()
: v
oid
-se
nd
Se
ttin
gto
Se
rve
r():
bo
ole
an
co
nn
ec
t
+c
on
ne
ct(
):b
oo
lea
n
de.i
tan
ic.k
iclie
nt.
mo
ve
Sh
otC
on
tro
l
-fie
ld:A
rra
y[i
nt]
[in
t]
-sh
otp
os
itio
ns
:Arr
ay[i
nt]
[in
t]
+s
etT
arg
etF
ield
():
vo
id
-co
mp
ute
Ta
rge
tFie
ld()
: v
oid
-se
nd
Ta
rge
tFie
ldto
Se
rve
r():
bo
ole
an
+a
rra
ng
eS
hip
s()
:v
oid
+m
ak
eA
tta
ck
():
vo
id
+g
etS
hip
De
str
oy
ed
By
Min
e()
+s
etP
lay
er(
Pla
ye
rID
, in
t)
+g
etI
ns
tan
ce
():C
on
tro
lle
r
Co
ntr
olle
r
Pla
ye
rClie
nt
+a
tta
ck
Pe
rfo
rme
d (
IAtt
ac
k, A
tta
ck
Re
su
lt):
+s
hip
Su
nk(I
Sh
ip):
+g
am
eS
tart
ed
(in
t[],
in
t[])
+g
am
eS
tart
ed
(in
t[],
in
t[],
Lis
t<IP
os
itio
n>
,
Lis
t<IS
hip
>)
+g
am
eS
tate
Ch
an
ge
d(G
am
eS
tate
)
+ro
un
dS
tate
Ch
an
ge
d (
Ro
un
dS
tate
, P
lay
erI
D)
+a
nn
ou
nc
eW
inn
er(
Pla
ye
rID
)
+g
etN
am
e()
:Str
ing
+a
rra
ng
eS
hip
s (
): v
oid
+m
ak
eA
tta
ck
():
vo
id
+g
etP
os
itio
nD
es
tro
ye
d()
:
+s
etP
lay
er(
Pla
ye
rID
, in
t):
vo
id
+a
nn
ou
nc
eO
pp
on
en
ts(L
ist<
Pla
ye
rID
>)
: v
oid
KIA
tta
ck
+g
etP
os
itio
n (
):
+g
etA
tta
ck
er
():
Pla
ye
rID
KIS
hip
+g
etP
os
itio
ns
():
+g
etS
hip
Ty
pe
():
Sh
ipT
yp
e
Pla
ye
rUI
+c
on
ne
ct
(Ho
stN
am
e):
vo
id
+d
isc
on
ne
ct
():
vo
id
◄ c
on
tro
ls1
1
has
►1
1
1
1◄
nee
ds
1
1
◄ n
eed
s
◄ m
anag
es
con
nec
tio
n o
f1
1
1
0, *
*
1
◄ g
ets
info
rmat
ion
fro
m
◄ g
ets
info
rmat
ion
fro
m
1
1
1
1
*
1
Abbildung 14: Klassendiagramm KI
23
3 Entwurf
3.3.3 Abläufe innerhalb der Komponente
In Abbildung 15 ist dargestellt wie sich der KI-Client während eines Spielablaufs verhält. ZuAnfang verbindet der Nutzer manuell den KI-Client über eine Benutzeroberfläche mit demServer. Wurde die Verbindung erfolgreich hergestellt, kann der Server den Client zu einemSpiel hinzufügen. Beim Start des Spiels werden dem KI-Client die Größe der Spielfläche sowiedie Regeln übergeben und es wird eine Klasse Game erstellt, die das Spiel abspeichert. Nunwird den Spielern vom Server eine ID zugeteilt und bekanntgegeben wie lange ein Spielzugdauern darf. Anschließend werden zusätzlich die IDs der Spielgegner übergeben. Sind alleVoreinstellungen getroffen, gibt der Server dem KI-Client den Befehl seine Schiffe zu platzieren.Dieser übergibt die Positionen der Schiffe in einer Liste und speichert sie selbst noch einmal inder Klasse Game. Während des Spiels fordert der Server gemäß den Spielregeln den KI-Clientauf einen Angriff durchzuführen. Dieser gibt die Daten des anzugreifenden Feldes zurück underhält daraufhin vom Server das Ergebnis seines Angriffs und speichert es in der Klasse Game.Zusätzlich informiert der Server den Client wenn er ein Schiff komplett versenkt hat. Sindalle Schiffe eines Spielers versenkt, gibt der Server den Sieger bekannt. Anschließend gibt derBenutzer den Befehl die Verbindung des KI-Clients zum Server zu trennen, woraufhin auch derServer den KI-Client vom Spiel entfernt. Damit ist eine Partie Schiffe-Versenken beendet.
24
3.3 KI
s: ServerStubp: PlayerClientUser
connectToServer(HostName)connectToServer(HostName)
addPlayer(p)
:success
gameStarted(area, rules)
create()
:ships
:position
saveAttackResult(result)
disconnect()
saveArrangement(list)
uI: PlayerUI
g: Game
setPlayer(playerid, seconds)
announceOpponents(opponents)
arrangeShips()
makeAttack()
:attack
attackPerformed(attack, result)
getPositionDestroyedByMine()
shipSunk(ship)
removePlayer(client)disconnect()
announceWinner(player)
X
X X
Abbildung 15: Datenfluss innerhalb der KI
25
3 Entwurf
Ablauf der Schiffsaufstellung Unser Algorithmus versucht die Schiffe möglichst weitverteilt über das Spielfeld zu verteilen. Dazu erstellen wir ein Array mit allen Spielfeldernund weisen ihnen jeweils zu Anfang eine gleiche Punktzahl zu.(Siehe Abbildung 16 ). Zuerst
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
1010
101010
101010
10
Abbildung 16: Spielfeld mit Punktzahl vor der ersten Platzierung
ermitteln wir zufällig ob das erste Schiff waagerecht oder senkrecht aufgestellt wird und dannermitteln wir wieder zufällig eine Startposition. Nun versuchen wir das Schiff zu platzieren.Sollte die Position ungültig sein, ermitteln wir eine neue Startposition. Nachdem das Schiffgesetzt ist(Siehe Abbildung 17 Rote Markierung) werden alle Punktzahlen in der Nähe desSchiffes gesenkt. Die weiteren Schiffe setzen wir indem wir jeweils 3 zufällige Positionen
1010
101010
101010
10
1010
101010
101010
10
1010
101010
777
10
1010
10107
303
7
1010
1073
000
3
1010
1073
000
3
1010
1073
000
3
1010
1073
000
3
1010
1073
000
3
1010
10107
303
7
Abbildung 17: Spielfeld mit Punktzahl nach der ersten Platzierung
ermitteln, dann jeweils für waagerecht und senkrecht die Punkte addieren auf den das Schiffstehen könnte und das Schiff dann auf die Position mit der höchsten Punktzahl stellen. Beigleicher Punktzahl gewinnt die erste Position. Sind alle Positionen ungültig ermitteln wir 3neue zufällige Positionen.Eine Position ist ungültig wenn sie entweder nicht auf dem Spielfeld liegt oder ihre Punktzahl0 beträgt. Inseln werden direkt mit der Punktzahl 0 erstellt.
26
3.3 KI
Ablauf des Angriffs Der KI-Client soll bei seinen Angriffen nach einem bestimmten Mustervorgehen, welches im Folgenden erläutert wird. Der erste Angriff geschieht zufällig und sollein beliebiges gültiges Feld treffen (Abbildung 18).
x
Abbildung 18: zufällige Angriffsauswahl des ersten Feldes
Danach wird im Hintergrund ein Muster erstellt, sodass die Angriffe zufällig dieses Musterabdecken. Das Muster, wie in Abbildung 19 zu sehen, entsteht durch Diagonalen die durch daserste angegriffene Feld laufen. Danach werden weitere Diagonalen erstellt, die jeweils um vierFelder nach rechts bzw. links verschoben werden. Nach Durchführung dieses Angriffsmusterswurden in jedem Fall alle Kreuzer und Schlachtschiffe entdeckt.
xxx
xxx
xxxxx
xx
x
xxxx
xx
xx
x
x
xxx
x
x x
x
x
x
x
x
Abbildung 19: Erstellung des Angriffsmusters
Sind bis dahin noch unentdeckte U-Boote und Zerstörer auf der Spielfläche, wird das Musterenger gezogen. In Abbildung
27
3 Entwurf
20 sieht man, dass das ursprüngliche Angriffsmuster durch die restlichen fehlenden Diagona-len ergänzt wird. Die noch nicht angegriffenen Felder des Musters werden nun auch zufällighintereinander angegriffen. So werden am Ende alle Schiffe des Gegners entdeckt sein.
xxx
xxx
xxxxx
xx
x
xxxx
xx
xx
x
x
xxx
x
x x
x
x
x
x
xx
xx
xx
xx x
x x
Abbildung 20: Verengung des Angriffsmusters
Tritt der Fall ein, dass ein Schiff getroffen wird, wird das Vorgehen nach dem oben beschrie-benen Angriffsmuster unterbrochen. Man versucht das Schiffe zu versenken indem man diehorizontal und vertikal angrenzenden Felder angreift (Abbildung 21). Ist das Schiff nochnicht versenkt, wird weiter in horizontaler bzw. vertikaler Richtung angegriffen bis das Schiffkomplett getroffen ist.
x
Abbildung 21: Vorgehen nach dem ein Schiff entdeckt wurde
28
3.3 KI
Bei der Regeleinstellung, dass Schiffe sich nicht berühren dürfen, kann man bestimmte Feldervom Angriff ausschließen (Abbildung 22). Da kein Schiff neben einem anderen liegt, mussman die Felder um das versenkte Schiff gar nicht mehr angreifen, da dort in jedem Fall Wasserist.
xx x
Abbildung 22: Regel: Schiffe dürfen sich nicht berühren
29
Abbildungsverzeichnis
1 GEF Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 32 RMI-Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Komponentendiagramm: Übersicht des Gesamtsystems . . . . . . . . . . . . 64 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Komponentendiagramm: Übersicht des Gesamtsystems . . . . . . . . . . . . 96 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Paketdiagramm Modellierer . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Klassendiagramm Modellierer . . . . . . . . . . . . . . . . . . . . . . . . . 149 Datenfluss Modellierer - Server . . . . . . . . . . . . . . . . . . . . . . . . . 1510 Paketdiagramm Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611 Klassendiagramm Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . 1812 Analyse-Sequenzdiagramm Beobachter . . . . . . . . . . . . . . . . . . . . 2013 Paketdiagramm KI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2114 Klassendiagramm KI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315 Datenfluss innerhalb der KI . . . . . . . . . . . . . . . . . . . . . . . . . . . 2516 Spielfeld mit Punktzahl vor der ersten Platzierung . . . . . . . . . . . . . . . 2617 Spielfeld mit Punktzahl nach der ersten Platzierung . . . . . . . . . . . . . . 2618 zufällige Angriffsauswahl des ersten Feldes . . . . . . . . . . . . . . . . . . 2719 Erstellung des Angriffsmusters . . . . . . . . . . . . . . . . . . . . . . . . . 2720 Verengung des Angriffsmusters . . . . . . . . . . . . . . . . . . . . . . . . . 2821 Vorgehen nach dem ein Schiff entdeckt wurde . . . . . . . . . . . . . . . . . 2822 Regel: Schiffe dürfen sich nicht berühren . . . . . . . . . . . . . . . . . . . 29
