Fakultät für Wirtschaftswissenschaften an der Hochschule Wismar

Hochschule Wismar
Fakultät für Wirtschaftswissenschaften
Bachelor-Thesis
Umsetzung eines Dialogmanagementmoduls für multimodale Interaktionen
Bachelor-Thesis zur Erlangung des Grades
Bachelor of Science (BSc.)
der Hochschule Wismar
eingereicht von:
Annemarie Ulbricht
geboren am 06. Juli 1989 in Neuruppin
Studiengang Wirtschaftsinformatik
Matrikel Nr. : 111504
Betreuer:
Prof. Dr. J. Cleve
H. Fiedler
Wismar, den 28. Juli 2011
Zusammenfassung
Die Technik erlebt einen rasanten Fortschritt, ob im Haushalt, der Mobil- oder Kommunikationsbranche. Handys und Navigationsgeräte sind keine Einzelfälle im Boom des technologischen
Fortschritts. Beiden ist gemeinsam, dass sie über eine grasche Oberäche gesteuert werden
können, häug auch nur über diesen Weg. Dabei würden zusätzliche Modalitäten den Komfort
und die Benutzerfreundlichkeit sichtlich erhöhen.
Ein Anwendungsgebiet für eine verbesserte Kommunikation könnte die eigene Wohnung oder
das Eigenheim sein, welches durch Sprache und grascher Oberäche eine Bedienung aller
technischen Geräte ermöglicht. Diese wäre vor allem für Senioren und Personen mit Handicap
eine groÿe Erleichterung.
Für die Steuerung der Eingaben ist ein Dialogsystem notwendig, dessen Kern ein Dialogmanager darstellt.
Die vorliegende Arbeit beschäftigt sich genau mit diesem Sachverhalt, nämlich der Umsetzung eines Dialogmanagers für multimodale Interaktionen, also den Gesprächen zwischen
Mensch und Computer über mehrere Kommunikationskanäle. Als Modalitäten wird einerseits
ein Chatfenster und andererseits ein Bedienfenster verwendet. Das Chatfenster funktioniert wie ein Chat aus dem Internet, nur zwischen dem Benutzer und Computer. Das Bedienfenster ermöglicht dem Anwender das gezielte Bedienen eines Gerätes über eine grasche
Oberäche. Über die Modalitäten werden diverse virtuelle Geräte und ein reales Fernsehgerät
gesteuert. Des Weiteren sorgt ein Ausgabefenster für die visuelle Darstellung der Geräte und
ihres Zustands.
Abstract
The engineering progress is growing rapidly whether in the section of household, automobile or
communication. That goes along with mobile phones and devices for navigation. Controlling is
based on graphic surfaces as is mostly the case. Unfortunately, inputs often are only possible
about this kind of way. Thereby additional input units will increase the accommodation and
usability.
A possible area of application could be the home or at which enables the control of all devices
via speech and a graphic interface. That could be a big relief for seniors and handicapped
persons.
The dialogsystem is necessary for the control of inputs. The core of the system calls dialogmanager. This work deals with the implementation of a dialog management module for
multimodal interactions, which are conversations between humans and computers about several communication ways. The used modalities are a Chatfenster and Bedienfenster. The
rst one acts like the well-known chat conversation of the internet. The only dierence is the
communcation between user and computer. It depends on human language. The other modality enables the user for a direct control of one unit. Both modalities allow a regulation
of many virtual devices and a real television receiver. Furthermore, a window, which calls
Ausgabefenster, shows the virtual house including all units and their condition.
Ehrenwörtliche Erklärung
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht. Es wurden keine anderen als die angegebenen Quellen und Hinweise verwendet.
Die vorliegende Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch
nicht veröentlicht.
Ort, Datum
Unterschrift
Inhaltsverzeichnis
Abbildungsverzeichnis
5
Tabellenverzeichnis
6
Abkürzungsverzeichnis
7
1 Einleitung
8
2 Grundlagen
2.1
10
Automatentheorie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.1
Endliche Automaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.2
Kellerautomaten
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Multimodale Kommunikation
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
Dialogsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4
Beschreibungssprachen im Vergleich
. . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.1
VoiceXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.2
CCXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.3
SALT
18
2.4.4
UsiXML
2.4.5
UIML
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4.6
SCXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4.7
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 Anforderungsanalyse
3.1
Ausgangssituation
3.2
Zielsetzung
3.3
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Abgrenzung der Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4 Konzept
24
4.1
Aufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2
Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5 Implementierung
5.1
5.2
Umsetzung
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.1
Zustandsautomaten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.2
Modalitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.1.3
Programmumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.1.4
Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
INHALTSVERZEICHNIS
6 Zusammenfassung und Ausblick
44
4
Abbildungsverzeichnis
1
Systematischer Aufbau eines endlichen Zustandsautomaten
L(p) =
an bm |n, m
> 0}
. . . . . . . . . . .
10
2
DFA, welcher die Sprache
akzeptiert . . . . . . . . . . .
11
3
Kellerautomat, welcher gleich viele a's und b's akzeptiert . . . . . . . . . . . . .
13
4
Multimedialität und Interaktivität [Her06, S. 13]
14
5
Kommunikationsmodell von Shannon/Weaver[Cha]
6
Aufbau des Basisprogramms [Ulb11]
7
Komponentenübersicht vom Programm
8
Komponentenübersicht des Dialogmanagers
9
Sequenzdiagramm - Benutzereingabe (unvollständiger Auftrag)
10
Dialogmanager - vereinfachter Zustandsautomat
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
24
25
. . . . . . . . .
29
. . . . . . . . . . . . . . . . .
31
11
Dialogorientierter Zustandsautomat für ein TV-Gerät . . . . . . . . . . . . . . .
33
12
Bedienfenster
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
13
Ablauf des Programms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
14
Denition des Structs DataFormat
39
. . . . . . . . . . . . . . . . . . . . . . . .
Tabellenverzeichnis
1
Übersicht über die 8 goldenen Regeln von Shneiderman [Dah06, S. 151] . . . . .
15
2
Tools, welche UsiXML unterstützen . . . . . . . . . . . . . . . . . . . . . . . . .
18
3
Unterstützung einiger Browser beim Anzeigen von SVG-Dateien . . . . . . . . .
36
4
Unterstützung einiger Rendering Engines beim Anzeigen von SVG-Dateien . . .
37
5
Maÿnahmen zur Berücksichtigung der Regeln von Shneiderman
43
. . . . . . . . .
Abkürzungsverzeichnis
ASR
Automatic Speech Recognition
CCXML
Call Control eXtensible Markup Language
DFA
Deterministic Finite Automaton
DTMF
Dual-Tone Multi-Frequency
GUI
Graphical User Interface
NFA
Nondeterministic Finite Automaton
SALT
Speech Application Language Tag
SCXML
State Chart XML
SVG
Scalable Vector Graphics
UI
User Interface
UIML
User Interface Markup Language
UsiXML
USer Interface eXtensible Markup Language
VoiceXML
Voice eXtensible Markup Language
W3C
World Wide Web Consortium
X3D
eXtensible 3D
XML
eXtensible Markup Language
1 EINLEITUNG
1
Einleitung
Mehr als die Hälfte aller Unfallverletzungen sind dem Bereich Haushalt und Freizeit anzurechnen. Dabei sind 80% der Unfälle auf menschliches Fehlverhalten zurückzuführen.
Besonders betroen sind Kinder und Senioren. Mehr als 10.000 Personen über 60 Jahren
sterben jedes Jahr in Deutschland infolge von Haus- und Freizeitunfällen. Bei Männern
sind rund 63% und bei Frauen rund 79% dieser Sterbefälle auf Stürze als Unfallursache
zurückzuführen. [Ges]
Aber auch andere Unfallgefahren sollten berücksichtigt und vermieden werden. Die Gesundheitsberichterstattung des Bundes schlägt daher drei wichtige Punkte zur Vermeidung von
Unfällen vor:
•
technisch sichere Gestaltung
•
gesetzliche Regelungen
•
erzieherische Einuÿnahme [Ges]
Ein interessanter und zugleich wichtiger Aspekt ist sicher die Technik und ihre Entwicklung.
In den letzten Jahren wurde viel getan um Unfälle basierend auf Technik zu vermeiden. Dazu
gehört beispielsweise das Verbieten von Handytelefonaten am Ohr während des Autofahrens.
Auch Navigationsgeräte helfen Unfälle zu vermeiden. Ein System ermöglicht das Errechnen
einer Strecke und gibt diese dann per Sprachausgabe an den Fahrer weiter. Das erspart das
lange Suchen auf der Karte und ermöglicht dem Fahrer sich konzentriert der Straÿe zu widmen. In der Automobilbranche wird viel zur Unfallvermeidung und Reduzierung von tödlichen
Unfällen unternommen.
Dabei sollte der häugste Unfallbereich nicht vergessen werden: der Haushalt. Wie die Statistiken beweisen, passieren etwa 1/3 der Unfälle im Haushalt. Daher sollte auch hier die Technik
zur Unfallvermeidung genutzt werden. Eine Möglichkeit wäre die Erschaung eines intelligenten Hauses, eines Smart Home. Ausgestattet mit Sensoren bedient es Geräte und hilft so
Unfälle zu vermeiden. Ein weiterer positiver Eekt ist die Reduzierung des Energieverbrauchs
und somit die Einsparung von Kosten. Eektiver wird das Smart Home, wenn die Geräte
nicht nur über eine grasche Bedienoberäche, sondern auch multimodal, also über Sprache
oder Mimik und Gestik, gesteuert werden können. So könnte beispielsweise die Forderung mache die Lampe im Flur an den nächtlichen Weg zur Toilette unfallfrei gestalten, weil eventuell
herumliegende Gegenstände am Boden leicht erkannt werden. Ein Abtasten der Wand, um den
Schalter zu suchen, ist überüssig.
Auch wenn es schon einige Systeme gibt, welche sich mit multimodaler Kommunikation beschäftigen, so ist das Forschungsgebiet längst noch nicht vollends ergründet.
8
1 EINLEITUNG
Diese Arbeit beschäftigt sich mit der Kommunikation zwischen Mensch und Computer. Genauer gesagt wird ein Dialogsystem erstellt, welches die multimodale Interaktion leiten soll. Der
Kern des Dialogsystems, der Dialogmanager, soll dafür Eingaben aus zwei Kommunikationskanälen aufnehmen und verarbeiten. Dies ist einerseits ein Chatfenster und andererseits ein
Bedienfenster. Das Chatfenster ist eine auf Sprache basierende Ein- und Ausgabemöglichkeit.
Dabei wird die Sprache in Form einer oder mehrerer Wörter an das System übermittelt. Ein
sogenanntes Bedienfenster hat nichts mit dem Internet zu tun, sondern ermöglicht dem Anwender Eingaben über eine grasche Oberäche. Dabei kann unter Zuhilfenahme eines Menüs
ein Gerät ausgewählt und eine Aktion in Auftrag gegeben werden. Ferner schat ein Ausgabefenster im virtuell verwalteten Haus eine bessere Benutzerfreundlichkeit durch grasche
Anzeige des jeweils aktuellen Zustands der Geräte im Haus.
Zu Beginn dieser Arbeit werden einige Grundlagen bzgl. der Erstellung eines Dialogmanagers
(Kapitel 2) erläutert. Anschlieÿend folgt eine Anforderungsanalyse (Kapitel 3) und die Darstellung des verwendeten Konzepts (Kapitel 4). Im Kapitel 5 werden die Gedanken bei der
Implementierung eines Prototyps im Vordergrund stehen, welche durch eine Zusammenfassung
mit integriertem Ausblick im 6. Kapitel abgerundet werden.
9
2 GRUNDLAGEN
2
Grundlagen
Im Folgenden wird das Basiswissen zur Erstellung eines Dialogmanagers kurz erläutert. Dies
beinhaltet Grundlagen zur Automatentheorie, eine Erklärung des Begries multimodale Kommunikation, Anmerkungen zu Dialogsystemen sowie eine Bewertung einiger Dialogbeschreibungssprachen.
2.1
Automatentheorie
Der zu erstellende Dialogmanager soll auf dem Konzept der Zustandsautomaten basieren.
Mehrere Automaten kommen dafür in Betracht. Im Folgenden werden die beiden für dieses Projekt am aussichtsreichsten Varianten vorgestellt, nach einer kurzen Einführung in das
Themengebiet der Automatentheorie.
Die Automatentheorie hat die Aufgabe, mit Hilfe abstrakter Automatenkonzepte die verschiedenen Verarbeitungstechniken von mechanischen oder elektronischen Geräten systematisch zu
erfassen. [Hed07, S.53]
In diesem Zusammenhang heiÿt das, dass ein Automat den Dialoguss zwischen Mensch und
Maschine steuern soll. Der Dialoguss ist eine Sequenz von Objekten. Dabei legen die jeweiligen
Objekte, ihre Parameter und die Reihenfolge, in der sie zusammengesetzt sind, den Weg fest,
dem ein Benutzer während seines Auftrags folgt. [Voi]
Bei den nachfolgend vorgestellten Automaten wird jedes Zeichen in einer Zeichenkette einmal
eingelesen. Anschlieÿend wird die Position des Lesekopfes um eins erhöht bis das Ende des
Eingabebandes erreicht ist.
2.1.1 Endliche Automaten
Endliche Automaten sind durch Zustände, Zustandsübergänge, einem Anfangs- und mindestens einem Endzustand gekennzeichnet. Die Abbildung 1 verdeutlicht den systematischen
Aufbau eines Zustandsautomaten. Man unterscheidet zwischen deterministischen (DFA) und
Abbildung 1: Systematischer Aufbau eines endlichen Zustandsautomaten
nichtdeterministischen endlichen Automaten (NFA). Der Unterschied liegt darin, dass bei letzterem der Zustandsübergang nicht eindeutig deniert sein muss. Ausgehend von einem kon-
10
2 GRUNDLAGEN
kreten Zustand können über ein Ereignis mehrere Folgezustände erreicht werden.[Hed07, S.
60 ] Dieses Konzept ist eine Erweiterung des deterministischen Automaten, da jede Überführungsfunktion auch eine Überführungsrelation ist. Beide Varianten der endlichen Automaten
können wie gefolgt deniert werden:
Ein endlicher Automat ist ein 5-tupel M = (Z, V,
d, qM
,F) mit
1. Z, V sind endliche nichtleere, disjunkte Mengen. Z heiÿt Zustandsmenge, V heiÿt das Eingabealphabet.
2.
d : ZxV → Z , d
d ⊆ ZxV xZ
3.
qM ∈ Z ,
4.
F ⊆ Z,
heiÿt Überführungsfunktion (bei deterministischen Automaten).
heiÿt Überführungsrelation (bei nichtdeterministischen Automaten).
qM heiÿt der Anfangszustand.
F heiÿt Menge der Endzustände. [Hed07, S. 57, 63]
Zustandsdiagramme (Übergangsdiagramme) ermöglichen die Darstellung von endlichen Automaten. Dabei werden Zustände durch Kreise, Zustandsübergänge durch Pfeile und Finalzustände durch einen Kreis mit doppelter Umrandung dargestellt. Für Anfangszustände, auch
Initialzustände genannt, gibt es verschiedene Varianten zur graschen Darstellung. Diese reichen von einer farblichen Hervorhebung des Kreises bis hin zur zusätzlichen Kennzeichnung
mit Pfeilen oder dem Wort Start.
Ein einfaches Beispiel soll den Aufbau eines deterministischen Zustandsautomaten näher bringen. Dabei wird eine Zeichenkette akzeptiert, welche mind. ein a und nachfolgend mind.
ein b beinhaltet. Die Spezikation des Zustandsautomaten kann wie folgt dargestellt werden:
M = ({q0 , q1 , q2 }, {a, b}, {(q0 , a) → q1 , (q1 , a) → q1 , (q1 , b) → q2 , (q2 , b) → q2 }, q0 , {q2 }).
Die Zustandsmenge Z besteht aus drei Zuständen:
q0 , q1
und
q2 .
Das Eingabealphabet V
besteht aus den Zeichen a und b. Nur diese Zeichen werden vom endlichen Automaten
berücksichtigt.
(q1 , a) → q1
aktuelle Zustand
q1
bedeutet hierbei, dass eine Zustandsänderung eintritt, falls der
ist und ein a eingelesen wird. Da dies eine reexive, also selbstbezogene
Beziehung ist, bleibt der aktuelle Zustand gleich, nämlich
Abbildung 2: DFA, welcher die Sprache
q1 . Der Startzustand ist q0 . Wird ein
L(p) = an bm |n, m > 0}
a von der Zeichenkette eingelesen, erfolgt gemäÿ Abbildung 2
stand
q1 .
1 ein Zustandswechsel zum Zu-
Andernfalls bleibt der Automat im aktuellen Zustand
wechselt der Zustandsautomat vom Zustand
q1
in
dem Einlesen der Zeichenkette im Finalzustand
akzeptiert
q0 .
Folgt anschlieÿend ein b
q2 . Bendet sich der Zustandsautomat nach
q2 ,
so erfüllt der String die obige Bedingung
und wird akzeptiert.
1
Erstellt mit JFLAP von Susan H. Rodger; URL: http://www.cs.duke.edu/csed/jap/
11
2 GRUNDLAGEN
Von endlichen Automaten akzeptierte Sprachen können auch durch reguläre Ausdrücke dargestellt werden. Dies ist eine strukturelle Notation zur Beschreibung der Muster, die durch
einen endlichen Automaten repräsentiert werden kann. [HMU02, S. 43]
Für das obige Beispiel würde der reguläre Ausdruck wie folgt lauten: p = a*b*. Daraus ergibt
sich die kontextfreie Sprache
2
L(p) = an bm |n, m > 0}. Die Sprache beschreibt alle Zeichenket-
ten, welche akzeptiert werden.
2.1.2 Kellerautomaten
Der Kellerautomat basiert auf den Gedanken vom DFA und NFA nur mit einer Erweiterung:
dem Stack, auch Keller genannt. Dieser kann sich die letzten Zustände merken indem er sie
in eine Liste speichert. Jedoch kann diese nur auf das letzte Element zugreifen. Die Denition
des Kellerautomaten ähnelt jener der endlichen Automaten.
Ein (nichtdeterministischer) Kellerautomat (mit Endzuständen) ist ein 7-tupel
M = (Z, V, U, δ, qM , KM , F )
mit
1. Z, V, U sind endliche, nichtleere Mengen. Z heiÿt Zustandsmenge, V heiÿt das Eingabealphabet, U heiÿt das Kelleralphabet.
2.
d
δ ⊆ Z × (V ∪ {ε}) × U × Z × U ∗, d
endlich,
d
heiÿt Überführungsrelation, die Elemente aus
heiÿen Anweisungen.
3.
qM ∈ Z , qM
4.
KM ∈ U , KM
5.
F ⊆ Z,
heiÿt der Anfangszustand.
heiÿt das Anfangskellerzeichen.
F heiÿt die Menge der Endzustände. [Hed07, S. 116]
Ein Beispiel soll auch die Funktionsweise dieses Automaten genauer erläutern.
Gesucht ist ein Kellerautomat, welcher einen String akzeptiert, der gleich viele a's und b's enthält. Jedoch müssen beide Zeichen mind. einmal vorkommen. Dargestellt kann diese Bedingung
durch folgende Sprache
L = {an bn |n ≥ 1}.
Die Abbildung 3
3 zeigt die grasche Darstellung
des Kellerautomaten in Bezug auf dieses Beispiel. Formal lassen sich die Merkmale wie nachstehend denieren:
M = ({q0 , q1 , q2 }, {a, b}, {A, B, E}, δ, q0 , E, {q2 }). Die Überführungsrelation δ
kann bestimmt werden durch die Anweisungen:
q0 aE → q1 AE , q0 bE → q1 BE , q1 aA → q1 AA, q1 aB → q1 ε, q1 bA → q1 ε, q1 bB → q1 BB ,
q1 εE → q2 ε.
Dabei ist
e
der leere String. An dieser Stelle wird dann nichts eingelesen.[Cle11,
S. 36]
Eine Anweisung setzt sich aus dem aktuellen Zustand, dem aktuellen String, dem obersten
Zeichen im Keller, dem neuen Zustand und den neuen obersten Zeichen zusammen. Die Anweisung
2
q0 aE → q1 AE
könnte man umschreiben mit den Aussagen: Wenn sich der Kellerautomat
beruht auf einer kontextfreien Grammatik, welche gilt, wenn jede Produktion die Form hat A → β , wobei
A ∈ Vn , β ∈ V + ist, mit der Ausnahme S → ε[Hed07, S. 36]
3
Mit JFLAP erstellt.
12
2 GRUNDLAGEN
Abbildung 3: Kellerautomat, welcher gleich viele a's und b's akzeptiert
im Zustand
q0
bendet, ein a vom Band eingelesen wird und das oberste Zeichen im Keller
ein E ist, dann wechsle in den Zustand
q1
und ersetze das ehemals oberste Element E durch
A und E. A steht für ein bereits eingelesenes a und wird gelöscht, wenn ein b eingelesen
wird. Das Gleiche gilt natürlich auch für das Zeichen B. Das Löschen wird durch das Zeichen
e
realisiert. Kann kein Zeichen vom Eingabealphabet mehr eingelesen werden und das
oberste Zeichen im Stack ist das E, so wird die Zeichenkette akzeptiert, da sie die Bedingung
L = {an bn |n ≥ 1}
2.2
erfüllt.
Multimodale Kommunikation
Zunächst müssen einige Begrisdenitionen vorgenommen werden. Interaktion beschreibt die
Wechselwirkung zwischen Mensch und Computer.[Her06, S. 12]
Eine Wechselwirkung basierend auf einem Dialog zwischen Mensch und Maschine wird in diesem Kontext Kommunikation genannt. Ein Dialog ist dabei der wechselseitige Austausch von
Daten oder Nachrichten zwischen Mensch und Maschine. Voraussetzung für eine Kommunikation ist die Verwendung einer übereinstimmenden Sprache und eines Übertragungskanals. Der
Begri Interaktion ist somit allgemeiner als der Begri Kommunikation.[Bei00, S. 50]
Multimedialität ist der Oberbegri für die verwendeten Medien, wie beispielsweise Text und
Videos. Modalitäten sind hingegen die Kommunikationskanäle und denieren die Art und
Weise auf der die Kommunikation über die Medien statt ndet. Den Zusammenhang zwischen
Mensch und Computer unter Berücksichtigung der Begrie Multimedialität und Interaktivität
zeigt die Abbildung 4.
Der Begri Kommunikation soll anhand des klassischen Kommunikationsmodells von Shannon/Weaver weiter ausgeführt werden. Die Abb. 5 veranschaulicht das Modell grasch. Drei
Thesen liegen diesem Modell zu Grunde. Die Erste besagt, dass es einen Sender gibt, welcher ein Signal ausgibt, basierend auf einer Informationsquelle. Des Weiteren kann das Signal
durch Störeinüsse von Aussen verändert werden und wird als letztes vom Empfänger aufgenommen. Im Rahmen der Mensch-Maschine Kommunikation sind Sender und Empfänger der
Mensch und der Computer, wobei je nach System die Zuordnung variiert. Signale werden durch
Kommunikationskanäle übertragen. Eine Störung des Signals ist auch hier bedingt möglich.
13
2 GRUNDLAGEN
Abbildung 4: Multimedialität und Interaktivität [Her06, S. 13]
Abbildung 5: Kommunikationsmodell von Shannon/Weaver[Cha]
Beispielsweise kann bei einer Spracheingabe ein Hintergrundgeräusch das Signal verändern,
sodass es fehlerhaft interpretiert werden kann. [Cha],[HS]
Mensch und Computer kommunizieren, um ein bestimmtes Ziel zu erreichen. Dafür werden
Informationen ausgetauscht.[Dah06, S. 18] Probleme bei der Kommunikation ergeben sich aus
der Inexibilität und der Beschränktheit des Computers. Abweichungen vom Programmcode
sind nicht möglich. Dies kann in einigen Fällen zu Fehlern führen, wenn der Benutzer abstrakte
Eingaben tätigt wie beispielsweise mache es doch an. Das System muss nun den gespeicherten
Kontext abrufen. Selbst dies stellt ein Problem dar, da mögliche Geräte erst geltert werden
müssen. Zur erfolgreichen Interaktion muss der Computer die Initiative ergreifen können und
ein eventuelles Missverständnis klären. Möglich ist dieses unter anderem mit systemgesteuerten
Dialogen (siehe Kapitel 2.3.), welche im folgenden Kapitel vorgestellt werden.
Generell kann ein Missverständnis auf zwei Arten gelöst werden: dem Diskurs und dem Disputio. Beim Diskurs tritt ein Missverständnis auf und kann durch Rückfragen gelöst werden. Die
Vermeidung von Problemen wird mit dem Begri Disputio dargestellt und sollte für MultiModale-Interaktionen Anwendung nden, da die Beseitigung des Missverständnisses meistens
sehr umfangreich ist. Eine Paraphrasierung, also Wiederholung der bisherigen Informationen,
soll Missverständnisse früh erkennbar machen. Dazu gehört auch eine Akzeptierung der bisherigen Informationen durch den anderen Kommunikationspartner.[Dah06, S. 121]
Eine Berücksichtigung aller Regeln zur Dialoggestaltung ist schwierig, sodass Shneidermans
Gedanken zu diesem Thema Verwendung nden.
14
2 GRUNDLAGEN
Ben Shneiderman stellte 8 goldene Regeln auf, welche bei der Umsetzung einer Benutzungsschnittstelle berücksichtigt werden sollten. Die Tabelle 1 gibt einen Überblick über die Inhalte
seiner Regeln.
Regel
Erklärung
1 Konsistenz
Ziel ist die einheitliche Gestaltung und Verwendung von allen
Bestandteilen (Aussehen, Wortwahl, Schnittstelle)
2 Berücksichtige
Erfahrene und Anfänger: jeder sollte passende Interaktionsform
unterschiedliche
bekommen
Erfahrungen
3 Rückmeldungen auf
Rückmeldung, dass Eingabe erkannt bzw. verarbeitet wurde;
Aktionen des Benutzers
Fehlerausgaben als besondere Rückmeldung
4 Abgeschlossene
Mitteilen von zusammenhängenden Operationen; Darstellung
Operationen
einzelner Schritte im Zusammenhang der vollständigen
Operation
5 Fehler verhindern
Konstruktive Fehlermeldung, sonst Fehlervermeidung durch
Blockieren nicht möglicher Aktionen und Anbieten von
Alternativen, schnelle Fehlerbehebung
6 Einfache
Ausprobieren des Nutzers ohne Bedenken, wenn UNDO und
Rücksetzmöglichkeiten
REDO oder mehrstuges Rücksetzen; Fehlermeldung wenn
Rücksetzen nicht möglich ist
7 Benutzerbestimmte
Benutzer soll Anwendung kontrollieren, keine Verwendung
Eingaben
starrer Sequenzen, Unterstützung beim Abbrechen von Aktionen,
übersichtliche Darstellung von Informationen und Aktionen
8 Geringe Belastung
Geringe Anzahl von Informationen an Nutzer ausgeben
des
Kurzzeitgedächtnisses
Tabelle 1: Übersicht über die 8 goldenen Regeln von Shneiderman [Dah06, S. 151]
2.3
Dialogsysteme
Dialogsystem heiÿt eine Form der Mensch-Maschine-Kommunikation, bei der über ein dialogfähiges Terminal ein Mensch in den Dialog mit einem Computersystem eintritt. [MH]
Den Kern eines Dialogsystems stellt der Dialogmanager dar. Er speichert den bisherigen Dialogverlauf, fragt Daten ab und erzeugt davon ausgehend die beste Antwort abhängig von der
verwendeten Methode. [Rina]
Das Ziel eines Dialoges kann verschieden sein. Zum Beispiel kann eine Informationsausgabe
(Erwerb von Wissen) das Ziel sein oder die Ausführung eines Auftrages wie beispielsweise
der Kauf von Zugfahrkarten. Häug sind diese Ziele auch miteinander verknüpft, wobei allen
gemein ist, dass eine Übereinstimmung zwischen Benutzer und System dem zur erfolgreichen
Verarbeitung vorausgehen muss.[Rina]
15
2 GRUNDLAGEN
Im Folgenden werden die Arten von Dialogsystemen erläutert.
Finite-State-basierte Dialogsysteme (endliche Automaten) richten sich nach dem Konzept von
endlichen Zustandsautomaten, indem der Nutzer einem vordenierten Weg folgt. An Verzweigungspunkten wird durch Nutzereingaben in Form von Systemfragen oder -ausgaben der neue
Pfad bestimmt. Der Vorteil dieser Variante ist die einfache und übersichtliche Modellierung.
Häug ist es möglich, mit einem Tool Zustandsautomaten grasch zu modellieren. Ebenfalls
kann der vollständige Informationsaustausch vorher modelliert werden. Aber genau in diesem
Vorteil liegt auch der Nachteil. Pfadabweichungen können nicht modelliert werden. Ebenfalls
kann eine Darstellung bei vielen Zuständen schnell unübersichtlich werden (Zustandsexplosion). Hierarchien, also Zusammenfassungen von Zuständen, können die negativen Auswirkungen reduzieren. Da viele Dialogsysteme einfache, zustandsabhängige Systeme sind, wird
diese Variante dennoch in den meisten kommerziellen Systemen auf Grund der Einfachheit
genutzt.[Rinb],[Pre99, S. 290]
Bei
framebasierten Dialogsystemen (framebasierte Slot-Filling-Systeme) wird ein Formular der
Reihe nach ausgefüllt. Dabei ist der Dialog am Muster orientiert, mit dem Ziel, diesen auszufüllen. Dabei müssen die Eingaben nicht in einer bestimmten Reihenfolge getätigt werden.
Das framebasierte Dialogsystem besteht aus einem Frame, welcher bereits getätigte Informationseingaben speichert, sowie eine Grammatik um die Eingaben in die entsprechenden Teile
der Formulare einzubinden und die nächsten Aktionen fest zu legen. Ein Anwendungsbeispiel hierfür ist VoiceXml. Der Vorteil liegt in der höheren Flexibilität gegenüber den nitestate-basierten Dialogsystemen und in der möglichen mixed-initiativen Dialogführung, wie
im weiteren Verlauf erläutert. Der Aufwand ist jedoch höher, als in der davor beschriebenen
Variante.[Rinb]
Bei
agentenbasierten Dialogsystemen wird mittels Expertensystemen und KI-Methoden ver-
sucht ein natürliches Gespräch zu führen. Die Implementierung ist sehr komplex und ndet
bisher nur an akademischen Einrichtungen Anwendung.[Rinb]
Dialogsysteme sollen auf Benutzeranforderungen eingehen. Dabei sind meistens zusätzliche Informationen notwendig um die Anfrage erfolgreich beantworten zu können. Zusätzliche Informationen können durch den bisherigen Dialog, Alltagswissen, Spezialwissen, den Erfahrungen
des Nutzers gesammelt werden.[Rinb] Eine Analyse des Dialogusses liefert hierfür wichtige
Informationen.
Dem Dialoguss können folgende drei Varianten zu Grunde liegen:
Bei einem systemgesteuerten Dialoguss behält der Computer die ganze Zeit die Initiative.
Er steuert den Dialog und erwartet vom Benutzer bestimmte Angaben, die seinen Vorgaben
entsprechen. Die zweite Möglichkeit besteht in der benutzergesteuerten Anwendung, wobei
der Nutzer die Initiative ergreift und der Computer nur auf seine Eingaben reagiert. Bei der
dritten Variante kann ein Dialoguss auch von beiden bisherigen Systemen gesteuert werden, ist also eine Mixvariante, wobei die Initiative ständig wechselt. Der Benutzer kann dabei
16
2 GRUNDLAGEN
die Dialogrichtung durch seine Eingabe ändern. Das System reagiert darauf und versucht die
ursprünglich Dialogrichtung wiederherzustellen. Diese Variante ndet heutzutage bei Dialogsystemen am häugsten Verwendung. [Rina]
2.4
Beschreibungssprachen im Vergleich
Für die diversen Modalitäten wird eine zustandsorientierte Beschreibungssprache benötigt.
Problematisch ist dabei, dass es viele Modalitäten gibt. So ist eine Beschreibungssprache für
sprachliche Dialoge anders deniert als für grasche. Im Weiteren werden nun einige der gängigsten Standardbeschreibungssprachen kurz erläutert und anschlieÿend bewertet. Viele beruhen auf XML, weshalb eine kurze Einordnung des Begries erfolgt.
XML steht für Extensible Markup Language (erweiterbare Auszeichnungssprache) und gilt
als Standard um Sprachen in einem bestimmten Format zu erzeugen. [UIM] Tatsächlich wird
er bei sehr vielen Beschreibungssprachen verwendet, wie die nachfolgenden Beispiele belegen.
2.4.1 VoiceXML
Seit 2000 gehört VoiceXML (Voice Extensible Markup Language) zu den Standardbeschreibungssprachen und gilt heute als eine der verbreitetsten Beschreibungssprachen zur Erstellung
von sprachlichen Dialogen. Das Ziel von VoiceXML ist es, die Vorteile von web basierenden
Entwicklungen zu interaktiven sprachgesteuerten Applikationen weiter zu entwickeln. [McG]
Als VoiceXML-Applikation bezeichnet man den gesamten Sprachdialog, welcher aus mind. einem VoiceXML-Dokument besteht. Die Dokumente können in einer beliebigen Reihenfolge ausgeführt werden. Dabei bildet ein VoiceXML-Dokument das Wurzeldokument (Root-Dokument,
Master). Andere Dokumente können in diesem aufgerufen und auf dieses referenziert werden.
Eine wichtige Komponente ist der Voice-Browser. Er führt Anwendungen aus und kann über
ein Voice-Gateway, mittels eines Telefonanrufs, erreicht werden. Eine Eingabe kann mittels
4 Tastenerkennung erfolgen. Die Ausgabe
automatischer Spracherkennung (ASR) bzw. DTMFwird mittels Text-to-Speech
5 bzw. Audiodateien erzeugt. [Gla]
2.4.2 CCXML
6 entwickelt und stellt eine eigene Beschreibungssprache dar.
Auch CCXML wurde vom W3C
Entwickelt wurde sie als Ergänzung zum VoiceXML-Interpreter. Die Abkürzung CCXML steht
für Call Control eXtensible Markup Language, was soviel wie erweiterbare Auszeichnungssprache zur Anrufsteuerung bedeutet. Ziel der Entwicklung von CCXML war die Unterstützung der Anrufsteuerung von Dialogsystemen durch erweiterte Telefonie-Funktionen. Eine
Anwendung besteht aus mehreren CCXML Dokumenten, welche u. a. für die Steuerung und
Kontrolle von Dialogen und Verbindungen verwendet werden. CCXML wird dabei von Events
gesteuert.[Aub]
4
DTMF steht für dual-tone multi-frequency, was übersetzt Doppeltonmehrfrequenz bedeutet und ist ein
Verfahren zum Übermitteln der gedrückten Tasten eines Telefons an das Telefonsystem.
5
TTS gibt künstlich erstellte Texte aus.
6
Das World Wide Web Consortium ist ein Gremium welches Standards fürs Internet bestimmt; URL:
http://www.w3.org/
17
2 GRUNDLAGEN
2.4.3 SALT
Die Abkürzung SALT steht für Speech Application Language Tag und basiert auf dem Speech
Application Interface (SAPI) von Microsoft. SALT ist ein vorgeschlagener Standard, welcher
Sprachschnittstellen implementiert. Er ist objekt-orientiert und eventgesteuert. Dies beinhaltet
das Verstehen von Spracheingaben, Erzeugen von Sprachausgaben sowie das Kommunizieren
mit anderen Komponenten der Plattform. All dies wird durch eine Software ermöglicht. Der
Vorteil dieser Sprache ist, dass sie unabhängig von einer Programmiersprache ist und leicht
in HTML- und XML-Dokumenten eingebunden werden kann. SALT wurde so konzipiert, dass
komplexe Probleme durch das Lösen von Unterproblemen gelöst werden können. Diese Unterprobleme sind weniger komplex und somit einfacher zu lösen, als das alleinige Hauptproblem.
Anwendung ndet dieses Verfahren häug im Internet, wo ein komplexer Vorgang aufgeteilt
und anschlieÿend durch weniger komplexe Vorgänge auf verschiedenen Seiten dargestellt wird.
Ein Unterproblem wird hier jeweils durch eine Seite dargestellt. Der Nachteil ist, dass es derzeit
noch Probleme bei der Sprachausgabe gibt.[Wan02]
2.4.4 UsiXML
UsiXML steht für USer Interface eXtensible Markup Language und ist eine auf XML basierende Sprache um UI (Benutzerschnittstellen) für mehrere Anwendungen zu beschreiben.
Dazu gehören Character User Interfaces (CUIs), Graphical User Interfaces (GUIs), Auditory User Interfaces und Multimodal User Interfaces. Die Benutzung durch verschiedene
Modalitäten, Kommunikationstechniken und Plattformen wird durch die deklarative Sprache UIDL (User interface Description Language) errreicht, wobei eine Trennung des Design
zu anderen physikalischen Komponenten erfolgt. Auÿerdem werden Anwendungselemente wie
Geräte, Modalitäten und Bedienelemente auf einer hohen Ebene abstrahiert. Ein Vorteil in der
Benutzung von UsiXML ist die Unterstützung von Toolkits. Dabei können erstellte UsiXMLAnwendungen in UsiXML-kompatiblen Toolkits bearbeitet werden.
Nachteilig ist, dass UsiXML bei seiner Ausführung und Erstellung abhängig von Engines von
Dritt-Anbietern ist. Dabei wird UsiXML von einer groÿen Anzahl von Tools unterstützt, wie
die nachfolgende Tabelle 2 verdeutlicht.[Sta]
Bereiche
Beispiele
Editor
GraXML, VisiXML, PlastiXML
Generator
UsiXML4ALL(RenderXML), KnowiXML
Interpreter
HaptiXML, QtkiXML
Andere
MultimodaliXML, FlowiXML
Modell Managers
MethodiXML, UsiXML metamodelling
Tabelle 2: Tools, welche UsiXML unterstützen
18
2 GRUNDLAGEN
2.4.5 UIML
Die Abkürzung UIML steht für User Interface Markup Language. UIML ist eine deklarative,
auf XML-basierende Sprache um Benutzerschnittstellen zu beschreiben. Dabei wird lediglich
ein Dokument für eine Geräteklasse entwickelt. UIML bestimmt den Ort, die Gestaltung und
eventgesteuerte Aktionen von Elementen wie Listen und Menüs. Die Ereignisse werden vom
Benutzer ausgelöst, z. B. durch einen Mausklick. Im Dezember 1997 wurde die erste Version
publiziert. Die aktuelle Version 3.1 (Working Draft) steht seit März 2004 zur Verfügung. UIML
ergänzt andere Standards wie VoiceXML. Dabei gibt UIML eine einheitliche Weise zur Implementierung vor, sodass jede Sprache UIML verwenden kann. Dabei ist vorgesehen ein Dokument in einer Sprache zu schreiben und es anschlieÿend mittels eines Tools in UML zu transformieren. Dieses kann dann in anderen Sprachen abgebildet werden. UIML ist u. a. unabhängig
von Oberächen, Zielplattformen (Endgeräte) und Zielsprachen wie VoiceXML. Vocabularys
können von jedem Benutzer unterschiedlich deniert werden. Diese legen dann die Klassen und
7 ermöglichen eine multimodale Benutzerschnittstelle.[Sta]
ihre Eigenschaften fest. Templates
2.4.6 SCXML
State Chart XML (SCXML) stellt eine ereignisgesteuerte, abstrakte Sprache für Zustandsau-
8
tomaten dar. Ziel ist die Verbindung von CCXML und Harel State Tables . CCXML verfügt
über eine Syntax für Zustandsautomaten und Ereignissteuerung und bietet einige bereits denierte Steuerungselemente. SCXML verbindet nun Harels Idee mit einer Darstellung durch
eine XML-Struktur und erweitert die Notation von CCXML.[Bar]
SCXML wurde mittels UML (Unied Modeling Language) erstellt. Das Konzept von UML
umfasst mehrere Diagramme. Unter der Gruppe der Verhaltenszustände ist das Konzept der
Zustandsautomaten (State Machines) zu nden. Damit können ebenfalls endliche Zustandsautomaten modelliert werden.[Obj10]
Ein SCXML-Dokument beginnt mit einem root element, auch Wurzelelement genannt. In
diesem werden Informationen wie die ID des Startzustandes, der Namespace und die Version
gespeichert. Ein Zustand wird deniert durch eine ID, einem eindeutigen String. Zusätzlich
sind Informationen denierbar, welche z. B. Informationen speichern, die beim Eintreten des
Zustands ausgeführt werden sollen. Übergänge benötigen einen Namen und optional ein Ziel.
Ist kein Ziel angegeben, so ist dies ein reexiver Übergang, bei dem Anfangs- und Endzustand
gleich sind. Auÿerdem können Übergänge eine Bedingung enthalten. Erst wenn diese erfüllt
ist, wird eine Zustandsänderung ausgelöst. Für die Kommunikation mit der Entwicklungsumgebung sorgen Tags wie send und nalize.
Im Anhang ist ein einfaches Beispiel dargestellt, welches die Funktionsweise einer Lampe als
SCXML-Datei darstellt.1
7
Schablonen, welche für Programme erstellt werden.
Konzept von Prof. David Harel vom Weizmann Institute of Science (Israel); Buch: D. Harel and M. Politi,
Modeling Reactive Systems with Statecharts: The STATEMATE Approach, McGraw-Hill, 1998
8
19
2 GRUNDLAGEN
Es gibt drei Zustände: an, aus, nal. Der Zustand aus ist der Startzustand. Von ihm ausgehend lösen die Ereignisse an und exit jeweils Zustandsänderungen zu anderen Zuständen
aus. Die Informationen im send-Tag können ausserhalb des Zustandsautomaten verwendet
werden. Den Abschluss des Dokuments kennzeichnet das Schlieÿen des SCXML-Tags.
2.4.7 Bewertung
Von den sechs vorgestellten Beschreibungssprachen ist mehr als die Hälfte auf eine Kommunikationsform spezialisiert. Da ein wichtiger Aspekt der Arbeit die Multimodalität darstellt,
werden UIML, SALT und VoiceXML auf Grund ihrer einseitigen Ausrichtung nicht weiter
betrachtet.
CCXML berücksichtigt den sprachlichen Kommunikationskanal und stellt in Verbindung mit
VoiceXML eine gute Alternative dar. Jedoch wird besonders dieser Kommunikationskanal
unterstützt, welcher das Erweitern um andere Modalitäten erschwert. Daher wird auch diese
Sprache nicht weiter betrachtet.
Lediglich UsiXML und SCXML erfüllen die grundlegenden Anforderungen an einen, für multimodale Interaktionen geeigneten, Dialogmanager.
UsiXML wird von vielen Tools unterstützt, welche das Arbeiten mit der Beschreibungssprache
einfach gestalten können. Besondere Rücksicht ndet die Erstellung grascher Modalitäten. Da
Sprachausgaben in Zukunft auch denkbar wären und eine Erweiterung diesbezüglich einfach
erfolgen soll, wird UsiXML nicht weiter betrachtet.
Lediglich SCXML bietet eine gute Alternative, mittels Zustandsautomaten verschiedene Kommunikationskanäle einzubinden, weshalb SCXML weiter verwendet wird. Weiterere Gründe für
die Nutzung von SCXML ist das Ausgangsprojekt, welches auf SCXML basiert und die ständige Weiterentwicklung dieser Beschreibungssprache.
20
3 ANFORDERUNGSANALYSE
3
Anforderungsanalyse
Nach den theoretischen Vorüberlegungen werden nun die Anforderungen an das Programm
deniert. Dafür werden als erstes die Ausgangssituation und die Zielsetzung erläutert. Auf
dieser Basis kann anschlieÿend eine Abgrenzung der Aufgabenstellung vorgenommen werden.
3.1
Ausgangssituation
Als Grundlage dieser Arbeit stand ein prototypisches Programm basierend auf einer graschen
und einer auf Sprache basierenden Modalität. Diese wurden durch einen Interaktion Manager gesteuert, welcher die zentrale Komponente des Programms bildete. Der Dialogmanager
verwaltete die Zustandsautomaten wobei die Leitung des Dialogmanagers durch den Interaction Manager realisiert wurde. Die nachstehende Abbildung 6 verdeutlicht den grundlegenden
Aufbau und Ablauf des Programms.
Abbildung 6: Aufbau des Basisprogramms [Ulb11]
Verbesserungswürdig war die Menüstruktur der graschen Oberäche, da diese unübersichtlich
und nicht intuitiv anwendbar war. Laut Aufgabenstellung soll der Dialogmanager die Modalitäten steuern, sodass dafür eine Umstrukturierung notwendig war. Dennoch konnten einige
Komponenten weitestgehend übernommen werden, wie auch im Kapitel 4.1 erläutert wird.
Aus den Unstimmigkeiten im Prototyp des Programms ergab sich ein Teil der Zielsetzung zu
dieser Arbeit, wie nachfolgend geschildert.
21
3 ANFORDERUNGSANALYSE
3.2
Zielsetzung
Die Bachelorarbeit unterteilt sich in den Bereich des Dialogmanagers, seiner Umgebung und
den Modalitäten. Daher werden die Ziele getrennt voneinander aufgelistet.
Die Anforderungen an den Dialogmanager sind folgendermaÿen speziziert:
•
Steuerung des Dialogusses
•
Steuerung der Modalitäten
•
Ermittlung des aktuellen Status der Modalitäten
•
Setzen eines Status einer Modalität
•
Auf Wunsch Synchronisierung der Kommunikationskanäle
•
Erstellung dialogorientierter Zustandsautomaten
Die Kernanforderungen bei der Erstellung der Modalitäten sind:
•
Erstellung einer graschen Oberäche mit geeigneter Menüstruktur
•
Anforderungen an die Menüstruktur:
•
Übersichtlichkeit
Geräteauswahl nach Rubriken
Implementierung einer graschen Oberäche, welche deutsche Wörter und Texte annehmen und auswerten kann
Die Zielsetzung der Programmumgebung ist etwas gröÿer und kann so zusammengefasst werden:
•
Steuerung von virtuellen Geräte (Lampen, Jalousien) eines virtuellen Hauses durch die
Modalitäten
•
Steuerung eines realen TV-Gerätes mit serieller Schnittstelle
•
Einbindung der TV-Steuerung in das virtuelle Haus
•
Steuerung des Hauses durch die Modalitäten
•
Visuelle Darstellung des virtuellen Hauses
Ferner ergeben sich zusätzliche Aufgaben, welche eine bessere Erweiterbarkeit und Funktionalität des Programms versprechen. Dazu gehören:
22
3 ANFORDERUNGSANALYSE
•
Erzeugen von Schnittstellen
•
Gute Dokumentation des Programms
•
Umstrukturierung, aufgrund der Verwaltung der Modalitäten durch den Dialogmanager
statt durch den Interaction Manager
•
Berücksichtigung von Shneidermans 8 goldenen Regeln bei der Entwicklung des Interface Designs (Benutzerschnittstellen)
3.3
Abgrenzung der Aufgabenstellung
Auf Grund des sehr begrenzten Zeitumfangs muss eine Abgrenzung der Aufgabenstellung erfolgen. Hierzu gehört die Steuerung von Geräten jenseits der Anforderungen. Auf eine spätere
Einbindung zusätzlicher Geräte wird jedoch geachtet. Auch bei den Modalitäten müssen Einschränkungen vorgenommen werden. Auf Grund von Mehrdeutigkeiten und einer Komplexität
der Sprache können nicht alle Befehle ausgewertet werden, sodass hier Probleme auftreten können. Dazu gehört auch die Verarbeitung von Zahlen. Ebenfalls werden nur Eingaben durch die
Modalitäten Chat- und Bedienfenster berücksichtigt. Geräteänderungen können nicht ausgegeben werden. Dies spielt besonders beim realen Fernsehgerät eine Rolle. Wird beispielsweise
eine Einstellung am Gerät vorgenommen wird diese nicht in den Modalitäten angezeigt. Statt
dessen wird sie bei der nächsten Aktion berücksichtigt. Gleichfalls nden Sicherheitsaspekte
und Benutzerauthentizierung bei der Umsetzung des Programms keinerlei Beachtung.
23
4 KONZEPT
4
Konzept
Dieses Kapitel beschäftigt sich mit dem erstellten Konzept unter Berücksichtigung der eben
bestimmten Anforderungen. Dabei wird nach den Rubriken Aufbau und Ablauf unterschieden.
4.1
Aufbau
Das Programm besteht aus verschiedenen Projekten, wobei zu den Projekten mehrere Klassen gehören. Eine Unterteilung in Projekte fand statt, damit eine spätere Kapselung leichter
durchgeführt werden kann. Somit können einzelne Projekte leichter ausgetauscht werden. Dazu gehört auch die Verwendung einzelner Projekte für andere Programme. Die Abbildung 7
stellt den groben Aufbau grasch dar. Dabei sind die grün markierten Areale die Projekte,
welche aus mindestens einer Klasse bestehen, obgleich nur die wichtigsten Klassen dargestellt
sind.
Figure 7: Komponentenübersicht vom Programm
Die Richtung der Pfeile weist auf die abhängigen Klassen. Folglich steuert der Dialogmanager
die Modalitäten, wie in der Anforderungsanalyse vorgegeben wurde und wird gleichzeitig vom
Interaction Manager gesteuert. Aufrufe entgegen der Pfeilrichtung werden über Events realisiert. Sowohl der Interaction-, also auch der Dialogmanager greifen auf den Context Manager
zu. Der Context Manager speichert alle Geräte und ihren Zustand. Er fungiert wie eine Daten-
24
4 KONZEPT
bank, weshalb der Zugri auf diese Klasse aus den beiden Projekten auch notwendig ist. Die
Automation Compontent beinhaltet die Methoden um die entsprechenden Geräte zu steuern
und ihren Zustand zu ändern. Sie ist also die Schnittstelle zu den realen und virtuellen Geräten (zwischen Maschine und Maschine). Die Linguistic Component ist ein Projekt, welches
mit Hilfe der Programmiersprache Prolog die Semantik, also die Bedeutung der Sprache und
Zeichen, ermittelt. Dies wird durch die Klasse SynSemComp realisiert. Anschlieÿend wird die
semantische Repräsentation des Textes durch die Klasse SyntaxProcessing ausgewertet. Das
Projekt Linguistic Component ndet nur bei einer Texteingabe Anwendung und ist wie der
Dialogmanager und die Modalitäten ein Teil der Mensch-Maschine-Interaktion. Die Steuerung
der Auswertung der Benutzereingaben wird vom Dialogmanager vollzogen. Er verwaltet ebenso die Modalitäten und steuert den Dialoguss. Das Ausgabefenster stellt die Wohnumgebung
visuell dar und wird vom Dialogmanager gesteuert.
Da der Schwerpunkt dieser Arbeit auf dem Dialogmanager basiert, soll im weiteren Verlauf
eine genaue Betrachtung dieser Komponente erfolgen.
Die Abb. 8 gibt einen Überblick über den Aufbau des Dialogmanagers.
Abbildung 8: Komponentenübersicht des Dialogmanagers
Kern dieses Projektes ist die Klasse Dialogmanager. Sie hat Zugri auf die Klasse ModalityStorage, welche alle Informationen (z. B. Namen der Modalitäten, aktuelle und bisherige
9 mit den
Zustände) zu den Modalitäten speichert. Die SCXMLFactory erzeugt eine Engine
entsprechenden Zustandsautomaten. Dafür werden die Klassen MyDispatcher und MyErrorReporter benötigt, welche nur für die Erzeugung gebraucht werden und somit im weiteren
9
Die auf java-basierende SCXML Engine abstrahiert die Schnittstellen und führt SXML-Dokumente in
Zustandsautomaten aus. URL:http://commons.apache.org/scxml/
25
4 KONZEPT
Verlauf keine Berücksichtigung mehr nden.
Der Dialogmanager basiert auf einem Zustandsautomaten, für welchen es zwei mögliche Realisierungen gibt.
Variante 1
Die Erste könnte aus vier verschiedenen Kellerautomaten bestehen, für jede
Informationsrubrik ein Automat. Wenn eine Eingabe zu einem bestimmten Bereich getätigt
wurde, wird dieses das oberste Element des entsprechenden Kellers. So kann eine UndoFunktion einfach realisiert werden, selbst wenn andere Informationen der entsprechenden Rubrik genannt wurden. Ist ein Keller leer, so wurde bisher noch keine Information eingegeben.
Nach der Ausführung eines Auftrags werden alle Keller gelöscht. Der Nachteil besteht darin,
dass man sich separat die Reihenfolge der Eingabe der Informationsrubriken merken muss.
Diesen Nachteil hat die zweite Möglichkeit nicht.
Variante 2
Hier gibt es einen Keller, welcher alle Informationen und ihre Rubriken spei-
chert. Eine Syntax könnte wie folgt Aussehen: <Informationsrubrik>:<Information>. Nachteilig wirkt sich diese Notationvariante auf den folgenden Ablauf aus. Eine Methode müsste
nach jeder Benutzung den Stack durchlaufen und die zuerst gefundenen Informationen dem
Auftrag zuordnen. Nachfolgende brauchen nicht weiter beachtet werden, da diese zuvor schon
eingegeben wurden und somit nur zur Realisierung der Undo-Funktion gespeichert werden.
Bewertung
Die geeignete Wahl wird demnach auf Grundlage der Unterstützung der Funk-
tionen und vorhandenen Bedingungen durchgeführt. Eine goldene Regel von Shneiderman
beinhaltet die Implementierung einer Undo-Funktion, mit der die letzten Eingaben widerrufen werden können. Da der Kellerautomat einen Speicher besitzt, würde dies bei der Realisierung dieser Funktion hilfreich sein. Andererseits werden dialogorientierte Zustandsautomaten
benötigt, welche mittels einer Engine gesteuert werden. Dieselbe Engine könnte auch einen
endlichen Automaten steuern, welcher sich bisherige Zustände durch eine zusätzliche Variable
merkt und so eine Benutzung der Undo-Funktion realisiert. Da der Prototyp auf dem zuletzt
geschilderten Verfahren basiert, wurde von einer Änderung des bisher verwendeten Automaten
abgesehen.
Die Modalitäten sollen leicht verständlich und anwendbar sein. Beim Chatfenster sollte die
Verwendung von Steuerelementen auf das Notwendige minimiert werden. Dazu gehört je eine
Textbox für Ein- und Ausgabe sowie einen Button zum Senden des eingegebenen Textes.
Da ein weiterer wesentlicher Aspekt die Menüsteuerung ist, sollten geeignete Steuerelemente
beim Bedienfenster ausgewählt werden. Die Entwicklungsumgebung Microsoft Visual Studio
2010 Express stellt eine Vielzahl von Steuerungselementen zu Verfügung, die in einer Toolbox
aufgelistet sind. Denkbar wäre die Verwendung einer Menüstruktur, wie man sie von Internetseiten kennt. Dieses folgt häug dem Schema eines Baumes, welches durch das TreeViewElement realisiert wird. Andererseits bieten auch Menüleisten eine Alternative. Beide Struk-
26
4 KONZEPT
turen sind allen Nutzern gut bekannt und übersichtlich. Um die Vorteile beider Strukturen
mit den Anforderungen und Ideen zu verbinden, sollten beide Menüstrukturen verwendet werden. Dabei sollte das MenuStrip Element den Benutzer zusätzliche Dienste wie Einstellungen
bieten. Das TreeView-Element wird hingegen zur Gerätenavigation (als Suche nach den geeigneten Geräten) verwendet. Zusätzliche Menüs wie ContextMenuStrip und ToolStrip würden
den Komfort erhöhen, jedoch ist dies auf Grund des geringen Zeitumfangs schwer realisierbar.
Weiterhin soll eine Einbindung weiterer Modalitäten möglich sein. Da jede Modalität auf unterschiedliche Weise Informationen sammelt, kann eine Auswertung durch den Dialogmanager
nicht einheitlich durchgeführt werden. Neue, auf jede Modalität zugeschnittene Methoden würden eine Umsetzung unübersichtlich und somit schwer steuerbar machen. Ebenfalls muss für
jeden hinzugefügten Kommunikationskanal die Verwaltung der Zustandsautomaten neu programmiert werden. Eine Lösung kann durch die Entwicklung eines Datenformats geschaen
werden. Die Grundidee hierzu ist ein einheitliches Datenformat, welches von jeder Modalität
verwendet wird. Es beinhaltet beispielsweise den Namen der aktuell verwendeten Modalität
und den Namen des zu Gerätes (siehe Abschnitt 5.1.4). Anschlieÿend wird es an den Dialogmanager übermittelt. Ausgehend von den Daten im Datenformat kann so eine einheitliche
Verarbeitung der Daten erfolgen. Es ist somit die Grundlage für eine einfache Erweiterung
durch neue Modalitäten.
4.2
Ablauf
In diesem Abschnitt sollen Überlegungen zum allgemeinen Ablauf bei der Ausführung des Programms durchgeführt werden. Ziel des Benutzers ist es, den Zustand eines Gerätes zu ändern.
Im weiteren Verlauf wird hierbei das Wort Auftrag für diesen Sachverhalt verwendet. Was
macht einen Auftrag aus? Um eine Lösung auf diese Frage zu nden, wird eine Beispieleingabe,
wie mache das Licht im Wohnzimmer an, untersucht. Daraus ersichtlich sind Informationen
zu den Rubriken Ort, Aktion und Gerät. Auf das Gerät kann durch die Verwendung des Wortes Licht geschlossen werden. Häug trit eine Aussage auf mehrere Geräte zu, sodass eine
Einschränkung vorgenommen werden muss. Dies erreicht man durch eine zusätzliche Information wie Deckenlicht. Somit ergeben sich die nachstehenden Rubriken als Kennziern für
Aufträge: Name, Ort, Information und Aktion.
An dieser Stelle sei nochmal auf das Ziel eines Auftrags eingegangen. Ein Gerät gehört zu einer
Geräteklasse. Geräteklassen sind dadurch kennzeichnet, dass sie Geräte mit gleichen Merkmalen umfassen. Jeder Geräteklasse wird ein Zustandsautomat zugeordnet, welcher mögliche Aktionen bestimmt. Das Ziel einer Benutzereingabe ist die Veränderung einer Einstellung beim
Gerät und wird durch eine Zustandsänderung des dazugehörigen Automaten erreicht. Zur
Verarbeitung des Auftrags gehört ebenfalls die Steuerung des Dialogusses durch einen vom
27
4 KONZEPT
Dialogmanager gesteuerten Zustandsautomaten. Die Verwaltung der jeweiligen Gerätezustände erfolgt im Context Manager. Zustandsautomaten sind für die Modellierung von möglichen
Aktionen gut geeignet, aber schon eine einfache Lampe mit Dimmfunktion würde bei der
Erstellung groÿe Probleme erzeugen. Laut dem grundlegenden Gedanken müsste je Gerätezustand ein Zustand in der SCXML-Datei modelliert werden. Daraus ergibt sich eine Vielzahl von
Zuständen. Um den Nachteil bei der Verwendung von Zustandsautomaten zur Modellierung
von möglichen Aktionen zu reduzieren, werden dialogorientierte Zustandsautomaten erzeugt.
Sie fassen eine Gruppe von Zuständen zusammen und unterstützen so die Modellierung des
Dialogusses. Im Kapitel 5.1.1 wird dieses anhand eines Beispiels genauer erläutert.
Jeder Durchlauf beginnt mit einer Benutzereingabe, auf welcher basierend eine Variable vom
entsprechenden Datenformat erstellt und mit Daten gefüllt wird. Die Daten enthalten Informationen zu den eben bestimmten Rubriken, sowie Möglichkeiten zur Navigation. Bei einer
Eingabe über das Chatfenster muss die Linguistic Component eine Zuordnung zu den Kategorien vornehmen. Im Anschluss befasst sich der Dialogmanager mit dem Daten. Dazu werden
Informationen wie der aktuelle Status und bisherige Eingaben geladen. Danach werden die
Informationen verarbeitet, wobei eine Zustandsänderung ausgelöst werden kann. Dies hängt
von den Eingaben ab. Werden nur Informationsrubriken verändert, erfolgt keine Zustandsänderung. Daraufhin erfolgt eine Überprüfung der bisherigen Informationen. Wurde ein Auftrag
vollständig eingegeben, so hat dieser bei erfolgreicher Ausführung eine Änderung am Gerät zur
Folge. Fehlen Informationen, so versucht der Context Manager sie zu erschlieÿen. Je nachdem
wird die entsprechende Ausgabe ermittelt. Diese richtet sich nach der vom Benutzer verwendeten Modalität. Die Abbildung 9 verdeutlicht grasch den eben geschilderten Sachverhalt in
Form eines UML-Sequenzdiagramms.
28
4 KONZEPT
Abbildung 9: Sequenzdiagramm - Benutzereingabe (unvollständiger Auftrag)
Der Ablauf verläuft ähnlich, wenn der Benutzer eine Eingabe über das Bedienfenster tätigt.
Eine Variable vom Datenformat wird mit den ermittelten Daten erstellt und an den Dialogmanager weitergeleitet. Es folgt die gleiche weitere Abarbeitung, wie vorstehend bereits
beschrieben. Eine Benutzung der Klasse Linguistic Component ist bei einer Eingabe durch
das Bedienfenster nicht notwendig.
Die Synchronität der Modalitäten soll durch die Verwaltungsklasse ModalityStorage erfolgen.
Diese, vom Dialogmanager verwaltete Klasse, beinhaltet alle Information zu den verwendeten
Modalitäten. Sie ist auch für das Setzen neuer Zustände zuständig. Wenn die Modalitäten
synchron agieren sollen, müssen die Informationen für jede Modalität gespeichert werden.
Im Abschnitt 5.1.2. wird die Umsetzung des Setzens von Zuständen für synchron handelnde
Modalitäten näher erläutert.
29
5 IMPLEMENTIERUNG
5
Implementierung
Dieses Kapitel befasst sich mit der Umsetzung des Programms. Dazu wird das Kapitel in Teile
gegliedert. Angefangen bei den Ideen der Implementierung der Zustandsautomaten, über die
Programmierung der Modalitäten bis zur Fertigstellung des Prototyps. Im Zuge dessen wird
ein exemplarischer Durchlauf die Funktionalität aufzeigen, welche anschlieÿend bewertet wird.
Die Programmierung wurde in den Sprachen C# und SCXML durchgeführt. Verwendet wurde
Microsoft Visual C# 2010 Express.
5.1
Umsetzung
Die Erstellung der Zustandsautomaten und Überlegungen zu den Modalitäten stehen bei der
Umsetzung im Vordergrund. Ferner wird auf Probleme im Bereich der Entwicklungsumgebung
eingegangen.
5.1.1 Zustandsautomaten
Es nden zwei Arten von Zustandsautomaten im Dialogmanager Verwendung. Wie im Abschnitt 4.2 erwähnt, wird für jede Geräteklasse ein dialogorientierter Zustandsautomat benötigt. Auÿerdem agiert der Dialogmanager nach einem Automat. Hier ergab sich das Problem,
den geeigneten Automaten zu nden, welcher sowohl die Abarbeitung der Auftragsstruktur,
als auch gleichzeitig grundlegende Funktionen von Dialogsystemen unterstützt. In dem Programm, welches dieser Arbeit zu Grunde liegt, wurde ein endlicher Zustandsautomat mittels
der Engine Commons SCXML erstellt. Sie wurde von The Apache Software Foundation erschaen und stellt eine API für SCXML bereit. Eine Übersicht über die bestehenden Packages
kann unter [The] gefunden werden.
Eine Umsetzung erfolgte mittels scxmlgui
10 . Dieser auf Java basierende Editor eignet sich gut
zur graschen Darstellung einfacher SCXML-Dateien, jedoch können bei der Umwandlung
Fehler auftreten. So empehlt sich eine weitere Vorgehensweise mit einem Standardeditor,
welcher XML-Tags farblich hervor heben kann. Eine vereinfachte grasche Darstellung, siehe
Abb. 10, soll das Grundkonzept der Funktionsweise des Dialogmanagers wiedergeben.
Der endliche Zustandsautomat kann wie folgt deniert werden, wobei nur ein Teil der Überführungsfunktion aus Übersichtlichkeitsgründen dargestellt ist.
M = (Z, V, δ, qM , F ).
Dabei können die einzelnen Variablen folgenderweise deniert werden:
Z = {chooseApplication{Initial, AcAp, AcIn, ApIn, AcLo, Run, History, ...}, Ask, F inal}
V = {enterApplication, enterLocation, enterInf ormation, renew, stopStatemachine, ...}
δ = {(Initial, enterAction) → Ac, (Initial, enterApplication) → Ap, ...}
qM = Initial
F = {F inal}
10
Editor für endliche Zustandsautomaten
http://code.google.com/p/scxmlgui/
basierend
auf
SCXML
von
F.
Morbini;
URL:
30
5 IMPLEMENTIERUNG
Abbildung 10: Dialogmanager - vereinfachter Zustandsautomat
Beginnend vom Initial-Zustand werden Eingaben des Benutzers einer der vier Rubriken zugeordnet. Darauf basierend erfolgt ein Zustandswechsel. Der Name des Zustandes ergibt dabei
die bisher erhaltenen Informationen entsprechend den Rubriken. ApLo beispielsweise bedeutet, dass bisher Informationen zum Namen des Gerätes (Application) und dem Ort (Location)
getätigt wurden. Ein Auftrag kann ausgeführt werden, wenn Eingaben zu allen Bereichen getätigt wurden. Eine Ausnahme bildet die Kategorie Information. Sie ist optional. Wenn der
Benutzer keine konkreten Anforderungen stellt, wird ein beliebiges Gerät genommen. Ein Beispiel wäre mache das Licht im Wohnzimmer an. Das System erkennt als Name Lampe, als
Ort Wohnzimmer und als Aktion anmachen. Eine Zusatzinformation zum Gerät ist nicht
ersichtlich. Die Eingabe ohne Zusatzinformation ist sinnvoll bei einmalig vorkommenden Geräten, welche keine Zusatzinformationen brauchen, oder in bestimmten Situationen. Betritt
beispielsweise der Wohnungsbesitzer ein dunkles Wohnzimmer und hat Probleme, den Weg zu
erkennen, so würde die Eingabe aus dem obigen Beispiel sinnvoll erscheinen.
Der Zustand ApLoInAc beinhaltet Informationen zu allen Informationsrubriken. Wird dieser
31
5 IMPLEMENTIERUNG
Zustand erreicht, wechselt der Automat automatisch in den Zustand Run und führt die
gleichnamige Methode aus. Nach deren Ausführung begibt sich der Automat in den InitialZustand.
Eine weitere Überlegung liegt der Erstellung des Dialogmanagers zu Grunde: das Eingeben
einer nicht direkt ausführbaren Aktion. Das erstellte Programm unterstützt das Springen von
Zuständen in Zustandsautomaten nicht. Ein Beispiel soll diesen Sachverhalt genauer erläutern. Der Nutzer möchte einen Film schauen. Das dazugehörige TV-Gerät ist aus. Kommt
nun die Eingabe spiele das 1. Kapitel ab tritt ein Fehler auf. Die Eingabe kann nicht verarbeitet werden und wird gelöscht, da das Gerät dafür erst angeschaltet und anschlieÿend ein
Film gewählt werden muss. Eine Lösung erlaubt dem Benutzer nur nach einer Geräte-Auswahl
Aktionen einzugeben. Ist der Vorgang gültig, ndet eine Zustandsänderung statt. Das eben geschilderte Beispiel würde nach diesem Sachverhalt wie folgt ablaufen: Der Benutzer macht eine
Eingabe, welche zur Folge hat, dass das TV-Gerät angeschaltet wird. Anschlieÿend erfolgt eine
Eingabe, wie spiele einen Film ab. Hier wird vorausgesetzt, dass das System zufällig einen
Film auswählt und diesen abspielt. Sein Ziel kann der Anwender durch die Eingabe starte 1.
Kapitel erreichen. Das Fernsehgerät wird bei allen zukünftigen Eingaben als Maschine vorausgesetzt, bis eine neue Information in den Rubriken Name, Ort oder Information eingegeben
wird.
Ein erfolgreicher Prototyp sollte dem Haushalt Tag und Nacht, 365 Tage im Jahr zur Verfügung stehen. In dem Zeitraum werden viele Eingaben getätigt, wobei eine Speicherung von
allen Aufträgen nicht sinnvoll erscheint. Im Rahmen der Implementierung der Undo-Funktion
muss somit eine geeignete Richtlinie gefunden werden. Auf Grund von Shneidermans 8. Regel
(Verringere Abfragen an das Kurzzeitgedächtnis) werden nur Informationen zu einem Auftrag
gespeichert, mit dem Ziel Versprecher leicht korrigieren zu können. Da ein endlicher Zustandsautomat zur Dialogführung verwendet wird, werden die letzten Zustände in einem Stack gespeichert. Dieser wird durch eine lokale Variable realisiert. Zustände werden gespeichert, wobei
beim Erreichen des Initial-Zustands der Stack gelöscht wird. Das Anfangskellerzeichen ist Initial, welcher die ID des Initial-Zustands darstellt. Somit kann die Undo-Funktion nur für den
aktuellen und nicht auf die vorherigen Aufträge angewendet werden.
Die Umsetzung der Undo-Funktion hat den Nachteil, dass die Menüstruktur komplizierter
wird. Statt einer azyklischen
11 wird nun eine zyklische12 Menüstruktur verwendet. Dies macht
es für den Nutzer schwerer, den Überblick über den aktuellen Zustand zu behalten. [Shn02, S.
286] Daher wurde im Bereich der Modalitäten eine Erweiterung vorgenommen. Die Informationen zum aktuellen Auftrag werden in einer Tabelle im Bedienfenster ausgegeben.
11
12
gerichteter Graph mit Mehrfachkanten bei dem sich alle Knoten eines Weges unterscheiden
gerichteter Graph mit Mehrfachkanten, bei dem Start- und Endpunkt übereinstimmen
32
5 IMPLEMENTIERUNG
Nachdem der verwendete Automat für den Dialogmanager erläutert wurde, soll hier eine kurze
Erläuterung der dialogorientierten Zustandsautomaten am Beispiel des Zustandsautomaten für
das Fernsehgerät gegeben werden.
Abbildung 11: Dialogorientierter Zustandsautomat für ein TV-Gerät
Der Zustandsautomat von Abbildung 11 orientiert sich an den realen Fernsehapparat und
13 realisiert. Der
seinen Funktionen. Die grasche Darstellung wurde mit dem SCXML-Editor
Abschnitt 5.1.3 beschäftigt sich intensiver mit der Verbindung zu dem Gerät. Es werden eine
Reihe von Funktionen unterstützt. Dazu gehören u. A. die in Abb. 11 aufgelisteten Ereignisse.
Der Fernseher bietet die Möglichkeit zwischen mehreren Kanälen umzuschalten. Leider gibt
es keinen Befehl, welcher den Fernseher an macht. Darum ist der Initial-Zustand menuDTV.
Anwender benutzen häug Befehle wie Kanalwechsel, Lautstärkewechsel und Videotext. Daher standen diese Anweisungen im Mittelpunkt bei der Implementierung. Eine Veränderung
der Lautstärke ist auch von anderen Kanälen aus möglich. Dies lässt sich durch einen neuen
Zustand setVolume realisieren. In diesem kann die Lautstärke variiert werden. Nach dem Beenden der Lautstärkeänderung durch das Ereignis setVolumeReady wird der History-Zustand
erreicht. Dieser wechselt in den letzten Zustand, bevor setVolume erreicht wurde. Ist kein
Übergang möglich, wird nach menuDTV gewechselt. Abb. 11 verdeutlicht sehr gut, dass ein
History-Zustand hier nicht notwendig wäre, da setVolume nur von einem Zustand aus er-
13
Der Editor von F. Morbini kann gefunden werden unter: http://code.google.com/p/scxmlgui/
33
5 IMPLEMENTIERUNG
reicht werden kann. Dennoch bietet der History-Zustand die Möglichkeit leicht Erweiterungen
z. B. durch andere Kanäle durchzuführen, welche für den Prototyp nicht realisiert wurden.
5.1.2 Modalitäten
Im Bereich der Modalitäten waren zwei Oberächen zu erstellen, welche Benutzereingaben
annehmen können: ein Chatfenster und ein Bedienfenster.
Das vorhandene Chatfenster erfüllte alle an ihn (im Abschnitt 3.2) gestellten Anforderungen,
sodass es aus der vorausgehenden Arbeit übernommen werden konnte.
Problematisch gestaltete sich die Implementierung des Bedienfensters. Auf Grund der veränderten Anforderungen und Ideen an die Modalität, musste eine Neuimplementation vorgenommen werden, immer vor dem Hintergrund von Shneidermans 8 goldenen Regeln. Eine Regel
beinhaltet den Kontrollaspekt durch den Benutzer. Einstellungen und zusätzliche Funktionen
sollen dem Anwender das Gefühl der Kontrolle geben und so seine Zufriedenheit steigern.
Andererseits hat dies zur Folge, dass die Oberäche trotz vieler Bemühungen unübersichtlich
werden kann. Um dem entgegenzuwirken, wurde in der Menüleiste ein Informationspunkt hinzugefügt. Dieser soll dem Anwender Auskunft über die wichtigsten Kenntnisse zur Bedienung
des Programms vermitteln sowie die Möglichkeiten und Bedeutungen einzelner Eingaben im
Programm erklären.
Im Vordergrund steht nach wie vor die Selektion von Geräten und Veränderung ihres Zustands.
Dafür stehen zwei Möglichkeiten zur Verfügung: eine Tabelle und eine Baumstruktur, welche
in Abbildung 12 dargestellt sind. Die Tabelle gibt wie eine Datenbank alle Geräte aus, welche leicht selektiert werden können. Anschlieÿend kann in einer neuen Tabelle ein möglicher
Zustand ausgewählt werden. Diese Eingabevariante ist für zielgerichtete Benutzer geeignet,
welche auf direktem Weg eine Applikation auswählen können. Die Bedienung der Baumstruktur ist besser geeignet für unentschlossene Nutzer und groÿe Datenbanken, d. h. bei vielen zu
verwaltenden Geräten im Context Manager wird die Tabelle als einzige Anzeigemöglichkeit
unübersichtlich, da die Tabelle ihr Daten vom Context Manager erhält. Die Baumstruktur
ermöglicht eine Auswahl der Geräte, wodurch die Anzahl der angezeigten Geräte sinkt und
demzufolge die Übersichtlichkeit steigt. Die Baumstruktur wird dynamisch generiert. Durch
Auswahl eines Knotens werden alle möglichen Geräte angezeigt. Selektiert man ein Gerät, werden alle noch oenen Informationsrubriken dargestellt, welche durch einen Mausklick wiederum
alle Auswahlmöglichkeiten für die Gerätewahl unter Berücksichtigung der bisher eingegebenen
Informationen anzeigen. Dies wird solange fortgeführt, bis alle Informationen ausgewählt wurden. Diese Variante benötigt bei einer normalen Eingabe, ohne zusätzliche Informationen,
mind. sechs Selektionen.
Um die Vorteile beider Möglichkeiten zu verbinden, gibt es eine gemischte Ansicht. Dabei
können Eingrenzungen zu Themenbereichen durch die Baumstruktur vorgenommen werden.
Daraufhin aktualisiert sich die Tabelle. Besonders ezient gestaltet sich dadurch die Geräte-
34
5 IMPLEMENTIERUNG
Abbildung 12: Bedienfenster
auswahl bei einer groÿen Anzahl an Geräten im Haushalt.
Des Weiteren können die Modalitäten synchron agieren, dass heiÿt, sie arbeiten parallel. Eine
Eingabe in einer Modalität beeinusst auch den Status der Anderen. Dies wird über eine Variable in der Klasse ModalityStorage realisiert. Gibt diese zurück, dass die Modalitäten synchron
agieren sollen, wird eine Methode aufgerufen. Diese ruft die Methode mit dem gleichen Namen
auf, welche als Übergabeparameter nicht den Namen der Modalität benötigt (Überladung).
Anschlieÿend wird hier für jede verwaltete Modalität die Information gespeichert. So kann die
Synchronität leicht über eine Variable gesteuert werden.
5.1.3 Programmumgebung
Die Zielsetzung beinhaltet die Steuerung eines realen TV-Gerätes
14 . Für die Bedienung stand
ein Projekt zur Verfügung, basierend auf der Klasse SerialPort. Die Klasse stellt eine Verbindung zwischen dem Dialogsystem und einem realen Gerät her. Nach den Einstellungen der
Kommunikationsbedingungen, wie Baud-Rate und Datenlänge, erfolgt die Steuerung über ein
überkreuztes RS-232C-Kabel. Bei einer Aktion erfolgt eine Abfrage an das Gerät bezüglich
des aktuellen Werts und ermöglicht so das Senden und Empfangen von Daten.
14
Typ AQUOS von Sharp mit der Kennung LC-52XD1E
35
5 IMPLEMENTIERUNG
Probleme ergaben sich bei der Erstellung der dritten Oberäche auf Grund der hohen Anforderungen. Die Oberäche soll Geräte darstellen, die Änderungen durch Animationen verdeutlichen und mit allen Plattformen kompatibel sein. Das standardisierte Dateiformat X3D
15
erfüllt alle Bedingungen. Durch ein Plug-In können Browser die Dateien anzeigen. Mit Hilfe der Software Sweet Home 3D wurde ein Haus grasch erstellt. SweetHome3D verfügt
über keine Export-Funktion in das Dateiformat X3D, sodass eine andere Software diesen Part
übernehmen muss. Die Engine Blender erwies sich als sehr kompatibel. Da aber die erstellte
X3D-Datei aus nicht nachvollziehbaren Gründen fehlerhaft war, wurde von einer graschen
3D-Darstellung der Wohnumgebung Abstand genommen wurde. Alternativ wurde nach einem Standard für 2D-Darstellungen recherchiert, wie das vom W3C standardisierte Format
.svg. Die Abkürzung SVG bedeutet Scalable Vector Graphics. So wie X3D basiert SVG
auf XML. Animationen sind mit Hilfe von SMIL möglich. SMIL steht für Synchronized
Multimedia Integration Language und ist ein W3C-Standard für interaktive audiovisuelle
Präsentationen.[Mic]
Eine SVG-Datei wurde mittels dem Open-Source-Vektorgrakeditor Inkscape erstellt. Animationen werden durch den Tag <animateColor> realisiert. In der selben Klasse gibt es einen
Tag namens <set>. Mit diesem lassen sich unter anderem Farben setzen. Beide Varianten
wurden in das Dokument eingebunden mit dem nachfolgenden Ergebnis: Die SVG-Datei lieÿ
sich ohne Probleme von jedem Browser önen, jedoch wurden sowohl die Animationen als auch
die Darstellung von jedem Browser anders unterstützt. Die Tabelle 3 gibt einen Überblick über
die Unterstützung beim Anzeigen von SVG-Dateien. Dabei bedeutet ein Plus-Zeichen, dass
dieser Bereich unterstützt wird, hingegen ein Minus-Zeichen für auftretende Probleme steht.
Browser
gute Darstellung
<animateColor>
<set>
Internet Explorer 9
-
-
-
Mozilla Firefox 5.0
+
-
+
Safari 5.0.5
-
+
+
Tabelle 3: Unterstützung einiger Browser beim Anzeigen von SVG-Dateien
Auf Grundlage der Ergebnisse wurde Mozilla Firefox zur weiteren Darstellung der SVG-Datei
verwendet.
Nach dem Starten des Prozesses Mozilla Firefox trat das Problem auf, dass eine Verwaltung des Prozesses nicht mehr möglich war. Der Prozess konnte gestartet werden, aber wurde
dann automatisch vom Betriebssystem verwaltet und im Programm beendet. Dies hatte zur
Folge, dass die SVG-Datei nicht mehr vom Programm geladen werden konnte. Abhilfe wurde
durch das Steuerungstool WebBrowser geschaen. Die Klasse ermöglicht die Verwaltung eines programm-internen Browserfensters. Beim Laden gab es ein Problem mit dem Standard
16 , welche für den Inter-
WebBrowser, auf Trident basierend. Trident ist eine Rendering Engine
15
Extensible 3D, ozieller Standard für 3D-Dateiformate auf XML-basierend; URL:
http://www.leed.ch/history/x3d/zweck.htm
16
Komponente eines Programms zur Aufbereitung von Informationen um diese darstellen zu können
36
5 IMPLEMENTIERUNG
net Explorer verwendet wird. Wie auch bei der Darstellung mit dem Internet Explorer wurden
keine Animationen unterstützt. Daraufhin wurden weitere Rendering Engines getestet.
Rendering Engine
Browser
gute Darstellung
<animateColor>
<set>
Trident
Internet Explorer
+
-
-
Gecko
Mozilla Firefox
+
-
-
WebKit
Safari
-
-
-
Tabelle 4: Unterstützung einiger Rendering Engines beim Anzeigen von SVG-Dateien
Wie die Tabelle 4 verdeutlicht, unterstützen alle getesteten Engines keine Animationen. Dies
beinhaltet auch das Setzen der Farbe durch den Tag <set>. Lediglich die Darstellung der
graschen Form wurde bei zwei der drei Engines gut unterstützt. Somit wurde für die weitere
Arbeit ein GeckoWebBrowser verwendet. Das ist ein Steuerungstool, welches durch Seiten
navigieren kann. Der Browser Mozilla Firefox basiert auf dieser Rendering Engine. Trotzdem
sind viele Unterschiede zwischen den Tabellen 3 und 4 zu erkennen. Der Grund ist, dass
Rendering Engines nur einfache WebBrowser erzeugen, welche vom Benutzer verwaltet werden
können. Hingegen unterstützen Browser, wie Mozilla Firefox, mehr Darstellungsformen als
durch Rendering Engines erstellte WebBrowser.
Um eine Farbänderung der entsprechenden Geräte zu erzeugen, wurde beim ersten Lesen der
SVG-Datei eine Datenbank angelegt, welche die zu verändernde Zeilennummer sowie das dazugehörige Gerät speichert. Bei einer Änderung wird die entsprechende Zeile neu geschrieben.
Dabei wird das ganze Dokument gelesen, verändert und gespeichert. Um beim zweiten Starten des Programmes alle Geräte in der Ausgangssituation vorzunden, wird eine Kopie der
ursprünglichen Datei erzeugt, mit welcher im Anschluss weiter gearbeitet wird. Eine Bewertung der gefundenen Lösung erfolgt im Kapitel 5.2.
5.1.4 Prototyp
In diesem Abschnitt soll ein exemplarischer Durchlauf erfolgen. Dabei werden angesprochene
Themen wie Eventhandling und das denierte Datenformat aufgegrien und erläutert.
Beim Start des Programms önet sich ein Startfenster. In diesem kann die Hausdatei ausgewählt werden. Hinter dem Begri verbirgt sich die SVG-Datei. Eine Auswahl ist sinnvoll, da
die Geräte in der Datenbank von den Geräten in der SVG-Datei abstammen. Die Gerätedatenbank wird also dynamisch erzeugt. So kann der Benutzer seine Wohnumgebung modellieren
und virtuell verwalten. Die Funktionsweise des Dialogmanagers orientiert sich an einem Zustandsautomaten, welcher ausgewählt werden kann. Dabei sind beide in den Tests benutzten
Dateien voreingestellt. Das Startfenster verändert sich nach dem Laden der Haus-Datei zu einem Fenster für Fehlerausgaben. Es gibt Fehler als auch Zwischenstände aus, um auftretende
Probleme schnell lokalisieren und beheben zu können.
37
5 IMPLEMENTIERUNG
Abbildung 13: Ablauf des Programms
38
5 IMPLEMENTIERUNG
Die Abbildung 13 zeigt den Ablauf des Programmes, basierend auf einer Eingabe. Dieser
Verlauf wird im Anschluss an einigen Stellen erläutert.
Der Dialogmanager empfängt Eingaben des Chatfensters. Die Linguistic Component wandelt
den String um. Dazu wird ein auf Prolog-basierendes Projekt verwendet. Das semantische
Analyseresultat wird in der Klasse SyntaxProcessing ausgewertet. Gleichwohl werden Eingaben unterstützt, welche mehrere Aufträge beinhalten, wie beispielsweise mache alle Lampen
an. Diese Eingabe wird anhand des Schlüsselwortes alle besonders behandelt. Dasselbe gilt
für die Wörter Zustand und home. Auch Navigationsbegrie wie synchronisieren und
löschen werden betrachtet. Davon ausgehend wird eine Variable vom Datenformat erstellt,
wobei die Deklarierung der Variablen in der Abb. 14 zu sehen ist.
Abbildung 14: Denition des Structs DataFormat
Eine Auswertung der Daten erfolgt im Dialogmanager. Dabei werden Informationen entsprechend ihrer Rubrik gefeuert. Das beinhaltet die Auslösung eines Events im jeweiligen Zustandsautomaten, welcher durch die Variable modality bestimmt wird. Sie ruft alle Werte in
ModalityStorage zu dieser Modalität ab.
Möglich wäre eine Eingabe, welche eine spezielle Geräteinformation und eine Aktion beinhaltet. Basierend auf dieser Information, kann häug auf ein bestimmtes Gerät geschlossen
werden, ohne dass zusätzliche Informationen erforderlich sind. Dies ist möglich, wenn es nur
ein Gerät mit einer bestimmten Zusatzinformation gibt. Beim Testen wurde dieses Gerät
durch die Stehlampe realisiert. Die Methode logic() im Context Manager ermittelt alle möglichen Geräte, welche mit dem aktuellen Informationsstand möglich sind. Gibt es, wie bei der
Stehlampe, nur ein Gerät, werden alle oenen Informationsrubriken ausgefüllt und an den
Dialogmanager gesendet. Dieser kann nun den Auftrag ausführen. Dafür wird der Zustandsautomat der Geräteklasse geladen. Dieses erfolgt durch das Erzeugen einer neuen Instanz von
der Klasse SCXMLFactory. Um die Speicherausnutzung zu reduzieren, existieren zur gleichen
Zeit nur zwei Variablen der Klasse: eine steuert den Dialogmanager und die Andere das Gerät. Selbst für die Modalitäten wird nur ein Zustandsautomat verwendet, hierbei muss der
39
5 IMPLEMENTIERUNG
Zustand gespeichert und im Automat gesetzt werden. Von einer zweiten Variante, welche das
Erzeugen von je einem Zustandsautomat je Gerät beinhaltet, wurde, auf Grund des hohen
Speicherbedarfs bei sehr vielen Geräten, Abstand genommen.
Ein weiterer Aspekt ist die Speicherung der Daten. Die Automation Component führt Aufträge an den Geräten aus. Bei den virtuellen Geräten kann dies immer durchgeführt werden.
Probleme können nicht auftreten, da die virtuellen Geräte keine Fehlerrückmeldungen machen
können. Beim Fernsehgerät erzeugen ungültige Eingaben einen Fehler, welche keine Veränderung des Zustands des TVs auslösen darf. Deshalb erzeugt die Automation Component einen
Befehl. Kann dieser erfolgreich ausgeführt werden, wird ein Event an den Interaction Manager
geschickt. Dieser reicht die erfolgreiche Ausführung an den Dialogmanager weiter, welcher im
Context Manager den Zustand verändert und die Ausgabe auf dem Ausgabefenster in Auftrag
gibt. Kann hingegen der Auftrag nicht erfolgreich ausgeführt werden, erfolgt die Löschung des
Auftrags und eine Fehlerausgabe ohne weitere Konsequenzen.
5.2
Diskussion
In dem aktuellen Abschnitt wird eine Bewertung des Prototyps auf Grund der Zielsetzung
vorgenommen.
Durch die Umstrukturierung konnte der Quellcode etwa um ein Drittel reduziert werden. Der
Dialogmanager steuert nun den Dialoguss und die Modalitäten. Der Status der Modalitäten
wird in der Klasse ModalityStorage gespeichert. Über den Dialogmanager ist ein Setzen der
Zustände möglich. Gleichzeitig ist es auch notwendig, da nur ein Zustandsautomat für alle
Modalitäten verwendet wird. Dies ergibt sich aus der Notwendigkeit, dass die Modalitäten
synchronisiert werden können. Dazu muss ebenfalls der Zustand abgefragt und im Anschluss
neu gesetzt werden. Die Anbindung neuer Kommunikationskanäle ist durch den Aufruf einer
Methode leicht durchführbar. Diese benötigt nur den Namen der Modalität zur Erzeugung
eines Eintrags in der Klasse ModalityStorage, da die Steuerung über den Namen ausgeführt
wird. Denkbar wäre eine ID zu vergeben um gleiche Namen und Schreibfehler auszuschlieÿen.
Grundlegende dialogorientierte Zustandsautomaten wurden erstellt, wobei hier einige Überarbeitungen notwendig sind. Um eine Verarbeitung zu erleichtern, wurde der Zustandsautomat
der Jalousie funktionsorientiert erstellt. Dies hat den Hintergrund, dass ein dialogorientierter
Zustandsautomat ständig Informationen vom Context Manager benötigt. Die Lampe hingegen
benötigt aufgrund ihres übersichtlichen Zustandsautomaten, welcher lediglich drei Zustände
hat, keine weiteren Daten zur Ausführung. Die Automation Component ermittelt die Daten
des Fernsehgeräts vor einer Aktion und erfasst so den aktuellen Zustand des Gerätes. Sodass
bei der aktuellen Version des Programms lediglich die Jalousiedaten, wie Winkel der Lamellen,
vom Context Manager benötigt werden. Eine Erweiterung des Programms wäre zur Benutzung
komplexer Geräte sinnvoll.
40
5 IMPLEMENTIERUNG
Das Ausgabefenster unterscheidet für jedes Gerät die beiden Zustände: an und aus. Bei dialogorientierten Zustandsautomaten kann dies nicht direkt festgestellt werden. Die Eingaben
müssten in Verbindung mit den im Context Manager gespeicherten Geräteeinstellungen verbunden und ausgewertet werden. Darauf basierend könnte eine Aktion durchgeführt werden,
welche nach erfolgreichem Ausführen im Context Manager gespeichert wird. Eine Erweiterung
des Context Managers würde folglich notwendig sein. Dieser Teil wurde bisher nicht realisiert.
Daher ist der Zustandsautomat für das TV-Gerät dialogorientiert und für die Jalousie funktionsorientiert. Nichtsdestoweniger wurde ein einfacher dialogorientierter Zustandsautomat für
Jalousien erstellt und ist im Anhang dargestellt.1
Die Anforderungen an die Modalitäten sind grundlegend erfüllt. Wie vermutet, können auf
Grund der Komplexität der Sprache nicht alle Wörter ausgewertet werden. Eine Erweiterung
der vorhandenen Prolog-Datei, zur Bestimmung der Semantik, sowie eine komplexere Klasse
zur Auswertung der Semantik wäre sinnvoll. Dennoch sind einfache Eingaben möglich. Diskussionswürdig ist die Variante, die Linguistic Component vom Dialogmanager aufzurufen. Derzeit
wird die entsprechende Variable vom Datenformat im Dialogmanager erzeugt. Besser wäre die
Reihenfolge: Chatfenster, Linguistic Component und Dialogmanager, wobei der Dialogmanager die Daten von der Linguistic Component erhält. Jedoch lieÿ es sich nicht realisieren, da zur
Bestimmung der Aufträge der Context Manager genutzt werden musste, welcher alle Geräte
verwaltet. Beim Beispiel mache alle Lampen an müssen alle Lampen vom Context Manager ermittelt werden. Anschlieÿend wird für jedes Gerät eine Instanz vom Typ Datenformat
erstellt und dem Dialogmanager zur Auswertung übergeben. Ungeachtet dessen können Eingaben über das Bedienfenster getätigt werden. Die Bedienbarkeit wird durch einen Hilfetext
erhöht. Tests mit der Benutzung der Baumstruktur lieferten unterschiedliche Werte. Einerseits
haben Benutzer, welche einen Weg bis zum vollendeten Auftrag entlanggehen, keine Probleme. Anderseits führt das sprunghafte Selektieren verschiedener Knoten über mehrere Ebenen
zu ungewollten Eingaben und Fehlern. Vor allem durch die dynamische Baumstruktur und
der verbundenen Tabelle ist eine gute Übersicht und Rubrik-orientierte Gerätewahl gegeben.
Eine Überarbeitung sollte die Änderung der Bedienfenster-Klasse auf eine browserbasierende
Modalität beinhalten, um die Nutzung der Eingabemöglichkeit u. a. auf Handys zu erweitern.
Zur Bewertung der Gestaltung werden die 8 goldenen Regeln von Shneiderman herangezogen.
Die Tabelle 5 gibt einen Überblick über die Maÿnahmen, welche zur Einhaltung der Regeln
vorgenommen wurden.
Die Zielsetzung der Programmumgebung konnte erfüllt werden. Durch die zahlreichen Lampen und Jalousien wurden Geräte mit dem virtuellen Haus verknüpft. Auch die Steuerung
des TV-Gerätes kann durch Nutzereingaben durchgeführt werden. Die Darstellung des Hauses konnte durch einen GeckoWebBrowser realisiert werden. Der Vorteil dieser Lösung ist
sicherlich die Verwendung unabhängig von Plattformen. Auÿerdem kann, unter bestimmten
41
5 IMPLEMENTIERUNG
Voraussetzungen, jedes Haus geladen und verwaltet werden. Nachteilig auswirken kann sich die
lange Ladezeit. Derzeit wird nach einem erfolgreich ausgeführten Auftrag eine Aktualisierung
vorgenommen. Sinnvoll wäre es, das Ausgabefenster durch Events zu steuern. Dazu sollte der
Context Manager genutzt werden. Eine mögliche Variante wäre folgende:
Wird der Zustand eines Gerätes verändert, so erfolgt eine Speicherung im Context Manager.
Dieser ermittelt nun, ob eine Farbänderung im Ausgabefenster vorgenommen werden soll. Bei
Sammelaufträgen, wie dem Anschalten aller Lampen, würde derzeit jede Lampe einzeln angeschaltet werden. Dies hat zu Folge, dass die Datei für n Lampen n-mal eingelesen, bearbeitet
und neu gespeichert werden muss. Da dies ungefähr drei Sekunden pro Lampe in Anspruch
nimmt, ist es bei vielen Lampen problematisch. Benutzereingaben während dieser Zeit können
zu Fehlern führen. Daher sollte dieser Aspekt bei der Idee, durch das Sammeln aller Aufträge,
berücksichtigt werden.
Generell sollte bei einer weiteren Bearbeitung dieses Projektes der Aspekt der Störungen,
insbesondere der Ausfallsicherheit, geachtet werden.
42
5 IMPLEMENTIERUNG
Regel
Umsetzung (Bedienfenster; Chatfenster, Allgemein)
Konsistenz
Einheitliche Beschriftung der Buttons; - ; -
Berücksichtige
Hilfedatei zur Einführung, 3 Varianten zur Ermittlung eines
unterschiedliche
Gerätes; Enter zum Senden von Texteingaben; -
Erfahrungen
Rückmeldungen auf
Anzeigen des bisher ausgewählten Informationen, Generierung
Aktionen des Benutzers
der Datenbank; Ausgabe fehlender und vorhandener
Informationen; Fehlermeldungen im extra Fenster
Abgeschlossene
leere Informationsrubriken; Rückmeldung über den Erfolg,
Operationen
Nachfragen verdeutlicht fehlende Aktionen/Informationen;
Klärung des Ablaufes in Hilfedatei
Fehler verhindern
Auswahl nur möglicher Informationen auf Grund von vorherigen
Eingaben; Missverständnisse durch Nachfragen vermeiden;
Blockieren von nicht benutzbaren Buttons, Vorgabe bei Auswahl
von Dateien
Einfache
Knoten alles löschen, Zurück durch Klicken auf anderen
Rücksetzmöglichkeiten
Knoten; löschen, zurück; -
Benutzerbestimmte
Überschaubarkeit der Informationen durch Tabelle &
Eingaben
Zwischenstand; Ausgabe der wichtigsten Informationen durch
Rückantwort; Aktion durch Eingaben vom Benutzer abhängig,
benutzerdenierte, Ausgabe abhängig von benutzter Modalität,
Einstellungen, abbrechbare Aktionen durch Löschbefehl
Geringe Belastung des
Ausgabe eines Zwischenstands mit bisherigen Informationen;
Kurzzeitgedächtnisses
Ausgabe einer Rückantwort mit bisherigen Informationen; -
Tabelle 5: Maÿnahmen zur Berücksichtigung der Regeln von Shneiderman
Resultate und Schlussfolgerungen lassen sich auch anhand der Liste von [Lar] feststellen. Sie
verschat einen Überblick über die Projekte, welche sich bereits mit dem Thema befassen bzw.
befasst haben. Ein gutes Ergebnis liefert SmartKom. Hier kann der Nutzer unter anderem
eine systemgesteuerte Stadtführung bekommen. Die Leitung übernimmt dabei ein Avatar
17 .
Auch wenn SmartKom sehr benutzerfreundlich ist, zeigt das Projekt die Beschränktheit aller
Anwendungen, welche aufgrund der Komplexität des Themenbereiches entstehen.
17
Figur in einer virtuellen Umgebung als Ersatz für agierende Menschen
43
6 ZUSAMMENFASSUNG UND AUSBLICK
6
Zusammenfassung und Ausblick
Die Umsetzung multimodaler Interaktionen ist ein viel erforschtes Themengebiet. Eine Erweiterung herkömmlicher Geräte durch zusätzliche Modalitäten wird zunehmend den Markt
bestimmen. Dennoch werden am Beispiel der vorliegenden Themenarbeit die derzeitigen Grenzen und die noch zu bewältigenden Probleme aufgezeigt.
Ziel der Arbeit war die Erstellung eines Dialogmanagers, das Schaen einer Umgebung sowie
die Anbindung von zwei Modalitäten. Ein Anwender soll durch Eingaben über die zur Verfügung stehenden Modalitäten virtuelle Lampen und Jalousien sowie einen realen Fernseher
steuern können.
Der Erläuterung von theoretischem Grundwissen in den Gebieten Automatentheorie, Beschreibungssprachen, Dialogsysteme und multimodale Interaktion, schloss sich die Erklärung des
Konzeptes an. In diesem Zusammenhang wurde der Begri Auftrag deniert, welcher die
Grundlage für das weitere Vorgehen bildete. Dieser kann durch Eingaben vom Anwender über
zwei Modalitäten bestimmt werden. Das Chatfenster ermöglicht eine Dateneingabe in Textform. Im Bedienfenster kann die Selektion eines Gerätes durch die Benutzung einer Baumstruktur und einer Tabelle erfolgen. Zur Bedienung der Modalitäten sind Informationen in den
Bereichen: Gerät, Ort, Information (optional) und Aktion notwendig. Des Weiteren wurden die
einzelnen Komponenten und ihre Beziehung zueinander erläutert. Der Dialogmanager bildet
dabei den Kern des Projektes. Von ihm ausgehend wird die Sprachverarbeitungskomponente
Linguistic Component, die Kommunikationskanäle Bedien- und Chatfenster, die Verwaltungskomponente Context Manager sowie das Ausgabefenster gesteuert. Der Interaction Manager
steuert seinerseits den Dialogmanager, den Context Manager und die Automation Component.
Letztere ist die Schnittstelle zwischen Dialogsystem und Gerät und erzeugt Schaltbefehle für
jedes Gerät. Das Leiten des Dialogusses durch einen Zustandsautomaten in der Beschreibungssprache SCXML, die Ausgabe einer virtuellen Wohnumgebung mittels SVG sowie die
Verwaltung der Modalitäten durch den Dialogmanager stellen die Schwerpunkte in der Umsetzung dar. Des Weiteren wurden dialogorientierte Zustandsautomaten für jede Geräteklassen
erstellt.
Obwohl ein ähnliches Projekt als Ausgangsbasis für diese Bachelorarbeit zur Verfügung stand,
konnten nicht alle vorhandenen Aspekte bei der Umsetzung berücksichtigt werden. Dies liegt
u. a. an der Vielfalt der Entwicklungsumgebungen. Sowohl zur Bearbeitung der vorliegenden
Arbeit als auch für eine erfolgreiche Implementierung werden gute Programmierkenntnisse benötigt. Dazu gehören Auszeichnungssprachen wie XML, Programmiersprachen wie C#, Kenntnisse in der Programmierung von Kommunikationsmedien sowie der Benutzerfreundlichkeit.
Die Bedienung des Menüs ist ebenfalls sehr verschieden und muss von allen Gruppen verwendet werden können. Auch Sprachunterschiede können Probleme bereiten, da das System bisher
nur gängige Wörter verarbeitet. Lokale Besonderheiten der deutschen Sprache wie ne und
44
6 ZUSAMMENFASSUNG UND AUSBLICK
dat erzeugen einen Fehler bei der Ermittlung der Semantik.
Zusammenfassend kann man dennoch sagen, dass die Zielsetzungen erreicht wurden. Eine
Mensch-Maschine-Kommunikation über verschiedene Modalitäten mit dem Ziel, Geräte zu
steuern, ist möglich. Um eine höhere Benutzerfreundlichkeit u. a. durch geringere Ladezeiten
beim Ausgabefenster zu erreichen, wäre eine Überarbeitung des Datenusses, insbesondere des
Context Managers, empfehlenswert.
Auf Grund der Vielfalt und Komplexität der Mensch-Maschine-Kommunikation ist eine umfassende Implementierung über mehrere Bereiche zum derzeitigen Zeitpunkt nur schwer umsetzbar. Auch wenn sich diese vorliegende Themenarbeit lediglich mit einen kleinen Bereich
der multimodalen Interaktion beschäftigt hat und auch das Ergebnis dieser Arbeit noch nicht
in Haushalten eingesetzt werden kann, schat sie jedoch Anknüpfungspunkte für weitere Forschungen auf diesem Gebiet. Ziel der Umsetzung multimodaler Interaktionen ist u.a., langfristig einen Beitrag zur Vermeidung von Unfällen zu leisten, den Energieverbrauch zu reduzieren
und sowohl den Komfort als auch die Flexibilität im Haushalt zu erhöhen.
45
LITERATUR
Literatur
[Aub]
Auburn, RJ: Voice Browser Call Control: CCXML Version 1.0.
org/TR/ccxml/.
[Bar]
http://www.w3.
Stand: 08.07.2011
State Chart XML (SCXML).
Barnett, Jim:
http://www.w3.org/TR/scxml/.
Stand: 08.07.2011
[Bei00]
Beigl, Michael: Kommunikation in interaktiven Räumen, Universität Karlsruhe(TH),
Fakultät der Informatik, Dissertation, 2000
[Cha]
Chandler, Daniel: The Transmission Model of Communication.
ac.uk/media/Documents/short/trans.html.
[Cle11]
http://www.aber.
Stand: 11.07.2011
Cleve, Prof. Dr. J.: Theoretische Informatik: Vorlesungsskript WS 2011/12. Hochschule Wismar, 2011
[Dah06] Dahm, Markus:
Grundlagen der Mensch-Computer-Interaktion. 1. Auage. Pearson
Studium, 2006
[Ges]
Gesundheitsberichterstattung des Bundes:
Unfälle in Haushalt und Frei-
http://www.gbe-bund.de/gbe10/abrechnung.prc_abr_test_logon?p_uid=
gasts&p_aid=&p_knoten=FID&p_sprache=D&p_suchstring=884::Suizid. Stand:
zeit.
17.07.2011
[Gla]
Glaeser, Udo: Tutorial: VoiceXML Einführung.
voicexml/tutorials_vxml.html.
[Hed07] Hedtstück, Prof. Dr. U.:
http://www.glaeser-bonn.de/
Stand: 08.07.2011
Einführung in die Theoretische Informatik. 4. Auage.
Oldenbourg Wissenschaftsverlag, 2007
[Her06] Herczeg, Michael:
Interaktionsdesign: Gestaltung interaktiver und multimedialer
Systeme. Oldenbourg Wissenschaftsverlag, 2006
[HMU02] Hopcraft, John E. ; Motwani, Rajeev ; Ullman, Jerey D.:
Einführung in die
Automatentheorie, Formale Sprachen und Komplexitätstheorie. 2. Auage. Pearson
Studium, 2002
[HS]
Häussermann-Schuler, Jochen: Klassisches Kommunikationsmodell nach Shan-
http://professionellegespraechsfuehrung.wordpress.com/2009/
11/23/klassisches-kommunikationsmodell-nach-shannon-weaver/. Stand:
non/ Weaver.
11.07.2011
[Lar]
Larsson, Staan: Dialogue systems and projects.
dialogue_links.html.
http://www.ling.gu.se/~sl/
Stand: 18.07.2011
46
LITERATUR
[McG]
McGlashan, Scott u.: Voice Extensible Markup Language 2.0.
org/TR/voicexml20/.
[MH]
Stand: 08.06.2011
Glossar.
Mayer, Renate ; Hoepelmann, Jaap:
uni-jena.de/teach/SoftErg/bd000.htm.
[Mic]
http://www.w3.
http://psc.informatik.
Stand: 17.07.2011
Michel, Thierry: Synchronized Multimedia.
http://www.w3.org/AudioVideo/.
Stand: 18.07.2011
[Obj10] Object Management Group: OMG Unied Modeling Language / Object Management Group (OMG). http://www.omg.org/spec/UML/2.3/Superstructure/, 2010.
Forschungsbericht
[Pre99]
Preim, Dr.-Ing. B.: Entwicklung interaktiver Systeme: Grundlagen, Fallbeispiele und
innovative Anwendungsfelder. Springer-Verlag, 1999
http://www.cis.
uni-muenchen.de/people/kristof/->Teaching->DialogsystemsandVoice-XML->
Folienzur1.,3.Sitzung. Stand: 10.07.2011
[Rina]
Ringlstetter, Christoph:
[Rinb]
Ringlstetter, Christoph:
Dialogsysteme und VoiceXML.
Dialogsystems.
people/kristof/DIALOG05/sitzung2.pdf.
[Shn02] Shneiderman, Ben:
[Sta]
[The]
Stand: 10.07.2011
User Interface Design. 3. Auage. mitp-Verlag, 2002
Stanciulescu, Adrian: What is UsiXML ?
mod=pages&id=2.
http://www.cis.uni-muenchen.de/
http://www.usixml.org/index.php?
Stand: 10.07.2011
The Apache Software Foundation: Commons SCXML 0.10-SNAPSHOT API.
http://commons.apache.org/scxml/apidocs/index.html?overview-summary.
html. 2010
[UIM]
UIML.org:
UIML INTRO.
http://www.uiml.org/intro/index.htm.
Stand:
09.07.2011
[Ulb11] Ulbricht, Annemarie:
Entwicklung eines Dialogmanagers für multimodale Interak-
tionen, Hochschule Wismar, Fakultät für Wirtschaftswissenschaften, Praktikumsbericht, 2011
[Voi]
http://developers.
voiceobjects.com/docs/en/VO9/007-structurethedialogflow.htm. Stand:
VoiceObjects AG:
How to Structure the Dialog Flow.
20.07.2011
[Wan02] Wang, Kuansan:
dialog systems
SALT: a spoken language interface for web-based multimodal
/ Speech Technology Group.
http://research.microsoft.com/en-
us/projects/salt/2002-kuansan-icslp.pdf, 2002. Forschungsbericht
47
LITERATUR
Anhang
Dialogorientierter Zustandsautomat einer Jalousie
SCXML-Datei einer Lampe
I
LITERATUR
Chatfenster
II