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.

Hier die Darstellung des Gesamtsystem auf der unser Review fußt. TODO: Insert IMG

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.

TODO: Beschreiben was Tabelle aussagt

Komponente	Benötigt bei direkten Szenarien	Anpassung bei indirekten Szenarien
GUI	DS02, DS04, DS05	IS01, IS04
Simulation	DS02, DS03, DS04, DS05	IS01, IS03, IS04
Fahrzeug	DS02, DS04, DS05	IS01
Ampelsteuerung	DS03
Konfig-Speicher	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

TODO

4. Gesamtbewertung

TODO Fazit

• "Tiled"-Editor fehlt in ARC: Müsste an XML Konfig-Speicher hängen?!
• Es ist nicht klar ersichtlich wie die VehicleHandoverLibrary eingebunden ist. Ist dies die Komponente "Nachbarsimulation"?