Die Aufgabe gliedert sich in vier Teile (separate Abgaben, siehe Kalender). Parallel zum Entwurf Feature-getrieben losimplementieren! Jede Woche wird im/nach dem Meeting bewertet, dazu gibt es Bewertungspunkte (-/O/+/++). Checkt eure Abgaben ein und zeigt sie auf dem Mittwochstreffen (z.B. auf dem Steuerungs-Notebook).
Entwurf (A2.1)
- Strategie-Entwurf: wie sieht euer Ansatz aus? Beschreibt dies textuell (1BP)
- Diagramm(e) – Klassendiagramm ist nicht das günstigste, es bieten sich zusätzlich Komponenten- oder Zustandsdiagramme an. Das Klassendiagramm soll verwendete Klassen aus der Bibliothek ebenfalls referenzieren. (1BP)
- Falls Nebenläufigkeit erforderlich (Warum?): Sequenzdiagramm (1BP)
- Erklärungen zu den Diagrammen (1BP)
Abgabe in einem gängigen Format, textuell und/oder mit Diagrammen, z.B. als PDF, im CVS!
Implementierung (A2.2-2.4, 3 Wochen)
Realisiert jede Woche mindestens vier Features, hier Vorschläge:
Feature-Liste
- Kiste umfahren um zu schieben
- Ampel Grün anfordern
- Fahren bis zur Ampellinie und auf Grün warten
- Fahren durch die Mitte wenn Grün (Reicht die Zeit?)
- Kiste durch die Mitte schieben
- Spielfeld beachten
- Außenrum fahren OHNE Kiste (um zurück zu fahren)
- Außenrum Kiste schieben
- Gegner beobachten, Kollision vermeiden
- Gegner Strategie vorhersagen
- Entscheiden, welcher Weg (außen rum oder über die Kreuzung) günstiger ist
- Statt goto() mit drehen/vorwärts in geschickten Kurven fahren (schneller)
Zu jeden kapselbaren Feature ein Test schreiben! Pro realisierbares Feature wird je 1 BP vergeben, für den dazugehörigen Test auch 1BP. Jede Woche werden maximal vier Features bewertet (man kann vorarbeiten…)
Programmierhinweise:
- Wem die Simulation aufgrund der Geschwindigkeitsbeschränkungen zu langsam sind -> SimulationThread.setSpeedupFactor() setzen.
- Es muss zu Beginn ein FIPS.waitForData() aufgerufen werden – dies dient im ‘Real’-Spiel zur Synchronisierung der Steuerrechner, damit beide gleichzeitig beginnen!
- SimulationNavAdapter.setPosition() ist natürlich nur einmal an Anfang erlaubt.
Bewertungshinweise:
- Prüft die Werte die an rotate/turn/travel()-Kommandos an die Bibliothek übergeben werden: 0 und Double/Float NaN/Infinity führen zu unvorhersehbarem Verhalten des realen Roboters.
- CPU-auslastende while(…) {}-Schleifen und vermeidbare Thread.sleep()-Aufrufe sind böse – verwendet gescheite asynchrone Mechanismen oder Threadsynchronisierung.
- CVS vs. SVN: Wenn euer Projekt im GForge-Projekt bleibt, verwende ich das cvsstats um die 1500 Zeilen abzuchecken. Das ist gutmütiger als ein cvs|svn annotate, da es auch überschriebene/gelöschte Zeilen weiterzählt.