D. Roller , E. Stoyanov
In dieser Phase des Projekts wurden drei Schritte durchgeführt - Analysis der Architekturelemente
und Beziehungen innerhalb Software für Produktentwicklung, Definition eines
Metamodells für die Beschreibung von verteilten Systemen und die Entwicklung eines Prototyps,
der das Metamodell benutzt um eine flexible Steuerung von Komponentensystemen mit
verfügbaren und bestehenden Management-Werkzeugen zu ermöglichen.
Elemente der Architektur
Die Architekturelemente, die in Produktentwicklungssoftware üblicherweise verwendet
werden sind von unterschiedlicher Natur und zumeist als Einzelelemente, in einer isolierten
Umgebung entwickelt. Ein komplexes System bindet mehrere solcher Komponenten ein, jede
mit unterschiedlichen Konfigurationsanforderungen und Kommunikationsschnittstellen. Das<
führt zu Schwierigkeiten, meistens beim Intallieren neuer Komponenten, oder neuen
Versionen von alten Komponenten. Eine Middle-Ware, welche die dynamische Überprüfung
der Beziehungen und Kommunikationswege über das ganze System unterstützt, bietet die
Möglichkeit, kritische Fehler und Ausfälle zu vermeiden, oder rechtzeitig entsprechend zu
alarmieren. Abbildung 1 stellt ein Beispiel für ein Produktenwicklungssystem dar, wobei drei
Komponententechnologien über unterschiedliche Kommunikationsprotokolle kommunizieren
um den RPD-Prozess zu unterstützen.
Abbildung 1: Beziehungen zwischen Komponenten in einem verteilten System für RPD-Support
Metamodell
Das Management von großen Systemen erfordert flexible Modelle für die Beschreibung der Struktur und der Komposition. Das am IRIS entwickelte Metamodell stellt eine Basis dar, auf
der verteilte selbst-gesteuerte Systeme beschrieben werden können. Es beinhaltet das Konzept
des Kommunikationswege-Management, die dynamische Auswahl von Kommunikationsschnittstellen (Abbildung 2) und eine Adaptierung des sogenannten „Viable System Models“
(VSM). Eine zentrale Rolle spielt dabei die rekursive Natur des Modells. Die unten genannten
Elemente des Metamodells sind zuständig für die Beobachtung der Events und für die
Kommunikationkonsistenz:
Abbildung 2: CIM-basierendes Meta-Modell zur Beschreibung der verteilten
Komponentenkommunikation
AC_System – repräsentiert das ganze System, mit allen internen Komponenten und Systemen
AC_Channel – repräsentiert eine Beziehung oder einen Kommunikationsweg
AC_Manager – repräsentiert die Managementkomponente, die auch als System funktionieren
kann
AC_Operation – repräsentiert die Komponentenschnittstellen, Event-Handler, Nachrichtensender
oder Empfänger
Die Assoziierungsklassen die die Konzepte verbinden, lassen externe und interne Elemente
auf das Managementmodell abbilden.
Architektur des Prototyps
Der am IRIS entwickelte Prototyp einer Middle-Ware zur Steuerung der Komponentenkommunikation benutzt das Metamodell um die interne Kommunikationssemantik zu generieren
und um die benötigten Schnittstellen für Managemententscheidungen zur Verfügung zu stellen.
Eine zentrale Rolle spielt das Common Information Model (CIM) als Technologie für die
Implementierung des Modells sowie als breit angenommener System-Management-Standard.
Alle Elemente des Prototyps sind im Model-Repository eingetragen. Jeder Komponenten-
Container hat integrierte Elemente, die als Sensoren funktionieren, um Mitteilungen,
Kommunikationsereignisse, Installation, Upgrade oder eine neue Konfiguration des Systems
der Middle-Ware zu berichten. Der Operation Manager ist für die Speicherung relevanter
Daten und Information zuständig, die später von den Management Elementen benötigt
werden. Alle Kommunikationswege sind mit der Hilfe des CORBA Protokolls realisiert, um
die Interoperabilität zwischen mehreren Komponententechnologien sicher zu stellen.
Abbildung 3: Architektur des Prototyps |
UZ) | © Universität Stuttgart | Impressum