IVS-Referenzmodelle und Werkzeuge - Anwendungsarchitektur: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „==Ist-Situation== Anwendungen im IVS-Bereich haben in der Regel eine sehr lange Lebensdauer (> 10 Jahre). Aus diesem Grund gibt es eine sehr heterogene, gewach…“) |
|||
(16 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | |||
− | |||
− | == | + | == IVS-Anwendungsarchitektur == |
− | |||
− | == | + | In der Anwendungsarchitektur werden Anwendungen (Services) sowie deren Schnittstellen beschrieben. |
− | Grundsätzlich sollen Anwendungen, Services und Schnittstellen in UML modelliert werden. Dabei können Komponentendiagramme | + | |
+ | == Historische Entwicklung == | ||
+ | |||
+ | Anwendungen im IVS-Bereich haben in der Regel eine sehr lange Lebensdauer (> 10 Jahre). Aus diesem Grund gibt es eine sehr heterogen gewachsene Anwendungssystemlandschaft. Bestehende Systeme sind häufig als monolithische Anwendungen und nur in wenigen Fällen als Komposition oder Orchestrierung von Services realisiert. | ||
+ | |||
+ | Aufgrund der fehlenden IVS-Rahmenarchitektur und -Referenzarchitekturen gibt es im Bereich der Anwendungsarchitektur eine historisch gewachsene Situation aus Anwendungen, Services und Schnittstellen. Diese Situation ist sowohl im Gesamtbereich der Intelligenten Verkehrs-Systeme als auch in den einzelnen IVS-Domänen durch Zufälle und projektbedingte Notwendigkeiten ohne eine übergeordnete Planung bzw. Lenkung entstanden. | ||
+ | |||
+ | == Begriffsdefinitionen der Anwendungsarchitektur == | ||
+ | |||
+ | Das folgende Diagramm zeigt die Architekturbausteine der Anwendungsarchitektur und deren Beziehungen untereinander: | ||
+ | |||
+ | [[File:Anwendungsarchitektur.jpg|thumb|left|300px|Anwendungsarchitektur]] | ||
+ | |||
+ | In der Anwendungsarchitektur werden die folgenden Architekturbausteine beschrieben: | ||
+ | |||
+ | *Eine '''IVS-Anwendung''' realisiert '''IVS-Schnittstellen''' | ||
+ | *Eine '''IVS-Schnittstelle''' verwendet ein '''IVS-Datenmodell''' | ||
+ | |||
+ | == IVS-Schnittstellen == | ||
+ | |||
+ | Eine IVS-Schnittstelle ist eine Einrichtung zwischen Systemen, die der Verbindung und der Kommunikation zwischen diesen dient. Zu jeder IVS-Schnittstelle, die zum Austausch zwischen verschiedenen Systemen verwendet wird, existieren Schnittstellenspezifikationen, die in der Regel schriftlich festgelegt sind oder durch einen Standard vorgegeben werden. Jede IVS-Schnittstellenspezifikation besteht aus einem Protokoll, mit dem festgelegt wird, wie die Informationen ausgetauscht werden, und einem Datenmodell, mit dem festgelegt wird, welche Informationen ausgetauscht werden können. Bei allgemeinen und sehr "breit" ausgelegten Schnittstellen werden häufig noch zusätzliche Vereinbarungen getroffen, mit denen die tatsächlich ausgetauschten Informationen weiter spezifiziert werden bzw. mit denen Erweiterungen oder Abwandlungen der allgemein verfügbaren Schnittstellenspezifikation festgelegt werden. | ||
+ | |||
+ | == IVS-Anwendungen == | ||
+ | |||
+ | IVS-Anwendungen sind Computerprogramme oder Systeme von Computerprogrammen, die genutzt werden, um nützliche Funktionen zu automatisieren bzw. computergestützt umzusetzen. Die technischen Aktivitäten eines IVS-Geschäftsprozesses werden in IVS-Anwendungen realisiert. Dabei kann eine Aktivität von einer oder mehreren IVS-Anwendungen realisiert werden. Es ist auch möglich, dass mehrere Aktivitäten eines IVS-Geschäftsprozesses in einer IVS-Anwendung realisiert werden. | ||
+ | |||
+ | Eine optimale Unterstützung von IVS-Geschäftsdiensten kann durch eine serviceorientierte Architektur (SOA) erreicht werden. Eine SOA ist ein Architekturmuster, bei dem Anwendungen über definierte Serviceschnittstellen miteinander kommunizieren. Aktuell sind die wenigsten IVS-Anwendungen mit einer serviceorientierten Architektur realisiert. Zukünftig sollen IVS-Anwendungen als Services in einer serviceorientierten Architektur entworfen und realisiert werden. | ||
+ | |||
+ | Der Zusammenhang zwischen Anwendungen und Services einerseits und Schnittstellen andererseits soll in [https://de.wikipedia.org/wiki/Komponentendiagramm Komponentendiagrammen] modelliert werden. Dabei werden Anwendungen und Services als Components und Schnittstellen als Interfaces dargestellt. | ||
+ | |||
+ | == Modellierungsprinzipien == | ||
+ | |||
+ | === Verwendung von Standards === | ||
+ | |||
+ | Falls möglich, sollen Standards als IVS-Schnittstellen verwendet werden. | ||
+ | |||
+ | === Verwendung einer serviceorientierten Architektur === | ||
+ | |||
+ | Neu zu erstellende IVS-Anwendungen sollen mit einer [https://de.wikipedia.org/wiki/Serviceorientierte_Architektur serviceorientierten Architektur] entworfen werden. Bei dieser Vorgehensweise können IVS-Geschäftsprozesse leicht durch die Integration von IT-Services umgesetzt werden. Ein IVS-Geschäftsprozess kann dann als Komposition bzw. Orchestrierung von Services umgesetzt werden. | ||
+ | |||
+ | == Modellierungswerkzeuge == | ||
+ | |||
+ | Grundsätzlich sollen Anwendungen, Services und Schnittstellen in UML modelliert werden. Dabei können [https://de.wikipedia.org/wiki/Komponentendiagramm Komponentendiagramme] verwendet werden, um die Beziehung zwischen Anwendungen, Services und Schnittstellen zu beschreiben. Anwendungen und Services werden dabei als Components und Schnittstellen als Interfaces modelliert. | ||
Eine einzelne Anwendung bzw. ein einzelner Service kann, falls benötigt, ebenfalls mithilfe eines Komponentendiagramms modelliert werden. Die Details von Schnittstellen können in Klassendiagrammen beschrieben werden. | Eine einzelne Anwendung bzw. ein einzelner Service kann, falls benötigt, ebenfalls mithilfe eines Komponentendiagramms modelliert werden. Die Details von Schnittstellen können in Klassendiagrammen beschrieben werden. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | [[Hauptseite|<< Zurück zur Hauptseite]] |
Aktuelle Version vom 15. November 2017, 15:10 Uhr
Inhaltsverzeichnis
IVS-Anwendungsarchitektur
In der Anwendungsarchitektur werden Anwendungen (Services) sowie deren Schnittstellen beschrieben.
Historische Entwicklung
Anwendungen im IVS-Bereich haben in der Regel eine sehr lange Lebensdauer (> 10 Jahre). Aus diesem Grund gibt es eine sehr heterogen gewachsene Anwendungssystemlandschaft. Bestehende Systeme sind häufig als monolithische Anwendungen und nur in wenigen Fällen als Komposition oder Orchestrierung von Services realisiert.
Aufgrund der fehlenden IVS-Rahmenarchitektur und -Referenzarchitekturen gibt es im Bereich der Anwendungsarchitektur eine historisch gewachsene Situation aus Anwendungen, Services und Schnittstellen. Diese Situation ist sowohl im Gesamtbereich der Intelligenten Verkehrs-Systeme als auch in den einzelnen IVS-Domänen durch Zufälle und projektbedingte Notwendigkeiten ohne eine übergeordnete Planung bzw. Lenkung entstanden.
Begriffsdefinitionen der Anwendungsarchitektur
Das folgende Diagramm zeigt die Architekturbausteine der Anwendungsarchitektur und deren Beziehungen untereinander:
In der Anwendungsarchitektur werden die folgenden Architekturbausteine beschrieben:
- Eine IVS-Anwendung realisiert IVS-Schnittstellen
- Eine IVS-Schnittstelle verwendet ein IVS-Datenmodell
IVS-Schnittstellen
Eine IVS-Schnittstelle ist eine Einrichtung zwischen Systemen, die der Verbindung und der Kommunikation zwischen diesen dient. Zu jeder IVS-Schnittstelle, die zum Austausch zwischen verschiedenen Systemen verwendet wird, existieren Schnittstellenspezifikationen, die in der Regel schriftlich festgelegt sind oder durch einen Standard vorgegeben werden. Jede IVS-Schnittstellenspezifikation besteht aus einem Protokoll, mit dem festgelegt wird, wie die Informationen ausgetauscht werden, und einem Datenmodell, mit dem festgelegt wird, welche Informationen ausgetauscht werden können. Bei allgemeinen und sehr "breit" ausgelegten Schnittstellen werden häufig noch zusätzliche Vereinbarungen getroffen, mit denen die tatsächlich ausgetauschten Informationen weiter spezifiziert werden bzw. mit denen Erweiterungen oder Abwandlungen der allgemein verfügbaren Schnittstellenspezifikation festgelegt werden.
IVS-Anwendungen
IVS-Anwendungen sind Computerprogramme oder Systeme von Computerprogrammen, die genutzt werden, um nützliche Funktionen zu automatisieren bzw. computergestützt umzusetzen. Die technischen Aktivitäten eines IVS-Geschäftsprozesses werden in IVS-Anwendungen realisiert. Dabei kann eine Aktivität von einer oder mehreren IVS-Anwendungen realisiert werden. Es ist auch möglich, dass mehrere Aktivitäten eines IVS-Geschäftsprozesses in einer IVS-Anwendung realisiert werden.
Eine optimale Unterstützung von IVS-Geschäftsdiensten kann durch eine serviceorientierte Architektur (SOA) erreicht werden. Eine SOA ist ein Architekturmuster, bei dem Anwendungen über definierte Serviceschnittstellen miteinander kommunizieren. Aktuell sind die wenigsten IVS-Anwendungen mit einer serviceorientierten Architektur realisiert. Zukünftig sollen IVS-Anwendungen als Services in einer serviceorientierten Architektur entworfen und realisiert werden.
Der Zusammenhang zwischen Anwendungen und Services einerseits und Schnittstellen andererseits soll in Komponentendiagrammen modelliert werden. Dabei werden Anwendungen und Services als Components und Schnittstellen als Interfaces dargestellt.
Modellierungsprinzipien
Verwendung von Standards
Falls möglich, sollen Standards als IVS-Schnittstellen verwendet werden.
Verwendung einer serviceorientierten Architektur
Neu zu erstellende IVS-Anwendungen sollen mit einer serviceorientierten Architektur entworfen werden. Bei dieser Vorgehensweise können IVS-Geschäftsprozesse leicht durch die Integration von IT-Services umgesetzt werden. Ein IVS-Geschäftsprozess kann dann als Komposition bzw. Orchestrierung von Services umgesetzt werden.
Modellierungswerkzeuge
Grundsätzlich sollen Anwendungen, Services und Schnittstellen in UML modelliert werden. Dabei können Komponentendiagramme verwendet werden, um die Beziehung zwischen Anwendungen, Services und Schnittstellen zu beschreiben. Anwendungen und Services werden dabei als Components und Schnittstellen als Interfaces modelliert.
Eine einzelne Anwendung bzw. ein einzelner Service kann, falls benötigt, ebenfalls mithilfe eines Komponentendiagramms modelliert werden. Die Details von Schnittstellen können in Klassendiagrammen beschrieben werden.