Generación de un campus activo a través de una
solución basada en movilidad tipo pervasive
Andrés Felipe Melani
UNIVERSIDAD DE LOS ANDES
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
BOGOTÁ, D.C.
Generación de un campus activo a través de una
solución basada en movilidad tipo pervasive
Andrés Felipe Melani
Documento de Proyecto de Grado para optar al título de Ingeniero de Sistemas
y Computación
Directora: Claudia Lucía Jiménez Guarín, Ph. D.
Profesora asociada
UNIVERSIDAD DE LOS ANDES
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
BOGOTÁ, D.C.
Contenido
1. INTRODUCCIÓN... 1
1.1 Objetivo principal del proyecto ... 3
1.2 Objetivos específicos... 3
1.3 Consideraciones y restricciones ... 3
2. MARCO TEÓRICO Y TRABAJOS RELACIONADOS ... 5
2.1 Tecnologías a usar ... 5
2.1.1 Localización ... 5
2.1.1.1 Localización basada en Bluetooth ... 5
2.1.1.2 Localización basada en Global Positioning System (GPS) ... 6
2.1.2 Representación y modelamiento de datos ... 6
2.1.2.1 RDF (Resource Description Framework) ... 6
2.2 Trabajos relacionados ... 8
3 ESTRATEGIA DE SOLUCIÓN ... 10
3.1 Descripción global de la solución ... 10
3.2 Casos de uso ... 14
3.3 Árbol de utilidad ... 15
3.4 Plan de pruebas ... 16
4 DISEÑO DETALLADO DE LA SOLUCIÓN ... 18
4.1 Diagrama de componentes detallado... 18
4.2 Diagramas de secuencia ... 19
4.3 Aplicación móvil ... 21
4.3.1 Componentes de geolocalización ... 22
4.3.2 Componentes EstadiaLugar y Lugares Frecuentados ... 23
4.3.3 Componente consulta de eventos ... 25
4.3.5 Activities de la aplicación ... 27
4.3.6 Filtros de Broadcast para consumir los servicios expuestos ... 28
4.4 Servidor SIEGE ... 29
5 IMPLEMENTACIÓN Y PRUEBAS ... 30
5.1 Plataforma de desarrollo ... 30
5.2 Retos en implementación ... 30
5.3 Resultados de pruebas ... 31
6 CONCLUSIONES Y TRABAJO FUTURO ... 42
Índice de figuras
Ilustración 1. Grafo RDF ... 7
Ilustración 2. Esquema general de la solución ... 10
Ilustración 3. Arquitectura global de la solución ... 13
Ilustración 4. Casos de uso ... 14
Ilustración 5. Diagrama de componentes detallado ... 18
Ilustración 6. Diagrama de secuencia - Eventos de la ubicación actual ... 19
Ilustración 7. Diagrama de secuencia - Almacenamiento posible lugar frecuentado ... 20
Ilustración 8. Diagrama de secuencia - Eventos a partir de lugar frecuentado ... 21
Ilustración 9. Componentes geolocalización ... 22
Ilustración 10. Diagrama de clases - componentes EstadiaLugar y LugaresFrecuentados ... 23
Ilustración 11. Estructura tablas Base de datos Lugares Frecuentados ... 24
Ilustración 12. Diagrama de clases componente consulta eventos ... 25
Ilustración 13. Diagrama de clases - Intereses y Principal ... 26
Ilustración 14. Diagrama de clases - MainActivity y RegistroActivity ... 27
Agradecimientos
Quiero agradecer principalmente a mi familia por el continuo apoyo que me han brindado durante toda mi vida y especialmente durante este trayecto de mi vida académica, que he logrado superar con éxito gracias a ellos para convertirme en un profesional del cual puedan estar orgullosos. Igualmente debo agradecer a mis amigos, cuya amistad y compañía fue muy valiosa para superar los momentos difíciles que se llegan a presentar en el camino; y a mis compañeros de tesis, que, aunque cada quién trabajó en su propio proyecto, fueron de gran ayuda para cumplir con todos los objetivos propuestos en el presente trabajo.
Finalmente, pero no por eso menos importante, quiero agradecer a mi asesora de tesis, Claudia Jiménez, por su constante guía que permitió el desarrollo del presente trabajo, por el tiempo dedicado a revisar y corregir errores que llegaron a presentarse en la realización del proyecto con tal de que el trabajo hecho resultase de la mejor calidad posible, y sobre todo por el apoyo que siempre me brindó y que me motivó a dar mi mejor esfuerzo para llevar a cabo el proyecto.
"Your work is going to fill a large part of
your life, and the only way to be truly
satisfied is to do what you believe is great
work. And the only way to do great work
is to love what you do.”
1
1. Introducción
Un anhelo que se tiene actualmente en muchas organizaciones es el de poder proveer información que resulte útil e interesante a cada uno de los individuos que se ven involucrados con la organización, y en los momentos en que lo requieran. Sin embargo, esto puede resultar difícil ya que cada persona tiene comportamientos e intereses muy diversos, que no pueden ser agrupados simplemente en roles predeterminados, ya que se tendería a caer en caracterizaciones equivocadas y posteriormente a dar información que no resulta relevante para la gran mayoría de personas. Por esta razón, se debe buscar una alternativa que de una identidad única a cada individuo, y que le puede ofrecer aquello que en verdad le resulta importante. Las soluciones pervasive plantean un modelo para lograr este objetivo, ya que manejan el hecho de que el usuario posee un contexto propio, que varía en gran medida con respecto al de cualquier otro individuo, inclusive dentro de una misma organización. Además, la computación pervasive busca estar siempre disponible cuando y donde se le necesite, lo cual con los dispositivos móviles actuales se puede lograr fácilmente, de modo que también se puede cubrir el objetivo de proveer la información adecuada en los momentos adecuados; aparte de tener la ventaja de ocultar la complejidad computacional al usuario, manteniendo una interacción mínima con este, de forma tal que resulta muy fácil para el usuario obtener aquello que quiere, sin ninguna interacción compleja (o inclusive sin interacción alguna).
Para lograr construir una solución pervasive es primordial la construcción del contexto del usuario de la forma más transparente posible para este. Ahí es cuando el uso de diversos sensores resulta especialmente útil, ya que permiten recoger toda clase de datos relacionados al contexto del usuario sin que este tenga que proveerlos directamente; algunos ejemplos de datos necesarios para la creación del contexto del usuario pueden ser su localización, tiempo (hora, día), clima actual, actividad que está realizando, etc. Los dispositivos móviles actuales proveen los sensores que se requieren para la recopilación de estos datos, así que es en estos donde se pueden desarrollar más fácilmente soluciones
pervasive de todo tipo; y además se debe aprovechar el hecho de que gran cantidad de personas poseen por lo menos un dispositivo móvil, de modo que ya la tecnología está masificada y se requiere simplemente el desarrollo de la solución.
Así mismo como se puede construir el contexto de una persona en un momento determinado con la información recopilada por los sensores presentes en los dispositivos, se pueden identificar comportamientos propios de cada individuo y llegar a predecir que puede querer o que puede hacer en un futuro próximo; y así generar recomendaciones basado en el perfil de usuario identificado, o incluso llegar a proveer información relacionada con aquello que se espera que realicé el usuario con anterioridad. Esto permite entonces darle más facilidades al usuario sin la necesidad de la lectura de un contexto
2
actual, sino proveerle anticipadamente aquello que necesita gracias al contexto futuro que se puede crear con los patrones encontrados. A pesar de que esto puede resultar de gran ayuda, se debe tener en cuenta que los comportamientos pueden ser muy volátiles, así que una solución pervasive que desee implementar una funcionalidad de este tipo debe de estar lista a cambiar de la misma manera que lo pueden hacer los hábitos de cada individuo.
Ya conociendo de forma general cómo puede una solución pervasive apoyar a los usuarios en una organización a obtener servicios e información de una forma más personalizada, se puede ver un ejemplo: Una universidad. Un estudiante tiene un horario propio, el cual tiene sincronizado en su dispositivo móvil. El dispositivo puede identificar la ubicación actual del estudiante, y al comparar el horario de clases con la hora actual puede llegar a identificar que el estudiante tiene clase en 10 minutos y aún no está en el salón, por ejemplo. Así, le puede informar al estudiante que tiene clase pronto, además del salón. Al finalizar la clase, el estudiante suele ir a almorzar a la cafetería de la universidad. El dispositivo de este ha detectado ya este patrón, así que un tiempo antes de que llegue la hora del almuerzo le notifica al estudiante el menú de ese día, para que pueda tomar la decisión de si quiere ir a la cafetería de nuevo o mejor a otro lugar. Así mismo, el dispositivo puede informarle toda clase de información que le interese al estudiante según lo que suele realizar: Supóngase que el estudiante tiene como habito reservar una sala de estudios los martes en la tarde. El dispositivo “recuerda” esto, así que unos minutos antes de la hora en que el usuario suele hacer esto, revisa si hay disponibilidad de salas y le informa al usuario, para que en caso de que no sea posible reservar una, mejor se dirija a otro lugar. Esta clase de ejemplos son los que se solucionan con la computación pervasive, y dan lugar a un ambiente activo, donde el usuario está informado todo el tiempo con aquello que le importa y de lo que sucede en los lugares que le interesan sin necesidad de realizar ninguna interacción compleja con algún dispositivo, lo cual en dado caso le puede ayudar a tomar una mejor decisión sobre qué hacer a continuación; todo gracias a que fue posible construir su contexto con la ayuda de los sensores presentes en su dispositivo y tal vez con algunos externos.
El presente proyecto busca lograr implementar un ambiente activo en el contexto de la Universidad de Los Andes, ofreciendo una aplicación móvil dirigida a los miembros de la comunidad universitaria, y apoyada en algunos sensores y sistemas externos, que permitan lograr crear un contexto adecuado de cada usuario y que le provean a cada uno información que le resulte útil del campus, según sus intereses y comportamientos, de modo que les sea más fácil llevar a cabo sus rutinas.
3
1.1 Objetivo principal del proyecto
Diseñar e implementar una solución basada en movilidad para la creación de un ambiente activo en el contexto de la Universidad de Los Andes, que le provea a su comunidad información que le resulte útil sobre el campus, siguiendo los principios de una solución
pervasive. Se busca proveer información relevante de los lugares en los que se encuentran los usuarios, o sobre aquellos lugares que frecuentan en el campus. Con tal de cumplir este fin, el sistema desarrollado debe ser capaz de:
- Notificar al usuario información importante del campus a partir de su perfil, lugar en que se encuentra e intereses y comportamiento habitual.
- Identificar los intereses y comportamientos habituales de las personas vinculadas a la Universidad, a partir de sus perfiles y lugares que suelen frecuentar en el campus, con el fin de poder proveer información relevante para cada uno de estos.
- Diseñar y desarrollar una aplicación móvil que permita proveer información relevante a los usuarios según su localización y comportamientos.
1.2 Objetivos específicos
Utilizar un conjunto de beacons que cuenten con Bluetooth LE 4.0 en el campus y el dispositivo del usuario para identificar la ubicación indoor del usuario sin interacción por parte de este, con un margen de error no mayor a 3 metros.
Utilizar el GPS del dispositivo para ubicar al usuario en caso de no ser posible realizar la ubicación por beacons. Se debe poder identificar como mínimo el edificio en el cual se encuentra al usuario, y el margen de error máximo no debe sobrepasar los 10 metros.
Integrar elementos del proyecto SIEGE para el almacenamiento de información relativa a lugares en el campus y eventos que ocurren dentro de este. Se espera en particular aprovechar la capacidad de inferencia de este sistema para proveer información que resulte relevante al usuario.
Identificar patrones de comportamiento de los usuarios en el campus teniendo en cuenta lugares que frecuenta y horarios en los que va a estos sitios, para proveer con anticipación información relevante.
1.3 Consideraciones y restricciones
El presente proyecto busca proveer sus servicios a la comunidad relacionada con la Universidad de Los Andes, en la cual podemos en general segmentar en los siguientes perfiles: Estudiantes, profesores, empleados, contratistas, visitantes y personas de servicios generales. El presente trabajo se centra en tres de estos perfiles, que corresponden a estudiantes, profesores y empleados, con el fin de realizar las pruebas de diseño e implementación de la solución; aun así, la solución planteada debe poder integrar los demás perfiles sin sufrir grandes modificaciones o eventualmente ninguna.
4
En lo que respecta a la aplicación móvil desarrollada, el alcance propuesto es para sistemas Android 4.1 o superior, que es uno de los sistemas operativos que predomina en la comunidad uniandina.
5
2. Marco teórico y trabajos relacionados
En este capítulo se muestran las tecnologías usadas para el desarrollo de la solución al problema planteado anteriormente. Se presentan primero las tecnologías que permiten el desarrollo de la solución y posteriormente trabajos realizados previamente en torno a un tema similar que pueden resultar relevantes para el presente proyecto.
2.1 Tecnologías a usar
En esta sección se presentan las tecnologías principales que se usan para el desarrollo del presente proyecto, se describen sus características y el por qué son útiles para el desarrollo de este trabajo.
2.1.1 Localización
Las tecnologías de localización permiten ubicar a un objeto o persona dentro de un espacio determinado. En el presente proyecto resulta de vital importancia el poder ubicar a las personas (o más específicamente a sus dispositivos) dentro del campus universitario para poder proveerlos de información útil sobre los lugares que visitan y suelen visitar, por ende es relevante revisar las tecnologías que posibilitan la localización para este trabajo específico.
2.1.1.1 Localización basada en Bluetooth
Bluetooth Low Energy (BLE) [1] es un estándar para la creación de redes de corto alcance, que resulta muy útil debido a su bajo consumo de energía. Gracias a que estos dispositivos ofrecen una forma de detectar proximidad a otro, a través del Bluetooth Proximity Profile (PXP) [2], es posible usarlos como medio de localización al ubicar una serie de estos dispositivos en un lugar determinado – almacenando la información de las ubicaciones de los dispositivos de forma que sea posible recuperarla posteriormente para realizar el proceso de localización – y especificar los comportamientos para cuando un dispositivo se acerca o aleja de otro.
Actualmente, existen varias aplicaciones que usan esta clase de dispositivos BLE que ofrecen servicios de proximidad para realizar procesos de localización. Uno de los más populares es el iBeacon [3], una especificación desarrollada por Apple Inc. para dispositivos BLE que permite la localización de estos, y que provee un API para dispositivos iOS para implementar estos servicios (Aunque actualmente existen también variedad de APIs para el sistema operativo Android).
Cuando un dispositivo posee iBeacon, emite una señal de reconocimiento que puede ser percibida por otros dispositivos, sin la necesidad de realizar un emparejamiento previo. Esta señal tiene los siguientes componentes [4]:
6
UUID (Universally Unique Identifier): Una cadena de 16 bytes que identifica a un iBeacon o un grupo de estos en un sistema.
Major: Una cadena de 2 bytes que permite hacer una subdivisión de una región (conjunto de iBeacons) que posee un determinado UUID.
Minor: Una cadena de 2 bytes que permite realizar una mayor subdivisión de un conjunto de iBeacons. Se usa frecuentemente para identificar iBeacons individuales.
Por la facilidad de uso y precisión de la tecnología iBeacon, los costos relativamente bajos de los dispositivos que la implementan y gracias a los APIs disponibles para Android, esta será la tecnología de localización a usar en el presente trabajo.
2.1.1.2 Localización basada en Global Positioning System (GPS)
Global Positioning System [16] es un sistema que permite ubicar las coordenadas – longitud y latitud – de un dispositivo que cuente con esta característica en cualquier parte del planeta; para encontrar la posición del dispositivo se realiza una triangulación a partir de las señales provenientes de un conjunto de satélites que orbitan la Tierra. Actualmente se cuenta con 31 satélites en órbita, con mínimo 24 de estos en funcionamiento el 95% del tiempo.
Hoy en día la gran mayoría de dispositivos móviles cuentan con GPS, de forma que para el presente proyecto esta tecnología representa una buena alternativa a la localización por
beacons cuando ese medio no está disponible. La precisión con esta tecnología es menor a la que se puede lograr con beacons, pero es una opción válida para obtener por lo menos el edificio donde se encuentra el usuario en el campus.
2.1.2 Representación y modelamiento de datos
Para poder realizar el manejo de la información relacionada a gustos de los usuarios, eventos y demás datos relacionados con los lugares en el campus, aparte de la necesidad de tener un acceso ágil a los mismos para cumplir con las características pervasive de la solución, se hace necesario usar un modelo de datos diferente al relacional, por la complejidad que implicaría para representación y recuperación de la información. Se utilizará entonces el modelo propuesto en el proyecto SIEGE [5], sobre el cual se basa el presente trabajo, cuyos componentes serán presentados a continuación.
2.1.2.1 RDF (Resource Description Framework)
RDF [6] es un framework utilizado para representar información en la Web. Uno de los puntos más importantes sobre este es que ofrece la posibilidad de mezclar diversos datos aun cuando los esquemas subyacentes a estos difieren, y además soporta la evolución de los esquemas de datos en el tiempo sin la necesidad de que deban cambiar los consumidores de los datos. RDF se presenta con una estructura de grafo dirigido, y la información se presenta en una forma conocida como triples, que incluyen un sujeto, predicado y objeto, donde la relación existente entre sujeto y objeto es dada por el predicado.
7
Esta representación resulta útil para el propósito de este proyecto ya que todos los sujetos y propiedades están definidos dentro de una ontología, que da un significado semántico a la información representada en esta forma; RDF pone la información en una codificación formal y la ontología provee un mecanismo de interpretación de modo que pueda ser entendida por software – permite la creación de reglas a través de las cuales más información sobre los sujetos descritos puede ser inferida por lógica – sin necesidad de la intervención de otro mecanismo aparte de la descripción de los triples RDF.
La ontología a utilizar en el presente proyecto es OWL (Web Ontology Language) [7]. Antes de pasar a describir las características de OWL, se presentarán algunas definiciones importantes:
Clase: Define un grupo de personas que presentan características comunes.
Individuos: Instancias de clases, para las cuales se pueden establecer relaciones entre instancias.
Propiedad: Relación binaria que denota una relación entre individuos o de un individuo a un valor literal. En OWL, se distinguen en ObjectTypeProperties (relación entre individuos de una clase) y DataTypeProperties (relación de un individuo a un valor literal).
OWL está basado en RDFS [8], que es el vocabulario más simple para la representación de información semántica para describir datos en RDF. RDFS permite el modelamiento de clases y propiedades de la información almacenada en RDF, pero tiene capacidades de razonamiento muy limitadas, como no permitir el uso de restricciones o propiedades inversas. OWL amplía las capacidades de RDFS adicionando representación para las relaciones entre clases, cardinalidad, igualdad, mayor cantidad de propiedades, características de propiedades y clases enumeradas. OWL permite además la puesta de restricciones sobre propiedades de clases.
Para este caso, al igual que lo fue para el proyecto SIEGE, se requieren las siguientes construcciones de lenguaje:
Modelar relaciones inversas con el fin de realizar pedidos por objetos contenidos en un lugar
Modelar relaciones transitivas para ser capaz de determinar el conjunto de espacios donde está ubicado un beacon; se requiere poder construir una cadena desde el
beacon, a la habitación donde está ubicado, al edificio, etc.
8
Se debe poder razonar sobre el rango y dominio de propiedades, ya que se quiere membresía a la clase para que los atributos sean dinámicos y basados en otros triples.
Se requiere poder definir clases como intersecciones de otras clases o como complementos a otras clases.
OWL permite definir todas estas construcciones, pero como puede ser computacionalmente costoso inferir todos los triples posibles de un conjunto, se puede utilizar un subconjunto de OWL para la implementación, el cual en este caso es OWL-DL [7].
2.2 Trabajos relacionados
Un trabajo que resulta interesante consultar para el desarrollo del presente proyecto es comMotion [9], el cual es un sistema que conoce la localización del usuario y a partir de estos datos le provee información de interés para él. Algo que tiene en cuenta comMotion y que es relevante para este trabajo es el hecho de que buscaba reconocer los lugares que el usuario frecuenta y los momentos en que se dirige a estos, para poder notificarle información relevante a la persona de forma anticipada a partir de la identificación de patrones, algo que este proyecto busca lograr. Las diferencias que presenta comMotion con el presente trabajo es que se concentra en localizaciones outdoor del usuario y a escala de una ciudad, mientras que aquí se busca localizaciones indoor y se maneja una escala de campus universitario. Las tecnologías también difieren, ya que comMotion utiliza GPS para la localización del usuario, mientras en este proyecto se trabaja con dispositivos BLE. A pesar de esto, el objetivo de comMotion de proveer información al usuario por su localización y especialmente el hecho de reconocimiento de lugares frecuentados plantean una base interesante para este proyecto.
Otro proyecto que provee información relevante para el presente trabajo es Metronaut [10], desarrollado en la Universidad Carnegie Mellon (CMU, por sus siglas en inglés). El propósito principal de Metronaut es proveer a los visitantes del campus de CMU una forma de guía y arreglo de horario en su visita a la Universidad. Metronaut no es solo un software, sino un dispositivo también; puede identificar la localización del usuario a partir de la lectura de códigos de barras ubicados en el campus y definir el horario de las reuniones que pueda tener el visitante a partir de negociaciones con otros sistemas. Lo que resulta interesante de Metronaut para el presente proyecto es el hecho de proveer a visitantes información relevante para ellos como una guía a través del campus y los horarios a manejar, lo cual se asemeja al objetivo de prestar información importante a visitantes de la Universidad de Los Andes presente en el actual proyecto. Metronaut se diferencia del presente trabajo en que es una solución que no presenta una característica vital de las soluciones pervasive, que es mantener la interacción directa con el usuario en lo mínimo posible, ya que requiere de la lectura de los códigos de barras para poder localizar al usuario en el campus. Aún así, presenta una visión interesante de cómo se puede prestar
9
información sobre el campus a los visitantes, y por ende sirve como una base para este proyecto.
Otro trabajo que provee una base interesante para el presente proyecto es el Wearable Remembrance Agent [11], desarrollado en el MIT Media Lab. Este consiste en un dispositivo wearable, que permite la toma de datos del contexto del usuario (notas, personas, lugar, etc.), para posteriormente proveer información relevante a este, cuando se encuentre en un contexto similar. Además, puede proveer al usuario información anticipadamente, cuando considera que el contexto inmediato lo amerita. De este proyecto resulta interesante resaltar su capacidad de inferir el contexto del usuario a partir del uso de sensores, como GPS, sistemas de localización indoor, micrófono, etc., algo que es característico de una solución pervasive y que se desea tener dentro del actual proyecto. Igualmente, Wearable Remembrance Agent busca proveer información relevante a cada usuario dependiendo de su contexto actual y otros contextos anteriores que resulten similares, es decir que puede recordar lo que el usuario suele hacer para poder proveerle datos que le resulten relevantes en momentos que considere adecuados; esto es muy parecido a lo que se quiere conseguir en el proyecto presentado en este documento. El trabajo del MIT Media Lab se diferencia del presente en que en el primero se provee un dispositivo wearable, no solo un software, para cumplir con el propósito de dar la información al usuario, y además los datos que maneja Wearable Remembrance Agent son recolectados por el mismo dispositivo en su funcionar, mientras que en el caso actual gran parte de la información que se va a presentar al usuario proviene de sistemas de información del campus de la Universidad de Los Andes.
Por último, otro trabajo relacionado con el actual proyecto es el proyecto SIEGE [5], que servirá como una de las bases principales para el presente trabajo. SIEGE es un sistema que a partir de la detección de la localización del usuario le provee información que puede resultar relevante sobre lo que sucede en el lugar en que se encuentra – o al que se encuentra próximo en su defecto –, teniendo en cuenta también el perfil del usuario y sus gustos. Además, el manejo de la información que hace SIEGE a través de RDF y una ontología le permite tener capacidades de inferencia que permiten proveer al usuario información verdaderamente relevante para este, pudiendo clasificar los datos por diversos aspectos que perfilen mejor a cada usuario. SIEGE es usado como base en el presente proyecto y se integran componentes de este, así que es de suma importancia resaltarlo como un trabajo relacionado al actual. El presente proyecto aprovecha las capacidades de SIEGE para generar el ambiente activo propuesto en el campus de la Universidad de Los Andes.
10
3 Estrategia de solución
3.1 Descripción global de la solución
La ilustración 2 muestra un esquema general del funcionamiento del proyecto. El dispositivo del usuario detecta los dispositivos iBeacon a través de Bluetooth LE, para obtener los datos de este – major y minor más exactamente – y así poder realizar un pedido al servidor de mapas para identificar la localización actual del usuario, el cual se realiza a través de HTTP [13], gracias a interfaces REST [14] expuestas por el servidor para interacción con este. El servidor de mapas provee el servicio de mapeo de los datos del
beacon a su localización dentro del campus, de tal forma que al realizar un pedido de ubicación retorna la ubicación del usuario. A través de SIEGE y su función de inferencia es posible obtener los datos relevantes de los lugares en el campus, ya que el modelo de información basado en RDF y OWL-DL es capaz de generar asociaciones entre los lugares y eventos que allí ocurren. Cabe mencionar aquí que los datos de eventos que poseía SIEGE no se encontraban actualizados, de manera que el presente proyecto provee un mecanismo para cargar la información actualizada de eventos y demás datos relevantes sobre los lugares. El anterior funcionamiento también se puede dar por detección de coordenadas por GPS, en caso de que no haya sido posible realizar ubicación por beacons.
11
En lo que respecta a la capacidad de reconocer lugares frecuentados por el usuario para proveerle de información anticipadamente, se maneja una base de datos local en el dispositivo, que es accedida a través de SQLite [12]. Allí se lleva la información de lugares que se identifiquen como frecuentados o potenciales frecuentados, teniendo en cuenta el criterio de que para ser incluido en la base de datos se debe permanecer más de X minutos en el lugar. Para conseguir la identificación de patrones, entendiendo un patrón como la costumbre del usuario de ir a un cierto lugar en un cierto día en un cierto horario, con el fin de definir un lugar frecuentado, se usa una aproximación de relaciones temporales, donde cada día de la semana se divide en franjas. Si el usuario permanece en un lugar durante más de X minutos, se genera una entrada nueva en la base de datos para tener en cuenta ese lugar. Para que este comportamiento se defina como un patrón y por ende se determine un lugar frecuentado, se calcula el soporte de cada entrada lugar-horario-día, que se define así:
Entiéndase como evento la estadía en un cierto lugar, por lo menos durante X minutos, en un cierto horario H de un día d. El horario H se refiere a un intervalo de la forma h±m
minutos, donde h es una hora del día. Para poder identificar un patrón, se debe realizar el cálculo del soporte, que es la probabilidad de que un evento ocurra nuevamente. Este está dado por la ecuación:
𝐸𝑣𝑒𝑛𝑡𝑜𝑈,𝑡 = (𝑈, 𝐿, 𝑑, ℎ𝑜, ℎ𝑓);
𝑑𝑜𝑛𝑑𝑒 𝑈 𝑒𝑠 𝑢𝑛 𝑢𝑠𝑢𝑎𝑟𝑖𝑜, 𝐿 𝑢𝑛 𝑙𝑢𝑔𝑎𝑟 𝑒𝑛 𝑒𝑙 𝑐𝑎𝑚𝑝𝑢𝑠, 𝑑 𝑢𝑛 𝑑𝑖𝑎 𝑑𝑒 𝑙𝑎 𝑠𝑒𝑚𝑎𝑛𝑎,
ℎ0 𝑙𝑎 ℎ𝑜𝑟𝑎 𝑑𝑒 𝑙𝑙𝑒𝑔𝑎𝑑𝑎 𝑎𝑙 𝑙𝑢𝑔𝑎𝑟 𝑦 ℎ𝑓 𝑙𝑎 ℎ𝑜𝑟𝑎 𝑑𝑒 𝑠𝑎𝑙𝑖𝑑𝑎 𝑑𝑒𝑙 𝑙𝑢𝑔𝑎𝑟.
𝑆𝑜𝑝𝑜𝑟𝑡𝑒𝑒𝑣𝑒𝑛𝑡𝑜 𝑗 =𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑝𝑒𝑡𝑖𝑐𝑖𝑜𝑛𝑒𝑠 𝑒𝑣𝑒𝑛𝑡𝑜 𝑗 ∑𝑈,𝑑𝐸; 𝑑𝑜𝑛𝑑𝑒 𝐸 𝑒𝑠 𝑢𝑛 𝑒𝑣𝑒𝑛𝑡𝑜
[𝐸𝑐𝑢𝑎𝑐𝑖ó𝑛 1]
El número de repeticiones del evento es entendido como el número de entradas correspondientes a ese evento dentro de la base de datos, que además están dentro de una ventana de tiempo V; esto con el fin de permitir identificar cambios en el patrón de forma rápida, ya que estos patrones pueden ser volátiles, es decir que pueden cambiar de forma repentina, así que el sistema debe ser capaz de reconocer cuando se empieza a dar un nuevo comportamiento. Para que se determine un patrón, el soporte de un evento debe superar un margen mínimo, que se conoce como el soporte mínimo.
𝑆𝑖 𝑠𝑜𝑝𝑜𝑟𝑡𝑒𝑒𝑣𝑒𝑛𝑡𝑜(𝑗) > 𝑠𝑜𝑝𝑜𝑟𝑡𝑒 𝑚í𝑛𝑖𝑚𝑜 → 𝑃𝑎𝑡𝑟ó𝑛 𝑛𝑢𝑒𝑣𝑜 [𝐸𝑐𝑢𝑎𝑐𝑖ó𝑛 2]
Como es posible ver en la ecuación de soporte, al aumentar el número de entradas se hace más complicado para un conjunto de eventos llegar a considerarse un patrón, ya que el soporte tiende a ser cada vez menor con el aumento de entradas. Si este comportamiento se da en el sistema, tomaría gran cantidad de tiempo conseguir el nuevo patrón, si es que se lograse reconocer eventualmente. Como solución a este problema, se plantea la ventana de
12
tiempo V ya mencionada, que permite tener en cuenta sólo entradas recientes. Esta solución se conoce como ventana deslizante.
Al ya tener definido un lugar frecuentado en su correspondiente franja horaria y día, se puede proceder a realizar peticiones acerca de eventos relacionados con el lugar frecuentado con anticipación. La petición se realizará de la misma forma que se realiza para el lugar en el que el usuario se encuentra en el momento, es decir, a través de HTTP utilizando las interfaces REST que ofrece el servidor SIEGE.
Otro factor relevante del proyecto es el reconocimiento de intereses del usuario. La solución plantea establecer una semántica a los eventos que se tienen en SIEGE. Esta semántica se refiere a que cada evento tiene relacionados los temas que trata, los cuales son obtenidos a través de OpenCalais. De esta forma los eventos tienen más significado, ya que se puede obtener de estos no solamente una descripción, sino además aquellos conceptos relacionados a este. Esto permite identificar y filtrar eventos por tema, lo cual es posible gracias a la ontología presente en SIEGE, y así obtener los eventos que presentan temas de interés para cada usuario. Cada vez que el usuario ve un evento de su interés, los temas relacionados a este evento se almacenan en una base de datos. Para lograr la identificación de los principales intereses, se revisa en la base de datos cuáles son los intereses que más veces aparecen en el conjunto de datos y que han sido agregados a la base de datos dentro de una ventana de tiempo V. La idea de la ventana aquí es nuevamente identificar con rapidez cambios en los intereses del usuario, como sucede con los lugares que frecuenta; se aplica en definitiva el mismo algoritmo de ventana deslizante.
Para fines de autenticación del usuario, se realiza mediante el servidor LDAP [15] de la Universidad de Los Andes. Este servicio se consume a través de SIEGE, que posee actualmente un módulo de autenticación contra el servidor LDAP. En el caso específico de los visitantes, no se requiere autenticación, pero igualmente se proveen todos los servicios de la aplicación para estos. Se asume que como la información de lugares frecuentados e intereses se mantiene localmente en el dispositivo, y el dispositivo en general es de uso personal, la información recolectada corresponde siempre al mismo visitante, así que no se requiere identificación adicional para proveer los datos que corresponden a cada visitante.
La arquitectura a nivel general de la solución consta entonces de una aplicación móvil tipo
pervasive – conoce el contexto del usuario y su entorno, además de ser capaz de interactuar con este de forma automática, ocultando la complejidad computacional al usuario – que es capaz de identificar la ubicación actual y los lugares frecuentados por el usuario en el campus, además de sus principales intereses, para traer información de relevancia para el usuario en el momento en que ingresa a un lugar o de forma anticipada. La relevancia de la información está dada por los intereses del usuario, de forma que datos importantes para el usuario son aquellos eventos que tratan temas de su interés.
13
Al localizar al usuario en un lugar en el campus, o detectar un lugar frecuentado, la aplicación debe consultar los eventos de interés para el usuario que ocurren en ese lugar y notificar al usuario. Una notificación consiste en mostrar en el dispositivo del usuario que hay eventos disponibles que le pueden interesar en el lugar en que se encuentra, o en el lugar en que se espera que se encuentre en el futuro. La notificación se produce entonces cuando: Se detecta que el usuario ha llegado a un nuevo lugar, es decir, se detecta un cambio en la localización ya que el lugar detectado es diferente al último lugar que se había registrado; o cuando se identifica un nuevo lugar frecuentado, donde se espera que el usuario esté dentro de un determinado tiempo. Cuando alguna de estas situaciones se da, la aplicación realiza una consulta de los eventos que se llevan a cabo en el lugar determinado y se le informa al usuario de estos, mediante una notificación a su dispositivo.
Con este mecanismo se logra entonces proveer al usuario un medio eficaz para obtener los eventos de su interés en la universidad, sin necesidad de tener una interacción directa con este, sino a partir de la información dada por sensores como GPS y beacons por Bluetooth que permiten construir un modelo del contexto del usuario y con esto realizar la operación de búsqueda de eventos. Además, el hecho de identificar automáticamente los lugares que frecuenta el usuario y sus intereses permite que la información proveída sea realmente importante para este, dándole valor agregado a la solución proveída.
A continuación se presenta la arquitectura global de la solución:
14
La figura 3 muestra la arquitectura global de la solución, donde se pueden apreciar los principales componentes del proyecto. Se pueden ver igualmente los componentes que conforman la aplicación móvil, todos estos ligados a un componente principal que utiliza los servicios proveídos por los demás para mostrar las notificaciones con la información relevante al usuario.
3.2 Casos de uso
A continuación se presenta el diagrama de casos de uso del sistema desarrollado:
Ilustración 4. Casos de uso
La anterior imagen muestra los posibles casos de uso del sistema propuesto. Estos son en general:
- Autenticación con LDAP: Los estudiantes, profesores y trabajadores de la Universidad se autentican contra el servidor LDAP de la Universidad para utilizar los servicios proveídos por el Sistema.
- Determinar localización en el campus: La aplicación detecta de forma automática la ubicación del usuario en el campus, para poder realizar la posterior consulta de eventos.
15
- Determinar ubicación futura: La aplicación determina la posible próxima ubicación del usuario a partir de la información recolectada de las localizaciones del usuario en el campus a lo largo del tiempo, y utilizando la ventana de tiempo definida para la búsqueda.
- Determinar principales intereses: La aplicación puede encontrar los principales intereses del usuario a partir de los eventos que ha visto.
- Consulta de eventos: La aplicación consulta eventos que ocurren en el campus a través de los servicios expuestos por SIEGE. Estos eventos son consultados a partir de la ubicación actual del usuario, de la posible ubicación futura del usuario y por gustos del usuario. Los eventos se muestran al usuario en su dispositivo.
3.3 Árbol de utilidad
Se presenta a continuación el árbol de utilidad definido para el proyecto:
Atributo de Calidad: Desempeño
Latencia ID Descripción Prioridad Consultas de
eventos al servidor SIEGE
Lat1 Las consultas por eventos al servidor SIEGE no deben tomar más de 7 segundos en resolverse y mostrarse al usuario.
Alta
Consumo de energía
ID Descripción Prioridad
Ahorro de batería Bat1 La duración de la batería del dispositivo con la aplicación corriendo debe ser casi igual a la duración de la batería del dispositivo sin la aplicación ejecutándose, con máximo una diferencia de 3 horas entre estos tiempos de duración de la batería.
Alta
Atributo de Calidad: Precisión Localización por
sensores
ID Descripción Prioridad
Ubicación del usuario por sensores
Ubi1 El desfase máximo permitido entre la ubicación detectada y la actual por beacons debe ser de 5 metros, mientras para GPS debe ser de 15 metros
Alta
Identificación de patrones y perfil
ID Descripción Prioridad
Búsqueda de lugares frecuentados y
Patr1 El 100% de las veces la aplicación debe
identificar correctamente un lugar frecuentado y los intereses principales del usuario, cuando
16
gustos se tengan datos sobre los cuales realizar análisis
Geolocalización ID Descripción Prioridad Ubicación del
usuario en el campus
Geoloc1 Por lo menos el 90% de las ubicaciones del usuario en el campus proveídas por el componente de geolocalización corresponden efectivamente con la realidad.
Alta
Atributo de Calidad: Disponibilidad
Datos ID Descripción Prioridad Datos de lugares e
intereses
Disp1 El 100% del tiempo la aplicación debe contar con la información de sus bases de datos internas correspondientes a lugares e interés, para poder realizar análisis sobre estos datos.
Alta
3.4 Plan de pruebas
En esta sección se presenta un resumen del plan de pruebas a llevar a cabo con el fin de verificar el cumplimiento de los atributos de calidad y los diversos parámetros utilizados para la implementación de la solución.
Prueba Descripción
Autenticación por LDAP Es posible autenticar un usuario a través del sistema LDAP de la Universidad. Este servicio se provee a través del servidor SIEGE.
Comunicación con beacons La aplicación puede identificar beacons cercanos y obtener su major y minor, cumpliendo con la medida de precisión definida
Obtención de coordenadas por GPS La aplicación puede determinar la latitud y longitud de la posición actual del usuario por GPS, cumpliendo con la medida de precisión definida Geolocalización del usuario La aplicación puede determinar la ubicación actual
del usuario en el campus, a partir de los datos obtenidos por GPS o beacons y la correspondiente consulta al servidor de mapas, cumpliendo con el objetivo de precisión definido
Obtención de eventos a partir de la ubicación actual del usuario.
La aplicación obtiene los eventos del lugar en el que se encuentra el usuario en el momento del servidor SIEGE, y los muestra al usuario, dentro del tiempo máximo establecido
Obtención de lugar frecuentado La aplicación es capaz de obtener un lugar frecuentado, el 100% de las veces, a partir de la base de datos de lugares visitados por el usuario y la aplicación del algoritmo de ventana deslizante sobre este.
Almacenamiento de lugar frecuentado La aplicación almacena correctamente una entrada en la base de datos de lugares frecuentados el 100% de las veces
17
Obtención de eventos a partir de ubicación futura del usuario
La aplicación obtiene los eventos del lugar en que el usuario se encontrará en el futuro, a través de consulta al servidor SIEGE, y los muestra al usuario, dentro del tiempo máximo establecido Verificación parámetro estadía mínima para considerar
lugar frecuentado
Se prueban varios valores para el tiempo de estadía mínima del usuario en un sitio para considerar un lugar frecuentado, con el fin de determinar el mejor valor para este parámetro Verificación parámetro tiempo entre corridas de
algoritmo lugar frecuentado
Se prueban varios valores para el tiempo entre corridas del algoritmo de búsqueda de lugar frecuentado, para determinar el mejor valor para éste parámetro.
Obtención de principales intereses del usuario La aplicación obtiene correctamente, el 100% de las veces, los principales intereses del usuario a partir del análisis de la base de datos de intereses Almacenamiento de intereses La aplicación obtiene correctamente, el 100% de
las veces, los temas relacionados a un evento revisado por el usuario y los almacena en la base de datos de intereses
Consumo de energía La aplicación no aumenta considerablemente el consumo de energía del dispositivo; la duración promedio no debe disminuir más de tres horas con la aplicación en ejecución.
18
4 Diseño detallado de la solución
En esta sección se muestra en detalle el diseño de la solución propuesta, en especial el diseño de la aplicación móvil, que es el componente principal desarrollado.
4.1 Diagrama de componentes detallado
A continuación se presenta el diagrama de componentes detallado de la solución
Ilustración 5. Diagrama de componentes detallado
La figura 5 muestra en detalle todos los componentes que conforman la solución propuesta. En general, hay tres grandes componentes: La aplicación móvil, el servidor de mapas y el servidor SIEGE. La aplicación móvil está igualmente conformada por componentes, cada uno encargado de una tarea específica. Cada componente se explica en detalle en los numerales siguientes. Los servicios ofrecidos por cada componente son consumidos por otros con el fin de cumplir el objetivo final de la solución, que es proveer la información relevante del campus al usuario.
19
4.2 Diagramas de secuencia
En este numeral se presentan los diagramas de secuencia que muestran la comunicación que se da entre componentes para mostrar la información al usuario. Se presentan cada uno de los posibles casos que la aplicación maneja de muestra de eventos al usuario, como mostrar eventos a partir del lugar actual del usuario o eventos a partir de un lugar frecuentado identificado.
El diagrama que se muestra a continuación muestra la comunicación de componentes para mostrar eventos al usuario del lugar en que se encuentra en el momento:
Ilustración 6. Diagrama de secuencia - Eventos de la ubicación actual
La ilustración 6 presenta en detalle la comunicación entre los componentes que se da para lograr mostrar al usuario los eventos del lugar en que se encuentra actualmente. El proceso inicia con la identificación de un nuevo beacon o coordenadas de GPS, a partir de las cuales se obtiene la ubicación del usuario en el campus, con una consulta al servidor de mapas. Ya con la geolocalización realizada, y al detectar que efectivamente el usuario se encuentra en un lugar diferente al último del que se tenía referencia, se procede a realizar la petición de eventos a SIEGE. Finalmente, se muestra una notificación al usuario con los eventos disponibles en el lugar en que se encuentra.
Otro caso posible es mostrar eventos al usuario a partir de un lugar frecuentado que identifica la aplicación. Primero se presenta el diagrama de secuencia que muestra cómo se almacena un posible lugar frecuentado, y luego se muestra el diagrama que presenta el flujo de información desde el componente que identifica un lugar frecuentado y a partir de este se realiza una petición por eventos que ocurren en el lugar frecuentado identificado para mostrar al usuario.
20
Ilustración 7. Diagrama de secuencia - Almacenamiento posible lugar frecuentado
La ilustración 7 presenta el proceso que se sigue para el almacenamiento de un posible lugar frecuentado. Lo primero que ocurre es la identificación de la ubicación del usuario en un momento t0 a partir de beacons o GPS, y la posterior geolocalización a través del
servidor de mapas. Esta información se guarda en el componente de EstadiaLugar, junto con la hora de entrada a ese sitio. Cuando se detecta que el tiempo de permanencia en ese lugar ha sido mayor o igual a X minutos, se envían los datos del lugar con hora de entrada y salida al componente de lugares frecuentados, para que se almacene como un posible lugar frecuentado.
21
Ilustración 8. Diagrama de secuencia - Eventos a partir de lugar frecuentado
La figura 8 muestra el diagrama de secuencia de obtención de eventos a partir de un lugar frecuentado identificado. La secuencia inicia cuando el componente de lugares frecuentados identifica un nuevo lugar frecuentado y lo informa al componente que realiza peticiones de eventos a SIEGE; el lugar frecuentado se identifica por el componente aplicando el algoritmo de ventana deslizante y cálculos de soporte, el cual corre cada X
minutos. Al recibir el lugar frecuentado el componente de peticiones al servidor, consulta los eventos de ese lugar, que se informan al componente principal para que notifique al usuario de los eventos disponibles en el lugar en que se espera que esté el usuario en el futuro.
4.3 Aplicación móvil
La aplicación móvil es el componente principal del presente proyecto. Este componente está desarrollado en base al API 19 Android o superior, por requerimientos de Bluetooth LE 4.0. A continuación se presentan los componentes principales desarrollados en la aplicación
22
4.3.1 Componentes de geolocalización
En este numeral se muestran la estructura de los componentes encargados de la geolocalización del usuario en el campus, que en general son RangingService, GPSLocation y LocationFinder.
Ilustración 9. Componentes geolocalización
La ilustración 9 presenta los diagramas de clases correspondientes a los componentes que permiten realizar la geolocalización del usuario. Estos componentes están encargados de:
23
- RangingService: Service encargado de la detección de los beacons para localizar al usuario. Al detectar un nuevo beacon, envía un broadcast con el major y minor del
beacon más cercano detectado.
- GPSLocation: Service encargado de la detección de las coordenadas de la posición actual del usuario. Al detectar un cambio en la posición del usuario, informa mediante un broadcast las nuevas coordenadas encontradas.
- LocationFinder: Service encargado de comunicarse con el servidor de mapas para geolocalizar al usuario partir de los datos de un beacon detectado o coordenadas GPS. Tiene un BroadcastReceiver que escucha por los datos detectados por GPSLocation o RangingService, para consultar en qué lugar se encuentra el usuario a partir de la información del broadcast recibido. Las consultas las realiza a través de AsyncTask, que permiten correr estas tareas fuera del hilo de ejecución principal.
4.3.2 Componentes EstadiaLugar y Lugares Frecuentados
A continuación se presentan los diagramas de clase correspondientes a los componentes de EstadiaLugar y LugaresFrecuentados presentes en la aplicación.
Ilustración 10. Diagrama de clases - componentes EstadiaLugar y LugaresFrecuentados
La figura 10 presenta las clases utilizadas en el desarrollo de los componentes EstadiaLugar y LugaresFrecuentados. Estos componentes consisten de:
- EstadiaLugar: Este componente lleva la última estadía conocida del usuario. Es un Service que cuenta con un BroadcastReceiver para recibir los mensajes enviados
24
por LocationFinder, los cuales le permiten determinar una nueva ubicación o si el usuario continúa en el mismo lugar. Al detectar un cambio en la ubicación del usuario, actualiza la última localización conocida e informa mediante un broadcast la nueva localización. En caso de que al detectarse el cambio en ubicación del usuario, es decir, que la nueva ubicación recibida por LocationFinder sea diferente a la que se tenía almacenada como última ubicación conocida del usuario, hayan transcurrido más de X minutos, se informa igualmente por broadcast de un posible lugar frecuentado.
- Lugares frecuentados: Service encargado de realizar el análisis de la base de datos de posibles lugares frecuentados para detectar efectivamente un lugar frecuentado. Cada X minutos corre este algoritmo de detección de lugares frecuentados para encontrar el lugar en que el usuario posiblemente se encuentre dentro de un cierto tiempo. Cuenta con un BroadcastReceiver para escuchar por broadcast provenientes de EstadiaLugar que informen de posibles nuevos lugares frecuentados para almacenar su información en la base de datos. Posee la clase LugaresSQLManager, que se utiliza para acceder a la base de datos. Igualmente, esa clase es la encargada de la creación de las tablas utilizadas para el almacenamiento de los posibles lugares frecuentados.
La base de datos de posibles lugares frecuentados consta de 7 tablas, una correspondiente a cada día de la semana. Cada una de estas tablas lleva los posibles lugares, con hora de entrada, salida y número de la semana del año en que el usuario visitó ese lugar, para el día de la semana que le corresponde a cada tabla. Por ejemplo, en la tabla MONDAY se llevan todos los posibles lugares frecuentados para los días lunes, y en la tabla FRIDAY se llevan todos los posibles lugares frecuentados para los días viernes. La estructura de las tablas se presenta a continuación:
Ilustración 11. Estructura tablas Base de datos Lugares Frecuentados
Lugar Hora Entrada Hora Salida Semana del año
25
4.3.3 Componente consulta de eventos
En esta sección se presenta el diagrama de clases utilizado para la consulta de eventos al servidor SIEGE.
Ilustración 12. Diagrama de clases componente consulta eventos
Como se puede observar en la figura 12, este componente está conformado de un Service encargado de la comunicación con el servidor SIEGE para consultar eventos. Cuenta con un BroadcastReceiver para recibir la localización actual o ubicación predicha del usuario por LugaresFrecuentados, a partir de la cual se realiza la petición por los eventos. Al recibir un mensaje de broadcast a través del BroadcastReceiver, construye la URL de la cual se pueden obtener los eventos y envía estos datos en un broadcast.
26
4.3.4 Componente de intereses del usuario y Principal
En este numeral se presentan los diagramas de clase de los componentes Principal y de identificación de intereses del usuario.
Ilustración 13. Diagrama de clases - Intereses y Principal
Las clases mostradas en la figura 13 tienen como función:
- Intereses: Es la clase encargada de realizar el análisis sobre la base de datos de intereses para obtener las palabras clave de los temas que más interesan al usuario. Igualmente es el punto de entrada a la base de datos de intereses, para agregar nuevas entradas a esta.
- Principal: Cuenta con un BroadcastReceiver para recibir notificaciones de nuevos eventos encontrados en la localización actual o ubicación predicha del usuario por los demás servicios de la aplicación. Al recibir estos datos crea una notificación para el usuario con el lugar en que se encuentra o posiblemente se encontrará informando que hay eventos disponibles allí, que al ser abierta por el usuario entregara los datos para mostrar los eventos al usuario. Corre como un Service.
En este caso, el componente de Intereses está integrado directamente como un atributo del componente Principal, ya que no hay necesidad de exponer los servicios de Intereses para otras aplicaciones.
27
4.3.5 Activities de la aplicación
La aplicación cuenta igualmente con las siguientes Activities:
Ilustración 14. Diagrama de clases - MainActivity y RegistroActivity
- MainActivity: Actividad principal de la aplicación. Contiene un ListView donde se despliegan los eventos encontrados al usuario. Es el encargado de iniciar los servicios de la aplicación una vez el usuario se ha autenticado correctamente. - RegistroActivity: Actividad que permite autenticar al usuario contra el servidor
LDAP, a través de los servicios ofrecidos por SIEGE. La autenticación la realiza a través de un AsyncTask, para separar la tarea de red del thread principal de la aplicación. Al realizar la operación de autenticación retorna si el usuario se ha autenticado exitosamente o si no fue posible autenticarlo. Igualmente cuenta con un AsyncTask para obtener el nombre completo del usuario y otros datos relacionados a este, si se desea, del servidor LDAP.
28
4.3.6 Filtros de Broadcast para consumir los servicios expuestos
Las aplicaciones que deseen consumir los servicios proveídos deben implementar BroadcastReceiver, que usen como IntentFilter el filtro asociado al servicio que deseen consumir. Los filtros implementados son los siguientes:
- com.example.uniandesac.BEACON_READ: Permite escuchar por broadcast realizados por el RangingService cuando detecta un nuevo beacon.
- com.example.uniandesac.GPS_READ: Permite escuchar por broadcast realizados por GPSLocation al detectar unas nuevas coordenadas, tras haber un cambio de posición significativo.
- com.example.uniandesac.RECEIVE_ESTADIA: Permite escuchar por broadcast realizados por LocationFinder al encontrar una nueva localización.
- com.example.uniandesac.SAVE_LOC: Permite escuchar por broadcast realizados por EstadiaLugar, que incluyen datos sobre una ubicación donde el usuario permaneció durante más de 20 minutos.
- com.example.uniandesac.NUEVO_ACTUAL: Permite escuchar broadcast realizados por EstadiaLugar, informando una nueva ubicación del usuario.
- com.example.uniandesac.LUGAR_FRECUENTADO: Permite escuchar por broadcast realizados por LugaresFrecuentados, que informan de un lugar frecuentado encontrado.
- com.example.uniandesac.NEW_EVENTS_NOW: Permite escuchar por broadcast realizados por EventQueryManager, que informan de nuevos eventos en la ubicación actual del usuario.
- com.example.uniandesac.NEW_EVENTS_FUTURE: Permite escuchar por broadcast realizados por EventQueryManager, que informan de nuevos eventos en un lugar frecuentado encontrado por la aplicación.
29
4.4 Servidor SIEGE
La estructura del servidor SIEGE se mantiene como estaba planteada en [5], a excepción de un componente más que permite el ingreso automático de nuevos eventos a partir del feed de eventos de la Universidad. Igualmente se incluye comunicación con los servicios externos de OpenCalais para enriquecer los eventos conociendo de qué temas hablan. A continuación se muestra la estructura de SIEGE:
Ilustración 15. Estructura servidor SIEGE [5]
El parser de eventos es el componente encargado de traducir los eventos del feed y pasarlos a RDF. Igualmente, la comunicación con OpenCalais se realiza al momento de agregar nuevas entradas al servidor, para que los eventos queden de una vez asociados a sus temas correspondientes.
En cuanto a los componentes del servidor, el QueryEngine es el punto de entrada al servidor y el encargado de iniciar las consultas para responder al usuario. Para cumplir este requerimiento usa los servicios de Geolocation Engine e Information Management, que permiten realizar la búsqueda de eventos para una localización específica.
30
5 Implementación y pruebas
En esta sección se presentan los resultados de la implementación del proyecto. Primero se muestran las plataformas, tanto de software como de hardware, utilizadas en la implementación del proyecto. Posteriormente se presentan los retos encontrados durante el desarrollo de cada componente y finalmente se muestran las pruebas realizadas y los resultados obtenidos de estas, como forma de validación de la solución implementada.
5.1 Plataforma de desarrollo
La aplicación móvil se desarrolló utilizando el API 18 de Android, correspondiente a la versión Android 4.3. El ambiente de desarrollo utilizado para esta implementación es Eclipse, que cuenta con Android SDK.
Los componentes del servidor SIEGE se encuentran todos desarrollados en PHP5. Para el despliegue de este servidor se utilizó como servidor web Apache2 sobre una máquina Linux con Ubuntu 12.04.4 LTS. En esta misma plataforma se encuentra la ontología con los datos de eventos, sobre un servidor Tomcat 7 y OWLIM-Lite 4.3, el cual corre como plugin a OpenRDF Sesame 2.7.11.
Las pruebas de la aplicación se realizaron en diversos dispositivos, entre los cuales se encuentran un LG Optimus-L3 con Android 4.1.2, un Samsung Galaxy S4 con Android 4.4 y un Motorola Moto G2 con Android 4.4.4.
5.2 Retos en implementación
Los componentes se implementaron tal cual se encuentran planteados en el diseño. Los principales retos encontrados durante el proceso de implementación fueron los siguientes:
- La necesidad de implementar los componentes como Service y a la vez necesitar escuchar broadcast como BroadcastReceiver, cuando no es posible extender de múltiples clases en Android. Se debió entonces plantear el diseño y la implementación con Services que poseen una clase interna privada que extienda de BroadcastReceiver, y registrar este receiver dinámicamente al iniciarse el Service. - El uso de múltiples Service requirió la creación de un proceso propio para cada uno,
con el fin de evitar que se pudiesen bloquear algunos al intentar correr todos bajo el mismo proceso de la aplicación.
- La implementación del detector de beacons con la librería iBeacon Android mostró ser bastante retador. Para lograr el funcionamiento adecuado fue necesario revisar con detalle el funcionamiento de la librería desde su código. Por fortuna se contó con la colaboración del desarrollador de esta librería, el señor David G. Young, quién aportó con sus conocimientos de la librería para lograr el funcionamiento correcto del componente de detección.
31
- Permitir que los servicios de la aplicación estuviesen disponibles para otras aplicaciones representó en su momento un gran reto, ya que se debió replantear el diseño y arquitectura de la aplicación, hasta llegar al diseño ya presentado en este documento. La estructura de componentes encargados de tareas específicas y que informan de los resultados obtenidos a través de broadcast resultó ser la estrategia adecuada para permitir el consumo de los servicios de la aplicación a otras aplicaciones en el dispositivo.
- Encontrar el valor correcto para los parámetros requeridos para la identificación de lugares frecuentados mostró ser un gran reto. Luego de probar con distintos valores, se determinó que el valor adecuado para el tiempo de permanencia del usuario en un lugar para considerarlo como posible frecuentado es de 20 minutos. Igualmente, el valor determinado como intervalo de tiempo entre corridas del algoritmo de identificación de lugares frecuentados es de 20 minutos. En los resultados de pruebas se muestra cómo se llegó a estos valores.
- Los componentes para geolocalización resultaron de gran complejidad. La realización de estos no hubiese sido posible sin el aporte de Juan Camilo Ortiz, Laura Díaz y Natalia Rojas, quienes trabajaron conjuntamente con este proyecto para lograr el desarrollo de estos componentes.
- El desarrollo del parser para obtener los eventos del feed de la universidad representó un reto enorme por la falta de estructura de este. Fue necesaria la utilización de técnicas de expresiones regulares para obtener la información de los eventos. Aún así, se espera que para posteriores trabajos se pueda contar con una estructura definida para este feed, ya que actualmente cada entidad que organiza los eventos define la estructura de su publicación, dificultando la extracción de la información. Esta parte del proyecto contó con un gran aporte de Juan Camilo Ortiz, con quien se logró implementar exitosamente el parser.
5.3 Resultados de pruebas
Prueba 1 Autenticación por LDAP
Tipo prueba Funcional
Escenario
Servidor SIEGE está disponible y la aplicación corriendo en el dispositivo del usuario
Descripción
Es posible autenticar un usuario a través del sistema LDAP de la Universidad el 100% de las veces, mientras se cuente con conexión a Internet. Este servicio se provee a través del servidor SIEGE.
Resultados esperados Autenticación exitosa del usuario e inicio de
32
Resultados obtenidos
El usuario se autentica exitosamente el 100% de las veces a través del servidor LDAP, y por consiguiente inician correctamente todos los servicios de la aplicación
Prueba 2 Comunicación con beacons
Tipo prueba Funcional/Precisión
Escenario
Los servicios de la aplicación han sido iniciados correctamente; el dispositivo del usuario cuenta con Bluetooth LE.
Descripción
La aplicación logra identificar exitosamente los beacons cercanos con una precisión de máximo 5 metros de desfase, y obtiene correctamente los datos del beacon
Resultados esperados
La aplicación identifica exitosamente los beacons cercanos, obteniendo sus datos y con una precisión de máximo 5 metros de desfase.
Resultados obtenidos
Se logró la identificación exitosa de los beacons cercanos y obtención correcta de los datos correspondientes a este (Major, minor). Igualmente, el desfase entre la distancia detectada y la actual del beacon no fue mayor a 5 metros, de forma que se cumple con la precisión deseada.
Observaciones
La detección de beacons fue posible solamente en algunos dispositivos. A pesar de realizarse pruebas siempre en dispositivos que contaran con Bluetooth LE y Android 4.3 o superior, no todos eran capaces de detectar los beacons, a pesar de tener el servicio de detección de la aplicación en ejecución correcta. En especial, se lograron pruebas exitosas en un Motorola Moto G2, más en dispositivos Samsung se detectaron en algunas ocasiones solamente.
Prueba 3 Obtención de coordenadas por GPS
Tipo prueba Funcional/Precisión
Escenario
Los servicios de la aplicación han sido iniciados correctamente; el dispositivo cuenta con GPS activo
33
Descripción
La aplicación obtiene exitosamente las coordenadas de la posición actual del usuario, con un desfase no mayor a 15 metros.
Resultados esperados
Obtención exitosa de las coordenadas del usuario, y con desfase dentro del rango permitido.
Resultados obtenidos
La aplicación logra obtener las coordenadas de la posición actual del usuario, y en todos los casos cumpliendo con la restricción de precisión de 15 metros de desfase máximo.
Observaciones
Establecer las coordenadas de la ubicación del usuario la primera vez puede tomar algo de tiempo (no mayor a un par de minutos), dependiendo del lugar donde se encuentre. Esto se da por la forma en que funciona el GPS; una forma de lograr que el GPS del dispositivo determine rápidamente la ubicación en caso de que tarde demasiado es desplazarse unos cuantos metros, buscando un lugar que no se encuentre muy cubierto para facilitar el proceso.
Prueba 4 Identificación de la ubicación actual del
usuario
Tipo prueba Funcional/Precisión
Escenario
Servidor de mapas está disponible y los servicios de la aplicación corriendo en el dispositivo.
Descripción
La aplicación obtiene exitosamente la ubicación del usuario el 90% de las veces. Esta medida se obtiene a partir de una pregunta al usuario al ser notificado de una nueva ubicación. Las respuestas del usuario se almacenan en un log, del cual es posible medir el porcentaje de ubicaciones acertadas.
Resultados esperados
El 90% o más de los lugares detectados automáticamente por la aplicación corresponden efectivamente a la ubicación actual del usuario. Esta medida se obtiene a partir de preguntas realizadas al usuario al momento de detectar su ubicación y de la revisión del log con los resultados de estas preguntas.
