Re-Design-Dokument


Im Anschluß an die Re-Engineering-Phase, in der die Struktur des alten Projektes erarbeitet worden war begann die Re-Design-Phase. In dieser Phasen wurden die Use-Cases für die neuen Anforderungen an das Programm erstellt und dann eine neue Klassenstruktur entwickelt.
Ferner wurden Entwürfe zu neuen Benutzerschnittstelle erstellt. (siehe Entwurf)


Überblick über die wichtigsten Änderungen:

Durch die Umstellung auf wabenförmige Felder muß die Darstellung in der GUI fast vollständig neu erstellt werden. Dazu müssen neue Graphiken für die Felder sowie die Feldinhalte gezeichnet werden. In den Anforderungen wird verlangt, möglichst wenig Graphikdateien zu benutzen. Daher haben wir beschlossen eine eigene Klasse für die Verwaltung der Arena-Graphiken zu entwickeln, welche mit Hilfe der Java 2D API aus einigen gezeichneten Graphiken die restlichen durch Rotation und Skalierung zur Laufzeit berechnet.

Die Speicherung der Feldinhalte soll aus Gründen der Effizienz durch ein Array realisiert werden. Daher ist es sinnvoll, die Verwaltung der Felder in eine eigene Klasse auszulagern, so daß die Arena sich nur noch mit dem Spielablauf beschäftigen muß. Zu entwickeln sind hier effiziente Konzepte, um schnell auf von der Arena-Klasse benötigte Daten zuzugreifen.
Da die gesamten Daten somit in einer Klasse organisiert sind bzw. von dort aus erreichbar sind, bietet es sich an, diese Klasse zur Speicherung einer Arena in einen Objekt-Stream zu serialisieren. Damit wird es nicht nur möglich sein, einen Arena-Designer zu schreiben, um neue Arenen zu entwickeln, sondern auch während des Spiels (z.B. im Pausenmodus) ein bereits begonnenes Spiel zu laden bzw. zu speichern.
Da dem Roboter die reale Arenagröße nicht bekannt ist, ist es unzweckmäßig, ein Array zur Speicherung der erkundeten Strecke zu verwenden. Sinnvoller ist es, die bestehende Speicherung per Referenzen anzupassen.

Um ein Mogeln der Roboter so weitestgehend wie möglich auszuschließen, werden die Roboterdaten von der Roboterstrategie getrennt. Die Arena übergibt einem Roboter jeweils ein oder mehrere Datencontainer, wenn sie mit ihm kommuniziert. (siehe Sequenzdiagramme) Diese Datencontainer werden bei jeder Kommunikation neu erstellt, damit eventuelle Manipulationen durch einen Roboter keinen Einfluß auf den weiteren Spielverlauf haben.
Ein Zugriff von einem Roboter-Thread auf die Arena ist nicht vorgesehen. Die Roboter werden keine Referenz auf unsere Arena besitzen und können somit auch keine relevanten Daten verändern und auch keine Methoden der Arena aufrufen.
Die Arena und der Roboter müssen an die neue Schnittstelle angepaßt werden.
Ferner muß die Strategie des Roboters an die wabenförmigen Felder angepaßt werden.

Ein DEBUG-Modus muß entwickelt und implementiert werden. Dadurch wird es möglich sein, das Spiel schrittweise (ein Schritt = eine Roboteraktion) durchzuspielen.


Zusammenfassung der wichtigsten Änderungen:
  • Im Zuge der Umstellung auf wabenförmige Felder wird die GUI fast vollständig neu erstellt.
  • Die Speicherung der Feldinhalte wird aus Gründen der Effizienz durch ein Array realisiert.
  • Die Roboterdaten wird von der Roboterstrategie getrennt werden um das Mogeln möglichst zu verhindern.
  • Der Roboter und die Arena müssen an die neue Schnittstelle angepaßt werden.
  • Der DEBUG-Modus der Arena, durch den das Spiel schrittweise (ein Schritt = eine Roboteraktion) durchgespielt werden kann, muß integriert werden.

UML-Diagramme des neuen Projekts

Use-Case Diagramme der Integration des alten Projektes mit den neuen Anforderungen:
Klassendiagramme des neuen Programms: Diagramme, die die Aufgabe und den Nachrichtenaustausch der Klasse Arena zeigen: Diagramme, die die Struktur der Roboter-Klassen und der Strategien zeigen:

Endgültige Klassen-Diagramme des fertigen Projektes


Im Folgenden finden Sie Klassendiagramme zu den einzelnen Packages, die erstellt wurden, als die Implementierungsphase abgeschlossen wurde: