Vorgehen
Allgemein
Vorgehen
Bedienungsanleitung

JavaDoc
Spielen!
Download
Links
Lizenz
 
Credits
Forum

Schritt-für-Schritt

Use-Case

Zuerst wurden Use-Cases erdacht und dokumentiert. Diese wurden in einer tabellarischen Ansicht festgehalten. Die Ergebnisse der Use-Case analysen sind im Use-Case Dokument im download-Bereich ersichtlich.

In diesem Schritt versuchten wir auch die Aufgabe für uns attraktiver zu gestalten und uns neue Aufgaben auszudenken. Dies gelang uns recht gut und somit ergaben sich folgende erweiterte Aufgaben, die wir uns zum Ziel setzten:

  • Hangman Animation passend zu den verbleibenden Versuchen - just for fun
  • Frei variierbare Spielfeld-Grösse
  • Mehrfarbenmodus
  • "Easy"-Modus in welchem angezeigt wird, welche konkreten Pins an korrekter Stelle stehen und welche lediglich die korrekte Farbe haben. Im "Normal" Modus wird lediglich die Anzahl Ausgegeben, ohne dass der Spieler weiss, welcher der Pins korrekt ist.
  • Mehrsprachigkeit
  • Mehrere (ev. sogar eigene) Pin Designs
  • Mehrspielermodus

... so, ich denke das sollte reichen... :-)

UML-Diagramme

Die nächste Arbeit war die Ausarbeitung eines detaillierten UML-Diagrammes. Dazu setzten wir zuerst Poseidon UML ein. Nach mehreren Datenverlusten und unbrauchbaren Diagrammen wechselten wir zu MagicDraw UML. Damit waren wir dann bis zum Projektschluss sehr zufrieden. Der einzige Nachteil an MagicDraw ist, dass es nicht kostenlos zur Verfügung steht.

Zunächst versuchten wir das Design nach dem KISS-Prinzip möglichst einfach zu halten. Kurz darauf entschlossen wir uns aber das MVC-Konzept in den Vordergrund zu stellen. Dies hatte zur Folge, dass nicht mehr alle Klassen direkt miteinander Kommunizieren sondern die Kommunikation und Kontrolle über einen Controller zu geschehen hat. Der Grösste Vorteil des MVC Konzeptes sahen wir darin, dass einzelne Komponenten (insbesondere das GUI) später problemlos durch andere Implementationen ersetzt werden können. Als Folge davon mussten für die einzelnen Komponenten Interfaces erstellt werden, welche die Kommunikationsschnittstellen regeln.

Daraus entstand dann ein erstes UML-Diagramm:

Das finale Diagramm wurde dann etwas grösser. Um die Übersichtlichkeit zu erhöhen hier die auf das Wesentliche eingedampfte Version:

Des weiteren haben wir folgende Detail-Diagramme erstellt. Sie zeigen einige Strukturen etwas genauer auf:

Ausserdem haben wir einige Vorgänge mit Sequenzdiagrammen beschrieben:

Aus diesem Diagramm erstellten wir dann ein erstes Framework bestehend aus den einzelnen Klassen und mit leeren Methoden. Da es MagicDraw erlaubt Kommentare für Klassen, Methoden und Attribute zu definieren waren auch diese bereits vorhanden und ein erstes JavaDoc konnte bereits erstellt werden.

CVS

Das erstellte Framework wurde dann in CVS eingecheckt um paralleles Arbeiten zu erleichtern. Dabei haben wir explizit nicht definiert, wer jetzt an welchen Source-Dateien oder gar Methoden arbeiten soll. Logischerweise hat sich das dann trotzdem ergeben, da die unterschiedlichen Erfahrungen in der Programmierung dazu führten, dass eine gewisse Selektion stattfand. Dies hielt mich aber als GUI-Entwickler nicht davon ab einige Dummy-Methoden im Model-Bereich zu implementieren, die ich für meine Tests benötigte. Die Person, die dann am Model zu arbeiten begann konnte dann einfach meine Änderungen erweitern/überschreiben, ohne dass dies auf Meine Arbeit negative Effekte gehabt hätte. CVS erlaubt es insbesondere Code-Konflikte (Arbeiten an der selben Code-Stelle) sehr schnell aufzulösen. Arbeiten in unterschiedlichen Regionen eines Code-Fragmentes werden von CVS weitgehend automatisch zusammengeführt.

Entwicklungsumgebung

Als Entwicklungsumgebung setzten wir von Beginn an eclipse ein. Die Software bot sich aus vielen Gründen an. Einer der Hauptgründe ist sicher die freie Verfügbarkeit. Weitere Gründe sind die gute Bedienbarkeit, Konfigurierbarkeit und eine grosse Anzahl verfügbarer Plugins. Als Nachteil ist zu erwähnen, dass eine IDE wie eclipse natürlich bedingt durch die Komplexität etwas träger arbeitet als ein einfacher Editor. Insbesondere der Startvorgang ist schon als elend langsam zu bezeichnen :-(. Dafür wird man von eclipse mit Features wie automatischer Code-Vervollständigung, Code-Formatierung, CVS-Integration, automatischer Code-Generierung und vielem mehr belohnt.

Adarvo

Um die Kommunikation im Team zu gewährleisten setzten wir Adarvo ein. Dies ist eine Groupware die uns beim Austausch von Informationen und Dokumenten sowie deren Versionierung geholfen hat.

Implementierung

Jetzt konnte die Phase der Implementierung beginnen. Neben dem reinen "hacken" wurden eine Vielzahl von Dokumenten erstellt. Hier eine Sammlung der wichtigsten Dokumente:

Die Implementierung hat besonders bei uns als unerfahrene Programmierer viel Zeit in Anspruch genommen. Prinzipbedingt ist dies aber eine recht unspektakuläre Phase, da einfach viel Code generiert wird, der erst gegen Ende ein brauchbares Egebnis erzielt.

Testing

Das Testing lieft natürlich bereits parallel zur Implementierung. Alle lauffähigen Funktionen wurden von uns getestet und bei der Einbindung in die Applikation auf Herz und Nieren geprüft. Das Testing geschah hauptsächlich auf manuelle Weise während der Implementierung wo wir auch versuchten JUnit Test-Cases für das White-Box-Testing zu erstellen. Ein Hauptproblem dabei war natürlich, dass sich keiner von uns länger mit JUnit beschäftigt hatte und eine Einarbeitung war innerhalb der kurzen Projektdauer nicht möglich. Deshalb beschlossen wir die Tests am fertigen Produkt (Black-Box-Testing) durchzuführen.

In der Testphase wurde dann ein Test-Dokument erstellt:

Dokumentation

Natürlich ist dieses Dokument nicht die einzige Dokumentation. Im rahmen des Projektes wurde noch eine komplette Dokumentation, die alle wichtigen Eckdaten zusammenfasst, erstellt.

Was wir nicht erledigen konnten

Wie das bei praktisch jedem Projekt und speziell bei Softwareentwicklung ist konnten wir leider nicht alle unsere Wünsche in die Tat umsetzen. Folgende Punkte hätten wir gerne implementiert/erledigt, fielen aber aus Zeitgründen dem Rotstift zum Opfer:

  • Mehrsprachigkeit - der Optionsdialog und die entsprechenden Events sind darauf eingestellt. Nach einem kurzen Studium der Resourcebundle-Klassen sind wir zum Schluss gekommen, dass wir dies mangels Zeit und Erfahrung noch nicht implementieren werden.
  • JUnit Testing: Einige JUnit Tests sind fertiggestellt, aber dies können wir auch nicht mit ruhigem gewissen als kompletten Applikationstest bezeichnen. Testing verschlingt halt auch sehr, sehr viel zeit.
  • Mehrspielermodus: Die Interfaces sind zwar implementiert, aber die Methoden des "HumanPlayer" konnten nicht mehr dermassen erweitert werden um die Eingabe eines Codewortes vom Benutzer zu erfragen.
  • Direktes Error-Report Mail bei Exceptions: Der GUI Dialog dafür ist implementiert und funktioniert, nur die Mail-Funktionalität fehlt noch.

Was wir zusätzlich erreichten

Wir haben auch ein paar Sachen erreichen könne, die nicht von Anfang an in diesem Umfang geplant waren:

  • Lauffähig als Applet im ".jar" Container.
  • Luaffähig als Applikation sowohl extrahiert auf dem Filesystem als auch als lokal gespeichertes ".jar" File.
  • Sauberes exception-Handling mit Ausgabe der Exceptions im GUI-Fenser, fals möglich.
  • Pin-Designs können im Package ch.skybeam.mastermind.view.image.pin abgelegt werden (sowohl im .jar als auch im Filesystem-Modus) und werden automatisch erkannt und eingebunden. Voraussetzung dafür ist lediglich die Benennung nach dem Muster:
    <DesignName><Nummer><.jpg|.gif>
    Um z.B. ein Design "MeinDesign" zu erzeugen müssen folgende Files abgelegt werden (es empfiehlt sich mindestens 6 Design-Bilder abzulegen, ansonsten kann ev. nicht mit voller Spielfeldgrösse gespielt werden):
    • MeinDesign0.gif
    • MeinDesign1.gif
    • MeinDesign2.gif
    • ...
    • MeinDesign8.gif