Los1: UAP1.2 TOGAF basiertes Rahmenwerk

Aus IVS-Wiki
Version vom 20. Juni 2016, 16:22 Uhr von Albrecht (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Architekturentwicklung (ADM) sowie Richtlinien und Techniken == TOGAF ist ursprünglich für den Einsatz in einem Unternehmen entwickelt worden. Die Tastsa…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Architekturentwicklung (ADM) sowie Richtlinien und Techniken

TOGAF ist ursprünglich für den Einsatz in einem Unternehmen entwickelt worden. Die Tastsache, dass es nun für die Entwicklung einer Rahmenarchitektur eingesetzt wird, macht eine Anpassung des TOGAF-Vorgehensmodells nötig. In diesem Arbeitspaket wird geklärt, wie dieses vor sich geht. Es ist Teil der Vorarbeit für die Anwendung von TOGAF. Im Folgenden werden erste Ansätze zur Anpassung von TOGAF beschrieben, die im Rahmen des Vorhabens weiter konkretisiert und umgesetzt werden müssen.

Generell werden gemäß TOGAF im ersten Projekt-Schritt Szenarien definiert, die umgesetzt werden können. Aus diesen Szenarien ergeben sich einerseits Capabilities, die zur Umsetzung notwendig sind, und andererseits Anforderungen (Requirements), die erfüllt werden müssen. Basierend auf den definierten High-Level Capabilities werden dann sogenannte Capability Architectures entworfen. Capabilities sind grundsätzliche Fähigkeiten bestehend aus Prozessen, Personen und IT, die langfristig nötig sind, um den Informationsaustausch zwischen den beteiligten Stakeholdern zu ermöglichen und somit zu intelligenten Verkehrssystemen zu gelangen. Zwischen den Fähigkeiten können Abhängigkeiten bestehen, gleichzeitig strukturieren sie aber die weitere Entwicklung der Rahmenarchitektur. Für jede High-Level-Capability wird die TOGAF ADM durchlaufen. Zunächst wird die ADM von den Los 1 - Projektpartnern intern angewendet, um die Version 0.9 der IVS-Rahmenarchitektur zu erstellen. Auch währenddessen wird bereits erstes Feedback von den Bearbeitern der IVS-Referenzarchitekten eingeholt. Für die Version 1.0 werden die Ergebnisse aus den Workshops mit einbezogen und die IVS-Rahmenarchitektur wird entsprechend angepasst.

Im Rahmen der TOGAF ADM werden zur Entwicklung der Rahmenarchitektur folgende Phasen durchlaufen:

  • Vorarbeiten
  • A – Architekturvision
  • B – Geschäftsarchitektur
  • C – Informationssystem-Architektur
  • D – Technologiearchitektur
  • E – Möglichkeiten und Lösungen
  • F – Migrationsplanung
  • G – Governance
  • H – Change Management
  • Requirements Management
TOGAF ADM in den Losen 1-4

Vertiefende Inforamtionen zu TOGAF

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:

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.