Entwicklung verteilter Geräte und Anwendungen für die UPnP

Transcrição

Entwicklung verteilter Geräte und
Anwendungen für die UPnP Plattform
unter besonderer Berücksichtigung
automatisch generierter User Interfaces
Jakob S. Doppler
DIPLOMARBEIT
eingereicht am
Fachhochschul-Masterstudiengang
Digitale Medien
in Hagenberg
im Juni 2006
c Copyright 2006 Jakob S. Doppler
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Hagenberg, am 26. Juni 2006
Jakob S. Doppler
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
ix
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Technische Begriffserklärungen
2.1 Bluetooth . . . . . . . . . . . . . . . .
2.1.1 Technische Details . . . . . . .
2.1.2 Architektur . . . . . . . . . . .
2.1.3 Profile . . . . . . . . . . . . . .
2.1.4 Vergleichbare Funktechnologien
2.2 Service-Plattformen . . . . . . . . . .
2.2.1 JINI . . . . . . . . . . . . . . .
2.2.2 UPnP . . . . . . . . . . . . . .
2.2.3 OSGi . . . . . . . . . . . . . .
1
2
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
7
7
8
8
11
15
3 Geräte
3.1 Szenario . . . . . . . . . . . . . . . . . . . . .
3.2 Konzept . . . . . . . . . . . . . . . . . . . . .
3.3 UPnP-Technologie . . . . . . . . . . . . . . .
3.4 Implementierung . . . . . . . . . . . . . . . .
3.4.1 Sensor-Hardwaredevice . . . . . . . . .
3.4.2 Webcam Streaming-Server und Client
3.4.3 UPnP-Winamp Media Player . . . . .
3.4.4 MIDI-Device . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
19
19
20
23
26
26
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
v
4 Generierung grafischer User Interfaces
4.1 Anforderungen im GUI-Design . . . . . . . . . . . . . .
4.2 Anforderungen im Pervasive Computing . . . . . . . . .
4.2.1 Kontext-sensitive und verteilte Anwendungen . .
4.2.2 Geräteeigenschaften . . . . . . . . . . . . . . . .
4.3 Techniken der GUI-Entwicklung . . . . . . . . . . . . . .
4.3.1 Window Manager und Toolkits . . . . . . . . . .
4.3.2 Web-basierte Entwicklungen . . . . . . . . . . . .
4.3.3 Interaktive GUI-Builder . . . . . . . . . . . . . .
4.4 XML GUI-Sprachen . . . . . . . . . . . . . . . . . . . .
4.4.1 XAML . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 XUL . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 XForms . . . . . . . . . . . . . . . . . . . . . . .
4.4.4 UIML . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5 XIML . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Model-based User Interface . . . . . . . . . . . . . . . .
4.5.1 User Interface Generierung . . . . . . . . . . . .
4.5.2 Projekt – Pebbles Personal Universal Controller
4.5.3 Projekt – Supple . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
30
30
31
32
32
32
34
34
35
36
36
38
39
42
44
44
48
5 GUI-Builder
5.1 Konzept . . . . . . . . . . . . . . . . . . . . . .
5.1.1 System-Schnittstellen . . . . . . . . . .
5.1.2 Setup . . . . . . . . . . . . . . . . . . .
5.2 Implementierung - PC . . . . . . . . . . . . . .
5.2.1 Entwicklung mit OSGi . . . . . . . . . .
5.2.2 Systemaufbau . . . . . . . . . . . . . . .
5.2.3 GUI-Generator . . . . . . . . . . . . . .
5.2.4 UI-Erweiterungen . . . . . . . . . . . .
5.3 Implementierung - Smart Phone . . . . . . . .
5.3.1 Entwicklung mobiler Java-Anwendungen
5.3.2 Gateway . . . . . . . . . . . . . . . . . .
5.3.3 Mobile Client . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
56
56
56
58
60
66
70
71
72
74
6 Fazit
6.1 Erreichte Ziele . . .
6.1.1 Geräte . . . .
6.1.2 GUI-Builder
6.2 Ausblick . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
79
79
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Inhalt der CD-ROM
82
A.1 Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
INHALTSVERZEICHNIS
A.4 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
vi
83
84
Vorwort
Mit der Fertigstellung der vorliegenden Diplomschrift geht ein weiterer Abschnitt in meinem Leben zu Ende. Der Blick zurück an den Beginn des
Studiums lässt mich kaum glauben, dass seither fünf Jahre vergangen sind.
Auch wenn die Zeit an der Fachhochschule Hagenberg mit viel Arbeitsaufwand und Engagement verbunden war, möchte ich sie dennoch nicht missen.
Viele gute Erinnerungen und lehrreiche Erfahrungen in fachlicher als auch
in menschlicher Hinsicht tragen zu diesem positiven Eindruck bei.
Die Faszination der Technik liegt für mich in ihrer gestalterischen Schaffenskraft, die, wenn sie mit Wissen und Gewissen eingesetzt wird, Großartiges vollbringen kann. Ich hoffe mit meiner Arbeit einen kleinen Teil zu
einem technologischen Fortschritt beizutragen, der in Einklang mit den Bedürfnissen und Werten unserer Gesellschaft steht. Daher scheint es auch
angemessen, jene Personen zu nennen, die mir das Gefühl geben eben dieses
erreichen zu können.
Im Rahmen einer mehrjährigen Forschungsarbeit konnten mit meinem
Projektpartner und Freund Bernhard Wally neue Aspekte einer intelligenten und vernetzten Gerätelandschaft beleuchtet werden, wie sie in ein paar
Jahren vielleicht in jedem Haushalt zu finden sein wird. Dafür und für die
vielen, teils lustigen Stunden gemeinsamen Wirkens sei ihm gedankt. Auch
meinem Betreuer DI Dr. Christoph Schaffer, der mir im Laufe meines Diplomstudiums in zahlreichen Gesprächen mit guten Ratschlägen und fachlichem Wissen zur Seite gestanden ist, gilt mein besonderer Dank.
Die Erkenntnis, dass das Leben neben der Schönheit der Technik auch
noch andere, ebenso wichtige Facetten zu bieten hat, habe ich zweifelsohne
meiner Familie und den zahlreichen, guten Freundschaften in Hagenberg
und Gallneukirchen zu verdanken. Insbesondere sind hier meine Eltern Regina und Erwin Doppler genannt, die mir in vielen richtungsweisenden Entscheidungen, denen ich im Laufe meines bisherigen Lebens begegnete bin,
geholfen haben und mir meine Ausbildung ermöglichten.
vii
Kurzfassung
Getragen von der rasanten Entwicklung mobiler und eingebetteter Geräte,
bringen einheitliche Kommunikationsstandards eine neue Qualität für die
im Netzwerk verteilten Anwendungen. Es existiert der Wunsch nach intelligenten Diensten, die in der eigenen Umgebung und in verschiedensten
Lebenssituationen in Anspruch genommen werden können. Ein weitgehend
ungeklärter Aspekt in diesem Zusammenhang sind Automatismen für die
Darstellung und Interaktion mit diesen verteilten Diensten.
Im Rahmen der vorliegenden Arbeit werden auf Basis der UPnP ServicePlattform verschiedene Geräte und Anwendungen für ein mögliches Mediensteuerungsszenario beleuchtet. Der erste Schwerpunkt liegt in der Entwicklung von Eingabemedien. Anhand eines sensorbasierten Hardwaredevices
und einer Kamera mit Bewegungserkennung soll in Verbindung mit einem
UPnP-basierten Framework zur Verknüpfung von Gerätediensten die Fähigkeit zur dynamischen Vernetzung und Ansteuerung anderer, verteilter
Geräte demonstriert werden.
Im zweiten Teil werden Anforderungen für die automatisierte Generierung von User Interfaces zur Fernsteuerung der Dienste ermittelt. Der Benutzer soll unabhängig vom Ort und der Plattform des darstellenden Endgerätes mit den netzwerkbasierten Anwendungen interagieren können. Anhand
zweier Prototypen für den PC und für das Smart Phone wird die technische
Machbarkeit dieses Ansatzes gezeigt.
viii
Abstract
Advances in mobile and embedded technology and communication standards for distributed device computing offer new opportunities for home
appliances. This trends reflects a deep longing for smart and sophisticated
services that help us in everyday life activities. But taking automated representation and interaction with these services into account, there are still
a number of open issues.
The present thesis deals with research and development of various applications and devices that are based on the UPnP service platform. The first
idea places emphasis on prototyping input devices for a UPnP-based media
control framework. Thus methods for integrating a sensor-based device and
a monitoring camera for motion detection have to be found.
The second part covers research on automated user interface generation for distributed network services. Since users should not be restricted in
choosing their favorite environment for application usage, two GUI building
applications to remotely control these services were implemented. The first
one is based on the PC platform. The second one tries to employ the remote
control metaphor by using a smart phone.
ix
Kapitel 1
Einleitung
Längst hat sich das Internet als globales Kommunikationsnetzwerk etabliert.
Waren die Anfänge des Mediums vorrangig von der schnellen Verbreitung
und Beschaffung von Informationen geprägt, so kam im Laufe der Zeit ein
weiterer Aspekt zur Geltung: Die Nutzung von automatisierten Dienstleistungen in Echtzeit zeigte neue Qualitäten der Vernetzung auf und sicherte
deren nachhaltigen Erfolg. Analog dazu vollzog sich auch im Softwaredesign
ein grundlegender Wandel von maßgefertigten Einzellösungen zu der Idee
von interoperablen Applikationen, die durch die gemeinsame Standardisierung von Technologien getragen wird. Erwähnenswert hierfür ist die universelle Beschreibungssprache XML (Extended Markup Language), die für die
Repräsentation verschiedenster Daten herangezogen wird.
Diese Entwicklung entfacht den Wunsch nach intelligenten Diensten, die
auch in der eigenen Umgebung und in verschiedensten Lebenssituationen
in Anspruch genommen werden können [13]. Der Benutzer soll unabhängig
von Ort und Zeit mit kontextsensitiven Anwendungen1 interagieren können.
Möglich wird dies durch die zunehmende Verbreitung von Embedded Systems2 und mobilen Endgeräten wie dem PDA (Personal Digital Assistant),
dem Mobiltelefon oder dem Laptop, die mit Nah- und Fernfunktechnologien
ausgestattet sind. In diesem Zusammenhang spricht man von Ubiquitous
Computing 3 . Die Begriffe bezeichnen die alles durchdringende Vernetzung
von intelligenten Gegenständen“ des Alltags [40]. Organisationen wie die
”
Digital Living Network Association (DNLA)4 beschäftigen sich mit den Anforderungen, die es am Weg zur universellen Vernetzung von Gerätediensten
im Haushalt zu erfüllen gilt und dem möglichen Mehrwert, der daraus generiert werden kann.
1
Kontextsensitive Anwendungen besitzen die Fähigkeit, sich an aktuelle Gegebenheiten
und Umwelteinflüsse anzupassen.
2
Eingebettete“ Computersysteme, die für den Benutzer - meist unsichtbar - Dienste
”
verrichten und auf spezialisierter Hardware basieren und mit Sensoren ausgestattet sind.
3
auch Pervasive Computing
4
DNLA - http://www.dnla.org
1
KAPITEL 1. EINLEITUNG
1.1
2
Motivation
Der Grundstein für die Realisierung der Vision einer pervasiven Umgebung
scheint mit den fortschreitenden Entwicklungen von mobilen und EmbeddedTechnologien gelegt. Ein weitgehend ungeklärter Aspekt hingegen sind Standards und Automatismen für die Darstellung und Interaktion mit verteilten
Diensten.
Service-Plattformen wie Universal Plug and Play (siehe Kapitel 2.2.2)
sind plattformunabhängige Software-Bibliotheken, die dem Entwickler die
große Verantwortung hinsichtlich einheitlicher Geräteschnittstellen und automatischer Erkennung der Netzwerkdienste abnehmen und diese von einem
beliebigen Ort aus fernsteuerbar und überwachbar machen. Sie treffen jedoch
keine Entscheidungen hinsichtlich der Repräsentation der Interaktionsdaten.
Aus diesen Überlegungen entsteht die Idee sowohl Eingabegeräte für den
Einsatz in einem Mediensteuerungsszenario zu entwickeln, als auch Forschung in Richtung der automatisierten Generierung von User Interfaces
zur Fernsteuerung von verteilten Geräten zu betreiben. Erstere ist Teil eines
lang ersehnten Wunsches, den PC als vorrangiges Interaktionsmedium für
computerisierte Dienste ablösen zu können. In diesem Zusammenhang wird
ein Weg gesucht, um Sensorik und die Bewegungserkennung einer Kamera
als Auslöser zur Steuerung verteilter Netzwerkdienste nutzen zu können.
Die zweite Idee befasst sich mit Interaktionen, in denen ein Display hingegen notwendig und sinnvoll ist. Hierfür muss ein Konzept zur automatisierten Generierung von User Interfaces im Kontext verteilter Geräte und
Anwendungen erstellt werden. Möglich wird dies durch die Architektur von
UPnP. Wird ein neues Gerät dem Netzwerk hinzugefügt, werden alle interessierten Teilnehmer darüber informiert und erhalten eine funktionale Beschreibung der Gerätedienste. Diese Beschreibung kann genutzt werden, um
ein Interface zur Steuerung des Gerätes darzustellen.
Da die Problemstellung der automatisierten Generierung von User Interfaces nicht alleine auf die Domäne der verteilten Netzwerke beschränkt
ist, gibt es einige, vielversprechende Ansätze. Mehrere XML-basierte Sprachen und GUI-Building Systeme (siehe Kapitel 4) bieten Lösungsansätze
auf verschiedenen Abstraktionsebenen an. Diese reichen von einer konkreten Beschreibung und Positionierung der Steuerelemente bis hin zu einer
Verknüpfung zwischen den Interaktionsdatentypen der Gerätefunktion und
abstrakten Elementen, denen abhängig von den Vorgaben der Plattform eine
andere grafische Repräsentation zukommt.
1.2
Abgrenzung
Ziel der Arbeit ist die Nutzung der UPnP Service-Plattform zur Erstellung
netzwerkbasierter Geräte, die in einen Wohn- und Arbeitsraum integriert
KAPITEL 1. EINLEITUNG
3
werden können und entweder passiv Informationen über Personen in der
Umgebung beziehen oder als physisches Interaktionsmedium einsetzbar sein
sollen. Zudem müssen, um im Netzwerk verteilte Gerätedienste unter einem
gemeinsamen User Interface Standard ansprechen zu können, bestehende
User Interface-Auszeichnungssprachen und GUI-Building Systeme zur Fernsteuerung einer UPnP-Gerätelandschaft evaluiert werden.
Anhand prototypischer Implementierungen soll der Einsatz der Technologie in einem Mediensteuerungsszenario gerechtfertigt werden. Dazu zählen
mit einem Sensormodul und einer Kamera zur Bewegungserkennung mehrere
UPnP-fähige Geräte. Weiters soll die Generierung grafischer User Interfaces
zur Fernsteuerung der verteilten Anwendungen am PC und für die Smart
Phone-Plattform demonstriert werden.
Die Arbeit ist in zwei Bereiche unterteilt. Der erste befasst sich mit den
technischen Vorrausetzungen und der Erstellung der Geräte. Im zweiten Teil
werden die Ergebnisse der Recherche zur automatisieren User Interface Generierung anhand zweier Prototypen beleuchtet. Die Schwerpunkte umfassen
jeweils zwei Kapitel:
Kapitel 2 stellt die technischen Vorraussetzungen für die Arbeit mit den
Geräten vor. Es wird der Funkstandard Bluetooth beleuchtet und die Wahl
UPnP als bevorzugte Service-Plattform vorgestellt.
Kapitel 3 versucht mit einem pervasiven Szenario die Intention der Arbeit
zu erklären und beleuchtet anhand der entwickelten Geräte den ersten Teil
der Implementierung.
Kapitel 4 beschäftigt sich mit vorhandenen Systemen und XML-Sprachdefinitionen rund um das Thema einer generischen Beschreibung und Generierung von grafischen Benutzeroberflächen.
Kapitel 5 demonstriert und dokumentiert die praktische Anwendbarkeit
einer generischen Mediensteuerung für verteilte Geräte anhand zweier prototypischer GUI-Builder Anwendungen für PC und Smart Phone.
Kapitel 6 ist eine Zusammenfassung der gewonnenen Erkenntnisse und
wagt einen Ausblick in die nahe Zukunft.
Kapitel 2
Technische
Begriffserklärungen
2.1
Bluetooth
Durch den Bedarf einer kostengünstigen Technologie mit niedrigem Energieverbrauch als Ersatz für kabelgebundene Kommunikation, wurde 1994 von
dem Mobilfunkunternehmen Ericsson die Bluetooth-Technologie1 ins Leben
gerufen. Das rege Interesse namhafter Hersteller wie IBM, Intel und Nokia
führte zur Gründung des Entwicklerkonsortiums Bluetooth Special Interest
Group (Bluetooth SIG)2 und zur Erhebung von Bluetooth zum Industriestandard gemäß IEEE3 802.15.1. Wenngleich auch die flächendeckende Einführung von Anfang an in einer allgemeinen Euphorie prognostiziert wurde,
vergingen einige Jahre bevor die Akzeptanz gegeben und eine genügende
Verbreitung an Endgeräten mit Bluetooth-Hardware gegeben war.
2.1.1
Technische Details
Die Datenübertragung bei Bluetooth erfolgt über das lizenzfreie ISM-Frequenzband im Bereich zwischen 2,400 GHz und 2,480 GHz [31]. Da dieses
Band jedoch von einer Vielzahl an Funktechnologien, darunter auch der
WLAN-Standard (IEEE 802.11) oder die Schnurlostelefonie, genutzt wird,
braucht es ein robustes Verfahren um die Übertragungsqualität zu gewährleisten. Diese Robustheit wird durch ein Frequenzsprungverfahren (Frequency
Hopping) garantiert. Darunter versteht man den Wechsel des Trägersignals
alle 625 µs zwischen den bei Bluetooth definierten 79 Frequenzstufen im
1-MHz Abstand. Die maximale Übertragungsrate liegt dabei in den Versionen 1.1 und 1.2 bei 723,1 kbit/s und in der verbesserten Version 2.0 EDR
1
Bluetooth - http://www.bluetooth.com/
Bluetooth SIG - https://www.bluetooth.org/
3
IEEE (Institute of Electrical and Electronics Engineers) - http://ieee.org- eine Institution zur Standardisierung von Computertechnologien
2
4
KAPITEL 2. TECHNISCHE BEGRIFFSERKLÄRUNGEN
5
WAE
WAP
SDP
TCP/UDP
vCard/vCal
IP
OBEX
PPP
TCS BIN
AT
Command
AUDIO
RFCOMM
L2CAP
HCI
LMP
Baseband
Bluetooth Radio
Abbildung 2.1: Bluetooth Stack Architektur (siehe [31]).
(Enhanced Data Rate) bei 2,1 Mbit/s. Um der Anforderung einer kostengünstigen und energiesparenden Funktechnologie gerecht zu werden, wurden
drei Leistungsklassen für verschiedene Einsatzzwecke geschaffen. Klasse 1Geräte sind für eine Reichweite von bis zu 100 m bei einer Leistung von
100 mW konzipiert. Am anderen Ende liegen Klasse 3-Geräte mit 1 m und
1 mW. Die breite Palette der Unterhaltungselektronik und mobilen Endgeräte arbeitet mit Klasse 2-Chips bei einem Verbrauch von 2,5 mW und einer
Reichweite bis zu 10 m [31].
In einem Bluetooth Netzwerk (Piconet) können sich bis zu 65.000 Geräte
befinden, von denen jedoch nur acht aktiv sein dürfen. Ein Master-Gerät
sorgt für sie Synchronisation der sieben Slaves. Ein Bluetooth-Teilnehmer
kann sich in mehreren Netzwerken aufhalten, wodurch eine netzwerkübergreifende Kommunikation möglich wird. Der Zusammenschluss mehrerer Piconets bezeichnet man als Scatternet.
2.1.2
Architektur
Der Bluetooth Protokollstack wurde von der Bluetooth SIG entworfen und
enthält eine Sammlung hierarchisch angeordneter Protokolle (siehe Abbildung 2.1). Erklärte Designziele waren eine bindende Richtlinie für die Implementierung von Bluetooth-Geräten und maximale Interoperabilität durch
die Wiederverwendung älterer Kommunikationsprotokolle in den höheren
Schichten. Die Protokolle werden in vier grundlegende Schichten eingeteilt
[31] (siehe Tabelle 2.1.2).
Protocol Layer
Bluetooth Core Protocols
Cable Replacement Protocol
Telephony Control Protocols
Adopted Protocols
6
Protocols
Baseband, LMP, L2CAP, SDP
RFCOMM
TCS Binary, AT-commands
PPP, TCP/UDP/IP, OBEX,
WAP, vCard, cCal, IrMC,
WAE
Tabelle 2.1: Bluetooth-Architektur Protokollschichten (siehe [5]).
Core Protocols: Das Baseband sorgt für die physikalische Verbindung
und die Synchronisation der Netzwerkteilnehmer mittels des zuvor erwähnten Frequenzsprungverfahrens. Echtzeitkritische Audiodaten werden ebenfalls ohne zusätzlichen Overhead über dieses Protokoll übertragen. Das Link
Manager Protocol (LMP) ist für den Verbindungsaufbau zwischen den Bluetooth-Geräten sowie Authentifizierung und Verschlüsselung zuständig. Das
Logical Link Control and Adaption Protocol (L2CAP) fungiert als Vermittlungsschicht zwischen höherliegenden Protokollen und dem Host Controller
Interface (HCI). Geräte- und Dienstinformationen können nach erfolgreicher
Verbindung mit dem Simple Discovery Protocol (SDP) abgefragt werden.
Cable Replacement Protocol - RFCOMM: Zur Emulation des seriellen Datenübertragungskanal RS232 wurde die RFCOMM -Schnittstelle
geschaffen. Dadurch können eine große Anzahl an höherliegenden Protokollen ohne Anpassungsaufwand auch über Bluetooth Funk betrieben werden.
Telephony Control Protocols: Auf Empfehlung der International Telecommunication Union (ITU-T) flossen AT-Steuerkommandos (AT-commands) in die Bluetooth-Spezifikation mit ein. Das zusätzliche Telephony
Control Protocol - Binary (TCS Binary) zeichnet sich für den Verbindungsaufbau von Daten- und Sprachübertragung verantwortlich.
Adopted Protocols: Um mit IP basierten Protokollen wie TCP und
UDP kommunizieren zu können, wurde das Point-to-Point Protokoll (PPP)
entwickelt. Es verwaltet den Paketversand des Bluetooth-Gerätes und ermöglicht die Darstellung von Internetinhalten mit dem Wireless Application Protocol (WAP) und der aufbauenden Wireless Application Environment (WAE) Anwendungen. Object Exchange (OBEX) ist der InfrarotSpezifikation entnommen und ermöglicht den schnellen Austausch von Objekten ohne den Transportkanal, in diesem Fall RFCOMM, zu definieren.
Ein Verwendungszweck ist das Synchronisieren von Kalendern (vCal) und
das Austauschen von Business Cards (vCard).
2.1.3
7
Profile
Im Vergleich zu anderen Funktechniken wie WLAN, die einmal spezifiziert
werden und eine starre Auslegung verlangen, lebt die Bluetooth-Spezifikation vor allem durch ihre hochgradige Flexibilität und Erweiterbarkeit. Verantwortlich dafür ist der vielschichtige Aufbau der Bluetooth-Architektur.
Um den verschiedenartigen Anwendungsmöglichkeiten für unterschiedliche
Geräteklassen gerecht werden zu können, bedarf es eines komponentenbasierten Ansatzes, der es durch einfachen Austausch von Protokollen schafft,
die gewünschten Szenarien abzudecken. Aufbauend auf einem generischen
Protokollstack setzen spezifischere Protokolle auf, die in einer Vererbungshierarchie angeordnet sind [20]. Profile sind Kombinationen dieser Komponenten, die bestimmte Rückschlüsse auf den Aufbau und die Zusammensetzung des Bluetooth Protokollstacks zulassen. Die Interoperabilität zwischen
zwei Bluetooth-Geräten ist von der Unterstützung der gemeinsamen Profile
abhängig. Beim Verbindungsaufbau tauschen die Teilnehmer diese aus und
ermitteln, ob sie zueinander kompatibel sind.
Es existiert eine Vielzahl an Profilen, die unter anderem die Synchronisation und Vernetzung, den Austausch von Daten und Dokumenten, die
Ein- und Ausgabe auf Endgeräten (FAX, Drucker) oder die Übertragung von
Audiodaten über Headset und Mobiltelefon definieren. Erwähnenswert ist in
diesem Zusammenhang eine Reihe an Profilen, die für die Mediensteuerung
interessant sind. Das Personal Area Network -Profil definiert, wie sich alle
in Reichweite befindlichen Geräte zu einem Ad-Hoc PAN-Netzwerk zusammenschließen können und Zugang zu einem LAN erhalten. Einen weiteren
Schritt in Richtung Vernetzung von Diensten geht die Bluetooth SIG mit
dem Entwurf für das Extended Service Discovery Protocol (ESDP), das zur
Erkennung von UPnP Geräten herangezogen werden soll. Die Liste der Profile ist einer ständigen Veränderung unterworfen und wird von der Bluetooth
SIG verwaltet4 .
2.1.4
Vergleichbare Funktechnologien
Im den letzten Jahren entwickelte sich rund um die Idee des Mobile Computing und die dadurch gewonnene Ortsunabhängigkeit ein kompetitives Geschäft. Neben Bluetooth drängen eine Menge ähnlicher Technologien auf den
Markt und eine steigende Anzahl an multifunktionalen Endgeräten mit unterschiedlichsten Anforderungen tragen ihren Teil dazu bei, dass die Wahl
nicht immer leicht fällt. Waren die Grenzen zwischen Wireless LAN und
Bluetooth anfangs noch relativ klar definiert, kann eine Überschneidung mit
Technologien wie ZigBee, Near Field Communication (NFC) und Radio Fre4
Eine aktuelle Liste der Bluetooth Profil-Spezifikationen findet sich unter http://
bluetooth.com/Bluetooth/Learn/Technology/Specifications/. Eine Liste der Entwürfe ist unter https://www.bluetooth.org/spec/ abrufbar
8
quency Identification (RFID) nur schwer geleugnet werden5 . Dies ruft auch
unweigerlich Probleme in der Standardisierung durch die IEEE auf den Plan,
wie sie im aktuellen Formatstreit um Ultra Wide Band (UWB), das als Basis
für das zukünftige drahtlose USB gilt, ersichtlich sind. Bluetooth wird dennoch an den Spezifikation der beiden gegensätzlichen Konsortien WiMedia
Alliance6 und dem UWB Forum7 mitwirken, verspricht UWB doch große
Datenübertragungsraten bei niedrigstem Energieverbrauch.
2.2
Service-Plattformen
Technologien wie Jini 8 und Universal Plug and Play (UPnP)9 wurden entwickelt, um Ordnung in die heterogene Landschaft verteilter Geräte und
Dienste zu bringen und die gegenseitige Kommunikation zu ermöglichen.
Neben der einheitlichen Kommunikationsschnittstelle ist auch die automatisierte Ad-Hoc-Vernetzung und Diensterkennung (Service Discovery) ein vorrangiges Ziel10 . Unter Ad-Hoc versteht man in der Informatik-Terminologie
die Vernetzung meist mobiler Geräte ohne das Vorhandensein einer festen
Infrastruktur. Die Konzepte und Unterschiede der beiden Standards werden im folgenden Kapitel näher erläutert. Im Anschluss wird mit OSGi ein
generisches Service-Framework Open Service Gateway Initiative (OSGi)11
vorgestellt, das die beiden konkurrierenden Netzwerk-Technologien in einem
gemeinsamen Standard zu vereinen versucht.
2.2.1
JINI
Allgemeines
Jini wurde 1999 als verteilte Netzwerktechnologie schon viele Jahre vor
UPnP ins Leben gerufen. Die Architektur wurde von Sun entworfen und verwendet gängige Java-Technologien [35]. Jini kann auf einem beliebigen Netzwerkprotokoll aufsetzen, ist aber an eine vorhandene Laufzeitumgebung, die
Java Virtual Machine (JVM), und dadurch an die Konzepte der Programmiersprache Java gebunden. Dies ist ein entscheidender Nachteil im Vergleich
zur generischeren Auslegung des Konkurrenten UPnP (siehe Kapitel 2.2.2)
Auf Basis der Virtual Machine setzten Jini’s eigene Netzwerkprotokolle
und das Java Remote Methode Invocation-Modell (RMI) für den Aufruf von
entfernten Objekten im Netzwerk auf. Die Jini-Bibliothek umfasst die oberen
5
Eine Gegenüberstellung verschiedener Wireless-Technologien und deren Einsatzzwecke
findet sich unter http://bluetooth.com/Bluetooth/Learn/Technology/Compare/
6
WiMedia Alliance - http://www.wimedia.org
7
UWB Forum - http://www.uwbforum.org/
8
Jini - http://www.jini.org
9
UPnP - http://www.upnp.org/
10
Ein Überblick über bestehende Protokolle zur Diensterkennung finden sich in [25]
11
OSGi - http://osgi.org/
Java Spaces
9
Other Services
Lookup
Discovery & Join
Jini
RMI
Java Virtual Machine
Abbildung 2.2: Jini Architektur (siehe [24]).
Schichten: das Discovery-Managment, den darüber liegenden Lookup-Service
und die Applikationsschicht, die sich in Client-Anwendungen, den dazugehörigen Services und unabhängigen Netzwerkservices genannt JavaSpaces
gliedert (siehe Abb. 2.2).
Kommunikationsmodell
Das Jini-Kommunikationsmodell wird von drei Komponenten getragen. Ein
Service Provider, im Java Jargon auch als Djinn bezeichnet, stellt einem
Netzwerk seine Dienste zur Verfügung. Dazu wird für jeden Dienst ein
Dienstobjekt und eine Liste von Attributen mit Serviceinformationen in einer speziell dafür vorgesehenen Java-Klasse erstellt. Dienstobjekte stellen
für den Service Provider ein Interface zur Verfügung, mit der er seine Fähigkeiten präsentieren kann. Der Service Provider sendet diese Information
an einen Lookup Service und wird dort registriert. Jeder Lookup Service ist
ebenfalls ein Dienst und die Anlaufstelle für Jini-Clients die nach Services
Ausschau halten. Will ein Client einen Service in Anspruch nehmen, so erhält er aus dem Index des Lookup Services die benötigte Information, um
den Dienst am Service Provider eigenständig aufrufen zu können.
Die Kommunikation zwischen den Teilkomponenten (Abb. 2.3) wird in
die Phasen Discovery, Join, Lookup und Service Call eingeteilt:
Discovery: Eine Netzwerkkomponente oder ein Service nutzen das Multicast Request Protocol um beim Start nach Jini Netzwerken und speziell
Lookup Services suchen und durchsuchen zu können.
Das Multicast Announcement Protocol findet beim Start eines neuen
Lookup Services Verwendung, damit dieser potentiellen Clients seine Verfügbarkeit mitteilen kann. Auch beim Ausfall und neuerlichen Eintreten eines
Lookup Services in das Jini-Netzwerk kommt dieses Protokoll zum Einsatz.
Das Unicast Discovery Protocol wird von Netzwerkteilnehmern verwen-
10
Lo
o
in
Jo
Se
rv
ice
nd
ya
er
ov
sc
Client
Di
Re
fe
re
nc
e
ku
p
Lookup Service
Service Call
Service Provider
Abbildung 2.3: Das Jini-Kommunikationsmodell (vereinfachte Darstellung
aus [24]).
det, um gezielt mit einem Lookup Service kommunizieren zu können. Als
Vorraussetzung für eine erfolgreichen Discovery-Prozess gilt die Netzwerkunterstützung von Multicast und Broadcast-Nachrichten.
Join: Diese Phase beschreibt die Prozedur der Service-Registrierung bei
verschiedenen Lookup Services. Der Service Provider meldet ein Dienstobjekt und die Attributliste an und gibt bekannt, über welche Zeitdauer der
Dienst dem Netzwerk zur Verfügung steht. Um die Netzlast zu reduzieren
können mehrere Lookup Services auch in logische Gruppen zusammengefasst
werden, die der Service Provider einheitlich mit einer Mulitcast Discovery
Nachricht ansprechen kann. Jeder Dienst weiß welcher Gruppe er zugeordnet
ist.
Lookup: Mit Lookup bezeichnet man den Vorgang den ein Client anstößt,
wenn er auf der Suche nach einem Dienst ist. Wird er bei einem Lookup Service fündig, so erhält er eine Kopie des Dienstobjektes. Für die Kommunikation wird eine RMI-Verbindung hergestellt, die das dynamisch Laden von
Programmteilen und das Ausführen von nicht-lokalen Prozessen auf einer
anderen Virtual Machine erlaubt.
Service Call: Mit dem Erhalt des Dienstobjektes bekommt der Client die
Möglichkeit, direkt mit dem Service Provider zu kommunizieren und den
Service in Anspruch zu nehmen.
Weitere Konzepte
Eventing: Ähnlich dem UPnP-Modell können sich Objekte als Service
Listener bei einem Dienst eintragen und werden beim Eintreten eines Ereignisses über die Zustandsänderung informiert.
11
Leasing: In Jini wird die temporäre Nutzung der Ressourcen eines Services als Leasing bezeichnet. Ein Client kann nach Absprache mit dem Service Provider einen Zeitrahmen definieren, in dem er den Dienst in Anspruch
nehmen darf. Wird bis zum Ablaufs des Abonnements keine Erneuerung der
Vereinbarung beantragt, so gibt der Provider die Ressourcen wieder frei.
2.2.2
UPnP
Allgemein
Universal Plug and Play ist eine offene, verteilte Netzwerkarchitektur, die automatischen Verbindungsaufbau, Steuerung und Datenaustausch zwischen
Geräten im Heim- und Office-Bereich auf Basis von TCP/IP und Internettechnologien ermöglicht. Die Entwicklung des Gerätesteuerungssystems wird
von namhaften Firmen unterstützt und versucht die Charakteristika des Plug
and Play-Paradigmas auf bestehenden Netzwerkstandards umzusetzen und
mit verteilter und unabhängiger Applikationslogik zu verbinden. Ein beliebiges Gerät kann somit dynamisch einem Netzwerk hinzugefügt werden, seine
Dienste offerieren und über die Verfügbarkeit und Serviceleistungen anderer
Geräte lernen. Die Merkmale von UPnP umfassen:
• Automatische Geräte- und Serviceerkennung, Konfiguration und Integration (zero configuration).
• Abstraktion der Netzwerktopologie zugunsten einer einfachen Bedienung ( invisible“ networking).
”
• Plattform-, protokoll- und geräteunabhängige Kommunikation und Datenaustausch.
Bedingt durch die Flexibilität der Architektur ist auch eine Anpassung
von Technologien und Mediengeräten mit nicht IP-konformen Protokollen möglich. Der Implementierungsaufwand für herstellerspezifische
Gerätetreiber ist damit ebenfalls überflüssig, da standardisierte Protokolle verwendet werden und dem Entwickler im Gegensatz zu Jini
die freie Wahl der Programmiersprache und des Betriebssystems garantieren.
Das UPnP Forum ist ein Konsortium das sich mit dem Design der Weiterentwicklung der UPnP-Kommunikation zwischen den Produkten verschiedener Hersteller beschäftigt. Praktisch alle namhaften Firmen in der ITBranche sind in diesem Forum vertreten12 .
Komponenten
Die UPnP-Architektur definiert zwei Komponententypen - das Gerät (Device) und die Steuerinstanz (Control Point).
12
UPnP Implementers Corporation - http://www.upnp-ic.org/
12
Gerät: Ein UPnP-Gerät beinhaltet Dienste (Services) und kann in einer
rekursiven Anordnung wieder Subgeräte (Embedded Devices) mit Diensten
enthalten. Ein mögliche Anwendung wäre eine multifunktionale Stereoanlage, die sich aus verschiedenen Teilgeräten wie CD-Player, Mini-Disk, Kassettendeck, Radio und Uhr zusammensetzt. Diese bieten dem Benutzer abstrakte Services an (Multimedia-Steuerung, Zeitanzeige, Wecker). Diese Services enthalten wiederum Zustandsvariablen (state variables) und Aktionen
(actions), die auf dem Gerät ausgeführt werden können (Ein- und Ausschalten, Starten und Stoppen eines Mediengerätes, Setzen und Auslesen der
Zeit).
Die funktionale Beschreibung dieser Eigenschaften ist in einer XMLDokumentenhierarchie im Gerät festgehalten, und wird im Netzwerk bekanntgegeben. Ausgehend von einem zentralen Dokument mit allgemeinen
Geräteeigenschaften sind über relative Verweise weitere Service-Dokumente
referenziert. Der untenstehende Code zeigt Teile der XML-Beschreibung eines Licht-Dienstes. Auffallend ist dabei die Kombination aus Zustandsvariable und zugehöriger Getter und Setter -Zugriffsaktion zum Setzen und
Auslesen des Variablenwertes, wie sie in UPnP sehr häufig zu finden ist.
Jeder Ein- und Ausgabeparameter einer Aktion ist an eine definierte Zustandsvariable gebunden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
< actionList >
< action >
< name > SetPower </ name >
< argumentList >
< argument >
< name > Power </ name >
< r e l a t e d S t a t e V a r i a bl e> Power </ r e l a t e d S t a t e V a r i a b l e>
< direction > in </ direction >
</ argument >
</ argumentList >
</ action >
< action >
< name > GetPower </ name >
< argumentList >
< argument >
< r e l a t e d S t a t e V a r i a bl e> Power </ r e l a t e d S t a t e V a r i a b l e>
< direction > out </ direction >
</ argument >
</ argumentList >
</ action >
</ actionList >
< serviceStat eT a bl e >
< stateVariable sendEvents = " yes " >
< dataType > boolean </ dataType >
</ stateVariable >
</ serviceStat eT a bl e >
13
UPnP Vendor
UPnP Forum
UPnP Device Architecture
GENA
SOAP
SSDP
HTTPMU
HTTPU
GENA
HTTP
UDP
TCP
IP
Abbildung 2.4: Aufbau der UPnP Architektur (siehe [22]).
Control Point: Der Control Point erlaubt die Entdeckung und Steuerung
der Geräte. Er liest die Gerätebeschreibungen aus, um Informationen über
die Dienste zu erhalten, kann Statusabfragen tätigen, Statusänderungen vornehmen und Aktionen aufrufen um Dienste in Anspruch zu nehmen.
Aufbau der UPnP-Stack Architektur
Aufbauend auf der IP-Adressierung in der Vermittlungsschicht des OSI/ISOReferenzmodells [36] setzt sich der UPnP-Stack aus folgenden, in Abb. 2.4
ersichtlichen, Protokollen und Technologien zusammen. Als Transportprotokoll für die Kommunikation kommt wahlweise TCP oder das ungesicherte
UDP zum Einsatz. Darauf aufbauend werden Protokolle für die speziellen
Anforderungen von UPnP bereitgestellt.
Auf der UDP Seite sind dies HTTP Multicast over UDP (HTTPMU),
HTTP Unicast over UDP (HTTPU) und die darin gekapselten Protokolle
Generic Event Notification Architecture (GENA) und Simple Service Discovery Protocol (SSDP), die für die Geräteerkennung zuständig sind. Das
bekanntere Protokoll HTTP wird auf der Basis von TCP für die Präsentation und Beschreibung benötigt. Simple Object Access Protocol (SOAP)
kümmert sich um den Steuervorgang und HTTP und GENA zusammen sind
für die Benachrichtigungen (eventing) im UPnP-Kommunikationsmodell zuständig.
UPnP Networking
Im Folgenden werden die einzelnen Phasen des in Abb. 2.5 dargestellten
UPnP-Kommunikationsmodells beschrieben. Eine ausführliche Beschreibung
von UPnP findet sich unter [38].
Addressing: Eine Voraussetzung für die automatische Geräteerkennung
ist die Adressierung der Geräte. Diese erfordert das Vorhandensein eines
14
Addressing
Discovery
Description
Control
Eventing
Presentation
Abbildung 2.5: Die einzelnen Phasen des UPnP Networking Modells (in
Anlehnung an [38]).
DHCP-Clients am Gerät. Der Client sucht beim Anschluss an das Netzwerk nach einem DHCP Server und bekommt nach der Anmeldung eine IP
Adresse zugewiesen. Ist keine Unterstützung von DHCP gegeben, so muss
das Device AutoIP verwenden.
Discovery: Nachdem das Device erreichbar ist, beginnt es eigenständig
seine Dienstleistungen, die eingebetteten Geräte und deren Services im Netzwerk mit Multicast discovery messages anzubieten. Control Points hingegen
suchen aktiv nach Geräten. Auch beim Verlassen des Netzwerkes muss eine
Multicast-Mitteilung generiert werden, um alle Netzwerkteilnehmer zu informieren.
Description: Nach der Identifizierung eines Gerätes hat ein Control Point
nur wenig Information über dessen Beschreibung. Er kennt die URL, die
zu einer detaillierten Gerätebeschreibung führt. Darin sind gemäß einem
definierten XML-Schema folgende Informationen enthalten:
• Herstellerspezifische Angaben wie Modellname, Modellnummer, Seriennummer, Herstellername und URLs zu Webseiten.
• Information über die eigenen Services und die der eingebetteten Geräte.
• URLs für die zeitgleichen Betriebsphasen der Steuerung, des Eventmanagements und der Präsentation (control, eventing, presentation).
• Beschreibung der Aktionen und Zustandsvariablen, die mit einem Service in Verbindung stehen.
Control: Mit dem Abschluss der Description ist das UPnP-Netzwerk betriebsbereit. Ein Control Point kann nun ihm bekannte Serviceleistungen in
Anspruch nehmen und Zustände an den Geräten abfragen. In Form von
15
XML-SOAP Nachrichten werden Aktionsaufrufe an die Geräte-URL geschickt. Das Gerät arbeitet diese Befehle ab und reagiert mit Zustandsänderungen.
Eventing: Wenn sich ein Control Point als Listener bei einem Gerät registriert, so wird er durch ausgelöste Events über Änderungen von Statusvariablen informiert. Für die Anmeldung an einem Service sendet er eine Subscription Message an das Gerät. Wenn das Abonnement angenommen wird,
definiert der Service die zeitliche Begrenzung und sendet diese Information
an die Steuerinstanz zurück. Um eine Weiterführung des Abonnements durch
eine erneute Benachrichtigung oder die Kündigung vor der abgelaufenen Zeit
muss sich der Control Point selbst kümmern. Event-Nachrichten werden im
XML-Format GENA erstellt. Um Szenarien mit mehreren Control Points
realisieren zu können, werden alle Abonnenten über alle Eventvariablen und
deren Änderungen informiert. Dabei ist nicht relevant ob die Zustandsänderung aufgrund eines externen Aktionsaufrufes oder innerhalb des Gerätes
zu Stande kommt.
Presentation: Bei vielen Geräten ist eine Präsentations-URL enthalten,
die in einem Control Point oder einem Webbrowser darstellen werden kann.
Die HTML-Seite kann vom Hersteller frei gestaltet werden und kann auch als
einfaches Userinterface dienen, das dem Benutzer die Steuerung des Gerätes
und der Dienste erlaubt.
Fazit
UPnP wird aufgrund der Unterstützung vieler Software- und Unterhaltungselektronikkonzerne mit großer Wahrscheinlichkeit zu einer Schlüsseltechnologie im Bereich der verteilten Heimnetzwerke heranwachsen. Es fehlt jedoch
noch an konkreten Szenarien, die dem Endkunden die Vorteile verdeutlichen.
2.2.3
OSGi
Die Spezifikation zu OSGi (Open Service Gateway Initiative) wird von der
OSGi Alliance 13 , einem Zusammenschluss bedeutender Hard- und Softwarehersteller, darunter Sun Microsystems, IBM und Ericsson, getragen. Das
OSGi-Framework definiert eine offene Service-Plattform für vernetzte Dienste, die sowohl für industrielle Anwendungen als auch für den Einsatz beim
Endkunden und in mobilen Umgebungen geeignet ist. Das Framework setzt
auf einer Java Virtual Machine-Umgebung auf und wird folgenden Anforderungen gerecht (vgl. [37]):
13
OSGi und OSGi Alliance - http://www.osgi.org/
16
Komponentenbasierte Architektur: Aufbauend auf einem Framework
für die Java-Plattform können modulare Softwareanwendungen (Bundles)
installiert werden, die spezialisierte Services zur Verfügung stellen.
Integration bestehender Protokollstandards: Der generische Ansatz
der OSGi Service-Definition erlaubt die Integration und Kommunikation mit
bestehenden Standards verteilter Geräte und Dienste. Auch für UPnP, Jini
und Webservices sind Schnittstellen vorhanden.
Dynamisches Management: OSGi-Bundles können zur Laufzeit administriert werden. Die Funktionalität für die Installation, das Starten und das
Stoppen von Bundles zur Laufzeit ist integraler Bestandteil des Systems.
Integriertes Sicherheitsmodell: Die Softwarearchitektur von OSGi ermöglicht eine strikte Trennung von Kompetenzen. Im Bundle-Kontext unterscheidet man zwischen privaten Ressourcen und solchen, die über eine
offene Schnittstelle zur Verfügung gestellt werden und auch von anderen
Bundles benutzt werden dürfen.
Kapitel 3
Geräte
3.1
Szenario
Um die Tauglichkeit von UPnP als Service-Plattform unter Beweis stellen zu
können, müssen vorher Anforderungen für prototypische Implementierungen
definiert werden. Es soll geklärt werden, inwiefern die Technologie in einem
Mediensteuerungsszenario genutzt werden kann. Mit Blick auf die vielfältige Unterhaltungselektronik eines Haushaltes ist schnell ein reichhaltiges
Einsatzgebiet gefunden.
So möchte man beispielsweise auch während der Küchenarbeit nicht
auf den Musikgenuss verzichten müssen. Zusätzlich zur Stereoanlage im
Wohnzimmer ist das Aufstellen eines weiteren Elektronikgerätes, nur für
das Musikhören, jedoch alles andere als platzsparend und ökonomisch. Hinzu
kommt, dass die jahrelang gepflegte Mp3-Sammlung am PC im Arbeitszimmer ohnehin dem Radio vorgezogen wird. Obwohl die Inhalte über das Netzwerk auf einen PC mit Bildschirm in die Küche übertragen werden könnten,
ist die Bedienung mehr als mühsam. Das Hantieren mit einer Maus passt in
keiner Weise zu den Tätigkeiten in der Küche. Ein in die Wand integriertes
Touchpanel würde hier Abhilfe schaffen, die Nutzung scheitert jedoch an der
Software des Medienplayers, dessen GUI mit den kleinen Bedienelementen
nicht für ein solches Szenario ausgelegt ist.
Zudem möchte man auch die Inhalte anderer, im Haus verteilter Geräte
und Anwendungen in einem gemeinsamen Display darstellen und fernsteuern
können, ohne sich über deren Standorte Gedanken machen zu müssen.
Ebenso wie in diesem Fall finden sich in einem Haushalt viele Beispiele,
in denen ein nahtloses Zusammenspiel zwischen Elektronikgeräten Sinn machen würde. Die Stereoanlage, der Fernseher, der DVD-Player und auch das
Raumlicht könnten unter einem gemeinsamen Standard und den entsprechenden technischen Vorrausetzungen alle von einem mobilen Smart Phone
aus gesteuert werden. Darüber hinaus eröffnen mit Sensoren ausgestattete
Embedded-Geräte und Bewegungsdetektoren neue Möglichkeiten, um Ab-
17
KAPITEL 3. GERÄTE
18
läufe zu automatisieren. Steht eine Person am Morgen auf, könnte dies von
Drucksensoren am Boden registriert werden und eine Gebäudesteuerung informieren, die das Licht in allen vordefinierten Räumen einschaltet. Verlässt
der Bewohner das Haus und geht zur Arbeit, wird eine Überwachungskamera
mit Bewegungsdetektor aktiviert, die, sobald eine Bewegung registriert wird,
eine E-Mail mit einem Standbild der Kamera an den Benutzer schickt.
3.2
Konzept
Alle diese Szenarien zeigen, dass Mediengeräte durch die Unterstützung verteilter Netzwerke nicht mehr nur als eigenständige Dienste betrachtet werden können, sondern gerade durch ihre vielfältigen Vernetzungsmöglichkeiten eine neue Servicequalität bieten. Die drahtlosen und netzwerkfähigen
Geräte hierfür sind mit PCs, PDAs, Touchpanels und Mobiltelefonen vorhanden. Auch Unterhaltungselektronik wird vermehrt mit Netzwerkfunktionalität ausgestattet. Mit einer gemeinsamen Service-Plattform für die
Dienste wird eine Trennung zwischen dem Standort eines Gerätes und dessen grafischer Repräsentation zur Fernsteuerung möglich. Die Inhalte der
verschiedenen Anwendungen könnten dann über ein gemeinsames, an das
Darstellungsgerät angepasstes, User Interface gesteuert werden. Aus diesen
Ideen ergeben sich mehrere Komponenten, die zum Aufbau solcher Szenarien
benötigt werden:
• Geräte: Für das oben erwähnte Szenario müssen UPnP-fähige Hardund Softwaregeräte gefunden oder selbst entwickelt werden.
• GUI-Builder: Genauso wie mit UPnP ein gemeinsames Steuerprotokoll für verteilte Geräte vorhanden ist, muss ein Weg zur automatisierten Generierung von User Interfaces zur Fernsteuerung der Netzwerkgeräte gefunden werden. Der Ansatz sollte sowohl auf mobilen
Endgeräten als auch auf PC-Systemen angewendet werden können.
• Framework zur Kopplung verteilter Geräte: Auf Basis von UPnP
als Service-Plattform muss ein System zur Verknüpfung von verteilten Gerätediensten geschaffen werden. Damit kann ein UPnP-fähiges
Sensorgerät etwa Drucksensorwerte zur Steuerung der Bedienelemente
eines Medienplayers liefern. Möglich wird dies durch die dezentrale
Architektur des Torem Frameworks [39], einer UPnP-Controlpoint Instanz, die Geräte im Netzwerk finden und ansteuern kann. Torem
erlaubt es dem Benutzer mit einem grafischen Editor ereignisorientierte Zustandsvariablen und Ein- und Ausgabeparameter von UPnPAktionen miteinander zu verknüpfen, um Szenarioabläufe zu definieren
(siehe Abb. 3.1).
KAPITEL 3. GERÄTE
19
Abbildung 3.1: Torem - Ein Framework zur Kopplung verteilter UPnPGeräte. Der Benutzer kann aus allen vorhandenen Geräte und zusätzlichen
Kontrollflusskomponenten, wie If -Bedingungen und Schleifen eine Ereigniskette definieren [39].
3.3
UPnP-Technologie
Als Grundlage für die Entwicklung der Geräte und GUI-Builder Steueranwendung wird eine Bibliothek benötigt, die die Besonderheiten der UPnPTechnologie abstrahiert und die Implementierung von Geräten und Controlpoint-Instanzen ermöglicht. Die Cyberlink UPnP Bibliotheken1 des japanischen Programmierers Satoshi Konno ist in den Programmiersprachen
C/C++ und Java verfügbar. Zusätzliche Beispielanwendungen und ein rudimentärer Controlpoint zum Steuern der Gerätedienste sind ebenfalls vorhanden. Die Java-Variante dieser Bibliothek wurde für die Entwicklung ausgewählt, da sie schon mehreren Revisionen unterzogen wurde und eine übersichtliche und gut abstrahierte Klassenstruktur bietet.
3.4
Implementierung
Für das Szenario werden Eingabegeräte und verteilte Anwendungen benötigt. UPnP spezifiziert trotz der breiten Herstellerunterstützung zum ge1
Cyberlink UPnP Bibliotheken http://www.cybergarage.org/net/
KAPITEL 3. GERÄTE
20
gebenen Zeitpunkt wenige Geräte-Standards2 , die für die Mediensteuerung
von Interesse sind. Neben Standards für Scanner, Drucker, Modems und
Router passen eine Überwachungskamera und eine AV MediaServer/MediaRenderer-Architektur [12] besser in das Konzept. Mit dem Philips SL300i3
stand ein WLAN-Client zur Verfügung, der Audio- und Videoformate vom
PC auf den Fernseher streamen kann. Das Produkt implementiert jedoch nur
die wichtigsten der spezifizierten Funktionen und ist damit nur eingeschränkt
bedienbar. Mit Hilfe softwarebasierter Adapter konnte weitere Hardware
UPnP-fähig gemacht werden. Dazu zählen ein mit acht Drucksensoren ausgestatteter Mikrocontroller mit LAN-Anschluss und ein Streaming-Server,
der das Video einer Webcam zu einem Client übertragen kann und dort Bewegungsdetektion ermöglicht. Auch der MIDI-Protokollstandard4 und der
Winamp Media Player konnten mit UPnP-Funktionalität gekapselt werden.
3.4.1
Sensor-Hardwaredevice
Anforderungen
Um ein alternatives Eingabegerät für das Steuerungsszenario zu erhalten,
wurde nach einer Möglichkeit zur Integration von Sensoren gesucht. Dazu
wird ein hardwarenahes System benötigt, das den Anschluss von Sensorik an
einen Analog-Digital Wandler erlaubt und die gemessenen Spannungswerte
der Sensoren ins UPnP-Netzwerk exportieren kann. Um die Anbindung an
das Netzwerk zu ermöglichen, sollte eine schlanke C/C++-Bibliothek gefunden werden, die einen UPnP-Stack für performanceschwache Systeme implementiert. In netzwerktechnischer Hinsicht muss das Gerät einen TCP/IP
Stack integrieren und den Zugriff über ein LAN-Modul mit RJ45-Anschluss
oder eine WLAN-Schnittstelle erlauben. Im besten Falle sollte das Gerät
auch geringen Stromverbrauch garantieren oder mit Batterie betrieben werden.
Hinsichtlich frei verfügbarer Software wurden folgende UPnP-Bibliotheken für die Entwicklung in Betracht gezogen:
• Intel Software for UPnP Technology: Intel’s UPnP-Implementierung5 ist eine Sammlung an Softwarepaketen für die Entwicklung
und das Testen UPnP-fähiger Anwendungen. Das Authoring ToolsPaket enthält einen automatisierten Device-Builder, der anhand funktionaler XML-Gerätebeschreibungen portablen Programmcode in C
2
UPnP Geräte-Standards - http://www.upnp.org/standardizeddcps/
Philips Streamium (UPnP AV MediaRenderer) - http://www.streamium.philips.com/
4
Musical Instrument Digital Interface (MIDI) ist ein Steuerprotokoll für digitale Musikinstrumente, wird aber auch für Mediensteuerungen und künstlerische Installationen
gerne eingesetzt. - http://www.midi.org/
5
Intel Software for UPnP Technology - http://www.intel.com/cd/ids/developer/
asmo-na/eng/downloads/upnp/
3
KAPITEL 3. GERÄTE
21
generiert. Jedoch ist dieser Code nur für Microsoft Windows, PocketPC und Linux ausgelegt.
• Linux UPnP-SDK: Ein UPnP-SDK für Linux6 wird als Open Source
Software zur Verfügung gestellt. Die Einarbeitungszeit in ein EmbeddedLinux System ist für den kleinen Teil des Szenarios allerdings nicht
gerechtfertigt.
• Cyberlink: Neben der Java-Variante wird von Cyberlink auch eine
C++und eine C-Bibliothek bereitgestellt. Aufgrund der umfassenden
Klassenstruktur und der mehrfachen Threads kann die C++-Implementierung nicht auf einem hardwarenahen System eingesetzt werden. Die
C-Bibliothek hingegen ist dezidiert für mehrere Embedded-Systeme
ausgelegt. Doch auch hier konnte für die unterstützten Betriebssysteme T-Engine 7 und uTRON 8 kein bekanntes Hardwareboard gefunden werden.
Auf der Suche nach entsprechender Hardware stellte sich heraus, dass
kein greifbares Gesamtsystem die Anforderungen hinreichend erfüllt und in
kurzer Zeit die Erstellung eines Prototyp ermöglicht:
• AVR Embedded Internet Toolkit: Mit dem Embedded Internet
Toolkit 9 konnte ein System gefunden werden, das ausdrücklich für Industral Control und Home Appliances ausgelegt ist und neben einen
TCP/IP-Stack auch aufbauende Protokolle, wie DHCP, HTTP und
FTP unterstützt. Jedoch sind die Anforderungen C++-basierter UPnPBibliotheken für einen Mikrocontroller mit 128Kb dynamischem FlashSpeicher und 1MB Festspeicher zu wenig, um Features wie XMLVerarbeitung, das Steuerprotokoll SOAP und die Multi- und BroadcastProtokolle für die automatische Geräteerkennung zu unterstützen. Eine
Portierung der Cyberlink C-Bibliothek auf die gängige ARM -Mikroprozessorarchitektur10 wäre mit einigem Zeitaufwand allerdings denkbar.
• Sindrion: Sindrion ist eine verteilte Systemarchitektur rund um einen
Chip mit niedrigem Energieverbrauch, der von der Firma Infineon11
mit dem Ziel eines kostengünstigen Sensornetzwerkes entwickelt wurde
[30]. Im Sindrion-Konzept wird explizit auch die Integration in die
6
Linux UPnP-SDK - http://upnp.sourceforge.net/
Embedded OS: T-Engine - http://www.t-engine.org/
8
Embedded OS: uTRON - http://www.utron.net/
9
AVR Embedded Internet Toolkit - http://www.atmel.com/dyn/resources/prod
documents/doc2493.pdf
10
Die ARM-Architektur ist ein Designspezifikation für eine Reihe an 32-bit Mikroprozessoren, die dem RISC-Konzept folgen. - http://www.arm.com/
11
Infineon - http://www.infineon.com/de/
7
KAPITEL 3. GERÄTE
22
UPnP-Serviceplattform erwähnt. Demnach ist ein Sindrion WirelessTransceiver eine Gerät, das einen reduzierten UPnP-Stack implementiert und Kontakt zu einer Terminal-Software hält, die den fehlenden
Teil der Netzwerkkommunikation übernimmt und so in Kombination
ein vollwertiges UPnP-Gerät repräsentiert [21]. Der Ansatz von Sindrion erscheint vielversprechend. Allerdings befindet sich die Technologie noch in der Entwicklungsphase.
• Sun SPOT: Das Forschungsprojekt Sun SPOT 12 der Sun Microsystems Laboratories13 ist ein Batterie betriebenes Hardwaregerät zum
Anschluss von Sensoren. Das ARM-basierte Mikroprozessorboard ist
mit Solarzellen und mit einem drahtlosen Funksender nach dem Standard IEEE 802.15.414 ausgestattet und kann als Informationsquelle in
intelligenten Netzwerken eingesetzt werden. Die Besonderheit des Konzeptes liegt in der Kombination aus robuster Hardware und Sun’s hauseigener, objektorientierter Programmiersprache Java, die mit CLDC
1.1 den Standard einer vollwertigen, mobilen Virtual Machine implementiert. Als Termin für die Produktreife von Sun SPOT wird aber
erst der Sommer 2006 angegeben.
Systemaufbau
Schließlich wurde ein prototypisches Hardwaredevice der Firma Ubitronix 15
eingesetzt. Das Gerät basiert auf einem Texas Instrument MSP430 -Mikrocontroller16 , der einen 8-Port Analog-Digital Wandler integriert. Zusätzlich
ist ein mit dem Lantronix XPort 17 ein Ethernet-Modul angebracht, das die
Netzwerkkommunikation ermöglicht. Am Gerät wurden acht Drucksensoren
angebracht und so konfiguriert, dass der Wandler je nach Druckstärke einen
skalierten Wert zwischen 0 und 4000 zurück liefert. Mit einem proprietären,
TCP/IP-basierten Kommunikationsprotokoll kann das Gerät im Netzwerk
angesprochen werden. Es definiert eine Folge an Befehlen im Byte-Format
um die acht Sensorwerte auslesen zu können.
Ein Zyklus einer Sensorabfrage (Abb. 3.2) sieht vor, dass zuerst ein request-Befehl an das Gerät gesendet wird. Das Hardwaredevice bestätigt
diese Anfrage (acknowledge) und teilt dem PC mit, dass es Daten senden
will (send). Ist der PC damit einverstanden (ack), sendet das Gerät die ermittelten acht Sensorwerte mit je 2 Byte Länge zurück (sensordata). Trotz
12
SUN Spot - http://www.sunspotworld.com/
Sun Microsystems Laboratories - http://research.sun.com/
14
IEEE 802.15 WPAN Task Group 4 ist ein Arbeitsgruppe zur Spezifizierung von
Kurzstrecken-Funktechnik in Wireless Personal Area Networks - http://www.ieee802.org/
15/pub/TG4.html
15
Ubitronix - http://www.ubitronix.com/
16
Texas Instrument MSP430 Mikrocontroller - http://www.ti.com/msp430
17
Lantronix XPort http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
13
KAPITEL 3. GERÄTE
23
request
ack
PC
send
ack
Hardware
Device
sensordata
ack
Abbildung 3.2: Die Abbildung zeigt die Befehlskette einer Sensorabfrage
zwischen dem PC und dem Hardware-Modul.
des aufwendigen Protokolls, das nicht nur für die Sensorabfrage entworfen
wurden, zeigte sich der Prototyp als robustes Eingabegerät, das auch nach
tagelangem Einsatz noch einwandfrei funktioniert.
Für die Integration ins UPnP-Netzwerk wurde eine Adapteranwendung
am PC implementiert, die eine persistente Verbindung zum Hardwaredevice hält und auf eine GetSensor-Aktionsanfrage eines UPnP-Controlpoints
die acht Sensorwerte ermittelt und in Form eines XML-formatierten Strings
zurück liefert.
Mit dieser Implementierung wurde die UPnP-Welt des Szenarios um ein
physisches Eingabegerät bereichert. Welche Funktionen die Sensoren erfüllen, ist Teil des Mappings zwischen zwei UPnP-Diensten, wie sie im ToremFramework definiert werden kann. So kann unter anderem folgendes Verhalten festgelegt werden: Wenn der Wert des Sensors1 kleiner 2000 ist, dann
soll der Play-Befehl eines Medienplayers ausgeführt werden. Ein erweitertes Szenario könnte auch eine Passwortabfrage anhand einer bestimmten
Abfolge an gedrückten Sensoren realisieren. Mit dem Hardwaredevice ist die
Integration vieler, weiterer Sensortypen, wie Temperatur-Sensoren, DistanzSensoren, Magnetfeld-Sensoren, etc. denkbar, da sie am gleichen Gerät angebracht werden können und die Bedeutung eines Sensors erst durch dessen
semantische Verknüpfung definiert wird.
3.4.2
Webcam Streaming-Server und Client
Für die Entwicklung eines weiteren Eingabegerätes wurde eine Streaming
Server/Client-Architektur entworfen, die das Video einer serverseitig angeschlossenen Webcam im Netzwerk bereitstellt. Die Idee ist, einen UPnPbasierten Server zu schaffen, dessen Konfiguration im Netzwerk vorgenommen werden kann. Neben der Möglichkeit zum Auslesen und Setzen der
URL des Videostreams kann der Servers vom Netzwerk aus gestartet und
gestoppt werden. Ein ebenfalls UPnP-fähiger Client besitzt dieselben Möglichkeiten, allerdings zum Empfang des Videosteams. Der Streaming Client
KAPITEL 3. GERÄTE
24
ermittelt über UPnP automatisch das Vorhandensein eines Servers, liest
dessen Videostream-URL aus und nutzt sie, um sich selbst zu konfigurieren
und zu starten. Zusätzlich ist am Client eine simple Bewegungserkennung
(motion detection) implementiert, die auf Änderungen des Videobildes reagiert und diese Information über zwei Wege auch einem UPnP-Controlpoint
zugänglich macht. Zum einen ist eine ereignisorientierte boolsche Variable
MotionDetected definiert, die Rückmeldung über den aktuellen Status des
Videobildes. Als zweite Maßnahme wird zum Zeitpunkt der Bewegung das
Bild des aktuellen Videoframes abgespeichert und über einen Webserver zugänglich gemacht, dessen URL wiederum mit der UPnP-Aktion GetLastMotionImage bekanntgegeben wird.
Systemaufbau
Für die Implementierung der Streaming-Architektur wurde das Java Media Framework 18 (JMF, Version 2.1.1e), eine Java-basierte Bibliothek für
die Medienverarbeitung, herangezogen. JMF ermöglicht den Zugriff auf die
Daten, der am PC angeschlossenen Audio- und Videohardware und abgespeicherter Medienformate. Durch die Entwicklung von Plugins können Änderungen in den Datenströmen der Verarbeitungskette vorgenommen werden, die sich aus einer Datenquelle, einem Prozessor und einer Datensenke
zusammensetzen. Sowohl Datenquelle als auch Datensenke sind abstrakte
Bezeichnungen für Ein- und Ausgabeinstanzen. Dazu zählen neben Geräten wie Videokamera und Bildschirm ebenso ein Netzwerkstream oder eine
Mediendatei.
Der Streaming Server und der Client verwenden eine annähernd identische Klassenstruktur, die in drei Bereiche unterteilt ist:
• net.digidop.upnp.device.rtpapp: Dieses Packet definiert das Zustandsmodell der Applikation, die Anbindung an das Netzwerk als
UPnP-Gerät. Für den Client ist zusätzlich auch eine UPnP-Controlpoint integriert, der zur Auffindung des Servers benötigt wird.
• net.digidop.upnp.device.rtpserver.business: Diese Schicht definiert Business-Objekte zum Aufbau der JMF-Verarbeitungskette, der
Instanzierung des medienverarbeitenden Prozessors und der Generierung einer grafischen Komponente für das Videovorschaubild.
• net.digidop.upnp.device.rtpserver.ui: Das Packet enthält Klassen für das GUI und die Konfigurationsoptionen, die auch über das
Netzwerk geändert werden können.
18
Java Media Framework API - http://java.sun.com/products/java-media/jmf/
KAPITEL 3. GERÄTE
25
Bevor eine Verarbeitung am Client erfolgt, muss der Processor konfiguriert werden. Anhand der vom Server ermittelten Multicast 19 -URL des
Videostreams wird ein MediaLocator angelegt, der zusammen mit einem
globalen Manager eine Instanz des Processors erzeugt. Im Anschluss kann
eine Liste an beliebigen Plugins in die Verarbeitungskette eingegliedert und
die Datensenke an eine GUI-Applikation angebunden werden. Der einfache
Motiondetection-Algorithmus FxMotionDetection reagiert auf die durchschnittliche Intensitätsänderungen eines Bildes. Hat sich der ermittelte Wert
im Vergleich zum vorgehenden Videoframe stark verändert, wird eine Bewegung registriert und die MotionDetected-Zustandsvariable auf TRUE gesetzt.
Sobald der Algorithmus im nächsten, zehnten Frame keine Bewegung mehr
registriert, wird der Wert wieder auf FALSE gesetzt.
1
2
3
4
/*
* Berechnung von d i v i d e d S u m o f D i f f e r e n c es als Durchschnitt sw e rt
* der Intensitäts än de r un g zweier Frames mit Abstand 10
*/
5
6
7
8
9
10
11
12
if (( frameCount % 10) == 0) {
if ( motionDetecte d ) {
motionDetecte d = false ;
} else {
clientDevice . trackingVar . setValue ( " FALSE " );
}
}
13
14
15
16
17
if ( d i v i d e d S u m o f D i f f e r e n ce s > treshold && ! motionDetecte d ) {
motionDetecte d = true ;
clientDevice . trackingVar . setValue ( " TRUE " );
}
Die Verarbeitung des RTP-Streams20 erfolgt mir 15 Bildern pro Sekunde.
Der Algorithmus für die Bewegungserkennung ist sehr einfach aufgebaut.
Die Flexibilität des Systems erlaubt es aber, dass mit wenig Aufwand ein
robusteres Verfahren, das etwa auch gegen Helligkeitsschwankungen resistent ist, implementiert werden kann. Auch die Nutzung von videobasiertem Tracking scheint in diesem Kontext denkbar. Mit dem Streaming Server
(siehe Abb. 3.3) und Client wurde eine kostengünstige Variante einer Überwachungskamera geschaffen, die ohne zusätzlichen Konfigurationsaufwand
betrieben werden kann.
19
Multicast bezeichnet in der Netzwerkkommunikation eine Nachrichtenübertragung
von einem Punkt zu einer Gruppe. In IPv4 ist hierfür der Adressbereich 224.0.0.0 bis
239.255.255.255 (Klasse D) reserviert
20
Das Real-Time Transport Protocol ist ein Protokoll zur kontinuierlichen Übertragung
von audiovisuellen Daten (Streams) über IP-basierte Netzwerke
KAPITEL 3. GERÄTE
26
Abbildung 3.3: Die Abbildung zeigt die UPnP-fähige Streaming Server
Applikation mit dem Videobild der Webcam. Im rechten Bild ist das Fenster
für die Webcam-Einstellungen zu sehen.
3.4.3
UPnP-Winamp Media Player
Um auch ein Gerät zum Abspielen von Musik anzusteuern zu können, wurde
der Winamp Media Player 21 in der Version 2.91 mit einem Softwareadapter an UPnP angebunden. Neben der Überlegung ein umfangreiches C++basiertes Plugin auf Basis der Winamp SDK22 und der Cyberlink UPnPBibliothek zu entwickeln, wurde mit httpQ 23 ein netzwerkbasiertes Plugin
gefunden, das die Funktionen von Winamp über den Zugriff via HTTPGET URL ermöglicht. Dafür wurde in Java ein Adapter entwickelt, der
diese Funktionen ins UPnP-Netzwerk exportiert und Steuerzugriffe in den
httpQ -Befehlssatz umsetzt. Neben der Steuerung der Abspielelemente kann
auch die Zeit, die Lautstärke und Auskunft über die geladene Playlist und
den aktuellen Song ermittelt und gesetzt werden. In der Klasse HttpQAdapter sind alle Befehle definiert und können mit processCmd ausgeführt
werden. Für das Starten des Players wird etwa folgender String aus dem
Play-Befehl und einem geforderten Passwort zusammengesetzt und ausgeführt: http://localhost:4800/play?p=pass.
3.4.4
MIDI-Device
Für die Übertragung von MIDI-Steuerbefehlen wurde mit Hilfe des LoopBe1
MIDI-Treibers24 , einer virtuellen MIDI-Kabelverbindung am PC, ein UPnPAdapter für das Windows Betriebsystem entwickelt. Damit können alle soft21
Winamp Media Player - http://httpq.sourceforge.net/
Winamp Plugin Development Center- http://www.winamp.com/nsdn/winamp/plugins/
23
httpQ Network Protocol - http://httpq.sourceforge.net/
24
LoopBe1 Virtual MIDI Driver - http://www.nerds.de/en/loopbe1.html
22
KAPITEL 3. GERÄTE
27
warebasierten Klangerzeuger wie Reaktor25 angesprochen werden. Der Adapter sendet mit Hilfe der Java-MIDI API javax.sound.midi Steuerbefehle
an die virtuelle Schnittstelle LoopBe1. Wird der Treiber in einem Klangerzeuger als MIDI-Eingabegerät ausgewählt, so leitet er die eintreffenden
Befehle direkt an dieses weiter. Über die installierten MIDI-Treiber der Soundkarte des PCs können auch externe Geräte angesprochen werden.
Das MIDI-Protokoll definiert eine Reihe an Steuernachrichten mit unterschiedlicher Parameteranzahl. Mit dem Befehlen NOTE_ON und NOTE_OFF
und dem Parameter der Tonhöhe kann beispielsweise ein Tastendruck auf
einem Klavier simuliert werden. Die Tondauer wird durch das Zeitintervall
zwischen den beiden NOTE-Befehlen festgelegt. Diese Funktionalität wird in
einem UPnP-Gerät gekapselt, das eine SetNote-Aktion implementiert. Als
Eingabeparameter verlangt sie einen MIDI-kompatiblen Tonhöhenparameter zwischen 0 − 127. Ist das virtuelle MIDI-Gerät an einen Klangerzeuger
gekoppelt, wird ein Tastendruck mit der Dauer von 100 ms simuliert. Dies
führt bei den Konfigurationen der meisten virtuellen Synthesizer zur Ausgabe eines Tons.
Obwohl mit diesem Ansatz bislang nur ein Teil des MIDI-Protokolls implementiert ist, demonstriert es die Integration eines breiten Spektrums an
zusätzlicher Hard- und Software, die mit diesem Protokoll arbeiten. Vor allem hinsichtlich neuer Eingabemedien scheint dieses Konzept interessant, da
zahlreiche MIDI-Controller mit integrierten Tasten, Drehknöpfen, Touchpanels und Schiebereglern für die Steuerung verteilter Geräte bereitstünden
und nicht nur im musikalischen Kontext verwendet werden könnten. Ein
Beispiel für solche Geräte sind alternative Controller-Produkte26 der deutschen Firma Döpfer27 .
25
Native Instruments Reaktor - http://www.native-instruments.com/index.php?id=
reaktor5 us
26
Eine Liste alternativer MIDI-Controller - http://www.stoffelshome.de/alt controller/
alt midi controller.html
27
Döpfer MIDI-Controller - http://www.doepfer.de/home d.htm
Kapitel 4
Generierung grafischer User
Interfaces
Eine große Herausforderungen in der Softwareentwicklung ist das Design
von Schnittstellen zwischen Mensch und Maschine. Erklärtes Ziel beim Entwurf eines Interfaces ist es, Daten und Funktionalitäten einer Applikation
in einer abstrahierten Form zu präsentieren und dem Benutzer einfache Interaktionsmöglichkeiten anzubieten. In diesem Zusammenhang befasst sich
der Human-Computer Interface (HCI) Forschungsbereich neben traditionellen grafischen Oberflächen (Graphical User Interface oder einfach GUI ) für
Endgeräte mit Display auch mit alternativen, physischen Eingabegeräten
unter dem Begriff Tangible Interfaces, die nicht Gegenstand der vorliegenden Arbeit sein sollen. Vielmehr soll erläutert werden, warum das Design
und die Implementierung von GUIs auch Jahrzehnte nach deren Aufkommen keine triviale Aufgabe darstellt [27].
Die Bringschuld des Softwareentwicklers besteht darin, User Interfaces
unter Berücksichtigung der Benutzererwartung, hinsichtlich der Bedienung
einer Software, zu gestalten. Abhängig von verschiedenen Faktoren wie dem
Alter des Benutzers und dem IT-Vorwissen kann dies zu den unterschiedlichsten Bedürfnissen führen. Ein Grafiker, dessen tägliches Arbeitswerkzeug
ein Bildbearbeitungsprogramm ist, sucht nach Wegen um wiederkehrende
Abläufe standardisieren zu können und schnellstmöglichen Zugriff auf alle
ihm zur Verfügung stehenden Funktionen zu haben. Ein Anfänger hingegen möchte aller Voraussicht nach schrittweise in das Programm eingeführt
werden und wenige für ihn wichtige Operationen ausführen können, ohne
sich in einer Ansammlung von Menüeinträgen und Mehrfachbelegungen von
Buttons zu verlieren.
Unterstützung im Entwicklungsprozess erfährt der Programmierer dabei
von Seiten psychologischer Studien hinsichtlich dem Nutzerverhalten und
der Gebrauchstauglichkeit der Software. Diese Art der Evaluierung durch
Beobachtung von Benutzern und ihren Gewohnheiten wird durch den Be28
KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 29
griff Usability geprägt. Zusätzliche Schwierigkeiten können sich durch die
Einbeziehung Kontext-sensitiver Informationen in die Anwendung ergeben.
Je mehr unvorhersehbare Anwendungsbereiche und Geräteumgebungen gegeben sind, desto vielschichtiger sind die Abhängigkeiten, die es in der Software und dem GUI-Design vorab zu bedenken gilt.
Dadurch werden eine Reihe wichtiger Fragen aufgeworfen. Im Mittelpunkt dieser Überlegungen steht die Suche nach überzeugenden Methoden
um konsistente und benutzerfreundliche Schnittstellen entwickeln zu können:
1. Welche allgemeingültigen Qualitätskriterien sind im GUI-Design definiert und wie können sie angewandt werden?
2. Welche Anforderungen werden bei der GUI-Entwicklung an den Entwickler herangetragen?
3. Welche gesonderten Anforderungen werden durch die Verbreitung mobiler Endgeräte, ubiquitärer Technologien und die Ad-hoc-Vernetzung
generiert?
4. Welche unterstützenden Konzepte und Werkzeuge kommen in der Praxis zum Einsatz?
4.1
Anforderungen im GUI-Design
In [27] werden allgemeine Aspekte aufgelistet, die es beim Design jedes grafischen Interfaces zu beachten gilt:
Standards und Richtlinien: Ebenso wie in anderen Disziplinen haben
sich auch im Interface-Design bewährte Konzepte durchgesetzt, die sich als
Richtlinien für heutige GUI-Applikationen etabliert haben. Dazu zählen Fenster, Menüleisten und Bestätigungs-Dialoge ebenso, wie Layout-spezifische
Konventionen. Das Schließen einer Applikationen oder das Öffnen einer Datei, werden als Hauptfunktionen in verschiedenen Applikationen an der gleichen Stelle zu finden sein. Dem Benutzer wird dadurch die Möglichkeit gegeben, sich an bereits erlernten Metaphern orientieren zu können. Das selbstverständliche Vorhandensein von Maus, Tastatur und einer grafischen Oberfläche bei PC-Systemen zeigt, dass sich aus den Ideen zu Eingabegeräten
schnell Standards entwickeln können.
Für die grafische Aufbereitung, die das Layout der Komponenten, den
Schriftsatz und die Farbwahl beinhaltet, werden von allen wichtigen Betriebssystemherstellern wie Microsoft1 und Apple2 Guidelines definiert. Neben einem konsistenten Look and Feel ist dies auch auf die Tatsache zurückzuführen, dass das moderne Betriebsystem grundlegende Zeichenoperationen
1
Microsoft User Interface Design and Development - http://msdn.microsoft.com/ui/
Apple Human Interface Guidelines - http://developer.apple.com/documentation/
UserExperience/Conceptual/OSXHIGuidelines/
2
mit Hilfe eigener Window Manager zur Verfügung stellt. Eine Vielzahl weiter
Publikationen beschäftigt sich mit Richtlinien für Interaktionsdesign [8, 34]
und auch für grafisches Design [4]. Aufgrund der Vielfalt und Komplexität
von Softwaresystem und dem unvorhersehbaren Nutzerverhalten lassen sich
diese Ansätze nicht in einer allgemeingültiger Theorie postulieren. Gutes
Design liegt demnach zu einem großen Teil noch immer in den Händen des
Designers.
Anpassungsfähigkeit und Hilfestellung: Trotz des Bestrebens robuste, einfach zu bedienende Software zu entwickeln, kann es zu Situationen
kommen, in denen eine Fehlerbehandlung unvermeidlich ist. Die Art wie der
Benutzer davon in Kenntnis gesetzt wird, ist ein Indikator für die Qualität
der Anwendung. Programmatische Fehlermeldungen stehen hier in starkem
Gegensatz zum Versuch, dem Benutzer die Handhabung der Software zu erklären oder im besten Fall die entstandene Problematik programmintern zu
lösen. Ein schwerwiegender Irrtum wäre es, in diesem Zusammenhang vom
Fehlverhalten des Benutzers zu sprechen, da das oberste Prinzip die Unterstützung des Benutzers in seiner Tätigkeit sein soll [8]. Die Internationalisierung von Anwendungen eröffnet besseren Zugang zu spezifischen Benutzergruppen und verlangt mehr als nur die Übersetzung von Textinhalten. Auch
externe Faktoren wie lokale Kultureinflüsse, soziale und rechtliche Gegebenheiten, spezielle Zahlenformate und Layoutbedingungen müssen ebenso wie
Anforderungen für Zielgruppen mit besonderen Bedürfnissen berücksichtigt
werden. Um eine gute Handhabung eines Interfaces zu erreichen, muss das
Navigationskonzept schlüssig und die Anordnung der Elemente konsistent
sein. Der Benutzer muss zudem jederzeit über den Zustand des Systems informiert sein, die Kontrolle haben und bei Interaktionen in kürzester Zeit
Feedback erhalten.
4.2
Anforderungen im Pervasive Computing
4.2.1
Kontext-sensitive und verteilte Anwendungen
Das Aufkommen mobiler Endgeräte und eingebetteter, smarter Technologien erweitert mit ebenso großer Tragweite den Horizont der computerisierten Wahrnehmungswelt, wie einst der Übergang zwischen dem Zeitalter
des zentralisierten Mainframe-Computing hin zur Ära des Desktop-PCs. Die
Erfassung Kontext-sensitiver Informationen durch Geräte, die mit Sensoren
ausgestattet sind, erlaubt heute schon eine engere Bindung der Anwendung
an die unmittelbare Umgebung (location-based services). Bis der Wunschtraum einer ubiquitären Welt nach Mark Weiser [40], in der der Benutzer
keinen unmittelbaren Kontakt mehr zu technischen Geräte hält, Wirklichkeit werden kann, müssen essentielle Fragen hinsichtlich Energieversorgung,
einheitliche Kommunikationsstandards und auch dem Design solcher intelligenter Gegenstände geklärt werden.
Durch die Mobilität wird das Paradigma der verteilten Anwendung und
spontaner Vernetzung gestärkt. Die physische Trennung von Applikationslogik und grafischer Repräsentation erlaubt es auch leistungsschwachen Geräten aufwendige Aufgaben zu erledigen. Diese können im Hintergrund von
Serverdiensten abgearbeitet werden und müssen lediglich für die Synchronisation der Information des GUI-Client sorgen.
4.2.2
Geräteeigenschaften
Die gestiegene Performance und Speicherkapazität bei mobilen Geräten erlaubt die Darstellung grafischer Inhalte auf Farbdisplays, die bis vor kurzem noch Desktop-Systemen vorbehalten waren. Mobile Betriebsysteme wie
Windows Mobile3 und Symbian4 und systemübergreifende Entwicklungsplattformen wie Microsoft .NET5 und die Java 2 Platform, Micro Edition
(J2ME)6 bieten mit grafischen Toolkits Unterstützung für einfache GUIProgrammierung.
Eine weitere Eigenschaft der neuen Geräteklassen sind spezialisierte Einund Ausgabehardware. Auf Seiten der Interaktionstechniken reicht die Palette von wandgroßen Displays über berührungsempfindlichen Touch Screens
und PDAs mit Bedienstift (stylus) bis hin zu Mobiltelefonen mit mehrfachbelegten Funktionstasten und Joystick oder Richtungstaste für die Navigation. Durch Wegfall von Maus und Tastatur muss die Navigation durch das
User Interface anders ausgelegt sein. Am Beispiel einer einfachen Texteingabe lässt sich der Paradigmenwechsel leicht erklären. Durch die Popularität des Short Message Services (SMS ) zeigt sich, dass es dem Konsumenten
selbst am Mobiltelefon ein Bedürfnis ist, Texte zu verfassen. Das neue Bedienungskonzept, das für wenigen Tasten mehrfache Buchstabenbelegungen
erfordert, wird trotz der offensichtlichen Nachteile in Kauf genommen. Am
PDA ist die selbe Funktionalität in mehrfacher Ausführung vorhanden: Der
Bedienstift kann dazu benutzt werden, um Zeichen, die auf einer im Display
sichtbaren Tastatur aufgereiht sind, anzuwählen. Eine neue Form der Interaktion bieten die Zeichenerkennung per Handschrift. Als weitere Möglichkeit
bieten sich externe Eingabegeräte wie das Virtual Laser Keyboard7 an, das
mittels einer Laserprojektion ein Standard-Tastaturlayout auf die Tischoberfläche zeichnet. Auch die Forschung mit Spracherkennung und Analyse von
Videobildern mittels integrierter Kamera lassen auf zukünftige, alternative
3
Windows Mobile - http://www.microsoft.com/windowsmobile/
Symbian OS - http://www.symbian.com/
5
.NET Compact Framework - http://msdn.microsoft.com/netframework/programming/
netcf/
6
Java Micro Edition - http://java.sun.com/javame/
7
Virtual Laser Keyboard - http://www.virtual-laser-keyboard.com/
4
Interaktionstechniken hoffen.
Alle Geräte verfügen mittlerweile über Farbdisplays in unterschiedlichen
Ausführungen. Die Auflösung und Skalierung des Displays hat ebenfalls signifikante Auswirkungen auf die Anzahl und Anordnung der grafischen Elemente die in einem GUI dargestellt werden können [26]. Die Bandbereite
reicht von kleinen Mobiltelefon-Displays bis zu hochauflösenden Bildschirmen. Trotz des Vorhandenseins gemeinsamer, grafischer Toolkits kann aufgrund der Varianten bei Ein- und Ausgabegeräten nicht jeder grafische Inhalt
gleich repräsentiert werden. Erschwerend kommt noch hinzu, dass nicht einmal gemeinsame Geräteklassen über gleiches Hardwarelayout verfügen und
Standards in dieser, bedingt durch den großen Wettbewerb, heterogenen
Landschaft nur sehr schwer Fuß fassen.
Die Entwicklung von Plattform-übergreifenden Applikationen in pervasiven Umgebungen erfordert neue Konzepte im Umgang mit Software und
deren grafischer Darstellung. Rapid Prototyping [9], die schnelle und teilautomatisierte Entwicklung von (prototypischen) Implementierungen, ist dabei
ebenso ein Thema wie Techniken zur abstrakten Beschreibung und Modellierung von Funktionalität einer Applikation. Auf Basis dieser Anstrengungen
können Versuche zur automatisierten Generierung grafischer Benutzeroberflächen unternommen werden.
4.3
4.3.1
Techniken der GUI-Entwicklung
Window Manager und Toolkits
Eine Reihe an Konzepten führt zu den heute angewandten und weit verbreiteten Techniken in der Entwicklung grafischer User Interfaces. Zu den großen
Errungenschaften der Window Manager zählt die Tiefenstaffelung und Skalierbarkeit von Fenstern, die schnelles Wechseln zwischen parallel laufenden Anwendungen ermöglichen. Window Manager sind Teil des Betriebsystems und bieten grundlegende grafische Operationen (Zeichnen, Updaten
des Bildschirms) und Schnittstellen für die Ereignisbehandlung an. Aufbauend auf diesem abstrakten Modell stellen grafische Toolkits ein meist komponentenbasiertes Framework für einfaches Arbeiten mit konkreten GUIElementen in einer bestimmten Programmiersprache zur Verfügung. Sie gewährleisten bis zu einem gewissen Grad Konsistenz hinsichtlich der Ereignisbehandlung und dem Zeichnen der grafischen Komponenten und dürfen
daher keinen starken Änderungen in der Programmbibliothek(API ) unterworfen sein.
4.3.2
Web-basierte Entwicklungen
In der Web-Entwicklung führte ein Zusammenspiel aus der Seitenbeschreibungssprache HTML, der Layoutbeschreibung CSS und Client- und server-
seitigen Scriptsprachen (Javascript, PHP, Perl) zum kommerziellen Durchbruch. Diese Sprachen müssen nicht kompiliert sondern lediglich zur Laufzeit
interpretiert werden und eröffnen durch leicht verständliche Ansätze einem
großen Personenkreis Zugang zur Programmierung. Ein Nachteil liegt in der
prozeduralen Abarbeitung des Programmcodes und der fehlenden Trennung
zwischen Datenhaltung, Präsentationslogik und Applikationslogik (ModelView-Controller oder MVC ). Der großen Erfolg von webbasierten Dienstleistungen führte dazu, dass führende objektorientierte Programmiersprachen
mit eigenen Scriptsprachen aufwarten und dadurch das MVC-Prinzip bestärken. Microsofts .NET Plattform arbeitet hier mit C# und Active Server
Pages (ASP). In der Java-Domäne erfüllen Java Server Pages und Servlets
diese Aufgabe.
Ein großer Nachteil von Webapplikationen liegt in dem zustandlosen
Transportprotokoll HTTP8 begründet, das die Verbindung zwischen Client und Server nur für den Zeitraum eines Request/Response-Zyklus offen
hält. Dadurch ist die grafische Oberfläche gezwungen, bei jeder Interaktion, die Datenzugriff auf den Server verlangt, die Inhalte neu zu laden.
Neue in Browser integrierte Technologien wie Asynchronous JavaScript and
XML (Ajax) [2], die vermehrte Verwendung von Web Services9 und SOAP
als XML- und HTTP-basierte Remote Procedure Call-Variante (RPC) versuchen diesen Nachteil mit Hilfe asynchroner Datenübertragung im Hintergrund ungeschehen zu machen. Auch proprietäre Rich Client Plattformen wie die Macromedia Flash Platform10 [19], arbeiten in dieser Hinsicht mit persistenten Verbindungen. Beispielhafte Anwendungen hierfür
sind die Kartographie-Software Google Maps11 und Services basierend auf
der Online-Fotodatenbank Flickr12 .
Mobiles Web
Die fortschreitende Entwicklung mobiler Endgeräte ermöglicht die Nutzung
von Webinhalten und Rich Media-Applikationen auch zunehmend auf Smart
Phones und PDAs. Mehrere vielversprechende Konzepte versuchen bestehende Technologien auf mobile Plattformen zu portieren. In [41] wird die
Idee eines zukünftigen, einheitlichen User Interfaces für dynamische, webbasierte Services erläutert:
The next logical step in this evolution is to extend the browser
to become the UI container for the smart phone platform. Moving
on from the rich media and application platform just described,
8
Das Hypertext Transfer Protocol wurde durch die Internet Engineering Task Force
spezifiziert (IETF) http://www.ietf.org/rfc/rfc2616.txt.
9
Web Services (Spezifikation der W3C) - http://www.w3.org/2002/ws/
10
Macromedia Flash Platform - http://www.adobe.com/de/platform/
11
Google Maps - http://maps.google.com/
12
Flickr Services - http://www.flickr.com/services/
by adding the ability to interact with the underlying smart phone
hardware and file system, the Web browser can become the engine
for the smart phone UI.
Drei Methoden wurden als richtungsweisend identifiziert: Die mobile
Java-Plattform J2ME, in den Browser integrierte XML GUI-Sprachen wie
XUL (siehe Kapitel 4.4.2) und standardisierte und proprietäre Auszeichnungssprachen und Scriptsprachen namens Macromedia Flash, JavaScript
und das Vektorgrafikformat SVG.
4.3.3
Interaktive GUI-Builder
GUI-Builder Werkzeuge gehen Hand in Hand mit dem eigentlichen Ziel der
grafischen Programmierung. Mit Hilfe eines Modellierwerkzeuges wird die
Oberfläche aus elementaren Teilen wie Fenster, Button, Textfeld, etc. zusammengesetzt und anschließend in editierbaren Programmcode für die objektorientierte Zielsprache konvertiert. Je nach Ausmaß der Bindung zwischen
der Grafikbibliothek der Programmiersprache und Entwicklungsumgebung
(Integrated Development Environment (IDE)) können Ereignisbehandlung,
Änderungen von Layout-Eigenschaften und auch die Datenanbindung an das
Interface integrativer Bestandteil des GUI-Builders sein. Visual Studio bietet eine solche Entwicklungsumgebung für die eigenen Programmiersprachen
C# und Visual Basic. Auch für die Java GUI-Bibliotheken Abstract Window Toolkit (AWT) und Swing stellen mehrere Entwicklungsumgebungen
GUI-Builder zur Verfügung.
4.4
XML GUI-Sprachen
XML als Metasprache mit baumartiger Gliederung eignet sich sehr gut zur
Definition von Auszeichnungssprachen, die die komponentenbasierte Struktur und hierarchische Anordnung von grafischen Elementen beschreiben. Es
existiert eine Vielzahl an XML GUI-Dialekten, die auf unterschiedlichen Abstraktionsebenen ein grafisches Interface für verschiedene Aufgabengebiete
spezifizieren. Das gemeinsame Ziel ist die automatische GUI-Generierung anhand einer Beschreibung, die auf einer Plattform in einer Entwicklungsumgebung mit Hilfe einer Programmiersprache oder in der Laufzeitumgebung
eines Programms oder Frameworks in ein konkretes Interface-Rendering verwandelt werden muss.
Mit Microsoft XAML, Mozilla XUL und XForms werden drei User Interface Description Languages (UIDL) vorgestellt, die eine starke Bindung
zu konkreten GUI-Komponenten und dadurch zum Endresultat des GUIBuilding Prozesses haben. UIML und XIML bieten eine generischere Definition eines grafischen Interfaces. Dies macht eine geräte- und plattformunabhängige Beschreibung möglich, verlangt aber im Gegenzug mehr Auf-
wand und Intelligenz bei der Auswertung der enthaltenen Information durch
Transformatoren und wissensbasierte Systeme und stellt vorab kein konkretes Rendering mit vordefinierten GUI-Elementen in Aussicht.
4.4.1
XAML
WinFX13 ist der Name von Microsofts .NET basierter Programmierschnittstelle, die die Basis für Applikationsentwicklungen im kommenden Betriebssystem Windows Vista bildet und in vier Bereiche gegliedert ist. Neben dem
Kommunikationsmodell Windows Communication Foundation (WCF), dem
Programmiermodell Windows Workflow Foundation (WF) und sicherheitsund authentifizierungsrelevanten InfoCard-Komponenten ist die Windows
Presentation Foundation (WPF) für die grafische Aufbereitung in Vista zuständig. Als Teil dieses Subsystems wurde die Extensible Application Markup Language (XAML) als XML-basierte Beschreibungssprache für User Interfaces konzipiert. Ziel ist die Trennung von Logik und Präsentationsschicht,
sowie die nahtlose Zusammenarbeit mit bestehenden .NET-Technologien.
So kann die Ereignisbehandlung, etwa ein Button-Klick, in externe C# oder
VB.NET Codefragmente ausgelagert werden, die in XAML referenziert werden. Innerhalb des Dokuments können auch Layouteigenschaften und einfache visuelle Effekte wie Transparenz festgelegt werden. Darüber hinaus
ist XAML als deklarative Sprache zur Darstellung folgender multimedialer
Inhalte, die Anlehnung an bestehenden Standards nehmen, angedacht14 :
• Layout: Ähnlich HTML und dem Portable Document Format (PDF)
soll es mit Flow-Format und Fixed-Format Dokumenten Unterstützung für verschiedene Text- und Objektlayoutdefinitionen und integrierte Steuerelemente für deren Betrachtung geben.
• Vektorgrafik und Multimedia: Die Definition von 2D und 3DVektorgrafiken sowie die Steuerung von Animationen und die Integration von Audio und Video erinnern an das Flash-Format SWF und die
XML-basierten W3C-Standards SVG (Scalable Vector Graphics) für
2D Grafiken und das Präsentationsformat SMIL (Synchronized Multimedia Integration Language).
• Daten Anbindung: Direkte Anbindung an Datenquellen wie Webservices und anderen XML-Daten ist ohne programmatischen Mehraufwand möglich.
• Technologieübergreifendes Formularwesen - In XAML festgelegte Oberflächen können sowohl für die Interface-Generierung von
Webanwendungen als auch für Desktop-Applikationen eingesetzt wer13
14
WinFX API - http://msdn.microsoft.com/winfx/technologies/default.aspx
XAML - http://www.xaml.net/
den und ersetzen damit unterschiedliche Technologien wie Windows
Forms und das webbasierte Formularwesen in ASP.NET.
4.4.2
XUL
XML User Interface Language (XUL)15 ist eine von Mozilla spezifizierte
GUI-Sprache, die in Mozillas Browser Firefox, dem Email-Client Thunderbird und weiteren Projekten zum Einsatz kommt und von der Gecko Rendering Engine verarbeitet wird. XUL wurde zur schnellen Entwicklung plattformunabhängiger Benutzeroberflächen entwickelt und versucht mit Hilfe
von Technologien wie XML-Transformationen, CSS und JavaScript den Implementierungsaufwand für grafische Oberflächen, der durch die Mischung
dieser verschiedenen Standards entsteht, zu minimieren. Zusätzlich wird an
der Gecko Laufzeitumgebung gearbeitet, die in Kombination mit serverseitigen Webarchitekturen wie PHP und JSP und der Programmiersprache Java,
die Entwicklung von GUI-Anwendungen mit dynamischem Inhalt auch außerhalb des Webbrowser-Kontextes erlaubt. Obwohl XUL kein Standard ist,
der von einer Dachorganisation getragen wird, beschäftigen sich mehrere
Projekte mit XUL Implementierungen16 und Anwendungen17. Mit der Erfindung von XUL versucht Mozilla dem durch lange Perioden der Stagnation
geprägten Prozess der Standardisierung von Web-Technologien zu entkommen und aufbauend auf vorhandenen Lösungen einen weiteren Schritt in
Richtung Unabhängigkeit von XHTML-basierten Services zu wagen.
Die Idee dahinter sieht eine Aufteilung von Kompetenzen in vier Bereiche
vor: Für die Beschreibung der baumartigen Struktur und den Inhalt des
grafischen Interfaces ist die XUL-Datei verantwortlich. Das Look & Feel des
Programms übernimmt ein eingebetteter oder referenzierter CSS-Code und
die Ereignisbehandlung wird an JavaScript-Anweisungen übertragen. Alle
internationalisierten Bezeichner einer GUI-Anwendung werden ebenfalls in
einer externen Datei festgelegt.
Wie auch XAML befindet sich XUL noch in der Entwicklungsphase, die
von einigen wenige Quellen dokumentiert wird18 .
4.4.3
XForms
Das XForms-Konzept19 ist aus der Notwendigkeit entstanden, das veraltete
Formularwesen in HMTL abzulösen. XForms ist ein XML basierter Standard und vollzieht eine klare Trennung zwischen der Präsentationsschicht
und dem dahinter liegenden Formularmodell [6]. Diese modulare Auslegung
15
Mozilla XUL - http://www.mozilla.org/projects/xul/
Luxor XUL - http://luxor-xul.sourceforge.net/
17
Mozilla Amazon Browser - http://www.faser.net/mab/
18
XUL Planet (Dokumentation des XUL Entwicklungsprozesses) - http://www.xulplanet.
com/tutorials/mozsdk/
19
XForms - http://www.w3.org/MarkUp/Forms/
16
Host Document
(XHTML,SVG,...)
XForms Model
Person
XForms
User Interface
Process Input
Validate
Name
Address
XForms:Input
Abbildung 4.1: XForms-Architektur (siehe [14]).
erlaubt die Definition von Formularen unabhängig vom konkreten, grafischen Erscheinungsbild und dem Endgerät. So sind neben einem XForm
User Interface auch XHTML, WML und proprietäre GUI-Renderings denkbar. Aufgabe der XForms ist das Sammeln von Daten (instance data), die
über das XForms Submit Protocol zwischen Server und Client ausgetauscht
werden. Die Unterbrechung und Wiederaufnahme von Formulareinträgen
und die Definition von Abläufen sind ebenfalls Teil der Spezifikation. Die
Validierung von Formularen muss nicht wie in XHTML mit einer gesondert
Scriptsprache vorgenommen werden, sondern ist Teil der Spezifikation. So
kann etwa die Reihenfolge der Formulareingaben, sowie die Überprüfung
von Datentypen lokal vorgenommen werden, sofern diese im XML-Schema
spezifiziert wurden.
Die Teilung von XForms in die Bereiche Präsentation, Logik und Datenhaltung vollzieht sich auch in der Dokumentenstruktur. Es ist wichtig
zu verstehen, dass XForms kein eigenes Dokumentenformat definieren und
aufgrund des Aspektes der Geräteunabhängigkeit in andere Dokumente wie
XHTML eingebettet werden können (Host Document, siehe Abb. 4.1). Darin
enthalten sind der XForms User Interface-Container und der XForms ModelContainer. Ersterer gibt Auskunft über die Anordnung der GUI-Elemente
innerhalb des Formulars. Das XForms Model hingegen hat drei Aufgaben: Es
ist für die Datenhaltung (instance), die Datenbindung an das Formular (binding) und die Abhandlung der Eingabeereignisse, die auch die Validierung
Peers
Presentation
Swing
Renderer
Interface
Logic
Structure
WML
Renderer
> i am quite
sure you can't
read this yerk!
yak '06...
Style
Content
Behaviour
Platform / Device
Application
Data Source
Abbildung 4.2: UIML Architektur (siehe [1]).
mit einbezieht (submission) zuständig. Zu den weitgefassten Designzielen
von XForms zählen auch die Unterstützung von mobilen Endgeräten und
die Generierung von Rich User Interfaces zur Steuerung von Geräten in Office und Haushalt.
4.4.4
UIML
Die User Interface Markup Language (UIML)20 versteht sich als eine Metasprache zur Beschreibung von User Interfaces, die plattformunabhängig,
geräteunabhängig und auch von der Vorstellung eines grafischen Interfaces
losgelöst sein soll. Das Mapping von abstrakten Interaktionselementen in die
spezifischen Sprachen Java, HTML, WML und VoiceXML, eine Sprache zur
Generierung von sprachgesteuerten Interfaces (auditory displays), wird in
der aktuellen Spezifikation [1] aus dem Jahr 2004 unterstützt. Diese Transformationsaufgabe wird dabei von speziellen Renderern übernommen, die
einmal für jede Sprache implementiert werden müssen.
UIML selbst definiert nur sehr wenige XML-Tags. Ähnlich der Document
Type Definition (DTD) für die Definition eines spezifischen XML-Dialekts
muss ein Vokabular, das ein direktes Mapping in eine Zielsprache oder eine
allgemeinere Beschreibung vorsieht, für das Arbeiten mit UIML geschaffen
werden. Die Komponenten eines Interfaces werden daher als Elemente mit
einer eindeutigen Id und einem Verweis auf eine Klasse gekennzeichnet.
Die Präsentation, die Anbindung an externe Datenquellen und das Interaktionsverhalten sind ebenfalls Teil der Sprachdefinition, die sich am
Model-View-Controller Designpattern orientiert (siehe Abb. 4.2). Auch UITemplates und zeitliche Veränderungen der Interface-Struktur, die durch
Öffnen eines neuen Fensters entstehen können, werden in UIML berücksichtigt. Die grundlegende Struktur ist in folgende Bereiche gegliedert:
1
2
< uiml xmlns = ’ http: // uiml . org / dtds / UIML3_0a . dtd ’ >
< head > ... </ head >
20
UIML - http://www.uiml.org/
3
4
5
6
7
8
9
10
11
12
13
14
15
16
< template > ... </ template >
< interface >
< structure >
< part / >
</ structure >
< style > ... </ style >
< content > ... </ content >
< behavior > ... </ behavior >
</ interface >
< peers >
< presentation > ... </ presentation >
< logic > ... </ logic >
</ peers >
</ uiml >
Interface-Elemente <part> werden innerhalb des <structure> -Tags hierarchisch angeordnet und können über den Klassennamen und die Id von
anderen Tags referenziert und mit Zusatzinformation wie Styleattributen
<property> versehen werden. In <presentation> wird das konkrete Mapping
zwischen abstraktem Element und konkretem Rendering festgelegt. Untenstehend ist eine vereinfachte Definition eines Java Swing-Fensters:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
< interface >
< structure >
< part class = " JFrame " id = " JFrame " >
< part class = " JButton " id = " Submitbutton " / >
</ part >
</ structure >
< style >
< property part - name = " JFrame " name = " layout " >
java . awt . GridBagLayout </ property >
< property part - name = " JFrame " name = " title " >
TestApp </ property >
</ style >
</ interface >
< peers >
< presentation id = " JavaSwing " >
<d - class id = " JFrame " used - in - tag = " part "
maps - type = " class " maps - to = " javax . swing . JFrame " >
...
</d - class >
</ presentation >
</ peers >
4.4.5
XIML
Ein fehlender Standard zur Interaktion und Repräsentation von Daten führte
zum Design der Extensible Interface Markup Language (XIML)21 . Die Auslegung der Sprache umfasst die ganzheitliche Unterstützung vom UI-Designprozess, über das Mapping zwischen abstrakten und konkreten Steuerele21
XIML - http://www.ximl.org/
menten bis hin zu Evaluierungsfunktionen und der Einbindung von wissensbasierten Systemen zur Auswertung aller vorhandener Daten. XIML will das
Paradigma interoperabler, vernetzter Softwaresysteme auch auf die Ebene
des User Interfaces ausweiten, indem ein einheitlicher Standard für die Präsentation und den Austausch von Interaktionsdaten definiert wird [29]. Eine
schwierige Aufgabe in Anbetracht der Tatsache, dass zu den komplexen Anforderungen von Interaktion und der Modellierung von Navigationsabläufen auch noch plattformübergreifende Synchronisation und Kontext-basierte
Einflüsse hinzukommen können.
Die Architektur von XIML definiert kontextuelle und strukturale Modelle und die Repräsentation eines Interfaces und bringt sie in einen relationalen Zusammenhang. Daher lässt die Nomenklatur dem Begriff der Komponente eine weitläufigere Bedeutung als in den meisten XML-GUI Sprachen
zukommen. Fünf Komponenten, die eine Sammlung an Elementen beinhalten, wurden festgelegt [29]:
1. Task: Die Task-Komponente liefert eine abstrakte Beschreibung aller Vorgänge, die die Interaktion mit dem Benutzer betreffen. Sowohl
die hierarchische Ordnung, als auch der Workflow können eingefangen werden. Beispiele für Vorgänge sind eine Datumseingabe oder das
Starten eines CD-Players.
2. Domain: Domain-Information bezeichnet anwendungsrelevante Objekte und Datentypen unterschiedlicher Komplexität, die mit dem Interface in Verbindung gebracht werden. Etwa ein Datum oder ein abstraktes Medienabspielgerät. Objekte werden in XIML als Attribute
definiert, die elementare Datentypen oder Instanzen von komplexen
Objekten sind.
3. User: Die User-Komponente hält alle benutzerspezifischen Informationen fest und erlaubt die Definition von Benutzergruppen.
4. Presentation: Die Präsentationsschicht beschreibt den hierarchischen
Aufbau des User Interfaces mit abstrakten Elementen wie einem Window oder einem Button. Für die Transformation in ein konkretes Erscheinungsbild ist ein Konverter für jede Plattform nötig.
5. Dialog: Der Dialog definiert alle Interaktionen und die erlaubte Navigationsstruktur für das GUI auf einer konkreteren Ebene als der Task.
Ein Klick und auch Spracheingabe bezeichnen beide Interaktionen.
1
2
3
4
5
6
7
< interface
xmlns = "x - schema:http: // www . ximl . org / validator / schema . xml "
id = " test " >
< definitions > ... </ definitions >
< model_compo ne nt s >
< task_model id = " dictionary " > ... </ task_model >
< domain_model id = " dictobjects " > ... </ domain_model >
XIML Interface
Specification
Presentation
Component 1
HTML
Converter
Presentation
Component 2
WML
Converter
> i am quite
sure you can't
read this yerk!
yak '06...
Abbildung 4.3: XIML Architektur (siehe [29]).
8
9
10
11
12
< user_model id = " dictobjects " > ... </ user_model >
< presentation _m o de l id = " java " > ... </ presentati on _m o de l >
< dialog_model id = " dictdialog " > ... </ dialog_model >
</ model_compo ne nt s >
</ interface >
Ein- und Mehrfachbeziehungen zwischen den Elementen dieser Modelle
komplementieren das gesammelte Wissen für ein konkretes Interface-Rendering. Die Datenauswertung ist Teil des XIML-Frameworks. Die Sprache
sieht vor, dass zu einem GUI für jede Plattform eine eigene Präsentationskomponente deklariert werden muss, die verarbeitet und angezeigt werden
kann.
Ist die Unterstützung mangels XML-Parser oder anderer, fehlender Vorrausetzungen nicht gegeben, kommen Konverter zum Einsatz. Um nicht für
jede GUI-Anwendung neue Komponenten spezifizieren zu müssen, gibt es
auch in XIML die Möglichkeit eine plattformübergreifende Präsentationsschicht mit abstrakten Elementbeschreibungen einzuführen (siehe Abb. 4.3
und Abb. 4.4). Es wird nicht definiert, wie diese Abstraktion auszusehen hat
und welche organisatorischen und semantischen Informationen darin enthalten sind. Unter dem Begriff Intelligent Interaction Management werden wissensbasierte Systeme unterstützt, die zur Laufzeit Personalisierung von Inhalten, dynamische Anpassung der Informationsdichte und Synchronisation
von Interaktionsinformation zwischen mehreren GUI-Instanzen ermöglichen
sollen.
Der hohe Abstraktionsgrad und die vielen Funktionen zwingen selbst bei
kleinen GUI-Projekten zu einer umfassenden Deklaration der Modelle und
Relationen. Das folgende Codestück 4.1 zeigt die für ein einfaches Java AWT
Fenster nötigen Definitionen der Präsentationskomponente:
Listing 4.1: Java AWT Fenster - Präsentationskomponente
1
2
3
4
5
< presentati on _m o de l id = " dictbasicpres " >
< name > basic presentation model for the dictionary </ name >
<! -- definition of presentation elements -- >
< definitions >
< relation_de fi ni t io n name = " m a i n w i n d o w _ i s _ a _ a i o w i n d o w" >
XIML Interface
Specification
Intermediate
Presentation
Component
Knowledgebased System
Presentation
Component 1
HTML
Converter
Presentation
Component 2
WML
Converter
> i am quite
sure you can't
read this yerk!
yak '06...
Abbildung 4.4: XIML Architektur mit Intermediate Presentation Component (siehe [29]).
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
< allowed_class es >
< class reference = " mainwindow " slot = " left " / >
< class reference = " aiowindow " slot = " right " / >
</ allowed_class es >
</ relation_de fi ni t io n >
</ definitions >
<! -- here is the hierarchy of presentation elements -- >
< p r e s e n t a t i o n _ e l e m e n t id = " mainwindow " location = " optional " >
< name > dictionary main window </ name >
< p r e s e n t a t i o n _ e l e m en t id = " deflabel " location = " optional " >
< name > dictionary definition label </ name >
</ p r e s e n t a t i o n _ e l e m en t>
< p r e s e n t a t i o n _ e l e m en t id = " termslist " location = " optional " >
< name > list of terms in the dictionary </ name >
<! -- now are the definitions of the ( aios ) themselves -- >
< p r e s e n t a t i o n _ e l e m e n t id = " aiowindow " location = " optional " >
< name > definition of the abstract window </ name >
< p r e s e n t a t i o n _ e l e m en t id = " javawindow "
location = " http: // www . ximl . org / ui / javaawtrender . ui # awt " >
< name > rendered for the java toolkit </ name >
< p r e s e n t a t i o n _ e l e m en t id = " winntwindow "
location = " http: // www . ximl . org / ui / winnt / window . vbx " >
< name > rendered for the windows nt environment </ name >
</ presentati on _m o de l >
4.5
Model-based User Interface
XML-basierende GUI-Sprachen bieten eine Möglichkeit für die automatisierte Erstellung von grafischen Oberflächen. Je abstrakter jedoch die Definition des grafischen User Interfaces ausgelegt ist, desto schwieriger ist es, alle
nötigen Anforderungen im Voraus festzulegen. Wie am Beispiel von UIML
und XIML zu sehen ist, ist der Aufwand für eine generische, deklarative
Beschreibung mit zunehmender Komplexität einer GUI-Anwendung höher
einzuschätzen, als eine programmatische Lösung. Zudem müssen ohnehin
Transformationswerkzeuge implementiert werden, die Quellcode für die spezifische Plattform oder -sprache erzeugen. In dieser Hinsicht haben XAML
und XUL den Vorteil der engen Bindung an bestehende Softwaresysteme,
die eine Entwicklung von GUI-Anwendungen auch ohne programmatischen
Mehraufwand erlauben.
All diese Konzepte stehen aber in Widerspruch zu den Anforderungen eines plattformübergreifenden User Interfaces, das dynamischen Änderungen
zur Laufzeit unterliegt und dabei kontextbezogene Informationen mit einbezieht. Model-based User Interface Tools sind Systeme zur automatisierten
Erfassung und Auswertung verschiedener Interface-bezogener Datenmodelle.
Bereits in den Neunziger Jahren wurden Forschungen in diese Richtung vorangetrieben. Obwohl zu diesem Zeitpunkt noch kein standardisiertes Datenformat wie XML oder tiefgreifende objektorientierte Paradigmen Teil der
Softwareentwicklung waren, wurden dennoch grundlegende User Interface
Modelle entworfen, die bis heute Gültigkeit haben. In [32] und [23] wurden
anhand mehrere Projekte folgende Modelle identifiziert:
• User Model: Die Modellierung des Users beinhaltet die Personalisierung von Inhalten und die Aufzeichnung und Analyse von Benutzerverhalten während der Laufzeit der GUI-Applikation.
• Task Model: Das Task Model definiert alle Tasks, die ein User in
einem GUI ausführen kann. Diese können auch anhand einer Zielbeschreibung, der Aufteilung in mehrere atomare Subtasks und Zustandsüberführungen festgehalten werden.
• Application Model: Das Application Model wird auch Object Model
oder Business Model genannt, repräsentiert den Zustand der Applikation und listet alle für das GUI relevanten Schnittstellen und Dienste.
Diese decken sich mit den Subtasks des Task Models.
• Dialog Model: Der Dialog ist eine spezifischere Auslegung des Task
Models und beschreibt die tatsächlichen Interaktionsmöglichkeiten einer GUI-Anwendung.
• Presentation Model: Auf Ebene des Presentation Models wird das
Rendering des GUIs durchgeführt. Dazu werden die vorhandenen Informationen der anderen Models ausgewertet und in eine konkrete Darstellung transformiert.
• Domain Model, Device Model und Platform Model: Je nach
Auslegung des UI Tools wird eine unterschiedliche Kategorisierung der
kontextspezifischen Information vorgenommen. Diese umfassen die Beschreibung der Geräte, die plattformspezifischen Anforderungen und
andere Daten aus dem Umfeld, die für die Anwendung von Bedeutung
sind.
4.5.1
User Interface Generierung
Die User Interfaces Generierung, die sich auf die Informationen aus den
verschiedenen Models stützt, ist mit einer Reihe an Aufgaben verbunden,
die es im Zuge des GUI-Rendering Prozesses zu lösen gilt [32]. Anhand der
beiden model-based User Interface Tools Supple und Pebbles Personal Universal Controller (siehe Kapitel 4.5.2 und 4.5.3) werden die Schritte näher
erläutert:
• Zuerst muss eine Auswertung der Models und eine anschließende Identifizierung aller abstrakten Interface-Elemente passieren. Ein Beispiel
für ein abstraktes Interface-Element ist die Definition eines Fenstermenüs, das je nach Wahl der Plattform anders aussehen kann, aber
immer die gleiche Funktion erfüllt.
• Die spätere Umwandlung in konkrete, plattformabhängige InterfaceElemente wird als Mapping bezeichnet und geschieht zusammen mit
der automatisierten Anordnung der Komponenten im Interface.
• Zwecks semantischer Bindung werden Zusatzinformationen zur Verhaltensmodellierung des Interfaces eingebracht. Damit können etwa
Abhängigkeiten zwischen Elementen definiert werden, um ganze Funktionsgruppen anhand eines Elements zu aktivieren oder zu deaktivieren. Komplexere Verhaltensmuster werden jedoch nicht von den modelbased UI Tools abgedeckt und müssen selbstständig modelliert werden.
• Kaum ein generiertes Interface entspricht in allen Belangen den Vorstellungen des Designers oder den Bedürfnissen des Users. Zusätzliche
Methoden zur Evaluierung und Revision unter Einbeziehung menschlicher Beurteilungen sind daher ein adäquates Mittel zur manuellen
und automatisierten Abänderung des Interfaces zur Laufzeit.
4.5.2
Projekt – Pebbles Personal Universal Controller
Der Personal Universal Controller (PUC)22 ist ein Forschungsschwerpunkt
im Rahmen des Pebbles Projektes an der Carnegie Mellon University, dass
sich mit der Nutzung von PDAs und Smart Phones als Interaktionsgerät für
verteilte Anwendungen beschäftigt. PUC setzt dabei auf die automatisierte
Generierung und Personalisierung von User Interfaces für Netzwerkdienste,
die sich im unmittelbaren Umfeld des Benutzers befinden und mit einer beliebigen Funktechnologie wie Bluetooth oder WLAN angesprochen werden
22
Personal Universal Controller - http://www.pebbles.hcii.cmu.edu/puc/
können. Das Konzept ist auf die Entwicklung mobiler Fernsteueranwendungen für die Betriebssysteme PalmOS und Windows Mobile ausgerichtet. Der
Begriff des Interfaces ist in PUC nicht nur auf grafische Oberflächen beschränkt, sondern inkludiert auch Spracheingabe und soll dem Benutzer bei
der Wahl des favorisierten Interaktionsmediums freie Hand lassen.
Als Basis für die Erstellung von User Interfaces zur Fernsteuerung von
Geräten dient die eigens definierte XML GUI-Sprache namens PUC Specification Language 23 , die eine funktionale Gerätespezifikation anhand hierarchisch strukturierter Gruppierungen, Zustandsvariablen und Steuerbefehlen
beschreibt. Die enthaltene Information ist mit der eines Application Models
gleichzusetzen.
Systemarchitektur
Abbildung 4.5 zeigt den Systemaufbau von PUC. Da die funktionale Beschreibung von jedem Endgerät zur Verfügung gestellt werden muss, braucht
es eine einheitliche Kommunikationsschnittstelle zwischen Gerät und Interface. Gerade im Bereich der Unterhaltungselektronik ist jedoch kaum ein
gemeinsamer Standard zu finden. Daher müssen Geräteadapter in Software
oder Hardware für die Umsetzung der Befehle des PUC-Protokolls in das
proprietäre Protokollformat zwischengeschalten werden. Soweit das Gerät
bidirektionale Kommunikation unterstützt, garantiert PUC die Konsistenz
zwischen dem Application Model und den Inhalten des Interfaces. Speziell
im Niedrigpreissegment sind aber immer noch viele Geräten mit InfrarotSchnittstellen ausgestattet und können nach dem bekannten Prinzip einer
Fernbedienung lediglich Befehle entgegennehmen.
In PUC existieren nach eigenen Angaben zum gegebenen Zeitpunkt Adapter für Camcorder mit IEEE 139424 -Anschluss und dem AV/C Protokoll,
Videorecorder die den Steuerungsstandard HAVi25 unterstützen, den amerikanischen Gebäudesteuerungsstandard X1026 und diverse proprietäre Hardware wie eine Telefonanlage. Die Integration von Jini und UPnP wird in
Aussicht gestellt.
Obwohl Funktechnologien bevorzugt werden, stellt PUC keine Anforderungen an die verwendete Netzwerktechnologie. Es wird jedoch vorausgesetzt, dass jedes Gerät oder dessen Adapter über eine eigene Netzwerkanbindung verfügt, um die Peer-to-Peer Kommunikation zwischen Endgerät
und dem Interface-Client, die ohne zentralen Verbindungsknoten auskommt,
zu ermöglichen. Das XML-basierte Kommunikationsprotokoll ist einfach gehalten und definiert sechs Befehle zum Austausch von Gerätebeschreibung,
23
PUC Specification Language - http://www.pebbles.hcii.cmu.edu/puc/specification.html
Die Datenschnittstelle ist auch unter dem Namen FireWire bekannt.
25
HAVi - urlhttp://www.havi.org/
26
X10 - http://www.x10.com/home2.html
24
Application
PUC Device
Adapter
PUC Protocol
Communication
PUC Protocol
Network (802.11, Bluetooth, IR...)
Communication
Abbildung 4.5: PUC Architektur (siehe [28]).
Steuernachrichten und Zustandsänderungen27.
Layout Generierung
Die Gerätespezifikation in Form einer funktionalen XML-Beschreibung ist
die Basis für die Generierung eines Interfaces. Innerhalb des Dokuments
ist eine Gruppen-Baumstruktur zur Anordnung von Zustandsvariablen und
Steuerbefehlen definiert. Die Variable gibt Auskunft über den Namen, den
Datentyp und den Wertebereich des Zustandes. Anhand des Datentyps, der
neben primären Datentypen auch eine Auflistung und eigens definierte Typen erlaubt, wird ein Interface-Element zur Darstellung und Manipulation
des Zustandes ausgewählt. Dennoch sind in Form von Steuerbefehlen, die
als ausführbare Buttons gerendert werden, zusätzliche Funktionen nötig, da
nicht jeder Zustand im vorhinein bekannt sein kann.
Am Beispiel eines Radios, das einen Button für den automatischen Frequenzsuchlauf benötigt, ist dieses Vorgehen schnell erklärt: Würde man ganz
auf die Verwendung von Zustandsvariablen verzichten, entspräche die Modellierung des Interfaces einer heutigen Hardware-Fernbedienung, die keinerlei
Rückmeldung über die Gerätezustände zulässt [28]. Die logische Gruppierung erlaubt dem UI-Generator, der für jede Plattform einmal implementiert werden muss, anfängliche Rückschlüsse über die Strukturierung der
Interface-Elemente.
Durch zusätzlich definierte Abhängigkeiten zwischen den Zustandsvariablen können weitere Rendering-Hinweise abgeleitet werden. Das Display
mobiler Endgeräte ist in seiner Größe stark eingeschränkt. Daher müssen
Funktionen oft in mehreren Reitern angeordnet werden. Werden im Zuge
der Auswertungen Gruppierungen und Elementen gefunden, die sich aufgrund von Abhängigkeiten gegenseitig ausschließen, kann diese Information
dazu benutzt werden, um die Interface-Elemente auch lokal von einander
27
PUC Communications Protocol - http://www.pebbles.hcii.cmu.edu/puc/protocol spec.
html
zu trennen. Ein Beispiel: Eine Stereoanlage definiert die Operationsmodi
Radio, CD, Kassette und AUX, die anhand eines Zahlenwertes von 1 − 4 definiert werden. Zu einem Zeitpunkt kann nur ein Modus in Betrieb genommen werden. Alle Zustände der CD-Sektion sind folglich nur aktiv, wenn
der CD-Player in Betrieb ist. Das untenstehende Codestück repräsentiert
die Nummer des aktuellen Musikstückes und zeigt die Abhängigkeit zum
Mode-Zustand in <active-if> .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
< spec name = " Audiophase - Stereo " >
< group >
< state name = " CDTrackState " >
< type >
< valueSpace >
< integer / >
</ valueSpace >
</ type >
< labels >
< label > CD Track </ label >
< label > Track </ label >
< text - to - speech text = " Track " recording = " track . au " >
</ labels >
< active - if >
< equals state = " Mode " >2 </ equals >
</ active - if >
</ state >
...
</ group >
</ spec >
Die Zuweisung von Zuständen und Steuerbefehlen zu konkreten Interface-Elementen wird mit Hilfe eines Entscheidungsbaumes und damit verbundenen Fragen nach dem Typ und anderen Eigenschaften des Elements
gelöst. Im Anschluss daran wird das Problem der strukturellen Anordnung
durch Traversieren und Analysieren des Gruppen-Baumes in Angriff genommen. Im Falle der Stereoanlage unterteilt der UI-Generator die vier exklusiven Operationsmodi aufgrund der gewonnenen Information schließlich in
mehrere, sich überlappende Reiter. Globale Funktionen, die sich auf die Aktivität aller Komponenten auswirken (Einschaltknopf), oder oft genutzt werden (Lautstärkeregler), werden durch andere Abhängigkeitsregeln am linken
Rand des Interfaces angeordnet und sind immer verfügbar (siehe Abb. 4.6).
Dieses Regel-basierte System wirkt sich nachteilig auf die Skalierbarkeit
und Portierbarkeit des PUC-Konzeptes aus, da es mit jeder Änderung auch
eine Änderung der plattformabhängigen Rendersysteme nach sich zieht. Der
Entscheidungsbaum stellt zudem ein weiteres Hindernis dar, weil das Interface in einem Durchgang erstellt wird und keine weitreichenderen Überlegungen hinsichtlich des globalen Ergebnisses und gerätebedingter Einschränkungen zulässt [17], wie das im nächsten Beispiel anhand von Supple der Fall
ist.
Abbildung 4.6: PUC Rendering einer Stereoanlage (siehe [28]).
4.5.3
Projekt – Supple
Supple28 ist ein Softwareprojekt der University of Washington, das in einer
langjähriger Tradition der HCI-Forschung steht. Es basiert auf Erkenntnissen im Bereich der Entscheidungstheorie und Optimierungsproblematik.
Supple ist ein plattformunabhängiges System zur Generierung von dynamisch-adaptiven User Interfaces für Java-fähige Endgeräte und das Web. Neben einer abstrakten, funktionalen Beschreibung der Applikation auf Ebene
des Sourcecodes, dienen ein Device Model und ein User Model als Informationsquellen zur GUI-Generierung [16].
Supple selbst umfasst keine abstrakte Modellierung von Tasks und semantischen Informationen, sondern konzentriert sich rein auf die technische
Umsetzung der Interface Generierung. Die funktionale Beschreibung umfasst
die hierarchische Anordnung von Steuerbefehlen und Zustandsvariablen, von
denen der Name, der Datentyp und Einschränkungen des Wertebereichs
bekannt sein müssen. Neben Basisdatentypen können auch Vektoren und
komplexere Container-Datentypen definiert werden, die aus ersteren zusammengesetzt werden können. In Supple wird kein Bedeutungsunterschied zwischen der Definition einer Variable und dessen grafischer Auslegung gemacht.
Container-Datentypen sind also nichts anderes, als logische Gruppierungen
mehrerer Interface-Elemente, die selbst wiederum ein Interface-Element darstellen. Das Device Model beschreibt alle konkreten Elemente, die ein Gerät
zur Verfügung stellt, sowie dessen spezifische Eigenschaften. Supple nimmt
auf Eigenschaften wie die Plattform, die Größe des Displays und die Interaktionsmethode, die mausähnliche Eingabegeräte aber auch ein Touchpanel
28
Supple - http://www.cs.washington.edu/ai/supple/
Supple
Method Call
Messages
Supple Solver
User
Model
Device
Model
Application
Display Device
Interface
Model
State and
Logic
Widget
Proxies
Concrete
Widget
Abbildung 4.7: Supple Architektur (siehe [15]).
sein können, Rücksicht. Das User Model sammelt zur Laufzeit Daten des
Benutzers, um das Interface den aktuellen Bedürfnissen anzupassen.
Systemarchitektur
Abbildung 4.7 zeigt die Architektur von Supple. Für die automatisierte Generierung wird ein Interface Model definiert, das die Steuerbefehle und Zustandsvariablen des unterliegenden Application Models als abstraktes Interface-Elemente exportiert und dem Supple Solver zur Verfügung stellt. Dieser
erstellt anhand der Device Model Information mehrere plattformabhängige
Widget Proxies und ordnet sie mit Hilfe einer kombinatorischen Suche einem
Element zu. Zuletzt werden die bestehenden Verbindungen ausgewertet und
für jedes abstrakte Element ein konkretes UI-Element generiert. Ist die Anbindung der Applikation mit Hilfe von Bean-Objekten realisiert, garantiert
Supple die bidirektionale Konsistenz zwischen den Daten des User Interfaces
und dem Application Model [15]. Mit dieser Funktionalität sind mehrere Instanzen eines GUI mit gleichbleibender Applikationslogik ohne zusätzlichen
Aufwand denkbar.
Layout Generierung
Supple definiert die Aufgabe des Interface-Rendering als Optimierungsproblem, das Teil der theoretischen Informatik und des Forschungsgebietes der
Künstlichen Intelligenz ist. Das Ziel ist die Suche nach der bestmöglichen
Darstellung des User Interfaces unter den gegebenen Einschränkungen und
Erkenntnissen. Diese sind durch die funktionale Spezifikation des InterfaceModels, durch das Device Model und durch die Ablaufverfolgung des Benutzers gegeben. Als Maß für die Optimierung wird eine Kostenfunktion,
die den Navigationsaufwand für den Benutzer darstellt, herangezogen. Das
bestmögliche Interface-Rendering, das aus einer Menge an errechneten Möglichkeiten ausgewählt wird, ist jenes, das den minimalsten Gesamtaufwand
aufweist. Die Kosten einer Möglichkeit können als gewichtete Summe einzelner Kostenfunktionen der Interface-Elemente beschrieben werden. Die Kosten für ein einzelnes Element setzen sich aus mehreren Faktoren K und
zugehörigen Gewichtungsfaktoren uk zusammen, die durch Interaktion des
Benutzers fortwährend adaptiert werden (siehe Formel 4.1 aus [17]).
$(render(e)) =
K
uk (render(e))
(4.1)
k=1
Als Lösungsverfahren des Optimierungsproblems auf Basis der InterfaceKostenfunktion wird der Branch and Bound-Algorithmus29 verwendet, der
es erlaubt, die Suche auf ein eindimensionales, rekursives Verfahren zu reduzieren. Indem der hierarchisch aufgespannte Suchbaum in Subregionen
unterteilt wird, die gesondert auf die Grenzen der gesuchten Variablen analysiert werden können, fällt es leichter ungültige Lösungsbereiche frühzeitig
zu finden und zu verwerfen. Bedingt durch die vielen Abhängigkeiten müssen selbst bei einfachen Beispielen wie der Generierung eines User Interfaces
für eine Mediensteuerung bis zu 1,8x109 potentielle Rendering-Varianten
beachtet werden (siehe Abb. 4.8). Mit Hilfe verteilten Wahrscheinlichkeitsberechungen hinsichtlich des zu erwartenden Nutzerverhaltens und heuristischer Annäherungsfunktionen an das theoretisch optimalste Interface kann
allerdings eine annehmbare Reduktion des Suchraumes erreicht werden. So
stellt die Auswertung für ein modernes PC-System bei einer durchschnittlichen Rechendauer von 1s keine allzu großen Schwierigkeiten dar. Für einen
PDA mit eingeschränkter Hardware kann sich diese Zeitdauer jedoch um
den Faktor 40 erhöhen [17].
Adaptierung und Personalisierung
Ein wichtige Erkenntnis von Supple ist die Tatsache, dass das Ergebnis
des Rendering-Prozesses selten den Erwartungen und Bedürfnissen eines bestimmten Benutzers entspricht. Die Personalisierung von Inhalten ist daher
Gegenstand intensiver Forschungen. In Supple sind zwei Arten der Personalisierung bekannt [3]: Adaptierung bezeichnet die automatisierte Änderung
des Interfaces auf Basis des Nutzerverhaltens und ist auch im Bereich der
künstlichen Intelligenz unter dem Namen Preference Elicitation bekannt [18]
. Die manuelle Anpassung ist eine vom Benutzer initiierte Methode zur Evaluierung der erwarteten Qualität des Renderings. Die Adaptierung setzt dabei auf das Erfassen, Verarbeiten und Interpretieren von Benutzerspuren.
Der Zustandsautomat einer Applikation wird dabei in Relation zu den ermittelten Interaktionen des Benutzers gesetzt. Werden im Zuge der Auswertung iterative Vorgänge entdeckt, die sich über mehrere, von einander
29
Branch and Bound Algorithmus - http://www.ie.bilkent.edu.tr/õmer/research/bb.html
(a)
(b)
Abbildung 4.8: Renderings einer Mediensteuerung für PC (a) und Touchpanel (b). Beide wurden auf dem Desktop-Screen mit einer Auflösung von
1680 x 1050 erstellt, nahmen jedoch weniger als den zur Verfügung stehenden
Platz in Anspruch. Die Hauptcontainer des Interfaces (LightBank, A/V Controls, Vent ) waren ursprünglich sogar untereinander angeordnet und wurden
erst durch eine zusätzliche Größeneinschränkung mit maximal 640 x 480 Pixel in eine Form mit ausgewogenem Seitenverhältnis gebracht.
entfernte Interaktions-Objekte wie Fenster, Popup-Dialoge und Reiter erstrecken, wird versucht diese Wegkosten zu minimieren. Die automatisierte
Umstrukturierung von Layout und Elementanordnungen durch Kopie oder
Verschieben muss in sorgfältiger Abwägung der Konsequenzen bedacht werden. Dazu zählt die Desorientierung des Benutzers durch sich dynamisch
ändernde Inhalte als auch der Verlust der Konsistenz zwischen ähnlichen
Interfaces.
Für das Problem der Preference Elicitation wird ein zu Supple komplementäres System namens Arnauld 30 eingesetzt, das ebenfalls entscheidungstheoretische Optimierungsverfahren verwendet [18]. Example Critiquing bezeichnet eine vom Benutzer initiierte Änderungen im System und im Falle
von Supple dem konkreten User Interface. Möglich wird dies durch ein
in Supple enthaltenes Werkzeug, das zur Laufzeit Änderungen von GUIKomponenten erlaubt (siehe Abb.4.9). Neben dem Slider kann das LevelElement auch noch durch andere Interface-Elemente wie eine Combobox,
eine Liste oder ein Spinner-Wiget, das ein manuelles Eingabefeld und zwei
kleine Knöpfe zur Abänderung des Wertes um 1 darstellt, repräsentiert werden.
Allein aus dieser Methode lassen sich allerdings nicht immer genügend
Parameter zur Erstellung der Supple-Kostenfunktion und nachhaltigen Ver30
Arnauld - http://www.cs.washington.edu/ai/arnauld/
Abbildung 4.9: Supple – Werkzeug zur dynamischen Änderung von GUIKomponenten zur Laufzeit.
besserung der subjektiven Qualität des Interfaces ermitteln. Für diese Fälle
generiert Arnauld einfache binäre Fragen, die zwei konkrete Interface-Renderings oder einfache Interface-Elemente miteinander vergleicht und den
User nach dem qualitativ besseren Ergebnis fragt. Wichtig ist dabei, dass
auch die Fragen signifikanter Relevanz sein müssen, um genügend Informationen extrahieren zu können. In diesem Zusammenhang muss dem Benutzer
der Unterschied zwischen den Renderings bewusst sein, um ein Urteil fällen
zu können. Betrifft die Frage etwa nur das Aussehen eines einzelnen Elements, so muss diese in einem auffolgenden Schritt auch im Kontext des
gesamten Interfaces präsentiert werden, um dieses Bewusstsein zu gewährleisten [18].
Kapitel 5
GUI-Builder
5.1
Konzept
Das Supple Projekt (siehe Kapitel 4.5.3) hat sich als brauchbares SoftwareWerkzeug zur automatisierten Generierung grafischer User Interfaces erwiesen. Supple verfügt über geeignete Schnittstellen zur Anbindung externer
Applikationslogik. Diese muss in der Lage sein, einen Bezug zwischen dem
technischen Aufbau des Interfaces und der zugrundeliegenden Aufgabe der
Anwendung herzustellen. Diese Verbindung ist grundsätzlich bei jeder Software der Fall, bei der sowohl die Benutzeroberfläche als auch die Logik gemeinsam entwickelt werden. Verteilte Netzwerkgeräte liefern hingegen nur
funktionale Beschreibungen der Schnittstellen ohne Bezug auf den Kontext
der Anwendung zu nehmen oder gar Auslegung und Verhalten eines grafischen Interfaces zu definieren. Die Service-Plattform UPnP integriert mit
Absicht keine Unterstützung für Benutzeroberflächen, um die herstellerspezifische Individualität der Produkte zu gewährleisten [7]. Die zur Verfügung
stehenden Controlpoint-Implementierungen bieten lediglich ein rudimentäres Interface zur zentralen Fernsteuerung der UPnP-Geräte und sind für
Laien nur schwer bedienbar (siehe Abb.5.1).
Aus dieser Überlegung heraus entstand die Idee zu einer Erweiterung
des UPnP-Standards, die den Nutzen einer einheitlichen Service-Plattform
auf das User Interface ausweitet und so zu einem Gesamtkonzept für die
Steuerung verteilter Anwendungen und Gerätedienste beiträgt. Dafür müssen folgende Anforderungen erfüllt werden:
• Zur Fernsteuerung von UPnP-Geräten soll ein ein gemeinsames User
Interface erstellt werden, das in ansprechender Form präsentieren und
intuitiv bedienbar sein.
• Zusätzlich zu der funktionalen UPnP-Gerätespezifikation muss eine Informationsquelle gefunden werden, die Aufschluss über die semantische
Zusammengehörigkeit von Interface-Elementen und dadurch zwischen
den einzelnen, ausführbaren UPnP-Aktionen gibt.
53
KAPITEL 5. GUI-BUILDER
54
1
Abbildung 5.1: Cyberlink Controlpoint (siehe auch Kap. 3.3) – Entlang einer Baumstruktur werden die Services, Aktionen und Zustandsvariablen der
UPnP-Geräte gelistet. Erst auf dritter Ebene ist das Ausführen einer Aktion möglich. Eine eklatante Schwäche hinsichtlich der Benutzerfreundlichkeit zeigt folgender Fall: Wurde ein neues Gerät gefunden oder vom Netzwerk
abgemeldet, wird der gesamte Baum geschlossen und neu aufgebaut.
• Es dürfen keine Einschränkungen hinsichtlich der Funktionalität bestehender UPnP-Mechanismen gemacht werden.
• Ein UPnP-basierter GUI-Builder soll für mehrere Plattformen realisiert werden. Neben der Entwicklung einer PC-Anwendung mit dem
Supple-Toolkit soll auch ein reduziertes User Interface für Smart Phones implementiert werden. Das mobile Endgerät wird am besten dem
Paradigma einer universell einsetzbaren und drahtlosen Fernsteuerung
gerecht.
• Sofern die Möglichkeit gegeben ist, soll mit dem UPnP Event-Mechanismus und der gemeinsamen Datenhaltung Konsistenz zwischen den
Inhalten der verschiedenen User Interfaces erreicht werden. Konsistenz
bedeutet in dieser Hinsicht, dass Änderungen an einem Interface des
gesteuerten UPnP-Dienstes auch auf andere Interface-Renderings, die
die selben Geräteinhalte darstellen, reflektiert werden sollen.
5.1.1
System-Schnittstellen
Für die Implementierung des GUI-Builder Prototyps wird ein OSGi-Framework mit einem Bundle zur Kommunikation mit UPnP eingesetzt.
55
Domoware Base Driver
generate
Exporter
UPnP Device 2
Importer
Virtual
UPnP Device 1
generate
Cyberlink
OSGi Framework
UPnP Network
Virtual
UPnP Device 2
UPnP Device 1
Abbildung 5.2: Aufbau des Domoware Base Drivers (siehe Domoware Homepage).
OSGi-Framework
Um eine Vereinfachung des Entwicklungsprozesses und maximale Kompatibilität zwischen den einzelnen Softwarekomponenten zu erreichen, wird
ein OSGi-Framework Release 4 eingesetzt. Die Entwicklung des UPnP-GUI
Builders wird mit dem Eclipse Equinox 2 Framework realisiert. Equinox ist
ein Teil der Java-Entwicklungsumgebung Eclipse IDE und wird für das Management der OSGi-Plugins (Bundles) verwendet. Durch die enge Bindung
zwischen OSGi-Framework und IDE können OSGi-Bundles in Eclipse entworfen und auch direkt darin getestet werden.
UPnP-OSGi Gateway
Für die Integration von UPnP in das OSGi Service-Framework steht der
UPnP Base Driver von Domoware3 zur Verfügung. Das Bundle agiert dabei
als Gateway zwischen den beiden Standards. Es importiert alle gefundenen
UPnP-Geräte als generische OSGi-Services und hilft beim Export aller in
OSGi entwickelten UPnP-Geräte ins UPnP-Netzwerk (siehe Abb. 5.2 von
der Domoware-Website4 ).
2
Eclipse Equinox - http://www.eclipse.org/equinox/
Domoware - http://domoware.isti.cnr.it/
4
Domoware UPnP Base Driver - http://domoware.isti.cnr.it/documentation.html
3
5.1.2
56
Setup
Das in Abbildung 5.3 ersichtliche Setup zeigt die Zusammenhänge zwischen
den einzelnen Applikationen. Der GUI-Builder PC ist als OSGi-Bundle entworfen und hat auf die OSGi-internen und, über den Base Driver, auf die externen UPnP-Geräte Zugriff. Er nutzt die von den verteilten UPnP-Geräten
zur Verfügung gestellte, XML-Gerätebeschreibung, um anhand dieser Information ein User Interface zu generieren.
Das selbe Konzept wird beim mobilen GUI-Builder angewandt. Diese
Anwendung wurde jedoch ohne den Overhead des OSGi-Frameworks entwickelt und besteht aus einer Gateway-Anwendung am PC und einem mobilen Client am Smart Phone. Das Gateway ist ein eigenständiger UPnPControlpoint und bereitet die Informationen der gefundenen UPnP-Geräte
für den Client auf. Ist ein Smart Phone über Bluetooth zum Gateway verbunden, bekommt es die Gerätebeschreibungen übermittelt und generiert ein
GUI zur Fernsteuerung. Die bei der Interaktion durch den Benutzer erzeugten Befehle werden anschließend an das Gateway zurückgeschickt und von
diesem auf dem angesteuerten UPnP-Gerät ausführt. Diese Server/ClientArchitektur hat den Vorteil, dass speicherintensive Aufgaben wie das Parsen
von XML-Beschreibungen und die Datenhaltung, die am mobilen Endgerät
zu Performanceengpässen führen würden, auf den Gateway-Server ausgelagert werden können. Das mobile Endgerät muss sich nur um die Darstellung
und Kommunikation kümmern.
5.2
Implementierung - PC
Die Implementierung des GUI-Builders wird anhand folgender Bereiche erläutert:
• OSGi-spezifische Entwicklungsmerkmale, die die Bundle-Struktur und
die Anbindung an die UPnP-Welt beleuchten.
• Die Beschreibung des Systemaufbaus.
• Die Implementierung des GUI-Generators mit Hilfe des Supple Toolkits.
• Erweiterung der UPnP-Gerätespezifikation durch die Integration relevanter Zusatzinformationen für eine verbesserte GUI-Generierung.
5.2.1
Entwicklung mit OSGi
Ein OSGi-Bundle ist das Herzstück des GUI-Builders. Es ist nicht alleine
lauffähig, sondern muss innerhalb eines OSGi-Frameworks gestartet werden.
Jedes Bundle stellt hierfür eine Activator -Schnittstelle zur Verfügung. Diese
wird beim Starten des Framework aktiviert und kennzeichnet den Eintrittspunkt in das Programm. Darauf kann eine herkömmliche Java-Applikation
57
OSGi Core
UPnP
Device
Bundle
Misc.
Bundle
UPnP
Device
Bundle
> i am quite
sure you can't
read this yerk!
yak '06...
Basedriver Bundle
GUI Builder
PC
UPnP Network
UPnP Device
Mobile
GUI Builder
Bluetooth Gateway
Controlpoint
Abbildung 5.3: Systemaufbau mit beiden GUI-Builder Applikationen.
aufgebaut werden. Ein Vorteil in der Arbeit mit OSGI ist der Informationsaustausch zwischen den Bundles über eine zentrale Registrierungsstelle
im Framework. Dort können Services registriert werden, die zur Laufzeit
zur Verfügung stehen. Alle Bundles können sich als Listener für beliebige
Service-Klassen anmelden und werden über Zustandsänderungen wie etwa
die An- und Abmeldung von zugehörigen Objekten, informiert. OSGi enthält eine Reihe an vordefinierten Services. Dazu zählt eine einfach gehalten
UPnP-Geräteklasse mit Zugriff auf UPnP-Services, Aktionen und Zustandsvariablen. Mit Hilfe dieser OSGi-Serviceschnittstelle für UPnP meldet der
Domoware Basedriver alle gefundenen UPnP-Geräte an.
Eine weitere Eigenschaft von OSGi ist die Einbindung passiver Bundles,
die nichts anderes als globale Programmbibliotheken darstellen. Für alle aktiven und passiven Bundles können Klassen-spezifische Zugriffsrechte mittels einer Manifest-Datei konfiguriert werden. Die Modularität des OSGiKonzeptes erlaubt es, eine Softwareanwendung nicht mehr als starres System, sondern als eine Zusammenspiel mehrerer, dynamischer Komponenten
zu begreifen. Dementsprechend muss auch den Beziehungen zwischen den
58
Bundles durch eine implizite Startreihenfolge Rechnung getragen werden,
indem jedes Bundle die Abhängigkeiten in seinem Manifest definiert. Für
das lauffähige Setup des PC GUI-Builders sind folgende Bundles notwendig.
Sie wurde als Eclipse Plugin-Projekte angelegt und direkt mit dem integrierten OSGi-Framework Equinox entwickelt und getestet:
• Domoware Basedriver und Basedriver Extra Bundle: Das Gateway zwischen UPnP und OSGi.
• Controlpoint-Bundle: Eine Bibliothek mit Hilfsklassen, um über
angemeldete UPnP-Geräte informiert zu werden.
• UPnPUI Bundle: GUI-Builder Applikation für den Desktop.
5.2.2
Systemaufbau
Bei der Konzeption des Systemaufbaus wurde auf eine Trennung von Datenhaltung, Applikationslogik und GUI geachtet. Daraus ergibt sich folgende
Aufteilung der wichtigsten Zuständigkeitsbereiche:
• net.digidop.upnpui.business.data: Das Package ist für das Management der Applikationsdaten und die Kommunikation mit UPnP
zuständig.
• net.digidop.upnpui.gui: Darin sind alle GUI-relevanten Klassen enthalten.
• net.digidop.upnpui.business.generator: Der Generator kümmert
sich um die Aufbereitung der UPnP-Gerätedaten und leitet diese an
das Supple-Toolkit, das daraus ein User Interface rendert, weiter.
Datenhaltung
Um Informationen über im Netzwerk befindliche UPnP-Geräte zu erhalten
und um diese ansteuern zu können, wird ein UPnPSupervisor definiert. Er
überwacht die An- und Abmeldung der Geräte und speichert die Objekte
in einem zugehörigen UPnPDeviceManager, der für die Datenhaltung der
Geräte zuständig ist. Allfällige Änderungen werden an betroffene Komponenten wie das GUI weitergeleitet. Mit der Anmeldung eines Gerätes liegt
dessen funktionale Beschreibung in Form einer objektorientierten Baumstruktur vor. In einem UPnPDevice sind alle UPnPServices enthalten, die
wiederum Zugriff auf die UPnPAction-Objekte und UPnPStateVariables
erlauben. Leider ist das Traversieren des Baumes durch die OSGi-bedingte
UPnP-Servicedefinition nur in Richtung der Unterelemente möglich. Daher
wurde eine ActionPath-Datenstruktur definiert, die Referenzen zu allen Entitäten entlang eines bestimmten Aktionsweges enthält. Dies ist notwendig,
da ausgehend von einer UPnPAction, oft auch auf das Service oder das Device zurückgeschlossen werden muss. Um die Zustände der UPnP-Geräte
59
auch zur Laufzeit überwachen zu können, abonniert der Supervisor bei der
Anmeldung eines Gerätes alle verfügbaren Services. Der UPnP-Eventing
Mechanismus garantiert, dass alle Änderungen von ereignisorientierten Zustandsvariablen eines abonnierten Services an die Applikation übermittelt
werden.
GUI
Abbildung 5.4 zeigt das GUI der Applikation. Im Bereich Available Devices
werden alle entdeckten UPnP-Geräte gelistet. Durch Doppelklick wird der
Supple Interface-Generator angestoßen und ein Fenster mit einem konkreten
Rendering zur Steuerung des Gerätes erzeugt (siehe Abb.5.7 und 5.8). Das
aktive Gerät wird anschließend im unteren Bereich Active Devices gelistet
und kann kein zweites Mal instanziert werden. Durch das Schließen des Fensters oder den Klick auf den Namen in der Active Device-Liste kann das
erstellte User Interface des Gerätes wieder entfernt werden. Um ein schöneres UI-Design zu erzielen, wurde anstatt des standardisierten Java Swing
Look and Feels die externe GUI-Bibliothek JGoodies Looks5 eingesetzt.
In einer zukünftigen Version soll die Erstellung von User Interfaces aus
zusammengesetzten Teilen verschiedener UPnP-Geräte möglich sein. Damit
kann eine individualisierte Oberfläche zur Steuerung und Übersicht über
mehrere, in einem Szenario vernetzte Geräte realisiert werden. Es wäre etwa
denkbar, einen Lichtschalter dazu zu benutzen, gleichzeitig einen CD-Player
weiterzuschalten und die Temperatur einer UPnP-fähigen Heizung zu regulieren. In einem gemeinsamen GUI wären somit der Lichtschalter, die Anzeige des aktuellen Songtitels und die Raumtemperatur von Interesse. Die
Definition von Abläufen mit UPnP-fähiger Soft- und Hardware ist Teil des
Torem-Frameworks, das in [39] näher erläutert wird.
Der Informationsaustausch zwischen Applikationslogik und GUI ist über
eine Schnittstelle definiert, die Befehle in Form von Beans mit angehängten
Objekten vom Interface-Typ IRenderedEntities kapselt. Jedes Objekt, das
dieses Interface implementiert, kann übergeben werden. Das Konzept wird
vor allem zur Benachrichtigung und einheitlichen Darstellung von Objekten im GUI benötigt. Die Bean-Klasse kennt derzeit vier Befehle, die über
das Hinzufügen und Entfernen von UPnP-Geräten und die Erstellung und
Zerstörung des User Interfaces eines aktiven Gerätes informieren. Obwohl
alle Business-Komponenten Bean-Objekte an das Interface schicken können,
macht derzeit nur der UPnPDeviceManager davon Gebrauch, wenn Geräte
an- und abgemeldet werden.
5
JGoodies Looks - http://www.jgoodies.com/freeware/looks/
60
Abbildung 5.4: GUI-Builder PC Applikation.
5.2.3
GUI-Generator
Das Supple-Toolkit bildet die Schnittstelle zwischen diesem Datenmodell der
Geräte und dem konkreten Interface-Rendering und kümmert sich sowohl
um das Mapping von UPnP-Datentypen und Interface-Elementen als auch
um das Layout der GUI-Komponenten. Zusätzlich überwacht Supple die
Zustände des User Interfaces und leitet durch Interaktionen hervorgerufene
Änderungen an interessierte Komponenten der Applikationsschicht weiter.
Bevor der Rendering-Prozess eingeleitet werden kann, muss eine Informationsquelle in Form einer UPnP-Gerätebeschreibung ausgewertet werden.
UPnP arbeitet mit Aktionen und Zuständen, die als Parametern für Aktionen eingesetzt werden, um Geräte ansteuern zu können. Sehr oft sind UPnPAktionen Getter und Setter -Funktionen einer Zustandsvariable. Am Beispiel
einer Volume-Zustandsvariable für einen UPnP-fähigen Medienplayer wird
die Vorgehensweise erklärt. Folgender Quellcode zeigt einen Auszug aus dem
Dokument des Config-Services am Gerät, das die Volume-Variable eines Medienplayers und deren Aktionen GetVolume und SetVolume definiert:
1
2
3
4
5
6
7
8
9
10
11
< actionList >
< action >
< name > GetVolume </ name >
< argumentList >
< argument >
< name > Volume </ name >
< r e l a t e d S t a t e V a r i a bl e> Volume </ r e l a t e d S t a t e V a r i a b l e>
< direction > out </ direction >
</ argument >
</ argumentList >
</ action >
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
61
< action >
< name > SetVolume </ name >
< argumentList >
< argument >
< r e l a t e d S t a t e V a r i a bl e> Volume </ r e l a t e d S t a t e V a r i a b l e>
< direction > in </ direction >
</ argument >
</ argumentList >
</ action >
</ actionList >
< serviceStat eT a bl e >
< stateVariable sendEvents = " yes " >
< dataType > ui1 </ dataType >
< defaultValue > 255 </ defaultValue >
< allowedValu e Ra ng e >
< minimum >0 </ minimum >
< maximum > 255 </ maximum >
</ allowedValue Ra ng e >
</ stateVariable >
</ serviceStat eT a bl e >
Das <direction> Element eines Action-Parameters gibt an, ob die referenzierte Zustandsvariable als Ein- oder Ausgabeparameter gedacht ist.
Im <serviceStateTable> sind die Eigenschaften der Variable spezifiziert. Besondere Bedeutung kommt auch dem Attribut sendEvents zu, das angibt,
ob die Zustandsvariable Events aussendet. UPnP-Controlpoint Instanzen
können das übergeordneten Service abonnieren und werden so über die Änderungen der enthaltenen Zustandsvariablen informiert. Ein Nachteil dieses
UPnP-Mechanismusses ist, dass man bei mehreren Eventvariablen in einem
Service immer alle abonnieren muss.
Für das Interface-Rendering liefert diese funktionale Gerätebeschreibung
wichtige Informationen. Die Annahme ist, dass eine UPnP-Aktion den elementarsten, ausführbaren Teil eines Interfaces darstellt. Anhand der Eingangsparameter der Setter -Aktion kann auf die Eigenschaften des referenzierten Zustandes rückgeschlossen werden. Vor allem der Datentyp und der
Wertebereich bieten Anhaltspunkte zur Repräsentation des Parameters durch
ein Interface-Element.
Da eine Getter -Aktion die selbe Zustandsvariable wie die Setter -Aktion
referenziert, muss sie nicht extra im Interface aufscheinen. Der abgefragte
Wert der Zustandsvariable ist ohnehin schon im von der Setter-Aktion gerenderten GUI-Element ersichtlich. Der Zustand einer Variable am UPnP-Gerät
kann jedoch nicht nur durch die Interaktion mit einem einzigen Interface
sondern auch durch andere, im Netzwerk verteilte GUIs oder durch interne
Abläufe am Gerät selbst geändert werden. Ein häufiges Abfragen des Wertes
mit der Getter -Aktion ist kein gutes Mittel, um die Aktualität des Wertes
und damit die Konsistenz der Inhalte des Interfaces gewährleisten zu kön-
62
nen. Dazu ist der vorher erwähnte Event-Mechanismus, der jede Änderung
an interessierte Netzwerkteilnehmer bekannt gibt, besser geeignet.
Für den Fall, dass für eine Aktion mit Rückgabeparameter keine entgegengesetzte Setter -Aktion gefunden wird, muss diese trotzdem im Interface
kenntlich gemacht werden. Weil sie jedoch selbst keinen Eingabeparameter
definiert, der in ein Elemente umgewandelt werden könnte, muss die Aktion
mit einem Button zum Ausführen und im einfachsten Fall einem zusätzlichen
Textfeld zur Darstellung des Rückgabewertes repräsentiert werden.
UPnP erlaubt auch die Definition von Aktionen mit mehreren oder keinen Ein- oder Ausgabeparametern. Auch Kombinationen sind denkbar. Alleine aus dem Kontext der Gerätebeschreibung kann aber kein Bezug zur
konkreten Auslegung im Interface abgeleitet werden. Ein Beispiel hierfür ist
eine Aktion mit zwei Integer-Parametern. Ohne die Aufgabe des Gerätes zu
verstehen, kann keine genaue Angabe über die Auslegung der Bedienung getroffen werden. Es wäre beispielsweise denkbar diese Aktion als 2D-Matrix
mit diskreten Werten aufzufassen und in equidistanten Abständen einen
Knopf für jede der Kombinationen im Interface zu zeichnen. Genauso gut
kann es aber auch möglich sein, dass zwei Slider eine bessere Repräsentation
darstellen. Darüber hinaus ist nicht bekannt, ob die Aktion nur zur Konfiguration von Einstellungen dient und die Aktion mit einem Bestätigungsbutton ähnlich einem Formular ausgeführt werden sollte. Oder aber ob sie,
sobald das Interface-Element manipuliert wird, ohne Bestätigung ausgeführt
werden soll.
Ideen um semantische Probleme dieser Art lösen zu können, werden ansatzweise in Kapitel 5.2.4 erläutert und anhand einiger Regeln demonstriert.
Das Konzept der UPnP-Zustandsvariablen kommt Supple sehr entgegen.
Der Toolkit benötigt für die Generierung des Interfaces keine Beschreibung
konkreter Interface-Elemente, sondern verwendet abstrakte Zustandsvariablen, die neben der Spezifikation des Datentyps und möglichen Einschränkungen des Wertebereichs auch nach einem Bean-Objekt zur Speicherung
des Zustandes verlangen. Erst beim Rendering-Prozess werden die Zustandsvariablen anhand ihrer Eigenschaften in Elemente wie Buttons, Slider und
Eingabefelder umgewandelt. Dabei ist eine fixe Zuweisung zwischen Zustand
und Interface-Element nicht gegeben. Vielmehr schränken deren Eigenschaften die möglichen Render-Ergebnisse ein. Der Datentyp ist zusammen mit
den wertebedingten Einschränkungen der Zustandsvariable und den Eigenschaften des Darstellungsgerätes das entscheidende Kriterium zur Generierung des konkreten Interface-Elements. Am Beispiel einer Integer-Variable
mit einer ganzzahligen Einschränkung von 0 − 5 werden Ergebnisse der dynamische Elementauswahl von Supple gezeigt. Alle Varianten in Abb.5.5
stellen legale Repräsentationen des Eingangsparameters der UPnP-Aktion
SetFanLevel dar.
63
<action>
<name>SetFanlevel</name>
<argumentList><argument>
<name>FanArg</name>
<relatedStateVariable>Fanlevel
</relatedStateVariable>
<direction>in</direction>
</argument></argumentList>
</action>
...
<stateVariable sendEvents="yes">
<name>Fanlevel</name>
<dataType>ui1</dataType>
<defaultValue>0</defaultValue>
<allowedValueRange>
<minimum>0</minimum>
<maximum>5</maximum>
</allowedValueRange>
</stateVariable>
Abbildung 5.5: Verschiedene Rendering einer Supple-Zustandsvariable mit
Integer-Datentyp und ganzzahligem Wertebereich von 0 − 5. Die Eigenschaften werden direkt aus der XML-Beschreibung einer UPnP-Aktion, deren Parameter auf eine UPnP-Zustandsvariable verweist, übernommen.
Datentyp
Der Datentyp der verknüpften UPnP-Zustandsvariable muss in einen JavaBasisdatentyp umgewandelt werden und anschließend als Supple-Datentyp
der Instanz einer Supple-Zustandsvariable StateVar mitgegeben wird. OSGi
selbst stellt für die erste Konvertierung mit dem UPnPStateVariable-Interface eine entsprechende Methode getJavaDataType() zur Verfügung. Die
Konvertierung in den entsprechenden Supple-Datentyp funktioniert ebenfalls nach einem einfachen Mapping-Prinzip. Die Tabelle 5.2.3 zeigt die Konvertierungsschritte.
Bean-Datenstruktur
Zur Speicherung des Variablenzustandes wird ein Bean-Objekt benötigt. Das
Objekt muss eine Membervariable entsprechend dem Datentyp und Namen
des Zustandes enthalten und zusätzlich eine Getter und eine Setter -Methode
zur Manipulation des Wertes definieren. Da der Name der Membervariable nicht im vorhinein bekannt ist, kann keine statische Bean-Klasse herangezogen werden. Für diese Aufgabe wird JavAssist 6 verwendet. Die Bytecode Engineering-Bibliothek ermöglicht die Erstellung und Instanzierung
von Java Klassen zur Laufzeit durch String-basierte Spezifikation auf Ebene
des Sourcecodes. Wenn das Bean-Objekt darüber hinaus für die Zustandsüberwachung ein Objekt der Klasse java.beans.PropertyChangeSupport
mitführt, garantiert Supple die Benachrichtigung aller, an einer Variable interessierten, Komponenten und führt in entgegengesetzter Richtung auch
Updates des Interfaces bei Manipulation des Bean-Objektes aus.
6
JavAssist - http://www.csg.is.titech.ac.jp/˜chiba/javassist/
64
UPnP datatype
ui1, ui2, ui4
i1, i2, i4, int
r4, r8, float
Java datatype
java.lang.Integer, int
java.lang.Integer, int
java.lang.Float, float
boolean
java.lang.Boolean or
boolean
java.lang.String
string
enum (as Xml-based
string)
java.util.Collection
additional formats for
time, date and url
any pre-defined
Supple datatype
IntegerTypeImpl
IntegerTypeImpl
IntegerTypeImpl
(not exact)
BooleanTypeImpl
StringTypeImpl,
TextTypeImpl
StringTypeImpl
with
collection
constraints
additional formats
for date and image
Tabelle 5.1: Mapping zwischen UPnP-, Java- und Supple-Datentypen.
ActiveDevice
1
n
Supple
Application
ActionPath
Bean
UIGenerator
Supple
Renderer
Container
TypeImpl
1
n
UIObject
StringTypeImpl
Renderer
Renderer
StateVarImpl
SimpleValue
Type
Abbildung 5.6: GUI-Builder – Klassendiagramm des Rendering-Prozesses.
Rendering-Prozess
Abb. 5.6 bietet einen Überblick über die im Rendering-Prozess involvierten
Klassen. Der UIGenerator bereitet die Informationen eines angeforderten
UPnP-Gerätes für den anschließenden Rendering-Vorgang mit Supple auf.
Dazu wird mit den UI-relevanten Supple Klassen7 eine hierarchische Struktur aus Containern und Komponenten ähnlich dem Java Swing Modell8 auf7
8
Supple Java Doc - http://www.cs.washington.edu/ai/supple/docs/
Java Foundation Classes und Swing - http://java.sun.com/products/jfc/
65
gebaut. Die Zustandsvariablen der Klasse StateVarImpl sind gleichzeitig
Objekte des Interfaces UiObject, die mittels ContainerTypeImpl zu Gruppierungen zusammengefasst werden können. Diese Container können wiederum in ein UiObject verpackt werden, womit der Kreis geschlossen ist.
Beim Traversieren eines UPnP-Gerätes werden alle Services und Aktionen
als Container definiert. Die Parameter einer Aktion hingegen, die bekanntlich
Zustandsvariablen eines Services referenzieren, werden mit der definierten
Klasse UiObjectCreator als StateVarImpl instanziert und dem Container
der Aktion hinzugefügt.
Ein finales UiObject, das die Verschachtelung der Komponenten und
Container enthält wird in einer SuppleApplication gekapselt und zuletzt
einer Instanz des Interfaces Renderer übergeben. Supple definiert mit HtmlRenderer, AwtRenderer und SwingRenderer für drei Plattformen konkrete
Renderer, die über globale DeviceProperties gesetzt werden können. Alle
drei Plattform können auf eine vollständige Bibliothek aller plattformspezifischen Interface-Objekte im Package edu.washington.cs.supple.wlib
zurückgreifen, um das Interface zu rendern. Die Auswahl und Positionierung
der Interface-Elemente wird anschließend von einer Solver-Klasse anhand
des in Kapitel 4.5.3 beschriebenen Optimierungsverfahrens vorgenommen.
Nach Abschluss des Rendering-Prozesses wird die SuppleApplication und
das für jede Aktion generierte ActionPath-Objekt in einem ActiveDevice
gespeichert. Abbildung 5.7 zeigt das Ergebnis des Rendering-Prozesses für
einen UPnP-fähigen Videostreaming-Server.
UPnP-Kommunikation
Damit Interaktionen im Interface in Steuerbefehle für die im Netzwerk verteilten UPnP-Geräten umgesetzt werden können, wird das ActiveDevice für
alle StateVarImpl-Objekte als PropertyChangeListener registriert. Wird
ein Interface-Element vom Benutzer manipuliert, versucht der PC GUIBuilder diese Aktion an das entsprechende Gerät weiterzuleiten. Dazu wird
ein Dictionary-Objekt mit Schlüssel-Wert Paaren erzeugt, das mit allen
Eingangsparameternamen der auszuführenden Aktion und den Werten der
zugehörigen Supple-Zustandsvariable befüllt wird. Damit ist auch für den
Fall vorgesorgt, dass eine Aktion, die mehrere Eingabeparameter besitzt,
auch bei der Manipulation nur eines entsprechenden Interface-Elements ausgeführt werden kann. Der untenstehende Quellcode zeigt den Vorgang in der
ActiveDevice-Methode executeAction():
1
2
3
4
public void executeAction ( ActionPath actionPath ) {
Dictionary arguments = new Hashtable ();
UPnPAction action = actionPath . getAction ();
Map < StateVar , String > stateVarToAr g Na me = actionPath . getMap ();
5
6
7
for ( StateVar suppleVar : stateVarToA rg Na m e . keySet ()) {
Object value = suppleVar . getValue ();
(a)
66
(b)
Abbildung 5.7: Rendering eines UPnP-fähigen Videostreaming-Servers.
Das originale User Interface der Applikation ist in Abb. (a) ersichtlich.
Abb. (b) zeigt das automatisierte Rendering-Ergebnis. Im Interface können
der Treiber der Webcam (SetCaptureDevice), die Broadcast-IP (SetAddress),
der Port (SetPort ) und die TimeToLive (SetTTL) Zeit gesetzt werden. Mit
Start und Stop kann der Streaming-Server mit Vorschaubild gesteuert werden.
8
String argName = stateVarToAr g Na me . get ( suppleVar );
arg . put ( argName , value );
9
10
}
action . invoke ( arguments );
11
12
}
5.2.4
UI-Erweiterungen
Da UPnP keine native Unterstützung zur Definition von grafischen Oberflächen bietet und die Gerätebeschreibung nicht ausreicht, um die vielschichtigen Vorgänge eines User Interfaces zu modellieren, muss der Standard um
semantische Zusatzinformation erweitert werden. Im Rahmen dieser Arbeit
wurden mehrere Ideen für eine Erweiterung des Prototyps in Erwägung gezogen. Eine davon wurde im Zuge der Implementierung mit den Geräten
getestet.
• Geräteklassen: UPnP definieren einheitliche Standards für Geräte-
67
klassen, damit herstellerübergreifende Kommunikation zwischen verschiedenen Produkten ermöglicht werden kann. Diese Strukturierung
könnte auch für die Auslegung der User Interface genutzt werden, weil
mit der Klasse des Gerätes auch dessen Funktionalität bekannt ist. Mit
vordefinierten Interface-Elementen und dem Wissen über die semantische Bedeutung einer Interaktion könnte für eine Instanz der Klasse
Mediaplayer, unabhängig von der Implementierung des Gerätes, ein
optimales User Interface präsentiert werden. Dieser Ansatz setzt allerdings voraus, dass alle Geräteklassen im vorhinein bekannt sind und die
Ressourcen zu einer Klasse außerhalb der Geräte gespeichert werden.
Wird ein neues Gerät gefunden, das nicht zugeordnet werden kann,
können keine Zusatzinformationen für das zu generierende Interface
abgeleitet werden.
• Kohärenzen: Ein weiterer Ansatz wäre, Funktionselemente in ähnlichen Geräten zu kategorisieren und diese Information für die Auswahl
vordefinierter Interface-Elemente zu nutzen. Der Interface-Generator
könnte mit einem wissensbasierten System gekoppelt werden, das über
die Zusammengehörigkeit (Kohärenz) der Funktionselemente in Form
eines vordefinierten Wissensschatzes verfügt. Am Beispiel der Abspielelemente eines Medienplayers sind beispielsweise Definitionen für die
Elemente Play, Pause, Stop, Vor und Zurück möglich. So könnte für
den Play-Button im Bezug zum Stop-Button ein Kohärenzwert von 10
definiert werden, der ein engere Bindung als ein Wert 5 im Zusammenhang mit dem Vor -Knopf signalisiert. Mit den Kohärenzwerten wird
ein Beziehungsnetzwerk aufgespannt, das für das Layout der Komponenten von Bedeutung ist. Dieses Konzept birgt großes Potential,
verlangt jedoch nach ausführlicheren Recherchen als dies im Rahmen
der vorliegenden Arbeit möglich war.
• Regelbasierte Beschreibung: Im einfachsten Fall sind in der Beschreibung eines Gerätes alle nötigen Informationen zur Darstellung
enthalten. Dazu zählen neben grafischen Ressourcen beispielsweise in
Form von Icons auch Layout-Informationen. Damit aber nicht zusätzlich zur funktionalen Spezifikation des Gerätes auch noch eine komplette Interface-Definition festgelegt werden muss, kann ein System
zum Einsatz kommen, das anhand weniger Regeln Informationen über
den Zusammenhang und die Bedeutung zwischen einzelnen Gerätefunktionen definiert. Dieser Ansatz wird im Anschluss anhand zweier
Regeln demonstriert.
Um den UPnP-Gerätestandard mit einem Interface-relevanten Regelwerk erweitern zu können, wurde folgendes Konzept umgesetzt: UPnP definiert die optionale Angabe einer Präsentations-URL in der XML-basierten
Gerätebeschreibung, die eine optionale Referenz zu einer HTML-basierten
68
Präsentationsseite beinhaltet [38]. Es bleibt dem Hersteller überlassen, wie
er diese Präsentationsseite gestaltet und mit welchen Inhalten er sie ausstattet. Eine URL zu der Homepage des Produktes ist dabei ebenso denkbar, wie
ein lokaler Verweis auf ein HTML-Frontend am Geräte selbst, das Auskunft
über Zustände gibt und unter Umständen auch die Steuerung erlaubt.
Dieser Ansatz hat jedoch zwei entscheidende Nachteile. Erstens wird nur
der Webbrowser als Plattform zur Präsentation von Geräteinhalten propagiert. Ohne fortgeschrittene Web-Technologien ist dieses Modell aber auf das
Request/Response-Prinzip reduziert, das kein automatisches Neuladen von
Seiteninhalten bei Zustandsänderungen erlaubt. Auch die Anzahl der Interaktionselemente ist im Vergleich zu den Komponenten einer GUI-Bibliothek
begrenzt. Zweitens steht dieses Konzept in starkem Kontrast zum Entwurf
der generischen Gerätesteuerung, wenn für das User Interface kein einheitlicher Standard gefunden werden kann.
Die Präsentations-URL wird daher zum Transport UI-spezifischer Regeln
in Form einer XML-Beschreibung genutzt. Das Regelwerk dient zur Unterstützung des GUI-Generators, der das User Interface sonst nur anhand der
funktionalen Gerätebeschreibung, die Aktionen mit Zustandsvariablen als
Ein- und Ausgabeparameter definiert, rendern kann. Für den Anfang werden zwei Regeln definiert:
• Gruppierung: Mit einer Gruppierungen kann die Anordnungsreihenfolge von UPnP-Aktionen und deren Interface-Elementen dezidiert gesetzt werden. Sie sind vor allem dann eine Hilfe, wenn semantisch
wichtige Zusammenhänge durch Platzierung der Elemente ausgedrückt
werden sollen. Ein Beispiel dafür ist die Anordnung der Knöpfe eines
Medienplayers. Der Zurück -Button sollte immer vor dem VorwärtsButton liegen.
• Datenquelle: Da in UPnP die Definition der Ein- und Ausgabeparametern einer Aktion auf primäre Datentypen beschränkt ist, können
vorerst keine Interface-Elemente gerendert werden, die sowohl dynamische Informationen vom Gerät abfragen als auch senden können. Ein
Beispiel hierfür ist die Auswahlliste: Bei einem Medienplayer muss zuerst eine Liste aller verfügbaren Titel im User Interface aufscheinen,
bevor der Benutzer einen Song auswählen und abspielen kann. Das Element wird daher aus zwei Aktionen zusammengesetzt. Eine GetPlayList-Aktion, die eine Liste der Titel liefert und eine SetSong-Aktion,
die den Titel des aktuellen Songs anwählt. Als Datenquelle der SetSong-Aktion wird dementsprechend erstere festgelegt.
Die Abbildungen 5.8(a) und 5.8(b) zeigen die Auswirkungen der Regeln auf das Interface-Rendering. Der untenstehende Quellcode gibt Aufschluss über die Struktur der XML-Datei mit beiden Regeldefinitionen und
Informationen, die in Zukunft ausgewertet werden könnten. Dazu zählen die
(a) Regeln deaktiviert
69
(b) Regeln aktiviert
Abbildung 5.8: Renderings eines Remote-Interfaces zur Steuerung von
Winamp mit und ohne zusätzliche Regeldefinitionen in der UPnPPräsentationsschicht. Die Gruppenregel kommt bei der Anordnung der Controls zu tragen. Die Definition einer Datenquelle führt dazu, dass die Aktionen GetPlayList und SetSong zu einer Auswahlliste zusammengeführt werden.
Definition von Icons und der Vorschlag eines bestimmten UI-Elementtyps
für das Rendering. Letzteres ist vor allem dann von Interesse, wenn mehrere
Interface-Elemente zur Darstellung des Datentyps in Frage kämen. Der ganzzahlige Wertebereich einer Zustandsvariable Volume könnte etwa mit einem
vertikalen und horizontalen Slider, einer Auswahlliste und einem SpinnerWidget gleich mehrfach grafisch ausgelegt werden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<? xml version = " 1.0 " ? >
< upnpui >
< groupings >
< group name = " Controls " type = " order " description = " " / >
</ groupings >
< actions >
< action name = " SetSong " type = " " >
< datasource name = " GetPlayList " type = " enum " / >
</ action >
< action name = " Start " type = " setter " >
< icon path = " start . gif " / >
< group name = " Controls " id = " 2 " / >
</ action >
< action name = " Stop " type = " setter " >
< icon path = " stop . gif " / >
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
70
</ action >
< action name = " Pause " type = " setter " >
</ action >
< action name = " Prev " type = " setter " >
</ action >
< action name = " Next " type = " setter " >
</ action >
< action name = " SetVolume " type = " setter " >
< widget type = " VerticalSlider " >
</ action >
</ actions >
</ upnpui >
Enumerationsdatentyp:
Ein UPnP-spezifisches Problem ist das Fehlen eines Enumerationsdatentyps,
der unter anderem für den Rückgabeparameter der GetPlayList-Aktion benötigt würde. Um dennoch eine Liste übertragen zu können, wird ein StringDatentyp aus mehreren XML-Elementen zusammengesetzt, der anschließend
am Empfänger wieder auseinander genommen werden kann. Dafür wurde
folgendes, einfache XML-Format festgelegt:
1
2
3
4
5
< t_list >
< element value = " Dave Matthews Band - Satellite " / >
< element value = " Incubus - Echo " / >
< element value = " Joss Stone - I had a dream " / >
</ t_list >
5.3
Implementierung - Smart Phone
Der Mobile GUI-Builder ist eine in der Funktionalität reduzierte Anwendung
zur Fernsteuerung von UPnP-Geräten. Eine Client-Server Architektur ermöglicht die Kommunikation zwischen einem PC-Gateway und einem Smart
Phone via Bluetooth. Die Gateway-Applikation implementiert die UPnPControlpoint Funktionalität und gibt Informationen über die gefundenen
Geräte an das Smart Phone weiter. Dieses generiert aus den funktionalen
Beschreibungen ein Java-basiertes Interface und sendet bei einer Interaktion
vordefinierte Steuerbefehle an das Gateway zurück. Dort werden die Befehle
ausgewertet, in gültige UPnP-Aktionsaufrufe konvertiert und ausgeführt.
5.3.1
71
Entwicklung mobiler Java-Anwendungen
Ähnlich der Java SE Plattform9 für PC-Applikationen, gibt es für die Entwicklung von Anwendungen auf mobilen Plattformen ein spezialisiertes und
im Umfang reduziertes Set an Technologien mit dem Namen J2ME10 . Im
Gegensatz zu Java SE ist J2ME jedoch nur ein Überbegriff für Konfigurationen, Profile und optionalen Packages, die vom Standardisierungskomitee
Java Community Process(JCP) vorgegeben werden und als Java Specification Requests(JSR) den Weg in eine allgemein gültige Spezifikation finden.
J2ME-Technologien werden als JSRs mit einer Nummer versehen. Bei aktuellen Entwicklung für Mobiltelefone muss vor allem auf die Kompatibilität des Endgerätes mit den Spezifikationen CLDC 1.1 (Connected, Limited
Device Discovery - JSR 139) und MIDP 2.0 (Mobile Information Device
Profile - JSR118) geachtet werden. Zusammen mit MMAPI (Mobile Media
API ) und WMA (Wireless Messaging API ) bilden diese Technologien den
JSR 185-Stack mit Namen Java Technology for Wireless Industry 11 , der die
Grundvoraussetzung an jedes J2ME-fähige Mobiltelefon stellt. Viele zusätzliche Funktionalitäten wie etwa die Bluetooth-Unterstützung (BTAPI - JSR
82), werden ebenfalls in eigenen Spezifikationen festgehalten, die von den
Geräten der Elektronikherstellern unterstützt werden können.
Softwareunterstützung
Für die Entwicklung von J2ME-Anwendungen ist eine Reihe an nützlicher Open Source-Software verfügbar. Das Wireless Toolkit (WTK)12 ist
eine einfach gehaltene Sammlung an Softwarekomponenten zur Entwicklung
von J2ME-Applikationen. Neben einem Compiler, den API-Spezifikationen
und zahlreichen Beispielanwendungen ist auch ein Simulator enthalten. Das
WTK ist ein solides Werkzeug um erstellte Applikationen am PC zu testen.
Da die Umsetzung der Java-Spezifikationen am Mobiltelefon jedoch dem Gerätehersteller überlassen ist, weicht das konkrete Erscheinungsbild oft vom
Look and Feel des Simulators ab. Um in der bekannten Java-Entwicklungsumgebung Eclipse arbeiten zu können, kann das Plugin EclipseME 13 verwendet werden, das die Schnittstelle zwischen dem WTK und Eclipse bildet. Da die Ressourcen mobiler Endgeräte meist begrenzt sind, muss auf
speicheroptimierte Programmierung geachtet werden. Um unnötigen Programmoverhead automatisch zu entfernen kann ein sogenannter Obfuscator
eingesetzt werden. EclipseME bietet Integrationsmöglichkeiten für externe
9
Java Platform, Standard Edition - http://java.sun.com/javase/
J2ME - Java Technology - http://java.sun.com/j2me/
http://developers.sun.com/techtopics/mobility/getstart/
11
Java Technology for Wireless Industry (JSR 185) - http://developers.sun.com/
techtopics/mobility/jtwi/
12
Sun Java Wireless Toolkit (WTK) - http://java.sun.com/products/sjwtoolkit/
13
EclipseME - http://eclipseme.org/
10
72
Application
State
UPnP
Controller
Discovery
Agent
Network
Supervisor
hierarchical
UPnP Data
Model
1
n
EndPoint
Connection
Handler
Sender
Reader
Abbildung 5.9: Das Klassendiagramm der wichtigsten Komponenten des
Gateways und des Clients. Da sowohl die Anwendung am PC als auch am
Smart Phone mit Java entwickelt wurde, können viele Klassen auf beiden
Plattformen eingesetzt werden.
Obfuscator. Für die Entwicklung des mobilen GUI-Builders kam ProGuard 14
zum Einsatz.
Auch wenn die Kombination dieser Software-Tools die Entwicklung mobiler Anwendungen vereinfacht, so bleiben trotzdem einige Unannehmlichkeiten bestehen. Das Testen der Client-Server Kommunikation ist im Zusammenhang mit dem Simulator des WTK nicht möglich, da dieser keinen
Zugriff auf die Bluetooth-Treiber des PCs hat. Daher muss das Programm
mit jeder Änderung zum Testen auf das Smart Phone übertragen werden.
Auch das Debuggen gestaltet sich bei der mobilen Anwendung als schwierig.
Da naturgemäß keine Konsole zur Verfügung steht und kaum aussagekräftige
Fehlermeldung an das überliegende Betriebssystem weitergegeben werden,
ist jede Fehlersuche mit vermehrtem Aufwand verbunden.
5.3.2
Gateway
Da die Java-Technologien J2SE uns dessen Derivat J2ME viele Gemeinsamkeiten aufweisen, liegt es nahe den Systemaufbau und das Kommunikationsprotokoll für das Gateway und den Client einheitlich zu gestalten (siehe
Abbildung 5.9).
Die Implementierung des Gateway ist in folgende Bereiche unterteilt:
• net.digidop.bt.network und net.digidop.bt.network.endpoint:
Netzwerkkomponenten und Bluetooth-Kommunikation.
• net.digidop.statemachine: Das Zustandsmodell der Applikation.
• net.digidop.upnp: Datenhaltung der UPnP-Geräte.
14
Pro Guard Obfuscator - http://proguard.sourceforge.net/
73
Netzwerk
Die Entwicklung von Java-Anwendungen mit Bluetooth-Unterstützung ist
noch im Anfangsstadium. Da es keine native Java-Unterstützung für Bluetooth-Hardware gibt, kommt Open Source Software zur Anwendung. BlueCove 15 , eine Bibliothek zur Java Bluetooth Kommunikation mit dem PC
setzt Teile der JSR82 -Spezifikation um und greift über den Microsoft Bluetooth-Stack direkt auf die Hardware zu16 . Für den Mobile GUI-Builder wird
das Bluetooth-Profil Serial Port Profile, das eine serielle Schnittstelle simuliert, eingesetzt.
Die Klasse Supervisor ist das Herzstück der Bluetooth-Kommunikation.
Sie übernimmt die Initialisierung, die Konfiguration und die Wartung der
Netzwerkverbindungen. Durch die Initialisierung zweier Objekte der Klassen DeviceInquiry und ConnectionHandler wird anfangs nach anderen
Kommunikationsteilnehmern in Funkreichweite gesucht und ein Server für
spätere Verbindungsanfragen eingerichtet. Der Server ist für die Kommunikation mit mehreren Mobile-Clients ausgelegt, jedoch noch nicht in der
Praxis getestet.
Beim Starten des Servers akquiriert die Klasse DeviceInquiry ein Singleton 17 -Objekt DiscoveryAgent. Dieser Agent instanziert eine ConnectionHandler-Klasse, die während der Laufzeit des Servers auf eingehende Verbindungsanfragen wartet. Bei einem erfolgreichen Verbindungsaufbau werden
zwei Threads (Reader und Sender) gestartet und in einem Endpoint gespeichert werden. Der Supervisor verwaltet alle Endpoints und gibt Befehle,
die nicht den Auf- und Abbau der Verbindung betreffen, an die Applikation
weiter. Ein- und ausgehende Nachrichten werden in Form von Packets gekapselt, die sowohl den Inhalt der Nachricht, als auch Informationen über
den Sender und einen verbindungsspezifischen Befehl (SIGNAL_TERMINATE,
SIGNAL_HANDSHAKE,SIGNAL_MESSAGE) enthalten.
Modellierung des Applikationszustand
Um die verschiedenen Zustände der einzelnen Clients modellieren zu können,
wurde ein einfach gehaltenes Zustandsmodell eingeführt. Bei einer Änderung
werden alle Komponenten die das StateListener Interface implementieren
und sich bei der Klasse ApplicationState registrieren, über die Zustandsüberführung informiert. Bei der Anmeldung eines neuen Client wird ein
neuer Zustand angelegt und die Klasse UPnPAccessPoint reagiert, indem
sie dem Client die Daten aller UPnP-Geräte sendet.
15
Java Bluetooth-Bibliothek - BlueCove http://sourceforge.net/projects/bluecove/
Eine Anleitung für das Arbeiten mit BlueCove findet sich unter
http://www.benhui.net/modules.php?name=Bluetooth&page=Connect PC Phone Part 1.
html
17
Singleton ist ein objektorientiertes Muster, das von einer Klasse nur eine konkrete
Instanzierung erlaubt.
16
74
Datenhaltung
Ebenso wie beim GUI-Builder für den PC werden die Informationen der
XML-Gerätebeschreibung in einer hierarchisch Form zusammengefasst. Die
Datenhaltung am Gateway wird in einer Baumstruktur speichert. Dieser
kann ausgehend von einem Node-Elementen in Richtungen der Kinder und
der Eltern-Elemente traversiert werden. Das Gateway transformiert diese
XML-Daten in eine flacherer Struktur, die die Verschachtelungstiefe der Elemente zu reduzieren versucht und sendet sie als Zeichenkette an den Client.
Dieser Vorverarbeitungsschritt ist notwendig, da die beschränkte Rechenleistung und Speicherkapazität des mobilen Endgeräten beschränkt ist. Der
folgende Quellcode zeigt die transformierte Beschreibung im Gegensatz zur
originalen Struktur (siehe Abs. 5.2.3).
1
2
3
4
5
6
7
8
9
10
11
12
< service serviceId = " urn:schemas - upnp - o r g : s e r v i c e I d : t e m p : 1"
serviceType = " urn:schemas - upnp - org:service : te mp : 1 " >
< stateVariable name = " Volume " sendEvents = " yes "
dataType = " ui1 " value = " 200 " / >
< stateVariable name = " Result " sendEvents = " no "
dataType = " boolean " value = " " / >
< action name = " SetVolume " >
< argument name = " Vol " direction = " in " relatedState = " Volume " / >
< argument name = " Re " direction = " out " relatedState = " Result " / >
</ action >
...
</ service >
5.3.3
Mobile Client
Bei der Entwicklung und den Tests kam ein Nokia 6600 18 -Mobiltelefon zum
Einsatz. Bis auf wenige Ausnahmen gleicht der Systemaufbau den Angaben
des Server-Gateways (siehe Abb. 5.9 der Server-Architektur).
XML-Parser
Die vom Gateway an den Mobile Client übertragenen Geräteinformationen
müssen mit einem, speziell für leistungsschwache Geräte ausgelegten, XMLParser ausgelesen werden. Für diese Aufgabe wird kXML2 19 , eine kleine
XML Pullparsing-Bibliothek, verwendet.
GUI
Die Applikation ist aufgrund gerätebedingter Verzögerungen beim Aufbau
der Bluetooth-Verbindung langsam in der Initialisierung. Es kann einige Zeit
18
Nokia 6600 Smart Phone - http://www.nokia.at/german/phones/phone models/6600/
index.html
19
XML Parsing kXML2 - http://kxml.sourceforge.net/
75
dauern bis am Smart Phone eine Anfrage an den Benutzer für die Erlaubnis
zum Verbindungsaufbau erscheint. Wird diese bestätigt, werden die UPnPGeräteinformationen vom Gateway übertragen und am Smart Phone dargestellt.
Die Menüführung wurde in folgender Hierarchie festgehalten: Geräteliste
> Aktionsliste > Parameterliste (siehe Abb. 5.10). Durch Anwahl eines Gerätes werden die enthaltenen Aktionen aufgelistet. Durch erneutes Klicken
kommt man in das Parametermenü der Aktion. Dort können die Werte für
die auszuführende Aktion gesetzt werden. Das Setzen von Boolean-Werten,
beispielsweise Licht an/aus, führt direkt zum Ausführen der Aktion. Sie können direkt mit einer Checkbox angewählt werden. Float, Integer und String
werden als Input Feld dargestellt und müssen erst mit einem Send-Befehl aus
dem Optionen-Menü bestätigt werden. Der Back -Befehl führt in das jeweils
vorherige Menü. Der Exit-Befehl meldet den Client beim Server ab. Sofern
das Gateway aktiviert bleibt, kann sich das mobile Gerät jedoch jederzeit
neu verbinden.
Um das Look and Feel der Anwendung verbessern zu können, wurde
die Grafikbibliothek J2ME Polish 20 verwendet. Mit Hilfe von Auszeichnungen im Java-Quellcode, externen CSS-Layoutdefinitionen und Grafiken kann
das Polish Building-Tool eine visuell ansprechende Version der Applikation
compilieren, die immer noch dem mobilen Java-Standard MIDP 2.0 entspricht. Dabei berücksichtigt die Bibliothek auch produktspezifische Eigenschaften eines mobilen Endgerätes durch vordefinierte Hersteller-Profile für
Firmen wie Nokia und Sony-Ericsson. Die Abbildung 5.11 zeigt das neu
gestaltete User Interface anhand der Geräteliste und der Aktionsliste, das
im Vergleich zu der vorher präsentierten J2ME-Benutzeroberfläche (siehe
Abb. 5.10) deutlich benutzerfreundlicher ist.
20
J2ME Polish - http://www.j2mepolish.org/
(a)
76
(b)
Abbildung 5.10: Der Mobile GUI-Builder im WTK Simulator. Die Abbildungen zeigen die Geräteliste (a) und die Parameterliste (b).
(a)
77
(b)
Abbildung 5.11: Der Mobile GUI-Builder am Nokia 6600 mit J2ME-Polish
Grafikbibliothek. Die Abbildungen zeigen die Geräteliste (a) und die Aktionsauswahl (b) eines Medienplayers.
Kapitel 6
Fazit
Anlass für die Idee der vorliegenden Arbeit war die Erkenntnis, dass vernetzte Strukturen, die in Form von computerisierter Geräte in beinahe alle
Bereiche unserer Lebenswelt eindringen, bereits heute allgegenwärtig sind.
Mit lokalen und globalen Funknetzwerken wie Bluetooth, WLAN, und den
Mobiltelefonie-Standards sind eine Vielzahl neuer Dienste möglich, die bis
vor einigen Jahren nicht in dieser Form denkbar gewesen wären. Die zugehörigen Technologien in Form von Geräten wie Smart Phones, PDAs, Laptops
und zahlreicher Unterhaltungselektronik finden sich in vielen Haushalten.
Es wird aller Voraussicht nach nicht mehr lange dauern, bis Haustechnik
wie beispielsweise Heizung und Elektroinstallationen auch an einem lokalen Netzwerk angeschlossen sein wird. In diesem Zusammenhang stellt sich
die Frage nach dem Sinn dieser Vernetzung [33]. Die Vision, dass die Wärmeregulierung eines Toasters per Netzwerk vorgenommen werden kann, hat
wenig praktische Relevanz um Tätigkeiten im Haushalt zu vereinfachen. Im
Gegensatz dazu wäre es jedoch wünschenswert die Steuerung der gesamten
Unterhaltungselektronik eines Haushaltes in einem Mobiltelefon zu vereinen und so die Fernbedienungen der einzelnen Geräte wie TV-Gerät und
Stereoanlage ersetzen zu können.
Solche Szenarien werden erst dann zur Realität, wenn nach der technischen Machbarkeit von Netzwerken auch die Vernetzungen von Anwendungen in die Konzeptualisierung kommender Technologien miteinbezogen wird.
Solange es von Seiten der Hersteller nur wenige Anstrengungen in Richtung
gemeinsamer Standards für verteilte Geräte gibt, bleibt für die Forschung
ein umso größeres Betätigungsfeld.
Die vernetzte Service-Plattform UPnP ist ein Ansatz in die richtige
Richtung. Wenngleich die Technologie dem Endkunden noch nicht geläufig ist und bisher nur in wenigen Mediengeräten integriert ist, so birgt sie
doch großes Potential durch die Standardisierung einer einheitlichen Serviceschnittstelle.
78
KAPITEL 6. FAZIT
6.1
79
Erreichte Ziele
Anhand der entwickelten Geräte und der zwei GUI-Builder Prototypen werden die Ergebnisse der Arbeit näher erläutert.
6.1.1
Geräte
Auf Basis von UPnP wurden mit einem Sensorgerät und einer Webcam
mit Bewegungserkennung zwei Geräte geschaffen, die als Eingabemedien für
ein Steuerungsszenario mit weiteren, vernetzten Geräten eingesetzt werden
können. Das für die Verknüpfung der Geräte notwendige Framework Torem
wird in [39] eingehend beschrieben.
In mehreren Tests konnte die nahtlose Zusammenarbeit unter Beweis
gestellt werden. So ist es beispielsweise möglich die Webcam als Überwachungskamera einzusetzen. Betritt eine Person den Raum, wird das Ereignis
Bewegung erkannt generiert und an die Torem gesendet. Das Framework
wertet das Ergebnis aus und schaltet ein Hardware-Licht1 an. Mit wenig
Aufwand kann der Ablauf dahingehend geändert werden, dass als Antwort
auf das vorher genannte Ereignis nicht nur das Licht angeschaltet, sondern
auch eine SMS-Nachricht an den Benutzer gesendet wird.
Ähnlich verhält es sich mit dem Drucksensor-Modul, das in einem Szenario als aktives oder passives Eingabegerät zum Einsatz kommen kann. Sind
die Drucksensoren am Boden angebracht, können sie zum Beispiel das Auftreten einer Person registrieren und dieses Ereignis an interessierte Steuerinstanzen weiterleiten. In einem anderen Fall könnten die Sensoren als Eingabefelder benutzt werden, um eine Passwortabfrage zu simulieren, die nach
einer definierten Reihenfolge bei der Eingabe verlangt.
Mit dieser dynamischen Zuordnung der Eingabegeräte zu der spezifischen
Bedeutung der Interaktion konnte im Gegensatz zu proprietären Softwarelösungen und dem Konzept des verteilten Netzwerkes eine klare Verbesserung
hinsichtlich der ökonomischen Nutzung des computerisierten Gerätes erzielt
werden. Umgelegt auf ein Szenario im Haushalt bedeutet dies, dass ein Bewegungsmelder an der Eingangstür nicht nur an das Einschalten eines Lichts,
sondern auch an andere Ereignisempfänger gekoppelt sein kann.
6.1.2
GUI-Builder
Mit der Definition der regelbasierten UI-Beschreibung am Gerät ist ein erster Schritt in Richtung automatisierter Generierung von User Interfaces für
die UPnP Service-Plattform getan. Zusammen mit der funktionalen Gerätebeschreibung stehen dem PC GUI-Builder zwei Informationsquellen zur
1
Das Licht ist Teil des Testaufbaus einer EIB-Gebäudesteuerung, die über einen Softwareadapter ebenfalls ins UPnP-Netzwerk eingebunden wurde.
KAPITEL 6. FAZIT
80
Verfügung, um Bedingungen für den UI-Rendering-Prozess formulieren zu
können.
Die generierten User Interfaces bieten eine einfachere und besser bedienbare Darstellung (siehe Abb. 5.8) als die bestehenden ControlpointImplementierungen (siehe Abb. 5.1) zur Fernsteuerung von UPnP-Geräten.
Der Ansatz reicht jedoch nicht aus, um komplexere Anwendungen und
Interaktionsmuster beschreiben zu können. Gerade die Spezifikation von gemeinsamen Schnittstellen für verteilte Geräte und Anwendungen verlangt
aber, dass dieses Konzept auch in Richtung Präsentation und Steuerung der
Inhalte fortgesetzt wird. Letztendlich ist das User Interface immer auch stark
an das Applikationsmodell gebunden. Nur mit genaueren Informationen über
die semantische Bedeutung der Interaktionen können Aussagen über das
Layout, die Navigationsstruktur, die einzelnen Interface-Komponenten, das
Verhalten und das Zustandsmodell eines User Interfaces getroffen werden.
Der Prototyp des mobilen GUI-Builders (siehe Abb. 5.10) am Smart
Phone hat sich ebenfalls als brauchbare Anwendung zur Steuerung der UPnPGerätedienste erwiesen. Das Konzept setzt die universellen Fernbedienung
um, die in Reichweite einer Bluetooth-Basisstation an das UPnP-Netzwerk
gekoppelt werden kann. Auch wenn sich die grafische Umsetzung und der
Bedienkomfort noch in einem Anfangsstadium befinden, so stehen dem Benutzer doch auch jetzt schon alle UPnP-Funktionen zur Verfügung. Alle im
Laufe der Arbeit vorgestellten Geräte sind damit ansteuerbar.
Um fernbedienbare Unterhaltungselektronik zentral steuern zu können,
muss ein Weg für die Integration eines Infrarot-Senders (IR)2 gefunden werden. Das BTkit 3 ist ein Hardwaremodul, das mit einem Bluetooth-Chip
und einem Infrarot-Sender und Empfänger über solche Kapazitäten verfügt.
In [10, 11] wird der Aufbau und Einsatz dieses Systems zur Steuerung von
Infrarot-Geräten via Bluetooth-fähigem Smart Phone beschrieben. Leider
konnte das Produkt wegen eines Lieferstopps nicht mehr zur Entwicklung
herangezogen werden.
6.2
Ausblick
Neben der zentralen Steuerung von Haushaltsgeräten scheinen verteilte Netzwerke in Kombination mit Eingabegeräten auch für einen weiteren Bereich
interessant. Es stellt sich die Frage, ob mit diesen Technologien auch künstlerische Medieninstallationen verwirklicht werden können. Diese basieren
meist auf der Interaktion eines Benutzers abseits eines Computerterminals
und benötigen neben diverser Sensorik auch Zugriff auf viele Mediengeräte.
2
Die Infrarot-Schnittstelle ist aufgrund der niedrigen Produktions- und Integrationskosten die vorrangige Technologie für Fernsteuerungen von Unterhaltungselektronik. Viele
Hersteller verwenden auf Basis des Lichtsignals ein eigenes, unidirektionales Übertragungsprotokoll. Ein Überblick findet sich unter http://www.xs4all.nl/˜sbp/knowledge/ir/ir.htm
3
BTkit - http://www.btkit.com/de/
KAPITEL 6. FAZIT
81
Dazu zählen Audio-, Video- und Lichtequipment, das über Steuerprotokolle
wie DMX und MIDI angesprochen werden kann. Sie können sehr schnell in
eine IP-basiertes Netzwerk eingebunden werden. Die Integration scheitert
jedoch an der Anforderung echtzeitfähiger Steuerbefehle. Obwohl Netzwerkbefehle mit ausreichender Geschwindigkeit abgearbeitet werden könnten hat
sich die Architektur von UPnP in diesem Zusammenhang als Nachteil erwiesen.
Für jeden ausgesandten Steuerbefehl und jedes Ereignis, das auf SOAP
und dem, in der Netzwerkschicht darunterliegenden, zustandslosen HTTPProtokoll aufsetzt, muss eine gesonderte Netzwerkverbindung aufgebaut werden. Dies wurde von UPnP so spezifiziert und auch in der verwendete JavaBiblothek Cyberlink umgesetzt. Aus diesem Grund liegt die Zeitdauer zwischen Aufruf und Ausführung einer Aktion zwischen 300 ms und bis zu 2 s.
Für Dienste die selten genutzt werden ist diese Latenz kaum ein Problem.
Echtzeitkritische Anwendungen können hingegen nicht zufriedenstellend bedient werden.
Ein Ansatz, um diese Steuerungsproblematik zu lösen ist die Verwendung
anderer Remote Procedure Call 4 -Technologien auf Kosten der Plattformunabhängigkeit, wie das Java-basierte RMI 5 oder die Middleware CORBA6 .
Der Einsatz von UPnP würde sich in diesem Fall nur auf die Geräteerkennung beschränken und die Steuerung diesen Architekturen mit persistenten
Netzwerkverbindungen übernehmen lassen.
Die erzielten Ergebnisse dieser Arbeit zeigen, dass mit einfachen Mitteln
auch heute schon verteilte Dienste des Alltags über einheitliche grafische
und physische Schnittstellen angesprochen werden können. Die Fähigkeit
zur dynamischen und intelligenten Vernetzung wird in Zukunft ein entscheidendes Kriterium für den Nutzen eines Gerätes und einer Anwendung in
einem Umfeld sein, dessen Voraussetzungen nicht immer bekannt sind.
Im Bereich der automatisierten Generierung grafischer User Interfaces
ist noch viel Arbeit zu leisten. Hier könnte mit einer Weiterentwicklung
eine einheitliche Schnittstelle für mehrere Plattformen zur Fernsteuerung
zukünftiger, im Haushalt integrierter Geräte geschaffen werden. Erste Tests
zeigten, dass sich das Supple Toolkit auch für GUI-Renderings auf einer
Web-basierten Plattform und für den PDA eignet. Voraussetzung dafür ist
eine zunehmende Verbreitung an standardisierten, netzwerkfähigen Geräten,
die von Seiten der Elektronikhersteller unterstützt werden muss.
4
Remote Procedure Call (RPC) bezeichnet den Aufruf einer entfernten Funktion über
ein Netzwerk.
5
Java Remote Method Invocation (RMI) - http://java.sun.com/products/jdk/rmi/
6
Common Object Request Broker Architecture (CORBA) - http://www.omg.org/
gettingstarted/corbafaq.htm
Anhang A
Inhalt der CD-ROM
File System: Joliet
Mode: Single-Session (CD-ROM)
A.1
Diplomarbeit
Pfad:
/thesis/
da doppler.pdf . . . . .
da doppler.ps . . . . . .
images/ . . . . . . . . .
A.2
Literatur
Pfad:
/docs/
index.html . . . . . . . .
Diplomarbeit (PDF-File)
Diplomarbeit (PostScript-File)
Alle Grafiken der Diplomarbeit im
EPS-Format
Link-Liste der Literaturquellen
Der Ordner enthält nach einzelnen Kapiteln geordnet alle Online-Literaturquellen als PDF-Files.
A.3
Anwendungen
Pfad:
/applications/
info.pdf . . . . . . . . .
guibuilder pc setup.exe
guibuilder pc.zip . . . .
Anleitung für die Inbetriebnahme und das
Arbeiten mit den Geräten.
Installierbare Win32 -Version des PC
GUI-Builders
Zip-Datei des PC GUI-Builders
82
ANHANG A. INHALT DER CD-ROM
guibuilder mobile.zip . .
devices setup.exe . . . .
devices.zip . . . . . . .
A.4
Quellcode
Pfad:
/source/
/guibuilder pc/ . . . . .
/guibuilder mobile/ . .
/devices/ . . . . . . . .
83
Zip-Datei des mobilen GUI-Builders für das
Smart Phone (getestet am Nokia 6600 )
Installierbare Win32 -Version der Geräte
Zip-Datei des Geräte
Alle Eclipse-Plugin-Projekte, die für den
GUI-Builder benötigt werden.
Eclipse-Projekt des mobilen GUI-Builders
Eclipse-Projekte der UPnP-Geräte
Sensor-Device, Streaming Server/Client,
Winamp, MIDI-Device
Literaturverzeichnis
[1] Abrams, M. und J. Helms: User Interface Markup Language (UIML)
Specification — Working Draft 3.1 . URL, http://www.oasis-open.org/
committees/download.php/5937/uiml-core-3.1-draft-01-20040311.pdf,
March 2004. Kopie auf CD-ROM.
[2] Allaire, J.: Macromedia Flash MX - A next-generation rich client.
URL, www.adobe.com/devnet/flash/whitepapers/richclient.pdf, March
2002. Kopie auf CD-ROM.
[3] Anderson, C., P. Domingos, Etzioni, K. Gajos, T. Lau, D. Weld
und S. Wolfman: Automatically Personalizing User Interfaces. In:
Proceedings of IJCAI-03 , 2003.
[4] Baxley, B.: Making the Web Work - Designing Effective Web Applications. Sams, 2002.
[5] Bluetooth Special Interest Group: Bluetooth Protocol
Architecture — Version 1.0 .
URL, http://bluetooth.com/NR/
rdonlyres/7F6DEA50-05CC-4A8D-B87B-F5AA02AD78EF/0/Protocol
Architecture.pdf, August 1999. Kopie auf CD-ROM.
[6] Boyer, J. und D. L. et al.: XForms 1.0 Specification (Second Edition). URL, http://www.w3.org/TR/xforms/, March 2006. Kopie auf
CD-ROM.
[7] Choy, H. und A. Fuchs: Developing Innovative Devices Using Universal Plug and Play (UPnP). Techn. Ber., 2004.
[8] Cooper, A. und R. Robert: About Face 2.0 - The Essentials of User
Interface Design. Wiley Publishing, Inc., Indianapolis, Indiana, 2003.
[9] Davies, N. und J. L. et al.: Rapid Prototyping for Ubiquitous Computing. Pervasive Computing, 4(4):15–17, 2005.
[10] Dr. Harbaum, T.: Drahtlos-Dolmetscher — Heim-Elektronik per Funk
fernbedienen - Teil 2 . CT, 15:220–225, 2005.
84
LITERATURVERZEICHNIS
85
[11] Dr. Harbaum, T.: Funkzentrale — Heim-Elektronik per Funk fernbedienen - Teil 1 . CT, 14:204–209, 2005.
[12] Dr. Scheller, A.: Brückenschlag — Die technische Infrastruktur fürs
Digital Home. CT, 18:106–108, 2005.
[13] Dr. Stieler, W.: Smarte Begleitung — Pervasive Computing durchdringt den Alltag. CT, 16:78–90, 2004.
[14] Focus Software Ltd.: Datasheet - What is XForms? . URL, http:
//www.xformation.com/xforms/pr02 01.asp, 2004. Kopie auf CD-ROM.
[15] Gajos, K., D. Christianson, R. Hoffmann, T. Shaked, K. Henning, J. J. Long und D. Weld: Fast And Robust Interface Generation
for Ubiquitous Applications. In: Proceedings of the Seventh International Conference on Ubiquitous Computing (UBICOMP 2005), Tokyo,
Japan, September 2005.
[16] Gajos, K. und D. S. Weld: Automatically Generating User Interfaces For Ubiquitous Applications. In: Workshop on Ubiquitous Display
Environments, Nottingham, UK, 2004.
[17] Gajos, K. und D. S. Weld: SUPPLE: Automatically Generating User
Interfaces. In: IUI ’04: Proceedings of the 9th international conference
on Intelligent user interface, S. 93–100, New York, NY, USA, 2004.
ACM Press.
[18] Gajos, K. und D. S. Weld: Preference Elicitation for Interface Optimization. In: UIST ’05: Proceedings of the 18th annual ACM symposium on User interface software and technology, S. 173–182, New York,
NY, USA, 2005. ACM Press.
[19] Garrett, J. J.: Ajax - A New Approach to Web Applications. Adaptive Path LLC, 18. Februar 2005 . URL, http://www.adaptivepath.com/
publications/essays/archives/000385.php, February 2005. Kopie auf CDROM.
[20] Gratton, D. A.: Bluetooth Profiles: The Definitive Guide. Prentice
Hall, New Jersey, 2003.
[21] Gsottberger, Y., X. Shi, G. Stromberg, W. Weber, T. Sturm,
H. Linde, E. Naroska und P. Schramm: Sindrion: a prototype system for low-power wireless control networks. In: 2004 IEEE International Conference on Mobile Ad-hoc and Sensor Systems, 2004.
[22] Jeronimo, M. und J. Weast: UPnP Design by Example — A Software Developer’s Guide to Universal Plug and Play. Intel Press, Hillsboro, Oregon, 2003.
86
[23] Jespersen, J. W. und J. Linvald: Investigating user interface engineering in the model driven architecture. In: Proceedings of the Interact
2003 Workshop on Software Engineering and HCI , September 2003.
[24] Li, S.: Professional Jini . Wrox Press Ltd., Birmingham, UK, 2003.
[25] Mutka, M. W., L. M. Ni und F. Zhu: Service Discovery in Pervasive
Computing Environments. Pervasive Computing, 4(4):81–89, 2005.
[26] Myers, B., S. E. Hudson und R. Pausch: Past, present, and future of
user interface software tools. ACM Transactions on Computer-Human
Interaction, 7(1):3–28, 2000.
[27] Myers, B. A.: Why are Human-Computer Interfaces Difficult to Design and Implement? . Techn. Ber. CMU-CS-93-183, July 93.
[28] Nichols, J., B. A. Myers, M. Higgins, J. Hughes, T. K. Harris,
R. Rosenfeld und M. Pignol: Generating Remote Control Interfaces
for Complex Appliances. In: CHI Letters: ACM Symposium on User
Interface Software and Technology, UIST’02 , S. 161–170. ACM Press,
2002.
[29] Puerta, A. und J. Eisenstein: XIML: A Universal Language for User
Interfaces. URL, http://ximl.org/documents/XimlWhitePaper.pdf, 2002.
Kopie auf CD-ROM.
[30] Reiter, S.: Smart Shelf Design and Implementation of an RFID Reader UPnP device based on the Sindrion architecture. Diplomarbeit,
Fachhochschule Hagenberg, Hardware- Software Systems Engineering,
Hagenberg, Austria, Juli 2005.
[31] Schiller, J.: Mobile Communications — Second Edition. Pearson
Education, Harlow, 2003.
[32] Schlungbaum, E.and Elwert, T.: Automatic User Interface Generation from Declarative Models. In: Proceedings of CADUI 1996 , S.
3–18, 1996.
[33] Sietmann, R.: Muss man alles und alle vernetzen ? — Natascha Adamowsky über die Folgen des Ubiquitous Computing. CT, 16:91, 2004.
[34] Smith, S. und J. Mosier: Guidelines for Designing User Interface
Software. Natl Technical Information, 1986.
[35] Sun Microsystems, Inc.: Jini Architecture Specification — Version
1.2.1 . URL, http://www.sun.com/software/jini/specs/, Juni 2003. Kopie
auf CD-ROM.
87
[36] Tanenbaum, A. S.: Computernetzwerke. Pearson Studium, München,
BRD, Dritte Aufl., 2000.
[37] The OSGi Alliance: OSGi Service Platform Core Specification —
Release 4 . URL, http://www.osgi.org/osgi technology/spec download3.
asp?Accept=Accept, August 2005. Kopie auf CD-ROM.
[38] UPnP Forum: UPnP Device Architecture. URL, http://www.upnp.
org/download/UPnPDA10 20000613.htm, 2000. Kopie auf CD-ROM.
[39] Wally, B.: Entwicklung einer Steuerinstanz zur interaktiven Kopplung
verteilter Geräte. Diplomarbeit, Fachhochschule Hagenberg, Medientechnik und -design, Hagenberg, Austria, Juli 2006.
[40] Weiser, M.: The computer for the 21st century. Scientific American,
265:94–104, September 1991.
[41] Zucker, D. F., M. Uematsu und T. Kamada: Content and Web
Services Converge — A Unified User Interface. Pervasive Computing,
4(4):8–11, 2005.
Messbox zur Druckkontrolle
— Druckgröße kontrollieren! —
Breite = 100 mm
Höhe = 50 mm
— Diese Seite nach dem Druck entfernen! —
88

Entwicklung verteilter Geräte und Anwendungen für die UPnP

Transcrição

Documentos relacionados

Schulanmeldung Kreativitätsgrundschule der Grundig Akademie

Antrag auf steuerliche Unbedenklichkeitsbescheinigung

Anbieterkatalog Seite 1 von 1 Stammdaten Anbietername

Zeittafel - Wald

väterberatung gera

Neues Gera

Schulanmeldung - Freie Gemeinschaftsschule der Grundig

Geraer Verkehrsbetrieb GmbH Ein Unternehmen der Stadtwerke

Casting für Massachusetts - Das Bee Gees Musical

Vollmacht