Entwickler- dokumentation
Entwickler- dokumentation
Entwickler- dokumentation
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Entwickler</strong><strong>dokumentation</strong><br />
Onlinespieleportal<br />
Reversi – Gruppe 23<br />
Projekt Softwaretechnik<br />
WS 2008/09<br />
Uni Rostock<br />
Christian Eichner<br />
Nils Faupel<br />
Stefan Gladisch<br />
Martin Nyolt<br />
Cornelius Radicke<br />
Jonas Vetterick
Inhaltsverzeichnis<br />
1 Spielregeln ........................................................................................1<br />
1.1 Turnierregeln................................................................................2<br />
2 Klassenbeschreibungen........................................................................3<br />
2.1 Netzwerk-Klassen..........................................................................3<br />
2.1.1 Allgemeines............................................................................3<br />
2.1.2 NetworkThread-Klasse..............................................................3<br />
2.1.3 NetworkServer-Klasse..............................................................4<br />
2.1.4 ListenThread-Klasse.................................................................4<br />
2.2 Verwaltungsklassen........................................................................4<br />
2.2.1 Logic-Klasse............................................................................4<br />
2.2.2 ServerLogic-Klasse...................................................................4<br />
2.2.3 ClientLogic-Klasse....................................................................5<br />
2.2.4 Player-Klasse..........................................................................5<br />
2.2.5 Group-Klasse..........................................................................5<br />
2.2.6 Statistics-Klasse......................................................................5<br />
2.2.7 Game-Klasse...........................................................................6<br />
2.2.8 Reversi-Klasse.........................................................................6<br />
2.2.9 Tournament-Klasse..................................................................6<br />
2.2.10 Member-Klasse......................................................................6<br />
2.3 Datenbank-Klassen........................................................................7<br />
2.3.1 Allgemeines............................................................................7<br />
2.3.2 Database-Klasse......................................................................7<br />
2.3.3 SQLTable-Klasse......................................................................7<br />
2.4 GUI-Klassen..................................................................................7<br />
2.4.1 Allgemeines............................................................................7<br />
2.4.2 GUIFunctions..........................................................................8<br />
2.4.3 ServerWindow.........................................................................9<br />
2.4.4 LobbyWindow..........................................................................9<br />
2.4.5 LobbyGameListCellRenderer.....................................................10<br />
2.4.6 GameListLabel bzw. TournamentListLabel..................................10<br />
2.4.7 GameWindow........................................................................10<br />
2.4.8 FieldButton...........................................................................10<br />
2.4.9 ReversiWindow......................................................................11<br />
2.4.10 ImagePanel.........................................................................11<br />
2.4.11 LobbyUpdate und GameUpdate...............................................11<br />
2.4.12 TournamentWindow..............................................................11<br />
2.4.13 TournamentTreePanel............................................................11<br />
2.4.14 ShowGroupWindow...............................................................11<br />
2.4.15 HelpWindow........................................................................12<br />
3 Server-Client-Kommunikation..............................................................13<br />
3.1 Ablauf eines Spielzuges.................................................................13
3.2 Ablauf eins Turnieres....................................................................13<br />
3.3 Login..........................................................................................14<br />
3.4 Dokumenttypdefinition..................................................................16<br />
4 GUI-Design.......................................................................................21<br />
4.1 Formularfenster...........................................................................21<br />
4.2 Lobbyfenster...............................................................................24<br />
4.3 Reversifenster.............................................................................26<br />
4.4 Turnierfenster..............................................................................27<br />
4.5 Gruppenverwaltungsfenster...........................................................28<br />
4.6 Statistikfenster............................................................................28<br />
4.7 Serverfenster..............................................................................29
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
1 Spielregeln<br />
Reversi ist ein Brettspiel für genau zwei Spieler.<br />
Ziel des Spiels ist es mehr eigene Spielsteine auf dem Spielfeld zu haben als der Gegenspieler. Jeder<br />
Stein zählt einen Punkt.<br />
Ein Spielzug besteht aus dem Setzen eines neuen eigenen Spielsteins auf ein freies Feld. Nach dem<br />
setzten des neuen Steins werden alle gegnerischen Steine, die durch den neuen Stein und bereits<br />
vorhandenen Steinen des aktiven Spielers in einer waagerechten, senkrechten, oder diagonalen<br />
Linie ohne Lücke eingeschlossen sind umgedreht. Das bedeutet alle eingeschlossenen Steine des<br />
Gegners werden durch Steine des aktiven Spielers ersetzt. Danach ist der andere Spieler am Zug.<br />
Beim Setzen eines Zuges muss immer mindestens ein gegnerischer Stein umgedreht werden. Wenn<br />
das nicht möglich ist, ist der andere Spieler dran ohne dass ein Zug gemacht wurde.<br />
Das Spiel ist zu Ende sobald kein Spieler mehr ziehen kann. Dies tritt ein, wenn alle Felder mit<br />
Steinen belegt sind, oder beide Spieler keinen gegnerischen Stein mehr umdrehen können. In<br />
diesem Fall werden alle noch freien Felder dem Spieler, der mehr Steine auf dem Feld hat, mit<br />
jeweils einem Punkt gutgeschrieben, als hätte er auf allen freien Feldern einen Stein.<br />
Bei einem Verbindungsabbruch bekommt der Verbleibende Spieler einen Win, der getrennte Spieler<br />
einen Loss. Die Steindifferenz beträgt "Anzahl der Steine des verbliebenen Spielers" zu null. Ein<br />
Sieg durch einen Time-out des Gegners über die maximale Zugzeit wird wie ein Disconnect<br />
gewertet.<br />
Uni Rostock – WS 08/09 4/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Abbildung 1.1: Statechart eines Reversi-Spiels<br />
Abbildung 1 beschreibt die verschiedenen Zustände innerhalb eines Reversi-Spiels.<br />
1.1 Turnierregeln<br />
Wenn bei eingestellten maximal 2 n Spielern zwischen 2 n und 2 n-1 Spieler angemeldet sind, dann wird<br />
jedem Spiel mindestens ein Spieler zugeordnet. Die restlichen Spieler verteilen sich zufällig auf die<br />
Spiele. Die Spieler, die keinen Gegner zugewiesen bekommen haben, erhalten ein freewin. Wenn<br />
sich nicht mehr als 2 n-1 Spieler zu dem Turnier angemeldet haben, wird die kleinstmögliche<br />
Zweierpotenz als maximale Spieleranzahl angenommen.<br />
Durch diese Wahl der Spieleranordnungen treten Freewins höchstens in der ersten Runde auf.<br />
Bei einem gruppenübergreifendem Turnier gehen die Ergebnisse der Spiele sowohl in die<br />
persönliche als auch in die gruppeninterne Statistik ein.<br />
Uni Rostock – WS 08/09 5/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
2 Klassenbeschreibungen<br />
Das Klassendiagramm befindet sich in einem zusätzlichen Dokument (Klassendiagramm.png).<br />
Im folgenden werden die einzelnen Klassen näher erläutert.<br />
2.1 Netzwerk-Klassen<br />
2.1.1 Allgemeines<br />
Für die Netzwerkkommunikation werden blockierende Sockets verwendet. Um jederzeit<br />
nebenläufige Aktionen ausführen zu können, wird das Empfangen und Senden von Nachrichten<br />
über Netzwerk in eigene Threads ausgelagert. Dabei sind die Netzwerkklassen nur für das<br />
Aufbereiten von Netzwerkinformationen und Ereignissen zuständig.<br />
Die Auswertung und Reaktion auf diese wird zentral von den Logik-Klassen übernommen.<br />
Informationen die auch einen anderen Spieler betreffen werden zuerst zum Server geschickt, der<br />
diese dann an alle betreffende Clients weiterleitet. So werden z.B. Chat-Nachrichten beim Sender<br />
auch erst dann angezeigt, wenn der Server diese empfangen hat und wieder zurück geschickt hat.<br />
Durch dieses Vorgehen sollen Asynchronität zwischen den Clients vermieden werden (z.B. wenn<br />
der Server die Nachricht nicht empfangen kann). Vorgänge bei denen so verfahren wird sind: das<br />
Senden eines Spielzuges, das Senden von Ingame- und Lobbychat-Nachrichten.<br />
2.1.2 NetworkThread-Klasse<br />
Die NetworkThread-Klasse ist ein Thread und die Basisklasse für alle Netzwerk-Klassen.<br />
Die Klasse implementiert die Funktionen read und write. Write sendet ein XML-Dokument über<br />
den Socket. Die Funktion read ließt an den übergebenen Socket gesendete Daten aus, und bereitet<br />
sie zu XML-Dokumente auf.<br />
2.1.3 NetworkServer-Klasse<br />
Der NetworkServer ist ein NetworkThread des Servers, welcher eingehende Verbindungen von den<br />
Clients auf den serverSocket akzeptiert.<br />
Nach starten des NetworkServer-Threads läuft dieser bis die Funktion stopNetworkServer<br />
aufgerufen wird oder das Programm beendet wird.<br />
Uni Rostock – WS 08/09 6/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
2.1.4 ListenThread-Klasse<br />
Der ListenThread ist ein NetworkThread der Daten an dem übergebenen Socket ausliest und diese<br />
als XML-Documente zur Auswertung/Verarbeitung an die Logik übergibt.<br />
Der ListenThread läuft nach dem Starten bis der entsprechende Socket geschlossen wird oder das<br />
Programm beendet wird.<br />
2.2 Verwaltungsklassen<br />
2.2.1 Logic-Klasse<br />
Die Logic-Klasse ist die Schnittstelle zwischen den Netzwerkfunktionen, der grafischen Oberfläche<br />
und der Datenbank. Sie definiert den Teil des Programms, der die Zusammenarbeit zwischen den<br />
einzelnen Komponenten organisiert, sowie den Großteil der Kommunikation zwischen Client und<br />
Server übernimmt. Die abstrakte Methode received wird durch ListenThreads aufgerufen und<br />
ermöglicht eine Verarbeitung der empfangenen XML-Dokumente.<br />
Die abstrakte Methode disconnected wird beim Trennen eines Sockets ausgeführt, um entsprechend<br />
reagieren zu können. Durch send bietet die Klasse eine sichere Funktion zur Übertragung von<br />
XML-Dokumenten an einem übergebenen Socket.<br />
Logic ist die Basisklasse für Client- und ServerLogic. Alle Logic-Klassen müssen thread-sicher<br />
sein. Die Logic-Klasse beinhaltet die für die jeweilige Logik erforderlichen Spiele gemappt nach<br />
ihrer ID.<br />
2.2.2 ServerLogic-Klasse<br />
Die ServerLogic-Klasse ist für die Verwaltung von Spielerprofilen, Spielen, Turnieren und Gruppen<br />
verantwortlich. Diese sind nach ihrer ID gemappt in der Serverlogik verfügbar.<br />
Durch startServer und stopServer kann der NetworkServer-Thread gesteuert werden. Die Methode<br />
connected wird aufgerufen wenn der NetworkServer eine neue Verbindung auf dem übergebenen<br />
Socket akzeptiert hat.<br />
Das für den Spieleportal-Server benötigte Verhalten wird durch überschreiben von received und<br />
disconnected der Basisklasse Logic implementiert.<br />
Uni Rostock – WS 08/09 7/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
2.2.3 ClientLogic-Klasse<br />
Die Klasse ClientLogic erbt von der Klasse Logic und dient zur Auswertung von Nachrichten,<br />
welche vom Server geschickt wurden. Dies wird mit der Methode received umgesetzt.<br />
Weiterhin dient die Klasse zum Verbindungsaufbau zu einem definierten Server (connectToServer)<br />
und ermöglicht auch das Trennen einer bereits vorher entstandenen Client-Server-Verbindung<br />
(disconnectFromServer).<br />
2.2.4 Player-Klasse<br />
Die Klasse Player steht in Assoziation mit den Klassen ClientLogic, ServerLogic und Statistics.<br />
Diese Klasse verwaltet Spielerinformationen durch die Attributen description, email, group, ID,<br />
nickname, regdate, socket und stats und kann diese mit Hilfe von get bzw. set Methoden auslesen<br />
bzw. setzen lassen. Die Methode toString wurde überschrieben, sodass sie den nickname<br />
zurückgibt.<br />
2.2.5 Group-Klasse<br />
Die Klasse Group steht in Assoziation mit den Klassen AccessRight und Statistics, da jede Gruppe<br />
eine Statistik besitzt und die Möglichkeit einer Gruppe beizutreten über ein AccessRight-Objekt<br />
definiert wird. Dieses ist entweder „Public“ oder „Restricted“.<br />
Die Klasse Group besitzt Attribute um den Admin (admin), eine Gruppenbeschreibung<br />
(description), eine ID (ID), eine Liste von Gruppenmitgliedern (members), einen Namen (name),<br />
eine Statistik (stats), sowie Eintrittsberechtigung zu definieren. Mit den zugehörigen get- und set-<br />
Methoden lassen sich diese Attribute verwalten.<br />
2.2.6 Statistics-Klasse<br />
Die Klasse Statistics steht in Assoziation mit den Klassen Group und Player, da Objekte von beiden<br />
Klassen Statistiken besitzen.<br />
Die Attribute eines Statistics-Objekts sind diff, draws, losses und wins. diff gibt die Steindifferenz<br />
an, die anderen Attribute haben intuitive Bedeutung.<br />
2.2.7 Game-Klasse<br />
Die Klasse Game stellt alle wichtigen Attribute für ein Spiel zur Verfügung.<br />
Hierzu zählen z.B. das Spielfeld, die Spieler und die Punkte der Spieler.<br />
Uni Rostock – WS 08/09 8/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Außerdem stellt sie Funktionen für die Kommunikation für das Spiel bereit wie die Funktion<br />
sendMove, die einen durchgeführten Zug an den Gegenspieler überträgt und verfügt über einen<br />
Timer, welcher die maximale Zugdauer angibt.<br />
2.2.8 Reversi-Klasse<br />
Die Klasse Reversi erbt von der Klasse Game. Reversi beinhaltet die Funktionen, welche die<br />
Spielregeln des Spiels Reversi umsetzen. Hierzu gehören die Funktionen checkMove, die prüft ob<br />
der gewünschte Zug möglich ist. calcMove führt einen Zug nach den Spielregeln durch, dreht die<br />
Steine um und aktualisiert den Punktestand. calcPossibleForActivePlayer berechnet welche Züge<br />
für den aktiven Spieler mögliche sind, um die Bedienung zu erleichtern und die Regeln einzuhalten.<br />
2.2.9 Tournament-Klasse<br />
Die Tournament-Klasse fasst mehrere Spiele zu einem Turnier zusammen und verwaltet die<br />
Spielerpaarungen gemäß einem binären Turnierbaum. Das Turnier wird zu einer in der Variablen<br />
startTime festgelegten Zeit automatisch gestartet. Die maximal zulässige Anzahl an Spielern wird<br />
durch maxPlayer bestimmt.<br />
Der Turnierbaum ist ein zweidimensionales Array, wobei für jede Runde ein Array von Spielen<br />
angelegt wird. Spieler die einen Freewin erhalten stehen in der Liste aller Spieler, sind aber in<br />
keinem Spiel-Objekt.<br />
2.2.10 Member-Klasse<br />
Die Klasse Member umfasst die Attribute player, vom Typ Player und status, vom Typ<br />
Memberstatus. Dieser Status ist entweder mit MEMBER oder CANDIDATE belegt. Objekte der<br />
Klasse Member dienen dazu, Die Angehörigkeit von Player zu einer Gruppe zu beschreiben.<br />
2.3 Datenbank-Klassen<br />
2.3.1 Allgemeines<br />
Die Datenbank dient zum Speichern von Informationen über Spielerprofilen und Gruppen.<br />
Die Statistik zu einem Spieler wird beim Einloggen aus der Datenbank in den Verweis des Player-<br />
Objekts geladen. Beim Ausloggen (oder beim Trennen der Verbindung) wird die Statistik des<br />
Spielers wieder zurück in die Datenbank geschrieben.<br />
Uni Rostock – WS 08/09 9/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Gruppen hingegen werden komplett beim Starten des Servers aus der Datenbank geladen und beim<br />
Beenden wieder zurückgeschrieben. Bei Veränderungen der Gruppeneinstellungen und des<br />
Spielerprofils werden diese sofort abgespeichert.<br />
2.3.2 Database-Klasse<br />
Die Klasse Database ist die Schnittstelle zur Datenbank. Für die Standard-Operationen Hinzufügen,<br />
Bearbeiten und Löschen existiert jeweils eine Methode für Gruppen, Spieler und Mitglieder mit<br />
dem entsprechenden Prefix: add, set, del (z.B. addPlayer() um einen Spieler zur Datenbank hinzu zu<br />
fügen)<br />
2.3.3 SQLTable-Klasse<br />
Die Klasse SQLTable bildet das Gründgerüst für alle Klassen die zur Generierung von MySQL-<br />
Queries verwendet werden. Dies sind SQLTable_Groups, SQLTable_Members, SQLTable_Player<br />
und SQLTable_Server. Bis auf den Konstruktor geben alle Methoden einen MySQL-Query in Form<br />
eines Strings zurück, der dann von einem Database-Objekt ausgeführt werden kann.<br />
2.4 GUI-Klassen<br />
2.4.1 Allgemeines<br />
Zur GUI-Programmierung wird das swing-Framework verwendet. Alle Window-Klassen erben<br />
direkt oder indirekt von JFrame und stellen die Schnittstelle zum Benutzer dar. Bis auf die<br />
Spielfenster verwenden alle Fenster als LayoutManager das GridBagLayout zum automatischen<br />
Anordnen der Komponenten. Die ReversiWindow-Klasse verwendet keinen LayoutManager, dort<br />
werden die Komponenten pixelgenau nach dem Design angeordnet.<br />
Alle direkt von JFrame erbenden Klassen implementieren die Methode initGUI zum erzeugen und<br />
Anordnen der einzelnen Komponenten.<br />
Mit wenigen Ausnahmen haben alle Fenster ein Verweis auf ein Logic-Objekt zum versenden von<br />
Nachrichten.<br />
Zur Übersicht wurden folgende Klassen nicht ins Klassendiagramm aufgenommen und werden<br />
auch nicht einzeln Erläutert:<br />
• Create(Game/Group/Tournament)Window<br />
• DelProfileWindow<br />
Uni Rostock – WS 08/09 10/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
• JoinGroupWindow<br />
• LoginWindow<br />
• RegisterWindow<br />
• ProfileWindow<br />
Diese Fenster stellen alle ein Formular bereit und schicken über die ClientLogic die verschiedenen<br />
Nachrichten an den Server. Das ProfileWindow dient zudem zur Anzeige des Profils von anderen<br />
Spielern.<br />
Zur Überprüfung von Formularfeldern deren Inhalt bestimmte Regeln einhalten muss (z. B. dürfen<br />
bestimmte Zeichen nicht im Spielernamen verwendet werden) werden die entsprechenden<br />
Funktionen der Klasse GUIFunctions benutzt um die Korrektheit der Eingabe zu überprüfen. Bei<br />
falscher Eingabe werden die Rahmen der Eingabefelder rot gefärbt, um dies dem Nutzer kenntlich<br />
zu machen<br />
Einige GUI-Klassen implementieren das Observer-Interface um Änderungen z. B. des Spieles zu<br />
überwachen und dem Nutzer dies anzuzeigen. Da das benutzte swing-Framework nicht threadsicher<br />
ist, ruft die öffentliche update-Methode eine jeweils zur Klasse passende private update()-<br />
Methode im swing-Thread auf.<br />
2.4.2 GUIFunctions<br />
Die Klasse GUIFunctions ist selber keine GUI-Klasse, stellt aber den anderen Klassen häufig<br />
benutzte Funktionen als statische Methoden zur Verfügung. Dazu gehört vor allem das Prüfen von<br />
Eingaben auf die korrekte Form (z. B. Spielernamen). Dazu wird geprüft, ob die Eingabe einem<br />
betsimmten regulären Ausdruck entspricht.<br />
Zusätzlich werden in dieser Klasse alle benötigten Ressourcen wie Bilder und Schriftarten mit der<br />
Methode initRessources() geladen.<br />
Außerdem berechnet es aus einem Passwort den SHA1-Hash in Base64-Kodierung zur<br />
Übermittlung an den Server und bietet eine Funktion zum escapen von HTML-Zeichen, damit<br />
Nutzer keinen HTML-Code im Chatfenster schreiben können.<br />
2.4.3 ServerWindow<br />
Die Klasse ServerWindow stellt dem Admin eine Schnittstelle zum Konfigurieren und überwachen<br />
der eingeloggten Spieler bereit.<br />
Uni Rostock – WS 08/09 11/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Die Klasse ServerWindow implementiert das Observer-Interface zum erhalten von<br />
Statusänderungen der ServerLogic, zum Beispiel wenn sich ein neuer Spieler eingeloggt hat. Dazu<br />
wird ein Vector-Objekt mit einer Liste aller Spiele an den Server übergeben, der diese<br />
Spielerliste dann dem Admin anzeigt. Des Weiteren zeigt das ServerWindow an, ob der Server<br />
überhaupt gestartet ist und ob es einen Fehler beim starten des Servers gab.<br />
2.4.4 LobbyWindow<br />
Das LobbyWindow ist das Hauptinterface im Client und gestattet dem Nutzer den Zugriff auf alle<br />
Funktionen, wie z. B. Registrieren, Einloggen, Chatten, einem Spiel beitreten oder eine Gruppe<br />
erstellen.<br />
Die Klasse LobbyWindow implementiert das Observer-Interface und überwacht die ClientLogic<br />
zum Erhalten von wichtigen Informationen wie z. B. die Nachricht, dass der Nutzer sich erfolgreich<br />
eingeloggt hat oder eine Liste aller offenen Spiele.<br />
Ein JEditorPane speichert die Chatnachrichten, dabei wird der Chat in einem HTML-Dokument<br />
verpackt, um z. B. Systemnachrichten farblich hervorzuheben und für Fehlermeldungen einen Link<br />
zur Hilfe anzubieten (siehe dazu auch die Klasse HelpWindow).<br />
Zum Anzeigen der einzelnen Spiele und Turniere werden mehrere JList-Objekte mit einem<br />
angepassten ListCellRenderer benutzt, um die wichtigsten Informationen übersichtlicher<br />
darzustellen.<br />
2.4.5 LobbyGameListCellRenderer<br />
Die Klasse LobbyGameListCellRenderer erbt von DefaultListCellRenderer und ist für die Anzeige<br />
der offenen Spiele und Turniere in der Lobby verantwortlich. Wenn ein Spielobjekt angezeigt<br />
werden soll, dann erstellt der ListCellRenderer ein GameListLabel, bei einem Turnier ein<br />
TournamentListLabel.<br />
2.4.6 GameListLabel bzw. TournamentListLabel<br />
Diese beiden Klassen erben jeweils von JLabel und stellen die verschiedenen Informationen von<br />
einem Spiel (z. B. Spieler und maximale Zugzeit) bzw. einem Turnier (z. B. Name und Startzeit) so<br />
dar, dass die einzelnen Informationen ausgerichtet sind und bei mehrere Spielen und Turnieren<br />
jeweils untereinander stehen. Dazu bekommt jede Informationen einen gewissen Anteil der<br />
Gesamtbreite und in der überschriebenen Methode paintComponent() werden die Informationen an<br />
einem bestimmten Platz gezeichnet.<br />
Uni Rostock – WS 08/09 12/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
2.4.7 GameWindow<br />
Die abstrakte Klasse GameWindow stellt alle wichtigen Funktionen bereit, die zum Spielen eines<br />
Spieles wichtig sind. So fordert die Methode getProfile() die wichtigsten Daten zum Spieler an,<br />
makeMove() gibt die gesetzten Koordinaten an das Spiel weiter und sendChatMessage() verschickt<br />
die eingegebene Nachricht an den Gegenspieler.<br />
Sie implementiert außerdem das Observer-Interface und überwacht das jeweilige Spiel um<br />
Änderungen dem Nutzer anzuzeigen. Bei Änderungen am Spielfeld wird die abstrakte Methode<br />
updateField() aufgerufen, die dem eigentlichen Spielfenster anordnet das Spielfeld neu zu zeichnen.<br />
Die einzelnen Felder werden als FieldButtons dargestellt. Dies ermöglicht gleichzeitig die<br />
Darstellung von Icons (z. B. Spielfiguren) und eine einfache Zuordnung von durch Klicks auf die<br />
Felder ausgelösten ActionEvents zu den Feldkoordinaten.<br />
2.4.8 FieldButton<br />
Die Klasse FieldButton erbt von JButton führt als neue Eigenschaft Koordinaten ein. Zusätzlich<br />
wird der Button standardmäßig auf Transparent gesetzt, sodass der Hintergrund des Spielfeldes<br />
immer sichtbar ist und nur durch z. B. die Spielfiguren verdeckt wird.<br />
2.4.9 ReversiWindow<br />
Die Klasse ReversiWindow erbt von GameWindow. Sie ist nur für die eigentliche Anzeige des<br />
Spielfensters, des Feldes und der Steine verantwortlich.<br />
Zur Anzeige des Hintergrundes wird ein Objekt der Klasse ImagePanel als oberstes Container-<br />
Element des Fensters gesetzt. Alle anderen Komponenten wie Labels werden als Kindelemente<br />
eingefügt. Durch die Transparenz der Komponenten bleibt das Hintergrundbild auch weiter sichtbar.<br />
Das Fenster nutzt zur Anzeige von Informationen eine gesonderte Schriftart, die zum Design<br />
passend gewählt ist und frei nutzbar ist.<br />
2.4.10 ImagePanel<br />
Die Klasse ImagePanel erbt von JPanel und fügt lediglich die Unterstützung für ein Hintergrundbild<br />
hinzu.<br />
2.4.11 LobbyUpdate und GameUpdate<br />
Die Klassen LobbyUpdate und GameUpdate werden beim Observable-Update an die Observer<br />
übergeben. Dort sind alle nötigen Statusänderungen gespeichert.<br />
Uni Rostock – WS 08/09 13/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
2.4.12 TournamentWindow<br />
Die Klasse TournamentWindow dient zur Darstellung des Turnieres (Übersicht über alle<br />
teilnehmenden Spieler und Turnierbaum). Sie ist nicht für die Verwaltung der einzelnen Spielfenster<br />
verantwortlich.<br />
2.4.13 TournamentTreePanel<br />
Die Klasse TournamentTreePanel erbt von JPanel und ist für die eigentliche Darstellung des<br />
Turnierbaumes verantwortlich. Sie implementiert zusätzlich das Scrollable-Interface, damit größere<br />
Turnierbäume nur ausschnittsweise dargestellt werden können.<br />
2.4.14 ShowGroupWindow<br />
Die Klasse ShowGroupWindow erlaubt dem Gruppenadministrator das Verwalten seiner Gruppe<br />
und allen anderen vollen Mitgliedern Einsicht in die Gruppe. Dazu gehört neben dem Gruppentext<br />
und der Zugangseinstellung auch die Mitgliederverwaltung. Dazu wird die Mitgliederliste in einem<br />
eigenen JPanel angezeigt, welches ein GridLayout erhält. Für den Gruppenadministrator wird neben<br />
einem Mitglied eine Auswahl an JCheckBoxen (zum Entfernen und Akzeptieren von Anwärtern)<br />
und JGroupBoxen (zum Befördern eines Mitgliedes zum Gruppenadministrator) angezeigt.<br />
Anwärter werden für normale Mitglieder nicht angezeigt.<br />
2.4.15 HelpWindow<br />
Die Klasse HelpWindow zeigt die verschiedenen Hilfeseiten im HTML-Format an. Dabei kann es<br />
auch eine bestimmte Hilfeseite anzeigen, z. B. die Erklärung einer Fehlermeldung nachdem der<br />
Nutzer auf diese geklickt hat.<br />
Uni Rostock – WS 08/09 14/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
3 Server-Client-Kommunikation<br />
3.1 Ablauf eines Spielzuges<br />
Das GameWindow erhält die Koordinaten des vom Nutzer ausgewählten Feldes und ruft<br />
Game.makeMove(x, y) auf. Game.makeMove(x, y) erzeugt das XML-Dokument und<br />
ClientLogic.sendDoc(xml) übermittelt dieses an den Server. Der ListenThread des Servers, für den<br />
entsprechenden Client, empfängt das Dokument und ruft ServerLogic.received(xml) auf, welcher<br />
das Dokument verarbeitet und über send(sock, xml) an beide Spieler übermittelt. Diese werten,<br />
ähnlich wie die ServerLogic, das Dokument aus und rufen im entsprechenden Spielobjekt<br />
setMove(x, y) auf. Dort wird calcMove(x, y) aufgerufen, was erst die eigentliche Änderung des<br />
Spielfeldes bewirkt.<br />
Abbildung 2 verdeutlicht dies anhand eines Sequenzdiagrammes.<br />
3.2 Ablauf eins Turnieres<br />
Nachdem ein Turnier mit openTournament erstellt wurde, erhält der erstellende Spieler eine<br />
joinTournament-Nachricht. Andere Spieler senden zum Beitritt eines Turnieres eine<br />
joinTournament-Nachricht und erhalten eine joinTournament-Nachricht als Antwort.<br />
Bei Erhalt der joinTournament-Nachricht, welche als JoinGameResult ein OK enthält, erstellt die<br />
ClientLogic das Turnierobjekt.<br />
Sobald die Startzeit des Turnieres erriecht ist, schickt der Server eine joinGame-Nachricht an alle<br />
Spieler die an einem Spiel in der aktuellen Runde teilnehmen. Zur Aktualisierung des<br />
Turnierbaumes wird eine tournamentInfo-Nachricht an alle Spieler geschickt. Danach bekommen<br />
alle Spieler in einem Spiel eine startGame-Nachricht.<br />
TournamentInfo-Nachrichten werden bei folgenden Ereignissen an alle Spieler geschickt:<br />
• Ein Spieler betritt das Turnier<br />
• Eine neue Runde wird gestartet<br />
• Ein Spiel wird entschieden<br />
Falls ein Spiel unentschieden gespielt wird, wird das Spiel nicht gewertet und ein neues Spiel<br />
gestartet. Dies wird solange wiederholt, bis ein Spieler gewonnen hat.<br />
Uni Rostock – WS 08/09 15/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
3.3 Login<br />
Abbildung 3 beschreibt die Kommunikation zwischen Client, Server und Datenbank bei einem<br />
Login-Vorgang.<br />
Bei einem Login sendet die ClientLogic mit Hilfe von sendLogin Name und Passwort an den<br />
Server. Dieser ruft checkPassword der Datenbank auf, erhält von dieser ein Spielerobjekt und<br />
übermittelt dieses wieder an den Client.<br />
Abbildung 3.1: Sequenzdiagramm eines Login-Vorganges<br />
Uni Rostock – WS 08/09 16/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Abbildung 3.3:<br />
Sequenzdiagramm eines<br />
Spielzuges<br />
Uni Rostock – WS 08/09 17/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
3.4 Dokumenttypdefinition<br />
Zur Kommunikation zwischen Client und Server werden XML-Dokumente ausgetauscht, die<br />
folgender DTD genügen.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Uni Rostock – WS 08/09 18/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Uni Rostock – WS 08/09 19/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Uni Rostock – WS 08/09 20/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Uni Rostock – WS 08/09 21/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Uni Rostock – WS 08/09 22/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4 GUI-Design<br />
4.1 Formularfenster<br />
Die Formularfenster sehen wie folgt aus, wobei sie in der Größe fest und nicht durch den Nutzer<br />
änderbar sind:<br />
Uni Rostock – WS 08/09 23/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Uni Rostock – WS 08/09 24/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Uni Rostock – WS 08/09 25/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4.2 Lobbyfenster<br />
Das Lobbyfenster sieht wie folgt aus:<br />
Uni Rostock – WS 08/09 26/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Links befindet sich der Chat-Verlauf. In der Liste rechts oben befinden sich die offenen Spiele,<br />
rechts unten die offenen Turniere. Durch die Buttons rechts oben kann man zwischen den<br />
öffentlichen, gruppeninternen und gruppenübergreifend Spielen und Turnieren wählen.<br />
Das Menü hat die folgende Struktur:<br />
• Account<br />
◦ Profile<br />
◦ Login<br />
◦ Logout<br />
◦ Register<br />
◦ Delete your Account<br />
◦ Connect to Server<br />
◦ Disconnect<br />
• Game<br />
◦ Create Game<br />
◦ Create Tournament<br />
◦ GetRanking<br />
▪<br />
▪<br />
Players<br />
Groups<br />
• Group<br />
◦ Show Group<br />
◦ Create Group<br />
◦ Join Group<br />
◦ LeaveGroup<br />
• Help<br />
◦ Help<br />
◦ About<br />
Uni Rostock – WS 08/09 27/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4.3 Reversifenster<br />
Das Reversifenster sieht folgendermaßen aus:<br />
Es ist in der Größe nicht veränderbar.<br />
Links und Rechts sieht man die jeweiligen Spieler, in der Mitte das Spielfeld. Unter dem Spielfeld<br />
befindet sich das Eingabefeld für den Chat, welcher am unteren Rand angezeigt wird.<br />
Die Anzahl an Steinen der Spieler werden durch „count:“ gekennzeichnet.<br />
Der aktive Spieler wird durch den Text „it's your turn!“ unter seinem Profil und blinkenden Pfeilen<br />
markiert. Ist man selbst der aktive Spieler wird ggf. die für den Zug verbleibende Zeit angezeigt und<br />
Felder für mögliche Züge werden wie oben gezeigt in der Spielerfarbe gekennzeichnet.<br />
Durch Klicken auf den Spielernamen lässt sich das Profil anzeigen.<br />
Uni Rostock – WS 08/09 28/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4.4 Turnierfenster<br />
Das Turnierfenster sieht folgendermaßen aus:<br />
Das Fenster ist in der Größe beliebig veränderbar. Bei Höhenveränderungen nehmen der<br />
Turnierbaum und die Spielerliste den zusätzlichen Platz ein, bei Veränderungen der Breite nimmt<br />
nur der Turnierbaum den zusätzlichen Platz ein. Wird das Fenster verkleinert wird analog der<br />
Turnierbaum und die Spielerliste verkleinert.<br />
Ist der Turnierbaum größer als der zur Verfügung stehene Platz, kann der sichtbare Ausschnitt mit<br />
Scrollleisten verschoben werden.<br />
Uni Rostock – WS 08/09 29/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4.5 Gruppenverwaltungsfenster<br />
Das Gruppenverwaltungsfenster soll (für den Gruppenadministrator) folgendermaßen aussehen:<br />
Das Fenster lässt sich vom Nutzer in der Größe nicht ändern, passt sich aber in der Höhe an die<br />
Mitgliederzahl an.<br />
4.6 Statistikfenster<br />
Das Statistikfenster sieht folgendermaßen aus:<br />
Es ist in allen Richtungen in der Größe durch den Nutzer veränderbar, die Tabelle nimmt immer die<br />
gesamte Größe ein.<br />
Wenn nicht genügend Platz zum Darstellen aller Spieler oder Gruppen ist, dann wird ein Scroll-<br />
Balken angezeigt.<br />
Uni Rostock – WS 08/09 30/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
4.7 Serverfenster<br />
Das Serverfenster sieht wie folgt aus (gestoppt und gestartet):<br />
Uni Rostock – WS 08/09 31/32
Projekt Softwaretechnik <strong>Entwickler</strong><strong>dokumentation</strong> 04. Mai 2009<br />
Gezeigt ist die Mindestgröße. Wird das Fenster durch den Nutzer vergrößert, dann nimmt die Liste<br />
der eingeloggten Nutzer den zusätzlichen Platz ein.<br />
Uni Rostock – WS 08/09 32/32