Entwickler- dokumentation

Entwicklerdokumentation
Onlinespieleportal
Reversi – Gruppe 23
Projekt Softwaretechnik
WS 2008/09
Uni Rostock
Christian Eichner
Nils Faupel
Stefan Gladisch
Martin Nyolt
Cornelius Radicke
Jonas Vetterick

Inhaltsverzeichnis
1 Spielregeln ........................................................................................1
1.1 Turnierregeln................................................................................2
2 Klassenbeschreibungen........................................................................3
2.1 Netzwerk-Klassen..........................................................................3
2.1.1 Allgemeines............................................................................3
2.1.2 NetworkThread-Klasse..............................................................3
2.1.3 NetworkServer-Klasse..............................................................4
2.1.4 ListenThread-Klasse.................................................................4
2.2 Verwaltungsklassen........................................................................4
2.2.1 Logic-Klasse............................................................................4
2.2.2 ServerLogic-Klasse...................................................................4
2.2.3 ClientLogic-Klasse....................................................................5
2.2.4 Player-Klasse..........................................................................5
2.2.5 Group-Klasse..........................................................................5
2.2.6 Statistics-Klasse......................................................................5
2.2.7 Game-Klasse...........................................................................6
2.2.8 Reversi-Klasse.........................................................................6
2.2.9 Tournament-Klasse..................................................................6
2.2.10 Member-Klasse......................................................................6
2.3 Datenbank-Klassen........................................................................7
2.3.1 Allgemeines............................................................................7
2.3.2 Database-Klasse......................................................................7
2.3.3 SQLTable-Klasse......................................................................7
2.4 GUI-Klassen..................................................................................7
2.4.1 Allgemeines............................................................................7
2.4.2 GUIFunctions..........................................................................8
2.4.3 ServerWindow.........................................................................9
2.4.4 LobbyWindow..........................................................................9
2.4.5 LobbyGameListCellRenderer.....................................................10
2.4.6 GameListLabel bzw. TournamentListLabel..................................10
2.4.7 GameWindow........................................................................10
2.4.8 FieldButton...........................................................................10
2.4.9 ReversiWindow......................................................................11
2.4.10 ImagePanel.........................................................................11
2.4.11 LobbyUpdate und GameUpdate...............................................11
2.4.12 TournamentWindow..............................................................11
2.4.13 TournamentTreePanel............................................................11
2.4.14 ShowGroupWindow...............................................................11
2.4.15 HelpWindow........................................................................12
3 Server-Client-Kommunikation..............................................................13
3.1 Ablauf eines Spielzuges.................................................................13

3.2 Ablauf eins Turnieres....................................................................13
3.3 Login..........................................................................................14
3.4 Dokumenttypdefinition..................................................................16
4 GUI-Design.......................................................................................21
4.1 Formularfenster...........................................................................21
4.2 Lobbyfenster...............................................................................24
4.3 Reversifenster.............................................................................26
4.4 Turnierfenster..............................................................................27
4.5 Gruppenverwaltungsfenster...........................................................28
4.6 Statistikfenster............................................................................28
4.7 Serverfenster..............................................................................29

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
1 Spielregeln
Reversi ist ein Brettspiel für genau zwei Spieler.
Ziel des Spiels ist es mehr eigene Spielsteine auf dem Spielfeld zu haben als der Gegenspieler. Jeder
Stein zählt einen Punkt.
Ein Spielzug besteht aus dem Setzen eines neuen eigenen Spielsteins auf ein freies Feld. Nach dem
setzten des neuen Steins werden alle gegnerischen Steine, die durch den neuen Stein und bereits
vorhandenen Steinen des aktiven Spielers in einer waagerechten, senkrechten, oder diagonalen
Linie ohne Lücke eingeschlossen sind umgedreht. Das bedeutet alle eingeschlossenen Steine des
Gegners werden durch Steine des aktiven Spielers ersetzt. Danach ist der andere Spieler am Zug.
Beim Setzen eines Zuges muss immer mindestens ein gegnerischer Stein umgedreht werden. Wenn
das nicht möglich ist, ist der andere Spieler dran ohne dass ein Zug gemacht wurde.
Das Spiel ist zu Ende sobald kein Spieler mehr ziehen kann. Dies tritt ein, wenn alle Felder mit
Steinen belegt sind, oder beide Spieler keinen gegnerischen Stein mehr umdrehen können. In
diesem Fall werden alle noch freien Felder dem Spieler, der mehr Steine auf dem Feld hat, mit
jeweils einem Punkt gutgeschrieben, als hätte er auf allen freien Feldern einen Stein.
Bei einem Verbindungsabbruch bekommt der Verbleibende Spieler einen Win, der getrennte Spieler
einen Loss. Die Steindifferenz beträgt "Anzahl der Steine des verbliebenen Spielers" zu null. Ein
Sieg durch einen Time-out des Gegners über die maximale Zugzeit wird wie ein Disconnect
gewertet.
Uni Rostock – WS 08/09 4/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Abbildung 1.1: Statechart eines Reversi-Spiels
Abbildung 1 beschreibt die verschiedenen Zustände innerhalb eines Reversi-Spiels.
1.1 Turnierregeln
Wenn bei eingestellten maximal 2 n Spielern zwischen 2 n und 2 n-1 Spieler angemeldet sind, dann wird
jedem Spiel mindestens ein Spieler zugeordnet. Die restlichen Spieler verteilen sich zufällig auf die
Spiele. Die Spieler, die keinen Gegner zugewiesen bekommen haben, erhalten ein freewin. Wenn
sich nicht mehr als 2 n-1 Spieler zu dem Turnier angemeldet haben, wird die kleinstmögliche
Zweierpotenz als maximale Spieleranzahl angenommen.
Durch diese Wahl der Spieleranordnungen treten Freewins höchstens in der ersten Runde auf.
Bei einem gruppenübergreifendem Turnier gehen die Ergebnisse der Spiele sowohl in die
persönliche als auch in die gruppeninterne Statistik ein.
Uni Rostock – WS 08/09 5/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
2 Klassenbeschreibungen
Das Klassendiagramm befindet sich in einem zusätzlichen Dokument (Klassendiagramm.png).
Im folgenden werden die einzelnen Klassen näher erläutert.
2.1 Netzwerk-Klassen
2.1.1 Allgemeines
Für die Netzwerkkommunikation werden blockierende Sockets verwendet. Um jederzeit
nebenläufige Aktionen ausführen zu können, wird das Empfangen und Senden von Nachrichten
über Netzwerk in eigene Threads ausgelagert. Dabei sind die Netzwerkklassen nur für das
Aufbereiten von Netzwerkinformationen und Ereignissen zuständig.
Die Auswertung und Reaktion auf diese wird zentral von den Logik-Klassen übernommen.
Informationen die auch einen anderen Spieler betreffen werden zuerst zum Server geschickt, der
diese dann an alle betreffende Clients weiterleitet. So werden z.B. Chat-Nachrichten beim Sender
auch erst dann angezeigt, wenn der Server diese empfangen hat und wieder zurück geschickt hat.
Durch dieses Vorgehen sollen Asynchronität zwischen den Clients vermieden werden (z.B. wenn
der Server die Nachricht nicht empfangen kann). Vorgänge bei denen so verfahren wird sind: das
Senden eines Spielzuges, das Senden von Ingame- und Lobbychat-Nachrichten.
2.1.2 NetworkThread-Klasse
Die NetworkThread-Klasse ist ein Thread und die Basisklasse für alle Netzwerk-Klassen.
Die Klasse implementiert die Funktionen read und write. Write sendet ein XML-Dokument über
den Socket. Die Funktion read ließt an den übergebenen Socket gesendete Daten aus, und bereitet
sie zu XML-Dokumente auf.
2.1.3 NetworkServer-Klasse
Der NetworkServer ist ein NetworkThread des Servers, welcher eingehende Verbindungen von den
Clients auf den serverSocket akzeptiert.
Nach starten des NetworkServer-Threads läuft dieser bis die Funktion stopNetworkServer
aufgerufen wird oder das Programm beendet wird.
Uni Rostock – WS 08/09 6/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
2.1.4 ListenThread-Klasse
Der ListenThread ist ein NetworkThread der Daten an dem übergebenen Socket ausliest und diese
als XML-Documente zur Auswertung/Verarbeitung an die Logik übergibt.
Der ListenThread läuft nach dem Starten bis der entsprechende Socket geschlossen wird oder das
Programm beendet wird.
2.2 Verwaltungsklassen
2.2.1 Logic-Klasse
Die Logic-Klasse ist die Schnittstelle zwischen den Netzwerkfunktionen, der grafischen Oberfläche
und der Datenbank. Sie definiert den Teil des Programms, der die Zusammenarbeit zwischen den
einzelnen Komponenten organisiert, sowie den Großteil der Kommunikation zwischen Client und
Server übernimmt. Die abstrakte Methode received wird durch ListenThreads aufgerufen und
ermöglicht eine Verarbeitung der empfangenen XML-Dokumente.
Die abstrakte Methode disconnected wird beim Trennen eines Sockets ausgeführt, um entsprechend
reagieren zu können. Durch send bietet die Klasse eine sichere Funktion zur Übertragung von
XML-Dokumenten an einem übergebenen Socket.
Logic ist die Basisklasse für Client- und ServerLogic. Alle Logic-Klassen müssen thread-sicher
sein. Die Logic-Klasse beinhaltet die für die jeweilige Logik erforderlichen Spiele gemappt nach
ihrer ID.
2.2.2 ServerLogic-Klasse
Die ServerLogic-Klasse ist für die Verwaltung von Spielerprofilen, Spielen, Turnieren und Gruppen
verantwortlich. Diese sind nach ihrer ID gemappt in der Serverlogik verfügbar.
Durch startServer und stopServer kann der NetworkServer-Thread gesteuert werden. Die Methode
connected wird aufgerufen wenn der NetworkServer eine neue Verbindung auf dem übergebenen
Socket akzeptiert hat.
Das für den Spieleportal-Server benötigte Verhalten wird durch überschreiben von received und
disconnected der Basisklasse Logic implementiert.
Uni Rostock – WS 08/09 7/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
2.2.3 ClientLogic-Klasse
Die Klasse ClientLogic erbt von der Klasse Logic und dient zur Auswertung von Nachrichten,
welche vom Server geschickt wurden. Dies wird mit der Methode received umgesetzt.
Weiterhin dient die Klasse zum Verbindungsaufbau zu einem definierten Server (connectToServer)
und ermöglicht auch das Trennen einer bereits vorher entstandenen Client-Server-Verbindung
(disconnectFromServer).
2.2.4 Player-Klasse
Die Klasse Player steht in Assoziation mit den Klassen ClientLogic, ServerLogic und Statistics.
Diese Klasse verwaltet Spielerinformationen durch die Attributen description, email, group, ID,
nickname, regdate, socket und stats und kann diese mit Hilfe von get bzw. set Methoden auslesen
bzw. setzen lassen. Die Methode toString wurde überschrieben, sodass sie den nickname
zurückgibt.
2.2.5 Group-Klasse
Die Klasse Group steht in Assoziation mit den Klassen AccessRight und Statistics, da jede Gruppe
eine Statistik besitzt und die Möglichkeit einer Gruppe beizutreten über ein AccessRight-Objekt
definiert wird. Dieses ist entweder „Public“ oder „Restricted“.
Die Klasse Group besitzt Attribute um den Admin (admin), eine Gruppenbeschreibung
(description), eine ID (ID), eine Liste von Gruppenmitgliedern (members), einen Namen (name),
eine Statistik (stats), sowie Eintrittsberechtigung zu definieren. Mit den zugehörigen get- und set-
Methoden lassen sich diese Attribute verwalten.
2.2.6 Statistics-Klasse
Die Klasse Statistics steht in Assoziation mit den Klassen Group und Player, da Objekte von beiden
Klassen Statistiken besitzen.
Die Attribute eines Statistics-Objekts sind diff, draws, losses und wins. diff gibt die Steindifferenz
an, die anderen Attribute haben intuitive Bedeutung.
2.2.7 Game-Klasse
Die Klasse Game stellt alle wichtigen Attribute für ein Spiel zur Verfügung.
Hierzu zählen z.B. das Spielfeld, die Spieler und die Punkte der Spieler.
Uni Rostock – WS 08/09 8/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Außerdem stellt sie Funktionen für die Kommunikation für das Spiel bereit wie die Funktion
sendMove, die einen durchgeführten Zug an den Gegenspieler überträgt und verfügt über einen
Timer, welcher die maximale Zugdauer angibt.
2.2.8 Reversi-Klasse
Die Klasse Reversi erbt von der Klasse Game. Reversi beinhaltet die Funktionen, welche die
Spielregeln des Spiels Reversi umsetzen. Hierzu gehören die Funktionen checkMove, die prüft ob
der gewünschte Zug möglich ist. calcMove führt einen Zug nach den Spielregeln durch, dreht die
Steine um und aktualisiert den Punktestand. calcPossibleForActivePlayer berechnet welche Züge
für den aktiven Spieler mögliche sind, um die Bedienung zu erleichtern und die Regeln einzuhalten.
2.2.9 Tournament-Klasse
Die Tournament-Klasse fasst mehrere Spiele zu einem Turnier zusammen und verwaltet die
Spielerpaarungen gemäß einem binären Turnierbaum. Das Turnier wird zu einer in der Variablen
startTime festgelegten Zeit automatisch gestartet. Die maximal zulässige Anzahl an Spielern wird
durch maxPlayer bestimmt.
Der Turnierbaum ist ein zweidimensionales Array, wobei für jede Runde ein Array von Spielen
angelegt wird. Spieler die einen Freewin erhalten stehen in der Liste aller Spieler, sind aber in
keinem Spiel-Objekt.
2.2.10 Member-Klasse
Die Klasse Member umfasst die Attribute player, vom Typ Player und status, vom Typ
Memberstatus. Dieser Status ist entweder mit MEMBER oder CANDIDATE belegt. Objekte der
Klasse Member dienen dazu, Die Angehörigkeit von Player zu einer Gruppe zu beschreiben.
2.3 Datenbank-Klassen
2.3.1 Allgemeines
Die Datenbank dient zum Speichern von Informationen über Spielerprofilen und Gruppen.
Die Statistik zu einem Spieler wird beim Einloggen aus der Datenbank in den Verweis des Player-
Objekts geladen. Beim Ausloggen (oder beim Trennen der Verbindung) wird die Statistik des
Spielers wieder zurück in die Datenbank geschrieben.
Uni Rostock – WS 08/09 9/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Gruppen hingegen werden komplett beim Starten des Servers aus der Datenbank geladen und beim
Beenden wieder zurückgeschrieben. Bei Veränderungen der Gruppeneinstellungen und des
Spielerprofils werden diese sofort abgespeichert.
2.3.2 Database-Klasse
Die Klasse Database ist die Schnittstelle zur Datenbank. Für die Standard-Operationen Hinzufügen,
Bearbeiten und Löschen existiert jeweils eine Methode für Gruppen, Spieler und Mitglieder mit
dem entsprechenden Prefix: add, set, del (z.B. addPlayer() um einen Spieler zur Datenbank hinzu zu
fügen)
2.3.3 SQLTable-Klasse
Die Klasse SQLTable bildet das Gründgerüst für alle Klassen die zur Generierung von MySQL-
Queries verwendet werden. Dies sind SQLTable_Groups, SQLTable_Members, SQLTable_Player
und SQLTable_Server. Bis auf den Konstruktor geben alle Methoden einen MySQL-Query in Form
eines Strings zurück, der dann von einem Database-Objekt ausgeführt werden kann.
2.4 GUI-Klassen
2.4.1 Allgemeines
Zur GUI-Programmierung wird das swing-Framework verwendet. Alle Window-Klassen erben
direkt oder indirekt von JFrame und stellen die Schnittstelle zum Benutzer dar. Bis auf die
Spielfenster verwenden alle Fenster als LayoutManager das GridBagLayout zum automatischen
Anordnen der Komponenten. Die ReversiWindow-Klasse verwendet keinen LayoutManager, dort
werden die Komponenten pixelgenau nach dem Design angeordnet.
Alle direkt von JFrame erbenden Klassen implementieren die Methode initGUI zum erzeugen und
Anordnen der einzelnen Komponenten.
Mit wenigen Ausnahmen haben alle Fenster ein Verweis auf ein Logic-Objekt zum versenden von
Nachrichten.
Zur Übersicht wurden folgende Klassen nicht ins Klassendiagramm aufgenommen und werden
auch nicht einzeln Erläutert:
• Create(Game/Group/Tournament)Window
• DelProfileWindow
Uni Rostock – WS 08/09 10/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
• JoinGroupWindow
• LoginWindow
• RegisterWindow
• ProfileWindow
Diese Fenster stellen alle ein Formular bereit und schicken über die ClientLogic die verschiedenen
Nachrichten an den Server. Das ProfileWindow dient zudem zur Anzeige des Profils von anderen
Spielern.
Zur Überprüfung von Formularfeldern deren Inhalt bestimmte Regeln einhalten muss (z. B. dürfen
bestimmte Zeichen nicht im Spielernamen verwendet werden) werden die entsprechenden
Funktionen der Klasse GUIFunctions benutzt um die Korrektheit der Eingabe zu überprüfen. Bei
falscher Eingabe werden die Rahmen der Eingabefelder rot gefärbt, um dies dem Nutzer kenntlich
zu machen
Einige GUI-Klassen implementieren das Observer-Interface um Änderungen z. B. des Spieles zu
überwachen und dem Nutzer dies anzuzeigen. Da das benutzte swing-Framework nicht threadsicher
ist, ruft die öffentliche update-Methode eine jeweils zur Klasse passende private update()-
Methode im swing-Thread auf.
2.4.2 GUIFunctions
Die Klasse GUIFunctions ist selber keine GUI-Klasse, stellt aber den anderen Klassen häufig
benutzte Funktionen als statische Methoden zur Verfügung. Dazu gehört vor allem das Prüfen von
Eingaben auf die korrekte Form (z. B. Spielernamen). Dazu wird geprüft, ob die Eingabe einem
betsimmten regulären Ausdruck entspricht.
Zusätzlich werden in dieser Klasse alle benötigten Ressourcen wie Bilder und Schriftarten mit der
Methode initRessources() geladen.
Außerdem berechnet es aus einem Passwort den SHA1-Hash in Base64-Kodierung zur
Übermittlung an den Server und bietet eine Funktion zum escapen von HTML-Zeichen, damit
Nutzer keinen HTML-Code im Chatfenster schreiben können.
2.4.3 ServerWindow
Die Klasse ServerWindow stellt dem Admin eine Schnittstelle zum Konfigurieren und überwachen
der eingeloggten Spieler bereit.
Uni Rostock – WS 08/09 11/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Die Klasse ServerWindow implementiert das Observer-Interface zum erhalten von
Statusänderungen der ServerLogic, zum Beispiel wenn sich ein neuer Spieler eingeloggt hat. Dazu
wird ein Vector-Objekt mit einer Liste aller Spiele an den Server übergeben, der diese
Spielerliste dann dem Admin anzeigt. Des Weiteren zeigt das ServerWindow an, ob der Server
überhaupt gestartet ist und ob es einen Fehler beim starten des Servers gab.
2.4.4 LobbyWindow
Das LobbyWindow ist das Hauptinterface im Client und gestattet dem Nutzer den Zugriff auf alle
Funktionen, wie z. B. Registrieren, Einloggen, Chatten, einem Spiel beitreten oder eine Gruppe
erstellen.
Die Klasse LobbyWindow implementiert das Observer-Interface und überwacht die ClientLogic
zum Erhalten von wichtigen Informationen wie z. B. die Nachricht, dass der Nutzer sich erfolgreich
eingeloggt hat oder eine Liste aller offenen Spiele.
Ein JEditorPane speichert die Chatnachrichten, dabei wird der Chat in einem HTML-Dokument
verpackt, um z. B. Systemnachrichten farblich hervorzuheben und für Fehlermeldungen einen Link
zur Hilfe anzubieten (siehe dazu auch die Klasse HelpWindow).
Zum Anzeigen der einzelnen Spiele und Turniere werden mehrere JList-Objekte mit einem
angepassten ListCellRenderer benutzt, um die wichtigsten Informationen übersichtlicher
darzustellen.
2.4.5 LobbyGameListCellRenderer
Die Klasse LobbyGameListCellRenderer erbt von DefaultListCellRenderer und ist für die Anzeige
der offenen Spiele und Turniere in der Lobby verantwortlich. Wenn ein Spielobjekt angezeigt
werden soll, dann erstellt der ListCellRenderer ein GameListLabel, bei einem Turnier ein
TournamentListLabel.
2.4.6 GameListLabel bzw. TournamentListLabel
Diese beiden Klassen erben jeweils von JLabel und stellen die verschiedenen Informationen von
einem Spiel (z. B. Spieler und maximale Zugzeit) bzw. einem Turnier (z. B. Name und Startzeit) so
dar, dass die einzelnen Informationen ausgerichtet sind und bei mehrere Spielen und Turnieren
jeweils untereinander stehen. Dazu bekommt jede Informationen einen gewissen Anteil der
Gesamtbreite und in der überschriebenen Methode paintComponent() werden die Informationen an
einem bestimmten Platz gezeichnet.
Uni Rostock – WS 08/09 12/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
2.4.7 GameWindow
Die abstrakte Klasse GameWindow stellt alle wichtigen Funktionen bereit, die zum Spielen eines
Spieles wichtig sind. So fordert die Methode getProfile() die wichtigsten Daten zum Spieler an,
makeMove() gibt die gesetzten Koordinaten an das Spiel weiter und sendChatMessage() verschickt
die eingegebene Nachricht an den Gegenspieler.
Sie implementiert außerdem das Observer-Interface und überwacht das jeweilige Spiel um
Änderungen dem Nutzer anzuzeigen. Bei Änderungen am Spielfeld wird die abstrakte Methode
updateField() aufgerufen, die dem eigentlichen Spielfenster anordnet das Spielfeld neu zu zeichnen.
Die einzelnen Felder werden als FieldButtons dargestellt. Dies ermöglicht gleichzeitig die
Darstellung von Icons (z. B. Spielfiguren) und eine einfache Zuordnung von durch Klicks auf die
Felder ausgelösten ActionEvents zu den Feldkoordinaten.
2.4.8 FieldButton
Die Klasse FieldButton erbt von JButton führt als neue Eigenschaft Koordinaten ein. Zusätzlich
wird der Button standardmäßig auf Transparent gesetzt, sodass der Hintergrund des Spielfeldes
immer sichtbar ist und nur durch z. B. die Spielfiguren verdeckt wird.
2.4.9 ReversiWindow
Die Klasse ReversiWindow erbt von GameWindow. Sie ist nur für die eigentliche Anzeige des
Spielfensters, des Feldes und der Steine verantwortlich.
Zur Anzeige des Hintergrundes wird ein Objekt der Klasse ImagePanel als oberstes Container-
Element des Fensters gesetzt. Alle anderen Komponenten wie Labels werden als Kindelemente
eingefügt. Durch die Transparenz der Komponenten bleibt das Hintergrundbild auch weiter sichtbar.
Das Fenster nutzt zur Anzeige von Informationen eine gesonderte Schriftart, die zum Design
passend gewählt ist und frei nutzbar ist.
2.4.10 ImagePanel
Die Klasse ImagePanel erbt von JPanel und fügt lediglich die Unterstützung für ein Hintergrundbild
hinzu.
2.4.11 LobbyUpdate und GameUpdate
Die Klassen LobbyUpdate und GameUpdate werden beim Observable-Update an die Observer
übergeben. Dort sind alle nötigen Statusänderungen gespeichert.
Uni Rostock – WS 08/09 13/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
2.4.12 TournamentWindow
Die Klasse TournamentWindow dient zur Darstellung des Turnieres (Übersicht über alle
teilnehmenden Spieler und Turnierbaum). Sie ist nicht für die Verwaltung der einzelnen Spielfenster
verantwortlich.
2.4.13 TournamentTreePanel
Die Klasse TournamentTreePanel erbt von JPanel und ist für die eigentliche Darstellung des
Turnierbaumes verantwortlich. Sie implementiert zusätzlich das Scrollable-Interface, damit größere
Turnierbäume nur ausschnittsweise dargestellt werden können.
2.4.14 ShowGroupWindow
Die Klasse ShowGroupWindow erlaubt dem Gruppenadministrator das Verwalten seiner Gruppe
und allen anderen vollen Mitgliedern Einsicht in die Gruppe. Dazu gehört neben dem Gruppentext
und der Zugangseinstellung auch die Mitgliederverwaltung. Dazu wird die Mitgliederliste in einem
eigenen JPanel angezeigt, welches ein GridLayout erhält. Für den Gruppenadministrator wird neben
einem Mitglied eine Auswahl an JCheckBoxen (zum Entfernen und Akzeptieren von Anwärtern)
und JGroupBoxen (zum Befördern eines Mitgliedes zum Gruppenadministrator) angezeigt.
Anwärter werden für normale Mitglieder nicht angezeigt.
2.4.15 HelpWindow
Die Klasse HelpWindow zeigt die verschiedenen Hilfeseiten im HTML-Format an. Dabei kann es
auch eine bestimmte Hilfeseite anzeigen, z. B. die Erklärung einer Fehlermeldung nachdem der
Nutzer auf diese geklickt hat.
Uni Rostock – WS 08/09 14/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
3 Server-Client-Kommunikation
3.1 Ablauf eines Spielzuges
Das GameWindow erhält die Koordinaten des vom Nutzer ausgewählten Feldes und ruft
Game.makeMove(x, y) auf. Game.makeMove(x, y) erzeugt das XML-Dokument und
ClientLogic.sendDoc(xml) übermittelt dieses an den Server. Der ListenThread des Servers, für den
entsprechenden Client, empfängt das Dokument und ruft ServerLogic.received(xml) auf, welcher
das Dokument verarbeitet und über send(sock, xml) an beide Spieler übermittelt. Diese werten,
ähnlich wie die ServerLogic, das Dokument aus und rufen im entsprechenden Spielobjekt
setMove(x, y) auf. Dort wird calcMove(x, y) aufgerufen, was erst die eigentliche Änderung des
Spielfeldes bewirkt.
Abbildung 2 verdeutlicht dies anhand eines Sequenzdiagrammes.
3.2 Ablauf eins Turnieres
Nachdem ein Turnier mit openTournament erstellt wurde, erhält der erstellende Spieler eine
joinTournament-Nachricht. Andere Spieler senden zum Beitritt eines Turnieres eine
joinTournament-Nachricht und erhalten eine joinTournament-Nachricht als Antwort.
Bei Erhalt der joinTournament-Nachricht, welche als JoinGameResult ein OK enthält, erstellt die
ClientLogic das Turnierobjekt.
Sobald die Startzeit des Turnieres erriecht ist, schickt der Server eine joinGame-Nachricht an alle
Spieler die an einem Spiel in der aktuellen Runde teilnehmen. Zur Aktualisierung des
Turnierbaumes wird eine tournamentInfo-Nachricht an alle Spieler geschickt. Danach bekommen
alle Spieler in einem Spiel eine startGame-Nachricht.
TournamentInfo-Nachrichten werden bei folgenden Ereignissen an alle Spieler geschickt:
• Ein Spieler betritt das Turnier
• Eine neue Runde wird gestartet
• Ein Spiel wird entschieden
Falls ein Spiel unentschieden gespielt wird, wird das Spiel nicht gewertet und ein neues Spiel
gestartet. Dies wird solange wiederholt, bis ein Spieler gewonnen hat.
Uni Rostock – WS 08/09 15/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
3.3 Login
Abbildung 3 beschreibt die Kommunikation zwischen Client, Server und Datenbank bei einem
Login-Vorgang.
Bei einem Login sendet die ClientLogic mit Hilfe von sendLogin Name und Passwort an den
Server. Dieser ruft checkPassword der Datenbank auf, erhält von dieser ein Spielerobjekt und
übermittelt dieses wieder an den Client.
Abbildung 3.1: Sequenzdiagramm eines Login-Vorganges
Uni Rostock – WS 08/09 16/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Abbildung 3.3:
Sequenzdiagramm eines
Spielzuges
Uni Rostock – WS 08/09 17/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
3.4 Dokumenttypdefinition
Zur Kommunikation zwischen Client und Server werden XML-Dokumente ausgetauscht, die
folgender DTD genügen.
Uni Rostock – WS 08/09 18/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 19/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 20/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 21/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 22/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4 GUI-Design
4.1 Formularfenster
Die Formularfenster sehen wie folgt aus, wobei sie in der Größe fest und nicht durch den Nutzer
änderbar sind:
Uni Rostock – WS 08/09 23/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 24/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Uni Rostock – WS 08/09 25/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4.2 Lobbyfenster
Das Lobbyfenster sieht wie folgt aus:
Uni Rostock – WS 08/09 26/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Links befindet sich der Chat-Verlauf. In der Liste rechts oben befinden sich die offenen Spiele,
rechts unten die offenen Turniere. Durch die Buttons rechts oben kann man zwischen den
öffentlichen, gruppeninternen und gruppenübergreifend Spielen und Turnieren wählen.
Das Menü hat die folgende Struktur:
• Account
◦ Profile
◦ Login
◦ Logout
◦ Register
◦ Delete your Account
◦ Connect to Server
◦ Disconnect
• Game
◦ Create Game
◦ Create Tournament
◦ GetRanking
▪
▪
Players
Groups
• Group
◦ Show Group
◦ Create Group
◦ Join Group
◦ LeaveGroup
• Help
◦ Help
◦ About
Uni Rostock – WS 08/09 27/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4.3 Reversifenster
Das Reversifenster sieht folgendermaßen aus:
Es ist in der Größe nicht veränderbar.
Links und Rechts sieht man die jeweiligen Spieler, in der Mitte das Spielfeld. Unter dem Spielfeld
befindet sich das Eingabefeld für den Chat, welcher am unteren Rand angezeigt wird.
Die Anzahl an Steinen der Spieler werden durch „count:“ gekennzeichnet.
Der aktive Spieler wird durch den Text „it's your turn!“ unter seinem Profil und blinkenden Pfeilen
markiert. Ist man selbst der aktive Spieler wird ggf. die für den Zug verbleibende Zeit angezeigt und
Felder für mögliche Züge werden wie oben gezeigt in der Spielerfarbe gekennzeichnet.
Durch Klicken auf den Spielernamen lässt sich das Profil anzeigen.
Uni Rostock – WS 08/09 28/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4.4 Turnierfenster
Das Turnierfenster sieht folgendermaßen aus:
Das Fenster ist in der Größe beliebig veränderbar. Bei Höhenveränderungen nehmen der
Turnierbaum und die Spielerliste den zusätzlichen Platz ein, bei Veränderungen der Breite nimmt
nur der Turnierbaum den zusätzlichen Platz ein. Wird das Fenster verkleinert wird analog der
Turnierbaum und die Spielerliste verkleinert.
Ist der Turnierbaum größer als der zur Verfügung stehene Platz, kann der sichtbare Ausschnitt mit
Scrollleisten verschoben werden.
Uni Rostock – WS 08/09 29/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4.5 Gruppenverwaltungsfenster
Das Gruppenverwaltungsfenster soll (für den Gruppenadministrator) folgendermaßen aussehen:
Das Fenster lässt sich vom Nutzer in der Größe nicht ändern, passt sich aber in der Höhe an die
Mitgliederzahl an.
4.6 Statistikfenster
Das Statistikfenster sieht folgendermaßen aus:
Es ist in allen Richtungen in der Größe durch den Nutzer veränderbar, die Tabelle nimmt immer die
gesamte Größe ein.
Wenn nicht genügend Platz zum Darstellen aller Spieler oder Gruppen ist, dann wird ein Scroll-
Balken angezeigt.
Uni Rostock – WS 08/09 30/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
4.7 Serverfenster
Das Serverfenster sieht wie folgt aus (gestoppt und gestartet):
Uni Rostock – WS 08/09 31/32

Projekt Softwaretechnik Entwicklerdokumentation 04. Mai 2009
Gezeigt ist die Mindestgröße. Wird das Fenster durch den Nutzer vergrößert, dann nimmt die Liste
der eingeloggten Nutzer den zusätzlichen Platz ein.
Uni Rostock – WS 08/09 32/32