Architektur Review
- Bernhofer Walter
- Eder Thomas
- Schöninger David
- Unterrainer Maximilian
- Ziegler Markus
Die Review basiert auf szenariobasierte Evaluierungsmethode SAAM „software architecture analysis method“. Diese Methode wurde in den Vorlesungen und als Quelle aus den vorgegeben Links im Labor vorgestellt.
Ziel der Softwarearchitekturbewertung mittels SAAM ist es, eine Softwarearchitektur auf ein oder mehrere bestimmte Qualitätsmerkmale hin zu untersuchen.
Das System besteht aus 5 einzelnen Komponenten, die bereits in der Abbildung deutlich erklärt werden. Die Verbindungen unter den Komponenten sind eingezeichnet und man kann den Datenfluss bzw. die Interaktion erkennen und verstehen.
Die Szenarien dienen zur Beschreibung der Tätigkeiten, die das System momentan unterstützen muss oder eventuell in Zukunft unterstützen soll und werden in zwei Kategorien eingeteilt:
- Direkte Szenarien (=DS), d.h. Szenarien, die mit der vorhandenen Architektur ohne Änderungen ausgeführt werden können
- Indirekte Szenarien (=IS) (Changecases oder Growthcases), d.h. Szenarien, zu deren Ausführung Änderungen an der Architektur vorgenommen werden müssen.
Priorität-stufen 1-3 (wobei 1 hoch ist und 3 niedrig)
1.0 In der Simulation gibt es LKW's und PKW's -> Prio 1 -> DS
1.1 In die Simulation können weitere Attribute berücksichtigt werden, wie Motorrad, Straßenbahn, Fußgänger -> Prio 3 -> DS
2.0 Es muss ein Zusammenhängendes Straßennetz bestehen -> Prio 1 -> DS
2.1 Die Straße kann durch Benutzer via GUI konfiguriert werden -> Prio 2 -> IS
3.0 Es gibt geregelte und ungeregelte Kreuzungen -> Prio 1 -> DS
3.1 Regelung kann über Verkehrszeichen erfolgen -> Prio 3 -> DS
4.0 Auf den Straßen gibt es Ampeln, die anfangs fix über die Konfiguration platziert werden -> Prio 1 -> DS
4.1 Die Ampeln können nicht nur bei Kreuzungen sondern auch entlang der Straße platziert werden -> Prio 2 -> IS
4.2 Verhalten der Ampelanlage muss parametrisierbar sein. Regelung erfolgt über eigenen Prozess -> Prio 2 -> DS
5.0 Anzahl der über Einfahrtstraßen in das System zufahrenden Fahrzeuge über das Programm regelbar -> Prio 1 ->
5.1 Der Benutzer kann die Anzahl der Straßen via GUI definieren -> Prio 2 -> IS
6.0 Die Simulation besitzt eine grafische Darstellung und hat einfache Benutzerschnittstelle -> Prio 1 -> DS
7.0 Die Simulationen sollen untereinander vernetzt werden. Das heißt, dass Fahrzeuge bei einer Straße einer Simulation ausfahren und dann in der anderen Simulation über eine Straße wieder einfahren können -> Prio 1 -> DS
8.0 ES muss es möglich sein, beliebige Hindernisse auf der Straße ein-/ausschaltbar zu machen; z.B. per Mausklick defekte Autos bzw. Baustellen zu positionieren/definieren -> Prio 1 -> DS
8.1 Ein Umfahren der Hindernisse mit eigens dafür definierten Straßen ist nicht erlaubt -> Prio 2 -> DS
Da Szenarien logisch aufeinanderfolgen, wird die Beschreibung Punkt für Punkt unabhängig der Prio und Szenarioart durchgeführt.
1.0 Prio 1 -> DS: im Code sind beide Fahrzeugarten LKW und PKW vorgesehen. Allerdings konnte man während der Simulations-start nur PKW gesichtet werden. Wahrscheinlich sollte lediglich die Startkonfiguration angepasst werden.
1.1 Prio 3 -> GS: Die Option ist bis jetzt nicht implementiert, allerdings sollte das keinen großen Aufwand mit sich bringen, da es um einen weiteren Agenten handelt, der über eine Factory generiert wird.
2.0 Prio 1 -> DS: Es existiert ein fixes Straßennetz. Es ist nicht auf ersten Blick erkennbar welcher Aufwand für das Zusammenstelle dahinter steckt. Es empfiehlt sich evtl. auf die Grafik zu verzichten und dafür mittels einfachen Tools die Straßen in unterschiedlichen Ausprägungen zeichnen zu können. Der tatsächlich angelegte Kurs entspricht nicht der Grafik. Man sieht das wenn die Option F2 ausgewählt ist. Als Verbesserung könnte man die sichtbaren Straßen bis zu Ende vernetzen. Aber für eine einfache Simulation ist das ausreichend.
2.1 Prio 2 -> IS: Diese Feature ist nicht gegeben und der Aufwand dafür kann unterschiedlich sein! Je nach dem, wie der Punkt 2.0 implementiert werden kann.
3.0 Prio 1 -> DS: Das Szenario funktioniert großteils. Man kann allerdings beobachten, dass die Fahrzeuge keine Rücksicht auf die Ampeln nehmen.
3.1 Regelung kann über Verkehrszeichen erfolgen -> Prio 3 -> DS: Die Verkehrszeichen sind vorgesehen und grafisch im Einsatz.
4.0 Prio 1 -> DS: Ja, das ist gegeben.
4.1 Prio 2 -> IS: derzeit nicht möglich. Der Aufwand wird eher hoch eingeschätzt, da es noch nicht vorgesehen ist Gegenstände dynamisch auf der Straße zu platzieren.
4.2 Prio 2 -> DS: Die Dauer der Rot/Grünphase ist einstellbar und zwar in einem Range zw. 4 und 59 sec. Eine Falscheingabe wurde abgefangen.
5.0 Prio 1 -> DS: Ja, es ist regelbar, aber nicht über die GUI und wir können den Hintergrund dafür nicht herausfinden.
5.1 Prio 2 -> IS: Nein, das ist nicht möglich. Der Aufwand für eine Umsetzung kann nicht eingeschätzt werden, da es nur eine fixe Karte gibt.
6.0 Prio 1 -> DS: Absolut. Die Darstellung wurde der Realität angepasst und hat nur wenige intuitive Verstellmöglichkeiten.
7.0 Prio 1 -> DS: allerdings kann man während der Simulation nicht erkennen, ob es ein eigenes oder fremdes Fahrzeug ist. Wir gehen davon aus, dass dieses Feature bereits besteht aber noch zu ende implementiert werden muss.
8.0 Prio 1 -> DS: Die beliebige Hindernisse sind derzeit nur die Autos. Diese können per Mausklick angehalten werden. Es fällt auf, dass die Fahrzeuge nicht abrupt sonder durch verlangsamtes Auslaufen stehen bleiben. Die Autos können zum Zeitpunkt der Review nicht entfernt werden, lediglich nur als defekt markiert. Nach der rückgängige Markierung fährt das Fahrzeug wieder weiter und die Stau löst sich auf.
8.1 Prio 2 -> DS: Laut Designedokumentation sollte dieses Verhalten möglich sein (Siehe Abschnitt:Auswirkungen Change Request "Überholen defekter Fahrzeuge"). Während der Simulation konnten wir das Verhalten nicht feststellen. Nach dem Stoppen eines Autos bildet sich nach eine kurzen Zeit ein Stau und das defekte Fahrzeug wird nicht überholt. In der Doku sollten die dahinter fahrende Fahrzeuge erkennen, dass der Vordermann steht. Danach wird dynamisch eine "Umgehungspunkt" eingerichtet, in dem das Fahrzeug auf die Gegenfahrbahn ausweicht und das kaputte Auto umfährt. Es ist zwar ein "neue" Straße aber technisch der Realität angepasst.
Bedeutung der Untersuchung nach SAAM:
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.
In unteren Abbildung kann man erkennen, dass die Interaktionen (Rote Pfeile sind die Calls) meist nur zwischen einzelnen Komponenten stattfinden. D.h. Änderungen müssten nur jeweils an einer Komponente durchgeführt werden.
Weitere Untersuchungen mittels VisualStudio-Tool "Show on Code Map" hat keine auffällige Überschneidungen ergeben.
Die Architektur stimmt mit dem Code und der gesamten Doku meistens über ein. Die Ordnungsstruktur in der Solution passt mit der Abbildung der Bausteinsicht zusammen.
Es fällt auf, dass manches dokumentiertes Verhalten sich (noch) nicht mit der laufenden Simulation deckt. Man kann aber im Code die Stellen mit entsprechenden Kommentaren was noch zu tun ist finden.
Die Architektur ist aus unserer Sicht stimmig und deckt sich auch mit dem gelieferten Source-Code. Die in der Architektur beschriebenen Komponenten sind in der Doku und Source-Code zu erkennen.