Smartsniff

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA DEL SOFTWARE SMARTSNIFF Realizado por DANIEL ALEJANDRO CASTRO GARCÍA Tutorizado por ENRIQUE ALBA TORRES JAMAL TOUTOUH EL ALAMIN Departamento LENGUAJE Y CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, Noviembre de 2016 Fecha defensa: El Secretario del Tribunal Resumen: En la actualidad, nuestro entorno se ve inundado de dispositivos con interfaces de red inalámbrica. Este proyecto consiste en el desarrollo de un sistema capaz de detectar, almacenar y procesar información procedente de los dispositivos wifi y Bluetooth empleando un dispositivo móvil Android. El sistema consta de dos partes, una aplicación móvil que detectará las distintas redes inalámbricas que se encuentren a su alcance para posteriormente almacenar información sobre dichas redes, además de detectar también dispositivos Bluetooth, y una aplicación web que almacenará toda la información procedente de la aplicación móvil para posteriormente emplearla en la creación de mapas y estadísticas. El grueso del trabajo se concentra en la aplicación móvil, capaz de detectar ambos tipos de dispositivos de forma simultánea, además de la ubicación donde fueron encontrados. Los datos son almacenados de forma local en el propio dispositivo móvil hasta que el usuario los envía al servidor web, momento en el que se elaboran estadísticas que el usuario podrá consultar en la aplicación web. Palabras claves: wifi, bluetooth, estadísticas, mapas, detección, aplicación móvil, aplicación web Abstract: Nowadays, our environment is flooded with wireless-ready devices. This project consists in the development of a system capable of detecting, storing and processing information from wifi and Bluetooth devices using an Android mobile device. The project consists of two parts, an Android mobile application which will detect the different wireless networks within reach of the device, and a web application which stores all the information sent by the mobile application to further create maps and statistics with it. The bulk of the work is concentrated in the mobile application, which is capable of detecting both types of devices at the same time, in addition to the position where they were detected. The data is stored locally in the device until the user sends them to the server, at which point statistics and maps will be elaborated. The user will be able to see these statistics by accessing the web application. Keywords: wifi, Bluetooth, statistics, maps, detection, mobile application, web application Índice CAPÍTULO 1. INTRODUCCIÓN ...................................................................... 1 1.1. MOTIVACIÓN ............................................................................................. 1 1.2. OBJETIVOS ............................................................................................... 1 1.3. ESTRUCTURA DE LA MEMORIA ..................................................................... 2 CAPÍTULO 2. TECNOLOGÍAS ....................................................................... 3 2.1. REPOSITORIO DE CÓDIGO FUENTE ............................................................... 3 2.2. APLICACIÓN MÓVIL ..................................................................................... 3 2.2.1. Base de datos ............................................................................... 3 2.2.2. Bibliotecas de funciones específicas para Android ....................... 3 2.3. SERVIDOR WEB ......................................................................................... 4 2.3.1. Base de datos ............................................................................... 4 2.3.2. Servidor HTTP............................................................................... 5 2.4. APLICACIÓN WEB ....................................................................................... 5 2.5. ENTORNO DE DESARROLLO ........................................................................ 5 CAPÍTULO 3. ESPECIFICACIÓN Y ANÁLISIS .............................................. 7 3.1. REQUISITOS DE LA APLICACIÓN ANDROID ..................................................... 7 3.1.1. Actores .......................................................................................... 7 3.1.2. Requisitos funcionales .................................................................. 7 3.1.3. Requisitos no funcionales ............................................................. 8 3.2. CASOS DE USO DE LA APLICACIÓN ANDROID............................................... 10 3.3. ANÁLISIS DE LAS BASES DE DATOS ............................................................ 14 3.3.1. Aplicación Android ....................................................................... 14 3.3.2. Servidor ....................................................................................... 14 3.4. ANÁLISIS DE LA INTERFAZ DE USUARIO ....................................................... 14 CAPÍTULO 4. DISEÑO .................................................................................. 17 4.1. DIAGRAMA DE DISTRIBUCIÓN .................................................................... 17 4.2. MODELO RELACIONAL DE LAS BASES DE DATOS .......................................... 18 4.2.1. Local ............................................................................................ 18 4.2.2. Remota ........................................................................................ 20 4.3. DIAGRAMA DE CLASES ............................................................................. 20 CAPÍTULO 5. IMPLEMENTACIÓN Y PRUEBAS ......................................... 23 5.1. ESTRUCTURA DEL PROYECTO ANDROID ..................................................... 23 5.2. ESTRUCTURA DEL PROYECTO WEB ............................................................ 25 5.3. DESARROLLO DEL PROYECTO ................................................................... 26 5.3.1. Branded Splash Screen .............................................................. 27 5.3.2. Escanear dispositivos .................................................................. 28 5.3.3. Detener escaneo ......................................................................... 33 5.3.4. Enviar datos ................................................................................ 36 5.3.5. Borrar datos ................................................................................ 36 5.3.6. Configuración .............................................................................. 37 5.3.7. Aplicación web – Mapa de calor .................................................. 38 5.3.8. Aplicación web – Estadísticas ..................................................... 39 5.4. PRUEBAS ................................................................................................ 42 CAPÍTULO 6. CONCLUSIONES Y TRABAJO FUTURO ............................. 47 6.1. CONCLUSIONES ....................................................................................... 47 6.2. LÍNEAS FUTURAS ..................................................................................... 48 REFERENCIAS ............................................................................................. 49 APÉNDICES……. .......................................................................................... 50 A. MANUAL DE USUARIO ............................................................................... 50 B. MANUAL DE INSTALACIÓN DE LA APLICACIÓN WEB ....................................... 54 C. GLOSARIO .............................................................................................. 61 1 Capítulo 1: Introducción Capítulo 1. Introducción 1.1. Motivación A lo largo de los últimos años, los dispositivos inalámbricos han disfrutado de una época de auge y expansión más que notable. Los puntos de acceso wifi pueden encontrarse en cualquier lugar, desde domicilios y establecimientos privados hasta parques, calles y plazas. Asimismo, la tecnología Bluetooth se puede encontrar en prácticamente cualquier dispositivo móvil, desde teléfonos móviles hasta televisores, pasando por pulseras cuantificadoras, relojes inteligentes y coches. Estas dos tecnologías conforman uno de los pilares fundamentales que posibilitan la existencia de las Ciudades Inteligentes (Smart Cities) [1]: la interconexión de dispositivos. Mediante la difusión de ambas tecnologías en el ámbito urbano, se impulsa la creación de un ecosistema digital de dispositivos interconectados. Y a pesar de que actualmente tan solo el uno por ciento de los dispositivos electrónicos está conectado a Internet [2], el aumento de esta cantidad es imparable. La situación descrita genera grandes oportunidades en el desarrollo de aplicaciones móviles que se aprovechen de estas tecnologías. En el presente documento se explora una de ellas: se propone el desarrollo de un sistema capaz de capturar datos relevantes sobre las redes y dispositivos inalámbricos para la elaboración de mapas que muestren las redes inalámbricas desplegadas por toda un área determinada, además de diversas estadísticas para obtener información útil sobre los dispositivos y las redes de comunicación desplegadas. 1.2. Objetivos El objetivo del presente Trabajo de Fin de Grado (TFG) es el desarrollo de una aplicación móvil que detecte redes inalámbricas (puntos de acceso) y dispositivos Bluetooth que estén en modo promiscuo. Una vez detectados, se almacenará información diversa sobre dichas redes o dispositivos, tales como el nombre y la zona geográfica donde fueron encontrados, además de diversos parámetros de configuración. Con los datos almacenados, se procederá a elaborar estadísticas y mapas, como por ejemplo el número de redes inalámbricas wifi en un área o una clasificación de los dispositivos por fabricante. 8 SmartSniff Identificador Descripción RF-1 El usuario podrá iniciar un escaneo para detectar puntos de acceso wifi y dispositivos Bluetooth al alcance del dispositivo móvil. RF-2 El usuario podrá detener un escaneo en progreso. RF-3 La aplicación mostrará los resultados de un escaneo que haya finalizado. RF-4 La aplicación almacenará de forma local los resultados de los escaneos. RF-5 El usuario podrá eliminar en cualquier momento los datos almacenados de forma local. RF-6 El usuario podrá enviar toda la información obtenida de los escaneos a un sistema de almacenamiento remoto. RF-7 La aplicación mostrará un mapa de calor, que permitirá al usuario visualizar de forma gráfica los datos recogidos. RF-8 El usuario podrá configurar determinados parámetros de la aplicación. Tabla 3 – Requisitos funcionales de la aplicación Android 3.1.3. Requisitos no funcionales Los requisitos no funcionales determinan condiciones o restricciones sobre las que el sistema funciona o es desarrollado. Se presentan en la Tabla 4 clasificados en función de la categoría correspondiente según el estándar IEEE-Std 830-1993. 9 Capítulo 3: Especificación y análisis Identificador Categoría Descripción RNF-1 Rendimiento La aplicación debe procesar un escaneo de dispositivos wifi y Bluetooth con un impacto mínimo en el rendimiento. RNF-2 Fiabilidad La aplicación debe ser capaz de mantener un escaneo en proceso en segundo plano. RNF-3 Fiabilidad La aplicación debe ser capaz de mantener su funcionamiento ante posibles deshabilitaciones de las interfaces empleadas durante los escaneos (wifi, Bluetooth, GPS) del dispositivo móvil. RNF-4 Fiabilidad La aplicación deberá reaccionar ante posibles errores en la manipulación de la base de datos local de forma que no interrumpa su funcionamiento. RNF-5 Interoperabilidad La aplicación debe poder enviar los datos almacenados localmente al servidor mediante una API REST. RNF-6 Documentación La aplicación estará bien documentada en un manual de usuario. RNF-7 Mantenimiento Los fragmentos de código de la aplicación más críticos y/o empleados durante la ejecución deberán estar debidamente documentados. RNF-8 Almacenamiento Los datos obtenidos por la aplicación deberán ser almacenados en una base de datos local. RNF-9 Usabilidad La aplicación tendrá una interfaz que haga que su uso sea sencillo para cualquier usuario. RNF-10 Interfaz La interfaz de la aplicación incluirá únicamente los elementos mínimos necesarios para ser empleada con efectividad. Tabla 4 – Requisitos no funcionales de la aplicación Android 10 SmartSniff 3.2. Casos de uso de la aplicación Android La Figura 1 presenta todos los casos de uso necesarios para cubrir todos los requisitos funcionales de la aplicación. Figura 1 – Diagrama de casos de uso de la aplicación Android Las tablas 5, 6, 7, 8 y 9 contienen la especificación de los cinco casos de uso principales (aquellos conectados directamente con el Usuario del diagrama del apartado anterior): Iniciar escaneo, Detener escaneo, Enviar datos a servidor, Borrar datos locales y Configurar aplicación. 11 Capítulo 3: Especificación y análisis Nombre Iniciar escaneo Identificador UC-01 Requisitos funcionales asociados RF-1, RF-4, RF-7 Descripción Este caso de uso describe la funcionalidad que permite al usuario iniciar un escaneo en busca de dispositivos wifi y Bluetooth al alcance de su dispositivo móvil Precondiciones La aplicación está en standby (sin escaneo activo) Postcondiciones La aplicación está en modo escaneo Prioridad Alta Escenario principal 1. El usuario presiona el botón de iniciar escaneo 2. La aplicación pide permiso para activar las interfaces del dispositivo necesarias (GPS, Bluetooth) 3. La aplicación inicia los procesos de detección con las interfaces disponibles 4. A medida que la aplicación encuentra datos, los mostrará en el mapa de calor de la interfaz Escenario alternativo Ninguno Tabla 5 – Caso de uso 1: Iniciar escaneo Nombre Detener escaneo Identificador UC-02 Requisitos funcionales asociados RF-2, RF-3 Descripción Este caso de uso describe la funcionalidad que permite al usuario interrumpir un escaneo en progreso Precondiciones La aplicación está en modo escaneo Postcondiciones La aplicación está en standby (sin escaneo activo) Prioridad Alta Escenario principal 1. El usuario presiona el botón para cancelar el escaneo activo 2. La aplicación detiene los procesos de detección 3. La aplicación muestra una interfaz en la que se detallan los resultados del escaneo detenido 4. La aplicación actualiza el mapa de calor de la interfaz Escenario alternativo Ninguno Tabla 6 – Caso de uso 2: Detener escaneo 12 SmartSniff Nombre Borrar datos locales Identificador UC-03 Requisitos funcionales asociados RF-5 Descripción Este caso de uso describe la funcionalidad que permite al usuario eliminar de la base de datos local los resultados de los escaneos almacenados en ella Precondiciones La aplicación está en standby (sin escaneo activo) Postcondiciones Los datos de la base de datos local son eliminados Prioridad Media Escenario principal 1. El usuario presiona el botón de borrar datos 2. La aplicación pide una confirmación al usuario 3. El usuario acepta la confirmación 4. La aplicación elimina todos los datos almacenados en la base de datos local 5. La aplicación muestra una notificación al usuario para indicar que el borrado se ha realizado con éxito Escenarios alternativos El usuario deniega la confirmación pedida por la aplicación: 3.a – El usuario deniega la confirmación 4.a – La aplicación cancela el proceso de borrado No hay datos que borrar: 2.b - La aplicación muestra un mensaje, indicando al us uario que no hay datos almacenados. Tabla 7 – Caso de uso 3: Borrar datos locales 13 Capítulo 3: Especificación y análisis Nombre Enviar datos a servidor Identificador UC-04 Requisitos funcionales asociados RF-6 Descripción Este caso de uso describe la funcionalidad que permite al usuario enviar los resultados de los diversos escaneos realizados a un servidor para su almacenamiento Precondiciones La aplicación está en standby (sin escaneo activo) Postcondiciones Los datos disponibles se han enviado al servidor Prioridad Media Escenario principal 1. El usuario presiona el botón de envío de datos 2. La aplicación recolecta los datos almacenados de forma local y los envía al servidor Escenario alternativo No hay datos para enviar: 2.b - La aplicación muestra un mensaje, indicando al usuario que no hay datos que enviar. Tabla 8 – Caso de uso 4: Enviar datos a servidor Nombre Configurar aplicación Identificador UC-05 Requisitos funcionales asociados RF-8 Descripción Este caso de uso describe la funcionalidad que permite al usuario configurar la aplicación mediante un menú habilitado a tal efecto Precondiciones La aplicación está en standby (sin escaneo activo) Postcondiciones La aplicación queda configurada con los parámetros de configuración introducidos por el usuario Prioridad Alta Escenario principal 1. El usuario presiona el botón para abrir el menú de configuración 2. La aplicación muestra un menú de configuración 3. El usuario altera los parámetros que considere oportunos, y cierra el menú Escenario alternativo Ninguno Tabla 9 – Caso de uso 5: Configurar aplicación 14 SmartSniff 3.3. Análisis de las bases de datos A continuación se presentan las especificaciones de las bases de datos del proyecto. En la Sección 4.2 se presenta el modelo relacional con mayor cantidad de detalles. 3.3.1. Aplicación Android La base de datos Android contiene tres tipos de entidades: • Session: almacena información de las sesiones. Una sesión contiene la fecha de inicio de un escaneo y su fecha de finalización. • Device: contiene información sobre un dispositivo detectado, sea wifi o Bluetooth. Incluye, entre otros parámetros, el SSID, la dirección MAC y el fabricante del dispositivo, si es posible encontrarlo. • Location: almacena información sobre las localizaciones en las que se han encontrado uno o varios dispositivos. Se almacena la fecha a la que se registró la localización y las coordenadas de la misma. Además de estas tres entidades, hay una más, Association. Esta entidad guarda información de las asociaciones entre las tres entidades anteriores en la base de datos. 3.3.2. Servidor La base de datos del servidor es exactamente igual que la base de datos de la aplicación Android con la diferencia de que la entidad Session almacena, además de los datos anteriores, la dirección MAC del adaptador de red del dispositivo móvil que envía los datos. De esta manera, se facilitan las comprobaciones de unicidad de las sesiones en el servidor y se provee de una manera básica de identificación de las sesiones por usuario, preparando así el terreno para una posible implementación de estadísticas personales en la propia aplicación móvil. 3.4. Análisis de la interfaz de usuario La interfaz de usuario se ha desarrollado considerando en todo momento la facilidad de manejo de la aplicación. Es por ello que se ha diseñado y construido la interfaz minimizando el número de pulsaciones sobre la pantalla que el usuario debe realizar. 15 Capítulo 3: Especificación y análisis Se han considerado los siguientes puntos a la hora de diseñar la interfaz: • Minimalismo: minimización de los elementos presentes en la interfaz de usuario. • Navegación: en la aplicación móvil el usuario tiene a su disposición un menú en la parte superior derecha de la aplicación móvil que le permitirá acceder a las funciones de enviar y borrar datos, además de al menú de configuración. En la aplicación web, el menú se localiza también en la parte superior derecha, y permite al usuario acceder al mapa de calor de dispositivos detectados, a la página que contiene las estadísticas y a una página que introduce el sistema a los usuarios. • Aspecto visual: se ha procurado combinar el minimalismo de interfaz comentado anteriormente con un aspecto visual sencillo para el usuario en las dos aplicaciones del sistema. 16 SmartSniff 17 Capítulo 4: Diseño Capítulo 4. Diseño Este capítulo presenta los diagramas UML que han sido creados y usados de guía para el desarrollo del sistema. Se detalla además el modelo de base de datos elaborado para las dos bases de datos. 4.1. Diagrama de distribución La comunicación es unidireccional en el caso de la aplicación móvil y bidireccional en el caso de la aplicación web. El servidor web también se comunica de manera bidireccional con la base de datos del propio servidor. De igual manera, la aplicación Android se comunica bidireccionalmente con la base de datos interna del dispositivo. La Figura 2 ilustra estos conceptos. Figura 2 – Diagrama de distribución El usuario puede hacer uso del sistema de dos maneras bien diferenciadas: 1. Usando la aplicación móvil: el usuario realiza escaneos con la aplicación móvil para recabar información sobre los dispositivos inalámbricos de su entorno, que después enviará al servidor web mediante una petición HTTP de tipo POST que incluye un objeto JSON con la información de la base de datos local. 2. Usando la aplicación web: el usuario puede consultar en cualquier momento el mapa de calor de dispositivos encontrados y las estadísticas elaboradas a partir de los datos enviados por la aplicación móvil. Además, puede consultar una breve introducción al sistema. 24 SmartSniff o DeviceType: enumerado que contiene los valores que los objetos de tipo Device pueden almacenar en su atributo type: WIFI o BLUETOOTH. • Utils: paquete que contiene clases que realizan tareas de cómputo de forma transparente al usuario para el adecuado funcionamiento de la aplicación. o DatabaseHelper: clase que implementa la base de datos local en SQLite, además de los métodos pertinentes para añadir, obtener y eliminar datos de sus tablas. o GeolocationGPS: clase que, empleando el módulo Google Play Services API, realiza todas las tareas de geolocalización requeridas por la aplicación. o JSONGenerator: clase dedica a generar los objetos JSON que la aplicación usa para enviar toda la información contenida en su base de datos local. Para ello, se apoya de dos módulos: Gson y Volley. El primero se usa para serializar los objetos de las clases modelo en el JSON y el segundo se usa para crear el JSON y enviarlo en una petición HTTP de tipo POST. o Utils: clase genérica con métodos, constantes y atributos que no tenían lugar en una clase concreta de la aplicación y que, por lo general, son usados en varias partes del código. • En el paquete principal de la aplicación del proyecto nos encontramos con clases que contienen la lógica que opera por debajo de las vistas de la aplicación, es decir, las clases controladoras. o MainActivity: actividad principal de la aplicación. Es donde se desarrolla la actividad de escaneo, donde se muestra el mapa de calor y donde aparece el menú que contiene el resto de funcionalidades de la aplicación. o MapManager: clase dedicada a gestionar el mapa de calor de la actividad principal. o ResultAdapter: adaptador personalizado de la ListView que gestiona los resultados de los escaneos que aparecen al terminar estos. o ResultsActivity: actividad que se activa cada vez que el usuario termina un escaneo. Muestra los resultados de dicho escaneo con todo lujo de detalles: fecha de inicio, fecha de fin, número total de hallazgos y una lista con todos los hallazgos. Gracias a la funcionalidad implementada en ResultAdapter, el usuario puede pulsar en un elemento de la lista para que aparezcan datos adicionales sobre dicho elemento. o SettingsActivity: actividad que se activa cuando el usuario pulsa la opción de configuración del menú de la aplicación. Contiene los parámetros de configuración que el usuario puede personalizar, como el modo de ahorro de energía. 25 Capítulo 5: Implementación y pruebas 5.2. Estructura del proyecto web En esta sección se procederá de igual manera que en la sección anterior, pero con la estructura del proyecto web. La Figura 6 expone dicha estructura y, seguidamente, se encuentra una explicación de las partes marcadas en la misma. Figura 6 – Estructura del proyecto de la aplicación web Las partes importantes de la estructura se encuentran numeradas en la Figura 6. Están detalladas a continuación: 1. Properties: aquí es donde se almacena la configuración general y las propiedades del proyecto. 2. References: apartado en el que se guardan todas las referencias a librerías de terceros o externas. 26 SmartSniff 3. wwwroot: en esta carpeta están contenidos todos los ficheros JavaScript, CSS, imágenes, etc. Es la carpeta raíz de la página web. 4. Controllers: en esta carpeta están contenidas todas las clases controladoras de la aplicación web. a. DbController: clase encargada de gestionar todas las transacciones con la base de datos del servidor. b. HomeController: clase encargada de manejar la funcionalidad de las páginas web a nivel de controlador. 5. Models: en esta carpeta están contenidas las clases que conforman el modelo de datos de la aplicación. Son las mismas 4 clases de entidad que aparecen en la aplicación móvil, con la diferencia de que la clase AsocSessionDevice se corresponde con la clase Association de la aplicación móvil. 6. Views: en esta carpeta están contenidas todas las vistas de la aplicación web, es decir, la estructura de las páginas en lenguaje HTML. 7. Program.cs: clase que conforma el punto de partida de la aplicación web. Es en esta clase donde se construye y ejecuta el servidor web autocontenido por la propia aplicación, que será el encargado de escuchar las peticiones HTTP. 8. project.json: fichero en formato JSON que contiene la configuración global del proyecto. 9. smartsniff_dbContext.cs: clase que es empleada para consultar la base de datos y agrupar los cambios que puedan realizarse en los datos para escribirlos en la propia base de datos como una unidad. 10. Startup.cs: antes de que la aplicación se ejecute, esta clase es la encargada de realizar un proceso de configuración que aglutina las librerías a emplear y la inyección de dependencias, entre otros pasos. 5.3. Desarrollo del proyecto Esta sección explica el desarrollo de las actividades más críticas del sistema, empezando por la aplicación móvil y terminando por la aplicación web. Las tareas se presentan siguiendo un orden cronológico, reflejando una secuencia habitual de ejecución de la aplicación, pasando por toda su funcionalidad. Son las siguientes: • Aplicación móvil o Branded Splash Screen o Escanear dispositivos o Detener escaneo o Enviar datos o Borrar datos o Configuración • Aplicación web o Mapa de calor o Estadísticas 27 Capítulo 5: Implementación y pruebas 5.3.1. Branded Splash Screen En las primeras fases de desarrollo de la aplicación móvil se podía apreciar que cada vez que se ejecutaba la aplicación, esta mostraba una pantalla completamente blanca y vacía durante unos segundos en los cuales estaba cargando la interfaz principal (el layout de la interfaz y el mapa de calor). Para solventar este inconveniente se pensó en desarrollar lo que se conoce como una splash screen. Esto es una pantalla que aparece nada más abrir la aplicación y que muestra una imagen representando el logo de la misma, y que tiene como propósito ocultar la interfaz del programa al usuario mientras este se carga. Están recogidas en la guía de Google de Material Design para su interfaz de Android [14]. Para implementar esta solución se ha procedido como sigue. En primer lugar, se debe declarar un tema visual para la pantalla que aparecerá. Esto se hace en el fichero styles.xml contenido en la carpeta res/values del proyecto. <style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar"> <item name="colorPrimary">@color/colorPrimary</item> <item name="colorPrimaryDark">@color/colorPrimaryDark</item> <item name="colorAccent">@color/colorAccent</item> </style> <style name="AppTheme.BrandedLaunch" parent="AppTheme"> <item name="android:windowBackground">@drawable/branded_logo</item> </style> Código 1 – Tema visual de la splash screen Como se puede observar, el tema visual principal es padre del tema visual empleado en la pantalla. Esto se hace para que la transición entre la splash screen y la interfaz principal sea lo más transparente posible para el usuario. Lo siguiente que debemos hacer es construir el fichero que en el tema visual hemos colocado bajo la etiqueta android:windowBackground. Esto es, el elemento que contendrá los elementos visuales de la pantalla. El fichero en cuestión se denomina branded_logo.xml y está en la carpeta res/drawable del proyecto, y contiene la estructura de la pantalla inicial: • Un elemento que contiene un color de fondo blanco, acorde al tema visual de la aplicación. • Un elemento que contiene la imagen que se muestra en la pantalla de carga. En nuestro caso, es el icono de la aplicación pero a una resolución mayor, y en formato de imagen 9-patch para que Android pueda mostrarla a un tamaño adecuado a la pantalla del usuario, sea cual sea su resolución. 28 SmartSniff <layer-list xmlns:android="http://schemas.android.com/apk/res/android"> <item> <color android:color="@color/background_material_light"/> </item> <item> <bitmap android:src="@drawable/smartsniff_launch9patch" android:tileMode="disabled" android:gravity="fill_horizontal|fill_vertical"/> </item> </layer-list> Código 2 – Elemento visual de la splash screen Por último, asignamos el tema visual que acabamos de crear a la actividad principal de la aplicación en el manifiesto de la misma (fichero AndroidManifest.xml). Cabe destacar que, para que la aplicación recupere su tema principal, hay que hacer una llamada a la función setContentView() con la interfaz principal de la aplicación al principio del método onCreate() de la actividad principal. El resultado final es el mostrado en la Figura 7. Ahora, cada vez que el usuario ejecute la aplicación, será esta pantalla la que salga en primer lugar, evitando así mostrar una pantalla vacía durante los segundos en los que la aplicación se carga. Además, al estar la interfaz contenida en un fichero XML, está precargada en memoria, por lo que la pantalla se muestra inmediatamente sin tiempo de carga alguno. 5.3.2. Escanear dispositivos Como seguramente intuirá el lector, esta funcionalidad es crítica para el funcionamiento de la aplicación. De hecho, es en torno a la cual gira el resto del sistema, desde la aplicación móvil hasta la aplicación web. Un esquema de funcionamiento a alto nivel es el siguiente: 1. El usuario presiona el botón de escaneo. 2. La aplicación crea una nueva sesión, y toma la fecha actual como fecha de inicio. Figura 7 – Branded Splash Screen 29 Capítulo 5: Implementación y pruebas 3. La aplicación verifica que los permisos de ubicación y la interfaz Bluetooth del dispositivo están disponibles. En caso contrario, pide al usuario permiso para activar las que no lo estén. 4. El sistema activa los procedimientos de escaneo, por lo que se empieza a escanear tanto puntos de acceso wifi como dispositivos Bluetooth de forma simultánea. 5. Cuando se detecta un dispositivo: a. La aplicación pide la ubicación del dispositivo móvil, proveniente o bien del GPS o bien de Internet, en función de si el usuario tiene el modo ahorro de energía activado o no. Dicha ubicación se almacena en una variable temporal. b. Una vez hecho esto, se crea un objeto de tipo Device y se puebla con la información obtenida del escaneo. c. La aplicación verifica si el dispositivo está ya en la base de datos o no, es decir, si ha sido descubierto previamente: i. Si no está en la base de datos, se inserta a la base de datos y se realiza una asociación entre la sesión, el dispositivo y la ubicación. Además, se incrementa el número de hallazgos de la sesión. ii. Si está en la base de datos, no se realiza la inserción. d. Si el usuario se ha movido con respecto a su última ubicación, se pinta en el mapa de calor de la interfaz un punto para indicar que en esa ubicación ha habido hallazgos. e. Repetir de ‘a’ hasta ‘d’, hasta que el usuario presione el botón de escaneo de nuevo. Para que esta actividad se desempeñe correctamente es necesaria la intervención de las siguientes clases: • GeolocationGPS: provee de una ubicación a la aplicación. • DatabaseHelper: implementa los métodos CRUD que se emplearan para añadir los dispositivos y ubicaciones que corresponda. • MainActivity: contiene la interfaz de escaneo y la funcionalidad de detección. El código de las tres clases es demasiado extenso como para ponerlo en la memoria. Se puede encontrar en el Anexo físico entregado junto a la misma o en el repositorio de código indicado en la sección 2.1. La Figura 8 presenta la interfaz principal de la aplicación móvil. El usuario, antes de presionar el botón de escaneo, se encuentra con dicha interfaz una vez el programa está cargado. 30 SmartSniff Figura 9 – Interfaz principal en modo escaneo Figura 8 - Interfaz principal en modo standby Cuando presiona el botón de escaneo, y tras verificar los permisos de ubicación y la interfaz Bluetooth, la interfaz muestra la información disponible de la sesión actual (fecha de inicio y número de hallazgos), como se muestra en la Figura 9. Es importante destacar que el número de hallazgos mostrado en esta interfaz es el número de dispositivos nuevos descubiertos. Los dispositivos nuevos que se vayan descubriendo se asocian a la sesión en memoria de manera temporal, con el objetivo de no tener que recurrir a la base de datos a la hora de mostrar los resultados de la sesión terminada. Si bien la obtención de la ubicación se hace de una forma muy habitual en este tipo de aplicaciones, la manera en la que se hacen las asociaciones es particular de esta aplicación. 31 Capítulo 5: Implementación y pruebas Únicamente se comentará la inserción de los dispositivos, puesto que la inserción de las localizaciones y las sesiones se hace de manera muy similar. A continuación se explica el método addDevice() de la clase DatabaseHelper. Dado que el código de dicho método es extenso no se ha expuesto aquí. No obstante, puede ser consultado en el Anexo físico de la memoria o en el repositorio de código de la aplicación móvil. Debemos obtener una instancia en modo de escritura de la base de datos local y, seguidamente, preparar un cursor para almacenar el resultado de la consulta de inserción. Preparamos un objeto ContentValues con los valores de las columnas de la tabla Device, obtenidos del dispositivo pasado como parámetro. Una vez hecho esto, creamos una variable en la que almacenaremos la ID que devuelva la consulta después de hacer la inserción. Esta ID es la ID de la fila de la tabla que correspondería al dispositivo añadido. En caso de error, esta consulta devolvería -1. No obstante, el error sería capturado por el bloque catch, y se procedería a su manejo. En caso de que la consulta de inserción se realice con éxito y se devuelva la ID, se almacena en una variable de clase llamada deviceId. En el caso de que la consulta no pueda realizarse debido a que el dispositivo ya esté almacenado en la tabla, se obtiene la ID del mismo en la tabla mediante una búsqueda, utilizando para ello su dirección física ya que dos dispositivos distintos no pueden tener la misma dirección física. Esto se hace para garantizar que, tanto si se ha hecho bien la consulta como si no debido a que el dispositivo ya existe en la base de datos, se tenga la ID del dispositivo en la variable deviceId al finalizar el método. A lo largo del proceso de trabajo se ha puesto un claro énfasis en llevar a cabo prácticas de programación defensiva. La descrita en el párrafo anterior es una de las muchas que hay distribuidas por todo el proyecto y, gracias a ellas, la aplicación puede mantener su funcionamiento de forma adecuada a pesar de que ocurran situaciones de error que se puedan controlar. Esto mismo que se ha hecho con el dispositivo se realiza con la sesión y la ubicación en las variables locationId y sessionId, respectivamente. Una vez se tienen las tres IDs, se llama al método addAssociation() de la misma clase. Nótese que la asociación se hace con las IDs obtenidas de haber realizado anteriormente las inserciones de la sesión, ubicación y dispositivo que intervienen en la asociación. 32 SmartSniff Ahora se procede a explicar el proceso de detección a nivel de código. Comenzaremos con los procesos de preparación para el escaneo, que tienen lugar cuando el usuario presiona el botón de escanear. Primero se activa un flag que inhabilita el menú de opciones para evitar que el usuario pueda modificarlas mientras tiene lugar un escaneo. Inmediatamente después se activa la interfaz de escaneo, y se procede a comprobar si la interfaz Bluetooth está activada, pidiéndole acto seguido al usuario que la active en caso contrario. En la llamada siguiente a geoGPS.connect(), la API de Google Play Services comprueba si los servicios de ubicación del teléfono están disponibles, y también se pide al usuario que los active si no lo están. A continuación se obtiene la fecha actual del dispositivo y se almacena como fecha de inicio de la sesión. Se crea la sesión con dicha fecha y se añade la sesión a la base de datos para tener preparada la ID de dicha sesión en la tabla para cuando llegue el momento de hacer asociaciones. Nótese que únicamente se añade la fecha de inicio, la fecha de finalización se añade con una actualización posterior. Para poder mantener un registro de los hallazgos de la sesión se crea la variable auxiliar lastSession, que contendrá a la sesión. Además, se crea la lista lastSessionDevices, que contendrá los resultados de la sesión para mostrarlos en la interfaz de resultados, más adelante. Es necesario destacar que esta lista tiene la propiedad de que es thread-safe, por lo que se accede a dicha lista de forma atómica. Una vez hecho todo esto, se llama al procedimiento beginScanningProcedure(). El procedimiento de escaneo de dispositivos wifi se lleva a cabo en un thread que se ejecuta constantemente a intervalos de tiempo definidos por el usuario en la configuración. El tiempo por defecto son 3 segundos. El procedimiento de escaneo de dispositivos Bluetooth se realiza fuera del thread. El BroadcastReceiver encargado de gestionar los resultados recibidos de los escaneos se registra en el contexto de la aplicación antes de comenzar los escaneos correspondientes. Antes de empezar el escaneo Bluetooth se comprueba de nuevo si la interfaz Bluetooth está activada para evitar empezarlo si no lo está, evitando así muchos errores. Es importante destacar que el thread continúa ejecutándose mientras el botón de escaneo esté pulsado. En el momento en el que se vuelva a pulsar para desactivarlo, su ejecución termina. 33 Capítulo 5: Implementación y pruebas El escaneo Bluetooth se trata de forma independiente puesto que es un proceso muy pesado tanto en coste de recursos como en tiempo de cómputo, por lo que se pide un escaneo cada vez que termina el anterior. Un escaneo Bluetooth tiene una duración estimada de unos 12 segundos. Está recomendado por Google como buena práctica pedir finalizar un escaneo Bluetooth aunque no se haya iniciado, para asegurar que no hay un gasto innecesario de recursos. Esto se hace en varios puntos de la aplicación, en especial durante el propio escaneo para verificar si el usuario ha desactivado la interfaz Bluetooth durante el mismo para evitar que se pidan escaneos hasta que se vuelva a activar de nuevo. Todo el código que interviene en la detección de dispositivos puede encontrarse en el repositorio de la sección 2.1 o en el Anexo físico entregado junto a esta memoria. 5.3.3. Detener escaneo Detener un escaneo en proceso pone en proceso una serie de eventos de especial importancia. Un resumen de dichos eventos es el siguiente: 1. Comienzan los procedimientos de parada de escaneo, que incluye la desvinculación del BroadcastReceiver encargado de procesar los resultados del escaneo, la actualización de la sesión y el refrescado del mapa de calor de la interfaz. 2. Se muestra al usuario una interfaz en la que se muestran los resultados. Cabe destacar que, si bien ambos sucesos ocurren de forma secuencial, se muestran los resultados en una interfaz nueva mientras se actualiza el mapa de calor. Esto se consigue mediante el empleo de una tarea asíncrona (AsyncTask) encargada de procesar todos los puntos del mapa de calor mientras el usuario interacciona con la lista de resultados. Las clases que intervienen en esta funcionalidad son MapManager y MainActivity. También se accede a la base de datos con los métodos de la clase DatabaseHelper. Para mostrar los resultados se recurre a las clases ResultsActivity y ResultAdapter. Cuando el usuario presiona el botón de parar escaneo, ocurren varias cosas. En primer lugar se desvincula el BroadcastReceiver encargado de procesar los resultados de los escaneos. Si la interfaz Bluetooth está activada se pide cancelar cualquier escaneo Bluetooth en proceso, incluso si no lo hubiere. Seguidamente se desconecta el GPS y se actualiza la sesión en la base de datos con la fecha de finalización. 40 SmartSniff • StatArray: no es más que un array de objetos StatData clasificados por diagrama a representar. Hay uno por cada gráfica, y cada uno de ellos contiene los datos necesarios para elaborar la estadística correspondiente. El código de ambas estructuras de datos es el siguiente: public struct StatData { public string label { get; set; } public string value { get; set; } public StatData(String dataLabel, int dataValue) { label = dataLabel; value = dataValue.ToString(); } } public struct StatArray { public StatData[] statDataArray { get; set; } public StatArray(StatData[] dataArray) { statDataArray = dataArray; } } Código 4 – Estructuras de datos del controlador para las estadísticas web La aplicación web permite al usuario filtrar los datos que se mostrarán en las gráficas por fecha. Se presentan a continuación capturas de dos de las cinco estadísticas empleadas, correspondientes a los dos tipos distintos de gráfica existentes en la aplicación (ver Figuras 15 y 16). 41 Capítulo 5: Implementación y pruebas Figura 15 – Dispositivos diarios detectados (diagrama de barras) 42 SmartSniff Figura 16 – Dispositivos detectados según fabricante (diagrama circular) 5.4. Pruebas No se han podido realizar pruebas de código en la aplicación móvil, como se estimó inicialmente. La razón es que los emuladores Android no pueden simular ni localizaciones ni redes o dispositivos inalámbricos, y aquellos emuladores que aseguraban poder hacerlo presentaban situaciones de error, como por ejemplo cierres constantes del emulador. Asimismo, resultaba imposible cargar en el emulador las bibliotecas de Google Play empleadas para el desarrollo de la aplicación. 43 Capítulo 5: Implementación y pruebas En su lugar, se han realizado pruebas en entornos urbanos reales para determinar el correcto funcionamiento de la aplicación y encontrar errores. A continuación se presenta la última prueba de campo realizada. Dicha prueba de campo es de especial relevancia para el TFG, puesto que además de ser la de mayor envergadura permitió trabajar con un volumen de datos considerable y, además, descubrió un error crítico en la aplicación móvil. Fecha de inicio 23/09/2016 18:18:35 Fecha de fin 23/09/2016 19:05:00 Número de dispositivos encontrados 973 Número de localizaciones registradas 513 Número de sesiones realizadas 3 Tabla 10 – Resumen de prueba de campo Figura 17 – Ruta seguida durante la prueba de campo 44 SmartSniff Primera sesión Figura 18 – Pantalla de resultados de la primera sesión La primera sesión fue un trayecto en coche. Como era de esperar, transcurrió sin ningún incidente y se recogió una amplia gama de resultados. Una particularidad de esta sesión fue la aparición de muchos puntos de acceso wifi sin SSID asignado. Normalmente, cuando un punto de acceso no dispone de SSID suele tratarse de un repetidor o un dispositivo similar que no requiere de interacción alguna con los usuarios, por lo que es habitual que el SSID se omita. No se encontraron muchos dispositivos Bluetooth. La inmensa mayoría de dispositivos (468) fueron puntos de acceso wifi. 45 Capítulo 5: Implementación y pruebas Segunda sesión Figura 19 – Pantalla de resultados de la segunda sesión La segunda sesión se realizó en metro. La intención era comprobar el comportamiento de la aplicación móvil en situaciones de cobertura escasa o nula. Los resultados obtenidos (ver Figura 19) fueron satisfactorios: la aplicación no tuvo ningún error que forzara su detención, y no registró los dispositivos encontrados sin haber una localización disponible, por lo que su comportamiento fue el esperado. En esta sesión, todos los dispositivos encontrados fueron puntos de acceso wifi. 46 SmartSniff De la tercera sesión no se dispone de pantalla resultados puesto que se encontró un error que hizo que la aplicación se detuviera forzosamente antes de mostrarlos. Dicho error era un fallo en el método que recargaba el mapa de calor de la interfaz tras un escaneo. Consistía en que una vez obtenidas las localizaciones de la tabla Location, al ejecutarse una función SQL COUNT para averiguar cuántos dispositivos tenía asociados cada localización (COUNT sobre idLocation en la tabla AsocSessionDevice) el programa tenía un error de desbordamiento de memoria. La razón de dicho error era un cursor que no se cerraba, y que se encuentra dentro de un bucle que itera por todas las localizaciones encontradas. Se presenta el código a continuación (método selectLocationsForHeatmap() en DatabaseHelper). public Map<Location, Integer> selectLocationsForHeatmap(){ Map<Location, Integer> locationMap = new ArrayMap<>(); SQLiteDatabase db = getReadableDatabase(); Cursor cursor = null; db.beginTransaction(); try{ String selectQuery = "SELECT * FROM " + TABLE_LOCATIONS; cursor = db.rawQuery(selectQuery, null); if(cursor.moveToFirst()){ do { String[] latlong = cursor.getString(2).split(", "); double latitude = Double.parseDouble(latlong[0]); double longitude = Double.parseDouble(latlong[1]); Location location = new Location(new LatLng(latitude, longitude)); String countQuery = "SELECT count(*) FROM " + TABLE_ASOCSESSIONSDEVICES + " WHERE " + KEY_ASSOCIATION_ID_LOCATION_FK + " = " + cursor.getInt(0); Cursor countCursor = db.rawQuery(countQuery, null); if(countCursor.moveToFirst()) locationMap.put(location, countCursor.getInt(0)); countCursor.close(); }while(cursor.moveToNext()); } db.setTransactionSuccessful(); } . . . return locationMap; } Código 5 – Método selectLocationsForHeatmap() El cursor que no se cerraba es countCursor, declarado para albergar el resultado de la consulta countQuery. La instrucción que arregló el error es countCursor.close(), situada justo debajo de la instrucción que coloca la ubicación junto al número de dispositivos detectados en ella en el Map que se devuelve como resultado de la función. Antes de hacer esto, la aplicación era capaz de cargar una cantidad limitada de puntos debido a la enorme cuantía de cursores que quedaban sin cerrar. Después del cambio, es capaz de procesar cualquier cantidad de ubicaciones. 47 Capítulo 6: Conclusiones y trabajo futuro Capítulo 6. Conclusiones y trabajo futuro 6.1. Conclusiones Uno de los pilares fundamentales de las ciudades inteligentes es la interconexión entre dispositivos inalámbricos. Esto ha provocado un crecimiento desorbitado de redes wifi y dispositivos Bluetooth en entornos urbanos. Este TFG ha propuesto SmartSniff, un sistema basado en una aplicación móvil capaz de recolectar datos sobre los puntos de acceso wifi y dispositivos Bluetooth para elaborar estadísticas que pueden ser útiles tanto para usuarios como para instituciones. La aplicación móvil permite recabar diversa información útil de los puntos de acceso wifi y dispositivos Bluetooth. Entre toda la información recabada, cabe destacar el nombre de dichos dispositivos, sus direcciones físicas y su fabricante, además de diversos parámetros como el tipo de dispositivo, el ancho de canal y la banda de frecuencia empleada para la emisión de datos. Estos datos se envían a una aplicación web para elaborar estadísticas visuales, entre los cuales podemos encontrar un mapa de calor que refleja el número de dispositivos detectados en un área determinada o diagramas que representan los dispositivos encontrados categorizados por fabricante. A partir de estos datos podrían elaborarse otras estadísticas significativas que podrían ser utilizadas para la toma de decisiones supervisada. Un ejemplo de ello sería el uso de la marca de teléfono de una zona determinada para realizar o evaluar tareas de marketing adaptadas. Este TFG ha supuesto una gran oportunidad para aprender muchas tecnologías nuevas, como Leaflet, .NET Core y Volley. El desafío fundamental del proyecto ha sido implementar un método de escaneo simultáneo de redes wifi y dispositivos Bluetooth por las particularidades del escaneo de estos últimos en dispositivos Android. Desarrollar este sistema nos ha permitido comprobar que, tal y como se preveía, los entornos urbanos modernos están repletos de redes wifi. Abundan las redes privadas, aunque se puede apreciar que las redes públicas tienen cada vez más presencia en dichos entornos. Esto implica que cada vez más personas podrán beneficiarse de servicios que se ofrezcan a través de este tipo de redes. 48 SmartSniff También hemos comprobado, en claro contraste con lo comentado anteriormente, la escasez de dispositivos Bluetooth encontrados. Podría inferirse a partir de este resultado que los usuarios de dispositivos móviles a día de hoy no ven mucho sentido a llevar habilitada la interfaz Bluetooth de sus dispositivos móviles. Esto puede ser una consecuencia de la falta de servicios disponibles que empleen esta tecnología como base. 6.2. Líneas futuras Del trabajo realizado en este TFG podrían partir las siguientes líneas de trabajo futuro. A continuación se presentan algunas de las más notables: • Muestra opcional del mapa de calor: una mejora interesante de la aplicación móvil sería añadir como parámetro de configuración que se mostrase el mapa de calor de manera opcional. Al cargar el mapa cuando la aplicación se carga, hay un pico de descarga de datos que puede evitarse con esta opción. Si bien no es una cantidad preocupante para las tarifas de datos existentes hoy en día, es interesante el añadido de esta opción al menú de configuración. • Identificación de usuario: añadir una identificación de resultados por perfil de usuario podría aumentar la experiencia de usuario con la aplicación y hacerla más positiva. • Exportación de datos: poder exportar los datos almacenados en la base de datos de la aplicación móvil reduciría la cantidad de memoria que ocupa la aplicación. • Incorporación de herramientas de Inteligencia de Negocio (Business Intelligence): esta mejora nos permitiría generar conocimiento a partir de las grandes cantidades de información que se obtiene con este sistema. 49 Referencias [1] Dameri, R. P., & Rosenthal-Sabroux, C. (2014). Smart City. Springer. [2] García, F. M. (7 de Mayo de 2015). Hipertextual. Obtenido de https://hipertextual.com/2015/05/smart-cities-espana [3] Página oficial SQLite: http://sqlite.org/docs.html [4] Documentación Google Play Services API: https://developer.android.com/training/location/receive-location-updates.html [5] Documentación Google Maps API - Heatmap: https://developers.google.com/maps/documentation/androidapi/utility/heatmap#introduction [6] Documentación Volley: https://developer.android.com/training/volley/index.html [7] Guía de usuario Gson: https://github.com/google/gson/blob/master/UserGuide.md [8] Página oficial PostgreSQL: https://www.postgresql.org/ [9] Shirhatti, S. Publish to a Linux Production Environment. Obtenido de ASP.NET Documentation: https://material.google.com/patterns/launchscreens.html# [10] Página oficial .NET: https://dotnet.github.io/ [11] Página oficial Leaflet: http://leafletjs.com/ [12] Plugin Heatmap.js para Leaflet: https://www.patrick-wied.at/static/heatmapjs/plugin-leaflet-layer.html [13] Página oficial FusionCharts: http://www.fusioncharts.com/ [14] Google. Launch Screen - Patterns. Obtenido de Material design guidelines: https://material.google.com/patterns/launch-screens.html 56 Figura 28 – Actualización de fuentes de paquetes de Linux con Terminal Para finalizar este paso, instalaremos el propio framework con la siguiente sentencia: sudo apt-get install dotnet-dev-1.0.0-preview2-003131 Es necesario mencionar que antes de ejecutar esta sentencia debemos eliminar cualquier versión previa de .NET Core que tengamos instalada en nuestro sistema. Para ello, podemos utilizar el script disponible en la propia sección de instalación de .NET Core para Linux, disponible en https://www.microsoft.com/net/core#ubuntu. Una vez instalemos .NET Core y el sistema nos muestre la confirmación habitual de que la instalación se ha realizado correctamente, procederemos a configurar el servidor proxy inverso Nginx. 57 Paso 3 – Nginx Instalaremos Nginx en el sistema ejecutando la sentencia sudo apt-get install nginx Figura 29 – Instalación de Nginx con Terminal Nginx queda completamente instalado. Ahora necesitamos configurarlo adecuadamente. Lo primero que debemos hacer es eliminar el servidor de escucha por defecto de Nginx. Los comentarios se escriben con un símbolo # delante, así que deberemos abrir el fichero con ruta /etc/nginx/sites-available/default con nuestro editor de texto favorito y comentar todas las líneas a excepción de aquellas que se encuentren dentro del ámbito server. Puede abrirse el fichero directamente desde el terminal con la siguiente sentencia: sudo nano /etc/nginx/sites-available/default 58 A continuación debemos configurar nuestro servidor modificando el fichero de configuración de Nginx, disponible en la ruta /etc/nginx/nginx.conf. Eliminaremos todo lo que se encuentra dentro del ámbito http y escribiremos lo siguiente: Figura 30 – Configuración de Nginx (fichero nginx.conf) Para finalizar, dado que nuestro servidor está escuchando en el puerto 5000, lo indicamos en el fichero default. Abrimos dicho fichero y escribimos lo que se muestra en la siguiente captura: Figura 31 – Configuración de Nginx (fichero default) Tras esto, deberemos indicarle a Nginx que la configuración ha cambiado con el comando sudo nginx -s reload. Si lo hemos hecho todo bien, no debería haber errores. 59 Paso 4 – Puesta a punto de la base de datos En este paso importaremos el esquema de la base de datos y configuraremos el usuario por defecto de PostgreSQL. En primer lugar, haremos lo segundo tal y como se muestra en la siguiente captura. Figura 32 – Configuración del usuario postgres con Terminal Inmediatamente después abriremos pgAdmin y crearemos una conexión nueva a la base de datos. Será en esta conexión donde importemos el esquema. La conexión se configura con el usuario postgres, tal y como se muestra en la Figura 33. 60 Figura 33 – Configuración de la conexión al servidor de bases de datos Una vez hecho esto abrimos el desplegable de la conexión hasta encontrarnos con el de las bases de datos. Hacemos click derecho sobre el mismo y después seleccionamos la opción “New Database”. La llamaremos “smartsniff-db” y asignamos el usuario postgres como Owner. Finalmente hacemos click derecho en la base de datos recién creada y después en “Restore”. Seleccionamos nuestro esquema de base de datos y hacemos click en “Restore”. Al finalizar el proceso, la base de datos quedará totalmente funcional. El paso final sería importar la aplicación en .NET Core a nuestro sistema linux y, en la carpeta donde se encuentre el dll de la aplicación, escribir el siguiente comando en el terminal: dotnet ‘dll de la aplicación’ 61 C. Glosario Todos los términos empleados en este documento relacionados directamente con la Ingeniería del Software están definidos en el estándar IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology. HTML: Hyper Text Markup Language. Lenguaje declarativo para la elaboración de páginas web. CSS: Cascading Style Sheets. Lenguaje para la definición y creación de la presentación visual de un documento HTML. JS: abreviatura de JavaScript, lenguaje de programación interpretado empleado para elaborar scripts que se ejecutan en páginas web. AJAX: Asynchronous JavaScript and XML. Técnica de desarrollo web que permite hacer peticiones asíncronas a una base de datos para actualizar una página web sin necesidad de recargarla. HTTP: HyperText Transfer Protocol. Protocolo de comunicación que permite las transferencias de información por Internet. JSON: JavaScript Object Notation. Formato de texto ligero para el intercambio de datos ampliamente usado en la actualidad. API: Application Programming Interface. Conjunto de funciones y métodos que son ofrecidos por bibliotecas software para ser empleados como capa de abstracción. REST: Representational State Transfer. Interfaz entre sistemas que usa HTTP de forma directa para obtener datos o indicar la ejecución de operaciones sobre datos. Sus principales características son un rendimiento rápido, una robustez elevada y su escalabilidad. CRUD: Create, Read, Update, Delete. Funcionalidades básicas en bases de datos. APK: Android Application Package. Paquete contenedor de componentes para el sistema operativo Android. Usado para distribuir e instalar aplicaciones. 62 Índice de figuras FIGURA 1 – DIAGRAMA DE CASOS DE USO DE LA APLICACIÓN ANDROID ............................ 10 FIGURA 2 – DIAGRAMA DE DISTRIBUCIÓN ....................................................................... 17 FIGURA 3 – MODELO DE BASE DE DATOS LOCAL ............................................................. 18 FIGURA 4 – DIAGRAMA DE CLASES DE LA APLICACIÓN ANDROID ...................................... 21 FIGURA 5 – ESTRUCTURA DEL PROYECTO DE LA APLICACIÓN ANDROID ............................ 23 FIGURA 6 – ESTRUCTURA DEL PROYECTO DE LA APLICACIÓN WEB ................................... 25 FIGURA 7 – BRANDED SPLASH SCREEN ........................................................................ 28 FIGURA 8 – INTERFAZ PRINCIPAL EN MODO STANDBY ...................................................... 30 FIGURA 9 – INTERFAZ PRINCIPAL EN MODO ESCANEO ..................................................... 30 FIGURA 10 – INTERFAZ DE RESULTADOS DE SESIÓN ....................................................... 34 FIGURA 11 – DETALLES DE RESULTADO ........................................................................ 34 FIGURA 12 – MENSAJE DE CONFIRMACIÓN DE BORRADO DE DATOS ................................. 36 FIGURA 13 – INTERFAZ DE CONFIGURACIÓN .................................................................. 37 FIGURA 14 – MAPA DE CALOR DE LA APLICACIÓN WEB .................................................... 39 FIGURA 15 – DISPOSITIVOS DIARIOS DETECTADOS (DIAGRAMA DE BARRAS) ...................... 41 FIGURA 16 – DISPOSITIVOS DETECTADOS SEGÚN FABRICANTE (DIAGRAMA CIRCULAR) ...... 42 FIGURA 17 – RUTA SEGUIDA DURANTE LA PRUEBA DE CAMPO ......................................... 43 FIGURA 18 – PANTALLA DE RESULTADOS DE LA PRIMERA SESIÓN .................................... 44 FIGURA 19 – PANTALLA DE RESULTADOS DE LA SEGUNDA SESIÓN ................................... 45 FIGURA 20 – CÓDIGO QR PARA DESCARGAR LA APLICACIÓN ANDROID ............................ 50 FIGURA 21 – INTERFAZ PRINCIPAL DE LA APLICACIÓN ANDROID ....................................... 51 FIGURA 22 – MENÚ CONTEXTUAL DE LA APPBAR ............................................................ 51 FIGURA 23 – CUADRO DE DIÁLOGO PARA CONFIRMAR EL BORRADO DE DATOS .................. 52 FIGURA 24 – INTERFAZ DE ESCANEO ............................................................................. 53 FIGURA 25 – INTERFAZ DE MUESTRA DE RESULTADOS .................................................... 53 FIGURA 26 – INSTALACIÓN DE POSTGRESQL CON TERMINAL ......................................... 54 FIGURA 27 – INSTALACIÓN DE PGADMIN CON TERMINAL ................................................. 55 FIGURA 28 – ACTUALIZACIÓN DE FUENTES DE PAQUETES DE LINUX CON TERMINAL .......... 56 FIGURA 29 – INSTALACIÓN DE NGINX CON TERMINAL ..................................................... 57 FIGURA 30 – CONFIGURACIÓN DE NGINX (FICHERO NGINX.CONF) .................................... 58 FIGURA 31 – CONFIGURACIÓN DE NGINX (FICHERO DEFAULT) ......................................... 58 FIGURA 32 – CONFIGURACIÓN DEL USUARIO POSTGRES CON TERMINAL .......................... 59 FIGURA 33 – CONFIGURACIÓN DE LA CONEXIÓN AL SERVIDOR DE BASES DE DATOS ........... 60 63 Índice de tablas TABLA 1 – TECNOLOGÍA USADA EN LA APLICACIÓN ANDROID ............................................. 4 TABLA 2 – TECNOLOGÍA USADA EN LA APLICACIÓN WEB .................................................... 6 TABLA 3 – REQUISITOS FUNCIONALES DE LA APLICACIÓN ANDROID .................................... 8 TABLA 4 – REQUISITOS NO FUNCIONALES DE LA APLICACIÓN ANDROID ............................... 9 TABLA 5 – CASO DE USO 1: INICIAR ESCANEO ................................................................ 11 TABLA 6 – CASO DE USO 2: DETENER ESCANEO ............................................................ 11 TABLA 7 – CASO DE USO 3: BORRAR DATOS LOCALES .................................................... 12 TABLA 8 – CASO DE USO 4: ENVIAR DATOS A SERVIDOR ................................................. 13 TABLA 9 – CASO DE USO 5: CONFIGURAR APLICACIÓN ................................................... 13 TABLA 10 – RESUMEN DE PRUEBA DE CAMPO ................................................................ 43