97
Entwicklung verteilter Ger¨ ate und Anwendungen f¨ ur die UPnP Plattform unter besonderer Ber¨ ucksichtigung automatisch generierter User Interfaces Jakob S. Doppler DIPLOMARBEIT eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im Juni 2006

UPnP Diplomarbeit

Embed Size (px)

Citation preview

Page 1: UPnP Diplomarbeit

Entwicklung verteilter Gerate undAnwendungen fur die UPnP Plattform

unter besonderer Berucksichtigungautomatisch generierter User Interfaces

Jakob S. Doppler

D I P L O M A R B E I T

eingereicht am

Fachhochschul-Masterstudiengang

Digitale Medien

in Hagenberg

im Juni 2006

Page 2: UPnP Diplomarbeit

c© Copyright 2006 Jakob S. Doppler

Alle Rechte vorbehalten

ii

Page 3: UPnP Diplomarbeit

Erklarung

Hiermit erklare ich an Eides statt, dass ich die vorliegende Arbeit selbst-standig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellenund Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenenStellen als solche gekennzeichnet habe.

Hagenberg, am 26. Juni 2006

Jakob S. Doppler

iii

Page 4: UPnP Diplomarbeit

Inhaltsverzeichnis

Erklarung iii

Vorwort vii

Kurzfassung viii

Abstract ix

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Technische Begriffserklarungen 42.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Technische Details . . . . . . . . . . . . . . . . . . . . 42.1.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Vergleichbare Funktechnologien . . . . . . . . . . . . . 7

2.2 Service-Plattformen . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 JINI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Gerate 173.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 UPnP-Technologie . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.1 Sensor-Hardwaredevice . . . . . . . . . . . . . . . . . . 203.4.2 Webcam Streaming-Server und Client . . . . . . . . . 233.4.3 UPnP-Winamp Media Player . . . . . . . . . . . . . . 263.4.4 MIDI-Device . . . . . . . . . . . . . . . . . . . . . . . 26

iv

Page 5: UPnP Diplomarbeit

INHALTSVERZEICHNIS v

4 Generierung grafischer User Interfaces 284.1 Anforderungen im GUI-Design . . . . . . . . . . . . . . . . . 294.2 Anforderungen im Pervasive Computing . . . . . . . . . . . . 30

4.2.1 Kontext-sensitive und verteilte Anwendungen . . . . . 304.2.2 Gerateeigenschaften . . . . . . . . . . . . . . . . . . . 31

4.3 Techniken der GUI-Entwicklung . . . . . . . . . . . . . . . . . 324.3.1 Window Manager und Toolkits . . . . . . . . . . . . . 324.3.2 Web-basierte Entwicklungen . . . . . . . . . . . . . . . 324.3.3 Interaktive GUI-Builder . . . . . . . . . . . . . . . . . 34

4.4 XML GUI-Sprachen . . . . . . . . . . . . . . . . . . . . . . . 344.4.1 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4.2 XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.3 XForms . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.4 UIML . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4.5 XIML . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5 Model-based User Interface . . . . . . . . . . . . . . . . . . . 424.5.1 User Interface Generierung . . . . . . . . . . . . . . . 444.5.2 Projekt – Pebbles Personal Universal Controller . . . 444.5.3 Projekt – Supple . . . . . . . . . . . . . . . . . . . . . 48

5 GUI-Builder 535.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 System-Schnittstellen . . . . . . . . . . . . . . . . . . 545.1.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 Implementierung - PC . . . . . . . . . . . . . . . . . . . . . . 565.2.1 Entwicklung mit OSGi . . . . . . . . . . . . . . . . . . 565.2.2 Systemaufbau . . . . . . . . . . . . . . . . . . . . . . . 585.2.3 GUI-Generator . . . . . . . . . . . . . . . . . . . . . . 605.2.4 UI-Erweiterungen . . . . . . . . . . . . . . . . . . . . 66

5.3 Implementierung - Smart Phone . . . . . . . . . . . . . . . . 705.3.1 Entwicklung mobiler Java-Anwendungen . . . . . . . . 715.3.2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 725.3.3 Mobile Client . . . . . . . . . . . . . . . . . . . . . . . 74

6 Fazit 786.1 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.1.1 Gerate . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.1.2 GUI-Builder . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A Inhalt der CD-ROM 82A.1 Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 82A.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82A.3 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Page 6: UPnP Diplomarbeit

INHALTSVERZEICHNIS vi

A.4 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Literaturverzeichnis 84

Page 7: UPnP Diplomarbeit

Vorwort

Mit der Fertigstellung der vorliegenden Diplomschrift geht ein weiterer Ab-schnitt in meinem Leben zu Ende. Der Blick zuruck an den Beginn desStudiums lasst mich kaum glauben, dass seither funf Jahre vergangen sind.Auch wenn die Zeit an der Fachhochschule Hagenberg mit viel Arbeitsauf-wand und Engagement verbunden war, mochte ich sie dennoch nicht missen.Viele gute Erinnerungen und lehrreiche Erfahrungen in fachlicher als auchin menschlicher Hinsicht tragen zu diesem positiven Eindruck bei.

Die Faszination der Technik liegt fur 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 zueinem technologischen Fortschritt beizutragen, der in Einklang mit den Be-durfnissen und Werten unserer Gesellschaft steht. Daher scheint es auchangemessen, jene Personen zu nennen, die mir das Gefuhl geben eben dieseserreichen zu konnen.

Im Rahmen einer mehrjahrigen Forschungsarbeit konnten mit meinemProjektpartner und Freund Bernhard Wally neue Aspekte einer intelligen-ten und vernetzten Geratelandschaft beleuchtet werden, wie sie in ein paarJahren vielleicht in jedem Haushalt zu finden sein wird. Dafur und fur dievielen, teils lustigen Stunden gemeinsamen Wirkens sei ihm gedankt. Auchmeinem Betreuer DI Dr. Christoph Schaffer, der mir im Laufe meines Di-plomstudiums in zahlreichen Gesprachen mit guten Ratschlagen und fachli-chem Wissen zur Seite gestanden ist, gilt mein besonderer Dank.

Die Erkenntnis, dass das Leben neben der Schonheit der Technik auchnoch andere, ebenso wichtige Facetten zu bieten hat, habe ich zweifelsohnemeiner Familie und den zahlreichen, guten Freundschaften in Hagenbergund 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 ermoglichten.

vii

Page 8: UPnP Diplomarbeit

Kurzfassung

Getragen von der rasanten Entwicklung mobiler und eingebetteter Gerate,bringen einheitliche Kommunikationsstandards eine neue Qualitat fur dieim Netzwerk verteilten Anwendungen. Es existiert der Wunsch nach in-telligenten Diensten, die in der eigenen Umgebung und in verschiedenstenLebenssituationen in Anspruch genommen werden konnen. Ein weitgehendungeklarter Aspekt in diesem Zusammenhang sind Automatismen fur dieDarstellung und Interaktion mit diesen verteilten Diensten.

Im Rahmen der vorliegenden Arbeit werden auf Basis der UPnP Service-Plattform verschiedene Gerate und Anwendungen fur ein mogliches Medien-steuerungsszenario beleuchtet. Der erste Schwerpunkt liegt in der Entwick-lung von Eingabemedien. Anhand eines sensorbasierten Hardwaredevicesund einer Kamera mit Bewegungserkennung soll in Verbindung mit einemUPnP-basierten Framework zur Verknupfung von Geratediensten die Fa-higkeit zur dynamischen Vernetzung und Ansteuerung anderer, verteilterGerate demonstriert werden.

Im zweiten Teil werden Anforderungen fur die automatisierte Generie-rung von User Interfaces zur Fernsteuerung der Dienste ermittelt. Der Be-nutzer soll unabhangig vom Ort und der Plattform des darstellenden Endge-rates mit den netzwerkbasierten Anwendungen interagieren konnen. Anhandzweier Prototypen fur den PC und fur das Smart Phone wird die technischeMachbarkeit dieses Ansatzes gezeigt.

viii

Page 9: UPnP Diplomarbeit

Abstract

Advances in mobile and embedded technology and communication stan-dards for distributed device computing offer new opportunities for homeappliances. This trends reflects a deep longing for smart and sophisticatedservices that help us in everyday life activities. But taking automated rep-resentation and interaction with these services into account, there are stilla 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 firstidea places emphasis on prototyping input devices for a UPnP-based mediacontrol framework. Thus methods for integrating a sensor-based device anda 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 inchoosing their favorite environment for application usage, two GUI buildingapplications to remotely control these services were implemented. The firstone is based on the PC platform. The second one tries to employ the remotecontrol metaphor by using a smart phone.

ix

Page 10: UPnP Diplomarbeit

Kapitel 1

Einleitung

Langst hat sich das Internet als globales Kommunikationsnetzwerk etabliert.Waren die Anfange des Mediums vorrangig von der schnellen Verbreitungund Beschaffung von Informationen gepragt, so kam im Laufe der Zeit einweiterer Aspekt zur Geltung: Die Nutzung von automatisierten Dienstlei-stungen in Echtzeit zeigte neue Qualitaten der Vernetzung auf und sichertederen nachhaltigen Erfolg. Analog dazu vollzog sich auch im Softwaredesignein grundlegender Wandel von maßgefertigten Einzellosungen zu der Ideevon interoperablen Applikationen, die durch die gemeinsame Standardisie-rung von Technologien getragen wird. Erwahnenswert hierfur ist die univer-selle Beschreibungssprache XML (Extended Markup Language), die fur dieReprasentation verschiedenster Daten herangezogen wird.

Diese Entwicklung entfacht den Wunsch nach intelligenten Diensten, dieauch in der eigenen Umgebung und in verschiedensten Lebenssituationenin Anspruch genommen werden konnen [13]. Der Benutzer soll unabhangigvon Ort und Zeit mit kontextsensitiven Anwendungen1 interagieren konnen.Moglich wird dies durch die zunehmende Verbreitung von Embedded Sy-stems2 und mobilen Endgeraten wie dem PDA (Personal Digital Assistant),dem Mobiltelefon oder dem Laptop, die mit Nah- und Fernfunktechnologienausgestattet sind. In diesem Zusammenhang spricht man von UbiquitousComputing3. Die Begriffe bezeichnen die alles durchdringende Vernetzungvon ”intelligenten Gegenstanden“ des Alltags [40]. Organisationen wie dieDigital Living Network Association (DNLA)4 beschaftigen sich mit den An-forderungen, die es am Weg zur universellen Vernetzung von Geratedienstenim Haushalt zu erfullen gilt und dem moglichen Mehrwert, der daraus ge-neriert werden kann.

1Kontextsensitive Anwendungen besitzen die Fahigkeit, sich an aktuelle Gegebenheitenund Umwelteinflusse anzupassen.

2

”Eingebettete“ Computersysteme, die fur den Benutzer - meist unsichtbar - Dienste

verrichten und auf spezialisierter Hardware basieren und mit Sensoren ausgestattet sind.3auch Pervasive Computing4DNLA - http://www.dnla.org

1

Page 11: UPnP Diplomarbeit

KAPITEL 1. EINLEITUNG 2

1.1 Motivation

Der Grundstein fur die Realisierung der Vision einer pervasiven Umgebungscheint mit den fortschreitenden Entwicklungen von mobilen und Embedded-Technologien gelegt. Ein weitgehend ungeklarter Aspekt hingegen sind Stan-dards und Automatismen fur die Darstellung und Interaktion mit verteiltenDiensten.

Service-Plattformen wie Universal Plug and Play (siehe Kapitel 2.2.2)sind plattformunabhangige Software-Bibliotheken, die dem Entwickler diegroße Verantwortung hinsichtlich einheitlicher Gerateschnittstellen und au-tomatischer Erkennung der Netzwerkdienste abnehmen und diese von einembeliebigen Ort aus fernsteuerbar und uberwachbar machen. Sie treffen jedochkeine Entscheidungen hinsichtlich der Reprasentation der Interaktionsdaten.

Aus diesen Uberlegungen entsteht die Idee sowohl Eingabegerate fur denEinsatz in einem Mediensteuerungsszenario zu entwickeln, als auch For-schung in Richtung der automatisierten Generierung von User Interfaceszur Fernsteuerung von verteilten Geraten zu betreiben. Erstere ist Teil eineslang ersehnten Wunsches, den PC als vorrangiges Interaktionsmedium furcomputerisierte Dienste ablosen zu konnen. In diesem Zusammenhang wirdein Weg gesucht, um Sensorik und die Bewegungserkennung einer Kameraals Ausloser zur Steuerung verteilter Netzwerkdienste nutzen zu konnen.

Die zweite Idee befasst sich mit Interaktionen, in denen ein Display hin-gegen notwendig und sinnvoll ist. Hierfur muss ein Konzept zur automati-sierten Generierung von User Interfaces im Kontext verteilter Gerate undAnwendungen erstellt werden. Moglich wird dies durch die Architektur vonUPnP. Wird ein neues Gerat dem Netzwerk hinzugefugt, werden alle inter-essierten Teilnehmer daruber informiert und erhalten eine funktionale Be-schreibung der Geratedienste. Diese Beschreibung kann genutzt werden, umein Interface zur Steuerung des Gerates darzustellen.

Da die Problemstellung der automatisierten Generierung von User In-terfaces nicht alleine auf die Domane der verteilten Netzwerke beschranktist, gibt es einige, vielversprechende Ansatze. Mehrere XML-basierte Spra-chen und GUI-Building Systeme (siehe Kapitel 4) bieten Losungsansatzeauf verschiedenen Abstraktionsebenen an. Diese reichen von einer konkre-ten Beschreibung und Positionierung der Steuerelemente bis hin zu einerVerknupfung zwischen den Interaktionsdatentypen der Geratefunktion undabstrakten Elementen, denen abhangig von den Vorgaben der Plattform eineandere grafische Reprasentation zukommt.

1.2 Abgrenzung

Ziel der Arbeit ist die Nutzung der UPnP Service-Plattform zur Erstellungnetzwerkbasierter Gerate, die in einen Wohn- und Arbeitsraum integriert

Page 12: UPnP Diplomarbeit

KAPITEL 1. EINLEITUNG 3

werden konnen und entweder passiv Informationen uber Personen in derUmgebung beziehen oder als physisches Interaktionsmedium einsetzbar seinsollen. Zudem mussen, um im Netzwerk verteilte Geratedienste unter einemgemeinsamen User Interface Standard ansprechen zu konnen, bestehendeUser Interface-Auszeichnungssprachen und GUI-Building Systeme zur Fern-steuerung einer UPnP-Geratelandschaft evaluiert werden.

Anhand prototypischer Implementierungen soll der Einsatz der Techno-logie in einem Mediensteuerungsszenario gerechtfertigt werden. Dazu zahlenmit einem Sensormodul und einer Kamera zur Bewegungserkennung mehrereUPnP-fahige Gerate. Weiters soll die Generierung grafischer User Interfaceszur Fernsteuerung der verteilten Anwendungen am PC und fur die SmartPhone-Plattform demonstriert werden.

Die Arbeit ist in zwei Bereiche unterteilt. Der erste befasst sich mit dentechnischen Vorrausetzungen und der Erstellung der Gerate. Im zweiten Teilwerden die Ergebnisse der Recherche zur automatisieren User Interface Ge-nerierung anhand zweier Prototypen beleuchtet. Die Schwerpunkte umfassenjeweils zwei Kapitel:

Kapitel 2 stellt die technischen Vorraussetzungen fur die Arbeit mit denGeraten vor. Es wird der Funkstandard Bluetooth beleuchtet und die WahlUPnP als bevorzugte Service-Plattform vorgestellt.

Kapitel 3 versucht mit einem pervasiven Szenario die Intention der Arbeitzu erklaren und beleuchtet anhand der entwickelten Gerate den ersten Teilder Implementierung.

Kapitel 4 beschaftigt sich mit vorhandenen Systemen und XML-Sprach-definitionen rund um das Thema einer generischen Beschreibung und Gene-rierung von grafischen Benutzeroberflachen.

Kapitel 5 demonstriert und dokumentiert die praktische Anwendbarkeiteiner generischen Mediensteuerung fur verteilte Gerate anhand zweier pro-totypischer GUI-Builder Anwendungen fur PC und Smart Phone.

Kapitel 6 ist eine Zusammenfassung der gewonnenen Erkenntnisse undwagt einen Ausblick in die nahe Zukunft.

Page 13: UPnP Diplomarbeit

Kapitel 2

TechnischeBegriffserklarungen

2.1 Bluetooth

Durch den Bedarf einer kostengunstigen Technologie mit niedrigem Energie-verbrauch als Ersatz fur kabelgebundene Kommunikation, wurde 1994 vondem Mobilfunkunternehmen Ericsson die Bluetooth-Technologie1 ins Lebengerufen. Das rege Interesse namhafter Hersteller wie IBM, Intel und Nokiafuhrte zur Grundung des Entwicklerkonsortiums Bluetooth Special InterestGroup (Bluetooth SIG)2 und zur Erhebung von Bluetooth zum Industrie-standard gemaß IEEE3 802.15.1. Wenngleich auch die flachendeckende Ein-fuhrung von Anfang an in einer allgemeinen Euphorie prognostiziert wurde,vergingen einige Jahre bevor die Akzeptanz gegeben und eine genugendeVerbreitung an Endgeraten mit Bluetooth-Hardware gegeben war.

2.1.1 Technische Details

Die Datenubertragung bei Bluetooth erfolgt uber das lizenzfreie ISM-Fre-quenzband im Bereich zwischen 2,400 GHz und 2,480 GHz [31]. Da diesesBand jedoch von einer Vielzahl an Funktechnologien, darunter auch derWLAN-Standard (IEEE 802.11) oder die Schnurlostelefonie, genutzt wird,braucht es ein robustes Verfahren um die Ubertragungsqualitat zu gewahrlei-sten. Diese Robustheit wird durch ein Frequenzsprungverfahren (FrequencyHopping) garantiert. Darunter versteht man den Wechsel des Tragersignalsalle 625 µs zwischen den bei Bluetooth definierten 79 Frequenzstufen im1-MHz Abstand. Die maximale Ubertragungsrate liegt dabei in den Versio-nen 1.1 und 1.2 bei 723,1 kbit/s und in der verbesserten Version 2.0 EDR

1Bluetooth - http://www.bluetooth.com/2Bluetooth SIG - https://www.bluetooth.org/3IEEE (Institute of Electrical and Electronics Engineers) - http://ieee.org- eine Insti-

tution zur Standardisierung von Computertechnologien

4

Page 14: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 5

�������������

� ����

���

�����

�������

�������

��

�������

��

��

!�"��!��

����##��

���

�����

���

$����

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

(Enhanced Data Rate) bei 2,1 Mbit/s. Um der Anforderung einer kosten-gunstigen und energiesparenden Funktechnologie gerecht zu werden, wurdendrei Leistungsklassen fur verschiedene Einsatzzwecke geschaffen. Klasse 1-Gerate sind fur eine Reichweite von bis zu 100 m bei einer Leistung von100 mW konzipiert. Am anderen Ende liegen Klasse 3-Gerate mit 1 m und1 mW. Die breite Palette der Unterhaltungselektronik und mobilen Endge-rate arbeitet mit Klasse 2-Chips bei einem Verbrauch von 2,5 mW und einerReichweite bis zu 10 m [31].

In einem Bluetooth Netzwerk (Piconet) konnen sich bis zu 65.000 Geratebefinden, von denen jedoch nur acht aktiv sein durfen. Ein Master-Geratsorgt fur sie Synchronisation der sieben Slaves. Ein Bluetooth-Teilnehmerkann sich in mehreren Netzwerken aufhalten, wodurch eine netzwerkuber-greifende Kommunikation moglich wird. Der Zusammenschluss mehrerer Pi-conets bezeichnet man als Scatternet.

2.1.2 Architektur

Der Bluetooth Protokollstack wurde von der Bluetooth SIG entworfen undenthalt eine Sammlung hierarchisch angeordneter Protokolle (siehe Abbil-dung 2.1). Erklarte Designziele waren eine bindende Richtlinie fur die Im-plementierung von Bluetooth-Geraten und maximale Interoperabilitat durchdie Wiederverwendung alterer Kommunikationsprotokolle in den hoherenSchichten. Die Protokolle werden in vier grundlegende Schichten eingeteilt[31] (siehe Tabelle 2.1.2).

Page 15: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 6

Protocol Layer ProtocolsBluetooth Core Protocols Baseband, LMP, L2CAP, SDPCable Replacement Protocol RFCOMMTelephony Control Protocols TCS Binary, AT-commandsAdopted Protocols PPP, TCP/UDP/IP, OBEX,

WAP, vCard, cCal, IrMC,WAE

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

Core Protocols: Das Baseband sorgt fur die physikalische Verbindungund die Synchronisation der Netzwerkteilnehmer mittels des zuvor erwahn-ten Frequenzsprungverfahrens. Echtzeitkritische Audiodaten werden eben-falls ohne zusatzlichen Overhead uber dieses Protokoll ubertragen. Das LinkManager Protocol (LMP) ist fur den Verbindungsaufbau zwischen den Blue-tooth-Geraten sowie Authentifizierung und Verschlusselung zustandig. DasLogical Link Control and Adaption Protocol (L2CAP) fungiert als Vermitt-lungsschicht zwischen hoherliegenden Protokollen und dem Host ControllerInterface (HCI). Gerate- und Dienstinformationen konnen nach erfolgreicherVerbindung mit dem Simple Discovery Protocol (SDP) abgefragt werden.

Cable Replacement Protocol - RFCOMM: Zur Emulation des se-riellen Datenubertragungskanal RS232 wurde die RFCOMM -Schnittstellegeschaffen. Dadurch konnen eine große Anzahl an hoherliegenden Protokol-len ohne Anpassungsaufwand auch uber 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 zusatzliche TelephonyControl Protocol - Binary (TCS Binary) zeichnet sich fur den Verbindungs-aufbau von Daten- und Sprachubertragung verantwortlich.

Adopted Protocols: Um mit IP basierten Protokollen wie TCP undUDP kommunizieren zu konnen, wurde das Point-to-Point Protokoll (PPP)entwickelt. Es verwaltet den Paketversand des Bluetooth-Gerates und er-moglicht 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 ermoglicht den schnellen Austausch von Ob-jekten ohne den Transportkanal, in diesem Fall RFCOMM, zu definieren.Ein Verwendungszweck ist das Synchronisieren von Kalendern (vCal) unddas Austauschen von Business Cards (vCard).

Page 16: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 7

2.1.3 Profile

Im Vergleich zu anderen Funktechniken wie WLAN, die einmal spezifiziertwerden und eine starre Auslegung verlangen, lebt die Bluetooth-Spezifika-tion vor allem durch ihre hochgradige Flexibilitat und Erweiterbarkeit. Ver-antwortlich dafur ist der vielschichtige Aufbau der Bluetooth-Architektur.Um den verschiedenartigen Anwendungsmoglichkeiten fur unterschiedlicheGerateklassen gerecht werden zu konnen, bedarf es eines komponentenba-sierten Ansatzes, der es durch einfachen Austausch von Protokollen schafft,die gewunschten Szenarien abzudecken. Aufbauend auf einem generischenProtokollstack setzen spezifischere Protokolle auf, die in einer Vererbungs-hierarchie angeordnet sind [20]. Profile sind Kombinationen dieser Kompo-nenten, die bestimmte Ruckschlusse auf den Aufbau und die Zusammenset-zung des Bluetooth Protokollstacks zulassen. Die Interoperabilitat zwischenzwei Bluetooth-Geraten ist von der Unterstutzung der gemeinsamen Profileabhangig. Beim Verbindungsaufbau tauschen die Teilnehmer diese aus undermitteln, 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, dieEin- und Ausgabe auf Endgeraten (FAX, Drucker) oder die Ubertragung vonAudiodaten uber Headset und Mobiltelefon definieren. Erwahnenswert ist indiesem Zusammenhang eine Reihe an Profilen, die fur die Mediensteuerunginteressant sind. Das Personal Area Network -Profil definiert, wie sich allein Reichweite befindlichen Gerate zu einem Ad-Hoc PAN-Netzwerk zusam-menschließen konnen und Zugang zu einem LAN erhalten. Einen weiterenSchritt in Richtung Vernetzung von Diensten geht die Bluetooth SIG mitdem Entwurf fur das Extended Service Discovery Protocol (ESDP), das zurErkennung von UPnP Geraten herangezogen werden soll. Die Liste der Pro-file ist einer standigen Veranderung unterworfen und wird von der BluetoothSIG verwaltet4.

2.1.4 Vergleichbare Funktechnologien

Im den letzten Jahren entwickelte sich rund um die Idee des Mobile Compu-ting und die dadurch gewonnene Ortsunabhangigkeit ein kompetitives Ge-schaft. Neben Bluetooth drangen eine Menge ahnlicher Technologien auf denMarkt und eine steigende Anzahl an multifunktionalen Endgeraten mit un-terschiedlichsten Anforderungen tragen ihren Teil dazu bei, dass die Wahlnicht immer leicht fallt. Waren die Grenzen zwischen Wireless LAN undBluetooth anfangs noch relativ klar definiert, kann eine Uberschneidung mitTechnologien wie ZigBee, Near Field Communication (NFC) und Radio Fre-

4Eine aktuelle Liste der Bluetooth Profil-Spezifikationen findet sich unter http://bluetooth.com/Bluetooth/Learn/Technology/Specifications/. Eine Liste der Entwurfe ist un-ter https://www.bluetooth.org/spec/ abrufbar

Page 17: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 8

quency Identification (RFID) nur schwer geleugnet werden5. Dies ruft auchunweigerlich Probleme in der Standardisierung durch die IEEE auf den Plan,wie sie im aktuellen Formatstreit um Ultra Wide Band (UWB), das als Basisfur das zukunftige drahtlose USB gilt, ersichtlich sind. Bluetooth wird den-noch an den Spezifikation der beiden gegensatzlichen Konsortien WiMediaAlliance6 und dem UWB Forum7 mitwirken, verspricht UWB doch großeDatenubertragungsraten bei niedrigstem Energieverbrauch.

2.2 Service-Plattformen

Technologien wie Jini8 und Universal Plug and Play (UPnP)9 wurden ent-wickelt, um Ordnung in die heterogene Landschaft verteilter Gerate undDienste zu bringen und die gegenseitige Kommunikation zu ermoglichen.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-Terminologiedie Vernetzung meist mobiler Gerate ohne das Vorhandensein einer festenInfrastruktur. Die Konzepte und Unterschiede der beiden Standards wer-den im folgenden Kapitel naher erlautert. Im Anschluss wird mit OSGi eingenerisches Service-Framework Open Service Gateway Initiative (OSGi)11

vorgestellt, das die beiden konkurrierenden Netzwerk-Technologien in einemgemeinsamen Standard zu vereinen versucht.

2.2.1 JINI

Allgemeines

Jini wurde 1999 als verteilte Netzwerktechnologie schon viele Jahre vorUPnP ins Leben gerufen. Die Architektur wurde von Sun entworfen und ver-wendet gangige Java-Technologien [35]. Jini kann auf einem beliebigen Netz-werkprotokoll aufsetzen, ist aber an eine vorhandene Laufzeitumgebung, dieJava Virtual Machine (JVM), und dadurch an die Konzepte der Program-miersprache Java gebunden. Dies ist ein entscheidender Nachteil im Vergleichzur generischeren Auslegung des Konkurrenten UPnP (siehe Kapitel 2.2.2)

Auf Basis der Virtual Machine setzten Jini’s eigene Netzwerkprotokolleund das Java Remote Methode Invocation-Modell (RMI) fur den Aufruf vonentfernten Objekten im Netzwerk auf. Die Jini-Bibliothek umfasst die oberen

5Eine Gegenuberstellung verschiedener Wireless-Technologien und deren Einsatzzweckefindet sich unter http://bluetooth.com/Bluetooth/Learn/Technology/Compare/

6WiMedia Alliance - http://www.wimedia.org7UWB Forum - http://www.uwbforum.org/8Jini - http://www.jini.org9UPnP - http://www.upnp.org/

10Ein Uberblick uber bestehende Protokolle zur Diensterkennung finden sich in [25]11OSGi - http://osgi.org/

Page 18: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 9

%!�&�"�����'����

�� '�!�"(�)�%���

��

���*�+

%!��+'� ����"���"!�'�

%���

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

Schichten: das Discovery-Managment, den daruber liegenden Lookup-Serviceund die Applikationsschicht, die sich in Client-Anwendungen, den dazuge-horigen Services und unabhangigen Netzwerkservices genannt JavaSpacesgliedert (siehe Abb. 2.2).

Kommunikationsmodell

Das Jini-Kommunikationsmodell wird von drei Komponenten getragen. EinService Provider, im Java Jargon auch als Djinn bezeichnet, stellt einemNetzwerk seine Dienste zur Verfugung. Dazu wird fur jeden Dienst einDienstobjekt und eine Liste von Attributen mit Serviceinformationen in ei-ner speziell dafur vorgesehenen Java-Klasse erstellt. Dienstobjekte stellenfur den Service Provider ein Interface zur Verfugung, mit der er seine Fa-higkeiten prasentieren kann. Der Service Provider sendet diese Informationan einen Lookup Service und wird dort registriert. Jeder Lookup Service istebenfalls ein Dienst und die Anlaufstelle fur Jini-Clients die nach ServicesAusschau halten. Will ein Client einen Service in Anspruch nehmen, so er-halt er aus dem Index des Lookup Services die benotigte Information, umden Dienst am Service Provider eigenstandig aufrufen zu konnen.

Die Kommunikation zwischen den Teilkomponenten (Abb. 2.3) wird indie 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 speziellLookup Services suchen und durchsuchen zu konnen.

Das Multicast Announcement Protocol findet beim Start eines neuenLookup Services Verwendung, damit dieser potentiellen Clients seine Verfug-barkeit mitteilen kann. Auch beim Ausfall und neuerlichen Eintreten einesLookup Services in das Jini-Netzwerk kommt dieses Protokoll zum Einsatz.

Das Unicast Discovery Protocol wird von Netzwerkteilnehmern verwen-

Page 19: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 10

������

���*�+���"!�'�

��"!�'���"�!���"���������

�����

����

�����

�� ���������� ����� ����

��

Abbildung 2.3: Das Jini-Kommunikationsmodell (vereinfachte Darstellungaus [24]).

det, um gezielt mit einem Lookup Service kommunizieren zu konnen. AlsVorraussetzung fur eine erfolgreichen Discovery-Prozess gilt die Netzwerkun-terstutzung von Multicast und Broadcast-Nachrichten.

Join: Diese Phase beschreibt die Prozedur der Service-Registrierung beiverschiedenen Lookup Services. Der Service Provider meldet ein Dienstob-jekt und die Attributliste an und gibt bekannt, uber welche Zeitdauer derDienst dem Netzwerk zur Verfugung steht. Um die Netzlast zu reduzierenkonnen mehrere Lookup Services auch in logische Gruppen zusammengefasstwerden, die der Service Provider einheitlich mit einer Mulitcast DiscoveryNachricht ansprechen kann. Jeder Dienst weiß welcher Gruppe er zugeordnetist.

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 fundig, so erhalt er eine Kopie des Dienstobjektes. Fur die Kommuni-kation wird eine RMI-Verbindung hergestellt, die das dynamisch Laden vonProgrammteilen und das Ausfuhren von nicht-lokalen Prozessen auf eineranderen Virtual Machine erlaubt.

Service Call: Mit dem Erhalt des Dienstobjektes bekommt der Client dieMoglichkeit, direkt mit dem Service Provider zu kommunizieren und denService in Anspruch zu nehmen.

Weitere Konzepte

Eventing: Ahnlich dem UPnP-Modell konnen sich Objekte als ServiceListener bei einem Dienst eintragen und werden beim Eintreten eines Er-eignisses uber die Zustandsanderung informiert.

Page 20: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 11

Leasing: In Jini wird die temporare 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 Anspruchnehmen darf. Wird bis zum Ablaufs des Abonnements keine Erneuerung derVereinbarung 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 zwischenGeraten im Heim- und Office-Bereich auf Basis von TCP/IP und Internet-technologien ermoglicht. Die Entwicklung des Geratesteuerungssystems wirdvon namhaften Firmen unterstutzt und versucht die Charakteristika des Plugand Play-Paradigmas auf bestehenden Netzwerkstandards umzusetzen undmit verteilter und unabhangiger Applikationslogik zu verbinden. Ein beliebi-ges Gerat kann somit dynamisch einem Netzwerk hinzugefugt werden, seineDienste offerieren und uber die Verfugbarkeit und Serviceleistungen andererGerate lernen. Die Merkmale von UPnP umfassen:

• Automatische Gerate- und Serviceerkennung, Konfiguration und Inte-gration (zero configuration).

• Abstraktion der Netzwerktopologie zugunsten einer einfachen Bedie-nung (”invisible“ networking).

• Plattform-, protokoll- und gerateunabhangige Kommunikation und Da-tenaustausch.

Bedingt durch die Flexibilitat der Architektur ist auch eine Anpassungvon Technologien und Mediengeraten mit nicht IP-konformen Proto-kollen moglich. Der Implementierungsaufwand fur herstellerspezifischeGeratetreiber ist damit ebenfalls uberflussig, da standardisierte Pro-tokolle verwendet werden und dem Entwickler im Gegensatz zu Jinidie 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 beschaftigt. Praktisch alle namhaften Firmen in der IT-Branche sind in diesem Forum vertreten12.

Komponenten

Die UPnP-Architektur definiert zwei Komponententypen - das Gerat (De-vice) und die Steuerinstanz (Control Point).

12UPnP Implementers Corporation - http://www.upnp-ic.org/

Page 21: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 12

Gerat: Ein UPnP-Gerat beinhaltet Dienste (Services) und kann in einerrekursiven Anordnung wieder Subgerate (Embedded Devices) mit Dienstenenthalten. Ein mogliche Anwendung ware eine multifunktionale Stereoan-lage, die sich aus verschiedenen Teilgeraten 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 Gerat ausgefuhrt werden konnen (Ein- und Ausschal-ten, Starten und Stoppen eines Mediengerates, Setzen und Auslesen derZeit).

Die funktionale Beschreibung dieser Eigenschaften ist in einer XML-Dokumentenhierarchie im Gerat festgehalten, und wird im Netzwerk be-kanntgegeben. Ausgehend von einem zentralen Dokument mit allgemeinenGerateeigenschaften sind uber relative Verweise weitere Service-Dokumentereferenziert. Der untenstehende Code zeigt Teile der XML-Beschreibung ei-nes Licht-Dienstes. Auffallend ist dabei die Kombination aus Zustandsva-riable und zugehoriger Getter und Setter -Zugriffsaktion zum Setzen undAuslesen des Variablenwertes, wie sie in UPnP sehr haufig 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 <relatedStateVariable>Power</relatedStateVariable>

8 <direction >in</direction >

9 </argument >

10 </argumentList >

11 </action>

12 <action>

13 <name >GetPower </name >

14 <argumentList >

15 <argument >

16 <name >Power</name >

17 <relatedStateVariable>Power</relatedStateVariable>

18 <direction >out</direction >

19 </argument >

20 </argumentList >

21 </action>

22 </actionList >

23 <serviceStateTable >

24 <stateVariable sendEvents ="yes">

25 <name >Power</name >

26 <dataType >boolean </dataType >

27 </stateVariable >

28 </serviceStateTable >

Page 22: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 13

��

��� ���

,����� ,���� ,���

-�����������-���

�������!�'���"'����'��"�

�����$�"�#

�����&����"

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

Control Point: Der Control Point erlaubt die Entdeckung und Steuerungder Gerate. Er liest die Geratebeschreibungen aus, um Informationen uberdie Dienste zu erhalten, kann Statusabfragen tatigen, Statusanderungen 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.4ersichtlichen, Protokollen und Technologien zusammen. Als Transportpro-tokoll fur die Kommunikation kommt wahlweise TCP oder das ungesicherteUDP zum Einsatz. Darauf aufbauend werden Protokolle fur die speziellenAnforderungen von UPnP bereitgestellt.

Auf der UDP Seite sind dies HTTP Multicast over UDP (HTTPMU),HTTP Unicast over UDP (HTTPU) und die darin gekapselten ProtokolleGeneric Event Notification Architecture (GENA) und Simple Service Dis-covery Protocol (SSDP), die fur die Gerateerkennung zustandig sind. Dasbekanntere Protokoll HTTP wird auf der Basis von TCP fur die Prasen-tation und Beschreibung benotigt. Simple Object Access Protocol (SOAP)kummert sich um den Steuervorgang und HTTP und GENA zusammen sindfur die Benachrichtigungen (eventing) im UPnP-Kommunikationsmodell zu-standig.

UPnP Networking

Im Folgenden werden die einzelnen Phasen des in Abb. 2.5 dargestelltenUPnP-Kommunikationsmodells beschrieben. Eine ausfuhrliche Beschreibungvon UPnP findet sich unter [38].

Addressing: Eine Voraussetzung fur die automatische Gerateerkennungist die Adressierung der Gerate. Diese erfordert das Vorhandensein eines

Page 23: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 14

���"� ��.

�� '�!�"(

�� '"�+����

����"�� �!�����. �"� �������

Abbildung 2.5: Die einzelnen Phasen des UPnP Networking Modells (inAnlehnung an [38]).

DHCP-Clients am Gerat. Der Client sucht beim Anschluss an das Netz-werk nach einem DHCP Server und bekommt nach der Anmeldung eine IPAdresse zugewiesen. Ist keine Unterstutzung von DHCP gegeben, so mussdas Device AutoIP verwenden.

Discovery: Nachdem das Device erreichbar ist, beginnt es eigenstandigseine Dienstleistungen, die eingebetteten Gerate und deren Services im Netz-werk mit Multicast discovery messages anzubieten. Control Points hingegensuchen aktiv nach Geraten. Auch beim Verlassen des Netzwerkes muss eineMulticast-Mitteilung generiert werden, um alle Netzwerkteilnehmer zu in-formieren.

Description: Nach der Identifizierung eines Gerates hat ein Control Pointnur wenig Information uber dessen Beschreibung. Er kennt die URL, diezu einer detaillierten Geratebeschreibung fuhrt. Darin sind gemaß einemdefinierten XML-Schema folgende Informationen enthalten:

• Herstellerspezifische Angaben wie Modellname, Modellnummer, Seri-ennummer, Herstellername und URLs zu Webseiten.

• Information uber die eigenen Services und die der eingebetteten Ge-rate.

• URLs fur die zeitgleichen Betriebsphasen der Steuerung, des Event-managements und der Prasentation (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 inAnspruch nehmen und Zustande an den Geraten abfragen. In Form von

Page 24: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 15

XML-SOAP Nachrichten werden Aktionsaufrufe an die Gerate-URL ge-schickt. Das Gerat arbeitet diese Befehle ab und reagiert mit Zustands-anderungen.

Eventing: Wenn sich ein Control Point als Listener bei einem Gerat regi-striert, so wird er durch ausgeloste Events uber Anderungen von Statusva-riablen informiert. Fur die Anmeldung an einem Service sendet er eine Sub-scription Message an das Gerat. Wenn das Abonnement angenommen wird,definiert der Service die zeitliche Begrenzung und sendet diese Informationan die Steuerinstanz zuruck. Um eine Weiterfuhrung des Abonnements durcheine erneute Benachrichtigung oder die Kundigung vor der abgelaufenen Zeitmuss sich der Control Point selbst kummern. Event-Nachrichten werden imXML-Format GENA erstellt. Um Szenarien mit mehreren Control Pointsrealisieren zu konnen, werden alle Abonnenten uber alle Eventvariablen undderen Anderungen informiert. Dabei ist nicht relevant ob die Zustandsan-derung aufgrund eines externen Aktionsaufrufes oder innerhalb des Gerateszu Stande kommt.

Presentation: Bei vielen Geraten ist eine Prasentations-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 alseinfaches Userinterface dienen, das dem Benutzer die Steuerung des Geratesund der Dienste erlaubt.

Fazit

UPnP wird aufgrund der Unterstutzung vieler Software- und Unterhaltungs-elektronikkonzerne mit großer Wahrscheinlichkeit zu einer Schlusseltechno-logie im Bereich der verteilten Heimnetzwerke heranwachsen. Es fehlt jedochnoch an konkreten Szenarien, die dem Endkunden die Vorteile verdeutlichen.

2.2.3 OSGi

Die Spezifikation zu OSGi (Open Service Gateway Initiative) wird von derOSGi Alliance13, einem Zusammenschluss bedeutender Hard- und Software-hersteller, darunter Sun Microsystems, IBM und Ericsson, getragen. DasOSGi-Framework definiert eine offene Service-Plattform fur vernetzte Dien-ste, die sowohl fur industrielle Anwendungen als auch fur den Einsatz beimEndkunden und in mobilen Umgebungen geeignet ist. Das Framework setztauf einer Java Virtual Machine-Umgebung auf und wird folgenden Anfor-derungen gerecht (vgl. [37]):

13OSGi und OSGi Alliance - http://www.osgi.org/

Page 25: UPnP Diplomarbeit

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN 16

Komponentenbasierte Architektur: Aufbauend auf einem Frameworkfur die Java-Plattform konnen modulare Softwareanwendungen (Bundles)installiert werden, die spezialisierte Services zur Verfugung stellen.

Integration bestehender Protokollstandards: Der generische Ansatzder OSGi Service-Definition erlaubt die Integration und Kommunikation mitbestehenden Standards verteilter Gerate und Dienste. Auch fur UPnP, Jiniund Webservices sind Schnittstellen vorhanden.

Dynamisches Management: OSGi-Bundles konnen zur Laufzeit admi-nistriert werden. Die Funktionalitat fur die Installation, das Starten und dasStoppen von Bundles zur Laufzeit ist integraler Bestandteil des Systems.

Integriertes Sicherheitsmodell: Die Softwarearchitektur von OSGi er-moglicht eine strikte Trennung von Kompetenzen. Im Bundle-Kontext un-terscheidet man zwischen privaten Ressourcen und solchen, die uber eineoffene Schnittstelle zur Verfugung gestellt werden und auch von anderenBundles benutzt werden durfen.

Page 26: UPnP Diplomarbeit

Kapitel 3

Gerate

3.1 Szenario

Um die Tauglichkeit von UPnP als Service-Plattform unter Beweis stellen zukonnen, mussen vorher Anforderungen fur prototypische Implementierungendefiniert werden. Es soll geklart werden, inwiefern die Technologie in einemMediensteuerungsszenario genutzt werden kann. Mit Blick auf die vielfal-tige Unterhaltungselektronik eines Haushaltes ist schnell ein reichhaltigesEinsatzgebiet gefunden.

So mochte man beispielsweise auch wahrend der Kuchenarbeit nichtauf den Musikgenuss verzichten mussen. Zusatzlich zur Stereoanlage imWohnzimmer ist das Aufstellen eines weiteren Elektronikgerates, nur furdas Musikhoren, jedoch alles andere als platzsparend und okonomisch. Hinzukommt, dass die jahrelang gepflegte Mp3-Sammlung am PC im Arbeitszim-mer ohnehin dem Radio vorgezogen wird. Obwohl die Inhalte uber das Netz-werk auf einen PC mit Bildschirm in die Kuche ubertragen werden konnten,ist die Bedienung mehr als muhsam. Das Hantieren mit einer Maus passt inkeiner Weise zu den Tatigkeiten in der Kuche. Ein in die Wand integriertesTouchpanel wurde hier Abhilfe schaffen, die Nutzung scheitert jedoch an derSoftware des Medienplayers, dessen GUI mit den kleinen Bedienelementennicht fur ein solches Szenario ausgelegt ist.

Zudem mochte man auch die Inhalte anderer, im Haus verteilter Gerateund Anwendungen in einem gemeinsamen Display darstellen und fernsteuernkonnen, ohne sich uber deren Standorte Gedanken machen zu mussen.

Ebenso wie in diesem Fall finden sich in einem Haushalt viele Beispiele,in denen ein nahtloses Zusammenspiel zwischen Elektronikgeraten Sinn ma-chen wurde. Die Stereoanlage, der Fernseher, der DVD-Player und auch dasRaumlicht konnten unter einem gemeinsamen Standard und den entspre-chenden technischen Vorrausetzungen alle von einem mobilen Smart Phoneaus gesteuert werden. Daruber hinaus eroffnen mit Sensoren ausgestatteteEmbedded-Gerate und Bewegungsdetektoren neue Moglichkeiten, um Ab-

17

Page 27: UPnP Diplomarbeit

KAPITEL 3. GERATE 18

laufe zu automatisieren. Steht eine Person am Morgen auf, konnte dies vonDrucksensoren am Boden registriert werden und eine Gebaudesteuerung in-formieren, die das Licht in allen vordefinierten Raumen einschaltet. Verlasstder Bewohner das Haus und geht zur Arbeit, wird eine Uberwachungskameramit 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 Mediengerate durch die Unterstutzung ver-teilter Netzwerke nicht mehr nur als eigenstandige Dienste betrachtet wer-den konnen, sondern gerade durch ihre vielfaltigen Vernetzungsmoglichkei-ten eine neue Servicequalitat bieten. Die drahtlosen und netzwerkfahigenGerate hierfur sind mit PCs, PDAs, Touchpanels und Mobiltelefonen vor-handen. Auch Unterhaltungselektronik wird vermehrt mit Netzwerkfunk-tionalitat ausgestattet. Mit einer gemeinsamen Service-Plattform fur dieDienste wird eine Trennung zwischen dem Standort eines Gerates und des-sen grafischer Reprasentation zur Fernsteuerung moglich. Die Inhalte derverschiedenen Anwendungen konnten dann uber ein gemeinsames, an dasDarstellungsgerat angepasstes, User Interface gesteuert werden. Aus diesenIdeen ergeben sich mehrere Komponenten, die zum Aufbau solcher Szenarienbenotigt werden:

• Gerate: Fur das oben erwahnte Szenario mussen UPnP-fahige Hard-und Softwaregerate gefunden oder selbst entwickelt werden.

• GUI-Builder: Genauso wie mit UPnP ein gemeinsames Steuerpro-tokoll fur verteilte Gerate vorhanden ist, muss ein Weg zur automati-sierten Generierung von User Interfaces zur Fernsteuerung der Netz-werkgerate gefunden werden. Der Ansatz sollte sowohl auf mobilenEndgeraten als auch auf PC-Systemen angewendet werden konnen.

• Framework zur Kopplung verteilter Gerate: Auf Basis von UPnPals Service-Plattform muss ein System zur Verknupfung von verteil-ten Geratediensten geschaffen werden. Damit kann ein UPnP-fahigesSensorgerat etwa Drucksensorwerte zur Steuerung der Bedienelementeeines Medienplayers liefern. Moglich wird dies durch die dezentraleArchitektur des Torem Frameworks [39], einer UPnP-Controlpoint In-stanz, die Gerate im Netzwerk finden und ansteuern kann. Toremerlaubt es dem Benutzer mit einem grafischen Editor ereignisorien-tierte Zustandsvariablen und Ein- und Ausgabeparameter von UPnP-Aktionen miteinander zu verknupfen, um Szenarioablaufe zu definieren(siehe Abb. 3.1).

Page 28: UPnP Diplomarbeit

KAPITEL 3. GERATE 19

Abbildung 3.1: Torem - Ein Framework zur Kopplung verteilter UPnP-Gerate. Der Benutzer kann aus allen vorhandenen Gerate und zusatzlichenKontrollflusskomponenten, wie If -Bedingungen und Schleifen eine Ereignis-kette definieren [39].

3.3 UPnP-Technologie

Als Grundlage fur die Entwicklung der Gerate und GUI-Builder Steueran-wendung wird eine Bibliothek benotigt, die die Besonderheiten der UPnP-Technologie abstrahiert und die Implementierung von Geraten und Control-point-Instanzen ermoglicht. Die Cyberlink UPnP Bibliotheken1 des japa-nischen Programmierers Satoshi Konno ist in den ProgrammiersprachenC/C++ und Java verfugbar. Zusatzliche Beispielanwendungen und ein ru-dimentarer Controlpoint zum Steuern der Geratedienste sind ebenfalls vor-handen. Die Java-Variante dieser Bibliothek wurde fur die Entwicklung aus-gewahlt, da sie schon mehreren Revisionen unterzogen wurde und eine uber-sichtliche und gut abstrahierte Klassenstruktur bietet.

3.4 Implementierung

Fur das Szenario werden Eingabegerate und verteilte Anwendungen beno-tigt. UPnP spezifiziert trotz der breiten Herstellerunterstutzung zum ge-

1Cyberlink UPnP Bibliotheken http://www.cybergarage.org/net/

Page 29: UPnP Diplomarbeit

KAPITEL 3. GERATE 20

gebenen Zeitpunkt wenige Gerate-Standards2, die fur die Mediensteuerungvon Interesse sind. Neben Standards fur Scanner, Drucker, Modems undRouter passen eine Uberwachungskamera und eine AV MediaServer/Media-Renderer-Architektur [12] besser in das Konzept. Mit dem Philips SL300i3

stand ein WLAN-Client zur Verfugung, der Audio- und Videoformate vomPC auf den Fernseher streamen kann. Das Produkt implementiert jedoch nurdie wichtigsten der spezifizierten Funktionen und ist damit nur eingeschranktbedienbar. Mit Hilfe softwarebasierter Adapter konnte weitere HardwareUPnP-fahig gemacht werden. Dazu zahlen ein mit acht Drucksensoren aus-gestatteter Mikrocontroller mit LAN-Anschluss und ein Streaming-Server,der das Video einer Webcam zu einem Client ubertragen kann und dort Be-wegungsdetektion ermoglicht. Auch der MIDI-Protokollstandard4 und derWinamp Media Player konnten mit UPnP-Funktionalitat gekapselt werden.

3.4.1 Sensor-Hardwaredevice

Anforderungen

Um ein alternatives Eingabegerat fur das Steuerungsszenario zu erhalten,wurde nach einer Moglichkeit zur Integration von Sensoren gesucht. Dazuwird ein hardwarenahes System benotigt, das den Anschluss von Sensorik aneinen Analog-Digital Wandler erlaubt und die gemessenen Spannungswerteder Sensoren ins UPnP-Netzwerk exportieren kann. Um die Anbindung andas Netzwerk zu ermoglichen, sollte eine schlanke C/C++-Bibliothek gefun-den werden, die einen UPnP-Stack fur performanceschwache Systeme im-plementiert. In netzwerktechnischer Hinsicht muss das Gerat einen TCP/IPStack integrieren und den Zugriff uber ein LAN-Modul mit RJ45-Anschlussoder eine WLAN-Schnittstelle erlauben. Im besten Falle sollte das Geratauch geringen Stromverbrauch garantieren oder mit Batterie betrieben wer-den.

Hinsichtlich frei verfugbarer Software wurden folgende UPnP-Bibliothe-ken fur die Entwicklung in Betracht gezogen:

• Intel Software for UPnP Technology: Intel’s UPnP-Implemen-tierung5 ist eine Sammlung an Softwarepaketen fur die Entwicklungund das Testen UPnP-fahiger Anwendungen. Das Authoring Tools-Paket enthalt einen automatisierten Device-Builder, der anhand funk-tionaler XML-Geratebeschreibungen portablen Programmcode in C

2UPnP Gerate-Standards - http://www.upnp.org/standardizeddcps/3Philips Streamium (UPnP AV MediaRenderer) - http://www.streamium.philips.com/4Musical Instrument Digital Interface (MIDI) ist ein Steuerprotokoll fur digitale Mu-

sikinstrumente, wird aber auch fur Mediensteuerungen und kunstlerische Installationengerne eingesetzt. - http://www.midi.org/

5Intel Software for UPnP Technology - http://www.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/

Page 30: UPnP Diplomarbeit

KAPITEL 3. GERATE 21

generiert. Jedoch ist dieser Code nur fur Microsoft Windows, Pocket-PC und Linux ausgelegt.

• Linux UPnP-SDK: Ein UPnP-SDK fur Linux6 wird als Open SourceSoftware zur Verfugung gestellt. Die Einarbeitungszeit in ein Embedded-Linux System ist fur den kleinen Teil des Szenarios allerdings nichtgerechtfertigt.

• Cyberlink: Neben der Java-Variante wird von Cyberlink auch eineC++und eine C-Bibliothek bereitgestellt. Aufgrund der umfassendenKlassenstruktur und der mehrfachen Threads kann die C++-Implemen-tierung nicht auf einem hardwarenahen System eingesetzt werden. DieC-Bibliothek hingegen ist dezidiert fur mehrere Embedded-Systemeausgelegt. Doch auch hier konnte fur die unterstutzten Betriebssy-steme T-Engine7 und uTRON 8 kein bekanntes Hardwareboard gefun-den werden.

Auf der Suche nach entsprechender Hardware stellte sich heraus, dasskein greifbares Gesamtsystem die Anforderungen hinreichend erfullt und inkurzer Zeit die Erstellung eines Prototyp ermoglicht:

• AVR Embedded Internet Toolkit: Mit dem Embedded InternetToolkit9 konnte ein System gefunden werden, das ausdrucklich fur In-dustral Control und Home Appliances ausgelegt ist und neben einenTCP/IP-Stack auch aufbauende Protokolle, wie DHCP, HTTP undFTP unterstutzt. Jedoch sind die Anforderungen C++-basierter UPnP-Bibliotheken fur 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 fur die automatische Gerateerkennung zu unterstutzen. EinePortierung der Cyberlink C-Bibliothek auf die gangige ARM -Mikro-prozessorarchitektur10 ware mit einigem Zeitaufwand allerdings denk-bar.

• Sindrion: Sindrion ist eine verteilte Systemarchitektur rund um einenChip mit niedrigem Energieverbrauch, der von der Firma Infineon11

mit dem Ziel eines kostengunstigen Sensornetzwerkes entwickelt wurde[30]. Im Sindrion-Konzept wird explizit auch die Integration in die

6Linux UPnP-SDK - http://upnp.sourceforge.net/7Embedded OS: T-Engine - http://www.t-engine.org/8Embedded OS: uTRON - http://www.utron.net/9AVR Embedded Internet Toolkit - http://www.atmel.com/dyn/resources/prod

documents/doc2493.pdf10Die ARM-Architektur ist ein Designspezifikation fur eine Reihe an 32-bit Mikropro-

zessoren, die dem RISC-Konzept folgen. - http://www.arm.com/11Infineon - http://www.infineon.com/de/

Page 31: UPnP Diplomarbeit

KAPITEL 3. GERATE 22

UPnP-Serviceplattform erwahnt. Demnach ist ein Sindrion Wireless-Transceiver eine Gerat, das einen reduzierten UPnP-Stack implemen-tiert und Kontakt zu einer Terminal-Software halt, die den fehlendenTeil der Netzwerkkommunikation ubernimmt und so in Kombinationein vollwertiges UPnP-Gerat reprasentiert [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 Hardwaregerat zumAnschluss von Sensoren. Das ARM-basierte Mikroprozessorboard istmit Solarzellen und mit einem drahtlosen Funksender nach dem Stan-dard IEEE 802.15.414 ausgestattet und kann als Informationsquelle inintelligenten 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 CLDC1.1 den Standard einer vollwertigen, mobilen Virtual Machine imple-mentiert. Als Termin fur die Produktreife von Sun SPOT wird abererst der Sommer 2006 angegeben.

Systemaufbau

Schließlich wurde ein prototypisches Hardwaredevice der Firma Ubitronix 15

eingesetzt. Das Gerat basiert auf einem Texas Instrument MSP430 -Mikro-controller16, der einen 8-Port Analog-Digital Wandler integriert. Zusatzlichist ein mit dem Lantronix XPort17 ein Ethernet-Modul angebracht, das dieNetzwerkkommunikation ermoglicht. Am Gerat wurden acht Drucksensorenangebracht und so konfiguriert, dass der Wandler je nach Druckstarke einenskalierten Wert zwischen 0 und 4000 zuruck liefert. Mit einem proprietaren,TCP/IP-basierten Kommunikationsprotokoll kann das Gerat im Netzwerkangesprochen werden. Es definiert eine Folge an Befehlen im Byte-Formatum die acht Sensorwerte auslesen zu konnen.

Ein Zyklus einer Sensorabfrage (Abb. 3.2) sieht vor, dass zuerst ein re-quest-Befehl an das Gerat gesendet wird. Das Hardwaredevice bestatigtdiese Anfrage (acknowledge) und teilt dem PC mit, dass es Daten sendenwill (send). Ist der PC damit einverstanden (ack), sendet das Gerat die er-mittelten acht Sensorwerte mit je 2 Byte Lange zuruck (sensordata). Trotz

12SUN Spot - http://www.sunspotworld.com/13Sun Microsystems Laboratories - http://research.sun.com/14IEEE 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

15Ubitronix - http://www.ubitronix.com/16Texas Instrument MSP430 Mikrocontroller - http://www.ti.com/msp43017Lantronix XPort -

http://www.lantronix.com/device-networking/embedded-device-servers/xport.html

Page 32: UPnP Diplomarbeit

KAPITEL 3. GERATE 23

�� ,"�/"���!�'�

�������

��

���

��

����������

��

Abbildung 3.2: Die Abbildung zeigt die Befehlskette einer Sensorabfragezwischen dem PC und dem Hardware-Modul.

des aufwendigen Protokolls, das nicht nur fur die Sensorabfrage entworfenwurden, zeigte sich der Prototyp als robustes Eingabegerat, das auch nachtagelangem Einsatz noch einwandfrei funktioniert.

Fur die Integration ins UPnP-Netzwerk wurde eine Adapteranwendungam PC implementiert, die eine persistente Verbindung zum Hardwarede-vice halt und auf eine GetSensor-Aktionsanfrage eines UPnP-Controlpointsdie acht Sensorwerte ermittelt und in Form eines XML-formatierten Stringszuruck liefert.

Mit dieser Implementierung wurde die UPnP-Welt des Szenarios um einphysisches Eingabegerat bereichert. Welche Funktionen die Sensoren erful-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, dannsoll der Play-Befehl eines Medienplayers ausgefuhrt werden. Ein erweiter-tes Szenario konnte auch eine Passwortabfrage anhand einer bestimmtenAbfolge an gedruckten Sensoren realisieren. Mit dem Hardwaredevice ist dieIntegration vieler, weiterer Sensortypen, wie Temperatur-Sensoren, Distanz-Sensoren, Magnetfeld-Sensoren, etc. denkbar, da sie am gleichen Gerat an-gebracht werden konnen und die Bedeutung eines Sensors erst durch dessensemantische Verknupfung definiert wird.

3.4.2 Webcam Streaming-Server und Client

Fur die Entwicklung eines weiteren Eingabegerates wurde eine StreamingServer/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 Moglichkeit zum Auslesen und Setzen derURL des Videostreams kann der Servers vom Netzwerk aus gestartet undgestoppt werden. Ein ebenfalls UPnP-fahiger Client besitzt dieselben Mog-lichkeiten, allerdings zum Empfang des Videosteams. Der Streaming Client

Page 33: UPnP Diplomarbeit

KAPITEL 3. GERATE 24

ermittelt uber UPnP automatisch das Vorhandensein eines Servers, liestdessen Videostream-URL aus und nutzt sie, um sich selbst zu konfigurierenund zu starten. Zusatzlich ist am Client eine simple Bewegungserkennung(motion detection) implementiert, die auf Anderungen des Videobildes rea-giert und diese Information uber zwei Wege auch einem UPnP-Controlpointzuganglich macht. Zum einen ist eine ereignisorientierte boolsche VariableMotionDetected definiert, die Ruckmeldung uber den aktuellen Status desVideobildes. Als zweite Maßnahme wird zum Zeitpunkt der Bewegung dasBild des aktuellen Videoframes abgespeichert und uber einen Webserver zu-ganglich gemacht, dessen URL wiederum mit der UPnP-Aktion GetLastMo-tionImage bekanntgegeben wird.

Systemaufbau

Fur die Implementierung der Streaming-Architektur wurde das Java Me-dia Framework18 (JMF, Version 2.1.1e), eine Java-basierte Bibliothek furdie Medienverarbeitung, herangezogen. JMF ermoglicht den Zugriff auf dieDaten, der am PC angeschlossenen Audio- und Videohardware und abge-speicherter Medienformate. Durch die Entwicklung von Plugins konnen An-derungen in den Datenstromen der Verarbeitungskette vorgenommen wer-den, die sich aus einer Datenquelle, einem Prozessor und einer Datensenkezusammensetzen. Sowohl Datenquelle als auch Datensenke sind abstrakteBezeichnungen fur Ein- und Ausgabeinstanzen. Dazu zahlen neben Gera-ten wie Videokamera und Bildschirm ebenso ein Netzwerkstream oder eineMediendatei.

Der Streaming Server und der Client verwenden eine annahernd 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 alsUPnP-Gerat. Fur den Client ist zusatzlich auch eine UPnP-Control-point integriert, der zur Auffindung des Servers benotigt wird.

• net.digidop.upnp.device.rtpserver.business: Diese Schicht de-finiert Business-Objekte zum Aufbau der JMF-Verarbeitungskette, derInstanzierung des medienverarbeitenden Prozessors und der Generie-rung einer grafischen Komponente fur das Videovorschaubild.

• net.digidop.upnp.device.rtpserver.ui:Das Packet enthalt Klas-sen fur das GUI und die Konfigurationsoptionen, die auch uber dasNetzwerk geandert werden konnen.

18Java Media Framework API - http://java.sun.com/products/java-media/jmf/

Page 34: UPnP Diplomarbeit

KAPITEL 3. GERATE 25

Bevor eine Verarbeitung am Client erfolgt, muss der Processor konfi-guriert werden. Anhand der vom Server ermittelten Multicast19-URL desVideostreams wird ein MediaLocator angelegt, der zusammen mit einemglobalen Manager eine Instanz des Processors erzeugt. Im Anschluss kanneine Liste an beliebigen Plugins in die Verarbeitungskette eingegliedert unddie Datensenke an eine GUI-Applikation angebunden werden. Der einfacheMotiondetection-Algorithmus FxMotionDetection reagiert auf die durch-schnittliche Intensitatsanderungen eines Bildes. Hat sich der ermittelte Wertim Vergleich zum vorgehenden Videoframe stark verandert, wird eine Bewe-gung registriert und die MotionDetected-Zustandsvariable auf TRUE gesetzt.Sobald der Algorithmus im nachsten, zehnten Frame keine Bewegung mehrregistriert, wird der Wert wieder auf FALSE gesetzt.

1 /*

2 * Berechnung von dividedSumofDifferences als Durchschnittswert

3 * der Intensitatsanderung zweier Frames mit Abstand 10

4 */

5

6 if (( frameCount % 10) == 0) {

7 if (motionDetected ) {

8 motionDetected = false;

9 } else {

10 clientDevice .trackingVar .setValue("FALSE");

11 }

12 }

13

14 if(dividedSumofDifferences > treshold && !motionDetected ) {

15 motionDetected = true;

16 clientDevice .trackingVar .setValue("TRUE");

17 }

Die Verarbeitung des RTP-Streams20 erfolgt mir 15 Bildern pro Sekunde.Der Algorithmus fur die Bewegungserkennung ist sehr einfach aufgebaut.Die Flexibilitat des Systems erlaubt es aber, dass mit wenig Aufwand einrobusteres 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 kostengunstige Variante einer Uber-wachungskamera geschaffen, die ohne zusatzlichen Konfigurationsaufwandbetrieben werden kann.

19Multicast bezeichnet in der Netzwerkkommunikation eine Nachrichtenubertragungvon einem Punkt zu einer Gruppe. In IPv4 ist hierfur der Adressbereich 224.0.0.0 bis239.255.255.255 (Klasse D) reserviert

20Das Real-Time Transport Protocol ist ein Protokoll zur kontinuierlichen Ubertragungvon audiovisuellen Daten (Streams) uber IP-basierte Netzwerke

Page 35: UPnP Diplomarbeit

KAPITEL 3. GERATE 26

Abbildung 3.3: Die Abbildung zeigt die UPnP-fahige Streaming ServerApplikation mit dem Videobild der Webcam. Im rechten Bild ist das Fensterfur die Webcam-Einstellungen zu sehen.

3.4.3 UPnP-Winamp Media Player

Um auch ein Gerat zum Abspielen von Musik anzusteuern zu konnen, wurdeder Winamp Media Player21 in der Version 2.91 mit einem Softwareadap-ter an UPnP angebunden. Neben der Uberlegung ein umfangreiches C++-basiertes Plugin auf Basis der Winamp SDK22 und der Cyberlink UPnP-Bibliothek zu entwickeln, wurde mit httpQ23 ein netzwerkbasiertes Plugingefunden, das die Funktionen von Winamp uber den Zugriff via HTTP-GET URL ermoglicht. Dafur wurde in Java ein Adapter entwickelt, derdiese Funktionen ins UPnP-Netzwerk exportiert und Steuerzugriffe in denhttpQ -Befehlssatz umsetzt. Neben der Steuerung der Abspielelemente kannauch die Zeit, die Lautstarke und Auskunft uber die geladene Playlist undden aktuellen Song ermittelt und gesetzt werden. In der Klasse HttpQAd-apter sind alle Befehle definiert und konnen mit processCmd ausgefuhrtwerden. Fur das Starten des Players wird etwa folgender String aus demPlay-Befehl und einem geforderten Passwort zusammengesetzt und ausge-fuhrt: http://localhost:4800/play?p=pass.

3.4.4 MIDI-Device

Fur die Ubertragung von MIDI-Steuerbefehlen wurde mit Hilfe des LoopBe1MIDI-Treibers24, einer virtuellen MIDI-Kabelverbindung am PC, ein UPnP-Adapter fur das Windows Betriebsystem entwickelt. Damit konnen alle soft-

21Winamp Media Player - http://httpq.sourceforge.net/22Winamp Plugin Development Center- http://www.winamp.com/nsdn/winamp/plugins/23httpQ Network Protocol - http://httpq.sourceforge.net/24LoopBe1 Virtual MIDI Driver - http://www.nerds.de/en/loopbe1.html

Page 36: UPnP Diplomarbeit

KAPITEL 3. GERATE 27

warebasierten Klangerzeuger wie Reaktor25 angesprochen werden. Der Ad-apter sendet mit Hilfe der Java-MIDI API javax.sound.midi Steuerbefehlean die virtuelle Schnittstelle LoopBe1. Wird der Treiber in einem Klan-gerzeuger als MIDI-Eingabegerat ausgewahlt, so leitet er die eintreffendenBefehle direkt an dieses weiter. Uber die installierten MIDI-Treiber der So-undkarte des PCs konnen auch externe Gerate angesprochen werden.

Das MIDI-Protokoll definiert eine Reihe an Steuernachrichten mit un-terschiedlicher Parameteranzahl. Mit dem Befehlen NOTE_ON und NOTE_OFFund dem Parameter der Tonhohe kann beispielsweise ein Tastendruck aufeinem Klavier simuliert werden. Die Tondauer wird durch das Zeitintervallzwischen den beiden NOTE-Befehlen festgelegt. Diese Funktionalitat wird ineinem UPnP-Gerat gekapselt, das eine SetNote-Aktion implementiert. AlsEingabeparameter verlangt sie einen MIDI-kompatiblen Tonhohenparame-ter zwischen 0 − 127. Ist das virtuelle MIDI-Gerat an einen Klangerzeugergekoppelt, wird ein Tastendruck mit der Dauer von 100 ms simuliert. Diesfuhrt 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 anzusatzlicher Hard- und Software, die mit diesem Protokoll arbeiten. Vor al-lem hinsichtlich neuer Eingabemedien scheint dieses Konzept interessant, dazahlreiche MIDI-Controller mit integrierten Tasten, Drehknopfen, Touchpa-nels und Schiebereglern fur die Steuerung verteilter Gerate bereitstundenund nicht nur im musikalischen Kontext verwendet werden konnten. EinBeispiel fur solche Gerate sind alternative Controller-Produkte26 der deut-schen Firma Dopfer27.

25Native Instruments Reaktor - http://www.native-instruments.com/index.php?id=reaktor5 us

26Eine Liste alternativer MIDI-Controller - http://www.stoffelshome.de/alt controller/alt midi controller.html

27Dopfer MIDI-Controller - http://www.doepfer.de/home d.htm

Page 37: UPnP Diplomarbeit

Kapitel 4

Generierung grafischer UserInterfaces

Eine große Herausforderungen in der Softwareentwicklung ist das Designvon Schnittstellen zwischen Mensch und Maschine. Erklartes Ziel beim Ent-wurf eines Interfaces ist es, Daten und Funktionalitaten einer Applikationin einer abstrahierten Form zu prasentieren und dem Benutzer einfache In-teraktionsmoglichkeiten anzubieten. In diesem Zusammenhang befasst sichder Human-Computer Interface (HCI) Forschungsbereich neben traditionel-len grafischen Oberflachen (Graphical User Interface oder einfach GUI ) furEndgerate mit Display auch mit alternativen, physischen Eingabegeratenunter dem Begriff Tangible Interfaces, die nicht Gegenstand der vorliegen-den Arbeit sein sollen. Vielmehr soll erlautert werden, warum das Designund die Implementierung von GUIs auch Jahrzehnte nach deren Aufkom-men keine triviale Aufgabe darstellt [27].

Die Bringschuld des Softwareentwicklers besteht darin, User Interfacesunter Berucksichtigung der Benutzererwartung, hinsichtlich der Bedienungeiner Software, zu gestalten. Abhangig von verschiedenen Faktoren wie demAlter des Benutzers und dem IT-Vorwissen kann dies zu den unterschied-lichsten Bedurfnissen fuhren. Ein Grafiker, dessen tagliches Arbeitswerkzeugein Bildbearbeitungsprogramm ist, sucht nach Wegen um wiederkehrendeAblaufe standardisieren zu konnen und schnellstmoglichen Zugriff auf alleihm zur Verfugung stehenden Funktionen zu haben. Ein Anfanger hinge-gen mochte aller Voraussicht nach schrittweise in das Programm eingefuhrtwerden und wenige fur ihn wichtige Operationen ausfuhren konnen, ohnesich in einer Ansammlung von Menueintragen und Mehrfachbelegungen vonButtons zu verlieren.

Unterstutzung im Entwicklungsprozess erfahrt der Programmierer dabeivon Seiten psychologischer Studien hinsichtlich dem Nutzerverhalten undder Gebrauchstauglichkeit der Software. Diese Art der Evaluierung durchBeobachtung von Benutzern und ihren Gewohnheiten wird durch den Be-

28

Page 38: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 29

griff Usability gepragt. Zusatzliche Schwierigkeiten konnen sich durch dieEinbeziehung Kontext-sensitiver Informationen in die Anwendung ergeben.Je mehr unvorhersehbare Anwendungsbereiche und Gerateumgebungen ge-geben sind, desto vielschichtiger sind die Abhangigkeiten, 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 Uberlegungen steht die Suche nach uberzeugenden Methodenum konsistente und benutzerfreundliche Schnittstellen entwickeln zu konnen:

1. Welche allgemeingultigen Qualitatskriterien sind im GUI-Design defi-niert und wie konnen 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 Endgerate, ubiquitarer Technologien und die Ad-hoc-Vernetzunggeneriert?

4. Welche unterstutzenden 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 habensich auch im Interface-Design bewahrte Konzepte durchgesetzt, die sich alsRichtlinien fur heutige GUI-Applikationen etabliert haben. Dazu zahlen Fen-ster, Menuleisten und Bestatigungs-Dialoge ebenso, wie Layout-spezifischeKonventionen. Das Schließen einer Applikationen oder das Offnen einer Da-tei, werden als Hauptfunktionen in verschiedenen Applikationen an der glei-chen Stelle zu finden sein. Dem Benutzer wird dadurch die Moglichkeit gege-ben, sich an bereits erlernten Metaphern orientieren zu konnen. Das selbst-verstandliche Vorhandensein von Maus, Tastatur und einer grafischen Ober-flache bei PC-Systemen zeigt, dass sich aus den Ideen zu Eingabegeratenschnell Standards entwickeln konnen.

Fur die grafische Aufbereitung, die das Layout der Komponenten, denSchriftsatz 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 zuruck-zufuhren, dass das moderne Betriebsystem grundlegende Zeichenoperationen

1Microsoft User Interface Design and Development - http://msdn.microsoft.com/ui/2Apple Human Interface Guidelines - http://developer.apple.com/documentation/

UserExperience/Conceptual/OSXHIGuidelines/

Page 39: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 30

mit Hilfe eigener Window Manager zur Verfugung stellt. Eine Vielzahl weiterPublikationen beschaftigt sich mit Richtlinien fur Interaktionsdesign [8, 34]und auch fur grafisches Design [4]. Aufgrund der Vielfalt und Komplexitatvon Softwaresystem und dem unvorhersehbaren Nutzerverhalten lassen sichdiese Ansatze nicht in einer allgemeingultiger Theorie postulieren. GutesDesign liegt demnach zu einem großen Teil noch immer in den Handen desDesigners.

Anpassungsfahigkeit und Hilfestellung: Trotz des Bestrebens robu-ste, einfach zu bedienende Software zu entwickeln, kann es zu Situationenkommen, in denen eine Fehlerbehandlung unvermeidlich ist. Die Art wie derBenutzer davon in Kenntnis gesetzt wird, ist ein Indikator fur die Qualitatder Anwendung. Programmatische Fehlermeldungen stehen hier in starkemGegensatz zum Versuch, dem Benutzer die Handhabung der Software zu er-klaren oder im besten Fall die entstandene Problematik programmintern zulosen. Ein schwerwiegender Irrtum ware es, in diesem Zusammenhang vomFehlverhalten des Benutzers zu sprechen, da das oberste Prinzip die Unter-stutzung des Benutzers in seiner Tatigkeit sein soll [8]. Die Internationalisie-rung von Anwendungen eroffnet besseren Zugang zu spezifischen Benutzer-gruppen und verlangt mehr als nur die Ubersetzung von Textinhalten. Auchexterne Faktoren wie lokale Kultureinflusse, soziale und rechtliche Gegeben-heiten, spezielle Zahlenformate und Layoutbedingungen mussen ebenso wieAnforderungen fur Zielgruppen mit besonderen Bedurfnissen berucksichtigtwerden. Um eine gute Handhabung eines Interfaces zu erreichen, muss dasNavigationskonzept schlussig und die Anordnung der Elemente konsistentsein. Der Benutzer muss zudem jederzeit uber den Zustand des Systems in-formiert sein, die Kontrolle haben und bei Interaktionen in kurzester ZeitFeedback erhalten.

4.2 Anforderungen im Pervasive Computing

4.2.1 Kontext-sensitive und verteilte Anwendungen

Das Aufkommen mobiler Endgerate und eingebetteter, smarter Technolo-gien erweitert mit ebenso großer Tragweite den Horizont der computeri-sierten Wahrnehmungswelt, wie einst der Ubergang zwischen dem Zeitalterdes zentralisierten Mainframe-Computing hin zur Ara des Desktop-PCs. DieErfassung Kontext-sensitiver Informationen durch Gerate, die mit Sensorenausgestattet sind, erlaubt heute schon eine engere Bindung der Anwendungan die unmittelbare Umgebung (location-based services). Bis der Wunsch-traum einer ubiquitaren Welt nach Mark Weiser [40], in der der Benutzerkeinen unmittelbaren Kontakt mehr zu technischen Gerate halt, Wirklich-keit werden kann, mussen essentielle Fragen hinsichtlich Energieversorgung,

Page 40: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 31

einheitliche Kommunikationsstandards und auch dem Design solcher intelli-genter Gegenstande geklart werden.

Durch die Mobilitat wird das Paradigma der verteilten Anwendung undspontaner Vernetzung gestarkt. Die physische Trennung von Applikations-logik und grafischer Reprasentation erlaubt es auch leistungsschwachen Ge-raten aufwendige Aufgaben zu erledigen. Diese konnen im Hintergrund vonServerdiensten abgearbeitet werden und mussen lediglich fur die Synchroni-sation der Information des GUI-Client sorgen.

4.2.2 Gerateeigenschaften

Die gestiegene Performance und Speicherkapazitat bei mobilen Geraten er-laubt die Darstellung grafischer Inhalte auf Farbdisplays, die bis vor kur-zem noch Desktop-Systemen vorbehalten waren. Mobile Betriebsysteme wieWindows Mobile3 und Symbian4 und systemubergreifende Entwicklungs-plattformen wie Microsoft .NET5 und die Java 2 Platform, Micro Edition(J2ME)6 bieten mit grafischen Toolkits Unterstutzung fur einfache GUI-Programmierung.

Eine weitere Eigenschaft der neuen Gerateklassen sind spezialisierte Ein-und Ausgabehardware. Auf Seiten der Interaktionstechniken reicht die Pa-lette von wandgroßen Displays uber beruhrungsempfindlichen Touch Screensund PDAs mit Bedienstift (stylus) bis hin zu Mobiltelefonen mit mehrfach-belegten Funktionstasten und Joystick oder Richtungstaste fur die Naviga-tion. Durch Wegfall von Maus und Tastatur muss die Navigation durch dasUser Interface anders ausgelegt sein. Am Beispiel einer einfachen Textein-gabe lasst sich der Paradigmenwechsel leicht erklaren. Durch die Populari-tat des Short Message Services (SMS ) zeigt sich, dass es dem Konsumentenselbst am Mobiltelefon ein Bedurfnis ist, Texte zu verfassen. Das neue Be-dienungskonzept, das fur wenigen Tasten mehrfache Buchstabenbelegungenerfordert, wird trotz der offensichtlichen Nachteile in Kauf genommen. AmPDA ist die selbe Funktionalitat in mehrfacher Ausfuhrung vorhanden: DerBedienstift kann dazu benutzt werden, um Zeichen, die auf einer im Displaysichtbaren Tastatur aufgereiht sind, anzuwahlen. Eine neue Form der Inter-aktion bieten die Zeichenerkennung per Handschrift. Als weitere Moglichkeitbieten sich externe Eingabegerate wie das Virtual Laser Keyboard7 an, dasmittels einer Laserprojektion ein Standard-Tastaturlayout auf die Tischober-flache zeichnet. Auch die Forschung mit Spracherkennung und Analyse vonVideobildern mittels integrierter Kamera lassen auf zukunftige, alternative

3Windows Mobile - http://www.microsoft.com/windowsmobile/4Symbian OS - http://www.symbian.com/5.NET Compact Framework - http://msdn.microsoft.com/netframework/programming/

netcf/6Java Micro Edition - http://java.sun.com/javame/7Virtual Laser Keyboard - http://www.virtual-laser-keyboard.com/

Page 41: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 32

Interaktionstechniken hoffen.Alle Gerate verfugen mittlerweile uber Farbdisplays in unterschiedlichen

Ausfuhrungen. Die Auflosung und Skalierung des Displays hat ebenfalls si-gnifikante Auswirkungen auf die Anzahl und Anordnung der grafischen Ele-mente die in einem GUI dargestellt werden konnen [26]. Die Bandbereitereicht von kleinen Mobiltelefon-Displays bis zu hochauflosenden Bildschir-men. Trotz des Vorhandenseins gemeinsamer, grafischer Toolkits kann auf-grund der Varianten bei Ein- und Ausgabegeraten nicht jeder grafische Inhaltgleich reprasentiert werden. Erschwerend kommt noch hinzu, dass nicht ein-mal gemeinsame Gerateklassen uber gleiches Hardwarelayout verfugen undStandards in dieser, bedingt durch den großen Wettbewerb, heterogenenLandschaft nur sehr schwer Fuß fassen.

Die Entwicklung von Plattform-ubergreifenden Applikationen in perva-siven Umgebungen erfordert neue Konzepte im Umgang mit Software undderen grafischer Darstellung. Rapid Prototyping [9], die schnelle und teilau-tomatisierte Entwicklung von (prototypischen) Implementierungen, ist dabeiebenso ein Thema wie Techniken zur abstrakten Beschreibung und Modellie-rung von Funktionalitat einer Applikation. Auf Basis dieser Anstrengungenkonnen Versuche zur automatisierten Generierung grafischer Benutzerober-flachen unternommen werden.

4.3 Techniken der GUI-Entwicklung

4.3.1 Window Manager und Toolkits

Eine Reihe an Konzepten fuhrt zu den heute angewandten und weit verbrei-teten Techniken in der Entwicklung grafischer User Interfaces. Zu den großenErrungenschaften der Window Manager zahlt die Tiefenstaffelung und Ska-lierbarkeit von Fenstern, die schnelles Wechseln zwischen parallel laufen-den Anwendungen ermoglichen. Window Manager sind Teil des Betriebsy-stems und bieten grundlegende grafische Operationen (Zeichnen, Updatendes Bildschirms) und Schnittstellen fur die Ereignisbehandlung an. Aufbau-end auf diesem abstrakten Modell stellen grafische Toolkits ein meist kom-ponentenbasiertes Framework fur einfaches Arbeiten mit konkreten GUI-Elementen in einer bestimmten Programmiersprache zur Verfugung. Sie ge-wahrleisten bis zu einem gewissen Grad Konsistenz hinsichtlich der Ereig-nisbehandlung und dem Zeichnen der grafischen Komponenten und durfendaher keinen starken Anderungen in der Programmbibliothek(API ) unter-worfen sein.

4.3.2 Web-basierte Entwicklungen

In der Web-Entwicklung fuhrte ein Zusammenspiel aus der Seitenbeschrei-bungssprache HTML, der Layoutbeschreibung CSS und Client- und server-

Page 42: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 33

seitigen Scriptsprachen (Javascript, PHP, Perl) zum kommerziellen Durch-bruch. Diese Sprachen mussen nicht kompiliert sondern lediglich zur Laufzeitinterpretiert werden und eroffnen durch leicht verstandliche Ansatze einemgroßen Personenkreis Zugang zur Programmierung. Ein Nachteil liegt in derprozeduralen Abarbeitung des Programmcodes und der fehlenden Trennungzwischen Datenhaltung, Prasentationslogik und Applikationslogik (Model-View-Controller oder MVC ). Der großen Erfolg von webbasierten Dienstlei-stungen fuhrte dazu, dass fuhrende objektorientierte Programmiersprachenmit eigenen Scriptsprachen aufwarten und dadurch das MVC-Prinzip be-starken. Microsofts .NET Plattform arbeitet hier mit C# und Active ServerPages (ASP). In der Java-Domane erfullen Java Server Pages und Servletsdiese Aufgabe.

Ein großer Nachteil von Webapplikationen liegt in dem zustandlosenTransportprotokoll HTTP8 begrundet, das die Verbindung zwischen Cli-ent und Server nur fur den Zeitraum eines Request/Response-Zyklus offenhalt. Dadurch ist die grafische Oberflache gezwungen, bei jeder Interak-tion, die Datenzugriff auf den Server verlangt, die Inhalte neu zu laden.Neue in Browser integrierte Technologien wie Asynchronous JavaScript andXML (Ajax) [2], die vermehrte Verwendung von Web Services9 und SOAPals XML- und HTTP-basierte Remote Procedure Call-Variante (RPC) ver-suchen diesen Nachteil mit Hilfe asynchroner Datenubertragung im Hin-tergrund ungeschehen zu machen. Auch proprietare Rich Client Plattfor-men wie die Macromedia Flash Platform10 [19], arbeiten in dieser Hin-sicht mit persistenten Verbindungen. Beispielhafte Anwendungen hierfursind die Kartographie-Software Google Maps11 und Services basierend aufder Online-Fotodatenbank Flickr12.

Mobiles Web

Die fortschreitende Entwicklung mobiler Endgerate ermoglicht die Nutzungvon Webinhalten und Rich Media-Applikationen auch zunehmend auf SmartPhones und PDAs. Mehrere vielversprechende Konzepte versuchen beste-hende Technologien auf mobile Plattformen zu portieren. In [41] wird dieIdee eines zukunftigen, einheitlichen User Interfaces fur dynamische, webba-sierte Services erlautert:

The next logical step in this evolution is to extend the browserto become the UI container for the smart phone platform. Movingon from the rich media and application platform just described,

8Das Hypertext Transfer Protocol wurde durch die Internet Engineering Task Forcespezifiziert (IETF) http://www.ietf.org/rfc/rfc2616.txt.

9Web Services (Spezifikation der W3C) - http://www.w3.org/2002/ws/10Macromedia Flash Platform - http://www.adobe.com/de/platform/11Google Maps - http://maps.google.com/12Flickr Services - http://www.flickr.com/services/

Page 43: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 34

by adding the ability to interact with the underlying smart phonehardware and file system, the Web browser can become the enginefor the smart phone UI.

Drei Methoden wurden als richtungsweisend identifiziert: Die mobileJava-Plattform J2ME, in den Browser integrierte XML GUI-Sprachen wieXUL (siehe Kapitel 4.4.2) und standardisierte und proprietare Auszeich-nungssprachen und Scriptsprachen namens Macromedia Flash, JavaScriptund das Vektorgrafikformat SVG.

4.3.3 Interaktive GUI-Builder

GUI-Builder Werkzeuge gehen Hand in Hand mit dem eigentlichen Ziel dergrafischen Programmierung. Mit Hilfe eines Modellierwerkzeuges wird dieOberflache aus elementaren Teilen wie Fenster, Button, Textfeld, etc. zusam-mengesetzt und anschließend in editierbaren Programmcode fur die objek-torientierte Zielsprache konvertiert. Je nach Ausmaß der Bindung zwischender Grafikbibliothek der Programmiersprache und Entwicklungsumgebung(Integrated Development Environment (IDE)) konnen Ereignisbehandlung,Anderungen von Layout-Eigenschaften und auch die Datenanbindung an dasInterface integrativer Bestandteil des GUI-Builders sein. Visual Studio bie-tet eine solche Entwicklungsumgebung fur die eigenen ProgrammiersprachenC# und Visual Basic. Auch fur die Java GUI-Bibliotheken Abstract Win-dow Toolkit (AWT) und Swing stellen mehrere EntwicklungsumgebungenGUI-Builder zur Verfugung.

4.4 XML GUI-Sprachen

XML als Metasprache mit baumartiger Gliederung eignet sich sehr gut zurDefinition von Auszeichnungssprachen, die die komponentenbasierte Struk-tur und hierarchische Anordnung von grafischen Elementen beschreiben. Esexistiert eine Vielzahl an XML GUI-Dialekten, die auf unterschiedlichen Ab-straktionsebenen ein grafisches Interface fur verschiedene Aufgabengebietespezifizieren. 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 Laufzeitumgebungeines 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 Bindungzu 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 gerate- und plattformu-nabhangige Beschreibung moglich, verlangt aber im Gegenzug mehr Auf-

Page 44: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 35

wand und Intelligenz bei der Auswertung der enthaltenen Information durchTransformatoren 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 fur Applikationsentwicklungen im kommenden Betriebs-system Windows Vista bildet und in vier Bereiche gegliedert ist. Neben demKommunikationsmodell Windows Communication Foundation (WCF), demProgrammiermodell Windows Workflow Foundation (WF) und sicherheits-und authentifizierungsrelevanten InfoCard-Komponenten ist die WindowsPresentation Foundation (WPF) fur die grafische Aufbereitung in Vista zu-standig. Als Teil dieses Subsystems wurde die Extensible Application Mar-kup Language (XAML) als XML-basierte Beschreibungssprache fur User In-terfaces konzipiert. Ziel ist die Trennung von Logik und Prasentationsschicht,sowie die nahtlose Zusammenarbeit mit bestehenden .NET-Technologien.So kann die Ereignisbehandlung, etwa ein Button-Klick, in externe C# oderVB.NET Codefragmente ausgelagert werden, die in XAML referenziert wer-den. Innerhalb des Dokuments konnen auch Layouteigenschaften und ein-fache visuelle Effekte wie Transparenz festgelegt werden. Daruber hinausist XAML als deklarative Sprache zur Darstellung folgender multimedialerInhalte, die Anlehnung an bestehenden Standards nehmen, angedacht14:

• Layout: Ahnlich HTML und dem Portable Document Format (PDF)soll es mit Flow-Format und Fixed-Format Dokumenten Unterstutz-ung fur verschiedene Text- und Objektlayoutdefinitionen und inte-grierte Steuerelemente fur 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 dieXML-basierten W3C-Standards SVG (Scalable Vector Graphics) fur2D Grafiken und das Prasentationsformat SMIL (Synchronized Mul-timedia Integration Language).

• Daten Anbindung: Direkte Anbindung an Datenquellen wie Webser-vices und anderen XML-Daten ist ohne programmatischen Mehrauf-wand moglich.

• Technologieubergreifendes Formularwesen - In XAML festge-legte Oberflachen konnen sowohl fur die Interface-Generierung vonWebanwendungen als auch fur Desktop-Applikationen eingesetzt wer-

13WinFX API - http://msdn.microsoft.com/winfx/technologies/default.aspx14XAML - http://www.xaml.net/

Page 45: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 36

den und ersetzen damit unterschiedliche Technologien wie WindowsForms und das webbasierte Formularwesen in ASP.NET.

4.4.2 XUL

XML User Interface Language (XUL)15 ist eine von Mozilla spezifizierteGUI-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-formunabhangiger Benutzeroberflachen entwickelt und versucht mit Hilfevon Technologien wie XML-Transformationen, CSS und JavaScript den Im-plementierungsaufwand fur grafische Oberflachen, der durch die Mischungdieser verschiedenen Standards entsteht, zu minimieren. Zusatzlich wird ander 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, beschaftigen sich mehrereProjekte mit XUL Implementierungen16 und Anwendungen17. Mit der Er-findung von XUL versucht Mozilla dem durch lange Perioden der Stagnationgepragten Prozess der Standardisierung von Web-Technologien zu entkom-men und aufbauend auf vorhandenen Losungen einen weiteren Schritt inRichtung Unabhangigkeit von XHTML-basierten Services zu wagen.

Die Idee dahinter sieht eine Aufteilung von Kompetenzen in vier Bereichevor: Fur die Beschreibung der baumartigen Struktur und den Inhalt desgrafischen Interfaces ist die XUL-Datei verantwortlich. Das Look & Feel desProgramms ubernimmt ein eingebetteter oder referenzierter CSS-Code unddie Ereignisbehandlung wird an JavaScript-Anweisungen ubertragen. Alleinternationalisierten Bezeichner einer GUI-Anwendung werden ebenfalls ineiner externen Datei festgelegt.

Wie auch XAML befindet sich XUL noch in der Entwicklungsphase, dievon einigen wenige Quellen dokumentiert wird18.

4.4.3 XForms

Das XForms-Konzept19 ist aus der Notwendigkeit entstanden, das veralteteFormularwesen in HMTL abzulosen. XForms ist ein XML basierter Stan-dard und vollzieht eine klare Trennung zwischen der Prasentationsschichtund dem dahinter liegenden Formularmodell [6]. Diese modulare Auslegung

15Mozilla XUL - http://www.mozilla.org/projects/xul/16Luxor XUL - http://luxor-xul.sourceforge.net/17Mozilla Amazon Browser - http://www.faser.net/mab/18XUL Planet (Dokumentation des XUL Entwicklungsprozesses) - http://www.xulplanet.

com/tutorials/mozsdk/19XForms - http://www.w3.org/MarkUp/Forms/

Page 46: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 37

���

��

�$�"# ������

,� ����'�#���0�,���1�&-12223

�$�"# � �"�����"4'�

����������

�����

������ ! ���

��������! ���

Abbildung 4.1: XForms-Architektur (siehe [14]).

erlaubt die Definition von Formularen unabhangig vom konkreten, grafi-schen Erscheinungsbild und dem Endgerat. So sind neben einem XFormUser Interface auch XHTML, WML und proprietare GUI-Renderings denk-bar. Aufgabe der XForms ist das Sammeln von Daten (instance data), dieuber das XForms Submit Protocol zwischen Server und Client ausgetauschtwerden. Die Unterbrechung und Wiederaufnahme von Formulareintragenund die Definition von Ablaufen sind ebenfalls Teil der Spezifikation. DieValidierung von Formularen muss nicht wie in XHTML mit einer gesondertScriptsprache vorgenommen werden, sondern ist Teil der Spezifikation. Sokann etwa die Reihenfolge der Formulareingaben, sowie die Uberprufungvon Datentypen lokal vorgenommen werden, sofern diese im XML-Schemaspezifiziert wurden.

Die Teilung von XForms in die Bereiche Prasentation, Logik und Da-tenhaltung vollzieht sich auch in der Dokumentenstruktur. Es ist wichtigzu verstehen, dass XForms kein eigenes Dokumentenformat definieren undaufgrund des Aspektes der Gerateunabhangigkeit in andere Dokumente wieXHTML eingebettet werden konnen (Host Document, siehe Abb. 4.1). Darinenthalten sind der XForms User Interface-Container und der XForms Model-Container. Ersterer gibt Auskunft uber die Anordnung der GUI-Elementeinnerhalb des Formulars. Das XForms Model hingegen hat drei Aufgaben: Esist fur die Datenhaltung (instance), die Datenbindung an das Formular (bin-ding) und die Abhandlung der Eingabeereignisse, die auch die Validierung

Page 47: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 38

��������������� �������������������������������������

���4�"#�����!�'�

����"4'�

���"

��.�'

���������

����

�� �� �

"�#�����

�"� �������

�++��'����

������"'�

$%��� �����

�&� '�� �����

Abbildung 4.2: UIML Architektur (siehe [1]).

mit einbezieht (submission) zustandig. Zu den weitgefassten Designzielenvon XForms zahlen auch die Unterstutzung von mobilen Endgeraten unddie Generierung von Rich User Interfaces zur Steuerung von Geraten 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 plattformunabhangig,gerateunabhangig und auch von der Vorstellung eines grafischen Interfaceslosgelost sein soll. Das Mapping von abstrakten Interaktionselementen in diespezifischen Sprachen Java, HTML, WML und VoiceXML, eine Sprache zurGenerierung von sprachgesteuerten Interfaces (auditory displays), wird inder aktuellen Spezifikation [1] aus dem Jahr 2004 unterstutzt. Diese Trans-formationsaufgabe wird dabei von speziellen Renderern ubernommen, dieeinmal fur jede Sprache implementiert werden mussen.

UIML selbst definiert nur sehr wenige XML-Tags. Ahnlich der DocumentType Definition (DTD) fur die Definition eines spezifischen XML-Dialektsmuss ein Vokabular, das ein direktes Mapping in eine Zielsprache oder eineallgemeinere Beschreibung vorsieht, fur das Arbeiten mit UIML geschaffenwerden. Die Komponenten eines Interfaces werden daher als Elemente miteiner eindeutigen Id und einem Verweis auf eine Klasse gekennzeichnet.

Die Prasentation, die Anbindung an externe Datenquellen und das In-teraktionsverhalten sind ebenfalls Teil der Sprachdefinition, die sich amModel-View-Controller Designpattern orientiert (siehe Abb. 4.2). Auch UI-Templates und zeitliche Veranderungen der Interface-Struktur, die durchOffnen eines neuen Fensters entstehen konnen, werden in UIML berucksich-tigt. Die grundlegende Struktur ist in folgende Bereiche gegliedert:

1 <uiml xmlns=’http:// uiml.org/dtds/UIML3_0a.dtd’>

2 <head > ... </head >

20UIML - http://www.uiml.org/

Page 48: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 39

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 konnen uber den Klassennamen und die Id vonanderen Tags referenziert und mit Zusatzinformation wie Styleattributen<property> versehen werden. In <presentation> wird das konkrete Mappingzwischen 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 Reprasentation von Daten fuhrtezum Design der Extensible Interface Markup Language (XIML)21. Die Aus-legung der Sprache umfasst die ganzheitliche Unterstutzung vom UI-Design-prozess, uber das Mapping zwischen abstrakten und konkreten Steuerele-

21XIML - http://www.ximl.org/

Page 49: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 40

menten bis hin zu Evaluierungsfunktionen und der Einbindung von wissens-basierten Systemen zur Auswertung aller vorhandener Daten. XIML will dasParadigma interoperabler, vernetzter Softwaresysteme auch auf die Ebenedes User Interfaces ausweiten, indem ein einheitlicher Standard fur die Pra-sentation und den Austausch von Interaktionsdaten definiert wird [29]. Eineschwierige Aufgabe in Anbetracht der Tatsache, dass zu den komplexen An-forderungen von Interaktion und der Modellierung von Navigationsablau-fen auch noch plattformubergreifende Synchronisation und Kontext-basierteEinflusse hinzukommen konnen.

Die Architektur von XIML definiert kontextuelle und strukturale Mo-delle und die Reprasentation eines Interfaces und bringt sie in einen relatio-nalen Zusammenhang. Daher lasst die Nomenklatur dem Begriff der Kompo-nente eine weitlaufigere Bedeutung als in den meisten XML-GUI Sprachenzukommen. Funf Komponenten, die eine Sammlung an Elementen beinhal-ten, wurden festgelegt [29]:

1. Task: Die Task-Komponente liefert eine abstrakte Beschreibung al-ler Vorgange, die die Interaktion mit dem Benutzer betreffen. Sowohldie hierarchische Ordnung, als auch der Workflow konnen eingefan-gen werden. Beispiele fur Vorgange sind eine Datumseingabe oder dasStarten eines CD-Players.

2. Domain: Domain-Information bezeichnet anwendungsrelevante Ob-jekte und Datentypen unterschiedlicher Komplexitat, die mit dem In-terface in Verbindung gebracht werden. Etwa ein Datum oder ein ab-straktes Medienabspielgerat. Objekte werden in XIML als Attributedefiniert, die elementare Datentypen oder Instanzen von komplexenObjekten sind.

3. User: Die User-Komponente halt alle benutzerspezifischen Informa-tionen fest und erlaubt die Definition von Benutzergruppen.

4. Presentation: Die Prasentationsschicht beschreibt den hierarchischenAufbau des User Interfaces mit abstrakten Elementen wie einem Win-dow oder einem Button. Fur die Transformation in ein konkretes Er-scheinungsbild ist ein Konverter fur jede Plattform notig.

5. Dialog: Der Dialog definiert alle Interaktionen und die erlaubte Navi-gationsstruktur fur 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_components >

6 <task_model id="dictionary ">...</task_model >

7 <domain_model id="dictobjects ">...</domain_model >

Page 50: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 41

��������������� �������������������������������������

���������"4'��+�'�4�'����

����� ���� ����� � ��(

����� ���� ����� � ��)

*+%��� ������

$%��� ������

Abbildung 4.3: XIML Architektur (siehe [29]).

8 <user_model id="dictobjects ">...</user_model >

9 <presentation_model id="java">...</presentation_model >

10 <dialog_model id="dictdialog ">...</dialog_model >

11 </model_components >

12 </interface >

Ein- und Mehrfachbeziehungen zwischen den Elementen dieser Modellekomplementieren das gesammelte Wissen fur ein konkretes Interface-Ren-dering. Die Datenauswertung ist Teil des XIML-Frameworks. Die Sprachesieht vor, dass zu einem GUI fur jede Plattform eine eigene Prasentations-komponente deklariert werden muss, die verarbeitet und angezeigt werdenkann.

Ist die Unterstutzung mangels XML-Parser oder anderer, fehlender Vor-rausetzungen nicht gegeben, kommen Konverter zum Einsatz. Um nicht furjede GUI-Anwendung neue Komponenten spezifizieren zu mussen, gibt esauch in XIML die Moglichkeit eine plattformubergreifende Prasentations-schicht mit abstrakten Elementbeschreibungen einzufuhren (siehe Abb. 4.3und Abb. 4.4). Es wird nicht definiert, wie diese Abstraktion auszusehen hatund welche organisatorischen und semantischen Informationen darin enthal-ten sind. Unter dem Begriff Intelligent Interaction Management werden wis-sensbasierte Systeme unterstutzt, die zur Laufzeit Personalisierung von In-halten, dynamische Anpassung der Informationsdichte und Synchronisationvon Interaktionsinformation zwischen mehreren GUI-Instanzen ermoglichensollen.

Der hohe Abstraktionsgrad und die vielen Funktionen zwingen selbst beikleinen GUI-Projekten zu einer umfassenden Deklaration der Modelle undRelationen. Das folgende Codestuck 4.1 zeigt die fur ein einfaches Java AWTFenster notigen Definitionen der Prasentationskomponente:

Listing 4.1: Java AWT Fenster - Prasentationskomponente1 <presentation_model id="dictbasicpres ">

2 <name > basic presentation model for the dictionary </name >

3 <!-- definition of presentation elements -->

4 <definitions >

5 <relation_definition name="mainwindow_is_a_aiowindow">

Page 51: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 42

��������������� �������������������������������������

���������"4'��+�'�4�'����

! �������������� ���� ����� � �

����� ���� ����� � ��(

����� ���� ����� � ��)

*+%��� ������

$%��� ������

5��/���.�6� ����( ��#

Abbildung 4.4: XIML Architektur mit Intermediate Presentation Compo-nent (siehe [29]).

6 <allowed_classes >

7 <class reference ="mainwindow " slot="left" />

8 <class reference ="aiowindow " slot="right" />

9 </allowed_classes >

10 </relation_definition >

11 </definitions >

12 <!-- here is the hierarchy of presentation elements -->

13 <presentation_element id="mainwindow " location="optional">

14 <name > dictionary main window </name >

15 <presentation_element id="deflabel" location="optional ">

16 <name > dictionary definition label </name >

17 </presentation_element>

18 <presentation_element id="termslist " location="optional ">

19 <name > list of terms in the dictionary </name >

20 </presentation_element>

21 </presentation_element>

22 <!-- now are the definitions of the (aios) themselves -->

23 <presentation_element id="aiowindow " location="optional">

24 <name > definition of the abstract window </name >

25 <presentation_element id="javawindow "

26 location="http://www.ximl.org/ui/javaawtrender .ui#awt">

27 <name >rendered for the java toolkit</name >

28 </presentation_element>

29 <presentation_element id="winntwindow "

30 location="http://www.ximl.org/ui/winnt/window.vbx">

31 <name >rendered for the windows nt environment </name >

32 </presentation_element>

33 </presentation_element>

34 </presentation_model >

4.5 Model-based User Interface

XML-basierende GUI-Sprachen bieten eine Moglichkeit fur die automati-sierte Erstellung von grafischen Oberflachen. Je abstrakter jedoch die Defini-tion des grafischen User Interfaces ausgelegt ist, desto schwieriger ist es, allenotigen Anforderungen im Voraus festzulegen. Wie am Beispiel von UIML

Page 52: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 43

und XIML zu sehen ist, ist der Aufwand fur eine generische, deklarativeBeschreibung mit zunehmender Komplexitat einer GUI-Anwendung hohereinzuschatzen, als eine programmatische Losung. Zudem mussen ohnehinTransformationswerkzeuge implementiert werden, die Quellcode fur die spe-zifische Plattform oder -sprache erzeugen. In dieser Hinsicht haben XAMLund XUL den Vorteil der engen Bindung an bestehende Softwaresysteme,die eine Entwicklung von GUI-Anwendungen auch ohne programmatischenMehraufwand erlauben.

All diese Konzepte stehen aber in Widerspruch zu den Anforderungen ei-nes plattformubergreifenden User Interfaces, das dynamischen Anderungenzur Laufzeit unterliegt und dabei kontextbezogene Informationen mit ein-bezieht. Model-based User Interface Tools sind Systeme zur automatisiertenErfassung 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 derSoftwareentwicklung waren, wurden dennoch grundlegende User InterfaceModelle entworfen, die bis heute Gultigkeit haben. In [32] und [23] wurdenanhand 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 wahrend der Laufzeit der GUI-Applikation.

• Task Model: Das Task Model definiert alle Tasks, die ein User ineinem GUI ausfuhren kann. Diese konnen auch anhand einer Ziel-beschreibung, der Aufteilung in mehrere atomare Subtasks und Zu-standsuberfuhrungen festgehalten werden.

• Application Model: Das Application Model wird auch Object Modeloder Business Model genannt, reprasentiert den Zustand der Applika-tion und listet alle fur das GUI relevanten Schnittstellen und Dienste.Diese decken sich mit den Subtasks des Task Models.

• Dialog Model: Der Dialog ist eine spezifischere Auslegung des TaskModels und beschreibt die tatsachlichen Interaktionsmoglichkeiten ei-ner GUI-Anwendung.

• Presentation Model: Auf Ebene des Presentation Models wird dasRendering des GUIs durchgefuhrt. 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 nachAuslegung des UI Tools wird eine unterschiedliche Kategorisierung derkontextspezifischen Information vorgenommen. Diese umfassen die Be-schreibung der Gerate, die plattformspezifischen Anforderungen und

Page 53: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 44

andere Daten aus dem Umfeld, die fur die Anwendung von Bedeutungsind.

4.5.1 User Interface Generierung

Die User Interfaces Generierung, die sich auf die Informationen aus denverschiedenen Models stutzt, ist mit einer Reihe an Aufgaben verbunden,die es im Zuge des GUI-Rendering Prozesses zu losen gilt [32]. Anhand derbeiden model-based User Interface Tools Supple und Pebbles Personal Uni-versal Controller (siehe Kapitel 4.5.2 und 4.5.3) werden die Schritte nahererlautert:

• Zuerst muss eine Auswertung der Models und eine anschließende Iden-tifizierung aller abstrakten Interface-Elemente passieren. Ein Beispielfur ein abstraktes Interface-Element ist die Definition eines Fenster-menus, das je nach Wahl der Plattform anders aussehen kann, aberimmer die gleiche Funktion erfullt.

• Die spatere Umwandlung in konkrete, plattformabhangige Interface-Elemente wird als Mapping bezeichnet und geschieht zusammen mitder automatisierten Anordnung der Komponenten im Interface.

• Zwecks semantischer Bindung werden Zusatzinformationen zur Ver-haltensmodellierung des Interfaces eingebracht. Damit konnen etwaAbhangigkeiten 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 mussen selbststandig modelliert werden.

• Kaum ein generiertes Interface entspricht in allen Belangen den Vor-stellungen des Designers oder den Bedurfnissen des Users. ZusatzlicheMethoden zur Evaluierung und Revision unter Einbeziehung mensch-licher Beurteilungen sind daher ein adaquates Mittel zur manuellenund automatisierten Abanderung des Interfaces zur Laufzeit.

4.5.2 Projekt – Pebbles Personal Universal Controller

Der Personal Universal Controller (PUC)22 ist ein Forschungsschwerpunktim Rahmen des Pebbles Projektes an der Carnegie Mellon University, dasssich mit der Nutzung von PDAs und Smart Phones als Interaktionsgerat furverteilte Anwendungen beschaftigt. PUC setzt dabei auf die automatisierteGenerierung und Personalisierung von User Interfaces fur Netzwerkdienste,die sich im unmittelbaren Umfeld des Benutzers befinden und mit einer be-liebigen Funktechnologie wie Bluetooth oder WLAN angesprochen werden

22Personal Universal Controller - http://www.pebbles.hcii.cmu.edu/puc/

Page 54: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 45

konnen. Das Konzept ist auf die Entwicklung mobiler Fernsteueranwendun-gen fur die Betriebssysteme PalmOS und Windows Mobile ausgerichtet. DerBegriff des Interfaces ist in PUC nicht nur auf grafische Oberflachen be-schrankt, sondern inkludiert auch Spracheingabe und soll dem Benutzer beider Wahl des favorisierten Interaktionsmediums freie Hand lassen.

Als Basis fur die Erstellung von User Interfaces zur Fernsteuerung vonGeraten dient die eigens definierte XML GUI-Sprache namens PUC Specifi-cation Language23, die eine funktionale Geratespezifikation anhand hierar-chisch strukturierter Gruppierungen, Zustandsvariablen und Steuerbefehlenbeschreibt. Die enthaltene Information ist mit der eines Application Modelsgleichzusetzen.

Systemarchitektur

Abbildung 4.5 zeigt den Systemaufbau von PUC. Da die funktionale Be-schreibung von jedem Endgerat zur Verfugung gestellt werden muss, brauchtes eine einheitliche Kommunikationsschnittstelle zwischen Gerat und Inter-face. Gerade im Bereich der Unterhaltungselektronik ist jedoch kaum eingemeinsamer Standard zu finden. Daher mussen Gerateadapter in Softwareoder Hardware fur die Umsetzung der Befehle des PUC-Protokolls in dasproprietare Protokollformat zwischengeschalten werden. Soweit das Geratbidirektionale Kommunikation unterstutzt, garantiert PUC die Konsistenzzwischen dem Application Model und den Inhalten des Interfaces. Speziellim Niedrigpreissegment sind aber immer noch viele Geraten mit Infrarot-Schnittstellen ausgestattet und konnen nach dem bekannten Prinzip einerFernbedienung lediglich Befehle entgegennehmen.

In PUC existieren nach eigenen Angaben zum gegebenen Zeitpunkt Ad-apter fur Camcorder mit IEEE 139424-Anschluss und dem AV/C Protokoll,Videorecorder die den Steuerungsstandard HAVi25 unterstutzen, den ameri-kanischen Gebaudesteuerungsstandard X1026 und diverse proprietare Hard-ware wie eine Telefonanlage. Die Integration von Jini und UPnP wird inAussicht gestellt.

Obwohl Funktechnologien bevorzugt werden, stellt PUC keine Anforde-rungen an die verwendete Netzwerktechnologie. Es wird jedoch vorausge-setzt, dass jedes Gerat oder dessen Adapter uber eine eigene Netzwerkan-bindung verfugt, um die Peer-to-Peer Kommunikation zwischen Endgeratund dem Interface-Client, die ohne zentralen Verbindungsknoten auskommt,zu ermoglichen. Das XML-basierte Kommunikationsprotokoll ist einfach ge-halten und definiert sechs Befehle zum Austausch von Geratebeschreibung,

23PUC Specification Language - http://www.pebbles.hcii.cmu.edu/puc/specification.html24Die Datenschnittstelle ist auch unter dem Namen FireWire bekannt.25HAVi - urlhttp://www.havi.org/26X10 - http://www.x10.com/home2.html

Page 55: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 46

��������,-.)/((0�"������#0�!�///1

�++��'����

��+��"

�����"���'��

��##���'����

������!�'�

�����"���'��

��##���'����

Abbildung 4.5: PUC Architektur (siehe [28]).

Steuernachrichten und Zustandsanderungen27.

Layout Generierung

Die Geratespezifikation in Form einer funktionalen XML-Beschreibung istdie Basis fur die Generierung eines Interfaces. Innerhalb des Dokumentsist eine Gruppen-Baumstruktur zur Anordnung von Zustandsvariablen undSteuerbefehlen definiert. Die Variable gibt Auskunft uber den Namen, denDatentyp und den Wertebereich des Zustandes. Anhand des Datentyps, derneben primaren Datentypen auch eine Auflistung und eigens definierte Ty-pen erlaubt, wird ein Interface-Element zur Darstellung und Manipulationdes Zustandes ausgewahlt. Dennoch sind in Form von Steuerbefehlen, dieals ausfuhrbare Buttons gerendert werden, zusatzliche Funktionen notig, danicht jeder Zustand im vorhinein bekannt sein kann.

Am Beispiel eines Radios, das einen Button fur den automatischen Fre-quenzsuchlauf benotigt, ist dieses Vorgehen schnell erklart: Wurde man ganzauf die Verwendung von Zustandsvariablen verzichten, entsprache die Model-lierung des Interfaces einer heutigen Hardware-Fernbedienung, die keinerleiRuckmeldung uber die Geratezustande zulasst [28]. Die logische Gruppie-rung erlaubt dem UI-Generator, der fur jede Plattform einmal implemen-tiert werden muss, anfangliche Ruckschlusse uber die Strukturierung derInterface-Elemente.

Durch zusatzlich definierte Abhangigkeiten zwischen den Zustandsva-riablen konnen weitere Rendering-Hinweise abgeleitet werden. Das Displaymobiler Endgerate ist in seiner Große stark eingeschrankt. Daher mussenFunktionen oft in mehreren Reitern angeordnet werden. Werden im Zugeder Auswertungen Gruppierungen und Elementen gefunden, die sich auf-grund von Abhangigkeiten gegenseitig ausschließen, kann diese Informationdazu benutzt werden, um die Interface-Elemente auch lokal von einander

27PUC Communications Protocol - http://www.pebbles.hcii.cmu.edu/puc/protocol spec.html

Page 56: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 47

zu trennen. Ein Beispiel: Eine Stereoanlage definiert die OperationsmodiRadio, 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 Zustande der CD-Sektion sind folglich nur aktiv, wennder CD-Player in Betrieb ist. Das untenstehende Codestuck reprasentiertdie Nummer des aktuellen Musikstuckes und zeigt die Abhangigkeit zumMode-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 Zustanden und Steuerbefehlen zu konkreten Inter-face-Elementen wird mit Hilfe eines Entscheidungsbaumes und damit ver-bundenen Fragen nach dem Typ und anderen Eigenschaften des Elementsgelost. Im Anschluss daran wird das Problem der strukturellen Anordnungdurch 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 inmehrere, sich uberlappende Reiter. Globale Funktionen, die sich auf die Ak-tivitat aller Komponenten auswirken (Einschaltknopf), oder oft genutzt wer-den (Lautstarkeregler), werden durch andere Abhangigkeitsregeln am linkenRand des Interfaces angeordnet und sind immer verfugbar (siehe Abb. 4.6).

Dieses Regel-basierte System wirkt sich nachteilig auf die Skalierbarkeitund Portierbarkeit des PUC-Konzeptes aus, da es mit jeder Anderung aucheine Anderung der plattformabhangigen Rendersysteme nach sich zieht. DerEntscheidungsbaum stellt zudem ein weiteres Hindernis dar, weil das Inter-face in einem Durchgang erstellt wird und keine weitreichenderen Uberle-gungen hinsichtlich des globalen Ergebnisses und geratebedingter Einschran-kungen zulasst [17], wie das im nachsten Beispiel anhand von Supple der Fallist.

Page 57: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 48

Abbildung 4.6: PUC Rendering einer Stereoanlage (siehe [28]).

4.5.3 Projekt – Supple

Supple28 ist ein Softwareprojekt der University of Washington, das in einerlangjahriger Tradition der HCI-Forschung steht. Es basiert auf Erkennt-nissen im Bereich der Entscheidungstheorie und Optimierungsproblematik.Supple ist ein plattformunabhangiges System zur Generierung von dynam-isch-adaptiven User Interfaces fur Java-fahige Endgerate und das Web. Ne-ben einer abstrakten, funktionalen Beschreibung der Applikation auf Ebenedes 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 technischeUmsetzung der Interface Generierung. Die funktionale Beschreibung umfasstdie hierarchische Anordnung von Steuerbefehlen und Zustandsvariablen, vondenen der Name, der Datentyp und Einschrankungen des Wertebereichsbekannt sein mussen. Neben Basisdatentypen konnen auch Vektoren undkomplexere Container-Datentypen definiert werden, die aus ersteren zusam-mengesetzt werden konnen. In Supple wird kein Bedeutungsunterschied zwi-schen der Definition einer Variable und dessen grafischer Auslegung gemacht.Container-Datentypen sind also nichts anderes, als logische Gruppierungenmehrerer Interface-Elemente, die selbst wiederum ein Interface-Element dar-stellen. Das Device Model beschreibt alle konkreten Elemente, die ein Geratzur Verfugung stellt, sowie dessen spezifische Eigenschaften. Supple nimmtauf Eigenschaften wie die Plattform, die Große des Displays und die Inter-aktionsmethode, die mausahnliche Eingabegerate aber auch ein Touchpanel

28Supple - http://www.cs.washington.edu/ai/supple/

Page 58: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 49

�� +�(���!�'��++��'����

��++��

2���%���

������%���

! ������%���

$��'�����3���

�� �����$��'��

����� ���'��

�����������%��#����%���'��

Abbildung 4.7: Supple Architektur (siehe [15]).

sein konnen, Rucksicht. Das User Model sammelt zur Laufzeit Daten desBenutzers, um das Interface den aktuellen Bedurfnissen anzupassen.

Systemarchitektur

Abbildung 4.7 zeigt die Architektur von Supple. Fur 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 Verfugung stellt. Diesererstellt anhand der Device Model Information mehrere plattformabhangigeWidget Proxies und ordnet sie mit Hilfe einer kombinatorischen Suche einemElement zu. Zuletzt werden die bestehenden Verbindungen ausgewertet undfur jedes abstrakte Element ein konkretes UI-Element generiert. Ist die An-bindung der Applikation mit Hilfe von Bean-Objekten realisiert, garantiertSupple die bidirektionale Konsistenz zwischen den Daten des User Interfacesund dem Application Model [15]. Mit dieser Funktionalitat sind mehrere In-stanzen eines GUI mit gleichbleibender Applikationslogik ohne zusatzlichenAufwand denkbar.

Layout Generierung

Supple definiert die Aufgabe des Interface-Rendering als Optimierungspro-blem, das Teil der theoretischen Informatik und des Forschungsgebietes derKunstlichen Intelligenz ist. Das Ziel ist die Suche nach der bestmoglichenDarstellung des User Interfaces unter den gegebenen Einschrankungen undErkenntnissen. Diese sind durch die funktionale Spezifikation des Interface-Models, durch das Device Model und durch die Ablaufverfolgung des Be-nutzers gegeben. Als Maß fur die Optimierung wird eine Kostenfunktion,die den Navigationsaufwand fur den Benutzer darstellt, herangezogen. Dasbestmogliche Interface-Rendering, das aus einer Menge an errechneten Mog-lichkeiten ausgewahlt wird, ist jenes, das den minimalsten Gesamtaufwand

Page 59: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 50

aufweist. Die Kosten einer Moglichkeit konnen als gewichtete Summe einzel-ner Kostenfunktionen der Interface-Elemente beschrieben werden. Die Ko-sten fur ein einzelnes Element setzen sich aus mehreren Faktoren K undzugehorigen Gewichtungsfaktoren uk zusammen, die durch Interaktion desBenutzers fortwahrend adaptiert werden (siehe Formel 4.1 aus [17]).

$(render(e)) =K∑

k=1

uk(render(e)) (4.1)

Als Losungsverfahren des Optimierungsproblems auf Basis der Interface-Kostenfunktion wird der Branch and Bound-Algorithmus29 verwendet, deres erlaubt, die Suche auf ein eindimensionales, rekursives Verfahren zu re-duzieren. Indem der hierarchisch aufgespannte Suchbaum in Subregionenunterteilt wird, die gesondert auf die Grenzen der gesuchten Variablen ana-lysiert werden konnen, fallt es leichter ungultige Losungsbereiche fruhzeitigzu finden und zu verwerfen. Bedingt durch die vielen Abhangigkeiten mus-sen selbst bei einfachen Beispielen wie der Generierung eines User Interfacesfur eine Mediensteuerung bis zu 1,8x109 potentielle Rendering-Variantenbeachtet werden (siehe Abb. 4.8). Mit Hilfe verteilten Wahrscheinlichkeits-berechungen hinsichtlich des zu erwartenden Nutzerverhaltens und heuristi-scher Annaherungsfunktionen an das theoretisch optimalste Interface kannallerdings eine annehmbare Reduktion des Suchraumes erreicht werden. Sostellt die Auswertung fur ein modernes PC-System bei einer durchschnittli-chen Rechendauer von 1s keine allzu großen Schwierigkeiten dar. Fur einenPDA mit eingeschrankter Hardware kann sich diese Zeitdauer jedoch umden Faktor 40 erhohen [17].

Adaptierung und Personalisierung

Ein wichtige Erkenntnis von Supple ist die Tatsache, dass das Ergebnisdes Rendering-Prozesses selten den Erwartungen und Bedurfnissen eines be-stimmten Benutzers entspricht. Die Personalisierung von Inhalten ist daherGegenstand intensiver Forschungen. In Supple sind zwei Arten der Persona-lisierung bekannt [3]: Adaptierung bezeichnet die automatisierte Anderungdes Interfaces auf Basis des Nutzerverhaltens und ist auch im Bereich derkunstlichen Intelligenz unter dem Namen Preference Elicitation bekannt [18]. Die manuelle Anpassung ist eine vom Benutzer initiierte Methode zur Eva-luierung der erwarteten Qualitat 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 Vorgange entdeckt, die sich uber mehrere, von einander

29Branch and Bound Algorithmus - http://www.ie.bilkent.edu.tr/˜omer/research/bb.html

Page 60: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 51

(a) (b)

Abbildung 4.8: Renderings einer Mediensteuerung fur PC (a) und Touch-panel (b). Beide wurden auf dem Desktop-Screen mit einer Auflosung von1680 x 1050 erstellt, nahmen jedoch weniger als den zur Verfugung stehendenPlatz in Anspruch. Die Hauptcontainer des Interfaces (LightBank, A/V Con-trols, Vent) waren ursprunglich sogar untereinander angeordnet und wurdenerst durch eine zusatzliche Großeneinschrankung mit maximal 640 x 480 Pi-xel in eine Form mit ausgewogenem Seitenverhaltnis gebracht.

entfernte Interaktions-Objekte wie Fenster, Popup-Dialoge und Reiter er-strecken, wird versucht diese Wegkosten zu minimieren. Die automatisierteUmstrukturierung von Layout und Elementanordnungen durch Kopie oderVerschieben muss in sorgfaltiger Abwagung der Konsequenzen bedacht wer-den. Dazu zahlt die Desorientierung des Benutzers durch sich dynamischandernde Inhalte als auch der Verlust der Konsistenz zwischen ahnlichenInterfaces.

Fur das Problem der Preference Elicitation wird ein zu Supple komple-mentares System namens Arnauld30 eingesetzt, das ebenfalls entscheidungs-theoretische Optimierungsverfahren verwendet [18]. Example Critiquing be-zeichnet eine vom Benutzer initiierte Anderungen im System und im Fallevon Supple dem konkreten User Interface. Moglich wird dies durch einin Supple enthaltenes Werkzeug, das zur Laufzeit Anderungen 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 zweikleine Knopfe zur Abanderung des Wertes um 1 darstellt, reprasentiert wer-den.

Allein aus dieser Methode lassen sich allerdings nicht immer genugendParameter zur Erstellung der Supple-Kostenfunktion und nachhaltigen Ver-

30Arnauld - http://www.cs.washington.edu/ai/arnauld/

Page 61: UPnP Diplomarbeit

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 52

Abbildung 4.9: Supple – Werkzeug zur dynamischen Anderung von GUI-Komponenten zur Laufzeit.

besserung der subjektiven Qualitat des Interfaces ermitteln. Fur diese Fallegeneriert Arnauld einfache binare Fragen, die zwei konkrete Interface-Ren-derings oder einfache Interface-Elemente miteinander vergleicht und denUser nach dem qualitativ besseren Ergebnis fragt. Wichtig ist dabei, dassauch die Fragen signifikanter Relevanz sein mussen, um genugend Informa-tionen extrahieren zu konnen. In diesem Zusammenhang muss dem Benutzerder Unterschied zwischen den Renderings bewusst sein, um ein Urteil fallenzu konnen. Betrifft die Frage etwa nur das Aussehen eines einzelnen Ele-ments, so muss diese in einem auffolgenden Schritt auch im Kontext desgesamten Interfaces prasentiert werden, um dieses Bewusstsein zu gewahr-leisten [18].

Page 62: UPnP Diplomarbeit

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 verfugt uber geeignete Schnittstellen zur Anbindung externerApplikationslogik. Diese muss in der Lage sein, einen Bezug zwischen demtechnischen Aufbau des Interfaces und der zugrundeliegenden Aufgabe derAnwendung herzustellen. Diese Verbindung ist grundsatzlich bei jeder Soft-ware der Fall, bei der sowohl die Benutzeroberflache als auch die Logik ge-meinsam entwickelt werden. Verteilte Netzwerkgerate liefern hingegen nurfunktionale Beschreibungen der Schnittstellen ohne Bezug auf den Kontextder Anwendung zu nehmen oder gar Auslegung und Verhalten eines grafi-schen Interfaces zu definieren. Die Service-Plattform UPnP integriert mitAbsicht keine Unterstutzung fur Benutzeroberflachen, um die herstellerspe-zifische Individualitat der Produkte zu gewahrleisten [7]. Die zur Verfugungstehenden Controlpoint-Implementierungen bieten lediglich ein rudimenta-res Interface zur zentralen Fernsteuerung der UPnP-Gerate und sind furLaien nur schwer bedienbar (siehe Abb.5.1).

Aus dieser Uberlegung heraus entstand die Idee zu einer Erweiterungdes UPnP-Standards, die den Nutzen einer einheitlichen Service-Plattformauf das User Interface ausweitet und so zu einem Gesamtkonzept fur dieSteuerung verteilter Anwendungen und Geratedienste beitragt. Dafur mus-sen folgende Anforderungen erfullt werden:

• Zur Fernsteuerung von UPnP-Geraten soll ein ein gemeinsames UserInterface erstellt werden, das in ansprechender Form prasentieren undintuitiv bedienbar sein.

• Zusatzlich zu der funktionalen UPnP-Geratespezifikation muss eine In-formationsquelle gefunden werden, die Aufschluss uber die semantischeZusammengehorigkeit von Interface-Elementen und dadurch zwischenden einzelnen, ausfuhrbaren UPnP-Aktionen gibt.

53

Page 63: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 54

1

Abbildung 5.1: Cyberlink Controlpoint (siehe auch Kap. 3.3) – Entlang ei-ner Baumstruktur werden die Services, Aktionen und Zustandsvariablen derUPnP-Gerate gelistet. Erst auf dritter Ebene ist das Ausfuhren einer Ak-tion moglich. Eine eklatante Schwache hinsichtlich der Benutzerfreundlich-keit zeigt folgender Fall: Wurde ein neues Gerat gefunden oder vom Netzwerkabgemeldet, wird der gesamte Baum geschlossen und neu aufgebaut.

• Es durfen keine Einschrankungen hinsichtlich der Funktionalitat be-stehender UPnP-Mechanismen gemacht werden.

• Ein UPnP-basierter GUI-Builder soll fur mehrere Plattformen reali-siert werden. Neben der Entwicklung einer PC-Anwendung mit demSupple-Toolkit soll auch ein reduziertes User Interface fur Smart Pho-nes implementiert werden. Das mobile Endgerat wird am besten demParadigma einer universell einsetzbaren und drahtlosen Fernsteuerunggerecht.

• Sofern die Moglichkeit gegeben ist, soll mit dem UPnP Event-Mecha-nismus und der gemeinsamen Datenhaltung Konsistenz zwischen denInhalten der verschiedenen User Interfaces erreicht werden. Konsistenzbedeutet in dieser Hinsicht, dass Anderungen an einem Interface desgesteuerten UPnP-Dienstes auch auf andere Interface-Renderings, diedie selben Gerateinhalte darstellen, reflektiert werden sollen.

5.1.1 System-Schnittstellen

Fur die Implementierung des GUI-Builder Prototyps wird ein OSGi-Frame-work mit einem Bundle zur Kommunikation mit UPnP eingesetzt.

Page 64: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 55

�(��"���*

��#�/"��� ���"�!�"

�������!�'��� �#+�"��"�7+�"��"

�������!�'��8

&�"����������!�'��8

�����

&�"����������!�'���

��

���

���������

������������

Abbildung 5.2: Aufbau des Domoware Base Drivers (siehe Domoware Ho-mepage).

OSGi-Framework

Um eine Vereinfachung des Entwicklungsprozesses und maximale Kompa-tibilitat zwischen den einzelnen Softwarekomponenten zu erreichen, wirdein OSGi-Framework Release 4 eingesetzt. Die Entwicklung des UPnP-GUIBuilders wird mit dem Eclipse Equinox 2 Framework realisiert. Equinox istein Teil der Java-Entwicklungsumgebung Eclipse IDE und wird fur das Ma-nagement der OSGi-Plugins (Bundles) verwendet. Durch die enge Bindungzwischen OSGi-Framework und IDE konnen OSGi-Bundles in Eclipse ent-worfen und auch direkt darin getestet werden.

UPnP-OSGi Gateway

Fur die Integration von UPnP in das OSGi Service-Framework steht derUPnP Base Driver von Domoware3 zur Verfugung. Das Bundle agiert dabeials Gateway zwischen den beiden Standards. Es importiert alle gefundenenUPnP-Gerate als generische OSGi-Services und hilft beim Export aller inOSGi entwickelten UPnP-Gerate ins UPnP-Netzwerk (siehe Abb. 5.2 vonder Domoware-Website4).

2Eclipse Equinox - http://www.eclipse.org/equinox/3Domoware - http://domoware.isti.cnr.it/4Domoware UPnP Base Driver - http://domoware.isti.cnr.it/documentation.html

Page 65: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 56

5.1.2 Setup

Das in Abbildung 5.3 ersichtliche Setup zeigt die Zusammenhange zwischenden einzelnen Applikationen. Der GUI-Builder PC ist als OSGi-Bundle ent-worfen und hat auf die OSGi-internen und, uber den Base Driver, auf die ex-ternen UPnP-Gerate Zugriff. Er nutzt die von den verteilten UPnP-Geratenzur Verfugung gestellte, XML-Geratebeschreibung, um anhand dieser Infor-mation ein User Interface zu generieren.

Das selbe Konzept wird beim mobilen GUI-Builder angewandt. DieseAnwendung 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 eigenstandiger UPnP-Controlpoint und bereitet die Informationen der gefundenen UPnP-Geratefur den Client auf. Ist ein Smart Phone uber Bluetooth zum Gateway ver-bunden, bekommt es die Geratebeschreibungen ubermittelt und generiert einGUI zur Fernsteuerung. Die bei der Interaktion durch den Benutzer erzeug-ten Befehle werden anschließend an das Gateway zuruckgeschickt und vondiesem auf dem angesteuerten UPnP-Gerat ausfuhrt. Diese Server/Client-Architektur hat den Vorteil, dass speicherintensive Aufgaben wie das Parsenvon XML-Beschreibungen und die Datenhaltung, die am mobilen Endgeratzu Performanceengpassen fuhren wurden, auf den Gateway-Server ausgela-gert werden konnen. Das mobile Endgerat muss sich nur um die Darstellungund Kommunikation kummern.

5.2 Implementierung - PC

Die Implementierung des GUI-Builders wird anhand folgender Bereiche er-lautert:

• OSGi-spezifische Entwicklungsmerkmale, die die Bundle-Struktur unddie Anbindung an die UPnP-Welt beleuchten.

• Die Beschreibung des Systemaufbaus.

• Die Implementierung des GUI-Generators mit Hilfe des Supple Tool-kits.

• Erweiterung der UPnP-Geratespezifikation durch die Integration rele-vanter Zusatzinformationen fur eine verbesserte GUI-Generierung.

5.2.1 Entwicklung mit OSGi

Ein OSGi-Bundle ist das Herzstuck des GUI-Builders. Es ist nicht alleinelauffahig, sondern muss innerhalb eines OSGi-Frameworks gestartet werden.Jedes Bundle stellt hierfur eine Activator -Schnittstelle zur Verfugung. Diesewird beim Starten des Framework aktiviert und kennzeichnet den Eintritts-punkt in das Programm. Darauf kann eine herkommliche Java-Applikation

Page 66: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 57

� ��"�!�"�������

�������!�'�

�� '2������

��-����"�

������!�'�������

��������/�"*

������!�'�������

��������������� �������������������������������������

-���������"��

����������-��/(����"��+����������

-���������"

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 uber eine zentrale Registrierungsstelleim Framework. Dort konnen Services registriert werden, die zur Laufzeitzur Verfugung stehen. Alle Bundles konnen sich als Listener fur beliebigeService-Klassen anmelden und werden uber Zustandsanderungen wie etwadie An- und Abmeldung von zugehorigen Objekten, informiert. OSGi ent-halt eine Reihe an vordefinierten Services. Dazu zahlt eine einfach gehaltenUPnP-Gerateklasse mit Zugriff auf UPnP-Services, Aktionen und Zustands-variablen. Mit Hilfe dieser OSGi-Serviceschnittstelle fur UPnP meldet derDomoware Basedriver alle gefundenen UPnP-Gerate an.

Eine weitere Eigenschaft von OSGi ist die Einbindung passiver Bundles,die nichts anderes als globale Programmbibliotheken darstellen. Fur alle ak-tiven und passiven Bundles konnen Klassen-spezifische Zugriffsrechte mit-tels einer Manifest-Datei konfiguriert werden. Die Modularitat des OSGi-Konzeptes erlaubt es, eine Softwareanwendung nicht mehr als starres Sys-tem, sondern als eine Zusammenspiel mehrerer, dynamischer Komponentenzu begreifen. Dementsprechend muss auch den Beziehungen zwischen den

Page 67: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 58

Bundles durch eine implizite Startreihenfolge Rechnung getragen werden,indem jedes Bundle die Abhangigkeiten in seinem Manifest definiert. Furdas lauffahige 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 uberangemeldete UPnP-Gerate informiert zu werden.

• UPnPUI Bundle: GUI-Builder Applikation fur 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 folgendeAufteilung der wichtigsten Zustandigkeitsbereiche:

• net.digidop.upnpui.business.data: Das Package ist fur das Ma-nagement der Applikationsdaten und die Kommunikation mit UPnPzustandig.

• net.digidop.upnpui.gui: Darin sind alle GUI-relevanten Klassen ent-halten.

• net.digidop.upnpui.business.generator: Der Generator kummertsich um die Aufbereitung der UPnP-Geratedaten und leitet diese andas Supple-Toolkit, das daraus ein User Interface rendert, weiter.

Datenhaltung

Um Informationen uber im Netzwerk befindliche UPnP-Gerate zu erhaltenund um diese ansteuern zu konnen, wird ein UPnPSupervisor definiert. Eruberwacht die An- und Abmeldung der Gerate und speichert die Objektein einem zugehorigen UPnPDeviceManager, der fur die Datenhaltung derGerate zustandig ist. Allfallige Anderungen werden an betroffene Kompo-nenten wie das GUI weitergeleitet. Mit der Anmeldung eines Gerates liegtdessen funktionale Beschreibung in Form einer objektorientierten Baum-struktur vor. In einem UPnPDevice sind alle UPnPServices enthalten, diewiederum Zugriff auf die UPnPAction-Objekte und UPnPStateVariableserlauben. Leider ist das Traversieren des Baumes durch die OSGi-bedingteUPnP-Servicedefinition nur in Richtung der Unterelemente moglich. Daherwurde eine ActionPath-Datenstruktur definiert, die Referenzen zu allen En-titaten entlang eines bestimmten Aktionsweges enthalt. Dies ist notwendig,da ausgehend von einer UPnPAction, oft auch auf das Service oder das De-vice zuruckgeschlossen werden muss. Um die Zustande der UPnP-Gerate

Page 68: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 59

auch zur Laufzeit uberwachen zu konnen, abonniert der Supervisor bei derAnmeldung eines Gerates alle verfugbaren Services. Der UPnP-EventingMechanismus garantiert, dass alle Anderungen von ereignisorientierten Zu-standsvariablen eines abonnierten Services an die Applikation ubermitteltwerden.

GUI

Abbildung 5.4 zeigt das GUI der Applikation. Im Bereich Available Deviceswerden alle entdeckten UPnP-Gerate gelistet. Durch Doppelklick wird derSupple Interface-Generator angestoßen und ein Fenster mit einem konkretenRendering zur Steuerung des Gerates erzeugt (siehe Abb.5.7 und 5.8). Dasaktive Gerat wird anschließend im unteren Bereich Active Devices gelistetund 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 daserstellte User Interface des Gerates wieder entfernt werden. Um ein scho-neres UI-Design zu erzielen, wurde anstatt des standardisierten Java SwingLook and Feels die externe GUI-Bibliothek JGoodies Looks5 eingesetzt.

In einer zukunftigen Version soll die Erstellung von User Interfaces auszusammengesetzten Teilen verschiedener UPnP-Gerate moglich sein. Damitkann eine individualisierte Oberflache zur Steuerung und Ubersicht ubermehrere, in einem Szenario vernetzte Gerate realisiert werden. Es ware etwadenkbar, einen Lichtschalter dazu zu benutzen, gleichzeitig einen CD-Playerweiterzuschalten und die Temperatur einer UPnP-fahigen Heizung zu regu-lieren. In einem gemeinsamen GUI waren somit der Lichtschalter, die An-zeige des aktuellen Songtitels und die Raumtemperatur von Interesse. DieDefinition von Ablaufen mit UPnP-fahiger Soft- und Hardware ist Teil desTorem-Frameworks, das in [39] naher erlautert wird.

Der Informationsaustausch zwischen Applikationslogik und GUI ist ubereine Schnittstelle definiert, die Befehle in Form von Beans mit angehangtenObjekten vom Interface-Typ IRenderedEntities kapselt. Jedes Objekt, dasdieses Interface implementiert, kann ubergeben werden. Das Konzept wirdvor allem zur Benachrichtigung und einheitlichen Darstellung von Objek-ten im GUI benotigt. Die Bean-Klasse kennt derzeit vier Befehle, die uberdas Hinzufugen und Entfernen von UPnP-Geraten und die Erstellung undZerstorung des User Interfaces eines aktiven Gerates informieren. Obwohlalle Business-Komponenten Bean-Objekte an das Interface schicken konnen,macht derzeit nur der UPnPDeviceManager davon Gebrauch, wenn Geratean- und abgemeldet werden.

5JGoodies Looks - http://www.jgoodies.com/freeware/looks/

Page 69: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 60

Abbildung 5.4: GUI-Builder PC Applikation.

5.2.3 GUI-Generator

Das Supple-Toolkit bildet die Schnittstelle zwischen diesem Datenmodell derGerate und dem konkreten Interface-Rendering und kummert sich sowohlum das Mapping von UPnP-Datentypen und Interface-Elementen als auchum das Layout der GUI-Komponenten. Zusatzlich uberwacht Supple dieZustande des User Interfaces und leitet durch Interaktionen hervorgerufeneAnderungen an interessierte Komponenten der Applikationsschicht weiter.

Bevor der Rendering-Prozess eingeleitet werden kann, muss eine Infor-mationsquelle in Form einer UPnP-Geratebeschreibung ausgewertet werden.UPnP arbeitet mit Aktionen und Zustanden, die als Parametern fur Aktio-nen eingesetzt werden, um Gerate ansteuern zu konnen. Sehr oft sind UPnP-Aktionen Getter und Setter -Funktionen einer Zustandsvariable. Am Beispieleiner Volume-Zustandsvariable fur einen UPnP-fahigen Medienplayer wirddie Vorgehensweise erklart. Folgender Quellcode zeigt einen Auszug aus demDokument des Config-Services am Gerat, 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 <relatedStateVariable>Volume</relatedStateVariable>

8 <direction >out</direction >

9 </argument >

10 </argumentList >

11 </action>

Page 70: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 61

12 <action>

13 <name >SetVolume </name >

14 <argumentList >

15 <argument >

16 <name >Volume</name >

17 <relatedStateVariable>Volume</relatedStateVariable>

18 <direction >in</direction >

19 </argument >

20 </argumentList >

21 </action>

22 </actionList >

23 <serviceStateTable >

24 <stateVariable sendEvents ="yes">

25 <name >Volume</name >

26 <dataType >ui1</dataType >

27 <defaultValue >255</defaultValue >

28 <allowedValueRange >

29 <minimum >0</minimum >

30 <maximum >255</maximum >

31 </allowedValueRange >

32 </stateVariable >

33 </serviceStateTable >

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 Instanzenkonnen das ubergeordneten Service abonnieren und werden so uber die An-derungen der enthaltenen Zustandsvariablen informiert. Ein Nachteil diesesUPnP-Mechanismusses ist, dass man bei mehreren Eventvariablen in einemService immer alle abonnieren muss.

Fur das Interface-Rendering liefert diese funktionale Geratebeschreibungwichtige Informationen. Die Annahme ist, dass eine UPnP-Aktion den ele-mentarsten, ausfuhrbaren Teil eines Interfaces darstellt. Anhand der Ein-gangsparameter der Setter -Aktion kann auf die Eigenschaften des referen-zierten Zustandes ruckgeschlossen werden. Vor allem der Datentyp und derWertebereich bieten Anhaltspunkte zur Reprasentation des Parameters durchein Interface-Element.

Da eine Getter -Aktion die selbe Zustandsvariable wie die Setter -Aktionreferenziert, muss sie nicht extra im Interface aufscheinen. Der abgefragteWert der Zustandsvariable ist ohnehin schon im von der Setter-Aktion geren-derten GUI-Element ersichtlich. Der Zustand einer Variable am UPnP-Geratkann jedoch nicht nur durch die Interaktion mit einem einzigen Interfacesondern auch durch andere, im Netzwerk verteilte GUIs oder durch interneAblaufe am Gerat selbst geandert werden. Ein haufiges Abfragen des Wertesmit der Getter -Aktion ist kein gutes Mittel, um die Aktualitat des Wertesund damit die Konsistenz der Inhalte des Interfaces gewahrleisten zu kon-

Page 71: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 62

nen. Dazu ist der vorher erwahnte Event-Mechanismus, der jede Anderungan interessierte Netzwerkteilnehmer bekannt gibt, besser geeignet.

Fur den Fall, dass fur eine Aktion mit Ruckgabeparameter keine entge-gengesetzte Setter -Aktion gefunden wird, muss diese trotzdem im Interfacekenntlich gemacht werden. Weil sie jedoch selbst keinen Eingabeparameterdefiniert, der in ein Elemente umgewandelt werden konnte, muss die Aktionmit einem Button zum Ausfuhren und im einfachsten Fall einem zusatzlichenTextfeld zur Darstellung des Ruckgabewertes reprasentiert 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 Geratebeschreibung kann aber kein Bezug zurkonkreten Auslegung im Interface abgeleitet werden. Ein Beispiel hierfur isteine Aktion mit zwei Integer-Parametern. Ohne die Aufgabe des Gerates zuverstehen, kann keine genaue Angabe uber die Auslegung der Bedienung ge-troffen werden. Es ware beispielsweise denkbar diese Aktion als 2D-Matrixmit diskreten Werten aufzufassen und in equidistanten Abstanden einenKnopf fur jede der Kombinationen im Interface zu zeichnen. Genauso gutkann es aber auch moglich sein, dass zwei Slider eine bessere Reprasentationdarstellen. Daruber hinaus ist nicht bekannt, ob die Aktion nur zur Konfi-guration von Einstellungen dient und die Aktion mit einem Bestatigungs-button ahnlich einem Formular ausgefuhrt werden sollte. Oder aber ob sie,sobald das Interface-Element manipuliert wird, ohne Bestatigung ausgefuhrtwerden soll.

Ideen um semantische Probleme dieser Art losen zu konnen, werden an-satzweise in Kapitel 5.2.4 erlautert und anhand einiger Regeln demonstriert.

Das Konzept der UPnP-Zustandsvariablen kommt Supple sehr entgegen.Der Toolkit benotigt fur die Generierung des Interfaces keine Beschreibungkonkreter Interface-Elemente, sondern verwendet abstrakte Zustandsvaria-blen, die neben der Spezifikation des Datentyps und moglichen Einschran-kungen des Wertebereichs auch nach einem Bean-Objekt zur Speicherungdes Zustandes verlangen. Erst beim Rendering-Prozess werden die Zustands-variablen anhand ihrer Eigenschaften in Elemente wie Buttons, Slider undEingabefelder umgewandelt. Dabei ist eine fixe Zuweisung zwischen Zustandund Interface-Element nicht gegeben. Vielmehr schranken deren Eigenschaf-ten die moglichen Render-Ergebnisse ein. Der Datentyp ist zusammen mitden wertebedingten Einschrankungen der Zustandsvariable und den Eigen-schaften des Darstellungsgerates das entscheidende Kriterium zur Generie-rung des konkreten Interface-Elements. Am Beispiel einer Integer-Variablemit einer ganzzahligen Einschrankung von 0 − 5 werden Ergebnisse der dy-namische Elementauswahl von Supple gezeigt. Alle Varianten in Abb.5.5stellen legale Reprasentationen des Eingangsparameters der UPnP-AktionSetFanLevel dar.

Page 72: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 63

���������������� ���������������������������������������� ��������������������������������� �������

������������������������������������������������������������������������������������������������������������������������ �������������������� ����!�������� �����"����������#����"���������������$�������%�����������#���������&���'���&���������$�������%���������������������

Abbildung 5.5: Verschiedene Rendering einer Supple-Zustandsvariable mitInteger-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, ubernommen.

Datentyp

Der Datentyp der verknupften UPnP-Zustandsvariable muss in einen Java-Basisdatentyp umgewandelt werden und anschließend als Supple-Datentypder Instanz einer Supple-Zustandsvariable StateVar mitgegeben wird. OSGiselbst stellt fur die erste Konvertierung mit dem UPnPStateVariable-Inter-face eine entsprechende Methode getJavaDataType() zur Verfugung. DieKonvertierung 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 benotigt. DasObjekt muss eine Membervariable entsprechend dem Datentyp und Namendes Zustandes enthalten und zusatzlich eine Getter und eine Setter -Methodezur Manipulation des Wertes definieren. Da der Name der Membervaria-ble nicht im vorhinein bekannt ist, kann keine statische Bean-Klasse her-angezogen werden. Fur diese Aufgabe wird JavAssist6 verwendet. Die By-tecode Engineering-Bibliothek ermoglicht die Erstellung und Instanzierungvon Java Klassen zur Laufzeit durch String-basierte Spezifikation auf Ebenedes Sourcecodes. Wenn das Bean-Objekt daruber hinaus fur die Zustands-uberwachung ein Objekt der Klasse java.beans.PropertyChangeSupportmitfuhrt, garantiert Supple die Benachrichtigung aller, an einer Variable in-teressierten, Komponenten und fuhrt in entgegengesetzter Richtung auchUpdates des Interfaces bei Manipulation des Bean-Objektes aus.

6JavAssist - http://www.csg.is.titech.ac.jp/˜chiba/javassist/

Page 73: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 64

UPnP datatype Java datatype Supple datatypeui1, ui2, ui4 java.lang.Integer, int IntegerTypeImpli1, i2, i4, int java.lang.Integer, int IntegerTypeImplr4, r8, float java.lang.Float, float IntegerTypeImpl

(not exact)boolean java.lang.Boolean or

booleanBooleanTypeImpl

string java.lang.String StringTypeImpl,TextTypeImpl

enum (as Xml-basedstring)

java.util.Collection StringTypeImplwith collectionconstraints

additional formats fortime, date and url

any pre-defined additional formatsfor date and image

Tabelle 5.1: Mapping zwischen UPnP-, Java- und Supple-Datentypen.

������

��++���++��'����

����9�'�

����"�"

��-���"��"

�������"�(+��#+� ����&"�#+�

����'��!���!�'� �'�������

��#+��&����(+�����"�"����"�"��"��.�(+��#+�

Abbildung 5.6: GUI-Builder – Klassendiagramm des Rendering-Prozesses.

Rendering-Prozess

Abb. 5.6 bietet einen Uberblick uber die im Rendering-Prozess involviertenKlassen. Der UIGenerator bereitet die Informationen eines angefordertenUPnP-Gerates fur den anschließenden Rendering-Vorgang mit Supple auf.Dazu wird mit den UI-relevanten Supple Klassen7 eine hierarchische Struk-tur aus Containern und Komponenten ahnlich dem Java Swing Modell8 auf-

7Supple Java Doc - http://www.cs.washington.edu/ai/supple/docs/8Java Foundation Classes und Swing - http://java.sun.com/products/jfc/

Page 74: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 65

gebaut. Die Zustandsvariablen der Klasse StateVarImpl sind gleichzeitigObjekte des Interfaces UiObject, die mittels ContainerTypeImpl zu Grup-pierungen zusammengefasst werden konnen. Diese Container konnen wie-derum in ein UiObject verpackt werden, womit der Kreis geschlossen ist.Beim Traversieren eines UPnP-Gerates werden alle Services und Aktionenals Container definiert. Die Parameter einer Aktion hingegen, die bekanntlichZustandsvariablen eines Services referenzieren, werden mit der definiertenKlasse UiObjectCreator als StateVarImpl instanziert und dem Containerder Aktion hinzugefugt.

Ein finales UiObject, das die Verschachtelung der Komponenten undContainer enthalt wird in einer SuppleApplication gekapselt und zuletzteiner Instanz des Interfaces Renderer ubergeben. Supple definiert mit Html-Renderer, AwtRenderer und SwingRenderer fur drei Plattformen konkreteRenderer, die uber globale DeviceProperties gesetzt werden konnen. Alledrei Plattform konnen auf eine vollstandige Bibliothek aller plattformspe-zifischen Interface-Objekte im Package edu.washington.cs.supple.wlibzuruckgreifen, um das Interface zu rendern. Die Auswahl und Positionierungder Interface-Elemente wird anschließend von einer Solver-Klasse anhanddes in Kapitel 4.5.3 beschriebenen Optimierungsverfahrens vorgenommen.Nach Abschluss des Rendering-Prozesses wird die SuppleApplication unddas fur jede Aktion generierte ActionPath-Objekt in einem ActiveDevicegespeichert. Abbildung 5.7 zeigt das Ergebnis des Rendering-Prozesses fureinen UPnP-fahigen Videostreaming-Server.

UPnP-Kommunikation

Damit Interaktionen im Interface in Steuerbefehle fur die im Netzwerk ver-teilten UPnP-Geraten umgesetzt werden konnen, wird das ActiveDevice furalle StateVarImpl-Objekte als PropertyChangeListener registriert. Wirdein Interface-Element vom Benutzer manipuliert, versucht der PC GUI-Builder diese Aktion an das entsprechende Gerat weiterzuleiten. Dazu wirdein Dictionary-Objekt mit Schlussel-Wert Paaren erzeugt, das mit allenEingangsparameternamen der auszufuhrenden Aktion und den Werten derzugehorigen Supple-Zustandsvariable befullt wird. Damit ist auch fur denFall vorgesorgt, dass eine Aktion, die mehrere Eingabeparameter besitzt,auch bei der Manipulation nur eines entsprechenden Interface-Elements aus-gefuhrt werden kann. Der untenstehende Quellcode zeigt den Vorgang in derActiveDevice-Methode executeAction():

1 public void executeAction (ActionPath actionPath ) {

2 Dictionary arguments = new Hashtable ();

3 UPnPAction action = actionPath .getAction ();

4 Map <StateVar ,String > stateVarToArgName = actionPath .getMap ();

5

6 for (StateVar suppleVar : stateVarToArgName .keySet()) {

7 Object value = suppleVar .getValue ();

Page 75: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 66

(a) (b)

Abbildung 5.7: Rendering eines UPnP-fahigen Videostreaming-Servers.Das originale User Interface der Applikation ist in Abb. (a) ersichtlich.Abb. (b) zeigt das automatisierte Rendering-Ergebnis. Im Interface konnender Treiber der Webcam (SetCaptureDevice), die Broadcast-IP (SetAddress),der Port (SetPort) und die TimeToLive (SetTTL) Zeit gesetzt werden. MitStart und Stop kann der Streaming-Server mit Vorschaubild gesteuert wer-den.

8 String argName = stateVarToArgName .get(suppleVar );

9 arg.put(argName ,value);

10 }

11 action.invoke(arguments );

12 }

5.2.4 UI-Erweiterungen

Da UPnP keine native Unterstutzung zur Definition von grafischen Ober-flachen bietet und die Geratebeschreibung nicht ausreicht, um die vielschich-tigen Vorgange eines User Interfaces zu modellieren, muss der Standard umsemantische Zusatzinformation erweitert werden. Im Rahmen dieser Arbeitwurden mehrere Ideen fur eine Erweiterung des Prototyps in Erwagung ge-zogen. Eine davon wurde im Zuge der Implementierung mit den Geratengetestet.

• Gerateklassen: UPnP definieren einheitliche Standards fur Gerate-

Page 76: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 67

klassen, damit herstellerubergreifende Kommunikation zwischen ver-schiedenen Produkten ermoglicht werden kann. Diese Strukturierungkonnte auch fur die Auslegung der User Interface genutzt werden, weilmit der Klasse des Gerates auch dessen Funktionalitat bekannt ist. Mitvordefinierten Interface-Elementen und dem Wissen uber die seman-tische Bedeutung einer Interaktion konnte fur eine Instanz der KlasseMediaplayer, unabhangig von der Implementierung des Gerates, einoptimales User Interface prasentiert werden. Dieser Ansatz setzt aller-dings voraus, dass alle Gerateklassen im vorhinein bekannt sind und dieRessourcen zu einer Klasse außerhalb der Gerate gespeichert werden.Wird ein neues Gerat gefunden, das nicht zugeordnet werden kann,konnen keine Zusatzinformationen fur das zu generierende Interfaceabgeleitet werden.

• Koharenzen: Ein weiterer Ansatz ware, Funktionselemente in ahnli-chen Geraten zu kategorisieren und diese Information fur die Auswahlvordefinierter Interface-Elemente zu nutzen. Der Interface-Generatorkonnte mit einem wissensbasierten System gekoppelt werden, das uberdie Zusammengehorigkeit (Koharenz) der Funktionselemente in Formeines vordefinierten Wissensschatzes verfugt. Am Beispiel der Abspiel-elemente eines Medienplayers sind beispielsweise Definitionen fur dieElemente Play, Pause, Stop, Vor und Zuruck moglich. So konnte furden Play-Button im Bezug zum Stop-Button ein Koharenzwert von 10definiert werden, der ein engere Bindung als ein Wert 5 im Zusammen-hang mit dem Vor -Knopf signalisiert. Mit den Koharenzwerten wirdein Beziehungsnetzwerk aufgespannt, das fur das Layout der Kom-ponenten von Bedeutung ist. Dieses Konzept birgt großes Potential,verlangt jedoch nach ausfuhrlicheren Recherchen als dies im Rahmender vorliegenden Arbeit moglich war.

• Regelbasierte Beschreibung: Im einfachsten Fall sind in der Be-schreibung eines Gerates alle notigen Informationen zur Darstellungenthalten. Dazu zahlen neben grafischen Ressourcen beispielsweise inForm von Icons auch Layout-Informationen. Damit aber nicht zusatz-lich zur funktionalen Spezifikation des Gerates auch noch eine kom-plette Interface-Definition festgelegt werden muss, kann ein Systemzum Einsatz kommen, das anhand weniger Regeln Informationen uberden Zusammenhang und die Bedeutung zwischen einzelnen Gerate-funktionen definiert. Dieser Ansatz wird im Anschluss anhand zweierRegeln demonstriert.

Um den UPnP-Geratestandard mit einem Interface-relevanten Regel-werk erweitern zu konnen, wurde folgendes Konzept umgesetzt: UPnP defi-niert die optionale Angabe einer Prasentations-URL in der XML-basiertenGeratebeschreibung, die eine optionale Referenz zu einer HTML-basierten

Page 77: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 68

Prasentationsseite beinhaltet [38]. Es bleibt dem Hersteller uberlassen, wieer diese Prasentationsseite gestaltet und mit welchen Inhalten er sie ausstat-tet. Eine URL zu der Homepage des Produktes ist dabei ebenso denkbar, wieein lokaler Verweis auf ein HTML-Frontend am Gerate selbst, das Auskunftuber Zustande gibt und unter Umstanden auch die Steuerung erlaubt.

Dieser Ansatz hat jedoch zwei entscheidende Nachteile. Erstens wird nurder Webbrowser als Plattform zur Prasentation von Gerateinhalten propa-giert. Ohne fortgeschrittene Web-Technologien ist dieses Modell aber auf dasRequest/Response-Prinzip reduziert, das kein automatisches Neuladen vonSeiteninhalten bei Zustandsanderungen erlaubt. Auch die Anzahl der Inter-aktionselemente ist im Vergleich zu den Komponenten einer GUI-Bibliothekbegrenzt. Zweitens steht dieses Konzept in starkem Kontrast zum Entwurfder generischen Geratesteuerung, wenn fur das User Interface kein einheit-licher Standard gefunden werden kann.

Die Prasentations-URL wird daher zum Transport UI-spezifischer Regelnin Form einer XML-Beschreibung genutzt. Das Regelwerk dient zur Unter-stutzung des GUI-Generators, der das User Interface sonst nur anhand derfunktionalen Geratebeschreibung, die Aktionen mit Zustandsvariablen alsEin- und Ausgabeparameter definiert, rendern kann. Fur 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 semantischwichtige Zusammenhange durch Platzierung der Elemente ausgedrucktwerden sollen. Ein Beispiel dafur ist die Anordnung der Knopfe einesMedienplayers. Der Zuruck -Button sollte immer vor dem Vorwarts-Button liegen.

• Datenquelle: Da in UPnP die Definition der Ein- und Ausgabepara-metern einer Aktion auf primare Datentypen beschrankt ist, konnenvorerst keine Interface-Elemente gerendert werden, die sowohl dynami-sche Informationen vom Gerat abfragen als auch senden konnen. EinBeispiel hierfur ist die Auswahlliste: Bei einem Medienplayer muss zu-erst eine Liste aller verfugbaren Titel im User Interface aufscheinen,bevor der Benutzer einen Song auswahlen 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 anwahlt. 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 uber die Struktur der XML-Datei mit beiden Regeldefinitionen undInformationen, die in Zukunft ausgewertet werden konnten. Dazu zahlen die

Page 78: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 69

(a) Regeln deaktiviert (b) Regeln aktiviert

Abbildung 5.8: Renderings eines Remote-Interfaces zur Steuerung vonWinamp mit und ohne zusatzliche Regeldefinitionen in der UPnP-Prasentationsschicht. Die Gruppenregel kommt bei der Anordnung der Con-trols zu tragen. Die Definition einer Datenquelle fuhrt dazu, dass die Aktio-nen GetPlayList und SetSong zu einer Auswahlliste zusammengefuhrt wer-den.

Definition von Icons und der Vorschlag eines bestimmten UI-Elementtypsfur das Rendering. Letzteres ist vor allem dann von Interesse, wenn mehrereInterface-Elemente zur Darstellung des Datentyps in Frage kamen. Der ganz-zahlige Wertebereich einer Zustandsvariable Volume konnte etwa mit einemvertikalen 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" />

Page 79: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 70

16 <group name="Controls " id ="3" />

17 </action>

18 <action name="Pause" type="setter">

19 <group name="Controls " id ="4" />

20 </action>

21 <action name="Prev" type="setter">

22 <group name="Controls " id ="1" />

23 </action>

24 <action name="Next" type="setter">

25 <group name="Controls " id ="5" />

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 fur den Ruckgabeparameter der GetPlayList-Aktion be-notigt wurde. Um dennoch eine Liste ubertragen zu konnen, wird ein String-Datentyp aus mehreren XML-Elementen zusammengesetzt, der anschließendam Empfanger wieder auseinander genommen werden kann. Dafur wurdefolgendes, 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 Funktionalitat reduzierte Anwendungzur Fernsteuerung von UPnP-Geraten. Eine Client-Server Architektur er-moglicht die Kommunikation zwischen einem PC-Gateway und einem SmartPhone via Bluetooth. Die Gateway-Applikation implementiert die UPnP-Controlpoint Funktionalitat und gibt Informationen uber die gefundenenGerate an das Smart Phone weiter. Dieses generiert aus den funktionalenBeschreibungen ein Java-basiertes Interface und sendet bei einer Interaktionvordefinierte Steuerbefehle an das Gateway zuruck. Dort werden die Befehleausgewertet, in gultige UPnP-Aktionsaufrufe konvertiert und ausgefuhrt.

Page 80: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 71

5.3.1 Entwicklung mobiler Java-Anwendungen

Ahnlich der Java SE Plattform9 fur PC-Applikationen, gibt es fur die Ent-wicklung von Anwendungen auf mobilen Plattformen ein spezialisiertes undim Umfang reduziertes Set an Technologien mit dem Namen J2ME10. ImGegensatz zu Java SE ist J2ME jedoch nur ein Uberbegriff fur Konfigura-tionen, Profile und optionalen Packages, die vom StandardisierungskomiteeJava Community Process(JCP) vorgegeben werden und als Java Specifica-tion Requests(JSR) den Weg in eine allgemein gultige Spezifikation finden.J2ME-Technologien werden als JSRs mit einer Nummer versehen. Bei ak-tuellen Entwicklung fur Mobiltelefone muss vor allem auf die Kompatibili-tat des Endgerates mit den Spezifikationen CLDC 1.1 (Connected, LimitedDevice Discovery - JSR 139) und MIDP 2.0 (Mobile Information DeviceProfile - JSR118) geachtet werden. Zusammen mit MMAPI (Mobile MediaAPI ) und WMA (Wireless Messaging API ) bilden diese Technologien denJSR 185-Stack mit Namen Java Technology for Wireless Industry11, der dieGrundvoraussetzung an jedes J2ME-fahige Mobiltelefon stellt. Viele zusatz-liche Funktionalitaten wie etwa die Bluetooth-Unterstutzung (BTAPI - JSR82), werden ebenfalls in eigenen Spezifikationen festgehalten, die von denGeraten der Elektronikherstellern unterstutzt werden konnen.

Softwareunterstutzung

Fur die Entwicklung von J2ME-Anwendungen ist eine Reihe an nutzli-cher Open Source-Software verfugbar. Das Wireless Toolkit (WTK)12 isteine einfach gehaltene Sammlung an Softwarekomponenten zur Entwicklungvon J2ME-Applikationen. Neben einem Compiler, den API-Spezifikationenund zahlreichen Beispielanwendungen ist auch ein Simulator enthalten. DasWTK ist ein solides Werkzeug um erstellte Applikationen am PC zu testen.Da die Umsetzung der Java-Spezifikationen am Mobiltelefon jedoch dem Ge-ratehersteller uberlassen ist, weicht das konkrete Erscheinungsbild oft vomLook and Feel des Simulators ab. Um in der bekannten Java-Entwicklungs-umgebung Eclipse arbeiten zu konnen, kann das Plugin EclipseME 13 ver-wendet werden, das die Schnittstelle zwischen dem WTK und Eclipse bil-det. Da die Ressourcen mobiler Endgerate meist begrenzt sind, muss aufspeicheroptimierte Programmierung geachtet werden. Um unnotigen Pro-grammoverhead automatisch zu entfernen kann ein sogenannter Obfuscatoreingesetzt werden. EclipseME bietet Integrationsmoglichkeiten fur externe

9Java Platform, Standard Edition - http://java.sun.com/javase/10J2ME - Java Technology - http://java.sun.com/j2me/

http://developers.sun.com/techtopics/mobility/getstart/11Java Technology for Wireless Industry (JSR 185) - http://developers.sun.com/

techtopics/mobility/jtwi/12Sun Java Wireless Toolkit (WTK) - http://java.sun.com/products/sjwtoolkit/13EclipseME - http://eclipseme.org/

Page 81: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 72

�++��'��������

���/�"*��+�"!� �"

�� '�!�"(�.���

��������"����"

��������

���""'��'�������������

���"�����"

�����'����,����"

Abbildung 5.9: Das Klassendiagramm der wichtigsten Komponenten desGateways und des Clients. Da sowohl die Anwendung am PC als auch amSmart Phone mit Java entwickelt wurde, konnen viele Klassen auf beidenPlattformen eingesetzt werden.

Obfuscator. Fur die Entwicklung des mobilen GUI-Builders kam ProGuard14

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 moglich, da dieser keinenZugriff auf die Bluetooth-Treiber des PCs hat. Daher muss das Programmmit jeder Anderung zum Testen auf das Smart Phone ubertragen werden.Auch das Debuggen gestaltet sich bei der mobilen Anwendung als schwierig.Da naturgemaß keine Konsole zur Verfugung steht und kaum aussagekraftigeFehlermeldung an das uberliegende 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 fur das Gateway und den Client einheitlich zu gestalten (sieheAbbildung 5.9).

Die Implementierung des Gateway ist in folgende Bereiche unterteilt:

• net.digidop.bt.networkund net.digidop.bt.network.endpoint:Netzwerkkomponenten und Bluetooth-Kommunikation.

• net.digidop.statemachine: Das Zustandsmodell der Applikation.

• net.digidop.upnp: Datenhaltung der UPnP-Gerate.14Pro Guard Obfuscator - http://proguard.sourceforge.net/

Page 82: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 73

Netzwerk

Die Entwicklung von Java-Anwendungen mit Bluetooth-Unterstutzung istnoch im Anfangsstadium. Da es keine native Java-Unterstutzung fur Blue-tooth-Hardware gibt, kommt Open Source Software zur Anwendung. Blue-Cove15, eine Bibliothek zur Java Bluetooth Kommunikation mit dem PCsetzt Teile der JSR82 -Spezifikation um und greift uber den Microsoft Blue-tooth-Stack direkt auf die Hardware zu16. Fur den Mobile GUI-Builder wirddas Bluetooth-Profil Serial Port Profile, das eine serielle Schnittstelle simu-liert, eingesetzt.

Die Klasse Supervisor ist das Herzstuck der Bluetooth-Kommunikation.Sie ubernimmt die Initialisierung, die Konfiguration und die Wartung derNetzwerkverbindungen. Durch die Initialisierung zweier Objekte der Klas-sen DeviceInquiry und ConnectionHandler wird anfangs nach anderenKommunikationsteilnehmern in Funkreichweite gesucht und ein Server furspatere Verbindungsanfragen eingerichtet. Der Server ist fur die Kommu-nikation mit mehreren Mobile-Clients ausgelegt, jedoch noch nicht in derPraxis getestet.

Beim Starten des Servers akquiriert die Klasse DeviceInquiry ein Single-ton17-Objekt DiscoveryAgent. Dieser Agent instanziert eine Connection-Handler-Klasse, die wahrend der Laufzeit des Servers auf eingehende Verbin-dungsanfragen wartet. Bei einem erfolgreichen Verbindungsaufbau werdenzwei 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 Applikationweiter. Ein- und ausgehende Nachrichten werden in Form von Packets ge-kapselt, die sowohl den Inhalt der Nachricht, als auch Informationen uberden Sender und einen verbindungsspezifischen Befehl (SIGNAL_TERMINATE,SIGNAL_HANDSHAKE,SIGNAL_MESSAGE) enthalten.

Modellierung des Applikationszustand

Um die verschiedenen Zustande der einzelnen Clients modellieren zu konnen,wurde ein einfach gehaltenes Zustandsmodell eingefuhrt. Bei einer Anderungwerden alle Komponenten die das StateListener Interface implementierenund sich bei der Klasse ApplicationState registrieren, uber die Zustands-uberfuhrung informiert. Bei der Anmeldung eines neuen Client wird einneuer Zustand angelegt und die Klasse UPnPAccessPoint reagiert, indemsie dem Client die Daten aller UPnP-Gerate sendet.

15Java Bluetooth-Bibliothek - BlueCove http://sourceforge.net/projects/bluecove/16Eine Anleitung fur das Arbeiten mit BlueCove findet sich unter

http://www.benhui.net/modules.php?name=Bluetooth&page=Connect PC Phone Part 1.html

17Singleton ist ein objektorientiertes Muster, das von einer Klasse nur eine konkreteInstanzierung erlaubt.

Page 83: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 74

Datenhaltung

Ebenso wie beim GUI-Builder fur den PC werden die Informationen derXML-Geratebeschreibung in einer hierarchisch Form zusammengefasst. DieDatenhaltung am Gateway wird in einer Baumstruktur speichert. Dieserkann ausgehend von einem Node-Elementen in Richtungen der Kinder undder Eltern-Elemente traversiert werden. Das Gateway transformiert dieseXML-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 beschrankte Rechen-leistung und Speicherkapazitat des mobilen Endgeraten beschrankt ist. Derfolgende Quellcode zeigt die transformierte Beschreibung im Gegensatz zuroriginalen Struktur (siehe Abs. 5.2.3).

1 <service serviceId ="urn:schemas -upnp -org:serviceId:temp:1"

2 serviceType ="urn:schemas -upnp -org:service:temp: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 zumEinsatz. Bis auf wenige Ausnahmen gleicht der Systemaufbau den Angabendes Server-Gateways (siehe Abb. 5.9 der Server-Architektur).

XML-Parser

Die vom Gateway an den Mobile Client ubertragenen Gerateinformationenmussen mit einem, speziell fur leistungsschwache Gerate ausgelegten, XML-Parser ausgelesen werden. Fur diese Aufgabe wird kXML2 19, eine kleineXML Pullparsing-Bibliothek, verwendet.

GUI

Die Applikation ist aufgrund geratebedingter Verzogerungen beim Aufbauder Bluetooth-Verbindung langsam in der Initialisierung. Es kann einige Zeit

18Nokia 6600 Smart Phone - http://www.nokia.at/german/phones/phone models/6600/index.html

19XML Parsing kXML2 - http://kxml.sourceforge.net/

Page 84: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 75

dauern bis am Smart Phone eine Anfrage an den Benutzer fur die Erlaubniszum Verbindungsaufbau erscheint. Wird diese bestatigt, werden die UPnP-Gerateinformationen vom Gateway ubertragen und am Smart Phone darge-stellt.

Die Menufuhrung wurde in folgender Hierarchie festgehalten: Gerateliste> Aktionsliste > Parameterliste (siehe Abb. 5.10). Durch Anwahl eines Ge-rates werden die enthaltenen Aktionen aufgelistet. Durch erneutes Klickenkommt man in das Parametermenu der Aktion. Dort konnen die Werte furdie auszufuhrende Aktion gesetzt werden. Das Setzen von Boolean-Werten,beispielsweise Licht an/aus, fuhrt direkt zum Ausfuhren der Aktion. Sie kon-nen direkt mit einer Checkbox angewahlt werden. Float, Integer und Stringwerden als Input Feld dargestellt und mussen erst mit einem Send-Befehl ausdem Optionen-Menu bestatigt werden. Der Back -Befehl fuhrt in das jeweilsvorherige Menu. Der Exit-Befehl meldet den Client beim Server ab. Soferndas Gateway aktiviert bleibt, kann sich das mobile Gerat jedoch jederzeitneu verbinden.

Um das Look and Feel der Anwendung verbessern zu konnen, wurdedie Grafikbibliothek J2ME Polish20 verwendet. Mit Hilfe von Auszeichnun-gen im Java-Quellcode, externen CSS-Layoutdefinitionen und Grafiken kanndas Polish Building-Tool eine visuell ansprechende Version der Applikationcompilieren, die immer noch dem mobilen Java-Standard MIDP 2.0 ent-spricht. Dabei berucksichtigt die Bibliothek auch produktspezifische Eigen-schaften eines mobilen Endgerates durch vordefinierte Hersteller-Profile furFirmen wie Nokia und Sony-Ericsson. Die Abbildung 5.11 zeigt das neugestaltete User Interface anhand der Gerateliste und der Aktionsliste, dasim Vergleich zu der vorher prasentierten J2ME-Benutzeroberflache (sieheAbb. 5.10) deutlich benutzerfreundlicher ist.

20J2ME Polish - http://www.j2mepolish.org/

Page 85: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 76

(a) (b)

Abbildung 5.10: Der Mobile GUI-Builder im WTK Simulator. Die Abbil-dungen zeigen die Gerateliste (a) und die Parameterliste (b).

Page 86: UPnP Diplomarbeit

KAPITEL 5. GUI-BUILDER 77

(a) (b)

Abbildung 5.11: Der Mobile GUI-Builder am Nokia 6600 mit J2ME-PolishGrafikbibliothek. Die Abbildungen zeigen die Gerateliste (a) und die Akti-onsauswahl (b) eines Medienplayers.

Page 87: UPnP Diplomarbeit

Kapitel 6

Fazit

Anlass fur die Idee der vorliegenden Arbeit war die Erkenntnis, dass ver-netzte Strukturen, die in Form von computerisierter Gerate in beinahe alleBereiche unserer Lebenswelt eindringen, bereits heute allgegenwartig sind.Mit lokalen und globalen Funknetzwerken wie Bluetooth, WLAN, und denMobiltelefonie-Standards sind eine Vielzahl neuer Dienste moglich, die bisvor einigen Jahren nicht in dieser Form denkbar gewesen waren. Die zugeho-rigen Technologien in Form von Geraten wie Smart Phones, PDAs, Laptopsund zahlreicher Unterhaltungselektronik finden sich in vielen Haushalten.Es wird aller Voraussicht nach nicht mehr lange dauern, bis Haustechnikwie beispielsweise Heizung und Elektroinstallationen auch an einem loka-len Netzwerk angeschlossen sein wird. In diesem Zusammenhang stellt sichdie Frage nach dem Sinn dieser Vernetzung [33]. Die Vision, dass die War-meregulierung eines Toasters per Netzwerk vorgenommen werden kann, hatwenig praktische Relevanz um Tatigkeiten im Haushalt zu vereinfachen. ImGegensatz dazu ware es jedoch wunschenswert die Steuerung der gesamtenUnterhaltungselektronik eines Haushaltes in einem Mobiltelefon zu verei-nen und so die Fernbedienungen der einzelnen Gerate wie TV-Gerat undStereoanlage ersetzen zu konnen.

Solche Szenarien werden erst dann zur Realitat, 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 Richtunggemeinsamer Standards fur verteilte Gerate gibt, bleibt fur die Forschungein umso großeres Betatigungsfeld.

Die vernetzte Service-Plattform UPnP ist ein Ansatz in die richtigeRichtung. Wenngleich die Technologie dem Endkunden noch nicht gelau-fig ist und bisher nur in wenigen Mediengeraten integriert ist, so birgt siedoch großes Potential durch die Standardisierung einer einheitlichen Service-schnittstelle.

78

Page 88: UPnP Diplomarbeit

KAPITEL 6. FAZIT 79

6.1 Erreichte Ziele

Anhand der entwickelten Gerate und der zwei GUI-Builder Prototypen wer-den die Ergebnisse der Arbeit naher erlautert.

6.1.1 Gerate

Auf Basis von UPnP wurden mit einem Sensorgerat und einer Webcammit Bewegungserkennung zwei Gerate geschaffen, die als Eingabemedien furein Steuerungsszenario mit weiteren, vernetzten Geraten eingesetzt werdenkonnen. Das fur die Verknupfung der Gerate notwendige Framework Toremwird in [39] eingehend beschrieben.

In mehreren Tests konnte die nahtlose Zusammenarbeit unter Beweisgestellt werden. So ist es beispielsweise moglich die Webcam als Uberwa-chungskamera einzusetzen. Betritt eine Person den Raum, wird das EreignisBewegung erkannt generiert und an die Torem gesendet. Das Frameworkwertet das Ergebnis aus und schaltet ein Hardware-Licht1 an. Mit wenigAufwand kann der Ablauf dahingehend geandert werden, dass als Antwortauf das vorher genannte Ereignis nicht nur das Licht angeschaltet, sondernauch eine SMS-Nachricht an den Benutzer gesendet wird.

Ahnlich verhalt es sich mit dem Drucksensor-Modul, das in einem Szena-rio als aktives oder passives Eingabegerat zum Einsatz kommen kann. Sinddie Drucksensoren am Boden angebracht, konnen sie zum Beispiel das Auf-treten einer Person registrieren und dieses Ereignis an interessierte Steuer-instanzen weiterleiten. In einem anderen Fall konnten die Sensoren als Ein-gabefelder benutzt werden, um eine Passwortabfrage zu simulieren, die nacheiner definierten Reihenfolge bei der Eingabe verlangt.

Mit dieser dynamischen Zuordnung der Eingabegerate zu der spezifischenBedeutung der Interaktion konnte im Gegensatz zu proprietaren Softwarelo-sungen und dem Konzept des verteilten Netzwerkes eine klare Verbesserunghinsichtlich der okonomischen Nutzung des computerisierten Gerates erzieltwerden. Umgelegt auf ein Szenario im Haushalt bedeutet dies, dass ein Be-wegungsmelder an der Eingangstur nicht nur an das Einschalten eines Lichts,sondern auch an andere Ereignisempfanger gekoppelt sein kann.

6.1.2 GUI-Builder

Mit der Definition der regelbasierten UI-Beschreibung am Gerat ist ein er-ster Schritt in Richtung automatisierter Generierung von User Interfaces furdie UPnP Service-Plattform getan. Zusammen mit der funktionalen Gera-tebeschreibung stehen dem PC GUI-Builder zwei Informationsquellen zur

1Das Licht ist Teil des Testaufbaus einer EIB-Gebaudesteuerung, die uber einen Soft-wareadapter ebenfalls ins UPnP-Netzwerk eingebunden wurde.

Page 89: UPnP Diplomarbeit

KAPITEL 6. FAZIT 80

Verfugung, um Bedingungen fur den UI-Rendering-Prozess formulieren zukonnen.

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-Geraten.

Der Ansatz reicht jedoch nicht aus, um komplexere Anwendungen undInteraktionsmuster beschreiben zu konnen. Gerade die Spezifikation von ge-meinsamen Schnittstellen fur verteilte Gerate und Anwendungen verlangtaber, dass dieses Konzept auch in Richtung Prasentation und Steuerung derInhalte fortgesetzt wird. Letztendlich ist das User Interface immer auch starkan das Applikationsmodell gebunden. Nur mit genaueren Informationen uberdie semantische Bedeutung der Interaktionen konnen Aussagen uber dasLayout, die Navigationsstruktur, die einzelnen Interface-Komponenten, dasVerhalten und das Zustandsmodell eines User Interfaces getroffen werden.

Der Prototyp des mobilen GUI-Builders (siehe Abb. 5.10) am SmartPhone hat sich ebenfalls als brauchbare Anwendung zur Steuerung der UPnP-Geratedienste erwiesen. Das Konzept setzt die universellen Fernbedienungum, die in Reichweite einer Bluetooth-Basisstation an das UPnP-Netzwerkgekoppelt werden kann. Auch wenn sich die grafische Umsetzung und derBedienkomfort noch in einem Anfangsstadium befinden, so stehen dem Be-nutzer doch auch jetzt schon alle UPnP-Funktionen zur Verfugung. Alle imLaufe der Arbeit vorgestellten Gerate sind damit ansteuerbar.

Um fernbedienbare Unterhaltungselektronik zentral steuern zu konnen,muss ein Weg fur die Integration eines Infrarot-Senders (IR)2 gefunden wer-den. Das BTkit3 ist ein Hardwaremodul, das mit einem Bluetooth-Chipund einem Infrarot-Sender und Empfanger uber solche Kapazitaten verfugt.In [10, 11] wird der Aufbau und Einsatz dieses Systems zur Steuerung vonInfrarot-Geraten via Bluetooth-fahigem Smart Phone beschrieben. Leiderkonnte das Produkt wegen eines Lieferstopps nicht mehr zur Entwicklungherangezogen werden.

6.2 Ausblick

Neben der zentralen Steuerung von Haushaltsgeraten scheinen verteilte Netz-werke in Kombination mit Eingabegeraten auch fur einen weiteren Bereichinteressant. Es stellt sich die Frage, ob mit diesen Technologien auch kunst-lerische Medieninstallationen verwirklicht werden konnen. Diese basierenmeist auf der Interaktion eines Benutzers abseits eines Computerterminalsund benotigen neben diverser Sensorik auch Zugriff auf viele Mediengerate.

2Die Infrarot-Schnittstelle ist aufgrund der niedrigen Produktions- und Integrationsko-sten die vorrangige Technologie fur Fernsteuerungen von Unterhaltungselektronik. VieleHersteller verwenden auf Basis des Lichtsignals ein eigenes, unidirektionales Ubertragungs-protokoll. Ein Uberblick findet sich unter http://www.xs4all.nl/˜sbp/knowledge/ir/ir.htm

3BTkit - http://www.btkit.com/de/

Page 90: UPnP Diplomarbeit

KAPITEL 6. FAZIT 81

Dazu zahlen Audio-, Video- und Lichtequipment, das uber Steuerprotokollewie DMX und MIDI angesprochen werden kann. Sie konnen sehr schnell ineine IP-basiertes Netzwerk eingebunden werden. Die Integration scheitertjedoch an der Anforderung echtzeitfahiger Steuerbefehle. Obwohl Netzwerk-befehle mit ausreichender Geschwindigkeit abgearbeitet werden konnten hatsich die Architektur von UPnP in diesem Zusammenhang als Nachteil er-wiesen.

Fur jeden ausgesandten Steuerbefehl und jedes Ereignis, das auf SOAPund 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 Ausfuhrung einer Aktion zwischen 300 ms und bis zu 2 s.Fur Dienste die selten genutzt werden ist diese Latenz kaum ein Problem.Echtzeitkritische Anwendungen konnen hingegen nicht zufriedenstellend be-dient werden.

Ein Ansatz, um diese Steuerungsproblematik zu losen ist die Verwendunganderer Remote Procedure Call4-Technologien auf Kosten der Plattformun-abhangigkeit, wie das Java-basierte RMI 5 oder die Middleware CORBA6.Der Einsatz von UPnP wurde sich in diesem Fall nur auf die Gerateerken-nung beschranken und die Steuerung diesen Architekturen mit persistentenNetzwerkverbindungen ubernehmen lassen.

Die erzielten Ergebnisse dieser Arbeit zeigen, dass mit einfachen Mittelnauch heute schon verteilte Dienste des Alltags uber einheitliche grafischeund physische Schnittstellen angesprochen werden konnen. Die Fahigkeitzur dynamischen und intelligenten Vernetzung wird in Zukunft ein entschei-dendes Kriterium fur den Nutzen eines Gerates und einer Anwendung ineinem Umfeld sein, dessen Voraussetzungen nicht immer bekannt sind.

Im Bereich der automatisierten Generierung grafischer User Interfacesist noch viel Arbeit zu leisten. Hier konnte mit einer Weiterentwicklungeine einheitliche Schnittstelle fur mehrere Plattformen zur Fernsteuerungzukunftiger, im Haushalt integrierter Gerate geschaffen werden. Erste Testszeigten, dass sich das Supple Toolkit auch fur GUI-Renderings auf einerWeb-basierten Plattform und fur den PDA eignet. Voraussetzung dafur isteine zunehmende Verbreitung an standardisierten, netzwerkfahigen Geraten,die von Seiten der Elektronikhersteller unterstutzt werden muss.

4Remote Procedure Call (RPC) bezeichnet den Aufruf einer entfernten Funktion uberein Netzwerk.

5Java Remote Method Invocation (RMI) - http://java.sun.com/products/jdk/rmi/6Common Object Request Broker Architecture (CORBA) - http://www.omg.org/

gettingstarted/corbafaq.htm

Page 91: UPnP Diplomarbeit

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 enthalt nach einzelnen Kapiteln geordnet alle Online-Literatur-quellen als PDF-Files.

A.3 Anwendungen

Pfad: /applications/

info.pdf . . . . . . . . . Anleitung fur die Inbetriebnahme und dasArbeiten mit den Geraten.

guibuilder pc setup.exe Installierbare Win32 -Version des PCGUI-Builders

guibuilder pc.zip . . . . Zip-Datei des PC GUI-Builders

82

Page 92: UPnP Diplomarbeit

ANHANG A. INHALT DER CD-ROM 83

guibuilder mobile.zip . . Zip-Datei des mobilen GUI-Builders fur dasSmart Phone (getestet am Nokia 6600 )

devices setup.exe . . . . Installierbare Win32 -Version der Geratedevices.zip . . . . . . . Zip-Datei des Gerate

A.4 Quellcode

Pfad: /source/

/guibuilder pc/ . . . . . Alle Eclipse-Plugin-Projekte, die fur denGUI-Builder benotigt werden.

/guibuilder mobile/ . . Eclipse-Projekt des mobilen GUI-Builders/devices/ . . . . . . . . Eclipse-Projekte der UPnP-Gerate

Sensor-Device, Streaming Server/Client,Winamp, MIDI-Device

Page 93: UPnP Diplomarbeit

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, March2002. 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 ProtocolArchitecture — Version 1.0 . URL, http://bluetooth.com/NR/rdonlyres/7F6DEA50-05CC-4A8D-B87B-F5AA02AD78EF/0/ProtocolArchitecture.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 aufCD-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 UserInterface 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 Funkfernbedienen - Teil 2 . CT, 15:220–225, 2005.

84

Page 94: UPnP Diplomarbeit

LITERATURVERZEICHNIS 85

[11] Dr. Harbaum, T.: Funkzentrale — Heim-Elektronik per Funk fernbe-dienen - Teil 1 . CT, 14:204–209, 2005.

[12] Dr. Scheller, A.: Bruckenschlag — Die technische Infrastruktur fursDigital 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 Generationfor 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 DisplayEnvironments, Nottingham, UK, 2004.

[17] Gajos, K. und D. S. Weld: SUPPLE: Automatically Generating UserInterfaces. In: IUI ’04: Proceedings of the 9th international conferenceon 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. PrenticeHall, 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.

Page 95: UPnP Diplomarbeit

LITERATURVERZEICHNIS 86

[23] Jespersen, J. W. und J. Linvald: Investigating user interface engi-neering in the model driven architecture. In: Proceedings of the Interact2003 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 PervasiveComputing Environments. Pervasive Computing, 4(4):81–89, 2005.

[26] Myers, B., S. E. Hudson und R. Pausch: Past, present, and future ofuser interface software tools. ACM Transactions on Computer-HumanInteraction, 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 Interfacesfor Complex Appliances. In: CHI Letters: ACM Symposium on UserInterface Software and Technology, UIST’02 , S. 161–170. ACM Press,2002.

[29] Puerta, A. und J. Eisenstein: XIML: A Universal Language for UserInterfaces. 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. PearsonEducation, 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 uber die Folgen des Ubiquitous Computing . CT, 16:91, 2004.

[34] Smith, S. und J. Mosier: Guidelines for Designing User InterfaceSoftware. Natl Technical Information, 1986.

[35] Sun Microsystems, Inc.: Jini Architecture Specification — Version1.2.1 . URL, http://www.sun.com/software/jini/specs/, Juni 2003. Kopieauf CD-ROM.

Page 96: UPnP Diplomarbeit

LITERATURVERZEICHNIS 87

[36] Tanenbaum, A. S.: Computernetzwerke. Pearson Studium, Munchen,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 Kopplungverteilter Gerate. 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 WebServices Converge — A Unified User Interface. Pervasive Computing,4(4):8–11, 2005.

Page 97: UPnP Diplomarbeit

Messbox zur Druckkontrolle

— Druckgroße kontrollieren! —

Breite = 100 mmHohe = 50 mm

— Diese Seite nach dem Druck entfernen! —

88