Projektbeschreibung
Spielidee
In der Basisversion des Spiels befindet sich der Spieler beim Spielstart an einem bestimmten Ort eines Parks, z.B. einem Badesee. Ziel ist es über Kommandos einen bestimmten Punkt, z.B. den Parkplatz, an dem das eigene Auto geparkt ist, zu finden. Eine Struktur des Parks könnte bspw. folgendermaßen aussehen:
Der Spieler selbst besitzt allerdings kein Wissen über die Struktur des Parks, sondern bekommt immer nur Informationen über den aktuellen Ort, an dem er sich befindet. Ein vollständiger Ablauf des Spiels könnte so aussehen:
Du bist beim Baden eingedöst, langsam wird es dunkel. Bevor nachts zwielichtige Gestalten kommen, solltest Du schnell zu Deinem Auto... Du bist hier: Badesee. Es gibt Wege nach: links > links Du bist hier: Grillplatz. Es gibt Wege nach: oben rechts > oben Du bist hier: Kiosk. Es gibt Wege nach: oben rechts unten links > oben Du bist hier: Streichelzoo. Es gibt Wege nach: unten links > oben Du kannst nicht nach oben gehen. Du bist hier: Streichelzoo. Es gibt Wege nach: unten links > links Du bist hier: Eingang. Es gibt Wege nach: oben rechts links > oben Du bist nun hier: Parkplatz Glückwunsch, Du hast es geschafft :-) Gute Heimfahrt!!!
Die Attraktivität des Spiels soll später durch Deine eigenen Ideen gesteigert werden, zuerst soll aber die Basisversion umgesetzt werden, um an einem lauffähigen Spiel Erfahrungen und eigene Ideen zu sammeln.
Aufgabe 1 - Anforderungsanalyse
Fasse die obigen Beschreibungen in einer Anforderungsanalyse möglichst exakt zusammen. Du kannst auch schon weitere Ideen formulieren, die aber im Moment noch als Erweiterungsstufe gelten sollen. Weitere Informationen zur Anforderungsanalyse und dem Wasserfallmodell findest Du beim Projekt Space Invaders.
Modellierungsidee
Passend zur obigen Projektidee ist auch ein Grundgerüst einer Modellierung gegeben:
Aufgabe 2 - Diskussion des Klassendiagramms
Mache Dich mit dem Klassendiagramm vertraut. Erkläre es umfassend und diskutiere eventuelle Alternativen.
Implementierungsideen
Für die verschiedenen Klassen existieren schon einige Implementierungsideen:
- In der Klasse
Ort
werden Orte definiert und Wege zwischen Orten gebaut.
Um einen Weg zwischen zwei Orten mit Hilfe der MethodebaueWeg
zu bauen, soll es reichen den Weg von einem der Orte aus zu bauen. Verbindet man also den Badesee nach links mit dem Grillplatz, soll dieser automatisch nach rechts mit dem Badesee verbunden sein. Es gibt also nur Verbindungen in der Art oben↔unten und links↔rechts.
In der MethodegetNachbarort
soll eine Zeichenkette wie "oben" o.ä. übergeben werden, die Methode gibt dann den entsprechenden Ort zurück odernull
, falls es den Ort nicht gibt.
Die Methodebeschreibung
gibt eine vollständige Beschreibung in der Art "Spielplatz. Es gibt Wege nach: oben rechts" zurück. - Im Konstruktor der Klasse
Spiel
werden alle Orte erzeugt und planmäßig verbunden. Da dasSpiel
bis auf den Zielort keinen Zugriff mehr auf die Orte benötigt, können diese als lokale Variablen im Konstruktor definiert werden. Außerdem soll der Spieler erzeugt und an den Startort, also z.B. den Badesee gesetzt werden.
Beimspielen
des Spiels soll der Spieler begrüßt werden. Solange der Spieler sich nicht am Zielort befindet, soll wiederholt ausgeführt werden:- Ausgabe des aktuellen Ortes
- Eingabe der neuen Richtung. Wie man in Java Benutzereingaben einliest, kannst Du z.B. im Anhang / Java-Schnipsel nachschauen.
- Bewegen des Spielers in die angegebene Richtung
- Der
Spieler
bekommt bei der Erzeugung seinen Startort übergeben. Beim Gehen in eine Richtung muss überprüft werden, ob es eine Verbindung in der angegebenen Richtung gibt. Falls dies der Fall ist, wird die Position des Spielers entsprechend geändert.
Aufgabe 3 - Implementierung
Falls Du Dich mit JUnit und testgetriebener Entwicklung beschäftigt hast, bietet es sich an, zuerst ein Grundgerüst der Klassen zu erstellen und anschließend die Testfälle zu erzeugen (s.u.)
Implementiere das Spiel gemäß den obigen Ideen. Das Spiel müsste damit in der Basisversion spielbar sein.
Testideen
Beim Testen der Klasse Ort
ist besonders zu testen, ob die
Verbindungen zwischen den Orten korrekt erstellt werden.
Aber auch die korrekte Belegung der weiteren Attribute sowie die Erzeugung
der Beschreibung sollte getestet werden.
Die Klasse Spiel
sollte mindestens daraufhin getestet werden,
ob das Setzen des Spielers und des Zielortes funktionieren.
Beim Spieler
sollte getestet werden, ob das Gehen an einen anderen Ort
korrekt funktioniert.
Aufgabe 4 - Testfälle entwerfen
Überlege Dir konkrete Testfälle für mindestens die oben genannten Tests. Führe die Tests durch und dokumentiere die Testfälle. Falls Du JUnit benutzt, kannst Du die JUnit-Tests auch zur Dokumentation heranziehen.
Gesamttest
Die einzelnen Klassen sind nun implementiert und getestet und die Software sollte lauffähig sein. Es fehlen allerdings noch Tests des Gesamtsystems. Man unterscheidet dabei Systemtests und Akzeptanztests. Bei Systemtests wird das Gesamtsystem - üblicherweise vom Entwickler selbst - dahingehend getestet, ob die in der Anforderungsanalyse formulierten Forderungen erfüllt sind. Bei Akzeptanztests wird überprüft, ob die Software für den Benutzer so bedienbar ist und funktioniert, wie sie es soll. Ein Teil von Akzeptanztests können z.B. Beta-Tests sein, bei denen Vorabversionen der Software an interessierte Endkunden verteilt werden. Man kann sowohl für System- als auch für Akzeptanztests Phasen und Kriterien formulieren, um systematisch zu vertrauenswürdigen Tests zu kommen. Darauf soll hier aber nicht weiter eingegangen werden.
Aufgabe 5 - Systemtest
Teste Deine Software ausgiebig. Versuche dabei typische und untypische Szenarien zu simulieren. (Benutzer geht hin und her, Benutzer läuft im Kreis, Benutzer gibt ungültige Befehle, ...). Korrigiere eventuell auftretende Fehler.
Aufgabe 6 - Akzeptanztest
Gib Deine Software einem anderen Schüler oder einem unbeteiligten Freund etc., um z.B. die Bedienbarkeit für Personen zu testen, die gedanklich nicht mit Deinem Projekt vertraut sind. Notiere die Rückmeldungen.
Iterationen des Projekts
Spätestens aus dem Akzeptanztest werden sich verschiedene Wünsche bzgl. der Funktionalität ergeben. Wahrscheinlich hattest du auch vorher schon einige Ideen, wie sich das Adventure attraktiver gestalten lässt. Das Spiel sollte nun also in einem weiteren Schritt erweitert oder verbessert werden.
Wenn Software in mehreren Wiederholungen verbessert und weiterentwickelt wird, spricht man von iterativer Softwareentwicklung (von lat. iterare ,wiederholen‘). Da Software selten einmalig entworfen und dann unverändert für lange Zeit benutzt wird, entspricht dies dem Normalfall. Bezogen auf das Wasserfallmodell bedeutet dies, dass man wie in einer Schleife wieder zur Anforderungsanalyse zurück kehrt.
Solange die Software genutzt und gepflegt wird, wiederholen sich diese Phasen, man spricht auch vom Software-Lebenszyklus.
Aufgabe 7 - Anforderungsanalyse
Untersuche die ursprüngliche Anforderungsanalyse. Welche Anforderungen wurden noch nicht umgesetzt? Welche Punkte sollten ergänzt werden? Welche Wünsche oder Anforderungen ergeben sich aus den Akzeptanztests? Überarbeite die Anforderungsanalyse entsprechend.
Aufgabe 8 - Modellierung
Überprüfe die Modellierung in Bezug auf die geänderten Anforderungen und überarbeite sie.
Aufgabe 9 - Implementierung
Implementiere die neuen und geänderten Anforderungen.
Aufgabe 10 - Testen
Führe Modul-, System- und Akzeptanztests durch.