Kontextadaptivität in der modellbasierten App-Orchestrierung

Transkript

1 Kontextadaptivität in der modellbasierten App-Orchestrierung Johannes Pfeffer, Leon Urbas Professur für Prozessleittechnik TU Dresden Dresden Abstract: Kontextadaptivität hat in den letzten Jahren immer weiter an Bedeutung gewonnen. Wichtigster Treiber für diesen Bedeutungsgewinn ist die zunehmende Verbreitung von Mobilgeräten, die durch ihre Sensorik über Kontextinformationen verfügen. In diesem Artikel wird das Konzept der modellbasierten App- Orchestrierung vorgestellt, welches es ermöglicht mit spezialisierten Anwendungen für Mobilgeräte komplexe Aufgaben aus der Industrie zu unterstützen. Eine Referenzimplementierung des Konzeptes befindet sich derzeit in Entwicklung und wird im Rahmen des ComVantage FP7 EU-Projektes vorangetrieben. Die Implikationen der Berücksichtigung von Nutzungskontext für den Orchestrierungsprozess werden diskutiert, Herausforderungen identifiziert und mögliche Lösungsansätze aufgezeigt. 1 Einleitung Seit Anfang der 90er Jahre spielt der Nutzungskontext bei der Softwareentwicklung eine zunehmend wichtigere Rolle [BDR07]. Verstärkt wurde dies noch einmal durch das Aufkommen und die allgegenwärtige Nutzung mobiler Endgeräte. Dabei ist Kontext keineswegs eindeutig definiert [SL04]. Einige Beispiele für die Vielfalt möglicher Kontextinformationen sind die Position des Nutzers, Umgebungsparameter, also z.b. Temperatur, Lichtverhältnisse, Wetter, usw., verwendeter Gerätetyp, Nutzerrolle, verfügbare Kommunikationskanäle, gewählte Bedienmetapher und die Anwendungsdomäne, wie z.b. Industrie, Endverbraucher, Kraftfahrzeug, o.ä. (siehe z.b. [Sc99]). Welche Teile davon relevant sind, ist meist domänenabhängig. Auch Desktop-Software, die auf stationären Computern und nicht auf mobilen Geräten verwendet wird, ist normalerweise an den Nutzungskontext angepasst. Beispielsweise sind für Leitwarten Farbschemata, Dialoggestaltung und ähnliches in Normen vorgegeben um in dieser definierten Umgebung ein optimales Arbeiten zu ermöglichen (z.b. [VDI3699] oder [ISO ]). Oft werden solche Anwendungen speziell für einen wohldefinierten Kontext entwickelt und dann auch nur in diesem eingesetzt. Diese 2679

2 Form der statischen Kontextanpassung ist natürlich mit deutlich weniger Aufwand verbunden als eine dynamische Kontextanpassung. Viele Aufgaben, die früher in statischem Kontext durchgeführt wurden, wandern heute auf Mobilgeräten ins Feld und damit in veränderliche Umgebungsbedingungen. Oft werden sie weiterhin durch Desktopanwendungen abgedeckt, die dann unterwegs auf Notebooks genutzt werden, obwohl sie ursprünglich für den Kontext einer Leitwarte, also für große Bildschirme und Mausbedienung, optimiert wurden. Apps, also kleine spezialisierten Programme, die hauptsächlich auf Mobilgeräten genutzt werden, sind eine Alternative dazu, welche in den letzten Jahren stetig an Bedeutung gewonnen hat. Sie werden im Alltag bereits selbstverständlich verwendet um den Weg zum Tagungsort zu finden (Navigation), eine Verbindung im öffentlichen Personennahverkehr herauszusuchen (Datenbankabfrage), zur Kommunikation mit Freunden und Geschäftspartnern (Nachrichtenübermittlung) oder sogar für das Online Banking (Geschäftsprozessautorisierung). Diese Entwicklung hin zur Omnipräsenz der [Wi12, SAP12]. Durch die vorwiegende Nutzung von Apps auf Mobilgeräten, geht damit auch ein erheblicher Bedeutungsgewinn von Kontextinformationen einher. Nach einer Einführung in das Konzept der App-Orchestrierung beschäftigt sich dieser Artikel mit der Rolle von Kontext im Orchestrierungsprozess und aktuellen Forschungsfragen zu diesem Themenkomplex. 2 Das Konzept App-Orchestrierung 2.1 Motivation und Einordnung Das Konzept der App-Orchestrierung ermöglicht es, durch intelligentes zusammenschalten auch komplexe Arbeitsabläufe durch spezialisierte Apps zu unterstützen. Im Gegensatz zur Service-Orchestrierung [Er05] geht es bei der App- Orchestrierung um Anwendungen mit expliziter Benutzerschnittstelle. Es werden aber keine verteilten Benutzerschnittstellen orchestriert [Da10] sondern native Apps auf einem Mobilgerät. Die Programme sind dabei nur lose gekoppelt, d.h. sie sind auch eigenständig lauffähig und tauschen Informationen einzig über wohldefinierte Schnittstellen aus. Gegenüber monolithischen mobilen Anwendungen bringt dies eine Reihe von Vorteilen: Durch die formale Beschreibung von Apps wird es möglich sie in verschiedenen Arbeitsabläufen wiederzuverwenden. Apps können nach kontextabhängigen Kriterien gefiltert werden, z.b. hinsichtlich verifizierter Gebrauchstauglichkeit, Standardkonformität oder unterstützter Eingabemodalitäten. 2680

3 Das riesige Angebot vorhandener auch herkömmlicher kommerzieller Apps kann für Teilaufgaben eines Arbeitsablaufs genutzt werden indem sie formal beschrieben und dann in das App-Ensemble eingebaut werden. Es entsteht nur ein geringer Aufwand bei Änderungen in den Arbeitsabläufen, denn nur der Orchestrierungsprozess muss erneut durchgeführt werden. Bestehende Businessprozess- und Kontextmodelle können durch Modelltransformation in den Orchestrierungsprozess übernommen werden. Statt komplexer monolithischer Anwendungen, die einen hohen Einarbeitungsaufwand erfordern können, werden spezialisierte, aufgabenzentrierte Werkzeuge verwendet, die entsprechend der Arbeitsaufgabe verschaltet sind. Die Management-Komponente ermöglicht eine gesteuerte Benutzerführung während des Arbeitsablaufes. Innerhalb der Domäne der Automatisierungs- und Prozessleittechnik wurden wiederkehrende aufgaben- und datenspezifische Invarianten identifiziert, die durch generalisierte Apps (Generic Apps) bedient werden können. Jede Generic App ist dabei auf die Erfüllung eines bestimmten Informationsbedarfs auf Nutzer- oder Anbieterseite spezialisiert. Die in den Informationsbedarfen enthaltenen Invarianten können beispielsweise semantische Nachbarschaftsverhältnisse um einen Point of Interest, Positionsdaten, Ereignisse, Zeitreihen, Wartungspläne oder Aufgabenlisten umfassen. Diese Invarianten sind unveränderlich, während sich der Arbeitskontext und die zugehörige Aufgabe anwendungsabhängig ändern. Durch Konzentration auf solche Invarianten können Generic Apps auf vielfältige Weise wiederverwendet werden (siehe auch [Zi12]). 2.2 Grundlagen Das App-Orchestrierungskonzept umfasst drei Hauptschritte: Select (auswählen) Adapt (anpassen) Manage (verknüpfen & vermitteln) Im ersten Schritt werden die Invarianten der zu unterstützen Aufgabe identifiziert. Auf dieser Grundlage werden Apps ausgewählt, die diese Invarianten optimal bedienen. Als zweites werden die Datenanbindung, die Eingabemodalität und das visuelle Erscheinungsbild der Anwendungen kontextabhängig adaptiert. Im dritten und letzten Schritt wird das dynamische Navigationsdesign generiert, welches das dynamische Umschalten zwischen den Apps zu Laufzeit ermöglicht. 2681

4 2.3 Architektur Im Folgenden werden die Grundlagen der prototypisch implementierten Architektur des App-Orchestrierungskonzeptes vorgestellt (siehe auch [Pf13] und [Zi12]). Sie ist eingebettet in die Infrastruktur einer Virtual Factory ([GR12] und [EC12]) und besteht aus einer Design-Time- sowie einer Runtime-Komponente. Erstere übernimmt den eigentlichen Orchestrierungsprozess und wird außerhalb des Mobilgerätes durchgeführt (Abbildung 1). Letztere dagegen verwaltet die Umschaltung zwischen den Apps auf dem Gerät gemäß dem erstellten Navigationsdesign, sorgt für den Informationszugriff und ermöglicht die Inter-App-Kommunikation (Abbildung 2). Die Design-Time-Komponente wurde als Sammlung von Python-Skripten zur Orchestrierung und zur Übertragung des App-Ensembles auf das Mobilgerät realisiert, sie ist plattformunabhängig. Die Runtime-Komponente muss dagegen plattformspezifisch für das jeweilige Zielsystem implementiert werden. Die bisher existierende Referenzimplementierung wurde für die Android-Plattform ab API- Level 15 entwickelt. Dort bietet der Intent-Mechanismus 1 eine gute Grundlage für die Umsetzung des Orchestrierungskonzeptes durch gesteuerte App-Wechsel. Für ios kann auf URL-Schemes 2 zurückgegriffen werden und unter Windows Phone auf die Launcher und Chooser 3, wobei hier aufgrund des strikt forcierten Sandbox-Konzeptes Einschränkungen bestehen [Zh11]. Die eigentliche Orchestrierung findet zur Design-Time statt und greift auf den gemeinsamen Informationsraum der Virtual Factory zurück. Er basiert auf dem Linked Data Konzept [Be06] und wird durch einen SPARQL Endpoint [W3C08] zugänglich gemacht. Enthalten sind verschiedene für die Orchestrierung relevante Modelle (Workflow-, Task-, Rollen- und Kontextmodelle), verwendete Ontologien und die eigentlichen Unternehmensdaten. Diese Modelle sind im ComVantage Projekt in einem umfassenden Businessprozessmodel enthalten (siehe [BK13]). 1 Mehr Informationen zum Intent-Mechanismus befinden sich auf den Android Developer Seiten ( ). 2 Mehr Informationen in der ios Developer Library ( unter Implementing Custom URL Schemes. 3 Mehr Informationen zu Launcher und Choosers für Windows Phone sind im Windows Phone Dev Center zu finden ( 2682

5 Abbildung 1: Informationsfluss der App-Orchestrierung zur Designzeit In Abbildung 1 wird der Informationsfluss dargestellt, Funktionen werden durch Kreise, Eingänge und Ausgänge durch Rechtecke repräsentiert, auf den Kanten sind Informationsflüsse notiert. Die erste Funktion (Select) wird mit dem Aufgabenmodell, dem Kontextmodell und den App-Beschreibungen, die in einem App-Pool hinterlegt sind, gespeist. Die notwendigen Informationen über den benötigte Fähigkeiten und den Aufgabenkontext können gesondert modelliert oder wie bei ComVantage in einem Businessprozessmodel enthalten sein. Mit diesen Informationen können die passenden Generic Apps ausgewählt werden. Dies kann auch automatisiert geschehen; bei auftretenden Ambiguitäten, beispielweise Apps mit identischer oder sehr ähnlicher Funktion, ist jedoch ein manueller Eingriff notwendig. Ist für eine modellierte Aufgabe noch keine passende App im App-Pool vorhanden, so wird die Aufgabe übersprungen und später im Navigationsdesign als nicht unterstützt gekennzeichnet. Für diese Aufgabe kann dann zu einem späteren Zeitpunkt eine passende App entwickelt werden oder sie wird wie bisher ohne mobile Unterstützung durchgeführt. Auf diese Weise werden die Einstiegshürden gesenkt und Workflows ermöglicht, welche herkömmliche Arbeitsweisen mit mobiler Unterstützung verbinden. In der zweiten Funktion (Adapt), beginnt der Adaptionsschritt. Das Kontextmodell wird herangezogen, um das visuelle Erscheinungsbild anzupassen und die Interaktionsmodalität der gewählten Apps festzulegen. Außerdem werden die in den App-Beschreibungen hinterlegten SPARQL-Templates (siehe Abbildung 3) an die verwendete Ontologie adaptiert, so dass die passenden Klassen und Properties in der Abfrage verwendet werden. Das Resultat, ein Satz von Adapted Apps, wird an die nächste Funktion weitergereicht (Manage). Unter Verwendung des in den App-Beschreibungen definierten Interfaces und 2683

6 der modellierten Arbeitsabläufe, wird durch Modelltransformation das Navigationsdesign generiert. Arbeitsabläufe können auf verschiedene Art modelliert sein, beispielsweise als Businessprozessmodelle, wie in ComVantage, oder als Wartungsrundgänge in Engineering-Werkzeugen. Ein Beispiel für die Modellierung als Hierarchisches Aufgabenmodell findet sich in [Zi12]. Als Ergebnis der Orchestrierung, entsteht ein App-Ensemble, welches auf das mobile Gerät übertragen werden kann. Abbildung 2: Runtime-Komponenten der App-Orchestrierung. Die Bestandteile des App-Ensembles sind blau gezeichnet. Die Management-Komponente (Abbildung 2) ist zur Laufzeit für den Wechsel zwischen den orchestrierten Apps (App Switcher), für das Navigationsdesign (Navigation Design), für die Inter-App Kommunikation (Message Dash) und für den Zugriff auf den gemeinsamen Informationsraum (Linked Data Interface) zuständig; ein Linked Data Cache kann temporär auch das Arbeiten ohne Netzwerkverbindung ermöglichen. Der App Switcher nutzt das erstellte Navigationsdesign, um zwischen den Apps umzuschalten, das Message Dash dient zum Informationsaustausch zwischen Apps. Sie können dort Nachrichten bestehend aus einem Zeitstempel, der App-ID und einem einfachen Schlüssel-Wert-Paar hinterlegen. Typische Nachrichten sind URIs, die zum nächsten Point of Interest zeigen, generierte oder eingegebene Daten, die von der nächsten App benötigt werden, oder andere in der App-Beschreibung definierte Nachrichten. Alle SPARQL-Queries, die eine App ausführen möchte, werden durch das Linked Data Interface geleitet, welches sich beim passenden Linked Data Endpoint authentifiziert und die gewünschten Informationen abfragt oder aus dem lokalen Cache holt. 2684

7 3 Kontextanpassung 3.1 Kontextadaptivität in der App-Orchestrierung Der Nutzungskontext spielt zur Design-Zeit, also wenn das App Ensemble zusammengestellt wird, an zwei Stellen im Orchestrierungsprozess eine Rolle: a) Bei der Auswahl der Apps (Select Schritt). Hier wird sichergestellt, dass nur solche Apps gewählt werden, die die Kontextanforderungen erfüllen (kontextabhängige Filterung, beispielsweise die Unterstützung von Gesten als Eingabemodalität). b) Im Adaptionsschritt werden die Apps entsprechend ihrer Adaptionsfähigkeit an den Kontext angepasst. Die Möglichkeiten zur Kontextadaption, die ein App bietet, sind in ihrer formalen Beschreibung definiert. (beispielsweise Anpassung des Farbschemas an eine Corporate Identity oder Normkonforme Anordnung der Bedienelemente. Die Fähigkeiten und Schnittstellen der Apps im Pool werden mittels einer App Description Language beschrieben. Diese Domänenspezifische Sprache (DSL) basiert auf einer Ontologie, die derzeit entwickelt wird. Abbildung 3 zeigt einen beispielhaften Ausschnitt einer solchen App-Beschreibung in Turtle Notation [BB08]. Es ist zu beachten, dass sich Sprachelemente und Syntax noch in der Entwicklung befinden und zukünftigen Änderungen unterworfen sind. Zur Laufzeit, also während der Nutzung eines App-Ensembles, wird der aktuelle Kontext einerseits aus der Sensorik des Mobilgerätes gewonnen (Position, NFC-Tags, Lichtverhältnisse), andererseits aus dem Navigationsdesign des App-Ensembles entnommen, welches aus den modellierten Arbeitsabläufen generiert wurde. Beispielsweise wird bereits im Businessprozessmodell festgelegt, dass bei Arbeiten, die in voller Schutzkleidung durchgeführt werden müssen (Helm, Handschuhe, Gehörschutz) keine Touch-Bedienung sinnvoll ist [KN07], sondern auf alternative Eingabemethoden wie Gestenerkennung oder abgesetzte Eingabegeräte zurückgegriffen werden muss [ZPU11]. Die Kontextadaption einer App zur Laufzeit ist unabhängig vom Orchestrierungsprozess. Sie muss auf herkömmliche Weise bei der App-Entwicklung berücksichtigt werden. Eine Übersicht von Ansätzen hierzu findet sich in [HSK09]. 2685

8 @pr ef i x o: <ht t p: / / comvant age. eu/ 2013/ Or chest r at i on. owl #>. # URI of t he Gener i c App t hat i s descr i bed o: Si mpl eli st _l f ooqq ## Capabi l i t i es o: ser vesi nf or mat i onal I nvar i ant o: I nvsi mpl eli st ; o: ser vesi nt er act i onmodal i t y o: Gest ur ei nt er act i on; [... ] # SPARQL Templ at es o: hasspar ql Templ at e [ o: r el at edcapabi l i t y o: I nvsi mpl eli st ; o: t empl at est r i ng " " " PREFI X obj ect Ont ol ogy: %%%obj ect Ont ol ogy%%% SELECT?t i t l e WHERE {?s a obj ect Ont ol ogy: %%%l i st Ent i t y%%%; dc: t i t l e?t i t l e. } " " " ] ; [... ]. Abbildung 3: Vereinfachter Ausschnitt aus der formalen Beschreibung einer App zur Darstellung einfacher Listen. Im Abschnitt Capabilities wird auf Elemente der in Entwicklung befindlichen Ontologie der App Description Language verwiesen. Der Abschnitt SPARQL Template stellt ein Template zur Verfügung, welches den Abruf notwendiger Daten ermöglicht. 3.2 Quellen für Kontextinformationen Als Quellen für Kontextinformationen kommen für die App-Orchestrierung hauptsächlich folgende in Betracht: Existierende Businessprozessmodelle Ontologiebasierte Kontextmodelle Übergeordnetes Ziel bei der App-Orchestrierung ist es, möglichst mit bereits bestehenden Modellen, wie z.b. Businessprozessmodellen zu arbeiten [SN07]. Die Notwendigkeit komplexe Kontextmodelle für Arbeitsabläufe zu erstellen, würde die Hürden für eine Nutzung des Orchestrierungsansatzes erhöhen, da die Kosten für Modellierung nur schwer abzuschätzen sind. Muss der Kontext jedoch gesondert modelliert werden, sollten ontologiebasierte Methoden bevorzugt werden um die 2686

9 Nutzung der Semantik der Modelle im Orchestrierungsprozess zu ermöglichen. [MHW10] stellen einen solchen Ansatz vor, der auch in [Be10] gefordert wird. 4 Ausblick In diesem Workshop-Beitrag wurde das App-Orchestrierungskonzept und eine in Entwicklung befindliche Referenzimplementierung für die Android Plattform vorgestellt. Es wurde dargestellt an welchen Stellen Kontextinformationen in den Orchestrierungsprozess eingehen können und welche Rolle der Nutzungskontext zur Laufzeit spielt. Eine Herausforderung für die kommenden Monate ist es nun, die Kontextinformationen so zu nutzen, dass sie sinnvoll in den implementierten Orchestrierungsprozess integriert werden. Dazu werden hauptsächlich ontologiebasierte Modellierungsansätze betrachtet. Bestehende Kontextinformationen aus Businessprozessmodellen sollen durch Modelltransformation und Ontology-Matching in den Orchestrierungsprozess eingehen. Die Ergebnisse dieser Arbeit, sowie die weiterentwickelte App Description Language, sollen auf dem Workshop vorgestellt und diskutiert werden. Danksagung Die diesem Beitrag zugrundeliegenden Arbeiten wurden teilweise im 7. Rahmenprogramm der Europäischen Union (FP ComVantage) gefördert. Literaturverzeichnis [BB08] Beckett, D.; Berners-Lee, T.: Turtle - Terse RDF triple language. W3C Team Submission, [BDR07] Baldauf, M.; Dustdar, S.; Rosenberg, F.: A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing, 2007; Bd. 2, S [Be06] Berners-Lee, T.: Design Issues Linked Data, W3C Website, [Online]. Available: LinkedData.html [Be10] Bettini, C. et.al.: A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing, 2010; Bd. 6, S [BK13] Buchmann, R.; Karagiannis, D.: Modelling Collaborative-driven Supply Chains: The ComVantage Method, IFAC MIM In print. [Da10] Daniel, F., Soi, S., Tranquillini, S., Casati, F., Heng, C., & Yan, L.: From People to Services to UI: Distributed Orchestration of User Interfaces. In R. Hull, J. Mendling, & S. Tai (Eds.), Business Process Management, Springer, 2010; S [EC12] European Commission: Factories of the Future, Public Private Partnerships in research website,

10 [Er05] Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River, NJ, USA. Prentice Hall PTR, [Gr12] Graube, M. et.al.: Daten- und Werkzeugintegration mit Linked Data für die industrielle Datenverarbeitung. Tagungsband Automation 2012, VDI-Verlag, Düsseldorf, 2012; S [HSK09] Hong, J.; Suh, E.; Kim, S.-J.: Context-aware systems: A literature review and classification. Expert Systems with Applications, [ISO ] ISO : Ergonomische Gestaltung von Leitzentralen. Teil 5: Anzeigen und Stellteile. International Organization for Standardization, [KN07] Krausman, A. S.; Nussbaum, M. A.: Effects of wearing chemical protective clothing on text entry when using wearable input devices. International journal of industrial ergonomics, 2007; Bd. 37, S [MHW10] Moore, P.; Hu, B.; Wan, J.: Smart-context: A context ontology for pervasive mobile computing. The Computer Journal, 2010; Bd. 53, S [Pf13] Pfeffer, J. et.al.: Vernetzte Apps für komplexe Aufgaben in der Industrie. atp edition - Automatisierungstechnische Praxis, 2013; Bd. 55(3), S [SAP12] Sodhi, B.; Agrawal, A; Prabhakar, T. V.: Appification of web applications: Architectural aspects. 1st IEEE International Conference on Communications in China Workshops (ICCC), [Sc99] Schmidt, A.; Beigl, M.; Gellersen, H.-W.: There is more to context than location. Computers & Graphics, 1999; Bd. 23(6), S [SL04] Strang, T.; Linnhoff-Popien, C.: A context modeling survey. Workshop Proceedings of the First International Workshop on Advanced Context Modelling, Reasoning And Management at UbiComp, [SN07] Saidani, O.; Nurcan, S.: Towards context aware business process modelling. 8th Workshop on Business Process Modeling, Development, and Support (BPMDS), [VDI3699] VDI/VDE 3699: Prozessführung mit Bildschirmen, [W3C08] W3C: SPARQL Query Language for RDF, W3C Recommendation, [Wi12] Wing Kosner, A. 360 Million Web Sites. Forbes, [Zh11] Zhou, Z. et.al.: Windows Phone 7 Programming for Android and ios Developers. John Wiley & Sons, [Zi12] Ziegler, J. et.al.: Beyond App-Chaining: Mobile App Orchestration for Efficient Model Driven Software Generation. Proceedings of the 17th international IEEE Conference on Emerging Technologies & Factory Automation (ETFA), [ZPU11] Ziegler, J.; Pfeffer, J.; Urbas, L.: A mobile system for industrial maintenance support based on embodied interaction. Proceedings of the fifth international conference on Tangible, embedded, and embodied interaction, ACM,