Aufrufe
vor 5 Jahren

8 Werkzeuge f¨ur Rapid Prototyping mit verteilten Soft - tuprints

8 Werkzeuge f¨ur Rapid Prototyping mit verteilten Soft - tuprints

vergleichsweise wenige

vergleichsweise wenige Komponenten (zwei Eingabe- und zwei Ausgabekomponenten und drei verschiedene Geräte mit jeweils einer Dialogkomponente, eine Strategiekomponente und einem Aktuator) miteinander kooperieren, machen deutlich, dass bei einer etwas erhöhten Anzahl an Komponenten der Weg des Datenflusses für den Entwickler eines solchen Komponentenensembles nur schwer nachvollziehbar ist. Die Entwicklung wird somit aufgrund fehlender Transparenz unnötig erschwert. Besonders betrifft dies die Entwicklung von neuen Konfliktlösungsmechanismen und der Möglichkeit der Beurteilung ihrer Entscheidungen, aber auch die Entwicklung neuer Komponenten (z. B. neuer Dialogkomponenten oder Strategiekomponenten). Eine Visualisierung des Komponentenmodells und des Datenflusses würde es hier möglich machen, die Integration neuer Komponenten in das Datenflussmodell eines bereits vorhandenen Komponentenensembles nachzuvollziehen und gegebenenfalls Änderungen zur Laufzeit vornehmen zu können. Um dies zu leisten wurde eine Topologie-Visualisierung für dynamische Komponentensysteme am Beispiel der im DYNAMITE-Projekt verwendeten Komponententopologie realisiert [126]. Diese ist direkt mit einem SODAPOPD(AEMON) verbunden (vgl. Kapitel 5.1). Bei der Implementierung der Visualisierung wurde davon ausgegangen, dass nur ein SODAPOPD(AEMON) für das gesamte Komponentenensemble zur Verfügung steht. Die Visualisierung dient der Entwicklung und Erprobung von neuen Komponenten und Strategien und soll nicht den Datenfluss von vielen verteilten Geräten (mit verteilten SODAPOPD(AEMON)s, vgl. Kapitel 5.2) visualisieren. Abbildung 110 zeigt die Visualisierung der Komponententopologie wie sie im ersten Beispiel in Kapitel 7.2 in Abbildung 92 illustriert ist. Sobald eine Komponente eine Nachricht in einen Kanal gibt, zeigt dies die Visualisierung durch gleichmäßiges kurzes Blinken der Komponente an. Danach blinkt die Verbindung der Komponente zum Kanal und danach der Kanal selbst (Abbildung 110 b)). Hat der Kanal die UtilityValue-Funktionen der registrierten Komponenten gemäß dem SODAPOP-Modell evaluiert und die Konfliktlösungsstrategie angewendet, so sendet er die Nachricht an den entsprechenden Empfänger-Transducer. Die Visualisierung zeigt dies durch regelmäßiges Blinken des Kanals, des Verbindungsstücks zum Empfänger-Transducer und zuletzt durch Blinken des Transducers an, der die Nachricht empfängt (Abbildung 110 c)). In den Anwendungsbeispielen, die in Kapitel 7.2 beschrieben sind, konnektiert sich zum bereits vorhandenen Filmwiedergabegerät ein solches weiteres Gerät, das seine eigenen Dialog- und Strategiekomponenten und seinen eigenen Aktuator mitbringt. Abbildung 111 zeigt das Verhalten der Visualisierung ausgehend vom bereits beschriebenen Komponentenensemble bei der Konnektion des neuen Filmwiedergabegerätes (Abbildung 111 b)). Die Visualisierung erlaubt jederzeit per Mausinteraktion die Veränderung der Ansicht auf das dargestellte Komponentenensemble (vgl. Abbildung 111 c)). Dadurch ist es dem Entwickler von Komponenten oder von Kanalstrategien jederzeit möglich den Fokus auf die interessanten Stellen der Komponententopologie zu setzen. Zuletzt zeigt Abbildung 112 das letzte der drei in Kapitel 7.2 beschriebenen Anwendungsbeispiele mit dem zusätzlichen Beitritt des dritten Gerätes, das ebenso eine eigene Dialogkomponente, eine eigene Strategiekomponente und einen eigenen Aktuator mitbringt. Andere Software-Infrastrukturen sind häufig nicht mit Visualisierungen der Kommunikationswege der einzelnen Komponenten ausgestattet. Eine 219

a) Dreidimensionale Visualisierung des ersten DYNAMITE-Anwendungsbeispiels aus Kapitel 7.2. b) Eingabekomponente . . . sendet eine Nachricht ...indenEreigniskanal c) Ereigniskanal . . . sendet Nachricht an . . . Empfängerkomponente Abbildung 110: Visualisierung des Datenflusses von einer Komponente in einen Kanal (b) und von einem Kanal nach Ausführung der Konfliktlösungsstrategie zu einer Komponente (c). Ausnahme bildet hier die in Kapitel 3.5 beschriebene und diskutierte Multiplatform. Sie verfügt über eine sogenannte Testbed GUI, die zur Systemüberwachung, zur Bedienung des Testbed Managers und zur Modifizierung der einzelnen Konfigurationen der verschiedenen Komponenten dient. Im EMBASSI-Projekt wurde zur Überwachung der von Komponente zu Komponente gesendeten Nachrichten ein Router mit integrierter GUI einge- 220

eine infrastruktur f ¨ur das management von verteilten ... - DVS