Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
Austauschens verwendet, der in ähnlicher Form auch im Rahmen des Parkens eingesetzt wird, um ein
Modul durch einen Stellvertreter zu ersetzen. Wird das Modul dann verwendet, so leitet der Stellvertreter
den Aufruf an den Verwalter weiter. Dabei müssen die benötigten Daten zum Zielknoten transportiert
werden. Da der Verwalter üblicherweise eine andere Hardwarearchitektur hat als die verwalteten
Knoten, müssen die Daten entsprechend umgewandelt werden. Die Umwandlung, Marshalling genannt,
wird dabei empfangsseitig durchgeführt. Das heißt, dass der Verwalter die Daten im Format des
verwalteten Knotens empfängt und sie dann in sein eigenes Format umwandelt. Dadurch soll die
Belastung des verwalteten Knotens möglichst gering gehalten werden.
Für die Durchführung des Marshallings werden die genaue Struktur und die genauen Typen der
Daten und Parameter benötigt. Diese Information kann von außen, zum Beispiel in Form einer erweiterten
Schnittstellenbeschreibung, zugeführt werden. Im Rahmen dieser Arbeit wird jedoch auch
ein Mechanismus vorgestellt, die Informationen automatisch aus zusätzlichen compilergenerierten
Informationen zu extrahieren (siehe Abschnitt 4.5.8).
4.2 Modularisierung
Um Software zu partitionieren oder zu verteilen, muss man sie in Abschnitte zerschneiden, sogenannte
Verteilungseinheiten, die als Basis der Operation dienen. Nachfolgend soll die Aufteilung in solche
Bausteine beschrieben werden. Dabei dient die Zergliederung nicht nur der Verteilung, sondern
bildet auch die Ausgangsbasis, um die Struktur der Anwendung zu erfassen und zu analysieren.
Die resultierenden kleinen Einheiten stellen die Module dar, die bereits in vorherigen Abschnitten
angesprochen wurden.
Erstellt man eine Anwendung von Beginn an unter dem Gesichtspunkt der Modularisierung, so
kann bereits in der Entwicklungsphase die Einteilung in Module vorgesehen werden. Eine Möglichkeit
besteht darin, die Software mithilfe eines Komponentenmodells zu entwickeln. Dadurch wird man
automatisch eine entsprechende Strukturierung in Komponenten vornehmen, welche dann unsere
Module darstellen können. Komponentenmodelle werden in Abschnitt 4.2.2 kurz beschrieben.
Um ein modulares Design zu erstellen und die Modularität im Laufe der Entwicklung sicherzustellen,
muss bei der Entwicklung zusätzlicher Aufwand in Form von Planungs- und Entwicklungszeit investiert
werden. Diese Mehrkosten werden jedoch häufig nicht in Kauf genommen, da der Vorteil einer späteren
Aufteilung in einzelne Einheiten bei der Entwicklung nicht hinreichend begründet werden kann.
Daher sollen für die in dieser Arbeit vorgestellte Basisinfrastruktur keine besonderen Modularisierungsanforderungen
an die Software gestellt werden. Es soll stattdessen beliebige existierende Software
verwendet werden können, auch wenn sie nicht vorwiegend mit dem Gedanken der Modularität
entwickelt wurde.
Die erste Aufgabe des Systems ist somit die Aufteilung der Software in Module. Die Zergliederung
soll dabei an funktionalen Grenzen der Software orientiert sein. Um automatisch eine sinnvolle Aufteilung
vorzunehmen, ist inhaltliches Wissen über die Software nötig. Die Basissoftware eines Verwalters
ist jedoch allgemein verwendbar und unabhängig von der eingesetzten Software. Semantische Informationen
über die Funktion der Software werden erst durch die höhere Kontrollschicht dem System
zugeführt. Der wichtigste Ansatzpunkt ist daher die Frage, an welchen Stellen man die Software in
Module aufteilen kann.
Hier bieten die grundlegenden Programmstrukturen einen möglichen Ansatzpunkt, auch ohne
explizites inhaltliches Wissen eine nachvollziehbare Aufteilung vorzunehmen. Eine grundlegende
Strukturierung der meisten Programme ist durch ihre Organisation in einzelne Funktionen und Daten
beziehungsweise, bei objektorientierter Programmierung, in Klassen und Objekte gegeben. Die Ba-
34