Pflichtenheft Gruppe by sanmelody

VIEWS: 96 PAGES: 24

									Pflichtenheft Gruppe 6

Inhaltsverzeichnis

Auftraggeber.................................................................2
Auftragnehmer..............................................................2
Vorwort..........................................................................2
Aufgabenstellung..........................................................3
Ist-Analyse....................................................................6
Soll-Konzept.................................................................8

Diagramme zur Ist-Analyse
 




  run-Methode der Arena...........................................12
 




  Klassendiagramm der Arena...................................14
 




  Klassendiagramm LAR...........................................15

Diagramme zum Soll-Konzept
 




  modifizierte run-Methode der Arena........................16
 




  Use Case System...................................................18
 




  Use Case Zwischensequenz...................................19
 




  Use Case ArenaDesigner.......................................19
 




  Use Case EnergieFestlegen...................................19
 




  Use Case ArenaRobot............................................20
 




  vorläufiges Aktivitätendiagramm der Schnittstelle. .21
 




  vorläufiges Sequenzdiagramm der Schnittstelle.....22
 




  vorläufiges Interface von Arena und Robot.............23




                                                         1
  Auftraggeber
AG Softwaretechnik
Prof. Dr. Wilhelm Schäfer
Universität Paderborn

http://www.uni-paderborn.de/cs/ag-schaefer/



  Auftragnehmer
Eine Gruppe von Studenten der Informatik der Universität Paderborn:

Stefan Henkler              (shenkler@upb.de)
Andreas Maas                (maasand@upb.de)
Christian Niggemeyer        (nigchr@upb.de)
Matthias Reuter             (cmreuter@upb.de)
Alexander Rüther            (matlock@upb.de)
Markus Sanders              (msanders@upb.de)
Stefan Scharberth           (schabo@upb.de)
Christian Schmitt           (chrisch@upb.de)



  Vorwort
   Allgemeines

Im Rahmen des Informatikstudiums an der Universität Paderborn findet ein
einsemestriges Softwaretechnikpraktikum statt. Dieses Praktikum soll den Studierenden
einen ersten Eindruck von industrieller Softwareproduktion vermitteln. Dazu wird anhand
einer nicht zu umfangreichen Aufgabenstellung ein Softwaresystem von der
Anforderungsspezifikation bis zur Realisierung und Übergabe in einem Team von ca. 8
Personen unter Verwendung von UML und Java entwickelt. Schwerpunkte des Praktikums
liegen in der Erfahrung einer teamorientierten Softwareentwicklung unter Benutzung
marktüblicher Werkzeuge und Methoden (Rational Rose, Configuration and Version
Management CVS).

   Zu diesem Pflichtenheft

Die hier dargestellten Diagramme, Graphiken und Spezifikationen stellen grundsätzliche
Leitlinien dar, können aber - wenn erforderlich - den Anforderungen des Programms
angepaßt werden. Insofern kann das endgütige Produkt von den hier gemachten
Angaben abweichen.
Aufgrund der Verzögerungen der Schnittstellengruppe sind einige Teile des Sollkonzepts
nicht ausreichend spezifizierbar.




                                              2
  Aufgabenstellung
   Einführung

In einem Roboterspiel befinden sich verschiedene Roboter in einer ihnen unbekannten
Arena. In der Arena befinden sich Wände, das Ziel, Teleporter, Brunnen sowie weitere
möglicherweise unbekannte Objekte. Für jede Aktion, die der Roboter durchführt, wird ihm
ein Energiepunkt abgezogen. An den Brunnen kann er sein Energiedepot wieder
auffüllen. In der Arena sollen sie sich zurecht finden und diverse Karten einsammeln. Aus
den aufgesammelten Karten berechnet sich der Punktestand jedes Roboters. Wenn ein
Roboter den Ausgang gefunden und betreten hat, endet das Spiel, und eine Rangliste der
Roboter wird erstellt. Versucht ein Roboter zu betrügen, zum Beispiel indem er sich
selber Karten gibt, wird dies durch die Arena automatisch erkannt und der Roboter zur
Disqualifikation vorgeschlagen.

   Konkrete Aufgabe

Jede Gruppe soll eine Arena und einen Roboter entwickeln. Die Roboter sollen nach
Gegenständen in der Arena und dem Ausgang suchen. Bei den Gegenständen handelt es
sich um Spielkarten eines normalen Kartenspiels mit 4 Farben (Kreuz, Pik, Herz, Karo)
und 13 Werten (2 - 10, Bube, Dame, König, As). Wenn zwei Roboter sich treffen besteht
die Möglichkeit, Spielkarten zu tauschen. Wenn der erste Roboter den Ausgang gefunden
hat, wird das Spiel beendet und eine Punktewertung vollzogen. Die Punkte werden auf
Grund der Anzahl der Farben und Werte berechnet (ähnlich wie bei Poker); die Arena
stellt hierzu eine Bewertungsfunktion zur Verfügung.

Die Arena selbst besteht aus einer Menge von Waben (Sechsecken). Jede Wabe enthält
genau ein Objekt. Objekte sind Wände, Boden, Roboter, Spielkarten zum Aufsammeln,
oder spezielle Objekte, die bestimmte Aktionen auslösen (zum Beispiel Wurmlöcher
(ehemalig Teleporter)). 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. Es darf nur einen Ausgang geben. Falls ein Roboter den Ausgang findet kann
wahlweise das Spiel: direkt beendet werden oder nach der Runde beendet werden. Jeder
Roboter kann bis zu 5 Spielkarten tragen (vgl. Anzahl der Farben). Jede Karte darf/muß
genau einmal in der Arena vorkommen. 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. Zusätzlich muß bei den Robotern die Ausrichtung der
Roboter erkennbar sein. Jeder Roboter muß einfach und schnell einer Gruppe
zugeordnet werden können. Während des Spiels muß ein Statistikfenster eingeblendet
sein, welches die folgenden Informationen für alle Roboter enthält: Name des Roboters -
Karten des Roboters - Punkte des Roboters und einen Timer, der die abgelaufene Zeit
eines Roboters für die Ausführung einer Aktion anzeigt. Karten dürfen sich nicht ändern
und auch nicht geändert werden. Das Layout der Arena darf sich während eines Spieles
nicht ändern. Die Arena legt für jeden Roboter am Anfang die Energie fest. Ein Roboter
hat eine Maximalgrenze an Energie. Das bedeutet, daß seine Energie durch einen
Brunnen oder anderes nicht höher als seine Maximalgrenze wachsen kann. Die
Maximalgrenze ist gleichzeitig der Anfangswert der Energie pro Roboter. Das heißt, seine
Energie ist zu Anfang maximal.

Die Roboter können pro Runde entweder einen Schritt nach vorne gehen, die Richtung
ändern oder den Gegenstand, der vor dem Roboter liegt, aufsammeln. Jeder Roboter hat
                                           3
zu Beginn eine bestimmte Energie. Diese Energie wird bei jeder Aktion um eine Einheit
gesenkt. Außerdem wird diese Energie bei Kollisionen mit Wänden oder anderen
Robotern erniedrigt.

Ebenso können spezielle Gegenstände diese Energie erniedrigen oder auch wieder
erhöhen. Ist die Energie eines Roboters gleich null, dann kann der Roboter sich nicht
mehr bewegen, sondern nur noch tauschen. Wurmlöcher sind paarweise untereinander
verbunden und stellen somit den Ein- und Ausgang eines Tunnels dar. Das Wurmloch ist
verantwortlich, den Roboter auf ein freies Feld neben dem Wurmloch zu setzen, und der
Roboter muß mindestens wieder durch das Wurmloch zurückgehen können. Bedenkt,
daß ggf. mehrere Roboter durch das Wurmloch gehen können und genügend Platz
vorhanden sein muß. Falls kein Platz hinter dem Wurmloch zur Verfügung steht, wird der
Roboter auf seinen ursprünglichen Platz zurückgestellt. Alle speziellen Objekte auf den
Waben führen ihre Aktion durch 'Betreten' der Wabe durch den Roboter aus. Der Roboter
wird allerdings automatisch wieder von der Wabe des Objekts entfernt, da ja nur ein
Objekt pro Wabe existieren darf. Kein Objekt darf umdefiniert werden, d.h. ein Brunnen
muß immer Energie zuführen und nicht entfernen.

Ein Spiel läuft in folgender Form ab:
    1. Laden der Roboter
    2. Solange kein Roboter das Ziel erreicht hat
           a. Reihenfolge der Roboter bestimmen
           b. gewünschtes Kommando der Roboter abfragen und direkt ausführen (evtl.
              Energie neu berechnen)
           c. Wenn zwei Roboter nebeneinander stehen Austauschkommunikation
              starten.
    3. Punktewertung und Siegerbestimmung

Die Austauschkommunikation läuft in folgender Form ab:
    1. Roboter a schlägt einen oder keinen seiner Gegenstände zum Austausch vor.
    2. Roboter b schlägt einen oder keinen seiner Gegenstände zum Austausch vor.
    3. Wenn beide Roboter einen Gegenstand zum Austausch vorschlagen, erhält der
       jeweils andere Roboter den gegnerischen Vorschlag zur Prüfung und Bewertung.
    4. Wenn beide tauschen wollen, wird der Tausch vollzogen.

Beim abschließenden Turnier werden alle Roboter in jeder Arena gegeneinander
antreten. Während des Turniers halten alle Gruppen einen kurzen Vortrag über ihre
Arena.

Das komplette Programm muß nicht neu entwickelt werden, sondern es wird auf eine im
Softwaretechnikpraktikum SS00 entwickelte Lösung aufgesetzt. Zuerst soll in einer
Reengineeringphase das Design der alten Software ausgearbeitet werden und in einer
Designphase die neuen Anforderungen in das alte Design eingebaut werden. Die im
Sommersemster SS00 implementierte Arena bot nur die Möglichkeit für matrizenartige
Karten, das heißt in Quadrate aufgeteilt. Aus Waben (Sechsecken) bestehende Karten
sind allerdings prinzipiell besser geeignet, um Landkarten darzustellen. Es soll nun die
Umstellung auf wabenstrukturierte Karten durchgeführt werden. Um dieses Ziel zu
erreichen, muß die interne Struktur der Arena erweitert werden, der Code für die
Bildschirmdarstellung der Arena neu geschrieben werden, sowie die Strategie der
Roboter an die neue Struktur angepaßt werden. Der Roboter kann nun auf das links,
mittig und rechts vor ihm liegende Feld schauen (im SS00 konnte der Roboter nur auf das
vor im liegende Feld schauen), um zu erkennen, welches Objekt dort liegt.
                                             4
Um die Anpassung der Roboterstrategie zu vereinfachen, wird im Gegensatz zur alten
Aufgabenstellung die Bewertungsfunktion der Karten fest vorgegeben. Diese
Bewertungsfunktion ist somit für alle Arenen und Roboter identisch und wird im Laufe des
Projektes festgelegt.

Zusätzlich sollen einige Schwachstellen des ursprünglichen Design verbessert werden.
Dies betrifft die Einführung eines Stellvertreterobjektes für den Roboter, so daß der
Roboter nicht mehr die Möglichkeit hat, Operationen auszuführen, die ihm nicht erlaubt
sind. Zusätzlich ist ein Debug-Modus zu implementieren, der die Möglichkeit bietet, jede
einzelne Roboteraktion genau zu verfolgen.

Um weiterhin zu gewährleisten, daß die Roboter weiterhin mit jeder Arena interagieren
können, wird ein Schnittstellenausschuß gebildet, der aus je einem Mitglied jeder Gruppe
besteht. In diesem Ausschuß werden die Schnittstellen zwischen Arena und Roboter
definiert, sowie weitere alle Gruppen betreffende Themen diskutiert und Ankündigungen
gemacht.

Handys und Walkie-Talkies sind während des Turniers verboten. Bei Punktegleichstand
sind die Plätze gleich, das heißt, 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.

Robotern ist es nicht erlaubt, sich ein globales Abbild der Arena zu machen, es sei denn
im Zuge des Durchfahrens der Arena. D.h. ein Roboter darf nicht auf ein beliebiges Feld
der Arena zugreifen. Die Arena darf nicht durch einen Roboter verändert werden. D.h. ein
Roboter darf keine Wand hinter sich herziehen, oder ähnliches. Roboter dürfen sich
NICHT klonen. Alle Zuwiderhandlungen der Roboter werden mit Disqualifikation bestraft.
Es darf kein Roboter automatisch disqualifiziert werden. Die Arena darf keine Roboter
vernichten oder ähnliches. Diese Anfangsenergie muß für jeden Roboter gleich sein.
Roboter dürfen keine Threads benutzen, um zum Beispiel nebenläufig strategische
Analysen zu fahren.
Ein Roboter der einen anderen Roboter rammt, also auffährt, verliert Energie, der
gerammte Roboter bleibt unbeeindruckt (Fairness-Klausel).

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, muss 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.
Für die graphische Darstellung soll pro Objekt nur ein Icon/Image existieren, welches zur
Laufzeit auf die passende Größe skaliert und passend gedreht wird. Für die Roboter
dürfen drei Graphiken verwendet werden.


                                            5
  Ist-Analyse
   Übersicht über die wichtigsten Klassen

   class Arena

Die Klasse Arena ist die Hauptspielklasse. Sie ist verantwortlich für die Kommunikation
zwischen Arena und Robotern sowie zwischen Robotern untereinander. Sie verwaltet das
Spielfeld, die Spielstände, die Daten (Energie, Karten, Position der Roboter). Die
Kontrolle der Roboter erfolgt dabei durch die Unterklasse RobotController. Die Arena
implementert dabei das runnable-Interface, um durch Threads die Ausführung der
Spielzüge der Roboter parallel tätigen zu können.

siehe auch: Aktivitätendiagramm der run-Methode (Seite 12)
siehe auch: Klassendiagramm Arena (Seite 14)


   class LAR (erbt von Robot)

Die Hauptaufgabe der Klasse ist es, eine Strategie festzulegen und zu entscheiden, ob
der Roboter eine Karte aufnehmen soll.
final public Card calcNewCardValue(Card newCard) gibt die Karte zurück,
welche getauscht werden soll, oder null, wenn nicht getauscht werden soll. Bei weniger
als fünf Karten bedeutet null, die Karte aufzunehmen.
Die Strategien werden in einer Hashtable verwaltet. In den Methoden private void
evaluateExitWeight(), private void evaluateCardWeight() und bestfit()
wird die Gewichtung der Strategien ExitStrategie und CardStrategie vorgenommen, was
eine Entscheidungshilfe für die Wahl einer Strategie ist. Ein weiteres
Entscheidungskriterium ist z.B. wenn der Roboter als letzte Aktion einen Teleporter
benutzt hat und dadurch in ein unbekanntes Gebiet gekommen ist, dann die Orientierung
in dem fremden Gebiet höher einzustufen als die Suche nach Energie.
Eine wichtige Schnittstellen-Methode ist getCommand(), die mit Hilfe der oben
erwähnten Methoden (evaluateCardWeigth(), evaluateExitWeight() und
changeStrat() ), die Stragie wählt. Zusätzlich sorgt die Klasse mit der Methode
static void debugPrintln(String s) für den Debugoutput.


   class robot (erbt von Item)

Charakterisiert den Roboter. Hier werden einige Methoden für LAR implementiert, die
dann in LAR überschrieben werden. Enthält auch Methode zum Löschen eines Roboters,
final public void removeYou()

   class Map

Die Klasse Map erstellt ein Abbild der vom Roboter bereits erkundeten Umgebung
inklusive aller Gegenstände (Karten, Teleporter, Roboter). Sie ist dafür verantwortlich,
Wege zwischen zwei bestimmten Items zu berechnen (z.B. eigener Roboter - Ausgang)
und dabei die benötigte Energie zu berücksichtigen. Diese Wege kann sie als
ShortestPath Objekt zurückgeben.

                                           6
   class MapItem

Die Klasse MapItem repräsentiert ein einzelnes Feld der Arena. Es wird von der Klasse
Map genutzt um ein Abbild des vom Roboter erforschten Gebietes zu erstellen. Jedes
MapItem Object enthält links zu seinen (bisher) vier Nachbarn und einen Teleporterlink
auf ein weiteres MapItem Objekt (bzw. null). Die Klasse verfügt über Methoden zur
Verwaltung der Objekte in einem MapItem-Netzwerk, z.B. getMapItembyDirection().


   class Coordinate

Die Klasse Coordinate erstellt ein Tripel (x,y,Arena), welches jedem MapItem-Objekt eine
eindeutige Position in der von Map erstellten Umgebung zuteilt. x,y sind die Koordinaten
in einer Umgebung Arena. Die Klasse liefert Möglichkeiten um anhand der
Himmelsrichtung die Koordinaten des benachbarten MapItem Objektes in der
entsprechenden Richtung zu erhalten.


   class ShortestPath

Die Klasse ShortestPath speichert eine Kommandofolge des Typs AbstractAction, welche
dem Roboter den schnellsten Weg zu einem von ihm gesuchtem Item liefert.

siehe auch: Klassendiagramm LAR (Seite 15)




                                           7
  Soll-Konzept
Um die vohandene Software der neuen Aufgabenstellung anzupassen, müssen folgende
Änderungen gemacht werden:

   In der Arena:

Da der Roboter nicht mehr auf die Arena zugreifen darf, muß die gesamte Kommunikation
von der Arena initiiert werden. Daher muß das Interface zwischen Arena und Roboter
geändert werden. Wie dies erfolgt, ist Aufgabe der Schnittstellengruppe.
Durch die geänderte Kommunikation entfällt die Notwendigkeit der RobotControl-Klasse.

Als weitere Änderung zum vorhandenen Programm soll der Spielstand auf einem zweiten
Rechner angezeigt werden. Dadurch kann sowohl der Spielstand als auch die Arena
übersichtlicher dargestellt werden. Screenshots dafür weiter unten. Die Kommunikation
zwischen den Rechnern soll mit Hilfe des RMI-Konzeptes von Java geschehen.

Durch die Umstellung von quadratischen Spielfeldern auf sechseckige Waben ergibt sich
das Problem der Numerierung der Koordinaten. Wir haben uns auf folgendes System
geeinigt:




   run-Methode

Da der Roboter nicht mehr auf die Arena zugreifen darf, entfällt die Kontrolle des
Roboters am Anfang eines Zuges. Statt dessen müssen dem Roboter die relevanten
Daten übergeben werden. Genaueres enthält die Schnittstellendefinition. Da Roboter
ohne Energie weiter im Spiel bleiben, entfällt die Notwendigkeit der
removeDeadDisqualifiedRobots-Methode. Weiterhin muß die run-Methode an die
Erweiterung auf sechseckige Spielfelder erweitert werden.


   Der Roboter

   Klasse LAR (erbt von Robot)

In dieser Klasse muß - bei Beibehaltung der Strategien - nicht viel verändert werden:
Anpassungen an die neue Arena-Schnittstelle durch Veränderungen der Sichtweise gibt
es eventuell Probleme mit den Strategien, also die Strategien anpassen.


   Klasse Robot (erbt von Item)

Muß auf sechs Himmelsrichtungen geändert werden.


                                         8
      Klasse Map:

Zum einen muß die Map von vier auf sechs Himmelsrichtungen erweitert werden. Dabei
sind alle Methoden der Klasse Map zu überprüfen ob sie übernommen werden, geändert
oder neu erstellt werden müssen. Außerdem muß die Schnittstelle integriert werden und
alle direkten Zugriffe auf das Arena-Objekt entfernt werden. Dazu sind Eingriffe in die
interne Verwaltung der Datenverwaltung der Klasse Map erforderlich. Zusätzlich sind
folgende Bedingungen einzubauen:
 




    Teleporter statt Wurmlöcher
 




    nach dem Teleportieren darf sich die Ausrichtung des Roboters nicht ändern.


    Klasse MapItem

Sie muß ausschließlich von vier auf sechs Himmelsrichtungen umgestellt werden.


    Klasse Coordinate

Geringe Anpassungen in bezug auf die Erweiterungen der Himmelsrichtungen.


    Klasse ShortestPath

Die Klasse scheint ohne große Veränderungen übernommen werden zu können, da sie
nur die Kommandofolge speichert und nicht erstellt.


    Use Cases

     ArenaDesigner

Dieses Use Case beschreibt den ArenaDesigner, ein Programm zur Erstellung von
Arenen.
siehe auch: Use Case ArenaDesigner (Seite 19)

    System

Dieses Use Case beschreibt die Funktionalität des Hauptprogramms. Alle Aktionen, die
von Außerhalb gesteuert werden können, sind hier enthalten.
siehe auch: Use Case System (Seite 18)

    Zwischensequenz

Dies ist ein Untermenü der GUI. Hier kann man z.B. einstellen, ob man den Roboterbaum
sehen will, einen Kartentausch usw. (Der Kartentausch wird dann in einem extra Fenster
angezeigt).
siehe auch: Use Case Zwischensequenz (Seite 19)



                                            9
   EnergieFestlegen

In diesem Diagramm sind die möglichen Aktionen beschrieben, die zum Setzen der
Energie der Roboter nötig sind.
siehe auch: Use Case EnergieFestlegen (Seite 19)

   ArenaRobot

Dieses Use Case beschreibt die Kommunikation der Arena zum Robot.
siehe auch: Use Case ArenaRobot (Seite 20)


   Screenshots und Graphiken

Arena




Spielfelder




                                        10
Spielkarten




Spielstandanzeige




                    11
  Diagramme zur Ist-Analyse
Aktivitätendiagramm der run-Methode der Arena:




                                         12
13
Klassendiagramm Arena




                        14
Klassendiagramm LAR




                      15
modifizierte run-Methode der Arena




                                     16
17
Use Case System




                  18
Use Case Zwischensequenz




Use Case ArenaDesigner




Use Case EnergieFestlegen




                            19
Use Case ArenaRobot




                      20
 Schnittstellendiagramm Aktivitätendiagramm




21
Schnittstellendiagramm Sequenzdiagramm




                                         22
RobotArenaInterface




                      23
24

								
To top