Entwurf und Implementierung eines datenbankgestützten Werkzeugs zum Monitoring simulierter Straßenverkehrsszenarien

Größe: px
Ab Seite anzeigen:

Download "Entwurf und Implementierung eines datenbankgestützten Werkzeugs zum Monitoring simulierter Straßenverkehrsszenarien"

Transkript

1 Friedrich-Wilhelms-Universität Bonn Institut für Informatik III Arbeitsgruppe Intelligente Datenbanken Diplomarbeit Entwurf und Implementierung eines datenbankgestützten Werkzeugs zum Monitoring simulierter Straßenverkehrsszenarien Sandra Loch und Youness Dehbi 19. Juni 2008 Betreuer: Prof. Dr. Rainer Manthey

2 2

3 Inhaltsverzeichnis 1 Einleitung 7 2 Grundlagen aus der Informatik Datenbanken Datenbanksysteme Datenbankentwurf Structured Query Language (SQL) SQL-Grundlagen Anfrageoptimierung Java Grundlegendes Threads JDBC Swing Extensible Markup Language (XML) Methoden der Softwaretechnologie Unified Modeling Language (UML) Design Patterns Grundlagen aus dem Verkehrswesen Begriffsbestimmungen Straßenverkehrsordnung Grundlagen der Simulation Simulationsmodelle Diskrete Ereignissimulation Multiagentensimulation Verkehrssimulationsmodelle Entwurf des Systems Anforderungserhebung Anforderungserhebung Simulator Anforderungserhebung Monitor Datenbankentwurf Konzeptueller Entwurf Logischer Entwurf

4 INHALTSVERZEICHNIS 6 Architektur und Funktionalität Gesamtarchitektur Simulator Architektur des Simulators Funktionalitäten des Simulators Strukturierung der statischen Komponenten Strukturierung der dynamischen Komponenten Monitor Funktionalitäten des Monitors Objektdesign für das GUI Architektur des Monitors Organisation der Monitoraktivitäten Synchronisation Ausgewählte Aspekte der Implementierung Ausgewählte Aspekte der Simulation Aufbau und Synchronisation der Karten Verwaltung der Routen Generierung und Fortbewegung der Fahrzeuge Beachtung der Verkehrsregeln Ausgewählte Aspekte des Monitorings Formulierung der Regelverstöße in SQL Verwaltung von Simulationsdaten und Regelverstößen Aktualisierung des GUIs auf Zellenebene Zusammenfassung und Ausblick 145 4

5 Übersicht über die Zuordnungen der Abschnitte zu den einzelnen Autoren: Sandra Loch: Datenbanksysteme Datenbankentwurf (Relationales Modell, Umsetzung ER- zu relationalem Schema) SQL-Grundlagen (Datenmanipulationssprache) Anfrageoptimierung Swing Unified Modeling Language (UML) 3 Grundlagen aus dem Verkehrswesen Anforderungserhebung Monitor Konzeptueller Entwurf 6.3 Monitor 7.2 Ausgewählte Aspekte des Monitorings Youness Dehbi: Datenbankentwurf (Entity-Relationship-Modell) SQL-Grundlagen (Datendefinitionssprache) Grundlegendes Threads JDBC 2.4 Extensible Markup Language (XML) Design Patterns 4 Grundlagen der Simulation Anforderungserhebung Simulator Logischer Entwurf 6.2 Simulator 7.1 Ausgewählte Aspekte der Simulation Die Unterkapitel und wurden zwar getrennt verfasst, stellen jedoch das Ergebnis eines gemeinsamen Entwurfs dar. Nicht hier aufgeführte Abschnitte wurden gemeinsam verfasst.

6

7 Kapitel 1 Einleitung Im Rahmen dieser Diplomarbeit wurde einerseits ein datenbankgestützter Simulator entworfen und implementiert, der Verkehrsszenarien im Straßenverkehr erzeugt und regelgerechtes sowie regelwidriges Fahrverhalten simuliert. Zum anderen wurde ein datenbankgestütztes Monitoring-System realisiert, das die vom Simulator erzeugten Daten online auswertet und ausgewählte Verstöße gegen die Straßenverkehrsordnung (wie z.b. Vorfahrtmissachtung) erkennt und meldet. Das Ergebnis stellt ein lose gekoppeltes System aus Simulator und Monitor dar, das auf den Namen SiMo getauft wurde. Dieses System verfügt über eine in Java realisierte grafische Benutzeroberfläche (GUI). Die vom Simulator erzeugten Daten werden dem Monitor über eine MS Access Datenbank zur Verfügung gestellt. Simulationen können ein mächtiges Hilfsmittel sein, um mit Systemen aus der realen Welt zu experimentieren. So lässt sich ein in der Entwicklung befindliches System mithilfe von Simulation erproben und untersuchen, bevor es in der Realität tatsächlich zum Einsatz kommt. Durch Simulation können verschiedene Parameter des zu entwickelnden Systems manipuliert werden. Durch die Auswertung des daraus resultierenden Verhaltens lassen sich schließlich Verbesserungsmöglichkeiten ableiten. Auch nach Einführung der Systeme im realen Einsatzgebiet kann Simulation entscheidende Vorteile mit sich bringen. Das Experimentieren mit solchen Systemen im laufenden Betrieb ist meist kostspielig und zeitaufwändig. In vielen Fällen ist es sogar aus ethischen Gründen bzw. aufgrund von potentiellen Gefahren gar nicht möglich, Versuche in der realen Welt durchführen zu lassen. Auch im Bereich des Verkehrs finden Simulationen Einsatz. Es gibt zahlreiche Anwendungsfelder für Verkehrssimulatoren. Mit deren Hilfe können u.a. Verkehrsprognosen erstellt und zur Vermeidung von Staus verwendet werden. Das Verkehrsinformationssystem autobahn.nrw erstellt z.b. durch Simulation von Verkehrsabläufen Prognosen für die Stauentwicklung auf Autobahnen Nordrhein-Westfalens [Min]. 7

8 1 EINLEITUNG Weiterhin bietet eine Verkehrssimulation die Möglichkeit, für die Verkehrsplanung die Auswirkungen der den Verkehr beeinflussenden Faktoren zu studieren. Somit lässt sich beispielsweise ein Baustellenmanagement oder die Planung für den Einsatz von Ampeln unterstützen. Das Bonner Verkehrsmanagementsystem City Traffic ist ein Vertreter eines erfolgreich für Planung und Prognose eingesetzten Simulationssystems [Fra]. Mit zunehmendem Verkehr nimmt die Gewährleistung der Verkehrssicherheit einen immer höheren Stellenwert ein. Daher werden bereits intensiv neue Technologien genutzt, um den Verkehr durch automatisierte Systeme zu kontrollieren. Der Einsatz dieser Technologien reicht von der Geschwindigkeitskontrolle durch Radar über Stauvermeidung durch Verkehrsprognosen bis hin zu Fahrerassistenzsystemen. Eine Erhöhung der Verkehrssicherheit lässt sich durch verschiedene Maßnahmen erzielen. Zum einen ist es möglich, gefährdete Verkehrsbereiche automatisch zu beobachten, wodurch häufig wiederkehrende Verkehrsregelverstöße erkannt und durch Umorganisation baulicher oder verkehrstechnischer Einrichtungen vermieden werden können. Zum anderen kann das Verhalten der Verkehrsteilnehmer z.b. durch eine Ahndung von Ordnungswidrigkeiten positiv beeinflusst werden. Wünschenswert ist daher eine automatisierte Überwachung des Verkehrgeschehens, wobei durch gezielte Verkehrsanalysen Erkenntnisse über Regelverstöße gewonnen werden können. Eine solche Überwachung ist mithilfe von Monitoring-Systemen realisierbar. Monitoring-Systeme zur Überwachung und Meldung von Ereignissen sind mittlerweile ein wichtiges Instrument zur Unterstützung der menschlichen Wahrnehmung. Vorgänge oder Prozesse können mithilfe von analogen Sensoren aufgenommen und in digitale Messwerte umgewandelt werden. Die daraus entstehenden Datenströme stehen schließlich für eine Überwachung von Ereignissen zur Verfügung. In der Analyse solcher großen Datenmengen besteht die Hauptaufgabe eines Monitoring-Systems. Dabei werden relevante Informationen meist in Echtzeit extrahiert und dem Benutzer besondere Vorkommnisse gemeldet. Der Einsatz solcher Ereignisüberwachungssysteme umfasst beispielsweise die Überwachung von Börsenkursen, die Verfolgung von Taxis oder Frühwarnsysteme für Naturkatastrophen. Ein Schwerpunkt dieser Arbeit liegt im datenbankgestützten Monitoring. Datenbanksysteme dienen hierbei nicht nur zur Speicherung von Daten, sondern auch der Überwachung bestimmter Ereignisse. Bisher haben konventionelle Datenbanksysteme in diesem Bereich keine bedeutende Rolle gespielt, da sie bei der Bearbeitung von Datenströmen ab einer gewissen Frequenz an ihre Grenzen stoßen. Deswegen gelten datenbankgestützte Ereignisüberwachungssysteme als junges Forschungsgebiet. Dabei möchte man das Potential relationaler Datenbanken ausschöpfen, um ihre tatsächlichen Grenzen hinsichtlich Überwachungsaufgaben zu erkennen. Das Hauptaugenmerk der gesamten Arbeit liegt auf dem Einsatz eines Datenbankmanagementsystems zur Analyse von Datenströmen. Klassischerweise verändern sich die Daten relativ selten, während die Anfragen von stets wechselnder Natur sind. Im Gegensatz dazu handelt es sich bei Ereignisüberwachungssystemen um gleichblei- 8

9 bende Abfragen, die auf einer sich stets ändernden Datenmenge ausgewertet werden. Solche sogenannten continuous queries überprüfen die Daten auf besondere Vorkommnisse. Die hier zugrunde liegende Arbeitshypothese liegt darin, dass sich die deskriptive Natur der Datenbanksprache SQL besonders für Analyseaufgaben auf großen Datenmengen eignet. Daher lassen sich deskriptiv spezielle Analysekriterien durch den Datenbankprogrammierer in SQL-Anfragen angemessen spezifizieren. Darüber hinaus verfügen Datenbankmanagementsysteme über generische Methoden zur Organisation von komplexen Auswertungen über großen Datenmengen. Je nach Datenbeschaffenheit werden die Anfragen DBMS-intern durch einen query optimizer optimiert. Eine Analyse der Datenströme innerhalb des DBMS mittels SQL-Anfragen erspart somit die Implementierung externer Analysespezialsoftware. Aus diesen Gründen werden sowohl die Regelverstöße für den Monitor als auch die Verkehrsregeln für den Simulator in SQL formuliert. Der für diese Arbeit realisierte datenbankgestützte Monitor erfordert für die Überwachung des Straßenverkehrs die Erfassung interpretierbarer Daten. Bereits heutzutage produziert die Automobilindustrie Fahrzeuge, die mit Sensoren und Sendern ausgestattet sind. Solche Fahrzeuge können Informationen über sich und ihre Umgebung liefern, was eine vielversprechende Grundlage für eine benötigte Datenerfassung darstellt. Auch ohne fahrzeugseitige Signale ist solch eine Erfassung denkbar, indem sich beispielsweise die Daten durch Induktionsschleifen aufzeichnen ließen. Da momentan realistische Daten zu Forschungszwecken nur schwierig zugänglich sind, müssen künstlich Datenströme aus Verkehrsszenarien erstellt werden. Aus diesem Grund ersetzt der Verkehrssimulator des SiMo -Systems die in späteren Realisierungen dieses Konzepts von Sensoren zu erwartenden Daten. Außerdem bietet eine Verkehrssimulation die Möglichkeit, beliebige Verkehrssituationen zu generieren, ohne dass schwerwiegende Folgen zu erwarten sind. Für den Testbetrieb des Monitors ist es nicht denkbar, in der Realität absichtlich verkehrswidriges Fahrverhalten zu verursachen. Ein bloßes Beobachten des realen Verkehrsgeschehens ist ebenfalls nicht in ausreichendem Maß realisierbar, da Verkehrssünder eher die Ausnahme als die Regel darstellen. Die Simulation orientiert sich in dieser Arbeit an der diskreten Ereignissimulation sowie der Multiagentensimulation. Für die detaillierte Beschreibung des Verkehrs liegt der Simulation ein mikroskopisches Modell zugrunde. Auf der Grundlage zellularer Automaten wird das Simulationsgebiet zur Bewältigung der Komplexität diskretisiert. Simuliert werden neben den Fahrzeugen auch die Steuerung der Lichtsignalanlagen. Als Simulationsraum wurde exemplarisch ein Ausschnitt des Stadtgebietes Bonn- Nord ausgewählt. Er weist alle Eigenschaften auf, die für diese Arbeit von Interesse sind, wie beispielsweise Mehrspurigkeit mancher Straßen oder vorfahrtregelnde Verkehrszeichen. Simuliert wird der Verkehr zwar im gesamten Straßennetz dieses Ausschnittes, für den Monitor sollen jedoch nur die innerhalb von Kreuzungen erzeugten Daten zugänglich sein. Begründet wird dies durch drei Argumente. Zum einen 9

10 1 EINLEITUNG gehören Kreuzungen zu den bedeutsamsten Gefahrenpunkten im Straßenverkehr. So zählen laut Verkehrsunfallstatistik 2007 der Polizei NRW Fehler beim Abbiegen und die Missachtung der Vorfahrt oder des Vorrangs zu den häufigsten Unfallursachen [Pol]. Ferner ist der Schutz der Privatsphäre ein oft diskutiertes Thema. Erst vor kurzem wurde ein Gesetz vom Bundesverfassungsgericht aufgehoben, das der Polizei die Nummernschildererfassung durch Videokameras zu Strafverfolgungszwecken ermöglichte. Es wurde als Verstoß gegen das Grundrecht auf informationelle Selbstbestimmung betrachtet, da die Gesetzesformulierungen die Erstellung von Bewegungsprofilen nicht ausschlossen. Aus diesem Grund soll auch in dieser Arbeit die Datenerfassung auf einzelne Kreuzungsbereiche beschränkt sein. Letztlich ist die ausschließliche Überwachung von Kreuzungen von Vorteil, um eine gute Performanz zu erzielen. Diese Einschränkung vermindert den Aufwand für die Interpretation von großen Datenmengen. Die Überwachung der Kreuzungen in Echtzeit erfordert eine Synchronisation beider Teilsysteme. Das Monitoring soll ohne Verzögerung gegenüber dem Simulationsprozess erfolgen. Darüber hinaus müssen fortlaufend die zugehörigen Benutzeroberflächen aktualisiert werden. Der wesentliche Informationsaustausch zwischen den zwei Teilsystemen Simulator und Monitor erfolgt über eine Datenbank. Dennoch soll die Möglichkeit bestehen, völlig unabhängig voneinander zu arbeiten. Der Simulator kann als eigenständiges Werkzeug angesehen werden. Ein Einsatz für die Verkehrsplanung ausgewählter Stadtgebiete ist somit möglich. Ebenso ist der Monitor nicht zwingend auf die externe Datenlieferung des Simulators angewiesen. Im realen Betrieb werden reale Datenströme in einer Datenbank abgelegt, worauf der Monitor zugreifen kann. Diese Unabhängigkeit spiegelt sich auch auf der grafischen Benutzeroberfläche wider: Simulator und Monitor benutzen zwar ein gemeinsames Hauptfenster, dennoch wird dies in zwei Anzeigebereiche unterteilt. So zeigt der Simulator das gesamte Simulationsgebiet bzw. einzelne Ausschnitte an, während der Monitor auf die Darstellung einzelner Kreuzungen beschränkt bleibt. Zu Beginn dieser Arbeit sollen in Kapitel 2 die Grundlagen aus der Informatik erläutert werden, die für diese Arbeit von Bedeutung sind. Kapitel 3 geht auf die Begrifflichkeiten aus dem Verkehrswesen sowie der dem Monitoring zugrunde liegenden Straßenverkehrsordnung ein. Anschließend bietet Kapitel 4 eine Einführung in die Thematik der Simulation, insbesondere die diskrete Ereignissimulation und die Multiagentensimulation. Kapitel 5 diskutiert den Entwurf des Systems SiMo. Die Architektur und Funktionaliät dieses Systems werden in Kapitel 6 vorgestellt. Kapitel 7 geht auf ausgewählte Aspekte der Implementierung ein. Schließlich fasst Kapitel 8 die hier vorliegende Arbeit zusammen und gibt einen Ausblick auf zukünftige Arbeiten im Rahmen der dies betreffenden Thematik. 10

11 Kapitel 2 Grundlagen aus der Informatik In diesem Kapitel werden die Thematiken aus der Informatik eingeführt, die im Rahmen dieser Arbeit verwendet wurden. Unterkapitel 2.1 behandelt die Grundlagen aus dem Bereich der Datenbanken, während Kapitel 2.2 eine Einführung in die Datenbanksprache SQL gibt. In Unterkapitel 2.3 sollen die grundlegenden in dieser Arbeit angewandten Konzepte der Programmiersprache Java vermittelt werden. Des Weiteren geht Unterkapitel 2.4 auf die Extensible Markup Language ein. Zuletzt werden in Unterkapitel 2.5 die Methoden der Softwaretechnologie erläutert, welche als Orientierung in dieser Arbeit gedient haben. 2.1 Datenbanken Zusammen mit der Menge an Informationen steigt gleichermaßen der Bedarf an effizienter Verwaltung dieser Daten. Somit entwickelte sich vor rund 40 Jahren das Gebiet der Datenbanksysteme als Teilgebiet der Informatik. Heutezutage gibt es kaum einen Bereich, in dem Datenbanksysteme keinen Einsatz finden. Der klassische Verwendungszweck liegt in der organisierten und strukturierten Speicherung von Daten. Mittlerweile ergeben sich immer wieder neue Anwendungsfelder wie z.b. die Analyse und Extraktion großer Datenmengen zur Unterstützung von Entscheidungsprozessen oder zur Verwaltung von geographischen Informationen. Dieses Unterkapitel soll einen Überblick über Datenbanksysteme und speziell das in dieser Arbeit eingesetzte DBMS MS Access geben. Weiterhin werden die Techniken zum Entwurf einer Datenbank vorgestellt und erläutert, welcher zur Entwicklung eines datenbankgestützten Systems erforderlich ist Datenbanksysteme Ein Datenbanksystem (DBS) setzt sich aus einem Datenbankmanagementsystem und mehreren Datenbanken zusammen. Eine Datenbank enthält anwendungsspezifische Informationen, welche einen Ausschnitt der realen Welt beschreiben. Ein Datenbankmanagementsystem (DBMS) ist eine Software zur Verwaltung der in den Datenbanken gespeicherten Daten. Es bietet dafür anwendungsunabhängige Dienste an, wie Schemaverwaltung, Anfragebearbeitung, Transaktionsverwaltung 11

12 2 GRUNDLAGEN AUS DER INFORMATIK und Speicherverwaltung. Neben der Speicherverwaltung gehört die effiziente Bearbeitung von Anfragen zu den wichtigsten Aufgaben eines DBMS. Jede Anfrage wird vor der Auswertung syntaktisch analysiert und mithilfe von DBMS-spezifischen Strategien und Heuristiken logisch und physisch verbessert. Einfluss auf den Auswertungsplan haben beispielsweise die verwendeten Operatoren oder die Größe der Tabelle. Abbildung 2.1 veranschaulicht diese Komposition aus Datenbanksystem und Datenbankmanagementsystem. Der Einsatz eines Datenbanksystems ermöglicht eine zentrale Speicherung der Daten. Verschiedene Anwendungsprogramme oder aber die Endbenutzer direkt können auf dieselbe Datenbasis zugreifen. Die Organisation der Daten bleibt für die Anwender transparent, sie bekommen lediglich eine anwendungspezifische Sicht auf die Daten. Im Gegensatz zu Dateisystemen lassen sich dadurch unter anderem Redundanz und Inkonsistenz vermeiden. Datenbanksysteme können durch das unterstützte Datenmodell klassifiziert werden, welches die Struktur und die Funktionaliäten einer Datenbank festlegt. Am weitesten verbreitet ist das relationale Datenmodell, wobei Objekte auf Tupel einer Relation abgebildet werden (siehe Abschnitt 2.1.2). Anwendung 1 Benutzer Anwendung 2 DBS = DBMS + n*db DBMS Datenbankmanagementsystem zur Verwaltung der Daten DB Datenbanken zur Speicherung von Informationen Abbildung 2.1: Komponenten eines DBS Ein Vertreter eines kommerziellen relationalen Datenbankmanagementsystems ist MS Access, welches im Rahmen dieser Arbeit verwendet wurde. Es ist insbesondere für kleine bis mittlere Datenbank-Anwendungen ohne Mehrbenutzerbetrieb gut geeignet. Ein Datenbankadministrator ist nicht erforderlich, sodass es leicht auf einem Rechner einsetzbar ist. Zentrale Komponente von MS Access ist die Microsoft Jet Engine. Sie verwaltet die Daten und ist unter anderem für die Datenvalidierung und die Optimierung von Anfragen zuständig. Ein heterogener Zugriff auf die Daten ist durch ODBC 12

13 2.1 Datenbanken möglich. MS Access bietet als Schnittstelle eine grafische Benutzeroberfläche und unterstützt damit visuell Definition und Manipulation der Daten. Eine SQL-Ansicht kann automatisch generierte Anfragen in SQL anzeigen und ermöglicht dem Datenbankentwickler darüber hinaus die Formulierung beliebiger von Access unterstützter Anfragen Datenbankentwurf Der Entwurf ist eine wichtige Phase der Datenbankentwicklung. Er stellt einen Übergang zwischen der Anforderungsanalyse und der Nutzung der Datenbank dar. Der Entwurf zeichnet sich durch drei Phasen aus: konzeptueller, logischer und physischer Entwurf (siehe Abbildung 2.2). Reale Welt Anforderungsanalyse Pflichtenheft Konzeptueller Entwurf Entity-Relationship-Schema Logischer Entwurf Relationales Schema Physischer Entwurf Physische Datenbankstruktur Abbildung 2.2: Phasen des Datenbankentwurfs Der konzeptuelle Entwurf ist die Brücke zwischen der Anforderungsanalyse und dem logischen Entwurf. In dieser Phase wird aus der realen Welt in die konzeptuelle Ebene auf dem Papier übergegangen. Mithilfe eines konzeptuellen Modells wird ein sogenanntes konzeptuelles Schema entworfen. Dabei werden die Benutzeranforderungen durch eine formale Repräsentation beschrieben. Das klassische konzeptuelle Modell ist das Entity-Relationship-Modell. 13

14 2 GRUNDLAGEN AUS DER INFORMATIK Dem konzeptuellen Entwurf folgt die Umsetzung auf der logischen Ebene. Im logischen Entwurf wird der zuvor durch ein konzeptuelles Schema abstrahierte Gegenstandsbereich auf ein logisches Datenmodell abgebildet. Das daraus resultierende logische Datenbankschema ist abhängig vom zugrunde liegenden DBMS. Die meisten kommerziellen Datenbankmanagementsysteme verwenden hierbei das relationale Datenmodell. Das Ziel des physischen Entwurfs liegt darin, die Leistungsfähigkeit zu steigern, ohne dabei Veränderungen an der logischen Datenbankstruktur vorzunehmen. Die physische Datenbankorganisation umfasst zur Beschleunigung der Datenbankzugriffe u.a. die Unterstützung durch Indexstrukturen sowie die Partitionierung bzw. Gruppierung von Daten. Im Folgenden werden der konzeptuelle sowie der logische Entwurf anhand deren Umsetzungsmethoden erläutert. Auf den physischen Entwurf soll an dieser Stelle nicht eingegangen werden, weil die physische Datenbankorganisation hauptsächlich vom DBMS übernommen wird. Entity-Relationship-Modell Das Entity-Relationship-Modell (kurz ER-Modell) ist eine grafische Notation zur konzeptuellen Datenmodellierung. Es stellt das Gegenstück zur Unified Modeling Language (UML) in der Softwareentwicklung dar, welche in Unterkapitel vorgestellt wird. Das ER-Modell zeichnet sich durch eine Menge von Konzepten und Begriffen aus. Die sogenannten Entities sowie die Relationships zwischen den Entities bilden die Grundbausteine des ER-Modells. An dieser Stelle werden die Modellierungsstrukturen erläutert, die dieses Modell anbietet. Entities stellen die Basisobjekte des ER-Modells dar. Sie sind wohlunterscheidbare physisch oder gedanklich existierende Konzepte der zu modellierenden Welt [KE06]. In die erste Kategorie, die in dieser Definition erwähnt, fallen tastbare Objekte wie Fahrzeuge oder Ampeln. Beispiele für die zweite Kategorie können Institutionen wie Universitäten oder Firmen sein. Die Eigenschaften zur Identifizierung eines Entitys werden als Attribute bezeichnet. Ein Attribut, das ein Entity eindeutig identifiziert, wird Schlüsselattribut genannt. Die Attribute eines ausgewählten Entitys haben Werte, wobei die Werte aller Attribute eines Entitys dieses Entity ausmachen. Die Zusammenfassung von Entities, die mindestens die gleiche Attributmenge besitzen, wird als Entity-Typ bezeichnet. Entity-Typen, deren Existenz stets von einem anderen Entity-Typ abhängt, heißen schwache Entity-Typen. Im ER-Modell werden die Entity-Typen als Rechtecke dargestellt, schwache Entity- Typen sind durch ein doppelt umrandetes Rechteck gekenntzeichnet. Attribute werden durch Ovale versinnbildlicht, Schlüsselattribute zusätzlich unterstrichen. Schlüsselattribute von schwachen Entity-Typen werden mit gestrichelter Linie 14

15 2.1 Datenbanken Gebäude GebNr Raumanzahl Abbildung 2.3: Entity-Typ Gebäude mit zwei Attributen unterstrichen. Abbildung 2.3 zeigt den Entity-Typ Gebäude mit seinen zwei Attributen GebNr und Raumanzahl. Die Gebäudenummer GebNr dient der Identifizierung eines Gebäudes und wird als Schlüsselattribut ausgezeichnet. Zwischen den Entities bestehen Beziehungen, sogenannte Relationships, die ihren Zusammenhang widerspiegeln. Diese Beziehungen werden im ER-Modell nicht als Attribute dargestellt, ihre Charakterisierung erfolgt durch ihre eigenen Attributwerte und die Werte der Schlüsselattribute der beteiligten Entities. Analog zu Entities werden Relationships, die mindestens dieselbe Attributstruktur sowie Anzahl und Typ der Entity-Typen besitzen, zu Relationship-Typen zusammengefasst. Relationship-Typen werden im ER-Modell durch eine Raute repräsentiert. Ist an dem Relationship-Typ ein schwacher Entity-Typ beteiligt, wird die Raute doppelt umrandet. GebNr Raumanzahl Gebäude 1 N liegt_in Raum RaumNr Etage Abbildung 2.4: Relationship-Typ mit schwachem Entity-Typ Ein Entity-Typ kann an mehreren Relationship-Typen teilnehmen. Relationship- Typen mit genau zwei beteiligten Entity-Typen werden als binär bezeichnet. Ternäre Relationship-Typen sind solche, die durch drei teilnehmende Entity-Typen zustande kommen. Die Anzahl der Teilnehmer am Relationship-Typ nennt man Grad des Relationship-Typs. Abbildung 2.4 stellt einen binären Relationship-Typ zwischen den Entity-Typen Gebäude und Raum dar. Da die Existenz des Raums von der Existenz des Gebäudes abhängt, ist der Entity-Typ Raum als schwacher Entity-Typ beteiligt. 15

16 2 GRUNDLAGEN AUS DER INFORMATIK Jedem an einer Relationship-Typ beteiligten Entity-Typ wird eine Rolle zugeteilt, die die Bedeutung des Relationship-Typs genauer erklärt. Sie vermeidet auch jede Ambiguität, die durch eine Mehrfachbeteiligung desselben Entity-Typs am Relationship-Typ entsteht. Die Rolle muss nicht explizit angegeben werden, sofern keine Mehrdeutigkeit vorliegt. Meistens ist es wichtig, bei binären Beziehungen auszudrücken, mit wie vielen Instanzen jedes beteiligte Entity sich an der Relationship beteiligen kann. Dies wird im ER-Modell mithilfe von Kardinalitätsverhältnissen, auch Funktionalitäten genannt, spezifiziert. Es gibt vier mögliche Kardinalitätsverhältnisse: 1:1, 1:N, N:1 und N:M. Bei einer 1:1-Relationship sind die Beziehungsteilnehmer mit höchstens einem Entity an der Relationship beteiligt. Die anderen Funktionalitäten können analog definiert werden. Bei der N:M-Relationship liegen keine Einschränkungen zugrunde. Abbildung 2.4 veranschaulicht eine 1:N-Relationship. In diesem Fall wird ein Raum genau einem Gebäude zugeordnet, während in einem Gebäude N Räume liegen. Die Entscheidungen während der konzeptuellen Modellierung sind nicht immer offensichtlich. Entschieden werden muss, ob Konzepte der zu modellierenden Welt durch Entity-Typen oder Attribute repräsentiert werden sollen. Heuristisch sollten Konzepte in zwei Fällen auf Entity-Typen abgebildet werden. Einerseits soll der Entity-Typ nicht nur die Bezeichnung eines Konzeptes darstellen und neben dem Schlüsselattribut ein weiteres Attribut besitzen. Auf der anderen Seite ist die Abbildung auf Entity-Typen gerechtfertigt, sobald sie mit mehr als einer Instanz an einer Relationship teilnimmt. Fahrzeug is-a Fahrrad part-of part-of Rahmen Räder Abbildung 2.5: Generalisierung und Aggregation Die Strukturierung von gleichartigen Entity-Typen und ihre Zuordnung zu einem gemeinsamen Obertyp nennt man Generalisierung. Dieser besondere Zusammenhang wird im konzeptuellen Entwurf mit einer is-a-relationship modelliert, welche mit einem Sechseck in der ER-Notation vertreten ist. Ein weiteres Modellierungskon- 16

17 2.1 Datenbanken zept wird durch die Aggregation ermöglicht, die eine andere Art der Zusammenfassung von Entity-Typen zu einem Ganzen modelliert. Im Gegensatz zur Generalisierung werden bei der Aggregation unterschiedliche Entity-Typen, die insgesamt einen komplexen Entity-Typ bilden, strukturiert. Diese Beziehung wird als partof -Beziehung bezeichnet. Diese zwei besonderen Modellierungskonzepte werden in Abbildung 2.5 dargestellt. Der Obertyp Fahrzeug wird durch den Untertyp Fahrrad spezialisiert. Dieser wiederum wird durch die Gesamtheit der beiden Entity-Typen Rahmen und Räder gebildet. Relationales Modell Wurde die reale Welt nun mithilfe eines Entity-Relationship-Modells auf einer konzeptuellen Ebene modelliert, kann die Umsetzung des konzeptuellen Schemas in ein logisches beginnen. Als Standardmodell hierfür hat sich das relationale Datenmodell durchgesetzt, welches auf Relationen, Integritätsbedingungen und Schemata basiert. Formal gesehen ist eine n-stellige Relation R eine Teilmenge eines Kreuzproduktes von n Wertebereichen W 1, W 2,..., W n : R W 1 W 2... W n Die Relation R besteht aus Tupeln T 1, T 2,..., T m, wobei m die Kardinalität der Relation festlegt. Relationen werden oft als Tabellen angesehen, da ihre aktuellen Instanzen tabellarisch darstellbar sind: R: A 1 A 2 A 3 x 1 x 2 x 3 wobei x i, y i W i y 1 y 2 y 3 Die Spalten einer Tabelle werden als Attribute oder Felder A 1, A 2,..., A n bezeichnet, welche über ihren Wertebereichen W 1, W 2,..., W n definiert sind. Die Tupel einer Relation sind mit den Zeilen einer Tabelle gleichzusetzen. Sie entsprechen den Datenobjekten und werden mengenorientiert bearbeitet. Umsetzung des ER-Schemas in das relationale Schema Ein relationales Schema kann schließlich aus dem konzeptuellen Entity-Relationship- Schema entwickelt werden. Wie bereits zuvor beschrieben besteht das ER-Schema aus Entity-Typen und Relationship-Typen, welche nun beide in Relationen transformiert werden müssen. Dafür sind verschiedene Vorgehensweisen bekannt, welche im Folgenden erläutert werden sollen. Zunächst wird jeder Entity-Typ auf eine Relation abgebildet, d.h. der Entity-Typ wird zum Tabellennamen, die Attribute zu Spaltennamen. Schlüsselattribute können mit Primärschlüsseln gleichgesetzt werden. Ein Relationship-Typ ist ganz ähnlich umsetzbar. Je nach Kardinaliät des Relationsship-Typs gibt es jedoch verschiedene Repräsentationsmöglichkeiten. N:M-Beziehungen werden mit ihren beteiligten 17

18 2 GRUNDLAGEN AUS DER INFORMATIK Attributen ebenso wie die Entity-Typen auf eine eigene Tabelle abgebildet. Die zugehörigen Entity-Typen sind dann mithilfe ihrer Schlüsselattribute als Fremdschlüssel in die Relation einzubinden. Für die speziellen Funktionalitäten 1:N, N:1 und 1:1, bei denen mindestens eine Seite nur einmal vorkommen darf, ist eine zusätzliche Tabelle für den Relationship- Typ nicht zwingend erforderlich. Die Attribute des Relationship-Typs können ohne Informationsverlust in die Tabelle eingebettet werden, deren beteiligter Entity- Typ mit N markiert ist. Jedoch müssen nicht alle Typen diese Beziehung eingehen. Dies kann demnach bewirken, dass die Attribute des Relationship-Typs unter Umständen sehr viele NULL-Werte enthalten. Aufgrund des problematischen Umgangs mit NULL-Werten ist daher eine Realisierung zu wählen, die möglichst keine unnötigen NULL-Werte produziert. Eine Aggregation wird ebenso transformiert wie gewöhnliche Beziehungen. Für die Generalisierung gibt es mehrere Umsetzungsmöglichkeiten, deren Vorund Nachteile abzuwägen sind. 1. Eine Generalisierung lässt sich relational realisieren, indem sowohl der Obertyp als auch der Untertyp wie bereits beschrieben auf eine eigene Tabelle abgebildet werden. Der Untertyp enthält hierbei zudem zusätzlich zu seinen spezialisierten auch alle vererbten Attribute. Der Vorteil liegt in der schnellen Zugriffszeit, da keine Joins erforderlich sind. Nachteilig ist jedoch, dass die Daten redundant gespeichert werden und zudem der Speicherplatzbedarf steigt. Um die Daten nach Änderungen weiterhin konsistent zu halten, sind referentielle Integritätsbedingungen mit Löschweitergabe sowie die Propagierung von Einfügungen und Änderungen notwendig. 2. Eine weitere Möglichkeit besteht darin, den Obertyp wie beim ersten Ansatz in eine eigene Relation zu transformieren. Die Untertypen erhalten hingegen nur ihre eigenen Attribute sowie den gemeinsamen Schlüssel. Durch einen Join über dem Schlüsselattribut kann später die komplette Information über den Untertyp hergeleitet werden. Dies macht zwar den Zugriff auf den Untertyp langsamer, erspart aber abgesehen vom Primärschlüssel eine redundante Speicherung und stellt die Konsistenz der Datensätze sicher. Dennoch sind auch bei dieser Umsetzung für Einfüge- und Lösch-Operationen referentielle Integritätsbedingungen erforderlich, da sich die Tupel über mehr als eine Tabelle verteilen. 3. Im Gegensatz dazu kann letztlich die Relation für den Obertyp auf Tupel beschränkt sein, die keinem der Untertypen zuzuordnen sind. Stattdessen besitzen die Untertypen sowohl die vererbten als auch die eigenen Attribute, sodass alle anderen Tupel nur in den Relationen der Untertypen vorzufinden sind. Ein Obertyp ist nun über eine Vereinigung (UNION) seiner lokalen Repräsentation mit allen Untertypen und die Projektion auf die vererbten Attribute herleitbar. Werden die Daten des Obertyps häufig benötigt, kann sich der verlangsamte Zugriff nachteilig auswirken. Vorteilhaft ist jedoch, dass es 18

19 2.2 Structured Query Language (SQL) keinerlei Redundanz gibt und somit Anpassungen im Falle von Änderungen entfallen. Die Auswahl für die eine oder andere Realisierung eines ER-Modells ist abhängig vom späteren Einsatz der Datenbank, speziell vom Speicherplatzbedarf, der Zugriffszeit bei Anfragen und den Kosten für das konsistenzerhaltende Ändern von Daten. Im Allgemeinen ist darauf zu achten, dass eine relationale Umsetzung keine unerwünschten Anomalien hervorruft. Diese entstehen meist durch Redundanzen, wenn Teile der Tupel mehr als einmal in den Tabellen vertreten sind und eine Konsistenzerhaltung beim Einfügen, Löschen oder Ändern nicht sichergestellt werden kann. Abhilfe schafft hier eine Normalisierung der Tabellen, was bedeutet, dass redundant besetzte Felder in eine eigene Tabelle ausgelagert und stattdessen durch ihren Primärschlüssel in der Ausgangstabelle referenziert werden. 2.2 Structured Query Language (SQL) Die Structured Query Language (SQL) ist die am weitesten verbreiteste relationale Datenbanksprache, welche in allen gängigen Datenbankmanagementsystemen Einsatz findet. Grundlagen dieser Sprache werden in Abschnitt behandelt. Abschnitt geht auf die Optimierungsmöglichkeiten von Anfragen und effizienter physischer Datenbankorganisation ein SQL-Grundlagen Bereits 1986 wurde SQL als relationale Datenbanksprache standardisiert. Seitdem sind verschiedene Überarbeitungen und Erweiterungen veröffentlicht worden. Die SQL-Syntax kommerzieller Datenbanksysteme richtet sich nach diesem Standard, dennoch sind vereinzelt DBMS-spezifische Abweichungen vorzufinden. Der im Folgenden erläuterte SQL-Standard setzt sich aus zwei Teilsprachen zusammen: Datendefinitionsprache (DDL) und Datenmanipulationssprache (DML). Datendefinitionsprache Die Datendefinitionssprache ist eine Sammlung von Befehlen zur Definition und Manipulation von Datenbankschemata. Ein Datenbankschema legt Namen und Struktur der Tabellen und deren Abhängigkeiten fest. Zur Definition eines Schemas gehören Name, Zugriffsrechtangabe und eine optionale Liste von Schemaelementen. Die wichtigsten Schemaelemente sind Tabellen-, View- und Bedingungsdefinitionen. Um die Objekte eines SQL-Schemas definieren und nachträglich verändern zu können, stehen in SQL drei Befehle zur Verfügung: CREATE, ALTER und DROP. Die Erstellung einer neuen Tabelle im Schema kann durch den Befehl CREATE TABLE erfolgen. Dabei wird der Name der Tabelle und ihrer Attribute mit dessen Wertebereichen und Integritätsbedingungen angegeben: CREATE TABLE Tabellenname (Liste der Tabellenelemente); 19

20 2 GRUNDLAGEN AUS DER INFORMATIK Ein Tabellenelement definiert entweder ein Tabellenattribut oder eine Integritätsbedingung. Attribute werden folgendermaßen definiert: Spaltenname Datentyp [Default-Definition] [Liste von Spalten-Constraints] Während Spaltenname das Tabellenattribut darstellt, wird mit Datentyp dessen zugehöriger Wertebereich bezeichnet. Optional lässt sich die Spaltendefinition um einen Default-Wert erweitern. Mit Spalten-Constraints werden besondere Spaltenbeschränkungen festgelegt wie z.b.: NOT NULL: Nullwerte für das Attribut nicht erlaubt UNIQUE: Mehrfaches Auftreten der Werte dieses Attributs nicht erlaubt CHECK: Die Werte müssen die Bedingung der Check-Klausel erfüllen PRIMARY KEY: Primärschlüssel REFERENCES: Fremdschlüssel Besonders wichtige Integritätsbedingungen stellen die Primärschlüssel- und Fremdschlüsseldefinitionen dar. Primärschlüssel dienen zur eindeutigen Identifizierung eines Tupels: PRIMARY KEY (Liste von Spaltennamen) Kandidaten dafür sind solche Spalten, die weder Duplikate noch Null-Werte enthalten. Null-Werte werden zur Markierung unbekannter Attributwerte eingesetzt. Ein Primärschlüssel kann entweder mehrspaltig (siehe obere Syntax) oder einspaltig sein. Im zweiten Fall erfolgt die Definition meist als Spalten-Constraint: Spaltenname Datentyp PRIMARY KEY Eine zweite Schlüsselform wird durch den sogenannten Fremdschlüssel umgesetzt. Dadurch werden eine oder mehrere Spalten der zu deklarierenden Tabelle gekennzeichnet, die die Werte anderer Spalten, meist Primärschlüssel, referenzieren und damit auf deren Vorkommen beschränkt werden: FOREIGN KEY (Liste von Spaltennamen) REFERENCES Tabellenname SQL bietet auch die Möglichkeit vordefinierte Anfragen als sogenannte Views zu deklarieren. In diesem Sinne ist eine View eine von jeweils einer oder mehreren Tabellen abgeleitete virtuelle Tabelle. Views können wie folgt mit eigenem Namen versehen werden: CREATE VIEW View-Name AS ( SELECT Liste von Spaltennamen FROM Tabellenname WHERE Bedingung ) 20

21 2.2 Structured Query Language (SQL) Für die Erstellung einer View spielt der SELECT-Ausdruck eine zentrale Rolle. Darauf wird im nächsten Abschnitt (Datenmanipulationssprache) im Detail eingegangen. Wie bereits erwähnt wurde, kann das Datenbankschema, genauer seine Datenbankobjekte, in SQL nachträglich modifiziert werden. Mit dem Schlüsselwort ALTER können Modifikationen vorgenommen werden, wobei mit dem Schlüsselwort DROP ein Objekt aus dem Schema gelöscht wird. Mit ADD können neue Datenbankobjekte wie z.b. neue Spalten einer Tabelle hinzugefügt werden. Datenmanipulationssprache Die Datenmanipulationssprache von SQL umfasst das Ändern sowie das Abfragen von Daten. Für eine Datensuche in der Datenbank bietet der SQL-Standard die SELECT-Anweisung. Ein SELECT-FROM-WHERE-Block bildet die Grundstruktur für eine Anfrage an die Datenbank: SELECT Attributliste FROM Tabellenliste WHERE Bedingung Die Tabellenliste der Anweisung stellt den Input für die Abfrage dar und zählt alle Tabellen auf, auf die zur Auswertung der Anfrage zugegriffen werden soll. Der WHERE-Teil ist optional und bewirkt durch seinen bedingten booleschen Ausdruck eine Selektion auf die Tupel einer Relation. Die Bedingung liefert demnach einen Wahrheitswert und kann in zahlreichen Variationen, wie z.b. Vergleiche von Attributwerten, vorkommen. Die Ergebnismenge wird schließlich auf diejenigen Attribute projeziert, die im SELECT-Teil aufgelistet wurden. Ein Stern (*) bedeutet hierbei, dass alle Attribute in die Ausgabe aufgenommen werden sollen. SQL arbeitet bei der Anfragebearbeitung mengenorientiert, Duplikate bleiben jedoch erhalten. Eine Duplikateliminierung kann durch das Schlüsselwort DISTINCT erzwungen werden: SELECT DISTINCT Attributliste... Der FROM-Teil muss nicht nur eine einfache Liste von Tabellen enthalten. Zum einen ist eine Tabelle durch eine Unterabfrage ersetzbar. Weiterhin bietet SQL das Konzept des relationalen Verbunds (JOIN). Hierbei werden die Tupel einer Tabelle anhand bestimmter Kriterien, meist einem Test auf Gleichheit, mit den Tupeln einer zweiten Tabelle verbunden: SELECT * FROM Tabellename1 T1 INNER JOIN Tabellenname2 T2 ON (T1.AttributY = T2.AttributY) Veranschaulichen lässt sich dieser Verbund durch Abbildung 2.6. Tupel aus den Tabellen T1 und T2, deren Werte in der Spalte Y gleich sind, bilden im Endergebnis ein neues Tupel. 21

22 2 GRUNDLAGEN AUS DER INFORMATIK T1: X Y T2: Y Z 1 b c 7 3 c c 9 = 2 a d 6 T3: X Y Z 3 c 7 3 c 9 Abbildung 2.6: Relationaler Verbund (JOIN) Ein JOIN ließe sich ebenso als SELECT-FROM-WHERE-Block formulieren, kann jedoch in den meisten Fällen vom DBMS effizienter ausgewertet werden als das folgende Äquivalent: SELECT * FROM Tabellename1 T1 INNER JOIN Tabellenname2 T2 WHERE T1.AttributY = T2.AttributY Wurde eine Basistabelle erstellt, so kann diese durch eine INSERT-Anweisung mit Daten gefüllt werden. Die Grundstruktur für das Einfügen einer Zeile beschreibt der folgende Code: INSERT INTO Tabellenname1 (AttributX, AttributY,...) VALUES (WertX, WertY,...) Die Tabelle kann demnach um ein Tupel erweitert werden, indem der Tabellenname sowie die einzelnen zu den Attributen gehörenden Werte angegeben werden. Die Angabe der Attributnamen direkt hinter dem Tabellennamen ist optional, jedoch hilfreich, wenn man nicht alle Werte angeben möchte oder aber die Reihenfolge und damit die Zuordnung der Werte zu den Spalten eindeutig spezifiziert werden soll. Hierbei nicht angegebene Attribute werden beim Einfügen in die Datenbank auf NULL gesetzt. Verletzen die neuen Werte die definierten Integritätsbedingungen, so wird die Anfügeabfrage in der Regel vom DBMS abgewiesen. Der SQL-Standard bietet neben dem Einfügen einzelner Tupel außerdem die Möglichkeit, mehrere Tupel mithilfe einer beliebigen Unterabfrage in eine Tabelle einzufügen: INSERT INTO Tabellenname1 (AttributX1, AttributY1,...) SELECT AttributX2, AttributY2,... FROM Tabellenname2 WHERE Bedingung Bereits in der Datenbank vorhandene Daten sind mit dem UPDATE-Befehl modifizierbar. Eine SET-Klausel weist dabei den Attributen für alle sich qualifizierten Tupel der Tabelle neue Werte zu: UPDATE Tabellenname SET AttributX = NeuerWertX, AttributY = NeuerWertY WHERE Bedingung 22

23 2.2 Structured Query Language (SQL) Wie die Anweisung zeigt, ist es möglich, die Änderung auf bestimmte die Bedingung erfüllenden Tupel einzuschränken. Der WHERE-Teil kann jedoch entfallen, wenn die Änderungsoperation auf der gesamten Tabelle ausgeführt werden soll. Sollen schließlich Tupel aus einer Tabelle entfernt werden, so kann dies mit einer DELETE-Anweisung erreicht werden: DELETE FROM Tabellenname WHERE Bedingung Dabei werden alle Tupel aus der spezifizierten Tabelle gelöscht, welche die Bedingung erfüllen. Durch Weglassen der Bedingung ist es möglich, alle Zeilen aus der Tabelle zu entfernen, sodass lediglich eine leere Tabelle in der Datenbank erhalten bleibt Anfrageoptimierung Datenbanken können unzählig viele Datensätze speichern, wodurch mit zunehmender Menge die Anfragen auf diese Datenmengen schnell langsamer werden. Somit ist die Anfrageoptimierung eine der wichtigsten Aufgaben während der Entwicklung eines datenbankgestützten Systems. Während eine effiziente Implementierung der Auswertungsoperatoren lediglich vom DBMS abhängig ist, kann die Auswertung von komplexeren Anfragen vom Datenbankentwickler beeinflusst werden. Es gibt sowohl logische als auch physische Optimierungsmöglichkeiten. Die Optimierung ist stets ein sehr umfangreiches Thema, im Folgenden werden einige ausgewählte Optimierungstechniken vorgestellt. Formulierung von Anfragen Für SQL-Anfragen gibt es meist eine Vielzahl von Formulierungsmöglichkeiten. Sie liefern zwar dasselbe Ergebnis, werden aber nicht immer vom DBMS gleich ausgewertet. Ziel ist es, Teilergebnisse so klein wie möglich zu halten. Dies ist insbesondere dann von großer Bedeutung, wenn der Hauptspeicher für die Bearbeitung der Anfragen nicht groß genug ist und Ergebnisse im Hintergrundspeicher zwischengespeichert werden müssen. Datenbankmanagementsysteme verfügen bereits über sogenannte Query Optimizer, die durch eine Analyse der Anfrage sowie der benötigten Tabellen eine Anfrageoptimierung durchführen. So werden beispielsweise Selektionen in der Abarbeitungshierarchie so weit wie möglich nach oben geschoben. Auch eine Zusammenfassung von Selektionen und Kreuzprodukten zu Joins sowie eine Umordnung von Joinfolgen tragen zu einer Performanzsteigerung bei. Dennoch sollte auch der Datenbankentwickler sein Augenmerk auf die Art und Weise der Anfrageformulierung richten. Beispielweise sollten im SELECT-Teil nicht erforderliche Spalten vermieden werden. Weiterhin können nicht alle Operatoren vom Query Optimizer gleich gut optimiert werden. So lassen sich z.b. Vergleichoperatoren wie AND, OR, BETWEEN, =, LIKE, IN effizient auswerten. Die Auswertung 23

24 2 GRUNDLAGEN AUS DER INFORMATIK von NOT IN oder NOT EXISTS hingegen ist teuer und selten vom DBMS optimierbar, sodass die Anfrage beispielsweise durch eine entwicklerseitige Umformung verbessert werden sollte. Partitionierung Bei der Partitionierung wird die Relation in logisch zusammengehörende Teile geteilt und zudem in verschiedenen Speicherbereichen abgelegt. Dadurch lassen sich zum Beispiel Zugriffskosten minimieren, wenn überflüssige Teilanfragen erkannt und eliminiert werden können und Anfragen nur auf einer Partitionierung ausgeführt werden müssen. Gegebenfalls ist auch eine parallele und somit schnellere Ausführung von Aggregatfunktionen, wie zum Beispiel Minimum- oder Summenberechnung, sowie die Auswertung von Selektion oder Projektion möglich. Vorberechnete Auswertungen Um das Ergebnis einer Anfrage schneller zu berechnen, kann auch ein redundantes Ablegen der Daten von Vorteil sein. Eine weitere Optimierungsmöglichkeit besteht somit in der Vorberechnung von Auswertungen. Für teure Teilanfragen, die oft benutzt werden, sich aber nicht ständig ändern, kann das Abspeichern des Teilergebnisses zu einer immensen Beschleunigung der Auswertung führen. So können zum einen Anfragen materialisiert werden. Dadurch liegt das Ergebnis vorberechnet in Tabellen vor und muss lediglich ausgelesen werden. Es ist jedoch darauf zu achten, dass Änderungen auf den Basistabellen der ursprünglichen Anfrage auch zur materialisierten Sicht durchpropagiert werden, um Inkonsistenzen zu vermeiden, sofern dies nicht durch das DBMS unterstützt wird. Bei größeren Datenmengen kann sich auch ein Clustering einer Tabelle lohnen. Hierbei werden die Daten inhaltlich sortiert nah beieinander im Hintergrundspeicher abgespeichert. Somit können Selektionen oder Joins vorberechnet abgespeichert und die Seitenzugriffe auf logisch verwandte Datensätze beim Laden der Daten beschleunigt werden. Nachteilig ist allerdings, dass hierbei Änderungsoperationen und das komplette Auslesen einer einzelnen Tabelle (Full Table Scan) kostspielig sind. Indexe In den meisten Abfragen, wie auch beim Einsatz von Joins, wird nach Datensätzen gesucht, die ein bestimmtes Kriterium erfüllen. Auch ein Sortieren von Datensätzen basiert auf Feldvergleichen. In der Regel muss dafür die gesamte Tabelle geladen und jedes einzelne Tupel auf die Bedingung hin überprüft werden. Um unnötige Seitenzugriffe und Vergleiche zu verhindern, kann das Anlegen von Indexen auf den für die Selektion notwendigen Spalten hilfreich sein. Dies ermöglicht die gezielte Suche nach qualifizierenden Tupeln. Je nach Selektionsbedingung bieten sich verschiedene Arten von Indexen an, wie z.b. Baumstrukturen oder Bitlisten. Auch hierbei wird eine Optimierung durch Redundanz erreicht. Ein Index benötigt demnach zusätzlichen 24

25 2.3 Java Speicherplatz. Zudem macht er eventuelle Änderungsoperationen teurer, da der Index bei jeder UPDATE-Operation neu aufgebaut werden muss. Somit ist abzuwägen, ob die Effizienzsteigerung der Anfrage größer ist als die Kosten durch ein eventuelles Ändern, Löschen oder Hinzufügen von Datensätzen. MS Access spezifische Optimierungen MS Access bietet ebenfalls einige Funktionalitäten, die den Datenbankentwickler bei der Datenbankoptimierung unterstützen. Im Folgenden soll darauf kurz eingegangen werden. Komprimierung Bei jeder Änderung werden vom DBMS Kopien der Daten erstellt, sodass regelmäßig eine Komprimierung notwendig wird. Mit der Option Datenbank komprimieren und reparieren..., welche zu den Datenbank-Dienstprogrammen gehört, wird die Datenbank um ein Vielfaches komprimiert. Des Weiteren werden die Daten dadurch neu strukturiert und für Abfragen zusammenhängender und damit eventuell für Seitenzugriffe günstiger abgespeichert. Leistungsanalyse Die Option Leistung zu finden unter Extras - Analyse analysiert die aktuelle Datenbank und gibt Empfehlungen und Vorschläge zur Steigerung der Effizienz. So können zum Beispiel auch sinnvolle Indexe oder Beziehungen automatisch angelegt werden. Die interne sogenannte Rushmore -Optimierung setzt insbesondere indizierte Felder voraus. JetShowPlan Nicht unmittelbar zugänglich, aber dennoch hilfreich während der Optimierung, ist die Erstellung eines Auswertungsplanes. MS Access bietet die Möglichkeit, die Anfragebearbeitung in einer Datei showplan.out zu dokumentieren. Daraus lassen sich Rückschlüsse auf kostenintensive Teilanfragen machen, auf deren Grundlage sich die Anfrage manuell verbessern lässt. Diese Funktionalität wird aktiviert, sobald die Variable JETSHOWPLAN in der Windows- Registry auf ON gesetzt wird. 2.3 Java Java ist eine objektorientierte Sprache, die sich durch ihre Plattformunabhängigkeit auszeichnet. Dies ist dem vom Java Compiler erzeugten Byte Code zu verdanken. Von der objektorientierten Natur abgesehen stellt Java gute Mittel zur Gestaltung grafischer Oberflächen sowie zur Erstellung nebenläufiger Anwendungen zu Verfügung. Die im Rahmen dieser Arbeit angewandten Aspekte dieser Sprache werden in diesem Abschnitt kurz vorgestellt. 25

26 2 GRUNDLAGEN AUS DER INFORMATIK Grundlegendes Der objektorientierte Ansatz baut auf dem Gedanken Alles ist ein Objekt auf. Ein Objekt ist ein tatsächlich existierendes Ding aus der Anwendungswelt des Programms. Es spielt dabei keine Rolle, ob es sich um die programmierte Umsetzung eines konkret existierenden Gegenstandes handelt, oder ob nur ein abstraktes Konzept modelliert wird [Krü04]. Jedes Objekt ist durch eine Identität, einen Zustand und ein Verhalten charakterisiert. Ein Bündel gleichartiger Objekte wird als Klasse bezeichnet. Die Klassen sind ein sehr wichtiger Begriff in der Objektorientierung. Die Identität eines Objekts wird durch eine Menge von Variablen ausgedrückt, die sogenannten Attribute, die den Zustand dieses Objekts definieren und sich von einer Instanz einer Klasse zur anderen unterscheiden können. Objekte können Operationen ausführen, die dadurch ihr Verhalten darstellen. Diese Operationen werden Methoden genannt. Die Attribute bleiben in der Regel aus externer Sicht verborgen, sodass der Zustand der Klasse nur über bestimmte Methoden beeinflusst werden kann. Dies wird als Kapselung bezeichnet. Die Objekte und Klassen werden nicht einzeln betrachtet, sondern sind untereinander durch Beziehungen verbunden. Eine wichtige Beziehung, die den Generalisierungsbzw. Spezialisierungsaspekt betont, wird durch die Vererbung umgesetzt. Diese Beziehung wird in Java durch das Schlüsselwort extends explizit beschrieben und soll durch den folgenden Code veranschaulicht werden: public class Mitarbeiter { private String _name; private String _geburtsdatum; } public class Professor extends Mitarbeiter { private String _grad; } Die Klasse Professor leitet die obere Klasse Mitarbeiter ab. Die untere Klasse erbt die Eigenschaften der oberen Klasse wie Name und Geburtsdatum, kann jedoch andere Attribute wie Grad besitzen. Ein anderes Merkmal der Objektorientierung stellt der Polymorphismus (dt. Vielfältigkeit) dar. Dies erlaubt es, Methoden mit gleichem Namen und gleicher Signatur in den Unterklassen neu zu implementieren, d.h. zu überschreiben, und an deren Anforderungen anzupassen. Das führt zur Verstärkung der Wiederverwendbarkeit und Flexibilität, die für die Entwicklung von Software-Systemen große Bedeutung trägt. 26

27 2.3 Java Dies macht sich insbesondere in dem von Java unterstützten Late Binding bzw. Dynamic Binding bemerkbar. Dabei wird erst zur Laufzeit und nicht direkt zur Kompilierzeit entschieden, welche Umsetzung der Methode in der Klassenhierarchie aufgerufen werden soll Threads Threads gehören mit zu den wichtigsten Konzepten, die Java anbietet. Sie ermöglichen eine scheinbar parallele Ausführung verschiedener Programmteile. Diese Programmteile werden verzahnt abgearbeitet, sodass man den Eindruck gewinnt, dass sie wirklich parallel ausgeführt werden. Im Gegensatz zu einem Prozess besitzt ein Thread keinen eigenen Speicher, sondern greift mit anderen Threads auf einen gemeinsamen Adressierungsraum zu. Damit werden Zeit und Systemressourcen gespart. Es gibt zwei Wege, um einen Thread zu starten: Entweder implementiert man die Schnittstelle Runnable, oder man erweitert die Klasse java.lang.thread. Im ersten Fall wird die Methode run() des Runnable-Interfaces implementiert, das Runnable- Objekt im Thread-Konstruktor übergeben und dann die Methode start() dieses erzeugten Threads aufgerufen. Beim zweiten Weg lässt man die betrachtete Klasse von der Thread-Klasse erben. Hierbei reicht es, dass die run()-methode überschrieben wird, die den Code beinhaltet, der nebenläufig mit den restlichen Programmen auszuführen ist. Wenn die Klasse, die man als Thread realisieren möchte, keine bereits abgeleitete Klasse ist, ist die zweite Variante die bessere, welche das folgende Code- Fragment zeigt: class MyThread extends Thread { public void run() { //Das auszuführende Code-Fragment try {... } catch (InterruptedException e) {} } } }... MyThread mythread = new MyThread(); mythread.start(); Um das Verhalten des Threads zu kontrollieren, bieten sich verschiedene Möglichkeiten an. Mit der Methode sleep() wird z.b. die Ausführung des Threads für eine bestimmte Anzahl von Millisekunden gestoppt. Der Aufruf von sleep() muss in einem 27

28 2 GRUNDLAGEN AUS DER INFORMATIK try-catch-block gekapselt werden. Solange die sleep()-methode ausgeführt wird, ist eine Sperre auf das Thread-Objekt gesetzt. Dies kann z.b. für 1000 Millisekunden wie folgt geschehen: try { sleep(1000); } catch (InterruptedException e) { throw new RuntimeException(e); } Die Threads können miteinander kooperieren und auf das Eintreffen bestimmter Ereignisse warten. Dies ist durch die Methoden wait() und notify() möglich. Es gibt zwei Sorten von wait(). Die eine nimmt einen Millisekunden-Parameter entgegen und hat dieselbe Auswirkung wie sleep(), während die andere Variante parameterlos ist. In letzterem Fall wird die Methode solange ausgeführt, bis eine der Methoden notify() bzw. notifyall() aufgerufen wird. Im Gegensatz zu sleep() kann die Sperre beim Aufruf von wait() freigegeben werden. Die Ausführung von wait() darf nur innerhalb eines synchronized-blocks erfolgen, wie der folgende Code zeigt: synchronized(this) { try { wait(); } catch (InterruptedException e) { throw new RuntimeException(e); } } Wird eine der Methoden wait(), notify() oder notifyall() in einer nicht mit synchronized ausgezeichneten Methode aufgerufen, wird das Programm zwar kompiliert, aber zur Laufzeit eine IllegalMonitorStateException ausgegeben. Das bedeutet, dass der Thread, der diese Methode aufgerufen hat, keine Sperre auf den aufgerufenen Thread besitzt. Ein durch das Schlüsselwort synchronized gekennzeichneter Code ermöglicht einen exklusiven Zugriff auf den Thread JDBC JDBC, inoffiziell mit Java Database Connectivity gleichgesetzt, bezeichnet die Schnittstelle zwischen einer SQL-Datenbank und der Java-Applikation, die darauf Zugriff nehmen soll. JDBC ist eine Java-Klassenbibliothek zur Ausführung von SQL- Anweisungen, die zusätzliche Prozesse für die Erstellung von Anfragen vermeidet. 28

29 2.3 Java Bevor eine Datenbankverbindung aufgebaut werden kann, muss der entsprechende JDBC-Treiber durch den Aufruf der Methode Class.forName( Treiber-Name ) geladen werden. Dies ist im Package java.sql enthalten, welches importiert werden muss. Der Zugriff auf die Datenbank kann mittels JDBC in den folgenden Schritten durchgeführt werden: 1. Verbindungsaufbau zur Datenbank über den zugehörigen JDBC-Treiber des verwendeten DBMS. Dies erfolgt über die Methode getconnection(), die mindestens die Adresse der Datenbank in Form einer URL als Parameter erwartet: Connection con = DriverManager.getConnection(db_url); 2. Erzeugung einer SQL-Anweisung. Dafür muss ein Statement-Objekt erzeugt werden, was durch die Methode createstatement() erfolgen kann: Statement stmt = con.createstatement(); 3. Ausführung der SQL-Anweisung. Während die Methode executeupdate() Änderungsoperationen ausführt, können Anfragen mit der Methode executequery() durchgeführt werden: ResultSet rst = stmt.executequery("meine Anfrage"); 4. Ergebnisse einer Anfrage aus der Datenbank lesen. Die Methode executequery() gibt ein ResultSet-Objekt zurück, welches die Ergebnismenge repräsentiert. Um auf diese Menge zugreifen zu können, stellt die Klasse ResultSet eine Iterator-Schnittstelle mit datentypspezifischen Getter-Methoden zur Verfügung: while (rst.next()) { mein_int = rst.getint(1); } 5. Verbindung mit der Datenbank schließen. Wurde die Ergebnismenge verarbeitet, soll diese sowie das Statement und anschließend die Verbindung geschlossen werden: rst.close(); stmt.close(); con.close(); 29

30 2 GRUNDLAGEN AUS DER INFORMATIK Swing Swing ist eine vollständig in Java geschriebene Bibliothek zur Gestaltung von grafischen Benutzeroberflächen (Graphical User Interface, GUI) und umfasst die Darstellung von GUI-Komponenten, das Zeichnen sowie das Event-Handling. Eine Benutzeroberfläche lässt sich durch das Zusammensetzen und Verschachteln der verschiedensten Swing-Elemente aufbauen, welche grob in Top-Level-Container, Grundkomponenten und Menüs unterteilt werden können. Der Hauptzweck eines Containers liegt darin, dass er andere Container und Komponenten enthalten und entsprechend seines Layouts anordnen kann. Die Grundlage für ein Fenster einer Abbildung 2.7: JFrame mit GUI-Komponenten Standardanwendung stellt hierbei die Top-Level-Container-Klasse JFrame dar. Ihr werden - gegebenfalls verschachtelt - alle die Benutzeroberfläche beinhaltenden GUI- Elemente hinzugefügt. Das Fenster kann dafür zunächst in eine optionale Menüleiste JMenuBar und einen Container contentpane für den eigentlichen Inhalt des Fensters unterteilt werden. Die Oberklasse Container, von der alle GUI-Komponenten abgeleitet werden, stellt die Methode add(component c) zur Verfügung, mit der sich beliebige Komponenten hinzufügen lassen. Die GUI-Elemente von Swing, in der Regel Unterklassen von javax.swing.jcomponent, umfassen für die Darstellung eines GUIs eine Vielzahl von einfachen und komplexen Komponenten, wie z.b. Schaltflächen, Auswahllisten, Eingabefelder oder Baumstrukturen (vgl. Abbildung 2.7) West North Center East South 3 BorderLayout GridBagLayout CardLayout Abbildung 2.8: Layout-Manager im Vergleich 30

31 2.3 Java Zur komfortablen Anordnung dieser Elemente bietet Swing verschiedene Layout- Manager (siehe Abbildung 2.8). Je nach Wahl des Layout-Managers passen sich die Komponenten automatisch an Ausmaß und Positionierung anderer Komponenten sowie die Größe des Anwendungsfensters an. Eine Möglichkeit stellt das sogenannte BorderLayout dar. Hierbei lassen sich die GUI-Komponenten mithilfe der BorderLayout-Konstanten NORTH, WEST, EAST, SOUTH und CENTER im Container platzieren: meincontainer.setlayout(new BorderLayout()); meincontainer.add(new JButton(), BorderLayout.NORTH); Ein weitaus flexiblerer und somit der aufwändigste Layout-Manager ist das GridBagLayout. Hierbei wird die Fläche logisch in ein rechteckiges Gitter unterteilt. Um die Positionierung im Detail festlegen zu können, werden sogenannte GridBag- Constraints definiert und einer Instanz der Klasse GridBagLayout zugeordnet. Die Bestandteile eines Containers können sich hierbei über mehrere Gitterzellen ausbreiten und freien Platz zu unterschiedlichen Graden füllen. Ein anderes Layout-Konzept stellt das CardLayout bereit, bei dem sich beliebige gleichartige Komponenten den gleichen Platz teilen. Dieser Layout-Manager organisiert die Komponenten wie Karteikarten auf einem Stapel, bei dem stets nur die oberste sichtbar ist. Für einen Wechsel der obersten Karte lässt sich die erste und letzte sowie die nächste und vorherige Karte ansprechen oder aber explizit eine Komponente mit einem zuvor vergebenen Namen aufrufen. Swing stellt weiterhin Mittel zum Zeichnen einfacher Grundelemente und zur Darstellung von Bildern zur Verfügung. Die Oberklasse aller GUI-Grundkomponenten JComponent enthält hierfür insbesondere die Methode paintcomponent(graphics g), die stets aufgerufen wird, wenn ein Objekt neu gezeichnet werden muss. Um eigene Zeichnungen auf einer Komponente zu erstellen, kann diese vererbte Methode überschrieben und dabei mithilfe des intern von Swing übergebenen Graphics- Objektes Operationen zum Zeichnen ausgeführt werden. Die Klasse Graphics stellt dafür zum einen eine Methode drawimage() zur Verfügung, die es ermöglicht eine Grafik auf der Komponente zu platzieren. Zum anderen existieren verschiedene Methoden drawxy() zum Zeichnen grafischer Grundelemente wie z.b. Linien oder Rechtecke. Swing arbeitet nach dem sogenannten Model-Delegate-Prinzip, welches eine Variante der Model-View-Controller-Architektur ist. Dies bedeutet, dass zum einen ein Modell existiert, welches die Zustände der Daten bereithält. Zum anderen besteht getrennt davon ein als Beobachter agierendes Objekt, in diesem Fall eine Zusammenfassung von View und Controller, welches auf Änderungen des Modells reagiert (vgl. auch Model-View-Controller, Abschnitt 2.5.2). Daher lassen sich Swing- Komponenten an die speziellen Bedürfnisse anpassen, indem sowohl ein eigenes Modell definiert als auch ein Event-Listener der Komponente hinzugefügt werden kann. 31

32 2 GRUNDLAGEN AUS DER INFORMATIK Die Behandlung von Ereignissen ist eine der wichtigsten Aufgaben einer Benutzeroberfläche und in Swing sehr leicht umsetzbar. GUI-Komponenten bieten bereits Methoden und Interfaces für das Event-Handling an. So kann zum Beispiel die Reaktion auf einen Klick einer Schaltfläche (JButton) wie folgt umgesetzt werden: JButton jbutton = new JButton("Mein Button"); jbutton.addactionlistener(new ActionListener(){ public void actionperformed(actionevent e) { //auf Klick reagieren } }); Mithilfe verschiedener Event-Listener kann auf die Zustandsänderungen der GUI- Komponenten reagiert werden. Dies reicht von der Auswahl von Elementen einer Liste über die Bewegung des Mauszeigers bis hin zur Größenänderung von Komponenten. 2.4 Extensible Markup Language (XML) Die Extensible Markup Language (XML) wurde vom World Wide Web Consortium (W3C) in die Welt gerufen, um u.a. eine klare Trennung zwischen Formatierung und Inhalt eines Dokumentes zu erzielen [Wor]. XML gehört zur Familie der Auszeichnungssprachen. Sie bewirkt eine strukturierte Gliederung der Daten und Dokumente. So besitzt ein XML-Dokument eine baumartige Struktur, die hierarchische und strukturierte Daten unterstützt, und besteht damit aus hierarchisch geschachtelten Elementen. Die hierarchische Struktur von XML kann durch das folgende Beispiel veranschaulicht werden: <telefonbucheintrag> <name> <vorname>max</vorname> <nachname>mustermann</nachname> </name> <nummer> </nummer> </telefonbucheintrag> Ein Element wie z.b. telefonbucheintrag kann Unterelemente besitzen, die sogenannten Kinder, die wiederum Kinder erzeugen können. Im vorigen Beispiel wurde das Element name noch zu Vor- und Nachname aufgespalten. Während man sich z.b. bei einem HTML-Dokument an einen vordefinierten Satz von Tags halten muss, kann man bei XML leicht neue Elemente definieren und ebenso anwenden. Diese Elemente werden in einer sogenannten DTD-Datei (Document 32

33 2.5 Methoden der Softwaretechnologie Type Definition) deklariert. Die DTD-Datei dient der Sicherung der Wohlgeformheit des XML-Dokuments. Außerdem zeichnet sich XML durch eine plattformunabhängige Daten-Darstellung aus. Um XML-Dokumente verarbeiten und parsen zu können, bieten sich mehrere Möglichkeiten an. Es gibt insbesondere drei Verarbeitungstypen, die sich etabliert haben: SAX (Simple API for XML), DOM (Document Object Model) und STAX (Streaming API for XML). Bei SAX wird die XML-Datei sequentiell durchgegangen. Die Verarbeitung resultiert aus einem ereignisbasierten API (Application Programming Interface). Ereignisbasiert heißt, dass der Parser auf die Elemente der Dokumentstruktur reagiert, indem er vordefinierte Methoden für entsprechende Elemente, wie z.b. Start-Tags, aufruft. Dies hat zum Vorteil, dass man effizient und schnell das Dokument durchlaufen kann. Der Nachteil besteht allerdings darin, dass man durch die sequentielle Bearbeitung des Dokuments nicht beliebig auf die Teildokumente zugreifen kann. In diesem Fall ist Zwischenspeichern eine Notwendigkeit. SAX wird klassischerweise von Browsern für die Darstellung von XML-Dateien genutzt. Beim DOM-Ansatz hingegen wird die Baumstruktur zunächst auf den Hauptspeicher abgebildet und dann durchlaufen. Das ermöglicht eine große Flexibilität bei der Behandlung des Dokuments, sodass der Zugriff auf beliebige Teile des Dokuments leicht möglich ist. Diese Strategie ist jedoch für sehr große Dateien ungeeignet, weil dafür viel Hauptspeicher benötigt wird. DOM wurde von W3C unabhängig von den Programmiersprachen entwickelt. Daher bietet es unterschiedliche Schnittstellen, die von den verschiedenen Programmiersprachen implementiert werden können. STAX arbeitet nach dem Iterator- bzw. Cursor-Ansatz, wobei stets die nächsten Bestandteile des Dokuments angefordert werden müssen. Zunächst wird eine XMLInputFactory und dementsprechend der passende Parser erzeugt. Für die Cursor- Verarbeitung steht ein XMLStreamReader zur Verfügung, während für die Iterator- Verarbeitung ein XMLEventReader benutzt wird. Mit der Methode next() wird die jeweils nächste Komponente der XML-Datei ermittelt und je nach Typ verarbeitet. 2.5 Methoden der Softwaretechnologie Softwaretechnologie befasst sich mit Spezifikation, Entwurf und Erstellung komplexer Softwaresysteme durch die praktische zielorientierte Verwendung von wissenschaftlichen Methoden, Prinzipien und Werkzeugen. Für eine qualitätsorientierte Softwareentwicklung stehen verschiedene Prinzipien im Vordergrund. Zur Bewältigung der Komplexität zu entwickelnder Systeme ist zum einen die Trennung der verschiedenen Anforderungen notwendig. Dies hat zum Vorteil, dass sich die Aufgaben unter verschiedenen Projektmitarbeitern aufteilen lassen. Ein weiterer wichtiger Aspekt der Softwaretechnologie ist die Modularität. Hierbei werden komplexe Systeme in Komponenten zerlegt, die untereinander möglichst geringe 33

34 2 GRUNDLAGEN AUS DER INFORMATIK Abhängigkeiten und einen intern starken Zusammenhalt aufweisen. Durch Beachtung dieses Prinzips lässt sich das System leichter modifizieren und seine einzelnen Komponenten wiederverwenden. Darüber hinaus stellt die Abstraktion der Realität eine wichtige Säule der Softwaretechnologie dar. Dort werden die wesentlichen Aspekte des Problems betrachtet und hervorgehoben, ohne sich in Details zu verlieren. Ferner können mit der Zeit neue Anforderungen an das System hinzukommen. Somit ist es von Wichtigkeit, zukunftsorientiert eventuelle Änderungen in Betracht zu ziehen. Um die Wiederverwendbarkeit zu erhöhen und die Komplexität zu reduzieren ist es von Nutzen, Sachverhalte so weit wie möglich zu verallgemeinern. Generalisierung ist damit ein fundamentales Prinzip der Softwaretechnologie. Zuletzt sollte sich der Softwareentwicklungsprozess durch ein inkrementelles Vorgehen auszeichnen. Dafür wird fortlaufend Feedback entgegengenommen, um die Anforderungsziele im Auge zu behalten und dementsprechend stets das System zu verbessern. Im Folgenden werden die im Rahmen dieser Arbeit verwandten Methoden und Techniken vorgestellt. Abschnitt behandelt UML als Modellierungssprache für die Softwareentwicklung. In Abschnitt wird auf Design Patterns als Vorlagen für Entwurfs- und Designprobleme eingegangen. Abbildung 2.9: Häufig verwendete UML-Diagramme 34

35 2.5 Methoden der Softwaretechnologie Abbildung 2.10: Elemente eines Use Case-Diagramms Unified Modeling Language (UML) Die Unified Modeling Language (UML) ist eine Standardnotation, die für die Entwicklung und Dokumentation von Softwaresystemen genutzt wird. Bei der Entwicklung eines Systems sind meist eine Vielzahl von Personen beteiligt, die verschiedene fachliche Kompetenzen und soziale Hintergründe mit sich bringen. Um eine zielstrebige Projektplanung durchführen zu können, ist es umso wichtiger, eindeutige und präzise Diagramm-Spezifikationen zur Verfügung zu stellen, um Ideen und Konzepte unmissverständlich austauschen zu können. UML kann dabei in allen Phasen der Softwareentwicklung eingesetzt werden. Dies reicht vom Entwurf über die Implementierung bis hin zum Testen des Systems. UML-Diagramme können in verschiedene Typen aufgeteilt werden. Abbildung 2.9 gibt eine Übersicht über die am häufigsten verwendeten Diagramme. Die Struktur eines Systems wird mithilfe von Klassen- oder Use Case - Diagrammen beschrieben. Ein Komponentendiagramm sagt insbesondere etwas über die Systemarchitektur aus. Soll das Verhalten eines Systems beschrieben werden, wird dies durch Aktivitäts-, Zustands- oder Sequenzdiagramme konkretisiert. Bei letzterem liegt die Interaktion zwischen den Komponenten im Vordergrund. Die folgenden Erläuterungen geben einen Überblick über die in dieser Arbeit verwendeten UML-Diagramme. Use Case-Diagramm Der Einsatz von Use Case-Diagrammen ist insbesondere dann hilfreich, wenn zu Beginn eines Projektes die Funktionalitäten eines Systems festzulegen sind. Use Case-Diagramme werden somit speziell während der Anforderungsanalyse eingesetzt und stellen dabei das System aus Anwendersicht dar, ohne technische Umsetzungen mit einzubringen. Sie dienen weiterhin als Leitfaden während des gesamten Entwicklungsprozesses, um sicherstellen zu können, dass stets alle funktionalen Anforderungen an das System erfüllt werden. 35

36 2 GRUNDLAGEN AUS DER INFORMATIK Die Hauptkomponenten eines Use Case-Diagramms sind Akteure und Anwendungsfälle (siehe Abbildung 2.10). Ein Akteur ist eine mit dem System interagierende Person oder technische Einheit, wie z.b. Drucker oder Betriebssystem. Er stellt eine Rolle dar und steht in Beziehung mit einem oder mehreren Anwendungsfällen. Ein Use Case (Anwendungsfall) beschreibt ein generalisiertes, abstrahiertes Verhalten, welches für einen Akteur von außen wahrnehmbar ist. Eine konkrete Realisierung ist hierbei irrelevant, es werden lediglich die Leistungsanforderungen an einen bestimmten Arbeitsablauf festgehalten. Wie bereits erwähnt, können Anwendungsfälle und Akteure in Beziehung zueinander stehen. Dabei sind vier Beziehungstypen gebräuchlich. Die Kommunikationsbeziehung gibt an, dass ein Informationsaustausch zwischen Akteur und Use Case oder zwischen zwei Use Cases stattfindet. Die Vererbungsbeziehung ist mit einer Java-Vererbung zu vergleichen und zeigt an, dass ein Use Case eine Spezialisierung eines anderen Use Cases ist. Der Pfeil zeigt in Richtung des verallgemeinerten Use Cases. Die Erweiterungsbeziehung wird benutzt, wenn ein Use Case ein Sonderfall oder eine Ausnahme eines anderen Use Cases darstellt. Der Use Case, in dessen Richtung der Pfeil verläuft, wird nur unter gewissen Bedingungen ausgeführt, wenn eine Erweiterung der Funktionalität erforderlich ist. Die Enthält-Beziehung macht es möglich, komplexe Use Cases in mehrere Teile aufzuspalten. Sie besagt, dass der Use Case, zu dem der Pfeil hinführt, im Arbeitsablauf des anderen Use Cases integriert ist und kann auch genutzt werden, um einen Use Case in verschiedenen anderen Use Cases wiederzuverwenden. Für eine unmissverständliche Definition eines Anwendungsfalles bietet sich eine textuelle Beschreibung an. Zu notieren sind dabei die in Tabelle 2.1 aufgeführten Eigenschaften eines Use Cases. Klassendiagramme Ein Klassendiagramm dient zur Beschreibung von im System eingesetzten Klassen und deren Beziehungen untereinander. Sie werden auch während des Datenbankentwurfs eingesetzt. Abbildung 2.11 zeigt die möglichen Notationen. Eine Klasse wird mindestens durch seinen Namen charakterisiert. Weiterhin ist es möglich, Attribute mit Typ und Methoden mit Parametern und Rückgabewerten anzugeben. Assoziationen in Form einer durchgezogenen Linie lassen sich als Beziehungen zwischen Objekten, d.h. Instanzen einer Klasse, verstehen. Die Enden werden mit einer sogenannten Multiplizität versehen. Das dort angegebene Intervall beschränkt die Anzahl der Objekte, die an dieser Beziehung teilhaben können. Ein Stern (*) steht dabei für beliebig viele Objektverbindungen, d.h. eine beliebige natürliche Zahl ( 1..n). Darüber hinaus kennt UML spezielle Assoziationen. Eine Aggregation ( ist-teil-von -Beziehung) betont den hierarchischen Aufbau der Elemente und 36

37 2.5 Methoden der Softwaretechnologie Name: Der Namen des Use Cases, der von allen Projektteilnehmern eindeutig zugeordnet werden kann. Kurzbeschreibung: Eine kurze Beschreibung, die die Aufgabe des Use Cases erläutert. Akteure: Aufzählung aller beteiligten Akteure, mit denen der Use Case interagiert. Ereignisfluss: Detaillierte Beschreibung von Interaktionen, welche in einzelne Schritte unterteilt wird. Anfangsbedingungen: Bedingungen, die vor der Ausführung des Use Cases gelten müssen. Endbedingungen: Bedingungen, die nach dem unmittelbaren Ende eines Use Cases gelten. Ausnahmen: Beschreibung von Interaktionen bei nicht gewolltem Verhalten. Spezielle Anforderungen: Nichtfunktionale Anforderungen und Nebenbedingungen, die nicht das vom Anwender zu beobachtende Verhalten betreffen, sondern Aufbau und Implementierung des Systems einschränken können. Tabelle 2.1: Textuelle Use Case-Beschreibung wird grafisch mit einer Raute markiert. Sie ist vergleichbar mit der 1:n-Beziehung und ordnet ein Teil einem oder mehreren Ganzen zu, von denen sie jedoch nicht abhängig ist. Eine Komposition ( ist-ausschließlich-teil-von ), dargestellt durch eine ausgefüllte Raute, drückt hingegen aus, das ein Objekt nur allein einem Ganzen zugeordnet ist, ohne das es nicht bestehen kann. Abbildung 2.11: Klassendiagramm Im Beispiel aus Abbildung 2.11 erbt Klasse B alle Eigenschaften von Klasse A, während Klasse C und D in Beziehung zueinander stehen. Weiterhin sind beliebig viele Instanzen der Klasse A (ausschließlich) in Klasse C enthalten (Komposition). 37

38 2 GRUNDLAGEN AUS DER INFORMATIK Aktivitätsdiagramm Aktivitätsdiagramme dienen zur dynamischen Modellierung eines Systems. Sie stellen spezielle Zustandsdiagramme dar, deren Zustände Aktivitäten sind, und beschreiben den genaueren Ablauf eines Use Cases oder den Aufbau eines Programms. Sie können somit sowohl für den konzeptuellen Entwurf als auch für die Implementierung eingesetzt werden. Abbildung 2.12: Aktivitätsdiagramm Aktivitäten, bzw. Aktionszustände, sind die Hauptkomponenten eines Aktivitätsdiagramms und definieren mithilfe von Transitionen, welche durch einen gerichteten Pfeil dargestellt werden, einen sequentiellen Ablauf. Zur Verfeinerung der Struktur bietet UML hier weitere Notationen (siehe Abbildung 2.12). Ein Initialknoten in Form eines schwarzen Punktes kennzeichnet den Anfang des Steuerungsflusses. Wird er von einem Kreis umrandet, handelt es sich um einen Aktivitätsendknoten und deutet auf das Ende eines Pfades hin. Entscheidungsknoten leiten bedingungsabhängige Transitionen ein und werden durch Rauten repräsentiert. Die ausgehenden Transitionen werden mit Bedingungen in eckigen Klammern versehen, welche über den weiteren Kontrollfluss entscheiden. Werden mehrere Transitionen zu einer Transition zusammengeführt so wird dies durch einen ebenfalls durch eine Raute repräsentierten Vereinigungsknoten sichtbar. Parallelisierungs- bzw. Synchronisationsknoten werden durch ein schmales ausgefülltes Rechteck dargestellt. Sie veranschaulichen einen parallelen Arbeitsablauf, wie er durch Threads umgesetzt werden kann. 38

39 2.5 Methoden der Softwaretechnologie Sequenzdiagramm Sequenzdiagramme bieten die Möglichkeit, Interaktionen zwischen Objekten darzustellen, die an einem Use Case beteiligt sind. Der Nachrichtenaustausch sowie die zeitliche Abfolge der Interaktionen steht hierbei im Vordergrund. Sequenzdiagramme sind insbesondere für die Beschreibung komplexer und unklarer Abläufe gut geeignet. Abbildung 2.13 veranschaulicht die zugehörige Notation. Objekte werden spaltenweise dargestellt, wobei gestrichelte Linien, sogenannte Lebenslinien, ihre Existenz symbolisieren. Auf der linken Seite steht stets der Akteur, der den Anwendungsfall initialisiert. Abbildung 2.13: Sequenzdiagramm Aktivitätsbalken auf den Lebenslinien stellen die Ausführung von Methoden dar. Sie werden durch Nachrichten aktiviert, welche durch einen Pfeil repräsentiert werden. Pfeile synchroner Nachrichten tragen eine ausgefüllte Pfeilspitze, während sich ansynchrone Nachrichten mit offener Pfeilspitze kennzeichnen lassen. Eine Iteration wird dabei durch eckige Klammern mit vorangestelltem Sternchen markiert. Pfeile mit gestrichelter Linie am Ende eines Aktivitätsbalkens stehen für die explizite Angabe einer Antwort zur Verfügung. Mit einer erzeugenden Nachricht, dessen Pfeil zum Objektnamen führt, wird die Konstruktion eines Objektes gekennzeichnet. Eine Objektdestruktion lässt sich durch ein Kreuz am Ende einer Lebenlinie vermerken. 39

40 2 GRUNDLAGEN AUS DER INFORMATIK Design Patterns Die Softwareentwickler haben im Laufe der Jahre festgestellt, dass sie stets auf wiederkehrende Probleme stoßen. Damit man leichter über sie diskutieren kann, war es erforderlich, neue Begriffe einzuführen. Die Lösungen dieser Probleme wurden gesammelt, getauft und dokumentiert. Die Beschreibung eines Entwurfsproblems und die Erläuterung seiner Lösung definiert ein sogenanntes Design Pattern (dt. Entwurfsmuster). Es gibt drei Arten von Entwurfsmustern: erzeugende und strukturelle Muster sowie Verhaltensmuster. Die erste Kategorie sind solche, die zum Erstellen und Instanzieren von Objekten dienen. Ein Vertreter dieser Kategorie ist das Factory Pattern. Die strukturellen Muster sind für die Zusammensetzung von Objekten und Klassen geeignet. Ein Beispiel dafür ist das Adapter Pattern. Die letzte Sorte befasst sich mit der Zusammenarbeit von Klassen und Objekten. Ein Stellvertreter dieser Klasse ist das Observer Pattern. In diesem Abschnitt werden die Design Patterns, die im Rahmen dieser Arbeit verwendet wurden, vorgestellt. Factory Method Pattern Das Factory Method Pattern kann eingesetzt werden, wenn eine Klasse nicht über den Typ einer zu instanziierenden Klasse entscheiden kann oder soll. Dies bewirkt somit eine Verzögerung des Erzeugens neuer Objekte. Hierbei wird bei der betrachteten Klasse durch den Aufruf einer sogenannten Factory-Methode über den Zeitpunkt der Erzeugung von Objekten entschieden. Die Entscheidung über den Typ der Objekte wird durch die Implementierung der Factory-Methode festgelegt. Eine mögliche Umsetzung dieses Patterns kann folgendermaßen aussehen: class Erzeuger { Objekt erzeuge(int typ) { if (typ==1) return Objekt1(); if (typ==2) return Objekt2();... } } Die Factory-Methode in der Erzeuger-Klasse soll anhand übergebener Informationen entscheiden, welche konkrete Klasse zu instanziieren ist. Observer-Pattern Viele Systeme bestehen aus mehreren Klassen, die voneinder abhängig sind. Dabei besteht die Gefahr, dass die Komponenten des Systems ihre Konsistenz aus Mangel an Informationsaustausch verlieren. Das Observer-Pattern regelt die Beziehungen 40

41 2.5 Methoden der Softwaretechnologie zwischen den zusammenhängenden Klassen, ohne dass sie eng miteinander gekoppelt werden müssen. Dieses Muster verfügt über zwei wichtige Komponenten: ein Subject und ein Observer. Ein Subject wird von einem oder mehreren Observern beobachtet. Die Observer bekommen Nachrichten vom Subject, wenn bei diesem eine Zustandsänderung vorliegt. Der Informationsaustausch zwischen dem Subject und dem Observer veranschaulicht der folgende Pseudo-Code: benachrichtigen() { for all o in observers { o.update(); } } Die Methode benachrichtigen() des Subjects ruft für jeden Observer dessen zugehörige update()-methode auf, die dann entscheiden kann, welche Änderungsmaßnahmen vorgenommen werden müssen. Singleton-Pattern Das Singleton-Pattern fällt unter die Klasse von Erzeugungsmustern. Bei einem Singleton-Pattern wird beabsichtigt, dass eine Klasse genau einmal instanziert wird. Es wird weiterhin dafür gesorgt, einen allgemeinen Zugriff auf diese Instanz zu ermöglichen. Damit wird eine effiziente Zugriffskontrolle über die Singleton-Klasse erzielt. Dieses Pattern verbessert des Konzept der statischen Variablen. Eine statische Variable bietet nicht nur die Möglichkeit des globalen Zugriffs, sondern auch eine mehrfache Instanzierung, die nicht immer gewünscht wird. Sollte der Entwickler dennoch an mehreren Exemplaren der Singleton-Klasse interessiert sein, kann er leicht und flexibel die Methode, die den Zugriff regelt, ändern. Der folgende Code veranschaulicht eine Singleton-Methode: public static Singleton getinstance() { if (instance == null) instance = new Singleton(); return instance; } Modell-View-Controller Das Model-View-Controller-Pattern (MVC) ist einer der erfolgreichsten und meist verwendeten Design-Patterns. Hierbei geht es darum, die Repräsentation, die Datenquelle und ihre Interaktion zu trennen. Dieses Architekturmuster zeichnet sich durch drei Komponenten aus: Ein Datenmodell (Model), eine bzw. mehrere Repräsentationen (View) und eine Steuerungseinheit (Controller). 41

42 2 GRUNDLAGEN AUS DER INFORMATIK Ereignis Controller View View Modell Abbildung 2.14: Modell-View-Controller-Architektur Abbildung 2.14 veranschaulicht die einzelnen Komponenten einer MVC-Architektur und ihre Interaktionen. Das Modell repräsentiert eine zentrale Datengrundlage zur Kapselung der Daten und Funktionalitäten einer Applikation. Die Views sind für die Bildschirmrepräsentation des Modells zuständig. Für ein und dasselbe Modell können verschiedene Views existieren. Beim Eintreten bestimmter Ereignisse aktualisiert der Controller die Daten des Modells. Darüber hinaus kann der Controller anwendungsspezifisch eine Änderung der Views bewirken. Sind einmal die Daten des Modells verändert, werden diese Änderungen zu allen registrierten Views propagiert. Folglich wird eine Aktualisierung der einzelnen betroffenen Views durchgeführt. Durch den Einsatz des MVC-Patterns können gleichzeitig verschiedene Views ohne Konsistenzprobleme verwendet werden. Das Hinzufügen neuer Views ist ferner ohne Änderung des Modells möglich. Dies führt zur Stärkung der Erweiterbarkeit und Wiederverwendbarkeit. 42

43 Kapitel 3 Grundlagen aus dem Verkehrswesen Die gesamte Arbeit baut auf der Thematik des Verkehrswesens auf. In besonderem Ausmaß betrifft dies die Überwachung von Regelverstößen im Straßenverkehr. Daher soll dieses Kapitel ein Grundwissen aus dem Verkehrswesen vermitteln, welches für diese Arbeit von Bedeutung ist. Unterkapitel 3.1 erläutert zunächst einige Begrifflichkeiten. Anschließend führt Unterkapitel 3.2 Verkehrsregeln aus der Straßenverkehrsordnung auf, die der Überprüfung von Ordnungswidrigkeiten zugrunde liegen sollen. 3.1 Begriffsbestimmungen Als Verkehrsteilnehmer wird derjenige bezeichnet, der öffentliche Wege benutzt und damit am öffentlichen Verkehr teilnimmt, um eine Ortsveränderung vorzunehmen. Beispiele der wichtigsten Verkehrsteilnehmer sind Fußgänger, Fahrradfahrer oder Fahrzeugführer. Im Sinne der Straßenverkehrsordnung sind Fahrzeuge zur Fortbewegung auf dem Boden bestimmte und geeignete Geräte, nach OLG Düsseldorf müssen diese auch zugelassen und betriebsbereit sein. [Xan08] Unter einem Fahrstreifen versteht man den Teil einer Fahrbahn, den ein mehrspuriges Fahrzeug zum ungehinderten Fahren im Verlauf der Fahrbahn benötigt.[bunb] Die Fahrbahn besteht dabei aus einem oder mehreren Fahrstreifen und ist zum Befahren durch Fahrzeuge vorgesehen. Damit bildet sie zusammen mit dem Seitenstreifen und Randstreifen, der rechtlich gesehen nicht zur Fahrbahn gehört, den zusammenhängenden, befestigten Teil der Straße. [For00] Zeichnet sich die Straße durch das Vorhandensein einer baulichen Trennung aus, so entstehen dadurch zwei Richtungsfahrbahnen. Eine Kreuzung ist die Schnittfläche zweier oder mehrerer öffentlicher Straßen, welche sich jeweils auf der anderen Seite des Kreuzungsbereichs fortsetzen. Eine Einmündung hingegen liegt vor, wenn eine oder mehrere Straßen in eine andere einmünden, ohne dass für sie wie bei einer Kreuzung eine Fortsetzung existiert. 43

44 3 GRUNDLAGEN AUS DEM VERKEHRSWESEN Unter einer Lichtsignalanlage (LSA) ist eine technische Einrichtung zu verstehen, die bestehend aus einem oder mehreren Lichtsignalgebern und der dazu notwendigen Regelungstechnik zur Steuerung des Verkehrsflusses dient. Lichtsignalgeber, allgemein als Ampeln bekannt, übermitteln durch das angezeigte Signalbild Informationen an die Verkehrsteilnehmer und schreiben somit gemäß der Straßenverkehrsordnung ein Verhalten vor. Gegeben wird ein solches Lichtsignal jeweils für eine bestimmte Zeitdauer, die sogenannte Signalzeit. Die dies betreffenden Festlegungen für eine Lichtsignalanlage werden in einem Signalprogramm zusammengefasst. Ein Signalprogramm lässt sich in mehrere Phasen unterteilen, die sich durch einen unveränderten Signalisierungszustand auszeichnen. Eine Ordnungswidrigkeit ist eine rechtswidrige und vorwerfbare Handlung, die eine Geldbuße nach sich ziehen kann kann. Für den beteiligten Verkehrsteilnehmer sind unterschiedliche Folgen möglich. Bei geringfügigen Ordnungswidrigkeiten ist es vorgesehen, den Betroffenen zu verwarnen und gegebenfalls ein Verwarnungsgeld zu verlangen. Je nach Schweregrad sind juristische Folgen möglich, wie ein Bußgeldbescheid, ein Eintrag im Verkehrszentralregister in Flensburg oder ein Fahrverbot. Wiederum andere ordnungswidrige Handlungen können Straftaten beinhalten, wenn sie in Kombination mit anderen Tatbeständen begangen werden und besondere Gefährdungen nach sich ziehen. 3.2 Straßenverkehrsordnung Die Straßenverkehrsordnung (StVO) ist Teil des Straßenverkehrsrechts der Bundesrepublik Deutschland. Sie enthält insbesondere allgemeine Verkehrsregeln für die Verkehrsteilnehmer sowie die Bedeutung der Zeichen und Verkehrseinrichtungen. Für die Verkehrssicherheit und die Förderung des fließenden Verkehrs ist die Einhaltung der Regelungen von großer Bedeutung. Um die Verkehrsteilnehmer zur Beachtung der Straßenverkehrsordnung zu ermahnen, kann ein Verstoß gegen eine Verkehrsregel als Ordnungswidrigkeit geahndet werden. Ordnungswidrig im Sinne des 24 des Straßenverkehrsgesetzes handelt, wer vorsätzlich oder fahrlässig gegen die in 49 der StVO aufgezählten Regeln verstößt [Bunb]. Allgemein gilt hier der Opportunitätsgrundsatz, d.h. von einer Ahndung kann abgesehen werden, wenn der Verstoß völlig ungefährlich und von geringer Bedeutung war [Buna]. In dieser Arbeit sind diejenigen Ordnungswidrigkeiten von Bedeutung, die den Kreuzungsbereich betreffen. Im Folgenden werden daher die relevanten Verkehrsregeln und Zeichen beschrieben, die die Grundlage dieser Regelverstöße bilden. Ihre Erläuterungen sollen dabei sogleich die Komplexität der Kriterien jedes einzelnen Gesetzes widerspiegeln. 44

45 3.2 Straßenverkehrsordnung Grundregeln Die allgemeinen Verkehrsregeln der StVO beginnen mit dem Gebot der Rücksichtsnahme, auf der alle weiteren Verkehrsregeln aufbauen: 1 Grundregeln (1) Die Teilnahme am Straßenverkehr erfordert ständige Vorsicht und gegenseitige Rücksicht. (2) Jeder Verkehrsteilnehmer hat sich so zu verhalten, daß kein Anderer geschädigt, gefährdet oder mehr, als nach den Umständen unvermeidbar, behindert oder belästigt wird. Während Absatz 1 als die wesentliche Grundregel im Straßenverkehr gilt, kann ein Verstoß gegen Absatz 2 als Ordnungswidrigkeit geahndet werden. Grundsätzlich gilt zwar für die Förderung des fließenden Verkehrs der Vertrauensgrundsatz, was bedeutet dass Verkehrsteilnehmer auf das regelgerechte Verhalten anderer vertrauen dürfen. Im Gegensatz dazu ist jedoch defensives Fahren für die Verkehrssicherheit von enormer Bedeutung. Dies bedeutet, dass mit Fehlern anderer Verkehrsteilnehmer gerechnet werden muss, insbesondere solche, die erfahrungsgemäß des Öfteren beobachtet werden. Dies spiegelt 1 der StVO wider, denn eine Beschädigung, Gefährdung oder Behinderung anderer Verkehrsteilnehmer ist in jedem Fall zu vermeiden, auch wenn dabei auf das eigene Recht verzichtet werden muss. Rechtsfahrgebot Paragraph 2 der StVO geht auf die Benutzung der Straßen durch Fahrzeuge ein: 2 Straßenbenutzung durch Fahrzeuge (1) Fahrzeuge müssen die Fahrbahn benutzen, von zwei Fahrbahnen die rechte. Seitenstreifen sind nicht Bestandteil der Fahrbahn. (2) Es ist möglichst weit rechts zu fahren, nicht nur bei Gegenverkehr, beim Überholtwerden, an Kuppen, in Kurven oder bei Unübersichtlichkeit. (...) Absatz 2 beschreibt dabei das Rechtsfahrgebot, welches den Gegen- und Überholverkehr schützt, und gebietet, das möglichst weit rechts zu fahren ist. Möglichst weit rechts ist dabei relativ anzusehen und abhängig von zahlreichen Parametern, wie z.b. Fahrbahnbreite, Hindernissen oder Geschwindigkeit. Eine weitere Einschränkung dieser Vorschriften kann durch Zeichen 295 als Fahrstreifenbegrenzung erfolgen, welches anordnet, rechts der durchgezogenen Linie zu fahren, sofern sie zur Abtrennung des Gegenverkehrs vorgesehen ist. Verstöße gegen diese Regeln zur Straßenbenutzung sind ordnungswidrig. Eine Ausnahme des Rechtsfahrgebot sieht die Existenz mehrerer Fahrstreifen in einer Fahrtrichtung vor. Innerorts dürfen beide Fahrstreifen gleichermaßen befahren werden. 45

46 3 GRUNDLAGEN AUS DEM VERKEHRSWESEN Vorfahrt Paragraph 8 beschäftigt sich mit den Vorfahrtregeln an Kreuzungen und Einmündungen, was als Unterfall des Vorrangs zu betrachten ist. 8 Vorfahrt (1) An Kreuzungen und Einmündungen hat die Vorfahrt, wer von rechts kommt. Das gilt nicht, 1. wenn die Vorfahrt durch Verkehrszeichen besonders geregelt ist (Zeichen 205, 206, 301, 306) oder 2. für Fahrzeuge, die aus einem Feld- oder Waldweg auf eine andere Straße kommen. (2) Wer die Vorfahrt zu beachten hat, muß rechtzeitig durch sein Fahrverhalten, insbesondere durch mäßige Geschwindigkeit, erkennen lassen, daß er warten wird. Er darf nur weiterfahren, wenn er übersehen kann, daß er den, der die Vorfahrt hat, weder gefährdet noch wesentlich behindert. (...) oder Einmündung hineintasten, bis er die Übersicht hat. Auch wenn der, der die Vorfahrt hat, in die andere Straße abbiegt, darf ihn der Wartepflichtige nicht wesentlich behindern. (3) (aufgehoben) Vorfahrt ist dabei das Recht eines Fahrzeugführers, vorrangig in eine Kreuzung oder Einmündung einzufahren, wenn die Fahrlinien sich schneiden, berühren oder einander hemmend nähern. Der Vorfahrtberechtigte muss dabei zügig und unbehindert durchfahren können, (...), wobei geringes Gaswegnehmen, Ausweichen und andere unwesentliche Behinderungen als unvermeidbar außer Betracht bleiben. [Hen07] Zeichen 205 Zeichen 206 Abbildung 3.1: Vorfahrt gewähren! Die in 8 erwähnten Vorschriftzeichen 205 und 206 werden in 41 erläutert. Zeichen 205 (siehe Abbildung 3.1) verpflichtet das ankommende Fahrzeug, allen vorfahrtberechtigten sich nähernden Fahrzeugen die Vorfahrt zu gewähren. Zeichen 206 (Halt! Vorfahrt gewähren!) beinhaltet dieselben Pflichten wie Zeichen 205. Hinzu kommt, 46

47 3.2 Straßenverkehrsordnung dass ein Fahrzeug vor der Kreuzung anhalten muss, bevor es diese überquert. Dies gilt auch dann, wenn sich kein vorfahrtberechtigtes Fahrzeug nähert. Die Rechtsvor-Links-Regel betrifft meist nur noch verkehrsarme Straßen, bei denen eine Vorfahrtregelung durch Verkehrszeichen für den fließenden Verkehr keine Notwendigkeit hat. Zeichen 301 Vorfahrt Zeichen 306 Vorfahrtstraße Zeichen 307 Ende der Vorfahrtstraße Abbildung 3.2: Vorfahrt Zeichen 301, 306 und 307 (siehe Abbildung 3.2) gehören zu den in 42 behandelten Richtzeichen, die zur Erleichterung des Verkehrs auf bestehende Rechte hinweisen. Zeichen 301 ( Vorfahrt ) weist dabei darauf hin, dass an der nächsten Kreuzung oder Einmündung Vorrang gegenüber Fahrzeugen aus anderen Straßen besteht. Zeichen 306 ( Vorfahrtstraße ) besagt, dass es sich bei der Straße um eine Vorfahrtstrasse handelt. Vorfahrt besteht an jeder Kreuzung oder Einmündung, sofern das Recht nicht durch die Zeichen 205 Vorfahrt gewähren!, 206 Halt! Vorfahrt gewähren! oder 307 Ende der Vorfahrtstraße aufgehoben wird. Die Vorfahrt muss auch dann gewährt werden, wenn der Vorfahrtberechtigte sich nicht gemäß den Vorschriften verhält. Das Vorfahrtsrecht besteht jedoch nicht, wenn die Straße in einer nicht erlaubten Fahrtrichtung befahren wird. Ein Verzicht auf die Vorfahrt ist möglich, wobei sich der Wartepflichtige jedoch unmissverständlich mit dem Berechtigten zu verständigen hat. In bestimmten Situationen fordert auch das Gesetz einen Vorfahrtverzicht ( 1, 11). Eine Vorfahrtverletzung liegt dann vor, wenn sich die Fahrlinien nahe berühren, so dass dem Berechtigten wenig Spielraum bleibt und er Kollision befürchtet (...) Ordnungswidrig handelt, wer die Vorfahrt verletzt oder nicht rechtzeitig durch sein Fahrverhalten anzeigt, dass er warten werde. [Hen07] Die Warteplicht besteht jedoch lediglich gegenüber berechtigten Fahrzeugen, welche im Sichtfeld des Wartepflichtigen liegen. Daher sind zur Beurteilung der Rechtslage Sichtverhältnisse und die Geschwindigkeit der Fahrzeuge mit heranzuziehen. Eine Gefährdung des Straßenverkehrs durch grob verkehrswidriges, rücksichtsloses Nichtbeachten der Vorfahrt fällt nicht mehr in den Bereich der Verkehrsverstöße gegen die StVO und wird stattdessen strafrechtlich verfolgt. 47

48 3 GRUNDLAGEN AUS DEM VERKEHRSWESEN Vorrang und Fahrtrichtungsanzeiger bei Abbiegevorgängen In Paragraph 9 sind die Regeln zu den Abbiegevorgängen für diese Arbeit von Bedeutung: 9 Abbiegen, Wenden und Rückwärtsfahren (1) Wer abbiegen will, muß dies rechtzeitig und deutlich ankündigen; dabei sind die Fahrtrichtungsanzeiger zu benutzen. (...) (2) (...) (3) Wer abbiegen will, muß entgegenkommende Fahrzeuge durchfahren lassen, (...) (4) Wer nach links abbiegen will, muß entgegenkommende Fahrzeuge, die ihrerseits nach rechts abbiegen wollen, durchfahren lassen. Führer von Fahrzeugen, die einander entgegenkommen und jeweils nach links abbiegen wollen, müssen voreinander abbiegen, es sei denn, die Verkehrslage oder die Gestaltung der Kreuzung erfordern, erst dann abzubiegen, wenn die Fahrzeuge aneinander vorbeigefahren sind. (5) (...) Abbieger sind grundsätzlich dazu verpflichtet, entgegenkommenden Fahrzeugen Vorrang zu gewähren. Der Fahrtrichtungsanzeiger während des Abbiegevorgangs ist insbesondere dann von großer Bedeutung, wenn er von einem vorfahrtberechtigten Fahrzeug falsch gesetzt wird und andere wartepflichtige Verkehrsteilnehmer darauf vertrauen (Vertrauensgrundsatz). Kommt es in dieser Situation zum Unfall, trifft den Vorfahrtsberechtigten das Hauptverschulden. [KR08] Stockender Verkehr Besondere Verkehrslagen, die ein von den Verkehrsregeln abweichendes Verhalten verlangen, werden in 11 geregelt. Dies betrifft insbesondere den stockenden Verkehr: 11 Besondere Verkehrslagen (1) Stockt der Verkehr, so darf trotz Vorfahrt oder grünem Lichtzeichen niemand in die Kreuzung oder Einmündung einfahren, wenn er auf ihr warten müßte. (2) (...) (3) Auch wer sonst nach den Verkehrsregeln weiterfahren darf oder anderweitig Vorrang hat, muß darauf verzichten, wenn die Verkehrslage es erfordert; auf einen Verzicht darf der andere nur vertrauen, wenn er sich mit dem Verzichtenden verständigt hat. Stockender Verkehr liegt genau dann vor, wenn die Kreuzung oder Einmündung in beabsichtigter Fahrtrichtung durch wartende Fahrzeuge blockiert ist, sodass ein zügiges Überqueren nicht sichergestellt werden kann. In dieser Situation fordert also die StVO einen Verzicht auf das Vorfahrtsrecht, da ein Fahrzeug im Kreuzungsbereich nicht warten darf. Eine zusätzliche Behinderung anderer ist keine Voraussetzung für den Tatbestand. 48

49 3.2 Straßenverkehrsordnung Lichtzeichen und Grünpfeil Der zweite Abschnitt der Straßenverkehrsordnung beschäftigt sich mit den in der Bundesrepublik Deutschland zur Verfügung stehenden Zeichen und Verkehrseinrichtungen. Für Kreuzungen und Einmündungen ist dabei zunächst 37 der Straßenverkehrsordnung relevant, welcher auf die Beachtung von Lichtsignalgebern eingeht. 37 Wechsellichtzeichen, Dauerlichtzeichen und Grünpfeil (1) Lichtzeichen gehen Vorrangregeln, vorrangregelnden Verkehrsschildern und Fahrbahnmarkierungen vor. Die drei Farben der Wechsellichtzeichen tragen an Kreuzungen dabei die folgenden Bedeutungen: (2) (...) Grün: Der Verkehr ist freigegeben. (...) Grüner Pfeil: Nur in Richtung des Pfeiles ist der Verkehr freigegeben. (...) Gelb ordnet an: Vor der Kreuzung auf das nächste Zeichen warten. (...) Rot ordnet an: Halt vor der Kreuzung. (...) Ein neben dem Lichtzeichen angebrachtes Schild mit grünem Pfeil auf schwarzem Grund, der sogenannte Grünpfeil, erlaubt zudem das Abbiegen nach rechts bei Rot, sofern es die Verkehrslage ohne Behinderung und Gefährdung erlaubt. Ein Anhalten vor der Kreuzung ist dennoch verpflichtend. Als Ordnungswidrigkeit ist der Rotlichtverstoß einer der gefährlichsten Verstöße. Der Schweregrad hängt dabei davon ab, in welcher Entfernung sich das Fahrzeug befand, während das Signal zu Rot wechselte und mit welcher Geschwindigkeit es sich näherte. Zeichen 209 Rechts Zeichen 214 Geradeaus und rechts Abbildung 3.3: Vorgeschriebene Fahrtrichtung Vorgeschriebene Fahrtrichtung Paragraph 41 behandelt neben den bereits erwähnten Vorfahrtzeichen weitere Vorschriftzeichen, deren Missachtung als Ordnungswidrigkeit geahndet werden können. Zeichen 209 und 214 (siehe Abbildung 3.3) zeigen an, dass nicht alle 49

50 3 GRUNDLAGEN AUS DEM VERKEHRSWESEN Fahrtrichtungen erlaubt sind. Die Pfeilrichtungen weisen auf die Fahrtrichtungen hin, in die abgebogen werden darf. Andere Fahrtrichtungen können dem Verkehr durch analoge Verkehrszeichen vorgeschrieben werden. Zeichen 297 (siehe Abbildung 3.4) zeichnet sich durch einen weißen Richtungspfeil auf dem Fahrstreifen einer Fahrbahn aus. Sind die Fahrstreifen durch Leitlinien (gestrichelte Linie) oder Fahrstreifenbegrenzungen (durchgezogene Linie) getrennt, darf ein Fahrzeug nur in die Richtung abbiegen, die durch den Pfeil auf seinem ausgewählten Fahrstreifen vorgeschrieben ist. Ein Pfeil zieht demnach dieselben Pflichten mit sich wie die Schilder der vorgeschriebenen Fahrtrichtung. Abbildung 3.4: Zeichen Richtungspfeil Abschließend soll darauf hingewiesen werden, dass die Gültigkeit von Verkehrsregeln von den vorhandenen Zeichen und Verkehrseinrichtungen abhängig ist. Dies betrifft insbesondere die Vorfahrt- und Vorrangregeln. Um die Beziehungen der einzelnen Regeln untereinander zu verdeutlichen, gibt die folgende Tabelle eine Übersicht über die Gültigkeit dieser Regeln Zeichen von Polizeibeamten 2 37 Lichtzeichenanlage 3 41,Abs. 2 b) Vorfahrt gewähren!, Halt! Vorfahrt gewähren 4 8, Abs. 1 Rechts-vor-Links Tabelle 3.1: Regeln zur Einfahrt in die Kreuzung 50

51 Kapitel 4 Grundlagen der Simulation Die Simulation ist mittlerweile in verschiedenen Disziplinen ein bedeutendes Mittel zur Beschreibung des Verhaltens verschiedener Objekte und Sachverhalte, um diese besser verstehen zu können. Dies wird erreicht durch die Beobachtung des Verhaltens in Bezug auf vorgenommene Änderungen. Nachfolgend soll in Unterkapitel 4.1 auf die einer Simulation zugrunde liegenden Simulationsmodelle eingegangen werden. Unterkapitel 4.2 gibt einen Überblick über die diskrete Ereignissimulation. Die Multiagentensimulation als Verfeinerung der diskreten Ereignissimulation wird in Unterkapitel 4.3 eingeführt. Unterkapitel 4.4 geht auf Verkehrssimulationsmodelle ein. 4.1 Simulationsmodelle Die Simulation ist ein Werkzeug, um das Experimentieren an bestimmten Ausschnitten der Realität zu umgehen. Diese Ausschnitte, die sich aus einer Menge von Objekten und die unter diesen Objekten bestehenden Beziehungen zusammensetzen, werden als System bezeichnet. Das zu einem gegebenen Zeitpunkt vorhandene System nennt man den Zustand des Systems. Um die Komplexität des betrachteten Systems zu bewältigen, wird zur Vereinfachung der Realität ein Modell als Repräsentation des Systems gebildet (siehe Abbildung 4.1). Modelle können in physikalische und mathematische Modelle unterteilt werden. Ein Beispiel für ein physikalisches Modell ist eine Modelleisenbahn. Solche Modelle sind jedoch für eine wissenschaftliche Analyse eines Systems meistens nicht von Interesse. Bei einem mathematischen Modell wird hingegen das System durch eine Menge logischer und mathematischer Beziehungen beschrieben. Sobald man das mathematische Modell aufgebaut hat, wird untersucht, inwiefern dies das Verhalten des Systems erfüllt und gegebenfalls ergänzt. Schließlich gibt es zwei Möglichkeiten, das System zu untersuchen. Wenn es sich um ein einfaches Modell handelt, ist es möglich, mittels seiner Beziehungen und Größen eine exakte Beschreibung zu schaffen. Diese Analyse mithilfe auflösbarer Formeln wird analytische Lösung genannt. Ist das System allerdings komplex, wie es bei den realen Systemen oft der Fall ist, ist sein Modell auch komplex. Dies schließt 51

52 4 GRUNDLAGEN DER SIMULATION System Mit dem System selbst experimentieren Mit Systemmodell experimentieren Physikalisches Modell Mathematisches Modell Analytische Lösung Simulation Abbildung 4.1: Methoden zur Untersuchung eines Systems (nach [LK00]) jede analytische Lösung aus. In diesem Fall muss das Modell mithilfe einer Simulation untersucht werden. In diesem Sinne lässt sich eine Simulation als Nachahmung realer Prozesse mittels Computern auf der Grundlage mathematischer Modelle definieren [KN98]. Simulationsmodelle sind spezielle Modelle, die zu Simulationszwecken konstruiert werden, und lassen sich auf verschiedene Weise klassifizieren. Sie können statisch oder dynamisch, stochastisch oder deterministisch, kontinuierlich oder diskret sein. Statische vs. dynamische Simulationsmodelle Ein Simulationsmodell wird als statisch bezeichnet, wenn es für ein System als Momentaufnahme gilt, d.h. keine Zustandsänderung im Zeitablauf vorliegt. Auch wenn die Zeit für das System nicht relevant ist, spricht man von einem statischen Modell. Ein System, das sich mit der Zeit verändern kann, wird dynamisch genannt. Bei der Abstraktion dieser Zustandsänderung durch ein Simulationsmodell spricht man von einem dynamischen Simulationsmodell. Deterministische vs. stochastische Simulationsmodelle Deterministische Simulationsmodelle sind Modelle, die keine probabilistischen bzw. stochastischen Größen enthalten. Ein Differentialgleichungssystem für die Beschreibung einer chemischen Reaktion kann z.b. als solches Modell gelten. Die Ausgabe ist bei diesem Modell festgelegt, sobald die Eingaben und ihre Abhängigkeiten feststehen. Im Gegensatz dazu geben stochastische Simulationsmodelle randomisierte Ergebnisse aus. 52

53 4.2 Diskrete Ereignissimulation Kontinuierliche vs. diskrete Simulationsmodelle Kontinuierliche Systeme sind Systeme, deren Zustände sich kontinuierlich mit der Zeit ändern. Im Gegensatz dazu ändern sich die Zustände der diskreten Systeme punktweise in der Zeit. Analog werden kontinuierliche bzw. diskrete Simulationsmodelle definiert. Die Entscheidung für das eine oder andere Modell ist unabhängig von der Natur des Systems. Das hängt alleine vom Ziel des Modells ab. Wird z.b. die Bewegung von Fahrzeugen modelliert, dann ist es entscheidend zu wissen, ob die Bewegung einzelner Fahrzeuge oder die gesamte Bewegung für das Modell wichtig ist. Dies kann die Entscheidung beeinflussen, ob diskret oder kontinuierlich gearbeitet wird. 4.2 Diskrete Ereignissimulation Die diskrete Ereignissimulation beschäftigt sich mit der Modellierung dynamischer Systeme, die ihre Zustände im Laufe der Zeit ändern. Die Zeitpunkte der Systemänderung entsprechen den Zeitpunkten, in denen die Ereignisse ausgelöst werden. Ein Ereignis ist daher ein zeitliches Vorkommnis, das den Zustand des Systems zur Veränderung bringen kann. Zwischen zwei Ereignissen bleibt der Systemzustand unverändert. Kontrolle des Zeitverlaufs Wegen der dynamischen Natur der betrachteten Systeme bei der diskreten Ereignissimulation ist es notwendig, einen Mechanismus für die Zustandsaufnahmen während der Simulation zu haben. Eine Variable, die die aktuelle Zeit ausdrückt, wird als Simulationsuhr (Clock) bezeichnet. Die Zeiteinheit bei den Simulationen muss nicht unbedingt festgelegt werden. Es gibt zwei Ansätze für das Inkrementieren der Simulationsuhr: next-event time advance und fixed-increment time advance. Bei dem ersten Ansatz wird die Uhr erst inkrementiert, sobald ein Ereignis ausgelöst wird. Dies hat zur Folge, dass die Abstände zwischen dem Vorkommen von Ereignissen nicht unbedingt gleich sind. Bei dem zweiten Ansatz wird die Uhr in regelmäßigen Abständen inkrementiert, unabhängig davon, ob ein Ereignis eingetreten ist oder nicht. Funktionsweise eines diskreten Ereignissimulationsmodells Alle diskreten Ereignissimulationsmodelle verfügen über eine Menge gemeinsamer Komponenten. Trotzdem weichen die einzelnen Modelle minimal voneinander ab, u.a. abhängig davon, wie sie die Simulationsuhr implementiert haben. Im Folgenden wird ein typischer Verlauf einer diskreten Ereignissimulation und seiner beteiligten Komponenten vorgestellt (siehe Abbildung 4.2). Die gesamte Kontrolle über den Simulationsprozess übernimmt das Hauptprogramm. Zu Beginn ist es Aufgabe einer Intitialisierungsprozedur, das Modell zum Zeitpunkt 0 zu initialisieren. Dabei wird eine Variable für die Ausgabe der aktuellen Simula- 53

54 4 GRUNDLAGEN DER SIMULATION Start Initialisierungsprozedur Hauptprogramm Timing-Prozedur Initialisieren der Ereignisliste Zeit = 0 Initialisierungsprozedur aufrufen Timing- und Ereignis-Prozedur wiederholen Nächstes Ereignis Ereignisprozedur Systemzustand aktualisieren und zukünftige Ereignisse generieren Bibliotheksfunktionen Zufallszahlen erzeugen Abbruch der Simulation? Nein Berichtsgenerator Ja Statistiken und Ergebnisbericht Stopp Abbildung 4.2: Funktionsweise eines Ereignissimulators (nach [LK00]) tionszeit, die Simulationsuhr, auf 0 gesetzt. Außerdem benötigt der Simulationsvorgang eine Ereignisliste, die die abzuarbeitenden Ereignisse mit Zeitstempel enthält. Mindestens ein Ereignis muss von der Intitialisierungsprozedur als initialisierendes Ereignis generiert werden. Des Weiteren ist der Systemzustand zu definieren. Er umfasst die Gesamtheit aller Zustandsvariablen, die für die Beschreibung des Systems im Laufe der Zeit notwendig sind. Für den weiteren Verlauf der Simulation sind zwei Teilprogramme notwendig, welche vom Hauptprogramm wiederholt aufgerufen werden. Zunächst holt eine Timing- Prozedur das nächste Ereignis aus der Ereignisliste und inkrementiert im Fall vom next-event time advance die Simulationsuhr. Anschließend dient eine Ereignisprozedur zur Aktualisierung des Systemzustands als Reaktion auf eingetretene Ereignisse. Zusätzlich generiert sie neue Ereignisse unter Zuhilfenahme von Bibliotheksfunktionen, die die im Modell spezifizierten randomisierten Größen erstellen. Iteriert wird durch das Hauptprogramm über diese zwei Teilprogramme, solange die Simulation noch nicht beendet wurde. Abschließend ist am Ende der Simulation ein Berichtsgenerator für die Berechnung geschätzter Performanzgrößen und Erstellung von Berichten zuständig. 54

55 4.2 Diskrete Ereignissimulation Zellulare Automaten Eine räumliche Diskretisierung kann mithilfe der Theorie zellularer Automaten umgesetzt werden. Zellulare Automaten wurden von John von Neumann im Rahmen seiner Forschung über die Selbstproduktion erfunden [BSL98]. Seitdem finden sie in verschiedenen Disziplinen für die Simulation von raumzeitlichen Systemen Anwendung. Sie zeichnen sich durch eine Diskretisierung des Raumes aus und dienen somit der Modellierung diskretisierter dynamischer Systeme. Formal wird ein zellularer Automat als 4-Tupel (G, N, Z, f) definiert. G ist ein unendliches m-dimensionales Gitter, das regelmäßig in Zellen unterteilt wird. N G n bildet eine Menge von Nachbarn einer Zelle, welche auf unterschiedliche Weise definiert werden kann. Abbildung 4.3 zeigt zwei mögliche Nachbarschaften. Die erste Variante ist die sogenannte Von-Neumann-Nachbarschaft. Hierbei zählen (x,y-1) (x-1,y-1) (x,y-1) (x+1,y-1) (x-1,y) (x,y) (x+1,y) (x-1,y) (x,y) (x+1,y) (x,y+1) (x-1,y+1) (x,y+1) (x+1,y+1) (a) Von-Neumann-Nachbarschaft (b) Moore-Nachbarschaft Abbildung 4.3: Nachbarschaft für 2-dimensionale zellulare Automaten solche Zellen im Gitter als Nachbarn, welche eine gemeinsame Kante mit der betrachteten Zelle haben. Im Sinne dieser Nachbarschaft gelten die Zellen mit den Koordinaten (x - 1,y), (x,y - 1), (x,y + 1), (x + 1,y) als Nachbarn der Zelle mit Koordinate (x,y). Eine andere Definition stellt die sogenannte Moore-Nachbarschaft dar. Zur Menge der Nachbarn einer Zelle gemäß dieser Nachbarschaftsdefinition gehören alle Zellen, die sich mindestens eine gemeinsame Ecke mit dieser Zelle teilen. Dementsprechend ist die Menge der Nachbarn im Sinne der Von-Neumann-Nachbarschaft eine Teilmenge der Nachbarn im Sinne der Moore-Nachbarschaft. Es kommen für eine Zelle (x,y) noch die Zellen mit Koordinaten (x - 1,y - 1), (x - 1,y + 1), (x + 1,y - 1), (x + 1,y + 1) als Nachbarn hinzu. 55

56 4 GRUNDLAGEN DER SIMULATION Ein weiterer Bestandteil eines zellularen Automaten stellt die Zustandsmenge Z dar. Dies ist eine endliche Menge von Zuständen, die eine Zelle annehmen kann. Zu einem gegebenen Zeitpunkt t befindet sich eine Zelle genau in einem Zustand z Z. Schließlich ist f eine Zustandsübergangsfunktion f : Z n Z. Der Zustand zum Zeitpunkt t hängt von den Zuständen der Nachbarzellen zum Zeitpunkt t-1 ab. 4.3 Multiagentensimulation Die zu simulierenden Systeme sind meistens sehr komplex. Innerhalb solcher Systeme agieren unterschiedliche und viele Bestandteile sowohl miteinander als auch mit ihrer Umgebung. Dieses Aktions- und Reaktionsverhalten kann nur schwierig bzw. unmöglich mithilfe klassischer Simulationsmodelle nachgebildet werden. In der Praxis hat sich ein neues Konzept etabliert, welches als eine Verfeinerung der diskreten Ereignissimulation angesehen wird: die Multiagentensimulation. Die Multiagentensimulation stellt eine neue Form zur Untersuchung von Systemen dar. Sie eignet sich insbesondere für komplexe Systeme und ermöglicht das Experimentieren an Multiagentenmodellen, welche die sogenannten Multiagentensysteme beschreiben. Nachfolgend wird auf Multiagentensysteme mit ihren Komponenten und insbesondere auf Agenten als wesentlicher Teil dieser Systeme eingegangen. Multiagentensysteme Multiagentensysteme sind solche Systeme, die aus mehreren eigenständig handelnden Einheiten, sogenannten Agenten, bestehen. Der Agentenbegriff wird im nächsten Abschnitt detailliert eingeführt. Multiagentensysteme zeichnen sich durch eine Menge von Eigenschaften aus. Innerhalb eines Multiagentensystems werden die Daten lokal auf Agentenebene verarbeitet. Die einzelnen Agenten verfügen nur über ein begrenztes Wissen über das Gesamtsystem. Demzufolge gibt es im Idealfall keine zentrale Stelle, die das System kontrollieren muss. Ferner liegt den Multiagentensystemen die Nebenläufigkeit zugrunde, die Agenten führen ihre Berechnungen aus und bereiten ihre Aktionen parallel vor. Agentenbegriff Ein wichtiger Begriff bei der Multiagentensimulation ist der Agent. Eine genaue Definition eines Agenten ist umstritten, es gibt jedoch eine Definition von Wooldridge, die allgemeine Anerkennung gefunden hat: An agent is an encapsulated computer system that is situated in some environment, and that is capable of flexible, autonomous action in that environment in order to meet its design objectives [Jen99]. Aus dieser Definition lassen sich folgende Eigenschaften eines Agenten ableiten. Ein Agent muss zum einen in eine Umgebung eingebettet sein. Die Umgebung eines Agenten besteht aus den anderen Agenten und den Objekten, die auf ihn Einfluss nehmen können. Agenten zeichnen sich weiterhin durch ein reaktives Verhalten aus. 56

57 4.3 Multiagentensimulation Sie können ihre Umgebung wahrnehmen und sind dazu fähig, sie zu verändern, indem sie ihr Verhalten modifizieren. Zusätzlich besitzt ein Agent die Autonomieeigenschaft, d.h. er kontrolliert eigenständig seinen Zustand und sein Verhalten und kann selbst Entscheidungen treffen. Der aktuelle Zustand des Agenten ist lediglich von seinem vorherigen Zustand sowie seiner Umgebung abhängig. Um seine Ziele und Motivationen zu realisieren, kann der Agent entweder ein kooperatives oder ein eigensinniges Verhalten zeigen. Das kooperative Verhalten kann auf unvollständiges Wissen, das der Agent besitzt, zurückgeführt werden. Das bedeutet, dass die Agenten aus Mangel an Wissen zu einer Zusammenarbeit mit den anderen Agenten gezwungen sind. Auf der anderen Seite können die Agenten versuchen, ihre Ziele zu erreichen, indem sie eigensinnig und zielorientiert handeln. Allgemein wird zwischen vier Arten von Agenten unterschieden. Die einfachen reflexbasierten Agenten verfügen über eine Wissensbasis, die aus Situationen, Aktionen und Regeln besteht. Die von Sensoren gelieferten Daten werden analysiert, einer Situation zugeordnet, mithilfe der Regeln zu einer Aktion übersetzt und mit den Effektoren ausgeführt. Die Entscheidung wird nur abhängig von der aktuellen Wahrnehmung getroffen (siehe Abbildung 4.4). Agent Sensoren Wahrnehmung Umgebung Effektoren Handlung Abbildung 4.4: Agent und seine Umgebung Reflexagenten mit internem Zustand hingegen besitzen zusätzlich ein internes Gedächtnis, in dem sie Informationen über die Umwelt speichern und beim Interpretieren darauf Zugriff nehmen können. Zwei Arten von Wissen sind dafür relevant: zum einem, wie die Welt momentan aussieht, zum anderen, welche Folgen die vom Agenten ausgeführten Aktionen haben. Weiterhin sind zielbasierte Agenten zusätzlich mit Wissen über ihre Ziele ausgestattet. Dies ermöglicht ihnen, nach Vergleich mit den Konsequenzen ihrer Aktionen eine Reihe von Aktionen auszuführen, die zur gewünschten Situation führen. Zuletzt sind nützlichkeitsbasierte Agenten in der Lage verschiedene Wege, die zur Zielsituation führen, zu vergleichen. Dies hat zur Folge, dass sie sich für den 57

58 4 GRUNDLAGEN DER SIMULATION! Abbildung 4.5: Reflexagent mit internem Zustand besten Weg oder die nützlichste Situation entscheiden können, um ihr Ziel zu erreichen. Im Folgenden wird auf das Verhalten eines Agenten mit seiner Umgebung am Beispiel eines Reflexagenten mit internem Zustand näher eingegangen, der in dieser Arbeit von Bedeutung ist. Reflexagent mit internem Zustand Wie erwähnt, besitzt ein Reflexagent mit internem Zustand einen internen Speicher, der eine Menge von Zuständen beinhaltet. Der Agent aktualisiert seinen Zustand kontinuierlich, indem er seine Wahrnehmungen mithilfe von Zuständen und Regeln zu Aktionen transformiert (siehe Abbildung 4.5). Sein Wissen besteht in den Informationen, wie sich die Umwelt entwickeln kann und welchen Einfluss die Aktionen des Agenten auf die Umwelt haben. Dieser Ablauf kann durch den folgenden Algorithmus beschrieben werden [PTV]: 1. zustand UPDATE-ZUSTAND[zustand,wahrnehmung] 2. regel REGEL-AUSWAHL[zustand,regelmenge] 3. aktion REGEL-AKTION[regel] 4. zustand UPDATE-ZUSTAND[zustand,aktion] Der Algorithmus zeichnet sich durch vier Phasen aus, welche die Aktualisierung des Agenten bewirken. Die erste Phase ist eine Wahrnehmungsphase. Dabei werden die Werte der Zustandsvariablen gesetzt, die den internen Zustand des Agenten bilden. Mit diesen Werten lässt sich eine Interpretation aus Wahrnehmungen ableiten. In der zweiten Phase wird eine passende Regel aus einer vordefinierten Regelmenge ausgesucht und in der dritten Phase ausgeführt. In der letzten Phase wird der interne Zustand nach der Umsetzung der in Phase 3 ausgewählten Aktion aktualisiert. 58

59 4.4 Verkehrssimulationsmodelle 4.4 Verkehrssimulationsmodelle Im Bereich des Verkehrs wird Simulation intensiv eingesetzt. Die sogenannte Verkehrssimulation kann unterschiedliche Absichten haben. Sie wird beispielsweise zum Austesten verschiedener Szenarien zur Optimierung des Verkehrsablaufs sowie für die Vermeidung von Unfällen oder Staus genutzt. Dank Verkehrssimulationen können die Optimierungsversuche vorher am Modell erprobt werden, bevor sie in der Realität Einsatz finden. Die Folgen von Änderungen der Beschilderungen oder Lichtsignalanlagen sowie Routenumleitungen lassen sich leicht am Modell beobachten. Wie allen Simulationen liegen Verkehrssimulationen Simulationsmodelle zugrunde. Abhängig vom Detaillierungsgrad können Verkehrsmodelle in drei Klassen unterteilt werden: Makro-, Meso- und Mikroskopische Verkehrsmodelle. Abbildung 4.6: Unterteilung von Verkehrsmodellen nach Detaillierungsgrad [PTV] Makroskopische Verkehrsmodelle Bei den makroskopischen Modellen wird statt einer Einheit der Verkehrsstrom als Zusammenfassung einer Menge von Fahrzeugen modelliert. Hierbei verzichtet man auf Details, wie z.b. das Verhalten einzelner Fahrzeuge. Makroskopische Modelle bilden nur durchschnittliche Werte der Belastungsgrößen, wie Geschwindigkeit oder Dichte, ohne Betrachtung des Zeitparameters. Für die Modellierung großer Räume sind solche Modelle sehr gut geeignet, da große Gebiete, Städte sowie ganze Länder wegen dem Rechenaufwand und der großen Datenmenge nur schwer detailliert simuliert werden können. Ein Einsatzgebiet makroskopischer Verkehrsmodelle besteht in der Erstellung von Verkehrsprognosen zur Vorerkennung und Vermeidung kritischer Verkehrsphänomene. Durch eine grobe räumliche sowie zeitliche Auflösung reduziert sich der Rechenaufwand und bleibt unabhängig von der Anzahl der simulierten Fahrzeuge. Interessiert man sich jedoch 59

60 4 GRUNDLAGEN DER SIMULATION für eine genaue Beschreibung spezieller Phänomene der Verkehrsabläufe, ist eine makroskopische Betrachtungsweise nicht ausreichend. Mikroskopische Verkehrsmodelle Ein mikroskopisches Verkehrsmodell liefert eine genauere und detailliertere Beschreibung des Verkehrsablaufs als ein makroskopisches Verkehrsmodell. Dieses Modell ist ein realitätsnahes Modell mit einer genaueren Nachbildung der Topologie des betrachteten Simulationsraums, insbesondere auf Kreuzungsebene. Im Gegensatz zum makroskopischen Modell wird nicht nur der Verkehrsfluss durch Durchschnittswerte, sondern auch das individuelle Verhalten einzelner Fahrer modelliert. Darunter fallen beispielsweise fahrzeugspezifische Geschwindigkeiten und die Interaktion der modellierten Verkehrsteilnehmer mit ihrer Umwelt. Hierbei werden auch Beschilderungen sowie die Steuerung der Lichtsignalanlagen betrachtet. Aufgrund des hohen Detaillierungsgrades basieren viele Verkehrssimulationen auf dem mikroskopischen Modell. Der realitätsgetreue Aspekt ist nicht ohne Kosten zu genießen, da dies zur Komplexität des Modells beiträgt. Mesoskopische Verkehrsmodelle Mesoskopische Verkehrsmodelle stellen ein hybrides Modell dar. Sie sind eine Kombination zwischen den makro- und mikroskopischen Modellen. Hierbei werden zwar einzelne Fahrzeuge modelliert, aber ihre Fortbewegung orientiert sich dennoch an durchschnittlichen Werten. Dieser Ansatz ermöglicht die Betrachtung größerer Simulationsgebiete und ist damit z.b. gut für Verkehrsleitsysteme geeignet. Binäres und Nagel-Schreckenberg-Verkehrsmodell Um die Komplexität der mikroskopischen Verkehrssimulation zu bewältigen, wird stets versucht, die Regeln zur Beschreibung der Bewegung zu reduzieren, ohne jedoch die wesentlichen Aspekte der Bewegung zu ignorieren. Dies wurde bereits 1986 von Ludwig Cremer [Kem06] mithilfe eines Verkehrsmodells vorgestellt. Hierbei wurden die Fahrzeuge als Bits abgebildet. Dieser Ansatz konnte allerdings den stochastischen Aspekt des Verkehrsablaufs nicht betrachten. Dank der zellularen Automaten (siehe Abschnitt 4.2) konnten Nagel und Schreckenberg 1992 [Kem06] ein neues Modell entwerfen, das möglichst viele Aspekte des Verkehrsflusses berücksichtigte. Dieses Modell ist in der Lage, den Bremsvorgang sowie die Geschwindigkeitskontrolle einzelner Fahrzeuge zu simulieren. Es wurde ursprünglich für einspurige Straßen entworfen, ist allerdings später für mehrspurige Verkehrsszenarien weiterentwickelt worden. Dieses Modell ermöglicht eine Echtzeitsimulation selbst für große Simulationsräume. Die Zustandsmenge Z beim Nagel-Schreckenberg-Ansatz ist von der maximalen Geschwindigkeit abhängig (Z = { 1, 0, 1,..., v max }). Die Fahrzeuge können mit einer Geschwindigkeit von 0 bis v max fahren. Nicht besetzte Zellen befinden sich im Zustand 1. 60

61 4.4 Verkehrssimulationsmodelle Der Nagel-Schreckenberg-Algorithmus [Mil] betrachtet hinsichtlich der Geschwindigkeit vier Arten von Regeln: Beschleunigen, Abbremsen, Trödeln und Fahren. Beschleunigen: ist v < v max, dann setze v := v + 1. Abbremsen: ist der Abstand w in Zellen zum Vordermann zu klein, dann setze v = max{0, v 1}. Trödeln: mit einer Wahrscheinlichkeit p setze v = max{0, v 1}. Fahren: jedes Fahrzeug wird um v Zellen in die Fahrtrichtung bewegt. Eine Vereinfachung dieses Modells stellt das sogenannte binäre Modell dar. Die Fahrzeuge sind gemäß des binären Modells entweder fahrend oder wartend. Ist eine Zelle frei, so nimmt sie analog wie beim Nagel-Schreckenberg-Modell den Zustand 1 an. Die Zustandsmenge lautet daher Z = { 1, 0, 1}. 61

62 4 GRUNDLAGEN DER SIMULATION 62

63 Kapitel 5 Entwurf des Systems Software kann man auf zwei Arten herstellen: Entweder macht man sie so klar und einfach, dass sie offensichtlich keine Fehler hat. - Oder man macht sie so kompliziert, dass sie keine offensichtlichen Fehler hat. Der Informatiker C.A.R. Hoare spricht hiermit ein Hauptproblem bei der Entwicklung eines Softwaresystems an. Schleichen sich in der Entwurfsphase Fehler bzw. Unklarheiten ein, so hat dies weitreichende Folgen, die den Erfolg des Systems beeinträchtigen können. Die Qualität einer Softwareentwicklung hängt daher entscheidend von der Entwurfsphase ab. Die Anforderungen an das zu realisierende System werden in Unterkapitel 5.1 dargelegt und spezifiziert. Unterkapitel 5.2 stellt den Datenbankentwurf auf konzeptueller und logischer Ebene dar. 5.1 Anforderungserhebung Dieses Unterkapitel konkretisiert die Anforderungen an das gesamte System. Verwendet wurden Use Cases als Methode für die Anforderungserhebung. Aus dem hierbei entstandenen Use Case-Diagramm lassen sich zwei Teilsysteme herausarbeiten: Simulator und Monitor. In Abschnitt werden die simulatorspezifischen Anforderungen aufgezeigt. Anforderungen an das Monitor-Teilsystem beschreibt Abschnitt Anforderungserhebung Simulator Im Rahmen dieser Diplomarbeit soll ein datenbankgestützter Simulator für Straßenverkehrsszenarien entworfen und implementiert werden. Aus der funktionalen Anforderungserhebung des Simulationssystems können zwei große Ziele ausgelesen werden. Einerseits soll das System als eigenständiges Simulationswerkzeug für den 63

64 5 ENTWURF DES SYSTEMS Straßenverkehr dienen. Andererseits soll es in der Lage sein, mit dem Monitoringsystem zu interagieren. Dabei soll er den Dienst erbringen, kontinuierlich Daten für das Verkehrsüberwachungssystem von Verkehrssündern bereitzustellen. Diese Ziele müssen bei der Erstellung der Use Cases beachtet und in Betracht gezogen werden. Außerdem zu berücksichtigen ist die Interaktion des Systems mit einem externen Benutzer als Bediener einer grafischen Benutzeroberfläche. Der Benutzer ist als einziger Akteur am System beteiligt. Die funktionalen Anforderungen an das System veranschaulicht Abbildung 5.1. Die simulatorzpezifischen Anwendungsfälle sind in Gelb dargestellt. Die roten gestrichelten Linien sollen die Abhängigkeiten zwischen dem Simulator und dem Monitor kennzeichnen. Im Folgenden wird auf die wesentlichen Teile dieser Use Cases eingegangen. Der Use Case Straßentopologie aufbauen beschreibt den Vorgang unmittelbar nach dem Start des SiMo-Systems. Hierbei werden eine Übersichtskarte und lokale Ausschnitte geladen. Die Übersichtskarte zeigt das gesamte Simulationsgebiet an, während sich die lokalen Ausschnitte auf ausgewählte Räume aus diesem Simulationsgebiet fokussieren. Das betrachtete Simulationsgebiet wird durch die Straßen Römerstraße, Augustusring, Graurheindorfer Straße sowie die Autobahnbrücke begrenzt. Der Aufbau der Straßentopologie setzt voraus, dass eine Datenbank im Hintergrund verfügbar ist. In dieser Datenbank müssen die topologischen Daten, die das Straßennetz abbilden, für die Darstellung des Simulationsgebiets vorliegen. Beim Startvorgang ist der Simulator auf den Benutzer angewiesen, der die Simulation initialisieren soll. Genauso soll derselbe Akteur den Simulationsprozess beenden dürfen. Dies beschreibt der Use Case Simulation starten/stoppen. Der Simulator reagiert auf die vom Benutzer ausgeführten Aktionen, indem er entsprechende Ereignisse auslöst. Folglich entstehen eine Menge von Aufgaben, die durch den Use Case Verkehr simulieren beschrieben werden. Daher kann dieser Use Case in drei Use Cases zerlegt und dadurch verfeinert werden. Dieser Zusammenhang wird durch die funktionale Dekomposition include ausgedrückt. Zur Simulation gehört zunächst die Steuerung der Lichtsignalanlagen, die durch den Use Case LSAs steuern repräsentiert wird. Parallel soll der Simulator für die Fortbewegung der Fahrzeuge auf dem Straßennetz sorgen. Die Beschreibung dieser Aufgabe erfolgt durch den Use Case Fahrzeuge fortbewegen, der durch einen weiteren Use Case Verkehrssünder generieren erweitert wird. Dieser beschreibt den Vorgang der Erzeugung von Fahrern, die ordnungswidriges Verhalten aufweisen. Dazu gehören z.b. diejenigen, die Ampeln oder Vorfahrtsregeln missachten. Bei den Simulationen spielt die Simulation der Zeit eine große Rolle, welche hier durch den 64

65 5.1 Anforderungserhebung Use Case Simulationsuhr fortschreiten lassen beschrieben wird. Dadurch lässt sich die zeitliche Abfolge von Fahrzeugpositionen und Bewegungen sowie Ampelzuständen festhalten. Zusammenfassend werden die einzelnen Aspekte des Use Cases Verkehr simulieren in folgender Beschreibung dargelegt: Name des Use Cases: Verkehr simulieren Kurzbeschreibung: Simuliert die Steuerung der LSAs, Simulationsuhr und die Fortbewegung der Fahrzeuge. Akteure: - Anfangsbedingung: 1. Die Übersichtskarte wurde geladen. 2. Der Benutzer hat den Start-Knopf gedrückt. Ereignisfluss: 1. Simulationsuhr starten und fortschreiten lassen. 2. LSA-Steuerung starten und Ampelschaltung regeln. 3. Fahrzeuge generieren und fortbewegen. Endbedingung: Der Benutzer drückt den Stopp-Knopf. Ausnahmen: - Der Benutzer soll bei Bedarf die Möglichkeit haben, verschiedene Parameter der Simulation zu verändern. Einer dieser Parameter ist die Simulationsgeschwindigkeit, welche die minimale Zeitspanne zwischen zwei Zustandsänderungen eines Fahrzeugs festlegt. Der Anwendungsfall Simulationsgeschwindigkeit ändern repräsentiert die Anpassung dieser Größe an die Benutzerwünsche. Weiterhin besteht für den Benutzer noch die Möglichkeit, die Verkehrsdichte zu manipulieren. Die Verkehrsdichte kann durch die Anzahl der Fahrzeuge auf einer Fläche zu einem gegebenen Zeitpunkt definiert werden. Dieser Fall beschreibt der Use Case Verkehrsdichte ändern. Bei Betrachtung des Verkehrsaufkommens in der Realität lässt sich feststellen, dass ein Zusammenhang zwischen Verkehrsdichte und der aktuellen Tageszeit bzw. des jeweiligen Wochentages besteht. So befinden sich zum Beispiel wochentags zu Zeiten des Berufsverkehrs besonders viele Fahrzeuge auf den Straßen. Um die Simulation auch in diesem Sinne realtitätsnah zu gestalten, sollen auf Wunsch des Benutzers Wochentage und Tageszeiten für die Simulation festgelegt werden können und dadurch indirekt eine Veränderung der Vekehrsdichte bewirkt werden. Da diese Festlegung ein Sonderfall der Änderung der Verkehrsdichte darstellt, erweitert der Use Case Wochentag/Tageszeit festlegen den Use Case Verkehrsdichte ändern. Auch die Lichtsignalanlagen richten sich gemäß ihres Signalprogrammes nach diesen Zeiten. Daher ist der Use Case LSA steuern abhängig vom Use Case Wochentag/Tageszeit festlegen. 65

66 5 ENTWURF DES SYSTEMS LSAs steuern <<include>> Simulationsuhr fortschreiten lassen Verkehr simulieren <<include>> <<include>> Fahrzeuge fortbewegen <<extends>> Verkehrssünder generieren Wochentag/Tageszeit festlegen <<extends>> Verkehrsdichte ändern Simulation starten/stoppen Simulationsgeschw. ändern Straßentopologie aufbauen Ausschnitte laden <<include>> <<include>> Übersichtskarte laden Simulation abspielen Kreuzung designen Benutzer Kreuzungsbereich beobachten <<include>> <<include>> <<extends>> Signalgeber zuordnen <<include>> Verkehrszeichen zuordnen Regelverstoß melden LSA-Phasen definieren Szenario erstellen Regelverstoß loggen <<include>> Signalisierungszustand festlegen <<include>> Fahrzeug setzen Regelverstoß abspielen Abbildung 5.1: Use-Case Entwurf 66

67 5.1 Anforderungserhebung Anforderungserhebung Monitor Der Entwurf und die Implementierung eines datenbankgestützten Monitors zur Überwachung von Verkehrsregelverstößen stellt den zweiten Teil dieser Diplomarbeit dar. Bei der Anforderungserhebung des Monitor-Teilsystems lässt sich auch hier der Akteur Benutzer identifizieren, der über ein GUI mit dem System interagieren kann. In Abbildung 5.1 sind die monitorspezifischen Use Cases mit blauer Farbe unterlegt. Die dadurch repräsentierten Anforderungen an das Teilsystem werden nachfolgend im Detail beschrieben. Die eigentliche Funktionalität des Monitor-Teilsystems liegt in der Auswertung der simulierten Daten durch den Monitor, während sich der simulierte Verkehr auf dem GUI beobachten lässt. Die zu überwachenden Verkehrsteilnehmer sollen sich in dieser Arbeit auf die Fahrer von Kleinkraftfahrzeugen beschränken, welche vom Simulator erzeugt werden. In regelmäßigen Abständen soll ihr Verhalten hinsichtlich Ordnungswidrigkeiten überprüft werden, das sich durch die Eigenschaften und Fahrzeugbewegungen der Fahrzeuge ausdrückt. Wie bereits in Kapitel 1 erwähnt, beschränkt sich das Monitoring auf Kreuzungsbereiche. Der diese Überprüfung betreffende Use Case Kreuzungsbereich beobachten basiert auf den aktuell erzeugten Simulationsdaten und ist daher abhängig vom Simulationsprozess des Simulators. Die folgende textuelle Beschreibung erläutert den Use Case Kreuzungsbereich beobachten im Detail: Name des Use Cases: Kreuzungsbereich beobachten Kurzbeschreibung: Die vom Simulator gelieferten Daten werden hinsichtlich Ordnungswidrigkeiten bezüglich der StVO überprüft. Akteure: - Anfangsbedingung: Die Simulation ist gestartet (Datenquelle ist entweder der Simulator oder selbst erstellte Szenarien) und liefert Daten. Ereignisfluss: 1. Die Fahrzeugbewegungen werden im Kreuzungsbereich in Echtzeit hinsichtlich möglicher Regelverstöße überprüft. 2. Zu den zu überprüfenden Ordnungswidrigkeiten gehören: - Vorfahrtsverletzung - Rotlichtverstoß - Einfahrt in Straße entgegen vorgeschriebener Fahrtrichtung - Einfahrt in Kreuzung trotz stockendem Verkehr - Falsches Setzen des Fahrtrichtungsanzeigers Endbedingung: - Ausnahmen: - 67

68 5 ENTWURF DES SYSTEMS Begeht ein Verkehrsteilnehmer eine Ordnungswidrigkeit und wird diese erkannt, meldet das System unmittelbar diesen Regelverstoß. Das Melden eines Regelverstoßes gehört zur Überwachung von Regelverstößen, jedoch ist der Use Case zur Beobachtung auch ohne den Use Case Regelverstoß melden ausführbar. Da er somit einen Sonderfall darstellt, steht der Use Case Regelverstoß melden in einer Erweiterungsbeziehung zu dem Use Case Kreuzungsbereich beobachten. In Fall eines erkannten Regelverstoßes ist eine weitere Aufgabe des Monitors, den Regelverstoß zu loggen, d.h. persistent in einer Datenbank zu speichern. Der Use Case Regelverstoß loggen ist abhängig vom Melden eines Regelverstoßes. Eine weitere wichtige funktionale Anforderung stellt das wiederholte Ansehen erkannter Regelverstöße dar. Diese Aktivität wird durch den Use Case Regelverstoß abspielen repräsentiert und kann vom Benutzer initiiert werden. Abgespielt werden können jedoch nur Verkehrssituationen, die vom Monitor geloggt wurden. Daher besteht eine Abhängigkeit zwischen den Use Cases Regelverstoß abspielen und Regelverstoß loggen. Die gewünschte Unabhängigkeit vom Simulator erfordert, dass es dem Benutzer des Systems möglich ist, eigene Verkehrsszenarien auf einer Kreuzung zu erstellen. Die dadurch aufgezeichneten Daten können dann ebenso wie die simulierten Daten des Simulators als Input für die Überwachung von Regelverstößen dienen. Diese funktionale Anforderung repräsentiert der Use Case Szenario erstellen, in welchem zwei Arbeitsabläufe integriert sind. Um Fahrzeugbewegungen zu konstruieren, werden zum einen die Positionen beteiligter Fahrzeuge sowie ihre Fahrtrichtung und Fahrtrichtungsanzeiger Zeitschritt für Zeitschritt festgelegt. Bei Existenz einer Lichtsignalanlage ist es weiterhin notwendig, den Signalisierungszustand der Signalgeber im Verlauf der Zeit zu definieren. Für die Benutzung des GUIs wird davon ausgegangen, dass topologische Daten über die Straßen eines Verkehrsgebietes bereits in einer Datenbank hinterlegt sind. Darauf aufbauend betrifft eine der funktionalen Anforderungen das Einrichten einer Kreuzung, was durch den Use Case Kreuzung designen repräsentiert wird. Wie in dem Use Case-Diagramm in Abbildung 5.1 zu sehen ist, enthält dieser Use Case zum einen das Zuordnen von Verkehrszeichen und Signalgebern. Zum anderen gehört zum Design einer Kreuzung das Definieren der zu den Signalgebern gehörigen LSA-Phasen. Letzteres bedeutet, dass die Länge der einzelnen Phasen sowie die Signalbilder der Signalgeber eingestellt werden können. Zusammenfassend werden folgende Anforderungen festgelegt: 68

69 5.2 Datenbankentwurf Name des Use Cases: Kreuzung designen Kurzbeschreibung: ermöglicht das Design einer Kreuzung zum Abspeichern in einer Datenbank Akteure: Benutzer Anfangsbedingung: In der Datenbank ist bereits die Topologie der Kreuzungen gespeichert. Wenn das Design bisher noch nicht festgelegt wurde, entspricht die Kreuzung einem Rechts-vor-Links-Knoten. Ereignisfluss: 1. Kreuzung auswählen, die bearbeitet werden soll 2. Signalgeber zuordnen 3. Verkehrszeichen zuordnen 4. Falls Signalgeber zugeordnet wurden, Anzahl und Länge der Phasen sowie Signalbild der einzelnen Signalgeber für jede Phase einstellen. 5. Die Konfiguration der Kreuzung speichern Endbedingung: Die Konfiguration wurde gespeichert. Ausnahmen: Datenbankentwurf Die datenbankgestützte Natur des SiMo -Systems erfordert den Entwurf einer Datenbank, welche eine gemeinsame Grundlage für beide Teilsysteme bildet. Deswegen war eine gemeinsame Arbeit vom Entwurf bis hin zur Datenerhebung erforderlich. Gemäß der beim Datenbankentwurf zu durchlaufenden Phasen beschreibt Abschnitt zunächst den konzeptuellen Entwurf. Anschließend wird die logische Umsetzung in Abschnitt erläutert Konzeptueller Entwurf Wie bereits erwähnt, erfordert der Entwurf einer Datenbank zunächst die Abbildung der realen Welt auf eine konzeptuelle Ebene (vgl. Abschnitt 2.1.2). In dieser Arbeit wird dafür das Entity-Relationship-Modell eingesetzt, um Objekte und ihre Beziehungen untereinander zu identifizieren. Zunächst stellt sich jedoch die Frage, wie sich die Straßentopologie für ein Stadtgebiet durch ein Modell abbilden lässt. Darauf aufbauend erläutert dieser Abschnitt, wie sich die Bestandteile einer Straßenkarte durch Entities beschreiben lassen und welche Zusammenhänge zwischen diesen bestehen. Die Topologie der Straßen baut grundlegend auf der Theorie der zellularen Automaten auf. Einzelne Zellen stellen somit die Grundbausteine des Straßennetzes dar, durch deren Aneinanderreihung die Wege modelliert werden. In dieser Arbeit 69

70 5 ENTWURF DES SYSTEMS soll ein Ausschnitt des Bonn-Nord-Gebietes näher betrachtet werden, welcher somit durch Aufteilung in einzelne Zellen zu diskretisieren ist. Zur Vereinfachung wird hierbei angenommen, dass Straßen nur in einem rechten Winkel aufeinander treffen können. Dies erleichertert die Darstellung durch rechteckige Zellen auf dem GUI und ist deshalb möglich, weil es das Ziel der Arbeit in keiner Weise beeinflusst. Ansonsten ist das betrachtete Stadtgebiet in seinen Proportionen und seiner Beschilderung möglichst realitätsgetreu zu modellieren. Stadtpläne sowie eine Bestandsaufnahme vor Ort haben dies für das im Rahmen dieser Arbeit entworfene System ermöglicht. y x Abbildung 5.2: Straßentopologie Abbildung 5.2 veranschaulicht die gemeinsam für die Simulation und das Monitoring verwendete Modellierung der Straßentopologie. Die in der Abbildung grau dargestellten Zellen, aus denen die Straßen zusammengesetzt sind, werden dabei durch eine X- und eine Y-Koordinate eindeutig identifiziert und einer bestimmten Position zugeordnet. Das gesamte Gebiet ist damit logisch in ein gleichmäßiges Gitter eingeteilt, dessen obere linke Ecke mit der Koordinate (1,1) ausgezeichnet ist. Aus diesen absoluten Angaben lässt sich weiterhin die Von-Neumann-Nachbarschaft der Zellen ableiten: Eine Zelle ist Nachbar einer anderen Zelle, sofern sich diese entweder in ihrer X- oder aber in ihrer Y-Koordinate um 1 unterscheiden. Die Schnittpunkte, in denen die verschiedenen Straßen zusammentreffen, werden als Knoten bezeichnet. Den Begrifflichkeiten aus Unterkapitel 3.1 entsprechend können dies sowohl Kreuzungen als auch Einmündungen sein. Eine schematische Darstellung eines Straßenknotens zeigt Abbildung 5.3. Sie ist aus einzelnen Zellen aufgebaut, die vier aufeinandertreffende Straßen ergeben. Eine Straße besitzt für jede Fahrtrichtung jeweils eine Spur, eine Erweiterung auf mehrere Fahrstreifen ist analog möglich. Um den Zellen in Kreuzungsnähe eine Struktur geben zu können, werden sie in unterschiedliche Typen aufgeteilt. Die gestreiften Zellen in der Mitte der Kreuzung stellen den eigentlichen Kreuzungsbereich dar und werden als Knotenzellen bezeichnet. Weiterhin lassen sich die direkt anliegenden Zellen in Knotenzufahrten und Knotenabfahrten unterscheiden. Über die Knotenzufahrten - in der Abbildung 70

71 5.2 Datenbankentwurf hellgrau gefärbt - befahren die Fahrzeuge den Kreuzungsbereich. Die dunkelgrauen Knotenabfahrten charakterisieren diejenigen Zellen, die zum Verlassen der Kreuzung dienen. Alle restlichen, außerhalb liegenden Zellen werden den Straßen zugeordnet und gehören der Kategorie Straßenzelle an. Knotenzelle Knotenabfahrt Knotenzufahrt Straßenzelle Abbildung 5.3: Schematische Darstellung eines Straßenknotens Abbildung 5.3 veranschaulicht weiterhin die erlaubten Fahrzeugbewegungen innerhalb eines Knotens, welche durch gerichtete Pfeile angedeutet werden. Die gestreiften Knotenzellen des Kreuzungsbereichs nehmen eine besondere Stellung ein, da sie aus zwei Richtungen befahren und auch in zwei Richtungen wieder verlassen werden können. Fahrzeugbewegungen, die entgegen der Vorschriften verlaufen, werden hierbei nicht einbezogen. Für die konzeptuelle Modellierung lässt sich damit festhalten, dass das Straßennetz grob als Graph zu verstehen ist, der aus Knoten und deren Verbindungen zueinander aufgebaut ist. Die Knoten repräsentieren die Kreuzungen oder Einmündungen, die durch Straßen miteinander verbunden sind. Abbildung 5.4 zeigt das Entity-Relationship-Diagramm, welches gemeinschaftlich für Simulator und Monitor entstanden ist. Aus der Aufteilung des Straßennetzes in einzelne Zellen lässt sich zunächst der Entity-Typ Zelle als zentrales Element ableiten. Eine Zelle ist bereits durch seine Attribute zu X- und Y-Koordinate eindeutig identifizierbar. Ein Zugriff auf Aus GUI-technischen Gründen führt ein zweiteiliger Schlüssel jedoch zu Problemen (siehe Abschnitt 7.1.1). Daher existiert zusätzlich das Schlüsselattribut zellen id. Eine Differenzierung der Zellen lässt sich gemäß dem zuvor beschriebenen Straßenmodell durch Untertypen mit einem is a-relationship- Typ festhalten, sodass weiterhin die Entity-Typen Straßenzelle, Knotenzelle, Knotenabfahrt und Knotenzufahrt existieren. 71

72 5 ENTWURF DES SYSTEMS Fahrzeug 1 steht_auf 1 N Knoten 1 N is_part_of Zelle ist_nachbar_von is_a M Straßenzelle Knotenzelle Knotenzufahrt Knotenabfahrt 1 M N rechte_zufahrt M zugeordnet_2 1 zugeordnet_1 N N linke_zufahrt M Signalgeber Verkehrszeichen N Zufahrt_gegenüber M N is_part_of 1 Lichtsignalanlage N zeigt_an N rechte_abfahrt M 1 hat M N linke_abfahrt M N Phase N Abfahrt_gegenüber M N dauert M Zeitintervall Abbildung 5.4: Entity-Relationship-Diagramm 72

73 5.2 Datenbankentwurf Die Zellen lassen sich ferner einem Knoten zuordnen. Daraus ist der Entity-Typ Knoten ableitbar, dessen Enitities durch die jeweilige knoten id identifiziert werden. Um dem Benutzer die Unterscheidung der Knoten in der Interaktion mit dem System zu erleichtern, sollen sie zusätzlich mit einer textuellen Bezeichnung versehen werden. Der Knotenbegriff soll erweitert werden, indem einem Knoten auch Straßenzellen zugeordnet werden können. Dies ist für den späteren Einsatz von Bedeutung, da durch einen Knoten ein gesamter Überwachungsbereich definiert wird, zu dem nicht nur Knotenzellen, Knotenabfahrten und Knotenzufahrten gehören müssen. Die Zuordnung von Zellen zu einem Knoten lässt sich durch einen Relationship-Typ is part of mit einer 1:N-Kardinalität abbilden. Um die Fahrzeugbewegungen innerhalb eines Knotens herleiten und Verkehrsregeln in SQL formulieren zu können, ist es weiterhin wichtig, zu definieren, wie Knotenabfahrten und Knotenzufahrten zueinander in Beziehung stehen. Zum einen werden jeder Knotenzufahrt beliebig viele Knotenzufahrten zugeordnet, die auf einer Straße rechts, links oder gegenüber von ihr liegen. Diese insbesondere für Vorfahrtregeln relevanten Informationen repräsentieren die Relationship-Typen rechte Zufahrt, linke Zufahrt und Zufahrt gegenüber. Weiterhin ist die relative Lage der Abfahrten bezüglich der Zufahrten erforderlich, mit denen sich die Information abfragen lässt, welche Richtung ein Fahrzeug auf dem Knoten verfolgt. Hierfür existieren ebenfalls drei Relationship-Typen: rechte Abfahrt, linke Abfahrt und Abfahrt gegenüber. Aufgrund der Unterstützung mehrerer Fahrstreifen für eine Fahrtrichtung kann einer Zufahrt mehr als eine Zu- bzw. Abfahrt zugeordnet werden, die links, rechts oder gegenüber von ihr liegt. Daher bestehen zwischen den Zellen jeweils N:M-Beziehungen. Weiterhin ist das Wissen über die Zellennachbarn und ihre Lage zueinander von großer Bedeutung, um die unmittelbare Umgebung eines Fahrzeugs erkunden zu können. Aus diesem Grund existiert der Relationship-Typ ist Nachbar von, dessen Relationships eine Von-Neumann-Nachbarschaft zugrunde liegt. An dieser Nachbarschaft orientiert bezeichnet ein Attribut lage zusätzlich, ob die Nachbarzelle vor, hinter, links oder rechts einer Zelle liegt. Betrachtet werden sollen hier im Vergleich zu Abbildung 5.3 nur diejenigen Nachbarn, die gemäß verkehrsrechtlichen Vorschriften zu erlaubten Fahrzeugbewegungen führen. Für die Knotenzellen im Kreuzungsbereich, denen meist mehr als ein Nachbar zugeordnet werden kann, ist eine weitere Differenzierung erforderlich. Daher wird ein Attribut fahrtrichtung eingeführt, welches die Lage des Nachbarn von der Ausrichtung des Fahrzeugs auf dieser Zelle abhängig macht. Für die Nachbildung des regelgerechten Straßenverkehrs sind des Weiteren Verkehrsschilder und Ampeln zu modellieren. Die Instanzen des Entity-Typs Verkehrszeichen sollen alle für dieses System möglichen Arten von Verkehrsschildern wie z.b. Vorfahrt gewähren! zusammenfassen. Charakteristisch für diesen Entity-Typ ist die StVO-Zeichen-Nummer. Da dessen Wertebereich jedoch nicht numerisch ist, dies 73

74 5 ENTWURF DES SYSTEMS aber für die Identifikation im Gegensatz zu Zeichenketten besser zu handhaben ist, besitzt der Entity-Typ das Schlüsselattribut zeichen id. Im Sinne einer Erweiterung muss auch bedacht werden, dass manche Verkehrszeichen, die in dem hier betrachteten Simulationsgebiet nicht vorhanden sind, über keine StVO-Zeichen-Nummer verfügen. Auch aus diesem Grund wird ein künstlicher Schlüssel benötigt. Durch den Relationship-Typ zugeordnet 2 wird schließlich ein Verkehrszeichen mit seinen zugeordneten Knotenzufahrten verbunden. Einer Knotenzufahrt lassen sich beliebig viele Verkehrszeichen zuordnen, sodass eine N:M-Beziehung gerechtfertigt ist. Einer Knotenzufahrt lässt sich ferner ein Signalgeber zuordnen. Der Entity-Typ Signalgeber umfasst daher alle im Verkehrsgebiet existierenden Signalgeber, welche mit den Entities des Entity-Typs Zelle eine 1:1-Beziehung eingehen. Genauer bedeutet dies, dass jedem Signalgeber genau eine Knotenzufahrt zugeordnet werden darf. Es stellt sich die Frage, ob sich die Relationship-Typen zugeordnet 1 und zugeordnet 2 nicht zusammenfassen ließen und Signalgeber sowie Verkehrsschilder von einem gemeinsamen Obertyp ableitbar sind. Von der konzeptuellen Umsetzung sind diese zwei jedoch sehr unterschiedlich, da im Gegensatz zu Signalgebern nicht jedes an einer Zufahrt aufgestellte Verkehrsschild einzeln aufgeführt wird. Somit sind die zwei Relationship-Typen zur Zellenzuordnung angebracht. Betrachtet man die reale Welt, so lässt sich weiterhin feststellen, dass jeder Signalgeber Teil einer Lichtsignalanlage (LSA) ist, die für die Steuerung der gesamten Kreuzung zuständig ist. Im Entwurf wird dies durch einen is part of -Relationship- Typ modelliert. Ob die LSA in oder außer Betrieb ist, besagt das boolesche Attribut in betrieb. Die Steuerung der LSA erfolgt durch eine Folge verschiedener Phasen. In einem numerischen Attribut phase kann daher während der Simulation festgelegt werden, in welcher Phase des Steuerungsprozesses sich die LSA befindet. Jeder Lichtsignalanlage stehen somit N verschiedene Phasen zur Verfügung, mit denen durch weitere Beziehungen festgelegt wird, wie lange die zugehörigen Signalgeber welches Signalbild anzeigen. Um jede einzelne Phase aufführen zu können, existiert somit der Entity-Typ Phase. Charakteristisch für jede Phase ist demnach die Signalzeit für bestimmte Zeitintervalle. Daher drückt der Relationship-Typ dauert aus, wie lange die jeweiligen Phasen des Signalprogramms dauern. Der Eintrag des zugehörigen Attributs Signalzeit ist abhängig von den Attributwerten tag, uhrzeit anfang und uhrzeit ende des Entity-Typs Zeitintervall, welche zusammen eine Zeitspanne eines Tages definieren. Die simulierte Schaltung der LSA wird letztlich über die Signalgeber sichtbar. Sie können die Farben Rot oder Grün anzeigen. Die Signalfarbe Orange ist aufgrund der Zeit-Diskretisierung nicht zwingend erforderlich und wurde der Einfachheit halber nicht betrachtet. Der Relationship-Typ zeigt an modelliert somit die Abbildung eines Signalgebers und einer zur LSA gehörenden Phase auf das entsprechende Signalbild. 74

75 5.2 Datenbankentwurf Wichtigster Bestandteil der Simulation stellen die Fahrzeuge dar. Sie werden durch den Entity-Typ Fahrzeug repräsentiert. Um die Fahrzeuge eindeutig identifizieren zu können, dient das Attribut fahrzeug id zur Unterscheidung einzelner Fahrzeuge. Das Attribut blinker gibt durch seine möglichen Werte links, rechts oder geradeaus an, welche gewünschte Abbiegerichtung an einem Knoten durch den Fahrtrichtungsanzeiger angezeigt wird. Eine weitere charakteristische Eigenschaft der Fahrzeuge stellt die Geschwindigkeit dar. Der Simulation in dieser Arbeit liegt ein binäres Modell zugrunde, was bedeutet, dass die Geschwindigkeit der Fahrzeuge nur zwei Werte, 0 oder 1, annehmen kann. Um die Erweiterbarkeit des Systems zu unterstützen, ist dennoch das Attribut geschwindigkeit vorgesehen, das die Geschwindigkeitswerte für eventuell andere Modelle angeben soll. Für die Fortbewegung der Fahrzeuge und deren angemessene Darstellung auf dem GUI wird weiterhin die Fahrtrichtung eines Fahrzeugs benötigt. Die Ausrichtung ist durch die Werte Sued, Nord, West und Ost beschrieben, deren Bedeutung äquivalent zu oben, unten, links und rechts ist. Sie stimmen daher nicht exakt mit der tatsächlichen Himmelsrichtung des Stadtgebietes überein, wurden jedoch als Bezeichnung gewählt, um eine Verwechslung mit den Blinker-Werten zu vermeiden und dem Benutzer dennoch eine intuitive Vorstellung über die Ausrichtung zu geben. Die momentane Position eines Fahrzeugs innerhalb des Verkehrsgebietes drückt der Relationship-Typ steht auf aus. Jedes Fahrzeug ist genau einer Zelle zugeordnet. Die an der Relationship beteiligte Zelle ist die vom Fahrzeug zuletzt besuchte Zelle und dient damit der Visualisierung der Fahrzeuge auf dem GUI Logischer Entwurf Nach dem konzeptuellen Entwurf folgt die Umsetzung des Entity-Relationship-Diagramms in das relationale Schema. Grob lässt sich das Datenbankschema des Systems in Tabellen für die Topologie und Tabellen für die Simulation unterteilen, die im Folgenden beschrieben werden. Zentraler Bestandteil der Straßentopologie stellt der Entity-Typ Zelle dar, der durch vier Unterklassen spezialisiert wurde. Wie in Abschnitt (relationales Modell) erläutert, kann eine Vererbung auf drei unterschiedliche Weisen umgesetzt werden. Zu analysieren ist hierbei, welche Informationen über die Zellen in der späteren Anwendung am häufigsten benötigt werden. Im Fall dieses Systems spielt die Unterscheidung der Zellen eine besondere Rolle. Die einzelnen Zellentypen werden wesentlich häufiger abgefragt als die allgemeinere Information der Zellen. Dies spricht dafür, das die Entity-Typen Knotenzufahrt, Knotenabfahrt, Knotenzelle und Strassenzelle auf eigene Tabellen abgebildet werden, die die geerbten Attribute des Obertyps Zelle aufnehmen: knotenzelle(zellen_id, x, y, knoten_id) knotenzufahrt(zellen_id, x, y, knoten_id) knotenabfahrt(zellen_id, x, y, knoten_id) strassenzelle(zellen_id, x, y, knoten_id) 75

76 5 ENTWURF DES SYSTEMS Aufgrund des is part of -Relationship-Typs, der die Beziehung zwischen dem Entity- Typ Knoten und den verschiedenen Entity-Typen der Zellen darstellt, ist das Attribut knoten id zur jeweiligen Zellentabelle herangezogen und als Fremdschlüssel angelegt worden. Die Tabelle zum Obertyp Zelle lässt sich mithilfe einer View zusammenstellen: CREATE VIEW zelle AS ( SELECT zellen_id, x, y, knoten_id FROM knotenabfahrt UNION SELECT zellen_id, x, y, knoten_id FROM knotenzufahrt UNION SELECT zellen_id, x, y, knoten_id FROM knotenzelle UNION SELECT zellen_id, x, y, knoten_id FROM strassenzelle; ) Um sich die wiederkehrende Anfragebearbeitung zu ersparen und damit einen erheblichen Performanzgewinn zu erzielen, ist es aus Effizienzgründen besser, diese View zu materialisieren. Die Nachteile, die solche Views nach sich ziehen können, lassen sich hier aus zwei Gründen relativieren. Zum einen bleibt der Verwaltungsaufwand, den solche Views bei Änderungsoperationen mitbringen, wegen der statischen Natur der Straßentopologie erspart. Die Daten in den vier Tabellen werden nur im Fall einer Erweiterung des Simulationsgebiets modifiziert. Ist die Straßentopologie einmal erfasst, bleibt sie langfristig unverändert. Werden außerdem solche materialisierten Views vom DBMS unterstützt, so ist auch die Änderungspropagierung der Daten sichergestellt. Zum anderen steigt der Speicherplatzbedarf aufgrund der redundanten Daten. Dies kann heutzutage bei ausreichendem Speicherplatz dennoch in Kauf genommen werden, um an Performanz zu gewinnen. Da der Relationship-Typ Ist Nachbar von mit einer N-M-Kardinalität ausgezeichnet ist, wurden diese Informationen auf eine eigene Tabelle abgebildet: nachbarzellen(zellen_id, nachbar_id,lage) In der Spalte lage dieser Tabelle wird durch die Werte V für vorne bzw. R für rechts eingetragen, wie die Nachbarn zu einer Zelle liegen. Linke bzw. hintere Nachbarn müssen nicht explizit gespeichert werden, sondern können durch die Symmetrie- Eigenschaft hergeleitet werden. 76

77 5.2 Datenbankentwurf Der Entity-Typ Knoten wird durch die Tabelle knoten konkretisiert: knoten(knoten_id, vorfahrtregelung,bezeichnung) Die unterschiedlichen Vorfahrtsregelungen werden in der Spalte vorfahrtsregelung abgekürzt folgendermaßen eingetragen: LSA MB LSA OB BK RVL Der Wert LSA MB repräsentiert eine Lichtsignalanlage (LSA) mit Beschilderung. Diese sind solche Knoten, die von einer LSA gesteuert werden und denen zusätzlich Verkehrsschilder zugeordnet sind. Mit LSA OB werden Knoten mit LSA, aber ohne Beschilderung gekennzeichnet. Ein Eintrag BK bezeichnet hingegen Knoten, bei denen der Kreuzungsverkehr lediglich mithilfe von Verkehrsschildern geregelt wird. Gilt allerdings nur die Rechts-vor-links-Regel, so wird dem Attribut vorfahrtsregelung der Wert RVL zugewiesen. Wie in Abschnitt erwähnt wurde, wird mit den N-M-Relationship-Typen rechte Zufahrt, linke Zufahrt, Zufahrt gegenüber, rechte Abfahrt, linke Abfahrt und Abfahrt gegenüber die Beziehung zwischen Zufahrten und Abfahrten zur Gestaltung gebracht. Kardinalitätsbedingt wurden diese Relationship-Typen auf eigene Tabellen abgebildet: rechte_zufahrt(zellen_id_zufahrt, zellen_id_rechtezufahrt) rechte_abfahrt(zellen_id_zufahrt, zellen_id_rechteabfahrt) linke_abfahrt(zellen_id_zufahrt, zellen_id_linkeabfahrt) abfahrt_gegenüber(zellen_id_zufahrt, zellen_id_gegenüber) Die Menge der linken Zufahrten kann aus Symmetriegründen durch eine View mit der Tabelle rechte zufahrt zusammengestellt werden. Ist eine Zufahrt A rechte Zufahrt einer Zufahrt B, dann ist B folglich linke Zufahrt zu A: CREATE VIEW linke_zufahrt AS ( SELECT rz.zellen_id_rechtezufahrt AS zellen_id_zufahrt, rz.zellen_id_zufahrt AS zellen_id_linkezufahrt FROM rechte_zufahrt AS rz; ) Zufahrten gegenüber einer Zufahrt, welche durch den Relationship-Typ Zufahrt gegenüber repräsentiert werden, können per Transitivitätsprinzip definiert werden. Verdeutlicht wird dies durch Abbildung 5.5 a. Die Zufahrt G gegenüber der 77

78 5 ENTWURF DES SYSTEMS G G R R Z Z (a) Kreuzung (b) Einmündung Abbildung 5.5: Bestimmung von Zufahrten gegenüber schwarzen Zelle Z kann in diesem Sinne in zwei Schritten festgelegt werden. Zuerst wird auf ihre rechte Zufahrt R zugegriffen. Dann ist die Zelle G die rechte Zufahrt der Zelle R. Einmündungen stellen hierbei eine Ausnahme dar. Nicht jeder Zufahrt lässt sich eine rechte Zufahrt zuordnen. Veranschaulicht wird dies schematisch durch die Situation in Abbildung 5.5 b. In diesem Fall kann die Zufahrt gegenüber transitiv nur mithilfe der linken Zufahrt analog wie oben bestimmt werden. Die Umsetzung des Relationship-Typs Zufahrt gegenüber kann mithilfe dieser zwei Vorgehensweisen durch folgende Sicht erfolgen: CREATE VIEW zufahrt_gegenüber AS ( SELECT DISTINCT rz.zellen_id_zufahrt, rz1.zellen_id_rechtezufahrt AS zellen_id_gegenüber FROM rechte_zufahrt AS rz INNER JOIN rechte_zufahrt AS rz1 ON rz.zellen_id_rechtezufahrt = rz1.zellen_id_zufahrt UNION SELECT DISTINCT lz.zellen_id_zufahrt, lz1.zellen_id_linkezufahrt AS zellen_id_gegenüber FROM linke_zufahrt AS lz INNER JOIN linke_zufahrt AS lz1 ON lz.zellen_id_linkezufahrt = lz1.zellen_id_zufahrt; ) Für ein in eine Vorfahrtstraße einfahrendes Fahrzeug (schwarze Zelle in Abbildung 5.6) ist es wichtig, die Zufahrten quer zur eigenen Zufahrt (graue Zellen) auf sich 78

79 5.2 Datenbankentwurf nähernde vorfahrtberechtigte Fahrzeuge zu überprüfen. Für die Herleitung dieser Information steht die View zufahrt quer als Vereinigung von rechte zufahrt und linke zufahrt zur Verfügung: CREATE VIEW zufahrt_quer AS ( SELECT rz.zellen_id_zufahrt, rz.zellen_id_rechtezufahrt AS zellen_id_quer FROM rechte_zufahrt AS rz UNION SELECT lz.zellen_id_zufahrt, lz.zellen_id_linkezufahrt AS zellen_id_quer FROM linke_zufahrt AS lz; ) Abbildung 5.6: Zufahrten quer zu einer Zufahrt Die Fahrzeuge und ihre Positionen innerhalb des Simulationsgebietes werden relational auf die Tabelle fahrzeug abgebildet, die den Entity-Typ Fahrzeug darstellt: fahrzeug(fahrzeug_id, zellen_id, blinker, geschwindigkeit, fahrtrichtung) Da die Beziehung steht auf ein 1-1-Relationship-Typ ist, wird der Schlüssel der Zelle als Fremdschlüsselattribut zellen id in der Tabelle fahrzeug angelegt. Die Beziehung wurde nicht in die Tabelle Zelle integriert, da die Positionen die Bewegungen eines 79

80 5 ENTWURF DES SYSTEMS Fahrzeugs ausdrücken und somit als Eigenschaft eines Fahrzeugs zu betrachten sind. Der Entity-Typ Verkehrszeichen sowie der N-M-Relationship-Typ zugeordnet 2 sind auf die folgenden Tabellen abgebildet: verkehrszeichen(zeichen_id, stvo_zeichen_nr, bezeichnung) zeichen_zuordnung(zellen_id, zeichen_id) Da der Entity-Typ Phase an sich keine charakteristischen Eigenschaften trägt, sondern nur im Zusammenhang mit anderen Entity-Typen an Bedeutung gewinnt, ist dafür keine konkrete relationale Umsetzung vorgesehen. Die Phasen sind daher durch eine Durchnummerierung und deren Zuordnung zu einer bestimmten LSA eindeutig festgelegt. Der Relationship-Typ dauert sowie der Entity-Typ Lichtsignalanlage wurden folgendermaßen auf die Tabellen lsa und phasenschaltung abgebildet: lsa(lsa_id, anzahl_phasen, phase, in_betrieb) phasenschaltung(lsa_id, phase, tag, anfang, ende, dauer) Wie bereits erwähnt, besteht jede LSA aus mehreren Signalgebern, die zu den Knotenzufahrten durch Anlegen eines Fremdschlüsselattributes zellen id zugeordnet werden. Analog ordnet das Attribut lsa id dem Signalgeber eine LSA zu. Signalgeber können auch nur für eine bestimmte Fahrtrichtung Gültigkeit haben. Dies wird durch die Einträge links, rechts und 0 des Feldes symbol ausgedrückt: signalgeber(signalgeber_id, symbol, lsa_id, zellen_id) Der binäre Relationship-Typ zeigt an wird relational durch die Tabelle signalbild umgesetzt: signalbild(signalgeber_id, phase, signalbild) + Abbildung 5.7: Von der Realität zum GUI 80

81 5.2 Datenbankentwurf Auf der Grundlage der konzeptuellen und logischen Modellierung lassen sich die Daten zur Beschreibung der Straßentopologie erheben. Abbildung 5.7 zeigt die notwendigen Schritte für den Übergang vom realen Stadtgebiet zu einer angemessenen Darstellung auf dem GUI. Durch Erkundung des zu simulierenden Gebiets Bonn- Nord und mithilfe des zugehörigen Stadtplans entstand eine maßstabsgetreue Abstraktion der Straßen auf Papier. Die Unterteilung von Straßen in Zellen konnte somit auf Datenbankebene übertragen werden. Auf diesen Daten baut das GUI auf. Darauf wird im Detail in den Abschnitten und eingegangen. 81

82 5 ENTWURF DES SYSTEMS 82

83 Kapitel 6 Architektur und Funktionalität Das System lässt sich gemäß des Entwurfs grob in zwei zunächst unabhängig voneinander agierende Subsysteme unterteilen, die dennoch lose miteinander gekoppelt sind: ein Verkehrssimulator und ein Monitor zur Überwachung von Regelverstößen. Die Aufgabe des Verkehrssimulators besteht in der Generierung von Daten, die dem Monitor als Input seiner Überwachungsaufgabe bereit gestellt werden. Unterkapitel 6.1 beschreibt zunächst die Gesamtarchitektur und gibt einen Überblick über die einzelnen Bausteine des Systems. In Unterkapitel 6.2 und Unterkapitel 6.3 werden die jeweiligen Teilsysteme Simulator und Monitor mit ihren zugehörigen Funktionaliäten und ihrer Architektur im Detail vorgestellt. 6.1 Gesamtarchitektur Im Folgenden wird das gesamte System in seiner Architektur beschrieben, während die verschiedenen Komponenten zunächst als Blackbox dargestellt werden. Die einzelnen Subsysteme weisen im Wesentlichen dieselbe Grundstruktur auf und setzen sich dabei letztendlich aus drei Komponenten zusammen. Das Frontend bildet eine Benutzeroberfläche, die zum Visualisieren und Editieren der Verkehrsituationen dient. Im Hintergrund steht ein Datenbankmanagementsystem, welches zur Strukturierung und Verwaltung der Daten eingesetzt wird. Gesteuert wird das jeweilige Subsystem von einem Controller, der intelligent als Manager der Systemprozesse fungiert und eine Schnittstelle zwischen Datenbank und GUI zu Verfügung stellt. Abbildung 6.1 veranschaulicht das Zusammenspiel der beiden Subsysteme und ihrer Komponenten. Hier lässt sich erkennen, dass die Datenbank für verschiedene Systembereiche zuständig ist. Als Grundlage für die Simulation ist eine Abstraktion der Straßentopologie nötig. Diese wird aufgrund des datenbankbasierten Ansatzes dieser Diplomarbeit auf Datenbankebene umgesetzt (vgl. Kap ). Auf die Topologie- Datenbank greift sowohl der Monitor als auch der Simulator zu. Der Simulator legt seine erstellten Ereignisse in der Simulationsdatenbank ab. Der Monitor hat damit die Möglichkeit, diese in Echtzeit abzufragen und für seine interne Analyse und zur 83

84 6 ARCHITEKTUR UND FUNKTIONALITÄT Simulator GUI Topologie-DB Simulations-DB Monitor Abbildung 6.1: Architektur des Gesamtsystems Darstellung auf GUI-Ebene zu verwenden. Somit erfolgt die Kommunikation der beiden Controller im Wesentlichen über die Datenbankkomponente, sodass sie auch völlig unabhängig voneinander funktionsfähig sein können. Für spezifische Aufgaben eines Subsystems sind schließlich lokale Tabellen und Views erforderlich. Für die Datenverwaltung wurde MS Access als DBMS verwendet. Der entscheidende Vorteil dabei liegt im geringen Wartungs- und Administrationsaufwand. In dieser Arbeit wurden jedoch keine Access-spezifischen Funktionalitäten eingebunden, sodass eine Migration zu einem anderen DBMS keine große Schwierigkeit darstellen wird. Da sowohl der Monitor als auch der Simulator den Verkehr auf der grafischen Benutzeroberfläche darstellen, liegt es nahe, die verschiedenen Ansichten in ein gemeinsames Fenster zu integrieren. Dennoch erzwingt diese Design-Entscheidung keine Abhängigkeit der beiden Subsysteme: In allen Schritten der Entwicklung hat Modularität eine große Rolle gespielt. In diesem Abschnitt wurden die beiden Teilsysteme lediglich als Blackbox dargestellt, nachfolgend soll darauf detailliert eingegangen werden. 6.2 Simulator Im Rahmen dieser Arbeit wurde aufbauend auf der Multiagentensimulation und der diskreten Ereignissimulation ein Simulator für Verkehrsszenarien entworfen und implementiert (vgl. Unterkapitel 4.3). Der Simulator soll datenbankgestützt sein und die Rolle des Datenlieferers für einen Monitor übernehmen. Ziel dabei ist die Überwachung und Beobachtung des Straßenverkehrs. In diesem Unterkapitel wird auf die Architektur des Systems Simulator sowie seiner Funktionalitäten näher eingegangen. 84

85 6.2 Simulator Architektur des Simulators Wie im vorigen Abschnitt 6.1 erwähnt wurde, ist das Gesamtsystem nach der Anforderungserhebung in zwei Subsysteme unterteilt worden, die jeweils in Komponenten für das GUI, den Controller und die Datenbank untergliedert werden können. Gemäß dieser Unterteilung ist das Simulator-Subsystem in drei Paketen strukturiert, was die Modularität des Systems verstärkt (s. Abbildung 6.2). Abbildung 6.2: Architektur des Systems Simulator Im Paket s db werden alle datenbankbezogenen Prozesse gekapselt. Die Klasse DB- Connection sorgt für die Herstellung und das Schließen der Datenbankverbindung. In dieser Klasse wird durch die als Singleton implementierte Methode getconnection() sichergestellt, dass lediglich eine einzige Verbindung hergestellt wird. Das System soll möglichst wiederverwendbar sein. Deshalb werden die Datenbankanfragen aus dem Code in der Klasse DBAnfragen zusammengestellt. Dies erleichtert die Wartung des Codes und unterstützt die Flexibilität des Systems. Stark benutzte und aufwändige Anfragen werden aus Effizienzgründen in einer eigenen als Thread implementierten Klasse InsertThread nebenläufig bearbeitet, um die weitere Abarbeitung des Codes nicht zu beeinflussen. Das Paket s gui enthält alle Klassen, die zum Aufbau und zur Gestaltung des GUIs dienen. Darin enthalten sind insbesondere Objekte, die zusammen das GUI-Fenster bilden. An dieser Stelle wird zwischen Objekten für benutzerseitige Editierungszwecke wie die Klasse Menu und simulationsrelevanten Objekten wie z.b. Zelle unterschieden. Wie diese Objekte dargestellt werden und wie sie zusammenspielen, 85

86 6 ARCHITEKTUR UND FUNKTIONALITÄT regelt die Klasse SIMMain. In dieser Klasse werden diese als Swing-Komponenten implementierten Objekte miteinander gekoppelt, um ein benutzerfreundliches GUI zu erstellen. Weiterhin wird in der Klasse SIMMain der Start der Simulation ausgelöst und damit der Simulator in Betrieb gesetzt. Das Paket s sim hingegen fasst alle Klassen zusammen, die an den Simulationsvorgängen beteiligt sind. Die Routenauswahl erfolgt mithilfe einer XML-Datei, die in der Klasse SkriptParse ausgelesen wird. Details hierzu werden im Abschnitt 7.1 besprochen. Die Klasse LSA stellt die Abbildung der Tabelle lsa auf Java-Ebene dar. Die Steuerung dieser LSA-Objekte erfolgt durch die Klasse LSASimulation. Nebenläufig werden die Fahrzeuge erzeugt und auf die Straßen gesetzt. Modelliert werden diese Fahrzeuge durch die Klasse Fahrzeug. Die Pakete fassen semantisch stark zusammenhängende Klassen zusammen. Dennoch herrscht zwischen den Paketen eine Kommunikation, die das Zusammenspiel der Systemkomponenten widerspiegelt. Das Klassendiagramm in Abbildung 6.3 veranschaulicht einen Teil der Interaktion zwischen den verschiedenen Klassen aus unterschiedlichen Paketen. Die Klasse SIMMain steht zu Beginn der Simulation im Abbildung 6.3: Simulator Klassendiagramm Vordergrund, sie ist insbesondere für den Start der Simulation verantwortlich. Zum einen setzt sie die Simulationsuhr und die Steuerung der LSAs in Betrieb. Zum anderen initialisiert sie die Erzeugung der Fahrzeuge. Daher enthält sie ein Objekt der Klasse java.util.timer zur periodischen Fahrzeugsgenerierung. Innerhalb des s gui-packages besteht eine Kompositionsbeziehung zwischen den Klassen Karte und Zelle. Dieser Zusammenhang bedeutet, dass eine Karte aus mehreren Zellen gebildet wird und die Zellenexistenz von ihrer Existenz abhängt. Die Kopplung zwischen s sim und s gui entsteht hauptsächtlich durch die Beziehung zwischen der Fahrzeugklasse und der Zellenklasse. Diese Abhängigkeit zeichnet sich dadurch aus, dass auf den Zellen der neueste Zustand eines Fahrzeugs dargestellt wird. 86

87 Fahrzeug F Zelle Z 6.2 Simulator Reale Welt DB Java-Programm GUI Karte K K.. K Karte K.... Zelle Z.... Fahrzeug F..... Zelle Z Z.. Fahrzeug F F.. Z F Z F Abbildung 6.4: Abbildung der Objekte Die wesentlichen Java-Objekte haben ihre Entsprechung in der Datenbank. Abbildung 6.4 zeigt, wie die Objekte aus der realen Welt auf die verschiedenen Teile der Systemkomponenten abgebildet werden. Jedes aus der realen Welt auf Java-Ebene abstrahierte Objekt besitzt ein Gegenstück auf Datenbankebene. Die Java-Klasse Knotenzelle beispielsweise entspricht der Tabelle Knotenzelle in der Datenbank. Die Klasse Fahrzeug entspricht auf der Datenbankebene dem Entity-Typ Fahrzeug. In diesem Sinne sind die Instanzen jeder Klasse als Datensätze in der entsprechenden Tabelle zu sehen. Für die grafische Darstellung entsprechen solche Objekte ebenso grafischen Objekten auf GUI-Ebene. Die Objekte müssen auf allen vorgenannten Ebenen konsistente Zustände haben. Deshalb spielt ihre Synchronisation eine zentrale Rolle. Diese Aufgabe wird vom Controller übernommen, der das GUI auf den neuesten Stand bringt und gleichzeitig die Datenbank mit den aktuellen Daten füllt. Die Entsprechung dieser Objekte auf den drei Ebenen Datenbank, Java und GUI gilt für ihren gesamten Lebenszyklus. Eine Ausnahme stellen die Fahrzeugobjekte auf Datenbankebene dar. Ihre zugehörigen Datensätze bestehen zwar fortlaufend in der Datenbank, werden jedoch nur innerhalb der Überwachungszonen aktualisiert. Dies wird durch das Streben nach Effizienzsteigerung und Schutz der Privatsphäre motiviert. Die Fahrzeuge existieren solange, bis sie das Simulationsgebiet verlassen haben. Angezeigt werden allerdings nur diejenigen, die sich auf der vom Benutzer ausgewählten Karte bzw. entsprechendem Kartenausschnitt befinden. 87

88 6 ARCHITEKTUR UND FUNKTIONALITÄT Funktionalitäten des Simulators Das Simulator-GUI bildet die Schnittstelle zwischen dem System und dem Benutzer. Das GUI setzt sich aus einer Werkzeugleiste, einem Anzeigefenster und einer mit dem Monitor geteilten Menüleiste zusammen. Die Werkzeugleiste dient hauptächtlich der Kontrolle des Simulationsablaufs. Zur Verfügung stehen auf der einen Seite verschiedene Schaltflächen, die den Start, die Pause, die Wiederaufnahme und das saubere Beenden der Simulation bewirken. Ist das SiMo -System einmal gestartet, kann der Simulationsvorgang auf Wunsch des Benutzers mithilfe der Pause -Schaltfläche in einen Pause-Modus gebracht werden. Dies ermöglicht eine genaue Betrachtung der Verkehrslage sowie die Beobachtung spezieller Verkehrsphänomene wie z.b. Staus. Eine Simulationswiederaufnahme kann durch die Wiederaufnahme -Schaltfläche erreicht werden. Abbildung 6.5: Werkzeugleiste Auf der anderen Seite können sowohl die Verkehrsdichte als auch die Simulationsgeschwindigkeit manipuliert werden. Dafür sind zwei Schieberegler vorgesehen. Der erste auf der linken Seite in Abbildung 6.5 bewirkt eine Änderung der Verkehrsdichte, d.h. der Anzahl der Fahrzeuge auf einer Fläche zu einem gegebenen Zeitpunkt. Der andere Schieberegler rechts modifiziert die zeitliche Abtastung, welche eine Auswirkung auf die Simulationsgeschwindigkeit hat. Je geringer der Wert ist, desto kürzer ist die Zeitspanne zwischen zwei Simulationsschritten. Der Simulator ist auch in der Lage, die Dichte des Verkehrs in Abhängigkeit von der Ausführungszeit der Simulation anzupassen. Durch eine Auswahlliste kann der Benutzer selbst das Zeitintervall, in dem die Simulation auszuführen ist, bestimmen. Dies verleiht der Simulation einen realistischeren Charakter. So werden zu bestimmten Zeiten, z.b. im Fall von Berufsverkehr, mehr Fahrzeuge erzeugt, sodass eine größere Dichte erreicht wird. Die Ausgabe der Simulationszeit erfolgt in einem Textfeld, in dem der aktuelle Zustand der Simulationsuhr dem Benutzer mitgeteilt wird. Den größten Teil des GUIs bildet das Anzeigefenster, in dem unmittelbar nach dem Start ein Straßenausschnitt aus dem Gebiet Bonn-Nord angezeigt wird. Die Kreuzungsbereiche, die für den Monitor besonders interessant sind, werden mit einem hellen Farbton hervorgehoben, während die aktuell im Detail angezeigte Kreuzung des Monitors gelb markiert wird. Rot gekennzeichnet werden Zufahrten, auf denen die Ampel gerade auf Rot geschaltet ist. 88

89 6.2 Simulator Abbildung 6.6: Übersichtskarte Für den großen Simulationsraum ist es schwierig, die Fahrzeuge und die Zellen gut zu erkennen. Deswegen ist es notwendig, lokale Ansichten zu ermöglichen. Dies bedeutet, dass die erste Karte, die nach dem Starten zu sehen ist, als Übersichtskarte dient (siehe Abbildung 6.6). Sie ist in mehrere Teilkarten unterteilt, die die Beobachtung der Fahrzeuge auf einer lokalen Ebene möglich machen. Abbildung 6.7 stellt einen lokalen Ausschnitt des Simulationsgebiets dar. Die Zellen auf der Übersichtskarte reagieren auf einen Mausklick. Sobald auf eine Zelle geklickt wird, erfolgt ein Wechsel von der Übersichtskarte zum zugehörigen lokalen Ausschnitt. Ein Klick auf eine Kreuzung auf der lokalen Karte lässt wiederum diese auf der Detail-Ansicht des Monitors erscheinen. Um wieder auf die Übersichtskarte zu gelangen, steht eine Schaltfläche in der Werkzeugleiste zur Verfügung (Abbildung 6.5). 89

90 6 ARCHITEKTUR UND FUNKTIONALITÄT Beachtung von Verkehrsregeln ausschalten Abbildung 6.7: Lokaler Ausschnitt Um die Auswirkung von Regelverstößen erkennbar zu machen und für den Testbetrieb häufiger zu produzieren, steht ein Menü zum Ausschalten der Beachtung von Verkehrsregeln zur Verfügung. So lassen sich die Verkehrsregeln zu Vorfahrtbeachtung, Setzen des Blinkers und Beachtung von Ampeln ausschalten (siehe Abbildung 6.7) Strukturierung der statischen Komponenten Bei Multiagentensimulationen als Verfeinerung der diskreten Ereignissimulation werden hauptsächtlich dynamische Systeme modelliert und nachgebildet. Diese Systeme können jedoch statische Komponenten beeinhalten, welche während der gesamten Simulation unverändert bleiben. Die Simulation baut jedoch auf diesen statischen Komponenten auf, sodass sie einen wichtigen Bestandteil des Simulationsprozesses darstellen. Unter den statischen Komponenten fallen Verkehrsschilder, Ampeln sowie topologische Bestandteile des Simulationsgebiets. Die Topologie beschreibt das Straßennetz des Simulationsraums. Das Straßennetz besteht aus Straßen, die sich in Straßenknoten schneiden können, und ist als Graph 90

91 6.2 Simulator sich vorzustellen. Dieser Arbeit liegt eine diskrete Ereignissimulation zugrunde. Deshalb wurde der Raum diskretisiert, indem die Straßen in Zellen unterteilt wurden. Diese Unterteilung erfolgte nach der in Unterkapitel 4.2 eingeführten Theorie der zellularen Automaten. Gemäß des Datenbankentwurfs sind diese Zellen relational auf Datenbankebene abgebildet. Der Darstellung dieser Topologie kommt u.a. eine Java-Objekt Karte zu Nutze, auf der die Straßenkomponenten abgebildet werden. Das Simulationsgebiet ist wie erwähnt so groß, dass man es nur schwer bzw. unmöglich mit allen Details auf dem Monitor ansehen kann. Daher sind zwei Typen von Karten vorgesehen. Abbildung 6.8 zeigt die Typisierung der Kartenobjekte. Abbildung 6.8: Karten-Arten Der Obertyp Karte kann in zwei Kategorien untergliedert werden. Zum einen repräsentiert die Unterklasse Uebersicht die Karte, die das Gesamtgebiet darstellt. Zum anderen dient die Unterklasse Ausschnitt dazu, dass ausgewählte Räume näher angeschaut und beobachtet werden können. Die beiden Typen unterscheiden sich dadurch, dass bei einer Übersichtskarte alle Zellen dargestellt werden, die zum Simulationsgebiet gehören. Bei den Ausschnittkarten hingegen ist der darzustellende Raum begrenzt und wird durch maximale und minimale Koordinatenangaben definiert. Abbildung 6.9: Zellen Klassendiagramm Getreu dem Datenbankentwurf existiert auf Java-Ebene ein Objekt Zelle und stellen die Bausteine einer Karte dar. Diese Zellenobjekte sind wiederum aus semantischen Gründen in vier Arten unterteilt. Diese Unterteilung veranschaulicht Abbildung 6.9. Die Zellenarten weichen semantisch leicht voneinander ab. Daher werden die gemeinsamen Eigenschaften vom Obertyp Zelle vererbt, während die typspezifischen Eigenschaften in den Untertypen gekapselt werden. Die vier hier eingeführten Klassen sollen die in Abschnitt vorgestellten Zellentypen modellieren. 91

92 6 ARCHITEKTUR UND FUNKTIONALITÄT Strukturierung der dynamischen Komponenten Wurden die statischen Komponenten einmal generiert, stehen die dynamischen im Mittelpunkt des Geschehens. Als dynamisch werden solche Komponenten bezeichnet, die ihren Zustand im Laufe der Zeit verändern. Unter solchen Objekten, die für den hier realisierten Simulator relevant sind, fallen auf der einen Seite die Fahrzeuge, die ihre Positionen im Laufe der Zeit verändern. Auf der anderen Seite ist die Steuerung der LSAs als dynamischer Prozess zu sehen. Abbildung 6.10: Aktivitäten im Simulationsvorgang Das Aktivitätsdiagramm in Abbildung 6.10 veranschaulicht die wesentlichen Aktivitäten beim Simulationsvorgang der dynamischen Objekte. Das Drücken des Start- Knopfs bewirkt den Start der Simulation. Dies hat zur Folge, dass drei nebenläufige Threads gestartet werden. Der erste Thread betreibt die Simulationsuhr, die das Fortschreiten der Simulationszeit bewirkt. Der zweite Thread übernimmt die nebenläufige Steuerung der Lichtsignalanlagen. Der letzte Thread hat die Generierung 92

93 6.2 Simulator der Fahrzeuge zur Aufgabe. Eine Zustandsveränderung, sowohl bei den LSAs als auch bei den Fahrzeugen, führt zur Aktualisierung des GUIs. Solange die Stopp - Schaltfläche nicht gedrückt wird, läuft die Simulation weiter. Der Simulationsprozess kann aber in einen Pausenzustand gesetzt und dann zur Wiederaufnahme gebracht werden. Die Fahrzeuge sind autonome in ein Multiagentensystem eingebettete Agenten, die mittels Informationsaustausch mit ihrer Umwelt Handlungen vornehmen können. Die Fahrzeuge reagieren beispielsweise unterschiedlich auf Ampelzustände: Sie halten bei Rot an und fahren bei Grün weiter. Sie sind in der Lage, einen gewissen Abstand zum Vordermann halten zu können. Abhängig von seiner Absicht kann das Fahrzeug eigene Entscheidungen treffen wie beispielsweise einen Spurwechsel durchzuführen. Da die Simulation im Rahmen dieser Arbeit nicht unbedingt für die Verkehrsplanung, sondern eher für Monitoring-Zwecke vorgesehen ist, wurden die Fahrzeuge in verschiedene Typen unterteilt. Es bestehen verschiedene Fahrerprofile, die die unterschiedlichen menschlichen Fahrverhalten modellieren. Dies stärkt zusätzlich die Erweiterbarkeit und Flexibilität der Arbeit. Das bedeutet, dass die Fahrertypen leicht und mit wenig Aufwand um andere Fahrer ergänzt werden können. Abbildung 6.11 zeigt die vom Simulator erzeugten unterschiedlichen Fahrzeugtypen. Abbildung 6.11: Fahrzeugklassen Wie erwähnt charakterisieren die Fahrertypen verschiedene Fahrverhalten. Sie verfügen zwar über viele Gemeinsamkeiten, die in der Klasse Fahrzeug wiederzufinden sind. Abhängig von den Absichten eines Typs werden jedoch zusätzliche Funktionalitäten geleistet. Die Fahrzeug-Instanzen der Klasse FahrzeugBlinker zeichnen sich dadurch aus, dass sie keinen Blinker setzen. Die Fahrer, die über die rote Ampel fahren, sind durch die Klasse FahrzeugAmpel vertreten. Die Klasse FahrzeugVorfahrt hingegen charakterisiert die Fahrer-Kategorie, die die Vorfahrtregelung missachtet. Eine andere modellierungswürdige Sorte von Fahrern sind solche, die gegen die vorgeschriebene Fahrtrichtung fahren. Diese werden durch die Klasse FahrzeugFalschAbbieger repräsentiert. Andere Sorten von Fahrern sind natürlich denkbar, würden aber den Rahmen der Arbeit sprengen. So könnten z.b. auch Unfallverursacher modelliert werden. 93

94 6 ARCHITEKTUR UND FUNKTIONALITÄT 6.3 Monitor Die Anforderungserhebung in Abschnitt ergab bereits konkrete funktionale Anforderungen, an denen sich die Entwicklung des Systems orientiert. Die folgenden Abschnitte beschreiben zunächst die Funktionaliäten des Monitor-Teilsystems, um darauf aufbauend die Modellierung der Objekte sowie die interne Architektur zu erläutern Funktionalitäten des Monitors Das Monitor-Teisystem ist neben der Überwachung von Verkehrsszenarien für die detaillierte Darstellung einer Kreuzung oder Einmündung auf dem GUI zuständig. Dafür bietet es vier verschiedene Ansichten, welche mit Registerkarten organisiert sind und deren Funktionalitäten im Folgenden näher erläutert werden sollen: Design-Ansicht Simulate-Ansicht Detail-Ansicht Logging-Ansicht Sie ermöglichen dem Benutzer die Interaktion mit dem System, um auf den Prozess des Monitorings Einfluss nehmen zu können. Bei der Entwicklung wurde ein besonderes Augenmerk auf die Benutzerfreundlichkeit gerichtet. Alle Ansichten haben denselben Aufbau und teilen sich in eine Werkzeugleiste sowie einen Anzeigebereich für die Visualisierung eines überwachten Knotens auf. Im Gegensatz zum GUI des Simulators werden hier die Eigenschaften im Detail dargestellt. Für den Benutzer sichtbar sind zum einen die statischen Objekte wie beispielsweise Verkehrszeichen und Signalgeber. Zum anderen lassen sich die Zustände der Signalgeber und Fahrzeuge erkennen. Fahrtrichtung, Blinker sowie ID der einzelnen Fahrzeuge werden augenscheinlich. Dem Benutzer stehen im Detail alle im Simulationsgebiet verfügbaren Überwachungsbereiche zur Verfügung. Der aktuell angezeigte Knoten lässt sich über eine Auswahlliste oder aber durch Navigation im Anzeigefenster des Simulators wechseln. Die Lage der Zellen, aus denen das gesamte Straßennetz aufgebaut ist, ist bereits vor dem Einsatz des SiMo -Systems in der Datenbank zu erfassen (vgl. Abschnitt 5.2.2). Im Gegensatz zu der relativ statischen Topologie der Straßen, kommt es in der Realität häufiger vor, dass Verkehrszeichen oder Lichtsignalanlagen aufgebaut, verändert oder aber wieder entfernt werden. Um die Zuordnung von Verkehrszeichen und Lichtsignalanlagen visuell zu unterstützen, bietet die Design-Ansicht die Möglichkeit, Signalgeber sowie Verkehrszeichen über ein Popup-Menü zuzuordnen (siehe Abbildung 6.12). Die Verkehrszeichen unterteilen sich in vorfahrtregelnde Zeichen und Verkehrszeichen zu vorgeschriebener Fahrtrichtung. Für diese drei Kategorien erscheinen für jede Knotenzufahrt drei graue Felder, die jeweils als Platzhalter für Ampeln, Vorfahrtzeichen und Fahrtrichtungszeichen dienen. 94

95 6.3 Monitor Abbildung 6.12: Design-Ansicht Zentrales Simulationskonzept zur Steuerung von Signalgebern ist die Aufteilung der Signalisierungszustände in Phasen. Bei Auswahl mindestens eines Signalgebers können der dadurch entstehenden Lichtsignalanlage die Eigenschaften der Phasenschaltung zugeordnet werden. Das zugehörige Dialogfeld wird mithilfe der Schaltfläche Phasen definieren sichtbar (siehe Abbildung 6.13). Nach Auswahl der Phasenanzahl kann die Dauer jeder einzelnen Phase in Sekunden festgelegt werden. Für jeden Signalgeber werden weiterhin entsprechend der Phasenanzahl farbliche Kreise angezeigt, die symbolisch für die Signalfarbe in den einzelnen Phasen stehen sollen. 95

96 6 ARCHITEKTUR UND FUNKTIONALITÄT Abbildung 6.13: Phasen definieren (Design Modus) Ein Klick auf einen Kreis ändert die Farbfolge. In der Werkzeugleiste des Design Modus dient schließlich eine Schaltfläche zum Speichern aller Einstellungen (vgl. Abbildung 6.14). Die Datenbank wird hinsichtlich der Zeichenzuordnung und der Positionierung der Signalgeber mit der Phasenschaltung der LSA aktualisiert. Änderungen haben unmittelbar Auswirkung auf alle anderen Ansichten und Funktionalitäten des Systems. Löschen Stopp Abspielen Schritt vor Abbildung 6.14: Allgemeine Schaltflächen des Monitors Schritt zurück Um im Testbetrieb eine Unabhängigkeit des Monitors vom Simulator zu erreichen, bietet die Simulate-Ansicht die Möglichkeit, eigene Szenarien auf einer ausgewählten Kreuzung zu erstellen (siehe Abbildung 6.15). Diese können genauso auf Regelverstöße untersucht werden wie die komplexeren Verkehrsszenarien des Simulators. Simuliert werden können sowohl die Bewegung von Fahrzeugen als auch die Schaltung von Signalgebern. Die Werkzeugleiste enthält neben der Auswahlliste für die Kreuzung eine zweite Auswahlliste, die anzeigt, um welches Szenario es sich handelt. Sie listet alle in der Datenbank vorhandenen Szenarien auf und bietet zudem die Möglichkeit, mit der Auswahl Neues Szenario eine neue Verkehrssituation zu erstellen. Das Textfeld Zeit zeigt den aktuellen Simulationsschritt an, welcher durch die daneben gelegenen Schaltflächen Schritt vor und Schritt zurück modifiziert werden kann. Um einem Simulationsschritt den Signalisierungszustand existierender Signalgeber zuordnen zu können, enthält die Werkzeugleiste die Auswahlliste für die aktuell gewünschte Phase der Lichtsignalanlage. Fahrzeuge können gesetzt werden, indem auf die entsprechende Zelle der Kreuzung geklickt wird und die gewünschten Eigenschaften des Fahrzeugs im erscheinenden Popup-Menü ausgewählt werden. Sie können sich in Farbe, Fahrtrichtungsanzeiger und Fahrtrichtung unterscheiden: Autofarbe Fahrtrichtungsanzeiger Fahrtrichtung blau geradeaus Nord grün Linksabbieger Ost rot Rechtsabbieger Süd West 96

97 6.3 Monitor Abbildung 6.15: Simulate-Ansicht Dabei wird ein Fahrzeug durch seine Farbe eindeutig identifiziert, sodass in jedem Simulationsschritt jede Farbe höchstens einmal verwendbar ist. Das Setzen eines Blinkers und die Fahrtrichtung des Fahrzeugs auf einer Zelle sollen hierbei in keiner Weise eingeschränkt werden. Dies soll das Konstruieren von fehlerhaftem Verhalten ermöglichen. Die Schaltflächen Schritt vor und Schritt zurück ermöglichen das Zuordnen der Fahrzeuge zu den jeweiligen Zeitschritten. Zu einer besseren Orientierung werden in aufgehellten Farben zusätzlich die Fahrzeuge des vorhergehenden Schrittes dargestellt. Über die Schaltfläche Vorheriges Fahrzeug andeuten (siehe Abbildung 6.16) kann diese Option aus- oder eingeschaltet werden. Ein gespeichertes Szenario steht in der Detail-Ansicht zur Auswahl, sobald es in der Simulate-Ansicht abgespeichert wurde. Abbildung 6.16: Schaltfläche Vorheriges Fahrzeug andeuten (Simulate-Ansicht) 97

98 6 ARCHITEKTUR UND FUNKTIONALITÄT Eine der zentralen Benutzeroberflächen des Systems ist die Detail-Ansicht. Hier wird der aktuelle Verkehr auf Kreuzungsebene dargestellt, während zeitgleich das Monitoring zur Beobachtung des Verkehrs abläuft. Da die Detail-Ansicht thematisch eng mit der Übersichtskarte des Simulators zusammenhängt, teilen sich diese beiden Ansichten ein Fenster. Im Gegensatz zur Übersichtkarte werden hier Details der simulierten Verkehrsszenarien sichtbar. Eine benutzerdefinierte Entscheidung liegt in der Auswahl der Datenquelle, die der Visualisierung und dem Monitoring in der Detail-Ansicht zugrunde liegen soll. Die Daten zu Fahrzeugen und LSAs können entweder vom Simulator oder von einem zuvor vom Benutzer zusammengestellten Szenario geliefert werden. Abbildung 6.17: Schaltfläche Regelverstöße anzeigen (Detail-Ansicht) Das Drücken der Start -Schaltfläche bewirkt, dass die von der Simulation gelieferten Fahrzeug-Bewegungen und Ampelschaltungen auf der aktuell ausgewählten Kreuzung angezeigt werden. Weiterhin wird begonnen, den Verkehr im Hinblick auf Regelverstöße zu beobachten. Wurde ein Regelverstoß auf der angezeigten Kreuzung erkannt, wird er dem Benutzer in einem Dialogfeld gemeldet und gleichzeitig das betroffene Fahrzeug mit roter Farbe unterlegt. Wird das Anzeigen der Regelverstöße als störend empfunden oder nicht benötigt, kann der Dialog mit einem Klick auf die Schaltfläche Regelverstöße anzeigen ein- und ausgeblendet werden (siehe Abbildung 6.17). Das Menü Monitor in der Menüleiste des SiMo -Systems bietet zudem die Option, die Überwachung von Regelverstößen ein- und auszuschalten. Die Aktionen der Detail-Ansicht werden abgebrochen, sobald die Schaltfläche Stopp gedrückt wird. Jeder Regelverstoß, der vom Monitor erkannt wurde, ist in der Datenbank hinterlegt. Ein genaueres Betrachten dieser Verkehrsszenarien ist wünschenswert und daher in der Logging-Ansicht möglich. Hier werden alle geloggten Regelverstöße aufgelistet, um im Nachhinein nochmals abrufbar zu sein. Im Testbetrieb des Systems ermöglicht dies eine kritische Validierung geloggter Verkehrsszenarien, im späteren Einsatz des Systems könnte dies eine Grundlage für die Ergreifung gezielter Maßnahmen sein. Der angegebene Verweis auf den Paragraphen stellt diejenige Textstelle dar, auf die sich die Anfragen stützen. Je nach Ausprägung des Regelverstoßes könnte jedoch ein anderes Gesetz für den tatsächlichen Tatbestand herangezogen werden. Aus dem geloggten Regelverstoß lassen sich daher noch keine Auswirkungen hinsichtlich einer Strafe ableiten, da dies oftmals davon abhängt, ob gegen die Verkehrsregel z.b. mit Behinderung oder mit Gefährdung anderer verstoßen wurde. Diejenigen Fahrzeuge, die eine Ordnungswidrigkeit begangen haben, werden rot unterlegt dargestellt. Die Ansicht bietet zur Betrachtung der einzelnen Regelverstöße verschiedene Funktionalitäten (vgl. Abbildung 6.14). Das Abspielen eines ausgewählten Regelverstoßes kann mit den entsprechenden Schaltflächen gestartet und gestoppt werden. Um die 98

99 6.3 Monitor Fahrzeugkonstellationen im Detail betrachten zu können, stehen zwei Schaltfächen zur Verfügung, die das Regelverstoß-Szenario einen Schritt vor oder zurück bewegen. Nicht mehr benötigte Regelverstöße können durch die Schaltfläche Löschen aus der Datenbank und somit aus der Auswahlliste entfernt werden Objektdesign für das GUI Die Phase des Objektdesigns verbindet den konzeptuellen Entwurf aus Kapitel 5 mit der Implementierung. So können mithilfe von Klassendiagrammen bereits zuvor konkrete Entscheidungen getroffen werden, die eine grobe Struktur für die Implementierung festlegen. Je früher die Implementierung durch solche Vorüberlegungen geleitet wird, desto weniger besteht später der Bedarf an einer Umstrukturierung des Codes. Weiterhin ermöglicht eine genaue Auseinandersetzung mit den Objekten eine bestmögliche objektorientierte Umsetzung. Entwickelte Klassendiagramme sind dann automatisierbar in Java-Code umsetzbar. Die Implementierung des Monitor-Teilsystems baut insbesondere auf der Implementierung des GUIs auf. Die Komplexität der Überwachung von Straßenverkehrsszenarien spiegelt sich stattdessen vielmehr auf Datenbankebene wider (siehe Abschnitt 7.2) und beeinflusst die Struktur der Klassen nur in geringem Ausmaß. Im Folgenden wird daher auf die getroffenen Design-Entscheidungen des GUIs eingegangen. Abbildung 6.18: Ansichten des Systems Abbildung 6.18 zeigt die benötigten Klassen für die verschiedenen Ansichten des Systems, die sich aus den Use Cases des Monitors ableiten lassen (vgl. Abschnitt 5.1.2). Die verschiedenen Ansichten des Systems im Anzeige-Fenster werden durch Registerkarten organisiert. Um dynamisch einen für den Benutzer sichtbaren Namen vergeben zu können, besitzen die Klassen eine Variable tab name für die entsprechende Registerkarte. Somit schreibt die abstrakte Klasse View, welche alle Ansichten implementieren müssen, diese Eigenschaft vor. Statisch festgelegte Variablen machen die Implementation flexibel, indem eine Umentscheidung lediglich das Modifizieren einer einzigen Variable erfordert. Weiterhin lässt sich feststellen, dass die vier Ansichten des Monitor-Teilsystems eine gemeinsame Grundstruktur haben: Alle stellen einen beobachteten Straßenbezirk im Kreuzungsbereich dar. Teilt man die Benutzeroberfläche in Werkeugleiste und 99

100 6 ARCHITEKTUR UND FUNKTIONALITÄT Straßenkarte, so unterscheiden sie sich hauptsächlich durch die Funktionalitäten in der Werkzeugleiste, während der grafische Aufbau der Karte stets in denselben Schritten abläuft. Abbildung 6.19: Komponenten der Karten Daher liegt in diesem Fall eine Umsetzung durch eine Vererbungshierarchie nahe, welche in Abbildung 6.18 modelliert wurde. Somit erhält die bereits erwähnte Klasse View eine ebenfalls als abstrakt markierte Unterklasse Crossing, welche alle Funktionalitäten zur Verfügung stellt, die in den verschiedenen Kreuzungsansichten gleichermaßen benötigt werden. So kann sowohl die Straßentopologie mit Zellen und Verkehrszeichen als auch eine Auswahlliste für Kreuzungen in der Oberklasse implementiert werden. Die Unterklassen View Design, View Simulate, View Detail und View Logging erben den Grundaufbau der GUI und passen sie an ihre Anforderungen an. Die Detail-Ansicht zum Beobachten des Verkehrs steht jedoch nicht einzeln als Ansicht zur Verfügung. Stattdessen ist sie gekoppelt mit der Übersichtskarte des Simulator-Teilsystems. Die Klasse View Overview Detail stellt, ebenfalls die abstrakte Klasse View erweiternd, diese gemeinsame Ansicht dar. Erwähnt sei hierbei, dass bei der Implementierung strikt auf Modularität geachtet wurde, sodass die in ein JPanel eingebettete Übersichtskarte des Simulators in dieser Zusammenstellung völlig unabhängig von den anderen Ansichten implementiert werden kann. Die einzelnen Kreuzungen werden wiederum aus verschiedenen Swing-Komponenten aufgebaut (siehe Abbildung 6.19). Jedes Element des Überwachungsbereichs wird durch eine eigene Klasse repräsentiert. Um die Benutzung der Komponenten im Code vom konkreten Objekt lösen zu können und damit das Konzept der Polymorphie umzusetzen, wird auch hier eine abstrakte Klasse als Oberklasse eingesetzt. Die Klasse MapComponent stellt sicher, dass alle sie implementierenden Klassen eine Methode zum Aktualisieren der Ansicht (refresh()) und eine Methode zum Speichern der Einstellungen (save()) zur Verfügung stellen. 100

101 6.3 Monitor Wesentliche Komponenten der Karte sind die Zeichen und Zellen. Die Klasse Zeichen stellt hierbei die Oberklasse von Signalgeber, Fahrtrichtungszeichen und Vorfahrtzeichen dar. Zellen enthalten weiterhin ein Fahrzeug, was durch die Kompositions- Beziehung verdeutlicht wird. Diese Modellierung nimmt an, dass ein Fahrzeug durch verschiedene Instanzen der Klasse Fahrzeug den Zellen zugeordnet werden kann. Sie repräsentieren also mehr die augenblickliche Darstellung eines Fahrzeugs auf einer bestimmten Zelle als das Fahrzeug an sich, sodass sie abhängig von der Existenz einer Zelle sind. Die objektorientierte Implementierung lässt es nun zu, dass die Instanzen der Kartenkomponenten bei Methodenaufrufen nicht hinsichtlich der Klasszugehörigkeit differenziert werden müssen. Stattdessen ist ein Aktualisieren der Kartenansicht in der Klasse Crossing durch Iterieren über die Kartenkomponenten mit ein und demselben Funktionsaufruf refresh() möglich. Zur Laufzeit wird entschieden, welcher Klasse sich die Komponente tatsächlich zuordnen lässt. So können Signalgeber ihr Signalbild ändern, währenddessen Zellen in ihrer refresh()-methode ein Fahrzeug darstellen. Das Speichern, welches in der Design- und Simulate-Ansicht erforderlich ist, kann analog umgesetzt werden, um das Konzept des Dynamic Bindings auszunutzen. Mit diesem Objektdesign steht bereits eine grobe Richtlinie für die Implementierung des Systems zur Verfügung, die im weiteren Verlauf der Entwicklung verfeinert und strukturiert wird Architektur des Monitors Der Controller des Monitor-Teilsystems steht sowohl mit der Datenbank als auch mit dem GUI in Beziehung. Weiterhin sind verschiedene Hilfsklassen notwendig. Das Teilsystem unterteilt sich daher in drei Komponenten. Die zugehörigen Java-Klassen sind thematisch den in Abbildung 6.20 dargestellten Paketen zugeordnet: m gui m db m obj Das Paket m gui fasst die Klassen zusammen, die für die Darstellung der grafischen Benutzeroberfläche benötigt werden. Der Einstieg des Java-Programms liegt in der Klasse Start, welche die main()-methode enthält. Hier liegt die zentrale Steuerung der Benutzeroberfläche. Es werden die verschiedenen Ansichten integriert, globale für das gesamte System geltende Werte festgelegt und ein Wechsel der Registerkarten ermöglicht. Wie bereits erwähnt, repräsentiert die abstrakte Klasse View die verfügbaren Ansichten des Systems (vgl. Abschnitt 6.3.2) und ist für die Darstellung eines Straßenausschnitts zuständig. Daher beinhaltet das Paket m gui weiterhin eine Reihe von Klassen, die Bestandteile der Karte sind und der abstrakten Klasse MapComponent 101

102 6 ARCHITEKTUR UND FUNKTIONALITÄT! " Abbildung 6.20: Organisation der Java-Klassen untergeordnet sind. Wird in einer der Kreuzungsansichten die Simulation gestartet, so wird die Klasse GUI Update beauftragt, die GUI der Zeit entsprechend dem aktuellen Zustand anzupassen. Diese als Thread implementierte Klasse steuert das Anzeigen der bereits in der Datenbank hinterlegten Simulationen auf Kreuzungsebene. Eine weitere Komponente des Systems ist das Paket m db, deren Klassen die Kommunikation mit der Datenbank kapseln. Das Paket umfasst zum einen die Klasse Connection Manager, welche für den Auf- und Abbau einer Verbindung zur Datenbank zuständig ist. Sie ist als Singleton implementiert und stellt damit eine einzige Instanz der Klasse und folglich ein einziges Connection-Objekt bereit, auf welches aus allen Klassen mit der statischen Getter-Methode getcon() zugegriffen werden kann. Dies hat den Vorteil, dass die Datenbank-Verbindung nicht bei jeder Anfrage aufs Neue aufgebaut werden muss, sondern stattdessen in einer Variablen zur Verfügung steht. Sofern noch keine Verbindung zur Datenbank besteht, d.h. con == null, wird mithilfe der Singleton-Methode connect() die Verbindung zur Access-Datenbank aufgebaut: public static Connection getcon() { if (con == null) connect(); return con; } Weiterhin bietet die Klasse eine Methode clean up data(), welche das Löschen von nicht mehr benötigten Daten zum Beispiel nach dem Schließen der Anwendung bündelt. 102

103 6.3 Monitor Die Klasse DB Queries kapselt in meist parametrisierten Methoden die Anfragen, die in den verschiedenen Java-Klassen benötigt werden. Dies hat zum Vorteil, dass die Datenbank-Realisierung von der Implementierung der GUI getrennt wird. Mehrfach genutzte Anfragen existieren nur einmal und Änderungen, die zum Beispiel aufgrund von Design-Entscheidungen in der Datenbank notwendig werden, müssen nur auf diesen Strings vollzogen werden. Idealerweise würde diese Aufgabe der Kapselung das DBMS selbst tragen, jedoch bietet MS Access nicht die Möglichkeit, parametrisierte SQL-Anfragen oder Stored Procedures für den JDBC-Zugriff zu definieren. Der Kern des Monitor-Teilsystems liegt in der Thread-Klasse DB Check. Sie steuert die Überwachung des Straßenverkehrs und enthält die deskripte Beschreibung der Regelverstöße in Form von SQL-Anfragen. Für jeden zu beobachtenden Regelverstoß existiert eine Instanz dieser Klasse. Wird ein Regelverstoß erkannt, kommt die Klasse DB Logging zum Einsatz. Sie ist für die Speicherung der Fahrzeug- und LSA-Zustände zuständig, die den Regelverstoß charakterisieren und später in der Logging-Ansicht zur Verfügung stehen sollen. Für das Überprüfen selbst erstellter Szenarien ersetzt die Klasse CopySim den Simulator und kopiert die zugehörigen Datensätze Schritt für Schritt in die Tabelle sm fahrzeug, auf der die Abfragen des Monitors ausgewertet werden. Die Ansichten auf Kreuzungsebene stellen dem Benutzer eine Reihe von Auswahllisten zur Verfügung, deren Einträge Objekte aus der Datenbank repräsentieren. Das Paket m obj fasst daher die Klassen Knoten, Szenario und Regelverstoss zusammen. Sie haben zwar keine direkte Verbindung zur Datenbank, stellen jedoch der GUI nach einmaliger Initialisierung die Attributwerte aus den Relationen zur Verfügung Organisation der Monitoraktivitäten Die Aufgaben des Monitors in der Detail-Ansicht teilen sich in zwei Aufgabenbereiche, dessen Aktivitäten simultan und in Echtzeit auszuführen sind: Die Darstellung eines Straßenknotens sowie das Monitoring von Regelverstößen. Abbildung 6.21 zeigt die Arbeitsweise des Monitors in einem Aktivitätsdiagramm. Die Prozesse beginnen, sobald die Start -Schaltfläche in der Werkzeugleiste der Detail-Ansicht gedrückt wird. Zum einen wird daraufhin fortlaufend das Verkehrsgeschehen eines Knotens auf dem GUI angezeigt. Aktualisiert wird die Ansicht, sobald ein Fahrzeug auf der angezeigten Kreuzung seine Position wechselt oder die Lichtsignalanlage ihren Zustand ändert. Zum anderen werden nebenläufig die in der Datenbank vorhandenen Fahrzeuge auf einen möglichen Regelverstoß überprüft, sofern die Option Monitor an über das Menü eingeschaltet wurde. Für das datenbankgestützte Monitoring werden zunächst die zuständigen Threads initialisiert. Dies geschieht dynamisch durch Erzeugung von Instanzen der Thread- Klasse DB Check, welche von den in der Tabelle m regelverstoss kat gespeicherten Regelverstoßkategorien abhängt. Durch ein dynamisches Initialisieren bleibt das 103

104 6 ARCHITEKTUR UND FUNKTIONALITÄT!"# % "&'!# $!#!#!#!# Abbildung 6.21: Arbeitsablauf des Monitors Monitoring flexibel gegenüber Erweiterungen hinsichtlich Regelverstoßkategorien. Das folgende Stück Code zeigt das Initialisieren der Monitor-Threads: Statement st = Connection_Manager.getCon().createStatement(); String query = DB_Queries.lst_regelverstoss_kat(); ResultSet rs = st.executequery(query); while(rs.next()) { DB_Check r = new DB_Check(rs.getInt("regelverstoss_kat_id"), rs.getstring("stvo_ref"),rs.getstring("beschreibung")); r.start(); } Connection_Manager.clean_up(rs, st); Die Regelverstöße sind nach den Verkehrsregeln der StVO klassifiziert, sodass sich jede Sicht einem konkreten Paragraphen zuordnen lässt. Die Kapselung der Regelverstöße in eine eigene Thread-Klasse versucht eine möglichst gleichzeitige Überwachung des Straßenverkehrs zu simulieren. Die im Konstruktor übergebene ID einer Regelverstoßkategorie entscheidet über die Art der Abfrage, die auf den Tabellen ausgeführt werden sollen. 104

105 6.3 Monitor Die run()-methode der Klasse DB Check organisiert jeweils das fortlaufende Überprüfen der Daten für jede Regelverstoßkategorie. Zunächst werden stets irrelevante Daten gelöscht, um die Tabellen, auf denen die Kontrollsichten basieren, möglichst klein zu halten. Anschließend wird eine SQL-Anfrage zum entsprechenden Regelverstoß ausgeführt. Wird ein Regelverstoß erkannt, so wird dieser dem Benutzer in einem Dialogfeld gemeldet. Direkt im Anschluss wird ein Thread gestartet, der allein für das Loggen der Daten, welche den Regelverstoß charakterisieren, verantwortlich ist. Währenddessen wird der Kontrollfluss an anderer Stelle mit dem Monitoring fortgesetzt. Wurde zwischenzeitlich die Stopp -Schaltfläche gedrückt, so wird sowohl das Monitoring als auch das Anzeigen der Fahrzeuge abgebrochen. Andernfalls können der Monitorprozess sowie das Aktualisieren von Fahrzeugen und LSAs weiter ausgeführt werden. Näheres zu den SQL-Kontrollsichten wird in Abschnitt beschrieben, das Logging-Konzept für erkannte Regelverstöße wird in Abschnitt vorgestellt. Die Aktualisierung des GUIs wird durch die Klasse GUI Update geleitet. Die Art und Weise der Aktionen zum Abfragen der aktuellen Datenbankzustände ist abhängig von der Ansicht, die dem Benutzer angezeigt wird. Im Wesentlichen besteht der Ablauf aus einer for-schleife, worin die Methode refresh view() der jeweiligen Ansicht aufgerufen wird. Das folgende repräsentative Code-Fragment zeigt hier den Ablauf für die Detail-Ansicht, sofern ein vom Benutzer erstelltes Szenario als Datenquelle ausgewählt wurde. int max = getmaxzeit(); for(int i = 1; i<= max &&!stop_detail; i++) { View_Detail.setZeit(i); View_Detail.getView_detail().refresh_view(); try{ Thread.sleep(Settings.getSleep_time_ms()); }catch (InterruptedException e) { e.printstacktrace(); } } Mithilfe der for-schleife werden die diskreten Zeitschritte durchlaufen und zur Erneuerung der GUI eine Nachricht an die Klasse View Detail gesendet. Damit wird die entscheidende Aktualisierung der Kreuzung aus der Klasse GUI Update ausgelagert. Wie bereits in Abschnitt beschrieben, bewirkt die Ausführung des dort gekapselten Codes, dass Fahrzeuge und Ampeln entsprechend ihrer aktuellen Zustände sichtbar werden. Die Zeitspanne zwischen den einzelnen Schritten wird durch die von Thread bereitgestellte Methode sleep() erreicht. Das dort als Parameter verwendete Zeitintervall sleep time ms steht sowohl für den Monitor als auch für den Simulator zur Verfügung und liefert eine für das gesamte System einheitliche Taktung der Ereignisse. 105

106 6 ARCHITEKTUR UND FUNKTIONALITÄT Eine Ausnahme bei der Aktualisierung einer Kreuzung stellt die vom Simulator gelieferte Simulation dar. Hier ist die Darstellung des Verkehrs nicht von einer maximalen Zeit begrenzt, sodass eine alternative Umsetzung der fortlaufenden GUI- Aktualisierung notwendig ist. In diesem Fall stellt die Klasse - orientierend am Observer-Pattern - eine Methode public static void update(int knoten_id) bereit, die es dem Simulator damit ermöglicht, eine Datenbank-Änderung zu einem bestimmten Knoten mitzuteilen. Sofern die Zustandsänderung den Knoten betrifft, der dem Benutzer sichtbar ist, wird letztlich auch hier die Methode refresh view() der View Detail-Instanz aufgerufen, um synchron mit der Übersichtskarte des Simulators die aktuelle Verkehrslage darzustellen (vgl. Unterkapitel 6.4). 6.4 Synchronisation Das SiMo -System setzt sich aus Simulator- und Monitor-Teilsystem zusammen. Wie bereits in Abschnitt 6.1 erläutert, erfolgt der Datenaustausch über die Datenbank, während die Visualisierung über ein gemeinsames GUI stattfindet. Daraus ergeben sich bezüglich der Synchronisation zwei grundlegende Herausforderungen. Einerseits muss der Monitor stets die aktuellen vom Simulator erzeugten Daten überprüfen. Ein Regelverstoß soll erkannt werden, bevor das beteiligte Fahrzeug den Überwachungsbereich verlässt. Zum anderen soll die Simulation auf den jeweiligen Anzeigefenstern der Teilsysteme synchron ablaufen, obwohl die Aktualisierung von verschiedenen Controllern durchgeführt wird. Hinsichtlich der Überwachung existieren zwei Möglichkeiten zur Kooperation. Die erste Methode ist eine pull -Methode, was bedeutet, das der Monitor explizit die Daten anfordert. Bei der zweiten Methode, push, schreibt der Simulator unaufgefordert die Daten in eine Logging-Tabelle. Das SiMo -System wendet die letztere Methode an. Ein Grund dafür liegt darin, dass keine zentrale Stelle zur Datensammlung zur Verfügung steht. Vielmehr stellen die Fahrzeuge unabhängige Agenten dar, worauf der Monitor nicht kontrolliert zugreifen kann. Somit ist der Monitor darauf angewiesen, dass die einzelnen Fahrzeuge Informationen über ihre Zustände senden. Fahrzeug 1 Fahrzeug 2 Monitor!!!!!!!??!? Update Anfrage Abbildung 6.22: Taktung Der Einsatz der push-methode hat zur Folge, dass der Datenstrom der Fahrzeuge 106

107 6.4 Synchronisation keine gleichmäßige Taktung aufweist, sondern die Fahrzeug zu unterschiedlichen Zeiten Daten senden. Abbildung 6.22 veranschauchlicht die asynchrone Signalisierung der Fahrzeuge. Dennoch soll der Monitor Verkehrsregelverstöße in Echtzeit erkennen. Vorteilhaft ist, dass in festen dem Monitor bekannten Zeitabständen Daten von Fahrzeugen in die Logging-Tabelle geschrieben werden. Dies ist der Diskretisierung von Raum und Zeit zu verdanken. In der Realität kann diese Rolle von einem vorgeschalteten Konvertierer übernommen werden. Die Daten könnten in diesem Fall beispielsweise von Induktionsschleifen erfasst und in einen Datenstrom umgewandelt werden. Mit dem Vorwissen über die Schrittlänge überprüft der Monitor bei jedem zweiten Takt die Daten auf Regelverstöße. Dadurch ist gewährleistet, dass alle Fahrzeuge neue Daten gesendet haben. Darüber hinaus ist die Periode nicht zu lang, sodass der Monitor eventuelle Regelverstöße noch melden kann, bevor das betroffene Fahrzeug den Überwachungsbereich verlässt. 107

108 6 ARCHITEKTUR UND FUNKTIONALITÄT Abbildung 6.23: Synchronisation der GUIs 108

109 6.4 Synchronisation Das zweite Problem stellt die Synchronisation des GUIs dar. Im Gegensatz zu einem Einsatz im realen Betrieb werden die beiden GUIs unabhängig voneinander aktualisiert. Dennoch soll der Benutzer den Eindruck gewinnen, dass sich die Zustände der einzelnen Fahrzeuge in den beiden GUIs nicht unterscheiden. Aus diesem Grund wird zum einen die Simulator-GUI erst aktualisiert, wenn die neu ermittelten Datensätze in die Datenbank geschrieben wurden. Diese Zeitdifferenz bietet dem Monitor zur Aktualisierung seines GUIs die Möglichkeit, die aktuellen Daten abzufragen. Eine Schwierigkeit liegt darin, dass die Fahrzeuge zu unterschiedlichen Zeiten ihre Zustände ändern. Ein getaktetes Aktualisieren erfordert eine hohe Abtastrate, was nicht dazu beitragen würde, dass die erhoffte Leistung in der Visualisierung erreicht wird. Dies motiviert den Einsatz eines Observer-Patterns (vgl. Abschnitt 2.5.2). Im Sinne des Observer-Patterns spielt der Simulator die Rolle des Subjects, während der Monitor den Observer darstellt. Jede Zustandsänderung eines Fahrzeugs wird dem Monitor durch Aufruf seiner update()-methode mitgeteilt. Um dem Monitor eine möglichst optimale Anpassung zu ermöglichen, besitzt die Methode den Parameter knoten id. Somit muss nur dann eine Aktualisierung des Monitor-GUIs durchgeführt werden, wenn die Änderung den aktuell angezeigten Knoten betrifft. Abbildung 6.23 zeigt das gemeinsame GUI von Monitor und Simulator. Die Zustände des Fahrzeugs auf der ausgewählten Kreuzung sind in beiden Fenstern synchron. Es wird ein Regelverstoß gemeldet, kurz nachdem das Fahrzeug bei Rot in die Kreuzung eingefahren ist. 109

110 6 ARCHITEKTUR UND FUNKTIONALITÄT 110

111 Kapitel 7 Ausgewählte Aspekte der Implementierung Nach intensiven Vorüberlegungen in der Entwurfsphase soll schließlich das System aufbauend auf der Konzeption implementiert werden. In diesem Kapitel werden ausgewählte Aspekte der Implementierung ausführlich erläutert. Sie verschaffen einen Einblick in die Problematik und die zur Lösung herangezogenen Vorgehensweisen und Techniken. Wie in den vorherigen Kapiteln lässt sich eine Unterteilung in zwei Teilbereiche, Simulator und Monitor, vornehmen. Zum einen beschreibt Unterkapitel 7.1 die Implementierung der bedeutendsten Komponenten sowie die Diskussion ausgewählter Probleme des Subsystems Simulator. Zum anderen diskutiert Unterkapitel 7.2, wie sich eine datenbankgestützte Überwachung des Verkehrs umsetzen lässt. 7.1 Ausgewählte Aspekte der Simulation Die Simulation wird in zwei Schritten ausgeführt. Zuerst werden die statischen Komponenten aus der Datenbank geladen. Darauf aufbauend erfolgt die Gestaltung des GUIs, die mit Einsatz verschiedener Karten nicht ohne Synchronisation angemessen zustande kommen kann. Anschließend werden nach dem Start der Simulation fortlaufend die dynamischen Komponenten erstellt und in Betrieb gesetzt. Für die Fortbewegung der Fahrzeuge als Teil der dynamischen Komponenten müssen Routen verfügbar sein. Schließlich ist die Beachtung der Verkehrsregeln eine notwendige Aufgabe für eine realistische Simulation Aufbau und Synchronisation der Karten Da die Flexibilität und Erweiterbarkeit sowie die überschaubare Strukturierung des Systems eine große Rolle beim Entwurf gespielt haben, bringt auch die Implementierung der statischen Objekte als Bausteine der Karten dementsprechend Anforderungen mit sich. Das System soll nicht nur im betrachteten Bonn-Nord-Gebiet Einsatz finden können, sondern flexibel gegenüber einer Erweiterung bzw. einem Wechsel des Einsatzortes sein. Daher soll der Code eine vom Simulationsgebiet vollständige Unabhängigkeit aufweisen. Weiterhin stellen die statischen Objekte einen nicht tri- 111

112 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG vialen Bestandteil der Simulationsumgebung dar. Umso wichtiger ist ihre Gestaltung und Strukturierung für einen guten Verlauf des Simulationsvorgangs. In diesem Abschnitt wird die Herangehensweise erklärt sowie die Design-Entscheidungen vorgestellt, die bei der Implementierung getroffen wurden. Dank der Unterteilung der Straßentopologie in Zellen, liegt das gesamte Straßennetz als Menge aller Zellen relational in der Datenbank vor. Sich stützend auf diese Datengrundlage, wird die Straßentopologie einmal beim Starten des Systems dynamisch zellenweise ausgelesen und aufgebaut. Soll das System für ein anderes Stadtgebiet in Betrieb genommen werden, ist einmalig der Aufwand der Datenerfassung und Eintragung in der Datenbank erforderlich. Da der Code davon unberührt bleibt, ist eine Migration folglich nicht problematisch. Wie bereits erwähnt wurde, werden die Zellen in vier Kategorien (Straßenzellen, Knotenzellen, Knotenzufahrten und Knotenabfahrten) unterteilt. Diese strikte Unterteilung ist für den Simulationsablauf von großer Bedeutung, da die ausgeführten Aktionen vom Zellentyp abhängen. Eine Zufahrtzelle ist z.b. wichtig für die Beachtung von Ampeln bzw. Verkehrsschildern. Dies trägt zur Steigerung der Effizienz bei, indem die Abfragen zur Beachtung der Verkehrsregeln (siehe Abschnitt 7.1.4) nur dann ausgeführt werden, wenn sich ein Fahrzeug auf einer Knotenzufahrt befindet. Es werden generell daher nicht alle Zellen angesprochen, sondern lediglich solche, die von der auszuführenden Aktion betroffen sind. Für eine angemessene Instantiierung kommt hier ein Factory Method Pattern zum Einsatz. Sich an diesem Pattern orientierend, wird beim Erzeugen der statischen Karte auf den Typ der Zelle geachtet und dementsprechend der zugehörige Konstruktor zum Erstellen des Zellenobjekts aufgerufen. Das folgende Stück Code zeigt, wie eine Knotenzufahrt erstellt und zur Karte mithilfe der Methode addcomponentcell hinzugefügt wird: if(typ.equals("zufahrt")) { addcomponentcell(this, new Knotenzufahrt(ID, x, y,zu_ueberwachen, zu_blinken, knoten_id, 0 ), x, y, 1, 1,1,1,ID); } Nachdem die Zellen zum Kartenobjekt hinzugefügt wurden, werden sie gemäß dem zugrunde liegenden Layout-Manager angeordnet. An dieser Stelle wurde das GridBagLayout verwendet, da die Flächenunterteilung in einem gleichmäßigen rechteckigen Gitter erfolgt. Dies entspricht der vorgesehenen Raumdiskretisierung, die auf zellularen Automaten basiert. Der Punkt oben links auf der Karte entspricht dem Nullpunkt des Koordinatensystems in Swing. Die Werte der X-Achse wachsen von links nach rechts, die der Y-Achse von oben nach unten. Aus diesem Grund wurden die Koordinaten der Zellen in der Datenbank abhängig vom Nullpunkt (1,1) gespeichert. Da die Zellen im Laufe der Simulation ihre Zustände verändern, müssen sie stets grafisch auf den neuesten Stand gebracht werden. Dadurch ist ein Zugriff auf die Zellen nicht zu vermeiden. Wurden die Swing-Komponenten einmal generiert, lassen sie sich jedoch nur anhand 112

113 7.1 Ausgewählte Aspekte der Simulation einer ID anstatt mittels (X,Y)-Position ansprechen. Um auf die Zellen während der Simulation zugreifen zu können, ist es daher notwendig, die Swing-Komponenten noch zusätzlich mit einem Identifikator (ID) zu versehen. Damit lassen sich die einzelnen Komponenten einer Karte zurückgeben: Component comp = SIMMain.getKarte(0).getComponent(id); Den Zellen werden neben den Identifizierungseigenschaften noch weitere Eigenschaften zugeordnet. Während die Simulation auf dem gesamten Gebiet erfolgt, werden nur Kreuzungen und ausgewählte Bereiche vom Monitor überwacht. Damit diese Überwachungsbereiche hervorgehoben werden, ist es für die grafische Darstellung von Interesse, zu vermerken, ob die Zellen zum Überwachungsbereich gehören. Besonders auszuzeichnen sind auch solche Zellen, bei denen ein Fahrzeug im Fall eines Abbiegevorgangs ordnungsgemäß den Fahrtrichtungsanzeiger setzen muss. Die Aneinanderreihung solcher benachbarter Zellen wird als Blinkerbereich bezeichnet. Abbildung 7.1 versinnbildlicht den Überwachungsbereich einer Kreuzung, der den Blinkerbereich einschließt. Blinkerbereich Überwachungsbereich Abbildung 7.1: Überwachungsbereich und Blinkerbereich Sind nun einmal die Zellen zur Übersichtskarte oder zur entsprechenden Ausschnittskarte hinzugefügt, soll der Benutzer die Möglichkeit haben, zwischen den einzelnen Karten zu navigieren. Dies ermöglicht das sogenannte CardLayout, da dort einzelne gleichartige Swingkomponenten als Stapel übereinandergelegt werden. Dementsprechend werden die einzelnen Straßenkarten als Swingkomponenten gemäß diesem Layout dargestellt. Hierbei liegen die Ausschnittskarten in der Tabelle s ausschnitte in der Datenbank vor und werden daher dynamisch geladen, was die Flexibilität des 113

114 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Systems unterstützen soll. Ein Ausschnitt ist durch die Beschränkung der X- und Y-Koordinaten eindeutig festgelegt: public static JPanel jcontentpanecards = new JPanel();... jcontentpanecards.add(getkarte(0),"0");//übersichtskarte hinzufügen Statement st = Connection_Manager.getCon().createStatement(); String query = "SELECT ID, x_min, x_max, y_min, y_max FROM s_ausschnitte;"; ResultSet rs = st.executequery(query); while(rs.next()) {//Ausschnitte hinzufügen jcontentpanecards.add( new Ausschnitt(rs.getInt("ID"),rs.getInt("x_min"), rs.getint("x_max"), rs.getint("y_min"), rs.getint("y_max")),string.valueof(id)); } rs.close(); st.close(); Um dem Benutzer einen neuen Ausschnitt zur Verfügung zu stellen, genügt es, die Kartentabelle um einen Eintrag zu erweitern. Bestehende Ausschnitte lassen sich in diesem Sinne auch leicht anpassen. Die Kapselung der Kartenausschnitte auf der Datenbank unterstützt weiterhin die Unabhängigkeit des Codes von den betrachteten Simulationsgebieten. Nachdem alle Kartenausschnitte zum JPanel jcontentpanecards hinzugefügt wurden, kann der Benutzer per Mausklick die gewünschte Karte anzeigen lassen. Die mit 0 gekennzeichnete Übersichtskarte z.b. wird dem Cardlayout entsprechend auf Wunsch des Benutzers folgendermaßen angezeigt: public static CardLayout cl = new CardLayout(); public void mouseclicked(java.awt.event.mouseevent e) { cl.show(simmain.jcontentpanecards, String.valueOf(0)); } Die Vielfalt der Karten bringt jedoch Konsistenzprobleme mit sich. Die Zellen in den verschiedenen Kartenausschnitten sind logisch gesehen dieselben Zellen wie auf den entsprechenden Teilen der Übersichtskarte. Diese Zellen werden für die unterschiedlichen Karten jedoch mit verschiedenen Swing-Komponenten grafisch dargestellt. Deshalb muss bei einem Wechsel von einer Karte zur anderen sichergestellt werden, dass eine Synchronisation der Darstellung stattfindet. Die Information über die Belegung einzelner Zellen muss auch nach dem Wechsel zur Verfügung stehen. Für solche Fälle ist ein Modell-View-Controller-Ansatz geeignet. Als Modell steht eine zentrale HashMap-Datenstruktur zur Verfügung. Sie gibt Auskunft über die Belegung einer Zelle sowie die Fahrtrichtung des sich darauf befindlichen Fahrzeugs. Die Zellen der betroffenen Karte fragen diese Informationen beim Wechsel ab und aktualisieren dementsprechend ihre Zustände. Die Fahrzeuge spielen die Rolle des Controllers. Sie verändern das Modell sobald sie ihre Position geändert 114

115 7.1 Ausgewählte Aspekte der Simulation Model Z1 Z2 belegt frei Z1 Z2 Z1 Z2 Übersichtskarte Ausschnittskarte Abbildung 7.2: Synchronisation des GUIs bei Kartenwechsel haben. Somit erfolgt die Aktualisierung der Zellenzustände und folglich der einzelnen Karten lediglich durch den Zugriff auf das Modell. Die Fahrzeuge bewirken damit keine direkte Zustandsänderung der verschiedenen Swing-Komponenten, die die Zellen modellieren. Dadurch wird jede mögliche Inkonsistenz der Zellenzustände vermieden Verwaltung der Routen Für das Erreichen des Zielortes eines Fahrzeugs ist die Ermittlung eines Weges zwischen dem Start und dem Ziel eine Notwendigkeit. Eine Routenermittlung kann dynamisch von einem Start und Ziel ausgehend erfolgen. In der Regel werden die kürzesten bzw. die schnellsten Routen berechnet. Die Berechnung orientiert sich an der Länge der Verbindungen zwischen dem Start- und Zielpunkt, bzw. an den maximalen Geschwindigkeiten, die zwischen den zwei Punkten gefahren werden dürfen. Die Laufzeit der Algorithmen, die diese Berechnungen durchführen, ist jedoch nicht zu vernachlässigen. Da der im Rahmen dieser Arbeit realisierte Simulator hauptsächlich zur Datenbereitstellung für den Monitor dient, wurde diese Berechnung aus Effizienzgründen nicht umgesetzt. Dennoch stellen sich für den Simulator hinsichtlich der Verwaltung der Routen ähnliche Anforderungen. Eine Fahrtroute setzt sich aus mehreren Strecken zusammen, die den Weg zwischen zwei Standorten beschreiben. In diesem Sinne weist eine Route eine gewisse Hierarchie auf. Für die Fortsetzung der Route ist die Reihenfolge der einzelnen Strecken von Relevanz. Eine Unabhängigkeit der Daten vom Code wird durch eine Umsetzung in XML ebenso ermöglicht wie ein Einsatz von Datenbanken, jedoch bietet sich 115

116 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG insbesondere XML für die Verwaltung der Routen an. Da XML besser als Datenbanken für hierarchische Datenstrukturierung mit Ordnungserhaltung geeignet ist, liegen die Fahrstrecken als XML-Datei vor. Darüber hinaus zeichnet sich XML mit einem für den Benutzer überschaubaren Format aus, sodass sich die Routen leichter erweitern lassen. Die Routen werden im Voraus festgelegt und beim Starten des SiMo -Systems einmalig geparst. Nach dem Parsen der XML-Datei werden die Routen dem Controller zur randomisierten Auswahl zur Verfügung gestellt. Da Abbiegevorgänge von den Routen abhängig sind und eine Entscheidung über die Abbiegerichtung nicht während des Programmablaufs getroffen werden kann, stehen zusätzlich Routen für die Realisierung von Falschabbiegern zur Verfügung. Aus diesem Grund wird mithilfe eines XML-Attributes vorentschieden, ob eine Route einem Falschabbieger zugeordnet werden kann. Andere Verkehrsregeln, wie z.b. Beachtung von Ampeln, sind unabhängig von der Routenwahl, sodass sie erst auf Java-Ebene betrachtet werden. Die Routen bestehen aus mehreren geraden Strecken. Ein XML-Element strecke zeichnet sich durch vier Attribute aus: von, bis, richtung und blinker. Das Element von bezeichnet die Startzelle, die den Anfang der Strecke festlegt. Die Festlegung der Zielzelle erfolgt durch das Attribut bis. Aus einem Paar von Start- und Zielzelle entsteht keine eindeutige Fahrstrecke, es wird zusätzlich eine Fahrtrichtung benötigt. Dies wird durch das Attribut richtung festgelegt. Auf die Richtung könnte im Fall eines einspurigen Verkehrsmodells verzichtet werden. Stattdessen reicht ein Vergleich der Koordinaten der Start- und Zielzellen aus, um die Richtung eindeutig zu definieren. Der hier realisierte Simulator unterstützt jedoch ein mehrspuriges Verkehrsmodell. Daher ist es unmöglich, eine eindeutige Fahrtrichtung herauszufinden, wenn die Start- und Zielzelle auf verschiedenen Spuren liegen. Eine Route lässt sich folgendermaßen beschreiben: <route id = "1" falschabbieger = "nein" name ="Autobahn-Roemerstr" > <strecke von="1745" bis="1648" richtung="ost" blinker="rechts"/> <strecke von="1649" bis="462" richtung="sued" blinker="links"/> <strecke von="466" bis="1150" richtung="ost" blinker="geradeaus"/> </route> Da sich die gesamte Route aus mehreren geraden Strecken zusammensetzt, ist beim Übergang von einer zur anderen Strecke meist ein Abbiegevorgang notwendig. Die Abbiegerichtung wird durch das Attribut blinker gesetzt und sorgt während der Simulation für eine angemessene und vorbildliche spätere Darstellung des Fahrtrichtungsanzeigers. Eine Ableitung der nächsten Abbiegerichtung kann zwar durch den Vergleich der Zellen zweier aufeinanderfolgender Strecken erfolgen, ist jedoch eine aufwändige Aufgabe. Da die Strecken statisch bleiben und innerhalb einer Route ihre Reihenfolge beibehalten, ist es effizienter, den Fahrtrichtungsanzeiger festzulegen. Um eine pflegeleichte Wartung des Routenplans zu ermöglichen und dessen Erweiterung dem Bearbeiter zu erleichtern, sind die Routen mit Namen versehen. Deterministisch stehen immer Start- und Zielzelle einer Strecke fest, zwischendurch ist dem Fahrzeug jedoch überlassen, bei mehrspurigen Straßen dynamisch Spurwechsel durchzuführen. Abbildung 7.3 zeigt eine Situation mit mehrspuriger Strecke und veranschaulicht zwei Möglichkeiten eines dynamischen Spurwechsels. 116

117 7.1 Ausgewählte Aspekte der Simulation Start Ziel Abbildung 7.3: Mehrspurige Strecke Generierung und Fortbewegung der Fahrzeuge Der Simulator soll in der Lage sein, eine große Anzahl von Fahrzeugen zu generieren und insbesondere angemessen fortzubewegen. Für den guten Verlauf der Simulation und die Stabilität des Systems ist die Verwaltung der großen Menge von Fahrzeugen daher von besonderer Bedeutung. Ferner zeichnet sich die Implementierung der Fahrzeuge durch verschiedene für den Monitor benötigte Fahrverhalten aus. Die Fahrzeuge in dieser Arbeit sind reflexbasierte Agenten mit internem Zustand. Sie verfügen über eine Menge von internen Zuständen, die ihr aktuelles Verhalten beschreiben können. Da der Fortbewegung der Fahrzeuge ein binäres Modell zugrunde liegt, können sie hinsichtlich ihrer Bewegung nur die zwei Zustände wartend oder fahrend annehmen. Darüber hinaus ergänzen die Eigenschaften Richtung, Position sowie Signalisierungszustand des Blinkers die Menge der internen Zustände. Die Umgebung der Fahrzeuge besitzt wiederum eine Menge von Zuständen. So umfasst diese Menge die Ampelzustände sowie die Belegung der Zellen durch andere Fahrzeuge. Besonders relevant ist die Existenz eines Vordermanns oder vorfahrtberechtigter Fahrzeuge. Die Fahrzeuge bewegen sich in Richtung ihres Ziels fort und weisen einen Zustandswechsel lediglich beim Eintritt bestimmter Ereignisse auf. Die Fahrzeuge reagieren auf folgende Ereignisse: Ampel auf Rot geschaltet vordere Zelle belegt vorfahrtberechtigtes Fahrzeug existiert Fahrzeug liegt nicht auf gewünschter Abbiegespur Fahrzeug liegt im Blinkerbereich Bei den ersten drei Ereignissen reagiert ein Fahrzeug, indem es vom Zustand fahrend auf den Zustand wartend umschaltet. Das vierte Ereignis tritt ein, wenn ein Fahrzeug einen Abbiegevorgang vornehmen möchte, es sich jedoch nicht auf der entsprechenden Fahrspur befindet. Die Reaktion erfolgt in diesem Fall durch eine Veränderung 117

118 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG der Position, wodurch ein Spurwechsel zustande kommt. Das fünfte Ereignis wird ausgelöst, falls sich ein Fahrzeug im Blinkerbereich befindet. Das Fahrzeug reagiert darauf je nach Absicht mit dem Setzen des Fahrtrichtungsanzeigers. Diese Reaktionen entsprechen den Aktionen bei der Multiagentensimulation und sind in Methoden gekapselt. Diese Methoden sorgen für ein regelgerechtes Verhalten der Fahrzeugagenten, das die Oberklasse Fahrzeug auszeichnet. Wie in Abschnitt erwähnt wurde, weisen die Unterklassen der Klasse Fahrzeug unterschiedliches ordnungswidriges Fahrverhalten auf und definieren somit die verschiedenen Fahrerprofile. Das Begehen einer Ordnungswidrigkeit wird dadurch ermöglicht, dass die Fahrzeuge keine Reaktionen auf die Ereignisse zeigen. Dies wird dadurch realisiert, dass die Aktionsmethoden der Oberklasse Fahrzeug überschrieben werden. In der Methode bei rot anhalten() der Oberklasse z.b. wird das Signalbild des Signalgebers bei den Zufahrten auf Rot überprüft und gegebenfalls angehalten. In der Klasse FahrzeugAmpel, welche ein die Ampel missachtendes Fahrzeug darstellt, wird diese Methode durch eine leere Methode überschrieben. Somit lassen sich verschiedene Fahrertypen modellieren. Im Folgenden soll auf die Generierung sowie die Problematiken, die bei der Verwaltung der Fahrzeuge entstehen, eingegangen werden. Generierung und Verwaltung der Fahrzeuge Die Generierung der Fahrzeuge stellt eine der wichtigen Aktivitäten des Simulators dar. Ein besonderer Aspekt hierbei ist, dass fortlaufend Fahrzeuge erzeugt werden müssen und mithilfe der verschiedenen Fahrerprofile unterschiedliche Verkehrsszenarien gestaltet werden können. Abbildung 7.4 veranschaulicht den gesamten Ablauf vom Start der Simulation bis zur Generierung von Fahrzeugen in Form eines Sequenzdiagramms. Da die Klasse SIMMain für die benutzerseitige Steuerung der Simulation verantwortlich ist, wird hier der Simulationsprozess initialisiert. Hat der Benutzer die Simulation gestartet, wird ein Event ausgelöst und damit die Methode actionperformed() aufgerufen. Die fortlaufende Generierung der Fahrzeuge wird grundlegend durch einen Timer realisiert. Timer dienen der zeitgesteuerten Ausführung von Methoden. In diesem Sinne werden die Fahrzeuge in regelmäßigen Zeitabständen wie folgt erzeugt: timer.schedule(new SIMTask(), 0, Settings.getSleep_time_ms()*8); Dafür ist die Übergabe eines TimerTasks an die Klasse Timer notwendig. Die Klasse TimerTask umfasst Operationen, die in wiederholten Zeitabständen auszuführen sind. Die Zeitabstände sind Vielfache der Dauer eines Simulationsschrittes, die in einer XML-Konfigurationsdatei enthalten ist und je nach Bedarf vom Benutzer geändert werden kann. Die TimerTask-Klasse SIMTask ist so gesehen ein Verwaltungsthread, der nebenläufig eine Operation durchführt. Im Simulationskontext besteht diese Operation darin, Objekte der Klasse Start zu erzeugen. Diese Klasse sorgt dafür, dass neue Fahrzeuge generiert werden. Abhängig von der vom Benutzer festgelegten Dichte wird eine obere Grenze der Anzahl zu generierender Fahrzeuge 118

119 7.1 Ausgewählte Aspekte der Simulation!! Abbildung 7.4: Erzeugungsprozess der Fahrzeuge (random fahrzeug) gesetzt. Da in dieser Arbeit viel Wert auf Fahrerprofile gelegt wird, gibt es noch eine stochastische Variable verstoss art, die dynamisch das Fahrverhalten bestimmt. Wie der folgende Code zeigt, werden durch die Werte dieser Variable entsprechende Unterklassen der Klasse Fahrzeug generiert: for (int i = 1; i <= random_fahrzeug ; i++) { switch(verstoss_art) { case 10: FahrzeugVorfahrt fvorfahrt = new FahrzeugVorfahrt(); fvorfahrt.start(); break;...(weitere Fälle) default: Fahrzeug fahrzeug = new Fahrzeug(); fahrzeug.start(); } } Mit dem Erzeugen eines Fahrzeugs als Java-Objekt wird ein entsprechender Datensatz in der Datenbank angelegt. Die Datenbankeinträge sind zum einen für die Beachtung der Verkehrsregeln erforderlich und ermöglichen zum anderen den Datenaustausch mit dem Monitor. Für jedes Fahrzeug existiert ein Tupel in der Tabelle fahrzeug, das bei Zustandsänderung aktualisiert wird. 119

120 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Regelung der Verkehrsdichte Für eine realistische Nachbildung des Verkehrsaufkommens ist die Verkehrsdichte einer der wichtigsten Parameter, worauf bei dieser Verkehrssimulation geachtet werden soll. Die Dichte lässt sich als Anzahl von zur Zeit sich auf den Straßen befindlichen Fahrzeuge im Verhältnis zur gesamten Fläche definieren. Die Fläche lässt sich über die Anzahl der Zellen des Simulationsgebiets definieren. Mit bloßem Auge kann die Entwicklung der Verkehrsdichte im Laufe der Simulation nicht genau untersucht werden. Zur Validierung des Modells wurde daher die Anzahl der Fahrzeuge pro Simulationsschritt im gesamten Simulationsgebiet gemessen und grafisch dargestellt. Diese Analyse der Verkehrserzeugung ergab, dass bei kontinuierlicher Fahrzeugerzeugung die Anzahl der Fahrzeuge stets ansteigt. Zurückzuführen lässt sich diese Beobachtung darauf, dass die Fahrzeuge das Simulationsgebiet nicht so schnell verlassen konnten, wie sie hineingekommen sind. Ein Grund dafür ist, dass die maximale Anzahl der zu erzeugenden Fahrzeuge zwar durch eine variierende Obergrenze beschränkt wurde, jedoch keine Anpassung an die aktuelle Verkehrsdichte stattfand. Die Lösung besteht darin, die Fahrzeuge mit Berücksichtigung der Verkehrsdichte zu generieren. Dies wird durch eine Observer-Klasse realisiert, die nebenläufig die Anzahl der Fahrzeuge bezüglich der Verkehrsdichte anpasst: while(!simmain.stop) { dichte = ((double)start.fahrzeuge.size())/anzahlzellen; } if(dichte*100>simmain.slidervalue) { SIMMain.anz_fahrzeuge = 1; } else { SIMMain.anz_fahrzeuge = SIMMain.slidervalue/2; }...// Für kurze Zeit warten In regelmäßigen Zeitabständen wird die Dichte berechnet. Wenn dieser Wert über einem vom Benutzer gewünschten Schwellenwert liegt, sollen dementsprechend weniger Fahrzeuge generiert werden. Wie bereits erläutert, erfolgt die Bestimmung der Anzahl zu generierender Fahrzeuge per Zufallsprinzip. Die Obergrenze dieser Anzahl wird daher auf eins heruntergesetzt, sobald die Dichte in Prozent den vom Benutzer festgelegten Wert überschreitet. Ansonsten wird die maximale Anzahl der Fahrzeuge gemäß dem benutzerdefinierten Schwellenwert festgelegt. Abbildung 7.5 zeigt die Ergebnisse der Messungen vor und nach dem Einsatz des Observers. 120

121 7.1 Ausgewählte Aspekte der Simulation 700 Anzahl der Fahrzeuge h Ohne Observer Mit Observer Simulationsschritt Abbildung 7.5: Anzahl Fahrzeuge bzgl. Simulationszeit Fortbewegung der Fahrzeuge Nachdem ein Fahrzeug generiert wurde, soll es in der Lage sein selbständig auf dem Straßennetz fahren zu können. Dafür benötigt das Fahrzeug als autonomer Agent sowohl einen Start- als auch einen Zielpunkt einer Route, die im XML-Routenskript festgelegt sind. Per Zufall wird daher dem Fahrzeug eine Route zugeordnet. Es wird über die einzelnen Strecken einer Route iteriert, bis das Fahrzeug die Zielzelle der letzten Strecke erreicht hat. Dank der Ausrichtung der Zellen in einem Gitter, kann der Fahrzeugagent ausgehend von einem Tripel von Fahrtrichtung, Start- und Zielzelle seine nächste Zelle ermitteln. Abbildung 7.6 zeigt die Ermittlung der nächsten Zelle für den Fall, dass die Fahrtrichtung Ost ist. In diesem Fall wird der Wert der X-Koordinate solange inkrementiert, bis die Zielzelle der Strecke erreicht wurde. Für andere Fahrtrichtungen lässt sich analog die nächste Zelle bestimmen. y x x+1 x+2... Start Ziel Abbildung 7.6: Ermittlung der nächsten Zelle 121

122 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Der Simulation in dieser Arbeit liegt ein mikroskopisches Modell zugrunde, um eine genaue Beobachtung des Straßenverkehrs zu ermöglichen. Dieses Modell benötigt einen großen Detaillierungsgrad. Der Einsatz einer Multiagentensimulation trägt zur Bewältigung der Systemkomplexität bei und verleiht der Simulation einen realistischen Aspekt. Die Fahrzeuge sollen als innerhalb eines Multiagentensystems handelnde Einheiten einzeln betrachtet und nachgebildet werden. Aus diesem Grund ist jedes Fahrzeug als Thread implementiert worden und verfolgt seine Route mit Reaktion auf seine Umgebung, um sein Ziel zu erreichen. Diese Individualität ist auf die Aktualisierung des GUIs übertragbar. Für eine realistische Darstellung wird die Karte nicht global neu gezeichnet. Stattdessen aktualisiert daher jedes Fahrzeug grafisch seinen Zustand nach jedem Zellenwechsel Beachtung der Verkehrsregeln Neben der Simulation von ordnungswidrigem Fahrverhalten bleibt die Beachtung von Verkehrsregeln eine der wichtigsten Aufgaben, die der Simulator erfüllen soll. Mit anderen Worten bedeutet dies, dass bei der Simulation auf der einen Seite dafür gesorgt wird, dass verschiedene Fahrertypen für die Missachtung der Regeln erzeugt werden. Auf der anderen Seite soll gleichzeitig auf die Einhaltung der Verkehrsregeln geachtet werden. Relevant für das betrachtete Simulationsgebiet sind besonders die Beachtung der Lichtsignalanlagen, Vorfahrtstraßen und Rechts-vor-Links-Knoten. Als Beispiel für die Umsetzung dieser Regeln wird in diesem Abschnitt auf die letzte Regel eingegangen. Die Arbeitshypothese in dieser Diplomarbeit ist, dass SQL für die Analyseaufgaben auf großen Datenmengen eine Alternative zur imperativen Vorgehensweise darstellt. In diesem Sinne wurden die Verkehrsregeln als SQL-Sichten formuliert. Die Beachtung der Verkehrsregeln erfolgt durch eine kontinuierliche Auswertung dieser Views ( continuous queries ). Dementsprechend baut auch die Rechts-vor-Links-Regel auf den Tabellen der Datenbank auf. Lookahead-Zelle Abbildung 7.7: Lookahead-Zelle 122

123 7.1 Ausgewählte Aspekte der Simulation Bei der Rechts-vor-Links-Regel geht es für ein in die Kreuzung einfahrendes Fahrzeug darum, sich zu vergewissern, dass sich kein vorfahrtberechtigtes Fahrzeug von rechts nähert. Netzknoten, auf denen für die Vorfahrt nur die Rechts-vor-Links-Regel gilt, sollen als Rechts-vor-Links-Knoten bezeichnet werden. Für die deskriptive Formulierung der Rechts-vor-Links-Regel werden alle Rechts-vor-links-Knoten des Simulationsgebiets benötigt. Diese Netzknoten sind durch die View s RVL Knoten definiert. Sie selektiert alle Rechts-vor-links-Knoten, die, wie bereits im Entwurf erklärt wurde, mit der Vorfahrtsregelung RVL gekennzeichnet sind. Verfügt ein Netzknoten über keine vorfahrtregelnde Beschilderung und ist ihm eine LSA zugeordnet, die aktuell außer Betrieb ist, so gilt er auch als Rechts-vor-links-Knoten: CREATE VIEW s_rvl_knoten AS ( SELECT k.knoten_id FROM knoten k WHERE k.vorfahrtregelung= RVL UNION SELECT k.knoten_id FROM knoten AS k, lsa WHERE lsa.in_betrieb=false AND k.vorfahrtregelung= LSA_OB AND lsa.lsa_id = k.knoten_id; ) Ein Vorfahrtsfall innerhalb eines Rechts-vor-Links-Knotens liegt vor, wenn sich ein Fahrzeug auf einer Knotenzufahrt befindet und ein anderer auf der Zufahrt rechts von ihm steht. In diesem Fall hat der zweite Vorfahrt und der erste ist wartepflichtig. Von besonderer Relevanz bei der Beachtung der Rechts-vor-Links-Regel ist daher die Belegung der rechten Zufahrt des Wartepflichtigen. Eine genauere Betrachtung realer Verkehrsereignisse zeigt, dass für die Verkehrssicherheit weitere Zellen berücksichtigt werden müssen, um ein vorausschauendes Fahren zu ermöglichen. Gerade bei Vorfahrtsituationen kommt es wegen ein paar entscheidender Sekunden oft zu Unfällen. Dadurch motiviert soll nicht nur geprüft werden, ob die rechte Zufahrt des wartepflichtigen Fahrzeugs frei ist. Stattdessen wird zusätzlich mit einem Lookahead-Ansatz sichergestellt, dass die hintere Nachbarzelle der rechten Zufahrt nicht belegt ist. Abbildung 7.7 soll einen Rechts-vor- Links-Knoten darstellen. Das rote Fahrzeug ist in dieser Situation gegenüber dem grünen Fahrzeug wartepflichtig. Das rote Fahrzeug darf erst in die Kreuzung einfahren, wenn weder die gelb markierte Knotenzufahrt noch die rot gekennzeichnete Lookahead-Zelle belegt ist. Die Belegung der beiden Zellen wird durch die Sicht s check rvl überprüft. Eine Auswertung findet immer dann statt, wenn sich ein Fahrzeug auf einer Knotenzufahrt befindet. Diese Differenzierung zur Effizienzsteigerung ist der Zellenkategorisierung 123

124 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG auf Java-Ebene zu verdanken. Die Sicht s check rvl wird durch eine Vereinigung der beiden Views s rvl zufahrt und s rvl lookahead realisiert: CREATE VIEW s_check_rvl AS ( SELECT Fahrzeug FROM s_rvl_zufahrt UNION SELECT Fahrzeug FROM s_rvl_lookahead ) Die erste View ist für die Prüfung der Belegung von Knotenzufahrten zuständig, die von einem vorfahrtberechtigten Fahrzeug besetzt werden können: CREATE VIEW s_rvl_zufahrt AS ( SELECT f.fahrzeug_id AS Fahrzeug FROM ( ( rechte_zufahrt rz INNER JOIN (knotenzufahrt kz INNER JOIN fahrzeug f ON kz.zellen_id = f.zellen_id) ON rz.zellen_id_zufahrt = f.zellen_id ) INNER JOIN s_rvl_knoten k ON kz.knoten_id = k.knoten_id) INNER JOIN fahrzeug AS f1 ON rz.zellen_id_rechtezufahrt = f1.zellen_id; ) Zunächst sind bei dieser Regel lediglich die Knotenzufahrten von Interesse, die von einem Fahrzeug belegt sind. Weiterhin sollen sich nur solche Fahrzeuge qualifizieren, deren rechte Zufahrt von einem anderen Fahrzeug besetzt ist. Diese zwei Bedingungen werden durch die Joins zwischen den Tabellen knotenzufahrt, fahrzeug und rechte zufahrt überprüft. Solch eine Regel macht nur Sinn, wenn sich die zwei im Vorfahrtsfall beteiligten Fahrer innerhalb desselben Netzknotens befinden. Auf diese Überprüfung kann verzichtet werden, da die Relation rechte zufahrt jeweils nur Zufahrten desselben Netzknoten verbindet. Ein Join mit der View s RVL Knoten stellt zusätzlich sicher, dass es sich um einen Rechts-vor-Links-Knoten handelt. Schließlich wird überprüft, ob die rechte Zufahrt tatsächlich von einem vorfahrtberechtigten Fahrzeug besetzt ist. Darüber hinaus prüft die View s rvl lookahead noch die Lookahead-Zelle des wartepflichtigen Fahrzeugs auf Belegung. Dies wird mithilfe eines Zugriffs auf die Tabelle nachbarzellen ermöglicht. Da aus symmetrischen Gründen keine hinteren 124

125 7.2 Ausgewählte Aspekte des Monitorings Nachbarzellen explizit gespeichert wurden, wird die gewünschte Zelle aus einem anderen Blickwinkel betrachtet. Die erforderlichen Nachbarzellen sind solche Zellen, die eine Knotenzufahrt als vorigen Nachbarn ( V ) besitzen. Die View s rvl lookahead ist zu Beginn genauso wie die View s rvl zufahrt aufgebaut. Der Unterschied liegt in der Einbindung der Tabelle nachbarzellen, sodass Fahrzeuge auf den Lookahead-Zellen betrachtet werden können. Dies wird in den mit (1) und (2) gekennzeichneten Teilen umgesetzt: CREATE VIEW s_rvl_lookahead AS ( SELECT f.fahrzeug_id AS Fahrzeug FROM ( ( ( rechte_zufahrt rz INNER JOIN (knotenzufahrt kz INNER JOIN fahrzeug f ON kz.zellen_id = f.zellen_id) ON rz.zellen_id_zufahrt = f.zellen_id ) INNER JOIN s_rvl_knoten k ON kz.knoten_id = k.knoten_id ) (1)INNER JOIN nachbarzellen n ON rz.zellen_id_rechtezufahrt = n.nachbar_id ) (2)INNER JOIN fahrzeug AS f1 ON n.zellen_id = f1.zellen_id WHERE (n.lage= V ); ) Zur Beachtung der Rechts-vor-Links-Regel werden demnach zwei Zellen bezüglich vorfahrtberechtigter Fahrzeuge in Betracht gezogen. Eine Erweiterung der View s rvl lookahead ist möglich, indem analog und mit demselben Schema weitere Zellen transitiv auf Belegung überprüft werden. 7.2 Ausgewählte Aspekte des Monitorings Stehen simulierte Daten in der Datenbank zur Verfügung, so kann das Monitoring einsetzen, um den Verkehr auf regelgerechtes Verhalten zu kontrollieren. Abschnitt gab bereits einen Einblick in die Arbeitsweise des Monitors. Die in Echtzeit vollzogene Überprüfung der Fahrzeugdaten hinsichtlich begangener Regelverstöße ist keine triviale Angelegenheit. Die Formulierung der SQL-Anfragen zur Überwachung der Regelverstöße muss zunächst aus natürlichsprachlichen Texten herausgearbeitet 125

126 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG werden. Weiterhin produziert der Simulator in kürzester Zeit viele Datensätze, wodurch die Tabellen in der Datenbank stark anwachsen. Daher müssen zum einen die zur Überwachung eingesetzten SQL-Anfragen effizient ausgewertet und zum anderen eine möglichst optimale Löschstrategie für nicht mehr benötigte Daten eingesetzt werden Formulierung der Regelverstöße in SQL Die Besonderheit des Monitors drückt sich dadurch aus, dass Verkehrsregelverstöße in der DB-Anfragesprache SQL formuliert wurden und mithilfe von SQL-Anfragen die Daten in Echtzeit auf Regelverstöße überprüft werden. Im Folgenden soll gezeigt werden, dass sich Ordnungswidrigkeiten in SQL ausdrücken lassen. Im Gegensatz zum Simulator, der durch die Verkehrsregeln mithilfe von SQL-Anfragen den nächsten Zustand plant, geht es bei der Überprüfung von Regelverstößen um den Vergleich verschiedener Fahrzeugzustände. Der Monitor selbst hat kein Wissen über den Verlauf des Verkehrs, sondern muss stattdessen die Informationen aus den einzelnen Zuständen herleiten. Die Daten zu den simulierten Fahrzeugen und Lichtsignalanlagen sind für den Monitor in den Tabellen sm fahrzeug und sm LSA gespeichert: sm_fahrzeug(zeit, fahrzeug_id, zellen_id, blinker, geschwindigkeit, fahrtrichtung) sm_lsa(zeit, lsa_id, phase, in_betrieb) Im Vergleich zu den Tabellen fahrzeug und lsa enthalten die mit sm gekennzeichneten Tabellen alle Zustände der Fahrzeuge und LSAs. Sie sind zur Rekonstruktion der Szenarien mit einem Zeitstempel versehen. Darüberhinaus gehen die statischen Informationen über die Straßentopologie in die Analyse mit ein. Die Ordnungswidrigkeiten, die einen Verstoß gegen die bereits in Unterkapitel 3.2 beschriebenen Regeln der StVO darstellen, werden in Form von SQL-Anfragen für das Monitoring auf den Datensätzen eingesetzt. Der im Rahmen dieser Arbeit entwickelte Monitor überprüft die folgenden sieben Passagen der Straßenverkehrsordnung, welche für das Fahrverhalten auf einer Kreuzung relevant sind: Gewähr der Vorfahrt bei Rechts-vor-Links-Knoten ( 8, Abs.1) Gewähr der Vorfahrt bei vorhandenen Vorfahrtzeichen ( 41, Abs.2, Nr.1b) Gewähr der Vorfahrt bei Abbiegevorgängen nach links ( 9, Abs.4) Beachtung der Wechsellichtzeichen ( 37, Abs.1, Nr.1) Abbiegen gemäß vorgeschriebener Fahrtrichtung ( 41, Abs.2, Nr.2) Korrekter Einsatz des Fahrtrichtungsanzeigers ( 9, Abs.1, Satz 1) Halt vor Kreuzung bei stockendem Verkehr ( 11, Abs. 1) Die SQL-Anfragen sollen genau dann ein Ergebnis liefern, wenn die Eigenschaften eines Fahrzeugs innerhalb eines Knotens nicht mit diesen Vorschriften übereinstimmen. Die Umsetzung natürlichsprachlicher Beschreibungen der Verkehrsverstöße in die formale Sprache SQL erfordert die Durchführung verschiedener Schritte. 126

127 7.2 Ausgewählte Aspekte des Monitorings Zunächst müssen Definitionen von grundlegenden Begriffen aus der natürlichen Sprache formaler definiert werden. Dies ist zum einen die Repräsentation von Fahrzeugen und Ampeln sowie der gesamten Straßentopologie, die bereits in Unterkapitel 5.2 ausführlich behandelt wurden. Ferner gehören dazu insbesondere die abstrakten Begriffe, die selbst durch das deutsche Gesetz nicht eindeutig festzuhalten sind. So wird oftmals ein fehlerhaftes Verhalten als Ordnungswidrigkeit geahndet, wenn dabei die Behinderung eines anderen Fahrzeugs vorliegt. In diesem Zusammenhang soll eine Behinderung genau dann vorliegen, sobald sich ein Fahrzeug auf einer Zelle befindet, die unmittelbar vor einem anderen Fahrzeug liegt. Dies bedeutet weiterhin, dass das Fahrzeug, dessen Verkehrsteilnehmer behindert wird, in diese Richtung ausgerichtet sein muss und nun wegen belegter Zellen nicht ohne Beeinträchtigung seinen Weg fortsetzen kann. Ein Fahrzeug gilt als wartend, wenn es sich länger als eine Zeiteinheit auf einer Zelle befindet. Bevor eine komplexe SQL-Abfrage entwickelt wird, ist es von Vorteil, die Ordnungswidrigkeiten gegen die entsprechenden Gesetze der StVO in konkrete auf das relationale Datenbankkonzept abbildbare Sätze umzuformulieren. Die einzelnen Zustände und Beziehungen der Fahrzeuge und Ampeln untereinander sind hierbei einzeln zu identifizieren. Sind die Begrifflichkeiten klar definiert und die einzelnen Kriterien herausgearbeitet, muss eine Umsetzung in SQL gefunden werden. Für eine dynamische Implementierung vom Melden und Logging von Regelverstößen ist eine einheitliche Information in der Zielliste der SQL-Anfragen wünschenswert, die für alle Regelverstoß- Kategorien gleichermaßen ausgewählt wird. Für das Wiedererkennen eines gemeldeten Regelverstoßes in einer Datenmenge sind daher die beteiligten Fahrzeuge sowie der Zeitpunkt des Geschehens und der zugehörige Knoten relevant. Die Art des Regelverstoßes ist ebenfalls wichtig, muss jedoch nicht explizit selektiert werden, da sich jede Abfrage bereits eindeutig einem entsprechenden Regelverstoß zuordnen lässt. Die Anzahl der selektierten Fahrzeuge - eins oder zwei - ist abhängig von der Art des Regelverstoßes. So betrifft der Rotlichtverstoß lediglich ein einzelnes Fahrzeug, wohingegen bei Missachtung der Vorfahrt zwei Fahrzeuge beteiligt sind. Ist eine Formulierung in der Anfragesprache SQL gefunden, ist eine Analyse der Performanz notwendig. So können eventuell unnötige Teilabfragen eliminiert oder die gesamte Abfrage sowie die physische Organisation der Tabellen optimiert werden. Im Allgemeinen wird angenommen, dass die Verkehrsteilnehmer weder gegen das Rechtsfahrgebot ( 2) verstoßen noch generell die Fahrstreifen in falscher Richtung befahren. Außerdem wird davon ausgegangen, dass Fahrzeuge nicht zweimal denselben Knoten befahren. Im Folgenden wird eine Auswahl der formulierten SQL- Anfragen vorgestellt, wodurch repräsentativ das Vorgehen beschrieben und einzelne Problemstellungen erläutert werden sollen. 127

128 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Gewähr der Vorfahrt bei vorhandenen Vorfahrtzeichen Bei Existenz der Zeichen Vorfahrt gewähren! und Halt! Vorfahrt gewähren! muss gemäß 8 der StVO auf vorfahrtberechigte Fahrzeuge geachtet werden. Ein Verstoß gegen diese Regel hat verschiedene Kriterien zu erfüllen: 1. Ein Fahrzeug befindet sich auf einer Knotenzufahrt, der ein Verkehrszeichen mit der StVO-Zeichen-Nr. 205 ( Vorfahrt gewähren! ) oder 206 ( Halt! Vorfahrt gewähren! ) zugeordnet ist. 2. Ein vorfahrtberechtigtes Fahrzeug befindet sich auf einer Zufahrt rechts oder links des Wartepflichtigen bzw. potentiell Vorfahrtnehmenden. 3. Der Wartepflichtige steht zu einem späteren Zeitpunkt auf einer Knotenzelle vor der Zufahrt oder einer Knotenzelle des Vorfahrtberechigten (zeitgleich). 4. Falls dem Knoten eine Lichtsignalanlage zugeordnet ist, muss diese außer Betrieb sein, damit eine Betrachtung der Vorfahrtzeichen überhaupt in Frage kommt. 1) 2a) 2b) Abbildung 7.8: Kriterien der Vorfahrtmissachtung am Beispiel 128

129 7.2 Ausgewählte Aspekte des Monitorings Abbildung 7.8 veranschaulicht, welche Bedingungen zu beachten sind. Das rote Fahrzeug stellt das wartepflichtige, das grüne das vorfahrtberechtigte Fahrzeug dar. Situation 1 stellt die Voraussetzung einer Vorfahrtverletzung dar. Für das Eintreten einer Vorfahrtverletzung, muss sich ein Fahrzeug von der linken oder rechten Seite nähern. Es ist nicht zwingend notwendig, dass die Fahrzeuge zeitgleich die beiden Zufahrten belegen, da ein vorausschauendes Fahren erwartet wird und auch Fahrzeuge auf Lookahead-Zellen zu beachten sind (vgl. Abschnitt 7.1.4). Situation 2a) zeigt die entscheidende Situation. Hier wird der Vorfahrtberechtigte durch das rote Fahrzeug an der Weiterfahrt gehindert. Situation 2b) stellt hingegen keine Vorfahrtverletzung dar und verdeutlicht die Relevanz der Betrachtung von Fahrzeugausrichtungen. Die Nachbarschaft der Zellen mit alleiniger Einbeziehung der Lage würde auch in dieser Konstellation besagen, dass die Zelle des roten Fahrzeugs vor der Zelle des grünen Fahrzeugs liegt (vgl. Abschnitt 5.2.1). Aus diesem Grund gilt die Zusatzbedingung, dass der Wartepflichtige der Ausrichtung des vorfahrtberechtigten Fahrzeugs entsprechend davor liegt. Für die Beobachtung dieser Zustände lassen sich vorab zwei Sichten definieren. Für Bedingung 1 sind alle Zellen erforderlich, denen ein vorfahrtregelndes Vorschriftzeichen zugeordnet ist: CREATE VIEW vorfahrt_zellen AS (SELECT zellen_id FROM zeichen_zuordnung INNER JOIN (SELECT * FROM verkehrszeichen WHERE verkehrszeichen.stvo_zeichen_nr= 205 Or verkehrszeichen.stvo_zeichen_nr= 206 ) AS v ON v.zeichen_id=zeichen_zuordnung.zeichen_id ) Hierbei wird die Tabelle zeichen zuordnung mit der Tabelle verkehrszeichen verknüpft. Dabei qualifizieren sich solche Zellen, denen ein Vorfahrtzeichen mit StVO- Zeichen-Nummer 205 oder 206 zugeordnet ist. Da es sich bei dem Input für das Monitoring um eine diskrete Simulation handelt und ein tatsächlicher Halt eines Fahrzeugs nicht gemessen werden kann, wird zwischen diesen beiden Verkehrszeichen nicht unterschieden. Für die Erkennung der Regelverstöße spielen meist die Bewegungen der Fahrzeuge eine bedeutende Rolle. Einzelne unabhängig voneinander betrachtete Positionen ergeben noch keine ausreichenden Informationen. Somit ist es erforderlich, zwei 129

130 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Positionen eines Fahrzeugs in Bezug zueinander zu bringen. Diese oft benötigte Datenmenge wird daher zur Übersichtlichkeit in eine Sicht ausgegliedert: CREATE VIEW fahrzeug_1_2_le AS ( SELECT f1.zellen_id AS zellen_id_1, f1.fahrzeug_id, f1.zeit AS zeit_1, f2.zellen_id AS zellen_id_2, f2.fahrtrichtung, f2.zeit AS zeit_2 FROM sm_fahrzeug AS f1 INNER JOIN sm_fahrzeug AS f2 ON f1.fahrzeug_id=f2.fahrzeug_id WHERE f1.zeit<f2.zeit ) Wie die Sicht zeigt, sind die Bedingungen für die Bildung eines neuen Tupels die Gleichheit in fahrzeug id und die Einschränkung, dass die erste Position zeitlich vor der zweiten Position liegt. Das Kürzel LE im Namen der Sicht soll kennzeichnen, dass die Bedingung im WHERE-Teil ein < verwendet. Eine äquivalente Sicht mit, die auch Fahrzeugpositionen zum selben Zeitpunkt erlaubt, trägt den Namen fahrzeug 1 2 LEQ. Mithilfe der identifizierten Kriterien und der soeben definierten Sichten ist die Abfrage für ein Missachten der Vorfahrt wie folgt formulierbar: SELECT DISTINCT ff.zeit_1 AS zeit, ff.fahrzeug_id, vv.fahrzeug_id AS fahrzeug_id_v, knotenzelle.knoten_id FROM ((((( fahrzeug_1_2_le ff (1) INNER JOIN vorfahrt_zellen ON vorfahrt_zellen.zellen_id=ff.zellen_id_1) (2) INNER JOIN knotenzelle ON knotenzelle.zellen_id=ff.zellen_id_2) (3) INNER JOIN zufahrt_quer ON ff.zellen_id_1=zufahrt_quer.zellen_id_zufahrt) (4) INNER JOIN fahrzeug_1_2_leq AS vv ON vv.zellen_id_1=zufahrt_quer.zellen_id_quer) (5) INNER JOIN (SELECT * FROM nachbarzellen WHERE lage = V ) AS n ON n.nachbar_id=ff.zellen_id_2 AND n.zellen_id=vv.zellen_id_2 AND n.fahrtrichtung=vv.fahrtrichtung) WHERE vv.zeit_2 IN (SELECT max(zeit) FROM sm_fahrzeug WHERE zeit <= ff.zeit_2 AND fahrzeug_id = vv.fahrzeug_id) AND NOT EXISTS (SELECT * FROM m_signalbild s WHERE s.zellen_id = ff.zellen_id_1 AND s.zeit = (SELECT max(zeit) FROM m_signalbild WHERE zeit <= ff.zeit_1 AND zellen_id = ff.zellen_id_1)); 130

131 7.2 Ausgewählte Aspekte des Monitorings Zunächst wird mit der Sicht fahrzeug 1 2 LE ff das Fahrzeug betrachtet, welches potentiell einen Regelverstoß begehen könnte. Die zellen id der ersten Fahrzeugposition muss nach Bedingung 1 einer Knotenzufahrt aus der Sicht vorfahrt zellen zuordenbar sein. Um einem Vorfahrtberechtigten die Vorfahrt nehmen zu können, soll die zweite Position hingegen innerhalb des Kreuzungsbereichs liegen, sodass das Zwischenergebnis nach dem ersten Join mit der Tabelle knotenzelle verknüpft wird. Schließlich muss noch der Bezug zum vorfahrtberechtigten Fahrzeug hergestellt werden. Wichtig ist, aus welchen Richtungen sich die beiden Fahrzeuge nähern. Es wird angenommen, dass keine abknickenden Vorfahrten existieren. In diesem Fall soll das vorfahrtberechtigte Fahrzeug auf einer Knotenzufahrt quer zu derjenigen Zufahrt stehen, auf dem sich das Fahrzeug ff zum Zeitpunkt ff.zeit 1 befindet. Die links und rechts einer Zufahrt liegenden Zellen sind in der materialisierten View zufahrt quer enthalten. Sie werden mit der Fahrzeugposition vv.zellen id 1 aus der Sicht vv für den Vorfahrtberechtigten in Verbindung gebracht. Durch den fünften Join mit der Tabelle nachbarzellen soll schließlich sicherstellt werden, dass das wartepflichtige Fahrzeug aus ff auf einer Zelle vor dem vorfahrtberechtigten Fahrzeug steht. Diese Behinderung ist das entscheidende Kriterium für den Regelverstoß. Das Ergebnis wird im WHERE-Teil noch durch zwei Bedingungen eingeschränkt. Zum einen müssen der Wartepflichtige ff und der Vorfahrtberechtigte vv zum selben Zeitpunkt zeit 2 benachbarten Zellen zugeordnet sein. Die über die Fahrzeuge gelieferten Informationen sind jedoch vom Simulator abhängig und stellen nicht für jeden Simulationsschritt eine Position des Fahrzeugs zur Verfügung. Somit kann kein einfacher Vergleich von Zeitpunkten, wie vv.zeit 2 = ff.zeit 2, als Bedingung in die Anfrage eingehen. Stattdessen muss der aktuelle Zeitpunkt eines Fahrzeugs im Vergleich zum anderen evaluiert werden. Daher benutzt die Anfrage die Aggregat- Funktion max(), um sicherzustellen, dass Vorfahrtberechtigter und Wartepflichtiger zum gleichen Zeitpunkt auf benachbarten Zellen platziert sind: vv.zeit_2 IN (SELECT max(zeit) FROM sm_fahrzeug WHERE zeit <= ff.zeit_2 AND fahrzeug_id = vv.fahrzeug_id) Weiterhin sind Kreuzungen mit Lichtsignalanlage zu betrachten. Da Wechsellichtzeichen vorfahrtregelnden Verkehrszeichen vorgehen, darf die dortige Beschilderung erst dann in Betracht gezogen werden, wenn die zugehörige LSA zu diesem Zeitpunkt außer Betrieb ist. Eine Unterabfrage mit NOT EXISTS stellt die Erfüllung dieser Kriterium 4 betreffenden Bedingungen sicher. Sie liefert genau dann true, wenn entweder die dem Knoten zugeordnete LSA außer Betrieb ist oder der Knotenzufahrt kein Signalgeber zugeordnet und damit der Betriebszustand einer LSA irrelevant ist. Zu beachten ist der Sonderfall, dass zu einer durch eine LSA gesteuerte Kreuzung auch Knotenzufahrten gehören können, deren Durchfahrt durch kein Lichtsignal eingeschränkt wird und stattdessen die Verkehrssicherheit lediglich durch ein Vorfahrtzeichen geregelt ist. In diesem Fall wird der Wartepflichtige direkt in die gewünschte 131

132 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Abbildung 7.9: Sonderfall bei Beachtung der Vorfahrt Straße und nicht in den Kreuzungsbereich einfahren, sodass die Richtung, aus der sich das vorfahrtberechigte Fahrzeug nähert, irrelevant bleibt (siehe Abbildung 7.9). Da die zuvor beschriebene Abfrage nur die Tabelle zufahrt quer in die Auswertung einbezieht, bleiben Zufahrten gegenüber dabei unbeachtet und eine zusätzliche Abfrage wird erforderlich. Die betroffenen Knotenzufahrten zeichnen sich dadurch aus, dass ihnen keine Knotenzelle als Nachbar zugeordnet ist. Für eine Vorfahrtverletzung muss sich der Vorfahrtnehmende stattdessen zum Zeitpunkt zeit 2 auf einer Knotenabfahrt befinden. Weiterhin ist nicht zu testen, über welche Knotenzufahrt der Vorfahrtberechtigte den Straßenknoten befahren hat. Mit Hinzunahme dieser leicht modifizierten Anfrage wird auch der Sonderfall abgedeckt. Beachtung von Wechsellichtzeichen Einer der gefährlichsten Regelverstöße ist das Überfahren der Kreuzung bei rotem Signalbild. Der Querverkehr verlässt sich bei eigenem grünem Licht darauf, dass er ohne Behinderung die Kreuzung überqueren kann, ohne auf kreuzende Fahrzeuge achten zu müssen. In der SQL-Umsetzung sind neben den Fahrzeugen auch die Lichtsignalanlagen von Bedeutung. Um eine Ordnungswidrigkeit melden zu können, müssen die folgenden Bedingungen erfüllt sein: 1. Zum Zeitpunkt 1 befindet sich ein Fahrzeug auf einer Knotenzufahrt k1, zum Zeitpunkt 2 ist es einer Knotenzelle zugeordnet, die vor dieser Knotenzufahrt liegt. 2. Dem Straßenknoten ist eine Lichtsignalanlage zugeordnet, die in Betrieb ist. 3. Der Knotenzufahrt k1 ist ein Signalgeber zugeordnet, der zum Zeitpunkt 1 sowie zum Zeitpunkt 2 auf Rot geschaltet ist. 132

133 7.2 Ausgewählte Aspekte des Monitorings Für die SQL-Anfrage wird die Sicht m signalbild rot benötigt, welche diejenigen Signalgeber-Zustände zurückliefert, bei denen die LSA in Betrieb ist und das Signalbild ein rotes Licht zeigt. Diese Information erhält man durch einen Join über sm lsa, signalgeber und phase: CREATE VIEW m_signalbild_rot AS ( SELECT p.signalbild, s.signalgeber_id, s.zellen_id, l.zeit, l.lsa_id FROM (sm_lsa AS l INNER JOIN signalgeber AS s ON s.lsa_id=l.lsa_id) INNER JOIN phase AS p ON p.signalgeber_id=s.signalgeber_id AND l.phase=p.phase WHERE l.in_betrieb=true AND p.signalbild= rot ) Die ebenfalls verwendetete Sicht m signalbild unterscheidet sich von der Sicht m signalbild rot in der fehlenden Selektion hinsichtlich des roten Signalbildes. Somit werden sowohl auf Rot als auch auf Grün geschaltete Signalgeber für eine Weiterverarbeitung eingesetzt. Die Abfrage zur Beobachtung des Rotlichtverstoßes lässt sich schließlich in zwei Teile strukturieren. Der erste Teil betrifft das Fahrzeug und seine Positionen aus Bedingung 1. Mithilfe der Sicht fahrzeug 1 2 LE werden alle Fahrzeuge selektiert, die zunächst auf einer Knotenzufahrt stehen und danach auf einer Nachbarzelle davor. Dabei kann bei Selektion der Nachbarzellen auf den Test der Fahrtrichtung verzichtet werden, da Knotenzufahrten lediglich ein Nachbar zugeordnet wird, der vor ihnen liegt. Der zweite Teil wählt über die Sicht m signalbild rot die auf Rot geschalteten Signalgeber aus. Dabei muss beschrieben werden, dass die Ampel während des Wechsels von einer zur anderen Zelle auf Rot geschaltet ist. Aufgrund der Diskretisierung wird dafür auch die Sicht m signalbild rot zweimal benötigt. Die beiden Inputs von Fahrzeugen und Signalgebern werden schließlich durch einen Join über die Knotenzufahrt verknüpft. Die Existenz eines Grünpfeils, der Rechtsabbiegern das Einfahren in die Kreuzung bei Rot erlaubt, wird ausgeschlossen. Der WHERE-Teil enthält den erforderlichen Zeit-Vergleich. Ähnlich wie in der Abfrage zur Vorfahrtmissachtung liegt in der Prüfabfrage für den Rotlichtverstoß ein Problem darin, dass die Phasenschaltung in größeren Abständen dokumentiert wird als die Fahrzeuge. Daher kann nicht für jeden möglichen Simulationsschritt ein Signalbild aus der Datenbank gelesen werden. Die Lösung liegt auch hier im Einsatz einer Maximumsberechnung, um z.b. zu überprüfen, ob beim Ereignis Fahrzeug auf Knotenzufahrt der Zustand Signalgeber zeigt Rot an eintritt: l1.zeit=(select max(l.zeit) FROM m_signalbild l WHERE l.zeit < ff.zeit AND l.signalgeber_id = l1.signalgeber_id) 133

134 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Des Weiteren soll eine auf Rot geschaltete Ampel im Sichtfeld des Fahrzeugführers liegen. Aus diesem Grund muss die Ampel bei Befahren der Knotenzufahrt bereits eine Zeiteinheit auf Rot geschaltet sein. Daher wird nach einem Signalbildeintrag gesucht, der vor dieser Zeit des betroffenen Fahrzeugs liegt (l.zeit < ff.zeit). Für die Fahrzeugposition im Kreuzungsbereich direkt vor der Ampel ist hingegen der aktuelle Datensatz zu selektieren, weswegen eine Gleichheit beider Zeiten zu bevorzugen ist. Damit lässt sich die Überprüfung des Regelverstoßes wie folgt in SQL umsetzen: SELECT DISTINCT ff.fahrzeug_id, ff.zeit_1 AS zeit, z1.knoten_id FROM ((fahrzeug_1_2_le AS ff INNER JOIN knotenzufahrt AS z1 ON ff.zellen_id_1=z1.zellen_id) INNER JOIN (SELECT * FROM nachbarzellen WHERE nachbarzellen.lage= V ) AS n ON n.zellen_id=ff.zellen_id_1 AND n.nachbar_id = ff.zellen_id_2) INNER JOIN (m_signalbild_rot AS l1 INNER JOIN m_signalbild_rot AS l2 ON l1.signalgeber_id=l2.signalgeber_id) ON l1.zellen_id=ff.zellen_id_1 WHERE l1.zeit=(select max(l.zeit) FROM m_signalbild l WHERE l.zeit < ff.zeit_1 AND l.signalgeber_id = l1.signalgeber_id) AND l2.zeit=(select max(l.zeit) FROM m_signalbild l WHERE l.zeit <= ff.zeit_2 AND l.signalgeber_id = l2.signalgeber_id); Abbiegen gemäß vorgeschriebener Fahrtrichtung Die Fahrtrichtungszeichen schreiben vor, in welche Richtung es Fahrzeugen erlaubt ist, abzubiegen. Im Einzelnen muss ein Verstoß gegen die vorgeschriebene Fahrtrichtung die folgenden zwei Bedingungen erfüllen: 1. Das Fahrzeug befindet sich auf einer Knotenzufahrt, der ein Fahrtrichtungszeichen zugeordnet ist. 2. Zu einem späteren Zeitpunkt befindet sich das Fahrzeug auf einer Abfahrt, die gemäß der vorgeschriebenen Fahrtrichtung verboten ist. linke_abfahrt rechte_abfahrt abfahrt_gegenüber Abbildung 7.10: Zuordnung der Zeichen zu nicht erlaubten Abfahrten 134

135 7.2 Ausgewählte Aspekte des Monitorings Für die Überprüfung dieser Ordnungswidrigkeit wurden fünf verschiedene Ausprägungen der Fahrtrichtungszeichen betrachtet: links, rechts, geradeaus, links und geradeaus sowie rechts und geradeaus. Bezogen auf das Erkennen einer Ordnungswidrigkeit können sie jeweils einer oder zwei der drei verbotenen Richtungen bzw. Abfahrten links, rechts oder geradeaus zugeordnet werden (siehe Abbildung 7.10). Somit besteht die Anfrage aus drei Teilanfragen, die durch eine Vereinigung (UNION) zu einem Endergebnis verbunden wird: SELECT unerlaubt.fahrzeug_id, unerlaubt.zeit, k.knoten_id FROM knotenzufahrt k INNER JOIN (rechts_unerlaubt UNION links_unerlaubt UNION geradeaus_unerlaubt) AS unerlaubt ON unerlaubt.zellen_id = k.zellen_id; Auf diese Weise wird zum Beispiel das Zeichen mit nach links zeigendem Pfeil den zwei Kategorien rechts und geradeaus zugeordnet. In den dafür zuständigen Unterabfragen rechts unerlaubt und geradeaus unerlaubt wird dann überprüft, ob ein Fahrzeug den Knoten über die verbotenen Knotenabfahrten verlässt. Die Sicht rechts unerlaubt, die für die Fahrtrichtungszeichen , und zutrifft, lässt sich folgendermaßen umsetzen: CREATE VIEW rechts_unerlaubt AS ( (SELECT ff.fahrzeug_id, ff.zeit_1 AS zeit, ff.zellen_id_1 AS zellen_id FROM ( (SELECT verkehrszeichen.zeichen_id FROM verkehrszeichen WHERE verkehrszeichen.stvo_zeichen_nr= Or verkehrszeichen.stvo_zeichen_nr= Or verkehrszeichen.stvo_zeichen_nr= ) AS v INNER JOIN zeichen_zuordnung zz ON v.zeichen_id=zz.zeichen_id ) INNER JOIN ( fahrzeug_1_2_le AS ff INNER JOIN rechte_abfahrt ra ON ra.zellen_id_rechteabfahrt=ff.zellen_id_2 AND ff.zellen_id_1=ra.zellen_id_zufahrt ) ON zz.zellen_id=ff.zellen_id_1) ) 135

136 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG Die Sicht besteht aus zwei logisch trennbaren Teilabfragen, die sich an den oben beschriebenen Kriterien orientieren. Zum einen werden alle Zufahrten selektiert, denen ein Verkehrszeichen mit nach links oder geradeaus zeigendem Pfeil zugeordnet sind. Zum anderen extrahiert die Abfrage solche Fahrzeuge, die von einer Zufahrt über eine rechte Abfahrt die Kreuzung verlassen. Ordnungswidrig verhalten sich all diejenigen Fahrzeuge, die durch den Join dieser beiden Teilergebnisse über die zellen id der Zufahrt einen Verbundpartner finden. Die Entscheidung für eine Unterteilung in drei Kategorien wird insbesondere durch die vorliegenden Tabellen linke abfahrt, rechte abfahrt und abfahrt gegenüber motiviert. Jede der verbotenen Fahrtrichungen kann einer der Relationen zugeordnet werden. Obige Sicht lässt sich daher für die Sichten links unerlaubt und geradeaus unerlaubt anpassen, indem die entsprechenden Verkehrzeichen gemäß Abbildung 7.10 selektiert werden und die Tabelle rechte abfahrt im FROM-Teil durch die Tabelle linke abfahrt bzw. abfahrt gegenüber ersetzt wird. Optimierung der Anfragen Die Tabelle sm fahrzeug wird in jedem Simulationsschritt mit neuen Daten gefüllt, sodass sie sehr große Mengen von Daten enthalten kann. Jeden zweiten Takt, beispielsweise jede Sekunde, müssen dabei sieben Anfragen über dieser Tabelle ausgewertet werden. Jede Anfrage referenziert dabei allein die Tabelle sm fahrzeug mindestens zweimal, weitere Tabellen müssen ebenfalls einbezogen werden. Dies macht die Anfrage besonders aufwändig, sodass eine möglichst effiziente Variante der Anfrageformulierung zu finden ist. Im Folgenden soll auf allgemeine Aspekte der Anfrageoptimierung eingegangen werden, die bei den zuvor beschriebenen Regelverstößen von Bedeutung waren. Um die Anzahl der Datensätze zu beschränken, merkt sich der Monitor in einer Variablen last checked den Zeitpunkt, zu dem er das letzte Mal die Anfrage ausgeführt hat. Anstatt die gesamte Tabelle für einen Join bereitzustellen, wird der Input mittels zeitlicher Bereichsanfrage eingegrenzt und die Anzahl der Tupel reduziert: PreparedStatement pst = Connection_Manager.getCon().prepareStatement( "... INNER JOIN (SELECT * FROM sm_fahrzeug WHERE zeit<=? AND zeit >?) AS f2 ON... "); pst.setint(1, now); pst.setint(2, last_checked); Dadurch können die Fahrzeugpositionen zu einem der Fahrzeuge reduziert werden. Die vorangestellte Selektion kann auf derjenigen Referenz der Tabelle sm fahrzeug angewandt werden, die ein Fahrzeug zum letztmöglichen Zeitpunkt repräsentiert. Eine Anwendung dieser Optimierung auf alle Eingaben der Fahrzeugtabelle würde zur Folge haben, dass Ergebnisse vorab unbeachtet bleiben, wenn es zum Abfragezeitpunkt noch keinen Regelverstoß zu melden gibt. 136

137 7.2 Ausgewählte Aspekte des Monitorings Ein weiterer Effekt dieser Bereichsanfrage liegt in der Vermeidung von Duplikaten bezüglich erkannter Regelverstöße. Ordnungswidrigkeiten würden ohne zusätzliche Selektion in das Endergebnis mit aufgenommen, solange ihre beteiligten Fahrzeug- Tupel noch nicht aus der Tabelle sm fahrzeug gelöscht wurden. Durch die verwendete Zeitspanne können Fahrzeuge in einer bestimmten Rolle nur einmal betrachtet werden. Somit kann vermieden werden, dass ein Regelverstoß dem Benutzer mehrmals angezeigt wird, obwohl sich das Fahrzeug bereits aus dem Überwachungsbereich heraus bewegt hat. Ebenso wird der Regelverstoß nur einmal geloggt. Um die Performanz verschiedener Varianten von Anfrageformulierungen zu vergleichen und eine bestmögliche Variante auswählen zu können, wurde die benötigte Anfragedauer gemessen. Abbildung 7.11 zeigt beispielhaft die Messergebnisse der Anfrage für die Überprüfung des Rotlichtverstoßes. Die bereits in diesem Abschnitt vorgestellte SQL-Anfrage wurde mithilfe von Joins umgesetzt. Anstelle von Joins ist im FROM-Teil jedoch auch eine simple Liste von Tabellen im Sinne von Kreuzprodukten denkbar, wobei die Bedingungen alle im WHERE-Teil überprüft werden. Auch eine Formulierung der Bedingungen durch EXISTS ist möglich, sodass der FROM-Teil lediglich die zur Ausgabe notwendigen Tabellen enthält. Das Diagramm zeigt die Dauer der drei Anfragen in Millisekunden bezüglich der Simulationszeit. Die Dauer eines Simulationsschrittes in diesen Messungen beträgt 500 ms. Um einen besseren Vergleich zu ermöglichen, wurde für jede Kurve eine Trendlinie erstellt. Rotlichtverstoß Anfragedauer (ms) Simulationsschritt Kreuzprodukt Join Exists Gleitender Durchschnitt (Kreuzprodukt) Gleitender Durchschnitt (Join) Gleitender Durchschnitt (Exists) Abbildung 7.11: Analyse der Performanz Die Messungen ergeben, dass die Variante mit EXISTS bedeutend schlechtere Ergebnisse liefert als eine Formulierung mit JOIN oder Kreuzprodukt. Dies lässt sich insbesondere darauf zurückführen, dass mit korrelierten Unterabfragen gearbeitet werden muss, welche für jeden Datensatz neu zu berechnen sind. Schließlich zeigt sich, dass sich die Formulierung mit Kreuzprodukt verglichen mit der JOIN-Variante 137

138 7 AUSGEWÄHLTE ASPEKTE DER IMPLEMENTIERUNG durch eine sehr ähnliche Anfragedauer auszeichnet. Die geringen Differenzen lassen sich erklären, wenn man einen Blick in den von MS Access generierten Auswertungsplan der Anfrage wirft. Durch eine DBMS-interne Optimierung der Kreuzprodukt- Anfrage wird erreicht, dass die Kreuzprodukte zur Auswertung durch eine Folge von Joins ersetzt werden. Eine weitere Analyse des Auswertungsplans macht deutlich, dass sich der query optimizer des Datenbankmanagementsystems an den Veränderungen der Tabellen orientiert. Mit Fortschreiten der Simulationszeit wird die Anfragebearbeitung stets an die Eigenschaften der Tabellen angepasst. Dies macht sich insbesondere durch Umordnung von Joins bemerkbar. Zudem zeigt das Diagramm, dass die Überwachung von Verkehrsszenarien bei einer Simulationsschrittdauer von 500 ms in Echtzeit zu bewältigen ist. Jede Sekunde - jeden zweiten Takt - wird die Abfrage neu ausgewertet, ohne dass die Anfragedauer die Umlaufzeit übersteigt. Eine erheblich bessere Performanz wurde darüber hinaus auch durch eine Materialisierung von Views erreicht. So müssten beispielsweise die Views linke zufahrt oder zufahrt quer in jeder Anfrage neu berechnet werden. Dieser Zeitaufwand lässt sich daher durch eine Materialisierung umgehen (vgl. Abschnitt 5.2.2) Verwaltung von Simulationsdaten und Regelverstößen Dieser Abschnitt beschäftigt sich mit der Verwaltung der Daten über Fahrzeuge und LSAs, die für das Monitoring von Regelverstößen relevant sind. Einerseits soll eine angemessene Protokollierung von Regelverstößen stattfinden, die eine eindeutige Rekonstruktion eines Szenarios in der Logging-Ansicht ermöglicht. Zum anderen ist es für die Stabilität des Systems von großer Bedeutung, dass eine effiziente Löschstrategie über den vom Simulator produzierten Daten eingesetzt wird. Zur Organisation erkannter Regelverstöße sind vier Tabellen erforderlich: m_regelverstoss_kat(regelverstoss_kat_id, stvo_ref, Beschreibung) m_logregelverstoss(regelverstoss_id, regelverstoss_kat_id, log_zeit, fahrzeug_id) m_logfahrzeug(regelverstoss_id, zeit, fahrzeug_id, zellen_id, blinker, geschwindigkeit, fahrtrichtung) m_loglsa(regelverstoss_id, zeit, lsa_id, phase, in_betrieb) Die Tupel der Tabelle m logregelverstoss repräsentieren die erkannten Regelverstöße. Es werden die Informationen über den Typ des Regelverstoßes, den Zeitpunkt des Erkennens und das schuldige Fahrzeug vermerkt. Die Regelverstöße sollen dabei in Reihenfolge ihres Auftretens durchnummeriert werden. In der Tabelle m logregelverstoss wird daher sofort ein neuer Datenbankeintrag mit neuer ID angelegt, sobald eine Abfrage ein positives Ergebnis erbracht hat. Die restlichen Daten zu Fahrzeugen und LSAs werden im Anschluss protokolliert. Um zu verhindern, dass das Protokollieren 138

139 7.2 Ausgewählte Aspekte des Monitorings der zu einem Regelverstoß gehörigen Datensätze den weiteren Verlauf der Verkehrsbeobachtung aufhält, ist diese Aufgabe stets in einen eigenen Thread ausgegliedert. Damit können die Knoten weiterhin in regelmäßigen Abständen kontrolliert werden, selbst wenn das Logging mehr Zeit in Anspruch nehmen würde. Logging von Fahrzeugen und LSA Wird ein Regelverstoß in einem gewissen Simulationsschritt erkannt, müssen die Fahrzeuginformationen geloggt werden, die diese Ordnungswidrigkeit charakterisieren (siehe Abbildung 7.12). Relevant ist dabei jeweils der gesamte Datensatz aus der Tabelle sm fahrzeug, weil dadurch ein Fahrzeug zu einem gewissen Zeitpunkt mit all seinen Eigenschaften dokumentiert ist. Die Anzahl der zu speichernden Fahrzeuge variiert mit der Kategorie der Regelverstöße. Ist der Regelverstoß von einem anderen Fahrzeug abhängig, wie es z.b. bei der Vorfahrtverletzung der Fall ist, so wird neben dem schuldigen Fahrzeug auch dieses protokolliert. Es wird angenommen, dass sich die Straßentopologie nicht ändert, sodass sie nicht gesondert abgespeichert werden muss. Bei erneutem Abspielen eines Regelverstoßes lässt sich auf die Basistabellen zugreifen, welche in Abschnitt beschrieben wurden. Für das Logging von Regelverstößen stellt sich die Frage, wie viele Datensätze jeweils relevant sind, um den Regelverstoß später wieder eindeutig rekonstruieren zu können. So kann das Intervall um den Meldezeitpunkt herum nicht mit einer bestimmten Zeitspanne festgelegt werden, da dies je nach Verkehrssituation stark variieren kann. Wichtig ist es stets, den Weg des Fahrzeugs mindestens von seiner Knotenzufahrt bis zur Knotenabfahrt verfolgen zu können. Die Dauer, die sich ein Fahrzeug innerhalb des Knotens aufhält, ist jedoch abhängig von der Größe des Knotens, der Verkehrsdichte, der Ampelschaltung und möglichem Gewähren der Vorfahrt/des Vorrangs. Abbildung 7.12: Logging von Fahrzeugen Um die relevanten Datensätze eines Fahrzeugs einzugrenzen, wurde daher die ID des Knotens herangezogen. Dies hat zwei positive Auswirkungen. Zum einen wird sichergestellt, dass alle für den Regelverstoß notwendigen Fahrzeuge und LSA-Schaltungen in der Datenbank gespeichert werden. Zum anderen wird verhindert, dass Positionen des Fahrzeugs geloggt werden, die sich außerhalb des Knotens befinden. Dies 139

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Einführung in die Informatik II

Einführung in die Informatik II Einführung in die Informatik II Die Structured Query Language SQL Prof. Dr. Nikolaus Wulff SQL Das E/R-Modell lässt sich eins zu eins auf ein Tabellenschema abbilden. Benötigt wird eine Syntax, um Tabellen

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004)

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004) Nachtrag: Farben Farbblindheit (Light und Bartlein 2004) 1 Vorgeschlagene Farbskalen (Light and Bartlein 2004) Farbkodierung metrisch skalierter Daten Unterscheide: 1. Sequential Data (ohne Betonung der

Mehr

Datendefinition und Datenmanipulation in SQL

Datendefinition und Datenmanipulation in SQL SQL Datendefinition und Datenmanipulation in SQL 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 SQL: Geschichte SQL (Structured Query Language) ist heute die bei weitestem populärste und verbreitetste

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Einführung in das Entity-Relationship-Modell

Einführung in das Entity-Relationship-Modell Einführung in das Entity-Relationship-Modell Historie Entity-Relationship-Modell kurz: ER-Modell bzw. ERM 1976 von Peter Chen vorgeschlagen Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung

Mehr

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Kapitel 3: Datenbanksysteme

Kapitel 3: Datenbanksysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2015 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL )

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL ) Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 6 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 1.12.2003 SQL-DDL und SQL-Anfragen

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

SQL-Befehlsliste. Vereinbarung über die Schreibweise

SQL-Befehlsliste. Vereinbarung über die Schreibweise Vereinbarung über die Schreibweise Schlüsselwort [optionale Elemente] Beschreibung Befehlsworte in SQL-Anweisungen werden in Großbuchstaben geschrieben mögliche, aber nicht zwingend erforderliche Teile

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

Relationale Datenbanken in der Praxis

Relationale Datenbanken in der Praxis Seite 1 Relationale Datenbanken in der Praxis Inhaltsverzeichnis 1 Datenbank-Design...2 1.1 Entwurf...2 1.2 Beschreibung der Realität...2 1.3 Enitiy-Relationship-Modell (ERM)...3 1.4 Schlüssel...4 1.5

Mehr

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Programmierung 2

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Programmierung 2 SQL SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R IV-1 Beispielrelationen Filiale ( Name Leiter Stadt Einlagen ) Konto ( KontoNr KundenNr FilialName Saldo ) Kredit

Mehr

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

Mehr

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 25.-29. April 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/index.html Datenbankentwurf Der Entwurf

Mehr

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig) 1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Datenbanken: ER-Modell

Datenbanken: ER-Modell Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm-

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

Referenzielle Integrität SQL

Referenzielle Integrität SQL Referenzielle Integrität in SQL aus Referential Integrity Is Important For Databases von Michael Blaha (Modelsoft Consulting Corp) VII-45 Referenzielle Integrität Definition: Referenzielle Integrität bedeutet

Mehr

Informatik 12 Datenbanken SQL-Einführung

Informatik 12 Datenbanken SQL-Einführung Informatik 12 Datenbanken SQL-Einführung Gierhardt Vorbemerkungen Bisher haben wir Datenbanken nur über einzelne Tabellen kennen gelernt. Stehen mehrere Tabellen in gewissen Beziehungen zur Beschreibung

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I SQL SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R VII-1 Beispielrelationen Filiale ( Name Leiter Stadt Einlagen ) Konto ( KontoNr KundenNr FilialName Saldo ) Kredit

Mehr

IV. Datenbankmanagement

IV. Datenbankmanagement Wirtschaftsinformatik 2 (PWIN) IV. Datenbankmanagement Kapitel 2: Datenmanipulationssprache SQL Wirtschaftsinformatik 2 (PWIN) SS 2009, Professur für Mobile Business & Multilateral Security 1 Agenda 1.

Mehr

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung 3 Indizes 3.1 Indexarchitektur von SQL Server Die folgende Abbildung zeigt die Organisationsstruktur einer Tabelle. Eine Tabelle befindet sich in einer oder mehreren Partitionen, und jede Partition enthält

Mehr

Carl-Engler-Schule Karlsruhe Datenbank 1 (5)

Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,

Mehr

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg Vorlesung Informationswissenschaft und Informationssysteme Hans Uszkoreit & Brigi1e Jörg Definitionen Data modeling in software engineering is the process of creating a data model by applying formal data

Mehr

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung Eltern Kind Kind Vererbung Definition von Klassen auf Basis von bestehenden Klassen. Implementierung von ist ein. bildet ein hierarchisches

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

Gliederung und Einordnung

Gliederung und Einordnung Gliederung und Einordnung 1. Objektorientierte Programmierung mit Object Pascal (5. Studienbrief, Kapitel 5) 9.4. + 16.4. 2. Software-Bausteine am Beispiel der Delphi-Komponenten (5. Studienbrief, Kapitel

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

Einführung in SQL mit Oracle

Einführung in SQL mit Oracle Seminar Einführung in SQL mit Oracle von Prof. Dr. Rainer Schwenkert Hochschule München c Vervielfältigung nur mit Zustimmung des Autors Themenbereiche SQL-Historie Wichtige DDL- und DML-Anweisungen Der

Mehr

Übung 1: Ein Website News-System mit MySQL

Übung 1: Ein Website News-System mit MySQL Übung 1: Ein Website News-System mit MySQL In der Vorübung haben wir bereits mit Hilfe eines ERMs den Datenbankentwurf erstellt und daraus die folgenden Tabellen abgeleitet: Nun muss diese Datenbank in

Mehr

5. SQL: Erstellen von Tabellen. Erzeugen und Löschen von Tabellen. Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten

5. SQL: Erstellen von Tabellen. Erzeugen und Löschen von Tabellen. Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten 5. SQL: Erstellen von Tabellen Erzeugen und Löschen von Tabellen Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten 106 SQL Structured Query Language Historie: Anfänge ca. 1974 als SEQUEL

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009 Einstieg in relationale Datenbanken mit MySQL Dr. Kerstin Puschke September 2009 1 Lizenz Lizenz Dieser Text steht unter einer Creative Commons Attribution-Share Alike 3.0 Germany Lizenz, siehe http://creativecommons.org/licenses/by-sa/3.0/de/

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

Einführung Datenbank

Einführung Datenbank Einführung Datenbank Einführung Datenbank Seite 2 Einführung in die Arbeit mit einer Datenbank Grundbegriffe: Datenbank - Datenbankmanagementsystem Eine Datenbank ist eine systematische strukturierte Sammlung

Mehr

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse Seminar Advanced Data Warehouse Thema: Index Selection Vortrag von Stephan Rieche gehalten am 2. Februar 2004 Download:.../~rieche Inhalt des Vortrages 1. Einleitung - Was ist das Index Selection Problem?

Mehr

Online-Kurs 'Datenbanken und Datenmodellierung'

Online-Kurs 'Datenbanken und Datenmodellierung' Online-Kurs 'Datenbanken und Datenmodellierung' Das Entity-Relationship-Modell Print-Version - 15.04.2002 (c) StR S. Winter - Universität Passau Inhaltsverzeichnis 1 Allgemeine Hinweise zum Abschnitt ER-Modell

Mehr

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

Mehr

Probabilistische Datenbanken

Probabilistische Datenbanken Probabilistische Datenbanken Seminar Intelligente Datenbanken AG Intelligente Datenbanken Prof. Dr. Rainer Manthey 26.04.05 Maarten van Hoek - 1 - Inhaltsverzeichnis 1.0 Einleitung...3 2.0 Modell probabilistischer

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Kapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell

Kapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell Kapitel 04 Strukturiertes Entity-Relationship-Modell 4 Strukturiertes Entity-Relationship- Modell 4 Strukturiertes Entity-Relationship-Modell...1 4.1 Erste Verbesserung...4 4.2 Objekttypen in SERM...6

Mehr

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language:

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language: SQL Structured Query Language: strukturierte Datenbankabfragesprache eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken In der SQL-Ansicht arbeiten In

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

Die SQL-Syntax für den Befehl CREATE TABLE sieht folgendermassen aus:

Die SQL-Syntax für den Befehl CREATE TABLE sieht folgendermassen aus: Einführung in MySQL SQL (Structured Query Language) ist eine Computersprache zum Speichern, Bearbeiten und Abfragen von Daten in relationalen Datenbanken. Eine relationale Datenbank kann man sich als eine

Mehr

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken 2 7 Erweiterungen 7 Erweiterungen 7.1 Prozess-Kommunikation mit Datenbanken Im Buch Einstieg in das Programmieren mit MATLAB wird im Abschnitt 4.8 das Thema Prozess-Kommunikation am Beispiel von MS-Excel

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Kapitel 7 Datenbank-Tuning

Kapitel 7 Datenbank-Tuning Kapitel 7 Datenbank-Tuning Flien zum Datenbankpraktikum Wintersemester 2012/13 LMU München 2008 Thmas Bernecker, Tbias Emrich 2010 Tbias Emrich, Erich Schubert unter Verwendung der Flien des Datenbankpraktikums

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern Objektorientierte Programmierung mit Python Polymorphismus und Vererbung Eltern Kind Kind Kind Kind Prinzipien der objektorientierten Programmierung Vererbung Strukturierung von Klassen. Oberbegriffe beschreiben

Mehr

Taschenbuch der Wirtschaftsinformatik und Wirtschaftsmathematik

Taschenbuch der Wirtschaftsinformatik und Wirtschaftsmathematik Taschenbuch der Wirtschaftsinformatik und Wirtschaftsmathematik von Wolfgang König, Heinrich Rommelfanger, Dietrich Ohse, Oliver Wendt, Markus Hofmann, Michael Schwind, Klaus Schäfer, Helmut Kuhnle, Andreas

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN Entwurf eines schulinternen Curriculums im Fach Informatik für die Qualifikationsphase (Jahrgang 11 und 12) Für die Gestaltung des Informatikunterrichts in der Qualifikationsphase sind für das schulinterne

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Datenbanken / Datenbankmanagementsystem

Datenbanken / Datenbankmanagementsystem Datenbanken / Datenbankmanagementsystem 1.Einführung Daten, Informationen; Datenbank, Datenbanksystem; Relationale Datenbanksysteme; Beispiel Access 2.Aufbau von Datenbanken Datenanalyse; Entitäten-Beziehungsmodell;

Mehr

Herbstsemester 2009. Datenbanken mit Übungen Kapitel 4: SQL. H. Schuldt. Inhalt

Herbstsemester 2009. Datenbanken mit Übungen Kapitel 4: SQL. H. Schuldt. Inhalt Herbstsemester 2009 Datenbanken mit Übungen Kapitel 4: SQL H. Schuldt Inhalt Datenmanipulationssprache SQL: SQL (Structured Query Language) ist die Standardsprache für die Datendefinition und Datenmanipulation

Mehr

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik-Vertiefte Grundlagen 3. Übung Einführung MS Access Folie-Nr.: 1 Allgemeines Microsoft Access ist ein Datenbank-Management-System (DBMS) zur Verwaltung von Daten in Datenbanken und

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Informatik Datenbanken SQL-Einführung

Informatik Datenbanken SQL-Einführung Informatik Datenbanken SQL-Einführung Gierhardt Inhaltsverzeichnis 1 Vorbemerkungen 1 2 Auswahl-Abfragen mit SELECT 2 2.1 Selektion...................................... 2 2.2 Projektion.....................................

Mehr

Structured Query Language (SQL) 1

Structured Query Language (SQL) 1 Structured Query Language (SQL) 1 1. Grundlagen und Hilfsmittel Structured Query Language, kurz SQL, wurde in den 70er Jahren bei IBM entwickelt, als eine Arbeitsgruppe die erste relationale Datenbank

Mehr

DB-Entwurf im ER-Modell

DB-Entwurf im ER-Modell DB-Entwurf im 1 Datenbankentwurf 2 Datenbankmodell 3 4 Erweiterungen des s 5 Weiteres Vorgehen beim Entwurf Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 1 Datenbankentwurf Entwurfsaufgabe Datenhaltung

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Geordnete Form...36 Erfassung und Speicherung...37 Relationale Datenbanken...37 Einfache Tabellen...37 Objekte und Begriffe relationaler

Geordnete Form...36 Erfassung und Speicherung...37 Relationale Datenbanken...37 Einfache Tabellen...37 Objekte und Begriffe relationaler Inhaltsverzeichnis Einleitung...13 SQL: Die Abfragesprache für Datenbanken...17 Kennzeichnende Merkmale von SQL...17 SQL-Dialekte...18 Kurze Entwicklungsgeschichte...18 SQL/86 oder SQL/1...19 SQL/89 oder

Mehr

SQL Performance - Tips Do's & Don'ts

SQL Performance - Tips Do's & Don'ts SQL Performance - Tips Do's & Don'ts S.K. Consulting GmbH, München DB2_SQL_PERF - 1 - Inhaltsverzeichnis I. Richtlinien bei der Verwendung von SQL 1.1. In Programmen "verbotene" SQL- Anweisungen 1.2 SQL

Mehr

Sichten II. Definition einer Sicht. Sichten. Drei-Ebenen-Schema-Architektur. Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank

Sichten II. Definition einer Sicht. Sichten. Drei-Ebenen-Schema-Architektur. Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank Vorteile Vereinfachung von Anfragen Strukturierung der Datenbank Sichten II logische Datenunabhängigkeit (Sichten stabil bei Änderungen der Datenbankstruktur) Beschränkung von Zugriffen (Datenschutz) Definition

Mehr

Whitepaper. Produkt: combit Relationship Manager 7, address manager 17. Import von Adressen nach Firmen und Kontakte

Whitepaper. Produkt: combit Relationship Manager 7, address manager 17. Import von Adressen nach Firmen und Kontakte combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager 7, address manager 17 Import von Adressen nach Firmen und Kontakte Import von Adressen nach Firmen und Kontakte

Mehr

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL Themenblock: Data Warehousing (I) Praktikum: Data Warehousing und Data Mining 2 Eigenschaften eines Data Warehouse Referenzarchitektur Integrierte Sicht auf beliebige Daten aus verschieden Datenbanken

Mehr

Vorlesung Datenbankmanagementsysteme

Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme SQL als Anfrage- und Datenmanipulationssprache (auf Basis von Oracle) Vorlesung Datenbankmanagementsysteme SQL als DQL und DML M. Lange, S. Weise Folie #8-1 Themen

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Aufbau des SELECT-Befehls. Im Folgenden werden zunächst Abfragen aus einer Tabelle vorgenommen.

Aufbau des SELECT-Befehls. Im Folgenden werden zunächst Abfragen aus einer Tabelle vorgenommen. Datenbankabfragen (Query) mit SQL (Structured Query Language) 1 Aufbau des SELECT-Befehls Im Folgenden werden zunächst Abfragen aus einer Tabelle vorgenommen. SQL-Syntax: SELECT spaltenliste FROM tabellenname

Mehr

MaxDB-Schulungsthemen

MaxDB-Schulungsthemen MaxDB-Schulungsthemen Ein Überblick über unser Angebot Allgemeine Hinweise zu unseren Schulungen Die Schulungen finden in der Regel als Inhouse Schulungen bei den interessierten Unternehmen statt. Die

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. Einleitung / Entity-Relationship

Mehr

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY Data Cube On-line Analytical Processing (OLAP). Einführung Ziel: Auffinden interessanter Muster in großen Datenmengen 2. Aggregation in SQL, GROUP BY 3. Probleme mit GROUP BY 4. Der Cube-Operator! Formulierung

Mehr