Geräteunabhängige Dienste Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Christine Haertl AG Kao Betriebssysteme und Verteilte.

Präsentation zum Thema: "Geräteunabhängige Dienste Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Christine Haertl AG Kao Betriebssysteme und Verteilte."—  Präsentation transkript:

1 Geräteunabhängige Dienste Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Christine Haertl AG Kao Betriebssysteme und Verteilte Systeme Institut für Informatik Universität Paderborn Vorstellen: Name, Tätigkeit, Veranstaltung - Mein Name ist Christine Haertl und meine Aufgabe fuer die Projektgruppe war, Ansaetze fuer eine geraeteunabhaengige Darstellung von Diensten zu finden, zu vergleichen und einen Vorschlag zu machen, wie wir in unserer PG Dienste geraeteunabhaengig darstellen.

2 Inhalt Motivation Lösungsansätze Vergleich der Ansätze
UIML IML ISL DDL Vergleich der Ansätze Ausgewählter Ansatz für die Projektgruppe Ich werde mit einer kurzen Motivation beginnen, in der ich das Problem darstelle, warum eine geraeteunabhaengige Darstellung notwendig ist. Dann werde ich 4 Loesungsansaetze vorstellen. Das sind User Interface Markup Language, Interaction Markup Language, Interaction Specification Language und Dialog Description Language. Nach einem anschliessenden Vergleich, werde ich vorstellen, welchen Ansatz ich fuer die Projektgruppe vorschlagen wuerde. Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

3 Motivation PC PDA Handy Haus Kuh Auto Haus Kuh Auto
Unser Ziel ist ja Dienste auf verschiedenen Geraeten verfuegbar zu machen. Die Geräte unterscheiden sich in ihrer Speichergröße, ihrer Rechenleistung und ihrer Leistungsfähigkeit von Benutzerinteraktion und Präsentation. Auf dieser Folie sehen wir jetzt das Beispiel, dass sich die Displaygroessen unterscheiden und dass die Darstellung daher an die einzelnen Geraetetypen angepasst werden muss. Auf einem normalen PC ist genug Platz, um Text und Bilder nebeneinander anzuordnen, wodurch der ganze gewuenschte Inhalt auf einmal dargestellt werden kann. Auf kleineren Displays, wie zum Beispiel bei PDAs, koennen Text dann beispielsweise untereinander angeordnet werden. Bei Geraeten mit winzigen Displays und wenig Speicher muessen die Bilder dann evtl. ganz wegfallen. Auto Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

4 ? Motivation Dienste WML E-mail E-mail E-mail WML E-mail HTML
tinyHTML tinyHTML WML HTML Kartendienst Browser HTML Benutzer wollen mit vielen Diensten von vielen verschiedenartigen Geräten kommunizieren (konkretes Beispiel nennen: Dienst - PC, Handy) (verschiedene Dienste mit unterschiedlichen Geräten ansprechen) Geräte haben unterschiedliche Leistungsfähigkeit (Speichergröße, Rechenleistung, ….) Und unterschiedliche Eingabe- / Ausgabearten (Bildschirm – Lautsprecher. Tastatur, Maus, Mikrofon) Einen Dienst für jedes Gerät einzeln zu Entwickeln -> teuer Manuelle Anpassung -> teuer Möglichkeiten: Gleiche Oberfläche auf allen Geräten Gerät mit geringster Leistung begrenzt die Funktionalität Vorteile von gerätespezifischen Eigenschaften werden nicht genutzt (Mikrofon, Scrollrad) Oberflächendesign nicht steuerbar (für wirtschaftliche Aspekte wichtig) Neue Version auf jedem Gerät Hohe Kosten für Implementierung Hohe Kosten für Wartung Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

5 Motivation WML HTML tinyHTML
Inhalt Struktur Struktur Struktur HTML Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

6 XML-XSL XML HTML Dienst HTML HTML XMLXSL XSL XMLXSL
XMLXSL-Dienst verbindet geräteunabhängige XML-Datei mit geräteabhängiger XSL-Datei XSL-Datei spezifiziert welche Teile aus XML benutzt werden Aufgabe des Erzeugers der XSL-Datei: gültige Typen (Button, Textfeld) auf graphische Komponenten der Geräte abbilden Aus einer Architektur rausgegriffen – allgemeines Konzept Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

7 Ansätze UIML ISL XMLXSL IML DDL Extensible Markup Language
User Interface Markup Language Interaction Specification Language IML DDL Interaction Markup Language Dialog Description Language Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

8 Anforderungen Trennung von Inhalt, Struktur und Logik
Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

9 UIML UIML <peers> <presentation name="VoiceXML">
head interface peers template <peers> <presentation name="WML"> <component name="Container" maps-to="wml:card"> <attribute name="content" maps-to="wml:card.title"/> </component> <component name="String" maps-to="wml:p"> <attribute name="content" maps-to="PCDATA"/> </presentation> </peers> <interface> <structure> <part name="TopHello" class="Container"> <part name="HelloStr" class="String"/> </part> </structure> <style> <property part-name="TopHello“ name="content">Hello</property> <property part-name="HelloStr" name="content">Hello World!</property> </style> </interface> <peers> <presentation name="VoiceXML"> <component name="Container" maps-to="vxml:form"/> <component name="String" maps-to="vxml:block"> <attribute name="content" maps-to="PCDATA"/> </component> </presentation> </peers> <uiml xmlns=' <head> ... </head> <interface> ... </interface> <peers> ... </peers> <template> ... </template> </uiml> <vxml> <form> <block>Hello World!</block> </form> </vxml> <wml> <card title="Hello"> <p>Hello World!</p> </card> </wml> Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

10 Einschränkung durch UIML
WML tinyHTML HTML UIML: direkte Abbildung von abstrakten Dialogelemente anstatt von abstrakten Interaktionen -> Dialogelemente stellen die Schnittmenge der Sprachen dar -> Einschränkung von Darstellung -> Fähigkeiten der Geräte werden nicht ausgenutzt Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

11 UIML - IML IML UIML Semantics Implementation UIML rendered to WML
DOC Interface User Interface Semantics Implementation UIML rendered to WML UIML rendered to HTML Render Engine WML IML UIML: Ähnliche Dialogelementen werden zu einem abstrakten Dialogelement zusammengefasst IML: Ähnliche Interaktionen werden zu abstrakten Interaktionen zusammengefasst Auswahl von einem aus 5 Elementen – Radiobuttons, Auswahl aus einer Liste,…. Gelb: Zwei Pfeile geben an, welche Schritte gemacht werden muessen Blau: UIML Dokument enthält beide Schritte in einem Dokument (es beschreibt Semantik und Implementation) Rot: IML Dokument enthält nur die Semantik, die Renderengine generiert die Implementation Vorteil: IML reduziert nicht auf gemeinsame Schnittmenge von Möglichkeiten aller Technologien und kann leicht erweitert werden Nachteil: komplexer Lösungsidee: semantische Informationen von Bedienelementen trennen und unabhängige Regeln benutzen um Semantik zu beschreiben Render Engine HTML Render Engine Java Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

12 Gibt es nicht! IML Sprachdefinition von IML: IML
Sprachdefinition gibt es nicht Aufgabe der Renderengine extrem komplex Keinerlei Anpassung von Layout und Ähnlichem (das Konzept einer Überschrift oder einer Hervorhebung existiert an der Stelle nicht, da nur Interaktionen beschrieben werden) Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

13 UML – IML Erfüllung von Anforderungen
UIML IML UIML IML Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

14 ISL - Interaction Specification Language
Geräte - unabhängig Geräte - abhängig Dienst - unabhängig Geräte - abhängig Dienst - abhängig Interaction Acts User Interface Dienst Interaction Engine Customization Form Interpretiert ISL Generiert UI Codierung in ISL Interpretiert Benutzeraktion Benutzer- Schnittstelle ISL UI Spez. (HTML) Benutzer-aktion Dienst Interaction Engine Customization form input output selection modification create destroy start stop Interaction acts Customization Form beinhaltet geräte- und dienstspezifische Informationen Dienstanbieter können Präsentation ihres Dienstes kontollieren kein Customization Form vorhanden  Standardeinstellungen Interaction act abstraktes Element für Interaktion zwischen Benutzer und Dienst beinhaltet keine Informationen über die Art und Weise der Präsentation Annahme: Die meisten Interaktionen können durch begrenzte Menge von interaction acts ausgedrückt werden Für jedes Gerät eine interaction engine Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

15 ISL - Interaction Specification Language
<out> <name>select_dest_O</name> <string>Please specify destination!</string> <meta>null</meta> </out> <select> <name>select_dest_S</name> <alt> <string>Stockholm</string> <retval>ARN</retval> </alt> <string>London</string> <retval>LHR</retval> <string>New York</string> <retval>JFK</retval> </select> </isl> <isl> <data> <name>select_dest_S</name> <value>LHR</value> </data> </isl> Abbildung von abstakt dargestelltem Interaction act auf gerätespezifische Bedienelemente anhand des Typs (out / select) oder aus Kombination Von Typ und Name Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

16 ISL – Resultat eines Customization Forms
Beispiel-Implementierung: Kalender Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

17 ISL - Erfüllung von Anforderungen
Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben  Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität () Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

18 DDL – Dialog Description Language
include head DataType Def Data- instance dialog class content part property constant Automatische Inhaltsanpassung benötigt Abbildung der Elemente einer geräteunabh. Inhaltsrepräsentation auf eine gerätespezifische Inhaltssprache Semantik der Eigenschaften nicht in DDL, nur DDL-renderers für Anpassung an gerätespez. Sprache muss erweitert werden können oder angepasst, um neue Eigenschaften zu interpretieren -> Syntax muss nicht verändert werden reference #PCDATA Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

19 DDL – Dialog Description Language
frameset container label image source form <part> <property name=“type“>label</property> <property name=“content“> TU-Dresden </property> <property name=“link“> </part> select submit textinput checkbox option Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

20 DDL – Dialog Description Language
container container atom atom container container part part part part part part part part part Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

21 Ausgabe auf Displays verschiedener Geräte
DDL WAP Handy PC - Standardbildschirm Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

22 DDL - Erfüllung von Anforderungen
Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an verschiedene Geräte Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

23 Zusammenfassung der Ansätze
UIML ISL gibt viel des Layouts durch abstrakte Dialogelemente vor Layoutinformationen durch Customization Forms IML DDL passt Informationsgehalt der Bildschirmgrösse an verwendet wie UIML abstrakte Dialogelemente überlässt nur die Layoutgenerierung dem Computer UIML: Probiert sehr viel des Layouts durch abstrakte Dialogelemente vorzugeben IML: Versucht Layout komplett zu generieren ISL: Probiert IML durch Customization Forms mit Layoutinfos zu versehen DDL: Kuemmert sich nur um Display-orientierte Elemente und versucht Informationsgehalt der Bildschirmgrösse anzupassen. (verwendet wie UIML abstrakte Dialogelemente, überlässt nur die Layoutgenerierung dem Computer) Versucht Layout komplett zu generieren Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

24 Vergleich der Ansätze   Trennung von Inhalt, Struktur und Logik
UIML IML ISL DDL Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

25 Möglicher Ansatz für die Projektgruppe
Interaction Acts (ISL) VoiceXML Dienst Interaction Engine Interaction Engine HTML Customization Form Customization Form DDL Fragment- ierung tinyHTML interaction engine und Customization Form nicht mehr geräteabhängig, da in abstrakte Sprache DDL übersetzt -> weniger aufwendig -> weniger Anpassung an Geräte möglich Für jede Gerätefamilie eine interaction engine Für jede Gerätefamilie u. jeden Dienst ein Customization Form WML Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

26 Interessenkonflikt einfach kompakt Flexibilität Anpassung ISL DDL
Da wenig Dienste und Geräte würde ich die Qualität der Anpassung vorziehen Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

27 Wichtigste Anforderungen für die Projektgruppe
UIML IML ISL DDL Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Zeile 2: Oberfläche und Funktion optimal an Geräte anpassen Zeile 3: Design der Dienste beeinflussen Zeile 4: Zeile 5: Erweiterbarkeit auf andere Geräte und Dienste sehr wichtig Letzten beiden Zeilen: für unser Projekt haben wir 3 Dienste geplant und auch nicht so viele verschiedene Geräte, deshalb ist das Erzeugen einer interaction engine pro Gerät nicht so tragisch und customization forms pro Gerät u. pro Dienst Auch ok, um die gerätespezifischen Fähigkeiten zu nutzen Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

28 Möglicher Ansatz für die Projektgruppe
ISL Geräte - unabhängig Geräte - abhängig Dienst - unabhängig Geräte - abhängig Dienst - abhängig User Interface Interaction Acts Dienst Geräte- bibliotheken Interaction Engine Customization Form XSL- Stylesheet ISL für Projektgruppe gut Zusätzliche Anforderungen einbauen Validation von Benutzereingaben Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

29 Möglicher Ansatz für die Projektgruppe
ISL XSL A1 HTML XML A eine XSL-Datei pro Dienst und pro Gerät XSL A2 WML XSL B1 XML B XSL B2 CF A1 XML A HTML E 1 eine Engine pro Gerät ein CF pro Dienst ISL für Projektgruppe gut Zusätzliche Anforderungen einbauen CF A2 CF B1 XML B WML E 2 CF B2 Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG

30 für die Aufmerksamkeit!
Vielen Dank für die Aufmerksamkeit! 

31 Backup Dienste WML E-mail E-mail E-mail WML E-mail HTML Kartendienst
tinyHTML tinyHTML WML HTML Kartendienst Browser HTML Benutzer wollen mit vielen Diensten von vielen verschiedenartigen Geräten kommunizieren (konkretes Beispiel nennen: Dienst - PC, Handy) (verschiedene Dienste mit unterschiedlichen Geräten ansprechen) Geräte haben unterschiedliche Leistungsfähigkeit (Speichergröße, Rechenleistung, ….) Und unterschiedliche Eingabe- / Ausgabearten (Bildschirm – Lautsprecher. Tastatur, Maus, Mikrofon) Einen Dienst für jedes Gerät einzeln zu Entwickeln -> teuer Manuelle Anpassung -> teuer Möglichkeiten: Gleiche Oberfläche auf allen Geräten Gerät mit geringster Leistung begrenzt die Funktionalität Vorteile von gerätespezifischen Eigenschaften werden nicht genutzt (Mikrofon, Scrollrad) Oberflächendesign nicht steuerbar (für wirtschaftliche Aspekte wichtig) Neue Version auf jedem Gerät Hohe Kosten für Implementierung Hohe Kosten für Wartung Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung

32 Backup WML E-mail HTML tinyHTML Struktur Struktur Struktur Inhalt
Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung

33 ? Backup WML E-mail HTML tinyHTML
Inhalts-beschreibungssprache Optionale Elemente HTML Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung