Fakultät für Elektrotechnik, Informatik und Mathematik Fachgebiet Softwaretechnik Warburger Straße Paderborn.

Transkript

1 Fakultät für Elektrotechnik, Informatik und Mathematik Fachgebiet Softwaretechnik Warburger Straße Paderborn Pflichtenheft im Rahmen des Softwaretechnikpraktikums 2009 Team 0 SOFTWARE

2

3 Inhaltsverzeichnis Zielbestimmung 2 Produkteinsatz 2 2. Beschreibung des Problembereichs Glossar Modell des Problembereichs Beschreibung der Geschäftsprozesse Taxi Aufbau eines Taxis Bewegung auf einer Karte Aufgaben Reverse Engineering 3. Einleitung Eclipse Modeling Framework Graphical Editing Framework Komponentendiagramm Paketdiagramme Interaktionseditor Simulationsvisualisierung Ausblick Produktfunktionen 8 4. Testumgebung A: Karte laden A2: Taxi laden A3: Taxi zur Inspektion auswählen A4: Überdeckung inspizieren A5: Elemente der Verteilung inspizieren A6: Interaktionsverlauf inspizieren A7: Taxi löschen A8: Simulation starten A9: Simulation pausieren A0: schrittweise Simulation A: Simulation beenden GUI Skizze Wegfindungsalgorithmus B: Wegabfrage B2: Abfrage des nächsten Feldes B3: Weg berechnen B4: Karte übergeben B5: Straße schließen

4 4.2.6 B6: Straße öffnen Produktdaten Entstehende Dateien Dateiformate cpm Dateien des Component-Editors dnm Dateien des Deployment-Editors stm Dateien des Behavior-Editors scm Dateien des Interaction-Editors map Dateien des Topologie-Editors Vorgaben Erweiterungen Produktcharakteristiken Hardwareumgebung Softwareumgebung Nichtfunktionale Anforderungen Abbildungsverzeichnis 38

5 Zielbestimmung Ein immer größerer Anteil von technischen Systemen wird heutzutage durch Software gesteuert. Aufgrund der steigenden Anforderungen an die Software wird zunehmend auf modellbasierte Methoden für den Softwareentwurf zurückgegriffen. Diese Modelle bedürfen der Möglichkeit systematisch und in einer einheitlichen Umgebung getestet zu werden. Der Auftraggeber verfügt bereits über eine Reihe von Werkzeugen für den modellbasierten Entwurf von eingebetteten Systemen sowie eine rudimentäre Simulationsumgebung. Ziel ist es diese Werkzeuge um eine integrierte Testumgebung, welche speziell auf die Entwicklung von Taxisteuerungen zugeschnitten ist, zu erweitern. Die Testumgebung soll den gesamten Entwicklungszyklus, beginnend mit dem Entwurf der Systeme, über eine möglichst realitätsnahe Simulation bis hin zur Analyse einzelner Komponenten während der Simulation, unterstützen. Für die Entwicklung von Taxisteuerungen bedarf es der Möglichkeit die einzelnen Taxis auf einer topologischen Karte zu testen. Dies erfordert die Entwicklung eines Wegfindungsalgorithmus, welcher den Taxen erlaubt sinnvoll auf der Karte zu navigieren. Dabei soll es jederzeit möglich sein, sowohl die Interaktionen zwischen den einzelnen Komponenten, als auch das Innere dieser im Detail zu betrachten. Die Testumgebung soll hierzu eine Interaktionsverlaufs-, eine Verteilungs- und eine Überdeckungsdarstellung anbieten, welche es dem Benutzer erlauben Fehler in der erstellten Taxisteuerung frühzeitig zu finden und zu beheben. Hierdurch werden der Entwicklungsprozess effizienter gestaltet und Kosten minimiert. Auf Basis dieser Entwicklungs- und Testumgebung wird exemplarisch vom Auftragnehmer eine Taxisteuerung entwickelt, sodass gewährleistet wird, dass die Software den Anforderungen des späteren, produktiven Einsatzes genügt. Das Produkt zielt auf fortgeschrittene Anwender ab, welche bereits mit Eclipse vertraut sind. Es werden allerdings weder tiefergehende Kenntnisse in Java oder den internen Strukturen von Eclipse vorausgesetzt. Die anzufertigende Dokumentation wird den Einstieg in das Produkt erleichtern.

6 2 Produkteinsatz 2 Produkteinsatz In diesem Abschnitt wird kurz erläutert, für welchen Bereich das Produkt entwickelt wird. Dazu wird im folgenden zuerst eine Übersicht des Problembereichs gegeben und in diesem Dokument verwendete Fachbegriffe erläutert. Des Weiteren werden die Zusammenhänge zwischen den einzelnen Elementen des Problembereichs durch ein Klassendiagramm spezifiziert und einzelne Geschäftsprozesse detaillierter betrachtet. 2. Beschreibung des Problembereichs Eingebettete Systeme sind elektronische Komponenten. Sie steuern elektrische Geräte jeder Art oder unterstützen Menschen bei ihrer täglichen Arbeit. Solche Systeme bestehen aus vielen Komponenten, welche oftmals auf mehrere Hardwareeinheiten verteilt sind und untereinander Informationen austauschen. Zur Entwicklung solcher Systeme wird aktuell eine Software eingesetzt, mit der es möglich ist solche Systeme zu modellieren. Dazu werden zuerst Komponenten wie Softwarekomponenten, Aktoren oder Sensoren mithilfe eines Komponenteneditors erstellt. Danach können sie mit dem Verteilungseditor auf ECUs verteilt und untereinander verbunden werden. Den Systemen können über Zustandsautomaten Verhaltensmuster hinzugefügt werden, die auf zwei verschiedene Arten simuliert werden können. Zum einen kann der Benutzer eine Reihe an Interaktionen festlegen, die das System abarbeiten soll, es ist aber auch möglich über eine so genannte Umweltsimulation zufällig Ereignisse generieren zu lassen, die dann vom System über Sensoren empfangen und verarbeitet werden. Ein Anwendungsfall sind intelligente Taxisteuerungen, welche selbstständig das Fahrzeug durch den Straßenverkehr navigieren, nach Passagieren Ausschau halten und diese gegebenenfalls zum gewünschten Ziel transportieren, sowie rechtzeitig Tankstellen ansteuern sollen. Sollte das System einmal nicht den Erwartungen entsprechend funktionieren, ist es im Moment in der Verantwortlichkeit des Nutzers, in jedem Editor zu überprüfen, ob alles richtig modelliert ist, und etwaige Fehler zu beheben. 2.2 Glossar Das Glossar erklärt die wichtigsten Fach- und programmspezifischen Begriffe, welche in diesem Pflichtenheft verwendet werden. Aktor Ein Aktor ist eine spezielle Komponente. Sie kann ausschließlich mit der Umwelt interagieren und keine Umweltereignisse wahrnehmen. Attribut Ein Attribut ist Bestandteil einer Softwarekomponente oder einer Nachricht und stellt eine Speicherstelle dar, deren Inhalt durch Zuweisungen verändert werden kann. 2

7 2.2 Glossar Bus Ein Bus ist eine Datenleitung, über welche Komponenten verschiedener ECUs miteinander kommunizieren können. ECU (Embedded Control Unit) Eine ECU ist eine Hardwareeinheit, auf welcher mehrere Komponenten kombiniert werden können. Mehrere ECUs können untereinander über Busse verbunden werden. Eingebettetes System In diesem Dokument oftmals als System bezeichnet. Interaktion Ein Informationsaustausch zwischen zwei Komponenten über deren Ports, sowohl auf einer ECU, als auch über Busse, wird Interaktion genannt. Komponente Eine Komponente stellt einen einzelnen Bestandteil einer ECU dar. Es existieren drei Arten von Komponenten: Aktoren, Sensoren und Softwarekomponenten. Eine Komponente kann über Ports mit anderen Komponenten interagieren. Nachricht Eine Nachricht wird von Komponenten über Ports an andere Komponenten versandt. Sie werden von Transitionen ausgelöst bzw. lösen sie aus. Außerdem können Ereignisse von Sensoren registriert und als Nachrichten verschickt werden. Nachrichtentyp Ein Nachrichtentyp definiert Struktur und Priorität einer Nachricht Port Ein Port bezeichnet die Schnittstelle, über welche eine Komponente mit anderen Komponenten interagieren kann. Dies geschieht über Nachrichten, die einen bestimmten Nachrichtentyp haben können. Sensor Ein Sensor ist eine spezielle Komponente. Sie kann ausschließlich Umweltereignisse wahrnehmen und an andere Komponenten weiterleiten und nicht mit der Umwelt interagieren. Softwarekomponente Eine Softwarekomponente kann im Unterschied zu Aktoren bzw. Sensoren weder Umweltereignisse wahrnehmen, noch mit der Umwelt interagieren. Sie können dies allerdings indirekt über mit ihnen verbundenen Sensoren und Aktoren. Eine Softwarekomponente verfügt über Attribute und eine Zustandsmaschine, welche das Verhalten dieser definiert. System Der Begriff System ist dem der Verteilung sehr ähnlich. Eine Verteilung wird dann als System bezeichnet, wenn sie simuliert oder realisiert wird. Taxi Der Begriff Taxi wird in diesem Dokument als Synonym für ein eingebettetes System, welches ein Taxi steuert, verwendet. Transition Eine Transition stellt einen Übergang zwischen zwei Zuständen in einer Zustandsmaschine dar. Dabei können Attribute geändert und Interaktionen ausgelöst werden. Überdeckung Eine Transition bzw. ein Zustand sind dann Teil einer Überdeckung, wenn sie in der Simulation verwendet bzw. besucht wurden. 3

8 2 Produkteinsatz Umwelt Die Umwelt beschreibt die Umgebung in der das System arbeitet. Sie sendet Umweltereignisse an die Sensoren des Systems und wird von Aktoren beeinflusst. Umweltereignis Ein Umweltereignis kann manuell oder durch die Umweltsimulation generiert werden. Dies könnte z.b. das Auftauchen eines Passagiers sein. Umweltsimulation Die Umweltsimulation generiert Umweltereignisse zum Testen eines Systems in einer möglichst realen Umgebung. Die Umweltsimulation verfügt über keine eigene grafische Benutzerschnittstelle. Verteilung Eine Verteilung ist eine konkrete Anordnung und Verbindung von mehreren Hardwareeinheiten (ECUs). Zustandsmaschine Eine Zustandsmaschine besteht aus einer Menge von Zuständen und Transitionen, sowie einem eindeutig definiertem Startzustand. Zustandsmaschinen können auch Endzustände besitzen, die keine ausgehenden Transitionen und können daher nicht wieder verlassen werden. 4

9 2.3 Modell des Problembereichs 2.3 Modell des Problembereichs In diesem Teil wird der Problembereich, in dem das zu entwickelnde System zum Einsatz kommen soll, durch ein objektorientiertes Modell dargelegt. Die in Abbildung dargestellten Klassen und Beziehungen lassen sich wie folgt beschreiben: Mit dem Komponenteneditor können drei Arten von Komponenten erzeugt werden: SWkomponenten (Softwarekomponenten), Aktoren und Sensoren. Die Komponenten werden im Verteilungseditor auf ECUs verteilt, diese wiederum können mithilfe von Bussen miteinander verbunden werden. Dies wird als Verteilung bezeichnet. Jede Komponente hat Ports, die sie mit anderen Komponenten oder Bussen verbinden. Jeder Port hat mindestens einen Nachrichtentyp, der definiert, welche der Nachrichten für sie relevant sind. Es gibt Ein- und Ausgangsports. Softwarekomponenten können Ein- und Ausgangsports besitzen, Aktoren allerdings nur Ein- und Sensoren nur Ausgangsports. Eine Softwarekomponente hat Attribute und eine Zustandsmaschine, die aus einer Menge an Zuständen und Transitionen besteht. Transitionen werden von Nachrichten ausgelöst und können dabei selbst eine oder mehrere Nachrichten verschicken. Hierfür können den Transitionen bestimmte Bedingungen zugewiesen werden, bei denen sie auslösen. Zustandsmaschinen und ihre Transitionen werden mit dem Zustandsmaschineneditor erstellt. Sensoren nehmen die Umwelt wahr und leiten Informationen an Softwarekomponenten weiter. Aktoren erhalten Nachrichten von Softwarekomponenten und interagieren mit der Umwelt. Die Umweltsimulation lädt eine Karte, auf der Taxen fahren können. Sie simuliert die Umwelt, die wiederum mit den Sensoren und Aktoren kommuniziert. Die Karte ist hier nicht als grafische Darstellung zu verstehen, sondern als Datensatz, der eine solche repräsentiert. Die Simulationsumgebung hingegen lädt Interaktionsszenarien, die mit dem Interaktionseditor festgelegt wurden. Sie simuliert dann die Verteilung für dieses Interaktionsszenario. 5

10 2 Produkteinsatz von Interaktionsszenario Interaktionseditor z u Verteilungseditor Zustand Zustandsmaschineneditor spezifiziert..* lädt und überprüft bezieht sich auf erstellt ist Anfangszustand ist Endzustand erstellt Simulationsumgebung simuliert Verteilung Taxi Zustandsmaschine Bus ECU ist angschlossen SWKomponente Att ribut 0.. benutzt OutInterface liegt auf Konnektor Komponente Sensor 0.. ist verbunden mit InInterface 2 Port -Warteschlange : Ganzzahl -Priorität : Ganzzahl Aktoren haben nur In-Interface; Sensoren haben nur Out-Interface beeinflusst Nachricht hat hat..* Nachrichtentyp spezifiziert erstellt Aktor beeinflusst Umwelt..* löst aus verschickt Bedingung +IstErfüllt() Komponenteneditor Karte simuliert Umweltsimulation Transition besitzt lädt ändert Abbildung : Modell des Problembereichs: Dieses Diagramm beschreibt den IST- Zustand der Software. Bestehende Zusammenhänge werden hier präzise festgehalten. 6

11 2.4 Beschreibung der Geschäftsprozesse 2.4 Beschreibung der Geschäftsprozesse Im Abschnitt Beschreibung der Geschäftsprozesse werden die aktuellen Abläufe beim Erstellen eines Taxis sowie die momentanen Testmöglichkeiten des Auftraggebers beschrieben. Komponente definieren Verhalten definieren Verteilung definieren Problem: Dieser Ablauf erlaubt es nicht einen Fehler im Detail zu betrachten. Verhält sich ein Taxi nicht wie gewollt, muss der Fehler direkt in den Editoren gesucht werden. [Komponente bearbeiten] [weitere Komponente def.] Simulationsvisualisierung öffnen Simulation starten [Komponente bearbeiten] [Komponente ergänzen] Abbildung 2: Der momentane Ablauf sieht das Erstellen eines Taxis (obere Teil) und das Beobachten dieses in der Simulation (unterer Teil) vor. Um hervorzuheben, dass es sich bei der Simulation um ein eigenes Werkzeug handelt, haben wir die Aktion Simulationsvisualisierung öffnen hinzugefügt. Wird während der Simulation ein Fehlverhalten beobachtet, muss der Fehler bisher manuell in den Editoren gesucht werden. Das Erstellen eines Taxis beinhaltet im Groben nur das Erstellen mehrerer Komponenten, das Definieren des Verhaltens und das Verteilen und Verbinden der Komponenten auf ECUs. Dies kann mit den vorhandenen Werkzeugen bereits effektiv umgesetzt werden. Zum Testen wird momentan eine Visualisierung der Umweltsimulation verwendet, 7

12 2 Produkteinsatz wodurch ein Fehlverhalten leichter als in den Editoren erkannt werden kann. Das Problem der vorhandenen Werkzeuge ist, dass bei einem Fehlverhalten keine weiteren Details, die zum schnelleren Finden und Beheben des Fehlers benötigt werden, betrachtet werden können. Hinweis: Hier muss genau zwischen der Simulation von eingebetteten Systemen und der Umweltsimulation unterschieden werden. Die gegebenen Werkzeuge beinhalten eine Simulation zum Verifizieren von Interaktionsszenarien. Bei der Visualisierung der Umweltsimulation handelt es sich um eine separate Software. In Abbildung 2 wird unter Simulation die Umweltsimulation verstanden. 2.5 Taxi Der Auftraggeber entwickelt bereits eigene Taxisteuerungen, sodass eindeutig definiert ist, wie ein Taxi zusammengesetzt ist und welche Probleme die Taxisteuerung lösen können muss. In diesem Abschnitt werden der vorgegeben Aufbau eines Taxis erläutert und anschließend die grundlegenden Funktionen zur Bewältigung der Aufgaben vorgestellt Aufbau eines Taxis Ein Taxi ist ein eingebettetes System, welches in vier ECUs unterteilt ist, welche gekapselt für die einzelnen Funktionsbereiche zuständig sind. Abbildung 3 zeigt den vom Auftraggeber vorgegebenen Aufbau. <<Sensor>> Positions Sensor Driving Unit < <Actor> > Under Carriage <<Sensor>> Gas Sensor Gas Unit < <Actor> > Gas Manager Gas and Driving Bus Control Unit Camera Bus <<Sensor>> Camera Camera Unit < <Actor> > Camera Manager Abbildung 3: Verteilung des eingebetteten Systems Taxi. Es wird strikt zwischen der Fahreinheit, der Benzineinheit, der Kameraeinheit und der Taxisteuerung unterschieden. Die Taxisteuerung (Control Unit) ist in diesem Diagramm leer, da der Auftraggeber keine solche zur Verfügung stellt. Im Rahmen der in Kapitel (siehe Seite ) beschriebenen, exemplarisch zu entwickelnden Taxisteuerung werden diese Komponenten ergänzt. 8

13 2.5 Taxi Bewegung auf einer Karte Ein Taxi kann sich nur eingeschränkt auf einer Karte, welche durch ein festes Gitter beschrieben wird, fortbewegen. Es kann sich nur schrittweise um jeweils eine Zelle fortbewegen. Es sind aber nicht immer alle Bewegungsrichtungen möglich Abbildung 4: Die Bewegungsmöglichkeiten eines Taxis sind stark eingeschränkt. Hinweis: Die in der Grafik angedeuteten Straßen sind nicht Teil des IST- Zustandes (Begründung siehe unten). Die in Abbildung 4 durch Zahlen markierten Felder sind nicht alle mit dem Taxi zu erreichen, oder führen zu einem Fehler:. Die Position des Taxis kann sich in einer Simulationsrunde um eins auf der x-achse verschieben. Somit sind diese Felder erreichbar. 2. Die Position des Taxis kann sich genauso um eins auf der y-achse verschieben. Somit ist auch dieses Feld zu erreichen. 3. Eine diagonale Bewegung ist nicht zulässig. Diese Felder können von der aktuellen Position nicht angesteuert werden. Der folgende Punkt beschreibt nicht den IST-Zustand und bezieht sich auf Taxis, wie sie mit der zu entwickelnden Testumgebung nutzbar sein werden. Dieser ist an dieser Stelle nur der Vollständigkeit halber aufgeführt. Die aktuellen Taxis können nicht zwischen befahrbaren Straßen und gesperrten Zellen unterscheiden. 4. Ein Verlassen der Straße, wie es das Ansteuern dieses Feldes zur Folge hätte, oder das Befahren einer gesperrten Straße, ist zwar möglich, führt allerdings zu einem Unfall. 9

14 2 Produkteinsatz Aufgaben Das Taxi muss drei verschiedene Problemtypen bewältigen. Es muss Passagiere finden und zu ihrem Ziel bringen, es muss mit Hilfe des Wegfindungsalgorithmus korrekte und intelligente Routen finden und abfahren, und sich um seine Energieversorgung kümmern. Die Umweltsimulation generiert in unregelmäßigen Abständen Passagiere und teilt den Taxis deren aktuellen Position, das gewünschte Ziel und den möglichen Gewinn mit. Ein Taxi kann einen Job allerdings erst dann annehmen, wenn es zum Passagier gefahren ist. Es ist nicht möglich im Vorhinein einen Job anzunehmen. Auch wird ein Taxi nicht informiert, wenn ein Passagier bereits von einem anderen Taxi abgeholt wurde. Ein Taxi bekommt nur dann einen Gewinn gutgeschrieben, wenn es erfolgreich einen Passagier abgeholt und zu seinem Ziel gefahren hat. Die Taxis müssen die Routen nicht selber berechnen. Sie können dazu über die Umweltsimulation mit dem Wegfindungsalgorithmus kommunizieren, welcher dem Taxi dann eine mögliche Route mitteilt. Der Wegfindungsalgorithmus muss dabei auf Grund von Baustellen gesperrte Straßen berücksichtigen. Unter Berücksichtigung der berechneten Route teilt das Taxi der Umwelt seine nächsten Aktionen über Aktoren mit. Fehler im Wegfindungsalgorithmus wirken sich somit direkt auf die Taxis aus. Taxis verfügen nicht über unbegrenzte Treibstoffvorräte. Folglich müssen sie regelmäßig Tankstellen ansteuern. Wird dies versäumt, kann sich ein Taxi nicht mehr fortbewegen. Das Taxi kann aber jederzeit seinen Treibstoffvorrat überprüfen und wird automatisch von der Umweltsimulation gewarnt, wenn diese zu niedrig werden. Auch kann sich ein Taxi jederzeit von der Umweltsimulation die nächstgelegene Tankstelle mitteilen lassen und mit Hilfe des Wegfindungsalgorithmus diese ansteuern. Dabei kann das Taxi auch mit einem Passagier an Bord auftanken. 0

15 3 Reverse Engineering 3. Einleitung Bei Eclipse handelt es sich um ein Open-Source Framework, welches zur Entwicklung unterschiedlichster Anwendungen eingesetzt werden kann. Neben der Verwendung als Entwicklungsumgebung für Java-Projekte sind Rich-Client-Applikationen (sprich erweiterbare Frameworks für Problemlösungen) der wachsende Einsatzbereich für Eclipse. Dazu bietet Eclipse eine Plattform an, um eigene Plugins bzw. Rich-Clients zu entwickeln. Diese können unabhängig von der Eclipse IDE sein. Bei der zu erweiternden Entwicklungsumgebung zur modellbasierten Entwicklung eingebetteter System handelt es sich um eine solche Sammlung von Plugins, bestehend aus Komponenteneditor, Verteilungseditor, Zustandseditor, Interaktionseditor und Simulationsvisualisierung, die auf dem Eclipse Modeling Framework und dem Graphical Editing Framework aufbauen. 3.2 Eclipse Modeling Framework Das Eclipse Modeling Framework (EMF) ist ein Hilfsmittel zur automatischen Generierung von Code aus vorher definierten Modellen. Dabei setzt EMF viele wichtige Design- Patterns um, unter anderem das für das sogenannte Model-View-Controller-Pattern (siehe unten) wichtige Observer-Pattern. Dabei wird bei jeder Änderung an einer von EMF generierten Klasse eine Meldung an alle Beobachter dieser Klasse gesendet. Darüber hinaus bietet der Serialisierungsmechanismus von EMF die Möglichkeit, Klassen intuitiv und konsistent zu speichern und zu laden, ohne ein eigenes Dateiformat und entsprechende Lade-/Speicher-Routinen implementieren zu müssen. Die für die EMF- Codegenerierung verwendeten Modelle wurden uns vom Auftraggeber zur Verfügung gestellt. Da diese den Aufbau der durch die Editoren erstellbaren Diagramme beschreiben, heißen sie in diesem Zusammenhang Metamodelle. Diese Metamodelle werden wir nicht verändern, um größtmögliche Kompatibilität zu erreichen. Aufgrund der Art und Weise, wie die Metamodelle realisiert sind, ist es aber dennoch möglich, zusätzliche Daten zu speichern und von unseren Plugins zu laden. 3.3 Graphical Editing Framework Das Graphical Editing Framework ist ein Plugin für Eclipse, welches Funktionalitäten für die Entwicklung von grafischen Editoren bereitstellt. Das Framework nimmt dem Programmierer die immer wiederkehrende Implementierung von Basisfunktionalitäten, wie dem Laden, Speichern, Editieren, Layouten, Rückgängig machen und Wiederherstellen ab bzw. vereinfacht diese. Des Weiteren werden Tools zur Markierung, Selektion und Erzeugung von grafischen Symbolen angeboten. Als Basis benötigt GEF ein Modell, welches zum Beispiel im oben erwähnten EMF realisiert werden kann. Das Modell ist Teil der in GEF-Editoren angewandten Architektur Model-View-Controller.

16 3 Reverse Engineering Model View Controller Abbildung 5: Model - View - Controller Architektur. Im Model werden die Daten gehalten, der Controller synchronisiert View und Model und der View stellt das Model grafisch dar. Die Architektur ermöglicht eine klare Trennung von Modell und der grafischen Darstellung des Modells. Jeder Editor der gegebenen Entwicklungsumgebung wurde mit GEF realisiert. 3.4 Komponentendiagramm Die bestehende Software setzt sich aus folgenden Komponenten zusammen: <<component>> Graphical Editing Framework <<component>> Eclipse <<component>> Eclipse Editing Framework {uses} {uses} GEF Schnittstelle EMF Schnittstelle <<component>> Interaction Editor <<component>> Behaviour Editor <<component>> Deployment Editor <<component>> Component Editor.scm Datei.ndm Datei. cpm Datei lädt lädt lädt.stm Datei <<component>> Help Hilfesystem für die einzelnen Editoren lädt lädt <<component>> Simulationvisualisation {uses} <<component>> Simulationsalgorithmus {uses} <<component>> Umweltsimulation Abbildung 6: Komponentendiagramm der vorhandenen Entwicklungsumgebung. EMF und GEF benutzen beide die Eclipse-Plattform. Jeder Editor verwendet sowohl GEF als auch EMF. Der Komponenteneditor erzeugt.cpm-dateien, die als Schnittstelle zum Verteilungseditor und Zustandseditor fungieren. Der Verteilungseditor erzeugt.ndm-dateien, der Zustandseditor wiederum.stm-dateien. Die.ndm-Dateien werden vom Interaktionseditor über seine Schnittstelle geladen. Im Interaktionseditor können 2

17 3.5 Paketdiagramme.scm-Dateien erstellt werden. Neben den.scm-dateien werden von der Simulationsvisualisierung.stm-Dateien über Schnittstellen geladen. Um eine Simulation durchzuführen, benutzt die Visualisierung den Simulationsalgorithmus. Der Simulationsalgorithmus berechnet Simulationsschritte für das vom Anwender modellierte eingebettete System. Dieser Algorithmus wird außerdem von der Umweltsimulation verwendet. Im Feature Umweltsimulation, ebenfalls bekannt unter der Bezeichnung Tournamentsystem bzw. Turniersystem, werden mehrere Taxis auf einer Karte simuliert. Da es sich dabei um ein Feature handelt, welches wir nicht verändern dürfen, gehen wir in unserem Diagramm nicht detaillierter darauf ein. Die Komponente Help bietet in jedem Editor Hilfe an. 3.5 Paketdiagramme Da sich die Paketstruktur der einzelnen Editoren nicht stark unterscheidet, geben wir exemplarisch nur das Paketdiagramm zum Interaktionseditor und zur Simulationsvisualisierung an Interaktionseditor Jeder der Editoren verfügt über die hier dargestellten Pakete. Lediglich die Klassenstruktur unterscheidet sich je nach Bedarf der einzelnen Editoren. Beispielhaft eine Erläuterung der Interaktionseditor-Pakete, die sich gleichermaßen auf die anderen Editoren anwenden lässt: actions Enthält die Actions, welche für das Model-View-Controller-Pattern von GEF benötigt werden. Mit den Actions werden z.b. Aktionen in Kontextmenüs und Toolbars realisiert. commands In diesem Paket sind die sogenannten Commands enthalten, welche Veränderungen am Model vornehmen, beispielsweise die Erstellung der Interaktionslinien. dialogs Dieses Paket enthält Dialoge, zum Beispiel zur Änderung der Eigenschaften einer Interaktion. figures Enthält die für GEF notwendigen sogenannten Figures, die sich um die Darstellung der Objekte kümmern. Hier gibt es zum Beispiel eine Klasse für die Interaktionslinie, welche beschreibt, wie diese darzustellen ist. parts Die sogenannten EditParts reagieren auf Änderungen an den Modellen und sorgen dafür, dass die View dem Model entspricht und dass Benutzeraktionen an die richtigen Policies weitergeleitet werden. perspective Zuständig für die Anzeige des Editors in Eclipse. policies Zuständig für die Erstellung der Commands. Außerdem ermöglichen sie Funktionen wie Verschieben von grafischen Objekten. 3

18 3 Reverse Engineering properties Die Klassen des Properties-Package sind für die Ausgabe der Eigenschaften z.b. einer Verbindungslinie in der Properties-View von Eclipse zuständig. utils Paket für Hilfsklassen. wizards In diesem Paket sind nötigen Klassen für die Wizards, beispielsweise zur Auswahl der Dateien, enthalten. Die Wizards weisen ein größeren Funktionsumfang als die Dialoge auf. So erstrecken sich die Wizards häufig über mehrere Seiten. interaction parts actions perspective outline commands policies utils nscenario onwizard dialogs properties misc figures wizards lists Abbildung 7: Paketdiagramm des Interaktionseditors: Dieses Diagramm beschreibt die Aufteilung des Interaktionseditors in seine verschiedenen Pakete. 4

19 3.5 Paketdiagramme Simulationsvisualisierung Die Simulationsvisualisierung weicht vom Aufbau etwas von den anderen Editoren ab. Die Pakete Actions, Dialogs, Figures, Parts, Perspective Policies, Utils und Wizards existieren wie bei den anderen Editoren mit entsprechender Bedeutung, lediglich Properties werden nicht benötigt. Dafür kommen einige weitere Pakete hinzu: draw2d Beinhaltet die Klasse FormattedLabel. Diese wird benötigt zum Darstellen von Text und Bildern. dialogs Beinhaltet die Klasse ReportDialog. Die Dialoge, die angezeigt werden, falls ein Interaktionsszenario einen Fehler aufweist oder erfolgreich durchgelaufen ist, werden hiermit dargestellt. simulation Beinhaltet die nötigen Klassen zum Berechnen und Darstellen der Simulation. views Dieses Paket beinhaltet die verschiedenen Ansichten in der Simulationsvisualisierung wie z.b. für das Interaktionsszenario oder die StateMachine. 5

20 3 Reverse Engineering visualization utils figures misc dep is or rd er ionscenario tionwizard figure sm parts dep actions policies is draw2d simulation sm dialogs views tree perspective wizards Abbildung 8: Paketdiagramm der Simulationsvisualisierung: Dieses Diagramm beschreibt die Aufteilung der Simulationsvisualisierung in die verschiedenen Pakete. 6

21 3.6 Ausblick 3.6 Ausblick In diesem Abschnitt möchten wir einen kleinen Ausblick darauf geben, wie das bestehende System in die zu erstellende Software einfließt. Zu berücksichtigen ist dabei jedoch, dass wir zum jetzigen Zeitpunkt nicht genau vorhersagen können, wie wir die Implementierung gestalten. Es kann also sein, dass die hier angegebenen Lösungsansätze nicht in der beschriebenen Form umgesetzt werden können. Die bisher vom Kunden verwendete Software und die Turniersimulation wird für uns der Ausgangspunkt der zu entwickelnden Software sein. Aller Voraussicht nach werden wir die Simulationsvisualisierung sowie Teile der vorhandenen Umweltsimulation als Basis für die Testumgebung verwenden. Die Schnittstelle zwischen Umweltsimulation und Simulationsvisualisierung wird im Analyse- und Entwurfsdokument genauer festgelegt. Für die Use-Cases A4 und A5, sprich Überdeckung inspizieren und Elemente der Verteilung inspizieren, werden wir die vorhandenen Views erweitern. Beim Interaktionsverlauf sind wahrscheinlich größere Anpassungen notwendig. Das liegt daran, dass der Interaktionsverlauf während der Simulation des Taxis entsteht und nicht wie bisher als Datei vorgegeben ist. Für die grafische Darstellung der Karte kann der hinzugekaufte Topologieeditor als Ausgangsbasis dienen. Dies wird sich allerdings erst zeigen, wenn wir den Editor vorliegen haben. Ansonsten werden wir in GEF eine eigene Darstellung komplett selber entwickeln. Die Use-Cases Karte laden bzw. Taxi laden können mit den vorhandenen Wizards im Turniersystem realisiert werden. Inwiefern Anpassungen zu machen sind wird sich zeigen. Alle mit dem Wegfindungsalgorithmus zusammenhängenden Produktfunktionen werden nicht auf bestehenden Code aufbauen können und werden somit von PiRat Software komplett neu implementiert. 7

22 4 Produktfunktionen 4 Produktfunktionen In diesem Abschnitt werden die Produktfunktionen der Testumgebung und des Wegfindungsalgorithmus im Detail beschrieben. Unter Verwendung dieser neuen Funktionalitäten wird anschließend eine Taxisteuerung entwickelt (Details siehe Kapitel 2.5, Seite 8). In diesem Kapitel wird zunächst einen Überblick über die Funktionalitäten mit Hilfe eines überarbeiteten Use-Case-Diagrammes geben, welche dann im Detail erläutert werden. 4. Testumgebung Abbildung 9 zeigt die Funktionen der Testumgebung. Die Testumgebung ist die Benutzerschnittstelle und umfasst alle für den Test notwendigen Werkzeuge. Testumgebung * A: Karte laden * A2: Taxi laden * A3: Taxi zur Inspektion auswählen * A4: Überdeckung inspizieren * A5: Elemente der Verteilung inspizieren Benutzer * A6: Interaktionsverlauf inspizieren * A7: Taxi löschen * A8: Simulation starten * A9: Simulation pausieren * A0: schrittweise Simulation * A: Simulation beenden Abbildung 9: Die vom Auftraggeber geforderten Use-Cases der Testumgebung, sowie zusätzliche Use-Cases zur Steuerung der Simulation. Die Erweiterungen des Use-Case A4 werden nicht mehr als einzelne Use-Cases aufgeführt, da unser Entwurf keine Unterscheidung zwischen diesen vorsieht. Dies wird in Kapitel 4..4 (siehe Seite 23) konkretisiert. Aus diesen neu hinzugekommenen Funktionen ergibt sich ein effizienterer Workflow. Die Schwäche des bisherigen Arbeitsprozesses liegt darin, dass nach dem Beobachten 8

23 4. Testumgebung eines Fehlers dieser nur direkt in den Editoren gesucht werden konnte. Die neuen Werkzeuge hingegen erlauben es, wie in den folgenden Diagrammen grob angedeutet, den Fehler direkt beim Auftreten zu analysieren. [weiteres Taxi laden/löschen] Testumgebung öffnen Karte laden Taxi laden [Taxi löschen] Taxi löschen Abbildung 0: Das Diagramm zeigt das Initialisieren der Testumgebung. Nach dem Laden einer Karte können beliebig viele Taxis geladen und ggf. wieder gelöscht werden. Simulation starten [Simulation anhalten] Simulation pausieren [keine Schritte] Taxi inspizieren [weitere Schritte] schrittweise Simulation [weiteres Taxi inspizieren] [Sim. weiterfüren] Simulation beenden Abbildung : Nachdem die Testumgebung initialisiert wurde, kann mit der Simulation und Analyse begonnen werden. Es besteht die Möglichkeit die Simulation zu pausieren und sie dann Einzelschritte simulieren zu lassen. Während der gesamten Zeit ist es möglich geladene Taxis zu inspizieren. 9

24 4 Produktfunktionen Im Folgenden werden die einzelnen Use-Cases genauer beschrieben. Es werden immer die charakterisierenden Informationen angegeben, welche Aufschluss über die Ziele des Nutzers gibt. Bei komplexeren Funktionen wird noch der Ablauf dieser in Tabellen und/oder Diagrammform geschildert. Es ist zu beachten, dass nach dem Öffnen der Testumgebung die Vorbedingung Simulation nicht gestartet gilt. 4.. A: Karte laden Dieser Use-Case beschreibt das Laden einer Karte in die Testumgebung. Die Karte stellt die Grundlage der späteren Simulation dar. Wenn bereits eine Karte mit einem oder mehreren Taxen geladen war, müssen alle Taxen gelöscht werden, da sich nach dem Laden der neuen Karte Taxen an inkorrekten Positionen befinden könnten. In diesem Use-Case kann der Benutzer bei jeder Interaktion mit dem System den Vorgang abbrechen. Dies wird im Folgenden nicht weiter im Detail betrachtet. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: Standardszenario Nutzer Beschreibung der Aktivität Benutzer Karte laden wählen 2 Testumgebung Datei abfragen 3 Benutzer Datei wählen 4 Testumgebung Karten laden Alternativszenarien Karte laden Benutzer Eine neue Karte laden Simulation nicht gestartet Karte geladen und keine Taxis vorhanden Benutzer wählt Karte laden Testumgebung Benutzer, Testumgebung Bedingung Nutzer Beschreibung der Aktivität 2. Taxis vorhanden Testumgebung Abfrage: Taxis löschen? 2.2 Benutzer bestätigt Abfrage 2.3 Testumgebung Taxis löschen 2.4 Testumgebung gehe zu Schritt 2 Bedingung Nutzer Beschreibung der Aktivität 4. Inkorrekte Datei Testumgebung Fehlermeldung 4.2 Testumgebung gehe zu Schritt 2 20

25 4. Testumgebung Benutzer Karte laden wählen Datei wählen [inkorrekte Datei] Testumgebung [Taxis vorhanden] Datei abfragen Abfrage: Taxis löschen? Taxis löschen Karte laden Fehlermeldung [Abbruch durch Benutzer] Abbildung 2: Aktivitätendiagramm Karte laden. Die obigen Tabellen werden hier noch einmal in einem Diagramm vereint, um die möglichen Abläufe auf einen Blick erfassen zu können A2: Taxi laden Dieser Use-Case beschreibt das Laden eines Taxis in die Testumgebung. Das Taxi ist ein integraler Teil der Simulation. Der Nutzer kann in diesem Use-Case den Ladevorgang jederzeit abbrechen, was im Folgenden nicht weiter im Detail beschrieben wird. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: Standardszenario Nutzer Beschreibung der Aktivität Benutzer Taxi laden wählen 2 Testumgebung Abfrage: Verteilung? 3 Benutzer Verteilung wählen 4 Testumgebung Abfrage: Startposition? 5 Benutzer Startposition setzen 6 Testumgebung Abfrage: Wegfindungsalgorithmus 7 Benutzer Wegfindungsalgorithmus wählen 8 Testumgebung Taxi hinzufügen Taxi laden Benutzer Ein neues Taxi laden Karte geladen, Simulation nicht gestartet Taxi und zugehöriger Wegfindungsalgorithmus geladen, Simulation nicht gestartet Anwender wählt Taxi laden Testumgebung Benutzer, Testumgebung 2

26 4 Produktfunktionen Alternativszenarien Bedingung Nutzer Beschreibung der Aktivität 2. Keine Karte geladen Testumgebung Fehlermeldung 2.2 Testumgebung Beenden Benutzer Taxi laden wählen Verteilung wählen Startposition setzen Wegfindungsalgo. wählen Testumgebung Abfrage: Verteilung? Abfrage: Startposition? Fehlermeldung [keine Karte geladen] Abfrage: Wegfindungsalgo. Taxi hinzufügen Abbildung 3: Aktivitätendiagramm Taxi laden. Das obige Diagramm beschreibt den Ablauf des Use-Cases Taxi laden A3: Taxi zur Inspektion auswählen Hier wird der Vorgang beschrieben ein Taxi zur Inspektion auszuwählen. Dies ist zu jeder Zeit möglich, insbesondere auch während einer laufenden Simulation. Charakterisierende Informationen Name: Taxi zur Inspektion auswählen Primärer Nutzer: Benutzer Ziel (des Nutzers): Verhalten des Taxis nachvollziehen Vorbedingung: mindestens ein Taxi geladen Nachbedingung: Verteilungs- und Interaktionsverlaufsdarstellung zeigen Informationen zum gewählten Taxi Auslösendes Ereignis: Benutzer wählt Taxi inspizieren Umgebende Systemgrenze: Testumgebung Beteiligte Nutzer: Benutzer, Testumgebung Standardszenario Nutzer Beschreibung der Aktivität Benutzer Taxi auswählen 2 Testumgebung Verteilungsansicht aktualisieren 3 Testumgebung Interaktionsverlaufsansicht aktualisieren 22

27 4. Testumgebung 4..4 A4: Überdeckung inspizieren Der folgende Use-Case beschreibt den Vorgang sich, als Nutzer, die aktuelle Überdeckung von Zuständen und Transitionen anzeigen zu lassen. Neben einer textuellen Darstellung werden die Überdeckungen grafisch visualisiert. Ein mögliches Beispiel für die Darstellung im Zustandsautomaten stellt die Abbildung 4 dar. A B D C Abbildung 4: Skizze einer Überdeckung eines Zustandsautomaten. In der Skizze sind schwarze Transitionen und Zustände bereits besucht worden. Dies ist eine logische und intuitive Darstellung einer Überdeckung. Daher wird hier schon genauer auf die Darstellung eingegangen. Eine solche grafische Darstellung macht eine Differenzierung zwischen einer Inspektion von Transitions- und Zustandsüberdeckung überflüssig. An dieser Stelle ist aber nochmals darauf hingewiesen, dass eine separate Betrachtung in textueller Form jederzeit möglich ist. Charakterisierende Informationen Name: Überdeckung inspizieren Primärer Nutzer: Benutzer Ziel (des Nutzers): Transitions- und/oder Zustandsüberdeckung anzeigen lassen Vorbedingung: mindestens ein Taxi geladen Nachbedingung: Zustandsautomat stellt Transitions- und Zustandsüberdeckung zusätzlich zur textuellen Darstellung dar Auslösendes Ereignis: Komponente wird ausgewählt Umgebende Systemgrenze: Testumgebung Beteiligte Nutzer: Benutzer, Testumgebung 23

28 4 Produktfunktionen Standardszenario Nutzer Beschreibung der Aktivität Anwender Komponente auswählen 2 Testumgebung Zustandsautomat aktualisieren 3 Testumgebung textuelle Überdeckungsdarstellung anzeigen 4..5 A5: Elemente der Verteilung inspizieren Dieser Use-Case beschreibt das Inspizieren eines Elementes der Verteilung des zuvor gewählten Taxis. Der Nutzer kann jederzeit ein Element auswählen und sich dessen relevanten Daten anzeigen lassen. Daten sind beispielsweise Zustandsautomaten und Attribute einer Softwarekomponente. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: 4..6 A6: Interaktionsverlauf inspizieren Elemente der Verteilung inspizieren Benutzer relevante Daten eines zuvor gewählten Elementes inspizieren Taxi ausgewählt die relevanten Daten werden angezeigt Benutzer wählt ein Taxi aus Testumgebung Benutzer, Testumgebung Dieser Use-Case beschreibt das Inspizieren des Interaktionsverlaufs. Da dies keine aktive Interaktion mit dem Programm benötigt, wird hier auch kein Standardszenario angegeben. Die Testumgebung zeichnet die Interaktionen zwischen Komponenten auf und stellt sie grafisch dar. Diese Interaktionsverlaufdarstellung erlaubt es dem Benutzer die Interaktionen zwischen einzelnen Komponenten anhand einer grafischen Übersicht zu inspizieren. Insbesondere kann der Simulationsschritt, in welchem die Interaktion statt fand, nachvollzogen werden. 24

29 4. Testumgebung Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: 4..7 A7: Taxi löschen Interaktionsverlauf inspizieren Benutzer Verlauf der Interaktionen betrachten Taxi ausgewählt Benutzer möchte Verhalten von Verteilung nachvollziehen Testumgebung Benutzer, Testumgebung Dieser Use-Case beschreibt den Vorgang ein ausgewähltes Taxi aus der Testumgebung zu entfernen. Dies ist nicht während einer laufenden Simulation möglich. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: Standardszenario Nutzer Beschreibung der Aktivität Benutzer Taxi löschen wählen 2 Testumgebung ausgewähltes Taxi entfernen Alternativszenarien Taxi löschen Benutzer Ein Taxi aus der Testumgebung entfernen Taxi ausgewählt, Simulation nicht gestartet Gewähltes Taxi entfernt, kein Taxi ausgewählt Benutzer wählt Taxi löschen Testumgebung Benutzer, Testumgebung Bedingung Nutzer Beschreibung der Aktivität 2. kein Taxi ausgewählt Testumgebung Fehlermeldung anzeigen 25

30 4 Produktfunktionen 4..8 A8: Simulation starten Dieser Use-Case beschreibt das Starten der Simulation. Unter starten wird hier auch das Weiterausführen einer pausierten Simulation verstanden, welches aber keiner gesonderten Beschreibung bedarf. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: 4..9 A9: Simulation pausieren Simulation starten Benutzer Taxi/Taxen auf Karte simulieren mindestens ein Taxi geladen, Karte geladen Simulation läuft Benutzer wählt Simulation starten Testumgebung Benutzer, Testumgebung Hier wird das Pausieren der Simulation genauer beschrieben. Unter pausieren versteht man das Unterbrechen der automatischen Schritte, was dazu führt, dass keine Transitionen mehr geschaltet werden und somit auch keine Interaktion zwischen Komponenten und/oder Umwelt mehr stattfindet. Eine pausierte Simulation kann jederzeit wieder gestartet werden. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: 4..0 A0: schrittweise Simulation Simulation pausieren Benutzer Interaktionen zwischen Taxis und/oder Umwelt unterbrechen Simulation läuft Simulation pausiert Benutzer möchte die Simulation pausieren Testumgebung Benutzer, Testumgebung Dieser Use-Case beschreibt das Simulieren einzelner Schritte. Während die Simulation pausiert ist, kann diese schrittweise fortgeführt werden. Dabei kann die Schrittanzahl variiert werden. 26

31 4. Testumgebung Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: 4.. A: Simulation beenden schrittweise Simulation Benutzer in Einzelschritten simulieren oder Schritte überspringen Simulation pausiert Simulation pausiert Benutzer wählt Schritt(e) simulieren Testumgebung Benutzer, Testumgebung Der Simulation beenden Use-Case beschreibt das Beenden der kompletten Simulation. Nachdem eine Simulation beendet wurde, kann sie nicht mehr weitergeführt werden. Charakterisierende Informationen Name: Simulation beenden Primärer Nutzer: Benutzer Ziel (des Nutzers): Abschließen einer Simulation Vorbedingung: Simulation läuft oder ist pausiert Nachbedingung: Simulation beendet Auslösendes Ereignis: Benutzer wählt Simulation beenden Umgebende Systemgrenze: Testumgebung Beteiligte Nutzer: Benutzer, Testumgebung 27

32 4 Produktfunktionen 4..2 GUI Skizze Die Abbildungen 5 und 6 zeigen einen Entwurf der Standardansicht der grafischen Benutzeroberfläche der Testumgebung. Die erste Grafik zeigt die Umgebung vor der Wahl einer Komponente. In der zweiten ist zusätzlich die grafische Darstellung der Zustandsund Transitionsüberdeckung zu sehen. Karte Interaktionsverlauf Outline + Taxi # - ECU # - ECU #2 - ECU #3 + Taxi #2 + ECU # + Komponente # - Zustände - Transitionen - Komponente #2 - Komponente #3 - ECU #2 - ECU #3 - Taxi #3 - Taxi #4 Verteilung Karte laden Taxi laden Taxi löschen Optionen Taxi #42 Abbildung 5: Die Skizze zeigt die geplante Standardansicht der Testumgebung mit geladener Karte und mehreren Taxis. In der Kartendarstellung (links) kann die Simulation verfolgt und Taxis ausgewählt werden. In der Interaktionsverlaufdarstellung (Mitte oben) können die Interaktionen eines Systems oder einer Auswahl von Komponenten inspiziert werden. In der Verteilungsdarstellung (Mitte unten) wird die Verteilung des aktuellen Systems dargestellt. In der Outline (rechter Rand) sind jederzeit die wichtigsten Informationen textuell einsehbar. Darüber hinaus ist geplant, dass die Ansicht einfach anzupassen ist. So soll es möglich sein jede Ansicht einzeln, oder nur eine Auswahl der Ansichten anzuzeigen. 28

33 4. Testumgebung Karte Karte laden Taxi laden Taxi löschen Optionen Taxi #42 Überdeckung Interaktionsverlauf Verteilung Outline + Taxi # - ECU # - ECU #2 - ECU #3 + Taxi #2 + ECU # + Komponente # - Zustände - Transitionen - Komponente #2 - Komponente #3 - ECU #2 - ECU #3 - Taxi #3 - Taxi #4 Abbildung 6: Diese Skizze stellt die Testumgebung nach Auswahl einer Softwarekomponente dar. Zusätzlich ist es nun möglich in der grafischen Überdeckungsdarstellung (links unten) die Überdeckung von Transitionen und Zuständen der Zustandsmaschine der gewählten Softwarekomponente zu inspizieren. 29

34 4 Produktfunktionen 4.2 Wegfindungsalgorithmus Abbildung 7 zeigt die Funktionen des Wegfindungsalgorithmus. Das Use-Case-Diagramm aus dem Lastenheft wurde um die Punkte Straße schließen und Straße öffnen erweitert, da dies ebenfalls wichtige Interaktionen zwischen der Umweltsimulation und dem Wegfindungsalgorithmus sind. Der Wegfindungsalgorithmus berechnet auf Basis der vorliegenden topologischen Daten eine Route. Wegfindungsalgorithmus * B: Wegabfrage <<Include>> B3: Weg berechnen <<Include>> * B2: Abfrage des nächsten Feldes Umweltsimulation * B4: Karte übergeben * B5: Straße schließen * B6: Straße öffnen Abbildung 7: Die vom Auftraggeber geforderten Use-Cases für den Wegfindungsalgorihtmus, sowie die zusätzlichen Use-Cases zum Schließen und Öffnen von Straßen B: Wegabfrage Dieser Use-Case beschreibt das Abfragen eines Weges. Der Weg wird unter Benutzung des Use-Case Weg berechnen bestimmt und dann entsprechend der Umweltsimulation übergeben. 30

35 4.2 Wegfindungsalgorithmus Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: Wegabfrage Umweltsimulation Weg vom Start- zum Zielpunkt erhalten Karte geladen Umweltsimulation benötigt Weg vom Start- zum Zielpunkt Wegfindungsalgorithmus Umweltsimulation, Wegfindungsalgorithmus Standardszenario Nutzer Beschreibung der Aktivität Umweltsimulation Weg abfragen 2 Wegfindungsalgorithmus Weg berechnen 3 Wegfindungsalgorithmus Weg zurückgeben Alternativszenarien Bedingung Nutzer Beschreibung der Aktivität 3. kein Weg vorhanden Wegfindungsalgortihmus Fehler zurückgeben Umweltsimulation Wegfindungsalgo. Weg abfragen Weg berechnen [kein Weg gefunden] Weg zurückgeben Fehlermeldung Abbildung 8: Aktivitätendiagramm Wegabfrage Das Aktivitätendiagramm zeigt die möglichen Abläufe des Use-Cases Wegabfrage. Nach der Berechnung des Weges muss der Umweltsimulation gegebenenfalls auf geeigneter Weise mitgeteilt werden, dass kein Weg gefunden wurde. Im Diagramm stellt dies die Fehlermeldung dar. 3

36 4 Produktfunktionen B2: Abfrage des nächsten Feldes Das Abfragen des nächsten Feldes arbeitet auf die gleiche Weise wie der Use-Case Wegabfrage. Es wird wieder der Weg berechnet und das nächste zu befahrende Feld bestimmt. Dieses wird der Umweltsimulation übergeben. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: B3: Weg berechnen Abfrage des nächsten Feldes Umweltsimulation nächstes Feld des Weges erhalten Karte geladen Umweltsimulation benötigt nächstes Feld des Weges Wegfindungsalgorithmus Umweltsimulation, Wegfindungsalgorithmus Das Berechnen des Weges ist integraler Bestandteil der beiden vorigen Use-Cases. Der Weg wird basierend auf der aktuellen Karte und den Informationen über geschlossene Straßen berechnet. Ist kein korrekter Weg möglich, wird dies entsprechend gemeldet. Da hier keine Interaktion zwischen der Umweltsimulation und dem Wegfindungsalgorithmus stattfindet, wird hier auch kein Standardszenario oder Diagramm angegeben B4: Karte übergeben Dieser Use-Case beschreibt das Übergeben der Karte von der Umweltsimulation an den Wegfindungsalgorithmus. Bei einer Wegabfrage wird der Weg basierend auf dieser Karte berechnet. Charakterisierende Informationen Name: Karte übergeben Primärer Nutzer: Umweltsimulation Ziel (des Nutzers): zukünftige Wege basierend auf dieser Karte berechnen Vorbedingung: Nachbedingung: Karte geladen Auslösendes Ereignis: Umweltsimulation hat neue Karte erhalten Umgebende Systemgrenze: Wegfindungsalgorithmus Beteiligte Nutzer: Umweltsimulation, Wegfindungsalgorithmus 32

37 4.2 Wegfindungsalgorithmus B5: Straße schließen Mit Hilfe dieser Funktion kann dem Wegfindungsalgorithmus mitgeteilt werden, dass eine bestimmte Straße geschlossen wurde. Berechnete Wege dürfen keine geschlossenen Straßen enthalten. Es ist hier möglich eine bereits geschlossene Straße nochmals zu schließen. Dies hat keine Auswirkung auf den Wegfindungsalgorithmus, während mögliche Fehler in der Umweltsimulation toleriert werden. Charakterisierende Informationen Name: Primärer Nutzer: Ziel (des Nutzers): Vorbedingung: Nachbedingung: Auslösendes Ereignis: Umgebende Systemgrenze: Beteiligte Nutzer: B6: Straße öffnen Straße schließen Umweltsimulation Wege sollen nicht über diese Straße verlaufen Karte geladen Karte geladen, diese Straße geschlossen Umweltsimulation hat Straße geschlossen Wegfindungsalgorithmus Umweltsimulation, Wegfindungsalgorithmus Geschlossene Straßen können mit Hilfe dieser Funktion wieder geöffnet werden. Wieder geöffnete Straßen dürfen für die Berechnung eines Weges wieder verwendet werden. Wie beim Schliessen einer Straße ist es auch hier möglich offene Straßen erneut zu öffnen. Somit ist die Fehlertoleranz gegenüber der Umweltsimulation höher. Charakterisierende Informationen Name: Straße öffnen Primärer Nutzer: Umweltsimulation Ziel (des Nutzers): Weg darf über diese Straße verlaufen Vorbedingung: Karte geladen Nachbedingung: Karte geladen, diese Straße geöffnet Auslösendes Ereignis: Umweltsimulation hat Straße geöffnet Umgebende Systemgrenze: Wegfindungsalgorithmus Beteiligte Nutzer: Umweltsimulation, Wegfindungsalgorithmus 33