PDF file - IDB - Universität Bonn

Rheinische Friedrich-Wilhelms-Universität Bonn
Institut für Informatik III
Diplomarbeit
Entwurf und Implementierung einer datenbankgestützten
Bildschirmkarte zur Analyse von Verkehrsszenarien
Harun Şahin
Dezember 2006
Erstgutachter: Prof. Dr. Rainer Manthey
(ausgesprochen: Bismi-illah-r-rahmani-r-rahim)
Im Namen Gottes des Allerbarmers, des Barmherzigen
ii
Abstract
Nowadays, the analysis of large amounts of data is carried out extensively with computers.
Intelligent software systems developed for special forms of analysis. Database technology has
been rarely exploited for more demanding analysis tasks, although the respective data is
managed in a database. Some possible fields of application of the analysis of data with the
help of database technology are medicine (patient supervision, plague recognition) and
banking (account movements, stock exchanges movements). Moreover, an ambitious task like
traffic supervision and control can benefit from such kind of analysis.
This work concerns a preliminary study towards a database supported traffic monitoring system. The analysis of traffic situations over static and dynamic traffic data is performed by
means of advanced database technology, more precisely deductive rules known as views in
SQL systems. The prototype system developed is called VADImA. Different kinds of database technology have been used for the analysis and processing of traffic data, however these
techniques are restricted to the analysis of the dynamic data also known as data streams. In
VADImA all available data is combined in a hierarchy of SQL views allocated to the application program of VADImA. Moreover, the admissibility of correct states in the database is controlled by means of global integrity constraints.
The main target of this work is to develop an analysis system which evaluates traffic scenarios
on road crossings and intersections using traffic data. This is because the traffic conflict situations occur predominantly at such junctions. These conditions must be detected and have to be
managed in a such way that collisions are avoided according to the right of way or precedence. In this work traffic scenarios are classified as global or local views. The global view is
the road network, whereas the local view consists of crossings and intersections including
with cars on these roads.
iii
Kurzfassung
Die Analyse großer Datenmengen wird heutzutage weitgehend von Computern durchgeführt,
auf denen oft ein für die spezielle Form der Analyse entwickeltes intelligentes Softwaresystem läuft. Für anspruchwsvollere Analyseaufgaben werden jedoch Datenbanktechniken selten
eingesetzt, obwohl die jeweiligen Daten in einer Datenbank verwaltet werden. Einige mögliche Einsatzgebiete zur Analyse von Daten mit Hilfe von Datenbanktechniken wären beispielsweise Medizin (Patientenüberwachung, Seuchenerkennung), Banken (Kontenbewegungen, Börsenbewegungen), aber auch eine ehrgeizige Aufgabe wie Verkehrsüberwachung und
-steuerung kann von Datenbanktechniken zur Analyse profitieren.
In dieser Arbeit geht es um eine Vorstudie auf dem Weg zum datenbankgestützten Verkehrsmonitoring. Über von statischen und dynamischen Verkehrsdaten wird die Analyse von Verkehrssituationen mittels fortgeschrittener Datenbanktechniken, genauer deduktiver Regeln,
die in SQL-Systemen auch als Sichten-Konzept bekannt sind, eingesetzt und in einem prototypischen System namens VADImA erprobt. Unterschiedliche Datenbanktechniken sind zur
Analyse und Verarbeitung von Verkehrsdaten entstanden, jedoch beschränken sich diese auf
die Analyse der dynamischen Daten, die auch als Datenströme bekannt sind. In VADImA
hingegen werden alle vorhandenen Daten je nach Bedarf in einer Hierarchie von SQLSichten verknüpft und für das Anwenderprogramm von VADImA bereitgestellt. Auch die
Zulässigkeit der korrekten Zustände in der Datenbank wird mit globalen Integritätsbedingungen überwacht.
Das zentrale Anliegen dieser Arbeit bestand daher darin, ein Analysesystem zu konstruieren,
das mittels Verkehrsdaten Verkehrsszenarien1 – wobei die dynamischen Verkehrsabläufe in
dieser Arbeit in Form von statischen Zuständen dargestellt werden – an Kreuzungen und Einmündungen auswertet, da die verkehrlichen Konfliktsituationen überwiegend an diesen Knotenpunkten vorkommen. Diese Situationen müssen im Vorfeld erkannt und durch Anwenden
von Vorfahrt- bzw. Vorrangregeln ohne Kollision gesteuert werden. Verkehrsszenarien werden in dieser Arbeit unterteilt in eine globale und lokale Sicht. Die globale Sicht ist das Straßennetz, während die lokale Sicht aus Kreuzungen bzw. Einmündungen mit deren stationären
Einrichtungen inkl. der sich auf der Kreuzung befindenden Fahrzeuge besteht.
1
Ein Szenario ist die Beschreibung einer möglichen Abfolge von Ereignissen innerhalb einer statischen Objektkonstellation.
iv
Hiermit erkläre ich, dass ich diese Diplomarbeit selbständig durchgeführt habe und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Bonn, den 29. Dezember 2006
_______________________
Harun Şahin
v
Danksagung
An dieser Stelle möchte ich mich bei einigen Menschen bedanken:
An erster Stelle möchte ich mich bei meinem Diplomvater und zugleich meinem Betreuer
Herrn Professor Dr. Manthey besonders herzlich bedanken für die Vergabe eines Diplomarbeitsthemas in Zeiten, in denen er mit Diplomanden ausgelastet gewesen ist, und für die unzähligen wertvollen gemeinsamen Stunden in allen Phasen der Erstellung dieser Arbeit. Ohne
seine leidenschaftliche persönliche Betreuung hätte diese Arbeit sicherlich nicht in Ansätzen
ihre jetzige Gestalt gehabt. Außerdem danke ich für das entgegengebrachte große Interesse
zum erfolgreichen Gelingen dieser Arbeit und nicht zuletzt für die Übernahme der Begutachtung.
Bei meinen Kommilitonen Armin Felke und Harpreet Singh möchte ich mich fürs Korrekturlesen liebend bedanken.
Des Weiteren möchte ich meiner Familie hierzulande danken, einfach für alles.
vi
Inhaltsverzeichnis
1 Einleitung.................................................................................................................... 1
2 Grundlagen aus der Informatik ............................................................................... 5
2.1 Softwaretechnologie .................................................................................................................................... 5
2.1.1 Java........................................................................................................................................................ 5
2.1.2 Entwurfsmuster.................................................................................................................................... 9
2.1.3 Unified Modeling Language .............................................................................................................. 11
2.2 Datenbanken.............................................................................................................................................. 13
2.2.1 Das Entity-Relationship-Modell........................................................................................................ 15
2.2.2 Das Relationale Datenmodell ............................................................................................................ 17
2.2.3 Die Relationale Algebra ..................................................................................................................... 18
2.2.4 Structured Query Language (SQL).................................................................................................. 19
2.2.5 JDBC ................................................................................................................................................... 23
3 Grundlagen aus dem Verkehrswesen .................................................................... 25
3.1 Verkehrsnetze............................................................................................................................................ 25
3.2 Verkehrsrecht............................................................................................................................................ 28
3.2.1 Vorfahrtregeln.................................................................................................................................... 28
3.2.2 Vorrangregeln .................................................................................................................................... 32
4 Entwurf, Konzept und Methodologie..................................................................... 33
4.1 Modellierung von Verkehrsszenarien ..................................................................................................... 33
4.1.1 Modellierung von vorfahrtregelnden Einrichtungen...................................................................... 37
4.1.2 Modellierung von Fahrzeugen im Straßennetz................................................................................ 38
4.2 Analyse von Verkehrsszenarien............................................................................................................... 39
4.2.1 Modellierung von Vorfahrtsszenarien.............................................................................................. 39
4.2.2 Modellierung von Vorrangszenarien................................................................................................ 40
4.2.3 Konfliktsituationserkennung............................................................................................................. 41
vii
5 Architektur des VADImA-Systems........................................................................ 51
5.1 Komponentenarchitektur ......................................................................................................................... 51
5.2 Aufbau und Funktionalität der GUIs...................................................................................................... 54
5.3 Die Paketstruktur von VADImA ............................................................................................................. 57
6 Ausgewählte Aspekte der Implementierung ......................................................... 63
6.1 SQL-Sichten im System ............................................................................................................................ 63
6.1.1 Integritätsbedingungen und Kontrollsichten in der VADImA-Datenbank .................................. 63
6.1.2 SQL-Sichten zur Analyse von Verkehrsszenarien .......................................................................... 67
6.2 Details zur grafischen Darstellung und zu Algorithmen in VADImA auf Codeebene........................ 71
6.2.1 Visualisierung der globalen Sicht des Straßennetzes ...................................................................... 72
6.2.2 Methoden zur Visualisierung der lokalen Sicht und zur Aktualisierung von Fahrzeugdaten .... 73
6.2.3 Methode zur Analyse von Verkehrsszenarien ................................................................................. 76
7 Zusammenfassung und Ausblick............................................................................ 83
Literaturverzeichnis ................................................................................................... 87
viii
Kapitel 1
Einleitung
Der Straßenverkehr wird zunehmend belastet und vernetzt und benötigt daher vielfältige technische Systeme zur adäquaten Steuerung. Hierfür wiederum müssen große Mengen von Verkehrsdaten erfasst, analysiert und verwaltet werden. Man kann Verkehrsdaten in dynamische
und statische Daten unterteilen. Die statischen Daten enthalten Informationen über die Struktur des Verkehrsnetzes (z.B. Topologie des Straßennetzes, Standorte und Bedeutungen der
Verkehrszeichen). Die dynamischen Daten werden von mobilen und/oder stationären Sensoren registriert. Mobile Sensoren sind an mobilen Objekten angebracht, während stationäre
Sensoren an vielen kritischen Orten im Straßenverkehr installiert sind, um den Verkehrsfluss
zu beobachten. Durch die Kombination dieser Daten kann der Verkehr intelligent geleitet
werden. Das geschieht durch Positionsauswertung der Fahrzeuge und der (stationär) erfassten
Lastinformationen einzelner Streckenabschnitte. Die von Sensoren erfassten dynamischen
Daten werden im Allgemeinen in Form von Datenströmen übermittelt. Datenströme sind sich
kontinuierlich mit der Zeit ändernde Folgen von Fakten.
In Verkehrsmanagementsystemen werden die erfassten dynamischen Daten sowie die statischen Daten oft in einer Datenbank abgelegt und von einem Datenbankmanagementsystem
(DBMS) verwaltet. Den dynamischen Teil der Datenbank kann man sich als eine Art „LogDatei“ vorstellen, in der die Datenströme protokolliert werden. Wählt man diesen Weg zur
Datenhaltung, lassen sich andere von einem DBMS gebotene Techniken (wie etwa deklarative Anfragesprachen) ausnutzen, um etwa eine intelligente Analyse der Verkehrsvorgänge zu
realisieren. Da der Begriff der Analyse hier und im weiteren Verlauf dieser Arbeit mehrfach
verwendet wird, soll dieser in diesem Zusammenhang näher spezifiziert werden. Allgemein
bedeutet Analyse die „Zergliederung eines Ganzen in seine Teile, genaue Untersuchung der
Einzelheiten, Auflösung …“ [Wahr00]. Das Ganze ist speziell in dem Kontext dieser Arbeit
ein Straßennetz mit den sich darauf befindenden Fahrzeugen. Die Einzelheiten, die untersucht
und aufgelöst werden, nennen wir Verkehrsszenarien1.
1
Ein Szenario ist die Beschreibung einer möglichen Abfolge von Ereignissen innerhalb einer statischen Objektkonstellation.
1
Es sind unterschiedliche Datenbanktechniken wie etwa das Auslösen von Triggern erprobt
worden. Des Weiteren sind auch Zeitreihenanalyse bzw. Data-Mining-Techniken auf Datenströmen adaptiert worden. Bei diesen Techniken allerdings hat man sich hauptsächlich auf die
Analyse der Datenströme selbst beschränkt. Sicherlich ist für einige Bereiche innerhalb des
komplexen Straßenverkehrs diese Einschränkung völlig ausreichend. Wenn man aber eine
umfassende und adäquate Steuerung des Verkehrs beansprucht, müssen diese dynamischen
mit statischen Daten gemeinsam analysiert werden. Deduktive Datenbanken eignen sich insbesondere zur Analyse von Datenströmen, die auf anspruchsvolle Weise mit (persistenten)
Meta-Daten verknüpft werden. Mittels gezielter Anfragen, die dann in einer Hierarchie von
SQL-Sichten vorliegen, gibt es Hoffnung, eine gigantische Aufgabe wie das Verkehrsmanagement, insbesondere die Analyse von Verkehrsszenarien, zumindest unter geeigneten Randbedingungen zu bewältigen.
Daher ist das Ziel dieser Arbeit, deduktive Datenbanktechniken zur Analyse von Verkehrsdaten/ Verkehrsszenarien zunächst beschränkt auf Kreuzungen und Einmündungen einzusetzen.
An diesen Knotenpunkten macht eine Analyse von Verkehrsszenarien für statisch dargestellte
Verkehrsabläufe Sinn, denn dort kommt es besonders häufig zu verkehrlichen Konfliktsituationen. Diese Situationen müssen im Vorfeld erkannt und durch Anwenden von Vorfahrt-/
Vorrangregeln intelligent ohne Kollision gesteuert werden. Sowohl die Erkennung von verkehrlichen Konfliktsituationen als auch den Vorfahrt-/Vorranghabenden zwischen Fahrzeugen
erfolgt in dieser Arbeit mittels SQL-Sichten, die kontinuierlich zur Analyse der jeweils aktuellen Situation abgefragt werden können.
Um dieses Ziel zu erreichen war die Aufgabe für diese Diplomarbeit, einerseits ein System zu
entwerfen und zu realisieren, das mithilfe von SQL-Sichten (deduktive Regeln) Verkehrssituationen analysiert und anderseits ein grafisch-interaktives Werkzeug bereitstellt, mit dem man
unterschiedliche Verkehrsszenarien durchspielen und visualisierte Verkehrsabläufe mitverfolgen kann. Verkehrsszenarien werden in dieser Arbeit unterteilt in globale und lokale Sicht.
Die globale Sicht ist das Straßennetz, während die lokale Sicht aus einzelnen Kreuzungen
bzw. Einmündungen mit deren stationären Einrichtungen besteht.
Um diese Aufgabe zu erfüllen, ist ein Analysesystem namens VADImA implementiert worden. „V“ steht für Verkehr, „A“ für Analyse, „D“ für Datenbank, „Im“ für Implementierung
und „A“ für Arbeit. Das VADImA-System setzt sich aus einem Anwenderprogramm und einer zugrundeliegenden Datenbank zusammen. VADImA ist der erste Prototyp eines datenbankbasierten Analysesystems, das Verkehrssituationen an Kreuzungen und Einmündungen
analysiert und die auf diese Analyse aufbauenden Verkehrsabläufe grafisch visualisiert. In
diesem Analysesystem ist das Zusammenspiel von Kontroll- und Analysesichten angestrebt
worden, wobei die Kontrollsichten die Zulässigkeit der Zustände in der Datenbank überwachen und die Analysesichten komplexe Eigenschaften der Szenarien auswerten. Somit übernehmen diese Sichten zusammen den Großteil an Aufgaben innerhalb von VADImA. Zudem
bietet VADImA, wie in der Aufgabenstellung erwünscht, viele interaktive Mitgestaltungsmöglichkeiten der Verkehrsszenarien durch den Benutzer an.
2
Die vorliegende Arbeit gliedert sich neben dieser Einleitung in sechs weitere Kapitel. Kapitel
2 bietet eine Einführung in die verwendeten Grundlagen von Softwaretechnologie und Datenbanken. Aufgabe des 3. Kapitels ist es, grundlegende Informationen zum Verkehrswesen
(Straßennetze, Verkehrsrecht) zusammenzustellen. In Kapitel 4 folgen eine konzeptuelle und
eine relationale Modellierung von Verkehrsszenarien. Kapitel 5 gibt einen Überblick über die
Architektur und Paketstruktur des entwickelten Systems. In Kapitel 6 werden ausgewählte
Aspekte der Implementierung näher diskutiert. Dabei werden Analysesichten, die Methode
der Generierung von Bildschirmkarten aus Datenbanken sowie der benutzte Algorithmus zur
Analyse von Verkehrsszenarien vorgestellt, der diese SQL-Sichten verwendet. Kapitel 7 liefert eine abschließende Zusammenfassung der entwickelten Konzepte und erzielten Ergebnisse. Außerdem wird ein Ausblick auf Anknüpfungspunkte für Folgearbeiten gegeben.
3
4
Kapitel 2
Grundlagen aus der Informatik
In diesem Kapitel werden Grundlagen eingeführt, die für den Entwurf und die Implementierung der erstellten Software wichtig gewesen sind. Im ersten Abschnitt Softwaretechnologie
werden die benutzten Programmier- und Entwurfstechniken beschrieben. Im zweiten Abschnitt werden Grundlagen zu Datenbanken zusammengestellt.
2.1 Softwaretechnologie
Dieser Abschnitt stützt sich weitgehend auf die Quellen: [GHJV95], [Esse01], [FoSc00],
[HoCo99], [HoCo02], [Knie03], [Krüg00], [Mart02], [OaWo97], [Oest01], [Oest02],
[Rauh00], [Sun06] und [Ulle02].
2.1.1 Java
Programme in der objektorientierten Programmiersprache Java setzen sich aus unabhängigen
Einheiten zusammen, den Klassen. Beim erfolgreichen Kompilieren von Klassen entsteht
Byte-Code. Dieser Byte-Code ist plattformunabhängig und kann dann auf anderen Betriebsystemen, auf denen die Java Virtual Machine (JVM) installiert ist, ohne erneutes Kompilieren
ausgeführt werden. Die Klassen legen die Eigenschaften der Objekte fest, d.h. sie stellen die
Baupläne für diese Objekte dar. Objekte sind durch Variablen (Struktur) und Methoden
(Verhalten) gekennzeichnet. Die Objekte werden dann als Instanzen dieser Klasse bezeichnet.
Java bietet sämtliche Konzepte an, die eine objektorientierten Programmiersprache ausmachen, d.h., Kapselung, Vererbung, Polymorphismus usw.
Um eine gute Vorraussetzung für die Erweiterung und Wiederverwendung von Software zu
erfüllen, bieten objektorientierten Sprachen Vererbungsverfahren an, so auch Java. Die „isa“-Beziehung zwischen Klassen X und Y besagt, dass jede Y-Instanz auch eine X-Instanz
ist“, also mindestens über alle Eigenschaften von X verfügt. Y ist eine Spezialisierung von
X, und umgekehrt betrachtet ist X eine Generalisierung von Y. Unterklassen erben (alle)
5
Variablen und Methoden ihrer Oberklassen. Die grundlegende Vaterklasse aller Klassen in
Java ist die Klasse Object. Java unterstützt keine Mehrfachvererbung, allerdings kann man
mit Hilfe von Interfaces eine Mehrfachvererbung nachbilden.
Ein Interface fasst eine Gruppe zusammengehöriger Methoden unter einem Namen zusammen, der die gemeinsame Aufgabe dieser Methoden charakterisiert. Es ist möglich, dass eine
Klasse verschiedene Interfaces implementiert. Sie muss dann zu jedem Interface alle definierten Methoden implementieren. Eine Klasse, die x Interfaces implementiert, ist demnach zu x +
1 Datentypen (zusätzlich zu ihren jeweiligen Oberklassen) kompatibel.
Für die Entwicklung von grafischen Benutzeroberflächen (engl.: Graphical User Interface
(GUI)) stehen in Java die beiden Pakete Abstract Window Toolkit (AWT) und Swing zur
Verfügung. Swing entstand später als AWT und gilt als Meilenstein unter den GUIGenerationen, da es unabhängig von dem GUI-API des Betriebssystems eine komplette grafische Benutzerschnittstelle mit vielen Komponenten zur Verfügung stellt. Die Betriebssystemunabhängigkeit wird durch die Verwendung von „Lightweight Components“ ermöglicht,
die im Gegensatz zu „Heavy Weight Components“, nicht auf betriebssystemspezifische Klassen zugreifen. In Swing werden sämtliche Grafikausgaben innerhalb der eigenen API1 ausgeführt. Aus diesem Grund kann das Aussehen einer Fensteranwendung sogar während der
Laufzeit geändert werden, indem einfach zwischen verschiedenen Layout-Vorlagen gewechselt wird. Dieses Feature wird in der Swing-Terminologie auch als „Plugable Look and Feel“
bezeichnet. Swing-Komponenten sind nach der Model-View-Controller (MVC)-Architektur
aufgebaut, welche Zustand, Repräsentation und Steuerung trennt. Dieses MVCEntwurfsmuster wird noch genauer im Abschnitt Entwurfsmuster erläutert.
Der Nachteil von Swing ist dessen hoher Ressourcenbedarf. Im Paket AWT ist die Ereignisbehandlung untergebracht, die für die GUI-Programmierung unerlässlich ist. Man kann jeden
in AWT geschriebenen Code in Swingcode konvertieren [Sun06]. Anders als in einigen anderen Programmiersprachen wie Visual Basic ist der Aufwand zur Erstellung der grafischen
Benutzeroberfläche relativ hoch. Auch die Werkzeuge in diesem Bereich sind noch nicht so
ausgereift [HoCo02]. Im Folgenden wird eine einfache Swing-Anwendung als Beispiel vorgestellt. Es zeigt ein kleines Fenster, in dem eine Schalfläche mit dem Text „Klick mich!“ enthalten ist. Der unter dieser Schaltfläche befindliche Text „Es wurde x-mal geklickt“ ist als
Label realisiert. Die Variable x im Label-Text wird durch betätigen der Schaltfläche jedes
Mal um einen ganzen Wert erhöht. Der Quellcode dieser Anwendung wird dazu genutzt um
einige grundlegende Eigenschaften von Swing zu erklären. Es geht darum zu zeigen, wie eine
Klasse, welche die Swing-Bibliothek verwendet, aussieht.
Abbildung 2.1: Eine einfache Swing-Anwendung
1
Applikation Program Interface (API) ist eine große Bibliothek mit fertigen Klassen, für beinahe alle Routinenaufgaben.
6
import
import
import
import
import
import
import
import
import
import
java.awt.BorderLayout;
java.awt.GridLayout;
java.awt.event.ActionEvent;
java.awt.event.ActionListener;
java.awt.event.WindowAdapter;
java.awt.event.WindowEvent;
javax.swing.JButton;
javax.swing.JFrame;
javax.swing.JLabel;
javax.swing.JPanel;
class DemoFenster extends JFrame implements ActionListener {
String labelanfang = "Es wurde";
String labelende = "- mal geklickt";
JLabel label;
JPanel panel, contentpane;
JButton knopf;
int anzahlKlicks = 0;
DemoFenster()
{
super("Demo-Fenster");
contentpane = new JPanel();
setContentPane(contentpane);
knopf = new JButton("Klick mich!");
knopf.addActionListener(this);
label = new JLabel(labelanfang + " 0 " + labelende);
panel = new JPanel();
panel.setLayout(new GridLayout(0, 1));
panel.add(knopf);
panel.add(label);
contentpane.add(panel, BorderLayout.CENTER);
setSize(300, 150);
setVisible(true);
addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent e){
System.exit(0);
}
});
}
public void actionPerformed(ActionEvent e)
{
anzahlKlicks++;
label.setText(labelanfang +" "+ anzahlKlicks +" "+ labelende);
}
public static void main(String[] args)
{
DemoFenster demoFenster = new DemoFenster();
}
}
7
Zuerst werden die benötigten Klassen aus den Paketen jawax.swing, java.awt und java.awt.event importiert. Das „Herzstück“ dieses Programms ist die von JFrame (RahmenFenster) abgeleitete Klasse DemoFenster, welche alle anderen zur Anwendung gehörigen
Komponenten enthält. Um dieses Programm zu starten muss in der main()-Methode ein Objekt der Klasse DemoFenster erzeugt werden. Mit dem Schlüsselwort new wird in Java signalisiert, dass ein neues Objekt erzeugt wird.
public static void main(String[] args)
{
DemoFenster demoFenster = new DemoFenster();
}
Das Demo-Fenster bekommt einen Titel durch einen direkten Aufruf des BasisklassenKonstruktors. Mit dem Schlüsselwort super wird der Konstruktor der Basisklasse direkt aufgerufen.
super("Demo-Fenster");
Konstruktoren sind spezielle Methoden, die bei der Initialisierung eines neu erzeugten Objekts aufgerufen werden. In Java erhalten die Konstruktoren den Namen der Klasse zu der sie
gehören und haben keinen Rückgabewert. Durch Aufruf der Methode setContentPane(…)
wird das JPanel als Content Pane des Fensters definiert. Content Pane ist ein Behälter
(engl.: Container) dem alle Komponenten übergeben werden müssen. JPanel-Komponenten
können ebenfalls als Behälter für andere Komponenten dienen und dabei selbst in einem übergeordneten Behälter untergebracht werden. In dem obigen Beispiel-Code gibt es zwei
JPanels, einmal den Content Pane und zum anderen das panel-Objekt, das zunächst die
Komponenten JButton, JLabel aufnimmt und dann selbst vom contentpane-Objekt aufgenommen wird.
panel = new JPanel();
panel.add(knopf);
panel.add(label);
contentpane.add(panel, BorderLayout.CENTER);
Java bietet unterschiedliche Layout-Manager, beispielsweise BorderLayout, GirdLayout
usw., die die Anordnung der in einem Behälter enthaltenen Komponenten nach einer bestimmten Form übernehmen. Es ist auch möglich sein eigenes Layout zu gestalten. Mit der
Komponente der Klasse JLabel kann man Informationen in Bild- und/oder Textform im
Fenster anzeigen lassen.
JLabel label; label = new JLabel(labelanfang + " 0 " + labelende);
Felder die mit dem Datentyp String deklariert wurden, sind String-Objekte und enthalten
Zeichenketten. Zum erzeugen einer Schaltfläche wird ein Objekt der Klasse JButton erzeugt.
Im konkreten Fall wird eine Schaltfläche mit der Beschriftung "Klick mich!" geschaffen.
JButton knopf; knopf = new JButton("Klick mich!");
Schaltflächen und auch einige weitere Komponenten werden in Java als Ereignisauslöser betrachtet. Sobald eine Schaltfläche gedrückt wird, wird ein Ereignis ausgelöst. Damit auf die
auftretenden Ereignisse entsprechend reagiert werden kann, registrieren sich die so genannten
Listener bei den Ereignisauslösern, damit sie deren Ereignisse empfangen können. Mit der
8
Methode addActionListener(…) werden Listener an Ereignisauslöser, also hier an die
Schalfläche knopf, gebunden. Ereignisempfänger müssen das Interface ActionListener
implementieren, um das Ereignis (Action-Event) zu erhalten. Die Ereignisbehandlung findet
dann innerhalb der Methode actionPerformed(ActionEvent e) statt. Diese Methode muss
ohnehin in der Klassendefinition enthalten sein, wenn man das Interface ActionListener
implementiert. Im konkreten Beispiel wird in dieser Methode folgende Operation durchgeführt: Zuerst wird das Feld anzahlKlicks um einen ganzen Zähler erhöht und anschließend
wird der Label-Text mit dem neuen Wert dieses Feldes neu beschriftet, umgeben von dem
Text der beiden Strings labelanfang und labelende.
public void actionPerformed(ActionEvent e)
{
anzahlKlicks++;
label.setText(labelanfang +" "+ anzahlKlicks +" "+ labelende);
}
Umfassende Tutorien und Einführungen zum Thema Java befinden sich, neben zahlreichen
Büchern (siehe z.B. das Literaturverzeichnis der vorliegenden Arbeit), auf der offiziellen Internetseite von Sun [Sun06].
2.1.2 Entwurfsmuster
„Jedes Muster beschreibt ein in unserer Umwelt beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem; so dass Sie diese Lösung beliebig oft anwenden können, ohne sie jemals ein zweites Mal gleich auszuführen“, so der Architekt Christopher Alexander in [AISJ+77] [GHJV95]. Hier wird eigentlich von Mustern beim Entwurf von
Gebäuden und Städten in der Architektur gesprochen, jedoch sehen [GHJV95] die Gültigkeit
dieser Aussage auch für Entwurfsmuster in der objektorientierten Programmierung (OOP).
Entwurfsmuster sind also bekannte Lösungen bzw. beschreiben in rezeptartiger Weise das
Zusammenwirken von Klassen, Objekten und Methoden für erwiesenermaßen wiederkehrende Probleme in bestimmten Kontexten.
Insgesamt werden in [GHJV95] 23 Entwurfsmuster vorgestellt, die hauptsächlich in drei Kategorien unterteilt werden:
• Erzeugungsmuster
• Strukturmuster
• Verhaltensmuster
Erzeugungsmuster betreffen die Erzeugung von Objekten. Strukturmuster beziehen sich auf
statische Aspekte der Interaktion von Klassen oder Objekten. Verhaltensmuster betreffen dynamische Aspekte der Interaktion von Klassen oder Objekten. Das Factory-, das Observer-,
sowie das Model-Viewer-Controller (MVC)-Entwurfsmuster werden detaillierter beschrieben,
da sie in der vorliegenden Arbeit teilweise umgesetzt wurden.
9
Factory
Eine sogenannte Factory-Klasse dient als Objekterzeuger (~Objektfabrik). Dieses Entwurfsmuster definiert eine abstrakte Klassenschnittstelle mit Methoden zur Erzeugung eines Objekts. Die von dieser Klasse abgeleiteten Klassen entscheiden dann, von welcher Klasse das
zu konstruierende Objekt stammen soll. D.h. eine Klasse hat die Möglichkeit die Objekterzeugung an die Unterklassen weiterreichen zu lassen. Der Einsatz dieses Entwurfsmuster
macht vor allem dann Sinn, wenn eine Klasse die Klassen der zu erzeugenden Objekte nicht
im Vorfeld kennt oder wenn diese Klasse „will“, dass die „Gestalt“, der von ihr zu erzeugenden Objekte, durch Unterklassen festgelegt wird. Ein Beispiel dazu wäre z.B., wenn man den
Umfang oder Flächeninhalt von einem Quadrat und einem gleichschenkligen und gleichseitigen Dreieck auf beliebige Eingabeparameter berechnen möchte. Dazu reicht es, die Seitenlänge dieser beiden Figuren einzugeben. (Die Höhe des Dreiecks, welche zur Berechnung des
Flächeninhalts benötigt wird, lässt sich bei diesen speziellen Dreiecken einfach aus den Seitenlängen – diese sind gleichlang – mithilfe der trigonometrischen Funktionen berechnen).
Deswegen wird zunächst eine Schnittstelle Figur – die auch die Signaturen der Methoden zur
Berechnung des Umfangs und Flächeninhalts festlegt – definiert, welche von den Klassen
Quadrat und Dreieck implementiert wird. Es werden dann die jeweiligen Factory-Klassen
für das Quadrat und das Dreieck konstruiert, die die Schnittstelle FigurFactory, welche
vorher festgelegt wird, implementiert. Die konkreten Factory-Klassen (Quadrat- und Dreieck-Klassen) erzeugen die Figuren Quadrat und Dreieck nach Übergabe eines einzigen Wertes an die Fabrik-Methode. In der Regel werden diese Fabrik-Methoden mit createXXXSignatur versehen. Dieses Beispiel wurde in Anlehnung an die allgemeine Musterstruktur der
(Factory Methode)-Entwurfsmuster aus dem Buch [GHJV95] erstellt, das etwa wie folgt aussieht:
Creator
product = FactoryMethod()
Product
FactoryMethod()
AnOperation()
ConcreteProduct
ConcreteCreator
return new ConcreteProduct
FactoryMethod()
Abbildung 2.2
Das Interface Product aus der Abbildung entspricht der Schnittstelle Figur. ConcreteProduct sind die Klassen Dreieck und Quadrat. Die Schnittstelle Creator entspricht im konkreten Fall der Schnittstelle FigurFactory und ConcreteCreate der konkreten FactoryKlassen.
10
Observer
Das Observermuster definiert „eine 1:n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustands eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt und
automatisch aktualisiert werden“ [GHJV95]. Die Änderungen eines Objekts können sich auf
andere Objekte auswirken, ohne dass das geänderte Objekt die anderen genauer kennen muss.
Damit wird erreicht, dass verschiedene Objekte zueinander konsistent sind. Das Observermuster wird in Fällen eingesetzt, in denen das Programm in die Elemente Modell, Benutzeroberfläche und Steuerung unterteilt wird.
Java bietet auch die Möglichkeit, das Observermuster umzusetzen: Im Paket java.util sind
die Klasse Observable und das Interface Observer bereits enthalten.
Model-View-Controller (MVC)
•
•
•
Das Model enthält die Daten der Komponente und speichert ihren Zustand.
Der View ist für die grafische Repräsentation der Komponente zuständig.
Der Controller wirkt als Verbindungsglied zwischen beiden. Er empfängt Ereignisse
und ergreift die erforderlichen Maßnahmen zur Änderung von Model und View.
In dem Modell ist die Anwendungslogik der Komponente enthalten. Ein Modell kann gleichzeitig unterschiedliche grafische Repräsentationen haben. Um Veränderungen des Modells in
allen grafischen Repräsentationen sichtbar werden zu lassen, wird das Observermuster eingesetzt, damit die Views über die Änderungen benachrichtigt werden. Durch diese Trennung ist
es möglich, das Modell in einem anderen Programm einzusetzen. Dies erhöht die Wiederverwendbarkeit und erlaubt flexiblere Programmierung.
Swing verwendet eine leicht modifizierte Variante des MVC-Entwurfs, nämlich den modeldelegate-Entwurf. Die Entscheidung, den model-delegate-Entwurf anstelle des MVCEntwurfs zu verwenden, lag nicht zuletzt daran, dass View und Controller in der Regel eng
miteinander gekoppelt sind. Dieser Entwurf kombiniert das View- und das Controller-Objekt
in einem Element. Dieses Element zeichnet dann die Komponenten auf den Bildschirm und
behandelt die GUI-Ereignisse. Das Element wird als UI-delegate bezeichnet.
2.1.3 Unified Modeling Language
„Die Unified Modeling Language (UML) ist eine Sprache und Notation zur Spezifikation,
Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme“
[Oest01].
Die Unified Modeling Language (UML) ist eine Modellierungssprache und keine Methode.
Die meisten Methoden enthalten prinzipiell eine Modellierungssprache und einen Prozess.
Der Prozess ist die Handlungsanleitung, welche Schritte für ein Design durchführt werden.
UML wird dazu benutzt, Entwürfe auszudrücken. Wegen ihrer Unabhängigkeit von einer speziellen Programmiersprache, gelten diese Entwürfe somit für jede objektorientierte Sprache
[FoSc00]. Die UML kennt diverse Diagrammtypen. Im Folgenden werden diejenigen Diagrammarten näher betrachtet, die in dieser Arbeit zum Einsatz gekommen sind.
11
Use Case-Diagramme
Die Use Case-Diagramme entstehen meist während der Anforderungsphase und beschreiben
die Geschäftsprozesse, indem die Interaktion von Personen oder von bereits existierenden
Programmen mit dem System dargestellt wird. Dabei werden die handelnden Personen oder
aktiven Systeme Akteuren genannt. Ein Akteur muss nicht unbedingt ein Mensch, sondern
kann auch ein Gerät sein. Da der Akteur für eine Rolle steht, muss er benannt werden. Die
Interaktion eines Akteurs mit einem Anwendungsfall (Use Case) geschieht dadurch, dass dieser dessen Ausführung startet oder an der Ausführung in irgendeiner Weise beteiligt ist. Ein
Use Case beschreibt dann eine Interaktion mit dem System. Dazu werden die Akteure als
Strichmännchen dargestellt und die einzelnen Anwendungsfälle als Ellipsen. Ein Use CaseDiagramm beinhaltet die grafische Darstellung des Systems, der Anwendungsfälle, der Akteure außerhalb des Systems und der Beziehungen zwischen Akteur und Anwendungsfall oder
der Anwendungsfälle bzw. der Akteure untereinander. Es wird ein einfaches Beispiel zu Use
Cases ohne erweiterte Konzepte vorgestellt, das eine Party modelliert. Dieses Beispiel soll
auch zeigen, dass das System, welches die Anwendungsfälle darstellt, nicht unbedingt aus
Software bzw. Hardware bestehen muss. Die reale Welt lässt sich damit ebenfalls modellieren.
Party
Tanzen
Trinken
Gast
Gäste unterhalten
Gastgeber
Gäste empfangen
Party beenden
Polizei
Abbildung 2.3
12
Klassendiagramme
Klassendiagramme stellen die statische Sicht auf einen Programmentwurf dar. Die Diagramme stellen zum einen je nach Detaillierungsgrad die Struktur der Elemente der Klasse dar,
zum anderen die Beziehungen der Klassen untereinander. Im Folgenden Beispiel wurde der
Detaillierungsgrad Analyse/Design vorgestellt. Es gibt auch die Sicht „Implementierung“,
allerdings enthält sie zu viele Details. Deswegen wurde sie für diese Arbeit nicht in Betracht
gezogen.
Punkt
xcoord:int
ycoord:int
Punkt()
getXcoord()
getYcoord()
setXcoord()
setYcoord()
Abbildung 2.4
Paketdiagramme
Ein Paketdiagramm wird dann angewendet, wenn das gesamte System am umfassenden Klassendiagramm nicht mehr überschaubar verdeutlicht werden kann. Diese Darstellung kommt
der einer Karteikarte sehr nahe. Es kann sein, dass Objekte verschiedener Klassen voneinander abhängen. In UML werden diese Abhängigkeiten durch gerichtete Pfeile dargestellt.
gui
Frame
Panel
Abbildung 2.5
2.2 Datenbanken
Beim Entwurf von Datenbankapplikationen wird zwischen drei Abstraktionsebenen unterschieden: der konzeptuellen, logischen und physischen Ebene. Beim konzeptuellen Entwurf
wird am häufigsten das Entity-Relationship-Modell (ER-Modell) verwendet. Diese die Benutzersicht repräsentierende Ebene wird unabhängig vom verwendeten Datenbankmanagementsystem (DBMS) modelliert. Auf der logischen Ebene ist das ER-Schema in ein Datenbankschema umgesetzt worden, auf welches das zugrundeliegende DBMS basiert. In dieser Arbeit
13
wird als Datenbanksprache die Stardard-Query-Language (SQL) verwendet. SQL basiert auf
dem relationalen Datenmodell. In der physischen Ebene geht es in erster Linie darum, die
Performanz von Datenbankanwendungen zu optimieren. Dafür wird ein internes Schema
erstellt, das die interne Datenorganisation und die Zugriffsmechanismen auf diese Daten regelt. Die physische Ebene wird vom gewählten DBMS festgelegt und alle durchgeführten
Optimierungen sind für den Benutzer einer Datenbank transparent.
In diesem Abschnitt werden nun die Konzepte des ER-Modells, des relationalen Datenmodells, sowie der Datenbanksprache SQL eingeführt und erläutert. Dieser Abschnitt schließt
mit dem Unterabschnitt JDBC ab, welches die Schnittstelle zwischen dem zugrundeliegenden
DBMS und dem Anwenderprogramm darstellt. Für diesen Abschnitt wurde das nötige Wissen
aus den folgenden Quellen angeeignet: [MaFr99], [Mant03], [Mant04], [KeEi01], [SaSa03],
[TuRe99], [Voss00] und [WFCH+99].
Datenbanksystem
---------------
--------------DBMS
DBDB
DB
--------------Anwender und Anwendungsprogramme
Abbildung 2.6: Architektur eines Datenbanksystems
Ein Datenbanksystem (DBS) besteht aus mindestens einer Datenbank (DB) und einem Datenbankmanagementsystem (DBMS). Ein DBMS basiert auf einem Datenmodell (meistens auf
dem relationalen Modell), mit dem die Modellierung der realen Welt möglich wird. Die Aufgaben eines DBMS sind anwendungsunabhängig, d.h., es hat zu jeder Zeit dafür zu sorgen,
dass Schemata, Speicher und Transaktionen verwaltet und Anfragen bearbeitet werden,
gleichgültig welche Datenbanken Verwendung finden. Eine Datenbank hingegen besteht aus
anwendungsspezifischen Informationen. Unter der Transaktionsverwaltung eines DBMS fallen Aufgaben wie Zugriffsschutz, Integritätssicherung, Benutzersynchronisation und Fehlerbehandlung.
Für die vorliegende Arbeit wurde das Datenbankmanagementsystem MySQL verwendet.
MySQL ist das bekannteste Open Source SQL-DBMS Projekt [MySQ06]. MySQL ist sehr
verbreitet, und neben einer Dokumentation auf der offiziellen Internetseite der MySQLEntwickler, existieren zu MySQL im Internet und in Buchform umfangreiche Informationen.
14
2.2.1 Das Entity-Relationship-Modell
Für die konzeptuelle Modellierung wird in der Regel das Entity-Relationship-Modell (ERModell) verwendet. Dieses Modell wurde in [Chen76] von Peter Chen veröffentlicht. Bei dieser Methode analysiert man die relevanten Objekte des betrachteten Anwendungsgebiets, ihre
Eigenschaften und Beziehungen untereinander, die dann grafisch in so genannten ERDiagrammen dargestellt werden. Durch die leichte Verständlichkeit und die gute Anschaulichkeit der ER-Diagramme ist die Überführung aus dem konzeptuellen Entwurf in ein relationales Schema relativ einfach.
Das ER-Modell basiert auf folgenden Darstellungselementen zur Beschreibung der realen
Welt:
•
Entity: Entities sind „wohl unterscheidbare physisch oder gedanklich existierende
Konzepte der zu modellierenden Welt“ [KeEi01]. Jedes Entity gehört zu mindestens
einem Entity-Typ. Es wird dann Instanz dieses Typs genannt. Entity-Typen werden in
der grafischen Notation des ER-Modells durch Rechtecke dargestellt. Entities mit
gleichen Eigenschaften können zu Entity-Typen zusammengefasst werden.
•
Relationship: Beziehungen zwischen Entities werden als Relationships bezeichnet.
Gleichartige Relationships können zu Relationship-Typen zusammengefasst werden,
die in der grafischen Notation des ER-Modells durch Rauten dargestellt werden.
•
Attribute: Attribute repräsentieren die für die Anwendung erforderlichen Eigenschaften von Entity- und Relationship-Typen und haben einen festgelegten Wertebereich.
Sie werden in den Diagrammen als Ovale dargestellt. In größeren Diagrammen fällt
die Attributstruktur meistens ganz weg oder wird getrennt notiert. Attribute, deren
Werte das zugeordnete Entity eindeutig innerhalb aller Entities seines Typs identifizieren, werden als Schlüssel bezeichnet. Bei mehreren möglichen Schlüsselkandidaten
wird ein Primärschlüssel ausgewählt. Schlüsselattribute werden unterstrichen. Relationships besitzen keine eigenen Schlüsselattribute, sie werden durch die Schlüsselattribute der beteiligten Entity-Typen eindeutig identifiziert.
gefahren von
Bolide
Fahrzeuggestellnr
Fahrzeugmodell
Baujahr
gewonnen von
Formel-1Fahrer
Fahzeuggestellnr FahrerID
Fahrer
Name
Formel-1Grandprix
FahrerID
Rennstrecke
Rennstrecke
Austragungsort
Austragungsjahr
Abbildung 2.7: Beispiel eines ER-Diagramms
Zur Unterscheidung der verschiedenen Formen der Beteiligung der betreffenden Entities innerhalb einer Beziehung können die Kanten mit Bezeichnern, sogenannten Rollen versehen
werden (s. Abb. 2.8). Diese werden spätestens dann erforderlich sein, wenn ein und derselbe
Entity-Typ mehrfach an einem Relationship-Typ beteiligt ist.
15
Mechaniker
getestet von
Bolide
Fahrer
Abbildung 2.8
Allgemeine Gesetzmäßigkeiten darüber, wie viele Beziehungen ein Entity mit anderen Entities eingehen darf, werden über Funktionalitäten ausgedrückt. Für binäre Beziehungen existieren vier Funktionalitätsangaben 1:1, 1:N, N:1 und N:M.
Ein binärer Relationship-Typ R zwischen den Entity-Typen E1 und E2 heißt eine
• 1:1-Beziehung, wenn jede Instanz von einem der beteiligten Entity-Typen mit keiner
oder genau einer Instanz des jeweils anderen Typs in Beziehung stehen kann.
• 1:N-Beziehung, wenn jede Instanz des Entity-Typs E1 mit beliebig vielen Instanzen
des Entity-Typs E2 in Beziehung stehen kann, aber jede Instanz des Typs E2 mit keiner
oder genau einer Instanz des Entity-Typs E1 in Beziehung stehen kann.
•
•
N:1-Beziehung, wenn jede Instanz des Typs E2 mit keiner oder genau einer Instanz des
Entity-Typs E1 in Beziehung stehen kann, aber umgekehrt jede Instanz des EntityTyps E1 mit beliebig vielen Instanzen des Entity-Typs E2 in Beziehung stehen kann.
N:M-Beziehung, wenn die Beziehung keiner Beschränkung unterliegt.
Relationship-Typen ohne Funktionalitätsangabe wird implizit die Beziehung N:M zugeordnet.
Die Abbildung 2.9 enthält Beispiele zu 1:1 und 1:N.
gewonnen von
1.)
Formel-1Fahrer
1
1
Formel-1Grandprix
gefahren von
2.)
Bolide
N
1
Formel-1Fahrer
Abbildung 2.9: Relationship-Typ mit Funktionalitätsangabe
Das erste ER-Diagramm aus dem Beispiel in Abbildung 2.9 wurde mit der Funktionalität 1:1
versehen. Wenn man modellieren möchte, dass es pro Formel-1-Grandprix nur einen Sieger
geben darf, dann ist nur diese Funktionalität passend. Im zweiten Beispiel wurde die Funktionalität N:1 für sinnvoll erachtet. Theoretisch können während einer Saison beliebig viele Boliden von einem Formel-1-Fahrer gefahren, z.B. weil ein Bolide in einem Rennen „schrottreif“ gefahren werden könnte und ausgewechselt werden muss. Zwar ist es wie erwähnt theo16
retisch möglich, dass ein Fahrer beliebig oft seinen Boliden während der Saison wechselt,
allerdings hält sich die Zahl der Wechsel in der Realität in Grenzen. Um solchen Sachverhalten gerecht zu werden, d.h. genauere Angaben machen zu können, gibt es die Min-MaxNotation. Eine anschauliche Einführung zu dieser Notation ist z.B. in [Mant03] zu finden.
Das ER-Modell wurde um weitere Konzepte erweitert und wird dann Extended EntityRelationship-Modell (EER-Modell) genannt. Zwei wichtige Konzepte der Erweiterungen sind
die Generalisierung und die Aggregation. Bei Generalisierung werden ähnliche EntityTypen (Untertypen) zu einem Obertyp zusammengefasst. Dies bedeutet eine Abstraktion auf
Typebene. Die Generalisierung wird als Sechseck mit der Bezeichnung „is_a“ dargestellt. Die
ein- und auslaufenden Kanten werden mit Pfeilen vom Untertyp zum Obertyp gezogen. Die
Vererbung ist ein wichtiges Konzept der Generalisierung: Jede Instanz des Untertyps ist
gleichzeitig auch eine Instanz des Obertyps, d.h., alle Attribute des Obertyps werden geerbt.
Die Instanzen des Untertyps können aber zusätzlich noch eigene Attribute enthalten. In Abbildung 2.10, als Beispiel zur Generalisierung, ist sowohl eine Rennstrecke als auch eine Autobahn als Spezialisierung einer Fahrbahn modelliert. Bei der Aggregation werden Hierarchien von Typen gebildet, falls sich Entities des Obertyps aus Instanzen der Untertypen zusammensetzen.
Fahrbahn
is_a
Rennstrecke
Autobahn
Abbildung 2.10: Generalisierung
2.2.2 Das Relationale Datenmodell
Zu Beginn der siebziger Jahre entstand das relationale Modell. Dieses Modell ist ein mengenorientiertes Modell. Die bis dahin vorherrschenden Modelle, hierarchisches Modell und
Netzwerkmodell, waren satzorientiert. Vergleichsweise ist das relationale Modell einfacher
strukturiert als die satzorientierten Modelle. Es gibt im Wesentlichen nur flache Relationen
(Tabellen). Die Zeilen (Tupel) dieser Tabellen entsprechen den Datenobjekten. Die Werte
einer Spalte müssen aus demselben Wertebereich sein. Zudem müssen sie atomar sein. Atomare Werte sind z.B. Zahlen, dagegen sind Mengen oder Records nicht atomar. Das Schema
einer Relation legt den Namen und Struktur fest. Die Spaltennamen müssen innerhalb einer
Tabelle eindeutig sein. Der Zustand wird in [Mant03] als „Gesamtheit aller aktuell in Relation
enthaltenen Tupel“ definiert. Die Struktur jedes Zustandes einer Relation wird durch ihr
Schema festgelegt.
17
Ein Relationsschema angelehnt an die Notation vom [KeEi01] für Fahrzeuge könnte nun so
aussehen:
Fahrzeug :{[Fahrzeugmodell : string, Fahrzeuggestellnr : integer]};
Die Werte der Spalte Fahrzeugmodell müssen Zeichenketten und die Werte für Fahrgestellnr
ganze Zahlen sein. Ein Zustand dazu könnte somit wie folgt aussehen:
Fahrzeug
Fahrzeugmodell
Fahrzeuggestellnr
C230
112112545
CDI
56598
Abbildung 2.11: Beispieltabelle
Die Umsetzung eines ER-Schemas in ein relationales Schema erfolgt durch die Abbildung des
ER-Modells in das relationale Modell. Die Entity- bzw. Relationshiptypen werden in Tabellen
abgebildet, wobei der Name der Tabelle der Typ ist und die Attribute der Entity- bzw. Relationshiptypen die Spaltennamen sind. Die Schüsselattribute der Entitytypen werden auf Primarschlüssel-Spalten abgebildet. Wenn spezielle Funktionalitäten vorliegen (1:N, N:1, 1:1), kann
die Abbildung von Relationship-Typen verfeinert werden. Dabei werden einige Relationen
eliminiert, die für die Modellierung von Beziehungstypen benötigt worden sind. Es ist nur
sinnvoll Relationen mit gleichem Schlüsselattribut zusammenzufassen, ansonsten könnte es
zu falschen Sachverhalten führen. Bei einer 1:N-Beziehung werden die Informationen aus der
Relationship-Tabelle in diejenige beteiligte Entity-Tabelle eingefügt, deren Instanzen höchstens einmal in Beziehung stehen. Für die N:1-Beziehung ist es ganz analog zu sehen. Bei der
relationalen Modellierung von 1:1-Beziehung hat man mehr Gestaltungsfreiheit als bei (1:N
und N:1)-Beziehungen, denn die Beziehungsinformation kann in eines der beteiligten EnitityTabellen eingefügt werden.
Um Informationen aus der Datenbank zu gewinnen, gibt es für das relationale Datenmodell
zwei Anfragsprachen – die relationale Algebra und das Tupelkalkül. Beim Tupelkalkül werden Variablen an Tupel einer Relation gebunden. Der relationalen Algebra ist, anders als für
den Tupelkalkül, ein eigener Abschnitt gewidmet, da diese für die Implementierung von Datenbanksystemen viel wichtiger ist. Die Ausdrücke in der relationalen Algebra enthalten direkt einen Abarbeitungsplan wie die Abfrage auszuwerten ist. Für die Anfrageoptimierung ist
diese Information ernorm bedeutsam.
2.2.3 Die Relationale Algebra
In der relationalen Algebra gibt es unterschiedliche Operatoren, die nachfolgend eingeführt
werden. Aus einer Relation kann man mittels der Selektion eine gewisse Menge von Tupeln
auswählen. Die Selektion gibt diejenigen Tupel der Relation zurück, die das Selektionsprädikat erfüllen.
σ<Prädikat>(R), R steht für eine beliebige Relation.
Um bestimmte Attribute aus der Relation R zu benutzen wird die Projektion verwendet.
∏<Attributlise>(R)
18
Ein Beispiel für die Projektion wäre die folgende Anfrage. In der Anfrage wird das Attribut
Fahrzeugmodell aus der Relation (~Tabelle) Fahrzeug gewählt.
∏<Fahrzeugmodell>(Fahrzeug)
Zwei Relationen mit gleicher Struktur können zu einer Relation vereinigt werden. Relationen
mit gleicher Struktur haben gleiche Attributnamen und -typen. In dem folgenden Beispiel
werden Attribute der Relationen Müllwagen und PKW zusammengefasst.
∏<Fahrzeugmodell, Fahrzeuggestellnr>(PKW)
υ ∏<Fahrzeugmodell, Fahrzeuggestellnr> (Müllwagen)
Wenn man aus zwei Relationen R und S mit gleichem Schema die Menge der Tupel haben
möchte, die in R aber nicht in S verkommenen soll, so ist die Mengendifferenz R − S zu
benutzen.
Das Kreuzprodukt R × S zweier Relationen R und S ergibt eine Ergebnisrelation in der
alle Attribute der beiden Relationen enthalten sind. Die Anzahl der Tupel in der Ergebnisrelation setzt sich aus dem Produkt der Anzahl der Relationen R,S zusammen. Alle Tupeln aus R
sind mit Tupeln aus S in der Ergebnisrelation gepaart. Wenn Relationen, die am Kreuzprodukt beteiligt sind, gleichnamige Attribute besitzen, wird in diesem Fall die eindeutige Bennennung dadurch gewährt, dass dem Attributnamen der Name der Relation, gefolgt von einem
Punkt, vorangestellt wird.
Es kommt mal vor, dass eine Relation mehrmals in einer Anfrage benutzt wird. Dafür bietet
die relationale Algebra zur Umbennung von Relationen den Umbennungsoperator:
ρ<Rennwagen „neuer Name“>(Fahrzeug „urprünglicher Name“)
Aus diesen Grundoperatoren der relationalen Algebra lassen sich weitere Operatoren zur
Formulierung einer Anfrage herleiten. Die bekanntesten sind die unterschiedlichen JoinVarianten. Aus Platzgründen wird der natürliche Join näher erläutert, denn alle anderen JoinVarianten lassen sich analog herleiten. Der natürliche Verbund zweier Relationen R |><| S
ist folgendermaßen definiert:
R |><| S = ∏
A1,A2,.., Am,R.B1,..,R.Bk, C1,…,Cn(σ< R.B1= S.B1,…,R.Bk=S.Bk >(R
× S))
Dabei wird angenommen, dass R m+k Attribute A1,A2,..,Am,B1,…Bk und die Relation S die
Attribute n+k A1,A2,.,B1,…Bk,C1,…,Cn hat.
2.2.4 Structured Query Language (SQL)
In diesem Abschnitt wird SQL erläutert. SQL ist neben der Programmiersprache das wichtigste Element für den experimentellen Anteil dieser Arbeit gewesen. SQL setzt sich aus zwei
Teilsprachen zusammen:
• einer Datendefinitionssprache ( engl. „data definition language“, DDL)
• einer Datenmanipulationssprache (engl. „data manipulation language“, DML).
19
Die DDL enthält Befehlsformate, mit denen man Datenbankschema definieren und manipulieren kann. Ein Schema besteht aus Tabellen und einer Attributdefinition. Ein einfacher SQLBefehl zur Definition der Tabelle Knoten und daneben die tabellarische Struktur sehen wie
folgt aus:
CREATE TABLE Knoten
(
ID bigint(20) NOT NULL,
….
….
….
….
(ID)
Spalte
PRIMARY KEY
ID
….
….
Zeile
)
Beispiel 1.1
Abbildung 2.12: Tabelle Knoten
Die SQL-Schlüsselwörter sind durch Fettdruck und Lilafärbung hervorgehoben. Das Schlüsselwort „CREATE TABLE“ gibt an, das man das Schema einer Tabelle definieren möchte.
Nachdem dieser Tabelle ein Namen (im Beispiel: Knoten) gegeben wurde, legt man innerhalb
der runden Klammern die Attribute der Tabelle fest. Um einem Attribut (Spalte) einen Datentyp zuzuordnen, steht in SQL eine Vielzahl unterschiedlicher Datentypen zur Verfügung, jedoch sind sie in der Regel in die Kategorie der Zahlen, Zeichenketten und Datumstypen einzuordnen. Für das Beispiel wurde der Datentyp bigint ausgewählt. Dieser zählt zu den Zahlendatentypen und steht als Abkürzung für Biginteger (Integer wird als gängiger Datentyp
in den Programmiersprachen für ganze Zahlen eingesetzt). Das Schlüsselwort NOT NULL, welches optional im Schema hinter dem Datentyp stehen kann, besagt, dass die Zeile (Tupel) der
Tabelle zwingend Werte für diese Attribute haben muss. Somit stellen NOT NULL und Datentypen die Integritätsbedingung für die Tabellendefinition dar. Diese Integritätsbedingungen
(IBen), auch Konsistenzbedingung genannt, sind im allgemeinen Boolesche Ausdrücke, die in
jedem Zustand der Datenbank unveränderlich erfüllt sein müssen. Bemerkenswert ist hier das
Schlüsselwort primary key, auch eine IB, zu Deutsch Primärschlüssel. Dieser dient der eindeutigen Identifizierung der Tupel. Jeder Knoten z.B. auf einem Graphen soll eindeutig sein.
Man kann die Struktur dieser Tabelle problemlos ändern, z.B. die Eigenschaft der Spalte ID
nicht mehr als Primärschlüssel deklarieren. Dies erfolgt nur, wenn diese Tabelle – genauer
seine mit Primärschlüssel deklarierte Spalte – nicht durch mindestens eine weitere Tabelle
referenziert wird (referentielle Integrität). Die Spalten einer Tabelle, welche die Primärschlüssel anderer Tabellen referenzieren, werden foreingn key genannt. In SQL sind nur statische
Integritätsbedingungen definierbar: Es sind Ja/Nein-Anfragen, die in jedem Zustand der Datenbank wahr sein müssen. Es werden allgemein vier Klassen von SQL-Integritätsbedingungen (engl: Contraints) unterschieden:
• Domänen-Constraint (‘domain constraint’): CHECK-Bedingung
•
Attribut-Constraint (‘column constraint’): NOT NULL, PRIMARY KEY,
UNIQUE KEY, FOREIGN KEY, CHECK-Bedingung
•
Basistabellen-Constraint (‘table constraint’): PRIMARY KEY, UNIQUE KEY,
FOREIGN KEY, CHECK-Bedingung
•
ASSERTION (deutsch: Zusicherung): CHECK-Bedingung
Domänen- und Attribut-Constraints sind IBen, die den Wert eines Attributs beschränken. Diese sind Abkürzungen für die Basistabellen-Constraint. Es sind auch komplizierte Integritäts20
bedingungen möglich, die sich auf mehrere Tabellen beziehen. Diese lassen sich durch eine
CHECK-Anweisung gefolgt von einer Bedingung implementieren, wobei die Anweisung auch
komplexe eingebettete Anfragen enthalten kann. Damit wird die Definition sehr spezieller
IBen ermöglicht und die Möglichkeit andere Tabellen zu referenzieren eingeräumt. Alle Formen der Constraints sind durch ASSERTIONS ausdrückbar. Nur für ASSERTION-Constraints
sind in SQL eigenständige Definitionen erlaubt, d.h. außerhalb von bestimmten Tabellendefinitionen. Der Einsatz einer ASSERTION erfordert ebenfalls den Gebrauch von Abfragen. Der
Syntax zur Definition einer ASSERTION sieht wie folgt aus:
CREATE ASSERTION ASSERTION CHECK Bedingungsanweisung;
In SQL sind Aussagen mit Allquantoren (Allaussagen) nur mittels eines negierten EXISTSOperators möglich, da das Allquantor-Symbol nicht zur Verfügung steht. Das hat zur Folge,
dass die formulierten Allaussagen intuitiv schwierig nachzuvollziehen sind. Die Einführung
von EXISTIS- und weiteren Operatoren aus SQL folgt im Abschnitt über Data-DefinitonLanguage (DML). Leider wird in der Praxis von den kommerziellen sowie von Open-SourceDBMS-Produkten die Formulierung von Integritätsbedingungen über CHECK-Constraints mit
eingebetteten Anfragen und/oder ASSERTIONS nicht angeboten, jedoch kann man sich mit der
in [Mant03] vorgestellten Methode der Kontrollsichten helfen. Dafür muss vorher die SQLSicht eingeführt werden. Sie werden in dieser Arbeit im Besonderen zur Analyse von Verkehrsszenarien eingesetzt und auch zur globalen Integritätssicherung.
Mittels Sichten ist es möglich, ein Datenbanksystem an die Bedürfnisse verschiedener Benutzer anzupassen. Dadurch wird es unterschiedlichen Benutzern ermöglicht, sich interessante
Daten aus mehreren Tabellen individuell „zurechtzuverknüpfen“. Es gibt aber auch Daten,
welche die Benutzer nicht sehen bzw. zu denen sie keinen Zugang haben dürfen. Solche Datenschutz-Mechanismen können ebenfalls mit Sichten gewährt werden. Die Daten in den
Sichten sind virtuell, d.h. nicht in der Datenbank persistent gespeichert, sondern werden aus
den Tabellen, die die Sicht über die SELECT-Anweisung referenziert, jedes Mal, wenn die
Sicht aufgerufen wird, abfragt. Der Vorteil besteht in erster Linie darin, dass die Änderungen
in den Basistabellen nach jedem Aufruf der Sicht erkennbar sind. Durch die virtuelle Erhaltung der Daten wird oft enorm viel Speicherplatz gespart. Eine Sichtendefinition erfolgt durch
Kopplung eines Tabellennamens mit einer Anfrage. Eine vereinfachte Syntax zur Sichtendefinition sieht wie folgt aus:
CREATE VIEW VIEWNAME AS SELECT-Anweisung;
Um globale Integritätsbedingungen in einem System einzusetzen, ist die Formulierung von
ASSERTIONS unabdingbar, jedoch werden solche Konzepte von kommerziellen Datenbankmanagementsystemen nicht unterstützt. Mithilfe der Methode der Kontrollsichten in [Mant03]
kann man sich da weiterhelfen. Es empfiehlt sich dabei folgendermaßen vorzugehen: Man
definiert zunächst die erwünschte Integritätsbedingung mittels ASSERTIONS und dann überträgt man deren SELECT-Anweisung in eine Kontrollsicht. Die Bedingung kann nun in der
Kontrollsicht überprüft werden.
Es sei angemerkt, dass solche Kontrollsichten an den entsprechenden Stellen eines Programms ständig aufgerufen und vom jeweiligen Programm auf Inhalt überprüft werden müssen, während bei einem Datenbankmanagementsystem, das ASSERTIONS zulässt, der Aufgabe
der Überwachung globaler Integritätsbedingungen dem DBMS überlassen wird.
21
Die DML dient dem Formulieren und Auswerten von Anfragen und zur Durchführung von
Änderungen. Jede elementare Anfrage in SQL beginnt mit dem Befehl SELECT. Sehr vereinfacht sieht die Syntax für den SELECT-Befehl folgendermaßen aus:
SELECT Spaltenliste
FROM
Tabellenliste
[WHERE Auswahlbedingung]
Der SELECT-Befehl ist für das Auslesen von Daten aus einer oder mehreren einzelnen oder
verbundenen Tabellen zuständig. Die FROM-Klausel gibt dabei an, welche Tabellen für die
Anfrage einbezogen werden. Wird statt einer Spaltenliste das Symbol „*“ neben dem SELECTBefehl aufgeführt, so werden alle Spaltennamen im Anfrageergebnis aufgeführt. Mit der optionalen WHERE-Klausel können bestimmte Datensätze ausgewählt werden. Diese Datensätze
müssen dann die Auswahlbedingung erfüllen. Eine Beispielanfrage in SQL könnte dann so
aussehen:
SELECT *
FROM Knoten
WHERE Knoten ID >15;
Die Anfrage, falls nicht leer, gibt alle Knoten zurück, deren ID größer als 15 ist.
SELECT, Abteilung, SUM(Lohn)
FROM Mitarbeiter
GROUP BY Abteilung
HAVING COUNT (*) >=5
In dieser Anfrage wird das Gesamteinkommen in jeder Abteilung ermittelt, die mindestens 5
Mitarbeiter hat. Bei dieser Anfrage fallen neben den bekannten Schlüsselwörtern SELECTFROM noch weitere unbekannte Schlüsselwörter auf. COUNT und SUM. COUNT zählt die Anzahl
der Zeilen in einer Tabelle und SUM bildet die Summe. Weitere Schlüsselwörter dieser Art
sind AVG, MAX und MIN. Mit AVG bestimmt man den Durchschnitt einer Menge von Zahlen und
mit MIN und MAX bestimmt man das kleinste bzw. größte Element. Diese sind einige „builtin“-Funktionen in SQL. Sie werden Aggregatfunktionen genannt. In Zusammenhang mit Aggregatfunktionen werden erweiterte SELECT-Blöcke mit Unterteilung der Resultattabelle in
Gruppen verwendet. Die GROUP-BY-Klausel dient dazu, Informationen aus einer Tabelle gezielt zusammenfassen zu können. Die HAVING-Klausel ist mit der WHERE-Klausel zu vergleichen. Sie kommt zum Einsatz, um aus dem Ergebnis eines SELECT mit GROUP BY noch spezielle Zeilen auszuwählen. HAVING wird bei Bedarf zusammen mit GROUP BY benutzt.
Zusammengesetzte Anfragen wie JOIN, UNION, MINUS etc. sind anlog zu relationale Algebra
zu sehen. SQL bietet auch die Möglichkeit verschachtelte Anfragen zu formulieren. Dafür
stehen die Operatoren EXISTS und IN Verfügung. Der Existenzquantor wird in SQL mit dem
Schlüsselwort EXISTS gebildet. Der EXISTS-quantifzierte Ausdruck wird in einer Unterabfrage notiert. Wenn das Ergebnis dieser Unterabfrage nicht leer ist wird der Term TRUE geliefert,
andernfalls FALSE. Verschachtelte Anweisungen, welche mit IN formuliert werden, können
äquivalent auch mit EXITS ausgedrückt werden. In SQL existieren drei Grundoperationen
zum Ändern von Daten. Mit dem Befehl INSERT werden neue Datensätze (Tupeln) in die Tabelle hinzugefügt, UPDATE führt Änderungen von Spaltenwerten durch und DELETE löscht Datensätze.
22
2.2.5 JDBC
JDBC ist die Standardschnittstelle für den Zugriff auf SQL-Datenbanken aus Java. Die Bezeichnung JDBC wird häufig als Abkürzung für „Java Database Connectivity“ angegeben,
allerdings ist JDBC nach [WFCH+99] kein Akronym, sondern ein geschützter Name. JDBC
erfordert die direkte Nutzung von SQL-Anweisungen als String. String ist ein Datentyp für
Zeichenketten in Java. Man kann dies sowohl positiv als auch negativ sehen: Durch die direkte Nutzung der SQL-Anweisungen als String werden mögliche Fehler in der SQL-Anweisung
erst zur Laufzeit bekannt und nicht während des Kompilierens. JDBC besteht aus einer Reihe
von Klassen und Schnittstellen, die in den Paketen java.sql und javax.sql zusammengefasst sind. In dem Paket java.sql ist die Schnittstelle enthalten, welche für die „normale“
Datenbankarbeit ist. In javax.sql hingegen werden Schnittstellen für serverseitige Verarbeitung, Connection Pooling usw. bereitgestellt. Die Struktur von JDBC sieht wie folgt aus:
DriverManager
getConnection
Connection
createStatement
Statement
Statement
executeQuery
ResultSet
ResultSet
Abbildung 2.13: Die Struktur von JDBC
Die wichtigsten Klassen und Schnittstellen (siehe Abbildung) haben folgende Aufgaben:
•
java.sql.DriverManager: Diese Klasse registriert den Treiber, eine Erklärung dazu
folgt weiter im Text, und baut eine Verbindung zur Datenbank auf.
•
java.sql.Connection repräsentiert eine Datenbankverbindung.
•
java.sql.Statement: Diese Klasse oder Schnittstelle macht die Ausführung von
SQL- Anweisungen über eine gegebene Verbindung möglich.
•
java.sql.ResultSet: Mit ResultSet sind Anfrageergebnisse verwaltbar und es un-
terstützt den Zugriff auf einzelne Spalten.
23
Man kann in JDBC Anwendungen entwickeln, ohne dabei die speziellen Eigenschaften unterschiedlicher Systeme studiert zu haben. Das hat dann zur vorteilhaften Folge, dass man eine
JDBC-Anwendung, die für das DB2-DBMS geschrieben wurde, in der Regel durch Austausch
des Treibers ebenso für MySQL-DBMS benutzen kann. Dabei sollte man nicht vergessen,
dass in der Praxis augrund unterschiedlicher SQL-Dialekte beim Austausch Inkompatibilitäten auftreten können, da die Treiber von DBMS-Produkten zur Verfügung gestellt werden und
somit spezifisch sind.
JDBC stellt einen Treibermanager bereit und definiert die Schnittstelle für den Datenbankzugriff. Die eigentliche Kommunikation mit dem zugrundeliegenden DBMS geschieht durch
konkrete Treiber, die die Schnittstellen implementieren. Dies hat zur Folge, dass für jedes
DBMS ein eigener Treiber gebraucht wird. Für die vorliegende Arbeit wird der Treiber vom
Typ-3 für das MySQL-DBMS gewählt: com.mysql.jdbc.Driver. Für das Treiberkonzept und
als umfassende Einführung zum Thema JDBC kann man das JDBC-Reference Manual unter
[Sun06] zu Hilfe nehmen.
Nun werden Aspekte von JDBC eingeführt, die in der vorliegenden Arbeit mehrfach umgesetzt werden. Eine SQL-Anweisung wird in JDBC durch ein Statement-Objekt gekapselt.
Dieses Objekt sendet die Anweisung an die Datenbank und liefert das Ergebnis zurück. Es
gibt drei verschiene Formen von Statements:
• java.sql.Statement für einfache Anweisungen ohne Parameter gedacht.
•
java.sql.PreparedStatement kapselt eine vorkompilierte Anweisung und wird
verwendet, wenn eine Anweisung mehrfach ausgeführt werden soll (z.B. Änderungen). Durch diese Technik wird auch die Zugriffseffizienz gesteigert, denn man
braucht somit nicht die Anweisung jedes Mal, wenn sie benötigt wird, neu zuladen.
•
java.sql.CallableStatement bietet die Möglichkeit des Aufrufs von gespeicherten
Prozeduren [SaSa03].
Nun ein Beispiel zur Schnittstelle PreparedStatement:
Connection conn = DriverManager
.getConnection(Datenbankpfad,Benutzername, asswort);
private void setVerkehrszeichenUpdate() throws SQLException
{
query = "UPDATE Knotenzufahrt k SET stvo_zeichennummer =? WHERE k.ID=?";
PreparedStatement verkehrszeichenUpdate = conn.prepareStatement(query);
verkehrszeichenUpdate.executeUpdate();
}
Aus dem obigen Code ersieht man, dass das PreparedStatement aus dem Rückgabewert der
Methode prepareStatement(String query)erzeugt wird. Diese Methode wird durch das
aktuelle Connection-Objekt aufgerufen. Die Fragezeichen sind hier Platzhalter für INParameter. Die IN-Parameter werden durch die in PreparedStatement zur Verfügung gestellten setXXX-Methoden gesetzt. Für beinahe jeden SQL-Typ wird eine setXXX-Methode
bereitgestellt.
24
Kapitel 3
Grundlagen aus dem Verkehrswesen
In diesem Kapitel werden Grundlagen aus dem Verkehrswesen zusammengestellt. Es werden
nur die für das Verständnis der weiteren Kapitel nötigen Basisinformationen eingeführt, eine
ausführliche Behandlung dieser Themen würde den Rahmen dieser Arbeit sprengen. Wie aus
dem Thema dieser Arbeit zu entnehmen, soll eine datenbankgestützte Bildschirmkarte entworfen und implementiert werden, mit der man Verkehrsszenarien analysieren kann. Die
Bildschirmkarte soll in gewisser Weise beliebige Straßennetze visualisieren und das Werkzeug zum Bearbeiten dieser Straßennetze bereitstellen. Die Informationen sowie die Vorschläge und Ideen zur Darstellung von Straßennetzen wurden aus [Eife06] entnommen. Auch
die weiteren Quellen, die in diesem Kapitel angegeben sind, stammen aus [Eife06].
3.1 Verkehrsnetze
Um Verkehrsszenarien modellieren und analysieren zu können, muss eine Analyse im Bereich des Straßenverkehrs stattfinden. Dabei spielen Straßen, insbesondere Kreuzungen und
Einmündungen eine zentrale Rolle.
Der Straßenverkehr ist eines von vielen Subsystemen eines Verkehrssystems. Ein Verkehrssystem setzt sich aus Verkehrsmitteln (Fahrzeug, Schiffe usw.), Verkehrswegen (Fahrwege
usw.) und Verkehrsteilnehmern (Autofahrer, Fußgänger usw.) zusammen. Der Straßenverkehr
umfasst die Verkehrsvorgänge auf öffentlichen Straßen. Die Analyse im Bereich des Straßenverkehrs erfordert Kenntnisse in den Gebieten:
• Straßenverkehrstechnik und Verkehrsplanung
• Straßenverkehrsrecht (Straßenverkehrsgesetz StVG, Straßenverkehrsordnung StVO)
• Straßenrecht (Bundesfernstraßengesetz FStrG, Straßengesetze der Länder)
Die Straßenverkehrstechnik und die Verkehrsplanung sind Wissenschaften, die sich mit den
Gesetzmäßigkeiten und der Organisation des Verkehrsablaufes auf den Straßenverkehrsanlagen sowie mit der Planung, Gestaltung und Dimensionierung der Verkehrsanlagen befassen
[Schn97]. Die Straßenverkehrsordnung [StVO04] ist ein Regelwerk, das „die Regeln für das
25
Verhalten im Straßenverkehr festlegt (Verhaltensrecht)“ [Eife06]. Die Straßenverkehrsordnung dient im Verkehr vor allem dazu, Unfälle zu vermeiden, aber auch einen flüssigen Verkehrsablauf aufrechtzuerhalten. Da in der vorliegenden Arbeit die [StVO04] als Grundlage
zur Konzeption und Realisierung von Verkehrsregeln verwendet wurde, wird das Straßenrecht
und Straßenverkehrsrecht (Straßenverkehrsgesetz StVG) nicht mehr näher erläutert. Eine ausführliche Beschreibung der wichtigsten Verkehrsregeln (Vorrang-/Vorfahrtregel) aus
[StVO04], die in dieser Arbeit zum Zuge kommen werden, erfolgt im nächsten Abschnitt.
Der Begriff Straße wird in [StVO04] als Obergriff für (gewidmete) Verkehrsflächen, auf denen tatsächlich Straßenverkehr stattfindet, verwendet. Straßen sind im verkehrsrechtlichen
Sinne „alle für den Straßenverkehr oder für einzelne Arten des Straßenverkehrs bestimmten
Flächen, und zwar unabhängig von den Eigentumsverhältnissen oder einer straßenrechtlichen
Widmung“ [Schu96]. Einige wichtige Klassen von Straßen wären z.B. Bundesautobahnen,
Bundesstraßen, Landstraßen etc.
Straßenbestandteile werden als Elemente von Straßenverkehrsanlagen gesehen. Das liegt
daran, dass Straßenbestandteile in der Straßenverkehrstechnik und -planung nicht eindeutig
und einheitlich klassifiziert sind. Straßenverkehrsanlagen wären z.B. Anlagen für den motorisierten individuellen Verkehr oder den Radverkehr (Radwege, Radfahrstreifen). Elemente von
Straßenverkehrsanlagen, wie z.B. Fahrbahnen, Verkehrsinseln usw., werden in der Straßenplanung Entwurfs-, Gestaltungs- und Betriebselemente genannt [Köhl01].
Im Straßenverlauf unterscheidet man Strecken oder Straßenabschnitte und Knotenpunkte.
Strecken dienen nur dem Längsverkehr und Knotenpunkte dienen der Verknüpfung von Straßen und somit dem Längsverkehr und Querverkehr. Im Folgenden wird kurz auf die Begriffe
Straßenabschnitt und Knotenpunkt eingegangen. Der Straßenquerschnitt ist ein vertikaler
Schnitt rechwinklig zur Straßenachse. Die bedeutendsten Elemente von Straßenabschnitten
sind [FGSV00]:
• Fahrbahnen – aus Fahrstreifen und Randstreifen bestehender, zusammenhängend befestigter Teil der Straße
• Gehwege
• Radwege
Knotenpunkte als bauliche Anlagen dienen der Verknüpfung von Verkehrswegen
[FGSV00]. Knotenpunkt wird von der Forschungsgesellschaft für Straßen- und Verkehrswesen unter anderem mit folgendem Begriff definiert:
• Knotenpunktarm – an einen Knotenpunkt anschließender Straßenabschnitt
• Knotenpunktzufahrt – Teil eines Knotenpunktarmes, auf dem sich der Straßenverkehr
dem Knotenpunkt nähert.
• Knotenpunktbereich
• baulich: Straßenabschnitt, in dem die bauliche Anlage durch die Verkehrsentwicklung am Knotenpunkt bestimmt wird,
• verkehrlich: Straßenabschnitt, in dem der Verkehrsablauf durch den Knotenpunkt beeinflusst wird.
Plangleiche Knotenpunkte bedeuten niveau- oder höhengleiche Knotenpunkte. Auf diesen
wird der Verkehr nur in einer Ebene abgewickelt. In dieser Arbeit werden plangleiche Knotenpunkte betrachtet. Weil alle anderen Knotenpunktarten somit irrelevant sind, werden sie
hier auch nicht aufgeführt. Je nach Regelung des Verkehrs wird zwischen Knotenpunkten
ohne bzw. mit Lichtsignalsteuerung unterschieden. Die Regelungen des Verkehrs an den Kno26
tenpunkten sind in der [StVO04] festgehalten. Die wichtigsten Knotenformen der plangleichen Knotenpunkte sind:
• Kreuzung – Knotenpunkt mit mehr als drei Knotenpunktarmen, die mindestens aus
zwei durchgehend befahrbaren Straßen gebildet werden.
• Einmündung – Knotenpunkt, bei dem eine Straße an eine durchgehende Straße angeschlossen ist.
• Kreisplatz – Knotenpunkt mit Verbindung der Knotenpunktarme über eine ringförmige Fahrbahn, die entgegen dem Uhrzeigersinn durchfahren wird.
• Gabelung – Knotenpunkt, bei dem sich eine Straße in zwei Straßen verzweigt, zwischen denen kein Abbiegeverkehr ist.
Abbildung 3.1: Grundformen plangleicher Knotenpunkte
(Quelle: [FGSV01] mit geringfügiger Änderung)
Ein Straßennetz ist ein System von Straßen und deren Knotenpunkten (Kreuzungen, Einmündungen). Das Straßennetz setzt sich aus allen Straßen eines Gebietes (z.B. eines Landes)
zusammen. Es ist Träger des motorisierten und nicht motorisierten Individualverkehrs und des
straßengebundenen, öffentlichen Verkehrs [Wies03] [FGV00].
Das Straßennetz wird auf zwei Detaillierungsstufen – globale sowie lokale Sicht – betrachtet.
In der globalen Sicht werden Straßennetze in abstrakter Weise als Graphen aufgefasst. Ein
Graph besteht aus einer Menge von Knoten und einer Menge von Kanten. Die Kanten sind
für Verbindungen zwischen Knoten und können gerichtet oder ungerichtet sein. In dieser Ar27
beit werden nur gerichtete Graphen betrachtet, um die erlaubten Fahrtrichtungen auf Graphen
darstellen zu können. Die Strecken (Kanten) repräsentieren die Straßenabschnitte zwischen
den Netzknoten (Einmündungen oder Kreuzungen) im Straßennetz. Die lokale Sicht wird aus
dem internen Knotennetz eines Netzknotens gebildet. Das interne Knotennetz setzt sich aus
Knotenzufahrten, Knotenabfahrten und Knotenstrecken zusammen, wobei Knotenstrecken
Knotenzu- und -abfahrten miteinander verbinden. Die Knotenzu- und -abfahrten sind Zufahrten bzw. Abfahrten an Kreuzungen oder Einmündungen. Die Knotenstrecken liegen im Kreuzungsbereich. Durch sie werden die Abbiegevorgänge dargestellt.
Abbildung 3.2: Detaillierte Darstellung eines Netzknotens
3.2 Verkehrsrecht
In diesem Abschnitt werden die rechtlichen Grundlagen im öffentlichen Straßenverkehr eingeführt, welche im Straßenverkehrsrecht verankert sind. Der Fokus liegt dabei auf der Anwendung von Vorfahrt- bzw. Vorrangregeln der Straßenverkehrsordnung (StVO) an Kreuzungen und Einmündungen. Bereits im vorangegangenen Abschnitt wurde die Straßenverkehrsordnung [StVO04] als ein Regelwerk, das die Regeln für das Verhalten im Straßenverkehr festlegt, beschrieben. Sie dient im Verkehr vor allem dazu, Unfälle zu vermeiden, aber
auch einen flüssigen Verkehrsablauf aufrechtzuerhalten.
Eifer hat in [Eife06] Verkehrsszenarien modellierend analysiert. Dazu diente ihr die Straßenverkehrsordnung [StVO04] für Verkehrsregeln als Referenz, welche sie mit Hilfe von Sekundärliteratur zu [StVO04] beispielsweise [Schnu04] zusammenfassend und kommentierend
wiedergegeben hat. Deshalb wurden Verkehrsregeln der StVO, die hier angewendet werden,
aus ihrer Arbeit entnommen. Dadurch wurde Zeit gespart, weil sich somit eine Untersuchung
der Hauptquellen zur Straßenverkehrsordnung erübrigte.
3.2.1 Vorfahrtregeln
Vorfahrt ist die „Berechtigung, den aus kreuzenden oder einmünden Straßen gebildeten Verkehrsraum zuerst benutzen zu dürfen“ [Schu96]. Ein Vorfahrtsfall liegt vor, siehe Abbildung
3.3, wenn „an einer Kreuzung oder Einmündung mindestens zwei Fahrzeuge, die aus verschiedenen Richtungen kommen, sich so zu einander bewegen, dass sich ihre Fahrlinien […]
mit Kollisionsgefahr schneiden“ [Schu04].
28
A
B
A
B
A
Vorfahrtberechtigter
B
Wartepflichtiger
B
A
B
A
A
Vorfahrtberechtigter
B
Wartepflichtiger
Abbildung 3.3
Die Vorfahrtsszenarien werden auf drei Arten von Straßenkreuzungen und Einmündungen
hinsichtlich der Regelung des Verkehrs unterteilt. Dabei wird die Terminologie aus [Schn97]
verwendet.
• Rechts-vor-Links-Knoten,
• Vorfahrtknoten,
• Lichtsignalgesteuerter Knoten (LSA-Knoten) mit oder ohne Beschilderung.
Rechts-vor-Links-Knoten
Auf Rechts-vor-Links-Knoten gilt die Regel „Rechts vor Links“:
„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 einer andere Straße kommen“ [StVO04].
29
Bei der Vorfahrt „Rechts vor Links“ sind alle Straßen gleichberechtigt (Ausnahme: Feld-/
Waldwege). Es gibt in der Realität kaum eine Verkehrsregel ohne Ausnahme, jedoch wird in
dieser Arbeit von vielen Ausnahmen im Straßenverkehr abgesehen. Deshalb bleiben im Weiteren Ausnahmesituationen aus und werden nicht behandelt, es sei denn einige dieser Situationen erscheinen für die Analyse von Verkehrsszenarien der folgenden Kapitel besonders
wichtig und unentbehrlich. Dann werden diese Ausnahmesituationen – auch Sonderfälle genannt – berücksichtigt.
Vorfahrtknoten
Vorfahrtknoten sind Kreuzungen oder Einmündungen, die mit dem Verkehrszeichen 306 Vorfahrtstraße bzw. 301 Vorfahrt auf der übergeordneten Straße und dem Zeichen 205 „Vorfahrt
gewähren“ oder 206 „Halt! Vorfahrt gewährt“ nach StVO auf der untergeordneten Straße
ausgerüstet sind [Schn97].
Abbildung 3.4: (Quelle: [StVO04])
Das Zeichen 301 gibt die Vorfahrt ausschließlich an der nächsten Kreuzung oder Einmündung. Das Zeichen 306 steht am Anfang der Vorfahrtstraße und wird an jeder Kreuzung und
Einmündung rechts wiederholt. Dieses Zeichen gibt die Vorfahrt, bis es durch ein entsprechendes Zeichen aufgehoben wird. Wenn unmittelbar vor der Kreuzung oder Einmündung das
Zeichen 206 steht, so muss man mit dem Fahrzeug an der Haltlinie das Haltgebot befolgen.
Die Zeichen 306 und 301 werden als positive, 206 und 205 als negative Zeichen bezeichnet.
Knotenzufahrten, denen ein positives Zeichen zugeordnet wird, sind übergeordnete Knotenzufahrten. Wenn einer Knotenzufahrt ein negatives Zeichen zugeordnet wird, so wird sie auch
als untergeordnete Knotenzufahrt bezeichnet. Wenn sich Fahrzeuge auf übergeordneten und
untergeordneten Knotenzufahrten befinden, so hat derjenige Vorfahrt, der auf einer übergeordneten Knotenzufahrt ist.
Es gibt noch einen Sonderfall der „abknickenden Vorfahrt“ (Abbildung 3.5). An dem „Knick“
der „abknickenden Vorfahrtstraße, die meist entgegen ihrem natürlichen Verlauf als einheitlicher Straßenzug gilt“, finden die Vorfahrt- und Abbiegeregelungen der §§ 8 und 9 Anwendung [Schu04]. In Abbildung 3.5, siehe Variante 1 und 2, befinden sich Fahrzeuge auf überund untergeordneten Knotenzufahrten. Vorfahrt hat derjenige, der sich auf einer übergeordneten Knotenzufahrt befindet. Für Fahrzeuge, die sich auf untergeordneten (nicht bevorrechtigten) Knotenzufahrten befinden, gilt untereinander die Regel „Rechts vor Links“, siehe Abbildung 3.5 Variante 3 dazu [Schu04]. Wenn Fahrzeuge Gegenverkehr zueinander sind, dann
werden die Vorrang- und nicht die Vorfahrtregeln angewendet. Solche Situationen (Variante
4) werden im nächsten Abschnitt behandelt, in der die Vorrangregeln detailliert beschrieben
werden.
30
Abbildung 3.5: Abknickende Vorfahrt. Variante 1,2,3 und 4
LSA-Knoten
Eine Lichtsignalanlage (LSA) ist eine „Kombination von Lichtsignalgebern und erforderlichen Betriebseinrichtungen zur Steuerung des Verkehrsablaufes“ [FGSV00]. Solange die
LSA in Betrieb ist, werden an Kreuzungen und Einmündungen die Vorfahrtzeichen und die
Regel „Rechts vor Links“ außer Kraft gesetzt [StVO04]. Die Signalfarben eines Lichtsignalgebers bedeuten wie folgt:
• Grün: „Der Verkehr ist freigegeben“
• Gelb: „Vor der Kreuzung auf das nächste Zeichen warten!“
• Rot: „Halt vor der Kreuzung!“
Die Signalbildfolge ist Grün, Gelb, Rot, Rot und Gelb (gleichzeitig), Grün. Grün ist unten,
Gelb in der Mitte und Rot oben.
31
3.2.2 Vorrangregeln
Vorfahrt ist ein Unterfall des Vorrangs und gilt nur im Verhältnis zwischen Fahrzeugen
[Schu04]. Vorrang ist die „einem Verkehrsteilnehmer verliehene Befugnis, seinen Weg fortzusetzen, ohne dabei von anderen, die den Vorrang nicht haben, gestört zu werden“ [Booß80].
Nach [StVO04] gilt grundsätzlich, dass der geradeaus fahrende Verkehr (Gegenverkehr) Vorrang vor dem abbiegenden Verkehr hat und weder beim Rechts- noch beim Linksabbiegen
gefährdet werden darf:
• „Wer abbiegen will, muss entgegenkommende Fahrzeuge durchfahren lassen, …“
• „Wer nach links abbiegen will, muss 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“ [StVO04].
B
B
A
A
B
A
Abbildung 3.6: Typische Verkehrssituationen zur Anwendung von Vorrangregeln
Der Abbiegende muss also gegenüber dem Gegenverkehr warten, wenn „sich beide Fahrlinien
kreuzen oder der Gegenverkehr so nahe herangekommen ist, dass er durch das Abbiegen gefährdet oder an der zügigen Weiterfahrt wesentlich behindert werden könnte“ [Schu04]. Für
die Vorrangregelung spielt die vorhandene LSA keine Rolle. „Ein Linksabbieger muss in einer lichtzeichengeregelten Kreuzung (ohne besondere Linksabbiegespur) unabhängig von den
Farbzeichen der Ampeln entgegenkommende Fahrzeuge durchfahren lassen …“ [Schu04].
Die hier besprochenen Verkehrsregeln werden im nächsten Kapitel 4 bei der Analyse und
Modellierung von Verkehrsszenarien herangezogen.
32
Kapitel 4
Entwurf, Konzept und Methodologie
In diesem Kapitel werden die Konzepte diskutiert, die zur Entstehung des Systems erarbeitet
worden sind. Im Vordergrund steht dabei die konzeptuelle und oder relationale Modellierung
von Verkehrsszenarien. Die Grundlage zur Modellierung von Verkehrsszenarien bildet das
Straßennetz (globale Sicht), Netzknoten (lokale Sicht) sowie Fahrzeuge, welche im ersten
Abschnitt dieses Kapitels dargestellt werden. Der darauf folgende Abschnitt befasst sich mit
der Analyse von Verkehrsszenarien.
Der Entwurf sollte so konzipiert sein, dass er einerseits universell einsetzbar und unabhängig
von dem später zu erstellenden System ist und andererseits die Komplexität im Hinblick auf
mögliche Realisierungen gering gehalten werden kann. D.h. (überflüssige) Details aus der
realen Welt werden bei dieser Modellierung nicht berücksichtigt oder aber vereinfacht dargestellt.
Es sei angemerkt, dass einige der folgenden Modellierungen zu Verkehrsszenarien aus [Eife06] stammen. Eifer hat in [Eife06] auch Verkehrsszenarien modelliert und analysiert. Grafische Modellierungen (= ER-Diagramme) aus [Eife06] in dieser Arbeit, werden dadurch
kenntlich gemacht, dass die Quelle [Eife06] angegeben wird.
4.1 Modellierung von Verkehrsszenarien
In diesem Abschnitt wird eine konzeptuelle Modellierung des Straßennetzes vorgenommen.
Dabei werden die im Kapitel Grundlagen aus dem Verkehrswesen eingeführten Darstellungsmöglichkeiten modelliert. Es werden nur diejenigen Aspekte der Darstellung berücksichtigt, die für das in dieser Arbeit zu erstellende System benötigt werden. Bei Bedarf wird
neben der konzeptuellen Modellierung auch der logische Entwurf angegeben. Die konzeptuelle Modellierung erfolgt unter Verwendung des erweiterten Entity-Relationship-Modells
(EER-Modell) [Mant03]. In EER-Diagrammen werden nur diejenigen Attribute dargestellt,
die für die Modellierung der in späteren Anschnitten dieses Kapitels vorzustellenden Verkehrsszenarien wichtig sind. Die Wahl von Bezeichnern in ER-Diagrammen in diesem Abschnitt erfolgt nach folgenden Regeln aus [Mant03]:
33
•
•
•
•
•
Entity-Typen werden durch Substantive benannt.
Relationship-Typen werden entweder durch Verben oder Substantive mit Präpositionen benannt.
Die Benennung von Attributen und Rollen erfolgt durch Substantive.
In einem Schema kommt der Name eines Entity- bzw. Relationship-Typs nur einmal
vor.
Attribute und Rollen können hingegen in anderen Typen erneut verwendet werden.
Die Grundlage für die Modellierung bildet das vorgestellte Straßennetz aus dem Kapitel
Grundlagen aus dem Verkehrswesen. Ein Straßennetz besteht unter anderem aus Straßenabschnitten, welche durch Strecken repräsentiert werden.
Strecke
Straße
N
1
gehört_zu
Abbildung 4.1
Eine Straße kann aus beliebigen Straßenabschnitten, also Strecken, bestehen, jedoch kann
jeder Abschnitt nur einer Straße zugeordnet werden. Eine Strecke verbindet zwei Netzknoten,
was durch eine N:1:1-Beziehung verbindet dargestellt wird. Zudem bekommt verbindet noch
ein Attribut Himmelsrichtung, mit dessen Hilfe die Lage der Strecke bezüglich eines Netzknotens näher spezifiziert wird. Durch die Angabe von Rollen (Anfang und Ende) für Netzknoten
wird die Richtung von Strecken verdeutlicht.
Anfang
N
verbindet
1
Strecke
Netzknoten
Himmelsrichtung
1
Ende
Abbildung 4.2
In der lokalen Sicht bestehen Netzknoten bekanntlich aus Knotenzufahrten, Knotenabfahrten
und Knotenstrecken. Für die Modellierung von Verkehrsszenarien in dieser Arbeit ist jedoch
der Bestandteil Knotenstrecke eines Netzknotens irrelevant. Es werden nur solche Netzknoten
(Kreuzung, Einmündung) betrachtet, in denen alle Knotenabfahrten und Knotenzufahrten innerhalb eines Netzknotens miteinander verbunden sind. Ausgenommen sind nebeneinander
liegende Knotenzu- und -abfahrten. Um mit einem Fahrzeug von einer Knotenzufahrt auf eine
Knotenabfahrt zu gelangen, muss ein Feld befahren werden, das zwischen diesen liegt. Die
Knotenstrecke gibt als eine Art Wegweiser zwar die Verbindung von der Knotenzufahrt auf
die Knotenabfahrt auf diesem Feld vor, allerdings macht sie keine Angabe über die Position
des Fahrzeugs während des Aufenthalts auf diesem Feld. Eine ausführliche Modellierung von
Fahrzeugen folgt in einem späteren Abschnitt. Gerade in der Realität ist es eine gängige Praxis, dass sich Fahrzeuge im Kreuzungsbereich befinden. Der innere Kreuzungsbereich – quasi
34
als Quadrat zu sehen – wird unterteilt in vier gleich große Quadranten, auch Zellen genannt.
Aus den geschilderten Gründen wird für die Modellierung eines Netzknotens mit Hilfe der
part_of-Beziehungen nicht die Knotenstrecke wie bei [Eife06] berücksichtigt, sondern ein
neuer Entity-Typ ImKreuzungsbereich definiert, der dann zusammen mit den Entity-Typen
Knotenabfahrt und -zufahrt den Netzknoten in Abhängigkeit von diesen Ab- bzw. Zufahrten
darstellt. darstellt.
Netzknoten
is_part_of
is_part_of
is_part_of
Knotenzufahrt
Knotenabfahrt
ImKreuzungsbereich
Abbildung 4.3
Wie bereits zuvor erwähnt, ist der innere Kreuzungsbereich in vier gleich große quadratische
Zellen aufgeteilt, d.h. der Kreuzungsbereich besteht aus diesen Zellen. Auch diesen Sachverhalt kann man im ER-Modell mit Hilfe von part_of-Beziehungen modellieren. Eine mögliche
relationale Modellierung sieht wie folgt aus:
ID
Himmelsrichtung
Netzknoten
Tabelle 4.1: Zelle
Die Spalte ID dient der eindeutigen Identifizierung der Zellen im Straßennetz. Die Himmelsrichtung gibt die absolute Lage der Zelle im Kreuzungsbereich an. Da man hier von vier
gleich großen Zellen im Kreuzungsbereich ausgehen kann, sind die Himmelsrichtungen
Nordwest, Nordost, Südwest und Südost als Bezeichnung dieser Zellen geeignet und passend
zu sehen. Durch die Spalte Netzknoten werden die Zellen dem Netzknoten zugeordnet. Bei
dieser relationalen Modellierung von Zellen bleibt die part_of-Beziehung zwischen Zellen
und ImKreuzungsbereich implizit, somit erübrigt das Anlegen einer zusätzlichen Tabelle
ImKreuzungsbereich hier. Wenn man dennoch diese part_of-Beziehung z.B. in SQL darstellen möchte, so kann man dafür SQL-Sichten benutzen.
Knotenzufahrten und Knotenabfahrten liegen auf Strecken. Dieser Sachverhalt wird durch
eine 1:1:1-Beziehung liegt_auf definiert. Auf einer Strecke kann jeweils eine Knotenzufahrt
und -abfahrt liegen (Abbildung 4.4).
35
1
1
Strecke
Knotenabfahrt
liegt_auf
1
Knotenzufahrt
Abbildung 4.4
Ein Teilschema des Straßennetzes zusammengestellt aus den Teildiagrammen kann wie in der
folgenden Abbildung aussehen:
Anfang
1
N
Strecke
Netzknoten
verbindet
1
Ende
1
is_part_of
is_part_of
is_part_of
1
Knotenabfahrt
liegt_auf
ImKreuzungsbereich
1
Knotenzufahrt
Abbildung 4.5: Teilschema Straßennetz
Die eingekreisten Entity-Typen modellieren die lokale Sicht des Straßennetzes. Der gestrichelte Kreis in dieser Abbildung dient allein der Kennzeichnung und hat mit der ERModellierung nichts zu tun.
36
4.1.1 Modellierung von vorfahrtregelnden Einrichtungen
Der Entity-Typ Netzknoten bekommt ein Attribut Vorfahrtregelung, welches eine vorhandene
stationäre vorfahrtregelnde Einrichtung beschreibt. Dieses Attribut nimmt einen der folgenden
Werte an:
• keine Einrichtung,
• Beschilderung,
• Lichtsignalanlage mit Beschilderung,
• Lichtsignalanlage ohne Beschilderung.
Dem Entity-Typ Knotenzufahrt werden zwei Attribute StVO_Zeichennummer und Signalbild
zugeordnet. Die Spalte StVO_Zeichennummer nimmt einen der Werte 205, 206, 301 und 306
an. Die Spalte Signalbild nimmt eine der Farben Rot, Gelb, Rotgelb oder Grün als Wert an.
Die Werte 205, 206, 301 und 306 stehen stellvertretend für Verkehrszeichen. Eine Lichtsignalanlage (LSA), auch Ampel genannt, ist eine „Kombination von Lichtsignalgebern zur
Steuerung des Verkehrsablaufes“ [FGSV00]. Die Ampel für Fahrzeuge wechselt in bestimmten Zeitabständen zur Steuerung des Verkehrsablaufes ständig das Signalbild in den Farben
Rot, Gelb, Rotgelb und Grün.
rechts von
Knotenzufahrt
1
1
StVO Zeichennummer, Signalbild
Knotenzufahrt
Abbildung 4.6
Je nachdem wie die vorfahrtregelnde Einrichtung eines Netzknotens ist, werden diese Werte
entsprechend berücksichtigt.
Wenn das Attribut Vorfahrtregelung den Wert
• keine Einrichtung hat, so werden die Werte dieser beiden Attribute (Signalbild und
StVO_Zeichennummer) vernachlässigt.
• Beschilderung hat, so wird nur der Inhalt des Attributs StVO_Zeichennummer berücksichtigt.
• Lichtsignalanlage mit Beschilderung annimmt, so wird der Inhalt des Attributs
StVO_Zeichennummer und Signalbild berücksichtigt.
• Lichtsignalanlage ohne Beschilderung enthält, so werden nur die Werte des Attributs
Signalbild in Betracht gezogen.
37
Beim Entwurf und bei der Modellierung wurde darauf geachtet, die Komplexität möglichst
gering zu halten. Man hätte genauso gut einen Entity-Typ für Lichtsignalanlage und Vorfahrtzeichen erstellen können und dadurch einen Prozess aus der Realität zur Regelung des Verkehrs durch eine LSA detaillierter beschreiben können. Diese gewählte Modellierung ist allerdings völlig ausreichend.
Der Relationship-Typ rechts_von gibt die Nachbarschaftsbeziehung zwischen zwei Knotenzufahrten wider. rechts_von ist von großer Bedeutung um festzustellen, welche Fahrzeuge von
rechts kommen. Einige Verkehrsregeln der Straßenverkehrsordnung basieren auf der Rechtsvor-Links-Regel. Wenn man Kenntnis über die Nachbarschaftsbeziehung zwischen Knotenzufahrten hat, so ist es ein geringer Aufwand herauszufinden, welches von zwei Fahrzeugen von
rechts auf die Kreuzung zufährt. Je nach Regelung des Verkehrs wäre dann diese Kenntnis
sehr wichtig. Näheres dazu wird im Zusammenhang mit der Analyse von Verkehrssituationen
beschrieben.
4.1.2 Modellierung von Fahrzeugen im Straßennetz
Zur Analyse von Verkehrssituationen, aber auch zum Verkehrsablauf gehören neben dem
Straßennetz auch Fahrzeuge. Deshalb werden Fahrzeuge ebenfalls modelliert. Durch die Beziehung befindet_sich_auf wird die Position eines Fahrzeugs innerhalb eines Netzknotens
(Kreuzung, Einmündung) beschrieben, welches sich entweder auf Knotenzufahrten oder Knotenabfahrten oder im Kreuzungsbereich befinden darf. Für die zu modellierenden Verkehrsregeln und die Analyse von Verkehrssituationen im Abschnitt Analyse von Verkehrsszenarien
ist die Fahrstreifenanzahl nicht relevant. Deswegen werden nur zweispurige Straßen betrachtet. Aufgrund dessen kann sich somit auf Knotenzu- bzw. -abfahrten jeweils nur ein Fahrzeug
befinden.
Knotenzufahrt
1
1
Fahrzeug
Fahrtrichtungsänderung
Netzknoten
1
befindet_sich_auf
Knotenabfahrt
Abbildung 4.7
Ein Fahrzeug kann z.B. auf einer Kreuzung entweder links, rechts oder geradeaus fahren. Das
Attribut Fahrtrichtungsänderung gibt hierüber Aufschluss. Wie bereits zuvor erwähnt, können sich Fahrzeuge auch im Kreuzungsbereich befinden. Somit kann sich ein Fahrzeug zu
einem Zeitpunkt in einem Bestandteil des Netzknotens befinden.
38
Auf einem Netzknoten dürfen sich mehrere Fahrzeuge aufhalten, aber ein Fahrzeug kann sich
zu einem bestimmten Zeitpunkt jeweils nur auf einem Netzknoten befinden (Abb. 4.8).
N
1
Fahrzeug
Netzknoten
befindet sich auf
Abbildung 4.8
4.2 Analyse von Verkehrsszenarien
In diesem Abschnitt werden typische Verkehrssituationen an einer Kreuzung zwischen zwei
Fahrzeugen analysiert und modelliert. Der Fokus liegt dabei auf Vorfahrt- bzw. Vorrangszenarien sowie Konfliktsituationen im Straßenverkehr. In Kapitel 3 wurden bereits ausführlich
Vorfahrt- und Vorrangregeln anschaulich beschrieben, auf welche in diesem Abschnitt zurückgegriffen wird. Es werden nur statische Zustände von Verkehrsabläufen modelliert, in
denen die Fahrzeuge auf Knotenzufahrten stehen. Wenn Fahrzeuge an Knotenzufahrten stehen, bedeutet dies je nach Regelung des Straßenverkehrs entweder ein kurzzeitiges Anhalten
des Fahrzeugs zur Prüfung der Verkehrssituation oder ein „Herantasten“ des Fahrzeugs an die
Kreuzung. Man kann diese statischen Zustände („Momentaufnahme“) als einen Schnappschuss einer Situation im Verkehr verstehen. Weil Verkehrsabläufe in Momentaufnahmen
dargestellt werden, lassen sich darauf zum einen Vorfahrt- und Vorrangregeln eindeutig anwenden und zum anderen können physikalische Faktoren wie z.B. Geschwindigkeit, Bremsweg usw. unberücksichtigt bleiben.
Der Begriff Analyse ist in der Einleitung als Zergliederung eines Ganzen in seine Teile und
als genaue Untersuchung der Einzelheiten, Auflösung usw. beschrieben. Bereits im vorangegangenen Abschnitt erfolgte eine Zergliederung eines Ganzen in seine Teile. Und zwar wurden Teile wie Straßennetz, Netzknoten und Fahrzeug von Verkehrsszenarien – wenn man
Verkehrsszenarien als Oberbegriff ansieht – modelliert. Somit ist bereits eine Analyse nach
dieser Definition erfolgt. In diesem Abschnitt findet eine genaue Untersuchung der Einzelheiten statt, wobei als Einzelheiten hier Verkehrssituationen innerhalb von Netzknoten gemeint
sind. Verkehrssituationen sollen aufgelöst werden in dem Sinne, dass Vorfahrt- bzw. Vorrangregeln auf unterschiedlichste Situationen im Verkehr, vor allem auf Kreuzungen und
Einmündungen, angewandt und modelliert werden können. Auch die Erkennung von Konfliktsituationen der zugrundeliegenden Verkehrssituationen wäre somit eine geeignete Auflösung.
4.2.1 Modellierung von Vorfahrtsszenarien
In diesem Abschnitt wird die ER-Modellierung eines Vorfahrtfalls vorgenommen. Wie zuvor
erwähnt werden Vorfahrtfälle zwischen zwei Fahrzeugen betrachtet. Es wird die ERModellierung der Vorfahrtszenarien aus der Arbeit von Eifer übernommen (Abbildung 4.9).
Sie definiert die abgeleitete Beziehung quer_zueinander für zwei Fahrzeuge auf benachbarten
Knotenzufahrten – für Fahrzeuge auf gegenüberliegen Knotenzufahrten gilt die Vorrangregel.
39
Der abgeleitete Relationship-Typ vorfahrt_vor gibt beide Fahrzeuge mit der Angabe, welches
von beiden Vorfahrt auf dem Netzknoten hat, wider. Dabei liefert quer_zueinander in Bezug
auf die Lage dieser beiden Fahrzeuge zueinander die Information für vorfahrt_vor. Die abgeleiteten Relationship-Typen können hier wie „normale“ Relationship-Typen angesehen werden. Die Idee hinter diesen abgeleiteten Konzepten, ist die Erweiterung des ER-Modells zur
Modellierung deduktiver Informationssysteme [Rauh05].
Abbildung 4.9: Entnommen aus [Eife06]
4.2.2 Modellierung von Vorrangszenarien
Für die ER-Modellierung von Vorrangszenarien wird ebenfalls eine erweiterte Modellierung
aus [Eife06] übernommen. Der Relationship-Typ entgegenkommend gibt die zwei Fahrzeuge
auf gegenüberliegenden Knotenzufahrten wider. Auf diese Information aufbauend kann man
bestimmen, welches von beiden Fahrzeugen nach den Vorrangregeln Vorrang hat. Der Relationship-Typ vorrang_vor stellt auf dem Netzknoten beide Fahrzeuge mit der Angabe des Vorranghabenden dar.
entgegenkommend
Abbildung 4.10: Entnommen aus [Eife06]
Dieser und der vorhergehende Abschnitt stützt sich auf die aufgeführten Regeln zur Straßenverkehrsordnung in Abschnitt 3.2 Verkehrsrecht.
40
4.2.3 Konfliktsituationserkennung
In den vorangegangenen Abschnitten wurden die Vorfahrts- und Vorrangregeln der StVO
[StVO04] modellierend analysiert. Diese wurden für statische Zustände („Momentaufnahmen“, z.B. an einer Kreuzung) definiert. Vorfahrts- und Vorrangregeln existieren, um Kollisionen von Fahrzeugen zu vermeiden, aber auch um einen reibungslosen Verkehrsfluss zu garantieren. Damit wird sichergestellt, dass der Verkehrsfluss durch z.B. an Kreuzungen unnötig
wartende Fahrzeuge – aus welchem Grund auch immer – dauerhaft unterbrochen bzw. blockiert wird. Wenn man in der Realität an einer Kreuzung steht, so beachtet man zwar als
Fahrzeugführer strikt die Verkehrsregeln, allerdings wird im optimalen Fall zusätzlich auch
noch vorausschauend gefahren, d.h. wenn es z.B. beim gleichzeitigen Abbiegen zweier Fahrzeuge zu keiner Konfliktsituation kommen kann, so „vernachlässigt“ man die Vorfahrtsregeln
und fährt gleichzeitig. Es soll nun ein Verfahren hergeleitet werden, welches solche Konfliktsituationen schon im Vorfeld erkennen kann.
Im Vorangegangenen sind die Begriffe Kollision und Konflikt/Konfliktsituation bereits mehrmals gefallen, doch für ein weitergehendes Verständnis des herzuleitenden Verfahrens müssen diese Begriffe zuvor geeignet definiert werden. Das Wort Kollision könnte man mit Begriffen wie Überschneidung, Zusammentreffen oder Zusammenstoß umschreiben.
Eine Kollision zwischen Fahrzeugen liegt dann vor, wenn diese miteinander in Berührung
kommen (unabhängig von der Wucht des Zusammenstoßes). Der Begriff Konflikt wird in
[Wahr00] als „Streit, Widerstreit, Zwiespalt, Krieg, kriegerische Auseinandersetzung …“ definiert und Konfliktsituation wird dort als eine „Situation, die durch einen Konflikt entsteht“
bezeichnet. Diese Definition von Konflikt und Konfliktsituation ist derart aber nicht auf den
Straßenverkehr übertragbar. Daher wird der Begriff für Situationen an einer Kreuzung/ Einmündung nun folgendermaßen definiert: Eine Konfliktsituation im Straßenverkehr, ist eine
Situation, in der Fahrzeuge Gefahr laufen, eine Kollision zu verursachen. Es wurde hierbei
bewusst der Begriff „Unfall“ vermieden, da es sich bei einem Unfall nicht zwangsläufig um
eine Kollision von Fahrzeugen handeln muss.
nord
west
B
ost
süd
B
A
A
Abbildung 4. 11: Typische Situationen auf einer Kreuzung
41
Zur Orientierung ist in der Abbildung mittig noch ein Kompass aufgeführt, mithilfe dessen
die Lage der Knotenzufahrten bzw. die Fahrzeuge auf der Kreuzung zueinander dargestellt
werden.
Bevor Konfliktsituationen anhand von Beispielabbildungen erläutert werden, wird darauf
hingewiesen, dass in dieser Arbeit grundsätzlich immer Konfliktsituationen zwischen zwei
Fahrzeugen betrachtet werden. An einer Kreuzung – wie auch in Abbildung 4.11 zusehen –
können nur zwei Konstellationen zu einer Konfliktsituation führen:
a) Zwei Fahrzeuge befinden sich auf benachbarten Knotenzufahrten einer Kreuzung oder
Einmündung.
b) Zwei Fahrzeuge befinden sich auf gegenüberliegenden Knotenzufahrten einer Kreuzung oder Einmündung.
Eine ER-Modellierung von Konfliktsituationen, die unter Berücksichtigung dieser Feststellungen entstanden ist, sieht wie folgt aus:
Fahrzeug A
Knotenzufahrt 1
1
1
Netzknoten
Fahrzeug
Konfliktsituation
1
1
Knotenzufahrt 2
Fahrzeug B
Knotenzufahrt
1
1
befindet_sich_auf
Abbildung 4.12: ER-Diagramm zu Konfliktsituation
Es ist ein Relationship-Typ Konfliktsituation definiert, an dem zwei Fahrzeuge inklusive der
Knotenzufahrten… auf denen sich diese beiden Fahrzeuge befinden, beteiligt sind, die eine
Konfliktsituation darstellen.
Im Folgenden wird anhand von partiellen Situationen (siehe Abbildung 4.13) zunächst die
erste Situation aus der Abbildung 4.12 analysiert und werden mögliche Konfliktsituationen
aufgezeigt. In Abbildung 4.13 sind zusätzlich zu der gleichen Kreuzung aus der ersten Situation noch vier Quadrate eingezeichnet. Diese Quadrate oder auch Zellen dienen dazu, solche
Situationen in der Momentaufnahme zu veranschaulichen, in der sich Fahrzeuge im Kreuzungsbereich (= in der Kreuzungsmitte) befinden, aber auch um den möglichen Fahrtweg eines Fahrzeugs von einer Knotenzufahrt auf eine Knotenabfahrt darzustellen. Fahrzeuge im
Kreuzungsbereich können sich je nach Fall in einer dieser Zellen aufhalten.
42
nord
west
ost
B
süd
nw
no
sw
so
A
Abbildung 4.13: Partielle Situationen auf einer Kreuzung
Zur Orientierung ist neben dem bereits verwendeten Kompass ein weiterer aufgeführt, mithilfe dessen die Lage der Quadrate im Kreuzungsbereich dargestellt werden. nw ist die Bezeichnung für das entsprechende Quadrat und steht als Abkürzung für die Himmelsrichtung Nordwest. Die weiteren drei Abkürzungen für Himmelsrichtungen sind analog zu sehen.
Entscheidend für eine Konfliktsituation sind die beabsichtigten Fahrtrichtungsänderungen der
Fahrzeugführer von Fahrzeugen und nicht irgendwelche bestimmten Fahrzeuge. Die Bezeichnungen A und B sind genauso gut durch ein beliebiges Symbol zu ersetzen und sind hier nur
zur eindeutigen Unterscheidung zwischen den Fahrzeugen gedacht. Als Fahrzeugführer eines
Fahrzeugs hat man z.B. an einer Kreuzung nur die Möglichkeiten das Fahrzeug rechts, links
bzw. geradeaus zu fahren. Deshalb werden ausgehend vom Fahrzeug A die drei Fälle
• links (für links abbiegen)
• rechts (für rechts abbiegen)
• keine (für geradeaus fahren)
untersucht.
Die Fahrtrichtung des Fahrzeugs A aus Abb.4.13 ist fest – sie lautet „Linksabbieger“. Fahrzeug B kann entweder Links-/Rechtsabbieger oder Geradeausfahrer sein.
Im Folgenden wird zuerst die partielle Situation „Fahrzeug B ist Linksabbieger“ betrachtet.
Damit Fahrzeug A, als Linksabbieger im Süden der Kreuzung stehend, nach links abbiegen
kann – also nach Westen auf der Kreuzung – muss es real betrachtet über die Zellen so, no
und nw fahren. Man führe sich den geschilderten Fahrtweg des Fahrzeugs A mit „großzügigem“ Radius des Abbiegebogens vor Augen. Dies entspricht tatsächlich dem in der Realität
häufig gefahrenen Weg beim Linksabbiegen. Realitätsfremdes Abbiegeverhalten oder selten
zurückgelegte Abbiegewege im Alltagsverkehr werden in den weiteren Ausführungen ausgeschlossen. Das Fahrzeug B, als Linksabbieger im Norden stehend, würde sein Ziel, nach Osten der Kreuzung zu kommen, über die Zellen nw, sw, so fahrend erreichen. Die Fahrtwege
der Fahrzeuge A und B überschneiden sich in den Zellen nw und so, d.h. in diesen Zellen laufen diese beiden Fahrzeuge Gefahr zu kollidieren.
43
Die für Konfliktsituationen verantwortlichen Fahrzeuge mit deren Fahrtrichtungen und Himmelsrichtungen der Knotenzufahrten, auf denen sich diese Fahrzeuge befinden, werden in
einer Tabelle namens Konfliktsituation festgehalten, welche in Anlehnung an das ERDiagramm aus Abbildung 4.12 erstellt wird. Nachdem alle Konfliktsituationen gefunden sind,
wird diese Tabelle anschließend mit diesen Informationen aufgeführt und interpretiert.
Die Tabelle Konfliktsituation besteht aus sechs Spalten:
• FZ_X steht für das Fahrzeug von welchem man ausgeht,
• FR_X für dessen Fahrtrichtung,
• HR_X für die Himmelsrichtung der Knotenzufahrt, auf der sich dieses Fahrzeug befindet.
• Die Spalten FZ_Y, FR_Y und HR_Y sind ganz analog zu verstehen.
Im Weiteren wird zuerst der Fall für die partielle Situation betrachtet: Fahrzeug B als Rechtsabbieger und Fahrzeug A weiterhin als Linksabbieger. Anschließend wird dann der Fall
„Fahrzeug B ist Geradeausfahrer“ analysiert.
Das im Norden stehende Fahrzeug B müsste, um nach rechts relativ vom Fahrzeug B ausgesehen abzubiegen, also in den Westen der Kreuzung über die Zelle nw fahren. Somit überschneiden sich die Wege von Fahrzeug A und Fahrzeug B in dieser partiellen Situation in nw.
Im Norden stehend könnte das Fahrzeug B als Geradeausfahrer in den Süden der Kreuzung
gelangen. Auf diesem Weg müssen die Zellen nw und sw überfahren werden. Auch in dieser
Situation kann es zur Kollision kommen, denn beide Fahrzeuge müssen die Zelle nw überqueren, um an die gewünschten Knotenabfahrten zu gelangen.
Die bislang erworbenen Kenntnisse über Konfliktsituationen haben folgende „Bedingungen“:
• Die beteiligten Fahrzeuge (in diesem Falle Fahrzeug A und B) befinden sich auf
gegenüberliegenden Knotenzufahrten einer Kreuzung, Fahrzeug A im Süden und
Fahrzeug B im Norden.
• Ein an der Konfliktsituation beteiligtes Fahrzeug (Fahrzeug A) ist Linksabbieger und
steht im Süden der Kreuzung. Das andere Fahrzeug (Fahrzeug B) schlägt je nach Situation eine der möglichen Fahrtrichtungen (links, rechts, keine) ein.
Die Erkenntnis ist also, dass unter diesen Bedingungen ein als Linksabbieger im Süden stehendes Fahrzeug mit einem im Norden stehenden Fahrzeug, unabhängig von seiner beabsichtigten Fahrtrichtungsänderung, in jedem Fall eine Konfliktsituation herbeiführt. Wie bereits
oben erwähnt, sind die Fahrzeuge A und B durch beliebige Fahrzeuge ersetzbar. Nachdem die
Analyse dieses Falls abgeschlossen ist, stellt sich nun die Frage, ob dieses Zwischenergebnis
auch auf alle Fahrzeuge, die sich auf gegenüberliegenden Knotenzufahrten einer Kreuzung
oder Einmündung befinden, grundsätzlich anwendbar ist, wenn diese eine Konfliktsituation
darstellen (z.B. wenn eines der Fahrzeuge im Osten und das andere im Westen steht, oder
umgekehrt). Um diese Frage zu beantworten, muss man sich zuerst die Beschaffenheit der
Kreuzung anschauen.
44
Diese Kreuzung ist eine Vierer-Kreuzung und ist symmetrisch. Symmetrie wird in der Schulmathematik in Punktsymmetrie und Achsensymmetrie unterteilt. Mathematische Kenntnisse
aus der Schule werden als bekannt vorausgesetzt, dennoch werden besonders wichtige Grundlagen hier wiederholt.
Symmetrie ist ein Begriff aus der Geometrie. Geometrische Objekte mit dieser Eigenschaft
können mittels einer Spiegelung auf sich selbst abgebildet werden, so dass sie unverändert
erscheinen. Unter der Vielzahl unterschiedlicher Symmetrien sind nur die aus der Schule bekannten Symmetrien relevant. Die Achsensymmetrie ist eine Form der Symmetrie, die bei
zweidimensionalen Objekten auftritt, die gemäß der Definition entlang einer Spiegelachse
gespiegelt werden können. Ein geometrisches Objekt (z.B. ein Viereck) ist punktsymmetrisch, wenn es eine Punktspiegelung gibt, die dieses Objekt auf sich selbst abbildet. Die Abbildung einer Kreuzung aufs Koordinatensystem ist in der folgenden Grafik zu sehen:
soy
0
x
Abbildung 4.14: Abbildung einer Kreuzung in einem Koordinatensystem
Die Kreuzung ist sowohl zur x- als auch zur y-Achse symmetrisch. Die Kreuzung ist in dieser
Lage zum Koordinatensystem mit Hilfe von affinen Abbildungen aus der linearen Algebra um
den Ursprung (dieser liegt in der Mitte des Koordinatensystems) drehbar (in positivem und
negativem Drehsinn). Dazu reicht mathematisch gesehen die Kreuzung K mit der
⎛ cos α − sin α ⎞
⎟⎟ zu multiplizieren, K * L.
Matrix L = ⎜⎜
⎝ sin α cos α ⎠
Wenn die Kreuzung z.B. um 180° im positiven Sinn gedreht wird, so ändern sich die partiellen Konfliktsituationen aus der Abbildung 4.13 nicht, denn das Fahrzeug A auf der südlichen
Knotenzufahrt wird durch die Drehung der Kreuzung A in den Norden gedreht und Fahrzeug
B nach Süden. Durch die gleichzeitige Drehung der beiden Fahrzeuge auf ihre gegenseitigen
ursprünglichen Positionen ändert sich an der Konstellation zwischen den Fahrzeugen nichts.
Die Drehung ist auch isometrisch, d.h. längentreu. Eine Koordinatentransformation findet
nicht statt. Mit anderen Worten gibt es aufgrund der Symmetrie und somit Spiegelbildlichkeit
der Kreuzung bei der Drehung keine verminderte oder erhöhte Information.
45
nord
y
west
ost
A
süd
nw
no
sw
so
x
B
Abbildung 4.15: Abbildung der gedrehten Kreuzung in einem Koordinatensystem
Die Blockpfeile geben die Richtung an, in der gedreht wurde. Ausgehend von diesen Erkenntnissen kann man nun die These aufstellen:
Befinden sich zwei Fahrzeuge auf gegenüberliegen Knotenzufahrten einer symmetrischen
Straßenführung (Kreuzung, Einmündung etc.), wobei eines von beiden Linksabbieger ist,
dann und nur dann stellt diese Situation, unabhängig von der beabsichtigten Fahrtrichtung des anderen Fahrzeugs, immer eine Konfliktsituation dar.
Um die Korrektheit dieser These zu beweisen, werden, ohne Beschränkung der Allgemeinheit, zwei Fahrzeuge X und Y eingeführt. Fahrzeug X sei der Linksabbieger und das andere
Fahrzeug Y. Symmetrische Straßenführungen sind spiegelbildlich. Durch die isometrische
Drehung der Straßenführung ändert sich nichts an den Konstellationen der Fahrzeuge zueinander, denn diese werden mitgedreht. Fahrzeug X bleibt Linksabbieger und Fahrzeug Y befindet sich gegenüber. Zwar ändern sich die Himmelsrichtungen der Knotenzufahrten, aber
die partiellen Konfliktsituationen bleiben erhalten.
Im Folgenden werden die Fälle für die partiellen Situationen betrachtet, in denen das Fahrzeug A Rechtsabbieger ist und Fahrzeug B – je nach partieller Situation – Linksabbieger,
Rechtsabbieger oder Geradeausfahrer ist.
46
nord
west
B
ost
süd
nw
no
sw
so
A
Abbildung 4.16: Partielle Situationen auf einer Kreuzung
Damit Fahrzeug A rechts abbiegen kann, muss es über die Zelle so fahren. Fahrzeug B überfährt die Zelle so dann und nur dann, wenn dieses Linksabbieger ist. Somit stellt diese partielle Situation eine Konfliktsituation dar.
Der Fall Fahrzeug A als Geradeausfahrer stellt ebenfalls eine Konfliktsituation dar, wenn
Fahrzeug B links abbiegt, denn auch hier kann es zur Kollision in der Zelle so kommen. Dieser Sachverhalt wird in die Tabelle eingetragen. Es wurde im Verlauf dieses Verfahrens festgestellt, dass diese Ergebnisse unter Nutzung der Symmetrieeigenschaften einer Kreuzung
allgemein angesehen werden können. Zur allgemeinen Formulierung dieser Konfliktsituationen sind die Angaben der Fahrtrichtungen der Fahrzeuge ausreichend.
Bislang sind mögliche Konfliktsituationen zwischen Fahrzeugen auf gegenüberliegenden
Knotenzufahrten betrachtet worden. Auf einer Kreuzung können sich Fahrzeuge aber auch auf
benachbarten Knotenzufahrten befinden (siehe Abbildung 4.11, zweite Situation). Im Weiteren werden partielle Situationen für diese Konstellationen untersucht. Auf einer ViererKreuzung kann ein Fahrzeug maximal zwei „Nachbarfahrzeuge“ haben. D.h., das Erste befindet sich auf – relativ von diesem aus gesehen – der linken Knotenzufahrt und der zweite auf
der – relativ gesehen – rechten Knotenzufahrt.
47
Zuerst sollen die partiellen Situationen analysiert werden, wenn das Nachbarfahrzeug rechts
von dem ausgehenden ist.
nord
west
ost
süd
B
nw
no
sw
so
A
Abbildung 4.17: Partielle Situationen auf einer Kreuzung zwischen zwei Nachbarfahrzeugen
Die blau gestrichelten Pfeile geben die Fälle links, rechts, keine vom ausgehenden Fahrzeug
aus an. Das Verfahren zur Konfliktsituationserkennung für diese partiellen Situationen wird
kompakter erläutert, denn das Verfahren für Fahrzeuge auf gegenüberliegende Fahrzeuge
wurde ausführlich und intensiv besprochen und ist hier prinzipiell übertragbar. Die Zellen, die
das Fahrzeug A, siehe Abbildung 4.17, zu fahren hat, wenn es entweder rechts, links oder
geradeaus fährt, sind bereits aus der Analyse der bisherigen partiellen Situationen bekannt.
Diese werden nochmals aufgeführt.
Als Linksabbieger fährt das Fahrzeug A, im Süden stehend, über die Zellen so, no, nw, als
Rechtsabbieger muss die Zelle so überquert werden, und als Geradeausfahrer sind die Zellen
so und no zu überfahren. Fahrzeug B fährt, als Linksabbieger im Osten stehend, über die Zellen no, nw und sw, um in den Süden der Kreuzung zu gelangen. Als Rechtsabbieger braucht
das Fahrzeug B nur die Zelle no zu befahren, um nach Norden zu kommen. Als Geradeausfahrer kann es sein Ziel, nach Westen zu kommen, nur erreichen, wenn es schon einmal in den
Zellen no und nw gewesen ist. Für den Fall, Fahrzeug A als Linksabbieger, überschneidet
sich dessen Fahrtweg mit dem von Fahrzeug B in der Zelle no und nw, wenn das Fahrzeug
Linksabbieger ist, in der Zelle no, wenn Fahrzeug B Rechtsabbieger ist, in der Zelle no und
nw, wenn es Geradeausfahrer ist.
Ganz analog können nun die Fälle Fahrzeug A als Rechtsabbieger und Fahrzeug B wird je
nachdem Links-/Rechtsabbieger oder Geradeausfahrer auf Konfliktsituationen untersucht
werden. Nach der Analyse auch dieser Fälle wird die Tabelle Konfliktsituation einmal im Zustand mit den Eintragungen zu Konfliktsituationen für das Verkehrszenario „Nachbarfahrzeug
steht zur Rechten vom ausgehenden Fahrzeug“ aufgeführt. Darauffolgend der Zustand fürs
Szenario „Nachbarfahrzeug steht zur Linken vom ausgehenden Fahrzeug“ vorgestellt.
48
FZ_X
….
A
A
A
A
A
A
FR_X
HR_X
FZ_Y
FR_Y
HR_Y
links
links
links
keine
keine
keine
Süd
Süd
Süd
Süd
Süd
Süd
links
rechts
keine
links
rechts
keine
B
B
B
B
B
B
Ost
Ost
Ost
Ost
Ost
Ost
Tabelle 4.2: Konfliktsituation: Zustand fürs Szenario: „Nachbarfahrzeug steht zur Rechten vom ausgehenden Fahrzeug“
Die Analyse des Falles zur Konfliktsituationserkennung, Fahrzeug A im Süden stehend und
Fahrzeug B im Westen, also links vom Fahrzeug A, von welchem man ausgeht, führte zum
Folgenden Ergebnis:
FZ_X
….
A
A
A
A
A
A
FR_X
HR_X
FZ_Y
FR_Y
HR_Y
links
links
rechts
rechts
keine
keine
Süd
Süd
Süd
Süd
Süd
Süd
B
B
B
B
B
B
links
keine
links
keine
links
keine
West
West
West
West
West
West
Tabelle 4.3: Konfliktsituation: Zustand fürs Szenario: „Nachbarfahrzeug steht zur Linken vom ausgehenden Fahrzeug“
Genauso wie für die Aufstellung von Thesen und der Verallgemeinerung der gefundenen Erkenntnisse zur Konfliktsituationserkennung für Fahrzeuge auf gegenüberliegenden Knotenzufahrten kann man nun für Fahrzeuge auf benachbarten Knotenzufahrten verfahren. Dies wird
ermöglicht, wenn man die im Laufe dieses Verfahrens diskutierten Symmetrieeigenschaften
einer Kreuzung berücksichtigt.
Projiziert man in dieser Tabelle die Spalten FR_X und FR_Y, so ergeben sich allgemeine Aussagen zu Konfliktsituationen auf benachbarten Knotenzufahrten für die beiden Szenarien
• Das Nachbarfahrzeug steht zur Rechten vom ausgehenden Fahrzeug
• das Nachbarfahrzeug steht zur Linken vom ausgehenden Fahrzeug
Es werden diese beiden Zustände aus der Tabelle Konfliktsituation im Folgenden gegenübergestellt:
FR_X
links
links
links
keine
keine
keine
FZ_Y
links
rechts
keine
links
rechts
keine
FR_X
links
links
rechts
rechts
keine
keine
FZ_Y
links
keine
links
keine
links
keine
Bemerkenswert ist, dass man als Linksabbieger mehr als doppelt so häufig in Konfliktsituation geraten kann wie ein Rechtsabbieger. Als Rechtsabbieger kommt es theoretisch zu keiner
Kollision, wenn sich das Nachbarfahrzeug auf der linken benachbarten Knotenzufahrt befindet.
49
50
Kapitel 5
Architektur des VADImA-Systems
In diesem Kapitel wird die Architektur des VADImA-Systems vorgestellt. Ferner soll die
Funktionalität der Benutzer- und Datenbankschnittstellen des Systems beschrieben werden.
Im Anschluss daran wird die Paketstruktur erläutert, ohne dabei auf die Codeebene einzugehen
5.1 Komponentenarchitektur
Die Architektur von VADImA basiert auf der konzeptuellen Modellierung der vorangegangenen Kapitel. Sie entspricht einer 3-Schichten-Architektur. Hierbei sind die Arbeitsplätze
(engl.: clients) die Benutzeroberflächen (GUIs). Die mittlere Schicht (Kontrollkomponenten)
besteht aus den Komponenten Kartengenerator, Analysemanager und Monitor. Die letzte
Schicht ist die der Datenbank. Die Kommunikation zwischen den einzelnen Kontrollkomponenten und der Datenbankschicht erfolgt über die in JDBC zur Verfügung stehenden Schnittstellen. Die Kommunikation zwischen der GUI- und der Kontrollkomponentenschicht verläuft über sogenannte Controller-Objekte, welche als Steuerungsmechanismen aus dem
Entwurfsmuster MVC (Model-View-Controller) bekannt sind. Eine detaillierte Beschreibung
der Zusammenarbeit dieser Komponenten befindet sich im Abschnitt Paketstruktur.
Jeder Benutzer von VADImA besitzt administrative Rechte. Somit ist dem Benutzer erlaubt,
die Daten in der Datenbank zu ändern. Die einzige Administrationsarbeit an VADImA wäre
die Pflege und Wartung der Datenbank. Der Zugang zum Java-Quellcode von VADImA und
zur Datenbankstruktur hingegen bleibt Benutzern verwehrt.
51
Bildschirmkarte-GUI
Kartengenerator
Analyse-GUI
Analyse-Manager
JDBC
Monitor-GUI
Monitor
DBMS
DB
Benutzer
Abbildung 5.1: Architektur von VADImA
Die Komponente Kartengenerator stellt die globale Sicht auf das zugrundeliegende Verkehrsszenario dar. Zur Visualisierung der Karte ist ein grafisches Werkzeug, die Bildschirmkarte entstanden, die unter anderem interaktive Funktionalitäten wie Löschen, Ändern und
Hinzufügen von Objekten (Netzknoten, Strecken) von Straßennetzen bereitstellt. Die digitalisierte Karte, stellt ein spezifisches Straßennetz dar, also die globale Sicht von Verkehrsszenarien. Zudem ist die Bildschirmkarte datenbankgestützt, d.h., die Daten zur Visualisierung des
Straßennetzes sind in relationaler Form in der jeweiligen Datenbank abgelegt. Im Allgemeinen bieten Bildschirmkarten heutzutage viele Funktionalitäten an, wie beispielsweise ein Layerkonzept, Navigation und Legende. Diese Kontroll- und Steuerungsmechanismen haben sich
mittlerweile zu De-facto-Standards für Bildschirmkarten etabliert. Bei der Entwicklung der
Bildschirmkarte in VADImA jedoch wurde auf viele dieser Funktionalitäten verzichtet. Jede
analoge wie digitale Karte ist vom Nutzerkreis und Darstellungsziel abhängig. Die Benutzer
von VADImA erwarten, dass die Bildschirmkarte datenbankgestützt sein soll und außerdem
die Möglichkeit bietet, Verkehrsszenarien zu analysieren. Diesen Forderungen wird das
52
zugrundeliegende System gerecht. Die Bildschirmkarte von VADImA ist die Hauptkomponente des Systems, denn von ihr aus sind alle anderen Schichten durch ihre entsprechenden
GUIs (Monitor-GUI, Analyse-GUI) erreichbar.
Die Komponente Analysemanager übernimmt die Aufgabe der Analyse von Verkehrssituationen. Um diese Analyse von Verkehrssituationen nun sowohl nachvollziehen als auch beobachten zu können, dient die grafische Oberfläche Analyse-GUI, die zu diesem Zweck entwickelt wurde. Diese Komponente stellt die lokale Sicht des jeweiligen Szenarios dar. Es sei
daran erinnert, dass die lokale Sicht das „Innere“ eines Netzknotens darstellt. Netzknoten bestehen wiederum aus unterschiedlichen Kreuzungen und Einmündungen.
Fahrzeuge sind nur in der lokalen Sicht sichtbar, denn nur in diesem Kontext finden die in
VADImA aktuell realisierten Analysen statt. Dem Fahrzeug bzw. Fahrzeugführer sind neben
der Lage der Netzknoten (geometrischer Aspekt) die Verbindungen zwischen zwei Netzknoten (Nachbarschaft im topologischen Sinne) wichtig, nicht aber die genaue Streckenführung.
Mit anderen Worten, es geht nicht darum, eine Simulation von Fahrzeugen auf Netzwerken
mit ihren Strecken durchzuführen, da es hier nicht zu einer Kollisionsgefahr kommen kann,
sondern darum, eine Analyse von Verkehrsszenarien an den Knotenpunkten durchzuführen,
denn nur hier ist eine Analyse überhaupt sinnvoll. Fahrzeuge stehen stellvertretend für alle
mobilen Objekte, die im aktiven Straßenverkehr teilnehmen und sich auf Knotenzufahrten
bzw. -abfahrten einer Kreuzung bzw. Einmündung befinden dürfen. Wie man nun in VADImA aus der globalen Sicht in die lokale Sicht gelangt oder wie die Sichten grafisch aussehen,
wird im nächsten Abschnitt beschrieben, wo die Funktionalitäten aus Benutzersicht vorgestellt werden.
Der wesentlichere Teil des VADImA-Systems besteht aus einer Datenbank. Die in der Datenbank befindlichen Daten möchte man visualisieren und auch beobachten können, denn
Verkehrsabläufe sind dynamisch, da Fahrzeuge ständig ihre Positionen ändern. Durch einen
so genannten Monitor kann man hier Abhilfe schaffen. Mit dem Monitor ist es einerseits
möglich, Zustandsänderungen der Datenbank während der Analyse von Verkehrsszenarien zu
verfolgen, andererseits aber auch Verkehrsszenarien umzugestalten, indem man Daten modifiziert, löscht oder hinzufügt. Der Monitor simuliert einen – in einem späteren realen Betrieb
eines solchen Systems sicher vorhandenen – Datenstrom, der von Sensoren im Netzknotenbereich kontinuierlich gespeist wird.
Das DBMS in der Datenbankschicht ist das MySQL-DBMS. Mit Hilfe des Datenbanktreibers mysql-connector-java-5.0-beta-bin.jar findet die Anbindung von JDBC an MySQL statt,
der die zugrundeliegende Datenbank verwaltet. Das DBMS lässt sich nach Wunsch gegen ein
anderes austauschen, da die eingebetteten SQL-Anweisungen in VADImA Standard-SQL
entsprechen und keine SQL-Dialekte enthalten. Dies ist möglich, weil MySQL einen erheblichen Teil des SQL-Standards unterstützt. Lediglich den Datenbanktreiber gilt es hier durch
einen entsprechenden vom neuen DBMS zur Verfügung gestellten zu ersetzen.
53
5.2 Aufbau und Funktionalität der GUIs
In diesem Abschnitt werden die drei verschiedenen GUIs (Bildschirmkarte-, Analyse- und
Monitor-GUI) und ihre Funktionalitäten vorgestellt. Auch hier sollen die folgenden Screenshots die Diskussion über den Aufbau der GUIs unterstützen.
Abbildung 5.2: Bildschirmkarte (globale Sicht)
In der Bildschirmkarte ist ein Straßennetz-Graph zu sehen, welcher manuell angelegt wurde.
Unterhalb der Bildschirmkarte befindet sich eine Fußleiste, die aus sechs Schaltflächen besteht. Mit dem Betätigen der Schaltfläche DB-Karte kann man sich ein Straßennetz visualisieren lassen, dessen Daten in der Datenbank bereits vorliegen. Die Schaltfläche DB-Speichern
erlaubt das Abspeichern von Straßennetzdaten in die Datenbank, z.B. solche, die man manuell
angelegt hat. Zusätzlich bietet VADImA die Speicherung der Daten im XML-Format an.
Die Kreise repräsentieren die Netzknoten, die orangefarbenen und grünen Verbindungslinien
stellen die Strecken des Straßennetzes dar, wobei es sich bei den Orange dargestellten Strecken um bidirektionale Verbindungen handelt. Das Straßennetz selbst wird wiederum auf ein
Gitternetz gezeichnet. Das Gitternetz dient hier als Koordinatensystem. Die darauf eingezeichneten Netzknoten des Straßennetzes werden genau auf die Schnittpunkte der vertikalen
und horizontalen Linien des Gitternetzes platziert.
Darüber hinaus besteht die Möglichkeit, das erstellte Straßennetz in einer so genannten RealDarstellung zu betrachten, welche dazu dient, das gesamte Straßennetz besser zu veranschaulichen, indem es realitätsnah dargeboten wird. Hierzu ist die Schaltfläche JPEG zu betätigen.
Diese wurde mit „JPEG“ bezeichnet, da die Ansicht, die dem Benutzer geboten wird, als
JPEG-Bild erzeugt wurde.
54
Abbildung 5.3: Die Real-Darstellung des Straßennetzes aus Abbildung 5.2
Die Netzknoten besitzen des Weiteren ein Kontextmenü, welches sich durch Anklicken auf
den Knoten öffnet. Darüber kann man
1. in die lokale Sicht (in die Ansicht Analyse-GUI) gelangen,
2. eine neue Strecke (Kante) anlegen, aber auch eine bestehende löschen, und
3. den Netzknoten löschen (es gehen dann auch die mit ihm verbundenen Strecken verloren) (Abbildung 5.4).
Abbildung 5.4: Interaktive Netzmodifikation
55
Abbildung 5.5: Lokale Sicht, Verkehrsszenario
In die lokale Sicht gelangt man über die Bedienung des Kontextmenüs, das durch Anklicken
eines Netzknotens erscheint. In Abbildung 5.5 ist ein Netzknoten Kreuzung mit der Vorfahrtregelungsart Lichtsignalanlage mit Beschilderung zu sehen. Es stehen unterschiedliche Verkehrszeichen zur Beschilderung der Kreuzung zur Verfügung, die durch Ziehen&Loslassen
(engl.: Drag&Drop) an die dafür vorgesehene Stelle (in die roten Rechtecke an der Kreuzung)
gezogen werden können. Das Signalbild der Ampeln kann ebenfalls interaktiv gewechselt
werden.
Zu einem Verkehrsszenario gehören auch die Verkehrsteilnehmer, hier die Fahrzeuge. Die
Pfeile vor den Fahrzeugen geben die Fahrtrichtungsänderung („links“, „rechts“ und „keine“)
an. Ein Fahrzeug mit grünem Pfeil ist ein Rechtsabbieger. Die Pfeile der Geradeausfahrer sind
blau. Ein Fahrzeug mit der Fahrtrichtungsänderung „links“ hat rosafarbene Pfeile. Auch die
Eigenschaften von Fahrzeugen lassen sich ändern, indem man wieder das Kontextmenü durch
Anklicken von Fahrzeugen sichtbar macht und darüber Modifikationen vornimmt (Abbildung
5.5).
Dem Benutzer wird ermöglicht, die Verkehrsszenarien zu modifizieren, so dass in einer lokalen Sicht unterschiedliche Verkehrsszenarien durchgespielt werden können. Die hinter dieser
GUI stehende Komponente Analysemanager ist zuständig für die Durchführung der Analyse
von Verkehrssituationen in der lokalen Sicht durch die im Datenbankschema abgelegten SQLSichten. Die Daten des Straßennetzes müssen spätestens dann in der Datenbank vorliegen,
wenn man die Analyse von Verkehrsszenarien in der lokalen Sicht durchführt. Deshalb müssen alle die Szenarien betreffenden Informationen nach jeder Änderung (z.B. der Fahrzeugwerte) wieder in der Datenbank liegen. VADImA muss also direkt nach jeder Änderung die
Daten in die Datenbank schreiben und die aktualisierten Daten wieder einlesen.
Zur Anzeige des Monitorfensters kann die Schaltfläche Datenbank, siehe Abbildung 5.2,
betätigt werden. Das Monitorfenster visualisiert die Daten aus der Datenbank in Form einer
Tabelle, in der auch interaktiv Änderungen durchgeführt werden können.
56
Abbildung 5.6: Monitor als Tabelle
5.3 Die Paketstruktur von VADImA
Abbildung 5.7: Paketdiagramm von VADImA
Bei den in Abbildung 5.7 aufgeführten Modulen handelt es sich um die wichtigsten Pakete
innerhalb des Systems VADImA. Um Wiederverwendbarkeit und Erweiterbarkeit, also Flexibilität von VADImA gewährleisten zu können, wurde in dem System das Entwurfsmuster
Model-View-Controller (MVC) umgesetzt. Die Schnittstellen der Module sind wohldefiniert,
um die Erweiterbarkeit zu erhöhen.
57
Die Swing-Kompenenten, die für die GUI von VADImA eingesetzt wurden, sind ebenfalls
prinzipiell nach dem MVC-Paradigma aufgebaut, allerdings mit der Modifikation, dass View
und Controller zu einem UI-Delegate zusammengefasst wurden, da die Bedieneigenschaften
und die grafische Repräsentation fast immer zusammengehören.
Betrachtet man nun die Pakete, so befinden sich im Paket org.karte die Klassen zur Erzeugung der Bildschirmkarte. Das Paket org.verkehr ist für die lokale Sicht sowie für die Analyse von Verkehrsszenarien zuständig. Eine lokale Sicht kann allerdings nur existieren, wenn
dazu auch die Netzknoten in der globalen Sicht definiert sind. Deswegen ist das Paket
org.verkehr abhängig von dem Paket org.karte. Sämtliche Klassen, die der Monitor
braucht, sind in org.monitor zu finden. Die Schnittstelle für die Datenbankanbindung sowie
weitere wichtige Klassen zur Bearbeitung von Datenbank-Daten sind in org.db enthalten.
Es besteht eine Abhängigkeit aller Pakete von org.db. Dafür sei erneut daran erinnert, dass
die Analyse von Verkehrsszenarien auf Abfrageergebnisse von SQL-Sichten beruht. Das wiederum hat zur Folge, dass man einerseits zur Aktualisierung der Daten ständig auf die Datenbank zugreifen und andererseits die aktuellen Anfrageergebnisse der SQL-Sichten einlesen
muss. Auch der Monitor muss auf die Datenbank zugreifen, um die Daten zu visualisieren.
Selbst um die Bildschirmkarte zu erstellen, werden Daten aus der Datenbank entnommen.
Aus diesen Gründen sind alle anderen Pakete von org.db abhängig.
Das Modul org.karte
Abbildung 5.8 : Paketdiagramm zu org.karte
Das Paket org.karte.modell enthält folgende Klassen und Pakete:
• Straßennetz,
• Netzknoten,
• Strecke,
• und das Unterpaket org.karte.knotenpunkte.
58
Diese Klassen stellen gewissermaßen die „Anwendungslogik“ der zugrunde gelegten
Bildschirmkarte dar. Diese ist unabhängig von allen Klassen aus anderen Paketen und
kann ohne weiteres in anderen Programmen verwendet werden. In VADImA ist die GUI
ebenfalls unabhängig vom Controller implementiert worden, so dass tatsächlich das
MVC-Paradigma aus [GHJV95] umgesetzt wurde. Somit kann diese GUI (ViewKomponente) leicht durch eine andere ersetzt werden. Um die Kommunikation zwischen
Model-Klassen und GUI-Klassen innerhalb sowie außerhalb der Pakete zu steuern, sind
Controller-Klassen innerhalb der wichtigsten Pakete entstanden, die dann auch die modulübergreifende Kommunikation zwischen diesen Klassen gewährleisten. Wenn sich der
Zustand eines Objekts der Model-Klasse ändert, z.B. die Position eines Netzknotens, wird
die Bekanntgabe der Änderung an das
KarteController-Objekt weitergeleitet.
Dieses übernimmt dann die Änderung an der GUI. Das Paket org.karte.gui enthält u.a.
zwei wichtige Klassen, HauptFrame und StraßennetzJPEG. Die Klasse HauptFrame implementiert das grafische Werkzeug zum Bearbeiten des Straßennetzes, also der Bildschirmkarte. Die Klasse StraßennetzJPEG generiert aus dem Graphen des Straßennetzes
die Real-Darstellung des Straßennetzes als Bild im JPEG-Format.
Das Modul org.verkehr
Abbildung 5.9: Paketdiagramm zu org.verkehr
Auch das Modul org.verkehr wurde nach demselben Entwurfsmuster wie org.karte angefertigt. Die Model-Klassen in org.verkehr sind:
• Fahrzeug,
• Knotenzufahrt,
• Knotenabfahrt,
• Verkehrszeichen,
• Verkehrsanalyse.
59
Ein Fahrzeug-Objekt ändert ständig seine Werte, wie z.B. die Position. Der Monitor muss
jedes Mal rechtzeitig über diese Änderungen benachrichtigt werden. Um eine Aktualisierung
zu realisieren, wurde hier das Observer-Muster eingesetzt. In Java stehen die Klasse java.util.Observable und das Interface java.util.Observer aus dem Paket java.util
für die Umsetzung des Observer-Musters zur Verfügung. Das Fahrzeug-Objekt wird beobachtet, d.h., die Klasse Fahrzeug muss die Klasse java.util.Observable ableiten. Allerdings besteht dabei das Problem, dass die Klasse Fahrzeug bereits von einer anderen Klasse
erbt. Die Programmiersprache Java erlaubt jedoch keine Mehrfachvererbung. Deswegen wurde die Klasse Fahrzeug als Delegated-Observable implementiert. Es ist eine Klasse ObservableClass geschrieben worden, die von der Klasse java.util.Observable erbt. Das
ObservableClass-Objekt ist ein Feld der Klasse Fahrzeug. Wenn eine Änderung eines
Fahrzeugobjekts stattfindet, delegiert das ObservableClass-Objekt der Klasse Fahrzeug die
Nachricht über Änderungen mit Hilfe entsprechender Methoden an die registrierten Observer-Objekte, deren Klassen das Interface java.util.Observer implementieren. In der Klasse Verkehrsanalyse werden Methoden zur Analyse des aktuellen Verkehrsszenarios bereitgestellt. Ein wichtiger dort enthaltener Algorithmus zur Analyse von Verkehrsszenarien wird
im nächsten Kapitel ausführlich erläutert.
Das Modul org.monitor
Das Modul org.monitor ist ebenso nach demselben Design wie die Module org.karte und
org.verkehr entstanden, d.h., die Beschreibung der Struktur sieht analog aus und soll deshalb an dieser Stelle weggelassen werden.
Abbildung 5.10: Paketdiagramm zu org.monitor
60
Das Modul org.db
Das Modul org.db ist für die Kommunikation zwischen der Datenbank und der Anwendung
zuständig. Es enthält die Datenbankschnittstelle. Das Paket ist aus den folgenden Klassen
aufgebaut:
• JDBCConnection,
• DBToData,
• DBToDataIB,
• DBToDataSichten,
• DBToDataUpdate.
Bevor mit JDBC auf eine Datenbank zugegriffen werden kann, muss zunächst eine Verbindung zu ihr hergestellt werden. Das Verbindungsobjekt als Exemplar der Klasse JDBCConnection wird mit Hilfe des Treibermanagers erstellt. Die JDBCConnection-Klasse implementiert das Interface java.sql.Connection. In der Klasse DBToData sind Methoden für
den Zugriff auf persistente Tabellen und das Verbindungsobjekt der Klasse JDBCConnection
bereitgestellt. In der Klasse DBToDataIB sind Methoden enthalten, die ständig auf die SQLSichten in der Datenbank zugreifen. Diese Sichten simulieren Integritätsbedingungen und
überwachen das System auf inkonsistente Zustände. Die Klasse DBToDataSichten enthält
zahlreiche Methoden, mit Hilfe derer auf SQL-Sichten wie in_konflikt_zueinander oder
vorfahrt_rechts_links zugegriffen wird. Es sei darauf hingewiesen, dass SQL-Sichten
eine zentrale Rolle in der vorliegenden Arbeit spielen, da einige wichtige Sichten ursprünglich
als deduktive Regeln vorlagen und bei der Analyse von Verkehrsszenarien zum Einsatz
kommen. Eine detaillierte Betrachtung dieser SQL-Sichten sowie des Java-Codes des Systems
VADImA erfolgt im nächsten Kapitel.
Das Verkehrsszenario kann sich ständig ändern, z.B. durch Fahrzeugwerte und das Signalbild
der Ampeln. Diese Änderungen werden dann in die Datenbank geschrieben. Durch die Änderungen kann sich evtl. auch die Vorfahrtsituation ändern. Um diese nun aber rechtzeitig und
korrekt durchführen zu können, stellt die Klasse DBToDataUpdate Änderungsoperationen zur
Verfügung. Die Klassen DBToDataIB, DBToDataSichten und DBToDataUpdate stellen die
Verbindung mit der Datenbank über das Verbindungsobjekt JDBCConnection jdbcconn her,
das ein Feld der Klasse DBToData ist. Um weitere Funktionalitäten der Klasse DBToData nutzen zu können, erben die anderen Klassen dieses Pakets von dieser Klasse. Dieser beschriebene Sachverhalt ist in der folgenden Abbildung in UML-Notation beschrieben:
Abbildung 5.11: Klassendiagramme aus org.db
61
Wie zuvor erwähnt sind nur die wichtigsten Klassen aufgeführt. Viele dieser Klassen implementieren Schnittstellen, um die Erweiterbarkeit auf hohem Level zu halten. Beispielsweise
implementiert die Klasse Strecke das Interface Kante oder die Klasse Netzknoten das Interface Knoten. All die hier erwähnten Controller-Klassen implementieren die Schnittstelle
IController. Aus Gründen der Übersichtlichkeit wurden sie weggelassen.
Während der Entwurfs- und Entwicklungsphase der Software von VADImA wurde nach dem
iterativen Entwicklungsprozess vorgegangen. Die Anforderungsanalyse wurde mithilfe von
Anwendungsfällen (engl.: Use Cases) durchgeführt. Für den Entwurf wurden unterschiedliche
UML-Diagramme verwendet. Diese bildeten die Grundlage für die erstellten Pakete, Klassen
und Schnittstellen. Für die Tests wurden teilweise JUnit1 benutzt. JUnit ist ein Framework mit
dem Regressionstests durchgeführt werden können [JUni06]. Dabei kennen JUnit-Tests nur
zwei Resultate. Entweder ist der durchgeführte Test gelungen oder nicht. Wenn der Test misslingen sollte, so kann es nur zwei Gründe dafür geben: einen Error (dt: Fehler) oder einen
Failure (dt: falsches Ergebnis), die beide per Ausnahme (engl.: Exception) ausgeworfen werden. Falsche Ergebnisse werden erwartet, während Fehler unerwartet auftreten. Auf diese
softwaretechnologischen Aspekte wird nicht mehr näher eingegangen. Es musste kurz aufgeführt und erwähnt werden, dass während der Konzeption und Realisierung des Anwenderprogramms von VADImA möglichst sich bewährte Konzepte aus Softwaretechnik – iterativer
Entwicklungsprozess, Entwurfsmuster, JUnit-Tests, UML – berücksichtigt worden sind.
1
http://www.junit.org
62
Kapitel 6
Ausgewählte Aspekte der Implementierung
In diesem Kapitel werden Implementierungsdetails auf Codeebene zu den verschiedenen Systemkomponenten, welche in Kapitel 5 beschrieben worden sind, gegeben. Dabei soll der Fokus auf bestimmte wichtige Aspekte der Umsetzung wie beispielsweise den Algorithmus zur
Analyse von Verkehrsszenarien gerichtet werden. Weiterhin sollen Probleme angesprochen
werden, die während der Realisierung aufgetreten sind, und mögliche Lösungsansätze dazu
diskutiert werden.
6.1 SQL-Sichten im System
Die Daten von Verkehrsszenarien befinden sich in der VADImA-Datenbank, welche eigens
zu diesem Zweck angelegt wurde. Die Struktur dieser Datenbank ist eine Umsetzung des konzeptuellen Schemas des Straßennetzes – sowohl globale wie lokale Sicht – in das relationale
Schema.
6.1.1 Integritätsbedingungen und Kontrollsichten in
der VADImA-Datenbank
Integritätsbedingungen (IBen) werden zur Sicherung der Konsistenzen im Straßennetz des
Systems VADImA eingesetzt. Hierfür ist es notwendig, dass globale Integritätsbedingungen
definiert werden, die verhindern, dass es zu inkorrekten Zuständen kommen kann, die durch
Systemfehler bzw. falsche Dateneingaben hervorgerufen werden können. Inkonsistente Zustände der Datenbank können in der Realität zu widersprüchlichen Verkehrssituationen führen. Diese benötigten (globalen) IBen sind durchweg tabellenübergreifend, d.h., sie können
sich auf eine oder mehrere Tabellen oder Sichten beziehen. Eine Formulierung solcher IBen
ASSERRTIONS oder CHECK-Contraints mit eingebetteten Anfragen ist gemäß dem SQLStandard möglich. Sowohl CHECK-Constraints mit eingebetteten Anfragen als auch ASSERRTIONS werden leider von den „klassischen“ DBMS – demnach auch von MySQL – nicht unter63
stützt, können allerdings diese Integritätsbedingungen mit Hilfe von Kontrollsichten „ausgeglichen“ werden, siehe dazu auch Kapitel Grundlagen aus der Informatik. Aus Platzgründen
werden nur einige Integritätsbedingungen detailliert beschrieben.
Das folgende Beispiel zeigt die Notwendigkeit von IBen. Bei der Dateneingabe in die Knotenzufahrtstabelle kann es nämlich passieren, dass einem Netzknoten eine unpassende Anzahl
an Knotenzufahrten zugeordnet wird. Dasselbe gilt aber auch für Knotenabfahrten, was jedoch nicht auftreten darf. Die IB IB1 überprüft in diesem Fall, ob die Anzahl der Knotenzufahrten, welche einer Kreuzung zugeordnet wird, nicht größer oder kleiner als vier ist – eine
Vierer-Kreuzung hat vier Knotenzu- bzw. -abfahrten. Wenn dies der Fall sein sollte, werden
derartige Verstöße in der Tabelle IB1 aufgeführt.
CREATE ASSERTION IB1 AS
CHECK NOT EXISTS (
SELECT DISTINCT k.netzknoten
FROM Knotenzufahrt k, netzknoten n
WHERE n.knotenpunktart = 'Kreuzung'
AND n.ID = k.netzknoten
GROUP BY k.netzknoten
HAVING COUNT(k.ID)>4 OR COUNT(k.ID)<4
);
Die fetteingerahmte SQL-Anfrage der ASSERRTION liefert als Antwort diejenigen Datensätze,
die diesen Verstoß verursachen. Um diese IB-Verstöße rechtzeitig aufspüren zu können, werden Kontrollsichten definiert, die je nach Änderung kontextbezogen aufgerufen werden.
Die Kontrollsicht IB1_violators zur IB-Prüfung der obigen ASSERRTION wird aus der fettgerahmten Anfrage definiert.
CREATE VIEW IB1_violatros AS
(
SELECT DISTINCT k.netzknoten
FROM Knotenzufahrt k, netzknoten n
WHERE n.knotenpunktart = 'Kreuzung'
AND n.ID = k.netzknoten
GROUP BY k.netzknoten
HAVING COUNT(k.ID)>4 OR COUNT(k.ID)<4
);
Die folgende inhärente IB überprüft, ob sich zwei Fahrzeuge auf derselben Knotenzufahrt
befinden. (Diese sogenannten inhärenten IBen sind im erstellten ER-Schema von Verkehrsszenarien aus Kapitel 4 als inhärente Funktionalitäten (1:1, 1:N, N:1) dargestellt.)
CREATE ASSERTION IB2 AS
CHECK NOT EXISTS (
SELECT DISTINCT b.fahrzeug, b.knotenzufahrt
FROM befindet_sich_auf b
WHERE(SELECT COUNT(*)
FROM befindet_sich_auf b1
WHERE b1.knotenzufahrt = b.knotenzufahrt)>1)
);
64
CREATE VIEW IB2_violators AS
(
SELECT DISTINCT b.fahrzeug, b.knotenzufahrt
FROM befindet_sich_auf b
WHERE(SELECT COUNT(*)
FROM befindet_sich_auf b1
WHERE b1.knotenzufahrt = b.knotenzufahrt)>1)
);
Wenn Fahrzeug X Vorfahrt vor Fahrzeug Y hat, kann das Fahrzeug Y nicht gleichzeitig Vorfahrt vor Fahrzeug X haben. Diese IB wird durch die ASSERRTION B3 überprüft.
CREATE ASSERTIONS IB3 AS
CHECK NOT EXISTS (
SELECT v1.fahrzeugX,v1.fahrzeugY
FROM vorfahrt_ vor_rechtslinks v1
WHERE EXISTS
(SELECT * FROM vorfahrt_vor_rechtslinks v2
WHERE v1.fahrzeugY=v2.fahrzeugX
AND v1.fahrzeugX=v2.fahrzeugY)
);
Die Kontrollsicht zu der Integritätsbedingung IB3 lautet wie folgt:
CREATE VIEW IB3_violators AS
(
SELECT v1.fahrzeugX,v1.fahrzeugY
FROM vorfahrt_ vor_rechtslinks v1
WHERE EXISTS
(SELECT * FROM vorfahrt_vor_rechtslinks v2
WHERE v1.fahrzeugY=v2.fahrzeugX
AND v1.fahrzeugX=v2.fahrzeugY)
);
Die Kontrollsicht IB4_violators überwacht die Tatsache, dass sich ein Fahrzeug nicht
gleichzeitig auf Knotenzufahrt bzw. Knotenabfahrt befinden darf. Wenn sich ein Fahrzeug
nicht auf einem Bestandteil des Netzknotens befindet, so ist der Wert an der entsprechenden
Stelle in der Spalte der Tabelle befindet_sich_auf NULL, andernfalls ist sie mit Werten
belegt.
CREATE VIEW IB4_violators AS
(SELECT fahrzeug
FROM befindet_sich_auf b
WHERE knotenzufahrt IS NOT NULL
AND
knotenabfahrt IS NOT NULL);
65
Solange alle Kontrollsichten leer bleiben, hat man nur konsistente Zustände in der Datenbank
vorliegen, ansonsten muss das System entsprechend reagieren, um Verstöße zu melden. Dazu
werden nach jeder Änderung von Verkehrsszenarien, vor allem bei Fahrzeugdaten, entsprechende Methoden in der Anwendung des Systems beispielsweise die Methode
IB4_violators() für die Kontrollsicht IB4_violators aufgerufen. In der Methode
IB4_violators(), weiter unten, greift die Variable preparedsetIB_4_violators auf die
Methode executeQuery() zu, um ihre gekapselte vorkompilierte Anweisung – einfache
SELECT-FROM-Anfrage an die Kontrollsicht IB3_violators – absetzen zu lassen. Ist die
Anfrage leer, ist der Rückgabewert von preparedsetIB_4_violators.executeQuery()
null (Wert in Java), andernfalls wird das Anfrageergebnis mit Hilfe des Zugriffs des resultset-Objekts vom Typ ResultSet auf dessen einzelne Spalten zurückgegeben. Die Ergebnisse
erscheinen dann im Dialogfenster DialogPane.alertDialog(…), wobei im Hintergrund ein
Alarmsignal ertönt. Das Dialogfenster inklusive Ertönen des Alarmsignals erscheint jedes Mal
neu nach dem Wegklicken, bis dieses Problem der Inkonsistenz gelöst ist (Abbildung 6.1).
Abbildung 6.1: Dialogfenster zur Meldung der Inkonsistenz
Das Dialogfenster in Abb. 6.1 wurde in der VADImA-Anwendung zu Demonstrationszwecken zum Erscheinen erzwungen. Damit es erscheint, wurden die Positionen Knotenzu- und
Knotenabfahrt für das Fahrzeug 1 mit Werten außer NULL belegt.
public void IB4_violators()
{
try
{
ResultSet resultSet = preparedsetIB_4_violators.executeQuery();
}
if (resultSet != null)
while (resultSet.next())
{
//statische selbst implementierte Methode der Klasse
DialogPane für das Dialogfenster
DialogPane.alertDialog(null, "Das Fahrzeug “ + resultSet.getString(1)
+“ darf sich nicht gleichzeitig auf Knotenzufahrt und Knotenabfahrt“
+“ befinden");
resultSet.next();
}
resultSet.close();
} catch (SQLException e)
//Ausnahmebehandlung
{
e.printStackTrace(); //Ausgabe des gestoßenen Exception
}
66
Leider bietet das System gegenwärtig keine automatische Behebung dieses Problems, so dass
es manuell gelöst werden muss. Das liegt daran, dass das VADImA-System in der Testphase
bezüglich dieser Aspekte kein Fehlveralten aufwies und somit kein Bedarf zur automatischen
Behebung des Problems bestand. Um dennoch automatisch1 konsistente Zustände nach einer
Inkonsistenz wiederherzustellen, reicht die Möglichkeit, protokollierte Daten auszuwerten,
und zwar jene mit dem jüngsten Zeitstempel. Man denke dabei an ein Lese-/Schreibkopf, der
zwischen den aktuellen sowie zurückliegenden Daten bewegt wird.
Die wenigen hier ausführlich aufgeführten IBen sollen einerseits dem Leser das Gefühl dafür
geben, wie man konsistente Zustände in der Datenbank gewährleistet und was man unter konsistenten Zuständen konkret innerhalb des VADImA-Systems versteht, und darüber hinaus
das Potential der Methode (Definition von IBen über Kontrollsichten) demonstrieren. Das
Grundlagenkapitel führte bereits in das Thema Integritätsbedingung/Kontrollsichten ein.
6.1.2 SQL-Sichten zur Analyse von Verkehrsszenarien
Die Analyse von statischen Zuständen an Kreuzungen/Einmündungen liefert Ergebnisse, welche in den SQL-Sichten der Datenbank zu finden sind. Im Rahmen dieser Arbeit sind viele
Sichten entstanden, jedoch können aus Platzgründen nur wenige wichtige Sichten besprochen
werden. Diese basieren auf dem konzeptuellen und relationalen Entwurf der Verkehrsszenarien aus Kapitel 4.
Es wird im Folgenden eine Pseudo-SQL-Sicht vorgeschlagen, die die Aufgabe hat, herauszufinden, ob zwei Fahrzeuge an einer Kreuzung/ Einmündung in eine Konfliktsituation geraten
sind. Diese Sichten sollen parametrisiert sein. Parametrisierung ist ähnlich zu einer Formel
mit Variablenbelegung (Platzhalter und Gegenteil einer Konstante). Dabei ist eine Formel die
Abstrahierung einer Gesetzmäßigkeit mit unterschiedlichen Größen, d.h., eine einzige Formel
muss auf variable Eingaben entsprechend korrekt reagieren. Speziell in diesem Kontext wird
damit die Erkennung einer allgemeinen Konfliktsituation auf einer Vierer-Kreuzung erreicht,
welche hier exemplarisch gedacht ist.
CREATE VIEW
in_konflikt_zueinander AS
(SELECT DISTINCT b1.fahrzeug AS fahrzeugA, b2.fahrzeug AS fahrzeugB, hk1.netzknoten
FROM (fahrzeug f1 JOIN befindet_sich_auf b1
ON b1.fahrzeug = f1.ID)
JOIN himmelsrichtung_von_knotenzufahrten hk1 ON b1.Knotenzufahrt =
hk1.Knotenzufahrt
JOIN (fahrzeug f2 JOIN befindet_sich_auf b2 ON b2.fahrzeug = f2.ID)
JOIN himmelsrichtung_von_knotenzufahrten hk2 ON b2.Knotenzufahrt =
hk2.Knotenzufahrt
1
Die automatische Wiederherstellung der konsistenten Zustände nach einer Inkonsistenz in der Datenbank ist
gegenwärtig in Bearbeitung, wie sie hier vorgeschlagen ist. Zum Zeitpunkt der Ausarbeitung dieser Arbeit liegen
keine konkreten nennenswerten Ergebnisse vor, weshalb sie hier nicht eingebracht werden.
67
WHERE
(
(hk1.strecke_liegt_zu_netzknoten = '[sued, west, nord, ost: lv]
OR [sued, ost, nord, west: rv]'
AND
((f1.fahrtrichtungsaenderung = 'rechts'
AND ((hk2.strecke_liegt_zu_netzknoten = '[nord, ost, sued, west: elv]
OR [nord, west, sued, ost: erv]'
AND f2.fahrtrichtungsaenderung = 'links')
OR (hk2.strecke_liegt_zu_netzknoten = '[west, nord, ost, sued: lv]'
AND (f2.fahrtrichtungsaenderung='links'
OR f2.fahrtrichtungsaenderung='keine'))))
OR
(f1.fahrtrichtungsaenderung = 'links'
AND ((hk2.strecke_liegt_zu_netzknoten = '[nord, ost, sued, west: elv]
OR [nord, west, sued, ost: erv]')
OR (hk2.strecke_liegt_zu_netzknoten = '[ost, nord, west, sued: rv]
OR [west, nord, ost, sued: lv]'
AND (f2.fahrtrichtungsaenderung = 'links'
OR f2.fahrtrichtungsaenderung='keine'))))
OR
(f1.fahrtrichtungsaenderung = 'keine'
AND ((hk2.strecke_liegt_zu_netzknoten = '[nord, ost, sued, west: elv]
OR [nord, west, sued, ost: erv]'
AND f2.fahrtrichtungsaenderung = 'links')
OR (hk2.strecke_liegt_zu_netzknoten = '[ost, nord, west, sued: rv]
OR [west, nord, ost, sued: lv]'
AND (f2.fahrtrichtungsaenderung = 'links'
OR f2.fahrtrichtungsaenderung='keine'))))
AND
hk1.netzknoten = hk2.netzknoten
))));
Diese Anweisung „hk1.strecke_liegt_zu_netzknoten ='[sued, west, nord, ost: lv] OR
[sued, ost, nord, west: rv]'“ bedeutet, dass man für „hk1.strecke_liegt_zu_netzknoten=“
entweder einen Parameter aus „[sued, west, nord, ost: lv]“ oder „[sued, ost, nord,
west: rv]’“ einsetzen kann. hk1 ist die Knotenzufahrt, auf der sich das Fahrzeug befindet,
von welchem man ausgeht. hk2 ist für das andere Fahrzeug analog zu sehen. Der Ausdruck
„[sued, west, nord, ost: lv]“ ist die parametrisierte Anfrage für das linke Nachbarfahrzeug, vom ausgehenden Fahrzeug betrachtet.
Wenn lv im Ausdruck durch rv ersetzt wird, wird die parametrisierte Anfrage für die Konstellation betrachtet, wenn das andere Fahrzeug rechts vom ausgehenden Fahrzeug steht. Wenn
nun aber erv oder elv im Ausdruck steht, so steht die parametrisierte Anfrage für Fahrzeuge
auf gegenüberliegenden Knotenzufahrten in Abhängigkeit von rv und lv. lv steht als Abkürzung für links_von. rv steht in gekürzter Form für rechts_von. erv ist für entgegenkommend in
Abhängigkeit von rechts_von gekürzt. elv steht für entgegenkommend in Abhängigkeit von
links_von. Es sei angemerkt, dass die Abhängigkeiten zur Erkennung einer Konfliktsituation
für Fahrzeuge auf gegenüberliegende Knotenzufahrten mit rechts_von und links_von hier nur
aus dem Grunde verknüpft sind, weil dadurch die Definition von weiteren parametrisierten
Ausdrücken erspart bleibt.
68
Die folgenden drei Ausdrücke müssen gemeinsam betrachtet werden:
„[sued, west, nord, ost: lv]“ wird für „hk1.strecke_liegt_zu_netzknoten =“ eingesetzt.
„[west, nord, ost, sued: lv]“ oder
„[nord, ost, sued, west: elv]“ werden für „hk2.strecke_liegt_zu_netzknoten =“ einge-
setzt.
Ebenso müssen die folgenden drei Ausdrücke gemeinsam betrachtet werden:
„[sued, ost, nord, west: rv]“,
„[ost, nord, west, sued: rv]“ oder
„[nord,
west, sued, ost: erv]“.
Es sei darauf hingewiesen, dass auch die Reihenfolge der Variablen (hier die Himmelsrichtungsrichtungen) innerhalb der eckigen Klammer sehr wichtig ist, d.h., wenn man z.B. sued
für
„hk1.strecke_liegt_zu_netzknoten=“
einsetzt,
so
muss
west
für
„hk2.strecke_liegt_zu_netzknoten=“ aus „[west, nord, ost, sued: lv]“ gewählt werden
oder nord aus „[nord, ost, sued, west: elv]“, weil sued an der ersten Stelle innerhalb der
eckigen Klammer steht. Somit müssen an den entsprechenden Stellen in der Sicht die Variablen an den ersten Stellen in der eckigen Klammer übernommen werden, hier sind es west oder
nord gewesen.
Es folgt nun ein konkretes Beispiel, an dem die Arbeitsweise dieser Sicht beschrieben wird:
In der SQL-Sichttabelle in_konflikt_zueinander sind für das Beispielszenario entsprechend Abbildung 6.2 folgende Werte zu finden:
fahrzeugX
3
fahrzeugY
2
netzknoten
3
Tabelle 6.1: in_konflikt_zueinander
Zusätzlich zu den Fahrzeugen, die in Konflikt miteinander stehen, wird der Netzknoten angezeigt, in dem sich die Fahrzeuge gerade aktuell befinden. Der Grund, weshalb Fahrzeug 1 aus
der Abbildung 6.2 nicht zu sehen ist, sollte bereits mit dem Wissen aus Kapitel 4 ergründbar
sein. Die Fahrzeuge 3 und 2 sind in eine Konfliktsituation geraten (Tabelle 6.1). Das Ausgangsfahrzeug
ist
der
PKW
3
und
hat
die
Fahrtrichtungsänderung
f1.fahrtrichtungsaenderung
=’west '
relativ
∈ [sued, west,
vom
PKW
f2.fahrtrichtungsaenderung
=’nord' ∈ [west, nord, ost,
=
'keine'
nord, ost:
und steht im hk1.strecke_liegt_zu_netzknoten
lv] der Kreuzung. Der LKW 2 steht zur Rechten
ausgesehen.
Er
hat
= 'links' und steht im
sued: lv] der Kreuzung.
die
Fahrtrichtungsänderung
hk2.strecke_liegt_zu_netzknoten
Sicherlich sind effizientere Formulierungen dieser Sicht möglich. Beispielsweise sind die
JOIN-Operationen im FROM-Teil dieser Sicht in den WHERE-Teil „verschiebbar“. Dadurch kann
eine spezielle (inkrementelle) Untersuchung der Konflikterkennung zwischen den zugrundeliegenden Fahrzeugen erzielt werden. Allerdings geht es hier in erster Linie darum, allgemein
Konfliktsituationen zu erkennen und zu zeigen, wie man diese in SQL-Sichten umsetzen
kann. Unabhängig davon wie man DB-technisch die Erkennung der Konfliktsituation realisiert, müssen letztendlich die Überlegungen des Verfahrens aus Kapitel 4 umgesetzt werden!
69
In der betrachteten Verkehrssituation ist die Lichtsignalsanlage außer Betrieb, somit wird die
Links-Rechts-Regelung für Vorfahrt angewendet.
Abbildung 6.2: Beispielszenario aus VADImA
Die Abbildung 6.2 wird weiterhin benutzt, um eine weitere Sicht vorfahrt_vor_lob_aus
vorzustellen, die eigens für solche Verkehrssituationen (wenn LSA außer Betrieb und die
Vorfahrtregelung auf diesem Netzknoten Lichtsignalanlage ohne Beschilderung ist) erstellt
worden ist. Wer von den Fahrzeugen 1, 2 und 3 warten bzw. zuerst fahren darf, ist in der
SQL-Sicht vorfahrt_vor_lob_aus festgehalten (Tabelle 6.2). Fahrzeug 3 darf vor Fahrzeug
2 fahren. Nach dieser SQL-Sicht müsste das Fahrzeug 1 warten bis Fahrzeug 2 gefahren ist,
jedoch wird Fahrzeug 1 mit Fahrzeug 3 gleichzeitig fahren, da dieses Fahrzeug nicht in der
Tabelle in_konflikt_zueinander aufgeführt wird. Die Spalten K1 und K2 sind Knotenzufahrten, auf denen sich diese Fahrzeuge befinden. Auf Knotenzufahrt K1 steht das Fahrzeug
fahrzeugX.
fahrzeugX
fahrzeugY
netzknoten
K1
K2
2
1
3
19
20
3
2
3
17
19
Tabelle 6.2: SQL-Sicht vorfahrt_vor_lob_aus
Nun folgt die Definition der Sicht vorfahrt_vor_lob_aus in SQL mit deren anschließender
Beschreibung. Es reicht, diese SQL-Sicht näher zu beschreiben, denn die weiteren SQLSichten zu Verkehrsregeln (Vorrang- bzw. Vorfahrtregeln) sind prinzipiell ähnlich aufgebaut,
70
d.h., diese Sicht soll repräsentativ demonstrieren wie der Aufbau weiterer Analyse-Sichten
der Verkehrsszenarien – in VADImA – definiert ist.
CREATE VIEW vorfahrt_vor_lob_aus AS
(SELECT DISTINCT b.fahrzeugX, b.fahrzeugY, k2.netzknoten AS netzknoten,
r.knotenzufahrt2 AS K1,r.knotenzufahrt1 AS K2
FROM rechts_von r
JOIN netzknoten n
JOIN knotenzufahrt K1
JOIN benachbart
WHERE ((b.K1 = r.knotenzufahrt2)
AND (b.K2 = r.knotenzufahrt1)
AND (k1.ID = q.K1)
AND (k2.ID = q.K2)
AND (n.vorfahrtregelung = 'Lichtsignalanlage ohne Beschilderung')
AND (k1.netzknoten = k2.netzknoten)
AND (n.ID = k2.netzknoten))
ORDER BY b.fahrzeugX,b.fahrzeugY);
Eigentlich reicht in vorfahrt_vor_lob_aus die Angabe von Fahrzeugen, denn es geht darum in der Momentaufnahme des Verkehrsablaufs festzustellen, welches Fahrzeug aktuell vorfahren darf. Die Vorfahrtregelung auf diesem Netzknoten erfolgt durch eine Lichtsignalanlage ohne Beschilderung. In der Tabelle benachbart werden benachbarte Knotenzufahrten inklusive der Fahrzeuge, die sich auf diesen Knotenzufahrten befinden, eingetragen. Mit Hilfe
der Tabelle rechts_von wird dann ermittelt, welches der zwei benachbarten Fahrzeuge sich
auf der – relativ gesehen – rechten Knotenzufahrt befindet. Da die Lichtsignalanlage außer
Betrieb und die Kreuzung nicht beschildert ist, muss die Rechts-Links-Regelung angewendet
werden. Vorfahrt von zwei Fahrzeugen hat derjenige, der von rechts kommt (Tabelle 6.2 und
Abbildung 6.2).
Abschließend zu diesem Abschnitt werden einige wichtige SQL-Sichten aufgezählt. Die folgenden Sichten „regeln“ die Vorfahrt auf
• über- und untergeordneten Knotenzufahrten (vorfahrt_vor_ueberunter),
• im Netzknoten, dessen Vorfahrtregelung Lichtsignalanlage mit Beschilderung ist
(vorfahrt_vor_lmb),
• im Netzknoten, dessen Vorfahrtregelung Lichtsignalanlage ohne Beschilderung ist
(vorfahrt_vor_lob).
6.2 Details zur grafischen Darstellung und zu
Algorithmen in VADImA auf Codeebene
In diesem Abschnitt wird beschrieben, wie die Methode zur Darstellung des Straßennetzes auf
Codeebene funktioniert. Weiterhin wird gezeigt, auf welche Weise Fahrzeuge visualisiert
werden und wie die Aktualisierung der Fahrzeugdaten in der Datenbank erfolgt. Es sei daran
erinnert – wie bereits zuvor im einleitenden Kapitel erwähnt – dass sich Datenbankanwendungen nur dann adäquat verständlich übermitteln lassen, wenn grafische Darstellungen bzw.
grafische benutzerfreundliche Schnittstellen zur Verfügung stehen.
71
Im letzten Unterabschnitt wird der Algorithmus zur Analyse von Verkehrsszenarien näher
erläutert. Es geht darum, das „Zusammenspiel“ des Verkehrs-Analyse-Algorithmus mit den
Analyse-Sichten aufzuzeigen, denn die Analyse-Sichten spielen in dieser Arbeit eine zentrale
Rolle.
6.2.1 Visualisierung der globalen Sicht des Straßennetzes
Um das Straßennetz in der Real-Darstellung zeichnen zu können, ist
1. die Kenntnis über die Knotenpunktart des Netzknotens nötig. Unter Knotenpunktart sind sämtliche Formen der Einmündung und Kreuzungen zu verstehen.
2. die absolute Koordinate des Netzknotens auf der Bildschirmkarte nötig. Die absoluten Koordinaten sind einzig und allein fürs Zeichnen (Visualisierung) gedacht,
da die Analyse von Verkehrsszenarien auf topologischen Netzen (Straßennetzen)
durchgeführt wird.
Die Koordinate (x,y) eines Netzknotens im zweidimensionalen Raum IR x IR bildet fürs
Zeichnen den Ausgangspunkt. Von diesem Punkt aus werden die Knotenpunkte gezeichnet.
Dieser Punkt befindet sich in der Mitte des Knotenpunktes. So vereinfacht sich das Zeichnen
von miteinander verknüpften Knotenpunkten. Die Verknüpfung muss dabei so erfolgen, dass
eine Knotenzufahrt mit einer Knotenabfahrt aus einem anderen Knotenpunkt verbunden wird
(Abbildung 6.3). Straßenabschnitte werden mit Rechtecken gezeichnet.
Abbildung 6.3: Der rote Punkt ist der Ausgangspunkt fürs Zeichnen
Der rote Punkt in der Abbildung 6.3 ist nur zur grafischen Veranschaulichung eingezeichnet
und ist in der Darstellung des Straßennetzes in der Real-Darstellung im System VADImA
ausgeblendet. Siehe dazu auch die Abbildung 5.3. Im Folgenden wird eine Methode aus VADImA zum Zeichnen von Knotenpunkten vorgestellt.
public void drawKnotenpunkt(Graphics g)
{
Graphics2D g2 = (Grapihcs2D) g;
. . .
//Kreuzung
g2.fillRect(xCoord-20,Math.abs(yCoord-100),40,200);
g2.fillRect(Math.abs(xCoord-100),Math.abs(yCoord-20), 200,40);
// horizontale gestrichelte Linien
g2.draw(new Line2D.Double(Math.abs(xCoord-20) , Math.abs(yCoord), Math.abs(xCoord-100),
Math.abs(yCoord)));
g2.draw(new Line2D.Double(xCoord+20 , yCoord , xCoord+100 , yCoord));
//vertikal
g2.draw(new Line2D.Double(Math.abs(xCoord), Math.abs(yCoord-25), Math.abs(xCoord),
Math.abs(yCoord-100)));
g2.draw(new Line2D.Double(Math.abs(xCoord) , Math.abs(yCoord+25) , Math.abs(xCoord),
Math.abs(yCoord+100)));
}
72
In der Methode drawKnotenpunkt(Graphics g), zuständig fürs Zeichnen von Knotenpunkten, ist nur das Codefragment zur Konstruktion einer Vierer-Kreuzung zu sehen. Die Felder
xCoord und yCoord sind die Koordinatenwerte von dem aktuellen Netzknoten. Die Methoden
g2.fillRect(…), auf die das Objekt g2 der Klasse Graphics2D zugreift, zeichnen das Kreuz.
Die Methoden g2.draw(…) malen jeweils die horizontalen und vertikalen gestrichelten Linien
zur Trennung zwischen Knotenzufahrten und Knotenabfahrten, in Abhängigkeit von dem
Punkt (xCoord,yCoord).
6.2.2 Methoden zur Visualisierung der lokalen Sicht
und zur Aktualisierung von Fahrzeugdaten
Wie eine Kreuzung/Einmündung dargestellt ist, ist bereits im vergangenen Abschnitt beschrieben. Der Fokus in diesem Abschnitt wird auf die Darstellung von Fahrzeugen sowie die
Aktualisierung der Daten in der Datenbank gesetzt, aber auch Probleme und Lösungsansätze
sollen angesprochen und diskutiert werden. Fahrzeuge zählen auch zur lokalen Sicht, da sie
momentan in VADImA in der lokalen Sicht zu sehen sind, jedoch erscheint die Erweiterung
zur Simulation – dies wird weiter unten beschrieben – in der globalen Sicht als sinnvoller.
Neben Fahrzeugen können auch Verkehrsszenarien in der Entwurfssicht ihre Daten ändern,
beispielsweise Änderung der Verkehrszeichen.
Visualisierung von Fahrzeugen
Damit ein Fahrzeug je nach Position innerhalb einer Kreuzung/Einmündung richtig und realitätsgetreu gezeichnet wird, ist es notwendig, die Himmelsrichtungen der Knotenzu- bzw.
Knotenabfahrt zu wissen. Das Fahrzeug-Objekt wird mithilfe von Fahrzeug-Bildern, entnommen aus der Straßenverkehrsordnung, dargestellt. Für jede Position auf einer Kreuzung/Einmündung wurde ein passendes Bild erzeugt. D.h., ein Fahrzeug, welches sich beispielsweise auf einer Knotenzufahrt im Norden einer Kreuzung befindet, wird vertikal mit der
Front nach unten abgebildet. Sobald ein Positionswechsel eines Fahrzeugs stattfindet, muss
die folgende Methode aufgerufen werden, damit je nach Position entsprechend ein anderes
Bild geladen wird. Es ist nur das Codefragment aus VADImA zu sehen, wenn ein Fahrzeug
auf einer Knotenzufahrt im Norden oder im Osten steht.
getFahrzeugBild()
{
…
if (this.getKnotenzufahrt()!= null)
{
if (this.getKnotenzufahrt().getHimmelsrichtung()!= null)
if (this.getKnotenzufahrt().getHimmelsrichtung().equals("nord"))
{
image = new ImageIcon(org.verkehr.gui.AnalysePanel.class.getResource
(KonstantenTabelle.RELATIV_PATH_AF_IMAGE+“\\gefahrt\\fahrzeug_nord.gif“))
.getImage();
} else if (this.getKnotenzufahrt().getHimmelsrichtung().equals("ost"))
{
image = new ImageIcon(org.verkehr.gui.AnalysePanel.class.getResource
(KonstantenTabelle.RELATIV_PATH_AF_IMAGE+“\\gefaehrt\\fahrzeug_ost.gif“)
.getImage();
…}}
73
Das ständige Laden eines neuen richtigen Bildes nach einem Positionswechsel kann auf Dauer ineffizient werden, wenn man bedenkt, dass besonders viele Fahrzeuge im Straßennetz dargestellt werden. Ein weiteres Problem in dieser Implementierung ist vorprogrammiert, wenn
VADImA auf Funktionalitäten wie Simulation von Fahrzeugen auf beliebigen Straßenetztopologien, mit dem Fokus auf die Bewegungen und exakte Positionsänderungen, erweitert
wird. Um Fahrzeuge in dieser Simulation auf Netztopologien für beliebige Positionen realitätsgetreu darzustellen, müsste man also für jede beliebige Position ein entsprechendes Bild
anfertigen. Stattdessen kann man affine Transformationen verwenden, in denen ein Bild in
unterschiedlichste Stellungen umgewandelt werden kann. Im Paket java.awt.Graphics2D
stehen dafür die nötigen Methoden bereit.
Diese Diskussion soll zeigen, dass während der Implementierungsphase auf Anhieb elementar
erscheinende Umsetzungen wie die Methode getFahrzeugBild() – welche ihre Aufgabe
innerhalb des VADImA gegenwärtig hervorragend erfüllt – im Nachhinein Probleme wie z.B.
Effizienzverlust herbeiführen und auch die Erweiterbarkeit von VADImA in Bezug auf diese
Simulation geringfügig einschränken kann.
Aktualisierung von Fahrzeugdaten in der Datenbank
Bereits in Kapitel 5 wurde geschildert, dass sobald ein Fahrzeug-Objekt seine Daten ändert,
alle ihn beobachtenden Objekte über Controller-Objekte benachrichtigt werden. Hierzu
dient das umgesetzte Observer-Entwurfsmuster aus [GHJV95]. Auf diese softwaretechnologischen Aspekte wird hier deshalb nicht erneut eingegangen.
Im Folgenden wird beschrieben, wie die Fahrzeugdaten nach Positionswechsel – beispielsweise hier, wenn Fahrzeuge auf Knotenzufahrt stehen und nach Knotenabfahrt „springen“ –
aktualisiert werden. Sofortiges Aktualisieren der entsprechenden Fahrzeugdaten ist unabdingbar, da VADImA ständig die aktuellsten Daten der Analyse-Sichten braucht, um korrekt auf
unterschiedliche Verkehrsszenarien reagieren zu können.
Es gibt zwei Methoden setFahrzeugKZToKA() und setDBFahrzeugWerteKA(Fahrzeug
fahrzeug, int aktuellerKnotenpunktart), die für das Aktualisieren von Fahrzeugen, die
von Knotenzu- auf Knotenabfahrt fahren, zuständig sind.
Die in der Methode setFahrzeugKZToKA() enthaltene SQL-Update-Anweisung ist parametrisiert und ist somit ein PreparedStatement – es liegt in vorkompilierter Weise vor. Das hat
den Vorteil, dass die Syntaxanalyse bzw. Vorbereitung der Anfrageoptimierung einmalig erledigt wird. Bei der Ausführung werden die formalen Parameter durch aktuelle Werte ersetzt
und an das DBMS weitergeleitet, ohne erneut kompiliert werden zu müssen. Die vorkompilierte Anweisung kann wiederholt ausgeführt werden und bringt dadurch enorme Laufzeitvorteile. Diese Methode wird nur einmal beim Starten des Systems aufgerufen.
Nun stellt die parametrisierte Update-Anweisung, welche vier formale Parameter enthält, die
folgende allgemeine Funktionalität bereit: Sie nimmt die Eintragung der Identifikationsnummer der Knotenabfahrt in die Tabelle befindet_sich_auf in der Spalte Knotenabfahrt auf
der Zeile des zugrundeliegenden Fahrzeugs vor, auf welche das Fahrzeug von der Knotenzufahrt aus zufährt.
74
private void setFahrzeugKZToKA() throws SQLException
{
this.query = "UPDATE befindet_sich_auf b SET b.knotenabfahrt =
(SELECT gka.Knotenabfahrt
FROM himmelsrichtung_von_knotenabfahrten gka,
himmelsrichtung_von_ knotenzufahrten gkz,
Knotenzufahrt KZ,Knotenabfahrt KA
WHERE gka.Knotenabfahrt = KA.ID
AND gkz.Knotenzufahrt = KZ.ID
AND gkz.strecke_liegt_zu_netzknoten =?
AND gka.strecke_liegt_zu_netzknoten =?
AND KA.netzknoten = KZ.netzknoten
AND KZ.netzknoten=?)
WHERE b.fahrzeug =?";
preparedsetFahrzeugKZToKA = jdbcconn.getConnection().prepareStatement(query);
}
Leider bietet die Anweisung nicht die Möglichkeit, gleichzeitig den Knotenzufahrtswert des
zugrundeliegenden Fahrzeugs in der entsprechenden Zeile auf NULL zu setzen. Das liegt daran, dass MySQL nicht erlaubt mehrere Spaltenwerte einer Zeile in einer UPDATE-Anweisung
zu ändern, wenn sich eine der neuen Spaltenwerte aus komplexen SELECT-Unterabfragen ergibt, deshalb kann man nicht einfach in die obige UPDATE-Anweisung zusätzlich
b.Knotenzufahrt=NULL einfügen. Das führt dann zum inkonsistenten Zustand, denn die Integritätsbedingung IB4 aus Abschnitt 6.1.1 besagt, dass ein Fahrzeug sich nicht gleichzeitig
auf Knotenzu- und Knotenabfahrt befinden darf. Dieses Problem wurde ähnlich wie bei den
Transaktionen dadurch gelöst, dass man inkonsistente Zwischenschritte erlaubt: „Manche
Übergänge von konsistentem Zustand in konsistenten Folgezustand sind durch inkonsistente
Zwischenschritte möglich“ [Mant03]. In VADImA wird die Ausführung der Integritätsüberprüfung nach jeder Aktualisierung verzögert durchgeführt, nachdem der Knotenzufahrtswert
des zugrundeliegenden Fahrzeugs auf NULL gesetzt worden ist, wenn sich dieses Fahrzeug
bereits auf Knotenabfahrt befindet.
Nun wird die Methode setDBFahrzeugWerteKA(Fahrzeug fahrzeug, int aktuellerKnotenpunktart) beschrieben, welche konkrete Werte für die parametrisierte UPDATEAnweisung setFahrzeugKZToKA() liefert. Wie bereits zuvor erwähnt, enthält diese Anweisung vier formale Parameter, die mit konkreten Werten belegt sein müssen. Auch hier dient
der Knotenpunkt Kreuzung als Beispiel zum Erklären dieser Methode. Die Funktionsweise
läuft wie folgt ab: Zuerst wird festgestellt, ob sich das jeweilige Fahrzeug auf Kontenzufahrt
befindet. Dazu gibt es ein Feld befindet_sich_auf der Klasse Fahrzeug, welches je nach
Position die Konstanten Fahrzeug.KNOTENZUFAHRT oder Fahrzeug.KNOTENABFAHRT annimmt. Dann wird bestimmt, auf welcher Knotenpunktart sich das Fahrzeug befindet – hier
eine Kreuzung. Diese Informationen sind für die passende Parameterauswahl für die parametrisierte UPDATE-Anweisung wichtig. Wenn sich das Fahrzeug im Süden der Kreuzung befindet,
so
wird
für
den
Ausdruck
(erster
formaler
Parameter)
gkz.strecke_liegt_zu_netzknoten =? aus setFahrzeugKZToKA() preparedsettDBFahrzeugWerteKA.setString(1, "sued") in setDBFahrzeugWerteKA(Fahrzeug fahrzeug, int aktuellerKnotenpunktart) eingesetzt. Wenn die Fahrtrichtungsänderung des
Fahrzeugs beispielsweise keine ist, so wird für den Ausdruck (zweiter formaler Parameter)
gka.strecke_liegt_zu_netzknoten =? preparedsetPreparedsetDBFahrzeugWerteKA.setString(2, "nord") eingesetzt, denn ein Fahrzeug, welches sich auf der Knotenzu-
fahrt im Süden der Kreuzung befindet und geradeaus fährt, gelangt auf die Knotenabfahrt im
Norden der Kreuzung. Für den Platzhalter des Ausdrucks (dritter formaler Parameter)
KZ.netzknoten=? wird die ID-Nummer preparedsetPreparedsetDBFahrzeugWerteKAsetInt(3, fahzeug. getKnotenzufahrt().
getNetzknoten().getID()) des Netzkno75
tens eingesetzt, auf dem sich das Fahrzeug befindet. Für den vierten formalen Parameter
b.fahrzeug =? wird die ID-Nummer preparedsetPreparedsetDBFahrzeugWerteKA.setInt(4, fahrzeug.getID()) des zugrundeliegenden Fahrzeugs eingesetzt.
public void setDBFahrzeugWerteKA(Fahrzeug fahrzeug, int aktuellerKnotenpunktart)
{
if (fahrzeug != null)
if (fahrzeug.getKnotenzufahrt() != null)
if (fahrzeug.befindet_sich_auf_zustand == Fahrzeug.KNOTENZUFAHRT){
switch (aktuellerKnotenpunktart) {
case KonstantenTabelle.KREUZUNG:
try {
if (fazeug.getKnotenzufahrt().getHimmelsrichtung().equals("sued")){
preparedsettDBFahrzeugWerteKA.setString(1, "sued");
if (fahrzeug.getfahrtrichtungsaenderung().equals("keine")){
preparedsetPreparedsetDBFahrzeugWerteKA.setString(2, "nord");
}
else if (fahrzeug.getfahrtrichtungsaenderung().equals(" links")){
preparedsetPreparedsetDBFahrzeugWerteKA.setString(2, "west");
}
else if (fahrzeug. getfahrtrichtungsaenderung().equals ("rechts")){
preparedsetPreparedsetDBFahrzeugWerteKA.setString(2, "ost");
}
…..
….
preparedsetPreparedsetDBFahrzeugWerteKA.
setInt(3,fahrzeug.getKnotenzufahrt().getNetzknoten().getID());
preparedsetPreparedsetDBFahrzeugWerteKA.setInt(4, fahrzeug.getID());
preparedsetPreparedsetDBFahrzeugWerteKA.executeUpdate();
}
}
Zusammenfassend zu diesem Abschnitt ist anzumerken, dass zur Aktualisierung der Fahrzeugdaten nur der Aspekt diskutiert wurde, in dem Fahrzeuge von Knotenzu- auf Knotenabfahrt fahren. Fahrzeuge können auch von Knotenab- auf Knotenzufahrt „springen“, d.h., dabei
findet ein Netzknotenwechsel statt. Fahrzeuge können ihre Fahrtrichtung ändern oder auch
total vom Verkehr entfernt oder neu eingeführt werden (Hinzufügung und Löschung). Auch
diese Informationen müssen umgehend in die Datenbank geschrieben werden. Die zugehörigen UPDATE-Anweisungen zu diesen Aspekten sind ebenso als PreparedStatement umgesetzt worden. Deshalb wird hier auf deren gesonderte Beschreibung verzichtet.
6.2.3 Methode zur Analyse von Verkehrsszenarien
Der Algorithmus verkehrsAnalyse(…) aus der Klasse Verkehrsanalyse ist dafür verantwortlich, dass Fahrzeuge in der lokalen Sicht nach Verkehrsregeln fahren. Zudem werden
Verkehrsabläufe toleriert, die zwar gegen die Regeln „verstoßen“, allerdings in der Realität
zuhauf vorkommen, wenn dabei Kollisionsgefahr ausgeschlossen ist. Dieser Algorithmus
wird zuerst in einem Flussdiagramm besprochen. Anschließend folgt die Beschreibung der
wichtigsten Aspekte auf Codeebene.
76
Bestimmung der Vorfahrtregelung des
aktuellen Netzknotens, auf dem sich das
Fahrzeug befindet.
getNetzknoten().getVorfahrtregelung()
wahr
falsch
Ist der Netzknoten
LSA gesteuert und ist
die LSA intakt?
Ermittle, wer (Fahrzeuge) grüne und rote Ampeln hat
Fahrzeuge mit grün
wahr
falsch
isBlockade ()
wahr
falsch
Löse die Blockade, wähle zufällig ein
Fahrzeug aus, das dann fährt
hat es Vorrangde/Vofahrthabende
Warte bis diese gefahren sind, dann fahre
Fahre
Fahrzeuge in Konflikt?
wahr
Fahrzeuge, die Vorfahrt und Vorrang haben, fahren
setvor_fahrt_rang_reli_fahre(getNetzknoten().getNetzknotenID()
falsch
Fahrzeuge, die nicht in Konflikt
stehen, fahren
Abbildung 6.4: Flussdiagramm zum Ablauf des Algorithmus
Zuerst muss ermittelt werden, wie die Vorfahrt im aktuellen Netzknoten geregelt wird. Wenn
die Vorfahrtregelung auf diesem Netzknoten Lichtsignalanlage (LSA) ist und zudem die LSA
in Betrieb ist, so ist herauszufinden, welche Fahrzeuge auf Knotenzufahrten stehen, an dessen
Ampel gerade grün ist. Fahrzeuge, die auf diesen Knotenzufahrten stehen, fahren, wenn sie
keinen Vorfahrt-/Vorranghabenden haben und nicht blockiert werden, ansonsten müssen sie
warten, bis die in Vorfahrt-/Vorrang stehenden gefahren sind.
77
Das Wort blockieren tauchte in Zusammenhang mit Verkehrssituationen bereits zuvor mehrmals auf und es soll deshalb definiert werden, was man unter blockieren oder einer Blockadebzw. Verklemmungssituation an einer Kreuzung/Einmündung versteht: Eine Verklemmung
an einer Einmündung/Kreuzung einer Verkehrssituation liegt genau dann vor, wenn jedes
Fahrzeug in der Einmündung/Kreuzung mindestens einen Fahrbevorrechtigten nach [StVO04]
hat, so dass sie sich alle gegenseitig an der Weiterfahrt hindern (blockieren).
Bei Kreuzungen/Einmündungen mit Vorfahrtregelung LSA, der intakt ist, kann es nur zur
Verklemmung kommen, wenn sich (zwei) Fahrzeuge auf gegenüberliegenden Knotenzufahrten befinden und grüne Ampeln haben und zudem die Fahrtrichtungsänderung links haben.
Bislang wurde der Fall behandelt, wenn die Vorfahrtregelung LSA ist. Bei allen anderen Fällen der Vorfahrtregelung auf dem Netzknoten tritt der Prozess der Konfliktsituationserkennung ein, nach dem die Blockadesituation gelöst wurde. Fahrzeuge, die nicht an Konfliktsituationen beteiligt sind, fahren. Auch Fahrzeuge, die Vorfahrt/Vorrang haben, fahren.
Die Untersuchungen zur Konfliktsituationserkennung im Rahmen dieser Arbeit haben gezeigt, dass unterschiedliche Verkehrssituationen noch lange keine Konfliktsituationen darstellen. Das hat zur Folge, dass simultanes Fahren von Fahrzeugen an einer Kreuzung möglich
ist, obwohl manche dieser nach [StVO04] hätten warten müssen, bis die weiterfahrtsbevorrechtigten Fahrzeuge die Kreuzung überquert haben. Das hat wiederum zur Folge, dass die
obige Definition zur Verklemmung zu lockern ist, wenn man die Fahrtrichtungsänderung der
Fahrzeuge bei der Definition berücksichtigt. Aus den Ergebnissen zum Konfliktsituationserkennungsverfahren und dem bereits oben genanten Fall kann es nur zu zwei Verklemmungssituationen kommen:
1. Zyklische Verklemmungssituationen entstehen, wenn alle Fahrzeuge an einer Kreuzung ein Nachbarfahrzeug auf der rechtsbenachbarten Knotenzufahrt (auf allen Knotenzufahrten müssen Fahrzeuge sein) und alle die Fahrtrichtungsänderung links haben.
2. Eine weitere Situation kann zur Blockade führen, wenn sich Fahrzeuge auf gegenüberliegen Knotenzufahrten befinden und deren Fahrtrichtungsänderung links ist.
Beispielszenario
Der Ablauf der Methode verkehrsAnalyse(…) wird beispielhaft an Abbildung 6.5 beschrieben. Bereits das Flussdiagramm gab einen Überblick über die Funktionsweise und den Aufbau der Methode. Zum besseren Verständnis ist der irrelevante Teil des Codes dieser Methode
ausgeblendet worden, denn sie ist ziemlich komplex aufgebaut. In der Abbildung ist eine
Kreuzung mit der Vorfahrtregelung Recht-Links-Regel zu sehen, d.h., der zugehörige Netzknoten hat keine Einrichtung. Im Programm steht die Konstante KE dafür. Auf einfache Weise wird festgestellt, ob die aktuelle Verkehrssituation eine Verklemmung ist. Die isBlockade()-Methode prüft auf das Vorhandensein einer Blockade, in der alle Fahrzeuge Linksfahrer
sind. Wenn es sich um Verklemmung handelt, so löst sie diese nach einem einfachen Prinzip
auf. Wenn es sich nicht um eine Verklemmung handelt, so wird eine Konflikterkennung mit
Hilfe der Methode setin_in_konflikt_zueinander() durchgeführt. In der Datenbank der
Tabelle in_konflikt_zueinander findet man im Falle des obigen Verkehrsszenarios folgende Werte:
78
fahrzeugX
1
2
1
3
3
4
fahrzeugY
2
1
3
1
4
3
netzknoten
3
3
3
3
3
3
Tabelle 6.3: in_konflikt_zueinander
Es ist keineswegs als Redundanz anzusehen, dass sich zwei in Konflikt zueinander stehende
Fahrzeugpaare, in dieser Tabelle einmal als (fahrzeugX ,fahrzeugY,netzknoten) und
zum anderen vertauscht als (fahrzeugY ,fahrzeugX,netzknoten) vorkommen, denn es
ermöglicht eine komfortable Verknüpfung mit anderen Tabellen.
Abbildung 6.5: Beispielverkehrsszenario
Wie man in der Tabelle 6.3 sieht, stehen alle Fahrzeuge in Konflikt zueinander. Die Methode
in_konflikt_zueinander() führt die, oben bereits beschriebene, Konfliktsituationserkennung durch und setzt alle in Konflikt stehenden Fahrzeuge in den Wartemodus. Somit sind
alle Fahrzeuge zunächst an der Weiterfahrt gehindert. Die setvor_fahrt_rang_reli_fahre(…) erlaubt solchen Fahrzeugen die Weiterfahrt, die in der Tabelle 6.4 in der Spalte fahrzeugX, aber nicht in fahrzeugY vorkommen. Somit können die Fahrzeuge 2 und 4 fahren.
79
fahrzeugX
2
3
4
fahrzeugY
1
1
3
netzknoten
3
3
3
Tabelle 6.4: SQL-Sicht vor_fahrt_rang_rechtslinks
Die SQL-Sicht vor_fahrt_rang_rechtslinks setzt sich aus den Sichten vorfahrt_rechtlinks und vorrang_vor (gibt zwischen zwei Fahrzeugen auf einem Netzknoten den Vorranghabenden wieder und besitzt eine ähnliche Struktur wie vorfahrt_rechtlinks) zusammen, wobei nur Fahrzeuge aus Konfliktsituationen enthalten sind.
Während die Fahrzeuge 2 und 4 auf die Knotenabfahrt zufahren bzw. schon drauf sind, müssen die Fahrzeuge 3 und 1 warten (Abbildung 6.6).
public synchronized boolean verkehrsAnalyse(…)
{
…
//ziemlich vereinfacht dargestellt
if(getNetzknoten().getVorfahrtregelung().toLowerCase().
equals(KonstantenTabelle.KE.toLowerCase())){
if (isBlockade ()){
blockadeLoesen() ;
// es wird nach einfachem Prinzip aufgelöst, in dem einem Fahrzeug die Weiterfahrt
// ertaubt wird
}
else {
verkehrController.getDbdataSicht().setin_in_konflikt_zueinander ();
verkehrcontroller
.getDbdataSicht().setvor_fahrt_rang_reli_fahre(getNetzknoten().getNetzknotenID());
}….
}
80
Abbildung 6.6: Die Fahrzeuge 3 und 4 sind gefahren
Nachdem der Algorithmus einmal durchlaufen wurde, kann die Analyse des so entstandenen
Verkehrsszenarios neu begonnen werden. Daraufhin reicht lediglich die Anwendung der Vorrangregel.
Dieser Abschnitt hat gezeigt, dass für die Analyse von Verkehrsszenarien unterschiedliche
SQL-Sichten eingesetzt werden, die ihrerseits wiederum aus SQL-Sichten zusammengesetzt
sind oder aus Basistabellen abgeleitet oder in Kombination entstanden sind. Ohne diese SQLSichten wäre eine datenbankgestützte Analyse von Verkehrsszenarien überhaupt nicht möglich.
81
82
Kapitel 7
Zusammenfassung und Ausblick
Diese Diplomarbeit hat sich mit der Konstruktion und Entwicklung einer Bildschirmkarte
zum Zweck des Aufbaus eines datenbankbasierten Systems zur Analyse von Verkehrsszenarien beschäftigt. Dieses Kapitel fasst die Ergebnisse zusammen und gibt einen Ausblick auf
mögliche Erweiterungen des implementierten prototypischen Analyse-Systems VADImA.
Im Rahmen dieser Arbeit wurde das VADImA-System angefertigt, dass die geforderte Aufgabe hat eine datenbankgestützte Bildschirmkarte bereitzustellen, die unterschiedliche Verkehrsszenarien an Kreuzungen/Einmündungen intelligent analysiert. Dabei wird der dynamische Verkehrsablauf in Form von statischen Zuständen dargestellt. Das VADImA-System
besteht aus einem Anwenderprogramm und einer Datenbank. VADImA zeigt die grundsätzliche Machbarkeit und Brauchbarkeit der Zusammenarbeit von Kontroll- und Analysesichten
zur Steuerung eines Verkehrs zumindest an Kreuzungen und Einmündungen, wobei die Kontrollsichten die Überwachung globaler Integritätsbedingungen übernehmen und die Analysesichten komplexe Eigenschaften der Szenarien auswerten.
Der Beginn der Arbeit bot eine allgemeine Einführung in das Gebiet des Verkehrsmanagements, wobei hauptsächlich Datenbanktechniken zur Analyse von Verkehrsdaten aufgeführt
worden sind, welche aus flüchtigen und persistenten Daten stammen. Das darauf folgende
Kapitel stellte die informatischen Grundlagen, die für die Konzeption und Realisierung notwendig gewesen sind, vor. In Kapitel 3 wurden basierend auf der Arbeit von Eifer [Eife06]
nur die grundlegenden Informationen sowie die Verkehrsregeln der Straßenverkehrsordnung
aus dem Verkehrwesen untergebracht, die für diese Arbeit im Vordergrund standen. In Kapitel 4 wurde die Extended Entity-Relationship- bzw. relationale Modellierung der globalen
Sicht (Straßennetz) und der lokalen Sicht (Knotenpunkte inklusive Fahrzeuge) erarbeitet. Der
Netzknoten setzte sich anders als in [Eife06] aus Knotenzufahrt, -abfahrt und dem Kreuzungsbereich zusammen. Auf dieses Extended-Entity-Relationship-Schema aufbauend wurden abschließend in diesem Kapitel Vorfahrt-/Vorrangsszenarien sowie verkehrliche Konfliktsituationen analysiert und modelliert. Die Ergebnisse der Analyse sind als SQL-Sichten
formuliert, die dann zur Analyse von Verkehrsszenarien in VADImA integriert sind. Auch die
Zulässigkeit der Zustände der zugrundeliegenden Datenbank werden mittels SQL-(Kontroll-)
Sichten überwacht. In Kapitel 5 wurde die Architektur und Funktionalität von VADImA vorgestellt. VADImAs Architektur ist in drei Schichten (Repräsentations-, Semantische- und
83
Datenverwaltungsebene) aufgeteilt, eine 3-Schichten-Architektur. Um die Erweiterbarkeit und
Flexibilität von diesem System hoch zu halten, wurden bei der Realisierung wichtige Entwurfsmuster berücksichtigt, wurde gegen definierte Schnittstellen programmiert und für die
SQL-Anweisungen der Standard gewählt. In Kapitel 6 wurden Details auf Codeebene aus
dem realisierten System aufgeführt. Dabei wurde deutlich, selbst einfachste Aspekte der Implementierung bedürfen einer gründlichen Vorüberlegung um die Effizienz des Systems zu
erhöhen. Für die Darstellung des Straßennetzes und deren Bearbeitung hat sich nur das Dialogelement Canvas aus dem Paket java.awt.* bewährt. Canvas ist ein freidefinierbares
Dialogelement. Es bietet und stellt keine Funktionalitäten zu Verfügung. Der Programmierer
muss die Funktionalitäten selber implementieren. Für die Darstellung wurde ursprünglich die
Swing-Komponente JPanel und andere Komponenten erprobt. Leider erwiesen sich diese
problematisch. Beispielsweise konnte man das Kontextmenü, welches sich durch Anklicken
auf den Netzknoten öffnet nicht sehen, da das Kontextmenü unter dem eingesetzten JPanel
blieb. Auch die Beschriftungen von Netzknoten und anderen Objekten waren verschollen.
Die SQL-Sicht zur Erkennung von verkehrlichen Konfliktsituationen könnte effizienter implementiert werden. Denn sie führt jedes Mal, wenn Sie aufgerufen wird, eine neue Konfliktsituationserkennung aller in einem Netzknoten befindlichen Fahrzeuge durch. Also auch von
Fahrzeugen, die ihre Situation nicht geändert haben. Es müsste ein Mechanismus entwickelt
werden, der sich merkt, welche Fahrzeuge neu in die Kreuzung/Einmündung hinzugekommen
sind und die Konfliktsituationserkennung nur auf solche Fahrzeuge anwenden zu lassen.
Bei der Modellierung von Verkehrsszenarien in Kapitel 4 wurden bisher ausschließlich Kreuzungs- oder Einmündungsbereiche berücksichtigt. Leider bietet VADImA aber gegenwärtig –
zum Zeitpunkt der Ausarbeitung der vorliegenden Arbeit – noch nicht die Möglichkeit, Fahrzeuge im Inneren des Kreuzungsbereich auf verkehrliche Konfliktsituationen hin zu analysieren. Das liegt daran, dass in der Realisierungsphase der Fokus auf Verkehrsituationen gesetzt
war, bei denen sich Fahrzeuge auf Knotenzu- bzw. Knotenabfahrten befinden.
Zunehmend werden in der Bundesrepublik Deutschland Kreuzungen/Einmündungen durch
Kreisel (Kreisplatz) ersetzt. Damit wird beabsichtigt einen flüssigen Verkehrsablauf zu gewähren. Auch die Gefahr der Kollision wird dadurch verringert, denn mit hoher Geschwindigkeit ist es kaum möglich einen Bogen um den Kreisel – diese Kreisel sind in der Regel
ähnlich zu Gehwegen höher gebaut als eine Fahrbahn – zu fahren. Doch Vielerorts wird
mittlerweile der Kreisverkehr durch Kreisel gewährt, welche lediglich eine sehr geringe Höhe
haben und durch einen markierten Kreis dargestellt werden. An diesen Stellen würde eine
Überwachung der Zu- und Ausfahrten des Kreisplatzes Sinn machen, denn Fahrzeugführer
kämen auf die Idee derartige Kreisel zu ignorieren und als Folge einfach darüber fahren, was
unterbunden werden muss. Durch die Umwandlung von Kreuzungen/Einmündungen zu
Kreisplätzen entfällt auch die Steuerung durch Lichtsignalanlagen an diesen Orten – nur
wenn diese auch vorher lichtsignalgesteuert waren. Aus diesen Gründen wird es unumgänglich sein in künftigen Arbeiten zu diesem Thema, den Kreisverkehr zu modellieren und auf
mögliche Gefahrensituationen hin analysieren zu lassen.
Eine andere Erweiterung, die sich anknüpfen lässt, wäre die Sichtbarkeit von Fahrzeugen auf
globaler Sicht zuzulassen. Dazu zählt auch, den dynamischen Verkehrsablauf exakt zu protokollieren, insbesondere die exakte Position von Fahrzeugen als sich bewegende, mobile Objekte festzuhalten. Dies führt dann dazu, dass man zur Analyse von Verkehrsszenarien neben
deduktiven (SQL-Sichten), normativen (SQL-Assertions) auch aktive (SQL-Trigger) Regeln
integriert, die dann in Kombination zusammenarbeiten. Ist eine systematische Protokollierung innerhalb von VADImA gewährleistet, so ist auch eine mögliche automatische Wieder84
herstellung des Systems zu einem beliebigen Zeitpunkt nach einem Systemfehler – bzw. einem inkonsistenten Zustand – zu bewerkstelligen. VADImA ist grundsätzlich änderungsfreundlich und flexibel implementiert, deswegen wäre es auch möglich, einzelne Module in
andere Projekten zu verwenden.
Die Bildschirmkarte ist sehr abstrakt implementiert. Sie stellt das Straßennetz dar, welches
mit den Methoden der Graphimplementierung aus Informatik, d.h. Netzwerk, Knoten, Kanten
und bekannte Algorithmen umgesetzt wurde. Leider bietet die Bildschirmkarte in der gegenwärtigen Umsetzung nicht die gängigen Funktionalitäten wie beispielsweise ein Layerkonzept, Navigation und Legende. Bildschirmkarten werden in der Regel zur Visualisierung von
Geodaten eingesetzt, welche durch Messungen von Objekten auf der (Erd-)Oberfläche gewonnen werden. Es wäre keine schwere Aufgabe eine Koordinatentransformation durchzuführen, der Weltkoordinaten – also solche Geodaten – in Bildschirmkoordinaten und umgekehrt konvertiert, sondern der Aufwand liegt vielmehr in der Visualisierung der gemessenen
Objekte (Geoobjekte).
Ein weiteres sehr interessantes Einsatzgebiet und an Genauigkeit und Anspruch an korrekter
Datenanalyse genauso bedeutend wie Verkehrsmanagement wäre die Medizin, weil es dabei
um die Gesundheit und das Leben von Patienten geht. Datenströme, beispielsweise aus Herzrhythmus und/oder Blutdruck eines Kranken, die mittels spezieller Sensoren übermittelt werden, müssen kontinuierlich überwacht werden und gegebenenfalls bei Erreichen kritischer
Werten lebensrettende Maßnahmen ergriffen werden.
85
86
Literaturverzeichnis
[AISJ+77] Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.; Fiksdahl-King, I.; Angel, S.: A Pattern Language, New York, Oxford University Press, 1997
[BaFl00] Barner, Martin; Flohr, F.: Analysis, Berlin, New York, Walter de Gruyter, 2000
[BoKo01] Bollmann u. Koch (Hrsg.): Lexikon der Kartographie und Geomatik, Spektrum
Verlag, 2001
[Booß80] Booß, H.: Straßenverkehrs-Ordnung, Kommentar, 3.Auflage, Carl Heymanns Verlag KG, 1980
[Chen76] Chen, P.: The Entity-Relationship model – toward a unified view of data, ACM
Trans. Database Syst. 1 (1): 9-36, 1976
[CHKS03] Cammer, M.; Heinz, C.; Krämer, J.; Seeger, B.: Datenströme im Kontext des Verkehrsmanagements (Projektnummer SE 553/4-1), Universität Marburg, Institut für Mathematik und Informatik, 2003
[DiGa00] Dittrich, Klaus R.; Gatziu, Stella: Aktive Datenbanksysteme – Konzepte und Mechanismen, 2. Auflage, dpunkt-Verlag, 2000
[EcGo00] Echtle, K.; Goedicke, M.: Lehrbuch der Programmierung mit Java, 1.Auflage, Heidelberg, dpunkt-Verlag, 2000
[Eife06] Eifer, A.: Objektorientiert, regelbasierte Modellierung komplexer Szenarien im Straßenverkehr, Diplomarbeit, Universität Bonn, Institut für Informatik III, 2006
[Esse01] Esser, F.: Designmuster und Zertifizierungswissen, Galileo Press GmbH, 2001 2002
[FGSV00] Forschungsgesellschaft für Straßen- und Verkehrswesen: Begriffsbestimmungen,
Teil: Verkehrsplanung, Straßenentwurf und Straßenbetrieb, FGSV Verlag, Ausgabe 2000
[FGSV03] Forschungsgesellschaft für Straßen- und Verkehrswesen: Begriffsbestimmungen,
Teil: Straßenbautechnik, FGSV Verlag, Ausgabe 2003
87
[FoSc00] Fowler, Martin; Scott, Kendall: UML konzentriert – Eine strukturierte Einführung
in die Standard-Objektmodellierungssprache anwenden, 2.Auflage, Addison-Wesley, 2000
[GHJV95] Gamma, E.; Helm, R.; Jonson, R.; Vlissides, J.: Design Patterns – Elements of
Reusable Object-Oriented Software, Addison-Wesley, 1995
[HoCo99] Horstman, S. C.; Cornell G.: Core Java ™ 2 – Advanced Features, Prentice Hall
International PTR, 1999
[HoCo02] Horstman, S. C.; Cornell G.: Core Java ™ 2 – Volume I Fundamentals, Sun Microsystems Press, Prentice Hall International PTR, 2002
[JUni06] JUnit-Framework (2006), Webseite: www.junit.org
[KeEi01] Kemper, A.; Eickler, A.: Datenbanksysteme – Eine Einführung, 4. überarbeitete und
erweiterte Auflage, Oldenbourg-Verlag, 2001
[Knie03] Kniesel, G.: Folien zur Vorlesung Softwaretechnologie im SS 2003, Universität
Bonn, Institut für Informatik III, 2003
[KoMi98] Kowalsky, H. J.; Michler, G. O.: Lineare Algebra, 11. Auflage, Berlin, New York,
Walter de Gruyter, 1998
[Köhl01] Köhler, U. (Hrsg.): Verkehr, Straße, Linie, Luft, Ernst&Sohn Verlag, 2001
[Krüg00] Krüger, G.: Handbuch der Java-Programmierung, 4. Auflage, Addison-Wesley,
2004
[MaFr99] Marsch, J.; Fritze, J.: Erfolgreiche Datenbankanwendung mit SQL, 5. Auflage, Vieweg-Verlag, 1999
[Mant03] Manthey, R.: Folien zur Vorlesung Informationssysteme im WS 2002/03, Universität Bonn, Institut für Informatik III, 2003
[Mant04] Manthey, R.: Folien zur Vorlesung Deduktive Datenbanken im SS 2004, Universität Bonn, Institut für Informatik III, 2004
[Mart02] Martin, R. C.: UML for Java Programmers, Prentice Hall, 2002
[MySQ06] MySQL (2006) A GPL SQL database server, Website: www.mysql.com
[OaWo97] Oaks, S.; Wong, H.: Java Threads, O’Reilly & Associates, 1997
[Oest01] Oesterreich, B.: Objektorientierte Softwareentwicklung mit der Unified Modeling
Language, 5. Auflage, München, Wien, Oldenbourg, 2001
[Oest02] Oesterreich, B.: Die UML-Kurzreferenz für die Praxis, 2. überarbeitete Auflage,
München, Wien, Oldenbourg, 2002
88
[Rauh00] Rauh, O.: Objektorientierte Programmierung in Java, 2.Auflage, Heilbronn, Vieweg-Verlag, 2000
[SaSa03] Saake, G.; Sattler, K.-U.: Datenbanken & Java, dpunkt-Verlag, 2003
[Schä94] Schäfer, S: Verfahren zum objektorientierten Softwareentwurf im Überblick, Bonn,
New York, Addison-Wesley, 1994
[Schn97] Schnabel, W., Lohse, D: Grundlagen der Straßenverkehrstechnik und Straßenverkehrsplanung, Verlag für Bauwesen, 1997
[Schu96] Schurig, R.: Grundriss des Verkehrsrechts, Kirchbaum Verlag, 1996
[Schu04] Schurig, R.: Kommentar zur Straßenverkehrs-Ordnung, 11. Auflage, Kirschbaum
Verlag 2004
[Seeg04] Seeger, B.: Datenströme, Datenbank-Spektrum (Kurz erklärt S. 30-33), 2004,
Webseite: www.datenbank-spektrum.de/pdf/dbs-09-3pdf
[Stre05] Streit, U.: Skript zur Vorlesung Einführung in die Geoinformatik im WS 2005/06,
Universität Münster, Institut für Geoinformatik, 2005,
Website: http://ifgivor.uni-muenster.de/vorlesungen/Geoinformatik/index.html
[Stro99] Stroustrup, B.: Die c++-Programmiersprache, 3. aktualisierte und erweiterte Auflage,
Bonn, Addison-Wesley-Longman, 1998
[StVO04] Straßenverkehrsordnung (StVO) vom 16 November 1970 (Bundesgesetzblatt, Teil
I, S. 1565), zuletzt geändert mit Verordnung vom 22. Januar 2004 (Bundesgesetzblatt, Teil I,
S. 117)
[Sun06] SUN (2006) Java Development Kit (JDK) Version 1.4.2, Sun Microsystems Inc.,
Webseite: http://java.sun.com
[Ulle02] Ullenboom, C.: Java ist auch eine Insel, 3. Auflage, Prentice Hall, 2002
[Voss00] Vossen, G.: Datenmodell, Datenbanksprachen und Datenbankmanagementsysteme,
4. korrigierte und ergänzte Auflage, Oldenbourg-Verlag, 2000
[Wahr00] Wahrig, G.: Deutsches Wörterbuch, 7. Auflage, Bertelsmann Lexikon Verlag, 2000
[WFCH+99] White, S.; Fisher, M.; Cattell, R. G.; Hamilton, G.; Hapner, M.: JDBC ™ API
Tutorial and Reference – Universal Data Access for the Java ™ 2 Platform, 2. Auflage, Addison-Wesley, 1999
89