UPnP Diplomarbeit

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 selbst-
stä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.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Technische Begriffserklärungen 4
2.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Technische Details . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Vergleichbare Funktechnologien . . . . . . . . . . . . . 7
2.2 Service-Plattformen . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 JINI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Geräte 17
3.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 UPnP-Technologie . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.1 Sensor-Hardwaredevice . . . . . . . . . . . . . . . . . . 20
3.4.2 Webcam Streaming-Server und Client . . . . . . . . . 23
3.4.3 UPnP-Winamp Media Player . . . . . . . . . . . . . . 26
3.4.4 MIDI-Device . . . . . . . . . . . . . . . . . . . . . . . 26
iv
INHALTSVERZEICHNIS v
4 Generierung grafischer User Interfaces 28

4.1 Anforderungen im GUI-Design . . . . . . . . . . . . . . . . . 29
4.2 Anforderungen im Pervasive Computing . . . . . . . . . . . . 30
4.2.1 Kontext-sensitive und verteilte Anwendungen . . . . . 30
4.2.2 Geräteeigenschaften . . . . . . . . . . . . . . . . . . . 31
4.3 Techniken der GUI-Entwicklung . . . . . . . . . . . . . . . . . 32
4.3.1 Window Manager und Toolkits . . . . . . . . . . . . . 32
4.3.2 Web-basierte Entwicklungen . . . . . . . . . . . . . . . 32
4.3.3 Interaktive GUI-Builder . . . . . . . . . . . . . . . . . 34
4.4 XML GUI-Sprachen . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.2 XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.3 XForms . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.4 UIML . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.5 XIML . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Model-based User Interface . . . . . . . . . . . . . . . . . . . 42
4.5.1 User Interface Generierung . . . . . . . . . . . . . . . 44
4.5.2 Projekt – Pebbles Personal Universal Controller . . . 44
4.5.3 Projekt – Supple . . . . . . . . . . . . . . . . . . . . . 48
5 GUI-Builder 53
5.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 System-Schnittstellen . . . . . . . . . . . . . . . . . . 54
5.1.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Implementierung - PC . . . . . . . . . . . . . . . . . . . . . . 56
5.2.1 Entwicklung mit OSGi . . . . . . . . . . . . . . . . . . 56
5.2.2 Systemaufbau . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3 GUI-Generator . . . . . . . . . . . . . . . . . . . . . . 60
5.2.4 UI-Erweiterungen . . . . . . . . . . . . . . . . . . . . 66
5.3 Implementierung - Smart Phone . . . . . . . . . . . . . . . . 70
5.3.1 Entwicklung mobiler Java-Anwendungen . . . . . . . . 71
5.3.2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3.3 Mobile Client . . . . . . . . . . . . . . . . . . . . . . . 74
6 Fazit 78
6.1 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.1.1 Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.1.2 GUI-Builder . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A Inhalt der CD-ROM 82

A.1 Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
INHALTSVERZEICHNIS vi
A.4 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Literaturverzeichnis 84
Vorwort
Mit der Fertigstellung der vorliegenden Diplomschrift geht ein weiterer Ab-
schnitt 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 Arbeitsauf-
wand 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 Schaf-
fenskraft, die, wenn sie mit Wissen und Gewissen eingesetzt wird, Großar-
tiges vollbringen kann. Ich hoffe mit meiner Arbeit einen kleinen Teil zu
einem technologischen Fortschritt beizutragen, der in Einklang mit den Be-
dü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 intelligen-
ten 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 Di-
plomstudiums in zahlreichen Gesprächen mit guten Ratschlägen und fachli-
chem 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 Re-
gina und Erwin Doppler genannt, die mir in vielen richtungsweisenden Ent-
scheidungen, 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 in-
telligenten 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 Service-
Plattform verschiedene Geräte und Anwendungen für ein mögliches Medien-
steuerungsszenario beleuchtet. Der erste Schwerpunkt liegt in der Entwick-
lung 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 Generie-
rung von User Interfaces zur Fernsteuerung der Dienste ermittelt. Der Be-
nutzer soll unabhängig vom Ort und der Plattform des darstellenden Endge-
rä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 stan-

dards 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 rep-
resentation 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 appli-
cations 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 genera-
tion 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 Dienstlei-
stungen 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 Standardisie-
rung von Technologien getragen wird. Erwähnenswert hierfür ist die univer-
selle 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 Sy-
stems2 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 An-
forderungen, die es am Weg zur universellen Vernetzung von Gerätediensten
im Haushalt zu erfüllen gilt und dem möglichen Mehrwert, der daraus ge-
neriert 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 2
1.1 Motivation
Der Grundstein für die Realisierung der Vision einer pervasiven Umgebung
scheint mit den fortschreitenden Entwicklungen von mobilen und Embedded-
Technologien gelegt. Ein weitgehend ungeklärter Aspekt hingegen sind Stan-
dards 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 au-
tomatischer 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 For-
schung 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 hin-
gegen notwendig und sinnvoll ist. Hierfür muss ein Konzept zur automati-
sierten 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 inter-
essierten Teilnehmer darüber informiert und erhalten eine funktionale Be-
schreibung 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 In-
terfaces nicht alleine auf die Domäne der verteilten Netzwerke beschränkt
ist, gibt es einige, vielversprechende Ansätze. Mehrere XML-basierte Spra-
chen und GUI-Building Systeme (siehe Kapitel 4) bieten Lösungsansätze
auf verschiedenen Abstraktionsebenen an. Diese reichen von einer konkre-
ten 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 Fern-
steuerung einer UPnP-Gerätelandschaft evaluiert werden.
Anhand prototypischer Implementierungen soll der Einsatz der Techno-
logie 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 Ge-
nerierung 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-Sprach-

definitionen rund um das Thema einer generischen Beschreibung und Gene-
rierung von grafischen Benutzeroberflächen.
Kapitel 5 demonstriert und dokumentiert die praktische Anwendbarkeit

einer generischen Mediensteuerung für verteilte Geräte anhand zweier pro-
totypischer 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 Energie-
verbrauch 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 Industrie-
standard gemäß IEEE3 802.15.1. Wenngleich auch die flächendeckende Ein-
fü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-Fre-
quenzband 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̈hrlei-
sten. 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 Versio-
nen 1.1 und 1.2 bei 723,1 kbit/s und in der verbesserten Version 2.0 EDR
1
Bluetooth - http://www.bluetooth.com/
2
Bluetooth SIG - https://www.bluetooth.org/
3
IEEE (Institute of Electrical and Electronics Engineers) - http://ieee.org- eine Insti-
tution zur Standardisierung von Computertechnologien
4
KAPITEL 2. TECHNISCHE BEGRIFFSERKLÄRUNGEN 5
WAE
WAP
TCP/UDP SDP
vCard/vCal IP TCS BIN
AT AUDIO
OBEX PPP Command
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 kosten-
günstigen und energiesparenden Funktechnologie gerecht zu werden, wurden
drei Leistungsklassen für verschiedene Einsatzzwecke geschaffen. Klasse 1-
Gerä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 Endge-
rä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̈ber-
greifende Kommunikation möglich wird. Der Zusammenschluss mehrerer Pi-
conets 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 Abbil-
dung 2.1). Erklärte Designziele waren eine bindende Richtlinie für die Im-
plementierung 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 Protocols

Bluetooth Core Protocols Baseband, LMP, L2CAP, SDP
Cable Replacement Protocol RFCOMM
Telephony Control Protocols TCS Binary, AT-commands
Adopted Protocols 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̈hn-
ten Frequenzsprungverfahrens. Echtzeitkritische Audiodaten werden eben-
falls ohne zusätzlichen Overhead über dieses Protokoll übertragen. Das Link
Manager Protocol (LMP) ist für den Verbindungsaufbau zwischen den Blue-
tooth-Geräten sowie Authentifizierung und Verschlüsselung zuständig. Das
Logical Link Control and Adaption Protocol (L2CAP) fungiert als Vermitt-
lungsschicht 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 se-

riellen Datenübertragungskanal RS232 wurde die RFCOMM -Schnittstelle
geschaffen. Dadurch können eine große Anzahl an höherliegenden Protokol-
len ohne Anpassungsaufwand auch über Bluetooth Funk betrieben werden.
Telephony Control Protocols: Auf Empfehlung der International Te-

lecommunication Union (ITU-T) flossen AT-Steuerkommandos (AT-com-
mands) in die Bluetooth-Spezifikation mit ein. Das zusätzliche Telephony
Control Protocol - Binary (TCS Binary) zeichnet sich für den Verbindungs-
aufbau 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 er-
möglicht die Darstellung von Internetinhalten mit dem Wireless Applica-
tion Protocol (WAP) und der aufbauenden Wireless Application Environ-
ment (WAE) Anwendungen. Object Exchange (OBEX) ist der Infrarot-
Spezifikation entnommen und ermöglicht den schnellen Austausch von Ob-
jekten 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 Profile
Im Vergleich zu anderen Funktechniken wie WLAN, die einmal spezifiziert
werden und eine starre Auslegung verlangen, lebt die Bluetooth-Spezifika-
tion vor allem durch ihre hochgradige Flexibilität und Erweiterbarkeit. Ver-
antwortlich 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 komponentenba-
sierten 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 Vererbungs-
hierarchie angeordnet sind [20]. Profile sind Kombinationen dieser Kompo-
nenten, die bestimmte Rückschlüsse auf den Aufbau und die Zusammenset-
zung 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 Synchro-
nisation 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 zusam-
menschließ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 Pro-
file 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 Compu-
ting und die dadurch gewonnene Ortsunabhängigkeit ein kompetitives Ge-
schäft. Neben Bluetooth drängen eine Menge ähnlicher Technologien auf den
Markt und eine steigende Anzahl an multifunktionalen Endgeräten mit un-
terschiedlichsten 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 Fre-
4
Eine aktuelle Liste der Bluetooth Profil-Spezifikationen findet sich unter http://
bluetooth.com/Bluetooth/Learn/Technology/Specifications/. Eine Liste der Entwürfe ist un-
ter https://www.bluetooth.org/spec/ abrufbar
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 den-
noch 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 ent-
wickelt, 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 automati-
sierte Ad-Hoc-Vernetzung und Diensterkennung (Service Discovery) ein vor-
rangiges 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 wer-
den 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 ver-
wendet gängige Java-Technologien [35]. Jini kann auf einem beliebigen Netz-
werkprotokoll aufsetzen, ist aber an eine vorhandene Laufzeitumgebung, die
Java Virtual Machine (JVM), und dadurch an die Konzepte der Program-
miersprache 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 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 dazuge-
hö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 ei-
ner 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 er-
hä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 Mul-

ticast 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̈g-
barkeit 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-
Lookup Service
e
nc
Di
re
sc
fe
ov
Re
er
ya
ice
p
ku
nd
rv
o
Lo
Se
Jo
in
Client Service Provider
Service Call
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 Netzwerkun-
terstützung von Multicast und Broadcast-Nachrichten.
Join: Diese Phase beschreibt die Prozedur der Service-Registrierung bei

verschiedenen Lookup Services. Der Service Provider meldet ein Dienstob-
jekt 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 Ser-
vice fündig, so erhält er eine Kopie des Dienstobjektes. Für die Kommuni-
kation 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 Er-
eignisses über die Zustandsänderung informiert.
Leasing: In Jini wird die temporäre Nutzung der Ressourcen eines Ser-
vices als Leasing bezeichnet. Ein Client kann nach Absprache mit dem Ser-
vice 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 au-
tomatischen Verbindungsaufbau, Steuerung und Datenaustausch zwischen
Geräten im Heim- und Office-Bereich auf Basis von TCP/IP und Internet-
technologien 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 beliebi-
ges 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 Inte-
gration (zero configuration).
• Abstraktion der Netzwerktopologie zugunsten einer einfachen Bedie-
nung ( invisible“ networking).
”
• Plattform-, protokoll- und geräteunabhängige Kommunikation und Da-
tenaustausch.
Bedingt durch die Flexibilität der Architektur ist auch eine Anpassung
von Technologien und Mediengeräten mit nicht IP-konformen Proto-
kollen möglich. Der Implementierungsaufwand für herstellerspezifische
Gerätetreiber ist damit ebenfalls überflüssig, da standardisierte Pro-
tokolle verwendet werden und dem Entwickler im Gegensatz zu Jini
die freie Wahl der Programmiersprache und des Betriebssystems ga-
rantieren.
Das UPnP Forum ist ein Konsortium das sich mit dem Design der Wei-
terentwicklung der UPnP-Kommunikation zwischen den Produkten verschie-
dener Hersteller beschäftigt. Praktisch alle namhaften Firmen in der IT-
Branche sind in diesem Forum vertreten12 .
Komponenten
Die UPnP-Architektur definiert zwei Komponententypen - das Gerät (De-
vice) und die Steuerinstanz (Control Point).
12
UPnP Implementers Corporation - http://www.upnp-ic.org/
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 Stereoan-
lage, die sich aus verschiedenen Teilgeräten wie CD-Player, Mini-Disk, Kas-
settendeck, Radio und Uhr zusammensetzt. Diese bieten dem Benutzer ab-
strakte Services an (Multimedia-Steuerung, Zeitanzeige, Wecker). Diese Ser-
vices enthalten wiederum Zustandsvariablen (state variables) und Aktionen
(actions), die auf dem Gerät ausgeführt werden können (Ein- und Ausschal-
ten, Starten und Stoppen eines Mediengerätes, Setzen und Auslesen der
Zeit).
Die funktionale Beschreibung dieser Eigenschaften ist in einer XML-
Dokumentenhierarchie im Gerät festgehalten, und wird im Netzwerk be-
kanntgegeben. 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 ei-
nes Licht-Dienstes. Auffallend ist dabei die Kombination aus Zustandsva-
riable 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 Zu-
standsvariable gebunden.
1 < actionList >
2 < action >
3 < name > SetPower </ name >
4 < argumentList >
5 < argument >
6 < name > Power </ name >
7 < 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>
8 < direction > in </ direction >
9 </ argument >
10 </ argumentList >
11 </ action >
12 < action >
13 < name > GetPower </ name >
14 < argumentList >
15 < argument >
17 < 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>
18 < direction > out </ direction >
19 </ argument >
21 </ action >
22 </ actionList >
23 < serviceStat eT a bl e >
24 < stateVariable sendEvents = " yes " >
26 < dataType > boolean </ dataType >
27 </ stateVariable >
28 </ serviceStat eT a bl e >
UPnP Vendor
UPnP Forum
UPnP Device Architecture
GENA SSDP SOAP GENA
HTTPMU HTTPU 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 vor-
nehmen und Aktionen aufrufen um Dienste in Anspruch zu nehmen.
Aufbau der UPnP-Stack Architektur

Aufbauend auf der IP-Adressierung in der Vermittlungsschicht des OSI/ISO-
Referenzmodells [36] setzt sich der UPnP-Stack aus folgenden, in Abb. 2.4
ersichtlichen, Protokollen und Technologien zusammen. Als Transportpro-
tokoll 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 Dis-
covery 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̈sen-
tation 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 zu-
stä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
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 Netz-

werk 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 Netz-
werk 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 in-
formieren.
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, Seri-

ennummer, Herstellername und URLs zu Webseiten.
• Information über die eigenen Services und die der eingebetteten Ge-
räte.
• URLs für die zeitgleichen Betriebsphasen der Steuerung, des Event-
managements und der Präsentation (control, eventing, presentation).
• Beschreibung der Aktionen und Zustandsvariablen, die mit einem Ser-
vice in Verbindung stehen.
Control: Mit dem Abschluss der Description ist das UPnP-Netzwerk be-
triebsbereit. Ein Control Point kann nun ihm bekannte Serviceleistungen in
Anspruch nehmen und Zustände an den Geräten abfragen. In Form von
XML-SOAP Nachrichten werden Aktionsaufrufe an die Geräte-URL ge-

schickt. Das Gerät arbeitet diese Befehle ab und reagiert mit Zustands-
änderungen.
Eventing: Wenn sich ein Control Point als Listener bei einem Gerät regi-
striert, so wird er durch ausgelöste Events über Änderungen von Statusva-
riablen informiert. Für die Anmeldung an einem Service sendet er eine Sub-
scription 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̈n-
derung 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 Unterhaltungs-
elektronikkonzerne mit großer Wahrscheinlichkeit zu einer Schlüsseltechno-
logie 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 Software-
hersteller, darunter Sun Microsystems, IBM und Ericsson, getragen. Das
OSGi-Framework definiert eine offene Service-Plattform für vernetzte Dien-
ste, 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 Anfor-
derungen gerecht (vgl. [37]):
13
OSGi und OSGi Alliance - http://www.osgi.org/
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 admi-

nistriert 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 er-

möglicht eine strikte Trennung von Kompetenzen. Im Bundle-Kontext un-
terscheidet 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̈l-
tige 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 Arbeitszim-
mer ohnehin dem Radio vorgezogen wird. Obwohl die Inhalte über das Netz-
werk 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 ma-
chen würde. Die Stereoanlage, der Fernseher, der DVD-Player und auch das
Raumlicht könnten unter einem gemeinsamen Standard und den entspre-
chenden 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 in-
formieren, 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 ver-
teilter Netzwerke nicht mehr nur als eigenständige Dienste betrachtet wer-
den können, sondern gerade durch ihre vielfältigen Vernetzungsmöglichkei-
ten eine neue Servicequalität bieten. Die drahtlosen und netzwerkfähigen
Geräte hierfür sind mit PCs, PDAs, Touchpanels und Mobiltelefonen vor-
handen. Auch Unterhaltungselektronik wird vermehrt mit Netzwerkfunk-
tionalität ausgestattet. Mit einer gemeinsamen Service-Plattform für die
Dienste wird eine Trennung zwischen dem Standort eines Gerätes und des-
sen 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 Hard-

und Softwaregeräte gefunden oder selbst entwickelt werden.
• GUI-Builder: Genauso wie mit UPnP ein gemeinsames Steuerpro-

tokoll für verteilte Geräte vorhanden ist, muss ein Weg zur automati-
sierten Generierung von User Interfaces zur Fernsteuerung der Netz-
werkgerä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 verteil-
ten 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 In-
stanz, die Geräte im Netzwerk finden und ansteuern kann. Torem
erlaubt es dem Benutzer mit einem grafischen Editor ereignisorien-
tierte Zustandsvariablen und Ein- und Ausgabeparameter von UPnP-
Aktionen miteinander zu verknüpfen, um Szenarioabläufe zu definieren
(siehe Abb. 3.1).
Abbildung 3.1: Torem - Ein Framework zur Kopplung verteilter UPnP-

Geräte. Der Benutzer kann aus allen vorhandenen Geräte und zusätzlichen
Kontrollflusskomponenten, wie If -Bedingungen und Schleifen eine Ereignis-
kette definieren [39].
3.3 UPnP-Technologie
Als Grundlage für die Entwicklung der Geräte und GUI-Builder Steueran-
wendung wird eine Bibliothek benötigt, die die Besonderheiten der UPnP-
Technologie abstrahiert und die Implementierung von Geräten und Control-
point-Instanzen ermöglicht. Die Cyberlink UPnP Bibliotheken1 des japa-
nischen Programmierers Satoshi Konno ist in den Programmiersprachen
C/C++ und Java verfügbar. Zusätzliche Beispielanwendungen und ein ru-
dimentärer Controlpoint zum Steuern der Gerätedienste sind ebenfalls vor-
handen. Die Java-Variante dieser Bibliothek wurde für die Entwicklung aus-
gewählt, da sie schon mehreren Revisionen unterzogen wurde und eine über-
sichtliche 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 ge-
1
Cyberlink UPnP Bibliotheken http://www.cybergarage.org/net/
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/Media-
Renderer-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 aus-
gestatteter Mikrocontroller mit LAN-Anschluss und ein Streaming-Server,
der das Video einer Webcam zu einem Client übertragen kann und dort Be-
wegungsdetektion 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 gefun-
den werden, die einen UPnP-Stack für performanceschwache Systeme im-
plementiert. 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 wer-
den.
Hinsichtlich frei verfügbarer Software wurden folgende UPnP-Bibliothe-
ken für die Entwicklung in Betracht gezogen:
• Intel Software for UPnP Technology: Intel’s UPnP-Implemen-

tierung5 ist eine Sammlung an Softwarepaketen für die Entwicklung
und das Testen UPnP-fähiger Anwendungen. Das Authoring Tools-
Paket enthält einen automatisierten Device-Builder, der anhand funk-
tionaler XML-Gerätebeschreibungen portablen Programmcode in C
2
UPnP Geräte-Standards - http://www.upnp.org/standardizeddcps/
3
Philips Streamium (UPnP AV MediaRenderer) - http://www.streamium.philips.com/
4
Musical Instrument Digital Interface (MIDI) ist ein Steuerprotokoll für digitale Mu-
sikinstrumente, 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/
generiert. Jedoch ist dieser Code nur für Microsoft Windows, Pocket-
PC 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 Embedded-
Linux 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++-Implemen-
tierung 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 Betriebssy-
steme T-Engine 7 und uTRON 8 kein bekanntes Hardwareboard gefun-
den 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 In-
dustral 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 UPnP-
Bibliotheken für einen Mikrocontroller mit 128Kb dynamischem Flash-
Speicher und 1MB Festspeicher zu wenig, um Features wie XML-
Verarbeitung, das Steuerprotokoll SOAP und die Multi- und Broadcast-
Protokolle für die automatische Geräteerkennung zu unterstützen. Eine
Portierung der Cyberlink C-Bibliothek auf die gängige ARM -Mikro-
prozessorarchitektur10 wäre mit einigem Zeitaufwand allerdings denk-
bar.
• 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/
7
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 Mikropro-
zessoren, die dem RISC-Konzept folgen. - http://www.arm.com/
11
Infineon - http://www.infineon.com/de/
UPnP-Serviceplattform erwähnt. Demnach ist ein Sindrion Wireless-

Transceiver eine Gerät, das einen reduzierten UPnP-Stack implemen-
tiert 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 Sin-
drion erscheint vielversprechend. Allerdings befindet sich die Techno-
logie noch in der Entwicklungsphase.
• Sun SPOT: Das Forschungsprojekt Sun SPOT 12 der Sun Microsy-
stems 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 Stan-
dard IEEE 802.15.414 ausgestattet und kann als Informationsquelle in
intelligenten Netzwerken eingesetzt werden. Die Besonderheit des Kon-
zeptes liegt in der Kombination aus robuster Hardware und Sun’s haus-
eigener, objektorientierter Programmiersprache Java, die mit CLDC
1.1 den Standard einer vollwertigen, mobilen Virtual Machine imple-
mentiert. 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 -Mikro-
controller16 , 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 re-
quest-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 er-
mittelten acht Sensorwerte mit je 2 Byte Länge zurück (sensordata). Trotz
12
SUN Spot - http://www.sunspotworld.com/
13
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
request
ack
send
PC Hardware
ack 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 Hardwarede-
vice 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̈l-
len, ist Teil des Mappings zwischen zwei UPnP-Diensten, wie sie im Torem-
Framework definiert werden kann. So kann unter anderem folgendes Verhal-
ten festgelegt werden: Wenn der Wert des Sensors1 kleiner 2000 ist, dann
soll der Play-Befehl eines Medienplayers ausgeführt werden. Ein erweiter-
tes 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, Distanz-
Sensoren, Magnetfeld-Sensoren, etc. denkbar, da sie am gleichen Gerät an-
gebracht 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 ange-
schlossenen Webcam im Netzwerk bereitstellt. Die Idee ist, einen UPnP-
basierten Server zu schaffen, dessen Konfiguration im Netzwerk vorgenom-
men 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̈g-
lichkeiten, allerdings zum Empfang des Videosteams. Der Streaming Client
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 rea-
giert 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 zu-
gänglich gemacht, dessen URL wiederum mit der UPnP-Aktion GetLastMo-
tionImage bekanntgegeben wird.
Systemaufbau
Für die Implementierung der Streaming-Architektur wurde das Java Me-
dia 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 abge-
speicherter Medienformate. Durch die Entwicklung von Plugins können Än-
derungen in den Datenströmen der Verarbeitungskette vorgenommen wer-
den, 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 identi-
sche Klassenstruktur, die in drei Bereiche unterteilt ist:
• net.digidop.upnp.device.rtpapp: Dieses Packet definiert das Zu-

standsmodell der Applikation, die Anbindung an das Netzwerk als
UPnP-Gerät. Für den Client ist zusätzlich auch eine UPnP-Control-
point integriert, der zur Auffindung des Servers benötigt wird.
• net.digidop.upnp.device.rtpserver.business: Diese Schicht de-

finiert Business-Objekte zum Aufbau der JMF-Verarbeitungskette, der
Instanzierung des medienverarbeitenden Prozessors und der Generie-
rung einer grafischen Komponente für das Videovorschaubild.
• net.digidop.upnp.device.rtpserver.ui: Das Packet enthält Klas-

sen 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/
Bevor eine Verarbeitung am Client erfolgt, muss der Processor konfi-

guriert 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 durch-
schnittliche Intensitätsänderungen eines Bildes. Hat sich der ermittelte Wert
im Vergleich zum vorgehenden Videoframe stark verändert, wird eine Bewe-
gung 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 * 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
3 * der Intensitäts än de r un g zweier Frames mit Abstand 10
4 */
5
6 if (( frameCount % 10) == 0) {
7 if ( motionDetecte d ) {
8 motionDetecte d = false ;
9 } else {
10 clientDevice . trackingVar . setValue ( " FALSE " );
11 }
12 }
13
14 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 ) {
15 motionDetecte d = true ;
16 clientDevice . trackingVar . setValue ( " TRUE " );
17 }
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 resi-
stent ist, implementiert werden kann. Auch die Nutzung von videobasier-
tem Tracking scheint in diesem Kontext denkbar. Mit dem Streaming Server
(siehe Abb. 3.3) und Client wurde eine kostengünstige Variante einer Über-
wachungskamera 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
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 Softwareadap-
ter an UPnP angebunden. Neben der Überlegung ein umfangreiches C++-
basiertes Plugin auf Basis der Winamp SDK22 und der Cyberlink UPnP-
Bibliothek zu entwickeln, wurde mit httpQ 23 ein netzwerkbasiertes Plugin
gefunden, das die Funktionen von Winamp über den Zugriff via HTTP-
GET 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 HttpQAd-
apter 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 ausge-
fü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 UPnP-
Adapter für das Windows Betriebsystem entwickelt. Damit können alle soft-
21
Winamp Media Player - http://httpq.sourceforge.net/
22
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
warebasierten Klangerzeuger wie Reaktor25 angesprochen werden. Der Ad-

apter sendet mit Hilfe der Java-MIDI API javax.sound.midi Steuerbefehle
an die virtuelle Schnittstelle LoopBe1. Wird der Treiber in einem Klan-
gerzeuger als MIDI-Eingabegerät ausgewählt, so leitet er die eintreffenden
Befehle direkt an dieses weiter. Über die installierten MIDI-Treiber der So-
undkarte des PCs können auch externe Geräte angesprochen werden.
Das MIDI-Protokoll definiert eine Reihe an Steuernachrichten mit un-
terschiedlicher 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̈henparame-
ter 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 Aus-
gabe eines Tons.
Obwohl mit diesem Ansatz bislang nur ein Teil des MIDI-Protokolls im-
plementiert ist, demonstriert es die Integration eines breiten Spektrums an
zusätzlicher Hard- und Software, die mit diesem Protokoll arbeiten. Vor al-
lem hinsichtlich neuer Eingabemedien scheint dieses Konzept interessant, da
zahlreiche MIDI-Controller mit integrierten Tasten, Drehknöpfen, Touchpa-
nels 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 deut-
schen 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 Ent-
wurf eines Interfaces ist es, Daten und Funktionalitäten einer Applikation
in einer abstrahierten Form zu präsentieren und dem Benutzer einfache In-
teraktionsmöglichkeiten anzubieten. In diesem Zusammenhang befasst sich
der Human-Computer Interface (HCI) Forschungsbereich neben traditionel-
len 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 vorliegen-
den Arbeit sein sollen. Vielmehr soll erläutert werden, warum das Design
und die Implementierung von GUIs auch Jahrzehnte nach deren Aufkom-
men 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 unterschied-
lichsten 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 hinge-
gen 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 Be-
28
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 ge-
geben sind, desto vielschichtiger sind die Abhängigkeiten, die es in der Soft-
ware und dem GUI-Design vorab zu bedenken gilt.
Dadurch werden eine Reihe wichtiger Fragen aufgeworfen. Im Mittel-
punkt 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 defi-

niert und wie können sie angewandt werden?
2. Welche Anforderungen werden bei der GUI-Entwicklung an den Ent-
wickler herangetragen?
3. Welche gesonderten Anforderungen werden durch die Verbreitung mo-
biler Endgeräte, ubiquitärer Technologien und die Ad-hoc-Vernetzung
generiert?
4. Welche unterstützenden Konzepte und Werkzeuge kommen in der Pra-
xis zum Einsatz?
4.1 Anforderungen im GUI-Design

In [27] werden allgemeine Aspekte aufgelistet, die es beim Design jedes gra-
fischen 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 Fen-
ster, Menüleisten und Bestätigungs-Dialoge ebenso, wie Layout-spezifische
Konventionen. Das Schließen einer Applikationen oder das Öffnen einer Da-
tei, werden als Hauptfunktionen in verschiedenen Applikationen an der glei-
chen Stelle zu finden sein. Dem Benutzer wird dadurch die Möglichkeit gege-
ben, sich an bereits erlernten Metaphern orientieren zu können. Das selbst-
verständliche Vorhandensein von Maus, Tastatur und einer grafischen Ober-
flä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 Be-
triebssystemherstellern wie Microsoft1 und Apple2 Guidelines definiert. Ne-
ben einem konsistenten Look and Feel ist dies auch auf die Tatsache zurück-
zuführen, dass das moderne Betriebsystem grundlegende Zeichenoperationen
1
Microsoft User Interface Design and Development - http://msdn.microsoft.com/ui/
2
Apple Human Interface Guidelines - http://developer.apple.com/documentation/
UserExperience/Conceptual/OSXHIGuidelines/
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 robu-

ste, 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 er-
klä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 Unter-
stützung des Benutzers in seiner Tätigkeit sein soll [8]. Die Internationalisie-
rung von Anwendungen eröffnet besseren Zugang zu spezifischen Benutzer-
gruppen und verlangt mehr als nur die Übersetzung von Textinhalten. Auch
externe Faktoren wie lokale Kultureinflüsse, soziale und rechtliche Gegeben-
heiten, 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 in-
formiert 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 Technolo-
gien erweitert mit ebenso großer Tragweite den Horizont der computeri-
sierten 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 Wunsch-
traum einer ubiquitären Welt nach Mark Weiser [40], in der der Benutzer
keinen unmittelbaren Kontakt mehr zu technischen Geräte hält, Wirklich-
keit werden kann, müssen essentielle Fragen hinsichtlich Energieversorgung,
einheitliche Kommunikationsstandards und auch dem Design solcher intelli-

genter Gegenstände geklärt werden.
Durch die Mobilität wird das Paradigma der verteilten Anwendung und
spontaner Vernetzung gestärkt. Die physische Trennung von Applikations-
logik und grafischer Repräsentation erlaubt es auch leistungsschwachen Ge-
räten aufwendige Aufgaben zu erledigen. Diese können im Hintergrund von
Serverdiensten abgearbeitet werden und müssen lediglich für die Synchroni-
sation der Information des GUI-Client sorgen.
4.2.2 Geräteeigenschaften
Die gestiegene Performance und Speicherkapazität bei mobilen Geräten er-
laubt die Darstellung grafischer Inhalte auf Farbdisplays, die bis vor kur-
zem noch Desktop-Systemen vorbehalten waren. Mobile Betriebsysteme wie
Windows Mobile3 und Symbian4 und systemübergreifende Entwicklungs-
plattformen wie Microsoft .NET5 und die Java 2 Platform, Micro Edition
(J2ME)6 bieten mit grafischen Toolkits Unterstützung für einfache GUI-
Programmierung.
Eine weitere Eigenschaft der neuen Geräteklassen sind spezialisierte Ein-
und Ausgabehardware. Auf Seiten der Interaktionstechniken reicht die Pa-
lette von wandgroßen Displays über berührungsempfindlichen Touch Screens
und PDAs mit Bedienstift (stylus) bis hin zu Mobiltelefonen mit mehrfach-
belegten Funktionstasten und Joystick oder Richtungstaste für die Naviga-
tion. Durch Wegfall von Maus und Tastatur muss die Navigation durch das
User Interface anders ausgelegt sein. Am Beispiel einer einfachen Textein-
gabe lässt sich der Paradigmenwechsel leicht erklären. Durch die Populari-
tät des Short Message Services (SMS ) zeigt sich, dass es dem Konsumenten
selbst am Mobiltelefon ein Bedürfnis ist, Texte zu verfassen. Das neue Be-
dienungskonzept, 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 Inter-
aktion 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 Tischober-
flä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/
4
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/
Interaktionstechniken hoffen.
Alle Geräte verfügen mittlerweile über Farbdisplays in unterschiedlichen
Ausführungen. Die Auflösung und Skalierung des Displays hat ebenfalls si-
gnifikante Auswirkungen auf die Anzahl und Anordnung der grafischen Ele-
mente die in einem GUI dargestellt werden können [26]. Die Bandbereite
reicht von kleinen Mobiltelefon-Displays bis zu hochauflösenden Bildschir-
men. Trotz des Vorhandenseins gemeinsamer, grafischer Toolkits kann auf-
grund der Varianten bei Ein- und Ausgabegeräten nicht jeder grafische Inhalt
gleich repräsentiert werden. Erschwerend kommt noch hinzu, dass nicht ein-
mal 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 perva-
siven Umgebungen erfordert neue Konzepte im Umgang mit Software und
deren grafischer Darstellung. Rapid Prototyping [9], die schnelle und teilau-
tomatisierte Entwicklung von (prototypischen) Implementierungen, ist dabei
ebenso ein Thema wie Techniken zur abstrakten Beschreibung und Modellie-
rung von Funktionalität einer Applikation. Auf Basis dieser Anstrengungen
können Versuche zur automatisierten Generierung grafischer Benutzerober-
flächen unternommen werden.
4.3 Techniken der GUI-Entwicklung

4.3.1 Window Manager und Toolkits
Eine Reihe an Konzepten führt zu den heute angewandten und weit verbrei-
teten Techniken in der Entwicklung grafischer User Interfaces. Zu den großen
Errungenschaften der Window Manager zählt die Tiefenstaffelung und Ska-
lierbarkeit von Fenstern, die schnelles Wechseln zwischen parallel laufen-
den Anwendungen ermöglichen. Window Manager sind Teil des Betriebsy-
stems und bieten grundlegende grafische Operationen (Zeichnen, Updaten
des Bildschirms) und Schnittstellen für die Ereignisbehandlung an. Aufbau-
end auf diesem abstrakten Modell stellen grafische Toolkits ein meist kom-
ponentenbasiertes Framework für einfaches Arbeiten mit konkreten GUI-
Elementen in einer bestimmten Programmiersprache zur Verfügung. Sie ge-
währleisten bis zu einem gewissen Grad Konsistenz hinsichtlich der Ereig-
nisbehandlung und dem Zeichnen der grafischen Komponenten und dürfen
daher keinen starken Änderungen in der Programmbibliothek(API ) unter-
worfen sein.
4.3.2 Web-basierte Entwicklungen

In der Web-Entwicklung führte ein Zusammenspiel aus der Seitenbeschrei-
bungssprache HTML, der Layoutbeschreibung CSS und Client- und server-
seitigen Scriptsprachen (Javascript, PHP, Perl) zum kommerziellen Durch-

bruch. 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 (Model-
View-Controller oder MVC ). Der großen Erfolg von webbasierten Dienstlei-
stungen führte dazu, dass führende objektorientierte Programmiersprachen
mit eigenen Scriptsprachen aufwarten und dadurch das MVC-Prinzip be-
stä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 Cli-
ent und Server nur für den Zeitraum eines Request/Response-Zyklus offen
hält. Dadurch ist die grafische Oberfläche gezwungen, bei jeder Interak-
tion, 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) ver-
suchen diesen Nachteil mit Hilfe asynchroner Datenübertragung im Hin-
tergrund ungeschehen zu machen. Auch proprietäre Rich Client Plattfor-
men wie die Macromedia Flash Platform10 [19], arbeiten in dieser Hin-
sicht 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 beste-
hende Technologien auf mobile Plattformen zu portieren. In [41] wird die
Idee eines zukünftigen, einheitlichen User Interfaces für dynamische, webba-
sierte 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 Auszeich-
nungssprachen 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. zusam-
mengesetzt und anschließend in editierbaren Programmcode für die objek-
torientierte 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 bie-
tet eine solche Entwicklungsumgebung für die eigenen Programmiersprachen
C# und Visual Basic. Auch für die Java GUI-Bibliotheken Abstract Win-
dow 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 Struk-
tur und hierarchische Anordnung von grafischen Elementen beschreiben. Es
existiert eine Vielzahl an XML GUI-Dialekten, die auf unterschiedlichen Ab-
straktionsebenen ein grafisches Interface für verschiedene Aufgabengebiete
spezifizieren. Das gemeinsame Ziel ist die automatische GUI-Generierung an-
hand einer Beschreibung, die auf einer Plattform in einer Entwicklungsum-
gebung mit Hilfe einer Programmiersprache oder in der Laufzeitumgebung
eines Programms oder Frameworks in ein konkretes Interface-Rendering ver-
wandelt werden muss.
Mit Microsoft XAML, Mozilla XUL und XForms werden drei User In-
terface Description Languages (UIDL) vorgestellt, die eine starke Bindung
zu konkreten GUI-Komponenten und dadurch zum Endresultat des GUI-
Building Prozesses haben. UIML und XIML bieten eine generischere Defi-
nition eines grafischen Interfaces. Dies macht eine geräte- und plattformu-
nabhä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 konkre-
tes Rendering mit vordefinierten GUI-Elementen in Aussicht.
4.4.1 XAML
WinFX13 ist der Name von Microsofts .NET basierter Programmierschnitt-
stelle, die die Basis für Applikationsentwicklungen im kommenden Betriebs-
system Windows Vista bildet und in vier Bereiche gegliedert ist. Neben dem
Kommunikationsmodell Windows Communication Foundation (WCF), dem
Programmiermodell Windows Workflow Foundation (WF) und sicherheits-
und authentifizierungsrelevanten InfoCard-Komponenten ist die Windows
Presentation Foundation (WPF) für die grafische Aufbereitung in Vista zu-
ständig. Als Teil dieses Subsystems wurde die Extensible Application Mar-
kup Language (XAML) als XML-basierte Beschreibungssprache für User In-
terfaces 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 wer-
den. Innerhalb des Dokuments können auch Layouteigenschaften und ein-
fache 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̈tz-
ung für verschiedene Text- und Objektlayoutdefinitionen und inte-
grierte Steuerelemente für deren Betrachtung geben.
• Vektorgrafik und Multimedia: Die Definition von 2D und 3D-
Vektorgrafiken sowie die Steuerung von Animationen und die Integra-
tion 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 Mul-
timedia Integration Language).
• Daten Anbindung: Direkte Anbindung an Datenquellen wie Webser-
vices und anderen XML-Daten ist ohne programmatischen Mehrauf-
wand möglich.
• Technologieübergreifendes Formularwesen - In XAML festge-
legte Oberflächen können sowohl für die Interface-Generierung von
Webanwendungen als auch für Desktop-Applikationen eingesetzt wer-
13
WinFX API - http://msdn.microsoft.com/winfx/technologies/default.aspx
14
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 Thunder-
bird und weiteren Projekten zum Einsatz kommt und von der Gecko Rende-
ring Engine verarbeitet wird. XUL wurde zur schnellen Entwicklung platt-
formunabhängiger Benutzeroberflächen entwickelt und versucht mit Hilfe
von Technologien wie XML-Transformationen, CSS und JavaScript den Im-
plementierungsaufwand 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 serverseiti-
gen 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 Er-
findung von XUL versucht Mozilla dem durch lange Perioden der Stagnation
geprägten Prozess der Standardisierung von Web-Technologien zu entkom-
men 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 Stan-
dard 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/
16
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/
Host Document
(XHTML,SVG,...)
XForms Model
Person
Name
Address
Process Input
Validate
XForms
User Interface
XForms:Input
Abbildung 4.1: XForms-Architektur (siehe [14]).
erlaubt die Definition von Formularen unabhängig vom konkreten, grafi-

schen Erscheinungsbild und dem Endgerät. So sind neben einem XForm
User Interface auch XHTML, WML und proprietäre GUI-Renderings denk-
bar. 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 Da-
tenhaltung 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 Model-
Container. 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 (bin-
ding) und die Abhandlung der Eingabeereignisse, die auch die Validierung
Peers
Presentation Interface Logic
Structure
Swing
Renderer WML Style
Renderer
> i am quite
sure you can't
Content Application
read this yerk!
yak '06...
Behaviour
Data Source
Platform / Device
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 Of-
fice und Haushalt.
4.4.4 UIML
Die User Interface Markup Language (UIML)20 versteht sich als eine Me-
tasprache 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 Trans-
formationsaufgabe 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 In-
teraktionsverhalten sind ebenfalls Teil der Sprachdefinition, die sich am
Model-View-Controller Designpattern orientiert (siehe Abb. 4.2). Auch UI-
Templates und zeitliche Veränderungen der Interface-Struktur, die durch
Öffnen eines neuen Fensters entstehen können, werden in UIML berücksich-
tigt. Die grundlegende Struktur ist in folgende Bereiche gegliedert:
1 < uiml xmlns = ’ http: // uiml . org / dtds / UIML3_0a . dtd ’ >
2 < head > ... </ head >
20
UIML - http://www.uiml.org/
3 < template > ... </ template >

4 < interface >
5 < structure >
6 < part / >
7 </ structure >
8 < style > ... </ style >
9 < content > ... </ content >
10 < behavior > ... </ behavior >
11 </ interface >
12 < peers >
13 < presentation > ... </ presentation >
14 < logic > ... </ logic >
15 </ peers >
16 </ uiml >
Interface-Elemente <part> werden innerhalb des <structure> -Tags hier-

archisch 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. Unten-
stehend ist eine vereinfachte Definition eines Java Swing-Fensters:
1 < interface >
2 < structure >
3 < part class = " JFrame " id = " JFrame " >
4 < part class = " JButton " id = " Submitbutton " / >
5 </ part >
6 </ structure >
7 < style >
8 < property part - name = " JFrame " name = " layout " >
9 java . awt . GridBagLayout </ property >
10 < property part - name = " JFrame " name = " title " >
11 TestApp </ property >
12 </ style >
13 </ interface >
14 < peers >
15 < presentation id = " JavaSwing " >
16 <d - class id = " JFrame " used - in - tag = " part "
17 maps - type = " class " maps - to = " javax . swing . JFrame " >
18 ...
19 </d - class >
20 </ presentation >
21 </ 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 Aus-
legung der Sprache umfasst die ganzheitliche Unterstützung vom UI-Design-
prozess, über das Mapping zwischen abstrakten und konkreten Steuerele-
21
XIML - http://www.ximl.org/
menten bis hin zu Evaluierungsfunktionen und der Einbindung von wissens-

basierten 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 An-
forderungen von Interaktion und der Modellierung von Navigationsabläu-
fen auch noch plattformübergreifende Synchronisation und Kontext-basierte
Einflüsse hinzukommen können.
Die Architektur von XIML definiert kontextuelle und strukturale Mo-
delle und die Repräsentation eines Interfaces und bringt sie in einen relatio-
nalen Zusammenhang. Daher lässt die Nomenklatur dem Begriff der Kompo-
nente eine weitläufigere Bedeutung als in den meisten XML-GUI Sprachen
zukommen. Fünf Komponenten, die eine Sammlung an Elementen beinhal-
ten, wurden festgelegt [29]:
1. Task: Die Task-Komponente liefert eine abstrakte Beschreibung al-

ler Vorgänge, die die Interaktion mit dem Benutzer betreffen. Sowohl
die hierarchische Ordnung, als auch der Workflow können eingefan-
gen werden. Beispiele für Vorgänge sind eine Datumseingabe oder das
Starten eines CD-Players.
2. Domain: Domain-Information bezeichnet anwendungsrelevante Ob-
jekte und Datentypen unterschiedlicher Komplexität, die mit dem In-
terface in Verbindung gebracht werden. Etwa ein Datum oder ein ab-
straktes 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 Informa-
tionen fest und erlaubt die Definition von Benutzergruppen.
4. Presentation: Die Präsentationsschicht beschreibt den hierarchischen
Aufbau des User Interfaces mit abstrakten Elementen wie einem Win-
dow oder einem Button. Für die Transformation in ein konkretes Er-
scheinungsbild ist ein Konverter für jede Plattform nötig.
5. Dialog: Der Dialog definiert alle Interaktionen und die erlaubte Navi-
gationsstruktur für das GUI auf einer konkreteren Ebene als der Task.
Ein Klick und auch Spracheingabe bezeichnen beide Interaktionen.
1 < interface
2 xmlns = "x - schema:http: // www . ximl . org / validator / schema . xml "
3 id = " test " >
4 < definitions > ... </ definitions >
5 < model_compo ne nt s >
6 < task_model id = " dictionary " > ... </ task_model >
7 < domain_model id = " dictobjects " > ... </ domain_model >
XIML Interface
Specification
Presentation HTML
> i am quite
sure you can't
read this yerk!
yak '06...
Component 1 Converter
Presentation WML
Abbildung 4.3: XIML Architektur (siehe [29]).
8 < user_model id = " dictobjects " > ... </ user_model >
9 < presentation _m o de l id = " java " > ... </ presentati on _m o de l >
10 < dialog_model id = " dictdialog " > ... </ dialog_model >
11 </ model_compo ne nt s >
12 </ interface >
Ein- und Mehrfachbeziehungen zwischen den Elementen dieser Modelle

komplementieren das gesammelte Wissen für ein konkretes Interface-Ren-
dering. Die Datenauswertung ist Teil des XIML-Frameworks. Die Sprache
sieht vor, dass zu einem GUI für jede Plattform eine eigene Präsentations-
komponente deklariert werden muss, die verarbeitet und angezeigt werden
kann.
Ist die Unterstützung mangels XML-Parser oder anderer, fehlender Vor-
rausetzungen 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̈sentations-
schicht 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 enthal-
ten sind. Unter dem Begriff Intelligent Interaction Management werden wis-
sensbasierte Systeme unterstützt, die zur Laufzeit Personalisierung von In-
halten, 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 < presentati on _m o de l id = " dictbasicpres " >
2 < name > basic presentation model for the dictionary </ name >
3 <! -- definition of presentation elements -- >
4 < definitions >
5 < 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 Knowledge-

Specification based System
Presentation HTML
> i am quite
sure you can't
read this yerk!
yak '06...
Intermediate
Presentation
Component
Presentation WML
Abbildung 4.4: XIML Architektur mit Intermediate Presentation Compo-

nent (siehe [29]).
6 < allowed_class es >

7 < class reference = " mainwindow " slot = " left " / >
8 < class reference = " aiowindow " slot = " right " / >
9 </ allowed_class es >
10 </ relation_de fi ni t io n >
11 </ definitions >
12 <! -- here is the hierarchy of presentation elements -- >
13 < p r e s e n t a t i o n _ e l e m e n t id = " mainwindow " location = " optional " >
14 < name > dictionary main window </ name >
15 < p r e s e n t a t i o n _ e l e m en t id = " deflabel " location = " optional " >
16 < name > dictionary definition label </ name >
17 </ p r e s e n t a t i o n _ e l e m en t>
18 < p r e s e n t a t i o n _ e l e m en t id = " termslist " location = " optional " >
19 < name > list of terms in the dictionary </ name >
22 <! -- now are the definitions of the ( aios ) themselves -- >
23 < p r e s e n t a t i o n _ e l e m e n t id = " aiowindow " location = " optional " >
24 < name > definition of the abstract window </ name >
25 < p r e s e n t a t i o n _ e l e m en t id = " javawindow "
26 location = " http: // www . ximl . org / ui / javaawtrender . ui # awt " >
27 < name > rendered for the java toolkit </ name >
29 < p r e s e n t a t i o n _ e l e m en t id = " winntwindow "
30 location = " http: // www . ximl . org / ui / winnt / window . vbx " >
31 < name > rendered for the windows nt environment </ name >
34 </ presentati on _m o de l >
4.5 Model-based User Interface

XML-basierende GUI-Sprachen bieten eine Möglichkeit für die automati-
sierte Erstellung von grafischen Oberflächen. Je abstrakter jedoch die Defini-
tion 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 spe-
zifische 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 ei-
nes plattformübergreifenden User Interfaces, das dynamischen Änderungen
zur Laufzeit unterliegt und dabei kontextbezogene Informationen mit ein-
bezieht. 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 vor-
angetrieben. Obwohl zu diesem Zeitpunkt noch kein standardisiertes Daten-
format 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 Personalisie-

rung von Inhalten und die Aufzeichnung und Analyse von Benutzer-
verhalten 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 Ziel-
beschreibung, der Aufteilung in mehrere atomare Subtasks und Zu-
standsüberführungen festgehalten werden.
• Application Model: Das Application Model wird auch Object Model
oder Business Model genannt, repräsentiert den Zustand der Applika-
tion 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 ei-
ner GUI-Anwendung.
• Presentation Model: Auf Ebene des Presentation Models wird das
Rendering des GUIs durchgeführt. Dazu werden die vorhandenen In-
formationen der anderen Models ausgewertet und in eine konkrete Dar-
stellung 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 Be-
schreibung 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 Uni-
versal 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 Iden-
tifizierung aller abstrakten Interface-Elemente passieren. Ein Beispiel
für ein abstraktes Interface-Element ist die Definition eines Fenster-
menü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 Interface-
Elemente wird als Mapping bezeichnet und geschieht zusammen mit
der automatisierten Anordnung der Komponenten im Interface.
• Zwecks semantischer Bindung werden Zusatzinformationen zur Ver-
haltensmodellierung des Interfaces eingebracht. Damit können etwa
Abhängigkeiten zwischen Elementen definiert werden, um ganze Funk-
tionsgruppen anhand eines Elements zu aktivieren oder zu deaktivie-
ren. Komplexere Verhaltensmuster werden jedoch nicht von den model-
based UI Tools abgedeckt und müssen selbstständig modelliert werden.
• Kaum ein generiertes Interface entspricht in allen Belangen den Vor-
stellungen des Designers oder den Bedürfnissen des Users. Zusätzliche
Methoden zur Evaluierung und Revision unter Einbeziehung mensch-
licher 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 be-
liebigen 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 Fernsteueranwendun-

gen für die Betriebssysteme PalmOS und Windows Mobile ausgerichtet. Der
Begriff des Interfaces ist in PUC nicht nur auf grafische Oberflächen be-
schrä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 Specifi-
cation Language 23 , die eine funktionale Gerätespezifikation anhand hierar-
chisch 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 Be-
schreibung von jedem Endgerät zur Verfügung gestellt werden muss, braucht
es eine einheitliche Kommunikationsschnittstelle zwischen Gerät und Inter-
face. 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 Infrarot-
Schnittstellen ausgestattet und können nach dem bekannten Prinzip einer
Fernbedienung lediglich Befehle entgegennehmen.
In PUC existieren nach eigenen Angaben zum gegebenen Zeitpunkt Ad-
apter für Camcorder mit IEEE 139424 -Anschluss und dem AV/C Protokoll,
Videorecorder die den Steuerungsstandard HAVi25 unterstützen, den ameri-
kanischen Gebäudesteuerungsstandard X1026 und diverse proprietäre Hard-
ware wie eine Telefonanlage. Die Integration von Jini und UPnP wird in
Aussicht gestellt.
Obwohl Funktechnologien bevorzugt werden, stellt PUC keine Anforde-
rungen an die verwendete Netzwerktechnologie. Es wird jedoch vorausge-
setzt, dass jedes Gerät oder dessen Adapter über eine eigene Netzwerkan-
bindung 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 ge-
halten und definiert sechs Befehle zum Austausch von Gerätebeschreibung,
23
PUC Specification Language - http://www.pebbles.hcii.cmu.edu/puc/specification.html
24
Die Datenschnittstelle ist auch unter dem Namen FireWire bekannt.
25
HAVi - urlhttp://www.havi.org/
26
X10 - http://www.x10.com/home2.html
Application PUC Device
Adapter
PUC Protocol PUC Protocol
Network (802.11, Bluetooth, IR...)

Communication 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 Ty-
pen 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 Fre-
quenzsuchlauf benötigt, ist dieses Vorgehen schnell erklärt: Würde man ganz
auf die Verwendung von Zustandsvariablen verzichten, entspräche die Model-
lierung des Interfaces einer heutigen Hardware-Fernbedienung, die keinerlei
Rückmeldung über die Gerätezustände zulässt [28]. Die logische Gruppie-
rung erlaubt dem UI-Generator, der für jede Plattform einmal implemen-
tiert werden muss, anfängliche Rückschlüsse über die Strukturierung der
Interface-Elemente.
Durch zusätzlich definierte Abhängigkeiten zwischen den Zustandsva-
riablen 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 auf-
grund 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 de-
finiert werden. Zu einem Zeitpunkt kann nur ein Modus in Betrieb genom-
men 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 <? xml version = " 1.0 " encoding = " UTF -8 " ? >
2 < spec name = " Audiophase - Stereo " >
3 < group >
4 < state name = " CDTrackState " >
5 < type >
6 < valueSpace >
7 < integer / >
8 </ valueSpace >
9 </ type >
10 < labels >
11 < label > CD Track </ label >
12 < label > Track </ label >
13 < text - to - speech text = " Track " recording = " track . au " >
14 </ labels >
15 < active - if >
16 < equals state = " Mode " >2 </ equals >
17 </ active - if >
18 </ state >
19 ...
20 </ group >
21 </ spec >
Die Zuweisung von Zuständen und Steuerbefehlen zu konkreten Inter-

face-Elementen wird mit Hilfe eines Entscheidungsbaumes und damit ver-
bundenen 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 genom-
men. Im Falle der Stereoanlage unterteilt der UI-Generator die vier exklu-
siven Operationsmodi aufgrund der gewonnenen Information schließlich in
mehrere, sich überlappende Reiter. Globale Funktionen, die sich auf die Ak-
tivität aller Komponenten auswirken (Einschaltknopf), oder oft genutzt wer-
den (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 Inter-
face in einem Durchgang erstellt wird und keine weitreichenderen Überle-
gungen hinsichtlich des globalen Ergebnisses und gerätebedingter Einschrän-
kungen 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 Erkennt-
nissen im Bereich der Entscheidungstheorie und Optimierungsproblematik.
Supple ist ein plattformunabhängiges System zur Generierung von dynam-
isch-adaptiven User Interfaces für Java-fähige Endgeräte und das Web. Ne-
ben einer abstrakten, funktionalen Beschreibung der Applikation auf Ebene
des Sourcecodes, dienen ein Device Model und ein User Model als Informa-
tionsquellen zur GUI-Generierung [16].
Supple selbst umfasst keine abstrakte Modellierung von Tasks und se-
mantischen 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 zusam-
mengesetzt werden können. In Supple wird kein Bedeutungsunterschied zwi-
schen 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 dar-
stellen. 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 Inter-
aktionsmethode, die mausähnliche Eingabegeräte aber auch ein Touchpanel
28
Supple - http://www.cs.washington.edu/ai/supple/
Supple
Method Call
Supple Solver Messages
User Device
Model Model
Application Display Device
State and Interface Widget Concrete

Logic Model Proxies 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 Ge-
nerierung wird ein Interface Model definiert, das die Steuerbefehle und Zu-
standsvariablen des unterliegenden Application Models als abstraktes Inter-
face-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 An-
bindung 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 In-
stanzen eines GUI mit gleichbleibender Applikationslogik ohne zusätzlichen
Aufwand denkbar.
Layout Generierung
Supple definiert die Aufgabe des Interface-Rendering als Optimierungspro-
blem, 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 Interface-
Models, durch das Device Model und durch die Ablaufverfolgung des Be-
nutzers 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̈g-
lichkeiten ausgewählt wird, ist jenes, das den minimalsten Gesamtaufwand
aufweist. Die Kosten einer Möglichkeit können als gewichtete Summe einzel-
ner Kostenfunktionen der Interface-Elemente beschrieben werden. Die Ko-
sten 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]).
K

$(render(e)) = uk (render(e)) (4.1)
k=1
Als Lösungsverfahren des Optimierungsproblems auf Basis der Interface-

Kostenfunktion wird der Branch and Bound-Algorithmus29 verwendet, der
es erlaubt, die Suche auf ein eindimensionales, rekursives Verfahren zu re-
duzieren. Indem der hierarchisch aufgespannte Suchbaum in Subregionen
unterteilt wird, die gesondert auf die Grenzen der gesuchten Variablen ana-
lysiert 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̈s-
sen 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 Wahrscheinlichkeits-
berechungen hinsichtlich des zu erwartenden Nutzerverhaltens und heuristi-
scher 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 durchschnittli-
chen 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 be-
stimmten Benutzers entspricht. Die Personalisierung von Inhalten ist daher
Gegenstand intensiver Forschungen. In Supple sind zwei Arten der Persona-
lisierung 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 Eva-
luierung der erwarteten Qualität des Renderings. Die Adaptierung setzt da-
bei auf das Erfassen, Verarbeiten und Interpretieren von Benutzerspuren.
Der Zustandsautomat einer Applikation wird dabei in Relation zu den er-
mittelten Interaktionen des Benutzers gesetzt. Werden im Zuge der Aus-
wertung 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 Touch-

panel (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 Con-
trols, Vent ) waren ursprünglich sogar untereinander angeordnet und wurden
erst durch eine zusätzliche Größeneinschränkung mit maximal 640 x 480 Pi-
xel in eine Form mit ausgewogenem Seitenverhältnis gebracht.
entfernte Interaktions-Objekte wie Fenster, Popup-Dialoge und Reiter er-

strecken, 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 wer-
den. 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 komple-
mentäres System namens Arnauld 30 eingesetzt, das ebenfalls entscheidungs-
theoretische Optimierungsverfahren verwendet [18]. Example Critiquing be-
zeichnet 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 GUI-
Komponenten erlaubt (siehe Abb.4.9). Neben dem Slider kann das Level-
Element 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 wer-
den.
Allein aus dieser Methode lassen sich allerdings nicht immer genügend
Parameter zur Erstellung der Supple-Kostenfunktion und nachhaltigen Ver-
30
Arnauld - http://www.cs.washington.edu/ai/arnauld/
Abbildung 4.9: Supple – Werkzeug zur dynamischen Änderung von GUI-

Komponenten 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-Ren-
derings 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 Informa-
tionen 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 Ele-
ments, so muss diese in einem auffolgenden Schritt auch im Kontext des
gesamten Interfaces präsentiert werden, um dieses Bewusstsein zu gewähr-
leisten [18].
Kapitel 5
GUI-Builder
5.1 Konzept
Das Supple Projekt (siehe Kapitel 4.5.3) hat sich als brauchbares Software-
Werkzeug zur automatisierten Generierung grafischer User Interfaces erwie-
sen. 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 Soft-
ware der Fall, bei der sowohl die Benutzeroberfläche als auch die Logik ge-
meinsam 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 grafi-
schen Interfaces zu definieren. Die Service-Plattform UPnP integriert mit
Absicht keine Unterstützung für Benutzeroberflächen, um die herstellerspe-
zifische 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̈s-
sen 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 In-
formationsquelle 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
Abbildung 5.1: Cyberlink Controlpoint (siehe auch Kap. 3.3) – Entlang ei-
ner Baumstruktur werden die Services, Aktionen und Zustandsvariablen der
UPnP-Geräte gelistet. Erst auf dritter Ebene ist das Ausführen einer Ak-
tion möglich. Eine eklatante Schwäche hinsichtlich der Benutzerfreundlich-
keit 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 be-

stehender UPnP-Mechanismen gemacht werden.
• Ein UPnP-basierter GUI-Builder soll für mehrere Plattformen reali-
siert werden. Neben der Entwicklung einer PC-Anwendung mit dem
Supple-Toolkit soll auch ein reduziertes User Interface für Smart Pho-
nes 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-Mecha-
nismus 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-Frame-
work mit einem Bundle zur Kommunikation mit UPnP eingesetzt.
Domoware Base Driver

generate
Exporter Importer Virtual

UPnP Device 2 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 Ho-
mepage).
OSGi-Framework
Um eine Vereinfachung des Entwicklungsprozesses und maximale Kompa-
tibilitä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 Ma-
nagement der OSGi-Plugins (Bundles) verwendet. Durch die enge Bindung
zwischen OSGi-Framework und IDE können OSGi-Bundles in Eclipse ent-
worfen 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/
3
Domoware - http://domoware.isti.cnr.it/
4
Domoware UPnP Base Driver - http://domoware.isti.cnr.it/documentation.html
5.1.2 Setup
Das in Abbildung 5.3 ersichtliche Setup zeigt die Zusammenhänge zwischen
den einzelnen Applikationen. Der GUI-Builder PC ist als OSGi-Bundle ent-
worfen und hat auf die OSGi-internen und, über den Base Driver, auf die ex-
ternen UPnP-Geräte Zugriff. Er nutzt die von den verteilten UPnP-Geräten
zur Verfügung gestellte, XML-Gerätebeschreibung, um anhand dieser Infor-
mation ein User Interface zu generieren.
Das selbe Konzept wird beim mobilen GUI-Builder angewandt. Diese
Anwendung wurde jedoch ohne den Overhead des OSGi-Frameworks ent-
wickelt und besteht aus einer Gateway-Anwendung am PC und einem mo-
bilen Client am Smart Phone. Das Gateway ist ein eigenständiger UPnP-
Controlpoint und bereitet die Informationen der gefundenen UPnP-Geräte
für den Client auf. Ist ein Smart Phone über Bluetooth zum Gateway ver-
bunden, bekommt es die Gerätebeschreibungen übermittelt und generiert ein
GUI zur Fernsteuerung. Die bei der Interaktion durch den Benutzer erzeug-
ten Befehle werden anschließend an das Gateway zurückgeschickt und von
diesem auf dem angesteuerten UPnP-Gerät ausführt. Diese Server/Client-
Architektur 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 ausgela-
gert 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 er-
lä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 Tool-
kits.
• Erweiterung der UPnP-Gerätespezifikation durch die Integration rele-
vanter 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 Eintritts-
punkt in das Programm. Darauf kann eine herkömmliche Java-Applikation
OSGi Core
UPnP
Misc. Device
Bundle Bundle
UPnP
Device
Bundle
> i am quite
sure you can't
read this yerk!
yak '06...
GUI Builder
Basedriver Bundle PC
UPnP Network
UPnP Device
Bluetooth Gateway
Mobile Controlpoint
GUI Builder
Abbildung 5.3: Systemaufbau mit beiden GUI-Builder Applikationen.
aufgebaut werden. Ein Vorteil in der Arbeit mit OSGI ist der Informati-
onsaustausch 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 ent-
hält eine Reihe an vordefinierten Services. Dazu zählt eine einfach gehalten
UPnP-Geräteklasse mit Zugriff auf UPnP-Services, Aktionen und Zustands-
variablen. 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 ak-
tiven und passiven Bundles können Klassen-spezifische Zugriffsrechte mit-
tels einer Manifest-Datei konfiguriert werden. Die Modularität des OSGi-
Konzeptes erlaubt es, eine Softwareanwendung nicht mehr als starres Sys-
tem, sondern als eine Zusammenspiel mehrerer, dynamischer Komponenten
zu begreifen. Dementsprechend muss auch den Beziehungen zwischen den
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 integrier-
ten OSGi-Framework Equinox entwickelt und getestet:
• Domoware Basedriver und Basedriver Extra Bundle: Das Ga-

teway 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 Da-
tenhaltung, Applikationslogik und GUI geachtet. Daraus ergibt sich folgende
Aufteilung der wichtigsten Zuständigkeitsbereiche:
• net.digidop.upnpui.business.data: Das Package ist für das Ma-

nagement der Applikationsdaten und die Kommunikation mit UPnP
zuständig.
• net.digidop.upnpui.gui: Darin sind alle GUI-relevanten Klassen ent-
halten.
• 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 Kompo-
nenten wie das GUI weitergeleitet. Mit der Anmeldung eines Gerätes liegt
dessen funktionale Beschreibung in Form einer objektorientierten Baum-
struktur 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 En-
titäten entlang eines bestimmten Aktionsweges enthält. Dies ist notwendig,
da ausgehend von einer UPnPAction, oft auch auf das Service oder das De-
vice zurückgeschlossen werden muss. Um die Zustände der UPnP-Geräte
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 Zu-
standsvariablen 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 Fen-
sters 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 regu-
lieren. In einem gemeinsamen GUI wären somit der Lichtschalter, die An-
zeige 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 Objek-
ten 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/
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 Infor-
mationsquelle in Form einer UPnP-Gerätebeschreibung ausgewertet werden.
UPnP arbeitet mit Aktionen und Zuständen, die als Parametern für Aktio-
nen eingesetzt werden, um Geräte ansteuern zu können. Sehr oft sind UPnP-
Aktionen 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 Me-
dienplayers und deren Aktionen GetVolume und SetVolume definiert:
1 < actionList >
2 < action >
3 < name > GetVolume </ name >
4 < argumentList >
5 < argument >
6 < name > Volume </ name >
7 < 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>
8 < direction > out </ direction >
9 </ argument >
11 </ action >
12 < action >

13 < name > SetVolume </ name >
14 < argumentList >
15 < argument >
17 < 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>
18 < direction > in </ direction >
19 </ argument >
21 </ action >
22 </ actionList >
23 < serviceStat eT a bl e >
24 < stateVariable sendEvents = " yes " >
26 < dataType > ui1 </ dataType >
27 < defaultValue > 255 </ defaultValue >
28 < allowedValu e Ra ng e >
29 < minimum >0 </ minimum >
30 < maximum > 255 </ maximum >
31 </ allowedValue Ra ng e >
32 </ stateVariable >
33 </ serviceStat eT a bl e >
Das <direction> Element eines Action-Parameters gibt an, ob die re-

ferenzierte Zustandsvariable als Ein- oder Ausgabeparameter gedacht ist.
Im <serviceStateTable> sind die Eigenschaften der Variable spezifiziert. Be-
sondere 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̈n-
derungen 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 ele-
mentarsten, ausführbaren Teil eines Interfaces darstellt. Anhand der Ein-
gangsparameter der Setter -Aktion kann auf die Eigenschaften des referen-
zierten 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 geren-
derten 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-
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 entge-
gengesetzte 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 kei-
nen Ein- oder Ausgabeparametern. Auch Kombinationen sind denkbar. Al-
leine 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 ge-
troffen 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 Konfi-
guration von Einstellungen dient und die Aktion mit einem Bestätigungs-
button 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 an-
satzweise 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 Zustandsvaria-
blen, die neben der Spezifikation des Datentyps und möglichen Einschrän-
kungen des Wertebereichs auch nach einem Bean-Objekt zur Speicherung
des Zustandes verlangen. Erst beim Rendering-Prozess werden die Zustands-
variablen 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 Eigenschaf-
ten die möglichen Render-Ergebnisse ein. Der Datentyp ist zusammen mit
den wertebedingten Einschränkungen der Zustandsvariable und den Eigen-
schaften des Darstellungsgerätes das entscheidende Kriterium zur Generie-
rung des konkreten Interface-Elements. Am Beispiel einer Integer-Variable
mit einer ganzzahligen Einschränkung von 0 − 5 werden Ergebnisse der dy-
namische Elementauswahl von Supple gezeigt. Alle Varianten in Abb.5.5
stellen legale Repräsentationen des Eingangsparameters der UPnP-Aktion
SetFanLevel dar.
<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 Eigenschaf-
ten werden direkt aus der XML-Beschreibung einer UPnP-Aktion, deren Pa-
rameter auf eine UPnP-Zustandsvariable verweist, übernommen.
Datentyp
Der Datentyp der verknüpften UPnP-Zustandsvariable muss in einen Java-
Basisdatentyp 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-Inter-
face eine entsprechende Methode getJavaDataType() zur Verfügung. Die
Konvertierung in den entsprechenden Supple-Datentyp funktioniert eben-
falls nach einem einfachen Mapping-Prinzip. Die Tabelle 5.2.3 zeigt die Kon-
vertierungsschritte.
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 Membervaria-
ble nicht im vorhinein bekannt ist, kann keine statische Bean-Klasse her-
angezogen werden. Für diese Aufgabe wird JavAssist 6 verwendet. Die By-
tecode 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 Zustands-
überwachung ein Objekt der Klasse java.beans.PropertyChangeSupport
mitführt, garantiert Supple die Benachrichtigung aller, an einer Variable in-
teressierten, 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/
UPnP datatype Java datatype Supple datatype

ui1, ui2, ui4 java.lang.Integer, int IntegerTypeImpl
i1, i2, i4, int java.lang.Integer, int IntegerTypeImpl
r4, r8, float java.lang.Float, float IntegerTypeImpl
(not exact)
boolean java.lang.Boolean or BooleanTypeImpl
boolean
string java.lang.String StringTypeImpl,
TextTypeImpl
enum (as Xml-based java.util.Collection StringTypeImpl
string) with collection
constraints
additional formats for any pre-defined additional formats
time, date and url for date and image
Tabelle 5.1: Mapping zwischen UPnP-, Java- und Supple-Datentypen.
ActiveDevice ActionPath Bean

1 n
Supple UIGenerator
Application
Supple
Renderer
Container
TypeImpl UIObject StateVarImpl
1 n
StringTypeImpl SimpleValue
Renderer
Renderer 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 Struk-
tur aus Containern und Komponenten ähnlich dem Java Swing Modell8 auf-
7
Supple Java Doc - http://www.cs.washington.edu/ai/supple/docs/
8
Java Foundation Classes und Swing - http://java.sun.com/products/jfc/
gebaut. Die Zustandsvariablen der Klasse StateVarImpl sind gleichzeitig

Objekte des Interfaces UiObject, die mittels ContainerTypeImpl zu Grup-
pierungen zusammengefasst werden können. Diese Container können wie-
derum 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 Html-
Renderer, 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 plattformspe-
zifischen 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 ver-
teilten 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 GUI-
Builder 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 aus-
geführt werden kann. Der untenstehende Quellcode zeigt den Vorgang in der
ActiveDevice-Methode executeAction():
1 public void executeAction ( ActionPath actionPath ) {
2 Dictionary arguments = new Hashtable ();
3 UPnPAction action = actionPath . getAction ();
4 Map < StateVar , String > stateVarToAr g Na me = actionPath . getMap ();
5
6 for ( StateVar suppleVar : stateVarToA rg Na m e . keySet ()) {
7 Object value = suppleVar . getValue ();
(a) (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 wer-
den.
8 String argName = stateVarToAr g Na me . get ( suppleVar );

9 arg . put ( argName , value );
10 }
11 action . invoke ( arguments );
12 }
5.2.4 UI-Erweiterungen
Da UPnP keine native Unterstützung zur Definition von grafischen Ober-
flächen bietet und die Gerätebeschreibung nicht ausreicht, um die vielschich-
tigen 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 ge-
zogen. Eine davon wurde im Zuge der Implementierung mit den Geräten
getestet.
• Geräteklassen: UPnP definieren einheitliche Standards für Geräte-

klassen, damit herstellerübergreifende Kommunikation zwischen ver-

schiedenen 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 seman-
tische 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 aller-
dings 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̈hnli-

chen 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 Abspiel-
elemente 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 Zusammen-
hang mit dem Vor -Knopf signalisiert. Mit den Kohärenzwerten wird
ein Beziehungsnetzwerk aufgespannt, das für das Layout der Kom-
ponenten 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 Be-

schreibung 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̈tz-
lich zur funktionalen Spezifikation des Gerätes auch noch eine kom-
plette 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̈te-
funktionen definiert. Dieser Ansatz wird im Anschluss anhand zweier
Regeln demonstriert.
Um den UPnP-Gerätestandard mit einem Interface-relevanten Regel-

werk erweitern zu können, wurde folgendes Konzept umgesetzt: UPnP defi-
niert die optionale Angabe einer Präsentations-URL in der XML-basierten
Gerätebeschreibung, die eine optionale Referenz zu einer HTML-basierten
Präsentationsseite beinhaltet [38]. Es bleibt dem Hersteller überlassen, wie

er diese Präsentationsseite gestaltet und mit welchen Inhalten er sie ausstat-
tet. 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 propa-
giert. 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 Inter-
aktionselemente 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 einheit-
licher 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 Unter-
stü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 wer-
den zwei Regeln definiert:
• Gruppierung: Mit einer Gruppierungen kann die Anordnungsreihen-

folge von UPnP-Aktionen und deren Interface-Elementen dezidiert ge-
setzt 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̈rts-
Button liegen.
• Datenquelle: Da in UPnP die Definition der Ein- und Ausgabepara-
metern einer Aktion auf primäre Datentypen beschränkt ist, können
vorerst keine Interface-Elemente gerendert werden, die sowohl dynami-
sche Informationen vom Gerät abfragen als auch senden können. Ein
Beispiel hierfür ist die Auswahlliste: Bei einem Medienplayer muss zu-
erst eine Liste aller verfügbaren Titel im User Interface aufscheinen,
bevor der Benutzer einen Song auswählen und abspielen kann. Das Ele-
ment wird daher aus zwei Aktionen zusammengesetzt. Eine GetPlay-
List-Aktion, die eine Liste der Titel liefert und eine SetSong-Aktion,
die den Titel des aktuellen Songs anwählt. Als Datenquelle der Set-
Song-Aktion wird dementsprechend erstere festgelegt.
Die Abbildungen 5.8(a) und 5.8(b) zeigen die Auswirkungen der Re-
geln auf das Interface-Rendering. Der untenstehende Quellcode gibt Auf-
schluss 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 (b) Regeln aktiviert
Abbildung 5.8: Renderings eines Remote-Interfaces zur Steuerung von

Winamp mit und ohne zusätzliche Regeldefinitionen in der UPnP-
Präsentationsschicht. Die Gruppenregel kommt bei der Anordnung der Con-
trols zu tragen. Die Definition einer Datenquelle führt dazu, dass die Aktio-
nen GetPlayList und SetSong zu einer Auswahlliste zusammengeführt wer-
den.
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 ganz-
zahlige Wertebereich einer Zustandsvariable Volume könnte etwa mit einem
vertikalen und horizontalen Slider, einer Auswahlliste und einem Spinner-
Widget gleich mehrfach grafisch ausgelegt werden.
1 <? xml version = " 1.0 " ? >
2 < upnpui >
3 < groupings >
4 < group name = " Controls " type = " order " description = " " / >
5 </ groupings >
6 < actions >
7 < action name = " SetSong " type = " " >
8 < datasource name = " GetPlayList " type = " enum " / >
9 </ action >
10 < action name = " Start " type = " setter " >
11 < icon path = " start . gif " / >
12 < group name = " Controls " id = " 2 " / >
13 </ action >
14 < action name = " Stop " type = " setter " >
15 < icon path = " stop . gif " / >

17 </ action >
18 < action name = " Pause " type = " setter " >
20 </ action >
21 < action name = " Prev " type = " setter " >
23 </ action >
24 < action name = " Next " type = " setter " >
26 </ action >
27 < action name = " SetVolume " type = " setter " >
28 < widget type = " VerticalSlider " >
29 </ action >
30 </ actions >
31 </ upnpui >
Enumerationsdatentyp:
Ein UPnP-spezifisches Problem ist das Fehlen eines Enumerationsdatentyps,
der unter anderem für den Rückgabeparameter der GetPlayList-Aktion be-
nötigt würde. Um dennoch eine Liste übertragen zu können, wird ein String-
Datentyp 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 < t_list >
2 < element value = " Dave Matthews Band - Satellite " / >
3 < element value = " Incubus - Echo " / >
4 < element value = " Joss Stone - I had a dream " / >
5 </ 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 er-
möglicht die Kommunikation zwischen einem PC-Gateway und einem Smart
Phone via Bluetooth. Die Gateway-Applikation implementiert die UPnP-
Controlpoint 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 Entwicklung mobiler Java-Anwendungen

Ähnlich der Java SE Plattform9 für PC-Applikationen, gibt es für die Ent-
wicklung 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 Konfigura-
tionen, Profile und optionalen Packages, die vom Standardisierungskomitee
Java Community Process(JCP) vorgegeben werden und als Java Specifica-
tion Requests(JSR) den Weg in eine allgemein gültige Spezifikation finden.
J2ME-Technologien werden als JSRs mit einer Nummer versehen. Bei ak-
tuellen Entwicklung für Mobiltelefone muss vor allem auf die Kompatibili-
tä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̈tz-
liche 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̈tzli-
cher 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 Ge-
rätehersteller überlassen ist, weicht das konkrete Erscheinungsbild oft vom
Look and Feel des Simulators ab. Um in der bekannten Java-Entwicklungs-
umgebung Eclipse arbeiten zu können, kann das Plugin EclipseME 13 ver-
wendet werden, das die Schnittstelle zwischen dem WTK und Eclipse bil-
det. Da die Ressourcen mobiler Endgeräte meist begrenzt sind, muss auf
speicheroptimierte Programmierung geachtet werden. Um unnötigen Pro-
grammoverhead 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/
10
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/
Application UPnP
State Controller hierarchical
UPnP Data
Model
Discovery Network
Supervisor EndPoint
Agent
1 n
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 mo-
biler Anwendungen vereinfacht, so bleiben trotzdem einige Unannehmlich-
keiten bestehen. Das Testen der Client-Server Kommunikation ist im Zu-
sammenhang 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 Gemeinsam-
keiten aufweisen, liegt es nahe den Systemaufbau und das Kommunikati-
onsprotokoll 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/
Netzwerk
Die Entwicklung von Java-Anwendungen mit Bluetooth-Unterstützung ist
noch im Anfangsstadium. Da es keine native Java-Unterstützung für Blue-
tooth-Hardware gibt, kommt Open Source Software zur Anwendung. Blue-
Cove 15 , eine Bibliothek zur Java Bluetooth Kommunikation mit dem PC
setzt Teile der JSR82 -Spezifikation um und greift über den Microsoft Blue-
tooth-Stack direkt auf die Hardware zu16 . Für den Mobile GUI-Builder wird
das Bluetooth-Profil Serial Port Profile, das eine serielle Schnittstelle simu-
liert, 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 Klas-
sen 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 Kommu-
nikation mit mehreren Mobile-Clients ausgelegt, jedoch noch nicht in der
Praxis getestet.
Beim Starten des Servers akquiriert die Klasse DeviceInquiry ein Single-
ton 17 -Objekt DiscoveryAgent. Dieser Agent instanziert eine Connection-
Handler-Klasse, die während der Laufzeit des Servers auf eingehende Verbin-
dungsanfragen wartet. Bei einem erfolgreichen Verbindungsaufbau werden
zwei Threads (Reader und Sender) gestartet und in einem Endpoint ge-
speichert 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 ge-
kapselt, 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 Zustands-
ü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/
16
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.
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 Ele-
mente zu reduzieren versucht und sendet sie als Zeichenkette an den Client.
Dieser Vorverarbeitungsschritt ist notwendig, da die beschränkte Rechen-
leistung 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 < service serviceId = " urn:schemas - upnp - o r g : s e r v i c e I d : t e m p : 1"
2 serviceType = " urn:schemas - upnp - org:service : te mp : 1 " >
3 < stateVariable name = " Volume " sendEvents = " yes "
4 dataType = " ui1 " value = " 200 " / >
5 < stateVariable name = " Result " sendEvents = " no "
6 dataType = " boolean " value = " " / >
7 < action name = " SetVolume " >
8 < argument name = " Vol " direction = " in " relatedState = " Volume " / >
9 < argument name = " Re " direction = " out " relatedState = " Result " / >
10 </ action >
11 ...
12 </ 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, XML-
Parser 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/
dauern bis am Smart Phone eine Anfrage an den Benutzer für die Erlaubnis
zum Verbindungsaufbau erscheint. Wird diese bestätigt, werden die UPnP-
Geräteinformationen vom Gateway übertragen und am Smart Phone darge-
stellt.
Die Menüführung wurde in folgender Hierarchie festgehalten: Geräteliste
> Aktionsliste > Parameterliste (siehe Abb. 5.10). Durch Anwahl eines Ge-
rä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̈n-
nen 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 Auszeichnun-
gen 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 ent-
spricht. Dabei berücksichtigt die Bibliothek auch produktspezifische Eigen-
schaften 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) (b)
Abbildung 5.10: Der Mobile GUI-Builder im WTK Simulator. Die Abbil-

dungen zeigen die Geräteliste (a) und die Parameterliste (b).
(a) (b)
Abbildung 5.11: Der Mobile GUI-Builder am Nokia 6600 mit J2ME-Polish

Grafikbibliothek. Die Abbildungen zeigen die Geräteliste (a) und die Akti-
onsauswahl (b) eines Medienplayers.
Kapitel 6
Fazit
Anlass für die Idee der vorliegenden Arbeit war die Erkenntnis, dass ver-
netzte 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 loka-
len Netzwerk angeschlossen sein wird. In diesem Zusammenhang stellt sich
die Frage nach dem Sinn dieser Vernetzung [33]. Die Vision, dass die Wär-
meregulierung 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 verei-
nen 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 techni-
schen Machbarkeit von Netzwerken auch die Vernetzungen von Anwendun-
gen 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̈u-
fig ist und bisher nur in wenigen Mediengeräten integriert ist, so birgt sie
doch großes Potential durch die Standardisierung einer einheitlichen Service-
schnittstelle.
78
KAPITEL 6. FAZIT 79
6.1 Erreichte Ziele

Anhand der entwickelten Geräte und der zwei GUI-Builder Prototypen wer-
den 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̈berwa-
chungskamera 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 Szena-
rio als aktives oder passives Eingabegerät zum Einsatz kommen kann. Sind
die Drucksensoren am Boden angebracht, können sie zum Beispiel das Auf-
treten einer Person registrieren und dieses Ereignis an interessierte Steuer-
instanzen weiterleiten. In einem anderen Fall könnten die Sensoren als Ein-
gabefelder 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 Be-
wegungsmelder 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 er-
ster 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 Soft-
wareadapter 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 be-
dienbare Darstellung (siehe Abb. 5.8) als die bestehenden Controlpoint-
Implementierungen (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 ge-
meinsamen 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 UPnP-
Gerä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 Be-
nutzer 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 wer-
den. 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 Netz-
werke in Kombination mit Eingabegeräten auch für einen weiteren Bereich
interessant. Es stellt sich die Frage, ob mit diesen Technologien auch künst-
lerische 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 Integrationsko-
sten die vorrangige Technologie für Fernsteuerungen von Unterhaltungselektronik. Viele
Hersteller verwenden auf Basis des Lichtsignals ein eigenes, unidirektionales Übertragungs-
protokoll. 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 Netzwerk-
befehle mit ausreichender Geschwindigkeit abgearbeitet werden könnten hat
sich die Architektur von UPnP in diesem Zusammenhang als Nachteil er-
wiesen.
Für jeden ausgesandten Steuerbefehl und jedes Ereignis, das auf SOAP
und dem, in der Netzwerkschicht darunterliegenden, zustandslosen HTTP-
Protokoll aufsetzt, muss eine gesonderte Netzwerkverbindung aufgebaut wer-
den. Dies wurde von UPnP so spezifiziert und auch in der verwendete Java-
Biblothek Cyberlink umgesetzt. Aus diesem Grund liegt die Zeitdauer zwi-
schen 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 be-
dient werden.
Ein Ansatz, um diese Steuerungsproblematik zu lösen ist die Verwendung
anderer Remote Procedure Call 4 -Technologien auf Kosten der Plattformun-
abhä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̈teerken-
nung 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 entschei-
dendes 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 . . . . . Diplomarbeit (PDF-File)
da doppler.ps . . . . . . Diplomarbeit (PostScript-File)
images/ . . . . . . . . . Alle Grafiken der Diplomarbeit im
EPS-Format
A.2 Literatur
Pfad: /docs/
index.html . . . . . . . . Link-Liste der Literaturquellen
Der Ordner enthält nach einzelnen Kapiteln geordnet alle Online-Literatur-
quellen als PDF-Files.
A.3 Anwendungen
Pfad: /applications/
info.pdf . . . . . . . . . Anleitung für die Inbetriebnahme und das
Arbeiten mit den Geräten.
guibuilder pc setup.exe Installierbare Win32 -Version des PC
GUI-Builders
guibuilder pc.zip . . . . Zip-Datei des PC GUI-Builders
82
ANHANG A. INHALT DER CD-ROM 83
guibuilder mobile.zip . . Zip-Datei des mobilen GUI-Builders für das

Smart Phone (getestet am Nokia 6600 )
devices setup.exe . . . . Installierbare Win32 -Version der Geräte
devices.zip . . . . . . . Zip-Datei des Geräte
A.4 Quellcode
Pfad: /source/
/guibuilder pc/ . . . . . Alle Eclipse-Plugin-Projekte, die für den
GUI-Builder benötigt werden.
/guibuilder mobile/ . . Eclipse-Projekt des mobilen GUI-Builders
/devices/ . . . . . . . . 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 Appli-
cations. 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 Edi-

tion). URL, http://www.w3.org/TR/xforms/, March 2006. Kopie auf
CD-ROM.
[7] Choy, H. und A. Fuchs: Developing Innovative Devices Using Uni-

versal 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 Com-

puting. 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 fernbe-

dienen - 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 durch-

dringt 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. Hen-

ning, J. J. Long und D. Weld: Fast And Robust Interface Generation
for Ubiquitous Applications. In: Proceedings of the Seventh Internatio-
nal Conference on Ubiquitous Computing (UBICOMP 2005), Tokyo,
Japan, September 2005.
[16] Gajos, K. und D. S. Weld: Automatically Generating User Interfa-

ces 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 Op-

timization. In: UIST ’05: Proceedings of the 18th annual ACM sympo-
sium 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. Adap-

tive Path LLC, 18. Februar 2005 . URL, http://www.adaptivepath.com/
publications/essays/archives/000385.php, February 2005. Kopie auf CD-
ROM.
[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 sy-
stem for low-power wireless control networks. In: 2004 IEEE Interna-
tional Conference on Mobile Ad-hoc and Sensor Systems, 2004.
[22] Jeronimo, M. und J. Weast: UPnP Design by Example — A Soft-

ware Developer’s Guide to Universal Plug and Play. Intel Press, Hills-
boro, Oregon, 2003.
[23] Jespersen, J. W. und J. Linvald: Investigating user interface engi-

neering 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 De-

sign 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 Rea-
der 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 Gene-

ration from Declarative Models. In: Proceedings of CADUI 1996 , S.
3–18, 1996.
[33] Sietmann, R.: Muss man alles und alle vernetzen ? — Natascha Ada-
mowsky 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.
[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, Medien-
technik 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

UPnP Diplomarbeit

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UPnP Diplomarbeit

Hochgeladen von

Copyright:

Verfügbare Formate

Entwicklung verteilter Geräte und

Anwendungen für die UPnP Plattform

Alle Rechte vorbehalten

Hagenberg, am 26. Juni 2006

4 Generierung graﬁscher User Interfaces 28

A Inhalt der CD-ROM 82

Getragen von der rasanten Entwicklung mobiler und eingebetteter Geräte,

Advances in mobile and embedded technology and communication stan-

Längst hat sich das Internet als globales Kommunikationsnetzwerk etabliert.

werden können und entweder passiv Informationen über Personen in der

Kapitel 4 beschäftigt sich mit vorhandenen Systemen und XML-Sprach-

Kapitel 5 demonstriert und dokumentiert die praktische Anwendbarkeit

Kapitel 6 ist eine Zusammenfassung der gewonnenen Erkenntnisse und

2.1.1 Technische Details

vCard/vCal IP TCS BIN

Abbildung 2.1: Bluetooth Stack Architektur (siehe [31]).

Protocol Layer Protocols

Tabelle 2.1: Bluetooth-Architektur Protokollschichten (siehe [5]).

Core Protocols: Das Baseband sorgt für die physikalische Verbindung

Cable Replacement Protocol - RFCOMM: Zur Emulation des se-

Telephony Control Protocols: Auf Empfehlung der International Te-

Adopted Protocols: Um mit IP basierten Protokollen wie TCP und

2.1.4 Vergleichbare Funktechnologien

Java Spaces Other Services

Discovery & Join Jini

Java Virtual Machine

Abbildung 2.2: Jini Architektur (siehe [24]).

Schichten: das Discovery-Managment, den darüber liegenden Lookup-Service

Discovery: Eine Netzwerkkomponente oder ein Service nutzen das Mul-

Abbildung 2.3: Das Jini-Kommunikationsmodell (vereinfachte Darstellung

det, um gezielt mit einem Lookup Service kommunizieren zu können. Als

Join: Diese Phase beschreibt die Prozedur der Service-Registrierung bei

Gerät: Ein UPnP-Gerät beinhaltet Dienste (Services) und kann in einer

UPnP Device Architecture

GENA SSDP SOAP GENA

HTTPMU HTTPU HTTP

Abbildung 2.4: Aufbau der UPnP Architektur (siehe [22]).

Aufbau der UPnP-Stack Architektur

Addressing: Eine Voraussetzung für die automatische Geräteerkennung

Control Eventing Presentation

DHCP-Clients am Gerät. Der Client sucht beim Anschluss an das Netz-

Discovery: Nachdem das Device erreichbar ist, beginnt es eigenständig

• Herstellerspeziﬁsche Angaben wie Modellname, Modellnummer, Seri-

XML-SOAP Nachrichten werden Aktionsaufrufe an die Geräte-URL ge-

Presentation: Bei vielen Geräten ist eine Präsentations-URL enthalten,

Komponentenbasierte Architektur: Aufbauend auf einem Framework

Integration bestehender Protokollstandards: Der generische Ansatz

Dynamisches Management: OSGi-Bundles können zur Laufzeit admi-

Integriertes Sicherheitsmodell: Die Softwarearchitektur von OSGi er-

• Geräte: Für das oben erwähnte Szenario müssen UPnP-fähige Hard-

• GUI-Builder: Genauso wie mit UPnP ein gemeinsames Steuerpro-

• Framework zur Kopplung verteilter Geräte: Auf Basis von UPnP

Abbildung 3.1: Torem - Ein Framework zur Kopplung verteilter UPnP-

gebenen Zeitpunkt wenige Geräte-Standards2 , die für die Mediensteuerung

• Intel Software for UPnP Technology: Intel’s UPnP-Implemen-

• AVR Embedded Internet Toolkit: Mit dem Embedded Internet

• Sindrion: Sindrion ist eine verteilte Systemarchitektur rund um einen

UPnP-Serviceplattform erwähnt. Demnach ist ein Sindrion Wireless-

Abbildung 3.2: Die Abbildung zeigt die Befehlskette einer Sensorabfrage

3.4.2 Webcam Streaming-Server und Client

ermittelt über UPnP automatisch das Vorhandensein eines Servers, liest

• net.digidop.upnp.device.rtpapp: Dieses Packet deﬁniert das Zu-

• net.digidop.upnp.device.rtpserver.business: Diese Schicht de-

• net.digidop.upnp.device.rtpserver.ui: Das Packet enthält Klas-