Index

Überblick

Algorithmen

Anhang

Teil 2 von 4


3. Terminplan

Nr.

Datum

geplanter Terminplan

ausgeführter Terminplan

1

Mo 24.2.1997

Grundsatzdiskussion

Grundsatzdiskussion

2

Di 25.2.1997

Festlegung der Klassen

Festlegung der Klassen

3

Mi 26.2.1997

Grundgerüst des Klassen

Grundgerüst des Klassen

4

Do 27.2.1997

Strategie

Weitere Implementationsarbeiten

5

Fr 28.2.1997

Zusammenfügen und erste Tests

Strategie

6

Mo 03.3.1997

Optimierung

Zusammenfügen der Teile

7

Di 04.3.1997

Fehlersuche

Fehlersuche

8

Mi 05.3.1997

1. Öffentliche Version und öffentlicher Test

Teilweise Neuimplementation verschiedener Routinen, Dokumentation

9

Do 06.3.1997

Weitere Verbesserungen, Dokumentation

Finalisierung, erste größere Tests, Dokumentation

10

Fr 07.3.1997

D-Day: Final Release und Turnier

D-Day: Final Release und Turnier

11

So 09.3.1997

.

Fertigstellung der Dokumentation

 

4. Überblick

An den ersten beiden Tagen befaßten wir uns mit dem grundlegenden Konzept, das wir für unsere Implementation eines Player-Moduls verwenden wollten. Wir suchten nach einer Klassenaufteilung, die es zur Vereinfachung der Organisation ermöglicht in zwei kleineren Gruppen zu arbeiten. Die erste Gruppe (Max Larsson, Christoph Müller, Henrik Stürzebecher) sollte sich mit der Implementation eines Bewertungsalgorithmus beschäftigen und die grundlegenden Funktionen zur Verwaltung von Spielbretter zur Verfügung stellen. Die zweite Gruppe (Philipp Hahn, Jörg Treschau, Martin Girschick) war dann für die Schnittstelle zum Monitor-Vertreter und zur restlichen Außenwelt verantwortlich. Außerdem sollte von ihr der alpha-beta-Algorithmus implementiert werden, der den Spielbaum aufbaut.

Am dritten Tag begannen dann die zwei Gruppen mit der Entwicklung ihrer Teile. Da wir größtenteils Java-taugliche Rechner zu Hause vorzuweisen hatten, fand diese dort statt. Leider war dies aber mit einigen Problemen verbunden. Es war zum Beispiel nicht möglich die bereitgestellten Vertreter-Klassen für die Netzwerkschnittstelle zu verwenden, da diese Bibliotheken von Java verwendeten, die für Linux nicht verfügbar sind.

In den folgenden Tagen wurde dann an denn verschiedenen Teilen weitergearbeitet. Das Interface zu den anderen Modulen wurde an der TH weiterentwickelt, der Rest konnte größtenteils in Heimarbeit entstehen. Durch verschiedene Probleme (z.B. keine gemeinsamen freien Termine) verschob sich der vorab gewählte Zeitplan nach hinten.

Erst am Donnerstag der zweiten Woche ließen sich vollständige Integrationstests aller Teile verwirklichen. Daß diese aber dann ohne größere Komplikationen abliefen zeigt doch die gute Wahl der Schnittstellen zwischen den Teilen.

Am Freitag konnte sich das fertige Softwarpaket dann im Spielbetrieb mit den anderen Komponenten bewähren.

 

5. Aufgabenverteilung

Christoph Müller

Bewertungsalg., Spielbaum

Henrik Stürzebecher

Bewertungsalg., Spielbaum, Dokumentation

Jörg Treschau

Eingabeparser, Timing-Routinen, Newswatcher

Martin Girschick

Spielbaum, Organisation, Dokumentation

Max Larsson

Hashing, Liste, Bewertungsalg.

Philipp M. Hahn

Schnittstelle nach außen, Timing-Routinen, Newswatcher

6. Pflichtenheft

In diesem Abschnitt soll kurz dargstellt werden, welche Funktionalität in dieser Software enthalten sein soll.

Er ist unterteilt ist Forderungen und Wünsche.

Forderungen:

Wünsche:

 

7. Klassenstruktur

Java-Datei / Klasse

Beschreibung

List

abstrakte Klasse für generische Listen

MoveList

von List abgeleitete Klasse

EvalBoardList

von List abgeleitete Klasse für EvalBoards als Einträge

Node

abstrakte Klasse für Listeneinträge

MoveNode

von Node abgeleitete Klasse mit einem Zug als Daten

Board

von Node abgeleitete Klasse für das Reversi Brett (Abschnitt 11)

Smartboard

von Board abgeleitete Klasse mit erhöhter Funktionalität (Abschnitt 11)

EvalBoard

von Smartboard abgeleitete Klasse mit erhöhter Funktionalität (Abschnitt 11)

Player

Kommunikation mit dem Monitor-Vertreter (Abschnitt 9)

PlayerTree

Implementation des alpha-beta-Algorithmus (Abschnitt 12)

 

java.lang.Object
   |
   +----gdi1.project.player.GSPORD.Node
   |     |
   |     +----gdi1.project.player.GSPORD.MoveNode
   |     |
   |     +----gdi1.project.player.GSPORD.Board
   |     |
   |     +----gdi1.project.player.GSPORD.SmartBoard
   |     |
   |     +----gdi1.project.player.GSPORD.EvalBoard
   |
   +----gdi1.project.player.GSPORD.List
   |
   +----gdi1.project.player.GSPORD.MoveList
   |
   +----gdi1.project.player.GSPORD.EvalBoardList

8. interne Schnittstelle

Als interne Schnittstelle bezeichneten wir während des Projektes diejenigen Klassen (oder nur diejenigen ihrer Funktionalitäten), die die Bewertungsgruppe zu erstellen hatte, die jedoch von der Spielbaumgruppe benötigt wurden. Bei dieser Schnittstelle kam es auf zwei Dinge an: Die Schnittstelle sollte möglichst kurz sein (also wenige Funktionen umfassen) und ausserdem einen möglichst schnellen Zugriff auf verschiedene Instanzen ermöglichen. Dazu hat sich das objektorientierte Prinzip bewährt. Zu Verfügung gestellt wurde eine Klasse Evalboard, deren Instanzen im folgenden kurz skizziert werden:

Instanz

Bedeutung

EvalBoard.eval

statische Bewertung der Stellung auf dem Spielfeld (Für schnellen Zugriff in einer Instanzenvariable)

EvalBoard.move

Zug, durch den dieser Spielstand erreicht worden ist (Der zu dem im Baum am besten bewerteten Spielbrett der ersten Ebene gehörende Zug wird zurückgeliefert!)

EvalBoard.toGameStatus()

belegt ein gamestatus.board mit dem Feld des EvalBoard (zur Ausgabe durch ein GUI)

EvalBoard.resultBoards()

liefert einen Verweis auf das erste Element einer Liste der von dem aktüllen Board durch legale Züge zu erreichenden EvalBoards. Die Liste ist bewertet und geordnet.

EvalBoard.next()

Verweis auf das nächste Element einer EvalBoardList (Siehe auch resultBoards)

außerdem einen Konstruktor zur Erzeugung eines Evalboards aus einem Gamestatus.

Die Internae der Evalboards und die von EvalBoard benutzten anderen Klassen werden von dem übergeordneten Spielbaum nicht benötigt und sind gekapselt, insoweit dies nicht die Debug-Möglichkeiten einschränkt.

 

9. Schnittstelle nach außen (von Philipp M. Hahn)

Aufgaben: Innerhalb der Gruppe war ich zuständig für die Implementierung der Schnittstellen zu den anderen Modulen wie Monitorvertreter und Gui, sowie die Programmierung der Player-Klasse, so daß die anderen Module mit den geforderten Schnittstellen zusammenarbeiten konnten. Als zentrales Modul des Players fungierte die Player-Klasse als eine Klasse, die die gesamte Kommunikation mit der Außenwelt wie Netzwerk und Benutzer abwickelt. In diesen Zusammenhang dient die Klasse Player zur Initialisierung und zum Aufruf der anderen Klassen, die dann den eigentlich intelligenten Spieler zur Verfügung stellen. Da die Verbindungen zu anderen Teilen des Projektes sehr fehleranfällig sind, war es auch meine Aufgabe, Routinen zur Fehlersuche und zur Anzeige von Status- und Zustandsmeldungen anzuzeigen. Schließlich und Endlich kümmerte ich mich auch um das Projektverzeichnis und um die Verwaltung der verschiedenen Versionen, wie sie im Laufe der zwei Wochen erstellt wurden.

Probleme: Wie gerade schon geschildert, hatte ich meistens mit der Anbindung unseres Spielers an die anderen Module zu tun. Viel Zeit und Arbeit verschwandt in der Fehlersuche, um den Spieler zum Laufen zu bringen. Vor allem die vielen unterschiedlichen Monitore und Guis machten die Arbeit nicht gerade leicht, denn oft waren die Komponenten nur teilweise, manchmal aber auch fehlerhaft implementiert. Rückfragen bei den verantwortlichen Gruppen brachten des öfteren leider auch keine Klärung, so daß lange nur mit der Sample-Gui und dem Sample-Monitor gearbeitet wurde. Leider waren auch diese nicht ganz fehlerfrei, so daß weitere Zeit in der Fehlersuche in fremden Modulen nötig wurde. Die Entwicklung des Projektes wollten wir anfangs unter Linux durchführen. Dies konnte jedoch leider nicht verwirklicht werden, da in der dortigen Version keine ObjektStreams implementiert waren, obwohl dies ebenfalls die Version 1.02 war, die auch im Aufgabenblatt vorausgesetzt wurde. Weitere Probleme traten mit Threads auf. So beendete sich ein Thread der AWT nicht von selbst und führte dazu, daß das Programm nicht ordnungsgemäß beendet werden konnte. In einer der Versionen nutzen wir Threads, um parallel zur Berechnung der Spielanalyse vorläufige Züge an den Monitor zu versenden. Dies konnte in der "endgültigen" Version dann aber leider nicht genutzt werden, da Thread teilweise zu wenig oder gar keine Rechenzeit bekamen. Während dem Turnier machten sich besonders die Verzögerungen der AWT bemerkbar, so daß teilweise durch Repaints das System so lange angehalten wurde, das die Zeit für den Spielzug um mehrere Sekunden überschritten wurde.

Positives: Das abschließende Turnier am Freitag fang ich persönlich sehr gut. Man konnte so das Ergebnis der zweiwöchigen Arbeit gut präsentieren und mit den anderen Entwicklern vergleichen. Die Idee für das Projekt, Reversi zu programmieren, fand ich auch recht nett.

Negatives: Leider hatten diese zwei Wochen auch ein paar dunkle Flecken: So waren die Zustände in den Rechnerpools manchmal sehr chaotisch und ein vernünftiges Arbeiten war nicht möglich, da die Rechenleistung oft so stark einbrach, daß für die Übersetzung des Programmes mehrere Minuten lang nichts geschah. Ein weiterer Punkt, der negativ auffiel, war die anfangs fehlerhafte Implementierung der Beispielklassen (Die Gui implementierte nicht das GuiInterface) und die Netzwerkfehler, die sporadisch auftraten und die Arbeit verzögerten.

Am Ende möchte ich nun Bilanz ziehen und sagen, daß es zwei schöne Wochen waren, die bestimmt noch lange in Erinnerung bleiben werden. (Philipp M. Hahn)

 

next...