Pflichtenheft


Pflichtenheft Gruppe 10
Gruppenleiter: Dipl. Inf. Jörg Niere

Teilnehmer:

Nicolas Cuntz
Joachim Gehweiler
Martin Hirsch
Michael Hußmann
Volker Rödig
Christian Ruwwe
Holger Sinnerbrink
Heiko Wichmann
Markus Zarbock





Inhaltsübersicht:

  1. Auftraggeber
  2. Auftragnehmer
  3. Vorwort
  4. Zielbestimmung
  5. Produkteinsatz
  6. Produktfunktion - Produktdaten - Produktleistungen
    1. Allgemein
    2. GUI
    3. Spielablauf
    4. Ablauf einer Spielrunde
    5. Die wichtigsten Spielregeln auf einen Blick
    6. Objektdefinition
    7. Zusätzliche Forderungen

Externe Dokumente:






  1. Auftraggeber:

    2. AG Softwaretechnik
    Prof. Dr. Wilhelm Schäfer
    Universität Paderborn
    Warbuger Str. 100
    33095 Paderborn

    zurück zur Inhaltsübersicht



  2. Auftragnehmer:

    3. 9 Studenten der Informatik/ Ingenieurinformatik der Universität Paderborn

    http://www.uni-paderborn.de/fachbereich/AG/schaefer/ag_dt/sopra/SS01/Gruppe10

    zurück zur Inhaltsübersicht



  3. Vorwort:

    4. Die verwendeten Abbildungen sind beispielhafte Darstellungen. Abweichungen im Erscheinungsbild des Endproduktes sind nicht ausgeschlossen.

    N. Cuntz , J. Gehweiler , M. Hirsch , M. Hußmann , V. Rödig ,
    C. Ruwwe , H. Sinnerbrink , H. Wichmann , M. Zarbock

     Paderborn, den 1. Juni 2001

    zurück zur Inhaltsübersicht



  4. Zielbestimmung:

    5. Ziel des Projekts, das im Rahmen des Softwaretechnikpraktikums im Sommersemester 2001 an der Universität Paderborn durchgeführt wurde, war es, ein im Sommersemester 2000 bereits implementiertes Computerspiel (basierend auf dem Open-Source Spiel Realtimebattle) weiterzuentwickeln.


    Screenshot der GUI aus dem vorgegebenen Projekt


    In dem Spiel treten verschiedene Roboter in einer gemeinsamen Arena gegeneinander an. In der den Robotern zu Beginn des Spiels unbekannten Arena stehen/liegen verschiedene Objekte ( Karten, Wände, Wurmlöcher, ein Ausgang ). Das Ziel eines Roboters und somit auch das des Spiels ist es, möglichst viele Punkte durch Einsammeln von Karten zu bekommen.
    Dabei spielt natürlich die Fortbewegungsstrategie der Roboter ein wichtige Rolle.
    Betritt ein Roboter den Ausgang der Arena, wird das Spiel beendet und eine Auswertung der eingesammtelten Karten wird vorgenommen.

    Details zum Spielablauf und Spielregeln hier.

    Bei der (Weiter-)Entwicklung des Spiels galt es nicht nur, (neue) Vorgaben (siehe Aufgabenstellung) zu berücksichtigen, sondern auch Fehler auszumerzen und Designänderungen vorzunehmen. Dabei wurden folgende Phasen der Entwicklung durchlaufen (siehe Projektplan).

    In der Reengineeringphase wurde die Struktur des alten Programmes erarbeitet.
    Das hierbei erstellte Klassendiagramm, daß die komplette Struktur der zur Verfügung gestellten Resourcen zeigt, wurde als Diskussionsgrundlage für die anschließende Re-Designphase genommen.
    Um den Ablauf des Spiels grob zu skizzieren, wurde ein Sequenzdiagramm der Methode getCommand() aus der Klasse LAR sowie ein Sequenzdiagramm bzw. Aktivitätendiagramm der run() Methode aus der Klasse Arena erstellt.
    Weiterhin wurde, u.a. zur Entwicklung einer neuen Schnittstelle, eine komplette Dokumentation mittels javadoc erstellt.
    Um die Bewegungs- sowie die Kartentauschstrategien an die im folgenden neuen Anforderungen des Spiels ( Wabenförmige Felder, dadurch mehr Kartentauschpartner ) anzupassen bzw. um neue zu entwickeln, wurden die gegebenen zuerst erarbeitet.
    Dabei wurden während der Reengineeringphase Diagramme zu den einzelnen Strategien erstellt.

    zurück zur Inhaltsübersicht



  5. Produkteinsatz:

    6. Am Ende des durchgeführten Projekts wird in einem abschließenden öffentlichen Turnier (Donnerstag, den 19. Juli 2001, im Hörsal C1 der Universität Paderborn) der Roboter gegen die Roboter anderer Gruppen in veschieden Arenen antreten.

    zurück zur Inhaltsübersicht



  6. Produktfunktion - Produktdaten - Produktleistungen:

    1. Allgemein:

      • Es soll eine Arena und ein Roboter entwickelt werden.
        In der Schnittstelle zwischen Roboter und Arena ist die Kommunikation zwischen diesen Packages für alle Gruppen einheitlich festgelegt.
        • Weiterhin spezifiziert die Schnittstelle eine ebenfalls für alle Gruppen einheitliche Kartenbewertungsfunktion.
        Durch die für alle Gruppen verbindlich festgelegte Schnittstelle wird garantiert, daß sich jeder Roboter problemlos in jedem, von anderen Gruppen programmierten Spiel, einsetzen läßt.
      • Weiterhin soll ein Arenadesigner entwickelt werden, um verschiedene Arena-Szenarien entwerfen zu können.
        • Use-Case Diagramm. Stellt die möglichen Use-Cases zwischen Anwender und dem Arena-Designer dar.

      • Ziel des Spiels:
        Karten einsammeln und Ausgang finden. Bei den Karten handelt es sich um normale Spielkarten mit 4 Farben (Kreuz, Pik, Herz, Karo) und 13 Werten (2 - 10, Bube, Dame, König, As). Diese werden nach einem für alle Gruppen einheitlichen System, basierend auf Pokerregeln, bewertet.

    2. GUI:

      1. Dem Nutzer des Programms werden die folgenden, im Use-Case dargestellten Interaktionsmöglichkeiten, in der GUI zur Verfügung gestellt.
        Use-Case Diagramm der GUI

      2. Das Spielfeld (Arena) ist eine Menge von Waben (Sechsecke). Die Menge der Waben bildet
        eine (m x n)-Matrix. Dabei sind zwei sich gegenüberliegende Seiten des Sechseckes so ausgerichtet, dass sie parallel zur Ober- bzw. Unterkante des Spiefeldes angeordentet sind.

        Ausschnitt des neuen Spielfeldes

      3. Die Waben können folgende Objekte enthalten:
      4. ein leeres Feld
        		5.
      5. Wand
        		6.
      6. Wurmloch
        		7.
      7. Brunnen
        		8.
      8. Spielkarte
        		9.
        Karten können die Farben annehmen.
      9. Roboter
        		10.
      10. Ausgang / Exit (nur einen insgesamt)
        		11.
      11. Waben müssen in alle 6 Richtungen Nachbarfelder haben, somit ist die Arena immer zyklisch (allerdings kann durch Wände die Arena eingeschränkt werden.
      12. Die Arena ist alleine für die Darstellung aller Objekte (inklusive der Roboter) zuständig. Es muß eine einwandfreie Unterscheidung aller Objekte gewährleistet sein.
      13. Zusätzlich muß bei den Robotern ihre Ausrichtung eindeutig erkennbar sein. Jeder Roboter muß einfach und schnell einer Gruppe zugeordnet werden können.
      14. Während des Spiels muß ein Statistikfenster eingeblendet sein, welches die folgenden Informationen für alle Roboter enthält:
        • Name des Roboters
        • Energievorrat des Roboters
        • Karten des Roboters
        • Punkte des Roboters
        • Timer, der die abgelaufene Zeit eines Roboters für die Ausführung einer Aktion anzeigt.
      15. Das Layout der Arena darf sich während eines Spiels nicht ändern.

    3. Spielablauf:

      1. Laden der Roboter. Dies erfolgt durch den Benutzer im FileManager


        2. Screenshot des FileManagers


      2. Einstellung der Maximalenergie für alle Roboter, die zugleich deren Anfangsenergie ist.
      3. Solange kein Roboter den Ausgang betreten hat bzw. nicht allen Robotern die Energie ausgegangen ist:
        1. Reihenfolge der Roboter für aktuelle Runde zufällig bestimmen.
        2. In dieser Reihenfolge gewünschtes Kommando der Roboter abfragen und direkt ausführen.
        3. Reihenfolge der Roboter nochmals zufällig bestimmen.
        4. In dieser Reihenfolge für jeden Roboter sichtbare Nachbarn ermitteln und Austauschkommunikation starten.
      4. Am Spielende werden die Karten der Roboter bewertet und der Sieger des Spiels ermittelt.

    4. Ablauf einer Spielrunde:

      1. Ein Roboter kann pro Runde wahlweise eine von folgenden im Use-Case illustrierten Aktionen durchführen:
        Use-Case Diagramm des Roboters
        • Einen Schritt in Blickrichtung gehen.
        • Die Richtung ändern (Vielfache von 60° nach links oder rechts).
        • Eine Karte von den Feldern aufsammeln, die für ihn sichtbar sind.
        • Eine Karte auf ein Feld legen, das für ihn sichtbar ist.
        • Einen Brunnen aktivieren, um seine Energie zu erhöhen.
        • Ein Wurmloch aktivieren.
        • Den Ausgang betreten.
      2. Nach jeder Aktion wird dem Roboter ein Energiepunkt abgezogen. Alternativ kann der Roboter auch auf eine Aktion verzichten und auf dem aktuellen Feld ohne Energieverlust verbleiben. Außerdem wird seine Energie bei Kollisionen mit Wänden oder anderen Robotern erniedrigt. Ist die Energie eines Roboters <= 0 dann kann der Roboter sich nicht mehr bewegen, sondern nur noch tauschen.
      3. Nach den Aktionen der Roboter beginnt die Tauschrunde:
        • Die Roboter werden sequentiell befragt, welche Karte sie tauschen möchten.
        • Bietet ein Roboter eine Karte an, werden seine sichtbaren Nachbarn in zufälliger Reihenfolge befragt, ob sie eine Karte zum Tausch anbieten möchten. Die Austauschkommunikation wird gestartet, wenn einer dieser Roboter ebenfalls eine Karte anbietet.
        • Während der Austauschkommunikation wird jedem der beiden Roboter der Vorschlag des jeweils anderen zur Zustimmung unterbreitet.
        • Stimmen beide zu, wird der Austausch vollzogen.

    5. Die wichtigsten Spielregeln auf einen Blick:

      • Jeder Roboter kann bis zu 5 Spielkarten tragen.
      • Die Arena enthält 52 verschiedene Karten, die nicht geändert oder verändert werden dürfen.
      • Ein Roboter kann genau drei Felder sehen: das Feld in Blickrichtung und deren zyklische Nachbarfelder.
      • Ein gerammter Roboter verliert keinen Energiepunkt, sondern nur der rammende Roboter (Fairneßklausel).
      • Verstößt ein Roboter gegen die Regeln, wird er zur Qualifikation vorgeschlagen. Die endgültige Disqualifikation wird durch den Spielleiter vorgenommen.
      • Bewertung der Spielkarten ähnlich wie beim Poker
        • .
      • Bei Punktegleichstand sind die Plätze gleich, d.h. wenn zwei Roboter 50 Punkte haben und alle anderen weniger, dann stehen diese beide Roboter auf Platz 1 und der nächste Roboter steht auf Platz 3.

    6. Objektdefinitionen:


      7.

    7. Zusätzliche Forderungen:

      • Die Arena soll einen DEBUG-Modus anbieten, durch den das Spiel schrittweise (ein Schritt = eine Roboteraktion) abläuft.
      • Der Roboter soll aufgeteilt implementiert werden: Der eine Teil enthält die Roboterstrategie (Intelligenz), der andere Teil dient als Datencontainer (Stellvertreterobjekt).
      • Roboter dürfen nur im Zuge des Durchfahrens der Arena ein Abbild derselbigen entwickeln. Ebenso darf er nicht auf die Arena zugreifen, insbesondere sie nicht verändern!
      • Roboter dürfen keine Threads benutzen, um zum Beispiel nebenläufig strategische Analysen zu fahren.
      • Die Oberfläche soll in Java mit Hilfe der Swing Bibliothek implementiert werden und mindestens folgende Funktionen unterstützen: Hinzufügen eines Roboters, Disqualifikation eines Roboters, Start und Stop des Spiels, Anzeige der aktuellen Spieldauer. Die Roboter haben pro Zug eine max. Zeitspanne von 10 sec. Wenn ein Roboter diese Zeit überschreitet, wird er disqualifiziert. Um dieses überprüfen zu können, muß in der GUI der aktuelle Roboter und die abgelaufene Zeit angezeigt werden.
      • Roboter der einzelnen Gruppen sollen in separate Unterpakete von de.uni_paderborn.robots.robot.groupN (N = Gruppennummer) abgelegt werden. Dadurch ist eine einfache Integration der Roboter in verschiedene Arenen gewährleistet.
      • Das Projekt ist nach heutigen Softwaretechnik-Standards durchzuführen. Abgabedokumente beinhalten neben dem lauffähigen, kommentierten Quelltext und einer Demo-Version eine präzise informelle Anforderungsdefinition, das Design (UML-Diagramme für statische und dynamische Teile der Spezifikation (siehe Re-Design-Dokument), Testpläne und Testergebnisse sowie ein den Projektfortschritt dokumentierender Projektplan (siehe Protokolle).

    zurück zur Inhaltsübersicht