14.01.2015 Aufrufe

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

4 Basisschicht e<strong>in</strong>es Verwalters<br />

plementierung gleich. Außerdem benötigt die dynamische Veränderung der Zusammensetzung e<strong>in</strong><br />

Verknüpfungsframework zur Laufzeit. Dieses benötigt zusätzliche Ressourcen und führt oft zu e<strong>in</strong>er<br />

<strong>in</strong>direkten Kommunikation zwischen den Komponenten.<br />

4.2.3 Modularisierung existierender Anwendungen<br />

Um e<strong>in</strong>e existierende Software <strong>in</strong> e<strong>in</strong>zelne Module aufzuteilen, ist e<strong>in</strong> Ansatz wünschenswert, bei dem<br />

die Struktur der Anwendung im Nachh<strong>in</strong>e<strong>in</strong> identifiziert wird. E<strong>in</strong> solcher Ansatz soll hier vorgestellt<br />

werden.<br />

Als Grenzen zur Festlegung der Module bieten sich bei e<strong>in</strong>em existierenden Programm die Konstrukte<br />

an, die durch die Programmiersprache angeboten werden, um das Programm zu strukturieren.<br />

So s<strong>in</strong>d die meisten Programme <strong>in</strong> e<strong>in</strong>zelne Quellcodedateien aufgeteilt. Diese Aufteilung kann man<br />

zur E<strong>in</strong>teilung <strong>in</strong> Module nutzen, da hier meistens zusammengehörende Funktionen und Daten enthalten<br />

s<strong>in</strong>d. E<strong>in</strong>e fe<strong>in</strong>ere Aufteilung ergibt sich, wenn man die e<strong>in</strong>zelnen Funktionen und globalen<br />

Datenobjekte als Modulgrenzen verwendet.<br />

Die Modularisierung kann auf Basis des Quellcodes oder auf Basis des B<strong>in</strong>ärcodes geschehen. In<br />

jedem Fall müssen die Grenzen und die Abhängigkeiten der Module identifiziert werden.<br />

4.2.3.1 Basise<strong>in</strong>heiten der Modularisierung<br />

Im Folgenden sollen Konstrukte betrachtet werden, die als Grenzen e<strong>in</strong>er Modularisierung hergenommen<br />

werden können.<br />

Quellcodedateien Die meisten Programmiersprachen lassen e<strong>in</strong>e Unterteilung des Codes <strong>in</strong> e<strong>in</strong>zelne<br />

Dateien zu. Manche Sprachen, wie beispielsweise Java, zw<strong>in</strong>gen den Entwickler dazu,<br />

öffentliche Klassen <strong>in</strong> eigenen Dateien abzulegen, bei anderen Sprachen ist das e<strong>in</strong> freiwilliges<br />

Strukturelement. Geme<strong>in</strong>sam ist jedoch, dass <strong>in</strong> e<strong>in</strong>er Datei Code und Daten zusammengefasst<br />

werden, die <strong>in</strong>haltlich zusammengehören. Diese Aufteilung bietet daher e<strong>in</strong>e gute Möglichkeit<br />

der Modularisierung, die relativ e<strong>in</strong>fach zu extrahieren ist.<br />

Die Strukturierung an Dateigrenzen ist allerd<strong>in</strong>gs relativ grobgranular. In objektorientierten<br />

Sprachen s<strong>in</strong>d <strong>in</strong> e<strong>in</strong>er Datei meist alle Methoden e<strong>in</strong>er Klasse enthalten, <strong>in</strong> funktionalen Sprachen<br />

werden üblicherweise auch mehrere Funktionen <strong>in</strong> e<strong>in</strong>er Datei zusammengelegt, wenn<br />

sie auf denselben Daten arbeiten. Obwohl die Funktionen semantisch zusammengehören, ist<br />

es dennoch wünschenswert, e<strong>in</strong>zelne Funktionen getrennt behandeln zu können. Enthält e<strong>in</strong>e<br />

Datei Thread.c beispielsweise alle Funktionen, um den Zustand von Threads zu verändern,<br />

so möchte man hiervon möglicherweise nur die Funktion zum Erzeugen neuer Threads parken,<br />

da sie nach dem Starten des Programms kaum noch benötigt wird.<br />

Funktionen und globale Daten E<strong>in</strong>e fe<strong>in</strong>ere Gliederung stellt die Unterteilung nach Funktionen 1 dar.<br />

Funktionen erfüllen üblicherweise e<strong>in</strong>e mehr oder weniger wohl def<strong>in</strong>ierte Aufgabe und s<strong>in</strong>d als<br />

Strukturelement <strong>in</strong> fast allen Programmen vorhanden. Sie s<strong>in</strong>d kle<strong>in</strong>er als Quellcodedateien und<br />

erlauben e<strong>in</strong>e fe<strong>in</strong>granulare Aufteilung der Software. Um alle Bestandteile e<strong>in</strong>es Programms zu<br />

erfassen, müssen neben den Funktionen auch globale Daten als Module dargestellt werden.<br />

Im Vergleich zur Modularisierung an Dateigrenzen ist das Identifizieren der Modulgrenzen hier<br />

aufwendiger. Es müssen zusätzliche Maßnahmen getroffen werden, um die Funktionen und<br />

Daten zu extrahieren und e<strong>in</strong>zeln erfassen zu können. Arbeitet man auf Quellcode, so müssen<br />

1 “Funktionen” wird hier als Oberbegriff für Prozeduren, Funktionen und Methoden verwendet<br />

38

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!