|
|
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| − | == AP 1.1 Bestandsaufnahme und -analyse ==
| |
| | | | |
| − | Die derzeitige Sicht auf den Themenkreis IVS-Architektur wird erfasst, analysiert, geordnet und dokumentiert. Bevor eine Erhebung des Kernwissens von IVS-Architekturen und Darstellungsformen stattfinden kann, müssen der politische Background sowie die Leitbilder auf nationaler und internationaler Ebene betrachtet werden. Abschließend sind dann die für IVS relevanten Domänen und Anwendungsfelder Gegenstand der Betrachtung.
| |
| − |
| |
| − | Zur Erfassung des Politikhintergrunds und der bestehenden Leitbilder sind die u.a. folgenden Inputs relevant:
| |
| − |
| |
| − | *IVS-Aktionsplan, IVS-Direktive, TENT-T-Regulation
| |
| − | *Nationaler IVS-Aktionsplan Straße
| |
| − | *Digitale Agenda 2014 - 2017 der Bundesregierung
| |
| − | *Europäische Initiativen: EasyWay-Projekt, EIP - European ITS Platform, EU-Korridore (URSAR MAJOR, NEXT ITS, CROCODILE, ARCC ATLANTIQUE, MEDT TIS)
| |
| − |
| |
| − | Im Anschluss daran werden das Kernwissen von IVS-Architekturen und Darstellungsformen u.a. anhand der folgenden Inputs erfasst:
| |
| − |
| |
| − | *Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305
| |
| − | *Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz
| |
| − | *EasyWay-Deployment Guidelines
| |
| − | *European ITS Framework Architecture und E-Frame
| |
| − |
| |
| − | Abschließend werden die relevanten Domänen und Anwendungsfelder von IVS identifiziert und betrachtet. Das EasyWay-Projekt hat dazu eine gute Struktur geliefert:
| |
| − |
| |
| − | *Verkehrsmanagement
| |
| − | *Verkehrsinformation
| |
| − | *Fracht & Logistik
| |
| − | *Multimodale Verkehrsinformation
| |
| − |
| |
| − | == AP 1.2: Entwicklung eines TOGAF basierten Rahmenwerks für IVS-Architektur ==
| |
| − |
| |
| − | Architekturentwicklung (ADM) sowie Richtlinien und Techniken
| |
| − |
| |
| − | == IVS-Architektur-Glossar und Metamodell ==
| |
| − |
| |
| − | Um im Projekt zwischen den Bearbeitern von Los 1 bis 4 von Anfang an babylonischen Sprachverhältnissen begegnen zu können, muss der Sprache bzw. der Begriffsbildung und Begriffsverwendung ein hoher Stellenwert eingeräumt werden. Dazu wird ein Glossar aufgebaut, in dem die wesentlichen Begriffen der IVS beschrieben werden.
| |
| − |
| |
| − | Um die Begriffe auf Ebene der IVS-Rahmenarchitektur adäquat beschreiben zu können, muss ein passendes Metamodell ausgewählt werden, in dem eine solche Beschreibung möglich ist. Die Meta Object Facility (MOF) ist eine Spezifikation der Object Management Group (OMG), die zur abstrakten Beschreibung beliebiger Modelle, also auch für das Glossar-Metamodell geeignet wäre. Unter anderem ist die Unified Modeling Language (UML) in MOF modelliert.
| |
| − |
| |
| − | Die MOF unterscheidet vier Ebenen der Modellierung M0 - M3. Die folgende Abbildung zeigt ein Beispiel für die Modellierungsebenen anhand eines Datenüberlassungsvertrags:
| |
| − |
| |
| − | Abbildung 12: Meta-Modelle am Beispiel eines Datenüberlassungsvertrags
| |
| − |
| |
| − | Die vier verschiedenen Ebenen haben die folgende Bedeutung:
| |
| − |
| |
| − | ; M0 – Realität
| |
| − | :Auf dieser Ebene ist die Realität angesiedelt. Im Beispiel ist dies der eigentliche Datenüberlassungsvertrag.
| |
| − |
| |
| − | ;M1 – Modell
| |
| − | :Auf dieser Ebene ist in einem Benutzermodell eine Beschreibung der Realität dargestellt. Dies können z.B. physikalische oder logische Daten- und Prozessmodelle sein. Im Beispiel ist diese eine Klasse, in der Datenüberlassungsverträge modelliert werden und eine Objektinstanz, in der ein bestimmter Datenüberlassungsvertrag beschrieben wird.
| |
| − |
| |
| − | ;M2 – Meta-Modell
| |
| − | :Auf der Meta-Modell-Ebene wird festgelegt, wie Modelle aufgebaut sind. Das können z.B. Festlegungen sein, welche Attribute in welcher Klasse vorhanden sein müssen. Im Beispiel ist dies eine Festlegung, dass die Klasse „Vertrag“ und die Attribute der Klasse „Vertrag“ als Klasse und die Objektinstanz „detektorDatenNRW“ als Instanz modelliert werden.
| |
| − |
| |
| − | ;M3 – Meta-Meta-Modell
| |
| − | :Die Meta-Meta-Modelle sind auf einer abstrakten Ebene, in der beschrieben wird, wie Meta-Modelle definiert werden. Die Definition der M3-Ebene erfolgt mit den Mitteln der M3-Ebene selbst, dies stellt den Abschluss einer sonst unendlichen Metaisierung dar.
| |
| − |
| |
| − | Für die IVS-Rahmenarchitektur bedeutet das, dass die Beschreibung vorwiegend auf der Ebene M2, in wenigen Einzelfällen auch auf der Ebene M1 stattfinden wird. Die Sprache UML ist geeignet, um die Ebenen M1 und M2 zu beschreiben (auch die Ebene M3 kann mit Mitteln der UML beschrieben werden). Aus diesem Grund wird vorgeschlagen, die Beschreibungen im Glossar in UML vorzunehmen. Bei dieser Beschreibung werden die zu definierenden Begriffe als UML-Klassen, Eigenschaften dieser Begriffe als Attribute der Klassen, Beziehungen zwischen den Begriffen als Konnektoren und Verallgemeinerungen von Begriffen als Generalisierung modelliert. Der Vorteil einer Beschreibung in UML gegenüber einer formlosen, natürlichsprachlichen Beschreibung liegt vor allem darin, dass Eigenschaften, Beziehungen, Verallgemeinerung bzw. Spezialisierungen einheitlich und in grafischer Form gut lesbar beschrieben werden können. Dabei muss nicht auf eine natürlichsprachliche Beschreibung verzichtet werden. Zu allen oben genannten UML-Elementen (Klassen, Attribute, Konnektoren, Generalisierungen) können Dokumentationen hinterlegt werden. Die vier Ebenen der MOF eignen sich auch, um in gewisser Weise die Architekturebenen zu beschreiben. Auf der Ebene M0 sind dabei die realen Systeme angesiedelt, die Ebene M1 enthält die Architekturen der realen Systeme, die Ebene M2 enthält die Referenzarchitekturen als Meta-Ebene zu den Architekturen realer Systeme und die Ebene M3 ist dabei die IVS-Rahmenarchitektur, die wiederum beschreibt, wie Referenzarchitekturen aufzubauen sind.
| |
