perfilamiento y recuperaciÓn de contexto como parte …
TRANSCRIPT
PERFILAMIENTO Y RECUPERACIÓN DE CONTEXTO COMO PARTE DE UN FRAMEWORK
PARA EL DESARROLLO DE APLICACIONES MÓVILES PERVASIVE. CASO DE ESTUDIO:
ADMINISTRACIÓN DE CLANES DE JUGADORES (GAMERS)
FABIÁN ANDRÉS GÓMEZ MENESES
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C.
ENERO 2011
PERFILAMIENTO Y RECUPERACIÓN DE CONTEXTO COMO PARTE DE UN FRAMEWORK
PARA EL DESARROLLO DE APLICACIONES MÓVILES PERVASIVE. CASO DE ESTUDIO:
ADMINISTRACIÓN DE CLANES DE JUGADORES (GAMERS)
FABIÁN ANDRÉS GÓMEZ MENESES
Trabajo de grado presentado como requisito para optar al título de
Pregrado en Ingeniería de Sistemas y Computación
Director: Claudia Lucía Jiménez Guarín
Profesor asociado
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C.
ENERO 2011
Hasta ayer era demasiado grande para ser niño.
Hoy tengo una muñeca vestida de lila y no quiero crecer.
2
Índice general
0. Resumen 9
1. Introducción 101.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Descripción general 122.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. Contexto y sensibilidad al contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3. Perfilamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. El Framework 183.1. Aspectos generales del Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Capas Framework pervasive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1. Information Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2. Context-Aware Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Context-Aware User Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.4. Convergence Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5. Orchestration Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.6. Linking Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.7. Privacy Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.8. Translator Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.9. Business Logic Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.10. Interaction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Capas Context-Aware: Diseño 234.1. Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3
4.2. Módulos User Context y Application Context . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1. ContextManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2. UserContextManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. ApplicationContextManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.4. ContextState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.5. MonitorDaemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.6. ContextMediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.7. ContextEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.8. ContextException . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.9. TestingCanvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.10. BTexplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.11. IAPInfoProvider e IAPInfoImplementation . . . . . . . . . . . . . . . . . . . . . . 28
4.3. Módulo User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1. UserProfileManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2. BasicUserProfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3. SecondaryUserProfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.4. IField, Field y FieldMulti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4. Módulo Application Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1. ApplicationProfileManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2. Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.3. ApplicationProfileFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.4. ApplicationProfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.5. UserPermissionsSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.6. RequirementsException . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5. Capas Context-Aware: Funcionamiento 385.1. Módulos User Context y Application Context . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.3. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Módulo User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.3. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3. Módulo Application Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.3. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4
6. Capas Context-Aware: Implementación 566.1. Tecnologías Empleadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7. Caso de Estudio: GCom 587.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2. Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2.1. Administración de clanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2.2. Acceso al contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2.3. Funcionalidades adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3. Cliente Gcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3.1. GComMobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.2. XMLHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.3. AlarmDaemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.4. IPosterListener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.5. ForumPoster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.6. NewsPoster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4. Integración con el Framework Pervasive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.4.1. Uso de los Módulos Context-Aware . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.4.2. Uso de otros Módulos del Framework . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.5. Servicios web GNews y GForum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.5.1. GNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.5.2. GForum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8. Validación, Resultados y Pruebas 738.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.2.1. Comparación de tamaño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.2.2. Tiempos de consulta a fuentes de contexto . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.3. Uso memoria primaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.4. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.5. Discusión de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.6. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9. Conclusiones 76
A. Anexos 77
5
Índice de figuras
3.1. Evolución computación Pervasive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Arquitectura Framework Pervasive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Diagrama de clases general Módulos de contexto. . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Diagrama de clases detallado Módulos User Context y Application Context. . . . . . . . . . 26
4.3. Diagrama de clases ContextEvent y ContextException. . . . . . . . . . . . . . . . . . . . . 27
4.4. Diagrama de clases componentes adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5. Proceso de reconocimiento de contexto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. Diagrama de clases Módulo User Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7. Diagrama de clases Módulo Application Profile. . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Casos de uso Módulos Context Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Diagrama de secuencia para consulta de fuentes de contexto (pull). . . . . . . . . . . . . . . 41
5.3. Diagrama de secuencia para suscripción a fuentes de contexto (push). . . . . . . . . . . . . 42
5.4. Casos de uso perfiles básicos de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5. Casos de uso perfiles secundarios de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6. Diagrama de secuencia para creación de un perfil básico de usuario. . . . . . . . . . . . . . 49
5.7. Diagrama de secuencia para creación de un perfil secundario de usuario. . . . . . . . . . . . 50
5.8. Casos de uso Módulo Application Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.9. Diagrama de secuencia para la creación de un perfil de aplicación. . . . . . . . . . . . . . . 54
5.10. Diagrama de secuencia para la creación de conjuntos de permisos. . . . . . . . . . . . . . . 55
7.1. Diagrama de clases GCom Mobile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Diagrama de clases GCom Mobile -detalle atributos. . . . . . . . . . . . . . . . . . . . . . . 61
7.3. Código creación perfil de usuario en GCom Mobile. . . . . . . . . . . . . . . . . . . . . . . 63
7.4. Nombre del servidor en GCom Desktop para uso de reconocimiento bluetooth . . . . . . . . 64
7.5. Configuración reconocimiento bluetooth en GCom Mobile. . . . . . . . . . . . . . . . . . . 64
7.6. Configuración roles usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.7. Menú principal rol clanmate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.8. Menú principal rol clanleader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.9. Configuración perfiles secundarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.10. Extracto (1) método saveSettings en GComMobile. . . . . . . . . . . . . . . . . . . . 68
6
7.11. Extracto (2) método saveSettings en GComMobile. . . . . . . . . . . . . . . . . . . . 68
7.12. Extracto método loadSettings en GComMobile. . . . . . . . . . . . . . . . . . . . . 68
7.13. Nueva entrada para GNews en operations.xml. . . . . . . . . . . . . . . . . . . . . . . 69
7.14. Nueva entrada para GNews en services.xml. . . . . . . . . . . . . . . . . . . . . . . . 69
7.15. Diagrama de clases GNews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.16. Diagrama de clases GForum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.1. Histórico de uso de CPU durante una de las pruebas. . . . . . . . . . . . . . . . . . . . . . 75
7
Índice de cuadros
4.1. Requerimientos de APIs evaluados por el Módulo Application Profile . . . . . . . . . . . . 35
4.2. Requerimientos de permisos evaluados por el Módulo Application Profile . . . . . . . . . . 36
7.1. Configuraciones perfiles secundarios GCom Mobile . . . . . . . . . . . . . . . . . . . . . . 66
7.2. Categorías de noticias en GNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1. Aporte relativo al tamaño del archivo jar de GCom Mobile . . . . . . . . . . . . . . . . . . 73
8.2. Comparación tiempo retorno de getEntries en GNews . . . . . . . . . . . . . . . . . . . . . 74
A.1. Listado fuentes de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.2. Métodos módulos User Context y Application Context . . . . . . . . . . . . . . . . . . . . 81
A.3. Métodos Módulo User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.4. Métodos Módulo Application Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.5. Conjuntos predefinidos de requerimientos de APIs para el Módulo Application Profile . . . . 88
8
Capítulo 0
Resumen
Las tendencias en computación omnipresente (en inglés pervasive1) constituyen un campo joven cuya
prosperidad depende de la disponibilidad de herramientas que optimicen el desarrollo y despliegue de las
soluciones. La heterogeneidad de los ambientes de ejecución y la limitada disponibilidad de ayudas para
los programadores se erigen así como un obstáculo para la definición clara de las fronteras y geografía
pervasive. Este trabajo presenta el diseño e implementación de los módulos de perfilamiento y contexto,
parte de un Framework para el desarrollo de aplicaciones pervasive en dispositivos móviles. Un caso de
estudio relacionado con la comunicación entre jugadores demuestra la aplicabilidad del Framework.
1En este texto se empleará el término en inglés, por considerar que no existe en español una palabra que capture el sentido deltérmino original
9
Capítulo 1
Introducción
The most profound technologies are those that disappear.
They weave themselves into the fabric of everyday life
until they are indistinguishable from it. [Wei99, 3]
Con una mayor difusión de los llamados “celulares inteligentes” las aplicaciones móviles han logrado cierta
visibilidad en la vida cotidiana. Y con el despliegue de aplicaciones “inteligentes” en un sentido más amplio
que el computacional, estamos ad portas de la incipiente realización del ambicioso proyecto de la compu-
tación pervasive. Una solución de este tipo es aquella que logra adaptarse al perfil del usuario, al dispositivo
donde se ejecuta, al lugar donde está, o a las condiciones de su entorno, haciendo invisible la complejidad
computacional al usuario. De acuerdo a algunos autores el campo en cuestión adopta cuatro paradigmas fun-
damentales: decentralización, diversificación, conectividad y simplicidad [HMNS03, 17]. Estos principios,
como promesas y visiones, suelen entrar en conflicto con las limitaciones de los dispositivos y ambientes
reales donde se despliega el software, imponiendo restricciones en dimensiones específicas que incluyen
sensibilidad al contexto y capacidad de adaptación.
1.1. Motivación
En el contexto antes planteado resultan deseables herramientas que asistan en el desarrollo y desplie-
gue de aplicaciones adscritas al campo de la computación pervasive. Por ello el desarrollo de plataformas
basadas en componentes reutilizables puede ser considerado un paso avante en el sendero trazado por Wei-
ser. Tales componentes no sólo deben hacer viable la transición entre aplicaciones móviles y sensibles al
contexto, sino que han de proveer además cimentación para una adaptación efectiva del comportamiento
de las aplicaciones. Este comportamiento -y tal es la pretensión y horizonte- es congruente con el propio
comportamiento del usuario.
Los retos que suscita una adaptación frente a las dimensiones cambiantes del usuario y su entorno, resultan
más interesantes en cuanto se consideran las posibilidades subyacentes: software que se convierte en una
extensión de nuestras vidas, una herramienta cuya índole es imposible discernir, tal es su transparencia en
10
la provisión de servicios.
1.2. Descripción del problema
El presente proyecto, enmarcado en una empresa mayor como lo es la iniciativa Pervasive Solutions
de la Universidad de los Andes, pretende implementar los componentes de contexto y perfilamiento de
un framework de tipo pervasive, centrado en celulares inteligentes. Proyectos coetáneos se ocupan de los
aspectos de persistencia, localización y administración de servicios. En conjunto estas partes conforman una
caja de herramientas (en tanto servicios desacoplados) y un soporte tangible para esa computación pervasive
que tiene lugar en celulares, bastión saliente de la miriada de artefactos con potencial “weiseriano.”
Los temas de contexto y perfilamiento, en su relación con el usuario y su entorno, generan un extraordinario
entramado de información heterogénea. En su adecuada obtención e interpretación se halla una fuente casi
inagotable de adaptación para las aplicaciones, ya no móviles, sino pervasive. No sólo se trata entonces de
recuperación de la información de sensores, sino antes bien de su traducción con sentido y su representación
útil como contextos múltiples. Esta reconstrucción de contextos articula las limitaciones reales ajenas a los
laboratorios y proyectos ad-hoc.
1.3. Estructura del documento
La estructura de este escrito sigue un orden de creciente especificidad. Tras la breve introducción a la
que corresponden estas líneas la segunda sección resume los resultados de un proceso de revisión bibliográ-
fica, que traza las fronteras y define el terreno al que se remiten los presentes desarrollos. A continuación, el
capítulo tres presenta el Framework en su diseño global. Los apartados al pie ahondan en las capas Context-
Aware, siendo transversales y frecuentes en todo ello las referencias a los componentes adicionales del
Framework, complemento de la funcionalidad ofrecida por los módulos de manejo de contexto y perfila-
miento.
El capítulo cuatro resume las consideraciones de diseño de estas capas, hallándose el detalle del funcio-
namiento e implementación en los capítulos cinco y seis, respectivamente. El capítulo siete se ocupa del
caso de estudio, GCom, como aplicación del Framework y específicamente de las capas Context-Aware.
Finalmente los capítulos ocho y nueve, de validación y conclusiones, cierran el documento resumiento los
hallazgos del proyecto.
11
Capítulo 2
Descripción general
Se presentan en este capítulo aspectos generales de los temas de perfilamiento y sensibilidad al contexto.
Acompañándolos y estableciendo parámetros de evaluación están los objetivos del proyecto.
2.1. Objetivo general
El proyecto del cual hace parte este documento busca implementar los módulos de perfilamiento y
contexto de un Framework que soporte el desarrollo de aplicaciones pervasive, en su primera versión. Como
parte de la validación de los susodichos componentes se implementa una aplicación de ejemplo que hace
uso no trivial de aquellos, y de los restantes módulos que se integran en el marco antes referido.
2.2. Objetivos específicos
Elaborar el diseño de los módulos de perfilamiento y contexto, integrando soluciones realizables frente
a las cuestiones de gestión de información de usuarios y aplicaciones, y adquisición y provisión de
información de contexto.
Implementar los módulos de perfilamiento y contexto, parte de un desarrollo conjunto de la primera
versión del Framework Pervasive.
Emplear los módulos del Framework desarrollados en este y los proyectos asociados en una aplicación
móvil con rasgos pervasive, identificando los beneficios y desventajas frente a una solución no asistida
por estos componentes.
2.3. Antecedentes
2.3.1. Arquitectura
Un breve sondeo de las plataformas que respaldan desarrollos en computación pervasive pone en evi-
dencia -además de su frecuente estado inédito- su heterogeneidad saliente, siendo amplísimo el espectro de
12
los casos (tanto en alcance y forma de las soluciones, como en requerimientos sobre espacios y dispositivos).
Los servicios para administrar contextos y perfiles, así como los procesos de adquisición y traducción de
contexto por un lado, y de perfilamiento por otro, comparten este carácter dispar. Se examinan aquí temas
y autores en la literatura existente, como preparación para la comprensión del abordaje adoptado en este
proyecto.
La tecnología de agentes al servicio de la computación pervasive se halla en [YOH03], donde se propone
su uso para afrontar cambios tanto en el contexto del usuario como en los servicios consumidos por este. Se
definen allí tres nuevos tipos de agentes en un sistema distribuido, frente al modelo three-tier y el cliente-
servidor, considerados insuficientes.
Una orientación distinta sigue OpenZoo, un proyecto local con piloto en el Zoológico de Cali y que aco-
ge una arquitectura orientada a servicios, elegida por la posibilidad de reutilización en otros contextos
[ZMA+10]. De acuerdo a una breve revisión bibliográfica realizada como parte de la exploración, se identifi-
can tres tendencias en SOA aplicado al diseño de sistemas pervasive urbanos: sistemas basados en ubicación,
sistemas con énfasis en contexto social, y sistemas con uso extendido de sensores.
Con base en el modelo conceptual PSP (Public Social Private, propuesto por Vassilis Kostakos y probado
en el proyecto Cityware) y en trabajo etnográfico en el Zoológico, se plantea una arquitectura con cinco
componentes, con las siguientes responsabilidades: provisión y orquestación de servicios, localización, con-
tenidos multimedia, contexto social, y perfilamiento de usuario. Esta última tarea corresponde a un “agente
urbano”, que en interacción directa con el usuario le permite acceder a preferencias personalizadas.
La arquitectura seleccionada para el Framework Pervasive, basada en servicios reutilizables, se muestra cer-
cana a la de OpenZoo incluso en su asignación de responsabilidades. De igual manera, en estos trabajos se
evidencia ya la relevancia de componentes o agentes dedicados a las labores de perfilamiento y manejo de
contexto.
[CQS06] presenta un Service-Oriented Adaptive Framework (SOAF) como un framework a nivel de capa de
aplicaciones con tecnología de proxies y mecanismos contextuales para conservar los estados de un usuario
cuando este migra de un dispositivo a otro, o se desconecta. SOAF incluye tres componentes, a saber:
Sistema proxy del cliente: actúa como mediador entre las peticiones y respuestas que fluyen entre
el administrador de servicios y los usuarios, empleando los contextos para restaurar los ambientes
previos de estos últimos. Incluye un módulo de invocación de contexto (que accede a los contextos en
el manejador de contextos o en el buffer) y un buffer de contexto (que almacena temporalmente los
contextos de los usuarios que han usado el proxy).
Sistema de administración de contexto: asiste a los proxies en la adaptación del framework. Incluye
una base de datos de contextos con registros de las peticiones de los usuarios.
Sistema de administración de servicios: es responsable de las peticiones, registro y acoplamiento de
los web services.
Del abordaje de SOAF se rescata el uso de un proxy de contexto, si bien allí se asume un carácter más
o menos estático del contexto. En ello difiere la aproximación aquí presentada, al considerar un contexto
eminentemente dinámico y por tanto no afín a persistencia en bases de datos. Así, la instrumentalización
13
como concepto de la palabra “contexto” depende de una definición explícita y apropiada, que evada la
ambigüedad y vaguedad de su uso coditiano.
2.3.2. Contexto y sensibilidad al contexto
En un artículo seminal de Dey [DA01] se define “contexto” como “cualquier información que puede
ser usada para caracterizar la situación de entidades (i.e. sea una persona, lugar, u objeto) que son con-
sideradas relevantes para la interacción entre un usuario y una aplicación, incluyendo al propio usuario y
a la aplicación. Contexto es usualmente la ubicación, identidad, y estado de personas, grupos, y objetos
computacionales y físicos”1. Los autores señalan que el manejo de contexto suele corresponder a un bajo
nivel (sensores de hardware y software), y restringirse a la localización. Por ello se presentan herramientas
conceptuales para acercarse a la visión de Weiser. Se introduce también una categorización de información
de contexto, que puede corresponder a identidad, ubicación (location), estado (o actividad), y tiempo. Y los
servicios o funciones sensibles al contexto estarían agrupados en: i) presentación de información y servicios;
ii) ejecución automática de servicios; iii) información de contexto adjunta para recuperación posterior.
Debido a este concepto de “contexto” la obra de Dey constituye fuente de consulta obligada para todo
proyecto que aborde el tema. El presente trabajo no es la excepción, siendo particularmente relevante la
identificación que efectúa de entidades relevantes para la reconstrucción de contexto (las cuales llamará
“Entidades de Interés” o EoI por sus siglas en inglés).
En otro artículo de Dey [BD03] se evalúan tres niveles de interactividad: personalización, passive context-
awareness, y active context-awareness. Aplicando método experimental en un caso de estudio se concluye
que una renuncia parcial al control del comportamiento de la aplicación es admisible si los servicios ofre-
cidos por la aplicación mejoran (con respecto a un enfoque no interactivo de personalización). El manejo
de contexto implementado en el presente proyecto, y sus vías pull y push de adquisición de información de
contexto, adhieren a estos tres niveles de personalización. La elección depende entonces del desarrollador-
usuario del Framework.
Ahora bien, el término context-awareness proviene de un artículo publicado por Schilit y Theimer [ST94],
hallándose una definición operativa en [Pol10]. El autor la asocia con la capacidad para asistir a los usuarios
en sus objetivos sin su intervención explícita, infiriendo el contexto a partir de sensores físicos (e.g. acelera-
ción, intensidad de luz), virtuales (e.g. calendario, contenido de correos electrónicos) y lógicos (e.g. bases de
datos). Rescata de la literatura el término “contexto intencional” (intentional context) que describiría lo que
el usuario ha estado haciendo y lo que se dispone a hacer. El concepto de “situación” es introducido como
“el estado global en un instante del tiempo, abarcando múltiples entidades con sus respectivos contextos”
[Pol10, 123].
Polzinetti menciona la dificultad que supone construir sistemas context-aware, debido a la ausencia de un
middleware o framework que apoye la labor de desarrollo. Un modelo de contexto -afirma- sería central para
soportar estas tareas, entendido como una representación del conocimiento sobre el mundo real asimilable
por un computador y transformable por este en contextos de alto nivel. El proceso de administración de
contexto, a su vez, comprendería adquisición, descubrimiento, agregación, y distribución.
1Traducción personal.
14
El diseño de los módulos de contexto acoge la idea de situación para otorgar sentido a la agregación de
información de los sensores, junto con el principio general de transparencia por el que parece abogar Polzo-
netti.
[YJ10] integran en su propuesta de un modelo de privacidad conceptos propios de “contexto de aplicación”
y “contexto de usuario”. El primero de estos es presentado como los factores que describen el ambiente
técnico de ejecución de la aplicación, tales como volumen, procesamiento en primer o segundo plano, y tipo
de red. El contexto de usuario a su vez son factores que describen lo que el usuario puede estar haciendo o
esperando en un momento dado del tiempo. Un concepto adicional, “contexto externo”, describe el ambiente
circundante del usuario, asociado a condiciones tales como días hábiles o feriados, horas de trabajo y clima.
2.3.3. Perfilamiento
En lo que respecta a perfilamiento de usuarios [Pol10] identifica dos tipos de perfiles: un perfil básico
y uno extendido. El primero contiene información sobre la identidad del usuario, con datos objetivos como
nombre, dirección, edad, género y correo electrónico. El segundo por su parte corresponde a datos y prefe-
rencias dependientes del contexto, incluyendo además los perfiles del dispositivo. Estos últimos, a su vez,
cambian de acuerdo a las preferencias de usuario.
Basado en la especificación de la ETSI (European Telecommunications Standards Institute) el autor men-
ciona las propiedades que ha de incluir un perfil de usuario: nombre del perfil, datos operativos centrales
(preferencias, configuraciones y reglas), criterio de activación, criterio de desactivación. Estas guias de dise-
ño, y el establecimiento de un perfil múltiple, están incorporadas en los módulos de contexto y perfilamiento
de este proyecto.
[Góm10] rescata y aplica de la revisión de la literatura una definición de estado del contexto conrrespondien-
te al conjunto de características del usuario en cuanto tal y las características de su entorno en un momento
específico.
Otros autores ([CRVOG07]) parten de una personalización y adaptación basadas en “contexto de uso” y
“preferencias de usuario”. El primero es definido como un conjunto de, por un lado elementos como ubi-
cación, tiempo de conexión y aplicación en primer plano, y por otra parte, los objetivos e intenciones del
usuario durante una sesión de búsqueda de información. Los autores se centran en generar un concepto de
preferencias de usuario compatible con un modelo operativo de adaptación para Web Information Services
en dispositivos móviles.
Allí se propone un CPMS (Contextual Profile Management System) como componente de adaptación de la
información. A partir de un perfil de usuario -entendido como conjunto de preferencias de usuario-, y del
contexto de uso, tal componente filtra las preferencias relevantes al contexto mediante un algoritmo CMA
(Contextual Matching Algorithm). Las preferencias seleccionadas se integran en un artefacto, el CUP (Con-
textual User Profile), “representación realista de aquellas preferencias de usuario a las cuales debe adaptarse
la información, i.e. i) al usuario considerando el contexto de uso y ii) a tal contexto” [CRVOG07, 339].
La relación entre un perfil de usuario y su contexto en un perfil contextual de usuario se refleja en el diseño
del manejador de perfiles de usuario del Framework. Este, haciendo uso de una aproximación simplificada
frente a CMA, filtra por contexto preferencias y las activa bajo la forma de perfiles secundarios de usuario.
15
En [CRVOG07] se definen así mismo las preferencias de usuario como expresiones que traducen los deseos
del mismo, correspondiendo a tres tipos: preferencias de actividad, preferencias de resultado y preferencias
de visualización. Las primeras se relacionan con las actividades, consistiendo cada una en un conjunto de
funcionalidades. Las preferencias de resultado corresponden al filtrado y ordenamiento del producto de la
ejecución de las funcionalidades, esto es, del contenido. Finalmente las preferencias de visualización están
asociadas a la forma en la que el usuario desea desplegar la información en su dispositivo (apariencia y
formatos). Los tres tipos de preferencias se clasifican en generales y específicas, de acuerdo a si aplican para
todas las sesiones o exclusivamente a la sesión actual.
[YJ10] también introducen conceptos a la medida de perfil, separando un perfil de usuario, un perfil de apli-
cación y un perfil de información. El perfil de usuario es configurado por el usuario final y es inaccesible
para el desarrollador. Uno de tales perfiles para una aplicación constaría de un MaxDT (o factor de toleran-
cia) y varios multiplicadores. Estos últimos factores multiplican otros factores en otros perfiles y contextos
para efectos del cálculo de una función de tolerancia).
El perfil de una aplicación comprende a su vez el tipo de aplicación (emergencia, corporativa, personal,
social) y factores invariantes (estos expresan los requisitos de tolerancia de una aplicación como valores
mínimos y máximos de cada factor del perfil de usuario). Es, por lo demás, el más abstracto e indefinido de
los perfiles que abordan estos autores.
Finalmente, el perfil de información en [YJ10] es un conjunto de valores para factores relacionados con el
uso que la aplicación da a la información del usuario. Es inicializado por el desarrollador en cada llamado a
la función de tolerancia y supone que este honrará los resultados de aquella. Comprende factores para la pre-
cisión de la fuente de información, “identificabilidad” del usuario (User Identifiability), “identificabilidad”
de la fuente (Source Identifiability), sensibilidad de la información, intenciones de publicación, localización
del procesamiento, y seguridad de la transferencia de información.
El Framework incorpora en su diseño las consideraciones de privacidad de la información de [YJ10], en la
capa homónima. El funcionamiento de esta es aún indefinido, hallándose en etapa de “caja negra”.
En un sentido completamente ajeno a los abordajes hasta ahora examinados [NMKS06] introduce un siste-
ma de hardware/software para dispositivos con recursos limitados. El performance profiling, afirma, permite
retroalimentación a los desarrolladores sobre el uso real de las aplicaciones, para mejorar su desempeño y
disminuir su uso de recursos. En su revisión del estado del arte del tema de program sampling (recolección
de información incompleta sobre la ejecución de programas) son examinados sistemas de profiling por hard-
ware y por software.
Para el muestreo por software los autores identifican técnicas idóneas: parcheo de código (code patching)
y duplicación de código (code duplication). El primero consiste en modificar el binario del programa pa-
ra ejecutar o dejar de ejecutar el código de recolección de perfil (esto puede ocurrir en el prólogo de los
métodos). La segunda técnica corresponde a duplicar el código binario parcial o totalmente y modificar la
copia para incluir la instrumentación de muestreo (también se introduce instrumentación en el original bajo
la forma de contadores que deciden cuándo pasar a la región instrumentalizada del código). Una tercera
técnica corresponde a incluir la instrumentación en el código justo antes de los eventos de interés (en tiempo
de programación).
16
Sobre la cuestión de cuándo muestrear se identifican tres aproximaciones: aleatoria, a intervalos predefinidos
o de acuerdo al comportamiento del programa (esta última técnica usa duplicación de código). En cuanto
a qué tanto debe muestrearse, los autores identifican eventos simples, conjuntos inteligentes de eventos, o
conjuntos fijos de eventos (en el caso de los sistemas aleatorios o periódicos). En lo que respecta a los siste-
mas que muestrean de acuerdo al comportamiento del programa muestrean durante un paso simple (single
pass), hasta la siguiente invocación de método.
Este aspecto de perfilamiento de desempeño no es desarollado en el manejador de perfiles de aplicación,
dado el alcance del proyecto. Sin embargo, el módulo de contexto de aplicación ofrece un conjunto de datos
sobre ambiente de ejecución que podría servir de base para pefilar las aplicaciones de manera dinámica,
como se sugiere en [NMKS06].
17
Capítulo 3
El Framework
3.1. Aspectos generales del Framework
El desarrollo de la computación pervasive a comienzos de este siglo es el resultado de la evolución de
tendencias previas (sistemas distribuidos y computación móvil), con la integración de caracteres novedosos,
habilitados por tecnologías recientes. Este nuevo campo abre la posibilidad de diseñar un framework que
defina la estructura deseada para las aplicaciones pervasive mientras simplifica las tareas de dsarrollo y
construcción de las mismas.
Figura 3.1: Evolución computación Pervasive.
La infraestructura de la computación pervasive, al basarse en sistemas distribuidos, debe cumplir con
una serie de atributos: comunicación remota, tolerancia a fallas, alta disponibilidad, acceso remoto a infor-
18
mación, y seguridad distribuida. Así mismo, una gran proporción de los desarrollos pervasive tiene lugar
en dispositivos móviles, por lo que se añaden a los atributos ya mencionados: soporte para redes móviles,
acceso móvil a información, sensibilidad a la ubicación. Por último, características propias y definitorias de
la computación pervasive son el uso efectivo de espacios inteligentes, invisibilidad (o transparencia), loca-
lización escalable, e infraestructura heterogénea.
La propuesta de un Framework Pervasive que sirve de marco para este proyecto, debe entonces soportar la
mayoría de aspectos mencionados (ver figura 3.1). Bajo estas consideraciones, el diseño en su estado actual
se presenta en los párrafos que siguen.
La arquitectura del Framework (figura 3.2) está basada en capas, siendo esta elección consecuente con el
flujo secuencial de la información empleada por una aplicación. Siguiendo la figura 3.2 cada capa represen-
ta un conjunto coherente de servicios y módulos, desde el ápice -Linking Layer- hasta la base -Information
Layer-. La posición de los módulos en capas específicas define su comunicación con las capas inferiores.
Figura 3.2: Arquitectura Framework Pervasive.
La capa de convergencia y las dos capas de sensibilidad al contexto establecen una distancia frente al
19
modelo arquitectural en que se basan: son capas “transversales”. Esta aparente anomia en la distribución se
explica por un conjunto de requerimientos comunes de los módulos en dichas capas, que consumen servicios
de la capa de información. Y para coordinar estas capas transversales se introduce en la arquitectura la capa
de orquestación.
Sigue una descripción general de cada capa del Framework y en el capítulo posterior una exposición a pro-
fundidad del diseño de las capas de sensibilidad al contexto de la aplicación (Context-Aware Application
Layer) y sensibilidad al contexto del usuario (Context-Aware User Layer). El detalle de las capas de infor-
mación, localización, y orquestación se halla en documentos similares a este elaborados por Lorena Ramirez
[Ram11], Arturo Henao [Hen11] y Leyla Bonilla [Bon11]. Las capas restantes son trabajo futuro del grupo
Pervasive Solutions.
3.2. Capas Framework pervasive
3.2.1. Information Layer
La responsabilidad de esta capa es administrar el conjunto global de información que necesita la apli-
cación. Esta puede corresponder bien a información que debe recuperarse de alguna fuente externa al dis-
positivo móvil (e.g. bases de datos), o bien a información local o recuperable haciendo uso de tecnologías
incluidas en el teléfono a nivel de localización (Wi-Fi, bluetooth, GPS). Con el fin de establecer una frontera
entre la información general de la aplicación y aquella obtenida a través de las tecnologías ya mencionadas,
fueron diseñados dos módulos, a saber:
Information Manager: ofrece la posibilidad de obtener y persistir en forma estandarizada la informa-
ción, sin importar si esta es de almacenamiento local o remoto. Para lograr esto el módulo adopta el
concepto de “entidad”, entendiendo por ello un objeto canónico con nombre propio y una serie de
atributos con valores.
Location Detection: se encarga de determinar la localización de un usuario en un momento dado,
con el fin de identificar elementos de información que resultan de importancia para la construcción
del contexto. En forma análoga al módulo anterior este componente abstrae la especificidad de las
tecnologías de localización que soporta, exponiendo servicios estándar para el conjunto de las mismas.
3.2.2. Context-Aware Application Layer
La capa de sensibilidad al contexto de aplicación administra la información referente a las aplicaciones
usuarias del Framework. El aspecto estático de esta información corresponde a los perfiles de aplicación,
y el dinámico coincide con el contexto de aplicación. La separación de tareas resulta en un diseño con dos
módulos:
Application Profile Manager: los perfiles de aplicación son empleados por este manejador para validar
los requerimientos de las aplicaciones sobre el ambiente donde se ejecutan. Una estructura auxiliar
20
y de caracter opcional (conjuntos de permisos) permite usar este componente para definir roles de
usuario.
Application Context Manager: este componente expone en forma estructurada la información de fuen-
tes de contexto cercanas al dispositivo y que pueden permitir a una aplicación ajustar sus parámetros
de ejecución.
3.2.3. Context-Aware User Layer
Esta capa replica la estructura bipartita de la anterior, con un Profile Manager y un Context Manager
de usuario. Sin embargo, los perfiles de usuario incluyen un aspecto dinámico ausente en los perfiles de
aplicación, lo que genera una relación de cercanía con el módulo de contexto de la capa.
3.2.4. Convergence Layer
Esta capa se encarga de agrupar los servicios ofrecidos a nivel interno y externo. Los servicios inter-
nos están relacionados con las capas anteriores. En particular, la capa de convergencia reune y expone los
servicios de información, actuando como mediador entre la capa de información y las capas superiores. En
cuanto a los servicios externos, es la capa de convergencia la que los consume y expone al conjunto de
módulos.
3.2.5. Orchestration Layer
La responsabilidad de esta capa es administrar el directorio de servicios y precisar cuáles de ellos están
disponibles y en qué momento.
3.2.6. Linking Layer
La capa de enlace desempeña el papel de mediador entre todos los módulos y capas en la arquitectura.
Dado que el Framework no establece formatos estándares para intercambio de información entre capas, se
requiere de esta traducción para simplificar las comunicaciones.
3.2.7. Privacy Layer
En esta capa se concentran las funciones de cifrado, autenticación y control de acceso al dispositivo. El
módulo de cifrado codifica aquella información que no debe abandonar el dispositivo en formato de texto
plano, debido al caracter “sensible” y confidencial de la misma. El módulo de autenticación maneja los
permisos de acceso a la aplicación, y el de autorización define el subconjunto de recursos del dispositivo
que pueden ser accedidos por la aplicación.
21
3.2.8. Translator Layer
Esta capa es mediadora entre las capas del front-end y el back-end de la arquitectura. Las primeras son
aquellas que están relacionadas por completo con la lógica de negocio, mientras las últimas guardan relación
con el Framework como tal y sus servicios de soporte. La mediación de esta nueva capa traductora consiste
en la traducción de la información desde un formato canónico a objetos susceptibles de ser manipulados por
la capa de lógica de negocio.
3.2.9. Business Logic Layer
La independencia frente a la lógica de negocio de las aplicaciones hace parte de los lineamientos de
diseño del Framework. Esta capa del front-end es, por consiguiente, responsabilidad del desarrollador.
3.2.10. Interaction Layer
De manera similar a la capa de lógica de negocio, corresponde al desarrollador la implementación de la
capa de interacción. Al ocuparse de cuestiones de interacción con el usuario y despliegue de información,
debe reflejar la lógica de negocio de la aplicación, y no así la del Framework.
22
Capítulo 4
Capas Context-Aware: Diseño
Dos componentes en el Framework Pervasive, Context-Aware Application Layer y Context-Aware User
Layer, reúnen en sí la información del usuario, el dispositivo y su entorno. Su labor es otorgar estructura y
unidad a datos naturalmente dispersos y disímiles, para que las aplicaciones puedan hacer uso provechoso
de los mismos. El éxito o fracaso en este objetivo depende de un proceso de diseño adecuado.
4.1. Definición del problema
La información provista por los sensores de los teléfonos celulares es el insumo por antonomasia para la
sensibilidad al contexto presentada en un aparte anterior. Del acceso oportuno a estos datos, así como de una
manipulación consecuente con su riqueza, dependen las posibilidades de una recuperación satisfactoria del
contexto. No obstante, la diversidad de las fuentes y el carácter casi oculto de las mismas en ciertos sistemas
operativos móviles, limitan notablemente su uso efectivo. Con ello se coarta también la adaptación que las
aplicaciones pueden alcanzar en su interacción dinámica con el usuario.
Otro tipo de información que también requiere garantías de administración consistente para cumplir fun-
ciones útiles son los datos de usuario y aplicación (llamados aquí perfiles). Y es que la personalización,
primer nivel de interactividad, exige cierto reconocimiento del usuario y de la propia aplicación. Reincide
aquí la complejidad inherente a la gestión de información diversa, esta vez con un elemento importante de
privacidad que debe ser atendido. Y así resulta deseable -pero ausente- un conjunto de servicios susceptibles
de ser consumidos sin mayor preámbulo y que expediten las operaciones sobre los perfiles.
En este estado de cosas, la asistencia de mediadores, que hagan inmediato y estructurado el acceso a la
información del contexto y los perfiles, es bienvenida. Los módulos de manejo de contexto aquí desaro-
llados constituyen una solución en este sentido, exponiendo servicios de consulta de fuentes de contexto,
y ofreciendo facilidades para su manejo con fines de adaptación del comportamiento de las aplicaciones.
Los módulos encargados de la gestión de perfiles, en la misma vena, apoyan el reconicimiento mutuo de la
aplicación y el dispositivo, mientras permiten a la aplicación el manejo de permisos y roles de usuario
23
4.2. Módulos User Context y Application Context
En el contexto del usuario se incluyen como fuentes de contexto sensores físicos y virtuales. Como sen-
sores físicos se cuentan nivel de batería e intensidad de señal celular. Entre los sensores virtuales se clasifican
estado del dispositivo bluetooth, presencia de conectividad a una red de datos (y su tipo), proximidad de dis-
positivos con bluetooth habilitado, disponibilidad de un horario en la agenda, y orientación de la pantalla,
entre otros. Por su parte, memoria primaria libre y colores del tema visual vigente en el dispositivo para
elementos en primer y segundo plano, son parte de las fuentes -todas ellas virtuales- que informan el con-
texto de la aplicación. La identidad del hilo de ejecución activo es una fuente común entre los dos contextos.
El cuadro A.1 en el capítulo de anexos presenta un listado completo de fuentes de contexto La estructura y
funcionamiento de los módulos de contexto de usuario y contexto de aplicación es similar, por lo que se hace
una presentación conjunta. En ese sentido los módulos ofrecen al desarrollador dos opciones para acceder
a la información de las fuentes. Este puede solicitar cuando lo requiera el último valor reportado al módulo
por una fuente, siendo este un mecanismo de tipo pull. O bien el módulo puede informar a la aplicación
novedades en los valores de una fuente (esto equivale a un push de tales datos). Para hacer efectiva esta
última modalidad, la aplicación debe suscribirse como listener de una o más fuentes de contexto (buscando
facilitar dicha elección el módulo ofrece conjuntos predefinidos de fuentes).
Independientemente de la vía que elija el desarrollador para recuperar datos del contexto, debe adherir en
su aplicación al formato estándar de reportes de contexto, considerando siempre la posibilidad de que esta
información no esté disponible. Esto es, la aplicación no debe depender de información del contexto del
usuario para ofrecer funcionalidades, sino antes bien usarla en forma “oportunista” para activar o personali-
zar operaciones en sus soluciones1.
Las tareas descritas se instancian en un conjunto de clases, de las cuales ContextManager, superclase de
UserContextmanager y ApplicationContextManager, reúne las funcionalidades comunes de
gestión de contexto expuestas al desarrollador.
4.2.1. ContextManager
Las operaciones abstractas en este componente permiten a las aplicaciones establecer suscripciones
a fuentes de contexto y solicitar directamente datos a las fuentes. Todo ello tiene como preámbulo una
verificación de la disponibilidad de las fuentes en el dispositivo, bloqueando el acceso a las ausentes. Una
responsabilidad saliente de esta clase es la gestión de los demonios de contexto, agentes dinámicos de
revisión de las fuentes. Este elemento exige a las aplicaciones que consuman sus servicios de tipo push
implementar la interfaz IContextListener.
4.2.2. UserContextManager
Esta clase hereda de ContextManager el manejo básico de demonios y fuentes, implementando su
versión de los métodos para revisar el estado de las fuentes y acceder a sus datos. Comparte un listado
actualizado de fuentes disponibles con el módulo manejador de contexto de aplicación y al igual que este1Esta y otras consideraciones introducen una perspectiva down to earth frente a la cuestión de la sensibilidad al contexto.
24
Figura 4.1: Diagrama de clases general Módulos de contexto.
permite registrar y cancelar suscripciones a fuentes de contexto en forma dinámica (el reinicio de los demo-
nios de contexto es transparente y automático). Y para conservar la consistencia en su interacción con las
aplicaciones esta clase adopta el patrón singleton [GHJV95].
25
Figura 4.2: Diagrama de clases detallado Módulos User Context y Application Context.
4.2.3. ApplicationContextManager
Este componente, subclase también de ContextManager, sólo se distingue del otro heredero en el
conjunto de fuentes que administra. El diseño permite, no obstante, aumentar la distinción con modificacio-
nes localizadas. Los elementos subsiguientes son empleados por los manejadores de contexto de usuario y
contexto de aplicación, si bien los demonios de uno y otro módulo conservan autonomía.
4.2.4. ContextState
Esta clase es un verdadero proxy de contexto, con su única instancia sirviendo de repositorio temporal
para los últimos reportes de contexto recopilados por los demonios. Su otra responsabilidad es generar
los eventos de contexto para todos los listeners con suscripciones vigentes a las fuentes2. Estos eventos
-de la clase ContextEvent- han de ser interpretados en el método ContextAlert del contrato en
IContextListener.2En un uso permitido pero no recomendado los métodos estáticos de ContextState permiten consultar la información más
reciente de contexto. Sin embargo los valores retornados pueden no haber sido actualizados, correspondiendo pues a los inválidosde inicialización
26
4.2.5. MonitorDaemon
Con el uso de un objeto de tipo Timer y una tarea diseñada a la medida (ContextTimerTask),
cada demonio consulta periódicamente las fuentes de contexto suscritas por el listener al que sirve. Sólo en
caso de cambios en los valores con respecto al último chequeo se reporta la novedad al proxy de contexto.
Con este filtrado se evita el envío de mensajes con información redundante a las aplicaciones usuarias del
Framework.
4.2.6. ContextMediator
Este singleton es el elemento más próximo a las fuentes de contexto, suministrando operaciones para
obtener los datos directamente de las fuentes. No todas las fuentes permiten lecturas inmediatas, y en esos
casos el mediador informa los últimos valores reportados. Es el caso de los dispositivos bluetooth en las
inmediaciones, que requiere la programación previa de una búsqueda.
Figura 4.3: Diagrama de clases ContextEvent y ContextException.
4.2.7. ContextEvent
Un evento de contexto transporta como cadena simple o arreglo de cadenas las novedades de cambio de
valor en una fuente. La clase cuenta con operaciones para reconocer la fuente del evento, el tipo de valor
(simple o mútiple) y finalmente el valor propiamente dicho.
4.2.8. ContextException
Las fuentes disponibles en el dispositivo, pero no consultables en un momento dado, producen excepcio-
nes de tipo ContextException. Como los eventos, las excepciones de contexto conocen la fuente que las
produce, y además contienen un mensaje descriptivo del problema. Todos los llamados a métodos que invo-
lucren consulta de fuentes deben enmarcarse en bloques try-catch que atrapen objetos ContextException.
27
Figura 4.4: Diagrama de clases componentes adicionales.
4.2.9. TestingCanvas
Este es el primer componente en un conjunto de proveedores de servicios específicos a fuentes. TestingCanvas
es utilizado internamente por el mediador para efectuar pruebas en la pantalla del dispositivo y determinar así
su resolución y orientación (de acuerdo a los formatos portrait o landscape). Para ello TestingCanvas
se “apropia” de la pantalla por una fracción de segundo, ejecuta sus validaciones, y finalmente restaura el
elemento gráfico mostrado previamente.
4.2.10. BTexplorer
BTexplorer tiene asignada la responsabilidad de detección de dispositivos bluetooth cercanos. Una
vez iniciado, se reiicia en forma autónoma y actualiza un listado en el proxy de contexto con información
básica de los “vecinos” bluetooth, que incluye su dirección para establecer conexiones salientes.
4.2.11. IAPInfoProvider e IAPInfoImplementation
Cumpliendo una labor análoga a TestingCanvas, la clase IAPInfoImplementation brinda
información sobre los puntos de acceso3 al mediador. Una estrategia de desacoplamiento es seguida con
IAPInfoImplementation, para aislar los llamados a IAPInfoImplementation cuando las fuen-
tes a las que se refieren no están disponibles. Se omiten así referencias ilegales.
3El concepto de Access Point en Nokia comprende cualquier conexión establecida por el teléfono: redes inalámbricas, conexio-nes de datos vía red celular, comunicación bluetooth, etc.
28
4.3. Módulo User Profile
El módulo de perfiles de usuario administra dos estructuras básicas de información: perfiles básicos
y perfiles secundarios. Los datos básicos de un usuario hacen parte de un perfil básico. Un subconjunto
de preferencias con reglas particulares asociadas define un perfil secundario, con un papel central en el
reconocimiento de situaciones.
Ahora bien, el reconocimiento de un estado o situación es un proceso que supone la interacción entre los
módulos de contexto y el módulo de perfiles de usuario, mediando un grupo de perfiles secundarios definidos
por el desarrollador4 Una visión algo más conceptual del proceso de reconocimiento permite identificar
etapas de agregación, selección y activación, paralelas a la vía directa de recuperación de contexto, que
concierne al módulo de manejo de contexto de usuario.
Cada perfil secundario de usuario corresponde a una situación, tal y como la define el desarrollador. Es este
también quien establece las reglas que permiten la activación del perfil y de las preferencias que contiene.
Los perfiles secundarios filtran con sus reglas y a intervalos regulares la información de las fuentes de
contexto, alternando la activación de las preferencias que les conforman. Una definición cuidadosa de las
reglas de activación para cada perfil, con criterios de exclusión entre los conjuntos de uno y otro perfil,
favorece el control adecuado del comportamiento de una aplicación. Las estructura del módulo User Profile
Figura 4.5: Proceso de reconocimiento de contexto.
4Para efectos de la interpretación de la información de contexto, se sugiere al desarrollador redundancia en las fuentes requeridas,de forma tal que sea viable reconocer un estado del contexto en presencia de información limitada o poco precisa.
29
se observa en el diagrama de clases de la figura 4.6. En las líneas que siguen se examina en detalle la
asignación de responsabilidades en el módulo.
Figura 4.6: Diagrama de clases Módulo User Profile.
30
4.3.1. UserProfileManager
Como elemento principal en el diseño del módulo la clase UserProfileManager interactúa con
las aplicaciones. Los servicios que brinda este singleton son la creación, edición y consulta de los perfiles
primarios y secundarios de usuario. En particular, para un perfil básico permite además de la creación y
remoción del perfil mismo, la adición, modificación y consulta de campos de valor sencillo o múltiple. En
lo que respecta a los perfiles secundarios la clase define operaciones para crearlos y eliminarlos, así como
para asociarles preferencias y reglas anteriormente registradas en el módulo. A esto se añade la activación a
voluntad de los perfiles secundarios.
Y es que las responsabilidades de UserProfileManager al interior del módulo se relacionan con su
capacidad de administrar el ciclo de vida de los perfiles secundarios, verdadero aspecto dinámico del mane-
jador en cuestión.
4.3.2. BasicUserProfile
Esta clase representa el perfil básico de usuario. Administra información sobre el mismo relevante pa-
ra las aplicaciones bajo la forma de campos (tuplas de nombre y valor, o de nombre y arreglo de valores,
dependiendo de la multiplicidad del dato cuya administración se delegue al módulo). Además de contener
información básica y de bajo “riesgo” para la privacidad como género y edad, puede incluir -si el desarrolla-
dor lo especifica- campos como nombre, dirección de correo electrónico, y teléfonos de contacto. Cada uno
de estos campos presentes puede ser marcado como requerido u opcional por el desarrollador (configurando
la propiedad required). Esto le permite a la clase central del módulo validar cuando un perfil satisface
las expectativas de la aplicación mediante la operación checkRequiredFields.
El desarrollador puede crear múltiples perfiles básicos por aplicación y adicionar libremente campos a cada
perfil, con la precaución de mantener la consistencia de los identificadores en el manejador durante el uso
de los campos en la lógica de su aplicación.
4.3.3. SecondaryUserProfile
Un perfil secundario contiene una serie de reglas o condiciones que al ser satisfechas activan las prefe-
rencias que le constituyen. Es por ello que los perfiles secundarios requieren comunicación constante con el
Módulo User Context, para evaluar los reportes de aquel y activar el perfil que corresponda. Esto se logra
mediante consultas periódicas al proxy de contexto (instancia única de ContextState, el estado “actual”
del contexto).
Los perfiles secundarios pueden estar activos o inactivos, y en un momento dado sólo ha de existir un perfil
en estado activo por aplicación: UserProfileManager hace las veces de garante de cambios de perfil.
De allí que cada perfil secundario de una aplicación tenga entre sus propiedades un nivel en la jerarquía
que no puede ser compartido con otros perfiles y que permite activarlo en forma preferente cuando el con-
texto vigente satisface varios perfiles5. Un perfil por omisión cubre aquellos casos en los cuales no existen
5Esta activación autónoma de perfiles debería ser autorizada por el usuario a través de la aplicación, so pena de generar unasensación de “pérdida de control.”
31
condiciones para la activación de los perfiles disponibles. Adicionalmente el módulo soporta la activación
“manual” de un perfil, siendo el desarrollador quien expone -u oculta- al usuario esta característica en la
aplicación.
Por su parte cada regla dentro de un perfil secundario hace referencia a una fuente de contexto con valo-
res numéricos y establece sobre esta una condición de tipo comparativo (i.e. igual a, estrictamente menor
que, menor o igual que, estrictamente mayor que, mayor que). Al ser satisfecha la condición se produce
una salida positiva de la regla. Para cada perfil el desarrollador define ademáas un criterio de activación,
entendido este como un threshold o umbral de activación (número mínimo de reglas que se deben satisfacer
para activar el perfil). La desactivación de los perfiles en ausencia de competencia con otros tiene lugar por
timeout (este periodo de expiración tiene prelación frente a la desactivación “disparada” por reglas).
En lo referente a las preferencias, una primera aproximación a las mismas permite comprenderlas como
tuplas conformadas por un recurso o parámetro de configuración de la aplicación y un valor asociado al mis-
mo. Estas tuplas alteran parámetros de funcionamiento de la aplicación (alarmas sonoras, colores de fondo,
tipo y tamaño de fuente, acceso a funcionalidades, etc.).
4.3.4. IField, Field y FieldMulti
Field y FieldMulti son modelos sencillos para representar los campos sencillos y múltiples -
respectivamente- en los perfiles básicos. La interfaz IField estipula un contrato sobre la gestión del nom-
bre, valor y propiedad required de un campo. Cada clase agrega en su implementación el tratamiento
particular propio de un valor único o múltiple para las operaciones de lectura y escritura, anexando un valor
por omisión para el campo.
4.4. Módulo Application Profile
Este módulo administra y verifica información de tipificación de la aplicación suministrada por el desa-
rrollador, permitiéndole especificar aquello que requiere la misma para funcionar. Complemento de esta
gestión de lo “requerido”, el módulo gestiona tambien lo “permitido”, con herramientas para definir esque-
mas de roles y permisos de usuario. De esta manera el objetivo del componente es servir de intermediario
entre lo que ofrece el dispositivo, y aquello que desea el programador para su aplicación y usuarios.
Un procedimiento granular para construir un perfil de aplicación garantiza que este sólo contendrá reque-
rimientos válidos en el ambiente de ejecución del dispositivo. Se trate de un requisito de APIs o de uno
de permisos sobre operaciones consideradas sensibles por el sistema operativo móvil, será verificado antes
de integrarse al perfil. Esto es, requerimientos ausentes en un perfil ya construido pueden considerarse no
cumplidos.
Los permisos de usuario constituyen el otro elemento de información que habita el módulo, bajo la forma
de conjuntos opcionales de permisos asociados a un perfil existente. Como los requerimientos los permisos
de usuario son elementos estables del módulo, y se espera sean configurados en la primera ejecución de la
aplicación y en adelante sólo sean objeto de consulta.
32
Estos y otros elementos del módulo reflejados en la figura 4.7 se describen a continuación.
Figura 4.7: Diagrama de clases Módulo Application Profile.
33
4.4.1. ApplicationProfileManager
Este singleton da acceso al desarrollador a servicios de creación de perfiles únicos por aplicación, con
requerimientos y -de manera opcional- conjuntos de permisos de usuario. Las alternativas para agregar
requerimientos son uno a uno, o mediante configuraciones predefinidas, y en ambos casos los requeri-
mientos no satisfechos o desconocidos generan excepciones informativas RequirementsException.
Los métodos de revisión checkAppProfileRequirement de la clase permiten examinar el cum-
plimiento de requerimientos por parte de un perfil (en representación de su aplicación). Esta clase no
contiene la lógica para creación y edición de perfiles, sirviendo únicamente de fachada para la fábrica
ApplicationProfileFactory.
Por su parte, la adición de permisos de usuario a un perfil supone la creación anterior de un conjunto de
permisos, identificado con un nombre (idealmente un rol o tipo de usuario).
4.4.2. Detector
Este elemento, aún antes de ser instanciado, puede leer del dispositivo propiedades de sistema relacio-
nadas con el ambiente de ejecución. Es el mecanismo central para la evaluación de requerimientos de los
dos tipos antes señalados (presencia de APIs y permisos sobre operaciones sensibles), para lo cual dispone
de un catálogo amplio de constantes. Se han incluído en Detector algunos métodos adicionales, por ser
cercanos a los mecanismos que emplea la clase para cumplir con sus tareas sobre requerimientos.
4.4.3. ApplicationProfileFactory
La clase ApplicationProfileFactory manipula directamente los perfiles de aplicación en lo re-
ferente a requerimientos, consumiendo los servicios de Detector para las verificaciones. Además alberga
configuraciones predefinidas de requerimientos por tipos de aplicación.
4.4.4. ApplicationProfile
El perfil de una aplicación, a diferencia de los perfiles de usuario, mantiene una relación de identidad
con su propietario. Un objeto de esta clase maneja dos listados, correspondientes a los APIs y permisos sobre
operaciones sensibles ya verificados a solicitud de la aplicación. Además conserva y actualiza una tabla con
los conjuntos de permisos que el desarrollador haya decidido crear a través de la clase principal del módulo.
Consecuentes con esta estructura las operaciones de ApplicatioProfile se reducen a la recuperación
y escritura de requerimientos y conjuntos de permisos.
4.4.5. UserPermissionsSet
Un objeto UserPermissionsSet es asimilable a un rol de usuario, pues contiene una selección
de tuplas de recursos y permisos sobre los mismos. El módulo no impone restricciones sobre el conte-
nido de los permisos de usuario y no controla su cumplimiento, ofreciendo apenas un mecanismo flexi-
ble para su gestión. Es responsabilidad de la aplicación hacer efectiva su política de usuarios. Los va-
34
lores de los permisos de un conjunto, incorporados ya en un perfil, pueden ser consultados a través de
ApplicationProfileManager.
4.4.6. RequirementsException
La clase RequirementsException dispone de vectores separados para registrar los requerimientos
no cumplidos y los que no fué posible validar durante la revisión. La forma en que el desarrollador haga
uso útil de sus contenidos dependerá de la estrategia adoptada para la elaboración del perfil: si utiliza una
configuración predefinida la fábrica garantiza la cobertura de la revisión y la excepción de requerimientos
que podrá generarse contiene los identificadores de todos los requerimientos no satisfechos y no verifi-
cables; si por el contrario recurre a la adición secuencial de requerimientos, en caso de ser generado un
objeto RequirementsException el mismo hará referencia exclusiva al primer requerimiento que no
se cumpla o no se pueda verificar.
Constante API Recurso asociado
MMAPI Mobile Media (MMAPI) javax.microedition.mediaPIMAPI PIM Optional Package API javax.microedition.pimM3GAPI Mobile 3D Graphics API (M3G) javax.microedition.m3gLOCATIONAPI Location API javax.microedition.locationBTAPI Bluetooth API javax.bluetooth.apiFILECONNAPI FileConnection Optional Package javax.microedition.io.file.FileConnectionINTERNATAPI Mobile Internationalization API javax.microedition.globalCHAPI Content Handler API (CHAPI) javax.microedition.contentSIPAPI SIP API java.microedition.sipWMAPI Wireless Messaging API (WMA) javax.wireless.messagingAMSAPI Advanced Multimedia Supple-
ments API (AMS)javax.microedition.amms
VECTOR2DAPI Scalable 2D Vector Graphics API javax.microedition.m2gPAYMENTAPI Payment API javax. microedition.paymentCONTACTLESSAPI Contactless Communication API javax. microedition.contactlessSENSORAPI Mobile Sensor API javax.microedition.sensorOBEXAPI OBEX API javax.obex.apiIAPINFO IAPInfo API com.nokia.mid.iapinfo
Cuadro 4.1: Requerimientos de APIs evaluados por el Módulo Applica-tion Profile
35
Constante PermisoDetector.HTTP javax.microedition.io.Connector.httpDetector .HTTPS javax.microedition.io.Connector.httpsDetector .SOCKET javax.microedition.io.Connector.socketDetector.SERVERSOCKET javax.microedition.io.Connector.serversocketDetector .SSL javax.microedition.io.Connector.sslDetector .DATAGRAMRCVR javax.microedition.io.Connector.datagramreceiverDetector .DATAGRAM javax.microedition.io.Connector.datagramDetector .MMS javax.microedition.io.Connector.mmsDetector .MMS_RCV javax.wireless.messaging.mms.receiveDetector .MMS_SEND javax.wireless.messaging.mms.sendDetector .SMS javax.microedition.io.Connector.smsDetector .SMS_RCV javax.wireless.messaging.sms.receiveDetector .SMS_SEND javax.wireless.messaging.sms.sendDetector .CONTENTHANDLER javax.microedition.content.ContentHandlerDetector .PUSHREGISTRY javax.microedition.io.PushRegistryDetector .BT_SERVER javax.microedition.io.Connector.bluetooth.serverDetector .BT_CLIENT javax.microedition.io.Connector.bluetooth.clientDetector .RECORDCTRL javax.microedition.media.control.RecordControlDetector .GETSNAPSHOT javax.microedition.media.control.VideoControl.getSnapshotDetector .LANDMARK_CAT javax.microedition.location.LandmarkStore.categoryDetector .LANDMARK_MGMT javax.microedition.location.LandmarkStore.managementDetector .LANDMARK_READ javax.microedition.location.LandmarkStore.readDetector .LANDMARK_WRITE javax.microedition.location.LandmarkStore.writeDetector .EVENT_WRITE javax.microedition.pim.EventList.writeDetector .EVENT_READ javax.microedition.pim.EventList.readDetector .TODO_WRITE javax.microedition.pim.ToDoList.writeDetector .TODO_READ javax.microedition.pim.ToDoList.readDetector .CONTACT_WRITE javax.microedition.pim.ContactList.writeDetector .CONTACT_READ javax.microedition.pim.ContactList.readDetector .FILE_WRITE javax.microedition.io.Connector.file.writeDetector .FILE_READ javax.microedition.io.Connector.file.readDetector .SIP javax.microedition.io.Connector.sipDetector .SIPS javax.microedition.io.Connector.sipsDetector .LOCATION javax.microedition.location.LocationDetector .ORIENTATION javax.microedition.location.OrientationDetector .PROXIMITY javax.microedition.location.ProximityListenerDetector .SENSOR javax.microedition.io.Connector.sensorDetector .PAYMENT javax.microedition.payment.process
Cuadro 4.2: Requerimientos de permisos evaluados por el Módulo Ap-plication Profile
36
37
Capítulo 5
Capas Context-Aware: Funcionamiento
5.1. Módulos User Context y Application Context
5.1.1. Funcionamiento
Para acceder a los servicios de un administrador de contexto el beneficiario del Framework debe obtener
una referencia a la instancia activa del componente:
public UserContextManager getInstance()
public UserContextManager getInstance(MIDlet midlet)
public ApplicationContextManager getInstance()
La diferencia entre estos los primeros métodos estriba en que el segundo habilita en el Módulo User Con-
text el uso de fuentes de contexto que requieren una referencia a un MIDlet para funcionar (por ejemplo, la
detección de orientación de pantalla, que debe “tomar control” de la pantalla por unos cuantos milisegundos
para efectuar detecciones). Al instanciarse cada módulo verifica la disponibilidad de fuentes de contexto
y en adelante bloqueará el uso de aquellas no disponibles (evitando así la generación de excepciones que
hagan inestable la ejecución de la aplicación).
Ahora bien, el usuario del Framework framework puede obtener información del contexto mediante dos vías
o métodos: pull y push. Los procedimientos relevantes en cada caso se incluyen a cotinuación.
Consulta de información de contexto bajo demanda (pull)
Bajo esta modalidad, la más simple, los módulos de contexto son consultados para recuperar los valores
actuales reportados por las fuentes de contexto. Para obtener una representación de tal valor para una fuente
de contexto dada basta con hacer un llamado a:
public String[] getRawContextSourceData(int contextSourceID) throws
ContextException
38
Este método retorna un arreglo de cadenas con el valor o valores más actualizados para la fuente cuyo
identificador se recibe como parámetro. De tratarse de una fuente que reporta un único valor este ocupa la
primera y única posición (0) del arreglo retornado. Si la fuente reporta múltiples valores, este arreglo tiene
el tamaño del número de elementos de la actualización o reporte. El llamado resulta en una excepción de
contexto si se cumple una de dos condiciones: la fuente no está disponible en el dispositivo; o la fuente está
disponible pero en el momento vigente no puede ser consultada (no reporta valores válidos).
El listado de fuentes y el formato de los valores vinculados a estas se halla descrito en los anexos de este
escrito. El proceso completo desde la obtención de una referencia al manejador, hasta la consulta de una
fuente se ilustra en el siguiente caso de uso.
Consulta de información de contexto por suscripción (push)
Esta forma de acceder a la información del contexto corresponde al registro de una clase de la aplicación
beneficiaria como listener de una o más fuentes de contexto. Para ello se debe implementar la interfaz
IContextListener ya introducida:
public interface IContextListener{
public void contextAlert(ContextEvent event);
public String getListenerID();
}
El método contextAlert en este contrato será llamado por el propio proxy cada vez que se produzca
un cambio en los valores reportados por una de las fuentes suscritas. El objeto de tipo ContextEvent
transporta la información relevante sobre el cambio en el contexto, pudiendo ser consultado por el desarro-
llador con los métodos que siguen:
public int getContextSource()
public String getValue()
public String[] getValues()
public boolean isMultiValue()
Se espera que como parte de su uso de fuentes de contexto en la aplicación el desarrollador obtenga la
multiplicidad del valor reportado por la fuente de contexto (usando isMultiValue) antes de solicitar el valor
como tal mediante el método apropiado (esto es, getValue o getValues). Si esta precaución no es adoptada
getValue retornará los elementos del arreglo encadenados al llamársele sobre un tipo de valor múltiple, y en
forma análoga getValues producirá como salida un arreglo de una sola posición al emplearse con un valor
de cadena simple.
Ahora bien, para que el beneficiario del Framework pueda recibir los eventos de contexto generados por
fuentes de su elección, debe -además de implementar IContextListener- suscribirse explícitamente a las
fuentes de contexto de su interés:
39
public void registerContextSourceListener(IContextListener listener,
int contextSourceID)
Si la fuente está disponible en el dispositivo un hilo de monitoreo de contexto (instancia de MonitorDaemon)
revisará periódicamente el estado de misma y cuando detecte cambios en sus valores actualizará un reposi-
torio en memoria principal (el proxy de contexto ContextState). Adicionalmente se creará un vínculo
entre este repositorio en memoria principal y el listener que se incluya como parámetro. Así, con cada
reporte de un valor nuevo en la fuente con identificador contextSourceID, el repositorio enviará un
evento a la aplicación suscriptora. Un método adicional en el manejador de contexto de usuario permite
suscribirse a un conjunto predeterminado de fuentes de contexto, agrupados de acuerdo a tipos frecuentes
de aplicaciones:
public void registerContextSourceSetListener(IContextListener listener,
int contextSourceSetID)
Como antes, la habilitación de estas fuentes de contexto para consulta push depende de su disponibilidad
en el dispositivo, y en ese sentido siempre es posible verificar el estado de una fuente usando:
public synchronized boolean isSourceAvailable(int contextSourceID)
Finalmente es posible cancelar las suscripciones a fuentes de contexto individuales y conjuntos presta-
blecidos.
public void unregisterContextSourceListener(IContextListener listener)
public void unregisterContextSourceSetListener(IContextListener
listener)
En todas estas operaciones el funcionamiento interno del módulo permanece oculto al usuario. Así el
hilo de monitoreo correspondiente a la aplicación es reiniciado con cada adición o eliminación de una fuente
de contexto, posibilitando la modificación dinámica del conjunto de fuentes de contexto.
5.1.2. Casos de uso
Los métodos arriba descritos para acceder a los datos de las fuentes de contexto hacen parte de los casos
de uso de los módulos de contexto.
40
Figura 5.1: Casos de uso Módulos Context Manager.
5.1.3. Diagramas de secuencia
La vía directa de acceder a los datos de una fuente (pull) se representa en un diagrama de secuencia con
una interacción en la que participan apenas las clases UserContextManager y ContextMediator.
Figura 5.2: Diagrama de secuencia para consulta de fuentes de contexto (pull).
El método pull supone la comunicación entre todas las estructuras principales de los módulos de con-
texto. La figura 5.3 ilustra los intercambios cíciclos entre los demonios de contexto y la instancia única de
Mediator.
41
Figura 5.3: Diagrama de secuencia para suscripción a fuentes de contexto (push).
5.2. Módulo User Profile
5.2.1. Funcionamiento
Al igual que las clases principales de los restantes módulos context-aware UserProfileManager
tiene un constructor protegido por el patrón singleton. Para recuperar una referencia a la instancia única de
la clase el desarrollador llama:
public static UserProfileManager getInstance()
Las operaciones expuestas por el módulo se agrupan naturalmente alrededor de las dos estructuras de
información del usuario allí manipuladas.
Administración de perfiles básicos de usuario
Un perfil básico de usuario puede ser adicionado o eliminado del Módulo mediante operaciones simé-
tricas. Estas y todas las operaciones sobre perfiles básicos requieren una secuencia de identificadores que
varía dependiendo del elemento que se desea acceder o crear y su posición en la estructura.
42
public void addBasicUserProfile(String appID, String bUserProfileID)
throws Exception
public void removeBasicUserProfile(String appID, String bUserProfileID)
throws Exception
Las excepciones lanzadas por cada método en esta pareja guardan relación inmediata con el uso de iden-
tificadores ya asignados o inexistentes, respectivamente.
Los perfiles básicos recién creados pueden ser completados con campos de valor sencillo y múltiple invo-
cando:
public void addBasicUserProfileField(String appID, String
bUserProfileID, String newFieldID, boolean required)
throws Exception
public void addBasicUserProfileField(String appID, String
bUserProfileID, String newFieldID, String value, boolean required)
throws Exception
public void addBasicUserProfileMultiField(String appID, String
bUserProfileID, String newFieldID, boolean required) throws
Exception
public void addBasicUserProfileMultiField(String appID, String
bUserProfileID, String newFieldID, String[] values, boolean
required) throws Exception
Las dos primeras operaciones son usadas para adicionar campos de valor único, distinguiéndose en si se
especifica o no un valor inicial. Los métodos más abajo ejecutan tareas análogas para los campos de valor
múltiple. A su vez el parámetro required en todos los métodos indica si el campo del perfil es requerido.
Ello permite validar la completitud de un perfil con
public boolean checkRequiredFields(String appID, String bUserProfileID)
throws Exception
Ahora bien, las actualizaciones en los valores de los campos son registradas con un par de métodos,
ajustados a los tipos simple y múltiple de valores:
public void setBasicUserProfileField(String appID, String
bUserProfileID, String fieldID, String value) throws Exception
public void setBasicUserProfileField(String appID, String
bUserProfileID, String fieldID, String[] values) throws Exception
43
Finalmente se puede recuperar el valor de un campo llamando:
public String getBasicUserProfileField(String appID, String
bUserProfileID, String fieldID) throws Exception
public String[] getBasicUserProfileMultiField(String appID, String
bUserProfileID, String fieldID) throws Exception)
Administración de perfiles secundarios de usuario
Como el aspecto de diseño más sofisticado de los módulos context-aware del Framework, la gestión
de perfiles secundarios de usuario ostenta un número importante de operaciones, que involucran reglas y
preferencias además de los propios perfiles.
El uso de los perfiles secundarios tiene como requisito implementar la interfaz IContextControllable,
cuyo contrato define operaciones para modificar el comportamiento de la aplicación:
public String getControllableID()
public void setBackground(boolean value)
public void setDataPlan(boolean value)
public void setOffline(boolean value)
public void setPowerSaving(boolean value)
public void setSilent(boolean value)
public void setDontDisturb(boolean value)
getControllableID debe retornar una cadena que identifique a la aplicación frente a la instancia
única de UserProfileManager, pues de ello depende el funcionamiento de los perfiles secundarios.
Además de implementar en una de sus clases la interfaz referida, la aplicación a ser controlada debe com-
poner uno o más perfiles secundarios, a partir de reglas y preferencias adicionadas previamente al módulo
con addRule y addPreference.
public void addRule(String ruleID, int contextSourceID, String
condition) throws Exception
public addPreference(String preferenceID, String resourceID, String
value) throws Exception
Agregar una regla implica bautizarla con un nombre único, y especificar un identificador de fuente de
contexto (ver tabla A.1) y una condición a evaluar con respecto a los valores reportados por aquella. El
formato de condition es el de una cadena con esta forma
COMPARADOR valor
44
Donde COMPARADOR es una de las constantes de UserProfileManager: LESSTHAN, LESSOREQUALTO,
EQUALTO, GREATEROREUQALTO, o GREATERTHAN. Y value es un valor numérico dentro del rango aso-
ciado a la fuente elegida.
De manera similar, el llamado a addPreference debe incluir el identificador de la nueva preferencia, y
dos constantes de la clase SecondaryProfile en los parámetros resourceID y value. Las constan-
tes válidas para recursos están en la sección de anexos, mientras value puede corresponder a PREF_OFF
o a PREF_ON1.
Con reglas y preferencias ya cargadas en el módulo es viable al fin crear un perfil secundario de usuario:
public void addSecUserProfile(String appID, String secUserProfileID,
int threshold, int hierarchyLevel) throws Exception
En caso de que el desarrollador no apruebe el timeout por defecto para la expiración de un perfil secun-
dario, puede personalizar el tiempo en milisegundos invocando:
public void setSecUserProfileTimeout(String appID, String
secUserProfileID, int timeout) throws Exception
Para todo uso de perfiles secundarios debe existir uno seleccionado como perfil por defecto, informando
al Módulo User Context su identidad con setDefaultSecUserProfile de UserProfileManager:
public void setDefaultSecUserProfile(String appID, String
secUserProfileID) throws Exception
Con la estructura básica de perfiles secundarios configurada el desarrollador debe asociar a estos las
reglas y preferencias, empleando para ello los identificadores que definió anteriormente y llamados a los
métodos:
public void setSecUserProfilePreference(String appID, String
secUserProfileID, String preferenceID) throws Exception
public void setSecUserProfileRule(String appID, String
secUserProfileID, String ruleID) throws Exception
Una última exigencia que habilita el control de la aplicación por parte del módulo User Profile es comu-
nicar la identidad de la clase a controlar en un llamado al método:
1El conjunto de recursos y valores es limitado debido al carácter exploratorio del proyecto. Una implementación futura queconstruya sobre la presente deberá incluir una selección mayor.
45
public void enableContextControl(IContextControllable controllable)
Inmediatamente después de este llamado los perfiles secundarios inician sus labores de filtado de con-
texto según sus reglas.
Por otra parte las operaciones de edición de perfiles secundarios, reglas y preferencias son completadas con
los siguientes métodos, ordenados de acuerdo al tamaño de la estructura a la que hacen referencia:
public void removeSecUserProfileSet(String appID) throws Exception
public void removeSecUserProfile(String appID, String secUserProfileID)
throws Exception
public void removeSecUserProfileRule(String appID, String
secUserProfileID, String ruleID) throws Exception
public void removePreference(String preferenceID) throws Exception
public void removeRule(String ruleID) throws Exception
Al respecto el desarrollador debe ser cauteloso pues reglas y preferencias no se eliminan “en cascada”
al suprimirse un perfil que las usa. Si no se espera reutilización, estos elementos deberían ser removidos del
módulo.
Finalmente es posible la activación a voluntad de los perfiles secundarios con sus preferencias a través de
métodos que evalúan el estado de las reglas y umbral de activación de un perfil, y permiten alternar su estado
de ejecución:
public boolean checkSecUserProfileRule(String appID, String
secUserProfileID, String ruleID) throws Exception
public boolean checkSecUserProfileThresholdStatus(String appID, String
secUserProfileID) throws Exception
public void setSecUserProfileStatus(String appID, String
secUserProfileID, boolean status) throws Exception
5.2.2. Casos de uso
Las operaciones que expone el Módulo User Profile en lo que se refiere a perfiles básicos se hallan
resumidas en la figura 5.4. Allí se observa la relación existente entre casos de uso base para las operaciones
de adicionar y recuperar campos de un perfil, y los casos de extensión correspondientes a estas operaciones
aplicadas a campos simples y múltiples. La validación de campos requeridos en un pefil se incluye como
una operación independiente, pues al igual que la creación de un perfil posee sentido completo por sí misma.
46
Figura 5.4: Casos de uso perfiles básicos de usuario.
El funcionamiento más complejo, pero también más dinámico de los perfiles secundarios puede apre-
ciarse en el conjunto de casos de uso que se incluye en la figura 5.5. Los casos más complejos asociados
a perfiles secundarios son los de control de ejecución de un perfil y revisión del estado de aquel. Estas dos
operaciones son representadas en el diagrama como casos compuestos por funciones más simples organiza-
das en secuencia.
Al igual que los perfiles básicos, los perfiles secundarios de usuario suponen la existencia de operaciones
normales de gestión, como creación, modificación y eliminación. La figura 5.5 lista operaciones de este tipo
aplicadas a las entidades de perfil secundario, reglas y preferencias. Una relación oculta por este diagrama
es el orden en el que tienen lugar las operaciones, pues no es posible adicionar una preferencia o una regla
a un perfil secundario si antes no se ha añadido la misma al Módulo.
Comparando los diagramas 5.4 y 5.5 resulta evidente la vocación dinámica de los perfiles secundarios de
usuario frente a los perfiles básicos. Mientras los segundos han sido diseñados para responder a condiciones
cambiantes alterando parámetros de funcionamiento de la aplicación, los últimos actúan como repositorios
estructurados para la información sobre el usuario.
47
Figura 5.5: Casos de uso perfiles secundarios de usuario.
5.2.3. Diagramas de secuencia
En relación directa con el primer conjunto de casos de uso presentados, en el diagrama de secuencia de la
figura 5.6 se aprecia como la adición de un nuevo perfil básico con dos campos requiere tres invocaciones a
48
operaciones distintas en UserProfileManager. Por lo demás esta secuencia resulta simple, acorde a la
función de los perfiles básicos. El único rasgo de complejidad viene dado por la distinción en el tratamiento
de campos simples y múltiples, ya expuesta en el diagrama de casos de uso en la figura 5.4.
Figura 5.6: Diagrama de secuencia para creación de un perfil básico de usuario.
Con un gran número de operaciones asociadas la construcción de un perfil secundario constituye un
procedimiento granular que habilita el aspecto más interesante del Módulo User Profile: el monitoreo y
control dinámicos del comportamiento de una aplicación. La figura 5.7 representa la adición de reglas y
preferencias al Módulo, como requisito previo de su vinculación a un perfil secundario. Si bien en esta
secuencia de operaciones no participan más de tres entidades, las iteraciones requeridas para completar la
construcción de un perfil secundario operativo reflejan la complejidad del proceso. Esta descomposición en
operaciones simples, no obstante, aporta flexibilidad a la funcionalidad que expone el Módulo User Profile
a la aplicación usuaria del mismo.
49
Figura 5.7: Diagrama de secuencia para creación de un perfil secundario de usuario.
50
5.3. Módulo Application Profile
5.3.1. Funcionamiento
Este Módulo debe ser instanciado inicialmente con un referencia al MIDlet de la aplicación que solicita
sus servicios:
public static ApplicationProfileManager getInstance(MIDlet midlet)
Entonces el desarrollador puede acceder a los servicios de gestión de perfiles de aplicación, correspon-
dientes a revisión de requerimientos (APIs instalados y permisos sobre operaciones sensibles) y a definición
de roles de usuario.
Administración de requerimientos
Para adicionar un perfil único de aplicación se llama uno de los siguientes métodos de ApplicationPro-
fileManager:
public void addAppProfile(String appID, int types) throws
RequirementsException, Exception
public ApplicationProfile createProfile(String appID, String[] perms,
int[] apis) throws RequirementsException
public void addAppProfile(String appID) throws RequirementsException,
Exception
El primero de ellos permite crear y validar un perfil de aplicación de acuerdo a tipos predefinidos. El
perfil sólo es registrado si el ambiente de ejecución satisface todos los requerimientos agrupados por el tipo
indicado. El segundo método para adicionar un perfil recibe como parámetros dos arreglos correspondientes
a los requerimientos a validar, en lo que respecta a APIs y permisos de aplicación. Al igual que el método
anterior, esta alternativa sólo registra el perfil si el entorno cumple con todos los requerimientos, generando
una excepción detallada en caso contrario.
El último método de creación registra un perfil vacío en el manejador. En caso de optar por esta alternativa
el desarrollador debe adicionar los requerimientos en forma individual, empleando los métodos:
public void addAppProfileRequirement(String appID, String perm) throws
RequirementsException, Exception
public void addAppProfileRequirement(String appID, int api) throws
RequirementsException, Exception
La primera versión recibe y valida uno de los permisos sobre operaciones sensibles predefinidos, adi-
cionándolo al perfil con el identificador dado en caso de ser positiva la evaluación. La segunda efectúa el
51
mismo procedimiento para uno de los APIs establecidos de antemano.
Los requerimientos no cumplidos pueden ser consultados examinando el objeto textttRequirementsExcep-
tion, que contiene dos vectores con los requerimientos no cumplidos (uno de ellos lista los APIs y el restante
los permisos). Un vector adicional incluye los requerimientos de permisos que no pudieron ser evaluados.
Para acceder a estos listados se emplea una serie de operaciones en esta clase:
public Vector getFailedApis()
public Vector getFailedReqs()
public Vector getFailedReqs()
Cuando el mecanismo de excepciones no se muestre acorde a las necesidades, el Módulo expone dos
operaciones para verificar si un perfil ya elaborado contiene un requerimiento dado:
public boolean checkAppProfileRequirement(String appID, String perm)
throws Exception
public boolean checkAppProfileRequirement(String appID, int api) throws
Exception
Para efectos de estas y todas las operaciones los identificadores de requerimientos de APIs corresponden
a las constantes de enteros definidas en Detector y a las cuales hace referencia la tabla 4.1. Los identi-
ficadores de permisos sobre operaciones se listan en la tabla 4.2 y son constantes de cadena de caracteres
también en Detector. El no apego al uso de estas constantes generará excepciones.
Administración de roles de usuario
Si es desarrollador decide crear uno o más conjuntos de permisos de usuario para un perfil de aplicación
debe invocar la operación addPermissionsSet de ApplicationProfileManager, que solicita el
identificador de la aplicación (para reconocer su perfil asociado) y un nombre único para el nuevo rol:
public void addPermissionsSet(String appID, String setID) throws
Exception
En cuanto a los permisos individuales la adición de los mismos a un conjunto ya creado supone la elec-
ción de un nombre y un valor para el permiso, como sigue:
public void addPermissionToPermissionsSet(String appID, String setID,
String permissionID, String value) throws Exception
52
Y finalmente la consulta del valor de un permiso recurre al encadenamiento de identificadores de las
estructuras que lo contienen:
public String getPermissionFromPermissionsSet(String appID, String
setID, String permissionID) throws Exception
5.3.2. Casos de uso
El mecanismo dual de mediación del Módulo Application Profile entre las aplicaciones por un lado, y su
ambiente de ejecución y usuarios, por otro, configura diez casos de uso con las relaciones que se presentan
en el gráfico.
Figura 5.8: Casos de uso Módulo Application Profile.
5.3.3. Diagramas de secuencia
La figura 5.9 muestra con caminos alternativos los posibles resultados de las validaciones de requeri-
mientos sobre permisos y APIs, con el arbitraje central ejercido por la fábrica de perfiles. Así, agregar un
53
requerimiento a un perfil de aplicación supone una validación previa, de la cual se encarga Detector.
Dependiendo del resultado se generará una excepción con detalles sobre el requerimiento no satisfecho por
el ambiente actual de ejecución. En el diagrama las iteraciones evocan el caracter granular e incremental de
la construcción de un perfil de aplicación.
Figura 5.9: Diagrama de secuencia para la creación de un perfil de aplicación.
Frente a los conjuntos de permisos el Módulo Application Profile actúa como mero repositorio de tuplas,
de allí la similitud entre las acciones en la figura 5.10 y la figura 5.6. Los conjuntos de permisos son en este
sentido similares a los perfiles básicos de usuario, como estructuras estáticas que facilitan la administración
de información por parte de la aplicación usuaria del Framework. Las operaciones iterativas anidadas en el
diagrama de secuencia para la creación de conjuntos de permisos hacen explícita la relación de contención
entre permisos, conjuntos de permisos (roles), y perfiles de aplicación.
54
Figura 5.10: Diagrama de secuencia para la creación de conjuntos de permisos.
55
Capítulo 6
Capas Context-Aware: Implementación
Guiada por el diseño presentado en el capítulo anterior, la realización en código de las capas context-
aware implicó nuevas decisiones e impuso restricciones. Se describe en este apartado la solución de com-
promiso alcanzada entre caracteres deseables y soluciones implementables.
6.1. Tecnologías Empleadas
Los módulos de contexto y perfilamiento de usuario fueron desarrollados en Java ME sobre el sistema
operativo Symbian en sus versiones S60 3rd Edition FP2 y S60 5th Edition. En específico se usaron celulares
Nokia con estos rasgos de software. Una revisión inicial de las implementaciones de Java ME permitió iden-
tificar esta como la más apropiada para soportar los servicios esperados de las capas Context-Aware, por su
amplio soporte de APIs opcionales y las propiedades de sistema disponibles. Como ejemplo el API IAPInfo,
exclusivo de Nokia, expone funcionalidades para extraer información sobre conexiones de todo tipo en el
dispositivo.
Durante la implementación y ante ciertas limitaciones de Java ME para la recuperación de contexto, se
consideró una solución “híbrida” con C++, lenguaje nativo de Symbian. No obstante las pruebas no fueron
exitosas y se decidió restringir el conjunto de fuentes de contexto a aquellas disponibles en la plataforma
elegida inicialmente. El esfuerzo se concentró entonces en los mecanismos para aprovechar estas fuentes,
conociendo a fondo su modus operandi en dispositivos reales para extraer los datos de contexto.
El ambiente de desarrollo fue Netbeans en su versión 6.9.1, con las plataformas estándar de Java ME de
Oracle y el SDK de Nokia para S60 3rd Edition. El código ejecutable se deslplegó en el emulador del SDK
mencionado en las primeras etapas de desarrollo, mostrándose insuficiente más adelante (la mayoría de
fuentes de contexto no cuentan con una emulación apropiada).
Finalmente en cuanto a teléfonos móviles se contó con los modelos E71, 5530 XpressMusic y 5800 Xpress-
Music de Nokia. El E71 y el 5800 fueron desbloqueados para ganar acceso a los directorios del sistema
operativo y modificar los permisos para las aplicaciones no firmadas de terceros. Esta modificación se con-
sideró indispensable para el buen curso de las pruebas de los módulos Context-Aware, dado su uso extensivo
de operaciones tipificadas como sensibles por el sistema operativo.
56
6.2. Restricciones
Las restricciones en la implementación de los módulos vienen dadas, en buena medida, por la platafor-
ma de desarrollo elegida. En particular el perfil de Java Mobile que aplica para celulares es MIDP (Mobile
Information Device Profile), apoyado sobre la configuración CDLC (Connected, Limited Device Configura-
tion), y complementado por APIs opcionales. La abundancia de estos últimos es un indicativo de la estrategia
seguida por Java Mobile al abarcar un espectro amplio de dispositivos, estableciendo un conjunto requeri-
mientos más o menos simples sobre los mismos. Este mismo rasgo -compatibilidad- impone restricciones
sobre la implementación de soluciones de tipo pervasive.
A lo anterior se suma la virtual ausencia de vías estandarizadas y eficientes para acceder a los recursos sub-
yacentes de Symbian, muchos de los cuales son en sí mismos fuentes de contexto1. Se afronta así una serie
de restricciones en el diseño actual, de las cuales se destacan:
Fuentes de contexto ocultas: ciertas fuentes de información de contexto con un alto valor en el análisis,
como el perfil activo del celular (silencio, vibración, etc.) no pueden ser accedidas desde Java ME.
Los módulos de perfilamiento y contexto no soportan, por tanto tales fuentes, si bien es implementable
una solución “híbrida” con C++ y un esquema cliente-servidor con comunicación vía sockets.
Dificultades en el acceso a los servicios del Framework: bajo la especificación más reciente de MIDP
(2.1), los MIDlets de una misma suite pueden comunicarse entre sí, pero no con los MIDlets de una
suite distinta (no en forma directa). Como consecuencia los módulos del Framework no pueden ser
empleados por más de una aplicación en un dispositivo, a menos de que se incluyan en los instaladores
de estas. Por lo demás el diseño de los módulos de perfilamiento y contexto soporta concurrencia,
preservando la identidad de las aplicaciones usuarias en todas las operaciones que así lo requieran.
Inicio asistido del Framework: los módulos del Framework, en general, requieren ser instanciados por
las aplicaciones antes de que sus servicios puedan ser consumidos. No es posible el inicio automático
del Framework cuando se enciende el dispositivo que lo alberga.
Heterogeneidad de Java ME: los fabricantes de teléfonos móviles despliegan implementaciones di-
ferentes de Java ME, variando incluso entre modelos de una misma casa. Dichas implementaciones
varían en los JSRs (Java Service Requests) soportados, interpretaciones de la especificación, caracte-
rísticas opcionales, y omisiones en la implementación [Hay09, 149]. Por consiguiente, los módulos
de perfilamiento y contexto están acoplados a una implementación particular.
Dominios de protección: el modelo de seguridad de la especificación MIDP define dominios para
controlar los permisos que una aplicación de terceros tiene sobre APIs “protegidos”, solicitando con-
firmaciones repetidas al usuario. Teniendo en cuenta la transparencia que se espera del Framework
esta interacción del usuario obstaculiza las tareas de los módulos.
1Las soluciones para comunicación entre código Symbian en C++ y Java suelen recaer en el uso de sockets en soluciones ad-hoc.El APIBridge de Nokia parece señalar en la vía correcta, pero la documentación sobre su uso es escasa.
57
Capítulo 7
Caso de Estudio: GCom
Con el objetivo de validar los módulos del Framework Pervasive desarrollados en conjunto se imple-
mento una aplicación móvil con rasgos pervasive. Por consiguiente GCom Mobile es un ejemplo aplicado
de los servicios a los que tiene acceso una solución cuando integra el Framework como parte de sí.
7.1. Contexto
Los videojuegos constituyen actualmente una subcultura, formando comunidades de interés identifica-
bles como tales. La riqueza de los fenómenos de comunicación al interior de estos grupos supone el uso
de medios electrónicos, que muchas veces se ubican en el origen de los vínculos sociales (una desviación
de la norma). De allí que surjan espacios de comunicación sincrónica y asíncrona para gamers, como foros
especializados y mensajeros instantáneos (IM). Entre los primeros se halla Gamers.co1, portal colombiano
responsable hasta hace unos años de la organización local de eventos masivos de videojuegos. En cuanto a
los mensajeros instantáneos Xfire se ubica como el más reconocido y usado.
Siguiendo la norma Gamers.co se desempeña como blog y foro. El primer aspecto se relaciona con la ingen-
te cantidad de información que fluye a diario sobre videojuegos, y que ha dado pie a portales especializados
como N4G, Kotaku y Destructoid2. No sólo se trata de información sobre juegos, sino que el interés de
un aficionado suele extenderse al hardware (tarjetas de video y periféricos, principalmente). En lo que res-
pecta a Gamers.co la generación de contenido propio es limitada, por lo que su carácter de foro domina la
orientación de la página. Además de los temas generales de discusión y aquellos especializados en áreas
de hardware o software, Gamers.co pone a disposición de los “clanes” de jugadores foros privados para
comunicación interna y coordinación de actividades. Estos hilos de conversación privados tienen el rasgo
de permanencia en el tiempo que requiere la coordinación, y que no es posible obtener de una herramienta
como Xfire.
1La página en Internet de Gamers.co es www.gamersco.com2Estos portales pueden ser consultados en www.n4g.com, www.kotaku.com y www.destructoid.com, respectivamente
58
7.2. Especificaciones
GCom es una suite de herramientas para gamers en movimiento, integrando administración de clanes
y acceso a información actualizada sobre temas de gaming. Con ello combina y traslada a un contexto
móvil las funcionalidades de blog y foro privado relegadas frecuentemente a los portales web. Los servicios
ofrecidos por GCom buscan ser pertinentes y relevantes, orientados al usuario y su contexto particular.
7.2.1. Administración de clanes
El cliente móvil de GCom ofrece al jugador de PC comunicación asíncrona con su clan, mediante dos
árboles de mensajes básicos: uno público y uno privado. A través del primero tiene lugar la discusión de
los asuntos de interés global para los miembros del clan, tales como coordinación de partidas, anuncios y
logística en general. El tema privado permite contactar a un usuario particular, siendo el equivalente de un
mensaje privado (PM) de un foro de internet.
Dado que la estructura de los clanes es jerárquica, los roles de líder de clan y clanmate se hallan represen-
tados en GCom. El líder tiene funciones de “super-moderador”: es el único que puede asociar un evento
de tiempo a un mensaje de conversación en un tema público (esto es, programar una notificación o alarma
en los clientes móviles de los miembros); y sólo él puede borrar cualquier mensaje del tema público. Los
clanmates tienen permisos limitados: pueden borrar únicamente los mensajes privados que han recibido. El
tema privado de cada usuario está excluido de la administración del líder del clan.
7.2.2. Acceso al contenido
El otro servicio central de GCom es la consulta de noticias de interés para jugadores. Así, al momento
de instalar el cliente de GCom en su dispositivo móvil el usuario debe crear un perfil básico en la aplicación,
que incluye un listado de temas de interés (categorías de noticias). A partir de esta selección un servicio
centralizado integra y filtra los contenidos provenientes de fuentes diversas para entregar al dispositivo sólo
información actualizada y relevante para el usuario.
7.2.3. Funcionalidades adicionales
Un conjunto de servicios adicionales no relacionados en forma directa con las funcionalidades centrales
soportan el uso de GCom en distintos contextos e incrementan su usabilidad. En este sentido, una aplicación
de escritorio complementaria (GCom Desktop), reporta el cambio de disponibilidad del usuario e inicia el
mensajero Xfire al detectar la proximidad del teléfono móvil vía bluetooth. Esta misma aplicación actualiza
la disponibilidad del jugador en un servidor central, el cual hace disponible esta información para consulta
desde el dispositivo móvil del líder.
En lo que atañe al cliente móvil, cuenta con opciones para configurar la conexión deseada para el intercambio
de datos con los servicios y con configuraciones especiales para revisión de mensajes en segundo plano y
desactivación por contexto de las alarmas programadas por el líder.
59
7.3. Cliente Gcom
Figura 7.1: Diagrama de clases GCom Mobile.
60
El diagrama de clases de la figura 7.1 presenta las clases principales implicadas en la provisión de
los servicios de administración de clanes y acceso al contenido que GCom ofrece a sus usuarios. Allí se
incluyen también referencias a los módulos del Framework Pevasive que GCom integra en su arquitectura.
Por motivos de espacio se omiten en este diagrama los atributos de la clase GComMobile, listados en el
diagrama 7.2.
Figura 7.2: Diagrama de clases GCom Mobile -detalle atributos.
7.3.1. GComMobile
Es la clase que implementa la interfaz MIDlet, por lo que de su ciclo de vida depende el del resto de cla-
ses. Concentra la lógica de negocio de GCom Mobile, esto es, la administración de los servicios de noticias y
foro, haciendo uso de la información suministrada por los módulos Context-Aware para ajustar la forma en
la que dichos servicios son consumidos. Además gestiona el flujo de pantallas en la interfaz gráfica. Y con
la implementación de las interfaces IContextListener y IContextControllable -relacionadas
con los módulos UserContext y ApplicationProfile- se somete a un control dinámico por parte
del contexto.
61
7.3.2. XMLHelper
Esta clase se encarga de la traducción desde el formato de etiquetas cercano a XML que emplean los web
services consumidos por GCom. A partir de la cadena recibida del servicio remoto, este elemento produce
como salida objetos de tipo ThreadItem y MessageItem, aptos para el despliegue gráfico de hilos de
conversación, mensajes, y noticias. Para cumplir esta labor emplea la librería kXML23, que implementa el
API XmlPull.
7.3.3. AlarmDaemon
Las instancias de esta clase se ocupan de las alarmas programadas por el líder del clan en ciertos mensa-
jes del foro público. Cuando ha expirado el tiempo de la alarma el objeto AlarmDaemon correspondiente
despliega un diálogo en pantalla con el mensaje asociado. Para la programación de las alarmas la clase
en cuestión contiene una clase privada AlarmTimerTask que extiende de TimerTask y que actúa en
colaboración con un ojeto Timer.
7.3.4. IPosterListener
Los dos métodos de esta interfaz simplificada, onRequestComplete y onRequestError, trans-
fieren el resultado de las operaciones remotas a la clase que las implemente, en este caso GComMobile.
Corresponde a las clases ForumPoster y NewsPoster hacer los llamados a los web services respecti-
vos.
7.3.5. ForumPoster
ForumPoster es mediador entre la aplicación y el web service GForum. Teniendo en cuenta el gran
número de operaciones publicadas por este servicio, y las invocaciones frecuentes del MIDlet, esta clase
soporta mecanismos de exclusión mutua para arbitrar las transacciones. El MIDlet atiende los retornos de
sus peticiones implementando los métodos de IPosterListener.
7.3.6. NewsPoster
La clase NewsPoster permite la comunicación con el servicio GNews y su única operación expues-
ta: getEntries. Este intermediario es la parte visible de un cliente genérico de web services construído
como parte de los módulos de orquestación e invocación de servicios del Framework Pervasive. Su fun-
cionamiento se basa en un llamado asíncrono al método onRequestComplete de GComMobile, parte
del contrato aquirido con la implementación de INewsPosterListener (una interfaz sencilla cuyo otro
único método es onRequestError).
3La página oficial en SourceForge de la librería es kxml.sourceforge.net/kxml2/
62
7.4. Integración con el Framework Pervasive
El cliente móvil GCom emplea en múltiples instancias y situaciones las funciones de las capas Context-
Aware:
7.4.1. Uso de los Módulos Context-Aware
La utilización de los servicios de estos módulos es extensiva dado su desarrollo conjunto con el caso
de estudio. Desde el momento de la primera ejecución del cliente GCom en el teléfono tiene lugar la de-
tección de contexto, partiendo por identificar el dispositivo y ajustar el despliegue gráfico en consecuencia.
Con un llamado inicial al método estático getDeviceModel() de la clase Detector, el cliente movil
elige entre dos conjuntos de imágenes el mas apropiado para el dispositivo. Si se trata de un Nokia 5800
XpressMusic, con resolucion de 640x360 pixeles y pantalla táctil, mostrará elementos graficos sobredimen-
sionados. En el E71, con una resolución de 320x240, se optará por los íconos pequeños.
Módulo User Profile
El método initializeFramework inicia con el MIDlet y crea un perfil básico de usuario, marcando
los campos como requeridos. Una vez el usuario de GCom Mobile ingresa sus datos por primera vez estos
campos serán diligenciados y se invocará checkRequiredFieldspara validar que no existan cadenas
vacías en el perfil.
Figura 7.3: Código creación perfil de usuario en GCom Mobile.
Módulo User Context
En el apartado de personalización también se beneficia GCom Mobile de las capas sensibles al contexto
del Framework, concentrando las características configurables en una pantalla de opciones. Allí se listan las
conexiones de datos disponibles en el dispositivo, para que el usuario elija la de su preferencia. Esta lista
es construida al momento del despliegue grafico de esta pantalla consultando la fuente de contexto corres-
pondiente a la lista de puntos de acceso. Con base en la seleccion del usuario se modifican las direcciones
de los web services, para que los llamados a las operaciones remotas empleen la conexion especificada.
Cumpliendo con el requisito de transparencia de toda aplicación pervasive todo el proceso de detección es
63
imperceptible para el usuario.
En el mismo lugar se encuentra la opción “reconocimiento bluetooth”, que habilita la identificación del
teléfono en presencia de un servidor GCom Desktop. Esta opción no puede ser activada si el dispositivo
bluetooth esta desactivado. Si el usuario marca la opción bajo estas circunstancias, al intentar aplicar la con-
figuracion se anula la selección y se avisa al usuario con un mensaje.
El modo de reconocimiento bluetooth emplea directamente la fuente de vecinos bluetooth, que realiza un
sondeo en las inmediaciones del teléfono a intervalos regulares, construyendo un listado de los dispositivos
bluetooth identificados. Para que Gcom Desktop le identifique el usuario sólo debe escribir el nombre ami-
gable (friendly name) del dispositivo bluetooth de su computador, tal y como lo muestra la aplicacion de
escritorio en la parte superior del logo:
Figura 7.4: Nombre del servidor en GCom Desktop para uso de reconocimiento bluetooth
Figura 7.5: Configuración reconocimiento bluetooth en GCom Mobile.
Con esta configuración activa y GCom Mobile en primer o segundo plano, el servidor detecta al cliente
y reporta el cambio de estado a GForum periódicamente (mientras el teléfono del usuario siga dentro del
64
rango del dispositivo bluetooth del servidor).
Módulo Application Profile
Un primer uso del Módulo Application Profile permite definir en el dispositivo los roles de clanleader
y clanmate, habilitando para el primero todos los permisos (i.e. borrado de mensajes públicos, borrado de
hilos de conversación, creación de alarmas para los mensajes públicos, acceso al estado de los miembros del
clan). En las líneas de código de la figura 7.9 se observa el procedimiento para adicionar los conjuntos de
permisos para los dos roles al perfil ya existente de la aplicación.
Figura 7.6: Configuración roles usuario.
Una vez establecidos estos conjuntos de permisos, pueden ser consultados para configurar las pantallas
del cliente GCom de acuerdo al rol del usuario activo, como se muestra en las figuras 7.7 y 7.8 (adicio-
nalmente el rol de líder habilita la opción de borrado de mensajes e hilos, y la creación de alarmas en las
pantallas del foro público).
Figura 7.7: Menú principal rol clanmate.
65
Figura 7.8: Menú principal rol clanleader.
El modo “No Molestar”, disponible en la pantalla de opciones, hace uso de dos perfiles secundarios de
usuario para escuchar el contexto y tomar decisiones sobre cambios en la configuración de GCom Mobile.
Estos perfiles Como parte del método textttinitializeFramework se incluye el código de la figura 7.5, que
establece la siguiente configuración para los dos perfiles
Perfil Reglas Preferencias Umbral de activación Jerarquía
Normal Día == Domingo Alerta de mensajes
nuevos activa
2 reglas 2
Día == Sábado Alarmas programa-
das activas
Hora >= 6 AM
Hora <10 PM
Agenda == libre
No Molestar Día >Domingo Alerta de mensajes
nuevos desactivada
3 reglas 3
Día <= Sábado Alarmas programa-
das desactivadas
Hora >10 PM
Hora <6 AM
Agenda == ocupada
Cuadro 7.1: Configuraciones perfiles secundarios GCom Mobile
Si bien se ha buscado que las reglas de estos perfiles sean excluyentes entre sí, el nivel de jerarquía de un
perfil secundario permite a ApplicationProfileManager decidir qué perfil debe activarse en caso de
conflicto. Una observación adicional es que el perfil por defecto es “normal” y tiene un umbral de activación
66
bajo frente a “No molestar.” La configuración de los perfiles secundarios adopta la forma mostrada en la
siguiente captura:
Figura 7.9: Configuración perfiles secundarios.
7.4.2. Uso de otros Módulos del Framework
GCom Mobile recurre a los servicios de la clase InfoManager para efectos de persistencia de todos
sus atributos de tipo booleano y cadenas de texto. En ese sentido define un objeto Entity en el que
guarda un arreglo de cadenas para representar tales campos. Esta instancia contiene un arreglo de cadenas
que almacena la representación de los atributos a persistir o recuperar. El código para persistir supone la
creación de una entidad vacía:
67
Figura 7.10: Extracto (1) método saveSettings en GComMobile.
Y tras llenar el arreglo fields con las cadenas de texto de los atributos, se actualiza la entidad de
persistencia en el módulo:
Figura 7.11: Extracto (2) método saveSettings en GComMobile.
Entretanto en cada reinicio de la aplicación se llama loadSettings, para recuperar del dispositivo
los valores de los atributos. El código requerido para ello se muestra en la figura
Figura 7.12: Extracto método loadSettings en GComMobile.
Por otra parte GCom Mobile consulta GNews empleando una operación del cliente genérico del Módulo
de Orquestación e Invocación de servicios del Framework. El llamado, parte de la clase NewsPoster,
incluye la palabra clave que identifica a GNews, “news”:
68
ServiceRequestor.getInstance().invokeServiceByKeywordWithContext(“news”,
inputs, context, 1);
Previamente se habían modificado los archivos services.xml y operations.xml del servidor
del Framework (el cual alberga el M?2dul de Orquestación e Incovación de servicios). Las entradas agrega-
das se meustran en las figuras 7.13 y 7.14:
Figura 7.13: Nueva entrada para GNews en operations.xml.
Figura 7.14: Nueva entrada para GNews en services.xml.
7.5. Servicios web GNews y GForum
Los dos servicios consumidos y adaptados para su usuario por GCom Mobile ostentan rasgos divergen-
tes: GNews es un web service liviano y de propósito único. GForum, por el contrario, alterna operaciones de
gestión de clanes con sus funciones de foro público con buzones privados de mensajes. En esta sección se
describe la estructura interna y funcionamiento de estos proveedores.
7.5.1. GNews
Este servicio integra y filtra el contenido de cinco fuentes de noticias sobre videojuegos y hardware:
además de los ya mencionados Kotaku y Destructoid, consulta Gamespot, Gametrailers y Tom’s Hardware4.
Para lograr su objetivo GNews elige las entradas en los feeds RSS de estos portales que contienen palabras
claves afines a las categorías elegidas por quien consume el servicio.
4Las URLs de las últimas tres webs son www.gamespot.com, www.gametrailers.com, y www.tomshardware.com
69
Figura 7.15: Diagrama de clases GNews.
De los cuatro elementos en la figura 7.15, la clase FeedEntry representa una entrada de noticias en
un feed ya consultado, y EntriesList es una agrupación de estas entradas por categorías. El elemento
dinámico en esta configuración son los objetos de tipo FeedReader, a los que la clase principal GNews
asigna los canales de noticias para que los exploren, ocupándose ellos mismos del filtrado del contenido. Los
reportes que entregan a GNews son clasificados de acuerdo a la categoría de contenido a la que pertenezcan.
Estas categorías y algunas de las palabras representativas se incluyen en el cuadro 7.2.
Categoría de noticias Descripción Palabras clave
FPS Juegos de disparon en primera
persona o First Person Shooters
“call of duty”, “black ops”,
“battlefield heroes”, “battlefield
bad company”, “fps”, “first per-
son shooter”, “modern warfare”,
“mw”, “cod”, “splinter cell, “re-
sident evil”, “left for dead”, “left
4 dead”, “team fortress”, “half-
life”
RTS Juegos de estrategia en tiempo
real (Real Time Strategy)
“age of mythologies”, “star-
craft”, “rts”, “real time strategy”,
“civilization”
70
RPG_MMORPG Juegos de rol, incluyendo su va-
riante masiva multijugador en lí-
nea (MMORPG por sus siglas en
inglés)
“wow”, “world of warcraft”,
“role playing game”, “rpg”,
“mmorpg”, “old republic”, “dc
universe online”, “dcuo”
ARCADE Juegos con escenarios cortos y
numerosos asociados a las má-
quinas recreativas de estableci-
mientos comerciales
“pac-man”, “asteroids”,
“mappy”
SPORTS_SIMS Juegos de simulación y deporte “need for speed”, “nfs”, “blur”,
“fifa”, “winning eleven”, “mlb”,
“nba”
HARDWARE Componente de computador y
accesorios
“cpu”, “ssd”, “videocard”, “mot-
herboard”, “ati”, “nvidia”, “sha-
ders”, “x4”, “i5”, “i7”, “i3”,
“1156”, “1366”, “ddr3”
Cuadro 7.2: Categorías de noticias en GNews
7.5.2. GForum
Como el proveedor principal de servicios de GCom Mobile, las operaciones de GForum abarcan tres
aspectos: comunicación asíncrona en foro público, mensajes privados, y herramientas para la administración
de clanes:
Cada clan tiene asignado un foro público, es decir, un conjunto de “hilos” -threads- de conversación.
A su vez cada thread está compuesto por mensajes en orden cronológico. Los mensajes públicos y
sus estructuras contenedoras solo pueden ser eliminados por un clanleader y es en ese sentido que
GForum integra manejo de roles y permisos. Como se verá adelante, GCom Mobile complementa este
esquema de roles mediante el uso del Módulo User Profile del Framework.
Los miembros de un clan tienen además acceso a un buzón privado en GForum, para intercambio
exclusivo de mensajes con sus coequiperos. Estos mensajes pueden ser eliminados a voluntad del
propietario del buzón, y sólo por este.
GForum conserva una tabla con los estados de conexión de los miembros de un clan, de acuerdo a
los reportes de la aplicación de escritorio GCom Desktop. Por estado “en línea” se entiende aquí la
proximidad del usuario de GCom Mobile con respecto a su computador de escritorio con salida a
Internet. El listado de estados puede ser consultado exclusivamente por el líder del clan, a través de
su cliente GCom Mobile.
71
El diagrama de clases de la figura 7.16 representa la estructura de GForum, con una clase principal homóni-
ma que hace accesibles las operaciones sobre hilos de conversación públicos y privados. A su vez GForum
es dependiente de un administrador de usuarios y de un servicio de persistenca, necesarios para preservar la
separación de responsabilidades al interior del servicio. Las clases restantes, con la excepción de Alarm,
agrupan en orden creciente los mensajes de los usuarios, por lo que no se incluye aquí el detalle de su
funcionamiento.
Figura 7.16: Diagrama de clases GForum.
72
Capítulo 8
Validación, Resultados y Pruebas
Se pretende evaluar los módulos desarrollados para el Framework Pervasive a la luz de cuatro criterios:
uso de memoria secundaria, footprint en memoria primaria, tiempo y procesamiento.
8.1. Metodología
Para las pruebas se emplearon los modelos de teléfonos de Nokia E71 y 5800 XpressMusic. Adicional-
mente se recurrió al emulador del SDK de Nokia para Symbian 3rd Edition FP2 y su utilidad de diagnós-
tico. Se inició la aplicación GCom Mobile, y se monitoreó el comportamiento de los parámetros evaluados
mientras se recibían actualizaciones via consola de las actividades de los módulos Context-Aware y de la
aplicación.
8.2. Resultados
8.2.1. Comparación de tamaño
De los 479 KB del archivo jar del caso de estudio, los cuatro módulos Context-Aware aportan 65 KB.
El módulo de información del Framework y el cliente genérico de los módulos de orquestación e invocación
de servicios dan cuenta de 17 KB del tamaño total.
Componente Tamaño componente Aporte al tamaño del jar
Módulos Context-Aware 65 KB 14 %
Módulos InfoManager y cliente
Módulo Invocación de servicios
17 KB 3,50 %
Lógica de negocio e interfaz
Gcom Mobile
397 KB 82,50 %
Cuadro 8.1: Aporte relativo al tamaño del archivo jar de GCom
Mobile
73
8.2.2. Tiempos de consulta a fuentes de contexto
En lo que respecta a los tiempos de recuperación de datos de fuentes de contexto mediando los módulos
Context-Aware, frente a un enfoque de extracción directa, la diferencia es del orden de milisegundos. Ello
debido a que la mayoría de las fuentes retornan inmediatamente y una o dos clases intermediarias de los
módulos de contexto no agregan un delay significativo.
En lo que respecta a las invocaciones a web services, la siguiente tabla compara el tiempo promedio de
retorno de un llamado a la operacion getEntries de GNews.
Vía contacto GNews Tiempo promedio retorno
Sin mediación del servidor del
Framework
5 segs
Con mediación del servidor del
Framework
7 segs
Cuadro 8.2: Comparación tiempo retorno de getEntries en GNews
Finalmente no se notó retraso en las operaciones de lectura o escritura a través del infoManager con
respecto a las operaciones directas sobre la base de datos RMS, Record Management Store del dispositivo.
8.2.3. Uso memoria primaria
Con el inicio del MIDlet el footprint de la aplicación GCom con los módulos Context-Aware activos
subió rápidamente, de 9.9 MB a 11.9 MB y segundos después se estabilizó en las inmediaciones de los 13
MB. Este comportamiento se explica por el proceso de carga en memoria de las imágenes de la interfaz. Este
footprint se mantuvo estable mientras los perfiles secundarios permanecían activos en background, revisando
fuentes de contexto y un thread adicional se ocupaba de contactar a GForum para buscar actualizaciones de
mensajes.
8.2.4. Procesamiento
El proceso de autorización para el cambio de un perfil secundario produjo pequeños picos en el histórico
de uso de CPU, llegando en ocasiones al 8 % con causa atribuible a la tarea mencionada. Por lo demás se
hicieron evidentes incrementos notables en el uso del procesador durante el consumo de los web services y
en la manipulación de los elementos gráficos.
8.2.5. Discusión de resultados
La mediación del Framework sí tiene un impacto sobre el desempeño de las aplicaciones, siendo esto
particularmente cierto para el caso de los Módulos Context-Aware. Sin embargo el impacto es mínimo y no
74
Figura 8.1: Histórico de uso de CPU durante una de las pruebas.
afecta el flujo de las aplicaciones, mientras compensa ello con una ampliación de los servicios que estas
pueden ofrecer a sus usuarios.
8.2.6. Trabajo futuro
Como parte de la evaluación se consideran aspectos pendientes en la implementación actual de los
módulos del Framework:
El diseño actual no considera la precisión propia de cada fuente de contexto.
No existen criterios de desactivación de los perfiles secundarios (idénticos en estructura a los criterios
de activación, pero con reglas independientes).
Solo existe un configuración de listeners en estado de contexto, lo que limita el numero posible de
aplicaciones usuarias de los módulos.
No se tienen en cuenta aspectos de privacidad de la información.
La persistencia basada exclusivamente en cadenas de texto impone una representación única de la
información persistida, requiriendo conversiones durante las operaciones de lectura y escritura.
75
Capítulo 9
Conclusiones
El desarrollo de los módulos Context-Aware, con su afinidad natural a sensores ausentes de los ambien-
tes emulados, supuso un inicio temprano de las pruebas en dispositivos reales, y por tanto, una prolongada
etapa de experimentación y frustración. No obstante los resultados obtenidos con el caso de estudio demues-
tran la pertinencia y viabilidad de servicios que hagan concreta la idea de sensibilidad al contexto. Aún en
presencia de un conjunto limitado de fuentes de contexto, la sola recuperación estructurada de sus datos
aumenta las posibilidades de una aplicación para adaptarse a su medio y su usuario.
Ahora bien, teniendo en cuenta que las mejores aproximaciones al problema del razonamiento sobre el con-
texto suelen ser poco realistas en el sentido de requerir infraestructura especial o propietaria, se propone
integrar al usuario como fuente de contexto. Esto se lograría mediante la alternativa de obtener del usuario
información complementaria cuando la lógica definida no permita identificar el estado o perfil aplicable en
el contexto en que se encuentra, y ello se considere crítico. Si bien la transparencia es un objetivo explícito
de todo esfuerzo pervasive, las limitaciones en la representación y reconstrucción del contexto señalan la
necesidad de compensación, correspondiendo la propuesta a una solución de compromiso entre transparen-
cia y riqueza de los contextos recuperados.
En lo que respecta a los módulos adicionales desarrollados en forma contemporánea, e integrados par-
cialmente en el caso de estudio, estos se muestran prácticos dentro de las restricciones del alcance de los
proyectos respectivos. El módulo encargado de persistencia sufre por las limitaciones propias de los dis-
positivos móviles e impone el uso de una representación de la información (cadenas de caracteres), pero
logra abstraer la distinción entre almacenamiento local y remoto. El módulo de orquestación es extraordi-
nariamente sencillo de usar, pero la complejidad de su funcionamiento interno durante la etapa actual puede
limitar su desarrollo futuro. Los mismos módulos Context-Aware aquí desarrollados tendrían mejor fortuna
en plataformas y lenguajes menos restrictivos.
76
Apéndice A
Anexos
77
Cua
dro
A.1
:Lis
tado
fuen
tes
deco
ntex
to
Fuen
teC
onst
ante
Val
ores
posi
bles
Val
orin
icia
lC
omen
tari
o
Est
ado
Blu
etoo
thC
onte
xtSt
ate.
SRC
_BL
UE
TOO
TH
0(O
FF)ó
1(O
N)
-1
Niv
elba
terí
aC
onte
xtSt
ate.
SRC
_BA
TT
ERY
0-10
0(p
orce
ntaj
eca
rga)
-1
Dis
poni
bilid
adde
red
ce-
lula
r
Con
text
Stat
e
.SR
C_N
ET
WO
RK
AVA
ILA
BIL
ITY
0(D
ispo
nibl
e)ó
1(N
odi
spon
ible
)-1
Niv
else
ñalc
elul
arC
onte
xtSt
ate.
SRC
_SIG
NA
L
STR
EN
GH
T
0-10
0(d
B)
-1
Punt
osde
acce
sopr
efer
i-
dos
Con
text
Stat
e.
SRC
_PR
EFE
RR
ED
AC
CE
SSPO
INT
S
Arr
eglo
con
cade
nas:
<Nom
bre
AP>
:<Id
entifi
cado
rAP>
Stri
ng[]
de
tam
año
0
Sólo
disp
onib
leen
disp
o-
sitiv
osco
nIA
PIN
FOA
PI
(e.g
.Nok
iaN
85)
Ulti
mo
punt
ode
acce
soC
onte
xtSt
ate.
SRC
_LA
STU
SED
AC
CE
SPO
INT
Cad
ena:
<Nom
bre
AP>
:<Id
entifi
cado
r
AP>
Cad
ena
vací
a
Sólo
disp
onib
leen
disp
o-
sitiv
osco
nIA
PIN
FOA
PI
(e.g
.Nok
iaN
85)
Dis
poni
bilid
aden
agen
daC
onte
xtSt
ate.
SRC
_SC
HE
DU
LE
STA
TU
S
0(C
ondi
spon
ibili
dad
enag
enda
)ó
1
(Ocu
pado
)
-1
Ori
enta
ción
dela
pant
alla
Con
text
Stat
e.
SRC
_SC
RE
EN
OR
IEN
TAT
ION
0(o
rien
taci
ónla
ndsc
ape)
ó1
(ori
enta
-
ción
port
rait)
-1Só
lodi
spon
ible
endi
s-
posi
tivos
con
sens
orde
orie
ntac
ión
(e.g
.N
okia
N85
)
78
Est
ado
tarj
eta
dem
emor
iaC
onte
xtSt
ate.
SRC
_ME
MO
RYC
AR
D
STA
TE
0(s
inta
rjet
ade
mem
oria
)ó
1(t
arje
ta
dem
emor
iaen
ranu
ra)
-1U
sono
segu
ro.E
nva
rios
mod
elos
deN
okia
laex
-
trac
ción
dela
tarj
eta
de
mem
oria
prov
oca
elci
erre
deto
das
las
aplic
acio
nes
(inc
luye
ndo
las
que
está
n
inst
alad
asen
lam
emor
ia
inte
rna)
Vec
inos
Blu
etoo
thC
onte
xtSt
ate.
SRC
_BL
UE
TOO
TH
NE
IGH
BO
RS
Arr
eglo
con
cade
nas
corr
espo
ndie
ntes
ala
sdi
recc
ione
sde
los
disp
ositi
vos
Blu
etoo
th
Stri
ng[]
de
tam
año
0
Tipo
dere
dac
tual
Con
text
Stat
e.
SRC
_CU
RR
EN
T
NE
TW
OR
KT
YPE
1(r
edde
dato
s:E
DG
E,
3G,
HSP
Ao
CSD
)ó2
(Wir
eles
sL
AN
)
-1
Día
dela
sem
ana
Con
text
Stat
e.
SRC
_DA
YO
FWE
EK
1-7
(Dom
ingo
-Sáb
ado)
-1
Hor
ade
ldía
Con
text
Stat
e.
SRC
_HO
UR
OFD
AY
0-23
(12
AM
a11
PM)
-1
Mem
oria
prim
aria
libre
Con
text
Stat
e.
SRC
_FR
EE
ME
MO
RY
Dep
ende
deld
ispo
sitiv
olo
ng
Col
oren
prim
erpl
ano
de
lapa
ntal
la
Con
text
Stat
e.
SRC
_BA
CK
GR
OU
ND
CO
LO
R
-1U
sono
segu
ro.L
osva
lo-
res
repo
rtad
osen
prue
bas
prel
imin
ares
son
inco
nsi-
tent
es
79
Col
oren
segu
ndo
plan
o
dela
pant
alla
Con
text
Stat
e.
SRC
_FO
RE
GR
OU
ND
CO
LO
R
-1U
sono
segu
ro.L
osva
lo-
res
repo
rtad
osen
prue
bas
prel
imin
ares
son
inco
nsi-
tent
es
Thr
ead
enpr
imer
plan
oC
onte
xtSt
ate.
SRC
_FO
RE
GR
OU
ND
TH
RE
AD
Cad
ena
dete
xto
con
elno
mbr
ede
lhilo
enpr
imer
plan
o
Cad
ena
vací
a
Sise
dese
aid
entifi
car
un
thre
adde
beas
igná
rsel
e
unno
mbr
eal
crea
rlo
80
Cua
dro
A.2
:Mét
odos
mód
ulos
Use
rCon
text
yA
pplic
atio
nC
onte
xt
Tipo
reto
rno
Sign
atur
eD
escr
ipci
ón
Mét
odos
com
unes
enU
serC
onte
xtM
anag
ery
App
licat
ionC
on-
text
Man
ager
bool
ean
getA
vaila
bleS
ourc
es()
Rec
uper
aun
arre
glo
con
los
esta
dos
dedi
spon
ibili
dad
deto
das
las
fuen
tes
deco
ntex
to.
Stri
ng[]
[]ge
tRaw
Con
text
Dat
a()
Rec
uper
aun
am
atri
zco
nlo
súl
timos
valo
res
repo
rtad
ospo
rto
-da
sla
sfu
ente
sde
cont
exto
disp
onib
les.
Stri
ng[]
getR
awC
onte
xtSo
urce
Dat
a(in
tco
ntex
tSou
rceI
D)
thro
ws
Con
-te
xtE
xcep
tion
Rec
uper
ael
últim
ova
lorr
epor
tado
poru
nafu
ente
deco
ntex
toen
lapr
imer
apo
sici
ónde
unar
regl
ode
cade
nas,
dees
tard
ispo
nibl
ela
fuen
te.S
ila
fuen
tere
port
aar
regl
osde
valo
res,
esto
soc
upan
unar
regl
ode
tam
año
acor
deal
núm
ero
deva
lore
s.bo
olea
nis
Sour
ceA
vaila
ble(
intc
onte
xtSo
urce
ID)
Val
ida
siun
afu
ente
dada
deco
ntex
toes
tádi
spon
ible
para
suco
nsul
taen
eldi
spos
itivo
.vo
idre
gist
erC
onte
xtSo
urce
Lis
tene
r(IC
onte
xtL
iste
ner
liste
ner,
int
cont
extS
ourc
eID
)R
egis
tra
una
aplic
ació
nco
mo
liste
nerd
eun
afu
ente
deco
ntex
to,
reci
bien
doco
mo
prim
erpa
rám
etro
una
refe
renc
iaa
laap
licac
ión
(que
debe
impl
emen
tarl
ain
terf
azIC
onte
xtL
iste
ner)
.vo
idre
gist
erC
onte
xtSo
urce
SetL
iste
ner(
ICon
text
Lis
tene
rlis
tene
r,in
tco
ntex
tSou
rceS
etID
)R
egis
tra
una
aplic
ació
nco
mo
liste
nerd
eun
conj
unto
pred
efini
dode
fuen
tes
deco
ntex
to,s
iend
oel
prim
erpa
rám
etro
una
refe
ren-
cia
ala
aplic
ació
n(q
uede
beim
plem
enta
rIC
onte
xtL
iste
ner)
.vo
idse
tMid
let(
MID
letm
idle
t)C
onfig
ura
enfo
rma
expl
ícita
lare
fere
ncia
alM
IDle
tre
quer
ida
para
cier
tas
func
iona
lidad
esde
los
man
ejad
ores
deco
ntex
to.
void
unre
gist
erC
onte
xtSo
urce
Lis
tene
r(IC
onte
xtL
iste
ner
liste
ner,
int
cont
extS
ourc
eID
)C
ance
lael
regi
stro
deun
aap
licac
ión
com
olis
tene
rde
una
fuen
tede
cont
exto
.vo
idun
regi
ster
Con
text
Sour
ceSe
tLis
tene
r(IC
onte
xtL
iste
ner
liste
ner,
intc
onte
xtSo
urce
SetI
D)
Can
cela
elre
gist
rode
una
aplic
ació
nco
mo
liste
ner
deun
con-
junt
opr
edefi
nido
defu
ente
sde
cont
exto
.M
étod
osex
clus
ivos
enU
serC
onte
xtM
anag
er
Use
rCon
text
Man
ager
getI
nsta
nce(
)R
ecup
era
una
refe
renc
iaa
lain
stan
cia
únic
ade
lacl
ase
prin
cipa
lde
lMód
ulo
Use
rCon
text
.
81
Use
rCon
text
Man
ager
getI
nsta
nce(
MID
letm
idle
t)R
ecup
era
una
refe
renc
iaa
lain
stan
cia
únic
ade
lacl
ase
prin
cipa
lde
lMód
ulo
Use
rC
onte
xt,h
abili
tand
ola
sfu
ncio
nes
que
requ
ie-
ren
acce
soa
unM
IDle
t.M
étod
osex
clus
ivos
enA
pplic
atio
nCon
text
Man
ager
App
licat
ionC
onte
xtM
anag
erge
tIns
tanc
e()
Rec
uper
aun
are
fere
ncia
ala
inst
anci
aún
ica
dela
clas
epr
inci
pal
delM
ódul
oU
serP
rofil
e.
82
Cua
dro
A.3
:Mét
odos
Mód
ulo
Use
rPro
file
Tipo
reto
rno
Mét
odo
Des
crip
ción
Mét
odos
para
gest
ión
depe
rfile
sbá
sico
sde
usua
rio
void
addB
asic
Use
rPro
file(
Stri
ngap
pID
,St
ring
bUse
rPro
fileI
D)
th-
row
sE
xcep
tion
Perm
itead
icio
nar
unpe
rfil
bási
co(v
acío
)de
usua
rio
para
una
aplic
ació
n.vo
idad
dBas
icU
serP
rofil
eFie
ld(S
trin
gap
pID
,Str
ing
bUse
rPro
fileI
D,
Stri
ngne
wFi
eldI
D,b
oole
anre
quir
ed)t
hrow
sE
xcep
tion
Adi
cion
aun
nuev
oca
mpo
sim
ple
aun
perfi
lbás
ico
deus
uari
o,in
cluy
endo
enlo
spar
ámet
rosl
aop
ción
dem
arca
rlo
com
oca
mpo
requ
erid
ode
lper
fil.
void
addB
asic
Use
rPro
fileF
ield
(Str
ing
appI
D,S
trin
gbU
serP
rofil
eID
,St
ring
new
Fiel
dID
,Str
ing
valu
e,bo
olea
nre
quir
ed)
thro
ws
Ex-
cept
ion
Adi
cion
aun
nuev
oca
mpo
sim
ple
aun
perfi
lbás
ico
deus
uari
o,in
cluy
endo
enlo
spar
ámet
ros
unva
lorp
orde
fect
opa
rael
mis
mo
yla
opci
ónde
mar
carl
oco
mo
cam
pore
quer
ido
delp
erfil
.vo
idad
dBas
icU
serP
rofil
eFie
ld(S
trin
gap
pID
,Str
ing
bUse
rPro
fileI
D,
Stri
ngne
wFi
eldI
D,
Stri
ng[]
valu
es,
bool
ean
requ
ired
)th
row
sE
xcep
tion
Adi
cion
aun
nuev
oca
mpo
múl
tiple
deun
perfi
lbás
ico
deus
ua-
rio,
incl
uyen
doen
los
pará
met
ros
unva
lor
por
defe
cto
para
elm
ism
oy
laop
ción
dem
arca
rlo
com
oca
mpo
requ
erid
ode
lper
-fil
.bo
olea
nch
eckR
equi
redF
ield
s(St
ring
appI
D,
Stri
ngbU
serP
rofil
eID
)th
-ro
ws
Exc
eptio
nV
alid
asi
todo
slo
sca
mpo
sde
unpe
rfilb
ásic
ode
usua
rio
mar
ca-
dos
com
ore
quer
idos
seha
llan
dilig
enci
ados
.St
ring
getB
asic
Use
rPro
fileF
ield
(Str
ing
appI
D,
Stri
ngbU
serP
rofil
eID
,St
ring
field
ID)t
hrow
sE
xcep
tion
Rec
uper
ael
cont
enid
ode
unca
mpo
sim
ple
deun
perfi
lde
usua
-ri
o.St
ring
[]ge
tBas
icU
serP
rofil
eMul
tiFie
ld(S
trin
gap
pID
,Str
ing
bUse
rPro
fi-le
ID,S
trin
gfie
ldID
)thr
ows
Exc
eptio
nR
ecup
era
elco
nten
ido
deun
cam
pom
últip
lede
unpe
rfil
deus
uari
o.vo
idre
mov
eBas
icU
serP
rofil
e(St
ring
appI
D,
Stri
ngbU
serP
rofil
eID
)th
row
sE
xcep
tion
Elim
ina
unpe
rfilb
ásic
ode
usua
rio
para
una
aplic
ació
n.
void
setB
asic
Use
rPro
fileF
ield
(Str
ing
appI
D,
Stri
ngbU
serP
rofil
eID
,St
ring
field
ID,S
trin
gva
lue)
thro
ws
Exc
eptio
nM
odifi
cael
cont
enid
ode
unca
mpo
deun
perfi
lbás
ico
deus
ua-
rio.
void
setB
asic
Use
rPro
fileF
ield
(Str
ing
appI
D,
Stri
ngbU
serP
rofil
eID
,St
ring
field
ID,S
trin
g[]v
alue
s)th
row
sE
xcep
tion
Mod
ifica
elco
nten
ido
deun
cam
pom
últip
lede
unpe
rfilb
ásic
ode
usua
rio.
Mét
odos
para
gest
ión
depe
rfile
sse
cund
ario
sde
usua
rio
void
addP
refe
renc
e(St
ring
pref
eren
ceID
,St
ring
reso
urce
ID,
Stri
ngva
lue)
thro
ws
Exc
eptio
nA
dici
ona
una
pref
eren
cia
alco
njun
togl
obal
depr
efer
enci
as,
dond
epu
ede
serr
eutil
izad
apo
rotr
asap
licac
ione
s.
83
void
addR
ule(
Stri
ngru
leID
,in
tco
ntex
tSou
rceI
D,
Stri
ngco
nditi
on)
thro
ws
Exc
eptio
nA
dici
ona
una
regl
aal
conj
unto
glob
alde
regl
as,d
onde
pued
ese
rre
utili
zada
poro
tras
aplic
acio
nes.
void
addS
ecU
serP
rofil
e(St
ring
appI
D,
Stri
ngse
cUse
rPro
fileI
D,
int
thre
shol
d,in
thie
rarc
hyL
evel
)thr
ows
Exc
eptio
nA
dici
ona
unnu
evo
perfi
lse
cund
ario
deus
uari
o,es
tabl
ecie
ndo
para
este
unum
bral
deac
tivac
ión
yun
nive
len
laje
rarq
uía
depe
rfile
sse
cund
ario
s.bo
olea
nau
thor
izeP
rofil
eCha
nge(
Seco
ndar
yUse
rPro
file
secU
serP
rofil
e)A
utor
iza
ore
stri
nge
aun
perfi
lsec
unda
rio
elca
mbi
ode
esta
doa
activ
o.bo
olea
nch
eckS
ecU
serP
rofil
eRul
e(St
ring
appI
D,
Stri
ngse
cUse
rPro
fi-le
ID,S
trin
gru
leID
)thr
ows
Exc
eptio
nR
ecup
era
eles
tado
dela
cond
ició
nde
una
regl
aen
unpe
rfils
e-cu
ndar
iode
usua
rio.
bool
ean
chec
kSec
Use
rPro
fileT
hres
hold
Stat
us(S
trin
gap
pID
,St
ring
se-
cUse
rPro
fileI
D)t
hrow
sE
xcep
tion
Rec
uper
ael
esta
dode
lum
bral
deac
tivac
ión
para
unpe
rfil
se-
cund
ario
deus
uari
o.vo
iden
able
Con
text
Con
trol
(IC
onte
xtC
ontr
olla
ble
cont
rolla
ble)
Con
figur
aun
aap
licac
ión
para
que
esta
pued
ase
rcon
trol
ada
por
elm
ódul
om
anej
ador
depe
rfile
sde
usua
rio.
void
enab
leD
efau
ltSec
Profi
le(S
trin
gco
ntro
llabl
eID
)A
ctiv
ael
perfi
lsec
unda
rio
deus
uari
opo
rdef
ecto
deun
aap
lica-
ción
.A
pplic
atio
nPro
fileM
anag
erge
tIns
tanc
e()
Rec
uper
aun
are
fere
ncia
ala
inst
anci
aún
ica
dela
clas
epr
inci
pal
delM
ódul
o.St
ring
[]ge
tPre
fere
nce(
Stri
ngpr
efer
ence
ID)t
hrow
sE
xcep
tion
Rec
uper
aun
arre
glo
con
elid
entifi
cado
rde
lre
curs
oy
valo
rel
valo
rde
suco
nfigu
raci
ónpa
raun
apr
efer
enci
ade
lcon
junt
ogl
o-ba
lde
pref
eren
cias
.St
ring
[]ge
tRul
e(St
ring
rule
ID)t
hrow
sE
xcep
tion
Rec
uper
aun
arre
glo
con
elid
entifi
cado
rde
lafu
ente
deco
ntex
toy
laco
ndic
ión
para
una
regl
ade
lcon
junt
ogl
obal
dere
glas
.vo
idre
mov
ePre
fere
nce(
Stri
ngpr
efer
ence
ID)t
hrow
sE
xcep
tion
Elim
ina
una
pref
eren
cia
delc
onju
nto
glob
alde
pref
eren
cias
.vo
idre
mov
eRul
e(St
ring
rule
ID)t
hrow
sE
xcep
tion
Elim
ina
una
regl
ade
lcon
junt
ogl
obal
dere
glas
.vo
idre
mov
eSec
Use
rPro
file(
Stri
ngap
pID
,St
ring
secU
serP
rofil
eID
)th
row
sE
xcep
tion
Elim
ina
unpe
rfils
ecun
dari
ode
usua
rio
para
una
aplic
ació
n.
void
rem
oveS
ecU
serP
rofil
eRul
e(St
ring
appI
D,
Stri
ngse
cUse
rPro
fi-le
ID,S
trin
gru
leID
)thr
ows
Exc
eptio
nE
limin
aun
are
gla
deun
perfi
lsec
unda
rio
deus
uari
o.
void
rem
oveS
ecU
serP
rofil
eSet
(Str
ing
appI
D)t
hrow
sE
xcep
tion
Elim
ina
todo
slo
spe
rfile
sse
cund
ario
sde
usua
rio
para
una
apli-
caci
ón.
84
void
setD
efau
ltSec
Use
rPro
file(
Stri
ngap
pID
,St
ring
secU
serP
rofi-
leID
)thr
ows
Exc
eptio
nE
stab
lece
elpe
rfils
ecun
dari
opo
rom
isió
npa
raun
aap
licac
ión.
void
setP
refe
renc
e(St
ring
cont
rolla
bleI
D,S
trin
gpr
efer
ence
ID,S
trin
gva
lue)
thro
ws
Exc
eptio
nC
onfig
ura
una
pref
eren
cia
enun
aap
licac
ión
con
cont
rolh
abili
-ta
dopo
rpar
tede
lmod
ulo.
void
setS
ecU
serP
rofil
ePre
fere
nce(
Stri
ngap
pID
,Str
ing
secU
serP
rofi-
leID
,Str
ing
pref
eren
ceID
)thr
ows
Exc
eptio
nC
onfig
ura
una
pref
eren
cia
para
unpe
rfils
ecun
dari
ode
usua
rio.
La
pref
eren
cia
debe
sera
dici
onad
apr
evia
men
teal
conj
unto
glo-
bald
epr
efer
enci
as.
void
setS
ecU
serP
rofil
eRul
e(St
ring
appI
D,
Stri
ngse
cUse
rPro
fileI
D,
Stri
ngru
leID
)thr
ows
Exc
eptio
nC
onfig
ura
una
regl
apa
raun
perfi
lsec
unda
rio
deus
uari
o.L
are
-gl
ade
bese
radi
cion
ada
prev
iam
ente
alco
njun
togl
obal
dere
glas
.vo
idse
tSec
Use
rPro
fileT
imeo
ut(S
trin
gap
pID
,St
ring
secU
serP
rofi-
leID
,int
timeo
ut)t
hrow
sE
xcep
tion
Con
figur
ael
tiem
pode
expi
raci
ónpa
raun
perfi
lsec
unda
rio
deus
uari
o.vo
idst
artS
econ
dary
Use
rPro
files
(Str
ing
cont
rolla
bleI
D)
thro
ws
Ex-
cept
ion
Inic
iael
cheq
ueo
auto
mát
ico
para
todo
slo
spe
rfile
sse
cund
ario
sde
usua
rio
regi
stra
dos
por
una
aplic
ació
n,pr
evia
activ
ació
nde
lco
ntro
lde
laap
licac
ión
porp
arte
delm
ódul
o.vo
idst
opSe
cond
aryU
serP
rofil
es(S
trin
gco
ntro
llabl
eID
)th
row
sE
x-ce
ptio
nD
etie
neel
cheq
ueo
auto
mát
ico
para
todo
slo
spe
rfile
sse
cund
a-ri
osde
unus
uari
ore
gist
rado
spo
runa
aplic
ació
n.
85
Cua
dro
A.4
:Mét
odos
Mód
ulo
App
licat
ion
Profi
le
Tipo
reto
rno
Sign
atur
eD
escr
ipci
ón
void
addA
ppPr
ofile
(Str
ing
appI
D,i
ntty
pes)
thro
wsR
equi
rem
ents
Ex-
cept
ion,
Exc
eptio
nIn
tent
aad
icio
naru
npe
rfild
eap
licac
ión,
deac
uerd
oa
tipos
pre-
defin
idos
(con
junt
osde
requ
erim
ient
os),
lanz
ando
una
exce
p-ci
ónsi
elam
bien
tede
ejec
ució
nno
cum
ple
algú
nre
quer
imie
nto.
void
appA
ppPr
ofile
(Str
ing
appI
D,S
trin
g[]
perm
s,in
t[]
apis
)th
row
sR
equi
rem
ents
Exc
eptio
n,E
xcep
tion
Inte
nta
adic
iona
run
perfi
lde
aplic
ació
nen
elm
anej
ador
,dad
osun
osco
njun
tos
dere
quer
imie
ntos
para
AP
Isy
perm
isos
Lan
zaun
aex
cepc
ión
siel
ambi
ente
deej
ecuc
ión
nocu
mpl
eal
gún
re-
quer
imie
nto.
.vo
idad
dApp
Profi
le(S
trin
gap
pID
)thr
ows
Exc
eptio
nA
dici
ona
unpe
rfild
eap
licac
ión
vací
o(s
inre
quer
imie
ntos
)vo
idad
dApp
Profi
leR
equi
rem
ent(
Stri
ngap
pID
,St
ring
perm
)th
row
sR
equi
rem
ents
Exc
eptio
n,E
xcep
tion
Inte
nta
adic
iona
run
requ
erim
ient
ode
perm
isos
aun
perfi
lde
aplic
ació
n,ge
nera
ndo
una
exce
pció
nsi
elam
bien
tede
ejec
ució
nno
losa
tisfa
ce.
void
addA
ppPr
ofile
Req
uire
men
t(St
ring
appI
D,i
ntap
i)th
row
sReq
ui-
rem
ents
Exc
eptio
n,E
xcep
tion
Inte
nta
adic
iona
run
requ
erim
ient
ode
AP
Ia
unpe
rfild
eap
lica-
ción
,ge
nera
ndo
una
exce
pció
nen
caso
dequ
eel
ambi
ente
deej
ecuc
ión
nolo
satis
faga
.vo
idad
dPer
mis
sion
sSet
(Str
ing
appI
D,
Stri
ngse
tID
)th
row
sE
xcep
-tio
nA
dici
ona
unco
njun
tova
cío
depe
rmis
osde
usua
rio
aun
perfi
lde
aplic
ació
n.vo
idad
dPer
mis
sion
ToPe
rmis
sion
sSet
(Str
ing
appI
D,
Stri
ngse
tID
,St
ring
perm
issi
onID
,Str
ing
valu
e)th
row
sE
xcep
tion
Adi
cion
aun
perm
iso
deus
uari
oa
unco
njun
tode
perm
isos
deun
perfi
lde
aplic
ació
n,re
cibi
endo
entr
esu
spa
rám
etro
sel
iden
tifi-
cado
rdel
nuev
ope
rmis
oy
elva
lord
elm
ism
o.St
ring
getP
erm
issi
onFr
omPe
rmis
sion
sSet
(Str
ing
appI
D,
Stri
ngse
tID
,St
ring
perm
issi
onID
)thr
ows
Exc
eptio
nR
ecup
era
elva
lor
deun
perm
iso
deus
uari
oen
unco
njun
tode
perm
isos
deun
perfi
lde
aplic
ació
n.bo
olea
nch
eckA
ppPr
ofile
Req
uire
men
t(St
ring
appI
D,
Stri
ngpe
rm)
th-
row
sE
xcep
tion
Ver
ifica
lapr
esen
cia
deun
requ
erim
ient
ode
perm
isos
enun
per-
filde
aplic
ació
n,y
port
anto
susa
tisfa
cció
npo
rpar
tede
lam
bien
-te
deej
ecuc
ión.
Req
uier
ela
adic
ión
prev
iade
lreq
ueri
mie
nto.
bool
ean
chec
kApp
Profi
leR
equi
rem
ent(
Stri
ngap
pID
,int
api)
thro
ws
Ex-
cept
ion
Ver
ifica
lapr
esen
cia
deun
requ
erim
ient
ode
AP
Ien
unpe
rfild
eap
licac
ión,
esto
ses
,su
satis
facc
ión
por
part
ede
lam
bien
tede
ejec
ució
n.R
equi
ere
laad
ició
npr
evia
delr
eque
rim
ient
o.
86
App
licat
ionP
rofil
ege
tIns
tanc
e()
Rec
uper
aun
are
fere
ncia
ala
inst
anci
aún
ica
dela
clas
epr
inci
pal
delM
ódul
o,ha
bilit
ando
las
func
ione
squ
ere
quie
ren
acce
soa
unM
IDle
t.
87
API
MMAPI
PIMAPI
M3GAPI
LOCATIONAPI
BTAPI
FILECONNAPI
INTERNAPI
CHAPI
SIPAPI
WMAPI
AMSAPI
VECTOR2DAPI
PAYMENTAPI
CONTACTLESSAPI
SENSORAPI
OBEXAPI
IAPINFO
Tipo
Blu
etoo
thx
Tipo
HT
TP
Tipo
GPS
x
Tipo
SMS
x
Tipo
back
grou
nd
Tipo
segu
ra
Tipo
repr
oduc
torm
ultim
edia
xx
Cua
dro
A.5
:Con
junt
ospr
edefi
nido
sde
requ
erim
ient
osde
AP
Ispa
-
rael
Mód
ulo
App
licat
ion
Profi
le
88
Bibliografía
[BD03] Louise Barkhuus and Anind Dey. Is Context-Aware Computing Taking Control away from
the User? three Levels of Interactivity Examined. In Anind K. Dey, Albrecht Schmidt, and Jo-
seph F. McCarthy, editors, UbiComp 2003: Ubiquitous Computing, pages 149–156. Springer,
2003.
[Bon11] Leyla Bonilla Palacio. Orquestación e Invocación de Servicios como parte de un Framework
para el Desarrollo de Aplicaciones Móviles Pervasive. Caso Asistente de Compras para Usua-
rios de Almacenes Retail. Universidad de los Andes, 2011. Tesis de pregrado.
[CQS06] Luhui Cao, Qingzhong, and Qi Sui. A Service-oriented Adaptive Framework for Pervasive
Computing. In 2006 1st International Symposium on Pervasive Computing and Applications,
pages 631–634, 2006.
[CRVOG07] A. Carrillo-Ramos, M. Villanova-Oliver, and J. Gensel. Contextual User Profile for Adapting
Information in Nomadic Environments. In WISE 2007 Workshops, pages 337–349, 2007.
[DA01] Anind K. Dey and Gregory D. Abowd. A Conceptual Framework and a Toolkit for Supporting
the Rapid Prototyping of Context-Aware Applications. Human-Computer Interaction, 16:97–
166, 2001.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[Góm10] A. Gómez Dalleman. Diseño y Desarrollo de una Solución Pervasive en el Contexto de las
Restricciones de un Dispositivo Móvil. Universidad de los Andes, 2010. Tesis de pregrado.
[Hay09] Roy Ben Hayun. Java ME on Symbian OS. Wiley, 2009.
[Hen11] Arturo Henao Chaparro. Diseño de un Framework que Soporta la Construcción de Soluciones
Pervasive y Aplicación Ejemplo en el Contexto del Transporte Escolar. Universidad de los
Andes, 2011. Tesis de pregrado.
[HMNS03] Uwe Hansmann, Lothar Merk, Martin S. Niklous, and Thomas Stober. Pervasive Computing.
Springer, Böblingen, Germany, 2003.
89
[NMKS06] P. Nagpurkar, H. Mousa, Ch. Krintz, and T. Sherwood. Efficient Remote Profiling for
Resource-Constrained Devices. ACM Transactions on Architecture and Code Optimization,
3(1):35–66, 2006.
[Pol10] Alberto Polzonetti. User-Centric Mobile Services: Context Provisioning and User Profiling.
In Proceedings of the 11th Annual International Conference on Digital Government Research,
pages 122–130, 2010.
[Ram11] Lorena Ramírez. Diseño de un Framework para la Construcción de Soluciones Pervasive y
Desarrollo de un Caso de Estudio en el Contexto de la Movilidad Bogotana. Universidad de
los Andes, 2011. Tesis de pregrado.
[ST94] B. Schilit and M. Theimer. Disseminating Active Map Information to Mobile Hosts. IEEE
Network, 8(5):22–32, 1994.
[Wei99] Mark Weiser. The Computer for the 21st Century. ACM SIGMOBILE Mobile Computing and
Communications Review, 3(3):3–11, 1999.
[YJ10] Miguel Yáñez and Claudia Jimenez. TOTEM: Privacy Model using Tolerance Thresholds in
Pervasive Applications. Artículo sin publicar, 2010.
[YOH03] Nobukazu Yoshioka, Akihiko Ohsuga, and Shinichi Honiden. A Multiagent Framework for
Pervasive Computing: The Mobeet Framework. Electrical Engineering in Japan, 149(3):49–
64, 2003.
[ZMA+10] Claudia L. Zuñiga, Andrés F. Millán, José L. Abadía, Monica Lora, Andrés Navarro, Juan C.
Burguillo, and Pedro S. Rodriguez. Design of Service-Oriented Pervasive System for Urban
Computing in Cali Zoo (Openzoo). In World Academy of Science, Engineering and Techno-
logy, number 63, pages 70–75, 2010.
90