|
|
|
|
|
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 |
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.
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 |
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:
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
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) |
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.
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)