Softwarepraktikum 2010

Transkript

1 Softwarepraktikum 2010 Erstellung eines Karteneditors und eines Wegfindungsalgorithmus Lastenheft Auftraggeber Universität Paderborn Heinz-Nixdorf-Institut Fakultät für Elektrotechnik, Informatik und Mathematik Fachgebiet Softwaretechnik Warburger Straße Paderborn Paderborn, den 29. April 2010 Version 1.3

2 Inhaltsverzeichnis 1 Zielbestimmung 1 2 Produkteinsatz Übersicht Anwendungsszenario Karteneditor Wegfindungsalgorithmus Produktfunktionen Karteneditor Wegfindungsalgorithmus Produktleistungen Kartenditor Wegfindungsalgorithmus Produktdaten Wegfindungsalgorithmus Speicherung der Karte Produktcharakteristiken Hardwareumgebung Nicht-funktionale Anforderungen A Vorgaben und Hilfestellungen 15 A.1 Plattform A.2 Installation der Eclipse Modeling Tools A.3 Installation zusätzlicher Plugins A.4 Plugins vom Veranstalter Abbildungsverzeichnis 18

3 1 Zielbestimmung Ein Großteil der Funktionen moderner, technischer Systeme wird heutzutage durch Software realisiert. Die stetig steigende Komplexität von Software aufgrund erhöhter Vernetzung und steigender Anforderungen führt dabei zu neuen Herausforderungen bei der Softwareentwicklung. Um diese Komplexität zu beherrschen, werden zunehmend modellbasierte Methoden für den Softwareentwurf eingesetzt. Im Speziellen bei der Entwicklung eingebetteter Systeme, die häufig in sicherheitskritischen Bereichen eingesetzt werden, ist dabei neben der Modellierung der Systeme wichtig, dass Methoden zum Überprüfen der Modelle zur Verfügung stehen. Ein Beispiel für komplexe eingebettete System sind Roboter. Diese werden nicht nur in der Industrie zur Fertigung eingesetzt, sondern zunehmend auch in Katastrophengebieten, in denen es für den Menschen zu gefährlich ist. Hierbei müssen sie sich auf unbekanntem Gelände zurecht finden, um ein gewünschtes Ziel anfahren zu können. Dabei können die Roboter mit anderen Geräten und Robotern interagieren, um z.b. bei der Wegfindung unterstützt zu werden. Erstellung eines Karteneditors und eines Wegfindungsalgorithmus Im diesjährigen Softwarepraktikum sollen Roboter betrachtet werden, die sich in einem Gebäude bewegen können. Für die Simulation der Roboter wird daher eine Karte des Gebäudes inklusive der enthaltenen Räume, Gegenstände und Hindernisse benötigt. Ziel dieses Softwarepraktikums ist, solche Karten durch einen zu erstellenden Editor modellieren zu können, um diese in der Simulation einzusetzen. Zudem sollen die Roboter bei der Wegfindung zu einem gewünschten Ziel von einem externen System unterstützt werden. Die Erstellung eines entsprechenden Wegfindungsalgorithmus ist daher eine weitere Aufgabe im diesjährigen Softwarepraktikum. Hierfür wird dem Auftragnehmer eine Schnittstelle vorgegeben, sodass dessen Wegfindung unkompliziert in das System integriert werden kann. 1

4 2 Produkteinsatz 2 Produkteinsatz In diesem Abschnitt werden die zu erstellenden Produkte und deren Produkteinsatz beschrieben. Im Detail handelt es sich dabei um einen Karteneditor für Gebäude mit brennbaren Objekten und einen Wegfindungsalgorithmus anhand einer solchen Karte. Zuvor wird eine Übersicht über den Einsatzbereich gegebenen und ein Anwendungsszenario beschrieben, in dem die mit dem Karteneditor erstellten Karten und der Wegfindungsalgorithmus zum Einsatz kommen sollen. 2.1 Übersicht Der Anwendungsbereich des Karteneditors und des Wegfindungsalgorithmus findet sich im Entwicklungsprozess zur Spezifikation und Simulation von Robotern wieder (siehe Abb. 1). Hierbei wird dem Entwickler eine Entwurfsumgebung zur Verfügung stehen, um Roboter spezifizieren zu können. Zudem soll eine Simulationsumgebung existieren, die zur Validierung der Spezifikation dient. Diese Umgebung besteht aus der Umweltsimulation, einer Reihe von Robotersimulationen und aus verschiedenen Wegfindungsalgorithmen, die von den Robotern über die Umweltsimulation angesprochen werden können. Der Wegfindungsalgorithmus arbeitet dabei auf einer fest definierten Karte, die mit dem Karteneditor vom Entwickler erstellt wird. Entwickler entwickelt mit validiert mit erstellt Karte mit Simulationsumgebung speichert Roboter- Spezifikation simuliert Robotersimulation Sensordaten Aktordaten Umweltsimulation Entwurfsumgebung Weganfrage Wegpunkte Karteneditor Wegfindungsalgorithmus arbeitet auf Karte speichert zu entwickeln zu entwickeln Abbildung 1: Anwendungsbereich des Karteneditors und des Wegfindungsalgorithmus Im folgenden Abschnitt wird ein beispielhaftes Anwendungsszenario beschrieben, das den Einsatz der Entwicklungsumgebung verdeutlicht. 2

5 2.2 Anwendungsszenario 2.2 Anwendungsszenario Der im diesjährigen Softwarepraktikum entwickelte Karteneditor soll dazu genutzt werden, Gebäudekarten zu entwerfen, auf denen sich spezielle Roboter, die BeBots, bewegen können. Der BeBot ist ein autonom agierender, mobiler Roboter, der am Heinz Nixdorf Institut der Universität Paderborn entwickelt wurde (siehe Abb. 2). Abbildung 2: Miniroboter BeBot Im Rahmen eines Turniers am Ende des Semesters sollen mehrere BeBots in einer Simulationsumgebung simuliert werden und gegeneinander antreten. Hierbei nehmen die BeBots die Rolle von Löschrobotern bei einem Gebäudebrand ein und sind mit einem fiktiven Löschmodul ausgestattet. Im Gebäude existieren spezielle Feuermelder, die über einen Wegfindungsalgorithmus verfügen, mit dessen Hilfe sie die Roboter zu den verschiedenen Bränden führen können. Es gilt daher als zweite Aufgabe einen geeignete Wegfindung für dieses Szenario zu entwickeln. Eine detaillierte Beschreibung dieses Szenarios ist im Lastenheft zum Löschroboter zu finden. 2.3 Karteneditor Aufgabe des Auftragnehmers ist es, einen Karteneditor zu erstellen, mit dem ein Gebäudeplan aus Räumen und Gegenständen erstellt werden kann. Jeder Raum soll genau eine Zimmertür und genau einen Feuermelder besitzen. Des Weiteren soll es genau einen Flur geben, der alle Räume miteinander verbindet. Dieser hat genau eine Zimmertür und besitzt einen Feuermelder. Zur Vereinfachung soll der Plan auf einem Gitternetz angelegt werden. Ein einzelnes Element des Gitternetzes wird im weiteren Verlauf als Feld bezeichnet. 3

6 2 Produkteinsatz Der Karteneditor soll auf Basis des in Abbildung 3 gezeigten Modells entwickelt werden. Das Wurzelobjekt einer Karte ist das Map-Objekt, mit Attributen, die den Namen der Karte und deren Ausdehnung festhalten. Abbildung 3: Modell der Karte Eine Karte enthält Räume (Room). Ein Raum hat einen Namen und eine Raumnummer. Er ist rechteckig und setzt sich aus mehreren Feldern zusammen. Die Wand, die den Raum umgibt, ist bestimmen Feldern zugeordnet und befindet sich nicht zwischen den Feldern. Seine Lage auf der Karte wird durch die Position der linken, oberen Ecke der Wand des Raumes (topleftcorner) spezifiziert. Die Attribute width und length geben dessen Ausdehnung an. Ein Raum besitzt genau eine Tür (Door), die an einer der vier Wände platziert ist. Eine Illustration eines möglichen Raumes findet sich in Abb. 4. Alle Felder (Field), die nicht in einem Raum sind, gehören automatisch zum Flur. Des Weiteren enthält ein Raum Gegenstände (Item). Jeder Gegenstand kann auf einem Feld platziert sein. Es gibt Hindernisse (Obstacle), die nicht brennen können, aber von einem BeBot umfahren werden müssen. 4

7 2.4 Wegfindungsalgorithmus topleftcorner width length Door Abbildung 4: Illustration eines Raumes Es gibt drei verschiedene Arten brennbarer Gegenstände: (BurnableItem): Möbel (Furniture), Gastanks (GasTank) und elektronische Geräte (ElectronicDevice). Diese brennbaren Gegenstände haben Attribute, die einmalig definiert und zur Laufzeit nicht veränderbar sind. Hierzu gehören die burndownduration, die beschreibt, wie lange der Gegenstand brennen kann bis er abgebrannt ist, die severity, die angibt, wie gefährlich es ist, falls der Gegenstand abbrennen sollte und maxrobotsneeded, welches definiert, wie viele Roboter maximal den Brand gemeinsam löschen können. Zudem haben alle brennbaren Gegenstände das Attribut stepsuntilburneddown, das zur Laufzeit zunächst mit der burndownduration initialisiert wird und anschließend von der Simulation schrittweise heruntergezählt wird. Ein Feuer (Fire) kann bei brennbaren Gegenständen ausbrechen. Diese können anschließend von einem Löschroboter (z.b. einem Bebot) gelöscht werden. Ob und wann ein Feuer ausbricht wird allein von der Simulation festgelegt und ist nicht Bestandteil des Karteneditors. Des Weiteren hat ein Feuer ein Attribut (stepstoextinguish), das beschreibt, wie lange es dauert, um dieses zu löschen. Falls vor oder während des Löschvorgangs die burndownduration des Gegenstandes abläuft, also stepsuntilburneddown gleich null ist, so ist dieser abgebrannt und der Löschversuch fehlgeschlagen. Die Startposition des Löschroboters soll nicht im Karteneditor festgelegt werden. 2.4 Wegfindungsalgorithmus Eine Illustration einer beispielhaften Wegfindung ist in Abbildung 5 zu sehen. Wenn ein Löschroboter zu einem gewünschten Ziel fahren möchte, so muss er mit einem, zwei oder maximal drei Feuermeldern kommunizieren, die ihm bei der Navigation durch das Gebäude helfen. Die unterschiedliche Anzahl ist dadurch begründet, dass jeder Feuermelder nur die Karte seines eigenen Raumes bzw. des Flurs kennt. Möchte der Löschroboter also ein Ziel innerhalb des Raumes ansteuern, in dem er sich bereits befindet, so ist nur die Kommunikation mit einem Feuermelder notwendig. Wenn er sich auf dem Flur befindet oder in einem anderen Raum als das Ziel, so muss er mit zwei oder drei Feuermeldern kommunizieren. 5

8 2 Produkteinsatz L X L =Löschroboter X=Ziel =Hindernis =Tür =Weg =Wegpunkt Abbildung 5: Illustration einer Wegfindung Hinsichtlich der zu übertragenden Daten werden dem Löschroboter nur Wegpunkte übermittelt. Diese befinden sich entweder auf einem Feld, an dem der Löschroboter seine Fahrtrichtung ändern muss, auf einem Türfeld oder auf dem Zielpunkt. Im Beispiel will der Löschroboter von Position (4,1) zur Position (12,1). Dies meldet er dem im Raum befindlichen Feuermelder. Dieser merkt, dass das Ziel außerhalb seines Raumes ist und führt den Wegfindungsalgorithmus aus, um den Weg bis zur Zimmertür zu suchen. Dieser berechnet ihn unter Berücksichtigung der Gegenstände im Raum und unter der Einschränkung, dass Löschroboters nicht diagonal fahren können. Als Antwort liefert er eine Liste von Wegpunkten. In diesem Fall sind das (1,1) und (1,3). Den Weg von der ersten zur zweiten Zimmertür berechnet wiederum der Wegfindungsalgorithmus des Flurfeuermelders. Hierbei kann es sich um den gleichen oder einen alternativen Wegfindungsalgorithmus handeln. Ebenso verhält es sich mit der Wegfindung von der zweiten Tür bis zum schlussendlichen Ziel. Anders ausgedrückt bedeutet dies, dass jeweils eine Instanz eines Wegfindungsalgorithmus je einem Raum zugeordnet ist. Die Gesamtfunktionalität der Feuermelder und der Wegfindungsalgorithmus für den Flur sind in der Umweltsimulation integriert und werden vom Auftraggeber umgesetzt. Der Auftragnehmer muss nur die Wegfindung für einzelnen Räumen realisieren. 6

9 2.4 Wegfindungsalgorithmus Hinweis: Der entwickelte Karteneditor und der Wegfindungsalgorithmus werden von den SoPra-Gruppen auf einer Messe präsentiert und können von den SWTPra- Gruppen gekauft werden. Im Gegenzug präsentieren die SWTPra-Gruppen Editoren für eine Roboter-Entwicklungsumgebung. Die SWTPra-Gruppen erstellen dabei nicht alle benötigten Editoren, sondern entwickeln entweder Komponenten- und Verteilungseditoren zur Spezifikation der Struktur eines Roboters, oder Editoren für Zustandsautomaten zur Spezifikation des Verhaltens. Die jeweils fehlenden Editoren erwerben die SWTPra-Gruppen ebenfalls von anderen SWTPra-Gruppen auf der Messe und integrieren die Editoren nach der Messe in ihre Umgebung. Auf der Messe können die SoPra-Gruppen jeweils eine SWTPra-Gruppe beauftragen ihnen eine komplette Entwicklungsumgebung für Roboter zur Verfügung zu stellen. Obwohl für alle SWTPra-Gruppen ein Fertigstellungstermin für die Entwicklungsumgebung mit allen Editoren vom Auftraggeber vorgegeben ist, sollten die SoPra-Gruppen eigene Liefertermine für die Roboter- Entwicklungsumgebung mit der SWTPra-Gruppe ihrer Wahl aushandeln. Mit der erworbenen Entwicklungsumgebung soll anschliessend ein Löschroboter entwickelt werden, der im Rahmen eines Turniers am Ende des Semesters gegen die Löschroboter der anderen Gruppen antritt. Ein entsprechendes Lastenheft wird im Verlauf des Semesters vom Auftraggeber zur Verfügung gestellt. 7

10 3 Produktfunktionen 3 Produktfunktionen In diesem Abschnitt werden die Produktfunktionen beschrieben, welche der Karteneditor und der Feuermelder bereitstellen müssen. Besondere Ansprüche an diese Funktionen werden in Abschnitt 4 aufgeführt. 3.1 Karteneditor Um die entwickelten Löschroboter zu simulieren, wird eine Karte der Umgebung benötigt, auf der die Roboter agieren können. Diese soll mit einem Karteneditor erstellt werden. Abb. 6 zeigt ein Use-Case-Diagramm für den Karteneditor. Die enthaltenen Use-Cases werden nachfolgend erläutert. Karteneditor A1: Karte anlegen/ bearbeiten/löschen A2: Raum anlegen/ bearbeiten/löschen A3: Gegenstand anlegen/bearbeiten/ löschen Anwender A4: Karte validieren A5: Karte laden/speichern Abbildung 6: Use-Cases: Karteneditor Use-Case A1: Karte anlegen/bearbeiten/löschen Es soll möglich sein, eine neue Karte anzulegen, zu bearbeiten und auch wieder löschen zu können. Die Bearbeitung der Karte betrifft ihren Namen und ihre Dimensionen Use-Case A2: Raum anlegen/bearbeiten/löschen Auf einer Karte sollen neue Räume angelegt werden können. Jeder Raum hat genau eine Tür, deren Position an der Grenze des Raums veränderbar sein soll. Des Weiteren sollen der Name, die Position und die Dimensionen des Raums bearbeitbar sein. 8

11 3.2 Wegfindungsalgorithmus Use-Case A3: Gegenstand anlegen/bearbeiten/löschen Innerhalb von Räumen sollen Gegenstände angelegt werden können. Gegenstände können Hindernisse oder brennbare Objekte wie Möbel, elektronische Geräte oder ein Gastank sein. Für brennbare Gegenstände sind die Eigenschaften des potentiellen Brandes anzugeben, wie dessen Schweregrad, die Brenndauer und die maximale Anzahl der zur Löschung benötigten Roboter Use-Case A4: Karte validieren Es ist möglich, die Karte bzgl. der Validitätskriterien aus Abschnitt 4.1 zu überprüfen. Schlägt die Validierung fehl, muss der Benutzer geeignet (z.b. durch ein Dialogfenster) darüber informiert werden, oder es muss dafür gesorgt werden dass keine invaliden Karten erstellt werden können Use-Case A5: Karte laden/speichern Die Karte kann jederzeit in dem in Abschnitt 5.2 beschriebenen Format gespeichert werden. Gespeicherte Karten können zu einem späteren Zeitpunkt wieder geladen und weiter bearbeitet werden. 3.2 Wegfindungsalgorithmus Die Feuermelder verfügen über einen Wegfindungsalgorithmus, der von der Umweltsimulation angesprochen wird. Abb. 7 zeigt ein Use-Case-Diagramm für den Wegfindungsalgorithmus. Der enthaltene Use-Case wird nachfolgend erläutert. Wegfindungsalgorithmus Umweltsimulation B1: Wegpunkte zu gewünschtem Ziel bereitstellen Abbildung 7: Use-Cases: Wegfindungsalgorithmus Use-Case B1: Wegpunkte zu gewünschtem Ziel bereitstellen Der Wegfindungsalgorithmus muss auf eine Zielanfrage eines Löschroboters hin eine Liste aller Wegpunkte des Wegs zum entsprechenden Ziel liefern. Der Start- und der Zielpunkt sind innerhalb eines Raums lokalisiert, wobei Start und Ziel auch Türen sein können. 9

12 4 Produktleistungen 4 Produktleistungen Der Karteneditor und der Wegfindungsalgorithmus müssen, neben der Bereitstellung der in Abschnitt 3 beschriebenen Funktionen, bestimmte Anforderungen erfüllen. Dabei wird zwischen verbindlichen und optionalen Anforderungen unterschieden. Die verbindlichen Anforderungen müssen vom Auftragnehmer erfüllt werden, die optionalen können freiwillig umgesetzt werden. 4.1 Kartenditor Verbindlich Jede Gegenstandklasse (Hindernis, Möbel, elektronisches Gerät, Gastank) hat ein eindeutiges Icon. Wandfelder und Raumtüren sind genau ein Feld breit und lang. Die Eigenschaften eines brennbaren Objekts (Brenndauer, Schweregrad, Anzahl benötigter Roboter zum Löschen) sollen in der Properties View editiert werden können. Optional Das Positionieren der Kartenelemente (Räume, Gegenstände) ist per Drag&Drop aus der Palette realisiert. Räume sind als in der Größe veränderbares Rechteck umgesetzt. Zur Verbesserung der Übersicht des Benutzers gibt es in der Outline View eine Übersicht der Karte, welche die gesamte Karte und den aktuell angezeigten Ausschnitt in Relation zueinander zeigt (siehe z.b. Markierung 4 in Abb. 8). Man kann in die Karte hinein und aus ihr heraus zoomen. Die Position der Tür eines Raums ist per Drag&Drop in der Karte veränderbar. Validität einer Karte Eine Karte ist valide, wenn folgende Kriterien gelten: Es sind keine Gegenstände im Flur abgestellt. Es ist maximal ein Gegenstand pro leerem Feld, welches nicht von einer Wand/Tür belegt ist, platziert. 10

13 4.1 Kartenditor Abbildung 8: Kartenübersicht in Outline View (Markierung 4) Da sich die Löschroboter nicht diagonal bewegen können, befinden sich Türen nicht in den Raumecken. Räume überlappen sich nicht, haben also auch keine gemeinsame Wand. Es sind keine Gegenstände oder Räume (auch teilweise) außerhalb der Karte platziert. Es sind alle brennbaren Objekte für die Löschroboter erreichbar (Optional). Diese Kriterien lassen sich zum einen durch eine gesondert ausführbare Überprüfung absichern. Eine solche Offline-Überprüfung würde man typischerweise vor dem Abspeichern einer Karte durchführen. In diesem Fall wird eine invalide Karte mit einer geeigneten Fehlermeldung quittiert. Diese Form der Überprüfung ist verbindlich. Zum anderen können die Eigenschaften auch dadurch abgesichert werden, dass invalidierende Aktionen beim Editieren der Karte verboten sind. Diese Online-Überprüfung ist optional und ersetzt die Offline-Überprüfung. 11

14 4 Produktleistungen 4.2 Wegfindungsalgorithmus Verbindlich Der Wegfindungsalgorithmus soll konform zur vorgegebenen Schnittstelle sein (siehe Abschnitt 5.1). Bei fehlerhafter Weganfrage (z.b. Ziel in einer Wand) soll die vorgegebene Exception de.upb.swt.swtpra2010.extensions.wayfinding.waypointsnotfoundexception mit geeigneter Fehlermeldung ausgelöst werden. 12

15 5 Produktdaten Das zu entwickelnde Produkt muss einigen besonderen Vorgaben seitens des Auftraggebers genügen. Dieses Kapitel listet vorgegebene Schnittstellen und zu speichernde Daten des zu erstellenden Produkts aus Sicht des Auftraggebers auf. 5.1 Wegfindungsalgorithmus Der Wegfindungsalgorithmus soll als Eclipse Plugin-Projekt abgegeben werden, das von der Umweltsimulation je Raum geladen und angesprochen werden kann. Für jeden Raum kann daher ein anderer Wegfindungsalgorithmus aktiv sein. Die Umweltsimulation bietet einen Extension-Point de.upb.swt.swtpra2010.extensions.wayfinding.wayfindingalgorithm an, den das Wegfindungs-Plugin in einer entsprechenden Extension implementieren muss. Für diese Extension muss eine Klasse angegeben werden, die das Interface de.upb.swt.swtpra2010.extensions.wayfinding.iwayfindingalgorithm implementiert. Das Interface verlangt dabei die Implementierung folgender Methoden: getwaypoints(field startfield, Field destinationfield):elist<field> setroom(room room):void Die Klassen Field und Room befinden sich im Paket de.upb.swt.swtpra2010.model. topology. Die Methode getwaypoints liefert hierbei eine Liste von Wegpunkten. Die Methode setroom ermöglicht das Festlegen eines Raumes für den Algorithmus. Wenn kein Weg gefunden werden kann, löst die Methode getwaypoints die Exception de. upb.swt.swtpra2010.extensions.wayfinding.waypointsnotfoundexception aus. Der Algorithmus soll in einem Paket mit dem Namen de.upb.swt.swtpra2010. simulation.wayfindingxx (XX ist die Gruppennummer) gespeichert werden. 5.2 Speicherung der Karte Die erstellten Karten können durch den Serialisierungsmechanismus von EMF in XMI- Dateien gespeichert werden. Die Dateiendung soll dabei.map lauten. 13

16 6 Produktcharakteristiken 6 Produktcharakteristiken 6.1 Hardwareumgebung Die Software muss auf einem PC mit den folgenden Spezifikation lauffähig sein: Intel Pentium-Prozessor (oder kompatible) mit 2 GHz 512 MB Arbeitsspeicher 500 MB freier Festplattenspeicher Betriebssystem: Microsoft Windows XP (verbindlich) oder höher 6.2 Nicht-funktionale Anforderungen Die Visualisierung der zu entwickelnden Plugins sollte sich an den Eclipse User Interface Guidelines (wiki.eclipse.org/user_interface_guidelines bzw. wiki.eclipse.org/ui_checklist) orientieren. Die Entwicklungssprache ist Englisch. Code und Codekommentare sind dementsprechend auf Englisch zu verfassen. Dokumente wie Pflichtenheft, Analyse- und Entwurfsdokument oder auch Protokolle können auf Deutsch verfasst werden. Codekommentare sollen im Javadoc-Format verfasst werden. Eine Javadoc-Dokumentation des Codes ist Bestandteil der Endabgabe. 14

17 A Vorgaben und Hilfestellungen Für die Entwicklung ist ein Phasenplan vorgegeben, der auf der Homepage der Veranstaltung veröffentlicht wird. Zu den gegebenen Deadlines müssen die jeweiligen Dokumente abgegeben werden. A.1 Plattform Der Karteneditor soll auf den Eclipse Modeling Tools v3.5.1 (EMT) ( eclipse.org) basieren. Die Bestandteile sind als Plugins für Eclipse zu entwickeln. Die Metamodelle wurden mit Hilfe von EMF v2.5.0 (Eclipse Modeling Framework) realisiert ( (in EMT enthalten). Der daraus generierte Modellcode wird vom Veranstalter zur Verfügung gestellt und darf nicht verändert werden. Als Rahmenwerk für die Darstellung der Grafiken ist GEF v3.5.0 (Graphical Editing Framework) einzusetzen ( (ebenfalls in EMT enthalten). Auf der Homepage der Veranstaltung bieten wir ein einfaches Beispiel an, das die Verwendung von GEF im Umgang mit einem Metamodell verdeutlicht. Außerdem findet ein GEF-Tutorium statt. Um Zugriff auf die Repositories der Veranstaltung zu erhalten, wird ein SVN Client (z.b. Tortoise SVN, oder als Eclipse-Plugin Subversive, benötigt. Hinweis: Beim Einchecken der entwickelten Plugins ist zu beachten, dass die zugehörigen bin-verzeichnisse, die den kompilierten Code enthalten, nicht mit eingecheckt werden. Dies kann sonst zu Problemen beim erneuten Auschecken bzw. Updaten der Projekte führen. Eingecheckt wird lediglich der unkompilierte Source- Code im src-verzeichnis. A.2 Installation der Eclipse Modeling Tools Zum Starten von Eclipse ist ein installiertes JDK (Java Development Kit) notwendig. Im Softwarepraktikum ist das JDK 6 Update 18 ( downloads/index_jdk6.jsp) zu verwenden. Auf der Eclipse-Homepage stehen unter die Eclipse Modeling Tools zur Verfügung. Nach dem herunterladen der.zip-datei muss diese nur noch entpackt werden. 15

18 A Vorgaben und Hilfestellungen A.3 Installation zusätzlicher Plugins Neue Plugins installiert man am besten in Eclipse selber. Dazu wählt man im Menü Help den Punkt Install New Software... woraufhin das Fenster Available Software erscheint (s. Abbildung 9). Abbildung 9: Installieren von Eclipse Plugins In dem Fenster lassen sich dann die sogenannten Update Sites eintragen, auf denen Eclipse nach möglichen Plugins suchen soll. Voreingetragen ist die Galileo Update Site, die z.b. das Subversive Plugin zum Download zur Verfügung stellt. Andere Plugins müssen über eigene Update Sites hinzugefügt werden. Dazu klickt man auf Add..., gibt der entsprechenden Seite einen beliebigen Namen und trägt die URL der Seite ein. Die folgende Tabelle enthält hilfreiche Plugins für das Praktikum und die entsprechenden Update Sites: Plugin EclEmma euml2 Free Edition Subversive SVN Team Provider Update Site Galileo Update Site, Gruppe: Collaboration 1 Bei der ersten Benutzung des SVN Team Provider Plugins wird aufgefordert, mindestens einen Subversive SVN Connector zu installieren. Hier sollten der Einfachheit halber alle ausgewählt und installiert werden. A.4 Plugins vom Veranstalter Neben den oben erwähnten Plugins, gibt es eine Reihe weiterer Plugins, die speziell für das diesjährige Softwaretechnikpraktikum vom Veranstalter (Auftraggeber) erstellt 16

19 A.4 Plugins vom Veranstalter werden. Diese Plugins werden zum Teil mit Quelltext in einem Repository und zum Teil ohne Quelltext auf einer Update-Site zur Verfügung gestellt. Das in Abb. 3 dargestellte Modell wird im Paket de.upb.swt.swtpra2010.model. topology realisiert. Zusammen mit der Schnittstelle für die Wegfindung steht das Paket mit Quelltext im Subversion-Repository unter folgender URL zur Verfügung: Die Umweltsimulation und die Turnier-Visualisierung werden im Verlauf des Projekts als Feature auf folgender Update-Site zur Verfügung gestellt: Plugin Umweltsimulation und Turniervisualisierung Update Site updatesites/branches/swtpra2010-software/ 17

20 Abbildungsverzeichnis Abbildungsverzeichnis 1 Anwendungsbereich des Karteneditors und des Wegfindungsalgorithmus. 2 2 Miniroboter BeBot Modell der Karte Illustration eines Raumes Illustration einer Wegfindung Use-Cases: Karteneditor Use-Cases: Wegfindungsalgorithmus Kartenübersicht in Outline View (Markierung 4) Installieren von Eclipse Plugins