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.	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 wahrgenommene Komponenteninteraktion für die oben definierten Szenarien:

• DS01: Über die Komponente Konfig-Speicher kann die Anpassung des Straßennetzes vorgenommen werden. Aus unserer Sicht fehlt hier die beschrieben "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.)
• DS03: TODO

...

TODO: Beschreiben was Tabelle aussagt

Komponente	Benötigt bei direkten Szenarien	Anpassung bei indirekten Szenarien
GUI	DS03,
Simulation	DS02, DS03, DS04
Fahrzeug	DS02, DS04
Ampelsteuerung	DS03,
Konfig-Speicher	DS01,

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"?