Architektur Dokumentation
Beim Projekt "Traffic Simulation" handelt es sich um ein FH-Projekt im Zuge der Lehrveranstaltung Softwarearchitektur. Die wesentliche Aufgabenstellung ist Entwurf, Dokumentation und Implementierung einer verteilten komponentenbasierten Verkehrsimulation gemäß des Anforderungsdokument
Die Simulation sollte wie folgt unterstützen:
- Mikroskopische Simulation der Fahrzeuge (PKW und LKW) und Ampelanlagen
- Zusammenhängendes Verkehrs-/Straßennetz
- Geregelte und ungeregelte Kreuzungen
- Verhalten der Verkehrsteilnehmer sollte weitgehend parametrierbar sein (variabel/- zufällig/individuell)
- Verhalten der Lichtsteueranlage parametrierbar Regelung �über eigenen Prozess
- Anzahl der �über Einfahrtstraßen in das System zufahrenden Fahrzeuge regelbar
- Grafische Darstellung und einfache Benutzerschnittstelle Konguration-GUI nicht unbedingt notwendig
| Qualitätsmerkmal | Beschreibung |
|---|---|
| agiler Softwareentwicklungsprozess | reine Entwurfsphase auf ein Mindestmaß zu reduzieren |
| im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen | |
| in regelmäßigen, kurzen Abständen dem Kunden zur gemeinsamen Abstimmung die Ergebnisse für weitere Abstimmung vorzeigen | |
| komponentenbasierte Entwicklung | mehrere logische Komponente und kein Monolit |
| Anpassbarkeit | In der Hinsicht auf mögliche Veränderungen oder Erweiterungen müssen die Komponenten zu einem gewissen Teil eine einfache Anpassung ohne größeren Aufwand "vertragen" |
| Testbarkeit | Die einzelnen Komponenten k�onnen getrennt voneinander getestet werden. |
| Roll | Erwartungshaltung |
|---|---|
| Roland Graf (Auftraggeber) | Fertigstellung des Projekts nach Anforderungsdokument |
| Eduard Hirsch(Auftraggeber) | Fertigstellung des Projekts nach Anforderungsdokument |
| Teammitglieder | Beschreibung Softwarearchitektur |
| Leichte Umsetzbarkeit | |
| Gut testbare Komponenten |
- C# / .NET
- Visual Studio 2015 und höher. Alternativ kann zur Entwicklung auch C#/Mono verwendet werden. Die Abgabe am Ende des Semesters hat aber ausnahmslos als Visual Studio Solution zu erfolgen!
Verteilte Zusammenarbeit
Das Team schafft entsprechende Rahmenbedingungen, dass einzelne Teammitglieder ihre Arbeitspakete von einander unabhängig fertigstellen können.
Vorgehensmodell
Die Entwicklung erfolgt iterativ und agil. Offene Punkte werden in Paketen nach Scrum- Prinzip abgearbeitet. Die Architekturdokumentation, das Designdokument und die Umsetzung müssen bis Mitte Juli 2017 abgeschlossen werden. Bei relevanten �Änderungen werde das entsprechende Dokument unverzüglich angepasst.
Sourcecodeverwaltung
Die Verwaltung erfolgt �über Github
Dokumentation
Alle relevanten Dokumente werden in Deutsch verfasst. Die Dokumentation im Sourcecode erfolgt in Englisch.
Grundsätzlich kann jede einzelne Komponente durch eine aus dem Dritt-System ersetzt oder erweitert werden. Bei dieser Implementierung liegt der Fokus auf die Simulation-Komponente. Alle anderen Komponenten können unter der Einhaltung der Schnittstellendefinition problemlos ersetzt werden.
| Einzelne Systeme | Schnittstelle | Ausgetauschte Daten |
|---|---|---|
| Simulation | WCF | -> Simulationsstart |
| -> Simulationsstart OK | ||
| -> Simulationsstop | ||
| -> Auto defekt | ||
| <- Ampeln | ||
| <- Kanten | ||
| <- Knoten | ||
| <- Autos | ||
| UI | WCF | <- Logik der Engine |
| -> GUI | ||
| Traffic Light Control | WCF | ->Start |
| -> Stop | ||
| -> Step |
Es sollen mehrere gekapselte Komponenten implementiert werden, die mittels WCF miteinander kommunizieren.
Die Strategie basiert auf einem Knoten- und Kanten-Prinzip.
Die Fahrzeuge bewegen sich auf den Kanten (= Straßen) und die Kanten haben Knoten (= Kreuzungen).
Der Straßennetz wird mittels eines Graph-Editor aufgebaut und in XML-Format für Weiterverarbeitung importiert.
Die Autos bekommen beim Erzeugen eine zufällige aber, von Anfang an bekannte, Route auf der sie sich bewegen.
Folgende Qualitätsziele sollen am Anfang mindestens berücksichtigt werden:
- geringe Komplexität und
- Leichte Erweiterbarkeit (Hinsichtlich auf nicht vorhersehbare Aufgabenstellung)
Die Traffic Simulation wird in vier verschiedene Komponenten aufgeteilt welche mit der Windows Communication Foundation (WCF) miteinander kommunizieren. Die WCF wurde ausgewählt da es damit sehr einfach möglich ist Interprozesskommunikation (IPC) zu implementieren und diese in Zukunft sogar auf Webservices umzustellen, um die Komponenten auf verschiedenen Systemen laufen zu lassen.
Beinhält die Simulationslogik, Steuerung und die Simulierten Objekte. Die Simulation ist unabhängig von jeglicher Anzeigetechnologie wie WPF oder Webtechniken.
Visualsierung der Simulation.
Steuerung der Ampelanlagen.
Logging ist in eine eigenständige Komponente ausgelagert, da mindestens zwei Prozesse Log-Meldungen produzieren werden und das nicht über verschiedenste Logfiles verteilt werden soll.
Nach dem Change Request zur Mitte des Semesters, wurde die Message-Queue-Komponente "Vehicle Handover Library" eingefügt. Hierzu wurde der Simple-Queue-Service der Amazon AWS Cloud genutzt. Beim Verlassen der Simulation wird die Fahrzeug-Beschreibung im JSON-Format in die Queue gepusht. Andere Simulationen können sich zur Queue subscriben und diese somit in Echtzeit erhalten und spawnen. Von einer anderen Gruppe wurde hierzu für alle die "Vehicle-Handover-Library" zur Verfügung gestellt, die sich um das Serialisieren und Pushen der Fahrzeuge bzw. das asynchrone Erhalten von Fahrzeugen via Events kümmert. Siehe dazu die Beschreibung
Die Kommunikation zwischen den Komponenten wird mit WCF durchgeführt. WCF ist ist eine dienstorientierte Kommunikationsplattform für verteilte Anwendungen in Microsoft Windows. Sie führt viele Netzwerkfunktionen zusammen und stellt sie den Programmierern solcher Anwendungen standardisiert zur Verfügung.
- Grafisch
- Textuell
Das Zusammenwirken der einzelnen Komponenten geschieht über die sogenannte Contracts, es sind die Schnittstellen, über die die gesamte Kommunikation abgewickelt wird. Die Abhängigkeiten ist auf der obere Grafik vereinfacht ersichtlich.
Die Beschreibung erfolgt in Form einer einfachen Aufzählung um das Verständnis des Konzeptes einfach zu halten.
Startreihenfolge:
- Applikation (Manuell)
- Logging (Automatisch) Ab hier werden nötige Abfolgen des Programms mitprotokolliert. Falls die UI abstürzen sollte, kann man im Logging nachsehen, ob die Simulation technisch nach wie vor läuft
- Simulation - Webservice (Automatisch)
- Ampelsteuerung (Automatisch)
- Userinterface (Automatisch)
- Start der Simulation (Manuell)
Nach Punkt 6 mittels Klick auf definierten Startbutton, beginnt die Simulation mit vorgegebenen Start- bzw. Defaultwerten laufen.
Die Simulationen der Gruppen laufen für gewöhnlich auf PCs/Notebooks/Workstations in einer .NET Umgebung. Über die VehicleHandoverLibrary können die einzelnen Simulationen der drei Laborgruppen Fahrzeuge übergeben. Dazu existiert in der Amazon Cloud im Simple Queue Service für jede Gruppe eine FIFO-Queue. Über die SQS-API werden in JSON serialisierte Fahrzeuge, welche eine Simulation verlassen in die jeweilige Queue der Gruppe gepusht. Simulationen anderer Gruppen können Queues anderer Gruppen abonnieren und somit die Fahrzeuge in Echtzeit erhalten.
Die WCF abstrahiert das Konzept des Endpunktes durch eine Trennung in Address, Binding und Contract (ABC-Prinzip). Die Address (Adresse) ist ein URI, der den Ort des Dienstes beschreibt und somit seine Erreichbarkeit für die Dienstkonsumenten kennzeichnet. Das Binding (Anbindung) beschreibt die Art der Kommunikation, worunter unter anderem die Merkmale der Kodierung und des Protokolls fallen. Der Contract (Vertrag) stellt die Dienstdefinition, insbesondere die zur Verfügung gestellten Methoden beinhaltend, dar.
Die Bausteinsicht verdeutlicht die Anwendung dieses Konzeptes:
Die Generierung erfolgt mittels "GraphML File Format".
Die GraphML Dateierweiterung wird von Dateien, die mit Programmen ähnlich dem von yEd erstellt werden, verwendet. Dieses Programm ist ein beliebtes Diagramm-Schöpfer- oder Diagramming-Programm, das große Mengen an Daten aufnehmen kann. GraphML beruht auf der Extensible Markup Language oder XML. Das Format sowohl für Menschen, als auch maschinell lesbar, so dass diese Datei es möglich macht, die vielen Formen wie Hypergraphen, gemischte Graphen und ungerichtete/gerichtete Graphen abzudecken. Diese Diagramme stellen Knoten, Kanten und Zahlenwerte dar, die vom Benutzer definiert wurden.
Verbindet mit dem SimulationService, aktualisiert den Service per Timer und zeichnet erneut via Timer. Bootstrapper implementiert Prism.Unity.UnityBootstrapper, die eine Basisklasse ist, die eine grundlegende Bootstrapping-Sequenz bereitstellt. Diese registriert die meisten Prism Library-Assets in einem Microsoft.Practices.Unity.IUnityContainer
Die VehicleHandoverLibrary verwendet eine Cloud-MessageQueue für den Datenaustausch zwischen den Gruppen. Dadurch können Fahrzeuge in Echtzeit zwischen entfernten Systemen übertragen werden. Es spielt dabei keine Rolle in welcher Programmiersprache die Systeme entwickelt wurden bzw. in welcher Laufzeitumgebung diese laufen, solange gegen die SQS-API entwickelt wird. Somit wäre es beispielsweise auch problemlos möglich, Simulationen die in Java o.Ä. programmiert wurden anzubinden.
Die Entwurfsentscheidungen basieren hauptsächlich auf oben genannte Konzepte. Bereits im Anfangsstadium des Projektes wurde entschieden die Kommunikation über WCF zu implementieren. Kurz danach fiel die Entscheidung im UI-Bereich mit Bootsrapper zu arbeiten um die Komplexität der Grafik gering zu halten.
- Effizienz: die Performance des System wird durch VisualStudio Tools immer wieder geprüft. Geschickte Aufteilung der Prozesse in verschiedene Threads soll das Verbrauchsverhalten optimieren.
- Änderbarkeit: eine Modifizierung innerhalb des Codes ist unproblematisch aufgrund der laufenden Codedoku.
- Zuverlässigkeit: Die Zuverlässigkeit der einzelnen Komponenten wird einerseits durch Unit-Tests uns andererseits durch gegenseitiges manuelles Testing gewährleistet. Die Applikation wird immer lauffähig gehalten. Neue Implementierungen werden erst nach erfolgreiche Tests eingecheckt.
- Funktionalität: Das Verhalten innerhalb der Simulation soll technisch der Realität entsprechen. Es wird bewusst kein Fokus auf realistisch aussehende Straßen oder Fahrzeuge gelegt. Dafür sollen beispielsweise neue Straßen schnell und einfach gezeichnet werden können.
- Benutzbarkeit: Die Benutzung soll intuitiv erfolgen. In der GUI werden nur wenige bzw. die notwendige Buttons zu Verfügung gestellt. Es soll ein Debug-Modus eingeführt werden um mehrere Informationen pro Fahrzeug zeigen zu können
- Übertragbarkeit: Eine Anpassung soll unkompliziert und schnell sein. Durch Benutzung von mehreren logisch und unabhängig aufgebauten Komponenten, können diese durch eine andere Komponente ausgetauscht werden.
Aktuelle technische Schulden:
- keine
durch von Anfang an durchdachtes Konzept und gute Zusammenarbeit in Team gab es keine grobe Risiken oder technischen Schulden.