06 Architektur Review

Im Folgenden ist unsere szenariobasierte Architekturbewertung der Verkehrssimulation der Gruppe um...

• Buchegger, Sebastian
• Crnogorcevic, Zeljko
• Probst, Johannes
• Unterhitzenberger, Sebastian

... dokumentiert.

Die Architekturbeschreibung der Gruppe kann unter https://github.com/sepeiFH/Fahrzeugsimulation/wiki eingesehen werden.

Es kann sein, dass sich die Architekturdokumentation der Gruppe mittlerweile verändert hat. Das Review wurde bei Revision 2d9d4a4 durchgeführt. Zu dieser Version kann zurück gewechselt werden, indem man in der Architekturdoku oben auf "revisions" klickt und anschließend nach 2d9d4a4 sucht. Hier die Darstellung des Gesamtsystems in Bausteinsicht zum Zeitpunkt des Reviews.

1. Szenarien

Ein Szenario ist die Beschreibung einer Interaktion eines Users oder einer Usergrupe mit dem System. Die Szenarien beschreiben sowohl Abläufe die das System momentan unterstützen muss, aber auch Abläufe die eventuell in der Zukunft unterstützt werden sollen.

Das Verfahren SAAM (Software Architecture Analysis Method) aus der Vorlesung unterscheidet deshalb zwischen:

• direkten Szenarien: Das System kann diese Szenarien mit der aktuellen Architektur durchführen.
• indirekte Szenarien: Das System kann diese Szenarien nur nach Änderungen an der Architektur durchführen. Aufgrund der ungewissen Zukunft eigenen sich diese Szenarien, um u.A. die Erweiterbarkeit bewertbar zu machen.

Quelle: Wikipedia SAAM

Direkte Szenarien

Folgende Tabelle beschreibt die von uns identifizierten direkten Szenarien und priorisiert diese.

Erlaubte Prios: hoch | mittel | niedrig

ID	Beschreibung	Prio
DS01	Der Benutzer passt über eine Config-Datei oder einen Editor ein Straßennetz inkl. Beschreibung der Kreuzungen und Verkehrsregeln (Schilder) auf dem sich später Fahrzeuge bewegen können, an.	mittel
DS02	Ein Fahrzeug nimmt andere Verkehrsteilnehmer in seiner Umgebung war, hält einen Sicherheitsabstand ein ohne hinten aufzufahren und berücksichtigt dabei die Vorrangregeln.	hoch
DS03	Der Benutzer steuert über eine grafische Benutzeroberfläche die Ampeln auf der Karte und passt die Rot-Grün-Intervalle frei nach belieben an.	hoch
DS04	Ein Fahrzeug, dass die eigene Simulation über eine Ausfahrtsstraße verlässt, wird einer entfernten Simulation übergeben und fährt dort bei einer Eingangsstraße mit den gleichen Eigenschaften (aktuelle Geschwindigkeit, Größe, Leistungsdaten etc.) weiter. Zufahrende Autos werden von anderen Simulationen übernommen.	niedrig
DS05	Der Benutzer klickt auf ein Fahrzeug um dieses zu deaktivieren. Das Fahrzeug bleibt daraufhin stehen und andere Fahrzeuge müssen das Hinderniss umfahren.	mittel

Indirekte Szenarien

Folgende Tabelle beschreibt die von uns identifizierten indirekten Szenarien und priorisiert diese.

Erlaubte Prios: hoch | mittel | niedrig

ID	Beschreibung	Prio
IS01	Weitere Verkehrsteilnehmer wie Fußgänger, Straßenbahnen, Einsatzfahrzeuge etc. werden in die Simulation aufgenommen.	mittel
IS02	Der Benutzer kann über ein Config-File oder einen Editor Baustellen auf dem Straßennetz hinzufügen. Die Fahrzeuge umfahren diese Hindernisse.	mittel
IS03	Die Simulation berücksichtigt die Tageszeit und spawned zur Rush-Hour eine große Anzahl an Verkehrsteilnehmern gleichzeitig um reale Gegebenheiten simulieren zu können.	hoch
IS04	Der Benutzer kann Hot-Spots auf der Karte festlegen (z.B. Einkaufszentrum), zu denen sich die Fahrzeuge mit höherer Wahrscheinlichkeit hinbewegen.	hoch
IS05	Bei einem defekten Fahrzeug werden spezielle Einsatzfahrzeuge (Abschleppwagen, Feuerwehr) gespawned. Diese bewegen sich zur Unfallstelle und beheben den Schaden. Die anderen Verkehrsteilnehmer geben den Einsatzfahrzeugen Vorrang und bilden eine Rettungsgasse.	niedrig

2. Einzelne Bewertung der Szenarien

Die im vorherigen Schritt zur Bewertung ausgewählten Szenarien werden den betroffenen Elementen der Architektur zugeordnet:

• Für direktes Szenario bedeutet dies eine Beschreibung der Ausführung der Szenarien durch das System.
• Für ein indirektes Szenario bedeutet dies eine Beschreibung der zur Ausführung des Szenarien nötigen Änderungen an der Architektur. Dabei werden die nötigen Änderungen identifiziert und der Änderungsaufwand geschätzt.

Quelle: Wikipedia SAAM

Die Architektur enthält folgende Komponenten:

• Konfig-Speicher

• Simulation

• Fahrzeug

• Ampelsteuerung

• GUI

Anbei die von uns wahrgenommenen Komponenteninteraktionen für die oben definierten direkten Szenarien:

• DS01: Über die Komponente Konfig-Speicher kann die Anpassung des Straßennetzes vorgenommen werden. Aus unserer Sicht fehlt hier die textuell beschriebene "Tiled"-Komponente im Komponentendiagramm.

• DS02: Die Komponente Fahrzeug liest aus der Komponente Simulation die Positionen und Eigenschaften der umliegenden Verkehrsteilnehmer und Regeln aus und reagiert entsprechend. (Geschwindigkeitsanpassungen, Vorrangregeln, etc.) Die Visualisierung erfolgt über die GUI

• DS03: Die Parametrisierung der Ampelanlagen erfolgt durch die Komponente Ampelsteuerung. Die Parameter werden and die Simulation weitergereicht.

• DS04: Die Simulation regelt das zufahren (=spawnen) und ausfahren von Fahrzeugen. Diese werden über die VehicleHandoverLibrary an Nachbarsimulationen übergeben. Diese Library hätte man noch in die Bausteinsicht als zusätzliche Komponente hinzufügen können. Einfahrende Fahrzeuge von anderen Simulationen werden schließlich von der GUI gerendert.

• DS05: Der Benutzer klickt in der GUI auf ein Fahrzeug um dieses zu deaktivieren. Da keine direkte Verbindung zwischen der Komponente Fahrzeug und GUI besteht, muss diese Event über die Simulation weitergereicht werden.

Anbei die von uns wahrgenommenen notwendigen Anpassungen die für die oben definierten indirekten Szenarien notwendig wären:

• IS01: Um weitere Typen von Verkehrsteilnehmer hinzufügen zu können, müsste die Fahrzeug Komponente erweitert werden. Die Simulation nimmt die Typen auf. Diese werden von der GUI dargestellt.
• IS02: Ein zusätzlicher Tile "Baustelle" müsste über den Konfig-Speicher parametrisierbar gemacht werden. Da es bereits jetzt möglich ist defekte Fahrzeuge zu umfahren, sollten ansonsten wenig Änderungen nötig sein.
• IS03: Die Simulation regelt die Dichte der zufahrenden Fahrzeuge. Um uhrzeitbedingt eine Rush-Hour zu simulieren, müsste nur diese Komponente erweitert werden.
• IS04: Die Festlegung von Hot-Spots könnte über das Klicken auf die GUI oder statisch über den Konfig-Speicher vorgenommen werden. In beiden Fällen müsste die Information über die Simulations-Komponente an die Fahrzeug-Komponente weitergereicht werden. Die Fahrzeug-Komponente kann dann die Routenwahl beeinflussen.
• IS05: Eine neuer Typ "Einsatzwagen" müsste in der Fahrzeug-Komponente definiert werden und mit der nötigen Intelligenz ausgestattet werden, um defekte Fahrzeuge auf der Map zu finden, dort hin zu navigieren und diese zu reparieren. Dazu ist außerdem das Polling von umliegenden Fahrzeugdaten von der Simulation notwendig. Die Simulation ist außerdem für das Spawnen solcher Einsatzfahrzeuge zuständig.

Folgende Tabelle fasst die Bewertungen übersichtlich zusammen. Für jede Komponente ist erkennbar, bei welchen Szenarien diese durchlaufen (bei direkten Szenarien) bzw. angepasst (bei indirekten Szenarien) werden müsste. In der Komponenten-Spalte ist in Klammern die Anzahl der Szenarien die diese betreffen aufsummiert.

Komponente	Benötigt bei direkten Szenarien	Anpassung bei indirekten Szenarien
GUI (5)	DS02, DS04, DS05	IS01, IS04
Simulation (8)	DS02, DS03, DS04, DS05	IS01, IS03, IS04, IS05
Fahrzeug (5)	DS02, DS04, DS05	IS01, IS05
Ampelsteuerung (1)	DS03
Konfig-Speicher (3)	DS01	IS02, IS04

3. Untersuchung von Szenariointeraktionen

Szenariointeraktion bedeutet, dass zwei oder mehr Szenarien Änderungen an derselben Komponente der Architektur erfordern.

Eine hohe Szenariointeraktion kann auf zwei verschiedene Probleme hinweisen: Eine Komponente realisiert mehrere nicht zusammengehörige Funktionsbereiche. Die Architektur einer Komponente ist nicht ausreichend genau dokumentiert. In diesem Fall sollte Schritt 1 von SAAM (Architekturbeschreibung) noch einmal ausgeführt werden.

Quelle: Wikipedia SAAM

Wie aus der obigen Tabelle ersichtlich ist, herrscht bei der Simulations-Komponente eine hohe Szenariointeraktion.

Laut Architekturdoku hat die Komponenten viele Verantwortlichkeiten inne:

• Simulationstakt
• Nimmt die verschiedenen Typen (Kreuzungen/Fahrzeuge) auf
• Regelt die Anzahl der zufahrenden Fahrzeuge
• Verwaltet die Konfigurationsdaten
• Stellt die Schnittstellen den Modulen Ampelsteuerung, Fahrzeug und GUI zur Verfügung

Aus unserer Sicht könnte man diese noch granularer modellieren bzw. die Komponente nach Aufgabenbereichen weiter auftrennen (Seperation of concerns).

Beispiel: Die Simulations-Komponente wird in einigen Szenarien lediglich zur Durchreichung von Daten verwendet. Eventuell würde es Sinn machen eine zentrale Messaging- oder Datenverwaltungskomponente einzuführen.

4. Gesamtbewertung

Die Architektur ist aus unserer Sicht stimmig und deckt sich auch mit dem gelieferten Source-Code. Die in der Architektur beschriebenen Komponenten sind zu erkennen.

Die Simulations-Komponente könnte noch granularer spezifiziert werden. Die Komponenten "Tiled" (zur Erstellung der Map-Beschreibung) und die "VehicleHandoverLibrary" hätte man auch in der Bausteinsicht noch abbilden können, um ein besseres Gesamtbild zu bekommen.