In den derzeit üblichen Beschreibungen von Komponenten finden sich Informationen syntaktischer Natur über die Komponentenschnittstellen, aber kaum Informationen über die Semantik angebotener Dienste oder den bisher beobachteten Anwendungskontext der Komponenten. Durch diesen Mangel an wesentlicher Information ist es nicht möglich, bei der Komponentenintegration Inkompatibilitäten aufzudecken oder rechtzeitig zu beherrschen, die sich aus Unstimmigkeiten unter den Komponenten oder zwischen den Komponenten und dem neuen Anwendungskontext ergeben.

Ziel des laufenden Vorhabens ist es deshalb, ein Verfahren zur Unterstützung einer weitgehend automatischen und fehlerfreien Integration von Softwarekomponenten zu entwickeln.

Von den geplanten Teilaufgaben wurden folgende bisher abgeschlossen:

Klassifikation möglicher Inkonsistenzen:

Um die Art und den Umfang der Informationen zu ermitteln, die in die erweiterte Beschreibungssprache aufgenommen werden müssen, wurde zunächst untersucht, welche Arten von Inkonsistenzen an den Schnittstellen von Komponenten bei der Integration auftreten können, die Ergebnisse wurden im Rahmen der internationalen Tagung PSAM7/ESREL'04 publiziert.

Erstellung der erweiterten Beschreibungssprache: Die ermittelten Inkonsistenzklassen wurden hinsichtlich der zu ihrer Erkennung und Beherrschung notwendigen Informationen analysiert. Die Sprache UML 2.0 wurde derart erweitert, dass die Beschreibung der Komponenten an Hand der Funktionen erfolgt, die die jeweiligen Komponenten an ihren Schnittstellen anbieten bzw. von außen benötigen, sowie an Hand ihres internen Verhaltens. Dazu wurde ein UML-Profil namens CCI (Consistent Component Integration) definiert.

Zur Sicherstellung anzustrebender Eigenschaften der geplanten Anwendung können darüber hinaus zulässige Abläufe durch entsprechende Einschränkungen, zum Beispiel hinsichtlich Komponentenzustände oder hinsichtlich Nachrichtenflüsse zwischen den Komponenten beschrieben werden. Ein Werkzeug wurde implementiert, um vorgegebene Komponentenbeschreibungen auf Konformität zum definierten CCI-Profil zu prüfen.

Beherrschung von Inkonsistenzen im integrierten System:

Für eine vorgegebene Menge von Komponenten und eine zu implementierende Anwendung wurde die automatische Erkennung vorgegebener Inkonsistenzklassen in ein Werkzeug umgesetzt. Dazu generiert das entwickelte Werkzeug bei Bedarf Komponenten-Wrappers, die in Abhängigkeit von der erkannten Inkonsistenzart unterschiedliche Beherrschungsmaßnahmen einleiten, darunter z.B. dynamische Konversion von Parametern an den Schnittstellen oder Verzögerungen vorübergehend nicht zugelassener Nachrichten.

Teilprojekt A: „Verfolgbarkeit und Prüfbarkeit nichtfunktionaler Anforderungen in komponentenbasierten Softwaresystemen“ (In Kooperation mit Continental TEMIC)

In diesem Teilprojekt wurde untersucht, inwieweit sich ausgewählte nichtfunktionale Anforderungen von der Anwendungsebene auf die Komponentenebene übertragen und überprüfen lassen. Die entwickelte Vorgehensweise wurde exemplarisch für eine reale Anwendung aus der Automobilindustrie umgesetzt und angewandt.

Teilprojekt B: „Formale Erfassung und Auswertung funktionaler und nichtfunktionaler Metadaten mittels eines Repositories“

Zum Zwecke einer möglichst vollständigen Erfassung bestehender Komponenten wurde in diesem Teilprojekt ein Konzept zur Beschreibung funktionaler (z.B. Prozeduren und Parameter) und nicht-funktionaler Informationen (z.B. Zeitverhalten, Betriebserfahrung, bestehende Testabdeckung) über Komponenten entwickelt und in die bestehende Komponentenbeschreibungssprache integriert. Passend zu den ermittelten Metadaten wurden Suchfunktionen implementiert, die in derartigen Komponenten-Repositories die gezielte Suche nach geeigneten wiederzuverwendenden Komponenten ermöglichen.

Teilprojekt C: „Konfiguration und Erstellung komponentenbasierter Softwaresysteme aus Repositories“

In diesem Teilprojekt wurde ein Verfahren entwickelt und implementiert, das die Konfiguration komponentenbasierter Softwaresysteme zu beschreiben und den für die Verknüpfung der Komponenten notwendigen Programmcode (sog. „Glue-code“) daraus automatisch zu erzeugen erlaubt. Dabei wurden unter anderem unterschiedliche Verknüpfungsarten (z.B. Broker, direkte Verknüpfung oder Mischformen) untersucht und hinsichtlich daraus resultierender Systemeigenschaften, insbesondere Performance und Ausfallwahrscheinlichkeit, analysiert.

Mittels der vorangehend beschriebenen, in Teilprojekten gewonnenen Einsichten und auf Basis zum Teil dabei implementierter bzw. kommerziell verfügbarer Werkzeuge und Modelltransformatoren wurde folgendes Gesamtkonzept zur sicheren Integration realisiert:

1. Einsatz eines Werkzeugs zur Modellierung der Komponenten und Systeme mittels UML: Durch Einsatz des Modellierungstools Poseidon lassen sich mittels eines generischen Schablonenprojektes alle für die CCI-Modellierung erforderlichen Stereotypen anlegen und bereitstellen.

2. Einlesen der Beschreibungen und Konversion in das CCI-Metamodell: Die mit Poseidon erstellten Modelle werden über implementierte Tools eingelesen, als Instanz des CCI-Metamodells interpretiert und in einem MDR (sog. metadata repository) gespeichert.

3. Prüfung der Anwendungsbeschreibungen und Erzeugung von Beherrschungsmechanismen:

Das im MDR gespeicherte CCI-Modell der Komponenten und der Anwendung wird auf Inkonsistenzen bei der Integration hin untersucht. Werden Inkonsistenzen gefunden, so werden individuelle Wrappers für einzelne Komponenten sowie anwendungszentrale Elemente, welche den Zustand des gesamten Systems und die Interaktion aller Komponenten im System überwachen, erzeugt.

4. Erzeugung einer fertigen Anwendung aus dem Komponentencode und den Schutzmechanismen

Die im Punkt 3 erzeugten Schutzmechanismen werden zusammen mit dem Code der Komponenten zu einer fertigen Anwendung verpackt, die dann ausgeliefert und zur Ausführung gebracht werden kann.

Eine anzustrebende Fortsetzung der bisherigen Forschungsarbeiten besteht in einer weitgehend automatisierten Lokalisierung geeigneter, vorgefertigter Komponenten anhand erfasster funktionaler und nicht-funktionaler Eigenschaften, idealerweise auf der Basis semantischer Mustererkennung. Auf diesem Weg identifizierte, funktional äquivalente, jedoch unterschiedliche Komponenten können darüber hinaus eingesetzt werden, um Fehlertoleranz systematisch zu erzielen.