„Context is constituted by the entities that characterize the situation“ ((Haake, et al., 2010) (Seite 87)).
Im letzten Kapitel wurden die Anforderungen für FacilitationSupport ausgearbeitet. Zu diesem Zweck wurde die Anwendungsdomäne hinsichtlich der wesentlichen Eigenschaften und der möglichen, beeinflussenden Faktoren untersucht. Im Rahmen der Recherche wurde geprüft, ob bereits eine Lösung existiert, die die in Kapitel 2 gesammelten Anforderungen abdeckt und Möglichkeiten einer Integration in das EMS MeetingStar erlaubt. Ein derartiges System konnte nicht gefunden werden. Mit a CAPella wird in diesem Kapitel ein EMS vorgestellt, bei dem, ähnlich wie es für FacilitationSupport vorgesehen ist, in ausgewählten Situationen Folge-Aktionen ausgelöst werden. Anschließend wird geprüft, inwiefern die an FacilitationSupport gestellten Anforderungen durch den vorgestellten Ansatz erfüllt werden könnten.
a CAPella ist ein EMS, das im Rahmen eines Forschungsprojekts von (Dey, Hamid, Beckmann, Li, & Hsu, 2004) entstanden ist. Ähnlich wie es für FacilitationSupport vorgesehen ist (siehe Abschnitt 2.2), erkennt a CAPella Situationen aufgrund von Zustandsinformationen und Einflussfaktoren und passt dann, sofern dies konfiguriert ist, die Arbeitsumgebung automatisch an.
3.1.1 Kontext
((Dey, Hamid, Beckmann, Li, & Hsu, 2004) (Seite 33)) betrachten a CAPella als ein „Context-Aware Prototyping environment“. Im Rahmen dieser Arbeit wird der Begriff context-aware im Deutschen als kontextbewusst verstanden. ((Baldauf, Dustdar, & Rosenberg, 2007) (Seite 265)) definieren kontextbewusste Systeme (engl. context-aware systems) als Systeme, die in der Lage sind, ihre Operationen gemäß des aktuellen Kontexts und ohne das ausdrückliche Eingreifen des Benutzers zu adaptieren (anzupassen). Durch diese kontextbasierte Adaption , d. h., einer Adaption, die ein System auf Basis des aktuellen Kontexts durchführt, soll nach ((Baldauf, Dustdar, & Rosenberg, 2007) (Seiten 270, 274)) die Benutzerfreundlichkeit und Effizienz verbessert werden. Synonym zu Adaption werden im Duden[22] Anpassung, Assimilation und Bearbeitung genannt.
Zwei weitere Definitionen finden sich in ((Dey & Abowd, 1999) (Seite 310)):
„A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.”
und in ((Raatikainen) (Seite 5)):
„A system is context-aware if it can extract, interpret and use context information and adapt its functionality to the current context of use.”
Nach den vorliegenden Definitionen erfasst und verarbeitet ein kontextbewusstes System den Kontext und passt daraufhin die Funktionalitäten des zugrundliegenden Systems an. ((Dey, Abowd, & Salber, 2001) (Seite 106)) definieren Kontext als
„any information that can be used to characterize the situation of entities (i.e., whether a person, place, or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves“.
Unter Kontext sind nach obiger Definition also alle Informationen zu verstehen, die verwendet werden können, um eine Situation zu charakterisieren, und als relevant einzustufen für die Interaktion zwischen Benutzer und Anwendung, einschließlich der Benutzer und der Anwendung selbst.
a CAPella identifiziert eintretende Situationen aufgrund von Zustandsinformation und löst eine zuvor konfigurierte Adaption aus. Das EMS nutzt den Kontext, um eintretende Situationen zu identifizieren. Der Anwender hat in a CAPella die Möglichkeit, Situationen mithilfe von Regeln zu definieren bzw. zu trainieren. Die Regeln werden vom Anwender in einem integrierten Editor erstellt. In ((Dey, Hamid, Beckmann, Li, & Hsu, 2004) (Seite 33)) wird dieser Ansatz Programmieren durch Vormachen (engl. Programming by demonstration, PBD) bezeichnet:
„Users ‚program‘ their desired context-aware behavior (situation and associated action) in situ, without writing any code, by demonstrating it to a CAPpella and by annotating the relevant portions of the demonstration.“
Der aktuelle Kontext wird anhand von Sensoren erfasst, die Bestandteil von a CAPella sind. ((Baldauf, Dustdar, & Rosenberg, 2007) (Seite 266)) unterscheiden zwischen physischen, virtuellen und logischen Sensoren. Der physische Sensor ist ein Hardware-Sensor, mit dem die Messung (fast) aller, physischer Daten ermöglicht wird (z. B. lichtempfindliche Sensoren) ((Baldauf, Dustdar, & Rosenberg, 2007) (Seite 266)). Ein virtueller Sensor empfängt Kontextinformationen von Software Applikationen oder Services ((Baldauf, Dustdar, & Rosenberg, 2007) (Seite 266)). Ein logischer Sensor bedient sich verschiedener Datenquellen und verbindet physische und logische Sensoren zzgl. weiteren Informationen aus Datenbanken oder anderen Quellen, um komplexere Aufgaben zu erfüllen ((Baldauf, Dustdar, & Rosenberg, 2007) (Seite 266)).
Dass der Anwender die Regeln selbst konfigurieren kann, ist vor allem von praktischem Nutzen. Der Anwender hat nach ((Dey, Hamid, Beckmann, Li, & Hsu, 2004) (Seite 34)) häufig einen besseren Überblick und ein tieferes Wissen über die Anwendungsdomäne, als sie ein Softwareentwickler bei der Implementierung dieser Regeln haben kann. Zudem bietet eine Konfiguration durch den Anwender die Möglichkeit, dass dieser die Regeln jederzeit anpassen und optimieren kann.
3.1.3 Beispiel
Ein mögliches Beispiel, dass in (Dey, Hamid, Beckmann, Li, & Hsu, 2004) erläutert wird, stellt nachfolgende Situation dar. Ein Benutzer betritt den Besprechungsraum und startet ein Telefon-Meeting. In dieser Situation soll das Licht im Raum angeschaltet und am Computer eine Applikation für Notizen geöffnet werden. Um a CAPella zu trainieren, startet der Anwender die Aufnahmefunktion. Dies hat zur Folge, dass alle Daten der zu dem Zeitpunkt verfügbaren und aktivierten Sensoren aufgezeichnet werden. Zu den verfügbaren Sensoren von a CAPella zählen eine Videokamera, ein Mikrofon, ein Radio-Frequency Identification System (RFID), ein Switch, der die Telefonaktivität überwacht und weitere Akteure, die prüfen, welche Programme auf dem Computer geöffnet oder geschlossen werden.
Abbildung 5 „a CAPpella“ Benutzerschnittstelle ((Dey, Hamid, Beckmann, Li, & Hsu, 2004) (Seite 35))
Abbildung 5 zeigt die a CAPella-Benutzerschnittstelle nach der Aufnahme eines Meetings. Die Raw Daten, die von den Sensoren aufgezeichnet wurden, werden anschließend durch eine Ereigniserkennung (engl. Event Detection) vorverarbeitet und in eine zeitliche Folge gebracht. So wird z. B. das Videomaterial ausgewertet und für den Benutzer grafisch aufbereitet. In Abbildung 5 findet der Benutzer an erster Position im Events Panel die verarbeiteten Daten zu der Anzahl Personen (engl. Number of People). Veränderungen an der Teilnehmerzahl werden durch ein Zeitverlaufsdiagramm dargestellt. Im vorliegenden Beispiel verfügt das Diagramm über die zwei möglichen Belegungen 0 und 1. Zum Start der Aufzeichnung befindet sich kein Teilnehmer im Raum und der Zustand 0 ist ausgewählt. Nach kurzer Zeit setzt sich ein Teilnehmer an den Tisch. Dies hat zur Folge, dass die Linie auf den Zustand 1 wechselt. An unterster Stelle des Panels können die Aktionen verknüpft werden, die nach Eintreten einer Situation ausgeführt werden sollen. In diesem Fall wird das Licht eingeschaltet und eine Anwendung auf dem Computer geöffnet.
a CAPella bietet dem Anwender die Möglichkeit, den Kontext mit Unterstützung von Sensoren aufzuzeichnen. Anhand der ausgewerteten Daten...