IVS-Referenzmodelle und Werkzeuge - Anwendungsarchitektur: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(13 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
==TOGAF==
 
Review and validate (or generate, if necessary) the set of application principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of application principles, are given in Part III, 23. Architecture Principles.
 
  
Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, the stakeholders, and their concerns.
+
== IVS-Anwendungsarchitektur ==
  
Select relevant Application Architecture viewpoints (for example, stakeholders of the applications - viewpoints relevant to functional and individual users of applications, etc.); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application Architecture.
+
In der Anwendungsarchitektur werden Anwendungen (Services) sowie deren Schnittstellen beschrieben.
  
Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques.
+
== 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]]
  
Consider using platform-independent descriptions of business logic. For example, the OMG's Model Driven Architecture (MDA) offers an approach to modeling Application Architectures that preserves the business logic from changes to the underlying platform and implementation technology.
 
==Architekturbausteine==
 
 
In der Anwendungsarchitektur werden die folgenden Architekturbausteine beschrieben:
 
In der Anwendungsarchitektur werden die folgenden Architekturbausteine beschrieben:
*Eine '''IVS-Anwendung''' realisiert '''IVS-Schnittstellen'''
 
*Eine '''IVS-Schnittstelle''' verwendet ein '''IVS-Datenmodell'''
 
  
Das folgende UML-Diagramm zeigt diese Architekturbausteine und deren Beziehungen untereinander:
+
*Eine '''IVS-Anwendung''' realisiert '''IVS-Schnittstellen'''
[[Datei: Anwendungsarchitektur.jpg | 400px |  Anwendungsarchitektur]]
+
*Eine '''IVS-Schnittstelle''' verwendet ein '''IVS-Datenmodell'''
  
==Ist-Situation==
+
== IVS-Schnittstellen ==
Anwendungen im IVS-Bereich haben in der Regel eine sehr lange Lebensdauer (> 10 Jahre). Aus diesem Grund gibt es eine sehr heterogene, gewachsene Anwendungssystemlandschaft. Bestehende Systeme sind häufig als monolithische Anwendungen und nur in wenigen Fällen als Komposition oder Orchestrierung von Services realisiert.
 
  
==Modellierungsprinzipien==
+
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.
Neu zu erstellende Anwendungen sollen mit einer [https://de.wikipedia.org/wiki/Serviceorientierte_Architektur serviceorientierten Architektur] entworfen werden. Bei dieser Vorgehensweise können einzelne Geschäftsprozesse leicht in einzelne IT-Services umgesetzt werden. Ein IVS-Geschäftsprozess dann als Komposition bzw. Orchestrierung von Services umgesetzt 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 ==
  
==Modelierungswerkzeuge==
 
 
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.
 
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

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:

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 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.


<< Zurück zur Hauptseite