Aufrufe
vor 5 Jahren

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

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

ne Geräte, wie ein

ne Geräte, wie ein Compaq h5550 PDA, ein Loewe Aconda Fernseher sowie ein digitaler Bilderrahmen in das Anwendungsszenario eingebunden (siehe Abbildung 128 c) und d)). Elting ist es somit gelungen mit der in dieser Arbeit entstandenen Software-Infrastruktur sowohl heterogene – d.h. Geräte unterschiedlicher Betriebssysteme – in eine Gesamtanwendung einzubinden, als auch eine eigene Konfliktlösungsstrategie zu implementieren. Die Benutzbarkeit der Software-Infrastruktur auf Basis des SODAPOP-Modells kann somit als bestätigt und gegeben angenommen werden. Im Gegensatz zu den in dieser Arbeit entstandenen und beschriebenen Konfliktlösungsstrategien zur Zuteilung von Ereignissen (vgl. Kapitel 6.2.1) und zur Auswahl unter konkurrierenden Komponenten (vgl. Kapitel 6.2.2) handelt es sich bei der von Elting implementierten Konfliktlösungsstrategie um eine ” echte“ Service-Decomposition-Strategie. Sie ist in der Lage auf Basis der UtilityValue- Funktionen eine Aufgabe (Ausgabe von Information an den Benutzer) in unterschiedliche Teilaufgaben (verteilte Informationsausgabe durch unterschiedliche Moden) zu zerlegen105 . Es ist somit zusätzlich – neben der Benutzbarkeit der Infrastruktur auf heterogenen Geräten und der Möglichkeit der Erweiterbarkeit der Software-Infrastruktur um eigene Konfliktlösungsstrategien – nachgewiesen, dass zusätzlich zu Service-Binding-Strategien auch Service-Decomposition-Strategien ausführbar sind. Die in Kapitel 7.2 und Kapitel 8.2 beschriebenen Anwendungen (multimodale Steuerung von Medienapplikationen und intelligente Umgebungen) zeigen, dass die in dieser Arbeit beschriebene Software-Infrastruktur auf Basis des SODAPOP-Modells die wichtigen geforderten Eigenschaften der Dynamik wie Erweiterbarkeit und Austauschbarkeit erfüllt. Im Gegensatz zu den hart-verdrahteten“ Kommunikationsansätzen auf der Ba- ” sis zentraler Routingregeln (wie Open Agent Architecture, vgl. Kapitel 3.7 oder Galaxy Communicator, vgl. Kapitel 3.8) muss bei Hinzufügen einer Komponente (vgl. das dynamische Hinzufügen von neuen Mediengeräten in Kapitel 7.2) keinerlei Eingriff an Routingservern oder anderen zentralen Stellen gemacht werden. Aber auch im Vergleich zu den peer-to-peer-Systemen wie AMIGO (vgl. Kapitel 3.1) in denen das Versenden von Nachrichten auf der Basis von komponenten-internen Enhanced-Service-Discovery“- ” Methoden bewerkstelligt wird zeigen sich Unterschiede. Die von der Software-Infrastruktur bereits angebotenen Konfliktlösungsstrategien lassen sich einsetzen, um sich vernünftig106 verhaltende Komponentenensembles zu entwickeln. Mit der Ausführung dieser Konfliktlösungsstrategien sind die Komponenten nicht belastet. Man kann sich leicht überlegen, welchen Aufwand es für die unterschiedlichen Entwickler der Dialog- und Strategiekomponenten der einzelnen Medienapplikationen aus Abbildung 97 bedeuten würde, jeweils interne Service-Discovery- und Service-Binding-Methoden zu implemen- 105 Bei der Konfliktlösungsstrategie zur Auswahl unter konkurrierenden Komponenten (vgl. Kapitel 6.2.2) handelt es sich genaugenommen um eine Strategie zum eindeutigen Service Binding. Auf Basis der von den einzelnen Komponenten abgegebenen UtilityValue-Funktionen wird die am besten geeignete Komponente gesucht und damit ein Diensteanbieter an den gesuchten Dienst gebunden. 106 Vernünftig bedeutet hier, dass sinnvolle Anwendungsszenarios mit den in dieser Arbeit entstandenen Konfliktlösungsstrategien implementiert werden können. Dass es darüber hinaus möglich ist, domänenabhängige und damit szenariengeeignete Konfliktlösungsstrategien zu implementieren, ist in dieser Arbeit am Beispiel der multimodalen Ausgabestrategie bereits hinreichend dargelegt worden. 253

tieren 107 . Die dynamische Auswertung der von den Komponenten bereit gestellten Utility- Value-Funktionen, sowie die Fähigkeit der Konfliktlösungsstrategien eine unbestimmte Anzahl an Komponenten zu ” moderieren“ macht hier die Dynamik der in Kapitel 7.2 und Kapitel 8.2 beschriebenen Applikationen und Anwendungen aus. Zuletzt soll hier – um die Leistungsfähigkeit der Software-Infrastruktur und der in dieser Arbeit definierten Komponententopologie mitsamt der dafür vorgesehenen Konfliktlösungsstrategien darzulegen – darauf hingewiesen werden, dass die beschriebenen Applikationen sehr umfangreich im Bezug auf die Heterogenität der beteiligten Komponenten und Geräte und im Bezug auf ihre Diversifikation sind. Sowohl Anwendungen im Bereich der Unterhaltungselektronik als auch Anwendungen im Bereich von Besprechungsräumen sind entstanden. Dabei sind Geräte unterschiedlichen Hardwaretyps und unterschiedlicher Betriebssysteme in die verschiedenen Anwendungsszenarios eingebunden worden. Die Bandbreite der realisierten Komponenten reicht hier von einfachen graphischen Benutzeroberflächen, über regelgesteuerte Inferenzsysteme, bis hin zu realen Aktuatoren für Fernsehgeräte oder Licht- und Rollosteuerung. Die Anwendbarkeit der in dieser Arbeit beschriebenen Software-Infrastruktur kann somit als nachgewiesen angesehen werden. 9.2 Assistenz und Untersützung für den Benutzer Ein zweiter wichtiger Schwerpunkt dieser Arbeit besteht neben der Software-Infrastruktur für dynamische Geräteensembles und der Definition einer Komponententopologie und geeigneten Konfliktlösungsstrategien für Ambient-Intelligence-Szenarios in der Realisierung intelligenter Anwendungen und Umgebungen. Hierbei liegt das Hauptaugenmerk auf der Implementierung von Dialog- und Strategiekomponenten. Streng genommen gehören diese Komponenten in den Bereich der Assistenten- und Agententechnologie, da sie mit Mitteln künstlicher Intelligenz auf Basis von externen Daten (z. B. Kontextdaten oder persönlichen Benutzerprofilen) mögliche Handlungsweisen inferieren und dem Benutzer Assistenz anbieten. Schon 1988 empfahl Sheridan [194] die Unterscheidung verschiedener Assistenzgrade. In steigender Folge der Assistenz unterscheidet Sheridan: 1. Keinerlei Assistenz: Das System bietet keinerlei Hilfen an, der Benutzer ist für alle Entscheidungen und Aktionen verantwortlich. 2. Angebotsassistenz: Das System bietet alle verfügbaren und möglichen Benutzungswege an. Der Benutzer ist weiterhin für die daraufhin erfolgenden Entscheidungen und für die Ausführung der Aktionen verantwortlich. 3. Filterassistenz: Das System bietet eine Auswahl möglicher Benutzungswege an. 4. Beraterassistenz: Das System bietet nur einen möglichen Benutzungsweg an. Es 107 Wie bereits erwähnt zeigen Erfahrungen aus vergangenen Projekten – z. B. EMBASSI – dass hier die meisten Entwickler den Weg wählen würden, Nachrichten direkt an die eigenen bekannten Komponenten zu senden. Dieses Vorgehen unterbindet erfahrungsgemäß die Dynamik innerhalb eines Ensembles und unterbindet der Fähigkeiten zur Kooperation. 254

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