Desarrollo de Aplicaciones Móviles Sensibles al Contexto Lic. en Cs. de la Comp. e Ingeniería en Computación 4 – Desarrollo de Aplicaciones Sensibles al Contexto: Arquitecturas Depto. de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 1er. Cuatrimestre de 2016 Alcance de Sistemas Sensibles al Contexto • Cómo extraer y usar el contexto cognitivo (el estado interno) del usuario en una aplicación sensible al contexto? – La mayoría de los sistemas sensibles al contexto actuales son sensibles sólo al contexto físico. • Cuáles son los patrones de diseño para sistemas sensibles al contexto? – La compilación de una lista de patrones de diseño podrían ayudar a prevenir la resolución de problemas ya resueltos previamente. • Cuál es el mejor algoritmo de inferencia para extraer el contexto del usuario y proveerle servicios adecuados? – Diferentes algoritmos pueden ser adecuados para diferentes tipos de contextos, un mapeo entre ambos puede ser útil. 2 Alcance de Sistemas Sensibles al Contexto • Cómo lidiar con una enorme cantidad de datos concurrentes, información y conocimiento teniendo diferentes formatos para servir adecuadamente a los usuarios? – No es claro como integrar (en el caso general) diferentes aspectos de un contexto. • Cómo extraer la mejor solución cuando el contexto de los usuarios es conflictivo? – Ejemplos de inconsistencia: los sensores pueden proveer información inconsistente, un sistema puede tener múltiples usuarios con preferencias conflictivas. 3 Alcance de Sistemas Sensibles al Contexto • Cómo reflejar las preferencias usuarios para poder satisfacer sus necesidades y expectativas? – El usuario puede expresar explícitamente algunas preferencias, aunque idealmente estas deberían aprenderse y/o predecirse: a través del contexto y del perfil. • Qué información almacenar de los usuarios en sistemas sensibles al contexto? Cómo almacenarla? Dónde? – Determinar qué parte de la información debe guardarse para futuro y en que forma (sistemas de flujos de datos). – Existen problemas de seguridad, privacidad, autenticación. • Cómo evaluar la eficiencia de los sistemas sensibles al contexto? – Qué significa que un sistema sensible al contexto sea mejor que otro. 4 Contexto • El contexto tiene al menos dos dimensiones: – Interno vs. externo – Físico vs. lógico • El contexto puede adquirirse de diferentes maneras: – Sensores en el mundo externo – Infraestructura de middleware – Servidor de contexto • El contexto puede ser manejado de muchas maneras: – Con widgets – Servicios en red – Usando un modelo blackboard (solución colaborativa) 5 Framework conceptual en capas Fuente figura: https://www.interaction-design.org 6 Framework conceptual en capas • Sensores: – Físicos (gps, etc.) – Virtuales (calendario, emails, etc.) – Lógicos: combinación de sensores físicos y virtuales, bases de datos, etc. • Recuperación de datos crudos (raw-data): – Drivers y APIs se usan como interfaz entre los sensores. • Pre procesamiento: – No está implementado en todos los sistemas. – Abstracciones sobre átomos de contexto para proveer información agregada -> Tiene ventajas incluir un modulo especifico en el marco de la arquitectura. 7 Framework conceptual en Capas • Almacenamiento y Administración: – Organiza los datos y provee acceso a ellos vía una interfaz pública. – Los clientes pueden acceder a los datos de distintas maneras dependiendo de las necesidades: • sincrónicamente (polling) • Asincrónicamente (subscription) • Aplicación: implementa la parte del cliente. 8 Arquitecturas de Software • El diseño de la arquitectura es un paso muy importante en el desarrollo de cualquier sistema de información. • La arquitectura de un sistema se crea temprano en el proceso de desarrollo. • Permite la creación de un diseño de alto nivel que tiene en cuenta la realización de los requerimientos de implementación. • El diseño de la arquitectura de un Sistema sensible al contexto es especialmente importante. 9 Arquitecturas de Software • La sensibilidad al contexto es el principal facilitador de los sistemas de computación ubicuos. • La sensibilidad al contexto permite proveer proactivamente servicios adaptados al usuario y a aplicaciones de acuerdo al contexto global. • Un entorno ubicuo tiene características específicas que deben tenerse en cuenta en el desarrollo y la evaluación de arquitecturas sensibles al contexto. 10 Arquitecturas de Sistemas Sensibles al Contexto • Criterios de evaluación de arquitectura: – nivel de abstracción del contexto, – modelo de comunicación, – sistema de razonamiento, – extensibilidad y – reusabilidad. 11 Nivel de abstracción del contexto • Los sistemas ubicuos utilizan sensores de distintos tipos para percibir la información contextual. • La arquitectura de software debe ocultar la complejidad de los sensores físicos: – provee un nivel de abstracción más alto – Independencia de la capa física -> favorece la reusabilidad de los componentes de la arquitectura. 12 Sistema de razonamiento • Los sistemas ubicuos están compuestos por dispositivos proactivos que se adaptan a distintos contextos sin una intervención explicita del usuario. – Esto requiere que los dispositivos embeban un mecanismo de razonamiento que permita tomar la iniciativa para una adaptación adecuada. 13 Modelo de comunicación • Los dispositivos deben ser autónomos, independientes y pueden conectarse fácilmente. • El modelo de comunicación peer-to-peer parece ser el mas apropiado para los sistemas ubicuos. – Ofrece una manera fácil de conectar dispositivos y las redes pueden establecerse rápida y económicamente. – Permiten compartir fácilmente información contextual entre dispositivos. – No necesita materiales dedicados (servidores) o software especial (sistema operativo dedicado, sistemas de manejo de bases de datos DBMSs, etc.) 14 Extensibilidad y reusabilidad • Un Sistema ubicuo se caracteriza por su entorno rápidamente cambiante dado por la movilidad del Sistema. • Dispositivos pueden ser agregados y removidos dinámicamente sin afectar la operación global del Sistema. (extensibilidad de hardware). • La computación ubicua es un nuevo dominio de computación, sus arquitecturas deben proveer componentes reusables de manera que su integración se facilite y el esfuerzo de desarrollo se reduzca. 15 Modelamiento del Contexto • Un modelo contextual debe ser: – Simple y genérico – Flexible y extensible – Expresivo: los átomos de contexto deben contener al menos: – Tipo del contexto (temp., tiempo, velocidad, etc.) , valores de contexto: estampillas de tiempo, Fuente, confiabilidad, etc. – Cuanto más rico es el modelo mejor se puede capturar el contexto y disminuir la brecha de percepción -> puede aumentar la complejidad. • Modelos típicos: Key-Value, Markup scheme, modelos gráficos, modelos Orientados a Objetos, modelos basados en lógica, ontologias, etc. 16 CASS [1] • Middleware para el desarrollo de aplicaciones sensibles al contexto: – Provee buen nivel de abstracción de la información contextual. • Usa un modelo orientado a objetos para la descripción del contexto. • La arquitectura se basa en un servidor que contiene una DB de información contextual y una base de conocimiento con una maquina de inferencia para infiere información contextual. • Los dispositivos móviles están provistos de sensores que perciben la variación del contexto y la envían (wireless) al server local sin pre procesamiento. 17 CASS 18 CASS • EL servidor también contiene un modelo de interpretación de contexto -> más abstracción. • La arquitectura provee buena modularidad -> fácil modificación de los componentes del server (por ejemplo la máquina de inferencia). • Los dispositivos no realizan ningún procesamiento todo está hecho por el servidor: – Limita la autonomía necesario en un sistema ubicuo. – Promueve la extensibilidad del sistema -> agregar o remover dispositivos solo requieren una reconfiguración del server. • Buen nivel de abstracción dado por el modulo de interpretación y el de mecanismo de inferencia -> incrementa la proactividad. 19 CORTEX [2] • La arquitectura se basa en “objetos sensitivos” con las siguientes características: – Sensibilidad: la capacidad de percibir el estado del entorno circundante por medio del uso de sensores. – Autonomía: la capacidad de operar independientemente del control de un usuario humano de manera distribuida. – Proactividad: toma iniciativas para alcanzar metas deseadas. • Los objetos sensitivos tienen dos interfaces: – Sensado de eventos percibidos por los sensores físicos (sensor o consumidor). – Emisión de eventos para adaptarse al contexto actual (actuador o productor). 20 CORTEX 21 CORTEX • La parte central de la arquitectura está compuesta de: – Un modulo para la fusión e interpretación de la información contextual -> incrementar el nivel de abstracción. – Un modulo para una representación jerárquica del contexto que sirve para delimitar la situación actual de contexto y el conjunto de posibles acciones. – Una maquina de inferencia que especifica el comportamiento de la aplicación dado un cierto contexto. – La comunicación entre los objetos sensitivos, sensores y actuadores usan un mecanismo de comunicación basado en eventos que se establece dinámicamente durante la operación del sistema: • Usa el modelo de ejecución evento-condición-acción. 22 Marco de Manejo de Contexto (CMF)[3] • Permite razonamiento semántico sobre los contextos en tiempo real (aun en presencia de ruido e incertidumbre). • Entrega información contextual a las aplicaciones (modelo de comunicación basada en eventos). • Arquitectura basada en el estilo cliente/servidor: – Administrador de Contexto: almacena información contextual y entrega contextos a las aplicaciones clientes (pedido/respuesta, suscripción/notificación, etc.) – Servidor de recursos: adquiere la información contextual de los sensores físicos e interpreta la información (pre procesamiento) antes de mandarla al Administrador de Contexto. 23 Marco de Manejo de Contexto (CMF) 24 Marco de Manejo de Contexto (CMF) – Servicio de reconocimiento de contexto: convierte el flujo de datos a un representación definida por la ontología de contexto (descripción jerárquica). – Servicio de detección de cambios: detecta el cambio de servicio y por lo tanto el cambio de contextos. – Seguridad: verifica y controla la información contextual de acuerdo a las necesidades del cliente. • CMF usa una ontología para la representación del contexto pero no tiene modulo de razonamiento sobre contextos. • El mecanismo de interpretación de contextos provee Buena abstracción y mejora la reusabilidad. • Problema: dependencia del servidor Administrador de Contextos. 25 JCAF[4] • JCAF (Java Context awareness Framework) basado en Java. • Provee soporte para el desarrollo de aplicaciones sensibles al contexto. • La arquitectura de JCAF está compuesta de un conjunto de componentes llamados “servicios de contexto”. • Los servicios de contexto se comunican mediante un modelo peer-to-peer. • Son responsables de recolectar la información de contexto de un entorno particular (habitación, aula, laboratorio, etc.) 26 JCAF: Modulos de la arquitectura • Contenedor de Entidades: Contiene las entidades que describen el contexto de un entorno objeto (persona, computadora, doctor, paciente, etc.). – maneja el intercambio de contextos con los clientes de contexto (comunicación basada en eventos, suscripción/notificación). • Repositorio Transformador: se encarga de las operaciones de agregación de contextos y traducción entre tipos de contextos. • Entorno de entidades: permite la comunicación entre entidades y controla el acceso a los recursos compartidos. 27 JCAF: Módulos de la arquitectura • Control de acceso: administra el acceso a las entidades por medio de un protocolo de autenticación de clientes. • Listener de Entidad: puede ser una entidad de otro servicio de contexto y puede acceder al contexto de entidades de un servicio de contexto ya sea por mecanismo de pedido/respuesta o suscripción/notificación. • Monitor de Contexto: permite la adquisición de contextos por medio de los sensores (realiza un pre procesamiento). • Actuador de Contexto: permite comandar los actuadores del entorno físico. 28 JCAF • JCAF permite controles complejos sobre la información contextual: confiabilidad en la información sensada, probabilidad de error sobre la información sensada, etc. • La comunicación entre los componentes se realiza por medio de RMI de JAVA (remote method invocation). • Limitaciones de JCAF: – No posee un mecanismo automático de descubrimiento de contextos (alt. usar un archivo de configuración con todos los servicios de contexto activos -> limita la extensibilidad). – No posee un mecanismo de razonamiento sobre contextos. – JCAF no provee buena abstracción: no hay un componente que interprete los contextos explícitamente. 29 Context toolkit [5] • Context toolkit tiene una arquitectura en capas que permite separar la adquisición del contexto, la presentación y le proceso de adaptación. • Se basa en “widgets de contexto” que funcionan de manera similar a widgets de interfaz gráfica de usuarios, para poder esconder la complejidad de los sensores físicos. – Esta decisión de diseño provee buena abstracción y bloques reusables para el. 30 Context toolkit • La arquitectura de Context Toolkit esta compuesta por: – Sensores: sensando el contexto físico. – Widgets: encapsulan la información contextual y provee métodos para acceder a ella. – Interpretadores: transforman el contexto para proveer un alto nivel de abstracción. – Agregador: agrupa contextos de acuerdo a un usuario o situación. – Discoverer (descubridor): mantiene un registro de las capacidades actuales del framework (los componentes disponibles para el uso en aplicaciones). – Servicio: ejecuta acciones para las aplicaciones clientes. 31 Context toolkit 32 Context toolkit • Ventajas: – Fácil de implementar. – Modelo de comunicación peer-to- peer : ofrece comunicacion distribuida entre los dispositivos del sistema. – Widgets reusables. • Desventajas: – Mecanismo de descubrimiento centralizado -> extensibilidad limitada si crece el número de dispositivos. – La arquitectura monitorea eventos (para notificar la variación de contextos) usando un thread por cada evento -> sobrecarga del Sistema, afecta la eficiencia. – No contiene una capa o modulo para razonamiento de contexto: usa como modelo de contexto un mapeo de clave/valor. 33 Hydrogen [6] • Hydrogen es una arquitectura y un marco para sistemas sensibles al contexto: responde a requerimientos particulares de dispositivos móviles. • Hydrogen considera contexto a cualquier información pertinente en un entorno de aplicación y lo describe usando un modelo orientado a objetos. • Consiste de tres capas: adaptación, administración y aplicación. • El servidor de contexto (capa de administración): – Contiene toda la información sensada por los sensores de la capa de adaptación. – Provee contexto a la capa de aplicaciones del dispositivo conectado o servicios a otros dispositivos por medio de comunicación peer-to-peer. 34 Hydrogen 35 Hydrogen • La arquitectura puede implementarse fácilmente, es simple y tiene en cuenta los recursos limitados de los dispositivos. • La capa de adaptación no separa el sensado de la información contextual de la tarea de interpretación del contexto -> poca abstracción de contexto y limita la reusabilidad. • Alta dependencia con los sensores físicos. • La arquitectura no contiene un modulo de razonamiento sobre contextos (tenerlo ayudaría a hacer mas fácil la tarea de adaptación). 36 SOCAM [7] • SOCAM es una arquitectura de middleware sensible al contexto orientado a servicios: diseñada para construir y realizar prototipos rápidamente de servicios móviles sensibles al contexto en un auto inteligente. • Los componentes de la arquitectura son: proveedor de contexto, interpretador de contexto, razonador de contexto y conocimiento general, servicio de ubicación de servicios, servicio móvil sensible al contexto, y base de datos de contexto. • La arquitectura sigue un estilo cliente/servidor: – El interpretador de contexto adquiere información contextual de los proveedores de contexto (internos o externos) y de la base de datos de contextos, y los provee a los servicios de ubicación de servicios y de sensibilidad al contexto. 37 SOCAM • El punto mas fuerte de SOCAM es su razonador de contexto: − Utiliza ontologías para describir contextos: especificas al dominio y generales. − Permite razonamiento robusto sobre contextos. − Distintos sistemas de razonamiento para ontologías pueden integrarse fácilmente en el interpretador de contexto para proveer una colección variada de tareas de razonamiento. 38 SOCAM 39 SOCAM • La arquitectura fue diseñada para el desarrollo de aplicaciones pequeñas no distribuidas -> limita su uso para un rango mas amplio de sistemas ubicuos. • El interpretador de contexto se puede sobrecargar cuando se utilizan diferentes ontologías de dominio ricas en representación de conocimiento -> el funcionamiento global del Sistema puede verse afectado. • Como todo arquitectura centralizada contradice la naturaleza de los sistemas ubicuos: sistema distribuido con dispositivos autónomos. 40 Arquitectura CoBrA [8] • CoBrA es una arquitectura basada en un agente de bolsa (broker agent) para el desarrollo de aplicaciones sensibles al contexto en un espacio inteligente. • El agente es un agente autónomo que administra y controla el modelo de contexto de un dominio específico. • Corre en una computadora dedicada (servidor) con muchos recursos de computo. • El agente contiene una arquitectura en capas con los siguientes componentes: conocimiento de contexto, maquina de razonamiento de contexto, modulo de adquisición de contextos, y modulo de administración de privacidad. 41 The CoBrA architecture 42 Arquitectura CoBrA • El agente adquiere diferentes contextos de los dispositivos, otros agentes y sensores y los fusiona en un modelo coherente que comparte entre los dispositivos y sus correspondientes agentes. • CoBrA usa ontologías para la descripción del contexto: – Poder de razonamiento mas rico. – Facilita el intercambio de información contextual. • Usa un modelo centralizado para almacenamiento y procesamiento para conservar los recursos limitados de los dispositivos pero implementa una política de confidencialidad para los usuarios. • La arquitectura requiere un server dedicado para el agente -> incremento de costos y limita la usabilidad. 43 Comparación de Arquitecturas 44 Comparación de Arquitecturas 45 Referencias Parte de esta presentación fue tomada de: Michael Maynord – University of Maryland College Park: “Context-Aware Systems”. Clase Sprin 2014. [1] P. Fahy, S. Clarke, "CASS – a middleware for mobile context-aware applications", Workshop on Context-Awareness,MobiSys 2004. [2] G. Biegel, V. Cahill, "A framework for developing mobile, context-aware applications", Proceedings of the 2nd IEEE Conference on Pervasive Computing and Communication, pp.361– 365, 2004. [3] P. Korpipää, J. Mantyjarvi, J. Kela, H. Keranen, E-J. Malm, "Managing context information in mobile devices", IEEE Pervasive Computing, Vol. 2, No. 3, July– September, pp.42–51, 2003. [4] J. E. Bardram, "The Java Context Awareness Framework (JCAF) – A Service Infrastructure and Programming Framework for Context-Aware Applications", Proceedings of the 3rd International Conference on Pervasive Computing, vol 3468 of Lecture Notes in Computer Science, pages 98–115. Springer Verlag. [5] A. Dey, G. D. Abowd, and D. Salber, "A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications", Human- Computer Interaction, 16:97–166, 2001. 46 Referencias [6] T. Hofer, W. Schwinger, M. Pichler, G. Leonhartsberger, J. Altmann, "Contextawareness on mobile devices – the hydrogen approach", Proceedings of the 36th Annual Hawaii International Conference on System Sciences, 2002 pp.292–302. [7] T. Gu, X H. Wang, H. K. Pung, D. Q. Zhang. "A Middleware for Context-Aware Mobile Services", IEEE Vehicular Technology Conference. Milan, Italy, 2004. [8] H. Chen, "An Intelligent Broker Architecture for Pervasive Context-Aware systems", PhD Thesis, University of Maryland, Baltimore County, 2004. [9] Beza Mamo, Dejene Ejigu, “A Generic Layered Architecture for Context Aware Applications”, Procedia Computer Science, Volume 34, 2014, Pages 619-624, ISSN 1877-0509. [10] Jong-yi Hong, Eui-ho Suh, and Sung-Jin Kim. 2009. “Context-aware systems: A literature review and classification”. Expert Syst. Appl. 36, 4 (May 2009), 8509 [11] Matthias Baldauf, Schahram Dustdar, and Florian Rosenberg. 2007. “A survey on context-aware systems”. Int. J. Ad Hoc Ubiquitous Comput. 2, 4 (June 2007), 263- 277. 47