Desarrollo de Aplicaciones Móviles Sensibles al...

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

6

Fuente figura: https://www.interaction-design.org

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, "Context-

awareness 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