PDF file - IDB - Universität Bonn

Friedrich-Wilhelms-Universität Bonn
Institut für Informatik III
Arbeitsgruppe Intelligente Datenbanken“
”
Diplomarbeit
Entwurf und Implementierung eines
datenbankgestützten Werkzeugs
zum Monitoring
simulierter Straßenverkehrsszenarien
Sandra Loch und Youness Dehbi
19. Juni 2008
Betreuer: Prof. Dr. Rainer Manthey
2
Inhaltsverzeichnis
1 Einleitung
7
2 Grundlagen aus der Informatik
2.1 Datenbanken . . . . . . . . . . . . . . . .
2.1.1 Datenbanksysteme . . . . . . . . .
2.1.2 Datenbankentwurf . . . . . . . . .
2.2 Structured Query Language (SQL) . . . .
2.2.1 SQL-Grundlagen . . . . . . . . . .
2.2.2 Anfrageoptimierung . . . . . . . . .
2.3 Java . . . . . . . . . . . . . . . . . . . . .
2.3.1 Grundlegendes . . . . . . . . . . .
2.3.2 Threads . . . . . . . . . . . . . . .
2.3.3 JDBC . . . . . . . . . . . . . . . .
2.3.4 Swing . . . . . . . . . . . . . . . .
2.4 Extensible Markup Language (XML) . . .
2.5 Methoden der Softwaretechnologie . . . . .
2.5.1 Unified Modeling Language (UML)
2.5.2 Design Patterns . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
13
19
19
23
25
26
27
28
30
32
33
35
40
3 Grundlagen aus dem Verkehrswesen
43
3.1 Begriffsbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Straßenverkehrsordnung . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Grundlagen der Simulation
4.1 Simulationsmodelle . . . . .
4.2 Diskrete Ereignissimulation
4.3 Multiagentensimulation . . .
4.4 Verkehrssimulationsmodelle
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Entwurf des Systems
5.1 Anforderungserhebung . . . . . . . . . .
5.1.1 Anforderungserhebung Simulator
5.1.2 Anforderungserhebung Monitor .
5.2 Datenbankentwurf . . . . . . . . . . . .
5.2.1 Konzeptueller Entwurf . . . . . .
5.2.2 Logischer Entwurf . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
53
56
59
.
.
.
.
.
.
63
63
63
67
69
69
75
INHALTSVERZEICHNIS
6 Architektur und Funktionalität
6.1 Gesamtarchitektur . . . . . . . . . . . . . . . . . . . .
6.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Architektur des Simulators . . . . . . . . . . . .
6.2.2 Funktionalitäten des Simulators . . . . . . . . .
6.2.3 Strukturierung der statischen Komponenten . .
6.2.4 Strukturierung der dynamischen Komponenten .
6.3 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Funktionalitäten des Monitors . . . . . . . . . .
6.3.2 Objektdesign für das GUI . . . . . . . . . . . .
6.3.3 Architektur des Monitors . . . . . . . . . . . . .
6.3.4 Organisation der Monitoraktivitäten . . . . . .
6.4 Synchronisation . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Ausgewählte Aspekte der Implementierung
7.1 Ausgewählte Aspekte der Simulation . . . . . . . . . . . . .
7.1.1 Aufbau und Synchronisation der Karten . . . . . . .
7.1.2 Verwaltung der Routen . . . . . . . . . . . . . . . . .
7.1.3 Generierung und Fortbewegung der Fahrzeuge . . . .
7.1.4 Beachtung der Verkehrsregeln . . . . . . . . . . . . .
7.2 Ausgewählte Aspekte des Monitorings . . . . . . . . . . . .
7.2.1 Formulierung der Regelverstöße in SQL . . . . . . . .
7.2.2 Verwaltung von Simulationsdaten und Regelverstößen
7.2.3 Aktualisierung des GUIs auf Zellenebene . . . . . . .
8 Zusammenfassung und Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
85
88
90
92
94
94
99
101
103
106
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
. 111
. 111
. 115
. 117
. 122
. 125
. 126
. 138
. 141
145
4
Übersicht über die Zuordnungen der Abschnitte zu den
einzelnen Autoren:
Sandra Loch:
2.1.1 Datenbanksysteme
2.1.2 Datenbankentwurf (Relationales Modell, Umsetzung ER- zu relationalem Schema)
2.2.1 SQL-Grundlagen (Datenmanipulationssprache)
2.2.2 Anfrageoptimierung
2.3.4 Swing
2.5.1 Unified Modeling Language (UML)
3
Grundlagen aus dem Verkehrswesen
5.1.2 Anforderungserhebung Monitor
5.2.1 Konzeptueller Entwurf
6.3
Monitor
7.2
Ausgewählte Aspekte des Monitorings
Youness Dehbi:
2.1.2 Datenbankentwurf (Entity-Relationship-Modell)
2.2.1 SQL-Grundlagen (Datendefinitionssprache)
2.3.1 Grundlegendes
2.3.2 Threads
2.3.3 JDBC
2.4
Extensible Markup Language (XML)
2.5.2 Design Patterns
4
Grundlagen der Simulation
5.1.1 Anforderungserhebung Simulator
5.2.2 Logischer Entwurf
6.2
Simulator
7.1
Ausgewählte Aspekte der Simulation
Die Unterkapitel 5.2.1 und 5.2.2 wurden zwar getrennt verfasst, stellen jedoch das
Ergebnis eines gemeinsamen Entwurfs dar.
Nicht hier aufgeführte Abschnitte wurden gemeinsam verfasst.
Kapitel 1
Einleitung
Im Rahmen dieser Diplomarbeit wurde einerseits ein datenbankgestützter Simulator
entworfen und implementiert, der Verkehrsszenarien im Straßenverkehr erzeugt und
regelgerechtes sowie regelwidriges Fahrverhalten simuliert. Zum anderen wurde ein
datenbankgestütztes Monitoring-System realisiert, das die vom Simulator erzeugten Daten online auswertet und ausgewählte Verstöße gegen die Straßenverkehrsordnung (wie z.B. Vorfahrtmissachtung) erkennt und meldet. Das Ergebnis stellt
ein lose gekoppeltes System aus Simulator und Monitor dar, das auf den Namen
SiMo“ getauft wurde. Dieses System verfügt über eine in Java realisierte grafische
”
Benutzeroberfläche (GUI). Die vom Simulator erzeugten Daten werden dem Monitor über eine MS Access Datenbank zur Verfügung gestellt.
Simulationen können ein mächtiges Hilfsmittel sein, um mit Systemen aus der realen Welt zu experimentieren. So lässt sich ein in der Entwicklung befindliches System mithilfe von Simulation erproben und untersuchen, bevor es in der Realität
tatsächlich zum Einsatz kommt. Durch Simulation können verschiedene Parameter
des zu entwickelnden Systems manipuliert werden. Durch die Auswertung des daraus
resultierenden Verhaltens lassen sich schließlich Verbesserungsmöglichkeiten ableiten. Auch nach Einführung der Systeme im realen“ Einsatzgebiet kann Simulation
”
entscheidende Vorteile mit sich bringen. Das Experimentieren mit solchen Systemen
im laufenden Betrieb ist meist kostspielig und zeitaufwändig. In vielen Fällen ist
es sogar aus ethischen Gründen bzw. aufgrund von potentiellen Gefahren gar nicht
möglich, Versuche in der realen Welt durchführen zu lassen.
Auch im Bereich des Verkehrs finden Simulationen Einsatz. Es gibt zahlreiche Anwendungsfelder für Verkehrssimulatoren. Mit deren Hilfe können u.a. Verkehrsprognosen erstellt und zur Vermeidung von Staus verwendet werden. Das Verkehrsinformationssystem autobahn.NRW“ erstellt z.B. durch Simulation von Verkehrs”
abläufen Prognosen für die Stauentwicklung auf Autobahnen Nordrhein-Westfalens
[Min].
7
1 EINLEITUNG
Weiterhin bietet eine Verkehrssimulation die Möglichkeit, für die Verkehrsplanung
die Auswirkungen der den Verkehr beeinflussenden Faktoren zu studieren. Somit
lässt sich beispielsweise ein Baustellenmanagement oder die Planung für den Einsatz
von Ampeln unterstützen. Das Bonner Verkehrsmanagementsystem City Traffic“
”
ist ein Vertreter eines erfolgreich für Planung und Prognose eingesetzten Simulationssystems [Fra].
Mit zunehmendem Verkehr nimmt die Gewährleistung der Verkehrssicherheit einen
immer höheren Stellenwert ein. Daher werden bereits intensiv neue Technologien
genutzt, um den Verkehr durch automatisierte Systeme zu kontrollieren. Der Einsatz dieser Technologien reicht von der Geschwindigkeitskontrolle durch Radar über
Stauvermeidung durch Verkehrsprognosen bis hin zu Fahrerassistenzsystemen. Eine
Erhöhung der Verkehrssicherheit lässt sich durch verschiedene Maßnahmen erzielen.
Zum einen ist es möglich, gefährdete Verkehrsbereiche automatisch zu beobachten,
wodurch häufig wiederkehrende Verkehrsregelverstöße erkannt und durch Umorganisation baulicher oder verkehrstechnischer Einrichtungen vermieden werden können.
Zum anderen kann das Verhalten der Verkehrsteilnehmer z.B. durch eine Ahndung
von Ordnungswidrigkeiten positiv beeinflusst werden. Wünschenswert ist daher eine
automatisierte Überwachung des Verkehrgeschehens, wobei durch gezielte Verkehrsanalysen Erkenntnisse über Regelverstöße gewonnen werden können. Eine solche
Überwachung ist mithilfe von Monitoring-Systemen realisierbar.
Monitoring-Systeme zur Überwachung und Meldung von Ereignissen sind mittlerweile ein wichtiges Instrument zur Unterstützung der menschlichen Wahrnehmung.
Vorgänge oder Prozesse können mithilfe von analogen Sensoren aufgenommen und in
digitale Messwerte umgewandelt werden. Die daraus entstehenden Datenströme stehen schließlich für eine Überwachung von Ereignissen zur Verfügung. In der Analyse
solcher großen Datenmengen besteht die Hauptaufgabe eines Monitoring-Systems.
Dabei werden relevante Informationen meist in Echtzeit extrahiert und dem Benutzer besondere Vorkommnisse gemeldet. Der Einsatz solcher Ereignisüberwachungssysteme umfasst beispielsweise die Überwachung von Börsenkursen, die Verfolgung
von Taxis oder Frühwarnsysteme für Naturkatastrophen.
Ein Schwerpunkt dieser Arbeit liegt im datenbankgestützten Monitoring. Datenbanksysteme dienen hierbei nicht nur zur Speicherung von Daten, sondern auch der
Überwachung bestimmter Ereignisse. Bisher haben konventionelle Datenbanksysteme in diesem Bereich keine bedeutende Rolle gespielt, da sie bei der Bearbeitung
von Datenströmen ab einer gewissen Frequenz an ihre Grenzen stoßen. Deswegen
gelten datenbankgestützte Ereignisüberwachungssysteme als junges Forschungsgebiet. Dabei möchte man das Potential relationaler Datenbanken ausschöpfen, um
ihre tatsächlichen Grenzen hinsichtlich Überwachungsaufgaben zu erkennen.
Das Hauptaugenmerk der gesamten Arbeit liegt auf dem Einsatz eines Datenbankmanagementsystems zur Analyse von Datenströmen. Klassischerweise verändern
sich die Daten relativ selten, während die Anfragen von stets wechselnder Natur sind.
Im Gegensatz dazu handelt es sich bei Ereignisüberwachungssystemen um gleichblei-
8
bende Abfragen, die auf einer sich stets ändernden Datenmenge ausgewertet werden.
Solche sogenannten continuous queries“ überprüfen die Daten auf besondere Vor”
kommnisse. Die hier zugrunde liegende Arbeitshypothese liegt darin, dass sich die
deskriptive Natur der Datenbanksprache SQL besonders für Analyseaufgaben auf
großen Datenmengen eignet. Daher lassen sich deskriptiv spezielle Analysekriterien durch den Datenbankprogrammierer in SQL-Anfragen angemessen spezifizieren.
Darüber hinaus verfügen Datenbankmanagementsysteme über generische Methoden zur Organisation von komplexen Auswertungen über großen Datenmengen. Je
nach Datenbeschaffenheit werden die Anfragen DBMS-intern durch einen query
”
optimizer“ optimiert. Eine Analyse der Datenströme innerhalb des DBMS mittels
SQL-Anfragen erspart somit die Implementierung externer Analysespezialsoftware.
Aus diesen Gründen werden sowohl die Regelverstöße für den Monitor als auch die
Verkehrsregeln für den Simulator in SQL formuliert.
Der für diese Arbeit realisierte datenbankgestützte Monitor erfordert für die Überwachung des Straßenverkehrs die Erfassung interpretierbarer Daten. Bereits heutzutage produziert die Automobilindustrie Fahrzeuge, die mit Sensoren und Sendern
ausgestattet sind. Solche Fahrzeuge können Informationen über sich und ihre Umgebung liefern, was eine vielversprechende Grundlage für eine benötigte Datenerfassung darstellt. Auch ohne fahrzeugseitige Signale ist solch eine Erfassung denkbar,
indem sich beispielsweise die Daten durch Induktionsschleifen aufzeichnen ließen. Da
momentan realistische Daten zu Forschungszwecken nur schwierig zugänglich sind,
müssen künstlich Datenströme aus Verkehrsszenarien erstellt werden. Aus diesem
Grund ersetzt der Verkehrssimulator des SiMo“-Systems die in späteren Realisie”
rungen dieses Konzepts von Sensoren zu erwartenden Daten.
Außerdem bietet eine Verkehrssimulation die Möglichkeit, beliebige Verkehrssituationen zu generieren, ohne dass schwerwiegende Folgen zu erwarten sind. Für den
Testbetrieb des Monitors ist es nicht denkbar, in der Realität absichtlich verkehrswidriges Fahrverhalten zu verursachen. Ein bloßes Beobachten des realen Verkehrsgeschehens ist ebenfalls nicht in ausreichendem Maß realisierbar, da Verkehrssünder
eher die Ausnahme als die Regel darstellen.
Die Simulation orientiert sich in dieser Arbeit an der diskreten Ereignissimulation
sowie der Multiagentensimulation. Für die detaillierte Beschreibung des Verkehrs
liegt der Simulation ein mikroskopisches Modell zugrunde. Auf der Grundlage zellularer Automaten wird das Simulationsgebiet zur Bewältigung der Komplexität
diskretisiert. Simuliert werden neben den Fahrzeugen auch die Steuerung der Lichtsignalanlagen.
Als Simulationsraum“ wurde exemplarisch ein Ausschnitt des Stadtgebietes Bonn”
Nord ausgewählt. Er weist alle Eigenschaften auf, die für diese Arbeit von Interesse
sind, wie beispielsweise Mehrspurigkeit mancher Straßen oder vorfahrtregelnde Verkehrszeichen. Simuliert wird der Verkehr zwar im gesamten Straßennetz dieses Ausschnittes, für den Monitor sollen jedoch nur die innerhalb von Kreuzungen erzeugten Daten zugänglich sein. Begründet wird dies durch drei Argumente. Zum einen
9
1 EINLEITUNG
gehören Kreuzungen zu den bedeutsamsten Gefahrenpunkten im Straßenverkehr. So
zählen laut Verkehrsunfallstatistik 2007 der Polizei NRW Fehler beim Abbiegen und
die Missachtung der Vorfahrt oder des Vorrangs zu den häufigsten Unfallursachen
[Pol].
Ferner ist der Schutz der Privatsphäre ein oft diskutiertes Thema. Erst vor kurzem wurde ein Gesetz vom Bundesverfassungsgericht aufgehoben, das der Polizei die Nummernschildererfassung durch Videokameras zu Strafverfolgungszwecken
ermöglichte. Es wurde als Verstoß gegen das Grundrecht auf informationelle Selbstbestimmung betrachtet, da die Gesetzesformulierungen die Erstellung von Bewegungsprofilen nicht ausschlossen. Aus diesem Grund soll auch in dieser Arbeit die
Datenerfassung auf einzelne Kreuzungsbereiche beschränkt sein. Letztlich ist die
ausschließliche Überwachung von Kreuzungen von Vorteil, um eine gute Performanz
zu erzielen. Diese Einschränkung vermindert den Aufwand für die Interpretation von
großen Datenmengen.
Die Überwachung der Kreuzungen in Echtzeit erfordert eine Synchronisation beider Teilsysteme. Das Monitoring soll ohne Verzögerung gegenüber dem Simulationsprozess erfolgen. Darüber hinaus müssen fortlaufend die zugehörigen Benutzeroberflächen aktualisiert werden. Der wesentliche Informationsaustausch zwischen den
zwei Teilsystemen Simulator und Monitor erfolgt über eine Datenbank. Dennoch
soll die Möglichkeit bestehen, völlig unabhängig voneinander zu arbeiten. Der Simulator kann als eigenständiges Werkzeug angesehen werden. Ein Einsatz für die
Verkehrsplanung ausgewählter Stadtgebiete ist somit möglich. Ebenso ist der Monitor nicht zwingend auf die externe Datenlieferung des Simulators angewiesen. Im
realen Betrieb werden reale Datenströme in einer Datenbank abgelegt, worauf der
Monitor zugreifen kann.
Diese Unabhängigkeit spiegelt sich auch auf der grafischen Benutzeroberfläche wider: Simulator und Monitor benutzen zwar ein gemeinsames Hauptfenster, dennoch
wird dies in zwei Anzeigebereiche unterteilt. So zeigt der Simulator das gesamte
Simulationsgebiet bzw. einzelne Ausschnitte an, während der Monitor auf die Darstellung einzelner Kreuzungen beschränkt bleibt.
Zu Beginn dieser Arbeit sollen in Kapitel 2 die Grundlagen aus der Informatik
erläutert werden, die für diese Arbeit von Bedeutung sind. Kapitel 3 geht auf die
Begrifflichkeiten aus dem Verkehrswesen sowie der dem Monitoring zugrunde liegenden Straßenverkehrsordnung ein. Anschließend bietet Kapitel 4 eine Einführung in
die Thematik der Simulation, insbesondere die diskrete Ereignissimulation und die
Multiagentensimulation. Kapitel 5 diskutiert den Entwurf des Systems SiMo“. Die
”
Architektur und Funktionaliät dieses Systems werden in Kapitel 6 vorgestellt. Kapitel 7 geht auf ausgewählte Aspekte der Implementierung ein. Schließlich fasst Kapitel 8 die hier vorliegende Arbeit zusammen und gibt einen Ausblick auf zukünftige
Arbeiten im Rahmen der dies betreffenden Thematik.
10
Kapitel 2
Grundlagen aus der Informatik
In diesem Kapitel werden die Thematiken aus der Informatik eingeführt, die im
Rahmen dieser Arbeit verwendet wurden. Unterkapitel 2.1 behandelt die Grundlagen
aus dem Bereich der Datenbanken, während Kapitel 2.2 eine Einführung in die
Datenbanksprache SQL gibt. In Unterkapitel 2.3 sollen die grundlegenden in dieser
Arbeit angewandten Konzepte der Programmiersprache Java vermittelt werden. Des
Weiteren geht Unterkapitel 2.4 auf die Extensible Markup Language ein. Zuletzt
werden in Unterkapitel 2.5 die Methoden der Softwaretechnologie erläutert, welche
als Orientierung in dieser Arbeit gedient haben.
2.1
Datenbanken
Zusammen mit der Menge an Informationen steigt gleichermaßen der Bedarf an effizienter Verwaltung dieser Daten. Somit entwickelte sich vor rund 40 Jahren das
Gebiet der Datenbanksysteme als Teilgebiet der Informatik. Heutezutage gibt es
kaum einen Bereich, in dem Datenbanksysteme keinen Einsatz finden. Der klassische Verwendungszweck liegt in der organisierten und strukturierten Speicherung
von Daten. Mittlerweile ergeben sich immer wieder neue Anwendungsfelder wie z.B.
die Analyse und Extraktion großer Datenmengen zur Unterstützung von Entscheidungsprozessen oder zur Verwaltung von geographischen Informationen.
Dieses Unterkapitel soll einen Überblick über Datenbanksysteme und speziell das
in dieser Arbeit eingesetzte DBMS MS Access geben. Weiterhin werden die Techniken zum Entwurf einer Datenbank vorgestellt und erläutert, welcher zur Entwicklung
eines datenbankgestützten Systems erforderlich ist.
2.1.1
Datenbanksysteme
Ein Datenbanksystem (DBS) setzt sich aus einem Datenbankmanagementsystem
und mehreren Datenbanken zusammen. Eine Datenbank enthält anwendungsspezifische Informationen, welche einen Ausschnitt der realen Welt beschreiben. Ein
Datenbankmanagementsystem (DBMS) ist eine Software zur Verwaltung der
in den Datenbanken gespeicherten Daten. Es bietet dafür anwendungsunabhängige
Dienste an, wie Schemaverwaltung, Anfragebearbeitung, Transaktionsverwaltung
11
2 GRUNDLAGEN AUS DER INFORMATIK
und Speicherverwaltung. Neben der Speicherverwaltung gehört die effiziente Bearbeitung von Anfragen zu den wichtigsten Aufgaben eines DBMS. Jede Anfrage
wird vor der Auswertung syntaktisch analysiert und mithilfe von DBMS-spezifischen
Strategien und Heuristiken logisch und physisch verbessert. Einfluss auf den Auswertungsplan haben beispielsweise die verwendeten Operatoren oder die Größe der
Tabelle.
Abbildung 2.1 veranschaulicht diese Komposition aus Datenbanksystem und Datenbankmanagementsystem. Der Einsatz eines Datenbanksystems ermöglicht eine
zentrale Speicherung der Daten. Verschiedene Anwendungsprogramme oder aber
die Endbenutzer direkt können auf dieselbe Datenbasis zugreifen. Die Organisation
der Daten bleibt für die Anwender transparent, sie bekommen lediglich eine anwendungspezifische Sicht auf die Daten. Im Gegensatz zu Dateisystemen lassen sich
dadurch unter anderem Redundanz und Inkonsistenz vermeiden.
Datenbanksysteme können durch das unterstützte Datenmodell klassifiziert werden, welches die Struktur und die Funktionaliäten einer Datenbank festlegt. Am
weitesten verbreitet ist das relationale Datenmodell, wobei Objekte auf Tupel einer
Relation abgebildet werden (siehe Abschnitt 2.1.2).
Anwendung 1
Benutzer
Anwendung 2
Datenbankmanagementsystem
zur Verwaltung der Daten
DBMS
DBS =
DBMS + n*DB
Datenbanken zur
Speicherung von Informationen
DB
Abbildung 2.1: Komponenten eines DBS
Ein Vertreter eines kommerziellen relationalen Datenbankmanagementsystems ist
MS Access, welches im Rahmen dieser Arbeit verwendet wurde. Es ist insbesondere für kleine bis mittlere Datenbank-Anwendungen ohne Mehrbenutzerbetrieb gut
geeignet. Ein Datenbankadministrator ist nicht erforderlich, sodass es leicht auf einem Rechner einsetzbar ist.
Zentrale Komponente von MS Access ist die Microsoft Jet Engine. Sie verwaltet
die Daten und ist unter anderem für die Datenvalidierung und die Optimierung
von Anfragen zuständig. Ein heterogener Zugriff auf die Daten ist durch ODBC
12
2.1 Datenbanken
möglich. MS Access bietet als Schnittstelle eine grafische Benutzeroberfläche und
unterstützt damit visuell Definition und Manipulation der Daten. Eine SQL-Ansicht
kann automatisch generierte Anfragen in SQL anzeigen und ermöglicht dem Datenbankentwickler darüber hinaus die Formulierung beliebiger von Access unterstützter
Anfragen.
2.1.2
Datenbankentwurf
Der Entwurf ist eine wichtige Phase der Datenbankentwicklung. Er stellt einen
Übergang zwischen der Anforderungsanalyse und der Nutzung der Datenbank dar.
Der Entwurf zeichnet sich durch drei Phasen aus: konzeptueller, logischer und physischer Entwurf (siehe Abbildung 2.2).
Reale Welt
Anforderungsanalyse
Pflichtenheft
Konzeptueller Entwurf
Entity-Relationship-Schema
Logischer Entwurf
Relationales Schema
Physischer Entwurf
Physische Datenbankstruktur
Abbildung 2.2: Phasen des Datenbankentwurfs
Der konzeptuelle Entwurf ist die Brücke zwischen der Anforderungsanalyse und
dem logischen Entwurf. In dieser Phase wird aus der realen Welt in die konzeptuelle
Ebene auf dem Papier übergegangen. Mithilfe eines konzeptuellen Modells wird ein
sogenanntes konzeptuelles Schema entworfen. Dabei werden die Benutzeranforderungen durch eine formale Repräsentation beschrieben. Das klassische konzeptuelle
Modell ist das Entity-Relationship-Modell.
13
2 GRUNDLAGEN AUS DER INFORMATIK
Dem konzeptuellen Entwurf folgt die Umsetzung auf der logischen Ebene. Im
logischen Entwurf wird der zuvor durch ein konzeptuelles Schema abstrahierte
Gegenstandsbereich auf ein logisches Datenmodell abgebildet. Das daraus resultierende logische Datenbankschema ist abhängig vom zugrunde liegenden DBMS. Die
meisten kommerziellen Datenbankmanagementsysteme verwenden hierbei das relationale Datenmodell.
Das Ziel des physischen Entwurfs liegt darin, die Leistungsfähigkeit zu steigern, ohne dabei Veränderungen an der logischen Datenbankstruktur vorzunehmen.
Die physische Datenbankorganisation umfasst zur Beschleunigung der Datenbankzugriffe u.a. die Unterstützung durch Indexstrukturen sowie die Partitionierung bzw.
Gruppierung von Daten.
Im Folgenden werden der konzeptuelle sowie der logische Entwurf anhand deren
Umsetzungsmethoden erläutert. Auf den physischen Entwurf soll an dieser Stelle
nicht eingegangen werden, weil die physische Datenbankorganisation hauptsächlich
vom DBMS übernommen wird.
Entity-Relationship-Modell
Das Entity-Relationship-Modell (kurz ER-Modell) ist eine grafische Notation zur
konzeptuellen Datenmodellierung. Es stellt das Gegenstück zur Unified Modeling
Language (UML) in der Softwareentwicklung dar, welche in Unterkapitel 2.5.1 vorgestellt wird. Das ER-Modell zeichnet sich durch eine Menge von Konzepten und
Begriffen aus. Die sogenannten Entities sowie die Relationships zwischen den Entities
bilden die Grundbausteine des ER-Modells. An dieser Stelle werden die Modellierungsstrukturen erläutert, die dieses Modell anbietet.
Entities stellen die Basisobjekte des ER-Modells dar. Sie sind wohlunterscheidbare
”
physisch oder gedanklich existierende Konzepte der zu modellierenden Welt“ [KE06].
In die erste Kategorie, die in dieser Definition erwähnt, fallen tastbare Objekte wie
Fahrzeuge oder Ampeln. Beispiele für die zweite Kategorie können Institutionen wie
Universitäten oder Firmen sein. Die Eigenschaften zur Identifizierung eines Entitys
werden als Attribute bezeichnet. Ein Attribut, das ein Entity eindeutig identifiziert, wird Schlüsselattribut genannt. Die Attribute eines ausgewählten Entitys
haben Werte, wobei die Werte aller Attribute eines Entitys dieses Entity ausmachen. Die Zusammenfassung von Entities, die mindestens die gleiche Attributmenge
besitzen, wird als Entity-Typ bezeichnet. Entity-Typen, deren Existenz stets von
einem anderen Entity-Typ abhängt, heißen schwache Entity-Typen.
Im ER-Modell werden die Entity-Typen als Rechtecke dargestellt, schwache EntityTypen sind durch ein doppelt umrandetes Rechteck gekenntzeichnet. Attribute werden durch Ovale versinnbildlicht, Schlüsselattribute zusätzlich unterstrichen. Schlüsselattribute von schwachen Entity-Typen werden mit gestrichelter Linie
14
2.1 Datenbanken
Gebäude
Raumanzahl
GebNr
Abbildung 2.3: Entity-Typ Gebäude mit zwei Attributen
unterstrichen. Abbildung 2.3 zeigt den Entity-Typ Gebäude mit seinen zwei Attributen GebNr und Raumanzahl. Die Gebäudenummer GebNr dient der Identifizierung
eines Gebäudes und wird als Schlüsselattribut ausgezeichnet.
Zwischen den Entities bestehen Beziehungen, sogenannte Relationships, die ihren Zusammenhang widerspiegeln. Diese Beziehungen werden im ER-Modell nicht
als Attribute dargestellt, ihre Charakterisierung erfolgt durch ihre eigenen Attributwerte und die Werte der Schlüsselattribute der beteiligten Entities. Analog zu Entities werden Relationships, die mindestens dieselbe Attributstruktur sowie Anzahl
und Typ der Entity-Typen besitzen, zu Relationship-Typen zusammengefasst.
Relationship-Typen werden im ER-Modell durch eine Raute repräsentiert. Ist an
dem Relationship-Typ ein schwacher Entity-Typ beteiligt, wird die Raute doppelt
umrandet.
GebNr
Gebäude
1
liegt_in
N
RaumNr
Raum
Etage
Raumanzahl
Abbildung 2.4: Relationship-Typ mit schwachem Entity-Typ
Ein Entity-Typ kann an mehreren Relationship-Typen teilnehmen. RelationshipTypen mit genau zwei beteiligten Entity-Typen werden als binär bezeichnet.
Ternäre Relationship-Typen sind solche, die durch drei teilnehmende Entity-Typen
zustande kommen. Die Anzahl der Teilnehmer am Relationship-Typ nennt man
Grad des Relationship-Typs. Abbildung 2.4 stellt einen binären Relationship-Typ
zwischen den Entity-Typen Gebäude und Raum dar. Da die Existenz des Raums
von der Existenz des Gebäudes abhängt, ist der Entity-Typ Raum als schwacher
Entity-Typ beteiligt.
15
2 GRUNDLAGEN AUS DER INFORMATIK
Jedem an einer Relationship-Typ beteiligten Entity-Typ wird eine Rolle zugeteilt, die die Bedeutung des Relationship-Typs genauer erklärt. Sie vermeidet auch
jede Ambiguität, die durch eine Mehrfachbeteiligung desselben Entity-Typs am
Relationship-Typ entsteht. Die Rolle muss nicht explizit angegeben werden, sofern
keine Mehrdeutigkeit vorliegt.
Meistens ist es wichtig, bei binären Beziehungen auszudrücken, mit wie vielen Instanzen jedes beteiligte Entity sich an der Relationship beteiligen kann. Dies wird
im ER-Modell mithilfe von Kardinalitätsverhältnissen, auch Funktionalitäten
genannt, spezifiziert. Es gibt vier mögliche Kardinalitätsverhältnisse: 1:1, 1:N, N:1
und N:M. Bei einer 1:1-Relationship sind die Beziehungsteilnehmer mit höchstens
einem Entity an der Relationship beteiligt. Die anderen Funktionalitäten können
analog definiert werden. Bei der N:M-Relationship liegen keine Einschränkungen
zugrunde. Abbildung 2.4 veranschaulicht eine 1:N-Relationship. In diesem Fall wird
ein Raum genau einem Gebäude zugeordnet, während in einem Gebäude N Räume
liegen.
Die Entscheidungen während der konzeptuellen Modellierung sind nicht immer offensichtlich. Entschieden werden muss, ob Konzepte der zu modellierenden Welt
durch Entity-Typen oder Attribute repräsentiert werden sollen. Heuristisch sollten
Konzepte in zwei Fällen auf Entity-Typen abgebildet werden. Einerseits soll der
Entity-Typ nicht nur die Bezeichnung eines Konzeptes darstellen und neben dem
Schlüsselattribut ein weiteres Attribut besitzen. Auf der anderen Seite ist die Abbildung auf Entity-Typen gerechtfertigt, sobald sie mit mehr als einer Instanz an einer
Relationship teilnimmt.
Fahrzeug
is-a
Fahrrad
part-of
part-of
Rahmen
Räder
Abbildung 2.5: Generalisierung und Aggregation
Die Strukturierung von gleichartigen Entity-Typen und ihre Zuordnung zu einem
gemeinsamen Obertyp nennt man Generalisierung. Dieser besondere Zusammenhang wird im konzeptuellen Entwurf mit einer is-a-Relationship modelliert, welche
mit einem Sechseck in der ER-Notation vertreten ist. Ein weiteres Modellierungskon-
16
2.1 Datenbanken
zept wird durch die Aggregation ermöglicht, die eine andere Art der Zusammenfassung von Entity-Typen zu einem Ganzen modelliert. Im Gegensatz zur Generalisierung werden bei der Aggregation unterschiedliche Entity-Typen, die insgesamt
einen komplexen Entity-Typ bilden, strukturiert. Diese Beziehung wird als partof -Beziehung bezeichnet. Diese zwei besonderen Modellierungskonzepte werden in
Abbildung 2.5 dargestellt. Der Obertyp Fahrzeug wird durch den Untertyp Fahrrad
spezialisiert. Dieser wiederum wird durch die Gesamtheit der beiden Entity-Typen
Rahmen und Räder gebildet.
Relationales Modell
Wurde die reale Welt nun mithilfe eines Entity-Relationship-Modells auf einer konzeptuellen Ebene modelliert, kann die Umsetzung des konzeptuellen Schemas in ein
logisches beginnen. Als Standardmodell hierfür hat sich das relationale Datenmodell
durchgesetzt, welches auf Relationen, Integritätsbedingungen und Schemata basiert.
Formal gesehen ist eine n-stellige Relation R eine Teilmenge eines Kreuzproduktes von n Wertebereichen W1 , W2 , ..., Wn :
R ⊆ W1 × W2 × ... × Wn
Die Relation R besteht aus Tupeln T1 , T2 , ..., Tm , wobei m die Kardinalität der Relation festlegt. Relationen werden oft als Tabellen angesehen, da ihre aktuellen Instanzen tabellarisch darstellbar sind:
A1
R: x1
y1
A2
x2
y2
A3
x3
y3
wobei xi , yi ∈ Wi
Die Spalten einer Tabelle werden als Attribute oder Felder A1 , A2 , ..., An bezeichnet, welche über ihren Wertebereichen W1 , W2 , ..., Wn definiert sind. Die Tupel einer
Relation sind mit den Zeilen einer Tabelle gleichzusetzen. Sie entsprechen den Datenobjekten und werden mengenorientiert bearbeitet.
Umsetzung des ER-Schemas in das relationale Schema
Ein relationales Schema kann schließlich aus dem konzeptuellen Entity-RelationshipSchema entwickelt werden. Wie bereits zuvor beschrieben besteht das ER-Schema
aus Entity-Typen und Relationship-Typen, welche nun beide in Relationen transformiert werden müssen. Dafür sind verschiedene Vorgehensweisen bekannt, welche
im Folgenden erläutert werden sollen.
Zunächst wird jeder Entity-Typ auf eine Relation abgebildet, d.h. der Entity-Typ
wird zum Tabellennamen, die Attribute zu Spaltennamen. Schlüsselattribute können
mit Primärschlüsseln gleichgesetzt werden. Ein Relationship-Typ ist ganz ähnlich
umsetzbar. Je nach Kardinaliät des Relationsship-Typs gibt es jedoch verschiedene Repräsentationsmöglichkeiten. N:M-Beziehungen werden mit ihren beteiligten
17
2 GRUNDLAGEN AUS DER INFORMATIK
Attributen ebenso wie die Entity-Typen auf eine eigene Tabelle abgebildet. Die
zugehörigen Entity-Typen sind dann mithilfe ihrer Schlüsselattribute als Fremdschlüssel in die Relation einzubinden.
Für die speziellen Funktionalitäten 1:N, N:1 und 1:1, bei denen mindestens eine
Seite nur einmal vorkommen darf, ist eine zusätzliche Tabelle für den RelationshipTyp nicht zwingend erforderlich. Die Attribute des Relationship-Typs können ohne Informationsverlust in die Tabelle eingebettet werden, deren beteiligter EntityTyp mit N markiert ist. Jedoch müssen nicht alle Typen diese Beziehung eingehen. Dies kann demnach bewirken, dass die Attribute des Relationship-Typs unter
Umständen sehr viele NULL-Werte enthalten. Aufgrund des problematischen Umgangs mit NULL-Werten ist daher eine Realisierung zu wählen, die möglichst keine
unnötigen NULL-Werte produziert. Eine Aggregation wird ebenso transformiert
wie gewöhnliche Beziehungen.
Für die Generalisierung gibt es mehrere Umsetzungsmöglichkeiten, deren Vorund Nachteile abzuwägen sind.
1. Eine Generalisierung lässt sich relational realisieren, indem sowohl der Obertyp als auch der Untertyp wie bereits beschrieben auf eine eigene Tabelle
abgebildet werden. Der Untertyp enthält hierbei zudem zusätzlich zu seinen
spezialisierten auch alle vererbten Attribute. Der Vorteil liegt in der schnellen
Zugriffszeit, da keine Joins erforderlich sind. Nachteilig ist jedoch, dass die Daten redundant gespeichert werden und zudem der Speicherplatzbedarf steigt.
Um die Daten nach Änderungen weiterhin konsistent zu halten, sind referentielle Integritätsbedingungen mit Löschweitergabe sowie die Propagierung von
Einfügungen und Änderungen notwendig.
2. Eine weitere Möglichkeit besteht darin, den Obertyp wie beim ersten Ansatz
in eine eigene Relation zu transformieren. Die Untertypen erhalten hingegen
nur ihre eigenen Attribute sowie den gemeinsamen Schlüssel. Durch einen Join
über dem Schlüsselattribut kann später die komplette Information über den
Untertyp hergeleitet werden. Dies macht zwar den Zugriff auf den Untertyp
langsamer, erspart aber abgesehen vom Primärschlüssel eine redundante Speicherung und stellt die Konsistenz der Datensätze sicher. Dennoch sind auch
bei dieser Umsetzung für Einfüge- und Lösch-Operationen referentielle Integritätsbedingungen erforderlich, da sich die Tupel über mehr als eine Tabelle
verteilen.
3. Im Gegensatz dazu kann letztlich die Relation für den Obertyp auf Tupel
beschränkt sein, die keinem der Untertypen zuzuordnen sind. Stattdessen besitzen die Untertypen sowohl die vererbten als auch die eigenen Attribute,
sodass alle anderen Tupel nur in den Relationen der Untertypen vorzufinden sind. Ein Obertyp ist nun über eine Vereinigung (UNION) seiner lokalen
Repräsentation mit allen Untertypen und die Projektion auf die vererbten Attribute herleitbar. Werden die Daten des Obertyps häufig benötigt, kann sich
der verlangsamte Zugriff nachteilig auswirken. Vorteilhaft ist jedoch, dass es
18
2.2 Structured Query Language (SQL)
keinerlei Redundanz gibt und somit Anpassungen im Falle von Änderungen
entfallen.
Die Auswahl für die eine oder andere Realisierung eines ER-Modells ist abhängig
vom späteren Einsatz der Datenbank, speziell vom Speicherplatzbedarf, der Zugriffszeit bei Anfragen und den Kosten für das konsistenzerhaltende Ändern von
Daten. Im Allgemeinen ist darauf zu achten, dass eine relationale Umsetzung keine
unerwünschten Anomalien hervorruft. Diese entstehen meist durch Redundanzen,
wenn Teile der Tupel mehr als einmal in den Tabellen vertreten sind und eine Konsistenzerhaltung beim Einfügen, Löschen oder Ändern nicht sichergestellt werden
kann. Abhilfe schafft hier eine Normalisierung der Tabellen, was bedeutet, dass redundant besetzte Felder in eine eigene Tabelle ausgelagert und stattdessen durch
ihren Primärschlüssel in der Ausgangstabelle referenziert werden.
2.2
Structured Query Language (SQL)
Die Structured Query Language (SQL) ist die am weitesten verbreiteste relationale Datenbanksprache, welche in allen gängigen Datenbankmanagementsystemen
Einsatz findet. Grundlagen dieser Sprache werden in Abschnitt 2.2.1 behandelt. Abschnitt 2.2.2 geht auf die Optimierungsmöglichkeiten von Anfragen und effizienter
physischer Datenbankorganisation ein.
2.2.1
SQL-Grundlagen
Bereits 1986 wurde SQL als relationale Datenbanksprache standardisiert. Seitdem
sind verschiedene Überarbeitungen und Erweiterungen veröffentlicht worden. Die
SQL-Syntax kommerzieller Datenbanksysteme richtet sich nach diesem Standard,
dennoch sind vereinzelt DBMS-spezifische Abweichungen vorzufinden. Der im Folgenden erläuterte SQL-Standard setzt sich aus zwei Teilsprachen zusammen: Datendefinitionsprache (DDL) und Datenmanipulationssprache (DML).
Datendefinitionsprache
Die Datendefinitionssprache ist eine Sammlung von Befehlen zur Definition und Manipulation von Datenbankschemata. Ein Datenbankschema legt Namen und Struktur der Tabellen und deren Abhängigkeiten fest. Zur Definition eines Schemas gehören
Name, Zugriffsrechtangabe und eine optionale Liste von Schemaelementen. Die wichtigsten Schemaelemente sind Tabellen-, View- und Bedingungsdefinitionen. Um die
Objekte eines SQL-Schemas definieren und nachträglich verändern zu können, stehen in SQL drei Befehle zur Verfügung: CREATE, ALTER und DROP.
Die Erstellung einer neuen Tabelle im Schema kann durch den Befehl CREATE
TABLE erfolgen. Dabei wird der Name der Tabelle und ihrer Attribute mit dessen
Wertebereichen und Integritätsbedingungen angegeben:
CREATE TABLE Tabellenname
(Liste der Tabellenelemente);
19
2 GRUNDLAGEN AUS DER INFORMATIK
Ein Tabellenelement definiert entweder ein Tabellenattribut oder eine Integritätsbedingung. Attribute werden folgendermaßen definiert:
Spaltenname Datentyp
[Default-Definition]
[Liste von Spalten-Constraints]
Während Spaltenname das Tabellenattribut darstellt, wird mit Datentyp dessen
zugehöriger Wertebereich bezeichnet. Optional lässt sich die Spaltendefinition um
einen Default-Wert erweitern. Mit Spalten-Constraints werden besondere Spaltenbeschränkungen festgelegt wie z.B.:
• NOT NULL: Nullwerte für das Attribut nicht erlaubt
• UNIQUE: Mehrfaches Auftreten der Werte dieses Attributs nicht erlaubt
• CHECK: Die Werte müssen die Bedingung der Check-Klausel erfüllen
• PRIMARY KEY: Primärschlüssel
• REFERENCES: Fremdschlüssel
Besonders wichtige Integritätsbedingungen stellen die Primärschlüssel- und Fremdschlüsseldefinitionen dar. Primärschlüssel dienen zur eindeutigen Identifizierung eines Tupels:
PRIMARY KEY (Liste von Spaltennamen)
Kandidaten dafür sind solche Spalten, die weder Duplikate noch Null-Werte enthalten. Null-Werte werden zur Markierung unbekannter Attributwerte eingesetzt.
Ein Primärschlüssel kann entweder mehrspaltig (siehe obere Syntax) oder einspaltig
sein. Im zweiten Fall erfolgt die Definition meist als Spalten-Constraint:
Spaltenname Datentyp PRIMARY KEY
Eine zweite Schlüsselform wird durch den sogenannten Fremdschlüssel umgesetzt.
Dadurch werden eine oder mehrere Spalten der zu deklarierenden Tabelle gekennzeichnet, die die Werte anderer Spalten, meist Primärschlüssel, referenzieren und
damit auf deren Vorkommen beschränkt werden:
FOREIGN KEY (Liste von Spaltennamen) REFERENCES Tabellenname
SQL bietet auch die Möglichkeit vordefinierte Anfragen als sogenannte Views zu
deklarieren. In diesem Sinne ist eine View eine von jeweils einer oder mehreren
Tabellen abgeleitete virtuelle Tabelle. Views können wie folgt mit eigenem Namen
versehen werden:
CREATE VIEW View-Name AS
(
SELECT Liste von Spaltennamen
FROM Tabellenname
WHERE Bedingung
)
20
2.2 Structured Query Language (SQL)
Für die Erstellung einer View spielt der SELECT-Ausdruck eine zentrale Rolle.
Darauf wird im nächsten Abschnitt (Datenmanipulationssprache) im Detail eingegangen.
Wie bereits erwähnt wurde, kann das Datenbankschema, genauer seine Datenbankobjekte, in SQL nachträglich modifiziert werden. Mit dem Schlüsselwort ALTER
können Modifikationen vorgenommen werden, wobei mit dem Schlüsselwort DROP
ein Objekt aus dem Schema gelöscht wird. Mit ADD können neue Datenbankobjekte
wie z.B. neue Spalten einer Tabelle hinzugefügt werden.
Datenmanipulationssprache
Die Datenmanipulationssprache von SQL umfasst das Ändern sowie das Abfragen
von Daten. Für eine Datensuche in der Datenbank bietet der SQL-Standard die
SELECT-Anweisung. Ein SELECT-FROM-WHERE-Block bildet die Grundstruktur für eine Anfrage an die Datenbank:
SELECT Attributliste
FROM Tabellenliste
WHERE Bedingung
Die Tabellenliste der Anweisung stellt den Input für die Abfrage dar und zählt alle Tabellen auf, auf die zur Auswertung der Anfrage zugegriffen werden soll. Der
WHERE-Teil ist optional und bewirkt durch seinen bedingten booleschen Ausdruck
eine Selektion auf die Tupel einer Relation. Die Bedingung liefert demnach einen
Wahrheitswert und kann in zahlreichen Variationen, wie z.B. Vergleiche von Attributwerten, vorkommen. Die Ergebnismenge wird schließlich auf diejenigen Attribute
projeziert, die im SELECT-Teil aufgelistet wurden. Ein Stern (*) bedeutet hierbei,
dass alle Attribute in die Ausgabe aufgenommen werden sollen. SQL arbeitet bei
der Anfragebearbeitung mengenorientiert, Duplikate bleiben jedoch erhalten. Eine
Duplikateliminierung kann durch das Schlüsselwort DISTINCT erzwungen werden:
SELECT DISTINCT Attributliste
...
Der FROM-Teil muss nicht nur eine einfache Liste von Tabellen enthalten. Zum
einen ist eine Tabelle durch eine Unterabfrage ersetzbar. Weiterhin bietet SQL das
Konzept des relationalen Verbunds (JOIN). Hierbei werden die Tupel einer Tabelle
anhand bestimmter Kriterien, meist einem Test auf Gleichheit, mit den Tupeln einer
zweiten Tabelle verbunden:
SELECT *
FROM Tabellename1 T1 INNER JOIN Tabellenname2 T2
ON (T1.AttributY = T2.AttributY)
Veranschaulichen lässt sich dieser Verbund durch Abbildung 2.6. Tupel aus den
Tabellen T1 und T2, deren Werte in der Spalte Y gleich sind, bilden im Endergebnis
ein neues Tupel.
21
2 GRUNDLAGEN AUS DER INFORMATIK
T1:
X Y
1
b
3
c
2
a
T2:
ZY
Y Z
c
7
c
9
d
6
T3:
=
X Y Z
3
c
7
3
c
9
Abbildung 2.6: Relationaler Verbund (JOIN)
Ein JOIN ließe sich ebenso als SELECT-FROM-WHERE-Block formulieren, kann
jedoch in den meisten Fällen vom DBMS effizienter ausgewertet werden als das
folgende Äquivalent:
SELECT *
FROM Tabellename1 T1 INNER JOIN Tabellenname2 T2
WHERE T1.AttributY = T2.AttributY
Wurde eine Basistabelle erstellt, so kann diese durch eine INSERT-Anweisung mit
Daten gefüllt werden. Die Grundstruktur für das Einfügen einer Zeile beschreibt der
folgende Code:
INSERT INTO Tabellenname1 (AttributX, AttributY, ...)
VALUES (WertX, WertY, ...)
Die Tabelle kann demnach um ein Tupel erweitert werden, indem der Tabellenname
sowie die einzelnen zu den Attributen gehörenden Werte angegeben werden. Die
Angabe der Attributnamen direkt hinter dem Tabellennamen ist optional, jedoch
hilfreich, wenn man nicht alle Werte angeben möchte oder aber die Reihenfolge und
damit die Zuordnung der Werte zu den Spalten eindeutig spezifiziert werden soll.
Hierbei nicht angegebene Attribute werden beim Einfügen in die Datenbank auf
NULL gesetzt. Verletzen die neuen Werte die definierten Integritätsbedingungen,
so wird die Anfügeabfrage in der Regel vom DBMS abgewiesen. Der SQL-Standard
bietet neben dem Einfügen einzelner Tupel außerdem die Möglichkeit, mehrere Tupel
mithilfe einer beliebigen Unterabfrage in eine Tabelle einzufügen:
INSERT INTO Tabellenname1 (AttributX1, AttributY1, ...)
SELECT AttributX2, AttributY2, ...
FROM Tabellenname2
WHERE Bedingung
Bereits in der Datenbank vorhandene Daten sind mit dem UPDATE-Befehl modifizierbar. Eine SET-Klausel weist dabei den Attributen für alle sich qualifizierten
Tupel der Tabelle neue Werte zu:
UPDATE Tabellenname
SET AttributX = NeuerWertX,
AttributY = NeuerWertY
WHERE Bedingung
22
2.2 Structured Query Language (SQL)
Wie die Anweisung zeigt, ist es möglich, die Änderung auf bestimmte die Bedingung
erfüllenden Tupel einzuschränken. Der WHERE-Teil kann jedoch entfallen, wenn die
Änderungsoperation auf der gesamten Tabelle ausgeführt werden soll.
Sollen schließlich Tupel aus einer Tabelle entfernt werden, so kann dies mit einer
DELETE-Anweisung erreicht werden:
DELETE FROM Tabellenname
WHERE Bedingung
Dabei werden alle Tupel aus der spezifizierten Tabelle gelöscht, welche die Bedingung
erfüllen. Durch Weglassen der Bedingung ist es möglich, alle Zeilen aus der Tabelle
zu entfernen, sodass lediglich eine leere Tabelle in der Datenbank erhalten bleibt.
2.2.2
Anfrageoptimierung
Datenbanken können unzählig viele Datensätze speichern, wodurch mit zunehmender Menge die Anfragen auf diese Datenmengen schnell langsamer werden. Somit
ist die Anfrageoptimierung eine der wichtigsten Aufgaben während der Entwicklung
eines datenbankgestützten Systems. Während eine effiziente Implementierung der
Auswertungsoperatoren lediglich vom DBMS abhängig ist, kann die Auswertung
von komplexeren Anfragen vom Datenbankentwickler beeinflusst werden. Es gibt
sowohl logische als auch physische Optimierungsmöglichkeiten. Die Optimierung ist
stets ein sehr umfangreiches Thema, im Folgenden werden einige ausgewählte Optimierungstechniken vorgestellt.
Formulierung von Anfragen
Für SQL-Anfragen gibt es meist eine Vielzahl von Formulierungsmöglichkeiten. Sie
liefern zwar dasselbe Ergebnis, werden aber nicht immer vom DBMS gleich ausgewertet. Ziel ist es, Teilergebnisse so klein wie möglich zu halten. Dies ist insbesondere
dann von großer Bedeutung, wenn der Hauptspeicher für die Bearbeitung der Anfragen nicht groß genug ist und Ergebnisse im Hintergrundspeicher zwischengespeichert
werden müssen. Datenbankmanagementsysteme verfügen bereits über sogenannte
Query Optimizer, die durch eine Analyse der Anfrage sowie der benötigten Tabellen
eine Anfrageoptimierung durchführen. So werden beispielsweise Selektionen in der
Abarbeitungshierarchie so weit wie möglich nach oben geschoben. Auch eine Zusammenfassung von Selektionen und Kreuzprodukten zu Joins sowie eine Umordnung
von Joinfolgen tragen zu einer Performanzsteigerung bei.
Dennoch sollte auch der Datenbankentwickler sein Augenmerk auf die Art und Weise
der Anfrageformulierung richten. Beispielweise sollten im SELECT-Teil nicht erforderliche Spalten vermieden werden. Weiterhin können nicht alle Operatoren vom
Query Optimizer gleich gut optimiert werden. So lassen sich z.B. Vergleichoperatoren wie AND, OR, BETWEEN, =, LIKE, IN effizient auswerten. Die Auswertung
23
2 GRUNDLAGEN AUS DER INFORMATIK
von NOT IN oder NOT EXISTS hingegen ist teuer und selten vom DBMS optimierbar, sodass die Anfrage beispielsweise durch eine entwicklerseitige Umformung
verbessert werden sollte.
Partitionierung
Bei der Partitionierung wird die Relation in logisch zusammengehörende Teile geteilt
und zudem in verschiedenen Speicherbereichen abgelegt. Dadurch lassen sich zum
Beispiel Zugriffskosten minimieren, wenn überflüssige Teilanfragen erkannt und eliminiert werden können und Anfragen nur auf einer Partitionierung ausgeführt werden müssen. Gegebenfalls ist auch eine parallele und somit schnellere Ausführung
von Aggregatfunktionen, wie zum Beispiel Minimum- oder Summenberechnung, sowie die Auswertung von Selektion oder Projektion möglich.
Vorberechnete Auswertungen
Um das Ergebnis einer Anfrage schneller zu berechnen, kann auch ein redundantes Ablegen der Daten von Vorteil sein. Eine weitere Optimierungsmöglichkeit besteht somit in der Vorberechnung von Auswertungen. Für teure Teilanfragen, die oft
benutzt werden, sich aber nicht ständig ändern, kann das Abspeichern des Teilergebnisses zu einer immensen Beschleunigung der Auswertung führen. So können zum
einen Anfragen materialisiert werden. Dadurch liegt das Ergebnis vorberechnet in
Tabellen vor und muss lediglich ausgelesen werden. Es ist jedoch darauf zu achten,
dass Änderungen auf den Basistabellen der ursprünglichen Anfrage auch zur materialisierten Sicht durchpropagiert werden, um Inkonsistenzen zu vermeiden, sofern
dies nicht durch das DBMS unterstützt wird. Bei größeren Datenmengen kann sich
auch ein Clustering einer Tabelle lohnen. Hierbei werden die Daten inhaltlich sortiert
nah beieinander im Hintergrundspeicher abgespeichert. Somit können Selektionen
oder Joins vorberechnet abgespeichert und die Seitenzugriffe auf logisch verwandte
Datensätze beim Laden der Daten beschleunigt werden. Nachteilig ist allerdings,
dass hierbei Änderungsoperationen und das komplette Auslesen einer einzelnen Tabelle (Full Table Scan) kostspielig sind.
Indexe
In den meisten Abfragen, wie auch beim Einsatz von Joins, wird nach Datensätzen
gesucht, die ein bestimmtes Kriterium erfüllen. Auch ein Sortieren von Datensätzen
basiert auf Feldvergleichen. In der Regel muss dafür die gesamte Tabelle geladen und
jedes einzelne Tupel auf die Bedingung hin überprüft werden. Um unnötige Seitenzugriffe und Vergleiche zu verhindern, kann das Anlegen von Indexen auf den für die
Selektion notwendigen Spalten hilfreich sein. Dies ermöglicht die gezielte Suche nach
qualifizierenden Tupeln. Je nach Selektionsbedingung bieten sich verschiedene Arten von Indexen an, wie z.B. Baumstrukturen oder Bitlisten. Auch hierbei wird eine
Optimierung durch Redundanz erreicht. Ein Index benötigt demnach zusätzlichen
24
2.3 Java
Speicherplatz. Zudem macht er eventuelle Änderungsoperationen teurer, da der Index bei jeder UPDATE-Operation neu aufgebaut werden muss. Somit ist abzuwägen,
ob die Effizienzsteigerung der Anfrage größer ist als die Kosten durch ein eventuelles
Ändern, Löschen oder Hinzufügen von Datensätzen.
MS Access spezifische Optimierungen
MS Access bietet ebenfalls einige Funktionalitäten, die den Datenbankentwickler
bei der Datenbankoptimierung unterstützen. Im Folgenden soll darauf kurz eingegangen werden.
• Komprimierung
Bei jeder Änderung werden vom DBMS Kopien der Daten erstellt, sodass
regelmäßig eine Komprimierung notwendig wird. Mit der Option Datenbank
”
komprimieren und reparieren...“, welche zu den Datenbank-Dienstprogrammen
gehört, wird die Datenbank um ein Vielfaches komprimiert. Des Weiteren werden die Daten dadurch neu strukturiert und für Abfragen zusammenhängender
und damit eventuell für Seitenzugriffe günstiger abgespeichert.
• Leistungsanalyse
Die Option Leistung“ – zu finden unter Extras - Analyse“ – analysiert die
”
”
aktuelle Datenbank und gibt Empfehlungen und Vorschläge zur Steigerung der
Effizienz. So können zum Beispiel auch sinnvolle Indexe oder Beziehungen automatisch angelegt werden. Die interne sogenannte Rushmore“-Optimierung
”
setzt insbesondere indizierte Felder voraus.
• JetShowPlan
Nicht unmittelbar zugänglich, aber dennoch hilfreich während der Optimierung, ist die Erstellung eines Auswertungsplanes. MS Access bietet die Möglichkeit, die Anfragebearbeitung in einer Datei showplan.out“ zu dokumentieren.
”
Daraus lassen sich Rückschlüsse auf kostenintensive Teilanfragen machen, auf
deren Grundlage sich die Anfrage manuell verbessern lässt. Diese Funktionalität wird aktiviert, sobald die Variable JETSHOWPLAN in der WindowsRegistry auf ON gesetzt wird.
2.3
Java
Java ist eine objektorientierte Sprache, die sich durch ihre Plattformunabhängigkeit
auszeichnet. Dies ist dem vom Java Compiler erzeugten Byte Code zu verdanken.
Von der objektorientierten Natur abgesehen stellt Java gute Mittel zur Gestaltung grafischer Oberflächen sowie zur Erstellung nebenläufiger Anwendungen zu
Verfügung. Die im Rahmen dieser Arbeit angewandten Aspekte dieser Sprache werden in diesem Abschnitt kurz vorgestellt.
25
2 GRUNDLAGEN AUS DER INFORMATIK
2.3.1
Grundlegendes
Der objektorientierte Ansatz baut auf dem Gedanken Alles ist ein Objekt“ auf.
”
Ein Objekt ist ein tatsächlich existierendes Ding“ aus der Anwendungswelt des
”
”
Programms. Es spielt dabei keine Rolle, ob es sich um die programmierte Umsetzung eines konkret existierenden Gegenstandes handelt, oder ob nur“ ein abstraktes
”
Konzept modelliert wird“ [Krü04].
Jedes Objekt ist durch eine Identität, einen Zustand und ein Verhalten charakterisiert. Ein Bündel gleichartiger Objekte wird als Klasse bezeichnet. Die Klassen sind
ein sehr wichtiger Begriff in der Objektorientierung. Die Identität eines Objekts wird
durch eine Menge von Variablen ausgedrückt, die sogenannten Attribute, die den
Zustand dieses Objekts definieren und sich von einer Instanz einer Klasse zur anderen unterscheiden können. Objekte können Operationen ausführen, die dadurch ihr
Verhalten darstellen. Diese Operationen werden Methoden genannt. Die Attribute
bleiben in der Regel aus externer Sicht verborgen, sodass der Zustand der Klasse
nur über bestimmte Methoden beeinflusst werden kann. Dies wird als Kapselung
bezeichnet.
Die Objekte und Klassen werden nicht einzeln betrachtet, sondern sind untereinander durch Beziehungen verbunden. Eine wichtige Beziehung, die den Generalisierungsbzw. Spezialisierungsaspekt betont, wird durch die Vererbung umgesetzt. Diese
Beziehung wird in Java durch das Schlüsselwort extends explizit beschrieben und
soll durch den folgenden Code veranschaulicht werden:
public class Mitarbeiter
{
private String _name;
private String _geburtsdatum;
}
public class Professor extends Mitarbeiter
{
private String _grad;
}
Die Klasse Professor leitet die obere Klasse Mitarbeiter ab. Die untere Klasse erbt
die Eigenschaften der oberen Klasse wie Name und Geburtsdatum, kann jedoch andere Attribute wie Grad besitzen.
Ein anderes Merkmal der Objektorientierung stellt der Polymorphismus (dt. Vielfältigkeit) dar. Dies erlaubt es, Methoden mit gleichem Namen und gleicher Signatur
in den Unterklassen neu zu implementieren, d.h. zu überschreiben, und an deren Anforderungen anzupassen. Das führt zur Verstärkung der Wiederverwendbarkeit und
Flexibilität, die für die Entwicklung von Software-Systemen große Bedeutung trägt.
26
2.3 Java
Dies macht sich insbesondere in dem von Java unterstützten Late Binding bzw.
Dynamic Binding bemerkbar. Dabei wird erst zur Laufzeit und nicht direkt zur
Kompilierzeit entschieden, welche Umsetzung der Methode in der Klassenhierarchie
aufgerufen werden soll.
2.3.2
Threads
Threads gehören mit zu den wichtigsten Konzepten, die Java anbietet. Sie ermöglichen eine scheinbar parallele Ausführung verschiedener Programmteile. Diese Programmteile werden verzahnt abgearbeitet, sodass man den Eindruck gewinnt, dass
sie wirklich parallel ausgeführt werden. Im Gegensatz zu einem Prozess besitzt ein
Thread keinen eigenen Speicher, sondern greift mit anderen Threads auf einen gemeinsamen Adressierungsraum zu. Damit werden Zeit und Systemressourcen gespart.
Es gibt zwei Wege, um einen Thread zu starten: Entweder implementiert man die
Schnittstelle Runnable, oder man erweitert die Klasse java.lang.Thread. Im ersten
Fall wird die Methode run() des Runnable-Interfaces implementiert, das RunnableObjekt im Thread-Konstruktor übergeben und dann die Methode start() dieses erzeugten Threads aufgerufen. Beim zweiten Weg lässt man die betrachtete Klasse von
der Thread-Klasse erben. Hierbei reicht es, dass die run()-Methode überschrieben
wird, die den Code beinhaltet, der nebenläufig mit den restlichen Programmen auszuführen ist. Wenn die Klasse, die man als Thread realisieren möchte, keine bereits
abgeleitete Klasse ist, ist die zweite Variante die bessere, welche das folgende CodeFragment zeigt:
class MyThread extends Thread
{
public void run()
{
//Das auszuführende Code-Fragment
try
{
...
} catch (InterruptedException e) {}
}
}
}
...
MyThread mythread = new MyThread();
mythread.start();
Um das Verhalten des Threads zu kontrollieren, bieten sich verschiedene Möglichkeiten an. Mit der Methode sleep() wird z.B. die Ausführung des Threads für eine
bestimmte Anzahl von Millisekunden gestoppt. Der Aufruf von sleep() muss in einem
27
2 GRUNDLAGEN AUS DER INFORMATIK
try-catch-Block gekapselt werden. Solange die sleep()-Methode ausgeführt wird, ist
eine Sperre auf das Thread-Objekt gesetzt. Dies kann z.B. für 1000 Millisekunden
wie folgt geschehen:
try
{
sleep(1000);
}
catch (InterruptedException e)
{
throw new RuntimeException(e);
}
Die Threads können miteinander kooperieren und auf das Eintreffen bestimmter
Ereignisse warten. Dies ist durch die Methoden wait() und notify() möglich. Es gibt
zwei Sorten von wait(). Die eine nimmt einen Millisekunden-Parameter entgegen
und hat dieselbe Auswirkung wie sleep(), während die andere Variante parameterlos
ist. In letzterem Fall wird die Methode solange ausgeführt, bis eine der Methoden
notify() bzw. notifyAll() aufgerufen wird. Im Gegensatz zu sleep() kann die Sperre
beim Aufruf von wait() freigegeben werden. Die Ausführung von wait() darf nur
innerhalb eines synchronized -Blocks erfolgen, wie der folgende Code zeigt:
synchronized(this)
{
try
{
wait();
}
catch (InterruptedException e)
{
throw new RuntimeException(e);
}
}
Wird eine der Methoden wait(), notify() oder notifyAll() in einer nicht mit synchronized ausgezeichneten Methode aufgerufen, wird das Programm zwar kompiliert,
aber zur Laufzeit eine IllegalMonitorStateException ausgegeben. Das bedeutet, dass
der Thread, der diese Methode aufgerufen hat, keine Sperre auf den aufgerufenen
Thread besitzt. Ein durch das Schlüsselwort synchronized gekennzeichneter Code
ermöglicht einen exklusiven Zugriff auf den Thread.
2.3.3
JDBC
JDBC, inoffiziell mit Java Database Connectivity gleichgesetzt, bezeichnet die Schnittstelle zwischen einer SQL-Datenbank und der Java-Applikation, die darauf Zugriff nehmen soll. JDBC ist eine Java-Klassenbibliothek zur Ausführung von SQLAnweisungen, die zusätzliche Prozesse für die Erstellung von Anfragen vermeidet.
28
2.3 Java
Bevor eine Datenbankverbindung aufgebaut werden kann, muss der entsprechende JDBC-Treiber durch den Aufruf der Methode Class.forName( Treiber-Name“)
”
geladen werden. Dies ist im Package java.sql enthalten, welches importiert werden
muss.
Der Zugriff auf die Datenbank kann mittels JDBC in den folgenden Schritten durchgeführt werden:
1. Verbindungsaufbau zur Datenbank über den zugehörigen JDBC-Treiber des
verwendeten DBMS. Dies erfolgt über die Methode getConnection(), die mindestens die Adresse der Datenbank in Form einer URL als Parameter erwartet:
Connection con = DriverManager.getConnection(db_url);
2. Erzeugung einer SQL-Anweisung. Dafür muss ein Statement-Objekt erzeugt
werden, was durch die Methode createStatement() erfolgen kann:
Statement stmt = con.createStatement();
3. Ausführung der SQL-Anweisung. Während die Methode executeUpdate() Änderungsoperationen ausführt, können Anfragen mit der Methode executeQuery()
durchgeführt werden:
ResultSet rst = stmt.executeQuery("Meine Anfrage");
4. Ergebnisse einer Anfrage aus der Datenbank lesen. Die Methode executeQuery()
gibt ein ResultSet-Objekt zurück, welches die Ergebnismenge repräsentiert.
Um auf diese Menge zugreifen zu können, stellt die Klasse ResultSet eine
Iterator-Schnittstelle mit datentypspezifischen Getter-Methoden zur Verfügung:
while (rst.next())
{
mein_int = rst.getInt(1);
}
5. Verbindung mit der Datenbank schließen. Wurde die Ergebnismenge verarbeitet, soll diese sowie das Statement und anschließend die Verbindung geschlossen werden:
rst.close();
stmt.close();
con.close();
29
2 GRUNDLAGEN AUS DER INFORMATIK
2.3.4
Swing
Swing ist eine vollständig in Java geschriebene Bibliothek zur Gestaltung von grafischen Benutzeroberflächen (Graphical User Interface, GUI) und umfasst die Darstellung von GUI-Komponenten, das Zeichnen sowie das Event-Handling.
Eine Benutzeroberfläche lässt sich durch das Zusammensetzen und Verschachteln
der verschiedensten Swing-Elemente aufbauen, welche grob in Top-Level-Container,
Grundkomponenten und Menüs unterteilt werden können. Der Hauptzweck eines
Containers liegt darin, dass er andere Container und Komponenten enthalten und
entsprechend seines Layouts anordnen kann. Die Grundlage für ein Fenster einer
Abbildung 2.7: JFrame mit GUI-Komponenten
Standardanwendung stellt hierbei die Top-Level-Container-Klasse JFrame dar. Ihr
werden - gegebenfalls verschachtelt - alle die Benutzeroberfläche beinhaltenden GUIElemente hinzugefügt. Das Fenster kann dafür zunächst in eine optionale Menüleiste
JMenuBar und einen Container contentPane für den eigentlichen Inhalt des Fensters unterteilt werden. Die Oberklasse Container, von der alle GUI-Komponenten
abgeleitet werden, stellt die Methode add(Component c) zur Verfügung, mit der sich
beliebige Komponenten hinzufügen lassen. Die GUI-Elemente von Swing, in der Regel Unterklassen von javax.swing.JComponent, umfassen für die Darstellung eines
GUIs eine Vielzahl von einfachen und komplexen Komponenten, wie z.B. Schaltflächen, Auswahllisten, Eingabefelder oder Baumstrukturen (vgl. Abbildung 2.7).
0 1
North
West
Center
East
2 3 4 5
6
0
1
2
3
South
BorderLayout
GridBagLayout
CardLayout
Abbildung 2.8: Layout-Manager im Vergleich
30
2.3 Java
Zur komfortablen Anordnung dieser Elemente bietet Swing verschiedene LayoutManager (siehe Abbildung 2.8). Je nach Wahl des Layout-Managers passen sich
die Komponenten automatisch an Ausmaß und Positionierung anderer Komponenten sowie die Größe des Anwendungsfensters an. Eine Möglichkeit stellt das sogenannte BorderLayout dar. Hierbei lassen sich die GUI-Komponenten mithilfe der
BorderLayout-Konstanten NORTH, WEST, EAST, SOUTH und CENTER im Container platzieren:
meinContainer.setLayout(new BorderLayout());
meinContainer.add(new JButton(), BorderLayout.NORTH);
Ein weitaus flexiblerer und somit der aufwändigste Layout-Manager ist das
GridBagLayout. Hierbei wird die Fläche logisch in ein rechteckiges Gitter unterteilt.
Um die Positionierung im Detail festlegen zu können, werden sogenannte GridBagConstraints definiert und einer Instanz der Klasse GridBagLayout zugeordnet. Die
Bestandteile eines Containers können sich hierbei über mehrere Gitterzellen ausbreiten und freien Platz zu unterschiedlichen Graden füllen.
Ein anderes Layout-Konzept stellt das CardLayout bereit, bei dem sich beliebige
gleichartige Komponenten den gleichen Platz teilen. Dieser Layout-Manager organisiert die Komponenten wie Karteikarten auf einem Stapel, bei dem stets nur die
oberste sichtbar ist. Für einen Wechsel der obersten Karte lässt sich die erste und
letzte sowie die nächste und vorherige Karte ansprechen oder aber explizit eine Komponente mit einem zuvor vergebenen Namen aufrufen.
Swing stellt weiterhin Mittel zum Zeichnen einfacher Grundelemente und zur Darstellung von Bildern zur Verfügung. Die Oberklasse aller GUI-Grundkomponenten
JComponent enthält hierfür insbesondere die Methode paintComponent(Graphics g),
die stets aufgerufen wird, wenn ein Objekt neu gezeichnet werden muss. Um eigene Zeichnungen auf einer Komponente zu erstellen, kann diese vererbte Methode überschrieben und dabei mithilfe des intern von Swing übergebenen GraphicsObjektes Operationen zum Zeichnen ausgeführt werden. Die Klasse Graphics stellt
dafür zum einen eine Methode drawImage() zur Verfügung, die es ermöglicht eine Grafik auf der Komponente zu platzieren. Zum anderen existieren verschiedene
Methoden drawXY() zum Zeichnen grafischer Grundelemente wie z.B. Linien oder
Rechtecke.
Swing arbeitet nach dem sogenannten Model-Delegate-Prinzip, welches eine Variante der Model-View-Controller-Architektur ist. Dies bedeutet, dass zum einen ein
Modell existiert, welches die Zustände der Daten bereithält. Zum anderen besteht
getrennt davon ein als Beobachter agierendes Objekt, in diesem Fall eine Zusammenfassung von View und Controller, welches auf Änderungen des Modells reagiert (vgl. auch Model-View-Controller, Abschnitt 2.5.2). Daher lassen sich SwingKomponenten an die speziellen Bedürfnisse anpassen, indem sowohl ein eigenes Modell definiert als auch ein Event-Listener der Komponente hinzugefügt werden kann.
31
2 GRUNDLAGEN AUS DER INFORMATIK
Die Behandlung von Ereignissen ist eine der wichtigsten Aufgaben einer Benutzeroberfläche und in Swing sehr leicht umsetzbar. GUI-Komponenten bieten bereits
Methoden und Interfaces für das Event-Handling an. So kann zum Beispiel die Reaktion auf einen Klick einer Schaltfläche (JButton) wie folgt umgesetzt werden:
JButton jButton = new JButton("Mein Button");
jButton.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
//auf Klick reagieren
}
});
Mithilfe verschiedener Event-Listener kann auf die Zustandsänderungen der GUIKomponenten reagiert werden. Dies reicht von der Auswahl von Elementen einer
Liste über die Bewegung des Mauszeigers bis hin zur Größenänderung von Komponenten.
2.4
Extensible Markup Language (XML)
Die Extensible Markup Language (XML) wurde vom World Wide Web Consortium
(W3C) in die Welt gerufen, um u.a. eine klare Trennung zwischen Formatierung und
Inhalt eines Dokumentes zu erzielen [Wor]. XML gehört zur Familie der Auszeichnungssprachen. Sie bewirkt eine strukturierte Gliederung der Daten und Dokumente. So besitzt ein XML-Dokument eine baumartige Struktur, die hierarchische und
strukturierte Daten unterstützt, und besteht damit aus hierarchisch geschachtelten
Elementen.
Die hierarchische Struktur von XML kann durch das folgende Beispiel veranschaulicht werden:
<telefonbucheintrag>
<name>
<vorname>Max</vorname>
<nachname>Mustermann</nachname>
</name>
<nummer>0228-123456</nummer>
</telefonbucheintrag>
Ein Element wie z.B. telefonbucheintrag kann Unterelemente besitzen, die sogenannten Kinder, die wiederum Kinder erzeugen können. Im vorigen Beispiel wurde das
Element name noch zu Vor- und Nachname aufgespalten.
Während man sich z.B. bei einem HTML-Dokument an einen vordefinierten Satz
von Tags halten muss, kann man bei XML leicht neue Elemente definieren und ebenso anwenden. Diese Elemente werden in einer sogenannten DTD-Datei (Document
32
2.5 Methoden der Softwaretechnologie
Type Definition) deklariert. Die DTD-Datei dient der Sicherung der Wohlgeformheit des XML-Dokuments. Außerdem zeichnet sich XML durch eine plattformunabhängige Daten-Darstellung aus.
Um XML-Dokumente verarbeiten und parsen zu können, bieten sich mehrere Möglichkeiten an. Es gibt insbesondere drei Verarbeitungstypen, die sich etabliert haben:
SAX (Simple API for XML), DOM (Document Object Model) und STAX (Streaming API for XML).
Bei SAX wird die XML-Datei sequentiell durchgegangen. Die Verarbeitung resultiert aus einem ereignisbasierten API (Application Programming Interface). Ereignisbasiert heißt, dass der Parser auf die Elemente der Dokumentstruktur reagiert,
indem er vordefinierte Methoden für entsprechende Elemente, wie z.B. Start-Tags,
aufruft. Dies hat zum Vorteil, dass man effizient und schnell das Dokument durchlaufen kann. Der Nachteil besteht allerdings darin, dass man durch die sequentielle
Bearbeitung des Dokuments nicht beliebig auf die Teildokumente zugreifen kann.
In diesem Fall ist Zwischenspeichern eine Notwendigkeit. SAX wird klassischerweise
von Browsern für die Darstellung von XML-Dateien genutzt.
Beim DOM-Ansatz hingegen wird die Baumstruktur zunächst auf den Hauptspeicher abgebildet und dann durchlaufen. Das ermöglicht eine große Flexibilität bei der
Behandlung des Dokuments, sodass der Zugriff auf beliebige Teile des Dokuments
leicht möglich ist. Diese Strategie ist jedoch für sehr große Dateien ungeeignet, weil
dafür viel Hauptspeicher benötigt wird. DOM wurde von W3C unabhängig von den
Programmiersprachen entwickelt. Daher bietet es unterschiedliche Schnittstellen, die
von den verschiedenen Programmiersprachen implementiert werden können.
STAX arbeitet nach dem Iterator- bzw. Cursor-Ansatz, wobei stets die nächsten Bestandteile des Dokuments angefordert werden müssen. Zunächst wird eine
XMLInputFactory und dementsprechend der passende Parser erzeugt. Für die CursorVerarbeitung steht ein XMLStreamReader zur Verfügung, während für die IteratorVerarbeitung ein XMLEventReader benutzt wird. Mit der Methode next() wird die
jeweils nächste Komponente der XML-Datei ermittelt und je nach Typ verarbeitet.
2.5
Methoden der Softwaretechnologie
Softwaretechnologie befasst sich mit Spezifikation, Entwurf und Erstellung komplexer Softwaresysteme durch die praktische zielorientierte Verwendung von wissenschaftlichen Methoden, Prinzipien und Werkzeugen. Für eine qualitätsorientierte
Softwareentwicklung stehen verschiedene Prinzipien im Vordergrund.
Zur Bewältigung der Komplexität zu entwickelnder Systeme ist zum einen die Trennung der verschiedenen Anforderungen notwendig. Dies hat zum Vorteil, dass sich
die Aufgaben unter verschiedenen Projektmitarbeitern aufteilen lassen. Ein weiterer wichtiger Aspekt der Softwaretechnologie ist die Modularität. Hierbei werden
komplexe Systeme in Komponenten zerlegt, die untereinander möglichst geringe
33
2 GRUNDLAGEN AUS DER INFORMATIK
Abhängigkeiten und einen intern starken Zusammenhalt aufweisen. Durch Beachtung dieses Prinzips lässt sich das System leichter modifizieren und seine einzelnen
Komponenten wiederverwenden.
Darüber hinaus stellt die Abstraktion der Realität eine wichtige Säule der Softwaretechnologie dar. Dort werden die wesentlichen Aspekte des Problems betrachtet und
hervorgehoben, ohne sich in Details zu verlieren. Ferner können mit der Zeit neue
Anforderungen an das System hinzukommen. Somit ist es von Wichtigkeit, zukunftsorientiert eventuelle Änderungen in Betracht zu ziehen. Um die Wiederverwendbarkeit zu erhöhen und die Komplexität zu reduzieren ist es von Nutzen, Sachverhalte
so weit wie möglich zu verallgemeinern. Generalisierung ist damit ein fundamentales
Prinzip der Softwaretechnologie. Zuletzt sollte sich der Softwareentwicklungsprozess
durch ein inkrementelles Vorgehen auszeichnen. Dafür wird fortlaufend Feedback
entgegengenommen, um die Anforderungsziele im Auge zu behalten und dementsprechend stets das System zu verbessern.
Im Folgenden werden die im Rahmen dieser Arbeit verwandten Methoden und Techniken vorgestellt. Abschnitt 2.5.1 behandelt UML als Modellierungssprache für die
Softwareentwicklung. In Abschnitt 2.5.2 wird auf Design Patterns als Vorlagen für
Entwurfs- und Designprobleme eingegangen.
Abbildung 2.9: Häufig verwendete UML-Diagramme
34
2.5 Methoden der Softwaretechnologie
Abbildung 2.10: Elemente eines Use Case-Diagramms
2.5.1
Unified Modeling Language (UML)
Die Unified Modeling Language (UML) ist eine Standardnotation, die für die Entwicklung und Dokumentation von Softwaresystemen genutzt wird. Bei der Entwicklung eines Systems sind meist eine Vielzahl von Personen beteiligt, die verschiedene
fachliche Kompetenzen und soziale Hintergründe mit sich bringen. Um eine zielstrebige Projektplanung durchführen zu können, ist es umso wichtiger, eindeutige und
präzise Diagramm-Spezifikationen zur Verfügung zu stellen, um Ideen und Konzepte unmissverständlich austauschen zu können. UML kann dabei in allen Phasen der
Softwareentwicklung eingesetzt werden. Dies reicht vom Entwurf über die Implementierung bis hin zum Testen des Systems.
UML-Diagramme können in verschiedene Typen aufgeteilt werden. Abbildung 2.9
gibt eine Übersicht über die am häufigsten verwendeten Diagramme. Die Struktur
eines Systems wird mithilfe von Klassen- oder Use Case - Diagrammen beschrieben.
Ein Komponentendiagramm sagt insbesondere etwas über die Systemarchitektur
aus. Soll das Verhalten eines Systems beschrieben werden, wird dies durch Aktivitäts-, Zustands- oder Sequenzdiagramme konkretisiert. Bei letzterem liegt die Interaktion zwischen den Komponenten im Vordergrund. Die folgenden Erläuterungen
geben einen Überblick über die in dieser Arbeit verwendeten UML-Diagramme.
Use Case-Diagramm
Der Einsatz von Use Case-Diagrammen ist insbesondere dann hilfreich, wenn zu
Beginn eines Projektes die Funktionalitäten eines Systems festzulegen sind. Use
Case-Diagramme werden somit speziell während der Anforderungsanalyse eingesetzt
und stellen dabei das System aus Anwendersicht dar, ohne technische Umsetzungen
mit einzubringen. Sie dienen weiterhin als Leitfaden während des gesamten Entwicklungsprozesses, um sicherstellen zu können, dass stets alle funktionalen Anforderungen an das System erfüllt werden.
35
2 GRUNDLAGEN AUS DER INFORMATIK
Die Hauptkomponenten eines Use Case-Diagramms sind Akteure und Anwendungsfälle (siehe Abbildung 2.10). Ein Akteur ist eine mit dem System interagierende
Person oder technische Einheit, wie z.B. Drucker oder Betriebssystem. Er stellt eine
Rolle dar und steht in Beziehung mit einem oder mehreren Anwendungsfällen. Ein
Use Case (Anwendungsfall) beschreibt ein generalisiertes, abstrahiertes Verhalten, welches für einen Akteur von außen wahrnehmbar ist. Eine konkrete Realisierung ist hierbei irrelevant, es werden lediglich die Leistungsanforderungen an einen
bestimmten Arbeitsablauf festgehalten.
Wie bereits erwähnt, können Anwendungsfälle und Akteure in Beziehung zueinander stehen. Dabei sind vier Beziehungstypen gebräuchlich.
• Die Kommunikationsbeziehung gibt an, dass ein Informationsaustausch
zwischen Akteur und Use Case oder zwischen zwei Use Cases stattfindet.
• Die Vererbungsbeziehung ist mit einer Java-Vererbung zu vergleichen und
zeigt an, dass ein Use Case eine Spezialisierung eines anderen Use Cases ist.
Der Pfeil zeigt in Richtung des verallgemeinerten Use Cases.
• Die Erweiterungsbeziehung wird benutzt, wenn ein Use Case ein Sonderfall
oder eine Ausnahme eines anderen Use Cases darstellt. Der Use Case, in dessen
Richtung der Pfeil verläuft, wird nur unter gewissen Bedingungen ausgeführt,
wenn eine Erweiterung der Funktionalität erforderlich ist.
• Die Enthält-Beziehung macht es möglich, komplexe Use Cases in mehrere
Teile aufzuspalten. Sie besagt, dass der Use Case, zu dem der Pfeil hinführt,
im Arbeitsablauf des anderen Use Cases integriert ist und kann auch genutzt
werden, um einen Use Case in verschiedenen anderen Use Cases wiederzuverwenden.
Für eine unmissverständliche Definition eines Anwendungsfalles bietet sich eine textuelle Beschreibung an. Zu notieren sind dabei die in Tabelle 2.1 aufgeführten Eigenschaften eines Use Cases.
Klassendiagramme
Ein Klassendiagramm dient zur Beschreibung von im System eingesetzten Klassen
und deren Beziehungen untereinander. Sie werden auch während des Datenbankentwurfs eingesetzt. Abbildung 2.11 zeigt die möglichen Notationen. Eine Klasse wird
mindestens durch seinen Namen charakterisiert. Weiterhin ist es möglich, Attribute
mit Typ und Methoden mit Parametern und Rückgabewerten anzugeben.
Assoziationen in Form einer durchgezogenen Linie lassen sich als Beziehungen
zwischen Objekten, d.h. Instanzen einer Klasse, verstehen. Die Enden werden mit einer sogenannten Multiplizität versehen. Das dort angegebene Intervall beschränkt
die Anzahl der Objekte, die an dieser Beziehung teilhaben können. Ein Stern (*)
steht dabei für beliebig viele Objektverbindungen, d.h. eine beliebige natürliche
Zahl (∈ 1..n). Darüber hinaus kennt UML spezielle Assoziationen. Eine Aggregation ( ist-Teil-von“-Beziehung) betont den hierarchischen Aufbau der Elemente und
”
36
2.5 Methoden der Softwaretechnologie
Name: Der Namen des Use Cases, der von allen Projektteilnehmern eindeutig zugeordnet werden kann.
Kurzbeschreibung: Eine kurze Beschreibung, die die
Aufgabe des Use Cases erläutert.
Akteure: Aufzählung aller beteiligten Akteure, mit denen
der Use Case interagiert.
Ereignisfluss: Detaillierte Beschreibung von Interaktionen, welche in einzelne Schritte unterteilt wird.
Anfangsbedingungen: Bedingungen, die vor der
Ausführung des Use Cases gelten müssen.
Endbedingungen: Bedingungen, die nach dem unmittelbaren Ende eines Use Cases gelten.
Ausnahmen: Beschreibung von Interaktionen bei nicht
gewolltem Verhalten.
Spezielle Anforderungen: Nichtfunktionale Anforderungen und Nebenbedingungen, die nicht das vom Anwender zu beobachtende Verhalten betreffen, sondern Aufbau
und Implementierung des Systems einschränken können.
Tabelle 2.1: Textuelle Use Case-Beschreibung
wird grafisch mit einer Raute markiert. Sie ist vergleichbar mit der 1:n-Beziehung
und ordnet ein Teil einem oder mehreren Ganzen zu, von denen sie jedoch nicht
abhängig ist. Eine Komposition ( ist-ausschließlich-Teil-von“), dargestellt durch ei”
ne ausgefüllte Raute, drückt hingegen aus, das ein Objekt nur allein einem Ganzen
zugeordnet ist, ohne das es nicht bestehen kann.
Abbildung 2.11: Klassendiagramm
Im Beispiel aus Abbildung 2.11 erbt Klasse B alle Eigenschaften von Klasse A,
während Klasse C und D in Beziehung zueinander stehen. Weiterhin sind beliebig
viele Instanzen der Klasse A (ausschließlich) in Klasse C enthalten (Komposition).
37
2 GRUNDLAGEN AUS DER INFORMATIK
Aktivitätsdiagramm
Aktivitätsdiagramme dienen zur dynamischen Modellierung eines Systems. Sie stellen spezielle Zustandsdiagramme dar, deren Zustände Aktivitäten sind, und beschreiben den genaueren Ablauf eines Use Cases oder den Aufbau eines Programms.
Sie können somit sowohl für den konzeptuellen Entwurf als auch für die Implementierung eingesetzt werden.
Abbildung 2.12: Aktivitätsdiagramm
Aktivitäten, bzw. Aktionszustände, sind die Hauptkomponenten eines Aktivitätsdiagramms und definieren mithilfe von Transitionen, welche durch einen gerichteten
Pfeil dargestellt werden, einen sequentiellen Ablauf. Zur Verfeinerung der Struktur
bietet UML hier weitere Notationen (siehe Abbildung 2.12). Ein Initialknoten in
Form eines schwarzen Punktes kennzeichnet den Anfang des Steuerungsflusses. Wird
er von einem Kreis umrandet, handelt es sich um einen Aktivitätsendknoten und
deutet auf das Ende eines Pfades hin. Entscheidungsknoten leiten bedingungsabhängige Transitionen ein und werden durch Rauten repräsentiert. Die ausgehenden Transitionen werden mit Bedingungen in eckigen Klammern versehen, welche
über den weiteren Kontrollfluss entscheiden. Werden mehrere Transitionen zu einer
Transition zusammengeführt so wird dies durch einen ebenfalls durch eine Raute repräsentierten Vereinigungsknoten sichtbar. Parallelisierungs- bzw. Synchronisationsknoten werden durch ein schmales ausgefülltes Rechteck dargestellt. Sie
veranschaulichen einen parallelen Arbeitsablauf, wie er durch Threads umgesetzt
werden kann.
38
2.5 Methoden der Softwaretechnologie
Sequenzdiagramm
Sequenzdiagramme bieten die Möglichkeit, Interaktionen zwischen Objekten darzustellen, die an einem Use Case beteiligt sind. Der Nachrichtenaustausch sowie
die zeitliche Abfolge der Interaktionen steht hierbei im Vordergrund. Sequenzdiagramme sind insbesondere für die Beschreibung komplexer und unklarer Abläufe
gut geeignet. Abbildung 2.13 veranschaulicht die zugehörige Notation. Objekte werden spaltenweise dargestellt, wobei gestrichelte Linien, sogenannte Lebenslinien, ihre
Existenz symbolisieren. Auf der linken Seite steht stets der Akteur, der den Anwendungsfall initialisiert.
Abbildung 2.13: Sequenzdiagramm
Aktivitätsbalken auf den Lebenslinien stellen die Ausführung von Methoden dar.
Sie werden durch Nachrichten aktiviert, welche durch einen Pfeil repräsentiert werden. Pfeile synchroner Nachrichten tragen eine ausgefüllte Pfeilspitze, während sich
ansynchrone Nachrichten mit offener Pfeilspitze kennzeichnen lassen. Eine Iteration
wird dabei durch eckige Klammern mit vorangestelltem Sternchen markiert. Pfeile
mit gestrichelter Linie am Ende eines Aktivitätsbalkens stehen für die explizite Angabe einer Antwort zur Verfügung. Mit einer erzeugenden Nachricht, dessen Pfeil
zum Objektnamen führt, wird die Konstruktion eines Objektes gekennzeichnet. Eine
Objektdestruktion lässt sich durch ein Kreuz am Ende einer Lebenlinie vermerken.
39
2 GRUNDLAGEN AUS DER INFORMATIK
2.5.2
Design Patterns
Die Softwareentwickler haben im Laufe der Jahre festgestellt, dass sie stets auf wiederkehrende Probleme stoßen. Damit man leichter über sie diskutieren kann, war
es erforderlich, neue Begriffe einzuführen. Die Lösungen dieser Probleme wurden
gesammelt, getauft“ und dokumentiert . Die Beschreibung eines Entwurfsproblems
”
und die Erläuterung seiner Lösung definiert ein sogenanntes Design Pattern (dt.
Entwurfsmuster).
Es gibt drei Arten von Entwurfsmustern: erzeugende und strukturelle Muster sowie
Verhaltensmuster. Die erste Kategorie sind solche, die zum Erstellen und Instanzieren von Objekten dienen. Ein Vertreter dieser Kategorie ist das Factory Pattern.
Die strukturellen Muster sind für die Zusammensetzung von Objekten und Klassen
geeignet. Ein Beispiel dafür ist das Adapter Pattern. Die letzte Sorte befasst sich
mit der Zusammenarbeit von Klassen und Objekten. Ein Stellvertreter dieser Klasse
ist das Observer Pattern . In diesem Abschnitt werden die Design Patterns, die im
Rahmen dieser Arbeit verwendet wurden, vorgestellt.
Factory Method Pattern
Das Factory Method Pattern kann eingesetzt werden, wenn eine Klasse nicht über
den Typ einer zu instanziierenden Klasse entscheiden kann oder soll. Dies bewirkt
somit eine Verzögerung des Erzeugens neuer Objekte. Hierbei wird bei der betrachteten Klasse durch den Aufruf einer sogenannten Factory-Methode über den Zeitpunkt der Erzeugung von Objekten entschieden. Die Entscheidung über den Typ
der Objekte wird durch die Implementierung der Factory-Methode festgelegt. Eine
mögliche Umsetzung dieses Patterns kann folgendermaßen aussehen:
class Erzeuger
{
Objekt erzeuge(int typ)
{
if (typ==1) return Objekt1();
if (typ==2) return Objekt2();
....
}
}
Die Factory-Methode in der Erzeuger-Klasse soll anhand übergebener Informationen entscheiden, welche konkrete Klasse zu instanziieren ist.
Observer-Pattern
Viele Systeme bestehen aus mehreren Klassen, die voneinder abhängig sind. Dabei
besteht die Gefahr, dass die Komponenten des Systems ihre Konsistenz aus Mangel an Informationsaustausch verlieren. Das Observer-Pattern regelt die Beziehungen
40
2.5 Methoden der Softwaretechnologie
zwischen den zusammenhängenden Klassen, ohne dass sie eng miteinander gekoppelt werden müssen. Dieses Muster verfügt über zwei wichtige Komponenten: ein
Subject und ein Observer. Ein Subject wird von einem oder mehreren Observern
beobachtet. Die Observer bekommen Nachrichten vom Subject, wenn bei diesem
eine Zustandsänderung vorliegt. Der Informationsaustausch zwischen dem Subject
und dem Observer veranschaulicht der folgende Pseudo-Code:
benachrichtigen()
{
for all o in observers
{
o.update();
}
}
Die Methode benachrichtigen() des Subjects ruft für jeden Observer dessen zugehörige update()-Methode auf, die dann entscheiden kann, welche Änderungsmaßnahmen vorgenommen werden müssen.
Singleton-Pattern
Das Singleton-Pattern fällt unter die Klasse von Erzeugungsmustern. Bei einem
Singleton-Pattern wird beabsichtigt, dass eine Klasse genau einmal instanziert wird.
Es wird weiterhin dafür gesorgt, einen allgemeinen Zugriff auf diese Instanz zu
ermöglichen. Damit wird eine effiziente Zugriffskontrolle über die Singleton-Klasse
erzielt. Dieses Pattern verbessert des Konzept der statischen Variablen. Eine statische Variable bietet nicht nur die Möglichkeit des globalen Zugriffs, sondern auch
eine mehrfache Instanzierung, die nicht immer gewünscht wird. Sollte der Entwickler dennoch an mehreren Exemplaren der Singleton-Klasse interessiert sein, kann er
leicht und flexibel die Methode, die den Zugriff regelt, ändern. Der folgende Code
veranschaulicht eine Singleton-Methode:
public static Singleton getInstance()
{
if (instance == null)
instance = new Singleton();
return instance;
}
Modell-View-Controller
Das Model-View-Controller-Pattern (MVC) ist einer der erfolgreichsten und meist
verwendeten Design-Patterns. Hierbei geht es darum, die Repräsentation, die Datenquelle und ihre Interaktion zu trennen. Dieses Architekturmuster zeichnet sich
durch drei Komponenten aus: Ein Datenmodell (Model), eine bzw. mehrere Repräsentationen (View) und eine Steuerungseinheit (Controller).
41
2 GRUNDLAGEN AUS DER INFORMATIK
Ereignis
Controller
View
View
Modell
Abbildung 2.14: Modell-View-Controller-Architektur
Abbildung 2.14 veranschaulicht die einzelnen Komponenten einer MVC-Architektur
und ihre Interaktionen. Das Modell repräsentiert eine zentrale Datengrundlage zur
Kapselung der Daten und Funktionalitäten einer Applikation. Die Views sind für
die Bildschirmrepräsentation des Modells zuständig. Für ein und dasselbe Modell
können verschiedene Views existieren. Beim Eintreten bestimmter Ereignisse aktualisiert der Controller die Daten des Modells. Darüber hinaus kann der Controller
anwendungsspezifisch eine Änderung der Views bewirken. Sind einmal die Daten des
Modells verändert, werden diese Änderungen zu allen registrierten Views propagiert.
Folglich wird eine Aktualisierung der einzelnen betroffenen Views durchgeführt.
Durch den Einsatz des MVC-Patterns können gleichzeitig verschiedene Views ohne
Konsistenzprobleme verwendet werden. Das Hinzufügen neuer Views ist ferner ohne
Änderung des Modells möglich. Dies führt zur Stärkung der Erweiterbarkeit und
Wiederverwendbarkeit.
42
Kapitel 3
Grundlagen aus dem
Verkehrswesen
Die gesamte Arbeit baut auf der Thematik des Verkehrswesens auf. In besonderem Ausmaß betrifft dies die Überwachung von Regelverstößen im Straßenverkehr.
Daher soll dieses Kapitel ein Grundwissen aus dem Verkehrswesen vermitteln, welches für diese Arbeit von Bedeutung ist. Unterkapitel 3.1 erläutert zunächst einige
Begrifflichkeiten. Anschließend führt Unterkapitel 3.2 Verkehrsregeln aus der Straßenverkehrsordnung auf, die der Überprüfung von Ordnungswidrigkeiten zugrunde
liegen sollen.
3.1
Begriffsbestimmungen
Als Verkehrsteilnehmer wird derjenige bezeichnet, der öffentliche Wege benutzt
und damit am öffentlichen Verkehr teilnimmt, um eine Ortsveränderung vorzunehmen. Beispiele der wichtigsten Verkehrsteilnehmer sind Fußgänger, Fahrradfahrer
oder Fahrzeugführer. Im Sinne der Straßenverkehrsordnung sind Fahrzeuge zur
”
Fortbewegung auf dem Boden bestimmte und geeignete Geräte, nach OLG Düsseldorf
müssen diese auch zugelassen und betriebsbereit sein.“ [Xan08]
Unter einem Fahrstreifen versteht man den Teil einer Fahrbahn, den ein mehrspu”
riges Fahrzeug zum ungehinderten Fahren im Verlauf der Fahrbahn benötigt.[Bunb]
Die Fahrbahn besteht dabei aus einem oder mehreren Fahrstreifen und ist zum
Befahren durch Fahrzeuge vorgesehen. Damit bildet sie zusammen mit dem Sei”
tenstreifen und Randstreifen, der rechtlich gesehen nicht zur Fahrbahn gehört, den
zusammenhängenden, befestigten Teil der Straße.“[For00] Zeichnet sich die Straße
durch das Vorhandensein einer baulichen Trennung aus, so entstehen dadurch zwei
Richtungsfahrbahnen.
Eine Kreuzung ist die Schnittfläche zweier oder mehrerer öffentlicher Straßen,
welche sich jeweils auf der anderen Seite des Kreuzungsbereichs fortsetzen. Eine
Einmündung hingegen liegt vor, wenn eine oder mehrere Straßen in eine andere
einmünden, ohne dass für sie wie bei einer Kreuzung eine Fortsetzung existiert.
43
3 GRUNDLAGEN AUS DEM VERKEHRSWESEN
Unter einer Lichtsignalanlage (LSA) ist eine technische Einrichtung zu verstehen,
die bestehend aus einem oder mehreren Lichtsignalgebern und der dazu notwendigen Regelungstechnik zur Steuerung des Verkehrsflusses dient. Lichtsignalgeber,
allgemein als Ampeln bekannt, übermitteln durch das angezeigte Signalbild Informationen an die Verkehrsteilnehmer und schreiben somit gemäß der Straßenverkehrsordnung ein Verhalten vor. Gegeben wird ein solches Lichtsignal jeweils für eine
bestimmte Zeitdauer, die sogenannte Signalzeit. Die dies betreffenden Festlegungen für eine Lichtsignalanlage werden in einem Signalprogramm zusammengefasst.
Ein Signalprogramm lässt sich in mehrere Phasen unterteilen, die sich durch einen
unveränderten Signalisierungszustand auszeichnen.
Eine Ordnungswidrigkeit ist eine rechtswidrige und vorwerfbare Handlung, die
eine Geldbuße nach sich ziehen kann kann. Für den beteiligten Verkehrsteilnehmer
sind unterschiedliche Folgen möglich. Bei geringfügigen Ordnungswidrigkeiten ist
es vorgesehen, den Betroffenen zu verwarnen und gegebenfalls ein Verwarnungsgeld
zu verlangen. Je nach Schweregrad sind juristische Folgen möglich, wie ein Bußgeldbescheid, ein Eintrag im Verkehrszentralregister in Flensburg oder ein Fahrverbot. Wiederum andere ordnungswidrige Handlungen können Straftaten beinhalten,
wenn sie in Kombination mit anderen Tatbeständen begangen werden und besondere
Gefährdungen nach sich ziehen.
3.2
Straßenverkehrsordnung
Die Straßenverkehrsordnung (StVO) ist Teil des Straßenverkehrsrechts der Bundesrepublik Deutschland. Sie enthält insbesondere allgemeine Verkehrsregeln für die
Verkehrsteilnehmer sowie die Bedeutung der Zeichen und Verkehrseinrichtungen.
Für die Verkehrssicherheit und die Förderung des fließenden Verkehrs ist die Einhaltung der Regelungen von großer Bedeutung. Um die Verkehrsteilnehmer zur Beachtung der Straßenverkehrsordnung zu ermahnen, kann ein Verstoß gegen eine Verkehrsregel als Ordnungswidrigkeit geahndet werden. Ordnungswidrig im Sinne des
”
§ 24 des Straßenverkehrsgesetzes handelt, wer vorsätzlich oder fahrlässig“ gegen die
in § 49 der StVO aufgezählten Regeln verstößt [Bunb]. Allgemein gilt hier der Opportunitätsgrundsatz, d.h. von einer Ahndung kann abgesehen werden, wenn der
”
Verstoß völlig ungefährlich und von geringer Bedeutung war“[Buna]. In dieser Arbeit sind diejenigen Ordnungswidrigkeiten von Bedeutung, die den Kreuzungsbereich
betreffen. Im Folgenden werden daher die relevanten Verkehrsregeln und Zeichen beschrieben, die die Grundlage dieser Regelverstöße bilden. Ihre Erläuterungen sollen
dabei sogleich die Komplexität der Kriterien jedes einzelnen Gesetzes widerspiegeln.
44
3.2 Straßenverkehrsordnung
Grundregeln
Die allgemeinen Verkehrsregeln der StVO beginnen mit dem Gebot der Rücksichtsnahme, auf der alle weiteren Verkehrsregeln aufbauen:
§ 1 Grundregeln
(1) Die Teilnahme am Straßenverkehr erfordert ständige Vorsicht und
gegenseitige Rücksicht.
(2) Jeder Verkehrsteilnehmer hat sich so zu verhalten, daß kein Anderer
geschädigt, gefährdet oder mehr, als nach den Umständen unvermeidbar,
behindert oder belästigt wird.
Während Absatz 1 als die wesentliche Grundregel im Straßenverkehr gilt, kann ein
Verstoß gegen Absatz 2 als Ordnungswidrigkeit geahndet werden. Grundsätzlich gilt
zwar für die Förderung des fließenden Verkehrs der Vertrauensgrundsatz, was bedeutet dass Verkehrsteilnehmer auf das regelgerechte Verhalten anderer vertrauen
dürfen. Im Gegensatz dazu ist jedoch defensives Fahren für die Verkehrssicherheit
von enormer Bedeutung. Dies bedeutet, dass mit Fehlern anderer Verkehrsteilnehmer
gerechnet werden muss, insbesondere solche, die erfahrungsgemäß des Öfteren beobachtet werden. Dies spiegelt §1 der StVO wider, denn eine Beschädigung, Gefährdung
oder Behinderung anderer Verkehrsteilnehmer ist in jedem Fall zu vermeiden, auch
wenn dabei auf das eigene Recht verzichtet werden muss.
Rechtsfahrgebot
Paragraph 2 der StVO geht auf die Benutzung der Straßen durch Fahrzeuge ein:
§ 2 Straßenbenutzung durch Fahrzeuge
(1) Fahrzeuge müssen die Fahrbahn benutzen, von zwei Fahrbahnen die
rechte. Seitenstreifen sind nicht Bestandteil der Fahrbahn.
(2) Es ist möglichst weit rechts zu fahren, nicht nur bei Gegenverkehr,
beim Überholtwerden, an Kuppen, in Kurven oder bei Unübersichtlichkeit.
(...)
Absatz 2 beschreibt dabei das Rechtsfahrgebot, welches den Gegen- und Überholverkehr schützt, und gebietet, das möglichst weit rechts zu fahren ist. Möglichst
”
weit rechts“ ist dabei relativ anzusehen und abhängig von zahlreichen Parametern, wie z.B. Fahrbahnbreite, Hindernissen oder Geschwindigkeit. Eine weitere Einschränkung dieser Vorschriften kann durch Zeichen 295 als Fahrstreifenbegrenzung
erfolgen, welches anordnet, rechts der durchgezogenen Linie zu fahren, sofern sie
zur Abtrennung des Gegenverkehrs vorgesehen ist. Verstöße gegen diese Regeln zur
Straßenbenutzung sind ordnungswidrig. Eine Ausnahme des Rechtsfahrgebot sieht
die Existenz mehrerer Fahrstreifen in einer Fahrtrichtung vor. Innerorts dürfen beide
Fahrstreifen gleichermaßen befahren werden.
45
3 GRUNDLAGEN AUS DEM VERKEHRSWESEN
Vorfahrt
Paragraph 8 beschäftigt sich mit den Vorfahrtregeln an Kreuzungen und Einmündungen, was als Unterfall des Vorrangs zu betrachten ist.
§ 8 Vorfahrt
(1) An Kreuzungen und Einmündungen hat die Vorfahrt, wer von rechts
kommt. Das gilt nicht,
1. wenn die Vorfahrt durch Verkehrszeichen besonders geregelt ist (Zeichen 205, 206, 301, 306) oder
2. für Fahrzeuge, die aus einem Feld- oder Waldweg auf eine andere
Straße kommen.
(2) Wer die Vorfahrt zu beachten hat, muß rechtzeitig durch sein Fahrverhalten, insbesondere durch mäßige Geschwindigkeit, erkennen lassen,
daß er warten wird. Er darf nur weiterfahren, wenn er übersehen kann,
daß er den, der die Vorfahrt hat, weder gefährdet noch wesentlich behindert. (...)
oder Einmündung hineintasten, bis er die Übersicht hat. Auch wenn der,
der die Vorfahrt hat, in die andere Straße abbiegt, darf ihn der Wartepflichtige nicht wesentlich behindern.
(3) (aufgehoben)
Vorfahrt ist dabei das Recht eines Fahrzeugführers, vorrangig in eine Kreuzung oder
Einmündung einzufahren, wenn die Fahrlinien sich schneiden, berühren oder einan”
der hemmend nähern“. Der Vorfahrtberechtigte muss dabei zügig und unbehindert
”
durchfahren können, (...), wobei geringes Gaswegnehmen, Ausweichen und andere
unwesentliche Behinderungen als unvermeidbar außer Betracht bleiben.“ [Hen07]
Zeichen 205
Zeichen 206
Abbildung 3.1: Vorfahrt gewähren!
Die in §8 erwähnten Vorschriftzeichen 205 und 206 werden in §41 erläutert. Zeichen
205 (siehe Abbildung 3.1) verpflichtet das ankommende Fahrzeug, allen vorfahrtberechtigten sich nähernden Fahrzeugen die Vorfahrt zu gewähren. Zeichen 206 (Halt!
Vorfahrt gewähren!) beinhaltet dieselben Pflichten wie Zeichen 205. Hinzu kommt,
46
3.2 Straßenverkehrsordnung
dass ein Fahrzeug vor der Kreuzung anhalten muss, bevor es diese überquert. Dies
gilt auch dann, wenn sich kein vorfahrtberechtigtes Fahrzeug nähert. Die Rechtsvor-Links-Regel betrifft meist nur noch verkehrsarme Straßen, bei denen eine Vorfahrtregelung durch Verkehrszeichen für den fließenden Verkehr keine Notwendigkeit
hat.
Zeichen 301
Vorfahrt
Zeichen 306
Vorfahrtstraße
Zeichen 307
Ende der Vorfahrtstraße
Abbildung 3.2: Vorfahrt
Zeichen 301, 306 und 307 (siehe Abbildung 3.2) gehören zu den in §42 behandelten
Richtzeichen, die zur Erleichterung des Verkehrs auf bestehende Rechte hinweisen.
Zeichen 301 ( Vorfahrt“) weist dabei darauf hin, dass an der nächsten Kreuzung oder
”
Einmündung Vorrang gegenüber Fahrzeugen aus anderen Straßen besteht. Zeichen
306 ( Vorfahrtstraße“) besagt, dass es sich bei der Straße um eine Vorfahrtstrasse
”
handelt. Vorfahrt besteht an jeder Kreuzung oder Einmündung, sofern das Recht
nicht durch die Zeichen 205 Vorfahrt gewähren!“, 206 Halt! Vorfahrt gewähren!“
”
”
oder 307 Ende der Vorfahrtstraße“ aufgehoben wird.
”
Die Vorfahrt muss auch dann gewährt werden, wenn der Vorfahrtberechtigte sich
nicht gemäß den Vorschriften verhält. Das Vorfahrtsrecht besteht jedoch nicht, wenn
die Straße in einer nicht erlaubten Fahrtrichtung befahren wird.
Ein Verzicht auf die Vorfahrt ist möglich, wobei sich der Wartepflichtige jedoch
unmissverständlich mit dem Berechtigten zu verständigen hat. In bestimmten Situationen fordert auch das Gesetz einen Vorfahrtverzicht (§1, §11).
Eine Vorfahrtverletzung liegt dann vor, wenn sich die Fahrlinien nahe berühren,
”
so dass dem Berechtigten wenig Spielraum bleibt und er Kollision befürchtet (...)
Ordnungswidrig handelt, wer die Vorfahrt verletzt oder nicht rechtzeitig durch sein
Fahrverhalten anzeigt, dass er warten werde.“[Hen07] Die Warteplicht besteht jedoch lediglich gegenüber berechtigten Fahrzeugen, welche im Sichtfeld des Wartepflichtigen liegen. Daher sind zur Beurteilung der Rechtslage Sichtverhältnisse und
die Geschwindigkeit der Fahrzeuge mit heranzuziehen. Eine Gefährdung des Straßenverkehrs durch grob verkehrswidriges, rücksichtsloses Nichtbeachten der Vorfahrt
fällt nicht mehr in den Bereich der Verkehrsverstöße gegen die StVO und wird stattdessen strafrechtlich verfolgt.
47
3 GRUNDLAGEN AUS DEM VERKEHRSWESEN
Vorrang und Fahrtrichtungsanzeiger bei Abbiegevorgängen
In Paragraph 9 sind die Regeln zu den Abbiegevorgängen für diese Arbeit von Bedeutung:
§9 Abbiegen, Wenden und Rückwärtsfahren
(1) Wer abbiegen will, muß dies rechtzeitig und deutlich ankündigen; dabei sind die Fahrtrichtungsanzeiger zu benutzen. (...)
(2) (...)
(3) Wer abbiegen will, muß entgegenkommende Fahrzeuge durchfahren
lassen, (...)
(4) Wer nach links abbiegen will, muß entgegenkommende Fahrzeuge, die
ihrerseits nach rechts abbiegen wollen, durchfahren lassen. Führer von
Fahrzeugen, die einander entgegenkommen und jeweils nach links abbiegen wollen, müssen voreinander abbiegen, es sei denn, die Verkehrslage
oder die Gestaltung der Kreuzung erfordern, erst dann abzubiegen, wenn
die Fahrzeuge aneinander vorbeigefahren sind.
(5) (...)
Abbieger sind grundsätzlich dazu verpflichtet, entgegenkommenden Fahrzeugen Vorrang zu gewähren. Der Fahrtrichtungsanzeiger während des Abbiegevorgangs ist
insbesondere dann von großer Bedeutung, wenn er von einem vorfahrtberechtigten
Fahrzeug falsch gesetzt wird und andere wartepflichtige Verkehrsteilnehmer darauf
vertrauen (Vertrauensgrundsatz). Kommt es in dieser Situation zum Unfall, trifft
”
den Vorfahrtsberechtigten das Hauptverschulden.“ [KR08]
Stockender Verkehr
Besondere Verkehrslagen, die ein von den Verkehrsregeln abweichendes Verhalten
verlangen, werden in §11 geregelt. Dies betrifft insbesondere den stockenden Verkehr:
§11 Besondere Verkehrslagen
(1) Stockt der Verkehr, so darf trotz Vorfahrt oder grünem Lichtzeichen
niemand in die Kreuzung oder Einmündung einfahren, wenn er auf ihr
warten müßte.
(2) (...)
(3) Auch wer sonst nach den Verkehrsregeln weiterfahren darf oder anderweitig Vorrang hat, muß darauf verzichten, wenn die Verkehrslage es
erfordert; auf einen Verzicht darf der andere nur vertrauen, wenn er sich
mit dem Verzichtenden verständigt hat.
Stockender Verkehr liegt genau dann vor, wenn die Kreuzung oder Einmündung
in beabsichtigter Fahrtrichtung durch wartende Fahrzeuge blockiert ist, sodass ein
zügiges Überqueren nicht sichergestellt werden kann. In dieser Situation fordert also
die StVO einen Verzicht auf das Vorfahrtsrecht, da ein Fahrzeug im Kreuzungsbereich nicht warten darf. Eine zusätzliche Behinderung anderer ist keine Voraussetzung für den Tatbestand.
48
3.2 Straßenverkehrsordnung
Lichtzeichen und Grünpfeil
Der zweite Abschnitt der Straßenverkehrsordnung beschäftigt sich mit den in der
Bundesrepublik Deutschland zur Verfügung stehenden Zeichen und Verkehrseinrichtungen. Für Kreuzungen und Einmündungen ist dabei zunächst §37 der Straßenverkehrsordnung relevant, welcher auf die Beachtung von Lichtsignalgebern eingeht.
§37 Wechsellichtzeichen, Dauerlichtzeichen und Grünpfeil
(1) Lichtzeichen gehen Vorrangregeln, vorrangregelnden Verkehrsschildern und Fahrbahnmarkierungen vor.
Die drei Farben der Wechsellichtzeichen tragen an Kreuzungen dabei die folgenden
Bedeutungen:
(2) (...)
Grün: Der Verkehr ist freigegeben“. (...)
”
Grüner Pfeil: Nur in Richtung des Pfeiles ist der Verkehr freigegeben“.
”
(...)
Gelb ordnet an: Vor der Kreuzung auf das nächste Zeichen warten“.
”
(...)
Rot ordnet an: Halt vor der Kreuzung“. (...)
”
Ein neben dem Lichtzeichen angebrachtes Schild mit grünem Pfeil auf schwarzem
Grund, der sogenannte Grünpfeil, erlaubt zudem das Abbiegen nach rechts bei Rot,
sofern es die Verkehrslage ohne Behinderung und Gefährdung erlaubt. Ein Anhalten
vor der Kreuzung ist dennoch verpflichtend.
Als Ordnungswidrigkeit ist der Rotlichtverstoß einer der gefährlichsten Verstöße.
Der Schweregrad hängt dabei davon ab, in welcher Entfernung sich das Fahrzeug
befand, während das Signal zu Rot wechselte und mit welcher Geschwindigkeit es
sich näherte.
Zeichen 209
Rechts
Zeichen 214
Geradeaus und rechts
Abbildung 3.3: Vorgeschriebene Fahrtrichtung
Vorgeschriebene Fahrtrichtung
Paragraph 41 behandelt neben den bereits erwähnten Vorfahrtzeichen weitere
Vorschriftzeichen, deren Missachtung als Ordnungswidrigkeit geahndet werden können. Zeichen 209 und 214 (siehe Abbildung 3.3) zeigen an, dass nicht alle
49
3 GRUNDLAGEN AUS DEM VERKEHRSWESEN
Fahrtrichtungen erlaubt sind. Die Pfeilrichtungen weisen auf die Fahrtrichtungen
hin, in die abgebogen werden darf. Andere Fahrtrichtungen können dem Verkehr
durch analoge Verkehrszeichen vorgeschrieben werden.
Zeichen 297 (siehe Abbildung 3.4) zeichnet sich durch einen weißen Richtungspfeil
auf dem Fahrstreifen einer Fahrbahn aus. Sind die Fahrstreifen durch Leitlinien
(gestrichelte Linie) oder Fahrstreifenbegrenzungen (durchgezogene Linie) getrennt,
darf ein Fahrzeug nur in die Richtung abbiegen, die durch den Pfeil auf seinem ausgewählten Fahrstreifen vorgeschrieben ist. Ein Pfeil zieht demnach dieselben Pflichten mit sich wie die Schilder der vorgeschriebenen Fahrtrichtung.
Abbildung 3.4: Zeichen 297 - Richtungspfeil
Abschließend soll darauf hingewiesen werden, dass die Gültigkeit von Verkehrsregeln
von den vorhandenen Zeichen und Verkehrseinrichtungen abhängig ist. Dies betrifft
insbesondere die Vorfahrt- und Vorrangregeln. Um die Beziehungen der einzelnen
Regeln untereinander zu verdeutlichen, gibt die folgende Tabelle eine Übersicht über
die Gültigkeit dieser Regeln.
1
§36
2
§37
3 §41,Abs. 2 b)
4
§8, Abs. 1
Zeichen von Polizeibeamten
Lichtzeichenanlage
Vorfahrt gewähren!, Halt! Vorfahrt gewähren
Rechts-vor-Links
Tabelle 3.1: Regeln zur Einfahrt in die Kreuzung
50
Kapitel 4
Grundlagen der Simulation
Die Simulation ist mittlerweile in verschiedenen Disziplinen ein bedeutendes Mittel
zur Beschreibung des Verhaltens verschiedener Objekte und Sachverhalte, um diese
besser verstehen zu können. Dies wird erreicht durch die Beobachtung des Verhaltens in Bezug auf vorgenommene Änderungen. Nachfolgend soll in Unterkapitel 4.1
auf die einer Simulation zugrunde liegenden Simulationsmodelle eingegangen werden. Unterkapitel 4.2 gibt einen Überblick über die diskrete Ereignissimulation. Die
Multiagentensimulation als Verfeinerung der diskreten Ereignissimulation wird in
Unterkapitel 4.3 eingeführt. Unterkapitel 4.4 geht auf Verkehrssimulationsmodelle
ein.
4.1
Simulationsmodelle
Die Simulation ist ein Werkzeug, um das Experimentieren an bestimmten Ausschnitten der Realität zu umgehen. Diese Ausschnitte, die sich aus einer Menge von Objekten und die unter diesen Objekten bestehenden Beziehungen zusammensetzen, werden als System bezeichnet. Das zu einem gegebenen Zeitpunkt vorhandene System
nennt man den Zustand des Systems. Um die Komplexität des betrachteten Systems
zu bewältigen, wird zur Vereinfachung der Realität ein Modell als Repräsentation
des Systems gebildet (siehe Abbildung 4.1).
Modelle können in physikalische und mathematische Modelle unterteilt werden. Ein
Beispiel für ein physikalisches Modell ist eine Modelleisenbahn. Solche Modelle sind
jedoch für eine wissenschaftliche Analyse eines Systems meistens nicht von Interesse. Bei einem mathematischen Modell wird hingegen das System durch eine Menge
logischer und mathematischer Beziehungen beschrieben. Sobald man das mathematische Modell aufgebaut hat, wird untersucht, inwiefern dies das Verhalten des
Systems erfüllt und gegebenfalls ergänzt.
Schließlich gibt es zwei Möglichkeiten, das System zu untersuchen. Wenn es sich
um ein einfaches Modell handelt, ist es möglich, mittels seiner Beziehungen und
Größen eine exakte Beschreibung zu schaffen. Diese Analyse mithilfe auflösbarer
Formeln wird analytische Lösung genannt. Ist das System allerdings komplex, wie
es bei den realen Systemen oft der Fall ist, ist sein Modell auch komplex. Dies schließt
51
4 GRUNDLAGEN DER SIMULATION
System
Mit dem System selbst
experimentieren
Mit Systemmodell
experimentieren
Physikalisches Modell
Mathematisches Modell
Analytische Lösung
Simulation
Abbildung 4.1: Methoden zur Untersuchung eines Systems (nach [LK00])
jede analytische Lösung aus. In diesem Fall muss das Modell mithilfe einer Simulation untersucht werden. In diesem Sinne lässt sich eine Simulation als Nachahmung
”
realer Prozesse mittels Computern auf der Grundlage mathematischer Modelle“ definieren [KN98].
Simulationsmodelle sind spezielle Modelle, die zu Simulationszwecken konstruiert
werden, und lassen sich auf verschiedene Weise klassifizieren. Sie können statisch
oder dynamisch, stochastisch oder deterministisch, kontinuierlich oder diskret sein.
Statische vs. dynamische Simulationsmodelle
Ein Simulationsmodell wird als statisch bezeichnet, wenn es für ein System als Momentaufnahme gilt, d.h. keine Zustandsänderung im Zeitablauf vorliegt. Auch wenn
die Zeit für das System nicht relevant ist, spricht man von einem statischen Modell.
Ein System, das sich mit der Zeit verändern kann, wird dynamisch genannt. Bei der
Abstraktion dieser Zustandsänderung durch ein Simulationsmodell spricht man von
einem dynamischen Simulationsmodell.
Deterministische vs. stochastische Simulationsmodelle
Deterministische Simulationsmodelle sind Modelle, die keine probabilistischen bzw.
stochastischen Größen enthalten. Ein Differentialgleichungssystem für die Beschreibung einer chemischen Reaktion kann z.B. als solches Modell gelten. Die Ausgabe
ist bei diesem Modell festgelegt, sobald die Eingaben und ihre Abhängigkeiten feststehen. Im Gegensatz dazu geben stochastische Simulationsmodelle randomisierte
Ergebnisse aus.
52
4.2 Diskrete Ereignissimulation
Kontinuierliche vs. diskrete Simulationsmodelle
Kontinuierliche Systeme sind Systeme, deren Zustände sich kontinuierlich mit der
Zeit ändern. Im Gegensatz dazu ändern sich die Zustände der diskreten Systeme
punktweise in der Zeit. Analog werden kontinuierliche bzw. diskrete Simulationsmodelle definiert. Die Entscheidung für das eine oder andere Modell ist unabhängig von
der Natur des Systems. Das hängt alleine vom Ziel des Modells ab. Wird z.B. die
Bewegung von Fahrzeugen modelliert, dann ist es entscheidend zu wissen, ob die Bewegung einzelner Fahrzeuge oder die gesamte Bewegung für das Modell wichtig ist.
Dies kann die Entscheidung beeinflussen, ob diskret oder kontinuierlich gearbeitet
wird.
4.2
Diskrete Ereignissimulation
Die diskrete Ereignissimulation beschäftigt sich mit der Modellierung dynamischer
Systeme, die ihre Zustände im Laufe der Zeit ändern. Die Zeitpunkte der Systemänderung entsprechen den Zeitpunkten, in denen die Ereignisse ausgelöst werden. Ein Ereignis ist daher ein zeitliches Vorkommnis, das den Zustand des Systems
zur Veränderung bringen kann. Zwischen zwei Ereignissen bleibt der Systemzustand
unverändert.
Kontrolle des Zeitverlaufs
Wegen der dynamischen Natur der betrachteten Systeme bei der diskreten Ereignissimulation ist es notwendig, einen Mechanismus für die Zustandsaufnahmen während
der Simulation zu haben. Eine Variable, die die aktuelle Zeit ausdrückt, wird als Simulationsuhr (Clock) bezeichnet. Die Zeiteinheit bei den Simulationen muss nicht
unbedingt festgelegt werden. Es gibt zwei Ansätze für das Inkrementieren der Simulationsuhr: next-event time advance und fixed-increment time advance. Bei dem
ersten Ansatz wird die Uhr erst inkrementiert, sobald ein Ereignis ausgelöst wird.
Dies hat zur Folge, dass die Abstände zwischen dem Vorkommen von Ereignissen
nicht unbedingt gleich sind. Bei dem zweiten Ansatz wird die Uhr in regelmäßigen
Abständen inkrementiert, unabhängig davon, ob ein Ereignis eingetreten ist oder
nicht.
Funktionsweise eines diskreten Ereignissimulationsmodells
Alle diskreten Ereignissimulationsmodelle verfügen über eine Menge gemeinsamer
Komponenten. Trotzdem weichen die einzelnen Modelle minimal voneinander ab,
u.a. abhängig davon, wie sie die Simulationsuhr implementiert haben. Im Folgenden
wird ein typischer Verlauf einer diskreten Ereignissimulation und seiner beteiligten
Komponenten vorgestellt (siehe Abbildung 4.2).
Die gesamte Kontrolle über den Simulationsprozess übernimmt das Hauptprogramm.
Zu Beginn ist es Aufgabe einer Intitialisierungsprozedur, das Modell zum Zeitpunkt
0 zu initialisieren. Dabei wird eine Variable für die Ausgabe der aktuellen Simula-
53
4 GRUNDLAGEN DER SIMULATION
Start
Initialisierungsprozedur
Initialisieren der Ereignisliste
Zeit = 0
Hauptprogramm
Timing-Prozedur
Initialisierungsprozedur aufrufen
Timing- und Ereignis-Prozedur
wiederholen
Ereignisprozedur
Nächstes Ereignis
Bibliotheksfunktionen
Systemzustand aktualisieren
und zukünftige Ereignisse
generieren
Abbruch
der
Simulation?
Zufallszahlen erzeugen
Nein
Ja
Berichtsgenerator
Statistiken und Ergebnisbericht
Stopp
Abbildung 4.2: Funktionsweise eines Ereignissimulators (nach [LK00])
tionszeit, die Simulationsuhr, auf 0 gesetzt. Außerdem benötigt der Simulationsvorgang eine Ereignisliste, die die abzuarbeitenden Ereignisse mit Zeitstempel enthält.
Mindestens ein Ereignis muss von der Intitialisierungsprozedur als initialisierendes
Ereignis generiert werden. Des Weiteren ist der Systemzustand zu definieren. Er umfasst die Gesamtheit aller Zustandsvariablen, die für die Beschreibung des Systems
im Laufe der Zeit notwendig sind.
Für den weiteren Verlauf der Simulation sind zwei Teilprogramme notwendig, welche vom Hauptprogramm wiederholt aufgerufen werden. Zunächst holt eine TimingProzedur das nächste Ereignis aus der Ereignisliste und inkrementiert im Fall vom
next-event time advance die Simulationsuhr. Anschließend dient eine Ereignisprozedur zur Aktualisierung des Systemzustands als Reaktion auf eingetretene Ereignisse.
Zusätzlich generiert sie neue Ereignisse unter Zuhilfenahme von Bibliotheksfunktionen, die die im Modell spezifizierten randomisierten Größen erstellen. Iteriert wird
durch das Hauptprogramm über diese zwei Teilprogramme, solange die Simulation
noch nicht beendet wurde. Abschließend ist am Ende der Simulation ein Berichtsgenerator für die Berechnung geschätzter Performanzgrößen und Erstellung von Berichten zuständig.
54
4.2 Diskrete Ereignissimulation
Zellulare Automaten
Eine räumliche Diskretisierung kann mithilfe der Theorie zellularer Automaten umgesetzt werden. Zellulare Automaten wurden von John von Neumann im Rahmen
seiner Forschung über die Selbstproduktion erfunden [BSL98]. Seitdem finden sie in
verschiedenen Disziplinen für die Simulation von raumzeitlichen Systemen Anwendung. Sie zeichnen sich durch eine Diskretisierung des Raumes aus und dienen somit
der Modellierung diskretisierter dynamischer Systeme. Formal wird ein zellularer
Automat als 4-Tupel (G, N, Z, f ) definiert. G ist ein unendliches m-dimensionales
Gitter, das regelmäßig in Zellen unterteilt wird.
N ⊆ Gn bildet eine Menge von Nachbarn einer Zelle, welche auf unterschiedliche
Weise definiert werden kann. Abbildung 4.3 zeigt zwei mögliche Nachbarschaften.
Die erste Variante ist die sogenannte Von-Neumann-Nachbarschaft. Hierbei zählen
(x,y-1)
(x-1,y)
(x,y)
(x+1,y)
(x-1,y-1)
(x,y-1)
(x+1,y-1)
(x-1,y)
(x,y)
(x+1,y)
(x,y+1)
(x-1,y+1) (x,y+1) (x+1,y+1)
(a) Von-Neumann-Nachbarschaft
(b) Moore-Nachbarschaft
Abbildung 4.3: Nachbarschaft für 2-dimensionale zellulare Automaten
solche Zellen im Gitter als Nachbarn, welche eine gemeinsame Kante mit der betrachteten Zelle haben. Im Sinne dieser Nachbarschaft gelten die Zellen mit den
Koordinaten (x - 1,y), (x,y - 1), (x,y + 1), (x + 1,y) als Nachbarn der Zelle mit
Koordinate (x,y).
Eine andere Definition stellt die sogenannte Moore-Nachbarschaft dar. Zur Menge
der Nachbarn einer Zelle gemäß dieser Nachbarschaftsdefinition gehören alle Zellen,
die sich mindestens eine gemeinsame Ecke mit dieser Zelle teilen. Dementsprechend
ist die Menge der Nachbarn im Sinne der Von-Neumann-Nachbarschaft eine Teilmenge der Nachbarn im Sinne der Moore-Nachbarschaft. Es kommen für eine Zelle
(x,y) noch die Zellen mit Koordinaten (x - 1,y - 1), (x - 1,y + 1), (x + 1,y - 1), (x
+ 1,y + 1) als Nachbarn hinzu.
55
4 GRUNDLAGEN DER SIMULATION
Ein weiterer Bestandteil eines zellularen Automaten stellt die Zustandsmenge Z
dar. Dies ist eine endliche Menge von Zuständen, die eine Zelle annehmen kann. Zu
einem gegebenen Zeitpunkt t befindet sich eine Zelle genau in einem Zustand z ∈ Z.
Schließlich ist f eine Zustandsübergangsfunktion f : Z n → Z. Der Zustand zum
Zeitpunkt t hängt von den Zuständen der Nachbarzellen zum Zeitpunkt t-1 ab.
4.3
Multiagentensimulation
Die zu simulierenden Systeme sind meistens sehr komplex. Innerhalb solcher Systeme agieren unterschiedliche und viele Bestandteile sowohl miteinander als auch mit
ihrer Umgebung. Dieses Aktions- und Reaktionsverhalten kann nur schwierig bzw.
unmöglich mithilfe klassischer Simulationsmodelle nachgebildet werden. In der Praxis hat sich ein neues Konzept etabliert, welches als eine Verfeinerung der diskreten
Ereignissimulation angesehen wird: die Multiagentensimulation.
Die Multiagentensimulation stellt eine neue Form zur Untersuchung von Systemen
dar. Sie eignet sich insbesondere für komplexe Systeme und ermöglicht das Experimentieren an Multiagentenmodellen, welche die sogenannten Multiagentensysteme
beschreiben. Nachfolgend wird auf Multiagentensysteme mit ihren Komponenten
und insbesondere auf Agenten als wesentlicher Teil dieser Systeme eingegangen.
Multiagentensysteme
Multiagentensysteme sind solche Systeme, die aus mehreren eigenständig handelnden Einheiten, sogenannten Agenten, bestehen. Der Agentenbegriff wird im nächsten
Abschnitt detailliert eingeführt. Multiagentensysteme zeichnen sich durch eine Menge von Eigenschaften aus. Innerhalb eines Multiagentensystems werden die Daten
lokal auf Agentenebene verarbeitet. Die einzelnen Agenten verfügen nur über ein
begrenztes Wissen über das Gesamtsystem. Demzufolge gibt es im Idealfall keine
zentrale Stelle, die das System kontrollieren muss. Ferner liegt den Multiagentensystemen die Nebenläufigkeit zugrunde, die Agenten führen ihre Berechnungen aus
und bereiten ihre Aktionen parallel vor.
Agentenbegriff
Ein wichtiger Begriff bei der Multiagentensimulation ist der Agent. Eine genaue Definition eines Agenten ist umstritten, es gibt jedoch eine Definition von Wooldridge,
die allgemeine Anerkennung gefunden hat: An agent is an encapsulated compu”
ter system that is situated in some environment, and that is capable of flexible,
autonomous action in that environment in order to meet its design objectives“ [Jen99].
Aus dieser Definition lassen sich folgende Eigenschaften eines Agenten ableiten.
Ein Agent muss zum einen in eine Umgebung eingebettet sein. Die Umgebung eines
Agenten besteht aus den anderen Agenten und den Objekten, die auf ihn Einfluss
nehmen können. Agenten zeichnen sich weiterhin durch ein reaktives Verhalten aus.
56
4.3 Multiagentensimulation
Sie können ihre Umgebung wahrnehmen und sind dazu fähig, sie zu verändern,
indem sie ihr Verhalten modifizieren. Zusätzlich besitzt ein Agent die Autonomieeigenschaft, d.h. er kontrolliert eigenständig seinen Zustand und sein Verhalten und
kann selbst Entscheidungen treffen. Der aktuelle Zustand des Agenten ist lediglich
von seinem vorherigen Zustand sowie seiner Umgebung abhängig.
Um seine Ziele und Motivationen zu realisieren, kann der Agent entweder ein kooperatives oder ein eigensinniges Verhalten zeigen. Das kooperative Verhalten kann auf
unvollständiges Wissen, das der Agent besitzt, zurückgeführt werden. Das bedeutet,
dass die Agenten aus Mangel an Wissen zu einer Zusammenarbeit mit den anderen
Agenten gezwungen sind. Auf der anderen Seite können die Agenten versuchen, ihre
Ziele zu erreichen, indem sie eigensinnig und zielorientiert handeln.
Allgemein wird zwischen vier Arten von Agenten unterschieden. Die einfachen
reflexbasierten Agenten verfügen über eine Wissensbasis, die aus Situationen,
Aktionen und Regeln besteht. Die von Sensoren gelieferten Daten werden analysiert,
einer Situation zugeordnet, mithilfe der Regeln zu einer Aktion übersetzt und mit
den Effektoren ausgeführt. Die Entscheidung wird nur abhängig von der aktuellen
Wahrnehmung getroffen (siehe Abbildung 4.4).
Agent
Wahrnehmung
Sensoren
Umgebung
Effektoren
Handlung
Abbildung 4.4: Agent und seine Umgebung
Reflexagenten mit internem Zustand hingegen besitzen zusätzlich ein internes
Gedächtnis, in dem sie Informationen über die Umwelt speichern und beim Interpretieren darauf Zugriff nehmen können. Zwei Arten von Wissen sind dafür relevant:
zum einem, wie die Welt momentan aussieht, zum anderen, welche Folgen die vom
Agenten ausgeführten Aktionen haben.
Weiterhin sind zielbasierte Agenten zusätzlich mit Wissen über ihre Ziele ausgestattet. Dies ermöglicht ihnen, nach Vergleich mit den Konsequenzen ihrer Aktionen
eine Reihe von Aktionen auszuführen, die zur gewünschten Situation führen.
Zuletzt sind nützlichkeitsbasierte Agenten in der Lage verschiedene Wege, die
zur Zielsituation führen, zu vergleichen. Dies hat zur Folge, dass sie sich für den
57
4 GRUNDLAGEN DER SIMULATION
!
Abbildung 4.5: Reflexagent mit internem Zustand
besten Weg oder die nützlichste Situation entscheiden können, um ihr Ziel zu erreichen. Im Folgenden wird auf das Verhalten eines Agenten mit seiner Umgebung am
Beispiel eines Reflexagenten mit internem Zustand näher eingegangen, der in dieser
Arbeit von Bedeutung ist.
Reflexagent mit internem Zustand
Wie erwähnt, besitzt ein Reflexagent mit internem Zustand einen internen Speicher, der eine Menge von Zuständen beinhaltet. Der Agent aktualisiert seinen Zustand kontinuierlich, indem er seine Wahrnehmungen mithilfe von Zuständen und
Regeln zu Aktionen transformiert (siehe Abbildung 4.5). Sein Wissen besteht in den
Informationen, wie sich die Umwelt entwickeln kann und welchen Einfluss die Aktionen des Agenten auf die Umwelt haben. Dieser Ablauf kann durch den folgenden
Algorithmus beschrieben werden [PTV]:
1. zustand ← UPDATE-ZUSTAND[zustand,wahrnehmung]
2. regel ← REGEL-AUSWAHL[zustand,regelmenge]
3. aktion ← REGEL-AKTION[regel]
4. zustand ← UPDATE-ZUSTAND[zustand,aktion]
Der Algorithmus zeichnet sich durch vier Phasen aus, welche die Aktualisierung des
Agenten bewirken. Die erste Phase ist eine Wahrnehmungsphase. Dabei werden die
Werte der Zustandsvariablen gesetzt, die den internen Zustand des Agenten bilden.
Mit diesen Werten lässt sich eine Interpretation aus Wahrnehmungen ableiten. In
der zweiten Phase wird eine passende Regel aus einer vordefinierten Regelmenge
ausgesucht und in der dritten Phase ausgeführt. In der letzten Phase wird der interne
Zustand nach der Umsetzung der in Phase 3 ausgewählten Aktion aktualisiert.
58
4.4 Verkehrssimulationsmodelle
4.4
Verkehrssimulationsmodelle
Im Bereich des Verkehrs wird Simulation intensiv eingesetzt. Die sogenannte Verkehrssimulation kann unterschiedliche Absichten haben. Sie wird beispielsweise zum
Austesten verschiedener Szenarien zur Optimierung des Verkehrsablaufs sowie für
die Vermeidung von Unfällen oder Staus genutzt. Dank Verkehrssimulationen können
die Optimierungsversuche vorher am Modell erprobt werden, bevor sie in der Realität Einsatz finden. Die Folgen von Änderungen der Beschilderungen oder Lichtsignalanlagen sowie Routenumleitungen lassen sich leicht am Modell beobachten.
Wie allen Simulationen liegen Verkehrssimulationen Simulationsmodelle zugrunde.
Abhängig vom Detaillierungsgrad können Verkehrsmodelle in drei Klassen unterteilt
werden: Makro-, Meso- und Mikroskopische Verkehrsmodelle.
Abbildung 4.6: Unterteilung von Verkehrsmodellen nach Detaillierungsgrad
[PTV]
Makroskopische Verkehrsmodelle
Bei den makroskopischen Modellen wird statt einer Einheit der Verkehrsstrom als
Zusammenfassung einer Menge von Fahrzeugen modelliert. Hierbei verzichtet man
auf Details, wie z.B. das Verhalten einzelner Fahrzeuge. Makroskopische Modelle
bilden nur durchschnittliche Werte der Belastungsgrößen, wie Geschwindigkeit oder
Dichte, ohne Betrachtung des Zeitparameters.
Für die Modellierung großer Räume sind solche Modelle sehr gut geeignet, da große
Gebiete, Städte sowie ganze Länder wegen dem Rechenaufwand und der großen
Datenmenge nur schwer detailliert simuliert werden können. Ein Einsatzgebiet makroskopischer Verkehrsmodelle besteht in der Erstellung von Verkehrsprognosen zur
Vorerkennung und Vermeidung kritischer Verkehrsphänomene. Durch eine grobe
räumliche sowie zeitliche Auflösung reduziert sich der Rechenaufwand und bleibt
unabhängig von der Anzahl der simulierten Fahrzeuge. Interessiert man sich jedoch
59
4 GRUNDLAGEN DER SIMULATION
für eine genaue Beschreibung spezieller Phänomene der Verkehrsabläufe, ist eine
makroskopische Betrachtungsweise nicht ausreichend.
Mikroskopische Verkehrsmodelle
Ein mikroskopisches Verkehrsmodell liefert eine genauere und detailliertere Beschreibung des Verkehrsablaufs als ein makroskopisches Verkehrsmodell. Dieses Modell ist
ein realitätsnahes Modell mit einer genaueren Nachbildung der Topologie des betrachteten Simulationsraums, insbesondere auf Kreuzungsebene. Im Gegensatz zum
makroskopischen Modell wird nicht nur der Verkehrsfluss durch Durchschnittswerte, sondern auch das individuelle Verhalten einzelner Fahrer modelliert. Darunter
fallen beispielsweise fahrzeugspezifische Geschwindigkeiten und die Interaktion der
modellierten Verkehrsteilnehmer mit ihrer Umwelt. Hierbei werden auch Beschilderungen sowie die Steuerung der Lichtsignalanlagen betrachtet. Aufgrund des hohen
Detaillierungsgrades basieren viele Verkehrssimulationen auf dem mikroskopischen
Modell. Der realitätsgetreue Aspekt ist nicht ohne Kosten zu genießen, da dies zur
Komplexität des Modells beiträgt.
Mesoskopische Verkehrsmodelle
Mesoskopische Verkehrsmodelle stellen ein hybrides Modell dar. Sie sind eine Kombination zwischen den makro- und mikroskopischen Modellen. Hierbei werden zwar
einzelne Fahrzeuge modelliert, aber ihre Fortbewegung orientiert sich dennoch an
durchschnittlichen Werten. Dieser Ansatz ermöglicht die Betrachtung größerer Simulationsgebiete und ist damit z.B. gut für Verkehrsleitsysteme geeignet.
Binäres und Nagel-Schreckenberg-Verkehrsmodell
Um die Komplexität der mikroskopischen Verkehrssimulation zu bewältigen, wird
stets versucht, die Regeln zur Beschreibung der Bewegung zu reduzieren, ohne jedoch
die wesentlichen Aspekte der Bewegung zu ignorieren. Dies wurde bereits 1986 von
Ludwig Cremer [Kem06] mithilfe eines Verkehrsmodells vorgestellt. Hierbei wurden
die Fahrzeuge als Bits abgebildet. Dieser Ansatz konnte allerdings den stochastischen Aspekt des Verkehrsablaufs nicht betrachten. Dank der zellularen Automaten
(siehe Abschnitt 4.2) konnten Nagel und Schreckenberg 1992 [Kem06] ein neues Modell entwerfen, das möglichst viele Aspekte des Verkehrsflusses berücksichtigte.
Dieses Modell ist in der Lage, den Bremsvorgang sowie die Geschwindigkeitskontrolle einzelner Fahrzeuge zu simulieren. Es wurde ursprünglich für einspurige Straßen
entworfen, ist allerdings später für mehrspurige Verkehrsszenarien weiterentwickelt
worden. Dieses Modell ermöglicht eine Echtzeitsimulation selbst für große Simulationsräume. Die Zustandsmenge Z beim Nagel-Schreckenberg-Ansatz ist von der
maximalen Geschwindigkeit abhängig (Z = {−1, 0, 1, ....., vmax }). Die Fahrzeuge
können mit einer Geschwindigkeit von 0 bis vmax fahren. Nicht besetzte Zellen befinden sich im Zustand −1.
60
4.4 Verkehrssimulationsmodelle
Der Nagel-Schreckenberg-Algorithmus [Mil] betrachtet hinsichtlich der Geschwindigkeit vier Arten von Regeln: Beschleunigen, Abbremsen, Trödeln und Fahren.
• Beschleunigen: ist v < vmax , dann setze v := v + 1.
• Abbremsen: ist der Abstand w in Zellen zum Vordermann zu klein, dann setze
v = max{0, v − 1}.
• Trödeln: mit einer Wahrscheinlichkeit p setze v = max{0, v − 1}.
• Fahren: jedes Fahrzeug wird um v Zellen in die Fahrtrichtung bewegt.
Eine Vereinfachung dieses Modells stellt das sogenannte binäre Modell dar. Die
Fahrzeuge sind gemäß des binären Modells entweder fahrend oder wartend. Ist eine
Zelle frei, so nimmt sie analog wie beim Nagel-Schreckenberg-Modell den Zustand
−1 an. Die Zustandsmenge lautet daher Z = {−1, 0, 1}.
61
4 GRUNDLAGEN DER SIMULATION
62
Kapitel 5
Entwurf des Systems
Software kann man auf zwei Arten herstellen: Entweder macht man sie so klar und
”
einfach, dass sie offensichtlich keine Fehler hat. - Oder man macht sie so kompliziert, dass sie keine offensichtlichen Fehler hat“. Der Informatiker C.A.R. Hoare
spricht hiermit ein Hauptproblem bei der Entwicklung eines Softwaresystems an.
Schleichen sich in der Entwurfsphase Fehler bzw. Unklarheiten ein, so hat dies weitreichende Folgen, die den Erfolg des Systems beeinträchtigen können. Die Qualität
einer Softwareentwicklung hängt daher entscheidend von der Entwurfsphase ab.
Die Anforderungen an das zu realisierende System werden in Unterkapitel 5.1 dargelegt und spezifiziert. Unterkapitel 5.2 stellt den Datenbankentwurf auf konzeptueller
und logischer Ebene dar.
5.1
Anforderungserhebung
Dieses Unterkapitel konkretisiert die Anforderungen an das gesamte System. Verwendet wurden Use Cases als Methode für die Anforderungserhebung. Aus dem
hierbei entstandenen Use Case-Diagramm lassen sich zwei Teilsysteme herausarbeiten: Simulator und Monitor. In Abschnitt 5.1.1 werden die simulatorspezifischen
Anforderungen aufgezeigt. Anforderungen an das Monitor-Teilsystem beschreibt Abschnitt 5.1.2.
5.1.1
Anforderungserhebung Simulator
Im Rahmen dieser Diplomarbeit soll ein datenbankgestützter Simulator für Straßenverkehrsszenarien entworfen und implementiert werden. Aus der funktionalen
Anforderungserhebung des Simulationssystems können zwei große Ziele ausgelesen
werden. Einerseits soll das System als eigenständiges Simulationswerkzeug für den
63
5 ENTWURF DES SYSTEMS
Straßenverkehr dienen. Andererseits soll es in der Lage sein, mit dem Monitoringsystem zu interagieren. Dabei soll er den Dienst erbringen, kontinuierlich Daten für
das Verkehrsüberwachungssystem von Verkehrssündern bereitzustellen. Diese Ziele
müssen bei der Erstellung der Use Cases beachtet und in Betracht gezogen werden.
Außerdem zu berücksichtigen ist die Interaktion des Systems mit einem externen
Benutzer als Bediener einer grafischen Benutzeroberfläche. Der Benutzer ist als einziger Akteur am System beteiligt.
Die funktionalen Anforderungen an das System veranschaulicht Abbildung 5.1. Die
simulatorzpezifischen Anwendungsfälle sind in Gelb dargestellt. Die roten gestrichelten Linien sollen die Abhängigkeiten zwischen dem Simulator und dem Monitor
kennzeichnen. Im Folgenden wird auf die wesentlichen Teile dieser Use Cases eingegangen.
Der Use Case Straßentopologie aufbauen beschreibt den Vorgang unmittelbar nach
dem Start des SiMo-Systems. Hierbei werden eine Übersichtskarte und lokale Ausschnitte geladen. Die Übersichtskarte zeigt das gesamte Simulationsgebiet an, während sich die lokalen Ausschnitte auf ausgewählte Räume aus diesem Simulationsgebiet fokussieren. Das betrachtete Simulationsgebiet wird durch die Straßen
Römerstraße, Augustusring, Graurheindorfer Straße sowie die Autobahnbrücke begrenzt. Der Aufbau der Straßentopologie setzt voraus, dass eine Datenbank im Hintergrund verfügbar ist. In dieser Datenbank müssen die topologischen Daten, die
das Straßennetz abbilden, für die Darstellung des Simulationsgebiets vorliegen.
Beim Startvorgang ist der Simulator auf den Benutzer angewiesen, der die Simulation initialisieren soll. Genauso soll derselbe Akteur den Simulationsprozess beenden dürfen. Dies beschreibt der Use Case Simulation starten/stoppen. Der Simulator
reagiert auf die vom Benutzer ausgeführten Aktionen, indem er entsprechende Ereignisse auslöst. Folglich entstehen eine Menge von Aufgaben, die durch den Use
Case Verkehr simulieren beschrieben werden. Daher kann dieser Use Case in drei
Use Cases zerlegt und dadurch verfeinert werden. Dieser Zusammenhang wird durch
die funktionale Dekomposition include ausgedrückt.
Zur Simulation gehört zunächst die Steuerung der Lichtsignalanlagen, die durch
den Use Case LSAs steuern repräsentiert wird. Parallel soll der Simulator für die
Fortbewegung der Fahrzeuge auf dem Straßennetz sorgen. Die Beschreibung dieser
Aufgabe erfolgt durch den Use Case Fahrzeuge fortbewegen, der durch einen weiteren Use Case Verkehrssünder generieren erweitert wird. Dieser beschreibt den Vorgang der Erzeugung von Fahrern, die ordnungswidriges Verhalten aufweisen. Dazu
gehören z.B. diejenigen, die Ampeln oder Vorfahrtsregeln missachten. Bei den Simulationen spielt die Simulation der Zeit eine große Rolle, welche hier durch den
64
5.1 Anforderungserhebung
Use Case Simulationsuhr fortschreiten lassen beschrieben wird. Dadurch lässt sich
die zeitliche Abfolge von Fahrzeugpositionen und Bewegungen sowie Ampelzuständen
festhalten. Zusammenfassend werden die einzelnen Aspekte des Use Cases Verkehr
simulieren in folgender Beschreibung dargelegt:
Name des Use Cases: Verkehr simulieren
Kurzbeschreibung: Simuliert die Steuerung der LSAs,
Simulationsuhr und die Fortbewegung der Fahrzeuge.
Akteure: Anfangsbedingung:
1. Die Übersichtskarte wurde geladen.
2. Der Benutzer hat den Start-Knopf gedrückt.
Ereignisfluss:
1. Simulationsuhr starten und fortschreiten lassen.
2. LSA-Steuerung starten und Ampelschaltung regeln.
3. Fahrzeuge generieren und fortbewegen.
Endbedingung: Der Benutzer drückt den Stopp-Knopf.
Ausnahmen: -
Der Benutzer soll bei Bedarf die Möglichkeit haben, verschiedene Parameter der Simulation zu verändern. Einer dieser Parameter ist die Simulationsgeschwindigkeit,
welche die minimale Zeitspanne zwischen zwei Zustandsänderungen eines Fahrzeugs
festlegt. Der Anwendungsfall Simulationsgeschwindigkeit ändern repräsentiert die
Anpassung dieser Größe an die Benutzerwünsche. Weiterhin besteht für den Benutzer noch die Möglichkeit, die Verkehrsdichte zu manipulieren. Die Verkehrsdichte
kann durch die Anzahl der Fahrzeuge auf einer Fläche zu einem gegebenen Zeitpunkt definiert werden. Dieser Fall beschreibt der Use Case Verkehrsdichte ändern.
Bei Betrachtung des Verkehrsaufkommens in der Realität lässt sich feststellen, dass
ein Zusammenhang zwischen Verkehrsdichte und der aktuellen Tageszeit bzw. des
jeweiligen Wochentages besteht. So befinden sich zum Beispiel wochentags zu Zeiten
des Berufsverkehrs besonders viele Fahrzeuge auf den Straßen. Um die Simulation
auch in diesem Sinne realtitätsnah zu gestalten, sollen auf Wunsch des Benutzers
Wochentage und Tageszeiten für die Simulation festgelegt werden können und dadurch indirekt eine Veränderung der Vekehrsdichte bewirkt werden. Da diese Festlegung ein Sonderfall der Änderung der Verkehrsdichte darstellt, erweitert der Use
Case Wochentag/Tageszeit festlegen den Use Case Verkehrsdichte ändern. Auch die
Lichtsignalanlagen richten sich gemäß ihres Signalprogrammes nach diesen Zeiten.
Daher ist der Use Case LSA steuern abhängig vom Use Case Wochentag/Tageszeit
festlegen.
65
5 ENTWURF DES SYSTEMS
LSAs
steuern
Fahrzeuge
fortbewegen
Simulationsuhr
fortschreiten lassen
<<include>>
<<include>>
<<extends>>
<<include>>
Verkehrssünder
generieren
Verkehr
simulieren
Straßentopologie
aufbauen
<<include>>
Wochentag/Tageszeit
festlegen
Ausschnitte
laden
Simulation
starten/stoppen
<<extends>>
Verkehrsdichte
ändern
<<include>>
Übersichtskarte
laden
Simulationsgeschw.
ändern
Simulation
abspielen
Kreuzung
designen
Benutzer
<<include>>
Signalgeber
zuordnen
Kreuzungsbereich
beobachten
<<extends>>
<<include>>
<<include>>
Regelverstoß
melden
Verkehrszeichen
zuordnen
LSA-Phasen
definieren
Regelverstoß
loggen
Szenario
erstellen
<<include>>
<<include>>
Signalisierungszustand
festlegen
Fahrzeug
setzen
Abbildung 5.1: Use-Case Entwurf
66
Regelverstoß
abspielen
5.1 Anforderungserhebung
5.1.2
Anforderungserhebung Monitor
Der Entwurf und die Implementierung eines datenbankgestützten Monitors zur Überwachung von Verkehrsregelverstößen stellt den zweiten Teil dieser Diplomarbeit dar.
Bei der Anforderungserhebung des Monitor-Teilsystems lässt sich auch hier der Akteur Benutzer identifizieren, der über ein GUI mit dem System interagieren kann.
In Abbildung 5.1 sind die monitorspezifischen Use Cases mit blauer Farbe unterlegt.
Die dadurch repräsentierten Anforderungen an das Teilsystem werden nachfolgend
im Detail beschrieben.
Die eigentliche Funktionalität des Monitor-Teilsystems liegt in der Auswertung der
simulierten Daten durch den Monitor, während sich der simulierte Verkehr auf dem
GUI beobachten lässt. Die zu überwachenden Verkehrsteilnehmer sollen sich in dieser
Arbeit auf die Fahrer von Kleinkraftfahrzeugen beschränken, welche vom Simulator
erzeugt werden. In regelmäßigen Abständen soll ihr Verhalten hinsichtlich Ordnungswidrigkeiten überprüft werden, das sich durch die Eigenschaften und Fahrzeugbewegungen der Fahrzeuge ausdrückt. Wie bereits in Kapitel 1 erwähnt, beschränkt sich
das Monitoring auf Kreuzungsbereiche. Der diese Überprüfung betreffende Use Case
Kreuzungsbereich beobachten basiert auf den aktuell erzeugten Simulationsdaten und
ist daher abhängig vom Simulationsprozess des Simulators. Die folgende textuelle
Beschreibung erläutert den Use Case Kreuzungsbereich beobachten im Detail:
Name des Use Cases: Kreuzungsbereich beobachten
Kurzbeschreibung: Die vom Simulator gelieferten Daten werden
hinsichtlich Ordnungswidrigkeiten bezüglich der StVO überprüft.
Akteure: Anfangsbedingung: Die Simulation ist gestartet
(Datenquelle ist entweder der Simulator oder selbst
erstellte Szenarien) und liefert Daten.
Ereignisfluss:
1. Die Fahrzeugbewegungen werden im Kreuzungsbereich in Echtzeit
hinsichtlich möglicher Regelverstöße überprüft.
2. Zu den zu überprüfenden Ordnungswidrigkeiten gehören:
- Vorfahrtsverletzung
- Rotlichtverstoß
- Einfahrt in Straße entgegen vorgeschriebener Fahrtrichtung
- Einfahrt in Kreuzung trotz stockendem Verkehr
- Falsches Setzen des Fahrtrichtungsanzeigers
Endbedingung: Ausnahmen: -
67
5 ENTWURF DES SYSTEMS
Begeht ein Verkehrsteilnehmer eine Ordnungswidrigkeit und wird diese erkannt, meldet das System unmittelbar diesen Regelverstoß. Das Melden eines Regelverstoßes
gehört zur Überwachung von Regelverstößen, jedoch ist der Use Case zur Beobachtung auch ohne den Use Case Regelverstoß melden ausführbar. Da er somit einen
Sonderfall darstellt, steht der Use Case Regelverstoß melden in einer Erweiterungsbeziehung zu dem Use Case Kreuzungsbereich beobachten.
In Fall eines erkannten Regelverstoßes ist eine weitere Aufgabe des Monitors, den
Regelverstoß zu loggen, d.h. persistent in einer Datenbank zu speichern. Der Use
Case Regelverstoß loggen ist abhängig vom Melden eines Regelverstoßes. Eine weitere wichtige funktionale Anforderung stellt das wiederholte Ansehen erkannter Regelverstöße dar. Diese Aktivität wird durch den Use Case Regelverstoß abspielen
repräsentiert und kann vom Benutzer initiiert werden. Abgespielt werden können
jedoch nur Verkehrssituationen, die vom Monitor geloggt wurden. Daher besteht
eine Abhängigkeit zwischen den Use Cases Regelverstoß abspielen und Regelverstoß
loggen.
Die gewünschte Unabhängigkeit vom Simulator erfordert, dass es dem Benutzer
des Systems möglich ist, eigene Verkehrsszenarien auf einer Kreuzung zu erstellen.
Die dadurch aufgezeichneten Daten können dann ebenso wie die simulierten Daten des Simulators als Input für die Überwachung von Regelverstößen dienen. Diese
funktionale Anforderung repräsentiert der Use Case Szenario erstellen, in welchem
zwei Arbeitsabläufe integriert sind. Um Fahrzeugbewegungen zu konstruieren, werden zum einen die Positionen beteiligter Fahrzeuge sowie ihre Fahrtrichtung und
Fahrtrichtungsanzeiger Zeitschritt für Zeitschritt festgelegt. Bei Existenz einer Lichtsignalanlage ist es weiterhin notwendig, den Signalisierungszustand der Signalgeber
im Verlauf der Zeit zu definieren.
Für die Benutzung des GUIs wird davon ausgegangen, dass topologische Daten über
die Straßen eines Verkehrsgebietes bereits in einer Datenbank hinterlegt sind. Darauf
aufbauend betrifft eine der funktionalen Anforderungen das Einrichten einer Kreuzung, was durch den Use Case Kreuzung designen repräsentiert wird. Wie in dem Use
Case-Diagramm in Abbildung 5.1 zu sehen ist, enthält dieser Use Case zum einen
das Zuordnen von Verkehrszeichen und Signalgebern. Zum anderen gehört zum Design einer Kreuzung das Definieren der zu den Signalgebern gehörigen LSA-Phasen.
Letzteres bedeutet, dass die Länge der einzelnen Phasen sowie die Signalbilder der
Signalgeber eingestellt werden können. Zusammenfassend werden folgende Anforderungen festgelegt:
68
5.2 Datenbankentwurf
Name des Use Cases: Kreuzung designen
Kurzbeschreibung: ermöglicht das Design einer Kreuzung
zum Abspeichern in einer Datenbank
Akteure: Benutzer
Anfangsbedingung: In der Datenbank ist bereits
die Topologie der Kreuzungen gespeichert.
Wenn das Design bisher noch nicht festgelegt wurde,
entspricht die Kreuzung einem Rechts-vor-Links-Knoten.
Ereignisfluss:
1. Kreuzung auswählen, die bearbeitet werden soll
2. Signalgeber zuordnen
3. Verkehrszeichen zuordnen
4. Falls Signalgeber zugeordnet wurden, Anzahl
und Länge der Phasen sowie Signalbild der einzelnen
Signalgeber für jede Phase einstellen.
5. Die Konfiguration der Kreuzung speichern
Endbedingung: Die Konfiguration wurde gespeichert.
Ausnahmen: -
5.2
Datenbankentwurf
Die datenbankgestützte Natur des SiMo“-Systems erfordert den Entwurf einer Da”
tenbank, welche eine gemeinsame Grundlage für beide Teilsysteme bildet. Deswegen
war eine gemeinsame Arbeit vom Entwurf bis hin zur Datenerhebung erforderlich.
Gemäß der beim Datenbankentwurf zu durchlaufenden Phasen beschreibt Abschnitt
5.2.1 zunächst den konzeptuellen Entwurf. Anschließend wird die logische Umsetzung in Abschnitt 5.2.2 erläutert.
5.2.1
Konzeptueller Entwurf
Wie bereits erwähnt, erfordert der Entwurf einer Datenbank zunächst die Abbildung der realen Welt auf eine konzeptuelle Ebene (vgl. Abschnitt 2.1.2). In dieser
Arbeit wird dafür das Entity-Relationship-Modell eingesetzt, um Objekte und ihre
Beziehungen untereinander zu identifizieren. Zunächst stellt sich jedoch die Frage,
wie sich die Straßentopologie für ein Stadtgebiet durch ein Modell abbilden lässt.
Darauf aufbauend erläutert dieser Abschnitt, wie sich die Bestandteile einer Straßenkarte durch Entities beschreiben lassen und welche Zusammenhänge zwischen
diesen bestehen.
Die Topologie der Straßen baut grundlegend auf der Theorie der zellularen Automaten auf. Einzelne Zellen stellen somit die Grundbausteine des Straßennetzes
dar, durch deren Aneinanderreihung die Wege modelliert werden. In dieser Arbeit
69
5 ENTWURF DES SYSTEMS
soll ein Ausschnitt des Bonn-Nord-Gebietes näher betrachtet werden, welcher somit
durch Aufteilung in einzelne Zellen zu diskretisieren ist. Zur Vereinfachung wird
hierbei angenommen, dass Straßen nur in einem rechten Winkel aufeinander treffen
können. Dies erleichertert die Darstellung durch rechteckige Zellen auf dem GUI und
ist deshalb möglich, weil es das Ziel der Arbeit in keiner Weise beeinflusst. Ansonsten ist das betrachtete Stadtgebiet in seinen Proportionen und seiner Beschilderung
möglichst realitätsgetreu zu modellieren. Stadtpläne sowie eine Bestandsaufnahme
vor Ort haben dies für das im Rahmen dieser Arbeit entworfene System ermöglicht.
x
y
1 2 3 4 5 6 7 8 9
2
3
4
5
6
7
8
9
Abbildung 5.2: Straßentopologie
Abbildung 5.2 veranschaulicht die gemeinsam für die Simulation und das Monitoring verwendete Modellierung der Straßentopologie. Die in der Abbildung grau
dargestellten Zellen, aus denen die Straßen zusammengesetzt sind, werden dabei
durch eine X- und eine Y-Koordinate eindeutig identifiziert und einer bestimmten
Position zugeordnet. Das gesamte Gebiet ist damit logisch in ein gleichmäßiges Gitter eingeteilt, dessen obere linke Ecke mit der Koordinate (1,1) ausgezeichnet ist.
Aus diesen absoluten Angaben lässt sich weiterhin die Von-Neumann-Nachbarschaft
der Zellen ableiten: Eine Zelle ist Nachbar einer anderen Zelle, sofern sich diese entweder in ihrer X- oder aber in ihrer Y-Koordinate um 1 unterscheiden.
Die Schnittpunkte, in denen die verschiedenen Straßen zusammentreffen, werden als
Knoten bezeichnet. Den Begrifflichkeiten aus Unterkapitel 3.1 entsprechend können
dies sowohl Kreuzungen als auch Einmündungen sein. Eine schematische Darstellung eines Straßenknotens zeigt Abbildung 5.3. Sie ist aus einzelnen Zellen aufgebaut, die vier aufeinandertreffende Straßen ergeben. Eine Straße besitzt für jede
Fahrtrichtung jeweils eine Spur, eine Erweiterung auf mehrere Fahrstreifen ist analog
möglich. Um den Zellen in Kreuzungsnähe eine Struktur geben zu können, werden sie
in unterschiedliche Typen aufgeteilt. Die gestreiften Zellen in der Mitte der Kreuzung stellen den eigentlichen Kreuzungsbereich dar und werden als Knotenzellen
bezeichnet. Weiterhin lassen sich die direkt anliegenden Zellen in Knotenzufahrten
und Knotenabfahrten unterscheiden. Über die Knotenzufahrten - in der Abbildung
70
5.2 Datenbankentwurf
hellgrau gefärbt - befahren die Fahrzeuge den Kreuzungsbereich. Die dunkelgrauen
Knotenabfahrten charakterisieren diejenigen Zellen, die zum Verlassen der Kreuzung
dienen. Alle restlichen, außerhalb liegenden Zellen werden den Straßen zugeordnet
und gehören der Kategorie Straßenzelle an.
Knotenzelle
Knotenabfahrt
Knotenzufahrt
Straßenzelle
Abbildung 5.3: Schematische Darstellung eines Straßenknotens
Abbildung 5.3 veranschaulicht weiterhin die erlaubten Fahrzeugbewegungen innerhalb eines Knotens, welche durch gerichtete Pfeile angedeutet werden. Die gestreiften
Knotenzellen des Kreuzungsbereichs nehmen eine besondere Stellung ein, da sie aus
zwei Richtungen befahren und auch in zwei Richtungen wieder verlassen werden
können. Fahrzeugbewegungen, die entgegen der Vorschriften verlaufen, werden hierbei nicht einbezogen. Für die konzeptuelle Modellierung lässt sich damit festhalten,
dass das Straßennetz grob als Graph zu verstehen ist, der aus Knoten und deren
Verbindungen zueinander aufgebaut ist. Die Knoten repräsentieren die Kreuzungen
oder Einmündungen, die durch Straßen miteinander verbunden sind.
Abbildung 5.4 zeigt das Entity-Relationship-Diagramm, welches gemeinschaftlich
für Simulator und Monitor entstanden ist. Aus der Aufteilung des Straßennetzes in
einzelne Zellen lässt sich zunächst der Entity-Typ Zelle als zentrales Element ableiten. Eine Zelle ist bereits durch seine Attribute zu X- und Y-Koordinate eindeutig
identifizierbar. Ein Zugriff auf Aus GUI-technischen Gründen führt ein zweiteiliger
Schlüssel jedoch zu Problemen (siehe Abschnitt 7.1.1). Daher existiert zusätzlich
das Schlüsselattribut zellen id. Eine Differenzierung der Zellen lässt sich gemäß dem
zuvor beschriebenen Straßenmodell durch Untertypen mit einem is a-RelationshipTyp festhalten, sodass weiterhin die Entity-Typen Straßenzelle, Knotenzelle, Knotenabfahrt und Knotenzufahrt existieren.
71
5 ENTWURF DES SYSTEMS
Fahrzeug
1
steht_auf
1
1
Knoten
N
is_part_of
N
Zelle
ist_Nachbar_von
M
is_a
Straßenzelle
Knotenzelle
N
1
M
zugeordnet_2
zugeordnet_1
1
M
rechte_Zufahrt
N
linke_Zufahrt
N
Signalgeber
Knotenabfahrt
Knotenzufahrt
Verkehrszeichen
N
M
M
Zufahrt_gegenüber
N
is_part_of
1
N
Lichtsignalanlage
N
rechte_Abfahrt
M
zeigt_an
1
N
M
linke_Abfahrt
M
hat
N
N
Abfahrt_gegenüber
Phase
N
dauert
M
Zeitintervall
Abbildung 5.4: Entity-Relationship-Diagramm
72
M
5.2 Datenbankentwurf
Die Zellen lassen sich ferner einem Knoten zuordnen. Daraus ist der Entity-Typ Knoten ableitbar, dessen Enitities durch die jeweilige knoten id identifiziert werden. Um
dem Benutzer die Unterscheidung der Knoten in der Interaktion mit dem System zu
erleichtern, sollen sie zusätzlich mit einer textuellen Bezeichnung versehen werden.
Der Knotenbegriff soll erweitert werden, indem einem Knoten auch Straßenzellen zugeordnet werden können. Dies ist für den späteren Einsatz von Bedeutung, da durch
einen Knoten ein gesamter Überwachungsbereich definiert wird, zu dem nicht nur
Knotenzellen, Knotenabfahrten und Knotenzufahrten gehören müssen. Die Zuordnung von Zellen zu einem Knoten lässt sich durch einen Relationship-Typ is part of
mit einer 1:N-Kardinalität abbilden.
Um die Fahrzeugbewegungen innerhalb eines Knotens herleiten und Verkehrsregeln
in SQL formulieren zu können, ist es weiterhin wichtig, zu definieren, wie Knotenabfahrten und Knotenzufahrten zueinander in Beziehung stehen. Zum einen werden
jeder Knotenzufahrt beliebig viele Knotenzufahrten zugeordnet, die auf einer Straße
rechts, links oder gegenüber von ihr liegen. Diese insbesondere für Vorfahrtregeln
relevanten Informationen repräsentieren die Relationship-Typen rechte Zufahrt, linke Zufahrt und Zufahrt gegenüber. Weiterhin ist die relative Lage der Abfahrten
bezüglich der Zufahrten erforderlich, mit denen sich die Information abfragen lässt,
welche Richtung ein Fahrzeug auf dem Knoten verfolgt. Hierfür existieren ebenfalls drei Relationship-Typen: rechte Abfahrt, linke Abfahrt und Abfahrt gegenüber.
Aufgrund der Unterstützung mehrerer Fahrstreifen für eine Fahrtrichtung kann einer
Zufahrt mehr als eine Zu- bzw. Abfahrt zugeordnet werden, die links, rechts oder gegenüber von ihr liegt. Daher bestehen zwischen den Zellen jeweils N:M-Beziehungen.
Weiterhin ist das Wissen über die Zellennachbarn und ihre Lage zueinander von
großer Bedeutung, um die unmittelbare Umgebung eines Fahrzeugs erkunden zu
können. Aus diesem Grund existiert der Relationship-Typ ist Nachbar von, dessen
Relationships eine Von-Neumann-Nachbarschaft zugrunde liegt. An dieser Nachbarschaft orientiert bezeichnet ein Attribut lage zusätzlich, ob die Nachbarzelle vor,
hinter, links oder rechts einer Zelle liegt. Betrachtet werden sollen hier im Vergleich
zu Abbildung 5.3 nur diejenigen Nachbarn, die gemäß verkehrsrechtlichen Vorschriften zu erlaubten Fahrzeugbewegungen führen. Für die Knotenzellen im Kreuzungsbereich, denen meist mehr als ein Nachbar zugeordnet werden kann, ist eine weitere
Differenzierung erforderlich. Daher wird ein Attribut fahrtrichtung eingeführt, welches die Lage des Nachbarn von der Ausrichtung des Fahrzeugs auf dieser Zelle
abhängig macht.
Für die Nachbildung des regelgerechten Straßenverkehrs sind des Weiteren Verkehrsschilder und Ampeln zu modellieren. Die Instanzen des Entity-Typs Verkehrszeichen
sollen alle für dieses System möglichen Arten von Verkehrsschildern wie z.B. Vor”
fahrt gewähren!“ zusammenfassen. Charakteristisch für diesen Entity-Typ ist die
StVO-Zeichen-Nummer. Da dessen Wertebereich jedoch nicht numerisch ist, dies
73
5 ENTWURF DES SYSTEMS
aber für die Identifikation im Gegensatz zu Zeichenketten besser zu handhaben ist,
besitzt der Entity-Typ das Schlüsselattribut zeichen id. Im Sinne einer Erweiterung
muss auch bedacht werden, dass manche Verkehrszeichen, die in dem hier betrachteten Simulationsgebiet nicht vorhanden sind, über keine StVO-Zeichen-Nummer
verfügen. Auch aus diesem Grund wird ein künstlicher Schlüssel benötigt. Durch
den Relationship-Typ zugeordnet 2 wird schließlich ein Verkehrszeichen mit seinen
zugeordneten Knotenzufahrten verbunden. Einer Knotenzufahrt lassen sich beliebig
viele Verkehrszeichen zuordnen, sodass eine N:M-Beziehung gerechtfertigt ist.
Einer Knotenzufahrt lässt sich ferner ein Signalgeber zuordnen. Der Entity-Typ
Signalgeber umfasst daher alle im Verkehrsgebiet existierenden Signalgeber, welche
mit den Entities des Entity-Typs Zelle eine 1:1-Beziehung eingehen. Genauer bedeutet dies, dass jedem Signalgeber genau eine Knotenzufahrt zugeordnet werden
darf. Es stellt sich die Frage, ob sich die Relationship-Typen zugeordnet 1 und zugeordnet 2 nicht zusammenfassen ließen und Signalgeber sowie Verkehrsschilder von
einem gemeinsamen Obertyp ableitbar sind. Von der konzeptuellen Umsetzung sind
diese zwei jedoch sehr unterschiedlich, da im Gegensatz zu Signalgebern nicht jedes
an einer Zufahrt aufgestellte Verkehrsschild einzeln aufgeführt wird. Somit sind die
zwei Relationship-Typen zur Zellenzuordnung angebracht.
Betrachtet man die reale Welt, so lässt sich weiterhin feststellen, dass jeder Signalgeber Teil einer Lichtsignalanlage (LSA) ist, die für die Steuerung der gesamten
Kreuzung zuständig ist. Im Entwurf wird dies durch einen is part of -RelationshipTyp modelliert. Ob die LSA in oder außer Betrieb ist, besagt das boolesche Attribut
in betrieb. Die Steuerung der LSA erfolgt durch eine Folge verschiedener Phasen.
In einem numerischen Attribut phase kann daher während der Simulation festgelegt werden, in welcher Phase des Steuerungsprozesses sich die LSA befindet. Jeder
Lichtsignalanlage stehen somit N verschiedene Phasen zur Verfügung, mit denen
durch weitere Beziehungen festgelegt wird, wie lange die zugehörigen Signalgeber
welches Signalbild anzeigen. Um jede einzelne Phase aufführen zu können, existiert
somit der Entity-Typ Phase.
Charakteristisch für jede Phase ist demnach die Signalzeit für bestimmte Zeitintervalle. Daher drückt der Relationship-Typ dauert aus, wie lange die jeweiligen
Phasen des Signalprogramms dauern. Der Eintrag des zugehörigen Attributs Signalzeit ist abhängig von den Attributwerten tag, uhrzeit anfang und uhrzeit ende
des Entity-Typs Zeitintervall, welche zusammen eine Zeitspanne eines Tages definieren.
Die simulierte Schaltung der LSA wird letztlich über die Signalgeber sichtbar. Sie
können die Farben Rot oder Grün anzeigen. Die Signalfarbe Orange ist aufgrund
der Zeit-Diskretisierung nicht zwingend erforderlich und wurde der Einfachheit halber nicht betrachtet. Der Relationship-Typ zeigt an modelliert somit die Abbildung
eines Signalgebers und einer zur LSA gehörenden Phase auf das entsprechende Signalbild.
74
5.2 Datenbankentwurf
Wichtigster Bestandteil der Simulation stellen die Fahrzeuge dar. Sie werden durch
den Entity-Typ Fahrzeug repräsentiert. Um die Fahrzeuge eindeutig identifizieren zu
können, dient das Attribut fahrzeug id zur Unterscheidung einzelner Fahrzeuge. Das
Attribut blinker gibt durch seine möglichen Werte ’links’, ’rechts’ oder ’geradeaus’
an, welche gewünschte Abbiegerichtung an einem Knoten durch den Fahrtrichtungsanzeiger angezeigt wird. Eine weitere charakteristische Eigenschaft der Fahrzeuge
stellt die Geschwindigkeit dar. Der Simulation in dieser Arbeit liegt ein binäres Modell zugrunde, was bedeutet, dass die Geschwindigkeit der Fahrzeuge nur zwei Werte,
0 oder 1, annehmen kann. Um die Erweiterbarkeit des Systems zu unterstützen, ist
dennoch das Attribut geschwindigkeit vorgesehen, das die Geschwindigkeitswerte für
eventuell andere Modelle angeben soll.
Für die Fortbewegung der Fahrzeuge und deren angemessene Darstellung auf dem
GUI wird weiterhin die Fahrtrichtung eines Fahrzeugs benötigt. Die Ausrichtung
ist durch die Werte ’Sued’, ’Nord’, ’West’ und ’Ost’ beschrieben, deren Bedeutung
äquivalent zu oben, unten, links und rechts ist. Sie stimmen daher nicht exakt mit
der tatsächlichen Himmelsrichtung des Stadtgebietes überein, wurden jedoch als
Bezeichnung gewählt, um eine Verwechslung mit den Blinker-Werten zu vermeiden
und dem Benutzer dennoch eine intuitive Vorstellung über die Ausrichtung zu geben.
Die momentane Position eines Fahrzeugs innerhalb des Verkehrsgebietes drückt der
Relationship-Typ steht auf aus. Jedes Fahrzeug ist genau einer Zelle zugeordnet.
Die an der Relationship beteiligte Zelle ist die vom Fahrzeug zuletzt besuchte Zelle
und dient damit der Visualisierung der Fahrzeuge auf dem GUI.
5.2.2
Logischer Entwurf
Nach dem konzeptuellen Entwurf folgt die Umsetzung des Entity-Relationship-Diagramms in das relationale Schema. Grob lässt sich das Datenbankschema des Systems in Tabellen für die Topologie und Tabellen für die Simulation unterteilen, die
im Folgenden beschrieben werden.
Zentraler Bestandteil der Straßentopologie stellt der Entity-Typ Zelle dar, der durch
vier Unterklassen spezialisiert wurde. Wie in Abschnitt 2.1.2 (relationales Modell)
erläutert, kann eine Vererbung auf drei unterschiedliche Weisen umgesetzt werden.
Zu analysieren ist hierbei, welche Informationen über die Zellen in der späteren
Anwendung am häufigsten benötigt werden. Im Fall dieses Systems spielt die Unterscheidung der Zellen eine besondere Rolle. Die einzelnen Zellentypen werden wesentlich häufiger abgefragt als die allgemeinere Information der Zellen. Dies spricht dafür,
das die Entity-Typen Knotenzufahrt, Knotenabfahrt, Knotenzelle und Strassenzelle
auf eigene Tabellen abgebildet werden, die die geerbten Attribute des Obertyps Zelle
aufnehmen:
knotenzelle(zellen_id, x, y, knoten_id)
knotenzufahrt(zellen_id, x, y, knoten_id)
knotenabfahrt(zellen_id, x, y, knoten_id)
strassenzelle(zellen_id, x, y, knoten_id)
75
5 ENTWURF DES SYSTEMS
Aufgrund des is part of -Relationship-Typs, der die Beziehung zwischen dem EntityTyp Knoten und den verschiedenen Entity-Typen der Zellen darstellt, ist das Attribut knoten id zur jeweiligen Zellentabelle herangezogen und als Fremdschlüssel
angelegt worden. Die Tabelle zum Obertyp Zelle lässt sich mithilfe einer View zusammenstellen:
CREATE VIEW zelle AS
(
SELECT zellen_id, x,
FROM knotenabfahrt
UNION
SELECT zellen_id, x,
FROM knotenzufahrt
UNION
SELECT zellen_id, x,
FROM knotenzelle
UNION
SELECT zellen_id, x,
FROM strassenzelle;
)
y, knoten_id
y, knoten_id
y, knoten_id
y, knoten_id
Um sich die wiederkehrende Anfragebearbeitung zu ersparen und damit einen erheblichen Performanzgewinn zu erzielen, ist es aus Effizienzgründen besser, diese View
zu materialisieren. Die Nachteile, die solche Views nach sich ziehen können, lassen
sich hier aus zwei Gründen relativieren. Zum einen bleibt der Verwaltungsaufwand,
den solche Views bei Änderungsoperationen mitbringen, wegen der statischen Natur
der Straßentopologie erspart. Die Daten in den vier Tabellen werden nur im Fall einer Erweiterung des Simulationsgebiets modifiziert. Ist die Straßentopologie einmal
erfasst, bleibt sie langfristig unverändert. Werden außerdem solche materialisierten
Views vom DBMS unterstützt, so ist auch die Änderungspropagierung der Daten
sichergestellt. Zum anderen steigt der Speicherplatzbedarf aufgrund der redundanten Daten. Dies kann heutzutage bei ausreichendem Speicherplatz dennoch in Kauf
genommen werden, um an Performanz zu gewinnen.
Da der Relationship-Typ Ist Nachbar von mit einer N-M-Kardinalität ausgezeichnet
ist, wurden diese Informationen auf eine eigene Tabelle abgebildet:
nachbarzellen(zellen_id, nachbar_id,lage)
In der Spalte lage dieser Tabelle wird durch die Werte ’V’ für vorne bzw. ’R’ für
rechts eingetragen, wie die Nachbarn zu einer Zelle liegen. Linke bzw. hintere Nachbarn müssen nicht explizit gespeichert werden, sondern können durch die SymmetrieEigenschaft hergeleitet werden.
76
5.2 Datenbankentwurf
Der Entity-Typ Knoten wird durch die Tabelle knoten konkretisiert:
knoten(knoten_id, vorfahrtregelung,bezeichnung)
Die unterschiedlichen Vorfahrtsregelungen werden in der Spalte vorfahrtsregelung
abgekürzt folgendermaßen eingetragen:
• LSA MB
• LSA OB
• BK
• RVL
Der Wert ’LSA MB’ repräsentiert eine Lichtsignalanlage (LSA) mit Beschilderung.
Diese sind solche Knoten, die von einer LSA gesteuert werden und denen zusätzlich
Verkehrsschilder zugeordnet sind. Mit ’LSA OB’ werden Knoten mit LSA, aber ohne Beschilderung gekennzeichnet. Ein Eintrag ’BK’ bezeichnet hingegen Knoten, bei
denen der Kreuzungsverkehr lediglich mithilfe von Verkehrsschildern geregelt wird.
Gilt allerdings nur die Rechts-vor-links-Regel, so wird dem Attribut vorfahrtsregelung der Wert ’RVL’ zugewiesen.
Wie in Abschnitt 5.2.1 erwähnt wurde, wird mit den N-M-Relationship-Typen rechte Zufahrt, linke Zufahrt, Zufahrt gegenüber, rechte Abfahrt, linke Abfahrt und Abfahrt gegenüber die Beziehung zwischen Zufahrten und Abfahrten zur Gestaltung
gebracht. Kardinalitätsbedingt wurden diese Relationship-Typen auf eigene Tabellen abgebildet:
rechte_zufahrt(zellen_id_zufahrt, zellen_id_rechteZufahrt)
rechte_abfahrt(zellen_id_zufahrt, zellen_id_rechteAbfahrt)
linke_abfahrt(zellen_id_zufahrt, zellen_id_linkeAbfahrt)
abfahrt_gegenüber(zellen_id_zufahrt, zellen_id_gegenüber)
Die Menge der linken Zufahrten kann aus Symmetriegründen durch eine View mit
der Tabelle rechte zufahrt zusammengestellt werden. Ist eine Zufahrt A rechte Zufahrt einer Zufahrt B, dann ist B folglich linke Zufahrt zu A:
CREATE VIEW linke_zufahrt AS
(
SELECT rz.zellen_id_rechtezufahrt AS zellen_id_zufahrt,
rz.zellen_id_zufahrt AS zellen_id_linkeZufahrt
FROM rechte_zufahrt AS rz;
)
Zufahrten gegenüber einer Zufahrt, welche durch den Relationship-Typ
Zufahrt gegenüber repräsentiert werden, können per Transitivitätsprinzip definiert
werden. Verdeutlicht wird dies durch Abbildung 5.5 a. Die Zufahrt G gegenüber der
77
5 ENTWURF DES SYSTEMS
G
G
R
Z
R
Z
(a) Kreuzung
(b) Einmündung
Abbildung 5.5: Bestimmung von Zufahrten gegenüber
schwarzen Zelle Z kann in diesem Sinne in zwei Schritten festgelegt werden. Zuerst
wird auf ihre rechte Zufahrt R zugegriffen. Dann ist die Zelle G die rechte Zufahrt
der Zelle R. Einmündungen stellen hierbei eine Ausnahme dar. Nicht jeder Zufahrt
lässt sich eine rechte Zufahrt zuordnen. Veranschaulicht wird dies schematisch durch
die Situation in Abbildung 5.5 b. In diesem Fall kann die Zufahrt gegenüber transitiv
nur mithilfe der linken Zufahrt analog wie oben bestimmt werden. Die Umsetzung
des Relationship-Typs Zufahrt gegenüber kann mithilfe dieser zwei Vorgehensweisen
durch folgende Sicht erfolgen:
CREATE VIEW zufahrt_gegenüber AS
(
SELECT DISTINCT rz.zellen_id_zufahrt,
rz1.zellen_id_rechtezufahrt AS zellen_id_gegenüber
FROM rechte_zufahrt AS rz INNER JOIN rechte_zufahrt AS rz1
ON rz.zellen_id_rechtezufahrt = rz1.zellen_id_zufahrt
UNION
SELECT DISTINCT lz.zellen_id_zufahrt,
lz1.zellen_id_linkezufahrt AS zellen_id_gegenüber
FROM linke_zufahrt AS lz INNER JOIN linke_zufahrt AS lz1
ON lz.zellen_id_linkezufahrt = lz1.zellen_id_zufahrt;
)
Für ein in eine Vorfahrtstraße einfahrendes Fahrzeug (schwarze Zelle in Abbildung
5.6) ist es wichtig, die Zufahrten quer zur eigenen Zufahrt (graue Zellen) auf sich
78
5.2 Datenbankentwurf
nähernde vorfahrtberechtigte Fahrzeuge zu überprüfen. Für die Herleitung dieser
Information steht die View zufahrt quer als Vereinigung von rechte zufahrt und linke zufahrt zur Verfügung:
CREATE VIEW zufahrt_quer AS
(
SELECT rz.zellen_id_zufahrt,
rz.zellen_id_rechtezufahrt AS zellen_id_quer
FROM rechte_zufahrt AS rz
UNION
SELECT lz.zellen_id_zufahrt,
lz.zellen_id_linkezufahrt AS zellen_id_quer
FROM linke_zufahrt AS lz;
)
Abbildung 5.6: Zufahrten quer zu einer Zufahrt
Die Fahrzeuge und ihre Positionen innerhalb des Simulationsgebietes werden relational auf die Tabelle fahrzeug abgebildet, die den Entity-Typ Fahrzeug darstellt:
fahrzeug(fahrzeug_id, zellen_id, blinker, geschwindigkeit,
fahrtrichtung)
Da die Beziehung steht auf ein 1-1-Relationship-Typ ist, wird der Schlüssel der Zelle
als Fremdschlüsselattribut zellen id in der Tabelle fahrzeug angelegt. Die Beziehung
wurde nicht in die Tabelle Zelle integriert, da die Positionen die Bewegungen eines
79
5 ENTWURF DES SYSTEMS
Fahrzeugs ausdrücken und somit als Eigenschaft eines Fahrzeugs zu betrachten sind.
Der Entity-Typ Verkehrszeichen sowie der N-M-Relationship-Typ zugeordnet 2 sind
auf die folgenden Tabellen abgebildet:
verkehrszeichen(zeichen_id, stvo_zeichen_nr, bezeichnung)
zeichen_zuordnung(zellen_id, zeichen_id)
Da der Entity-Typ Phase an sich keine charakteristischen Eigenschaften trägt, sondern nur im Zusammenhang mit anderen Entity-Typen an Bedeutung gewinnt, ist
dafür keine konkrete relationale Umsetzung vorgesehen. Die Phasen sind daher durch
eine Durchnummerierung und deren Zuordnung zu einer bestimmten LSA eindeutig festgelegt. Der Relationship-Typ dauert sowie der Entity-Typ Lichtsignalanlage
wurden folgendermaßen auf die Tabellen lsa und phasenschaltung abgebildet:
lsa(lsa_id, anzahl_phasen, phase, in_betrieb)
phasenschaltung(lsa_id, phase, tag, anfang, ende, dauer)
Wie bereits erwähnt, besteht jede LSA aus mehreren Signalgebern, die zu den
Knotenzufahrten durch Anlegen eines Fremdschlüsselattributes zellen id zugeordnet
werden. Analog ordnet das Attribut lsa id dem Signalgeber eine LSA zu. Signalgeber können auch nur für eine bestimmte Fahrtrichtung Gültigkeit haben. Dies wird
durch die Einträge ’links’, ’rechts’ und ’0’ des Feldes symbol ausgedrückt:
signalgeber(signalgeber_id, symbol, lsa_id, zellen_id)
Der binäre Relationship-Typ zeigt an wird relational durch die Tabelle signalbild
umgesetzt:
signalbild(signalgeber_id, phase, signalbild)
+
Abbildung 5.7: Von der Realität zum GUI
80
5.2 Datenbankentwurf
Auf der Grundlage der konzeptuellen und logischen Modellierung lassen sich die
Daten zur Beschreibung der Straßentopologie erheben. Abbildung 5.7 zeigt die notwendigen Schritte für den Übergang vom realen Stadtgebiet zu einer angemessenen
Darstellung auf dem GUI. Durch Erkundung des zu simulierenden Gebiets BonnNord und mithilfe des zugehörigen Stadtplans entstand eine maßstabsgetreue Abstraktion der Straßen auf Papier. Die Unterteilung von Straßen in Zellen konnte
somit auf Datenbankebene übertragen werden. Auf diesen Daten baut das GUI auf.
Darauf wird im Detail in den Abschnitten 7.1.1 und 7.2.3 eingegangen.
81
5 ENTWURF DES SYSTEMS
82
Kapitel 6
Architektur und Funktionalität
Das System lässt sich gemäß des Entwurfs grob in zwei zunächst unabhängig voneinander agierende Subsysteme unterteilen, die dennoch lose miteinander gekoppelt
sind: ein Verkehrssimulator und ein Monitor zur Überwachung von Regelverstößen.
Die Aufgabe des Verkehrssimulators besteht in der Generierung von Daten, die dem
Monitor als Input seiner Überwachungsaufgabe bereit gestellt werden. Unterkapitel
6.1 beschreibt zunächst die Gesamtarchitektur und gibt einen Überblick über die
einzelnen Bausteine des Systems. In Unterkapitel 6.2 und Unterkapitel 6.3 werden
die jeweiligen Teilsysteme Simulator und Monitor mit ihren zugehörigen Funktionaliäten und ihrer Architektur im Detail vorgestellt.
6.1
Gesamtarchitektur
Im Folgenden wird das gesamte System in seiner Architektur beschrieben, während
die verschiedenen Komponenten zunächst als Blackbox dargestellt werden. Die einzelnen Subsysteme weisen im Wesentlichen dieselbe Grundstruktur auf und setzen
sich dabei letztendlich aus drei Komponenten zusammen. Das Frontend bildet eine Benutzeroberfläche, die zum Visualisieren und Editieren der Verkehrsituationen
dient. Im Hintergrund steht ein Datenbankmanagementsystem, welches zur Strukturierung und Verwaltung der Daten eingesetzt wird. Gesteuert wird das jeweilige
Subsystem von einem Controller, der intelligent als Manager der Systemprozesse
fungiert und eine Schnittstelle zwischen Datenbank und GUI zu Verfügung stellt.
Abbildung 6.1 veranschaulicht das Zusammenspiel der beiden Subsysteme und ihrer
Komponenten. Hier lässt sich erkennen, dass die Datenbank für verschiedene Systembereiche zuständig ist. Als Grundlage für die Simulation ist eine Abstraktion der
Straßentopologie nötig. Diese wird aufgrund des datenbankbasierten Ansatzes dieser
Diplomarbeit auf Datenbankebene umgesetzt (vgl. Kap. 5.2.1). Auf die TopologieDatenbank greift sowohl der Monitor als auch der Simulator zu. Der Simulator legt
seine erstellten Ereignisse in der Simulationsdatenbank ab. Der Monitor hat damit
die Möglichkeit, diese in Echtzeit abzufragen und für seine interne Analyse und zur
83
6 ARCHITEKTUR UND FUNKTIONALITÄT
Simulator
GUI
Topologie-DB Simulations-DB
Monitor
Abbildung 6.1: Architektur des Gesamtsystems
Darstellung auf GUI-Ebene zu verwenden. Somit erfolgt die Kommunikation der
beiden Controller im Wesentlichen über die Datenbankkomponente, sodass sie auch
völlig unabhängig voneinander funktionsfähig sein können. Für spezifische Aufgaben
eines Subsystems sind schließlich lokale Tabellen und Views erforderlich.
Für die Datenverwaltung wurde MS Access als DBMS verwendet. Der entscheidende
Vorteil dabei liegt im geringen Wartungs- und Administrationsaufwand. In dieser Arbeit wurden jedoch keine Access-spezifischen Funktionalitäten eingebunden, sodass
eine Migration zu einem anderen DBMS keine große Schwierigkeit darstellen wird.
Da sowohl der Monitor als auch der Simulator den Verkehr auf der grafischen Benutzeroberfläche darstellen, liegt es nahe, die verschiedenen Ansichten in ein gemeinsames Fenster zu integrieren. Dennoch erzwingt diese Design-Entscheidung keine
Abhängigkeit der beiden Subsysteme: In allen Schritten der Entwicklung hat Modularität eine große Rolle gespielt. In diesem Abschnitt wurden die beiden Teilsysteme
lediglich als Blackbox dargestellt, nachfolgend soll darauf detailliert eingegangen
werden.
6.2
Simulator
Im Rahmen dieser Arbeit wurde aufbauend auf der Multiagentensimulation und
der diskreten Ereignissimulation ein Simulator für Verkehrsszenarien entworfen und
implementiert (vgl. Unterkapitel 4.3). Der Simulator soll datenbankgestützt sein
und die Rolle des Datenlieferers für einen Monitor übernehmen. Ziel dabei ist die
Überwachung und Beobachtung des Straßenverkehrs. In diesem Unterkapitel wird
auf die Architektur des Systems Simulator sowie seiner Funktionalitäten näher eingegangen.
84
6.2 Simulator
6.2.1
Architektur des Simulators
Wie im vorigen Abschnitt 6.1 erwähnt wurde, ist das Gesamtsystem nach der Anforderungserhebung in zwei Subsysteme unterteilt worden, die jeweils in Komponenten
für das GUI, den Controller und die Datenbank untergliedert werden können. Gemäß
dieser Unterteilung ist das Simulator-Subsystem in drei Paketen strukturiert, was
die Modularität des Systems verstärkt (s. Abbildung 6.2).
Abbildung 6.2: Architektur des Systems Simulator
Im Paket s db werden alle datenbankbezogenen Prozesse gekapselt. Die Klasse DBConnection sorgt für die Herstellung und das Schließen der Datenbankverbindung. In
dieser Klasse wird durch die als Singleton implementierte Methode getConnection()
sichergestellt, dass lediglich eine einzige Verbindung hergestellt wird. Das System soll
möglichst wiederverwendbar sein. Deshalb werden die Datenbankanfragen aus dem
Code in der Klasse DBAnfragen zusammengestellt. Dies erleichtert die Wartung des
Codes und unterstützt die Flexibilität des Systems. Stark benutzte und aufwändige
Anfragen werden aus Effizienzgründen in einer eigenen als Thread implementierten
Klasse InsertThread nebenläufig bearbeitet, um die weitere Abarbeitung des Codes
nicht zu beeinflussen.
Das Paket s gui enthält alle Klassen, die zum Aufbau und zur Gestaltung des GUIs
dienen. Darin enthalten sind insbesondere Objekte, die zusammen das GUI-Fenster
bilden. An dieser Stelle wird zwischen Objekten für benutzerseitige Editierungszwecke wie die Klasse Menu und simulationsrelevanten Objekten wie z.B. Zelle
unterschieden. Wie diese Objekte dargestellt werden und wie sie zusammenspielen,
85
6 ARCHITEKTUR UND FUNKTIONALITÄT
regelt die Klasse SIMMain. In dieser Klasse werden diese als Swing-Komponenten
implementierten Objekte miteinander gekoppelt, um ein benutzerfreundliches GUI
zu erstellen. Weiterhin wird in der Klasse SIMMain der Start der Simulation ausgelöst und damit der Simulator in Betrieb gesetzt.
Das Paket s sim hingegen fasst alle Klassen zusammen, die an den Simulationsvorgängen beteiligt sind. Die Routenauswahl erfolgt mithilfe einer XML-Datei, die
in der Klasse SkriptParse ausgelesen wird. Details hierzu werden im Abschnitt 7.1
besprochen. Die Klasse LSA stellt die Abbildung der Tabelle lsa auf Java-Ebene
dar. Die Steuerung dieser LSA-Objekte erfolgt durch die Klasse LSASimulation.
Nebenläufig werden die Fahrzeuge erzeugt und auf die Straßen gesetzt. Modelliert
werden diese Fahrzeuge durch die Klasse Fahrzeug.
Die Pakete fassen semantisch stark zusammenhängende Klassen zusammen. Dennoch herrscht zwischen den Paketen eine Kommunikation, die das Zusammenspiel
der Systemkomponenten widerspiegelt. Das Klassendiagramm in Abbildung 6.3 veranschaulicht einen Teil der Interaktion zwischen den verschiedenen Klassen aus unterschiedlichen Paketen. Die Klasse SIMMain steht zu Beginn der Simulation im
Abbildung 6.3: Simulator Klassendiagramm
Vordergrund, sie ist insbesondere für den Start der Simulation verantwortlich. Zum
einen setzt sie die Simulationsuhr und die Steuerung der LSAs in Betrieb. Zum
anderen initialisiert sie die Erzeugung der Fahrzeuge. Daher enthält sie ein Objekt der Klasse java.util.Timer zur periodischen Fahrzeugsgenerierung. Innerhalb
des s gui -Packages besteht eine Kompositionsbeziehung zwischen den Klassen Karte und Zelle. Dieser Zusammenhang bedeutet, dass eine Karte aus mehreren Zellen
gebildet wird und die Zellenexistenz von ihrer Existenz abhängt. Die Kopplung zwischen s sim und s gui entsteht hauptsächtlich durch die Beziehung zwischen der
Fahrzeugklasse und der Zellenklasse. Diese Abhängigkeit zeichnet sich dadurch aus,
dass auf den Zellen der neueste Zustand eines Fahrzeugs dargestellt wird.
86
Fahrzeug
F
Zelle
Z
6.2 Simulator
Reale Welt
DB
Java-Programm
Karte
K K’
Karte
K .. ..
Zelle
Z .. .. …
Fahrzeug
F
.. .. ….
GUI
..
K
Z
Zelle
Z Z’
Z’
..
F’
Fahrzeug
F
F’
F
..
Abbildung 6.4: Abbildung der Objekte
Die wesentlichen Java-Objekte haben ihre Entsprechung in der Datenbank. Abbildung 6.4 zeigt, wie die Objekte aus der realen Welt auf die verschiedenen Teile der
Systemkomponenten abgebildet werden. Jedes aus der realen Welt auf Java-Ebene
abstrahierte Objekt besitzt ein Gegenstück auf Datenbankebene. Die Java-Klasse
Knotenzelle beispielsweise entspricht der Tabelle Knotenzelle in der Datenbank. Die
Klasse Fahrzeug entspricht auf der Datenbankebene dem Entity-Typ Fahrzeug. In
diesem Sinne sind die Instanzen jeder Klasse als Datensätze in der entsprechenden
Tabelle zu sehen. Für die grafische Darstellung entsprechen solche Objekte ebenso
grafischen Objekten auf GUI-Ebene.
Die Objekte müssen auf allen vorgenannten Ebenen konsistente Zustände haben.
Deshalb spielt ihre Synchronisation eine zentrale Rolle. Diese Aufgabe wird vom
Controller übernommen, der das GUI auf den neuesten Stand bringt und gleichzeitig die Datenbank mit den aktuellen Daten füllt. Die Entsprechung dieser Objekte
auf den drei Ebenen Datenbank, Java und GUI gilt für ihren gesamten Lebenszyklus. Eine Ausnahme stellen die Fahrzeugobjekte auf Datenbankebene dar. Ihre
zugehörigen Datensätze bestehen zwar fortlaufend in der Datenbank, werden jedoch nur innerhalb der Überwachungszonen aktualisiert. Dies wird durch das Streben nach Effizienzsteigerung und Schutz der Privatsphäre motiviert. Die Fahrzeuge
existieren solange, bis sie das Simulationsgebiet verlassen haben. Angezeigt werden
allerdings nur diejenigen, die sich auf der vom Benutzer ausgewählten Karte bzw.
entsprechendem Kartenausschnitt befinden.
87
6 ARCHITEKTUR UND FUNKTIONALITÄT
6.2.2
Funktionalitäten des Simulators
Das Simulator-GUI bildet die Schnittstelle zwischen dem System und dem Benutzer.
Das GUI setzt sich aus einer Werkzeugleiste, einem Anzeigefenster und einer mit
dem Monitor geteilten Menüleiste zusammen.
Die Werkzeugleiste dient hauptächtlich der Kontrolle des Simulationsablaufs. Zur
Verfügung stehen auf der einen Seite verschiedene Schaltflächen, die den Start, die
Pause, die Wiederaufnahme und das saubere Beenden der Simulation bewirken. Ist
das SiMo“-System einmal gestartet, kann der Simulationsvorgang auf Wunsch des
”
Benutzers mithilfe der Pause“-Schaltfläche in einen Pause-Modus gebracht werden.
”
Dies ermöglicht eine genaue Betrachtung der Verkehrslage sowie die Beobachtung
spezieller Verkehrsphänomene wie z.B. Staus. Eine Simulationswiederaufnahme kann
durch die Wiederaufnahme“-Schaltfläche erreicht werden.
”
Abbildung 6.5: Werkzeugleiste
Auf der anderen Seite können sowohl die Verkehrsdichte als auch die Simulationsgeschwindigkeit manipuliert werden. Dafür sind zwei Schieberegler vorgesehen. Der
erste auf der linken Seite in Abbildung 6.5 bewirkt eine Änderung der Verkehrsdichte,
d.h. der Anzahl der Fahrzeuge auf einer Fläche zu einem gegebenen Zeitpunkt. Der
andere Schieberegler rechts modifiziert die zeitliche Abtastung, welche eine Auswirkung auf die Simulationsgeschwindigkeit hat. Je geringer der Wert ist, desto kürzer
ist die Zeitspanne zwischen zwei Simulationsschritten.
Der Simulator ist auch in der Lage, die Dichte des Verkehrs in Abhängigkeit von
der Ausführungszeit der Simulation anzupassen. Durch eine Auswahlliste kann der
Benutzer selbst das Zeitintervall, in dem die Simulation auszuführen ist, bestimmen. Dies verleiht der Simulation einen realistischeren Charakter. So werden zu
bestimmten Zeiten, z.B. im Fall von Berufsverkehr, mehr Fahrzeuge erzeugt, sodass
eine größere Dichte erreicht wird. Die Ausgabe der Simulationszeit erfolgt in einem
Textfeld, in dem der aktuelle Zustand der Simulationsuhr dem Benutzer mitgeteilt
wird.
Den größten Teil des GUIs bildet das Anzeigefenster, in dem unmittelbar nach dem
Start ein Straßenausschnitt aus dem Gebiet Bonn-Nord angezeigt wird. Die Kreuzungsbereiche, die für den Monitor besonders interessant sind, werden mit einem
hellen Farbton hervorgehoben, während die aktuell im Detail angezeigte Kreuzung
des Monitors gelb markiert wird. Rot gekennzeichnet werden Zufahrten, auf denen
die Ampel gerade auf Rot geschaltet ist.
88
6.2 Simulator
Abbildung 6.6: Übersichtskarte
Für den großen Simulationsraum ist es schwierig, die Fahrzeuge und die Zellen gut zu
erkennen. Deswegen ist es notwendig, lokale Ansichten zu ermöglichen. Dies bedeutet, dass die erste Karte, die nach dem Starten zu sehen ist, als Übersichtskarte dient
(siehe Abbildung 6.6). Sie ist in mehrere Teilkarten unterteilt, die die Beobachtung
der Fahrzeuge auf einer lokalen Ebene möglich machen. Abbildung 6.7 stellt einen
lokalen Ausschnitt des Simulationsgebiets dar. Die Zellen auf der Übersichtskarte
reagieren auf einen Mausklick. Sobald auf eine Zelle geklickt wird, erfolgt ein Wechsel von der Übersichtskarte zum zugehörigen lokalen Ausschnitt. Ein Klick auf eine
Kreuzung auf der lokalen Karte lässt wiederum diese auf der Detail-Ansicht des
Monitors erscheinen. Um wieder auf die Übersichtskarte zu gelangen, steht eine
Schaltfläche in der Werkzeugleiste zur Verfügung (Abbildung 6.5).
89
6 ARCHITEKTUR UND FUNKTIONALITÄT
Beachtung von
Verkehrsregeln
ausschalten
Abbildung 6.7: Lokaler Ausschnitt
Um die Auswirkung von Regelverstößen erkennbar zu machen und für den Testbetrieb häufiger zu produzieren, steht ein Menü zum Ausschalten der Beachtung von
Verkehrsregeln zur Verfügung. So lassen sich die Verkehrsregeln zu Vorfahrtbeachtung, Setzen des Blinkers und Beachtung von Ampeln ausschalten (siehe Abbildung
6.7).
6.2.3
Strukturierung der statischen Komponenten
Bei Multiagentensimulationen als Verfeinerung der diskreten Ereignissimulation werden hauptsächtlich dynamische Systeme modelliert und nachgebildet. Diese Systeme
können jedoch statische Komponenten beeinhalten, welche während der gesamten
Simulation unverändert bleiben. Die Simulation baut jedoch auf diesen statischen
Komponenten auf, sodass sie einen wichtigen Bestandteil des Simulationsprozesses
darstellen. Unter den statischen Komponenten fallen Verkehrsschilder, Ampeln sowie topologische Bestandteile des Simulationsgebiets.
Die Topologie beschreibt das Straßennetz des Simulationsraums. Das Straßennetz
besteht aus Straßen, die sich in Straßenknoten schneiden können, und ist als Graph
90
6.2 Simulator
sich vorzustellen. Dieser Arbeit liegt eine diskrete Ereignissimulation zugrunde. Deshalb wurde der Raum diskretisiert, indem die Straßen in Zellen unterteilt wurden.
Diese Unterteilung erfolgte nach der in Unterkapitel 4.2 eingeführten Theorie der
zellularen Automaten. Gemäß des Datenbankentwurfs sind diese Zellen relational
auf Datenbankebene abgebildet. Der Darstellung dieser Topologie kommt u.a. eine
Java-Objekt Karte zu Nutze, auf der die Straßenkomponenten abgebildet werden.
Das Simulationsgebiet ist wie erwähnt so groß, dass man es nur schwer bzw. unmöglich
mit allen Details auf dem Monitor ansehen kann. Daher sind zwei Typen von Karten
vorgesehen. Abbildung 6.8 zeigt die Typisierung der Kartenobjekte.
Abbildung 6.8: Karten-Arten
Der Obertyp Karte kann in zwei Kategorien untergliedert werden. Zum einen repräsentiert die Unterklasse Uebersicht die Karte, die das Gesamtgebiet darstellt.
Zum anderen dient die Unterklasse Ausschnitt dazu, dass ausgewählte Räume näher
angeschaut und beobachtet werden können. Die beiden Typen unterscheiden sich
dadurch, dass bei einer Übersichtskarte alle Zellen dargestellt werden, die zum Simulationsgebiet gehören. Bei den Ausschnittkarten hingegen ist der darzustellende
Raum begrenzt und wird durch maximale und minimale Koordinatenangaben definiert.
Abbildung 6.9: Zellen Klassendiagramm
Getreu dem Datenbankentwurf existiert auf Java-Ebene ein Objekt Zelle und stellen
die Bausteine einer Karte dar. Diese Zellenobjekte sind wiederum aus semantischen
Gründen in vier Arten unterteilt. Diese Unterteilung veranschaulicht Abbildung 6.9.
Die Zellenarten weichen semantisch leicht voneinander ab. Daher werden die gemeinsamen Eigenschaften vom Obertyp Zelle vererbt, während die typspezifischen Eigenschaften in den Untertypen gekapselt werden. Die vier hier eingeführten Klassen
sollen die in Abschnitt 5.2.1 vorgestellten Zellentypen modellieren.
91
6 ARCHITEKTUR UND FUNKTIONALITÄT
6.2.4
Strukturierung der dynamischen Komponenten
Wurden die statischen Komponenten einmal generiert, stehen die dynamischen im
Mittelpunkt des Geschehens. Als dynamisch werden solche Komponenten bezeichnet, die ihren Zustand im Laufe der Zeit verändern. Unter solchen Objekten, die für
den hier realisierten Simulator relevant sind, fallen auf der einen Seite die Fahrzeuge, die ihre Positionen im Laufe der Zeit verändern. Auf der anderen Seite ist die
Steuerung der LSAs als dynamischer Prozess zu sehen.
Abbildung 6.10: Aktivitäten im Simulationsvorgang
Das Aktivitätsdiagramm in Abbildung 6.10 veranschaulicht die wesentlichen Aktivitäten beim Simulationsvorgang der dynamischen Objekte. Das Drücken des StartKnopfs bewirkt den Start der Simulation. Dies hat zur Folge, dass drei nebenläufige
Threads gestartet werden. Der erste Thread betreibt die Simulationsuhr, die das
Fortschreiten der Simulationszeit bewirkt. Der zweite Thread übernimmt die nebenläufige Steuerung der Lichtsignalanlagen. Der letzte Thread hat die Generierung
92
6.2 Simulator
der Fahrzeuge zur Aufgabe. Eine Zustandsveränderung, sowohl bei den LSAs als
auch bei den Fahrzeugen, führt zur Aktualisierung des GUIs. Solange die Stopp“”
Schaltfläche nicht gedrückt wird, läuft die Simulation weiter. Der Simulationsprozess
kann aber in einen Pausenzustand gesetzt und dann zur Wiederaufnahme gebracht
werden.
Die Fahrzeuge sind autonome in ein Multiagentensystem eingebettete Agenten, die
mittels Informationsaustausch mit ihrer Umwelt Handlungen vornehmen können.
Die Fahrzeuge reagieren beispielsweise unterschiedlich auf Ampelzustände: Sie halten bei Rot an und fahren bei Grün weiter. Sie sind in der Lage, einen gewissen
Abstand zum Vordermann halten zu können. Abhängig von seiner Absicht kann das
Fahrzeug eigene Entscheidungen treffen wie beispielsweise einen Spurwechsel durchzuführen.
Da die Simulation im Rahmen dieser Arbeit nicht unbedingt für die Verkehrsplanung, sondern eher für Monitoring-Zwecke vorgesehen ist, wurden die Fahrzeuge in
verschiedene Typen unterteilt. Es bestehen verschiedene Fahrerprofile, die die unterschiedlichen menschlichen Fahrverhalten modellieren. Dies stärkt zusätzlich die
Erweiterbarkeit und Flexibilität der Arbeit. Das bedeutet, dass die Fahrertypen
leicht und mit wenig Aufwand um andere Fahrer ergänzt werden können. Abbildung 6.11 zeigt die vom Simulator erzeugten unterschiedlichen Fahrzeugtypen.
Abbildung 6.11: Fahrzeugklassen
Wie erwähnt charakterisieren die Fahrertypen verschiedene Fahrverhalten. Sie verfügen zwar über viele Gemeinsamkeiten, die in der Klasse Fahrzeug wiederzufinden
sind. Abhängig von den Absichten eines Typs werden jedoch zusätzliche Funktionalitäten geleistet. Die Fahrzeug-Instanzen der Klasse FahrzeugBlinker zeichnen sich dadurch aus, dass sie keinen Blinker setzen. Die Fahrer, die über die
rote Ampel fahren, sind durch die Klasse FahrzeugAmpel vertreten. Die Klasse
FahrzeugVorfahrt hingegen charakterisiert die Fahrer-Kategorie, die die Vorfahrtregelung missachtet. Eine andere modellierungswürdige Sorte von Fahrern sind solche,
die gegen die vorgeschriebene Fahrtrichtung fahren. Diese werden durch die Klasse FahrzeugFalschAbbieger repräsentiert. Andere Sorten von Fahrern sind natürlich
denkbar, würden aber den Rahmen der Arbeit sprengen. So könnten z.B. auch Unfallverursacher modelliert werden.
93
6 ARCHITEKTUR UND FUNKTIONALITÄT
6.3
Monitor
Die Anforderungserhebung in Abschnitt 5.1.2 ergab bereits konkrete funktionale
Anforderungen, an denen sich die Entwicklung des Systems orientiert. Die folgenden
Abschnitte beschreiben zunächst die Funktionaliäten des Monitor-Teilsystems, um
darauf aufbauend die Modellierung der Objekte sowie die interne Architektur zu
erläutern.
6.3.1
Funktionalitäten des Monitors
Das Monitor-Teisystem ist neben der Überwachung von Verkehrsszenarien für die
detaillierte Darstellung einer Kreuzung oder Einmündung auf dem GUI zuständig.
Dafür bietet es vier verschiedene Ansichten, welche mit Registerkarten organisiert
sind und deren Funktionalitäten im Folgenden näher erläutert werden sollen:
• Design-Ansicht
• Simulate-Ansicht
• Detail-Ansicht
• Logging-Ansicht
Sie ermöglichen dem Benutzer die Interaktion mit dem System, um auf den Prozess
des Monitorings Einfluss nehmen zu können. Bei der Entwicklung wurde ein besonderes Augenmerk auf die Benutzerfreundlichkeit gerichtet.
Alle Ansichten haben denselben Aufbau und teilen sich in eine Werkzeugleiste sowie
einen Anzeigebereich für die Visualisierung eines überwachten Knotens auf. Im Gegensatz zum GUI des Simulators werden hier die Eigenschaften im Detail dargestellt.
Für den Benutzer sichtbar sind zum einen die statischen Objekte wie beispielsweise
Verkehrszeichen und Signalgeber. Zum anderen lassen sich die Zustände der Signalgeber und Fahrzeuge erkennen. Fahrtrichtung, Blinker sowie ID der einzelnen
Fahrzeuge werden augenscheinlich. Dem Benutzer stehen im Detail alle im Simulationsgebiet verfügbaren Überwachungsbereiche zur Verfügung. Der aktuell angezeigte
Knoten lässt sich über eine Auswahlliste oder aber durch Navigation im Anzeigefenster des Simulators wechseln.
Die Lage der Zellen, aus denen das gesamte Straßennetz aufgebaut ist, ist bereits
vor dem Einsatz des SiMo“-Systems in der Datenbank zu erfassen (vgl. Abschnitt
”
5.2.2). Im Gegensatz zu der relativ statischen Topologie der Straßen, kommt es in
der Realität häufiger vor, dass Verkehrszeichen oder Lichtsignalanlagen aufgebaut,
verändert oder aber wieder entfernt werden. Um die Zuordnung von Verkehrszeichen und Lichtsignalanlagen visuell zu unterstützen, bietet die Design-Ansicht
die Möglichkeit, Signalgeber sowie Verkehrszeichen über ein Popup-Menü zuzuordnen (siehe Abbildung 6.12). Die Verkehrszeichen unterteilen sich in vorfahrtregelnde
Zeichen und Verkehrszeichen zu vorgeschriebener Fahrtrichtung. Für diese drei Kategorien erscheinen für jede Knotenzufahrt drei graue Felder, die jeweils als Platzhalter
für Ampeln, Vorfahrtzeichen und Fahrtrichtungszeichen dienen.
94
6.3 Monitor
Abbildung 6.12: Design-Ansicht
Zentrales Simulationskonzept zur Steuerung von Signalgebern ist die Aufteilung
der Signalisierungszustände in Phasen. Bei Auswahl mindestens eines Signalgebers
können der dadurch entstehenden Lichtsignalanlage die Eigenschaften der Phasenschaltung zugeordnet werden. Das zugehörige Dialogfeld wird mithilfe der Schaltfläche Phasen definieren“ sichtbar (siehe Abbildung 6.13). Nach Auswahl der Pha”
senanzahl kann die Dauer jeder einzelnen Phase in Sekunden festgelegt werden. Für
jeden Signalgeber werden weiterhin entsprechend der Phasenanzahl farbliche Kreise
angezeigt, die symbolisch für die Signalfarbe in den einzelnen Phasen stehen sollen.
95
6 ARCHITEKTUR UND FUNKTIONALITÄT
Abbildung 6.13: Phasen definieren (Design Modus)
Ein Klick auf einen Kreis ändert die Farbfolge. In der Werkzeugleiste des Design Modus dient schließlich eine Schaltfläche zum Speichern aller Einstellungen (vgl. Abbildung 6.14). Die Datenbank wird hinsichtlich der Zeichenzuordnung und der Positionierung der Signalgeber mit der Phasenschaltung der LSA aktualisiert. Änderungen
haben unmittelbar Auswirkung auf alle anderen Ansichten und Funktionalitäten des
Systems.
Löschen
Stopp
Abspielen
Schritt
vor
Schritt
zurück
Abbildung 6.14: Allgemeine Schaltflächen des Monitors
Um im Testbetrieb eine Unabhängigkeit des Monitors vom Simulator zu erreichen,
bietet die Simulate-Ansicht die Möglichkeit, eigene Szenarien auf einer ausgewählten Kreuzung zu erstellen (siehe Abbildung 6.15). Diese können genauso auf
Regelverstöße untersucht werden wie die komplexeren Verkehrsszenarien des Simulators. Simuliert werden können sowohl die Bewegung von Fahrzeugen als auch die
Schaltung von Signalgebern. Die Werkzeugleiste enthält neben der Auswahlliste für
die Kreuzung eine zweite Auswahlliste, die anzeigt, um welches Szenario es sich handelt. Sie listet alle in der Datenbank vorhandenen Szenarien auf und bietet zudem die
Möglichkeit, mit der Auswahl Neues Szenario“ eine neue Verkehrssituation zu er”
stellen. Das Textfeld Zeit“ zeigt den aktuellen Simulationsschritt an, welcher durch
”
die daneben gelegenen Schaltflächen Schritt vor“ und Schritt zurück“ modifiziert
”
”
werden kann. Um einem Simulationsschritt den Signalisierungszustand existierender
Signalgeber zuordnen zu können, enthält die Werkzeugleiste die Auswahlliste für die
aktuell gewünschte Phase der Lichtsignalanlage.
Fahrzeuge können gesetzt werden, indem auf die entsprechende Zelle der Kreuzung
geklickt wird und die gewünschten Eigenschaften des Fahrzeugs im erscheinenden
Popup-Menü ausgewählt werden. Sie können sich in Farbe, Fahrtrichtungsanzeiger
und Fahrtrichtung unterscheiden:
Autofarbe
• blau
• grün
• rot
Fahrtrichtungsanzeiger
• geradeaus
• Linksabbieger
• Rechtsabbieger
96
Fahrtrichtung
• Nord
• Ost
• Süd
• West
6.3 Monitor
Abbildung 6.15: Simulate-Ansicht
Dabei wird ein Fahrzeug durch seine Farbe eindeutig identifiziert, sodass in jedem
Simulationsschritt jede Farbe höchstens einmal verwendbar ist. Das Setzen eines
Blinkers und die Fahrtrichtung des Fahrzeugs auf einer Zelle sollen hierbei in keiner
Weise eingeschränkt werden. Dies soll das Konstruieren von fehlerhaftem Verhalten
ermöglichen.
Die Schaltflächen Schritt vor“ und Schritt zurück“ ermöglichen das Zuordnen der
”
”
Fahrzeuge zu den jeweiligen Zeitschritten. Zu einer besseren Orientierung werden in
aufgehellten Farben zusätzlich die Fahrzeuge des vorhergehenden Schrittes dargestellt. Über die Schaltfläche Vorheriges Fahrzeug andeuten“ (siehe Abbildung 6.16)
”
kann diese Option aus- oder eingeschaltet werden. Ein gespeichertes Szenario steht
in der Detail-Ansicht zur Auswahl, sobald es in der Simulate-Ansicht abgespeichert
wurde.
Abbildung 6.16: Schaltfläche Vorheriges Fahrzeug andeuten“ (Simulate-Ansicht)
”
97
6 ARCHITEKTUR UND FUNKTIONALITÄT
Eine der zentralen Benutzeroberflächen des Systems ist die Detail-Ansicht. Hier
wird der aktuelle Verkehr auf Kreuzungsebene dargestellt, während zeitgleich das
Monitoring zur Beobachtung des Verkehrs abläuft. Da die Detail-Ansicht thematisch
eng mit der Übersichtskarte des Simulators zusammenhängt, teilen sich diese beiden Ansichten ein Fenster. Im Gegensatz zur Übersichtkarte werden hier Details der
simulierten Verkehrsszenarien sichtbar. Eine benutzerdefinierte Entscheidung liegt
in der Auswahl der Datenquelle, die der Visualisierung und dem Monitoring in der
Detail-Ansicht zugrunde liegen soll. Die Daten zu Fahrzeugen und LSAs können
entweder vom Simulator oder von einem zuvor vom Benutzer zusammengestellten
Szenario geliefert werden.
Abbildung 6.17: Schaltfläche Regelverstöße anzeigen“ (Detail-Ansicht)
”
Das Drücken der Start“-Schaltfläche bewirkt, dass die von der Simulation gelie”
ferten Fahrzeug-Bewegungen und Ampelschaltungen auf der aktuell ausgewählten
Kreuzung angezeigt werden. Weiterhin wird begonnen, den Verkehr im Hinblick auf
Regelverstöße zu beobachten. Wurde ein Regelverstoß auf der angezeigten Kreuzung erkannt, wird er dem Benutzer in einem Dialogfeld gemeldet und gleichzeitig
das betroffene Fahrzeug mit roter Farbe unterlegt. Wird das Anzeigen der Regelverstöße als störend empfunden oder nicht benötigt, kann der Dialog mit einem Klick
auf die Schaltfläche Regelverstöße anzeigen“ ein- und ausgeblendet werden (siehe
”
Abbildung 6.17). Das Menü Monitor in der Menüleiste des SiMo“-Systems bietet
”
zudem die Option, die Überwachung von Regelverstößen ein- und auszuschalten. Die
Aktionen der Detail-Ansicht werden abgebrochen, sobald die Schaltfläche Stopp“
”
gedrückt wird.
Jeder Regelverstoß, der vom Monitor erkannt wurde, ist in der Datenbank hinterlegt.
Ein genaueres Betrachten dieser Verkehrsszenarien ist wünschenswert und daher in
der Logging-Ansicht möglich. Hier werden alle geloggten Regelverstöße aufgelistet,
um im Nachhinein nochmals abrufbar zu sein. Im Testbetrieb des Systems ermöglicht
dies eine kritische Validierung geloggter Verkehrsszenarien, im späteren Einsatz des
Systems könnte dies eine Grundlage für die Ergreifung gezielter Maßnahmen sein.
Der angegebene Verweis auf den Paragraphen stellt diejenige Textstelle dar, auf die
sich die Anfragen stützen. Je nach Ausprägung des Regelverstoßes könnte jedoch ein
anderes Gesetz für den tatsächlichen Tatbestand herangezogen werden. Aus dem geloggten Regelverstoß lassen sich daher noch keine Auswirkungen hinsichtlich einer
Strafe ableiten, da dies oftmals davon abhängt, ob gegen die Verkehrsregel z.B. mit
Behinderung oder mit Gefährdung anderer verstoßen wurde. Diejenigen Fahrzeuge,
die eine Ordnungswidrigkeit begangen haben, werden rot unterlegt dargestellt.
Die Ansicht bietet zur Betrachtung der einzelnen Regelverstöße verschiedene Funktionalitäten (vgl. Abbildung 6.14). Das Abspielen eines ausgewählten Regelverstoßes
kann mit den entsprechenden Schaltflächen gestartet und gestoppt werden. Um die
98
6.3 Monitor
Fahrzeugkonstellationen im Detail betrachten zu können, stehen zwei Schaltfächen
zur Verfügung, die das Regelverstoß-Szenario einen Schritt vor oder zurück bewegen.
Nicht mehr benötigte Regelverstöße können durch die Schaltfläche Löschen“ aus
”
der Datenbank und somit aus der Auswahlliste entfernt werden.
6.3.2
Objektdesign für das GUI
Die Phase des Objektdesigns verbindet den konzeptuellen Entwurf aus Kapitel 5
mit der Implementierung. So können mithilfe von Klassendiagrammen bereits zuvor
konkrete Entscheidungen getroffen werden, die eine grobe Struktur für die Implementierung festlegen. Je früher die Implementierung durch solche Vorüberlegungen
geleitet wird, desto weniger besteht später der Bedarf an einer Umstrukturierung
des Codes. Weiterhin ermöglicht eine genaue Auseinandersetzung mit den Objekten
eine bestmögliche objektorientierte Umsetzung. Entwickelte Klassendiagramme sind
dann automatisierbar in Java-Code umsetzbar.
Die Implementierung des Monitor-Teilsystems baut insbesondere auf der Implementierung des GUIs auf. Die Komplexität der Überwachung von Straßenverkehrsszenarien spiegelt sich stattdessen vielmehr auf Datenbankebene wider (siehe Abschnitt
7.2) und beeinflusst die Struktur der Klassen nur in geringem Ausmaß. Im Folgenden
wird daher auf die getroffenen Design-Entscheidungen des GUIs eingegangen.
Abbildung 6.18: Ansichten des Systems
Abbildung 6.18 zeigt die benötigten Klassen für die verschiedenen Ansichten des
Systems, die sich aus den Use Cases des Monitors ableiten lassen (vgl. Abschnitt
5.1.2). Die verschiedenen Ansichten des Systems im Anzeige-Fenster werden durch
Registerkarten organisiert. Um dynamisch einen für den Benutzer sichtbaren Namen
vergeben zu können, besitzen die Klassen eine Variable tab name für die entsprechende Registerkarte. Somit schreibt die abstrakte Klasse View, welche alle Ansichten
implementieren müssen, diese Eigenschaft vor. Statisch festgelegte Variablen machen
die Implementation flexibel, indem eine Umentscheidung lediglich das Modifizieren
einer einzigen Variable erfordert.
Weiterhin lässt sich feststellen, dass die vier Ansichten des Monitor-Teilsystems eine
gemeinsame Grundstruktur haben: Alle stellen einen beobachteten Straßenbezirk
im Kreuzungsbereich dar. Teilt man die Benutzeroberfläche in Werkeugleiste und
99
6 ARCHITEKTUR UND FUNKTIONALITÄT
Straßenkarte, so unterscheiden sie sich hauptsächlich durch die Funktionalitäten
in der Werkzeugleiste, während der grafische Aufbau der Karte stets in denselben
Schritten abläuft.
Abbildung 6.19: Komponenten der Karten
Daher liegt in diesem Fall eine Umsetzung durch eine Vererbungshierarchie nahe,
welche in Abbildung 6.18 modelliert wurde. Somit erhält die bereits erwähnte Klasse
View eine ebenfalls als abstrakt markierte Unterklasse Crossing, welche alle Funktionalitäten zur Verfügung stellt, die in den verschiedenen Kreuzungsansichten gleichermaßen benötigt werden. So kann sowohl die Straßentopologie mit Zellen und
Verkehrszeichen als auch eine Auswahlliste für Kreuzungen in der Oberklasse implementiert werden. Die Unterklassen View Design, View Simulate, View Detail und
View Logging erben den Grundaufbau der GUI und passen sie an ihre Anforderungen an.
Die Detail-Ansicht zum Beobachten des Verkehrs steht jedoch nicht einzeln als
Ansicht zur Verfügung. Stattdessen ist sie gekoppelt mit der Übersichtskarte des
Simulator-Teilsystems. Die Klasse View Overview Detail stellt, ebenfalls die abstrakte Klasse View erweiternd, diese gemeinsame Ansicht dar. Erwähnt sei hierbei,
dass bei der Implementierung strikt auf Modularität geachtet wurde, sodass die in
ein JPanel eingebettete Übersichtskarte des Simulators in dieser Zusammenstellung
völlig unabhängig von den anderen Ansichten implementiert werden kann.
Die einzelnen Kreuzungen werden wiederum aus verschiedenen Swing-Komponenten
aufgebaut (siehe Abbildung 6.19). Jedes Element des Überwachungsbereichs wird
durch eine eigene Klasse repräsentiert. Um die Benutzung der Komponenten im
Code vom konkreten Objekt lösen zu können und damit das Konzept der Polymorphie umzusetzen, wird auch hier eine abstrakte Klasse als Oberklasse eingesetzt.
Die Klasse MapComponent stellt sicher, dass alle sie implementierenden Klassen
eine Methode zum Aktualisieren der Ansicht (refresh()) und eine Methode zum
Speichern der Einstellungen (save()) zur Verfügung stellen.
100
6.3 Monitor
Wesentliche Komponenten der Karte sind die Zeichen und Zellen. Die Klasse Zeichen
stellt hierbei die Oberklasse von Signalgeber, Fahrtrichtungszeichen und Vorfahrtzeichen dar. Zellen enthalten weiterhin ein Fahrzeug, was durch die KompositionsBeziehung verdeutlicht wird. Diese Modellierung nimmt an, dass ein Fahrzeug durch
verschiedene Instanzen der Klasse Fahrzeug den Zellen zugeordnet werden kann. Sie
repräsentieren also mehr die augenblickliche Darstellung eines Fahrzeugs auf einer
bestimmten Zelle als das Fahrzeug an sich, sodass sie abhängig von der Existenz
einer Zelle sind.
Die objektorientierte Implementierung lässt es nun zu, dass die Instanzen der Kartenkomponenten bei Methodenaufrufen nicht hinsichtlich der Klasszugehörigkeit differenziert werden müssen. Stattdessen ist ein Aktualisieren der Kartenansicht in der
Klasse Crossing durch Iterieren über die Kartenkomponenten mit ein und demselben Funktionsaufruf refresh() möglich. Zur Laufzeit wird entschieden, welcher
Klasse sich die Komponente tatsächlich zuordnen lässt. So können Signalgeber ihr
Signalbild ändern, währenddessen Zellen in ihrer refresh()-Methode ein Fahrzeug
darstellen. Das Speichern, welches in der Design- und Simulate-Ansicht erforderlich
ist, kann analog umgesetzt werden, um das Konzept des Dynamic Bindings auszunutzen.
Mit diesem Objektdesign steht bereits eine grobe Richtlinie für die Implementierung des Systems zur Verfügung, die im weiteren Verlauf der Entwicklung verfeinert
und strukturiert wird.
6.3.3
Architektur des Monitors
Der Controller des Monitor-Teilsystems steht sowohl mit der Datenbank als auch
mit dem GUI in Beziehung. Weiterhin sind verschiedene Hilfsklassen notwendig. Das
Teilsystem unterteilt sich daher in drei Komponenten. Die zugehörigen Java-Klassen
sind thematisch den in Abbildung 6.20 dargestellten Paketen zugeordnet:
• m gui
• m db
• m obj
Das Paket m gui fasst die Klassen zusammen, die für die Darstellung der grafischen
Benutzeroberfläche benötigt werden. Der Einstieg des Java-Programms liegt in der
Klasse Start, welche die main()-Methode enthält. Hier liegt die zentrale Steuerung
der Benutzeroberfläche. Es werden die verschiedenen Ansichten integriert, globale
für das gesamte System geltende Werte festgelegt und ein Wechsel der Registerkarten ermöglicht.
Wie bereits erwähnt, repräsentiert die abstrakte Klasse View die verfügbaren Ansichten des Systems (vgl. Abschnitt 6.3.2) und ist für die Darstellung eines Straßenausschnitts zuständig. Daher beinhaltet das Paket m gui weiterhin eine Reihe von
Klassen, die Bestandteile der Karte sind und der abstrakten Klasse MapComponent
101
6 ARCHITEKTUR UND FUNKTIONALITÄT
!
"
Abbildung 6.20: Organisation der Java-Klassen
untergeordnet sind. Wird in einer der Kreuzungsansichten die Simulation gestartet, so wird die Klasse GUI Update beauftragt, die GUI der Zeit entsprechend dem
aktuellen Zustand anzupassen. Diese als Thread implementierte Klasse steuert das
Anzeigen der bereits in der Datenbank hinterlegten Simulationen auf Kreuzungsebene.
Eine weitere Komponente des Systems ist das Paket m db, deren Klassen die Kommunikation mit der Datenbank kapseln. Das Paket umfasst zum einen die Klasse
Connection Manager, welche für den Auf- und Abbau einer Verbindung zur Datenbank zuständig ist. Sie ist als Singleton implementiert und stellt damit eine einzige
Instanz der Klasse und folglich ein einziges Connection-Objekt bereit, auf welches
aus allen Klassen mit der statischen Getter-Methode getCon() zugegriffen werden
kann. Dies hat den Vorteil, dass die Datenbank-Verbindung nicht bei jeder Anfrage aufs Neue aufgebaut werden muss, sondern stattdessen in einer Variablen
zur Verfügung steht. Sofern noch keine Verbindung zur Datenbank besteht, d.h.
con == null, wird mithilfe der Singleton-Methode connect() die Verbindung zur
Access-Datenbank aufgebaut:
public static Connection getCon()
{
if (con == null) connect();
return con;
}
Weiterhin bietet die Klasse eine Methode clean up data(), welche das Löschen von
nicht mehr benötigten Daten zum Beispiel nach dem Schließen der Anwendung
bündelt.
102
6.3 Monitor
Die Klasse DB Queries kapselt in meist parametrisierten Methoden die Anfragen,
die in den verschiedenen Java-Klassen benötigt werden. Dies hat zum Vorteil, dass
die Datenbank-Realisierung von der Implementierung der GUI getrennt wird. Mehrfach genutzte Anfragen existieren nur einmal und Änderungen, die zum Beispiel
aufgrund von Design-Entscheidungen in der Datenbank notwendig werden, müssen
nur auf diesen Strings vollzogen werden. Idealerweise würde diese Aufgabe der Kapselung das DBMS selbst tragen, jedoch bietet MS Access nicht die Möglichkeit,
parametrisierte SQL-Anfragen oder Stored Procedures für den JDBC-Zugriff zu definieren.
Der Kern des Monitor-Teilsystems liegt in der Thread-Klasse DB Check. Sie steuert die Überwachung des Straßenverkehrs und enthält die deskripte Beschreibung
der Regelverstöße in Form von SQL-Anfragen. Für jeden zu beobachtenden Regelverstoß existiert eine Instanz dieser Klasse. Wird ein Regelverstoß erkannt, kommt
die Klasse DB Logging zum Einsatz. Sie ist für die Speicherung der Fahrzeug- und
LSA-Zustände zuständig, die den Regelverstoß charakterisieren und später in der
Logging-Ansicht zur Verfügung stehen sollen. Für das Überprüfen selbst erstellter
Szenarien ersetzt die Klasse CopySim den Simulator und kopiert die zugehörigen
Datensätze Schritt für Schritt in die Tabelle sm fahrzeug, auf der die Abfragen des
Monitors ausgewertet werden.
Die Ansichten auf Kreuzungsebene stellen dem Benutzer eine Reihe von Auswahllisten zur Verfügung, deren Einträge Objekte aus der Datenbank repräsentieren.
Das Paket m obj fasst daher die Klassen Knoten, Szenario und Regelverstoss zusammen. Sie haben zwar keine direkte Verbindung zur Datenbank, stellen jedoch
der GUI nach einmaliger Initialisierung die Attributwerte aus den Relationen zur
Verfügung.
6.3.4
Organisation der Monitoraktivitäten
Die Aufgaben des Monitors in der Detail-Ansicht teilen sich in zwei Aufgabenbereiche, dessen Aktivitäten simultan und in Echtzeit auszuführen sind: Die Darstellung
eines Straßenknotens sowie das Monitoring von Regelverstößen. Abbildung 6.21 zeigt
die Arbeitsweise des Monitors in einem Aktivitätsdiagramm. Die Prozesse beginnen,
sobald die Start“-Schaltfläche in der Werkzeugleiste der Detail-Ansicht gedrückt
”
wird. Zum einen wird daraufhin fortlaufend das Verkehrsgeschehen eines Knotens
auf dem GUI angezeigt. Aktualisiert wird die Ansicht, sobald ein Fahrzeug auf der
angezeigten Kreuzung seine Position wechselt oder die Lichtsignalanlage ihren Zustand ändert. Zum anderen werden nebenläufig die in der Datenbank vorhandenen
Fahrzeuge auf einen möglichen Regelverstoß überprüft, sofern die Option Monitor
”
an“ über das Menü eingeschaltet wurde.
Für das datenbankgestützte Monitoring werden zunächst die zuständigen Threads
initialisiert. Dies geschieht dynamisch durch Erzeugung von Instanzen der ThreadKlasse DB Check, welche von den in der Tabelle m regelverstoss kat gespeicherten Regelverstoßkategorien abhängt. Durch ein dynamisches Initialisieren bleibt das
103
6 ARCHITEKTUR UND FUNKTIONALITÄT
!"
#
%
"
&'
$
!
#
!
#
!
#
!
#
!
#
Abbildung 6.21: Arbeitsablauf des Monitors
Monitoring flexibel gegenüber Erweiterungen hinsichtlich Regelverstoßkategorien.
Das folgende Stück Code zeigt das Initialisieren der Monitor-Threads:
Statement st = Connection_Manager.getCon().createStatement();
String query = DB_Queries.lst_regelverstoss_kat();
ResultSet rs = st.executeQuery(query);
while(rs.next())
{
DB_Check r = new DB_Check(rs.getInt("regelverstoss_kat_id"),
rs.getString("stvo_ref"),rs.getString("beschreibung"));
r.start();
}
Connection_Manager.clean_up(rs, st);
Die Regelverstöße sind nach den Verkehrsregeln der StVO klassifiziert, sodass sich
jede Sicht einem konkreten Paragraphen zuordnen lässt. Die Kapselung der Regelverstöße in eine eigene Thread-Klasse versucht eine möglichst gleichzeitige Überwachung des Straßenverkehrs zu simulieren. Die im Konstruktor übergebene ID einer
Regelverstoßkategorie entscheidet über die Art der Abfrage, die auf den Tabellen
ausgeführt werden sollen.
104
6.3 Monitor
Die run()-Methode der Klasse DB Check organisiert jeweils das fortlaufende Überprüfen der Daten für jede Regelverstoßkategorie. Zunächst werden stets irrelevante
Daten gelöscht, um die Tabellen, auf denen die Kontrollsichten basieren, möglichst
klein zu halten. Anschließend wird eine SQL-Anfrage zum entsprechenden Regelverstoß ausgeführt. Wird ein Regelverstoß erkannt, so wird dieser dem Benutzer in
einem Dialogfeld gemeldet. Direkt im Anschluss wird ein Thread gestartet, der allein
für das Loggen der Daten, welche den Regelverstoß charakterisieren, verantwortlich
ist. Währenddessen wird der Kontrollfluss an anderer Stelle mit dem Monitoring
fortgesetzt. Wurde zwischenzeitlich die Stopp“-Schaltfläche gedrückt, so wird so”
wohl das Monitoring als auch das Anzeigen der Fahrzeuge abgebrochen. Andernfalls
können der Monitorprozess sowie das Aktualisieren von Fahrzeugen und LSAs weiter
ausgeführt werden. Näheres zu den SQL-Kontrollsichten wird in Abschnitt 7.2.1 beschrieben, das Logging-Konzept für erkannte Regelverstöße wird in Abschnitt 7.2.2
vorgestellt.
Die Aktualisierung des GUIs wird durch die Klasse GUI Update geleitet. Die Art und
Weise der Aktionen zum Abfragen der aktuellen Datenbankzustände ist abhängig
von der Ansicht, die dem Benutzer angezeigt wird. Im Wesentlichen besteht der Ablauf aus einer for-Schleife, worin die Methode refresh view() der jeweiligen Ansicht
aufgerufen wird. Das folgende repräsentative Code-Fragment zeigt hier den Ablauf
für die Detail-Ansicht, sofern ein vom Benutzer erstelltes Szenario als Datenquelle
ausgewählt wurde.
int max = getMaxZeit();
for(int i = 1; i<= max && !stop_detail; i++)
{
View_Detail.setZeit(i);
View_Detail.getView_detail().refresh_view();
try{
Thread.sleep(Settings.getSleep_time_ms());
}catch (InterruptedException e) {
e.printStackTrace();
}
}
Mithilfe der for-Schleife werden die diskreten Zeitschritte durchlaufen und zur Erneuerung der GUI eine Nachricht an die Klasse View Detail gesendet. Damit wird
die entscheidende Aktualisierung der Kreuzung aus der Klasse GUI Update ausgelagert. Wie bereits in Abschnitt 6.3.2 beschrieben, bewirkt die Ausführung des
dort gekapselten Codes, dass Fahrzeuge und Ampeln entsprechend ihrer aktuellen
Zustände sichtbar werden.
Die Zeitspanne zwischen den einzelnen Schritten wird durch die von Thread bereitgestellte Methode sleep() erreicht. Das dort als Parameter verwendete Zeitintervall
sleep time ms steht sowohl für den Monitor als auch für den Simulator zur Verfügung
und liefert eine für das gesamte System einheitliche Taktung der Ereignisse.
105
6 ARCHITEKTUR UND FUNKTIONALITÄT
Eine Ausnahme bei der Aktualisierung einer Kreuzung stellt die vom Simulator
gelieferte Simulation dar. Hier ist die Darstellung des Verkehrs nicht von einer maximalen Zeit begrenzt, sodass eine alternative Umsetzung der fortlaufenden GUIAktualisierung notwendig ist. In diesem Fall stellt die Klasse - orientierend am
Observer-Pattern - eine Methode
public static void update(int knoten_id)
bereit, die es dem Simulator damit ermöglicht, eine Datenbank-Änderung zu einem
bestimmten Knoten mitzuteilen. Sofern die Zustandsänderung den Knoten betrifft,
der dem Benutzer sichtbar ist, wird letztlich auch hier die Methode refresh view()
der View Detail -Instanz aufgerufen, um synchron mit der Übersichtskarte des Simulators die aktuelle Verkehrslage darzustellen (vgl. Unterkapitel 6.4).
6.4
Synchronisation
Das SiMo“-System setzt sich aus Simulator- und Monitor-Teilsystem zusammen.
”
Wie bereits in Abschnitt 6.1 erläutert, erfolgt der Datenaustausch über die Datenbank, während die Visualisierung über ein gemeinsames GUI stattfindet. Daraus
ergeben sich bezüglich der Synchronisation zwei grundlegende Herausforderungen.
Einerseits muss der Monitor stets die aktuellen vom Simulator erzeugten Daten
überprüfen. Ein Regelverstoß soll erkannt werden, bevor das beteiligte Fahrzeug
den Überwachungsbereich verlässt. Zum anderen soll die Simulation auf den jeweiligen Anzeigefenstern der Teilsysteme synchron ablaufen, obwohl die Aktualisierung
von verschiedenen Controllern durchgeführt wird.
Hinsichtlich der Überwachung existieren zwei Möglichkeiten zur Kooperation. Die
erste Methode ist eine pull“-Methode, was bedeutet, das der Monitor explizit die
”
Daten anfordert. Bei der zweiten Methode, push“, schreibt der Simulator unaufge”
fordert die Daten in eine Logging-Tabelle. Das SiMo“-System wendet die letztere
”
Methode an. Ein Grund dafür liegt darin, dass keine zentrale Stelle zur Datensammlung zur Verfügung steht. Vielmehr stellen die Fahrzeuge unabhängige Agenten dar,
worauf der Monitor nicht kontrolliert zugreifen kann. Somit ist der Monitor darauf
angewiesen, dass die einzelnen Fahrzeuge Informationen über ihre Zustände senden.
Fahrzeug 1
Fahrzeug 2
Monitor
!
!
!
!
!
?
!
?
!
! Update
? Anfrage
Abbildung 6.22: Taktung
Der Einsatz der push-Methode hat zur Folge, dass der Datenstrom der Fahrzeuge
106
6.4 Synchronisation
keine gleichmäßige Taktung aufweist, sondern die Fahrzeug zu unterschiedlichen Zeiten Daten senden. Abbildung 6.22 veranschauchlicht die asynchrone Signalisierung
der Fahrzeuge. Dennoch soll der Monitor Verkehrsregelverstöße in Echtzeit erkennen. Vorteilhaft ist, dass in festen dem Monitor bekannten Zeitabständen Daten von
Fahrzeugen in die Logging-Tabelle geschrieben werden. Dies ist der Diskretisierung
von Raum und Zeit zu verdanken. In der Realität kann diese Rolle von einem vorgeschalteten Konvertierer übernommen werden. Die Daten könnten in diesem Fall
beispielsweise von Induktionsschleifen erfasst und in einen Datenstrom umgewandelt werden. Mit dem Vorwissen über die Schrittlänge überprüft der Monitor bei
jedem zweiten Takt die Daten auf Regelverstöße. Dadurch ist gewährleistet, dass
alle Fahrzeuge neue Daten gesendet haben. Darüber hinaus ist die Periode nicht
zu lang, sodass der Monitor eventuelle Regelverstöße noch melden kann, bevor das
betroffene Fahrzeug den Überwachungsbereich verlässt.
107
Abbildung 6.23: Synchronisation der GUIs
6 ARCHITEKTUR UND FUNKTIONALITÄT
108
6.4 Synchronisation
Das zweite Problem stellt die Synchronisation des GUIs dar. Im Gegensatz zu einem
Einsatz im realen Betrieb werden die beiden GUIs unabhängig voneinander aktualisiert. Dennoch soll der Benutzer den Eindruck gewinnen, dass sich die Zustände der
einzelnen Fahrzeuge in den beiden GUIs nicht unterscheiden. Aus diesem Grund wird
zum einen die Simulator-GUI erst aktualisiert, wenn die neu ermittelten Datensätze
in die Datenbank geschrieben wurden. Diese Zeitdifferenz bietet dem Monitor zur
Aktualisierung seines GUIs die Möglichkeit, die aktuellen Daten abzufragen.
Eine Schwierigkeit liegt darin, dass die Fahrzeuge zu unterschiedlichen Zeiten ihre
Zustände ändern. Ein getaktetes Aktualisieren erfordert eine hohe Abtastrate, was
nicht dazu beitragen würde, dass die erhoffte Leistung in der Visualisierung erreicht
wird. Dies motiviert den Einsatz eines Observer-Patterns (vgl. Abschnitt 2.5.2). Im
Sinne des Observer-Patterns spielt der Simulator die Rolle des Subjects“, während
”
der Monitor den Observer“ darstellt. Jede Zustandsänderung eines Fahrzeugs wird
”
dem Monitor durch Aufruf seiner update()-Methode mitgeteilt. Um dem Monitor
eine möglichst optimale Anpassung zu ermöglichen, besitzt die Methode den Parameter knoten id. Somit muss nur dann eine Aktualisierung des Monitor-GUIs durchgeführt werden, wenn die Änderung den aktuell angezeigten Knoten betrifft.
Abbildung 6.23 zeigt das gemeinsame GUI von Monitor und Simulator. Die Zustände
des Fahrzeugs auf der ausgewählten Kreuzung sind in beiden Fenstern synchron. Es
wird ein Regelverstoß gemeldet, kurz nachdem das Fahrzeug bei Rot in die Kreuzung
eingefahren ist.
109
6 ARCHITEKTUR UND FUNKTIONALITÄT
110
Kapitel 7
Ausgewählte Aspekte der
Implementierung
Nach intensiven Vorüberlegungen in der Entwurfsphase soll schließlich das System
aufbauend auf der Konzeption implementiert werden. In diesem Kapitel werden ausgewählte Aspekte der Implementierung ausführlich erläutert. Sie verschaffen einen
Einblick in die Problematik und die zur Lösung herangezogenen Vorgehensweisen
und Techniken. Wie in den vorherigen Kapiteln lässt sich eine Unterteilung in zwei
Teilbereiche, Simulator und Monitor, vornehmen. Zum einen beschreibt Unterkapitel 7.1 die Implementierung der bedeutendsten Komponenten sowie die Diskussion
ausgewählter Probleme des Subsystems Simulator. Zum anderen diskutiert Unterkapitel 7.2, wie sich eine datenbankgestützte Überwachung des Verkehrs umsetzen
lässt.
7.1
Ausgewählte Aspekte der Simulation
Die Simulation wird in zwei Schritten ausgeführt. Zuerst werden die statischen Komponenten aus der Datenbank geladen. Darauf aufbauend erfolgt die Gestaltung des
GUIs, die mit Einsatz verschiedener Karten nicht ohne Synchronisation angemessen zustande kommen kann. Anschließend werden nach dem Start der Simulation
fortlaufend die dynamischen Komponenten erstellt und in Betrieb gesetzt. Für die
Fortbewegung der Fahrzeuge als Teil der dynamischen Komponenten müssen Routen verfügbar sein. Schließlich ist die Beachtung der Verkehrsregeln eine notwendige
Aufgabe für eine realistische Simulation.
7.1.1
Aufbau und Synchronisation der Karten
Da die Flexibilität und Erweiterbarkeit sowie die überschaubare Strukturierung des
Systems eine große Rolle beim Entwurf gespielt haben, bringt auch die Implementierung der statischen Objekte als Bausteine der Karten dementsprechend Anforderungen mit sich. Das System soll nicht nur im betrachteten Bonn-Nord-Gebiet Einsatz
finden können, sondern flexibel gegenüber einer Erweiterung bzw. einem Wechsel
des Einsatzortes sein. Daher soll der Code eine vom Simulationsgebiet vollständige
Unabhängigkeit aufweisen. Weiterhin stellen die statischen Objekte einen nicht tri-
111
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
vialen Bestandteil der Simulationsumgebung dar. Umso wichtiger ist ihre Gestaltung
und Strukturierung für einen guten Verlauf des Simulationsvorgangs. In diesem Abschnitt wird die Herangehensweise erklärt sowie die Design-Entscheidungen vorgestellt, die bei der Implementierung getroffen wurden.
Dank der Unterteilung der Straßentopologie in Zellen, liegt das gesamte Straßennetz als Menge aller Zellen relational in der Datenbank vor. Sich stützend auf diese
Datengrundlage, wird die Straßentopologie einmal beim Starten des Systems dynamisch zellenweise ausgelesen und aufgebaut. Soll das System für ein anderes Stadtgebiet in Betrieb genommen werden, ist einmalig der Aufwand der Datenerfassung
und Eintragung in der Datenbank erforderlich. Da der Code davon unberührt bleibt,
ist eine Migration folglich nicht problematisch.
Wie bereits erwähnt wurde, werden die Zellen in vier Kategorien (Straßenzellen,
Knotenzellen, Knotenzufahrten und Knotenabfahrten) unterteilt. Diese strikte Unterteilung ist für den Simulationsablauf von großer Bedeutung, da die ausgeführten
Aktionen vom Zellentyp abhängen. Eine Zufahrtzelle ist z.B. wichtig für die Beachtung von Ampeln bzw. Verkehrsschildern. Dies trägt zur Steigerung der Effizienz bei,
indem die Abfragen zur Beachtung der Verkehrsregeln (siehe Abschnitt 7.1.4) nur
dann ausgeführt werden, wenn sich ein Fahrzeug auf einer Knotenzufahrt befindet.
Es werden generell daher nicht alle Zellen angesprochen, sondern lediglich solche, die
von der auszuführenden Aktion betroffen sind. Für eine angemessene Instantiierung
kommt hier ein Factory Method Pattern zum Einsatz. Sich an diesem Pattern orientierend, wird beim Erzeugen der statischen Karte auf den Typ der Zelle geachtet
und dementsprechend der zugehörige Konstruktor zum Erstellen des Zellenobjekts
aufgerufen. Das folgende Stück Code zeigt, wie eine Knotenzufahrt erstellt und zur
Karte mithilfe der Methode addComponentCell hinzugefügt wird:
if(typ.equals("zufahrt"))
{
addComponentCell(this, new Knotenzufahrt(ID, x, y,zu_ueberwachen,
zu_blinken, knoten_id, 0 ), x, y, 1, 1,1,1,ID);
}
Nachdem die Zellen zum Kartenobjekt hinzugefügt wurden, werden sie gemäß dem
zugrunde liegenden Layout-Manager angeordnet. An dieser Stelle wurde das
GridBagLayout verwendet, da die Flächenunterteilung in einem gleichmäßigen rechteckigen Gitter erfolgt. Dies entspricht der vorgesehenen Raumdiskretisierung, die auf
zellularen Automaten basiert.
Der Punkt oben links auf der Karte entspricht dem Nullpunkt des Koordinatensystems in Swing. Die Werte der X-Achse wachsen von links nach rechts, die der
Y-Achse von oben nach unten. Aus diesem Grund wurden die Koordinaten der Zellen
in der Datenbank abhängig vom Nullpunkt (1,1) gespeichert. Da die Zellen im Laufe
der Simulation ihre Zustände verändern, müssen sie stets grafisch auf den neuesten
Stand gebracht werden. Dadurch ist ein Zugriff auf die Zellen nicht zu vermeiden.
Wurden die Swing-Komponenten einmal generiert, lassen sie sich jedoch nur anhand
112
7.1 Ausgewählte Aspekte der Simulation
einer ID anstatt mittels (X,Y)-Position ansprechen. Um auf die Zellen während der
Simulation zugreifen zu können, ist es daher notwendig, die Swing-Komponenten
noch zusätzlich mit einem Identifikator (ID) zu versehen. Damit lassen sich die einzelnen Komponenten einer Karte zurückgeben:
Component comp = SIMMain.getKarte(0).getComponent(id);
Den Zellen werden neben den Identifizierungseigenschaften noch weitere Eigenschaften zugeordnet. Während die Simulation auf dem gesamten Gebiet erfolgt, werden
nur Kreuzungen und ausgewählte Bereiche vom Monitor überwacht. Damit diese
Überwachungsbereiche hervorgehoben werden, ist es für die grafische Darstellung
von Interesse, zu vermerken, ob die Zellen zum Überwachungsbereich gehören. Besonders auszuzeichnen sind auch solche Zellen, bei denen ein Fahrzeug im Fall eines
Abbiegevorgangs ordnungsgemäß den Fahrtrichtungsanzeiger setzen muss. Die Aneinanderreihung solcher benachbarter Zellen wird als Blinkerbereich“ bezeichnet.
”
Abbildung 7.1 versinnbildlicht den Überwachungsbereich einer Kreuzung, der den
Blinkerbereich einschließt.
Blinkerbereich
Überwachungsbereich
Abbildung 7.1: Überwachungsbereich und Blinkerbereich
Sind nun einmal die Zellen zur Übersichtskarte oder zur entsprechenden Ausschnittskarte hinzugefügt, soll der Benutzer die Möglichkeit haben, zwischen den einzelnen
Karten zu navigieren. Dies ermöglicht das sogenannte CardLayout, da dort einzelne gleichartige Swingkomponenten als Stapel übereinandergelegt werden. Dementsprechend werden die einzelnen Straßenkarten als Swingkomponenten gemäß diesem
Layout dargestellt. Hierbei liegen die Ausschnittskarten in der Tabelle s ausschnitte
in der Datenbank vor und werden daher dynamisch geladen, was die Flexibilität des
113
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Systems unterstützen soll. Ein Ausschnitt ist durch die Beschränkung der X- und
Y-Koordinaten eindeutig festgelegt:
public static JPanel jContentPanecards = new JPanel();
...
jContentPanecards.add(getKarte(0),"0");//Übersichtskarte hinzufügen
Statement st = Connection_Manager.getCon().createStatement();
String query = "SELECT ID, x_min, x_max, y_min, y_max
FROM s_ausschnitte;";
ResultSet rs = st.executeQuery(query);
while(rs.next())
{//Ausschnitte hinzufügen
jContentPanecards.add(
new Ausschnitt(rs.getInt("ID"),rs.getInt("x_min"),
rs.getInt("x_max"), rs.getInt("y_min"),
rs.getInt("y_max")),String.valueOf(id));
}
rs.close(); st.close();
Um dem Benutzer einen neuen Ausschnitt zur Verfügung zu stellen, genügt es, die
Kartentabelle um einen Eintrag zu erweitern. Bestehende Ausschnitte lassen sich in
diesem Sinne auch leicht anpassen. Die Kapselung der Kartenausschnitte auf der Datenbank unterstützt weiterhin die Unabhängigkeit des Codes von den betrachteten
Simulationsgebieten. Nachdem alle Kartenausschnitte zum JPanel jContentPanecards hinzugefügt wurden, kann der Benutzer per Mausklick die gewünschte Karte
anzeigen lassen. Die mit 0“ gekennzeichnete Übersichtskarte z.B. wird dem Card”
layout entsprechend auf Wunsch des Benutzers folgendermaßen angezeigt:
public static CardLayout cl = new CardLayout();
public void mouseClicked(java.awt.event.MouseEvent e)
{
cl.show(SIMMain.jContentPanecards, String.valueOf(0));
}
Die Vielfalt der Karten bringt jedoch Konsistenzprobleme mit sich. Die Zellen in den
verschiedenen Kartenausschnitten sind logisch gesehen dieselben Zellen wie auf den
entsprechenden Teilen der Übersichtskarte. Diese Zellen werden für die unterschiedlichen Karten jedoch mit verschiedenen Swing-Komponenten grafisch dargestellt.
Deshalb muss bei einem Wechsel von einer Karte zur anderen sichergestellt werden, dass eine Synchronisation der Darstellung stattfindet. Die Information über die
Belegung einzelner Zellen muss auch nach dem Wechsel zur Verfügung stehen. Für
solche Fälle ist ein Modell-View-Controller-Ansatz geeignet.
Als Modell steht eine zentrale HashMap-Datenstruktur zur Verfügung. Sie gibt Auskunft über die Belegung einer Zelle sowie die Fahrtrichtung des sich darauf befindlichen Fahrzeugs. Die Zellen der betroffenen Karte fragen diese Informationen beim
Wechsel ab und aktualisieren dementsprechend ihre Zustände. Die Fahrzeuge spielen
die Rolle des Controllers. Sie verändern das Modell sobald sie ihre Position geändert
114
7.1 Ausgewählte Aspekte der Simulation
Model
Z1
Z2
belegt
frei
Z1
Z1
Z2
Z2
Übersichtskarte
Ausschnittskarte
Abbildung 7.2: Synchronisation des GUIs bei Kartenwechsel
haben. Somit erfolgt die Aktualisierung der Zellenzustände und folglich der einzelnen Karten lediglich durch den Zugriff auf das Modell. Die Fahrzeuge bewirken
damit keine direkte Zustandsänderung der verschiedenen Swing-Komponenten, die
die Zellen modellieren. Dadurch wird jede mögliche Inkonsistenz der Zellenzustände
vermieden.
7.1.2
Verwaltung der Routen
Für das Erreichen des Zielortes eines Fahrzeugs ist die Ermittlung eines Weges zwischen dem Start und dem Ziel eine Notwendigkeit. Eine Routenermittlung kann
dynamisch von einem Start und Ziel ausgehend erfolgen. In der Regel werden die
kürzesten bzw. die schnellsten Routen berechnet. Die Berechnung orientiert sich
an der Länge der Verbindungen zwischen dem Start- und Zielpunkt, bzw. an den
maximalen Geschwindigkeiten, die zwischen den zwei Punkten gefahren werden
dürfen. Die Laufzeit der Algorithmen, die diese Berechnungen durchführen, ist jedoch nicht zu vernachlässigen. Da der im Rahmen dieser Arbeit realisierte Simulator
hauptsächlich zur Datenbereitstellung für den Monitor dient, wurde diese Berechnung aus Effizienzgründen nicht umgesetzt. Dennoch stellen sich für den Simulator
hinsichtlich der Verwaltung der Routen ähnliche Anforderungen.
Eine Fahrtroute setzt sich aus mehreren Strecken zusammen, die den Weg zwischen
zwei Standorten beschreiben. In diesem Sinne weist eine Route eine gewisse Hierarchie auf. Für die Fortsetzung der Route ist die Reihenfolge der einzelnen Strecken
von Relevanz. Eine Unabhängigkeit der Daten vom Code wird durch eine Umsetzung in XML ebenso ermöglicht wie ein Einsatz von Datenbanken, jedoch bietet sich
115
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
insbesondere XML für die Verwaltung der Routen an. Da XML besser als Datenbanken für hierarchische Datenstrukturierung mit Ordnungserhaltung geeignet ist,
liegen die Fahrstrecken als XML-Datei vor. Darüber hinaus zeichnet sich XML mit
einem für den Benutzer überschaubaren Format aus, sodass sich die Routen leichter
erweitern lassen.
Die Routen werden im Voraus festgelegt und beim Starten des SiMo“-Systems
”
einmalig geparst. Nach dem Parsen der XML-Datei werden die Routen dem Controller zur randomisierten Auswahl zur Verfügung gestellt. Da Abbiegevorgänge von
den Routen abhängig sind und eine Entscheidung über die Abbiegerichtung nicht
während des Programmablaufs getroffen werden kann, stehen zusätzlich Routen für
die Realisierung von Falschabbiegern zur Verfügung. Aus diesem Grund wird mithilfe eines XML-Attributes vorentschieden, ob eine Route einem Falschabbieger zugeordnet werden kann. Andere Verkehrsregeln, wie z.B. Beachtung von Ampeln, sind
unabhängig von der Routenwahl, sodass sie erst auf Java-Ebene betrachtet werden.
Die Routen bestehen aus mehreren geraden Strecken. Ein XML-Element strecke
zeichnet sich durch vier Attribute aus: von, bis, richtung und blinker. Das Element
von bezeichnet die Startzelle, die den Anfang der Strecke festlegt. Die Festlegung
der Zielzelle erfolgt durch das Attribut bis. Aus einem Paar von Start- und Zielzelle entsteht keine eindeutige Fahrstrecke, es wird zusätzlich eine Fahrtrichtung
benötigt. Dies wird durch das Attribut richtung festgelegt. Auf die Richtung könnte
im Fall eines einspurigen Verkehrsmodells verzichtet werden. Stattdessen reicht ein
Vergleich der Koordinaten der Start- und Zielzellen aus, um die Richtung eindeutig
zu definieren. Der hier realisierte Simulator unterstützt jedoch ein mehrspuriges Verkehrsmodell. Daher ist es unmöglich, eine eindeutige Fahrtrichtung herauszufinden,
wenn die Start- und Zielzelle auf verschiedenen Spuren liegen. Eine Route lässt sich
folgendermaßen beschreiben:
<route id = "1" falschabbieger = "nein" name ="Autobahn-Roemerstr" >
<strecke von="1745" bis="1648" richtung="Ost" blinker="rechts"/>
<strecke von="1649" bis="462" richtung="Sued" blinker="links"/>
<strecke von="466" bis="1150" richtung="Ost" blinker="geradeaus"/>
</route>
Da sich die gesamte Route aus mehreren geraden Strecken zusammensetzt, ist beim
Übergang von einer zur anderen Strecke meist ein Abbiegevorgang notwendig. Die
Abbiegerichtung wird durch das Attribut blinker gesetzt und sorgt während der
Simulation für eine angemessene und vorbildliche spätere Darstellung des Fahrtrichtungsanzeigers. Eine Ableitung der nächsten Abbiegerichtung kann zwar durch den
Vergleich der Zellen zweier aufeinanderfolgender Strecken erfolgen, ist jedoch eine
aufwändige Aufgabe. Da die Strecken statisch bleiben und innerhalb einer Route ihre Reihenfolge beibehalten, ist es effizienter, den Fahrtrichtungsanzeiger festzulegen.
Um eine pflegeleichte Wartung des Routenplans zu ermöglichen und dessen Erweiterung dem Bearbeiter zu erleichtern, sind die Routen mit Namen versehen. Deterministisch stehen immer Start- und Zielzelle einer Strecke fest, zwischendurch ist
dem Fahrzeug jedoch überlassen, bei mehrspurigen Straßen dynamisch Spurwechsel
durchzuführen. Abbildung 7.3 zeigt eine Situation mit mehrspuriger Strecke und
veranschaulicht zwei Möglichkeiten eines dynamischen Spurwechsels.
116
7.1 Ausgewählte Aspekte der Simulation
Start
Ziel
Abbildung 7.3: Mehrspurige Strecke
7.1.3
Generierung und Fortbewegung der Fahrzeuge
Der Simulator soll in der Lage sein, eine große Anzahl von Fahrzeugen zu generieren
und insbesondere angemessen fortzubewegen. Für den guten Verlauf der Simulation
und die Stabilität des Systems ist die Verwaltung der großen Menge von Fahrzeugen daher von besonderer Bedeutung. Ferner zeichnet sich die Implementierung der
Fahrzeuge durch verschiedene für den Monitor benötigte Fahrverhalten aus.
Die Fahrzeuge in dieser Arbeit sind reflexbasierte Agenten mit internem Zustand.
Sie verfügen über eine Menge von internen Zuständen, die ihr aktuelles Verhalten
beschreiben können. Da der Fortbewegung der Fahrzeuge ein binäres Modell zugrunde liegt, können sie hinsichtlich ihrer Bewegung nur die zwei Zustände wartend oder
fahrend annehmen. Darüber hinaus ergänzen die Eigenschaften Richtung, Position
sowie Signalisierungszustand des Blinkers die Menge der internen Zustände.
Die Umgebung der Fahrzeuge besitzt wiederum eine Menge von Zuständen. So umfasst diese Menge die Ampelzustände sowie die Belegung der Zellen durch andere
Fahrzeuge. Besonders relevant ist die Existenz eines Vordermanns oder vorfahrtberechtigter Fahrzeuge. Die Fahrzeuge bewegen sich in Richtung ihres Ziels fort und
weisen einen Zustandswechsel lediglich beim Eintritt bestimmter Ereignisse auf. Die
Fahrzeuge reagieren auf folgende Ereignisse:
• Ampel auf Rot geschaltet
• vordere Zelle belegt
• vorfahrtberechtigtes Fahrzeug existiert
• Fahrzeug liegt nicht auf gewünschter Abbiegespur
• Fahrzeug liegt im Blinkerbereich
Bei den ersten drei Ereignissen reagiert ein Fahrzeug, indem es vom Zustand fahrend
auf den Zustand wartend umschaltet. Das vierte Ereignis tritt ein, wenn ein Fahrzeug
einen Abbiegevorgang vornehmen möchte, es sich jedoch nicht auf der entsprechenden Fahrspur befindet. Die Reaktion erfolgt in diesem Fall durch eine Veränderung
117
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
der Position, wodurch ein Spurwechsel zustande kommt. Das fünfte Ereignis wird
ausgelöst, falls sich ein Fahrzeug im Blinkerbereich befindet. Das Fahrzeug reagiert
darauf je nach Absicht mit dem Setzen des Fahrtrichtungsanzeigers.
Diese Reaktionen entsprechen den Aktionen bei der Multiagentensimulation und
sind in Methoden gekapselt. Diese Methoden sorgen für ein regelgerechtes Verhalten
der Fahrzeugagenten, das die Oberklasse Fahrzeug auszeichnet. Wie in Abschnitt
6.2.4 erwähnt wurde, weisen die Unterklassen der Klasse Fahrzeug unterschiedliches
ordnungswidriges Fahrverhalten auf und definieren somit die verschiedenen Fahrerprofile. Das Begehen einer Ordnungswidrigkeit wird dadurch ermöglicht, dass die
Fahrzeuge keine Reaktionen auf die Ereignisse zeigen. Dies wird dadurch realisiert,
dass die Aktionsmethoden der Oberklasse Fahrzeug überschrieben werden. In der
Methode bei rot anhalten() der Oberklasse z.B. wird das Signalbild des Signalgebers
bei den Zufahrten auf Rot überprüft und gegebenfalls angehalten. In der Klasse
FahrzeugAmpel, welche ein die Ampel missachtendes Fahrzeug darstellt, wird diese
Methode durch eine leere Methode überschrieben.
Somit lassen sich verschiedene Fahrertypen modellieren. Im Folgenden soll auf die
Generierung sowie die Problematiken, die bei der Verwaltung der Fahrzeuge entstehen, eingegangen werden.
Generierung und Verwaltung der Fahrzeuge
Die Generierung der Fahrzeuge stellt eine der wichtigen Aktivitäten des Simulators
dar. Ein besonderer Aspekt hierbei ist, dass fortlaufend Fahrzeuge erzeugt werden
müssen und mithilfe der verschiedenen Fahrerprofile unterschiedliche Verkehrsszenarien gestaltet werden können. Abbildung 7.4 veranschaulicht den gesamten Ablauf vom Start der Simulation bis zur Generierung von Fahrzeugen in Form eines
Sequenzdiagramms. Da die Klasse SIMMain für die benutzerseitige Steuerung der
Simulation verantwortlich ist, wird hier der Simulationsprozess initialisiert. Hat der
Benutzer die Simulation gestartet, wird ein Event ausgelöst und damit die Methode actionPerformed() aufgerufen. Die fortlaufende Generierung der Fahrzeuge
wird grundlegend durch einen Timer realisiert. Timer dienen der zeitgesteuerten
Ausführung von Methoden. In diesem Sinne werden die Fahrzeuge in regelmäßigen
Zeitabständen wie folgt erzeugt:
timer.schedule(new SIMTask(), 0, Settings.getSleep_time_ms()*8);
Dafür ist die Übergabe eines TimerTasks an die Klasse Timer notwendig. Die Klasse TimerTask umfasst Operationen, die in wiederholten Zeitabständen auszuführen
sind. Die Zeitabstände sind Vielfache der Dauer eines Simulationsschrittes, die in
einer XML-Konfigurationsdatei enthalten ist und je nach Bedarf vom Benutzer
geändert werden kann. Die TimerTask-Klasse SIMTask ist so gesehen ein Verwaltungsthread, der nebenläufig eine Operation durchführt. Im Simulationskontext besteht diese Operation darin, Objekte der Klasse Start zu erzeugen. Diese Klasse
sorgt dafür, dass neue Fahrzeuge generiert werden. Abhängig von der vom Benutzer
festgelegten Dichte wird eine obere Grenze der Anzahl zu generierender Fahrzeuge
118
7.1 Ausgewählte Aspekte der Simulation
!
!
Abbildung 7.4: Erzeugungsprozess der Fahrzeuge
(random fahrzeug) gesetzt. Da in dieser Arbeit viel Wert auf Fahrerprofile gelegt
wird, gibt es noch eine stochastische Variable verstoss art, die dynamisch das Fahrverhalten bestimmt. Wie der folgende Code zeigt, werden durch die Werte dieser
Variable entsprechende Unterklassen der Klasse Fahrzeug generiert:
for (int i = 1; i <= random_fahrzeug ; i++)
{
switch(verstoss_art)
{
case 10:
FahrzeugVorfahrt fVorfahrt = new FahrzeugVorfahrt();
fVorfahrt.start();
break;
...(weitere Fälle)
default:
Fahrzeug fahrzeug = new Fahrzeug();
fahrzeug.start();
}
}
Mit dem Erzeugen eines Fahrzeugs als Java-Objekt wird ein entsprechender Datensatz in der Datenbank angelegt. Die Datenbankeinträge sind zum einen für die
Beachtung der Verkehrsregeln erforderlich und ermöglichen zum anderen den Datenaustausch mit dem Monitor. Für jedes Fahrzeug existiert ein Tupel in der Tabelle
fahrzeug, das bei Zustandsänderung aktualisiert wird.
119
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Regelung der Verkehrsdichte
Für eine realistische Nachbildung des Verkehrsaufkommens ist die Verkehrsdichte einer der wichtigsten Parameter, worauf bei dieser Verkehrssimulation geachtet
werden soll. Die Dichte lässt sich als Anzahl von zur Zeit sich auf den Straßen befindlichen Fahrzeuge im Verhältnis zur gesamten Fläche definieren. Die Fläche lässt
sich über die Anzahl der Zellen des Simulationsgebiets definieren. Mit bloßem Auge kann die Entwicklung der Verkehrsdichte im Laufe der Simulation nicht genau
untersucht werden. Zur Validierung des Modells wurde daher die Anzahl der Fahrzeuge pro Simulationsschritt im gesamten Simulationsgebiet gemessen und grafisch
dargestellt.
Diese Analyse der Verkehrserzeugung ergab, dass bei kontinuierlicher Fahrzeugerzeugung die Anzahl der Fahrzeuge stets ansteigt. Zurückzuführen lässt sich diese
Beobachtung darauf, dass die Fahrzeuge das Simulationsgebiet nicht so schnell verlassen konnten, wie sie hineingekommen sind. Ein Grund dafür ist, dass die maximale
Anzahl der zu erzeugenden Fahrzeuge zwar durch eine variierende Obergrenze beschränkt wurde, jedoch keine Anpassung an die aktuelle Verkehrsdichte stattfand.
Die Lösung besteht darin, die Fahrzeuge mit Berücksichtigung der Verkehrsdichte
zu generieren. Dies wird durch eine Observer-Klasse realisiert, die nebenläufig die
Anzahl der Fahrzeuge bezüglich der Verkehrsdichte anpasst:
while(!SIMMain.stop)
{
dichte = ((double)Start.fahrzeuge.size())/anzahlZellen;
if(dichte*100>SIMMain.slidervalue)
{
SIMMain.anz_fahrzeuge = 1;
}
else
{
SIMMain.anz_fahrzeuge = SIMMain.slidervalue/2;
}
...// Für kurze Zeit warten
}
In regelmäßigen Zeitabständen wird die Dichte berechnet. Wenn dieser Wert über
einem vom Benutzer gewünschten Schwellenwert liegt, sollen dementsprechend weniger Fahrzeuge generiert werden. Wie bereits erläutert, erfolgt die Bestimmung der
Anzahl zu generierender Fahrzeuge per Zufallsprinzip. Die Obergrenze dieser Anzahl
wird daher auf eins heruntergesetzt, sobald die Dichte in Prozent den vom Benutzer
festgelegten Wert überschreitet. Ansonsten wird die maximale Anzahl der Fahrzeuge gemäß dem benutzerdefinierten Schwellenwert festgelegt. Abbildung 7.5 zeigt die
Ergebnisse der Messungen vor und nach dem Einsatz des Observers.
120
7.1 Ausgewählte Aspekte der Simulation
h
600
Anzahl der Fahrzeuge
700
500
400
Ohne Observer
Mit Observer
300
200
100
0
0
200
400
600
800
1000
1200
Simulationsschritt
Abbildung 7.5: Anzahl Fahrzeuge bzgl. Simulationszeit
Fortbewegung der Fahrzeuge
Nachdem ein Fahrzeug generiert wurde, soll es in der Lage sein selbständig auf dem
Straßennetz fahren zu können. Dafür benötigt das Fahrzeug als autonomer Agent
sowohl einen Start- als auch einen Zielpunkt einer Route, die im XML-Routenskript
festgelegt sind. Per Zufall wird daher dem Fahrzeug eine Route zugeordnet. Es wird
über die einzelnen Strecken einer Route iteriert, bis das Fahrzeug die Zielzelle der
letzten Strecke erreicht hat. Dank der Ausrichtung der Zellen in einem Gitter, kann
der Fahrzeugagent ausgehend von einem Tripel von Fahrtrichtung, Start- und Zielzelle seine nächste Zelle ermitteln. Abbildung 7.6 zeigt die Ermittlung der nächsten
Zelle für den Fall, dass die Fahrtrichtung Ost“ ist. In diesem Fall wird der Wert
”
der X-Koordinate solange inkrementiert, bis die Zielzelle der Strecke erreicht wurde.
Für andere Fahrtrichtungen lässt sich analog die nächste Zelle bestimmen.
x
x+1 x+2 ...
y
Start
Ziel
Abbildung 7.6: Ermittlung der nächsten Zelle
121
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Der Simulation in dieser Arbeit liegt ein mikroskopisches Modell zugrunde, um eine genaue Beobachtung des Straßenverkehrs zu ermöglichen. Dieses Modell benötigt
einen großen Detaillierungsgrad. Der Einsatz einer Multiagentensimulation trägt zur
Bewältigung der Systemkomplexität bei und verleiht der Simulation einen realistischen Aspekt. Die Fahrzeuge sollen als innerhalb eines Multiagentensystems handelnde Einheiten einzeln betrachtet und nachgebildet werden. Aus diesem Grund
ist jedes Fahrzeug als Thread implementiert worden und verfolgt seine Route mit
Reaktion auf seine Umgebung, um sein Ziel zu erreichen. Diese Individualität ist
auf die Aktualisierung des GUIs übertragbar. Für eine realistische Darstellung wird
die Karte nicht global neu gezeichnet. Stattdessen aktualisiert daher jedes Fahrzeug
grafisch seinen Zustand nach jedem Zellenwechsel.
7.1.4
Beachtung der Verkehrsregeln
Neben der Simulation von ordnungswidrigem Fahrverhalten bleibt die Beachtung
von Verkehrsregeln eine der wichtigsten Aufgaben, die der Simulator erfüllen soll.
Mit anderen Worten bedeutet dies, dass bei der Simulation auf der einen Seite dafür
gesorgt wird, dass verschiedene Fahrertypen für die Missachtung der Regeln erzeugt
werden. Auf der anderen Seite soll gleichzeitig auf die Einhaltung der Verkehrsregeln
geachtet werden. Relevant für das betrachtete Simulationsgebiet sind besonders die
Beachtung der Lichtsignalanlagen, Vorfahrtstraßen und Rechts-vor-Links-Knoten.
Als Beispiel für die Umsetzung dieser Regeln wird in diesem Abschnitt auf die letzte
Regel eingegangen.
Die Arbeitshypothese in dieser Diplomarbeit ist, dass SQL für die Analyseaufgaben
auf großen Datenmengen eine Alternative zur imperativen Vorgehensweise darstellt.
In diesem Sinne wurden die Verkehrsregeln als SQL-Sichten formuliert. Die Beachtung der Verkehrsregeln erfolgt durch eine kontinuierliche Auswertung dieser Views
( continuous queries“). Dementsprechend baut auch die Rechts-vor-Links-Regel auf
”
den Tabellen der Datenbank auf.
Lookahead-Zelle
Abbildung 7.7: Lookahead-Zelle
122
7.1 Ausgewählte Aspekte der Simulation
Bei der Rechts-vor-Links-Regel geht es für ein in die Kreuzung einfahrendes Fahrzeug
darum, sich zu vergewissern, dass sich kein vorfahrtberechtigtes Fahrzeug von rechts
nähert. Netzknoten, auf denen für die Vorfahrt nur die Rechts-vor-Links-Regel gilt,
sollen als Rechts-vor-Links-Knoten bezeichnet werden. Für die deskriptive Formulierung der Rechts-vor-Links-Regel werden alle Rechts-vor-links-Knoten des Simulationsgebiets benötigt. Diese Netzknoten sind durch die View s RVL Knoten definiert. Sie selektiert alle Rechts-vor-links-Knoten, die, wie bereits im Entwurf erklärt
wurde, mit der Vorfahrtsregelung ’RVL’ gekennzeichnet sind. Verfügt ein Netzknoten über keine vorfahrtregelnde Beschilderung und ist ihm eine LSA zugeordnet, die
aktuell außer Betrieb ist, so gilt er auch als Rechts-vor-links-Knoten:
CREATE VIEW s_RVL_Knoten AS
(
SELECT k.knoten_id
FROM knoten k
WHERE k.vorfahrtregelung=’RVL’
UNION
SELECT k.knoten_id
FROM knoten AS k, lsa
WHERE
lsa.in_betrieb=False AND k.vorfahrtregelung=’LSA_OB’
AND lsa.lsa_id = k.knoten_id;
)
Ein Vorfahrtsfall innerhalb eines Rechts-vor-Links-Knotens liegt vor, wenn sich ein
Fahrzeug auf einer Knotenzufahrt befindet und ein anderer auf der Zufahrt rechts
von ihm steht. In diesem Fall hat der zweite Vorfahrt und der erste ist wartepflichtig.
Von besonderer Relevanz bei der Beachtung der Rechts-vor-Links-Regel ist daher die
Belegung der rechten Zufahrt des Wartepflichtigen.
Eine genauere Betrachtung realer Verkehrsereignisse zeigt, dass für die Verkehrssicherheit weitere Zellen berücksichtigt werden müssen, um ein vorausschauendes
Fahren zu ermöglichen. Gerade bei Vorfahrtsituationen kommt es wegen ein paar
entscheidender Sekunden oft zu Unfällen. Dadurch motiviert soll nicht nur geprüft
werden, ob die rechte Zufahrt des wartepflichtigen Fahrzeugs frei ist. Stattdessen
wird zusätzlich mit einem Lookahead-Ansatz sichergestellt, dass die hintere Nachbarzelle der rechten Zufahrt nicht belegt ist. Abbildung 7.7 soll einen Rechts-vorLinks-Knoten darstellen. Das rote Fahrzeug ist in dieser Situation gegenüber dem
grünen Fahrzeug wartepflichtig. Das rote Fahrzeug darf erst in die Kreuzung einfahren, wenn weder die gelb markierte Knotenzufahrt noch die rot gekennzeichnete
Lookahead-Zelle belegt ist.
Die Belegung der beiden Zellen wird durch die Sicht s check rvl überprüft. Eine Auswertung findet immer dann statt, wenn sich ein Fahrzeug auf einer Knotenzufahrt
befindet. Diese Differenzierung zur Effizienzsteigerung ist der Zellenkategorisierung
123
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
auf Java-Ebene zu verdanken. Die Sicht s check rvl wird durch eine Vereinigung der
beiden Views s rvl zufahrt und s rvl lookahead realisiert:
CREATE VIEW s_check_rvl AS
(
SELECT Fahrzeug
FROM s_rvl_zufahrt
UNION
SELECT Fahrzeug
FROM s_rvl_lookahead
)
Die erste View ist für die Prüfung der Belegung von Knotenzufahrten zuständig, die
von einem vorfahrtberechtigten Fahrzeug besetzt werden können:
CREATE VIEW s_rvl_zufahrt AS
(
SELECT f.fahrzeug_id AS Fahrzeug
FROM
(
(
rechte_zufahrt rz INNER JOIN
(knotenzufahrt kz INNER JOIN fahrzeug f
ON kz.zellen_id = f.zellen_id)
ON rz.zellen_id_zufahrt = f.zellen_id
)
INNER JOIN s_RVL_Knoten k ON kz.knoten_id = k.knoten_id)
INNER JOIN fahrzeug AS f1
ON rz.zellen_id_rechtezufahrt = f1.zellen_id;
)
Zunächst sind bei dieser Regel lediglich die Knotenzufahrten von Interesse, die von
einem Fahrzeug belegt sind. Weiterhin sollen sich nur solche Fahrzeuge qualifizieren,
deren rechte Zufahrt von einem anderen Fahrzeug besetzt ist. Diese zwei Bedingungen werden durch die Joins zwischen den Tabellen knotenzufahrt, fahrzeug und
rechte zufahrt überprüft. Solch eine Regel macht nur Sinn, wenn sich die zwei im
Vorfahrtsfall beteiligten Fahrer innerhalb desselben Netzknotens befinden. Auf diese
Überprüfung kann verzichtet werden, da die Relation rechte zufahrt jeweils nur Zufahrten desselben Netzknoten verbindet. Ein Join mit der View s RVL Knoten stellt
zusätzlich sicher, dass es sich um einen Rechts-vor-Links-Knoten handelt. Schließlich wird überprüft, ob die rechte Zufahrt tatsächlich von einem vorfahrtberechtigten
Fahrzeug besetzt ist.
Darüber hinaus prüft die View s rvl lookahead noch die Lookahead-Zelle des wartepflichtigen Fahrzeugs auf Belegung. Dies wird mithilfe eines Zugriffs auf die Tabelle
nachbarzellen ermöglicht. Da aus symmetrischen Gründen keine hinteren
124
7.2 Ausgewählte Aspekte des Monitorings
Nachbarzellen explizit gespeichert wurden, wird die gewünschte Zelle aus einem anderen Blickwinkel betrachtet. Die erforderlichen Nachbarzellen sind solche Zellen,
die eine Knotenzufahrt als vorigen Nachbarn (’V’) besitzen.
Die View s rvl lookahead ist zu Beginn genauso wie die View s rvl zufahrt aufgebaut. Der Unterschied liegt in der Einbindung der Tabelle nachbarzellen, sodass
Fahrzeuge auf den Lookahead-Zellen betrachtet werden können. Dies wird in den
mit (1) und (2) gekennzeichneten Teilen umgesetzt:
CREATE VIEW s_rvl_lookahead AS
(
SELECT f.fahrzeug_id AS Fahrzeug
FROM
(
(
(
rechte_zufahrt rz INNER JOIN
(knotenzufahrt kz INNER JOIN fahrzeug f
ON kz.zellen_id = f.zellen_id)
ON rz.zellen_id_zufahrt = f.zellen_id
)
INNER JOIN s_RVL_Knoten k
ON kz.knoten_id = k.knoten_id
)
(1)INNER JOIN nachbarzellen n
ON rz.zellen_id_rechtezufahrt = n.nachbar_id
)
(2)INNER JOIN fahrzeug AS f1
ON n.zellen_id = f1.zellen_id
WHERE (n.lage=’V’);
)
Zur Beachtung der Rechts-vor-Links-Regel werden demnach zwei Zellen bezüglich
vorfahrtberechtigter Fahrzeuge in Betracht gezogen. Eine Erweiterung der View
s rvl lookahead ist möglich, indem analog und mit demselben Schema weitere Zellen
transitiv auf Belegung überprüft werden.
7.2
Ausgewählte Aspekte des Monitorings
Stehen simulierte Daten in der Datenbank zur Verfügung, so kann das Monitoring
einsetzen, um den Verkehr auf regelgerechtes Verhalten zu kontrollieren. Abschnitt
6.3.4 gab bereits einen Einblick in die Arbeitsweise des Monitors. Die in Echtzeit
vollzogene Überprüfung der Fahrzeugdaten hinsichtlich begangener Regelverstöße ist
keine triviale Angelegenheit. Die Formulierung der SQL-Anfragen zur Überwachung
der Regelverstöße muss zunächst aus natürlichsprachlichen Texten herausgearbeitet
125
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
werden. Weiterhin produziert der Simulator in kürzester Zeit viele Datensätze, wodurch die Tabellen in der Datenbank stark anwachsen. Daher müssen zum einen die
zur Überwachung eingesetzten SQL-Anfragen effizient ausgewertet und zum anderen eine möglichst optimale Löschstrategie für nicht mehr benötigte Daten eingesetzt
werden.
7.2.1
Formulierung der Regelverstöße in SQL
Die Besonderheit des Monitors drückt sich dadurch aus, dass Verkehrsregelverstöße
in der DB-Anfragesprache SQL formuliert wurden und mithilfe von SQL-Anfragen
die Daten in Echtzeit auf Regelverstöße überprüft werden. Im Folgenden soll gezeigt werden, dass sich Ordnungswidrigkeiten in SQL ausdrücken lassen. Im Gegensatz zum Simulator, der durch die Verkehrsregeln mithilfe von SQL-Anfragen
den nächsten Zustand plant, geht es bei der Überprüfung von Regelverstößen um
den Vergleich verschiedener Fahrzeugzustände. Der Monitor selbst hat kein Wissen über den Verlauf des Verkehrs, sondern muss stattdessen die Informationen aus
den einzelnen Zuständen herleiten. Die Daten zu den simulierten Fahrzeugen und
Lichtsignalanlagen sind für den Monitor in den Tabellen sm fahrzeug und sm LSA
gespeichert:
sm_fahrzeug(zeit, fahrzeug_id, zellen_id, blinker,
geschwindigkeit, fahrtrichtung)
sm_LSA(zeit, lsa_id, phase, in_betrieb)
Im Vergleich zu den Tabellen fahrzeug und lsa enthalten die mit sm gekennzeichneten Tabellen alle Zustände der Fahrzeuge und LSAs. Sie sind zur Rekonstruktion
der Szenarien mit einem Zeitstempel versehen. Darüberhinaus gehen die statischen
Informationen über die Straßentopologie in die Analyse mit ein.
Die Ordnungswidrigkeiten, die einen Verstoß gegen die bereits in Unterkapitel 3.2
beschriebenen Regeln der StVO darstellen, werden in Form von SQL-Anfragen für
das Monitoring auf den Datensätzen eingesetzt. Der im Rahmen dieser Arbeit entwickelte Monitor überprüft die folgenden sieben Passagen der Straßenverkehrsordnung,
welche für das Fahrverhalten auf einer Kreuzung relevant sind:
• Gewähr der Vorfahrt bei Rechts-vor-Links-Knoten (§8, Abs.1)
• Gewähr der Vorfahrt bei vorhandenen Vorfahrtzeichen (§41, Abs.2, Nr.1b)
• Gewähr der Vorfahrt bei Abbiegevorgängen nach links (§9, Abs.4)
• Beachtung der Wechsellichtzeichen (§37, Abs.1, Nr.1)
• Abbiegen gemäß vorgeschriebener Fahrtrichtung (§41, Abs.2, Nr.2)
• Korrekter Einsatz des Fahrtrichtungsanzeigers (§9, Abs.1, Satz 1)
• Halt vor Kreuzung bei stockendem Verkehr (§11, Abs. 1)
Die SQL-Anfragen sollen genau dann ein Ergebnis liefern, wenn die Eigenschaften eines Fahrzeugs innerhalb eines Knotens nicht mit diesen Vorschriften übereinstimmen.
Die Umsetzung natürlichsprachlicher Beschreibungen der Verkehrsverstöße in die
formale Sprache SQL erfordert die Durchführung verschiedener Schritte.
126
7.2 Ausgewählte Aspekte des Monitorings
Zunächst müssen Definitionen von grundlegenden Begriffen aus der natürlichen
Sprache formaler definiert werden. Dies ist zum einen die Repräsentation von Fahrzeugen und Ampeln sowie der gesamten Straßentopologie, die bereits in Unterkapitel
5.2 ausführlich behandelt wurden. Ferner gehören dazu insbesondere die abstrakten
Begriffe, die selbst durch das deutsche Gesetz nicht eindeutig festzuhalten sind. So
wird oftmals ein fehlerhaftes Verhalten als Ordnungswidrigkeit geahndet, wenn dabei die Behinderung eines anderen Fahrzeugs vorliegt. In diesem Zusammenhang
soll eine Behinderung genau dann vorliegen, sobald sich ein Fahrzeug auf einer Zelle
befindet, die unmittelbar vor einem anderen Fahrzeug liegt. Dies bedeutet weiterhin, dass das Fahrzeug, dessen Verkehrsteilnehmer behindert wird, in diese Richtung
ausgerichtet sein muss und nun wegen belegter Zellen nicht ohne Beeinträchtigung
seinen Weg fortsetzen kann. Ein Fahrzeug gilt als wartend, wenn es sich länger als
eine Zeiteinheit auf einer Zelle befindet.
Bevor eine komplexe SQL-Abfrage entwickelt wird, ist es von Vorteil, die Ordnungswidrigkeiten gegen die entsprechenden Gesetze der StVO in konkrete auf das relationale Datenbankkonzept abbildbare Sätze umzuformulieren. Die einzelnen Zustände
und Beziehungen der Fahrzeuge und Ampeln untereinander sind hierbei einzeln zu
identifizieren.
Sind die Begrifflichkeiten klar definiert und die einzelnen Kriterien herausgearbeitet,
muss eine Umsetzung in SQL gefunden werden. Für eine dynamische Implementierung vom Melden und Logging von Regelverstößen ist eine einheitliche Information in der Zielliste der SQL-Anfragen wünschenswert, die für alle RegelverstoßKategorien gleichermaßen ausgewählt wird. Für das Wiedererkennen eines gemeldeten Regelverstoßes in einer Datenmenge sind daher die beteiligten Fahrzeuge sowie
der Zeitpunkt des Geschehens und der zugehörige Knoten relevant. Die Art des
Regelverstoßes ist ebenfalls wichtig, muss jedoch nicht explizit selektiert werden,
da sich jede Abfrage bereits eindeutig einem entsprechenden Regelverstoß zuordnen
lässt. Die Anzahl der selektierten Fahrzeuge - eins oder zwei - ist abhängig von der
Art des Regelverstoßes. So betrifft der Rotlichtverstoß lediglich ein einzelnes Fahrzeug, wohingegen bei Missachtung der Vorfahrt zwei Fahrzeuge beteiligt sind.
Ist eine Formulierung in der Anfragesprache SQL gefunden, ist eine Analyse der
Performanz notwendig. So können eventuell unnötige Teilabfragen eliminiert oder
die gesamte Abfrage sowie die physische Organisation der Tabellen optimiert werden. Im Allgemeinen wird angenommen, dass die Verkehrsteilnehmer weder gegen
das Rechtsfahrgebot (§2) verstoßen noch generell die Fahrstreifen in falscher Richtung befahren. Außerdem wird davon ausgegangen, dass Fahrzeuge nicht zweimal
denselben Knoten befahren. Im Folgenden wird eine Auswahl der formulierten SQLAnfragen vorgestellt, wodurch repräsentativ das Vorgehen beschrieben und einzelne
Problemstellungen erläutert werden sollen.
127
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Gewähr der Vorfahrt bei vorhandenen Vorfahrtzeichen
Bei Existenz der Zeichen Vorfahrt gewähren!“ und Halt! Vorfahrt gewähren!“ muss
”
”
gemäß §8 der StVO auf vorfahrtberechigte Fahrzeuge geachtet werden. Ein Verstoß
gegen diese Regel hat verschiedene Kriterien zu erfüllen:
1. Ein Fahrzeug befindet sich auf einer Knotenzufahrt, der ein Verkehrszeichen
mit der StVO-Zeichen-Nr. 205 ( Vorfahrt gewähren!“) oder 206 ( Halt! Vor”
”
fahrt gewähren!“) zugeordnet ist.
2. Ein vorfahrtberechtigtes Fahrzeug befindet sich auf einer Zufahrt rechts oder
links des Wartepflichtigen bzw. potentiell Vorfahrtnehmenden.
3. Der Wartepflichtige steht zu einem späteren Zeitpunkt auf einer Knotenzelle
vor der Zufahrt oder einer Knotenzelle des Vorfahrtberechigten (zeitgleich).
4. Falls dem Knoten eine Lichtsignalanlage zugeordnet ist, muss diese außer Betrieb sein, damit eine Betrachtung der Vorfahrtzeichen überhaupt in Frage
kommt.
2a)
1)
2b)
Abbildung 7.8: Kriterien der Vorfahrtmissachtung am Beispiel
128
7.2 Ausgewählte Aspekte des Monitorings
Abbildung 7.8 veranschaulicht, welche Bedingungen zu beachten sind. Das rote Fahrzeug stellt das wartepflichtige, das grüne das vorfahrtberechtigte Fahrzeug dar. Situation 1 stellt die Voraussetzung einer Vorfahrtverletzung dar. Für das Eintreten
einer Vorfahrtverletzung, muss sich ein Fahrzeug von der linken oder rechten Seite
nähern. Es ist nicht zwingend notwendig, dass die Fahrzeuge zeitgleich die beiden
Zufahrten belegen, da ein vorausschauendes Fahren erwartet wird und auch Fahrzeuge auf Lookahead-Zellen zu beachten sind (vgl. Abschnitt 7.1.4).
Situation 2a) zeigt die entscheidende Situation. Hier wird der Vorfahrtberechtigte
durch das rote Fahrzeug an der Weiterfahrt gehindert. Situation 2b) stellt hingegen
keine Vorfahrtverletzung dar und verdeutlicht die Relevanz der Betrachtung von
Fahrzeugausrichtungen. Die Nachbarschaft der Zellen mit alleiniger Einbeziehung
der Lage würde auch in dieser Konstellation besagen, dass die Zelle des roten Fahrzeugs vor der Zelle des grünen Fahrzeugs liegt (vgl. Abschnitt 5.2.1). Aus diesem
Grund gilt die Zusatzbedingung, dass der Wartepflichtige der Ausrichtung des vorfahrtberechtigten Fahrzeugs entsprechend davor liegt.
Für die Beobachtung dieser Zustände lassen sich vorab zwei Sichten definieren. Für
Bedingung 1 sind alle Zellen erforderlich, denen ein vorfahrtregelndes Vorschriftzeichen zugeordnet ist:
CREATE VIEW vorfahrt_zellen AS
(SELECT zellen_id
FROM zeichen_zuordnung
INNER JOIN
(SELECT * FROM verkehrszeichen
WHERE verkehrszeichen.stvo_zeichen_nr=’205’ Or
verkehrszeichen.stvo_zeichen_nr=’206’ ) AS v
ON v.zeichen_id=zeichen_zuordnung.zeichen_id
)
Hierbei wird die Tabelle zeichen zuordnung mit der Tabelle verkehrszeichen verknüpft. Dabei qualifizieren sich solche Zellen, denen ein Vorfahrtzeichen mit StVOZeichen-Nummer ’205’ oder ’206’ zugeordnet ist. Da es sich bei dem Input für das
Monitoring um eine diskrete Simulation handelt und ein tatsächlicher Halt eines
Fahrzeugs nicht gemessen werden kann, wird zwischen diesen beiden Verkehrszeichen nicht unterschieden.
Für die Erkennung der Regelverstöße spielen meist die Bewegungen der Fahrzeuge eine bedeutende Rolle. Einzelne unabhängig voneinander betrachtete Positionen ergeben noch keine ausreichenden Informationen. Somit ist es erforderlich, zwei
129
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Positionen eines Fahrzeugs in Bezug zueinander zu bringen. Diese oft benötigte
Datenmenge wird daher zur Übersichtlichkeit in eine Sicht ausgegliedert:
CREATE VIEW fahrzeug_1_2_LE AS
(
SELECT f1.zellen_id AS zellen_id_1, f1.fahrzeug_id,
f1.zeit AS zeit_1,
f2.zellen_id AS zellen_id_2, f2.fahrtrichtung,
f2.zeit AS zeit_2
FROM sm_fahrzeug AS f1
INNER JOIN sm_fahrzeug AS f2
ON f1.fahrzeug_id=f2.fahrzeug_id
WHERE f1.zeit<f2.zeit
)
Wie die Sicht zeigt, sind die Bedingungen für die Bildung eines neuen Tupels die
Gleichheit in fahrzeug id und die Einschränkung, dass die erste Position zeitlich vor
der zweiten Position liegt. Das Kürzel ’LE’ im Namen der Sicht soll kennzeichnen,
dass die Bedingung im WHERE-Teil ein < verwendet. Eine äquivalente Sicht mit
≤, die auch Fahrzeugpositionen zum selben Zeitpunkt erlaubt, trägt den Namen
fahrzeug 1 2 LEQ.
Mithilfe der identifizierten Kriterien und der soeben definierten Sichten ist die Abfrage für ein Missachten der Vorfahrt wie folgt formulierbar:
SELECT DISTINCT ff.zeit_1 AS zeit, ff.fahrzeug_id,
vv.fahrzeug_id AS fahrzeug_id_v, knotenzelle.knoten_id
FROM (((((
fahrzeug_1_2_LE ff
(1) INNER JOIN vorfahrt_zellen
ON vorfahrt_zellen.zellen_id=ff.zellen_id_1)
(2) INNER JOIN knotenzelle
ON knotenzelle.zellen_id=ff.zellen_id_2)
(3) INNER JOIN zufahrt_quer
ON ff.zellen_id_1=zufahrt_quer.zellen_id_zufahrt)
(4) INNER JOIN fahrzeug_1_2_LEQ AS vv
ON vv.zellen_id_1=zufahrt_quer.zellen_id_quer)
(5) INNER JOIN (SELECT * FROM nachbarzellen WHERE lage = ’V’) AS n
ON n.nachbar_id=ff.zellen_id_2 AND n.zellen_id=vv.zellen_id_2
AND n.fahrtrichtung=vv.fahrtrichtung)
WHERE vv.zeit_2 IN (SELECT max(zeit) FROM sm_fahrzeug
WHERE zeit <= ff.zeit_2
AND fahrzeug_id = vv.fahrzeug_id)
AND NOT EXISTS (SELECT * FROM m_signalbild s
WHERE s.zellen_id = ff.zellen_id_1 AND
s.zeit = (SELECT max(zeit) FROM m_signalbild
WHERE zeit <= ff.zeit_1 AND
zellen_id = ff.zellen_id_1));
130
7.2 Ausgewählte Aspekte des Monitorings
Zunächst wird mit der Sicht fahrzeug 1 2 LE ff das Fahrzeug betrachtet, welches
potentiell einen Regelverstoß begehen könnte. Die zellen id der ersten Fahrzeugposition muss nach Bedingung 1 einer Knotenzufahrt aus der Sicht vorfahrt zellen
zuordenbar sein. Um einem Vorfahrtberechtigten die Vorfahrt nehmen zu können,
soll die zweite Position hingegen innerhalb des Kreuzungsbereichs liegen, sodass das
Zwischenergebnis nach dem ersten Join mit der Tabelle knotenzelle verknüpft wird.
Schließlich muss noch der Bezug zum vorfahrtberechtigten Fahrzeug hergestellt werden. Wichtig ist, aus welchen Richtungen sich die beiden Fahrzeuge nähern. Es wird
angenommen, dass keine abknickenden Vorfahrten existieren. In diesem Fall soll das
vorfahrtberechtigte Fahrzeug auf einer Knotenzufahrt quer zu derjenigen Zufahrt
stehen, auf dem sich das Fahrzeug ff zum Zeitpunkt ff.zeit 1 befindet. Die links und
rechts einer Zufahrt liegenden Zellen sind in der materialisierten View zufahrt quer
enthalten. Sie werden mit der Fahrzeugposition vv.zellen id 1 aus der Sicht vv für
den Vorfahrtberechtigten in Verbindung gebracht. Durch den fünften Join mit der
Tabelle nachbarzellen soll schließlich sicherstellt werden, dass das wartepflichtige
Fahrzeug aus ff auf einer Zelle vor dem vorfahrtberechtigten Fahrzeug steht. Diese
Behinderung ist das entscheidende Kriterium für den Regelverstoß.
Das Ergebnis wird im WHERE-Teil noch durch zwei Bedingungen eingeschränkt.
Zum einen müssen der Wartepflichtige ff und der Vorfahrtberechtigte vv zum selben Zeitpunkt zeit 2 benachbarten Zellen zugeordnet sein. Die über die Fahrzeuge
gelieferten Informationen sind jedoch vom Simulator abhängig und stellen nicht für
jeden Simulationsschritt eine Position des Fahrzeugs zur Verfügung. Somit kann
kein einfacher Vergleich von Zeitpunkten, wie vv.zeit 2 = ff.zeit 2, als Bedingung in
die Anfrage eingehen. Stattdessen muss der aktuelle Zeitpunkt eines Fahrzeugs im
Vergleich zum anderen evaluiert werden. Daher benutzt die Anfrage die AggregatFunktion max(), um sicherzustellen, dass Vorfahrtberechtigter und Wartepflichtiger
zum gleichen Zeitpunkt auf benachbarten Zellen platziert sind:
vv.zeit_2 IN (SELECT max(zeit) FROM sm_fahrzeug
WHERE zeit <= ff.zeit_2
AND fahrzeug_id = vv.fahrzeug_id)
Weiterhin sind Kreuzungen mit Lichtsignalanlage zu betrachten. Da Wechsellichtzeichen vorfahrtregelnden Verkehrszeichen vorgehen, darf die dortige Beschilderung
erst dann in Betracht gezogen werden, wenn die zugehörige LSA zu diesem Zeitpunkt außer Betrieb ist. Eine Unterabfrage mit NOT EXISTS stellt die Erfüllung
dieser Kriterium 4 betreffenden Bedingungen sicher. Sie liefert genau dann ’true’,
wenn entweder die dem Knoten zugeordnete LSA außer Betrieb ist oder der Knotenzufahrt kein Signalgeber zugeordnet und damit der Betriebszustand einer LSA
irrelevant ist.
Zu beachten ist der Sonderfall, dass zu einer durch eine LSA gesteuerte Kreuzung
auch Knotenzufahrten gehören können, deren Durchfahrt durch kein Lichtsignal eingeschränkt wird und stattdessen die Verkehrssicherheit lediglich durch ein Vorfahrtzeichen geregelt ist. In diesem Fall wird der Wartepflichtige direkt in die gewünschte
131
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Abbildung 7.9: Sonderfall bei Beachtung der Vorfahrt
Straße und nicht in den Kreuzungsbereich einfahren, sodass die Richtung, aus der
sich das vorfahrtberechigte Fahrzeug nähert, irrelevant bleibt (siehe Abbildung 7.9).
Da die zuvor beschriebene Abfrage nur die Tabelle zufahrt quer in die Auswertung
einbezieht, bleiben Zufahrten gegenüber dabei unbeachtet und eine zusätzliche Abfrage wird erforderlich.
Die betroffenen Knotenzufahrten zeichnen sich dadurch aus, dass ihnen keine Knotenzelle als Nachbar zugeordnet ist. Für eine Vorfahrtverletzung muss sich der Vorfahrtnehmende stattdessen zum Zeitpunkt zeit 2 auf einer Knotenabfahrt befinden.
Weiterhin ist nicht zu testen, über welche Knotenzufahrt der Vorfahrtberechtigte
den Straßenknoten befahren hat. Mit Hinzunahme dieser leicht modifizierten Anfrage wird auch der Sonderfall abgedeckt.
Beachtung von Wechsellichtzeichen
Einer der gefährlichsten Regelverstöße ist das Überfahren der Kreuzung bei rotem
Signalbild. Der Querverkehr verlässt sich bei eigenem grünem Licht darauf, dass
er ohne Behinderung die Kreuzung überqueren kann, ohne auf kreuzende Fahrzeuge achten zu müssen. In der SQL-Umsetzung sind neben den Fahrzeugen auch die
Lichtsignalanlagen von Bedeutung. Um eine Ordnungswidrigkeit melden zu können,
müssen die folgenden Bedingungen erfüllt sein:
1. Zum Zeitpunkt 1 befindet sich ein Fahrzeug auf einer Knotenzufahrt k1, zum
Zeitpunkt 2 ist es einer Knotenzelle zugeordnet, die vor dieser Knotenzufahrt
liegt.
2. Dem Straßenknoten ist eine Lichtsignalanlage zugeordnet, die in Betrieb ist.
3. Der Knotenzufahrt k1 ist ein Signalgeber zugeordnet, der zum Zeitpunkt 1
sowie zum Zeitpunkt 2 auf Rot geschaltet ist.
132
7.2 Ausgewählte Aspekte des Monitorings
Für die SQL-Anfrage wird die Sicht m signalbild rot benötigt, welche diejenigen
Signalgeber-Zustände zurückliefert, bei denen die LSA in Betrieb ist und das Signalbild ein rotes Licht zeigt. Diese Information erhält man durch einen Join über
sm lsa, signalgeber und phase:
CREATE VIEW m_signalbild_rot AS
(
SELECT p.signalbild, s.signalgeber_id, s.zellen_id, l.zeit, l.lsa_id
FROM (sm_LSA AS l
INNER JOIN signalgeber AS s
ON s.lsa_id=l.lsa_id)
INNER JOIN phase AS p
ON p.signalgeber_id=s.signalgeber_id
AND l.phase=p.phase
WHERE l.in_betrieb=TRUE AND p.signalbild=’rot’
)
Die ebenfalls verwendetete Sicht m signalbild unterscheidet sich von der Sicht
m signalbild rot in der fehlenden Selektion hinsichtlich des roten Signalbildes. Somit
werden sowohl auf Rot als auch auf Grün geschaltete Signalgeber für eine Weiterverarbeitung eingesetzt.
Die Abfrage zur Beobachtung des Rotlichtverstoßes lässt sich schließlich in zwei
Teile strukturieren. Der erste Teil betrifft das Fahrzeug und seine Positionen aus
Bedingung 1. Mithilfe der Sicht fahrzeug 1 2 LE werden alle Fahrzeuge selektiert,
die zunächst auf einer Knotenzufahrt stehen und danach auf einer Nachbarzelle davor. Dabei kann bei Selektion der Nachbarzellen auf den Test der Fahrtrichtung
verzichtet werden, da Knotenzufahrten lediglich ein Nachbar zugeordnet wird, der
vor ihnen liegt. Der zweite Teil wählt über die Sicht m signalbild rot die auf Rot geschalteten Signalgeber aus. Dabei muss beschrieben werden, dass die Ampel während
des Wechsels von einer zur anderen Zelle auf Rot geschaltet ist. Aufgrund der Diskretisierung wird dafür auch die Sicht m signalbild rot zweimal benötigt. Die beiden
Inputs von Fahrzeugen und Signalgebern werden schließlich durch einen Join über
die Knotenzufahrt verknüpft. Die Existenz eines Grünpfeils, der Rechtsabbiegern
das Einfahren in die Kreuzung bei Rot erlaubt, wird ausgeschlossen.
Der WHERE-Teil enthält den erforderlichen Zeit-Vergleich. Ähnlich wie in der Abfrage zur Vorfahrtmissachtung liegt in der Prüfabfrage für den Rotlichtverstoß ein
Problem darin, dass die Phasenschaltung in größeren Abständen dokumentiert wird
als die Fahrzeuge. Daher kann nicht für jeden möglichen Simulationsschritt ein Signalbild aus der Datenbank gelesen werden. Die Lösung liegt auch hier im Einsatz
einer Maximumsberechnung, um z.B. zu überprüfen, ob beim Ereignis ’Fahrzeug auf
Knotenzufahrt’ der Zustand ’Signalgeber zeigt Rot an’ eintritt:
l1.zeit=(SELECT max(l.zeit) FROM m_signalbild l
WHERE l.zeit < ff.zeit AND
l.signalgeber_id = l1.signalgeber_id)
133
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Des Weiteren soll eine auf Rot geschaltete Ampel im Sichtfeld des Fahrzeugführers
liegen. Aus diesem Grund muss die Ampel bei Befahren der Knotenzufahrt bereits
eine Zeiteinheit auf Rot geschaltet sein. Daher wird nach einem Signalbildeintrag
gesucht, der vor dieser Zeit des betroffenen Fahrzeugs liegt (l.zeit < ff.zeit). Für die
Fahrzeugposition im Kreuzungsbereich direkt vor der Ampel ist hingegen der aktuelle Datensatz zu selektieren, weswegen eine Gleichheit beider Zeiten zu bevorzugen
ist. Damit lässt sich die Überprüfung des Regelverstoßes wie folgt in SQL umsetzen:
SELECT DISTINCT ff.fahrzeug_id, ff.zeit_1 AS zeit, z1.knoten_id
FROM
((fahrzeug_1_2_LE AS ff
INNER JOIN knotenzufahrt AS z1 ON ff.zellen_id_1=z1.zellen_id)
INNER JOIN
(SELECT * FROM nachbarzellen WHERE nachbarzellen.lage=’V’) AS n
ON n.zellen_id=ff.zellen_id_1 AND n.nachbar_id = ff.zellen_id_2)
INNER JOIN
(m_signalbild_rot AS l1
INNER JOIN m_signalbild_rot AS l2
ON l1.signalgeber_id=l2.signalgeber_id)
ON l1.zellen_id=ff.zellen_id_1
WHERE l1.zeit=(SELECT max(l.zeit) FROM m_signalbild l
WHERE l.zeit < ff.zeit_1 AND
l.signalgeber_id = l1.signalgeber_id)
AND l2.zeit=(SELECT max(l.zeit) FROM m_signalbild l
WHERE l.zeit <= ff.zeit_2 AND
l.signalgeber_id = l2.signalgeber_id);
Abbiegen gemäß vorgeschriebener Fahrtrichtung
Die Fahrtrichtungszeichen schreiben vor, in welche Richtung es Fahrzeugen erlaubt
ist, abzubiegen. Im Einzelnen muss ein Verstoß gegen die vorgeschriebene Fahrtrichtung die folgenden zwei Bedingungen erfüllen:
1. Das Fahrzeug befindet sich auf einer Knotenzufahrt, der ein Fahrtrichtungszeichen zugeordnet ist.
2. Zu einem späteren Zeitpunkt befindet sich das Fahrzeug auf einer Abfahrt, die
gemäß der vorgeschriebenen Fahrtrichtung verboten ist.
linke_abfahrt
rechte_abfahrt
abfahrt_gegenüber
Abbildung 7.10: Zuordnung der Zeichen zu nicht erlaubten Abfahrten
134
7.2 Ausgewählte Aspekte des Monitorings
Für die Überprüfung dieser Ordnungswidrigkeit wurden fünf verschiedene Ausprägungen der Fahrtrichtungszeichen betrachtet: ’links’, ’rechts’, ’geradeaus’, ’links und
geradeaus’ sowie ’rechts und geradeaus’. Bezogen auf das Erkennen einer Ordnungswidrigkeit können sie jeweils einer oder zwei der drei verbotenen Richtungen
bzw. Abfahrten links, rechts oder geradeaus zugeordnet werden (siehe Abbildung
7.10). Somit besteht die Anfrage aus drei Teilanfragen, die durch eine Vereinigung
(UNION) zu einem Endergebnis verbunden wird:
SELECT unerlaubt.fahrzeug_id, unerlaubt.zeit, k.knoten_id
FROM knotenzufahrt k
INNER JOIN
(rechts_unerlaubt
UNION
links_unerlaubt
UNION
geradeaus_unerlaubt) AS unerlaubt
ON unerlaubt.zellen_id = k.zellen_id;
Auf diese Weise wird zum Beispiel das Zeichen mit nach links zeigendem Pfeil
den zwei Kategorien rechts und geradeaus zugeordnet. In den dafür zuständigen
Unterabfragen rechts unerlaubt und geradeaus unerlaubt wird dann überprüft, ob
ein Fahrzeug den Knoten über die verbotenen Knotenabfahrten verlässt. Die Sicht
rechts unerlaubt, die für die Fahrtrichtungszeichen ’209-10’, ’209-30’ und ’214-10’
zutrifft, lässt sich folgendermaßen umsetzen:
CREATE VIEW rechts_unerlaubt AS
(
(SELECT ff.fahrzeug_id, ff.zeit_1 AS zeit,
ff.zellen_id_1 AS zellen_id
FROM
(
(SELECT verkehrszeichen.zeichen_id FROM verkehrszeichen
WHERE verkehrszeichen.stvo_zeichen_nr=’209-10’
Or verkehrszeichen.stvo_zeichen_nr=’209-30’
Or verkehrszeichen.stvo_zeichen_nr=’214-10’) AS v
INNER JOIN zeichen_zuordnung zz
ON v.zeichen_id=zz.zeichen_id
)
INNER JOIN
(
fahrzeug_1_2_LE AS ff
INNER JOIN rechte_abfahrt ra
ON ra.zellen_id_rechteAbfahrt=ff.zellen_id_2
AND ff.zellen_id_1=ra.zellen_id_zufahrt
)
ON zz.zellen_id=ff.zellen_id_1)
)
135
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Die Sicht besteht aus zwei logisch trennbaren Teilabfragen, die sich an den oben beschriebenen Kriterien orientieren. Zum einen werden alle Zufahrten selektiert, denen
ein Verkehrszeichen mit nach links oder geradeaus zeigendem Pfeil zugeordnet sind.
Zum anderen extrahiert die Abfrage solche Fahrzeuge, die von einer Zufahrt über
eine rechte Abfahrt die Kreuzung verlassen. Ordnungswidrig verhalten sich all diejenigen Fahrzeuge, die durch den Join dieser beiden Teilergebnisse über die zellen id
der Zufahrt einen Verbundpartner finden. Die Entscheidung für eine Unterteilung
in drei Kategorien wird insbesondere durch die vorliegenden Tabellen linke abfahrt,
rechte abfahrt und abfahrt gegenüber motiviert. Jede der verbotenen Fahrtrichungen kann einer der Relationen zugeordnet werden. Obige Sicht lässt sich daher für
die Sichten links unerlaubt und geradeaus unerlaubt anpassen, indem die entsprechenden Verkehrzeichen gemäß Abbildung 7.10 selektiert werden und die Tabelle
rechte abfahrt im FROM-Teil durch die Tabelle linke abfahrt bzw. abfahrt gegenüber
ersetzt wird.
Optimierung der Anfragen
Die Tabelle sm fahrzeug wird in jedem Simulationsschritt mit neuen Daten gefüllt,
sodass sie sehr große Mengen von Daten enthalten kann. Jeden zweiten Takt, beispielsweise jede Sekunde, müssen dabei sieben Anfragen über dieser Tabelle ausgewertet werden. Jede Anfrage referenziert dabei allein die Tabelle sm fahrzeug mindestens zweimal, weitere Tabellen müssen ebenfalls einbezogen werden. Dies macht
die Anfrage besonders aufwändig, sodass eine möglichst effiziente Variante der Anfrageformulierung zu finden ist. Im Folgenden soll auf allgemeine Aspekte der Anfrageoptimierung eingegangen werden, die bei den zuvor beschriebenen Regelverstößen
von Bedeutung waren.
Um die Anzahl der Datensätze zu beschränken, merkt sich der Monitor in einer
Variablen last checked den Zeitpunkt, zu dem er das letzte Mal die Anfrage ausgeführt hat. Anstatt die gesamte Tabelle für einen Join bereitzustellen, wird der
Input mittels zeitlicher Bereichsanfrage eingegrenzt und die Anzahl der Tupel reduziert:
PreparedStatement pst = Connection_Manager.getCon().prepareStatement(
"... INNER JOIN
(SELECT * FROM sm_fahrzeug WHERE zeit<=? AND zeit > ?) AS f2
ON ... ");
pst.setInt(1, now);
pst.setInt(2, last_checked);
Dadurch können die Fahrzeugpositionen zu einem der Fahrzeuge reduziert werden.
Die vorangestellte Selektion kann auf derjenigen Referenz der Tabelle sm fahrzeug
angewandt werden, die ein Fahrzeug zum letztmöglichen Zeitpunkt repräsentiert.
Eine Anwendung dieser Optimierung auf alle Eingaben der Fahrzeugtabelle würde
zur Folge haben, dass Ergebnisse vorab unbeachtet bleiben, wenn es zum Abfragezeitpunkt noch keinen Regelverstoß zu melden gibt.
136
7.2 Ausgewählte Aspekte des Monitorings
Ein weiterer Effekt dieser Bereichsanfrage liegt in der Vermeidung von Duplikaten
bezüglich erkannter Regelverstöße. Ordnungswidrigkeiten würden ohne zusätzliche
Selektion in das Endergebnis mit aufgenommen, solange ihre beteiligten FahrzeugTupel noch nicht aus der Tabelle sm fahrzeug gelöscht wurden. Durch die verwendete
Zeitspanne können Fahrzeuge in einer bestimmten Rolle nur einmal betrachtet werden. Somit kann vermieden werden, dass ein Regelverstoß dem Benutzer mehrmals
angezeigt wird, obwohl sich das Fahrzeug bereits aus dem Überwachungsbereich heraus bewegt hat. Ebenso wird der Regelverstoß nur einmal geloggt.
Um die Performanz verschiedener Varianten von Anfrageformulierungen zu vergleichen und eine bestmögliche Variante auswählen zu können, wurde die benötigte
Anfragedauer gemessen. Abbildung 7.11 zeigt beispielhaft die Messergebnisse der
Anfrage für die Überprüfung des Rotlichtverstoßes. Die bereits in diesem Abschnitt
vorgestellte SQL-Anfrage wurde mithilfe von Joins umgesetzt. Anstelle von Joins
ist im FROM-Teil jedoch auch eine simple Liste von Tabellen im Sinne von Kreuzprodukten denkbar, wobei die Bedingungen alle im WHERE-Teil überprüft werden.
Auch eine Formulierung der Bedingungen durch EXISTS ist möglich, sodass der
FROM-Teil lediglich die zur Ausgabe notwendigen Tabellen enthält. Das Diagramm
zeigt die Dauer der drei Anfragen in Millisekunden bezüglich der Simulationszeit.
Die Dauer eines Simulationsschrittes in diesen Messungen beträgt 500 ms. Um einen
besseren Vergleich zu ermöglichen, wurde für jede Kurve eine Trendlinie erstellt.
Rotlichtverstoß
1000
Kreuzprodukt
900
Anfragedauer (ms)
800
Join
700
Exists
600
500
Gleitender Durchschnitt
(Kreuzprodukt)
Gleitender Durchschnitt
(Join)
Gleitender Durchschnitt
(Exists)
400
300
200
100
0
0
100
200
300
400
500
Simulationsschritt
Abbildung 7.11: Analyse der Performanz
Die Messungen ergeben, dass die Variante mit EXISTS bedeutend schlechtere Ergebnisse liefert als eine Formulierung mit JOIN oder Kreuzprodukt. Dies lässt sich
insbesondere darauf zurückführen, dass mit korrelierten Unterabfragen gearbeitet
werden muss, welche für jeden Datensatz neu zu berechnen sind. Schließlich zeigt
sich, dass sich die Formulierung mit Kreuzprodukt verglichen mit der JOIN-Variante
137
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
durch eine sehr ähnliche Anfragedauer auszeichnet. Die geringen Differenzen lassen
sich erklären, wenn man einen Blick in den von MS Access generierten Auswertungsplan der Anfrage wirft. Durch eine DBMS-interne Optimierung der KreuzproduktAnfrage wird erreicht, dass die Kreuzprodukte zur Auswertung durch eine Folge von
Joins ersetzt werden.
Eine weitere Analyse des Auswertungsplans macht deutlich, dass sich der ’query
optimizer’ des Datenbankmanagementsystems an den Veränderungen der Tabellen
orientiert. Mit Fortschreiten der Simulationszeit wird die Anfragebearbeitung stets
an die Eigenschaften der Tabellen angepasst. Dies macht sich insbesondere durch
Umordnung von Joins bemerkbar.
Zudem zeigt das Diagramm, dass die Überwachung von Verkehrsszenarien bei einer Simulationsschrittdauer von 500 ms in Echtzeit zu bewältigen ist. Jede Sekunde
- jeden zweiten Takt - wird die Abfrage neu ausgewertet, ohne dass die Anfragedauer
die Umlaufzeit übersteigt.
Eine erheblich bessere Performanz wurde darüber hinaus auch durch eine Materialisierung von Views erreicht. So müssten beispielsweise die Views linke zufahrt
oder zufahrt quer in jeder Anfrage neu berechnet werden. Dieser Zeitaufwand lässt
sich daher durch eine Materialisierung umgehen (vgl. Abschnitt 5.2.2).
7.2.2
Verwaltung von Simulationsdaten und Regelverstößen
Dieser Abschnitt beschäftigt sich mit der Verwaltung der Daten über Fahrzeuge
und LSAs, die für das Monitoring von Regelverstößen relevant sind. Einerseits soll
eine angemessene Protokollierung von Regelverstößen stattfinden, die eine eindeutige Rekonstruktion eines Szenarios in der Logging-Ansicht ermöglicht. Zum anderen ist es für die Stabilität des Systems von großer Bedeutung, dass eine effiziente
Löschstrategie über den vom Simulator produzierten Daten eingesetzt wird.
Zur Organisation erkannter Regelverstöße sind vier Tabellen erforderlich:
m_regelverstoss_kat(regelverstoss_kat_id, stvo_ref, Beschreibung)
m_logRegelverstoss(regelverstoss_id, regelverstoss_kat_id,
log_zeit, fahrzeug_id)
m_logFahrzeug(regelverstoss_id, zeit, fahrzeug_id, zellen_id,
blinker, geschwindigkeit, fahrtrichtung)
m_logLSA(regelverstoss_id, zeit, lsa_id, phase, in_betrieb)
Die Tupel der Tabelle m logRegelverstoss repräsentieren die erkannten Regelverstöße.
Es werden die Informationen über den Typ des Regelverstoßes, den Zeitpunkt des Erkennens und das schuldige Fahrzeug vermerkt. Die Regelverstöße sollen dabei in Reihenfolge ihres Auftretens durchnummeriert werden. In der Tabelle m logRegelverstoss
wird daher sofort ein neuer Datenbankeintrag mit neuer ID angelegt, sobald eine Abfrage ein positives Ergebnis erbracht hat. Die restlichen Daten zu Fahrzeugen und
LSAs werden im Anschluss protokolliert. Um zu verhindern, dass das Protokollieren
138
7.2 Ausgewählte Aspekte des Monitorings
der zu einem Regelverstoß gehörigen Datensätze den weiteren Verlauf der Verkehrsbeobachtung aufhält, ist diese Aufgabe stets in einen eigenen Thread ausgegliedert.
Damit können die Knoten weiterhin in regelmäßigen Abständen kontrolliert werden,
selbst wenn das Logging mehr Zeit in Anspruch nehmen würde.
Logging von Fahrzeugen und LSA
Wird ein Regelverstoß in einem gewissen Simulationsschritt erkannt, müssen die
Fahrzeuginformationen geloggt werden, die diese Ordnungswidrigkeit charakterisieren (siehe Abbildung 7.12). Relevant ist dabei jeweils der gesamte Datensatz aus der
Tabelle sm fahrzeug, weil dadurch ein Fahrzeug zu einem gewissen Zeitpunkt mit all
seinen Eigenschaften dokumentiert ist. Die Anzahl der zu speichernden Fahrzeuge
variiert mit der Kategorie der Regelverstöße. Ist der Regelverstoß von einem anderen
Fahrzeug abhängig, wie es z.B. bei der Vorfahrtverletzung der Fall ist, so wird neben
dem schuldigen Fahrzeug auch dieses protokolliert. Es wird angenommen, dass sich
die Straßentopologie nicht ändert, sodass sie nicht gesondert abgespeichert werden
muss. Bei erneutem Abspielen eines Regelverstoßes lässt sich auf die Basistabellen
zugreifen, welche in Abschnitt 5.2.2 beschrieben wurden.
Für das Logging von Regelverstößen stellt sich die Frage, wie viele Datensätze
jeweils relevant sind, um den Regelverstoß später wieder eindeutig rekonstruieren
zu können. So kann das Intervall um den Meldezeitpunkt herum nicht mit einer
bestimmten Zeitspanne festgelegt werden, da dies je nach Verkehrssituation stark
variieren kann. Wichtig ist es stets, den Weg des Fahrzeugs mindestens von seiner
Knotenzufahrt bis zur Knotenabfahrt verfolgen zu können. Die Dauer, die sich ein
Fahrzeug innerhalb des Knotens aufhält, ist jedoch abhängig von der Größe des
Knotens, der Verkehrsdichte, der Ampelschaltung und möglichem Gewähren der
Vorfahrt/des Vorrangs.
Abbildung 7.12: Logging von Fahrzeugen
Um die relevanten Datensätze eines Fahrzeugs einzugrenzen, wurde daher die ID des
Knotens herangezogen. Dies hat zwei positive Auswirkungen. Zum einen wird sichergestellt, dass alle für den Regelverstoß notwendigen Fahrzeuge und LSA-Schaltungen
in der Datenbank gespeichert werden. Zum anderen wird verhindert, dass Positionen des Fahrzeugs geloggt werden, die sich außerhalb des Knotens befinden. Dies
139
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
ermöglicht dem GUI bei Aufruf eines Regelverstoßes in der Logging-Ansicht, eine
eindeutige Kreuzung darstellen zu können. Die Tabelle m logFahrzeug wird schließlich unter Beachtung des Straßenknotens durch Kopieren der Daten aus der Simulationstabelle sm fahrzeug gefüllt:
//Iteriere über beteiligte Fahrzeuge
for(int i = 0; i<_fahrzeug_id.length;i++)
{
String ins_f =
" INSERT INTO m_logFahrzeug" +
" (fahrzeug_id, zellen_id, blinker, geschwindigkeit, "+
" fahrtrichtung, zeit, regelverstoss_id) "+
" SELECT s.fahrzeug_id, s.zellen_id, s.blinker, "+
"
s.geschwindigkeit, s.fahrtrichtung,s.zeit,"+new_id+
" FROM sm_fahrzeug s INNER JOIN zelle k "+
"
ON s.zellen_id = k.zellen_id "+
" WHERE k.knoten_id = "+_knoten_id+
" AND s.fahrzeug_id = "+_fahrzeug_id[i];
Connection_Manager.db_update(ins_f);
}
Für eine eindeutige Rekonstruktion des Regelverstoßes ist auch die Steuerung der
Lichtsignalanlagen von Bedeutung. Sofern dem Knoten Signalgeber zugeordnet sind,
werden auch die zeitlich zugehörigen Datensätze aus der Tabelle sm lsa zur Archivierung in die Tabelle m logLSA kopiert. In der Logging-Ansicht lassen sich alle
Regelverstöße abspielen, die in der Tabelle m logRegelverstoss hinterlegt wurden.
Letztlich ist eine Entscheidung zu treffen, wie lange die gespeicherten Regelverstöße
in den Tabellen archiviert werden sollen. Hierbei wird dem Benutzer die Wahl gelassen, ob die Regelverstöße manuell vom Benutzer oder nach dem Schließen der
Anwendung automatisch gelöscht werden sollen.
Löschen von Datensätzen
Die Positionen und Eigenschaften der Fahrzeuge sowie die Zustände der Lichtsignalanlagen werden fortlaufend in die Tabellen sm fahrzeug und sm lsa eingefügt.
Dies lässt die Größe der Tabellen schnell anwachsen, was sich in der Performanz der
Anfragebearbeitung bemerkbar macht. Es ist jedoch nicht notwendig, die Daten auf
lange Zeit hinweg zu speichern. Daher ist es sinnvoll, in regelmäßigen Abständen die
für das Monitoring nicht mehr relevanten Daten zu löschen. Zu beachten ist hierbei,
dass keine Datensätze gelöscht werden, die potentiell noch an einem Regelverstoß
beteiligt sein könnten. Ein frühzeitiges Löschen kann ein fehlerhaftes Verhalten des
Monitors hervorrufen, zu seltene Löschanfragen gehen hingegen zu Lasten der Effizienz. Des Weiteren ist die Löschstrategie so zu wählen, dass sie den weiteren Verlauf
der Simulation und des Monitorings nicht beeinträchtigt.
140
7.2 Ausgewählte Aspekte des Monitorings
Um die Datenbankzugriffe anderer Prozesse nicht zu beeinflussen, werden lediglich alle 50 Simulationsschritte irrelevante Datensätze gelöscht. Ein genaue Betrachtung der Regelverstöße ergab, dass das Befahren einer Knotenzufahrt den letzten
relevanten Zustand für eine Beteiligung an einem Regelverstoß darstellt, bevor ein
Fahrzeug den Überwachungsbereich verlässt. Da die Überwachung in Echtzeit durchgeführt wird, werden daher Datensätze von Fahrzeugen, die sich außerhalb des
Überwachungsbereichs befinden, nicht mehr benötigt.
Um das Löschen dieser Datensätze durchzuführen, wird die Tabelle fahrzeug herangezogen, die die aktuellen Fahrzeugpositionen bereitstellt. Die Bedingung zellen id
= null stellt ein angemessenes Löschen sicher, da ein Null-Wert besagt, dass das
Fahrzeug sich zur Zeit in keinem Überwachungsbereich befindet. Diese Bedingung
reicht jedoch nicht aus, da es vorkommen kann, dass das Fahrzeug bereits aus der
Tabelle fahrzeug gelöscht wurde und dann der Test auf Null nie TRUE werden
kann. Aus diesem Grund wird noch ein Test auf Existenz durchgeführt, sodass sich
die Löschstrategie wie folgt umsetzen lässt.
DELETE FROM sm_fahrzeug s
WHERE s.fahrzeug_id IN (SELECT fahrzeug_id
FROM fahrzeug
WHERE zellen_id = null) OR
s.fahrzeug_id NOT IN (SELECT fahrzeug_id
FROM fahrzeug)
Das regelmäßige Löschen der Daten reduziert somit insbesondere den Aufwand zur
Überwachung der Regelverstöße und stellt hinsichtlich Privatsphäre zusätzlich sicher, dass die Daten nicht länger als nötig gespeichert bleiben.
7.2.3
Aktualisierung des GUIs auf Zellenebene
Die grafische Benutzeroberfläche stellt die Schnittstelle zwischen Benutzer und dem
System dar. Eine der Herausforderungen dieser Arbeit ist es, ein möglichst benutzerfreundliches GUI zu gestalten, mit der die Aufgaben intuitiv gelöst bzw. leicht
erlernt werden können und die Darstellung zudem möglichst ästhetisch wirkt. An
dieser Stelle soll auf die Aktualisierung des GUIs eingegangen werden, womit stellvertretend ein Einblick in die Implementierungstechniken des Monitor-GUIs gegeben
werden soll.
Bereits in den vorherigen Kapiteln wurde auf den objektorientierten Aufbau und
die Synchronisation des GUIs eingegangen. An dieser Stelle soll die Implementierung
näher erläutert werden, welche den einzelnen Komponenten – Zellen, Verkehrszeichen und Signalgebern – die Aufgabe überträgt, selbstständig ihren Zustand zu
aktualisieren. Die Methode refresh view() der Klasse Crossing initialisiert bei jeder Zustandsänderung den Aktualisierungsprozess eines für den Benutzer sichtbaren
141
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
Überwachungsbereiches. Sie iteriert über sämtliche in der Karte enthaltenen GUIKomponenten, die aufgrund von Vererbung letztlich ein Objekt vom Typ MapComponent sind und alle die Methode refresh() implementieren:
protected void refresh_view() {
Component [] comps = getJPanel_map().getComponents();
for (int i= 0; i< comps.length; i++)
{
((MapComponent) comps[i]).refresh();
}
}
Beispielhaft soll an dieser Stelle die Aktualisierung einer Zelle beschrieben werden.
Ist durch Dynamic Binding eine Kartenkomponente als Zellenobjekt identifiziert
worden, so wird die Methode refresh() der Klasse Zelle aufgerufen.
Dank des eindeutigen Attributes zellen id, welches entsprechend der Datenbank auch
die GUI-Komponente besitzt, kann die aktuelle Belegung einer Zelle aus der Datenbank abgefragt werden:
SELECT fahrzeug_id, blinker, fahrtrichtung
FROM fahrzeug WHERE zellen_id = "+zellen_id
In Abschnitt 6.3.2 wurde bereits die Kompositionsbeziehung zwischen Fahrzeug und
Zelle beschrieben. Liefert die SQL-Anfrage eine Ergebnismenge zurück, lässt sich
mithilfe dieser Informationen der in Zelle enthaltenen Fahrzeugvariable ein neues
Objekt zuweisen:
Fahrzeug f;
...
f= new Fahrzeug(Fahrzeug.getFarbe(fahrzeug_id),
blinker,fahrtrichtung, fahrzeug_id,
DB_Check.istGemeldet(fahrzeug_id, knoten_id));
Hierbei werden zwei an das GUI angepasste Eigenschaften sichtbar. Zum einen
wird anhand der Fahrzeug-ID eine Fahrzeug-Farbe bestimmt, welche durch ModuloBerechnungen evaluiert wird und den Fahrzeugen ein für den Benutzer besser unterscheidbares Kriterium verleihen soll. Weiterhin ist die Aufgabe des MonitoringSystems, dem Benutzer in Echtzeit erkannte Regelverstöße mitzuteilen. Auch dies
soll visuell unterstützt werden, indem der Zellenhintergrund rot gefärbt wird, wenn
sich darauf ein geloggtes Fahrzeug befindet. Die Klasse DB Check führt daher eine Hashmap, die zu gegebenen IDs von Fahrzeug und Knoten zurückliefert, ob das
Fahrzeug einen Regelverstoß begangen hat.
Am Ende der refresh()-Methode wird schließlich die Java-interne Methode repaint()
aufgerufen, die letztlich das Neuzeichnen des Zellenobjektes veranlasst. Die hierdurch aufgerufene Methode paintComponent() wurde in den Klassen der Kartenkomponenten überschrieben und an die benötigte Darstellung angepasst. Im Falle der Zelle wird auf das zuvor erzeugte Fahrzeugobjekt zugegriffen. Ist ihm ein
142
7.2 Ausgewählte Aspekte des Monitorings
Fahrzeug zugewiesen, wird eine den Fahrzeugeigenschaften entsprechende Grafik
erstellt. Zu Optimierungszwecken wird diese Aktualisierung nur dann initialisiert,
wenn sich die Werte der Fahrzeugvariable im Vergleich zum vorherigen Simulationsschritt geändert haben.
Das Fenster, welches dem Benutzer zur Beobachtung des Verkehrs angezeigt wird, ist
in seiner Größe frei modifizierbar. Der Layout-Manager übernimmt dabei automatisch die Größenanpassung der einzelnen Zellen. Problematisch erweist sich jedoch
die Darstellung der Grafiken, die von dieser Java-seitigen Regulierung nicht berührt
wird. Dies führt zunächst dazu, dass beispielsweise die Grafik eines Fahrzeugs nur
zur Hälfte sichtbar ist.
Um dies zu verhindern, muss zur Skalierung der Grafik der Aufruf der Zeichenmethode abhängig von der Zellengröße mit unterschiedlichen Parametern aufgerufen
werden. Die simple Einbeziehung der aktuellen Zellengröße der einzelnen betroffenen
Zellen ist in diesem Fall nicht ausreichend. Da nicht ausgeschlossen werden kann,
dass alle Zellenkomponenten einer Karte die gleiche Dimension haben, würde ein
und dasselbe Fahrzeug während seiner Fortbewegung in unterschiedlichen Größen
dargestellt, was eine verwirrende Wirkung für den Benutzer hätte.
Die Lösung besteht darin, dass sich alle Zeichnungen an einer einheitlichen Größe
orientieren. Aus diesem Grund kommt hier das Model-View-Controller-Pattern zum
Einsatz. Das Modell wird durch eine Variable repräsentiert, welche die aktuelle minimale Dimension aller Zellen speichert. Die Klasse Crossing reagiert mithilfe eines
ComponentListeners des Java-Pakets java.awt.event auf Größenveränderung. Bei
Auslösung eines Ereignisses, wird die minimale Dimension durch Iteration über alle Kartenkomponenten neu berechnet und der Variable zugewiesen. Die einzelnen
Instanzen der GUI-Klasse Zelle können darauf nun in jedem Aktualisierungsschritt
zugreifen. Die Grafiken werden mithilfe der Methode drawImage() auf die minimale
Zellengröße skaliert und zentriert auf der Zelle gezeichnet.
143
7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG
144
Kapitel 8
Zusammenfassung und Ausblick
Ziel dieser Arbeit war der Entwurf und die Entwicklung des Systems SiMo“, das
”
sich aus einem Verkehrssimulator und einem Monitor zur Überwachung von Regelverstößen im Straßenverkehr zusammensetzt. Der Simulator produziert die Daten,
die vom Monitor ausgewertet werden. Das Ergebnis von Simulation und Überwachung
wird auf einer grafischen Benutzeroberfläche (GUI) visualisiert. Das besondere Merkmal stellt der Einsatz der Datenbanksprache SQL dar, wodurch die relevanten Informationen zur Beobachtung von Regelverstößen analysiert werden. Eine Formulierung von Verkehrsregelverstößen in SQL erwies sich als gute Alternative zu einer
Umsetzung durch ein externes Softwaresystem. SQL wird ebenso vom SimulatorTeilsystem zur Einhaltung der Verkehrsregeln eingesetzt.
Der Simulation liegen die Theorien der diskreten Ereignissimulation sowie der Multiagentensimulation zugrunde. Der Simulator orientiert sich an einem mikroskopischen
Modell, bei dem sich jedes Fahrzeug durch ein eigenes Verhalten auszeichnet. Eine Modellierung verschiedener Fahrerprofile ermöglicht die Erzeugung von sowohl
regelgerechtem als auch regelwidrigem Fahrverhalten. Darüber hinaus unterstützt
die Simulation den mehrspurigen Verkehr mit der Möglichkeit, einen Spurwechsel
durchzuführen.
Die Abstraktion des Straßennetzes orientiert sich an der Theorie der zellularen Automaten. Die Straßen werden als eine Aneinanderreihung von Zellen modelliert und als
Datensätze in einer Datenbank abgelegt. Die Datenbank enthält zusätzlich Informationen über bestehende Verkehrszeichen und Lichtsignalanlagen. Zur dynamischen
Darstellung des Simulationsgebietes auf dem GUI stehen diese Daten sowohl dem
Simulator als auch dem Monitor zur Verfügung. Die Simulation bildet exemplarisch
einen realen Ausschnitt aus dem Stadtgebiet Bonn-Nord nach. Der Simulator simuliert Fahrzeuge und Ampelschaltungen im gesamten Simulationsgebiet. Die Datenerfassung für den Monitor beschränkt sich jedoch auf Kreuzungen und Einmündungen.
Die Überwachung und die Visualisierung erfolgt in Echtzeit während des laufenden
Simulationsbetriebs. Regelverstöße werden dem Benutzer mitgeteilt und zum erneuten Abspielen protokolliert.
145
8 ZUSAMMENFASSUNG UND AUSBLICK
In dieser Arbeit wurden intensiv Methoden der Softwaretechnologie eingesetzt. Dies
reichte von der Anforderungserhebung bis zur Implementierung. Modularität und
Erweiterbarkeit haben dabei eine große Rolle gespielt. Die Implementierung des
GUIs sowie der Controller erfolgte in der Programmiersprache Java.
Das SiMo“-System stellt bereits zahlreiche Funktionalitäten zur Verfügung, ist aber
”
dennoch erweiterungsfähig. Der Regelung der Geschwindigkeit liegt ein binäres Modell zugrunde. Eine Umsetzung auf der Grundlage des Nagel-Schreckenberg-Modells
könnte die Fortbewegung der Fahrzeuge realitätsnäher beschreiben (vgl. Unterkapitel 4.4). Der Spurwechsel geschieht momentan nur im Fall, dass sich das Fahrzeug
nicht auf seiner Abbiegespur bzw. Zielspur befindet. Ein Spurwechsel zur Stauvermeidung würde ebenso zur Realitätstreue beitragen. Eine Erweiterung der bei der
Simulation unterstützten Verkehrsregeln ist denkbar. Die Fahrerprofile können genauso ergänzt werden, um weiteres regelwidriges Fahrverhalten zu unterstützen.
Darunter fällt beispielsweise das Provozieren von Unfällen.
Der Monitor lässt sich um die Überwachung weiterer Regelverstöße erweitern. So
könnte er beispielsweise für die Beobachtung der Fahrzeuggeschwindigkeit eingesetzt werden. Des Weiteren wurden bisher keine abknickenden Vorfahrten oder die
Existenz des Grünpfeils betrachtet. Mit einer Erweiterung des gesamten Systems
um andere Arten von Verkehrsteilnehmern wie beispielsweise Straßenbahnen oder
Fahrradfahrern würden sich weitere Möglichkeiten ergeben.
Zur Zeit laufen die beiden Teilsysteme Monitor und Simulator auf einem einzigen
Rechner. Sie müssen sich die Systemressourcen teilen und stehen dadurch in Konkurrenz zueinander. Dies führt zu einer maximalen CPU-Auslastung und wirkt sich
folglich auf die Effizienz aus. Im späteren Einsatz des Systems entfällt jedoch die
Arbeit des Simulators. Daher bietet sich zur Verbesserung der Performanz an, das
System als verteiltes System zu realisieren. Dadurch können die beiden Teilsysteme
unabhängig voneinander bezüglich Ressourcen in Betrieb genommen werden.
Als Datenbankmanagementsystem wurde MS Access eingesetzt. Im Hinblick auf eine
Performanzsteigerung ist ein Vergleich mit dem Einsatz eines anderen Datenbankmanagementsystems wie beispielsweise Oracle von Interesse. Oracle bietet einerseits
einen leistungsstärkeren Query Optimizer. Zum anderen verfügt Oracle über verschiedene Funktionalitäten, die von MS Access nicht unterstützt werden. Trigger,
Stored Procedures sowie materialisierte Views mit Änderungspropagierung könnten
für dieses System von Nutzen sein. Eine Migration zu einem anderen DBMS kann ohne großen Aufwand erfolgen, da bei der Implementierung des SiMo“-Systems darauf
”
geachtet wurde, dass keine Access-spezifischen Funktionalitäten benutzt werden.
146
Literaturverzeichnis
[AJ05]
Alan, Shalloway; James, Trott: Design patterns explained. 2. Auflage.
Addison-Wesley, 2005
[BDM07] Behrend, Andreas; Dorau, Christian ; Manthey, Rainer: TinTO: A
Tool for the View-Based Analysis of Streams of Stock Market Data. In:
DASFAA Bd. 4443, Springer, 2007 (Lecture Notes in Computer Science),
1110-1114
[Beh07]
Behrndt, Maren: Diplomarbeit Entwurf und Implementierung eines
”
datenbankgestützten, graphischen Werkzeugs zur Analyse von Verkehrsszenarien“. Universität Bonn, 2007
[Bod07]
Bode, Thomas: Folien der Vorlesung Relationale Datenbanken II“.
”
Wintersemester 2006/2007. Universität Bonn, 2007
[Bos94]
Bossel, Hartmut: Modellbildung und Simulation. Vieweg Verlagsgesellschaft, 1994
[BSL98]
Bandini, Stefania; Serra, Roberto ; Liverani, Furio S.: Cellular automata. Springer, 1998
[Buna]
Bundesministerium der Justiz: Gesetz über Ordnungswidrigkeiten. http://www.bundesrecht.juris.de/bundesrecht/owig_1968/
gesamt.pdf, Abruf: 14. 06. 2008
[Bunb]
Bundesministerium der Justiz: Straßenverkehrs-Ordnung. http://
www.bundesrecht.juris.de/bundesrecht/stvo/gesamt.pdf, Abruf:
14. 06. 2008
[CHKS03] Cammert, Michael; Heinz, Christoph; Krämer, Jürgen ; Seeger,
Bernhard: Datenströme im Kontext des Verkehrsmanagements. In: Mobilität und Informationssysteme, ETH Zürich, Departement Informatik,
Institut für Informationssysteme, 2003
[Eck03]
Eckel, Bruce: Thinking in Java. 3. Auflage. Pearson Education, 2003
[EN02]
Elmasri, Ramez; Navathe, Shamkant B.: Grundlagen von Datenbanksystemen. 3. Auflage. Pearson Studium, 2002
147
LITERATURVERZEICHNIS
[Fab]
Fabrice Constants: Guide d’optimisation de vos applications Microsoft ACCESS. ftp://ftp-developpez.com/loufab/optimisation.
pdf, Abruf: 14. 06. 2008
[For00]
Forschungsgesellschaft für Straßen- und Verkehrswesen:
Begriffsbestimmungen Teil Verkehrsplanung, Straßenentwurf und Straßenbetrieb, Ausgabe 2000. FGSV-Verlag Köln, 2000
[Fra]
Fraunhofer-Gesellschaft-IAIS:
citytraffic.de, Abruf: 15. 06. 2008
City-Traffic.
http://www.
[GHJV02] Gamma, Erich; Helm, Richard; Johnson, Ralph ; Vlissides, John:
Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software. 1. Auflage. Addison-Wesley München, 2002
[He07]
He, Zhengyu: Diplomarbeit Entwurf und Implementierung eines da”
tenbankgestützten Simulators für Verkehrsszenarien“. Universität Bonn,
2007
[Hen07]
Hentschel, Peter: Straßenverkehrsrecht. 39. Auflage. C.H.Beck, 2007
[Jen99]
Jennings, Nicholas R.: Agent-Oriented Software Engineering. In: Proceedings of the 9th European Workshop on Modelling Autonomous Agents
in a Multi-Agent World : Multi-Agent System Engineering (MAAMAW99), 1999
[KE06]
Kemper, Alfons; Eickler, André:
Datenbanksysteme - Eine
Einführung. 6. Auflage. Oldenbourg Verlag, 2006
[Kem06]
Kemper, Carsten: Dynamische Simulation des Verkehrsablaufs unter
Verwendung statischer Verflechtungsmatrizen. Universität Hannover,
2006
[Klü01]
Klügl, Franziska: Multiagentensimulation. 2. Auflage. Addison-Wesley,
2001
[KN98]
Kramer, Ulrich; Neculau, Mihaela: Simulationstechnik. Carl Hanser
Verlag München Wien, 1998
[Kni07]
Kniesel, Günter: Folien der Vorlesung Softwaretechnologie“. Sommer”
semester 2007. Universität Bonn, 2007
[Krü04]
Krüger, Guido: Handbuch der Java-Programmierung.
Addison-Wesley, München, 2004
[KR08]
Kotzian-Rumpf, Manfred (Hrsg.): Rechtstipps. Akademische Arbeitsgemeinschaft Verlag Mannheim, 2008
[KW04]
Kopp, Markus; Wilhelms, Gerhard: Java Solutions. Hanser Fachbuchverlag, 2004
148
4. Auflage.
LITERATURVERZEICHNIS
[LK00]
Law, Averill M.; Kelton, W. D.: Simulation Modeling and Analysis. 3.
Auflage. McGraw Hill Higher Education, 2000
[Man05]
Manthey, Rainer: Folien der Vorlesung Informationssysteme“. Win”
tersemester 2004/2005. Universität Bonn, 2005
[MB07]
Manthey, Rainer; Behrend, Andreas: Folien der Vorlesung Data”
base Techniques for Event Monitoring Systems“. Sommersemester 2007.
Universität Bonn, 2007
[Mey]
Meyers Lexikon
22. 05. 2008
[Mil]
Milbradt, Peter:
Theorie und Anwendung Zellulare Automaten.
http://www.bauinf.uni-hannover.de/~milbradt/Lehre/
ModellSimul/7_zellul%areAutomaten.pdf, Abruf: 15. 06. 2008
[Min]
Ministerium für Bauen und Verkehr des Landes NordrheinWestfalen: Verkehrsinformationssystem autobahn.NRW. http://
www.autobahn.nrw.de, Abruf: 15. 06. 2008
[Oes05]
Oestereich, Bernd: Die UML 2.0 Kurzreferenz für die Praxis. 4. Auflage. Oldenbourg Verlag München Wien, 2005
[Pol]
Polizei des Landes Nordrhein-Westfalen: Verkehrsunfallstatistik 2007.
http://www1.polizei-nrw.de/bonn/Start/Aktuelle%
20Themen/zahlen-und-dat%en/verkehr-2/, Abruf: 14. 06. 2008
[PTV]
PTV AG: Verkehrsplanung Software. http://www.ptv.de/cgi-bin/
traffic/traf_vision.pl, Abruf: 15. 06. 2008
[Ray01]
Ray, Erik T.: Learning XML. O’Reilly Associates, 2001
[SVP]
Bemessung von Knotenpunkten mit Lichtsignalanlagen (LSA).
http://www2.fh-wolfenbuettel.de/trafficsz/forstluerken/
Download/Verkeh%rsplanung/SVP&SVT-LSA.pdf, Abruf: 14. 06. 2008
[Ull08]
Ullenboom, Christian: Java ist auch eine Insel. 7. Auflage. Galileo
Computing, 2008
[Vos00]
Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. 4. Auflage. Oldenbourg Verlag München Wien,
2000
[WJ95]
Wooldridge, Michael; Jennings, Nicholas R.:
Intelligent
Agents: Theory and Practice.
In: Knowledge Engineering Review (1995), Nr. 2.
http://cognition.iig.uni-freiburg.de/
teaching/veranstaltungen/ws03/WooldridgeJennings95.pdf, Abruf: 15. 06. 2008
online.
http://lexikon.meyers.de/,
149
Abruf:
[Wor]
World Wide Web Consortium: World Wide Web Consortium.
http://www.w3.org/Consortium/, Abruf: 15. 06. 2008
[Xan08]
Xanke, Peter (Hrsg.): Straßenverkehrsstrafrecht. 59. Aktualisierung.
Deubner Verlag Köln, 2008
Erklärung
Hiermit versichere ich, dass ich diese Diplomarbeit selbstständig durchgeführt und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate
kenntlich gemacht habe.
Bonn, den 19.06.2008
Sandra Loch
Youness Dehbi
DANKSAGUNG
An erster Stelle möchten wir uns bei Prof. Dr. Manthey für die Ermöglichung unserer Diplomarbeit bedanken. Mit seiner herzlichen und konstruktiven Betreuung
hat er einen wesentlichen Beitrag zum Gelingen dieser Arbeit geleistet.
Weiterhin möchten wir all denjenigen danken, die in irgendeiner Form für die Verfeinerung dieser Diplomarbeit beigetragen haben. Besonderer Dank gilt dabei Khaled
Abuamsha, Daniel Lyssi, Andina Archid-Schramm, Jennifer Große-Chammaa, Imke
Schuster und Mušan Ahmetašević, die durch gewissenhafte Revision der Texte und
kritische Anregungen zum Thema wesentlich beigetragen haben. Für die fachliche
Beratung in juristischen Fragen bedanken wir uns bei Rechtsanwältin Frau GriesRedeker.
Ich, Sandra, bedanke mich ganz besonders bei meinen Eltern, die mich während des
gesamten Studiums mit viel Liebe und Geduld unterstützt haben. Ohne sie wären
die letzten Jahre und insbesondere die letzte Phase nicht so reibungslos verlaufen.
Ganz besonders möchte ich, Youness, meinen Eltern für ihre Liebe und Unterstützung,
vor allem während meines Studiums, danken. Mein herzlicher Dank gilt auch meinen Geschwistern Mehdi, Mohammed und Fatima Zahra für ihre moralische Unterstützung. Bedanken möchte ich mich zudem bei Dr. Hilali und Dr. Kamouni,
die dazu beigetragen haben, dass ich mein Studium in Deutschland beginnen durfte. Auch möchte ich mich recht herzlich bei Familie Loch für ihre Herzlichkeit und
Hilfsbereitschaft bedanken.