Messe-Zulaufsteuerung Informationsarchitektur: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
== Datenarchitektur ==
 
== Datenarchitektur ==
 
=== Referenzmodelle und Werkzeuge ===
 
=== Referenzmodelle und Werkzeuge ===
 +
Siehe [[IVS-Referenzmodelle_und_Werkzeuge|IVS-Referenzmodelle und Werkzeuge]].
  
 
=== Ausgangssituation der Datenarchitektur ===
 
=== Ausgangssituation der Datenarchitektur ===
−
Für die Übertragung der Verkehrslagedaten werden existierende Schnittstellen (DATEX II und OCIT-C) verwendet. Für die Slotinformationen (Anforderung eines Slots bzw. Beschreibung eines Slots) sind noch keine Datenformate vorhanden.
+
Für die Übertragung der Verkehrslagedaten existieren Schnittstellen ([http://www.datex2.eu/ DATEX II] und [http://www.ocit.org/downloadOCIT-C.htm OCIT-C]).
 +
 
 +
{| class="wikitable"
 +
!Daten
 +
!Datenformat
 +
!Beschreibung
 +
|-
 +
|Verkehrslage (außerorts)
 +
|DATEX II
 +
|Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
 +
|-
 +
|Verkehrslage (innerorts)
 +
|OCIT-C
 +
|Die städtische Verkehrslage wird mit OCIT-C übertragen.
 +
|}
  
 
=== Zielsituation der Datenarchitektur ===
 
=== Zielsituation der Datenarchitektur ===
Zeile 14: Zeile 29:
 
|-
 
|-
 
|Verkehrslage (außerorts)
 
|Verkehrslage (außerorts)
−
|[http://www.datex2.eu/ DATEX II]
+
|DATEX II
 
|Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
 
|Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
 
|-
 
|-
 
|Verkehrslage (innerorts)
 
|Verkehrslage (innerorts)
−
|[http://www.ocit.org/downloadOCIT-C.htm OCIT-C]
+
|OCIT-C
 
|Die städtische Verkehrslage wird mit OCIT-C übertragen.
 
|Die städtische Verkehrslage wird mit OCIT-C übertragen.
 
|-
 
|-
 
|Slotdaten
 
|Slotdaten
−
|[https://de.wikipedia.org/wiki/JavaScript_Object_Notation JSON]
+
|UML
−
|Das Datenmodell zur Beschreibung eines Be- bzw. Entladeslots wird neu entwickelt. Die Daten werden im JSON Format übertragen.
+
|Das Datenmodell zur Beschreibung eines Be- bzw. Entladeslots wird neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt.
 
|-
 
|-
 
|Slotanforderung
 
|Slotanforderung
−
|JSON
+
|UML
−
|Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden im JSON Format übertragen
+
|Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt.
 
|}
 
|}
  
 
=== Gap Analyse ===
 
=== Gap Analyse ===
 +
Die vertikale Achse der folgenden Tabelle enthält die bereits vorhandenen Datenformate, die horizontale Achse die benötigten Formate:
 +
{| class="wikitable"
 +
!
 +
!Verkehrslage (außerorts)
 +
!Verkehrslage (innerorts)
 +
!Slotdaten
 +
!Slotanforderung
 +
!Ausgeschieden
 +
|-
 +
! scope="row"| Verkehrslage (außerorts)
 +
|inbegriffen
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
! scope="row"| Verkehrslage (innerorts)
 +
|
 +
| inbegriffen
 +
|
 +
|
 +
|
 +
|-
 +
! scope="row"| Neu
 +
|
 +
|
 +
| neu
 +
| neu
 +
|
 +
|}
  
 
=== Roadmap Komponenten ===
 
=== Roadmap Komponenten ===
 +
Die folgende Tabelle enthält die Priorisierung für die neu zu entwickelnden Datenarchitektur-Komponenten in einer Skale von 1-3 (1=höchste Priorität, 3=niedrigste Priorität):
 +
{| class="wikitable"
 +
!Komponenten
 +
!Priorität
 +
|-
 +
| Slotdaten
 +
| 1
 +
|-
 +
| Slotanforderung
 +
| 2
 +
|}
  
 
=== Auswirkung auf die Architekturlandschaft ===
 
=== Auswirkung auf die Architekturlandschaft ===
 +
Dieser Punkt kann für das Beispiel nicht sinnvoll durchgeführt werden, da der Kontext fehlt. Normalerweise werden an diesem Punkt andere Architektur Artefakte in der Architektur Landschaft untersucht , um zu identifizieren:
 +
* Hat die Datenarchitektur Auswirkungen auf bereits existierende Architekturen?
 +
* Wurden jüngst Änderungen ausgeführt, die Auswirkungen auf die Datenarchitektur haben?
 +
* Gibt es Möglichkeiten, Arbeiten die innerhalb der Datenarchitektur verrichtet wurden in anderen Bereichen zu nutzen?
 +
* Hat die Datenarchitektur Auswirkungen auf andere Projekte (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?
 +
* Wird die Datenarchitektur von anderen Projekten beeinflusst (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?
 +
 +
Im Rahmen einer Referenzarchitektur könnte z.B. geklärt werden, ob die neu zu entwickelnden Datenmodelle mittel- bis langfristig in eines der bestehenden Datenmodelle aufgenommen werden sollen (z.B. als Level-B-Erweiterung in DATEX II)
  
 
=== Stakeholder Review ===
 
=== Stakeholder Review ===
 +
An dieser Stelle sollten die relevanten Informationen und Entscheidungen an die Stakeholder kommuniziert werden. Insbesondere die direkt von den Änderungen/Erweiterungen betroffenen Stakeholder (in unserem Beispiel Garmin und die Messegesellschaft Frankfurt) müssen involviert werden.
  
 
=== Finalisierung der Datenarchitektur ===
 
=== Finalisierung der Datenarchitektur ===
 +
An dieser Stelle werden die Rückmeldungen aus den Stakeholder-Reviews eingearbeitet und nochmals mit der Geschäftsarchitektur abgeglichen. Die Ergebnisse der Stakeholder-Reviews werden zum Zweck der Rückverfolgbarkeit dokumentiert. Ebenso werden alle Bausteine vollständig dokumentiert.
  
 
=== Dokumentation der Datenarchitekturdefinition ===
 
=== Dokumentation der Datenarchitekturdefinition ===
 +
Die Dokumentation der Datenarchitekturdefinitionen wird im Repository abgelegt.
  
 
== Anwendungsarchitektur ==
 
== Anwendungsarchitektur ==

Aktuelle Version vom 15. April 2016, 10:53 Uhr

Datenarchitektur

Referenzmodelle und Werkzeuge

Siehe IVS-Referenzmodelle und Werkzeuge.

Ausgangssituation der Datenarchitektur

Für die Übertragung der Verkehrslagedaten existieren Schnittstellen (DATEX II und OCIT-C).

Daten Datenformat Beschreibung
Verkehrslage (außerorts) DATEX II Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
Verkehrslage (innerorts) OCIT-C Die städtische Verkehrslage wird mit OCIT-C übertragen.

Zielsituation der Datenarchitektur

In der folgenden Liste sind die auszutauschenden Daten mit den verwendeten Datenformaten aufgelistet:

Daten Datenformat Beschreibung
Verkehrslage (außerorts) DATEX II Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
Verkehrslage (innerorts) OCIT-C Die städtische Verkehrslage wird mit OCIT-C übertragen.
Slotdaten UML Das Datenmodell zur Beschreibung eines Be- bzw. Entladeslots wird neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt.
Slotanforderung UML Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt.

Gap Analyse

Die vertikale Achse der folgenden Tabelle enthält die bereits vorhandenen Datenformate, die horizontale Achse die benötigten Formate:

Verkehrslage (außerorts) Verkehrslage (innerorts) Slotdaten Slotanforderung Ausgeschieden
Verkehrslage (außerorts) inbegriffen
Verkehrslage (innerorts) inbegriffen
Neu neu neu

Roadmap Komponenten

Die folgende Tabelle enthält die Priorisierung für die neu zu entwickelnden Datenarchitektur-Komponenten in einer Skale von 1-3 (1=höchste Priorität, 3=niedrigste Priorität):

Komponenten Priorität
Slotdaten 1
Slotanforderung 2

Auswirkung auf die Architekturlandschaft

Dieser Punkt kann für das Beispiel nicht sinnvoll durchgeführt werden, da der Kontext fehlt. Normalerweise werden an diesem Punkt andere Architektur Artefakte in der Architektur Landschaft untersucht , um zu identifizieren:

  • Hat die Datenarchitektur Auswirkungen auf bereits existierende Architekturen?
  • Wurden jüngst Änderungen ausgeführt, die Auswirkungen auf die Datenarchitektur haben?
  • Gibt es Möglichkeiten, Arbeiten die innerhalb der Datenarchitektur verrichtet wurden in anderen Bereichen zu nutzen?
  • Hat die Datenarchitektur Auswirkungen auf andere Projekte (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?
  • Wird die Datenarchitektur von anderen Projekten beeinflusst (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?

Im Rahmen einer Referenzarchitektur könnte z.B. geklärt werden, ob die neu zu entwickelnden Datenmodelle mittel- bis langfristig in eines der bestehenden Datenmodelle aufgenommen werden sollen (z.B. als Level-B-Erweiterung in DATEX II)

Stakeholder Review

An dieser Stelle sollten die relevanten Informationen und Entscheidungen an die Stakeholder kommuniziert werden. Insbesondere die direkt von den Änderungen/Erweiterungen betroffenen Stakeholder (in unserem Beispiel Garmin und die Messegesellschaft Frankfurt) müssen involviert werden.

Finalisierung der Datenarchitektur

An dieser Stelle werden die Rückmeldungen aus den Stakeholder-Reviews eingearbeitet und nochmals mit der Geschäftsarchitektur abgeglichen. Die Ergebnisse der Stakeholder-Reviews werden zum Zweck der Rückverfolgbarkeit dokumentiert. Ebenso werden alle Bausteine vollständig dokumentiert.

Dokumentation der Datenarchitekturdefinition

Die Dokumentation der Datenarchitekturdefinitionen wird im Repository abgelegt.

Anwendungsarchitektur

Referenzmodelle und Werkzeuge

Ausgangssituation der Anwendungsarchitektur

Zielsituation der Anwendungsarchitektur

Gap Analyse

Roadmap Komponenten

Auswirkung auf die Architekturlandschaft

Stakeholder Review

Finalisierung der Anwendungsarchitektur

Dokumentation der Anwendungsarchitekturdefinition

Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=Messe-Zulaufsteuerung_Informationsarchitektur&oldid=1816“