Projekt 2
Christian Kirchner
Entwicklung einer kontextsensitiven Plattform zur Verwaltung und Verteilung von Informationen im Living Place
Fakultät Technik und Informatik
Studiendepartment Informatik Faculty of Engineering and Computer Science Department of Computer Science
Christian Kirchner
Entwicklung einer kontextsensitiven Plattform zur Verwaltung
und Verteilung von Informationen im Living Place
Inhaltsverzeichnis
1. Einführung 1
1.1. Zielsetzung . . . 1
2. Projektbeschreibung 2 2.1. Idee . . . 2
2.2. Device Content Manager (DCM) . . . 2
2.2.1. Filter . . . 3
2.2.2. Filter Listener . . . 3
3. Stakeholder 4 3.1. Entwickler . . . 4
3.2. UX-Designer . . . 4
4. DCM Framework 5 4.1. Erweiterte Spezifikation und Status Helper . . . 5
4.2. DCM Agent . . . 5
4.2.1. DCM Device Agent . . . 6
4.2.2. DCM Content Agent . . . 7
5. Inhalte 8 5.1. Videostream . . . 8
5.2. Twitter . . . 9
5.3. Kalender . . . 10
5.4. DCM Manager . . . 10
6. Schlussbetrachtung 11 6.1. Zusammenfassung . . . 11
6.2. Ausblick . . . 11
A. Anhang 13 A.1. DSL Beispiel . . . 13
A.2. DCM Kommunikationsfluss . . . 13
A.3. DCM Framework Architektur . . . 14
A.4. DCM-Manager-Content . . . 15
A.4.1. Inhalte . . . 15
A.4.2. Mappings . . . 15
A.4.3. Spezifikation . . . 16
A.5. Content API Beispiel . . . 17
A.6. Content Agent Beispiel . . . 19
1. Einführung
In dieser Projektarbeit geht es um die Fortsetzung der praktischen Grundlagen für die Entwick- lung einer Komponente zur zentralen Verwaltung von Inhalten und entsprechenden Anzei- gegeräten im Living Place (LP). In dem Projekt 1 wurden ein erster Architekturentwurf für ein solches System vorgestellt und die Anforderungen aus der Sicht der Entwickler analysiert.
Außerdem wurde zur Evaluation der Ergebnisse des Projektes ein erstes Testszenario entwi- ckelt, welches mit Hilfe von Kontextinformationen aus dem LP das Fernsehbild auf dem best möglichen Anzeigegerät erscheinen lässt.
Das in dieser Arbeit beschrieben Projekt 2 hat sich darüber hinaus mit der Entwicklung eines Frameworks zur Umsetzung der analysierten Anforderungen seitens der Entwickler befasst.
Außerdem wurden erste Überlegungen hinsichtlich der Interessen der UX-Designer aufgestellt, welche die Anforderungen der Endbenutzer repräsentieren sollen.
Die Einleitung (Kapitel1) gibt einen Überblick über die Gliederung dieses Berichts und wird abgeschlossen mit der Zielsetzung dieses Projekts. Im darauf folgenden Kapitel2 wird die grundlegende Idee des Projektes genauer beschrieben und außerdem noch ein kurzer Überblick über den aktuellen Stand des Device Content Management Systems gegeben. Das Kapitel3 beschreibt die unterschiedlichen Sichtweisen auf das System und die daraus entstehenden Anforderungen und deren Lösungsmöglichkeiten. Im Kapitel4wird ein Überblick über das für Entwickler bereitgestellte Framework zur vereinfachten Implementierung von neuen Inhalten und Geräten gegeben. Das Kapitel5stellt noch einmal alle bereits entwickelten Inhalte für den DCM vor und gibt einen groben Überblick über deren Funktionen. In der Schlussbetrachtung (Kapitel6) werden die gewonnen Erkenntnisse kurz zusammengefasst und abschließend die noch zu beantwortende Fragestellungen identifiziert.
1.1. Zielsetzung
Das Ziel des zweiten Projektes lässt sich in zwei Teilziele unterteilen. Zum einen die Verbesse- rung der Benutzbarkeit aus Sicht der Entwickler, durch die Bereitstellung eines Frameworks für den DCM und zum anderen die Entwicklung weiterer Inhalte und Geräte, um ein komplexeres Gesamtszenario zu ermöglichen. Mit Hilfe des neuen Szenarios sollen eventuelle Architek- turfehler aufgedeckt werden, welche die Unterstützung von dringend benötigten Funktionen hinsichtlich des DCM’s verhindern.
Durch die Entwicklung eines speziellen DCM-Inhaltes wird den Entwicklern die Möglichkeit gegeben sich einen Überblick über den aktuellen Zustand des DCM’s zu verschaffen. Über ihn können alle Geräte mit ihren zugehörigen Inhalten angezeigt werden und es gibt die Möglichkeit Inhalte auf ausgewählten Geräten anzuzeigen. Mit Hilfe dieses Inhaltes können anschließend unterschiedliche Testszenarien entwickelt werden, mit denen die Benutzbarkeit des Systems unter der Verwendung mehrere verschiedener Inhalte getestet werden kann.
2. Projektbeschreibung
Dieses Kapitel wird die grundlegende Idee und das Ziel dieses Projektes erläutern und mit Hilfe eines Beispielszenarios verdeutlichen.
2.1. Idee
Das Projekt 2 ist die Weiterführung des in der Ausarbeitung (vgl.Kirchner(2014)) beschrie- benen Agenten zur kontextsensitiven Verwaltung von unterschiedlichen Inhalten und deren Verarbeitungsgeräten, sowie der intelligenten Verteilung der Inhalte im LP. Diese Ausarbeitung befasst sich mit zwei verschiedenen Perspektiven auf das entwickelte DCM. Es sollen die unter- schiedlichen Sichtweisen und daraus resultierenden Anforderungen an das System verdeutlicht werden.
Zum Einen gibt es die Perspektive der Entwickler im LP. Sie sollen neue Geräte und Inhalte für das LP entwickeln, wofür die häufig verwendeten Grundfunktionen wie das Erstellen der Spezifikationen von Inhalten und Geräten, dessen Registrierung beim DAC-Manager oder das Verteilen von Inhalten auf bestimmte Geräte, vereint werden sollen. Allerdings muss das System auf Grund der losen Kopplung und der großen Vielfalt von unterschiedlichen Inhalten und Geräten stets flexibel und erweiterbar sein, sodass auch sehr spezielle Vorstellungen der Entwickler mit möglichst wenig Modifikation der Kern Komponenten umgesetzt werden können.
Die zweite Perspektive ist die Sicht der UX-Designer des LP. Deren Fokus liegt auf der Bedienung des Gesamtsystems und der Nachvollziehbarkeit der intelligenten Verteilung der Inhalte. Es müssen Lösungsstrategien entwickelt werden, um Konfliktsituationen zwischen verschiedenen Geräten und Inhalten zu behandeln. Eine Konfliktsituation stellt zum Beispiel die Zuweisung mehrerer Inhalte auf ein bestimmtes Gerät dar. Werden alle Inhalte gleichzeitig angezeigt oder gibt es eine bestimmte Reihenfolge oder Priorität in welcher die Inhalte nacheinander angezeigt werden? Will der Benutzer das sein Film, den er gerade schaut, durch neu zugewiesene Inhalte ersetzt wird oder sollen diese lieber auf anderen Geräten angezeigt werden? Inwiefern kann der Benutzer auf die automatische Verteilung der Inhalte Einfluss nehmen?
2.2. Device Content Manager (DCM)
Mit Hilfe des DCM’s können Anzeigegeräte und für diese Geräte bereitgestellte Inhalte verwaltet werden. Die Geräte und Inhalte haben jeweils eine Spezifikation, welche die wesentlichen Merkmale des Objektes, wie zum Beispiel die Größe des Bildschirms enthält. Außerdem besitzen sie einen Status, welcher den veränderbaren Zustand des Objektes repräsentiert. Der Status eines Gerätes kann zum Beispiel aussagen, ob der Bildschirm des Gerätes eingeschaltet ist, ob er vertikal oder horizontal angeordnet ist, ob das Gerät Töne abspielen kann oder andere hilfreiche Informationen. Der wesentliche Unterschied zwischen Spezifikation und Status besteht darin,
2. Projektbeschreibung
dass sich die Spezifikation des Objektes während der Zeit, die es beim DCM registriert ist, nicht ändern kann.
2.2.1. Filter
Durch die Verwendung von Filtern können bestimmte Geräte oder Inhalte, die beim DCM registriert sind, gesucht und hinsichtlich ihrer Attribute abgefragt werden. Durch die Filter
„DeviceSpecificationFilter“ bzw. „ContentSpecificationFilter“ lassen sich Inhalte bestimmen, deren Spezifikation und Status auf ein im Filter definiertes Muster passen. Für die Muster gibt es verschiedene Operatoren wie„equals“,„greater“ oder„smaller“ aber auch Operatoren für Collections wie„contains“ oder„sizeIsEqual“, mit denen Geräte und Inhalte entsprechend ihrer Eigenschaften gefiltert werden können. Durch„and“und„or“ Operatoren können auch mehrere Operatoren miteinander verknüpft werden, sodass sich komplexe Abfragen konstruieren lassen.
Außerdem gibt es noch den NearestDeviceFilter, welcher das Gerät zurück gibt, welches sich am dichtesten an einem im Filter definierten Ubisense Tag befindet. Im Laufe der Zeit sollen weitere Filter hinzugefügt werden, die beim Identifizieren von geeigneten Geräten oder Inhalten behilflich sein könnten.
2.2.2. Filter Listener
Filter Listener können dazu verwendet werden, regelmäßig Informationen von bestimmten Geräten und Inhalten zu abonnieren. Dafür werden mit Hilfe der zuvor vorgestellten Filter die gewünschten Geräte oder Inhalte ausgewählt und anschließend werden die Informationen in eine Gruppe veröffentlicht, die bei der Registrierung des Listeners übergeben wird. Zur Zeit werden die Listener über die folgenden Ereignisse mit Hilfe von Nachrichten informiert:
• DeviceStatusChanged(deviceId: String, change: StatusChange)
Benachrichtigt alle Listener über die Änderung des Status eines Gerätes mit der ID
„deviceId“ und zeigt durch das Objekt „StatusChange“ an, welche Art von Änderung vorgenommen wurde (StatusAttributeUpdatedoderStatusAttributeRemoved).
• ContentStatusChanged(contentId: String, change: StatusChange) Identisch zur „DeviceStatusChanged“ Nachricht, nur diesmal für Inhalte.
• TagPositionChanged(tag: String, position: Position)
Antwortet mit einer Status Nachricht, welche eine Map der entsprechenden Statusattribute entweder des Gerätes oder des Inhaltes enthält. Bei diesem Aufruf wird der gesamte Status übermittelt.
3. Stakeholder
Um bei der Architektur des Systems möglichst alle Anforderungen zu berücksichtigen, muss die Anwendung mindestens aus zwei verschiedenen Perspektiven betrachtet werden. Die folgende Unterteilung versucht die unterschiedlichen Anforderungen zu analysieren und identifiziert entsprechende Maßnahmen.
3.1. Entwickler
Wichtig für die Entwicklung ist, dass die Umsetzung nicht durch die Architektur des DCM’s eingeschränkt ist und dadurch die Vorstellungen und Pläne der Entwickler nicht realisierbar sind. Dafür muss das System plattformübergreifend mit anderen Technologien verwendbar sein und es muss eine Art Plugin System unterstützt werden, welches das Einbetten neuer Geräte oder Inhalte in das laufende System ermöglicht. Durch die Verwendung der Middleware und das zum Datenaustausch verwendete JSON Format, kann das DAC System von jeder Plattform aus verwendet werden, welches in der Lage ist JSON Nachrichten zu versenden und zu empfangen. Um an Informationen aus dem DCM zu gelangen und auf bestimmte Ereignisse zu reagieren, bietet die DCM API zusätzlich zu den Filter Listenern (vgl. Abschnitt2.2.2) allgemeine Informationsnachrichten an, welche über neu registrierte und abgemeldete Geräte und Inhalte oder auf Geräten hinzugefügte oder entfernte Inhalte benachrichtigen.
3.2. UX-Designer
Der Blickwinkel des UX-Designers soll die Interessen des Endbenutzers repräsentieren. Dafür ist es wichtig den Prozess der automatischen Verteilung der Inhalte für den Benutzer nachvoll- ziehbar zu gestalten und ihm zu jedem Zeitpunkt die volle Kontrolle über das System geben.
Zumindest sollte er die Möglichkeit haben die intelligente Verteilung der Inhalte individualisiert zu gestalten. Um dieses Problem zu lösen gibt es zwei verschiedene Lösungsansätze. Zum einen kann dem Benutzer, über eine DSL ermöglicht werden, Regeln zur automatischen Verteilung der Inhalte zu erstellen. Andererseits können Lernverfahren verwendet werden um die Verteilung der Inhalte an den Benutzer anzupassen. In beiden Fällen sollte der Benutzer jedoch die Möglich- keit besitzen das Verfahren außer Kraft zu setzen, um eine manuelle Verteilung vorzunehmen.
Basierend auf den im Abschnitt2.2.1vorgestellten Filtern und den DCM Informationsnach- richten könnte eine DSL entwickelt werden, welche es dem Benutzer ermöglicht verschiedene Filter zu erstellen, zu bearbeiten und zu kombinieren. Die Informationsnachrichten können als Eventtrigger verwendet werden. AbbildungA.1zeigt ein Beispiel, wie eine Regel mit Hilfe der DSL erstellt werden könnte. Die Regel besagt, dass sobald ein Inhalt beim DCM Manager regis- triert wird, welcher vom Typ „YoutubeVideo“ ist und dem Benutzer „Bernd“ zugeordnet ist, soll dieser auf dem Gerät angezeigt werden, welches in der Lage ist Inhalte vom Typ „YoutubeVideo“
zu verarbeiten, zur Zeit keine anderen Inhalte abspielt und am dichtesten zu Bernd gelegen ist.
4. DCM Framework
Das DCM Framework soll dabei helfen die Benutzbarkeit des DCM Systems für Entwickler zu vereinfachen, indem durch die Bereitstellung von Basisklassen häufig verwendete Anwen- dungsfälle einfacher zu handhaben sind. Im wesentlichen unterstützt das Framework in drei verschiedenen Bereichen, dem Erstellen und Bearbeiten von Spezifikationen und Status, dem Registrieren der Inhalte und Geräte beim DCM und dem Hinzufügen von Inhalten auf Gerä- ten. Das Diagramm im AnhangA.3gibt einen Überblick über das Zusammenspiel des DCM Frameworks im gesamten DCM System.
4.1. Erweiterte Spezifikation und Status Helper
In der DCM-API werden die Spezifikationen und Status jeweils als eine immutable Map von key- value Paaren übergeben, welche von der Middleware im JSON-Format transportiert werden. Um das Erstellen dieser Maps zu vereinfachen und das Übergeben der Pflichtattribute zu garantieren gibt es in dem Framework Objekte, welche beim Anlegen einer Spezifikation oder eines Status prüfen, ob alle benötigten Informationen übergeben wurden. Für die Pflichtattribute gibt es einfache getter Methoden, welche den Zugriff auf die häufig verwendeten Attribute vereinfachen.
Ein weiterer Vorteil ist, dass durch die typisierten Helferklassen sichergestellt werden kann, dass nicht versehentlich die Spezifikation eines Gerätes anstelle der eines Inhaltes verwendet wird. Dies reduziert die Fehleranfälligkeit bei der Programmierung von Inhalten und Geräten für den DCM.
4.2. DCM Agent
DCM Agenten sind Unterklassen der im Middleware Framework bereitgestellten Agent Klassen.
Deshalb können sie ohne weiteres die Gruppenkommunikation der Middleware nutzen um mit anderen Agenten zu kommunizieren. Die Nachrichten der abonierten Gruppen werden wie gewohnt in der receive Methode verarbeitet. Die DCM Agenten fangen bestimmte Nachrichten in der receive Methode ab und ermöglichen dadurch die Verwendung bestimmter Grundfunktio- nalitäten in den Agenten. Die von den DCM Agenten implementierten Nachrichten entsprechen den in der DCM Device API, bzw. DCM Content API definierten Nachrichten:
• GetSpecification()
Antwortet mit einer Specification Nachricht, welche eine Map der entsprechenden Spezi- fikationsattribute entweder des Gerätes oder des Inhaltes enthält. Bei diesem Aufruf wird die gesamte Spezifikation übermittelt.
• GetSpecificationAttribute(path: String)
Antwortet mit einer SpecificationAttribute Nachricht, die gezielte Abfrage bestimmter Werte aus der Spezifikation ermöglicht.
4. DCM Framework
• GetStatus()
Antwortet mit einer Status Nachricht, welche eine Map der entsprechenden Statusattribute entweder des Gerätes oder des Inhaltes enthält. Bei diesem Aufruf wird der gesamte Status übermittelt.
• GetStatusAttribute(path: String)
Antwortet mit einer StatusAttribute Nachricht, die gezielte Abfrage bestimmter Werte aus des Status ermöglicht.
• AddStatusAttribute(path: String, value: Attribute)
Mit Hilfe dieser Nachricht kann dem Status ein beliebiger key-value Wert hinzugefügt werden. Sollte der key bereits bestehen wird eine Fehlernachricht übermittelt.
• RemoveStatusAttribute(path: String)
Entfernt einen key-value Paar aus dem Status des Objektes. Sollte der key bereits existieren wird eine Fehlernachricht übermittelt.
• UpdateStatusAttribute(path: String, value: Attribute
Ändert den value zu dem entsprechenden key. Die Antwortnachricht enthält sowohl den alten als auch den neuen Wert.
Bei den Nachrichten zur Statusveränderung werden automatisch Informationsnachrichten der entsprechenden Ereignisse in der Status Gruppe des Gerätes oder Inhaltes veröffentlicht.
Dadurch können andere Agenten auf die Statusänderungen reagieren.
DCM Agenten registrieren sich beim Start des Agenten automatisch, mit ihrer Spezifikation, beim einem in der Config des Agenten angegeben DCM. Nach der Registrierung wird durch ein in der Middleware eingebautes Agent Monitoring die Erreichbarkeit des Agenten überwacht. Bricht der Kontakt zwischen dem DCM und dem Agenten ab, wird der Agent beim DCM abgemeldet.
Somit ist sichergestellt, das Inhalte nur auf Geräte verteilt werden, die auch tatsächlich erreichbar sind.
4.2.1. DCM Device Agent
Die DCM Device Agent Klasse verfügt über die Basis Funktionen hinaus noch über die Möglich- keit Inhalte dem Gerät hinzuzufügen oder zu entfernen. Die Inhalte eines Gerätes werden nach dem Hinzufügen automatisch im Status festgehalten. Dort wird die ID jedes Inhaltes mit dem momentanen Anzeigestatus (Showing, Hidden, Loading) in einem Map Attribut gespeichert.
Wie das jeweilige Gerät die ihm zugeordneten Inhalte verarbeitet muss individuell für jedes Gerät implementiert werden. Verglichen mit dem MVC-Pattern stellt das Gerät also ein View zur Verfügung, um die Informationen eines Inhaltes zu repräsentieren. Ein Gerät mit Bildschirm
4. DCM Framework
beispielsweise kann eine Liste von Terminen anzeigen, ein Gerät welches nur Tonwiedergabe unterstützt könnte die Termine statt dessen vorlesen. Der DCM-Device Agent kann für unter- schiedliche Gerätetypen erweitert werden. Ein Android Gerät zum Beispiel kann das Interface dahingehend erweitern, dass verschiedene Sensortypen ein und ausgeschaltet, die Lautstärke des Gerätes oder der Betriebszustand des Gerätes verändert werden können. Wichtig ist, dass alle Eigenschaften, die über den DCM abgefragt werden sollen auch im Status aktualisiert werden. Wird also über das Interface die Lautstärke verändert, muss auch der Status mit Hilfe der dafür bereitgestellten „UpdateStatusAttribute“ Methode aktualisiert werden.
4.2.2. DCM Content Agent
Der DCM Content Agent ist ein DCM Agent, der sich beim Start, analog zum Device Agent, als DCM Inhalt registriert. Da die Inhalte in ihrer Ausprägung stark variieren gibt es hier momentan noch keine heraus faktorisierten Gemeinsamkeiten. Alle in Abschnitt5beschriebenen Inhalte erweitern den DCM Content Agent um ein eigene API, welche ihre Funktionen zugänglich macht. Anschließend stellt der Agent eine Art Model dar (analog zum Model im MVC-Pattern), welches die Informationen des entsprechenden Inhaltes enthält. Durch diese Trennung von Model und View wird ein großer Teil der Orthogonalität des Systems gewährleistet, dadurch dass nur ein Model für die Funktionalität eines Inhaltes existieren muss, welches aber durch verschiedene Views repräsentiert werden kann. Außerdem können durch die Agentenstruktur und die Kommunikationsmöglichkeiten über die Middleware verschiedene Models miteinander kooperieren, was eine Trennung der Funktionalitäten ermöglicht.
5. Inhalte
Dieses Kapitel gibt einen Überblick über alle bereits umgesetzten Inhalte, welche über den DCM angezeigt werden können. Anhand des Videostream Inhalts wird erläutert, wie die Inhalte mit Hilfe des Frameworks aufgebaut werden.
5.1. Videostream
Bei dem ersten Inhalt handelt es sich um die Anzeige eines Videostreams. Zunächst werden in der Videostream API alle für den Inhalt benötigten Funktionen zum Darstellen und der Kontrolle des Inhaltes definiert (vgl. AnhangA.5). Anschließend wird ein Agent erstellt, welcher die Basisklasse „DCMContentAgent“ aus dem DCM Framework erweitert. Über eine Config im JSON Format können den Inhalten initiale Werte für Spezifikation und Status übergeben werden.
Folgende Werte müssen unbedingt in der Config angegeben werden, da für die Registrierung beim DCM benötigt werden (vgl. Attributinitialisierung Zeile 4-15 in AnhangA.6):
• spezification.id (String)
Ist eine ID, welche den Inhalt eindeutig im DCM referenziert. Sofern die ID bereits vergeben ist, kann sich dieser Inhalt nicht beim DCM registrieren.
• spezification.agentId (String)
Ist der Agentenname, welcher bei der Middleware registriert wird. Dieser muss in der gesamten Middleware betrachtet eindeutig sein.
• spezification.groups.dcmDefault (String)
Der Gruppenname der „default“ Gruppe, über den der Inhalt mit dem DCM kommuniziert.
Die „default“ Gruppe wird verwendet, falls ein Fehler in der Kommunikation auftritt.
Sie sollte von jedem Agenten aboniert werden, um auf eventuelle Fehlernachrichten zu reagieren.
• spezification.groups.dcmState (String)
Der Gruppenname der „state“ Gruppe, über den der Inhalt mit dem DCM kommuniziert.
Die „state“ Gruppe wird verwendet, um allgemeine Informationen in einer Gruppe zu veröffentlichen.
• spezification.groups.dcmControl (String)
Der Gruppenname der „control“ Gruppe, über den der Inhalt mit dem DCM kommuniziert.
Die „control“ Gruppe wird verwendet, um Anfragen oder Befehle an den Agenten zu senden.
Mit den erstellten Attributen werden anschließend der initiale Status und die Spezifikation erstellt (vgl. Zeile 20-37 in AnhangA.6). Das „State“ Objekt enthält die Methoden aus der Vi- deostream API, in diesem Beispiel die Methoden „getVolume()“ und „setVolume(volume: Int)“.
In der„getVolume“ Methode (vgl. Zeile 41-44 in AbbildungA.6) wird durch die Hilfsfunktion
5. Inhalte
„getStatus()“ aus der DCM-Content-Agent Klasse der aktuelle Status abgefragt und das Attribute
„volume“ ermittelt. Die„setVolume“ Methode verwendet die Hilfsmethode „updateStatusAttri- bute“ um den Status entsprechend zu aktualisieren.
In der „receive“ Methode (vgl. Zeile 55-63 in AnhangA.6) werden anschließend nur noch die in der Videostream API definierten Nachrichten empfangen, die entsprechende Methode aus dem
„State“ Objekt aufgerufen und die passenden Antwort Nachrichten zurück geschickt.
Bei der Konzeption eines Inhaltes ist es dem Entwickler überlassen, ob er größere Daten ebenfalls über die Middleware übermitteln möchte oder ob er nur die Quelle der Daten angibt, sodass die beiden Enden sich selbständig um die Datenübermittlung kümmern können. Das Diagramm in AnhangA.2zeigt noch einmal die Nachrichten und Komponenten, welche zum Anzeigen von Inhalten über das DCM benötigt werden.
In diesem Beispiel hält der Videostream Inhalt nur eine Referenz auf ein RTMP- oder YouTube- Stream, welcher auf den Geräten verarbeitet wird. Jeder Inhalt wird von einem eigenen Agenten repräsentiert, welcher die Eigenschaften und den Status des Inhaltes verwaltet. Die Manipulation eines Inhaltes kann also von jedem Agenten aus mit Hilfe eines einfachen Nachrichtenaustau- sches über die Middleware erfolgen. Getestet wurde der Inhalt mit RTMP Streams, welche über einen Wowza Media Server im LP bereit gestellt werden und Youtube Videos aus dem Internet.
5.2. Twitter
Mit Hilfe des Twitter Inhaltes kann man sich eine Liste der letzten Tweets von einer oder mehreren Twitter ID’s anzeigen lassen. Dafür ermittelt der Inhaltsagent mit Hilfe von polling bei einem Twitter Agenten die jeweils letzten Tweets von einer Sequenz von Twitter ID’s, welche dem Twitter Inhalt über ein Statusattribute übergeben werden können. Da die Twitter API auf eine gewisse Anzahl von REST Aufrufen pro Tag limitiert ist, werden die Twitter Informationen im Twitter Content für die Länge des polling Intervals zwischengespeichert. Sollten also mehrere Geräte diesen Inhalt anzeigen, wird trotzdem nur ein REST Aufruf pro polling Interval benötigt.
Für ein geplantes Beispielszenario sollen Twitter Feeds von Schauspieler des aktuell laufenden Films automatisch auf einem weiteren Gerät angezeigt werden. Dafür muss der Twitter Agent in der Lage sein anhand des Namens der Schauspieler die entsprechenden Twitter Profile zu identifizieren. Für die erste Umsetzung dieses Agenten wird dafür die Twittersuche mit dem Vor- und Zunamen des Schauspielers ausgeführt und das Profil mit den meisten Followern ausgewählt. Diese Funktion sollte später durch eine zuverlässigere Methode ersetzt werden, in der zum Beispiel Schauspieler Namen mit Hilfe einer Map entsprechenden Profilen zugeordnet werden können.
5. Inhalte
5.3. Kalender
Der Kalender Inhalt kann eine Liste der nächsten anstehenden Termine ab einem definierbaren Datum anzeigen. Außerdem kann eine Detailansicht eines Termins angezeigt werden. Dieser Inhalt kann genutzt werden, um den Benutzer beispielsweise eine bestimmte Zeit vor einem Termin auf diesen hinzuweisen. Für die Kalender gibt es eine allgemein gehaltene Calendar API, welche die grundlegenden Funktionen eines Kalenders zur Verfügung stellt. Dazu zählt das Ermitteln aller Termine eines Kalenders in einem definierten Zeitintervall oder das Erstellen, Bearbeiten oder Löschen von Terminen. Als konkrete Implementierung dieser API wurde ein „GoogleCalendarAgent“ realisiert, welcher mit Hilfe einer OAUTH2 Authentifizierung die Kalenderinformationen eines „Google Calendar“ Accounts auslesen kann.
Angereichert durch weitere Kontextinformationen aus dem LP könnte dieser Inhalt verwendet werden, um beispielsweise je nach Aufenthaltsort des Kalenderbesitzers eine Benachrichtigung über den anstehenden Termin zu platzieren. Hält sich die Person vor einem Termin, welcher außerhalb des Hauses oder mit anderen anwesenden Personen stattfindet, im Bett auf, muss die Benachrichtigung deutlicher eher und aggressiver angezeigt werden, da davon auszugehen ist, dass die Person noch Zeit benötigt um sich auf den Termin vorzubereiten. Befindet sich die Per- son jedoch schon seit geraumer Zeit im Badezimmer ist davon auszugehen, dass sich die Person des Termins bewusst ist und es reicht ein dezenter Hinweis mit zusätzlichen Informationen, wie Routenplanung, Wetterinformationen oder Informationen über andere Teilnehmer.
5.4. DCM Manager
Der DCM Manager-Inhalt unterstützt die Entwickler bei der Fehlersuche im DCM System. Mit ihm können sowohl die Spezifikation, als auch der Status aller Geräte und Inhalte die beim DCM registriert sind überwacht werden (vgl. AnhangA.4.3). Für jedes Gerät wird angezeigt, welche Inhalte ihm über welches Mapping zugeordnet sind (vgl. AnhangA.4.1). Außerdem kann man Mappings aus dem DCM entfernen und vordefinierte Mappings hinzufügen (vgl. Anhang A.4.2). Es können ausgewählte Beispielinhalte generiert werden, um sie auf beliebigen Gerät anzuzeigen. Aus diesem Grund kann dieser Inhalt als eine Art Fernbedienung für DCM Inhalte im LP dienen und zum Beispiel für Vorführungen verwendet werden.
6. Schlussbetrachtung
In der Schlussbetrachtung werden die gewonnen Erkenntnisse und wesentlichen Fakten noch einmal kurz zusammengefasst und es wird ein Ausblick über mögliche Ansatzpunkte zur Weiterführung dieser Arbeit aufgelistet.
6.1. Zusammenfassung
Diese Projektarbeit beschreibt mit dem Hinzufügen von Filtern und Filter Listenern die wesent- lichen Veränderungen des DCM Systems seit dem letzten Projektbericht. Zusammen mit dem entwickelten Framework sollen sie dazu beitragen, dass den Entwickler im LP das Erstellen von Inhalten und Geräten weitestgehend vereinfacht wird. Das Framework mit seinen Helferklassen ermöglicht es in dem ansonsten sehr flexibel gestalteten Nachrichtenaustausch per JSON eine gewisse Art von Typsicherheit zu garantieren und prüft Pflichtattribute und deren Typen bereits zur Compilezeit.
Durch den entwickelten DCM-Manager Inhalt wird den Entwicklern die Möglichkeit gegeben die Spezifikation und den Status eines jeden Inhalts oder Gerätes in Echtzeit zu überprüfen und es wird die Verteilung der Inhalte auf die verschiedenen Geräte veranschaulicht. Zusätzlich zu dem in der Middleware bereitgestellten Agententests soll dies bei der Fehlersuche im DCM System behilflich sein.
Mit Hilfe des Frameworks wurden weitere DCM-Inhalte entwickelt, welche entweder durch den DCM-Inhalt auf entsprechende Geräte verteilt werden können oder aber durch ein regelbasiertes Verteilungssystem. Es wurde ein Beispiel gegeben, wie eine DSL für ein solches Verteilungssys- tem aussehen könnte und wie es mit Hilfe der Filter Listener und Informationsnachrichten des DCM umgesetzt werden kann.
Aus verschiedenen DCM-Inhalten kann nun ein komplexes Gesamtszenario entwickelt werden, welches es ermöglicht sowohl die Kombination aus Inhalten zu erstellen und diese intelli- gent zu verteilen aber auch Konfliktsituationen bei der Verteilung zu ermitteln und geeignete Lösungsstrategien zu entwickeln.
6.2. Ausblick
Da der „Kontext“ Begriff in den Bereichen „Context Aware Computing“, „Smart Home“ und
„Location Based Services“ unterschiedlich definiert ist (vgl. Kapitel 2.1.2Eichler(2014)), gilt es diesen genauer einzugrenzen. Es müssen die Informationen identifiziert werden, welche den Kontext für den DCM im LP darstellen und für die Verteilung der Inhalte eine Rolle spielen.
Bisher wurden im wesentlichen der Ort und die Verfügbarkeit verschiedener Anzeigegeräte als Kontextparameter verwendet. Sofern nicht in dem Kontextbegriff inbegriffen, müssen auch
6. Schlussbetrachtung
die benutzerspezifische Individualisierung des DCM hinsichtlich der Geräte, Inhalte und der Verteilungsstrategien berücksichtigt werden.
Durch die Forschung eines studentisches Projektes der Hochschule ist es möglich Middleware Agenten unter Android zu verwenden. Durch die Kombination mit dem DCM Framework kann somit ein DCM-Device Agent für Android Geräte entwickelt werden. Im Vergleich zu dem bereits bestehenden DCM-Web-Device, kann dieses Gerät sehr einfach auf Sensorinformatio- nen zugreifen und diese über den Status bereitstellen. Dies ermöglicht es unter anderem den Displaystatus oder die Lautstärke des Android Geräts im DCM zu aktualisieren und dadurch eine Umverteilung der Inhalte zu initialisieren. Die Androidgeräte, wie Tablets oder Smart- phones, würden durch ihre Mobilität und durch ihre Benutzer Personalisierung zusätzliche Kontextinformationen für das System bereitstellen.
A. Anhang
A.1. DSL Beispiel
1 When C o n t e n t A d d e d W i t h S p e c i f i c a t i o n Where " ‘ Typ " ’ = " ‘ Y o u t u b e V i d e o " ’
2 And S t a t u s Where " ‘ Owner " ’ = " ‘ B e r n d " ’ MapTo D e v i c e W hi c h I s U n u s e d
3 And Can P l a y " ‘ Y o u t u b e V i d e o " ’ And N e a r e s t To " ‘ B e r n d " ’
A.2. DCM Kommunikationsfluss
Abbildung A.1.: Nachrichtenfluss im DCM System für das Anzeigen von Inhalten
A. Anhang
A.3. DCM Framework Architektur
Abbildung A.2.: Integration des DCM Frameworks in das DCM Gesamtsystem
A. Anhang
A.4. DCM-Manager-Content
A.4.1. Inhalte
Abbildung A.3.: Liste aller Inhalte eines Gerätes mit den dazugehörigen Mappings über welches sie dem Gerät zugeordnet wurden.
A.4.2. Mappings
Abbildung A.4.: Alle aktiven Mappings, welche auf das Gerät verweisen
A. Anhang
A.4.3. Spezifikation
Abbildung A.5.: Die Spezifikation eines Gerätes
A. Anhang
A.5. Content API Beispiel
1 / ∗ ∗
2 ∗ G i b t d i e i n d i v i d u e l l e L a u t s t ä r k e d e s V i d e o s z u r ü c k .
3 ∗
4 ∗ @ r e t u r n V o l u m e ( v o l u m e : I n t ) , w o b e i v o l u m e e i n e A n g a b e n v o n 0−1 0 0
5 ∗ i s t u n d e i n e n p r o z e n t u a l e n W e r t r e p r ä s e n t i e r t
6 ∗ /
7 c a s e c l a s s G e t V o l u m e ( )
8 c a s e c l a s s V o l u m e ( v o l u m e : I n t )
9 10 / ∗ ∗
11 ∗ V e r ä n d e r t d i e i n d i v i d u e l l e L a u t s t ä r k e d e s V i d e o s .
12 ∗
13 ∗ @param v o l u m e : I n t , W e r t v o n 0−1 0 0 , a l s p r o z e n t u a l e r W e r t d e r
14 ∗ L a u t s t ä r k e
15 ∗ /
16 c a s e c l a s s S e t V o l u m e ( v o l u m e : I n t )
17 18 / ∗ ∗
19 ∗ G i b t d i e a k t u e l l e n F o r t s c h r i t t d e s V i d e o s i n S e k u n d e n z u r ü c k .
20 ∗
21 ∗ @ r e t u r n P o s i t i o n ( p o s i t i o n : I n t )
22 ∗ /
23 c a s e c l a s s G e t P o s i t i o n ( )
24 c a s e c l a s s P o s i t i o n ( p o s i t i o n : L o n g )
25 26 / ∗ ∗
27 ∗ V e r ä n d e r t d e n F o r t s c h r i t t d e s V i d e o s a u f e i n e g e w ü n s c h t e n
28 ∗ Z e i t p u n k t .
29 ∗
30 ∗ @param p o s i t i o n : L o n g
31 ∗ /
32 c a s e c l a s s S e t P o s i t i o n ( p o s i t i o n : L o n g )
33 34 / ∗ ∗
35 ∗ G i b t d i e a k t u e l l e n S t a t u s d e r W i e d e r g a b e z u r ü c k .
36 ∗
37 ∗ @ r e t u r n V i d e o S t a t u s ( s t a t u s : P l a y b a c k S t a t u s ) , s t a t u s k a n n
38 ∗ m o me n t a n d e n W e r t P l a y o d e r P a u s e a n n e h m e n
39 ∗ /
A. Anhang
40 c a s e c l a s s G e t V i d e o S t a t u s ( )
41 c a s e c l a s s V i d e o S t a t u s ( s t a t u s : P l a y b a c k S t a t u s )
42 43 / ∗ ∗
44 ∗ V e r ä n d e r t d e n W i e d e r g a b e s t a t u s d e s V i d e o s .
45 ∗
46 ∗ @param s t a t u s : P l a y b a c k S t a t u s
47 ∗ /
48 c a s e c l a s s S e t V i d e o S t a t u s ( s t a t u s : P l a y b a c k S t a t u s )
49 50 / ∗ ∗
51 ∗ I n f o r m a t i o n s n a c h r i c h t ü b e r d i e V e r ä n d e r u n g d e r L a u t s t ä r k e
52 ∗
53 ∗ @param v o l u m e : I n t
54 ∗ /
55 c a s e c l a s s V o l u m e C h a n g e d ( v o l u m e : I n t )
56 57 / ∗ ∗
58 ∗ I n f o r m a t i o n s n a c h r i c h t ü b e r d i e V e r ä n d e r u n g d e s F o r t s c h r i t t s
59 ∗
60 ∗ @param p o s i t i o n : L o n g
61 ∗ /
62 c a s e c l a s s P o s i t i o n C h a n g e d ( p o s i t i o n : L o n g )
63 64 / ∗ ∗
65 ∗ I n f o r m a t i o n s n a c h r i c h t ü b e r d i e V e r ä n d e r u n g d e s W i e d e r g a b e s t a t u s
66 ∗
67 ∗ @param s t a t u s : P l a y b a c k S t a t u s
68 ∗ /
69 c a s e c l a s s V i d e o S t a t u s C h a n g e d ( s t a t u s : P l a y b a c k S t a t u s )
A. Anhang
A.6. Content Agent Beispiel
1 c l a s s V i d e o s t r e a m C o n t e n t A g e n t ( c o n f i g : C o n f i g )
2 e x t e n d s D c m C o n t e n t A g e n t ( c o n f i g ) {
3
4 l a z y v a l D c m G r o u p P r e f i x = " Dcm "
5 l a z y v a l i d = c o n f i g . a s [ S t r i n g ] ( " c o n t e n t . s p e c i f i c a t i o n . i d " )
6 l a z y v a l u r l = c o n f i g . a s [ S t r i n g ] ( " c o n t e n t . s p e c i f i c a t i o n . u r l " )
7 l a z y v a l v i d e o T y p e = c o n f i g . a s [ S t r i n g ] ( " c o n t e n t . s p e c i f i c a t i o n . v i d e o T y p e " )
8 l a z y v a l v o l u m e = c o n f i g . a s [ L o n g ] ( " c o n t e n t . s t a t u s . v o l u m e " )
9 l a z y v a l p o s i t i o n = c o n f i g . a s [ L o n g ] ( " c o n t e n t . s t a t u s . p o s i t i o n " )
10 l a z y v a l p l a y b a c k S t a t u s = c o n f i g . a s [ S t r i n g ] ( " c o n t e n t . s t a t u s . p l a y b a c k S t a t u s " )
11 l a z y v a l g r o u p M a p = Map [ S t r i n g , A t t r i b u t e ] (
12 " d c m C o n t r o l " −> s " $ D c m G r o u p P r e f i x $ i d . C o n t r o l " ,
13 " d c m S t a t e " −> s " $ D c m G r o u p P r e f i x $ i d . S t a t e " ,
14 " d c m D e f a u l t " −> s " $ D c m G r o u p P r e f i x $ i d . D e f a u l t " ,
15 " c o n t r o l " −> s " $ i d . C o n t r o l " ,
16 " s t a t e " −> s " $ i d . S t a t e " ,
17 " d e f a u l t " −> s " $ i d . D e f a u l t "
18 )
19
20 o v e r r i d e l a z y v a l i n i t S t a t u s = new M u t a b l e C o n t e n t S t a t u s (
21 Map [ S t r i n g , A t t r i b u t e ] (
22 " s t a t u s " −> p l a y b a c k S t a t u s . t o S t r i n g ,
23 " v o l u m e " −> v o l u m e ,
24 " p o s i t i o n " −> p o s i t i o n
25 )
26 )
27
28 o v e r r i d e l a z y v a l s p e c i f i c a t i o n = new C o n t e n t S p e c i f i c a t i o n (
29 Map [ S t r i n g , A t t r i b u t e ] (
30 " i d " −> i d ,
31 " a g e n t I d " −> ( " V i d e o s t r e a m C o n t e n t A g e n t−"+ i d ) ,
32 " g r o u p s " −> g r o u p M a p ,
33 " p r o v i d e r " −> " V i d e o s t r e a m C o n t e n t P r o v i d e r " ,
34 " d e s c r i p t i o n " −> " D e s c r i p t i o n " ,
35 " u r l " −> u r l ,
36 " t y p " −> v i d e o T y p e
37 )
38 )
39 . . .
A. Anhang
40 o b j e c t S t a t e {
41 d e f g e t V o l u m e = g e t S t a t u s . g e t ( " v o l u m e " ) . map {
42 c a s e I n t V a l u e ( v a l u e : I n t ) = > v a l u e
43 c a s e _ = > 5 0
44 } . g e t O r E l s e ( 5 0 )
45
46 d e f s e t V o l u m e ( v o l u m e : I n t ) {
47 i m p o r t V i d e o s t r e a m C o n t e n t S e r i a l i z a t i o n . _
48 v a l v a l u e = I n t V a l u e ( v o l u m e )
49 u p d a t e S t a t u s A t t r i b u t e ( " v o l u m e " , v a l u e )
50 G r o u p s . V i d e o s t r e a m C o n t e n t . S t a t e ! V o l u m e C h a n g e d ( v o l u m e )
51 }
52 . . .
53 }
54
55 o v e r r i d e d e f r e c e i v e : R e c e i v e = s u p e r . r e c e i v e o r E l s e {
56 c a s e S e t V o l u m e ( v o l u m e : I n t ) = >
57 S t a t e . s e t V o l u m e ( v o l u m e )
58
59 c a s e G e t V o l u m e ( ) = >
60 . . .
61 r e p l y T o ( G r o u p s . r e p l y T o ( G r o u p s . V i d e o s t r e a m C o n t e n t ) )
62 ( V o l u m e ( S t a t e . g e t V o l u m e ) )
63 . . .
64 }
65 }
Literaturverzeichnis
[Eichler 2014] Eichler, Tobias:Agentenbasierte Middleware zur Entwicklerunterstützung in einem Smart-Home-Labor, Diplomarbeit, 2014. – URLhttp://users.informatik.
haw-hamburg.de/~ubicomp/arbeiten/master/eichler.pdf
[Kirchner 2014] Kirchner, Christian: Entwicklung eines kontextsensitiven Agen- ten zur Verwaltung und Verteilung von Informationen im Living Place (Projekt 1).
(2014). – URL http://users.informatik.haw-hamburg.de/~ubicomp/
projekte/master2014-proj/kirchner.pdf
