PG KOSI Entwurfsgruppe - Protokoll der Sitzung vom 10.04.2001

Prokollant: Timo Sticher

1 Formelles:

• Anwesend waren: Christian Stehno, Iris Najman, Tanja Schmedes, Jan-Ole Janssen, Niklas Mehner, Jan-Christian Marinesse, Timo Sticher
• Abwesend war: Harro Wimmel (Urlaub)

2 Programmierregeln

Ab sofort soll nicht mehr alleine und getrennt nach Client- und Server-Gruppe, sondern gemeinsam in (wechselnden) Zweiergruppen programmiert werden. Es wurden folgende regelmäßige Termine zum Programmieren vereinbart:

• Mittwoch 10-14 Uhr
• Freitag 13-17 Uhr

An diesen Terminen besteht Anwesenheitspflicht, Fernbleiben von diesen Terminen muß angekündigt und begründet werden. Dadurch sollen die vorhandenen Kommunikationsprobleme zwischen Client- und Server-Gruppe behoben werden. Besprechungen der Entwurfsgruppe werden bei Bedarf in diesen Zeiträumen durchgeführt. Grundlegende Dinge müssen innerhalb der Gruppe geklärt werden, so dürfen z.B. nicht eigenmächtig ohne Rücksicht auf die Konsequenzen für das Gesamtsystem Schnittstellen geändert werden. Die Schnittstelle zwischen Client und Server muß klarer definiert und dafür der AbstractClient wiederhergestellt werden. Im CVS dürfen ausschließlich nur compilierfähige Sourcen vorhanden sein. In diesen Sourcen dürfen weiterhin keine Funktionalitäten vorhanden sein, die beim Aufruf das System (egal ob Client und/oder Server) lahm legen bzw. abstürzen lassen.

Es soll in Zukunft eine ToDo-Liste und/oder eine Bug-Datenbank geben. Niklas schlug die Verwendung von Sourceforge vor. Christian regte außerdem an, größere Ereignisse bzw. Veränderungen in einer Version History zu dokumentieren. In Zusammenarbeit mit den Test-Beauftragten Julian und Rainer müssen das Vorgehen beim Testen sowie die konkreten Testfälle festgelegt werden. Endgültige Vereinbarungen für diese Punkte wurden nicht getroffen.

3 Festlegung von Funktionalitäten

3.1 Zuschauer bei Turnieren und Einzelspielen

Es soll folgende Zuschauer-Modi geben:

• Zuschauer können alle Karten sehen
• Zuschauer können nur die Karten des Alleinspieler und des Dummy sehen
• Zuschauer können nur die Karten des Dummy sehen
• Zuschauer sind nicht zugelassen

Der Zuschauer-Modus wird im Turnier vom Turnierleiter und im Einzelspiel vom Tischbesitzer festgelegt.

3.2 Verwaltung und Änderung von User-Daten

• Pro E-Mail-Adresse ist im System nur ein Account erlaubt.
• Beim Anmeldedialog ist es möglich, sich das Paßwort zu einem Login an die im System gespeicherte E-Mail-Adresse zuschicken zu lassen. Dieses ist nur einmal innerhalb von 24 Stunden möglich. In der E-Mail steht nur das Paßwort, nicht das Login.
• Bei der Änderung der E-Mail-Adresse wird automatisch ein neues Paßwort erstellt und an die neue E-Mail-Adresse geschickt. Dieser Vorgang kann innerhalb von 24 Stunden 3mal getätigt werden.

3.3 Verschiedenes

• Der Server soll dem Client eine Liste aller momentan eingeloggten Benutzer zur Verfügung stellen, damit im Client aus dieser Liste einzelne Benutzer an einen Tisch eingeladen werden können. Auf dem Client wird mit Hilfe der Filter-Option dadurch auch eine ``Buddy-List'' mit favorisierten Spielpartnern ermöglicht.
• Die Methode, die Himmelsrichtung eines Spielers abzufragen, muß vom Game-Objekt in das Tisch-Objekt verschoben oder kopiert werden, damit man schon vor Beginn eines Spiels die Himmelsrichtung ermitteln kann.
• Bei Einzelspielen soll fortlaufend nach Rubberbridge-Regeln abgerechnet werden. Der Tischbesitzer kann den aktuellen Punktestand löschen.

4 Entwurfsdokumente

Die Entwurfsdokumente sollen laufend erweitert und aktualisiert werden. Es soll nicht nur die Funktionalität, sondern auch deren konkrete Umsetzung beschrieben werden (Was ist in welcher Klasse/Methode wie implementiert ?). Einschränkungen der Funktionalität, die beim Programmieren festgestellt werden, sollten möglichst immer sofort dokumentiert werden.

5 Nächste zu erledigende Aufgaben

Der vorhandene Source-Code muß nach den oben erwähnten Kriterien ``aufgeräumt'' werden. Die Schnittstelle zwischen Client und Server muß im AbstractClient klar definiert werden. Die vorhandenen Klassen müssen vollständig dokumentiert und die Entwurfsdokumente aktualisiert werden.

6 Nächste Sitzung

Der Termin der nächsten Sitzung wird noch festgelegt, in der Woche vom 16.-22.04. treffen wir uns am Mittwoch um 10 Uhr und am Freitag um 13 Uhr. Dazu kommen noch die in der PG-Sitzung am 12.04. festzulegenden Termine für die PG-Sitzung und der Termin zum Bridge spielen.