Computacion-Sensible(...) - Departamento de Ciencias e

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