T reba ll F ina l de G rau
GRAU D’ENGINYERIA INFORMÀTICA
Guía interactiva para asistencia a eventos al aire libre y espacios cerrados
JUSTO HERRERO AMORÓS
Tutor
Miquel Mascaró Portells
Escola Politècnica Superior
Universitat de les Illes Balears
Í NDICE GENERAL
Índice general i
Acrónimos iii
Resumen v
1 Introducción 1
1.1 Contextualitzación . . . 1
1.2 Estado del arte . . . 2
1.3 Bases del proyecto. . . 3
1.4 Aplicaciones . . . 4
2 Desarrollo del proyecto 5 2.1 Requisitos de desarrollo . . . 5
2.2 Metodología de desarrollo . . . 7
2.2.1 Stakeholders . . . 7
2.2.2 Requisitos de la aplicación . . . 8
2.2.3 Backlog . . . 8
2.2.4 Iteraciones. . . 12
2.3 Elección del sistema operativo de desarrollo . . . 13
2.4 Herramientas de desarrollo . . . 15
2.4.1 Netbeans 8.2 . . . 15
2.4.2 XAMPP 5.6.30 . . . 16
2.4.3 Android Studio 2.3.2 . . . 16
2.4.4 Bootstrap . . . 17
2.4.5 GlassFish . . . 17
2.5 Almacenamiento de datos . . . 18
2.6 Acceso a la información . . . 19
2.7 Mantenimiento de la información . . . 21
2.8 Diseño de la aplicación web . . . 22
2.8.1 Distribución de las páginas de la aplicación web . . . 22
2.8.2 Navegación de la aplicación web . . . 24
2.9 Diseño de la aplicación Android. . . 26
2.10 Elección del algoritmo de reconocimiento . . . 28
2.11 Reconocimiento de objetos . . . 30
3 Resultados 33
3.1 Aplicación Web. . . 33
3.1.1 Información. . . 33
3.1.2 Preguntas . . . 34
3.1.3 Mantenimiento . . . 35
3.2 Aplicación Android . . . 41
3.2.1 Pantalla principal. . . 41
3.2.2 Menu . . . 42
3.2.3 Reconocimiento de objetos. . . 42
3.2.4 Catálogo de información . . . 43
3.2.5 Información en detalle . . . 43
3.2.6 Preguntas frecuentes. . . 45
3.2.7 Pregunta en detalle. . . 46
4 Conclusiones 47 A Anexo 51 A.1 Definiciones . . . 51
Bibliografía 53
A CRÓNIMOS
FAQ Frequently Asked Questions GUI Graphical User Interface MVC Modelo-Vista-Controlador MySQL My Structured Query Language
OpenCV Open Source Computer Vision Library SO Sistema Operativo
SOAP Simple Object Access Protocol
SGBD Sistema de Gestión de Bases de Datos SW Servicio Web
W3C World Wide Web Consorcium WWW World Wide Web
XML eXtensible Markup Language
R ESUMEN
En el presente documento, se describe el desarrollo realizado sobre una aplicación basada en una guía para eventos al aire libre o en espacios cerrados mediante la cual ofrecer información destacada y de interés para los asistentes de dicho evento. El principio básico de dicha aplicación es que mediante la cámara del dispositivo móvil del asistente, se realice una focalización del elemento, donde mediante un software de reconocimiento de imágenes, se permita reconocer el elemento en cuestión y así proporcionar un conjunto de información relacionado con el mismo. No obstante, para la exposición de dicho proyecto se ha escogido la temática referente a un museo donde los objetos a reconocer son las propias obras de arte. El fundamento de dicho proyecto es que el concepto sea extrapolable a cualquier otro tipo de necesidad, desde la definición de rutas por carretera u otros puntos de interés hasta la exposición en una feria de videojuegos, por ejemplo. Entonces, se detallará en los próximos capítulos el funcionamiento de las dos aplicaciones construidas, tanto la aplicación web, que per- mite el mantenimiento de los datos, como la aplicación Android. Además, se pretende una estandarización en el uso de secciones de ayuda en las aplicaciones que faciliten el uso de la misma a usuarios con dificultades.
C
APÍTULO1
I NTRODUCCIÓN
1.1 Contextualitzación
En la actualidad, los dispositivos móviles o comúnmente conocidos comoSmartphones o teléfonos inteligenteshan experimentado una evolución destacable en el sector de la telefonía móvil, aunque más destacable aún en el campo de la informática en si.
Esta evolución se ha materializado en forma de la obtención de un micro-hardware casi tan potente como algunos de los ordenadores que hay en el mercado a día de hoy. Es por ello, que en el campo de desarrollo de aplicaciones paraSmartphonesse ha invertido un gran esfuerzo para aprovechar la potencia y la capacidad que tienen dichos dispositivos sumada a su gran portabilidad.
Entonces, es cuando se presenta la idea de realizar un proyecto software a nivel de aplicación paraSmartphonemediante la cual poder realizar un seguimiento de un evento de manera cómoda y rápida desde el dispositivo móvil. Dicha guía inter- activa, proporciona al usuario la capacidad de acceder a los recursos de información que este presenciando en ese mismo instante mediante la cámara de su dispositivo, mostrándose así toda la información relacionada con el elemento en cuestión.
1.2 Estado del arte
A día de hoy, existen diferentes aplicaciones que hacen uso de la tecnología del recono- cimiento en imágenes como por ejemplo Vuforia. Estos tienen una serie de aplicaciones en dicho ámbito que explotan el software de reconocimiento para lanzar aplicaciones de realidad aumentada mediante la cual necesitan reconocer una serie de elementos (cartas, tarjetas, etc) y a partir de ahí generan un output sobre lo que se esta visualizan- do en la pantalla mediante la captura de imágenes. Cabe destacar que la captura de imágenes se realiza de una manera eficiente, mediante tracking (VerA.1) por ello hace que el usuario únicamente tenga que centrarse en enfocar los elementos necesarios y esperar una respuesta. [1]
En la respuesta que espera el usuario hay un factor diferencial para el cuál nosotros ofrecemos una solución y es en el procesamiento de las imágenes. En este tipo de aplicaciones el tracking realizado va enviando las imágenes a un servidor mediante algún protocolo de comunicación donde son tratadas y entonces este devuelve una respuesta en función de la entrada. Entonces, nosotros para realizar un tratamiento más eficiente en el reconocimiento mediante tracking, implementamos el software de reconocimiento en la parte del dispositivo móvil y no en la parte del servidor, por lo que el procesamiento no tendrá ningún tiempo de respuesta más que el del propio software proporcionado por la librería gráfica.
También existe una aplicación desarrollada por una serie de investigadores, Nigel Davies y Andre Hesse, enfocada al reconocimiento de imágenes destinado a las guías turísticas. Esta aplicación, no utiliza el tracking de objetos por lo que el usuario debe ser el que realice las capturas de forma manual, lo cuál hará que la detección de elementos sea mucho más lenta. Además, el reconocimiento se hace en la parte del servidor, lo que deja patente que los resultados serán mucho menos eficientes de lo que se observaba en la aplicación de Vuforia. Es necesario decir que este representa un proyecto antiguo por lo que es comprensible que la evolución en los años posteriores ha sido más que notable.[2]
Es más, si nos adentramos en la industria de los videojuegos, la empresa japonesa Sony, ha desarrollado videojuegos para una de sus plataformas utilizando el recono- cimiento de objetos y partir de ellos expone una serie de elementos haciendo uso de la realidad aumentada. Si bien es cierto, que ha tenido poco soporte por lo que se ha quedado algo estancado el concepto. Dicha aplicación también hace uso del tracking de imágenes aunque únicamente está restringido al uso de un conjunto de cartas que activan el videojuego en cuestión. [3]
1.3. Bases del proyecto
1.3 Bases del proyecto
A partir de todas las ideas existentes en la actualidad, y analizando los puntos a mejorar en cada una de ellas, surge la idea de realizar una aplicación que sea una guía de ca- rácter general, es decir, que su utilización no se vea restringida a un solo ámbito como podría ser el de los videojuegos, por ejemplo. Entonces, nuestra aplicación principal- mente utilizará una librería gráfica, como es lógico, para el reconocimiento de imágenes pero esta, no se ejecutará en la parte del servidor, si no que formara parte de uno de los módulos que componen la aplicación móvil, de esta manera conseguimos eliminar el tiempo de comunicación entre el servidor y el dispositivo móvil. No obstante, el reconocimiento de imágenes se realizará mediante tracking, de esta manera el usuario se sentirá más cómodo y libre a la hora de hacer uso de la aplicación.
Además, otro de los puntos a destacar es que el reconocimiento no hace uso de el GPS integrado en el dispositivo móvil por lo que la aplicación puede usarse en eventos interiores, como podría ser una feria. Sin embargo, hay que destacar que ello hace que la posibilidad de un error de la geo-locazación de nuestro dispositivo no nos ofrezca los resultados esperados. Relacionado con la ausencia del uso de la geo-localización tenemos el consumo energético del dispositivo, que al hacer uso de menos recursos, hace que la aplicación sea más eficiente en cuanto al impacto en la autonomía de la bateria.
Incluso, en uno de los puntos más destacados respecto a las diferentes aplicaciones que existen hoy en día, la aplicación desarrollada necesita de conexión a internet una única vez, por lo que una vez descargados los recursos de información necesarios para poder reconocer los elementos propuestos podrá utilizarse sin la necesidad de una co- nexión a internet permanente lo cuál supone, en primera instancia una flexibilidad no conocida hasta la fecha, ya que la gran mayoría de aplicaciones móviles en el mercado necesitan de una conexión a internet permanente. Aunque, cabe recordar que en caso de que el usuario quisiera tener la información más actual posible, deberá de hacer uso de su conexión a internet.
A grandes rasgos, la aplicación desarrollada reúne las siguientes características en comparación a lo existente en la actualidad:
Característica App UIB Vuforia Investigadores Sony
Sin uso de GPS X X X
Tracking X X X
Almacenamiento local X X
Reconocimiento en local X
Cuadro 1.1: Características de las aplicaciones.
1.4 Aplicaciones
El principal punto de interés de este tipo de aplicación, está enfocado, hacia el sector turístico mediante la cual se pretende realizar una guía interactiva vistosa y de gran calidad que permita acceder al huésped del hotel a la información que precise de ma- nera sencilla e intuitiva. Como ya es sabido, la información más recurrente en un hotel puede ser desde las tarifas establecidas para el minibar hasta las instrucciones para utilizar la caja de seguridad de la habitación.
Por ello, se pretende hacer más accesible la información del hotel de manera que el usuario pueda ir consultando dicha información en todo momento sin la necesidad de realizar dicha consulta a alguno de los trabajadores del hotel.
No obstante, existen otro tipo de aplicaciones, como pueden el recorrido de rutas donde mediante puntos de interés se va conociendo el recorrido sin la necesidad de utilizar la geo-localización. También tiene cabida la posibilidad de realizar guías para eventos como una feria de videojuegos donde las diferentes paradas aguarden promo- ciones y otras informaciones de interés para los asistentes.
Si bien es cierto, que todo el desarrollo de la aplicación no tiene sentido sin un buen software de reconocimiento de imágenes que permita reconocer los elementos capturados por el usuario. Este software es proporcionado por la librería Open Source Computer Vision Library (OpenCV)(VerA.1) que como se verá más adelante ofrece diferentes posibilidades.
Además de la aplicación móvil, se presentará la aplicación web de mantenimiento de la base de datos adicional para poder realizar las operaciones sobre las tablas de información de la cuál hará uso la aplicación móvil. Mediante dicha aplicación se per- mitirá al usuario realizar las operaciones básicas de mantenimiento de los recursos de información y de las preguntas de la sección de consultas frecuentes además de poder consultar la información contenida en la aplicación para verificar su correcteza. De esta manera se ofrece a los administradores de contenidos poder realizar actualizaciones del conjunto de datos de una manera sencilla y segura.
C
APÍTULO2
D ESARROLLO DEL PROYECTO
2.1 Requisitos de desarrollo
Una vez presentada la idea y establecidas las bases mediante las cuáles se ha construido el proyecto, se presenta la necesidad de definir los conceptos que deberemos utilizar para entender el desarrollo del software en cuestión. Por ello, a continuación se definen los diferentes elementos necesarios para el desarrollo:
• Framework de desarrollo web(VerA.1): mediante el cuál se ha realizado el desa- rrollo de una aplicación web dinámica, adaptable y accesible.
• Librería gráfica: mediante la cuál se obtienen las diferentes funcionalidades a nivel de reconocimiento de imágenes.
• Servicio Web (SW)(VerA.1): mediante el cuál se realiza el intercambio de in- formación a través de peticiones entre la aplicación móvil y la aplicación de mantenimiento, y el propio servicio. De esta manera podemos acceder a toda la información alojada en la base de datos de manera segura y totalmente transpa- rente.
• Sistema de Gestión de Bases de Datos (SGBD)(VerA.1): mediante el cuál reali- zamos toda la gestión operativa de la base de datos, tanto a nivel de almacena- miento como a nivel de mantenimiento.
• Sistema Operativo (SO) del dispositivo móvil(VerA.1): necesario para desarro- llar una aplicación móvil ajustándose a las necesidades del proyecto.
No obstante, los elementos expuestos anteriormente han sido usados para más de un propósito y aplicación. Por ello, surge la necesidad de presentar la visión general del proyecto para entender el alcance del mismo.
Figura 2.1: Estructura general del proyecto.
Como se puede observar en la figura2.1, el proyecto está compuesto por dos sub- proyectos. El primero de ellos relacionado con el desarrollo de la base de datos, el servicio web asociado y la aplicación web de mantenimiento de la base de datos. Por otra parte, en el segundo, aparece el desarrollo de la aplicación móvil junto a la in- tegración con las librerías gráficas que permiten acceder a las funcionalidades de reconocimiento de imágenes.
Por ello, deberemos tener claro que el desarrollo del proyecto, tendrá dos vías para- lelas las cuáles al final están destinadas a integrarse para poder realizar una operativa conjunta como una unidad.
2.2. Metodología de desarrollo
2.2 Metodología de desarrollo
Antes de iniciar la explicación detallada del proyecto propiamente dicho, se presenta la necesidad de definir la metodología de desarrollo utilizada para llevar a cabo el proyec- to. Debido a que en el desarrollo sólo ha participado el autor del presente documento, se ha utilizado una metodología ágil cercana a una ya existente, llamada Scrum. Esto es, se han aplicado los puntos más beneficiosos para este tipo de proyecto, descartando otros que no eran necesarios.
El motivo principal de la elección de dicha metodología ágil, como referencia, es su facilidad de ajuste a las necesidades del proyecto donde se ha realizado un desarrollo de forma iterativa e incremental que permita una descomposición en tareas del proyecto.
Si bien es cierto, que en este proyecto los requisitos no son cambiantes por lo cuál no tendremos un impacto significativo en cuanto a cambios en la estructura del mismo.
2.2.1 Stakeholders
El primer paso a realizar en todo proyecto está relacionado con la determinación de las personas que intervienen en el desarrollo directa e indirectamente. Es por ello que en la figura2.2aparecen los principales interesados:
Figura 2.2: Interesados del proyecto.
De la figura anterior, tenemos los siguientes interesados:
• Administrador de contenidos: encargado del mantenimiento de la información, desde la aplicación web, disponible en ambos tipos de aplicación.
• Administrador del sistema: encargado del mantenimiento de las aplicaciones, tanto web como Android, y bases de datos que tratan el flujo de información.
• Asistente: persona que utilizará la aplicación Android en un evento indefinido para consultar el catálogo mediante la captura de imágenes.
2.2.2 Requisitos de la aplicación
Otro de los pasos importantes a realizar en todo proyecto es el relacionado con la obtención de requisitos. Debemos tener en cuenta que los requisitos presentados se corresponden a los de tipo usuario y aunque estos presenten las características a alto nivel del sistema a desarrollar permiten ofrecer una perspectiva más que suficiente para ilustrar el alcance del mismo.
• RU1: El asistente tiene que poder reconocer objetos mediante la cámara.
• RU2: El asistente tiene que poder acceder al módulo de información de la aplica- ción.
• RU3: El asistente tiene que poder acceder al módulo de preguntas de la aplica- ción.
• RU4: El administrador de contenidos tiene que poder gestionar los módulos de información y preguntas desde la aplicación web.
Nota: el término gestión se corresponde a las operaciones de consulta, inserción, actualización y eliminación de recursos de información y/o preguntas.
2.2.3 Backlog
Para un desarrollo estructurado, es necesario definir el conjunto de tareas a realizar que permita obtener una perspectiva completa del alcance del proyecto y poder realizar una planificación adecuada del mismo.
Por ello, definiremos las diferentes tareas por módulos, mediante los cuáles iden- tificar de forma sencilla lo que se debe desarrollar. No obstante, se ha realizado una distinción entre diseño, generación (entendido como la generación del código co- rrespondiente) y integración de cada uno de los módulos. De esta manera podemos asegurar que el diseño de cada uno de los módulos ha sido llevado a cabo con criterio y analizado previamente para evitar posibles desviaciones en un futuro.
Cabe destacar, que en la estructuración de tareas tendremos una diferenciación entre las que esta directamente relacionadas con la aplicación web y las que están rela- cionadas con la aplicación Android. Sin embargo, existen algunas no están en ninguno de los dos grupos mencionados ya que se corresponden con la base y tratamiento de la información.
En el cuadro2.1, se presenta el conjunto de tareas que componen el desarrollo completo del proyecto para satisfacer las funcionalidades previstas.
2.2. Metodología de desarrollo
Identificador Descripción
T1 Diseño de la base de datos T2 Diseño del servicio web T3 Generación de la base de datos T4 Generación del servicio web
T5 Integración del servicio web con la base de datos T6 Diseño de las páginas informativas del proyecto de
la aplicación web
T7 Diseño de la página de acceso de la aplicación web T8 Diseño de las páginas de consulta de los módulos de
información/preguntas
T9 Diseño de la página de mantenimiento de los módulos de información/preguntas
T10 Generación de las páginas informativas del proyecto de la aplicación web
T11 Generación de la página de acceso de la aplicación web T12 Generación de las páginas de consulta de los módulos
de información/preguntas
T13 Generación de la página de mantenimiento de los módulos de información/preguntas
T14 Diseño de las tareas de pantalla de inicio y menú de la aplicación Android
T15 Diseño de las tareas de consulta de catálogo de información y recurso específico
T16 Diseño de las tareas de consulta de preguntas más frecuentes y recurso específico
T17 Diseño de la tarea de reconocimiento de objetos mediante cámara
T18 Diseño de comunicación con el servicio web T19 Diseño de descarga de los recursos
T20 Generación de las tareas de pantalla de inicio y menú de la aplicación Android
T21 Generación de las tareas de consulta de catálogo y recurso específico
T22 Generación de las tareas de consulta de preguntas más frecuentes y recurso específico
T23 Generación de la tarea de reconocimiento de objetos mediante cámara
T24 Generación de comunicación con el servicio web T25 Generación de descarga de los recursos
T26 Integración de la librería OpenCV en la tarea de reconocimiento de objetos mediante cámara
Cuadro 2.1: Backlog de tareas del proyecto.
En el siguiente cuadro, se presenta la estimación temporal de las tareas definidas en el cuadro2.1, para su posterior distribución por iteraciones.
Identificador Duración (h)
T1 0.5
T2 0.5
T3 2
T4 2
T5 4
T6 1
T7 1
T8 2
T9 3
T10 2
T11 2
T12 3
T13 10
T14 2
T15 2
T16 1
T17 4
T18 2
T19 2
T20 2
T21 6
T22 4
T23 8
T24 4
T25 2.5
T26 5
Total 77.5
Cuadro 2.2: Estimación temporal de las tareas del proyecto.
En la figura2.3, podemos observar la distribución temporal que siguen cada una de las tareas. Las tareasT13, T23, T21, T26son aquellas cuyo impacto ha sido mayor en el proyecto en cuanto a tiempo, por lo que son aquellas sobre las que se ha puesto especial atención ya que son las que fundamentan las ideas clave del proyecto.
2.2. Metodología de desarrollo
Figura 2.3: Comparativa del alcance de tareas por horas.
No obstante, en la figura2.4, aparece la proporción de horas que son necesarias para llevar a cabo las tareas del tipo: Diseño, Generación y Integración.
Figura 2.4: Comparativa entre los diferentes tipos de tareas.
Como se puede apreciar, las tareas de generación son las que han tenido un mayor coste en el proyecto, seguido por la parte de diseño.
2.2.4 Iteraciones
Una vez definido el backlog con su correspondiente conjunto de tareas para llevar a cabo el proyecto, es necesario realizar una planificación de la ejecución de las mismas.
Para ello, se ha establecido un límite superior aproximado de 5 horas para cada una de las iteraciones. Como podemos observar, existen tareas que tienen un alcance superior al límite, por ello, han sido fraccionadas y tratadas en dos iteraciones consecutivas.
Teniendo en cuenta el tiempo total de desarrollo, estimado en unas 77.5h, se han reali- zado un total de 15 iteraciones.
Mediante la estimación temporal que se ha presentado en el cuadro2.2para cada una de las tareas definidas en el backlog, deberemos realizar una distribución coherente de las tareas en función de la relación existente entre las mismas y la adecuación tem- poral sobre el límite definido. A continuación se presenta la planificación de desarollo por iteraciones:
Identificador Tarea/s
IT1 T1, T2, T3, T4
IT2 T5, T6
IT3 T7, T10, T11
IT4 T8, T12
IT5 T9, T13
IT6 T13
IT7 T13, T14
IT8 T20, T15, T16
IT9 T21
IT10 T21, T17
IT11 T22, T23
IT12 T23, T18
IT13 T18, T24
IT14 T19, T25
IT15 T26
Cuadro 2.3: Distribución por iteraciones de las tareas del proyecto.
Nota: Las tareas repetidas representan un desarrollo parcial de la misma compren- dida entre las diferentes iteraciones en las cuáles aparece.
2.3. Elección del sistema operativo de desarrollo
2.3 Elección del sistema operativo de desarrollo
Para el desarrollo de dicho proyecto se han tenido en cuenta diferentes posibilidades existentes a día de hoy en el sector de los dispositivos móviles a la hora de realizar el desarrollo de dicha aplicación.
Figura 2.5: Distribución de ventas por sistema operativo para cada trimestre del año.
En la Figura2.5se puede apreciar que los dos sistemas operativos móviles con más demanda son Android y iOS respectivamente. Por ello, estos fueron los dos sistemas principales a tener en cuenta.
Debido al gran impacto que tienen en el mercado y la estandarización de sus pro- ductos en la sociedad actual se han escogido los dos sistemas operativos previamente comentados para posteriormente debatir en cuál de ellos era adecuado realizar el desa- rrollo.
Una vez expuestos los sistemas sobre los cuáles se pretendía desarrollar se requiere un cierto debate para determinar en cuál de ellos es más adecuado desarrollar la aplicación, se presentan a las siguientes conclusiones:
1. Desarrollo en Android:
a) Es un sistema que basa su desarrollo en un lenguaje orientado a objetos lo cuál facilita la distribución de los componentes de la aplicación.
b) Los conocimientos necesarios son de carácter más general por lo que se precisa de menos formación.
c) La utilización implicita del Modelo-Vista-Controlador (MVC) hace que la aplicación tenga bien diferenciadas la parte correspondiente a la Graphical User Interface (GUI) respecto a la parte de datos y control de la misma.
d) Posee de una plataforma de desarrollo de propia además de ser multiplata- forma (Microsoft Windows, macOS, GNU/Linux).
2. Desarrollo en iOS:
a) Es también un sistema que basa su desarrollo en un lenguaje orientado a objetos.
b) Los conocimientos necesarios son de carácter más específico debido a que los productos Apple están diseñados sobre un entorno más cerrado por lo cuál se precisa de formación complementaria.
c) También tiene como patrón de diseño más común el Modelo-Vista-Controlador (MVC) aunque no lo implementa de base como estructura general del pro- yecto de desarrollo.
d) Posee de una plataforma de desarrollo propia aunque existen varias alter- nativas como Adobe Flex, si bien es cierto que presentan un uso complejo y no abarcan un uso completo donde se pueda extraer todo el rendimiento que ofrece iOS. Existe la posibilidad de utilizar software multiplataforma aunque debido al carácter del proyecto no era aconsejable.
A través de las razones expuestas anteriormente, se eligió como plataforma de desarrollo Android ya que, a grandes rasgos, es la que ofrecía mayor flexibilidad y facilidad para el desarrollo de una aplicación con los requisitos y necesidades de los que disponíamos al inicio del proyecto.
2.4. Herramientas de desarrollo
2.4 Herramientas de desarrollo
Para la realización del proyecto se han utilizado diferentes herramientas las cuáles nos han permitido generar el contenido requerido a diferentes niveles. Los niveles sobre los cuáles se ha trabajado durante el desarrollo son los siguientes:
• Web service.
• Base de datos.
• Aplicación Android.
• Aplicación web.
2.4.1 Netbeans 8.2
La herramienta Netbeans es un entorno de desarrollo muy completo principalmente orientado para el lenguaje de programación Java. Se ha elegido dicha herramienta debido a su gratuito acceso además de ser una herramienta ya conocida.[4]
Figura 2.6: Logo de Netbeans IDE.
Netbeans nos permitirá cubrir un conjunto extenso de las diferentes necesidades que se nos presentan. Entre ellas destacan las siguientes:
• Creación y mantenimiento de un servicio web.
• Generación de páginas web.
• Acceso y mantenimiento de la base de datos.
2.4.2 XAMPP 5.6.30
XAMPP es un paquete software que contiene un conjunto de herramientas bastante extenso entre ellas, dos de las cuáles necesitamos, un Sistema de Gestión de Bases de Datos (SGBD) de tipo My Structured Query Language (MySQL) y un servidor web Apache.[5]
Figura 2.7: Logo de XAMPP
Por ello, de las dos herramientas comentadas anteriormente, se derivan las siguien- tes funcionalidades requeridas:
• Creación de una base de datos.
• Operaciones de inserción, consulta, eliminación y modificación sobre la base de datos.
• Montaje de un servidor web de ámbito local.
2.4.3 Android Studio 2.3.2
Android Studio es la herramienta certificada por Google para el desarrollo de aplicacio- nes para dispositivos Android. Dicha herramienta proporciona todo tipo de funcionali- dades desde depuración, pasando por análisis rendimiento, hasta la compilación de la aplicación.[6]
Figura 2.8: Logo de Android Studio
De Android Studio se derivan las siguientes funcionalidades:
2.4. Herramientas de desarrollo 2.4.4 Bootstrap
Bootstrap es un framework de código abierto para el diseño de sitios y aplicaciones web. Contiene plantillas de diseño con la tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como, extensiones de JavaScript.[7]
Figura 2.9: Logo de Bootstrap De Bootstrap se derivan los siguientes beneficios:
• El diseño gráfico se ajusta dinámicamente en función de las características del dispositivo.
• Contribuye a la accesibilidad de la aplicación web.
• Reduce los tiempos de desarollo y integración.
2.4.5 GlassFish
GlassFish es un servidor de aplicaciones de software libre que implementa las tecnolo- gías definidas en la plataforma Java EE. [8,32]
Figura 2.10: Logo de GlassFish De GlassFish se deriva el siguiente beneficio:
• Permite que las aplicaciones sean portables y puedan ser utilizadas en más de un servidor independientemente del fabricante.
2.5 Almacenamiento de datos
Por lo que respecta al almacenamiento de la información debemos tener en cuenta dos aspectos fundamentales en el desarrollo:
1. Base de datos de carácter general
• Contiene toda la información de carácter general de la aplicación, es de- cir, aquella información que necesite estar centralizada para los diferentes recursos disponibles. Esto es en última instancia la aplicación web de ma- netenimiento y la aplicación Android.
Figura 2.11: Representación conceptual de la base de datos de carácter general.
2. Base de datos específica de la aplicación
• Contiene únicamente la información necesaria para llevar las tareas conte- nidas en la aplicación, desde consultas de recursos de información hasta el apartado Frequently Asked Questions (FAQ).
2.6. Acceso a la información
2.6 Acceso a la información
Una vez definidas las estructuras de datos necesarias para el almacenamiento de la información requerida en nuestro proyecto, se presenta la necesidad de definir la forma en la que se accede a dicha información.
Para ello, se utilizará una tecnología más que conocida en este tipo de aplicaciones, como es elWeb Service o Servicio Web. Esta tecnología nos permite realizar cualquier tipo de operación sobre los datos disponibles en la base de datos teniendo en cuenta que dichas operaciones se procesarán mediante peticiones de acuerdo a los protocolos y estándares web.
Figura 2.12: Diagrama de secuencia del acceso a la información.
En la figura2.12se nos presenta el diagrama de secuencia para el acceso a la información contenida en la base de datos donde a grandes rasgos tenemos la siguiente secuenciación:
1. El usuario accede a la información mediante la Graphical User Interface (GUI), definido en el diagrama comollamadaAcceso().
2. La Graphical User Interface (GUI) procesa la interacción del usuario y envía una petición de acceso al servicio web, definido en el diagrama comoaccesoWS().
3. Una vez el servicio web recibe la petición de acceso y esta es procesada, este envía una solicitud de acceso a la información contenida en la base de datos, definido en el diagrama comosolicitud().
4. La base de datos recibe una petición (alta, baja o modificación) y la procesa generando unos resultados, definido en el diagrama comorespuesta().
5. El servicio web una vez recibidos los datos, manda una petición alNormalizador con los datos recibidos para preparar el protocolo eXtensible Markup Language (XML), definido en el diagrama comonormalizaResultado().
6. El normalizador procesa la respuesta obtenida por parte del servicio web y la transforma a un lenguaje común como es eXtensible Markup Language (XML) para posteriormente enviar la respuesta al usuario, definido en el diagrama como resultadoNormalizado().
La secuenciación anterior es idéntica para ambas aplicaciones, es decir, para la aplicación web de mantenimiento y la aplicación Android puesto que en ambos casos se accede mediante protocolo Simple Object Access Protocol (SOAP) y se utiliza un protocolo eXtensible Markup Language (XML) para el intercambio de datos entre el Servicio web y el recurso.[25]
2.7. Mantenimiento de la información
2.7 Mantenimiento de la información
Como en la mayoría de proyectos, se presenta la necesidad de tener una aplicación que permita realizar el mantenimiento de una forma accesible, sencilla e intuitiva. Es por ello que se ha decidido desarrollar unaWeb App o aplicación webque permita realizar dichas tareas.
Cabe destacar que la realización de una aplicación de estas características permite que esta sea accesible desde un amplio abanico de dispositivos lo cuál aporta gran fle- xibilidad en cuanto al acceso se refiere. Dicha aplicación, a grandes rasgos contiene dos módulos claramente diferenciales en el ámbito del mantenimiento de la información como aparece en la figura2.13.
Figura 2.13: Módulos de mantenimiento de la base de datos.
Para cada uno de los módulos definidos se permite la realización de las siguientes operaciones:
• Inserción de nuevos registros de información/pregunta.
• Eliminación por índice de un registro de información/pregunta.
• Modificación por índice de un registro de información/pregunta.
• Consulta por índice de un registro de información/pregunta.
2.8 Diseño de la aplicación web
2.8.1 Distribución de las páginas de la aplicación web
La necesidad de una aplicación web de mantenimiento de la información ya ha sido discutida anteriormente y por ello debemos tener en cuenta cuál es el diseño que tiene la aplicación que realiza dicha gestión.
Figura 2.14: Diagrama de paginación de la aplicación web.
2.8. Diseño de la aplicación web
Como se puede apreciar en la figura2.14, la aplicación presenta la siguiente estruc- tura:
• Index: proporciona el acceso principal a la aplicación web.
• Login: proporciona el acceso al apartadoHomede la aplicación mediante una identificación de usuario y contraseña. Además, incluye la posibilidad de crear una cuenta de usuario para posibilitar el acceso.
• Home: contiene recursos referidos al proyecto de carácter informativo.
• Information: contiene una tabla con los recursos disponibles para la aplicación Android con la información representada en la figura2.11.
• Questions: contiene una tabla con la información de las preguntas representada en la figura2.11para la sección de ayuda de la aplicación web y Android.
• Maintenance: contiene los respectivos formularios para realizar el mantenimien- to de información/pregunta.
• Help: contiene toda la información de ayuda de la aplicación web.
2.8.2 Navegación de la aplicación web
Para facilitar la comprensión de uso de la aplicación al completo, a continuación, se presenta el diagrama de flujo el cuál permitirá entender cuáles son las acciones que se pueden realizar a través de la aplicación web y cuáles son sus consecuencias.
2.8. Diseño de la aplicación web
De la figura2.15, hay que destacar tres puntos clave en la gestión de las operaciones:
• Registro: en caso de que la operación de registro se lleve a cabo de manera satisfactoria o no se retornará al usuario a la página deLogindonde aparecerá una notificación que indique al usuario la situación de su petición.
• Login: en caso de que la operación se acceso a la aplicación se lleve a cabo de forma satisfactoria se enviará al usuario a la páginaHome. En caso contrario, el usuario permanecerá en la pagina deLogincon la notificación pertinente.
• Mantenimiento: en caso de que cualquiera de las operaciones de mantenimiento se lleven a cabo de manera exitosa o no, el usuario permanecerá en la página deMaintenance. Para cada caso, se notificará al usuario si la operación que este quería llevar a cabo se ha realizado correctamente.
Además, mediante la figura anterior, se representan todas las conexiones y vías de acceso a cada una de las páginas que componen la aplicación web.
2.9 Diseño de la aplicación Android
A la hora de hablar del diseño de la aplicación Android deberemos tener en cuenta que la metodología de desarrollo para este tipo de sistemas está muy definida por lo que el diseño de la aplicación tendrá una estructura Modelo-Vista-Controlador (MVC) como se ha comentado anteriormente.
En la figura2.16, se presenta el diagrama de secuencia de la aplicación mediante el cuál permite entender cuáles son las acciones que se pueden realizar sobre la aplicación y cuáles son las tareas que se ejecutan como consecuencia.
Figura 2.16: Diagrama de flujo de la aplicación Android.
2.9. Diseño de la aplicación Android
De la figura expuesta anteriormente, se pueden diferenciar dos puntos clave:
• Carga / Descarga de información: en caso de que la operación de obtención de información se lleve a cabo correctamente se enviará al usuario a la pantalla del menú de la aplicación.En caso contrario, la aplicación se cerrará notificando al usuario la imposibilidad de acceso a la información necesaria para ejecutar la aplicación correctamente. Por otra parte, si la información ya ha sido descargada previamente, se enviará al usuario a la pantalla de menú con la notificación correspondiente.
• Reconocimiento de objeto: en caso de que la operación de reconocimiento de objetos encuentre alguna similitud con alguno de los objetos contenidos en la aplicación enviará al usuario a una pantalla donde tendrá toda la información relacionada con el objeto reconocido. En caso contrario, la aplicación seguirá intentando reconocer objetos.
2.10 Elección del algoritmo de reconocimiento
Para la elección del algoritmo de reconocimiento contenido en Open Source Computer Vision Library (OpenCV) se han tenido en cuenta diferentes opciones, entre ellas:
• Brisk
• ORB
• SIFT
• SURF
De los algoritmos anteriores, los dos últimos son los más actuales y eficientes a día de hoy, aunque para tener acceso a los módulos que permiten el uso de ambos hay que adquirir una licencia y, por tanto, son de pago por lo que para nuestro desarrollo han sido descartados. Si bien es cierto, que en un ámbito profesional sería lógico hacerse con dichas licencias pues permiten realizar los reconocimientos de forma mas rápida, con mayor flexibilidad y con menor coste computacional. [9]
Por ello, los dos primeros han sido los usados para las respectivas pruebas que se han realizado durante el desarrollo. El primero de ellos, Brisk, ha sido el que se ha utilizado en el proyecto final debido a que este ofrecía mejores resultados a la hora de reconocer imágenes con diferentes tonalidades y de diferente procedencia además de la inclinación de la misma respecto al algoritmo ORB. No obstante, debemos destacar que dicha estabilidad y eficacia viene marcada por una contra, y es que el algoritmo es algo más lento y necesita un mayor tiempo de carga, aunque en este caso se ha preferido asegurar la eficacia de los resultados. [10]
Para ilustrar la comparativa entre los diferentes algoritmos expuestos anteriormen- te, y algunos que no han sido expuestos, en la figura2.17se presenta una gráfica que contrasta el porcentaje de acierto en el reconocimiento en función de la rotación en grados:
2.10. Elección del algoritmo de reconocimiento
Figura 2.17: Comparativa de los algoritmos de reconocimiento en función de la rotación en grados.
2.11 Reconocimiento de objetos
Uno de los puntos más interesantes de dicho proyecto es en el cuál se realiza la com- paración de la imagen que captura el usuario mediante la cámara de su dispositivo móvil con la imagen contenida en la aplicación. No obstante, dicha comparación puede realizarse de dos maneras totalmente diferentes:
• Comparación total: es aquella en la cuál se compara la imagen obtenida con cada una de las imágenes de cada uno de los recursos de información contenidos en la aplicación.
• Comparación única: es aquella en la cuál se compara la imagen obtenida con una única imagen que contiene todas las imágenes de cada uno de los recursos.
De estas dos posibles soluciones, se ha optado por la implementación de la segunda, puesto que en términos de eficiencia es mejor. Por ello, la comparación única permite realizar una única comparación en cada instante de tiempo. No obstante, mediante el algoritmoBriskimplementado en las librerías Open Source Computer Vision Li- brary (OpenCV) podemos obtener los puntos coincidentes entre la imagenFuentey la imagenDestinolo cuál nos permitirá determinar a que recurso específico corresponde.
Para entender de que manera se realiza dicho proceso de reconocimiento es ne- cesario detallar de que manera se construye dicha imagen única. En la figura2.18, aparece la representación gráfica de la imagen conjunto en forma de matriz cuadrada de dimensiónp
n×p
n, donde n es el número de imágenes, donde cada celda con- tiene la imagen correspondiente a cada uno de los recursos contenidos en la aplicación.
2.11. Reconocimiento de objetos
Como se puede observar en la figura anterior, están representados, mediante un conjunto de líneas, los puntos de reconocimiento sobre la imagen conjunto y la imagen de la cámara. A partir de cada uno de los puntos reconocidos en la matriz conjunto, podemos saber cuál es la imagen con mayor número de puntos coincidentes y entonces acceder al recurso en correspondiente. Nótese que para el caso de la figura2.18la celda que contiene un mayor número de puntos coincidentes con la imagen de la cámara es la número 1. Entonces, a partir de ese índice se puede realizar una consulta a la base de datos de la aplicación para que proporcione toda la información referente al recurso mediante el identificador obtenido. Además, el tamaño de las imágenes debe ser el mismo para poder realizar una identificación uniforme sobre los recursos disponibles.
De esta manera, podemos tener toda la información centralizada en un punto, en este caso la matriz de imágenes, además de realizar el reconocimiento de una manera más eficiente. Es necesario destacar que durante el proceso de reconocimiento, pueden existir lo que se conocen comooutliers o valores atípicos, los cuáles representan puntos coincidentes que realmente no lo son. Para el ejemplo expuesto en la figura existen dos outliers: uno de ellos en la celda número 4 y el otro en la celda número 8.
No obstante, una de las cualidades que presenta dicho software de reconocimiento de imágenes es que este es independiente del grado de inclinación o ángulo de la imagen obtenida lo cuál aporta una gran flexibilidad al usuario y amplía el rango de condiciones en las que la aplicación puede ser utilizada.
Sin embargo, en la figura2.19se presenta la distribución de rendimiento en función del número de imágenes que componen la matriz. Hay que destacar que los resultados ofrecidos son sobre un Samsung Galaxy S4, por lo que seguramente en un terminal con especificaciones más actuales podría obtenerse un mayor rendimiento con una matriz de imágenes de dimensión mayor.
Figura 2.19: Distribución del rendimiento del reconocimiento.
Como podemos observar en el gráfico anterior, tenemos la distribución temporal que existe en función del número de imágenes que compone la matriz. En primer lugar, destacar que los resultados que ofrece el algoritmo a medida la matriz tiene un tamaño mayor son bastante bueno, si tenemos en cuenta que en las pruebas realizadas, con 10 imágenes diferentes, para cada tamaño ofrece unos resultados de un 100 % de efectividad, donde para el caso de 100 imágenes, únicamente fallo 1 de las 10 pruebas realizadas. Si bien es cierto, que el tiempo que necesita para procesar el reconocimiento va aumentando de forma exponencial a medida que se utilizan más imágenes, pues el tamaño de la matriz va creciendo, llegando a una imagen de tamaño 2000x2000 píxeles para el caso de 100 imágenes.
Cabe destacar, que estos resultados se han obtenido formando la matriz con imáge- nes ajustadas a un tamaño de 200x200 píxeles, por lo que mediante una variación de este parámetro seguramente se podrían obtener resultados mejores. No obstante, si se tuviera la necesidad de almacenar un número considerable de imágenes, la matriz diseñada perderia eficiencia hasta el punto de no funcionar por no hablar del tiempo que se necesitaria para realizar el reconocimiento. Por ello, una posible solución a dicho problema, sería realizar un conjunto de matrices donde estubiera repartido el conjunto de imágenes, entonces la búsqueda del objeto a reconocer debería realizarse en cada una de las matrices para el peor de los casos aumentando así el tiempo final de reconocimiento en función del número de matrices procesadas.
C
APÍTULO3
R ESULTADOS
3.1 Aplicación Web
La aplicación web permite realizar las tareas de mantenimiento de la base de datos que contiene los recursos de información a los cuáles accederá la aplicación mediante un servicio web.
Dicha aplicación web como ya se ha visto en la figura2.14consta de diferentes páginas aunque las más destacables son: información, preguntas y mantenimiento.
3.1.1 Información
Dicha página muestra los recursos de información que podrán ser accedidos desde la aplicación Android. De esta manera, se puede ver si la información de un recurso específico está correctamente, tal como el nombre, la descripción la imagen asociada incluso hasta la geoposición (si tuviera).
Figura 3.1: Aspecto visual de la página de los recursos de información.
Como se puede observar en la figura3.1, los recursos de información están conte- nidos en una tabla a la cuál se le pueden aplicar ordenaciones de tipo ascendente y descendente para cada una de las columnas de la misma. Además, esta contiene un campo de búsqueda para realizar consultas sobre cualquier campo indistintamente.
Este tipo de ayudas son realmente útiles cuando existen miles de recursos y se necesita realizar una búsqueda sobre uno específico aportando flexibilidad al usuario.
No obstante, cabe destacar que dicha tabla viene paginada de manera que se per- mite al usuario determinar el número de recursos por página que desee.
3.1.2 Preguntas
Dicha página muestra las diferentes preguntas frecuentes que pueden darse en el uso de ambas aplicaciones, tanto la web como Android. Esta contiene una tabla donde se pueden consultar las preguntas y cada una de las respuestas además de su destino, es decir, si son para la aplicación web o Android.
3.1. Aplicación Web
Figura 3.2: Aspecto visual de la página de preguntas.
En la figura3.2, se puede observar como a la tabla, al igual que la vista en el apartado 3.1.1, se le pueden aplicar ordenaciones a cada una de las columnas además de contener un filtro general para realizar búsquedas de manera sencilla. En este caso, se puede observar que la paginación utilizada es de 10 preguntas por página.
3.1.3 Mantenimiento
En esta página están definidas las diferentes operaciones de mantenimiento que se pueden realizar para cada uno de los recursos tanto de información como las preguntas de ayuda. Entonces, las operaciones de mantenimiento disponibles desde dicha página son las siguientes:
• Inserción
• Modificación
• Eliminación
No obstante, a continuación se detallarán las peculiaridades de cada una de ellas.
Inserción información
En este punto se pretende mostrar el formulario que permite introducir nuevos recursos de información a la base de datos donde dicha inserción está dividida en tres pasos:
• Información básica
• Asociación de imagen
• Geoposición
Figura 3.3: Aspecto visual del formulario de inserción de información (Paso 1).
En la figura3.3, se puede observar el primer paso donde se precisa el nombre del recurso y la descripción asociada al mismo.
Figura 3.4: Aspecto visual del formulario de inserción de información (Paso 2).
En la figura3.4, se puede observar el segundo paso donde se pide al usuario que asigne una imagen a dicho recurso para poder realizar el reconocimiento desde la aplicación Android.
3.1. Aplicación Web
En la figura3.5, se puede observar el tercer y último paso donde se precisa de una geoposición en caso de ser necesario. Dicha geoposición deberá ser proporcionada en formato de latitud y longitud.
Cabe destacar que dicho formulario permite la navegación entre los diferentes pasos en caso de ser necesaria la modificación de alguno de ellos.
Modificación de información
Por lo que respecta a la modificación de información se presenta el siguiente formulario con los mismos campos que se han presentado en el apartado anterior.
El funcionamiento de este es simple, el usuario deberá proporcionar el identificador del recurso que desee modificar. Entonces presionando la teclaEnter, la información del elemento en cuestión será cargada en cada uno de los campos correspondientes para que el usuario pueda realizar la modificaciones pertinentes.
En la figura3.6, se puede observar el aspecto del formulario con la información del registro número 1.
Figura 3.6: Aspecto visual del formulario de modificación o eliminación de información.
Una vez finalizado, el usuario deberá presionar el botónUpdatepara llevar a cabo la acción. De forma análoga con la inserción, todos los campos obligatorios deberán estar rellenados correctamente, donde en caso contrario, se notificará al usuario de ello como se explicará más adelante en la figura3.11.
Eliminación de información
De forma análoga con la modificación, el usuario deberá realizar los mismos pasos, con la única diferencia de que para realizar la eliminación del recurso de información pertinente deberá presionar el botónDelete
Inserción de preguntas
Como en el caso de la inserción de recursos de información, para las preguntas dis- pondremos de un formulario con los campos necesarios aunque en este caso todos
agrupados en un mismo paso, como se puede apreciar en la figura3.7.
Figura 3.7: Aspecto visual del formulario de inserción de preguntas.
Modificación de preguntas
En cuanto a la modificación de preguntas se refiere, también sigue el mismo patrón visto anteriormente, donde en primer lugar, se deberá proporcionar el identificador de la pregunta que se desee modificar donde posteriormente se deberá presionar la te- claEnterpara cargar la información asociada en cada uno de los campos del formulario.
Una vez modificados los campos pertinentes, el usuario deberá presionar el botón Updatepara actualizar los datos de dicho registro.
En la figura3.8, aparece dicho formulario con la pregunta con identificador número 1 cargada como ejemplo.
Figura 3.8: Aspecto visual del formulario de modificación o eliminación de preguntas.
Eliminación de preguntas
Nuevamente, de forma análoga a la modificación de preguntas, el usuario deberá realizar los mismos pasos donde al final del proceso deberá presionar el botónDelete para eliminar el registro como se puede apreciar en la figura3.8.
3.1. Aplicación Web
correctamente o bien que no ha podido completarse debido a la falta de información.
Por una parte tenemos que si la operación se ha completado de manera satisfactoria, el usuario recibirá la notificación que aparece en la figura3.9.
Figura 3.9: Aspecto visual de la notificación de operación completada.
No obstante, en caso de que la operación, por problemas ajenos a la interacción del usuario, no pudiese llevarse a cabo correctamente, la aplicación notificará al usuario de que la operación no ha quedado registrada en la base de datos, como se puede apreciar en la figura3.10.
Figura 3.10: Aspecto visual de la notificación de operación fallida.
Además, es necesario destacar que en caso de existir alguno de los campos obliga- torios vacíos, la aplicación notificará al usuario de este hecho como se puede apreciar en la figura3.11.
Figura 3.11: Aspecto visual de la notificación de campos vacíos.
3.2. Aplicación Android
3.2 Aplicación Android
La aplicación Android, como ya se ha comentado anteriormente, a grandes rasgos, es la que permite realizar mediante el uso de la cámara del dispositivo móvil el reconoci- miento de objetos asociandolos a un recurso de información.
Dicha aplicación como ya se ha expuesto anteriormente en la figura2.16, presenta una serie de tareas que permiten el funcionamiento completo de la aplicación. A continuación se presenta el funcionamiento completo de la aplicación.
3.2.1 Pantalla principal
En primer lugar, tenemos la carga de los datos en la pantalla inicial donde nos aparecerá una pequeña notificación donde se indica que los datos están siendo obtenidos, como aparece en la figura3.12.
Figura 3.12: Aspecto visual de la carga de datos de la aplicación Android.
En caso de que la aplicación ya disponga de los datos, se omitirá la pantalla ante- riormente mostrada.
3.2.2 Menu
Una vez cargados los datos, accederemos al menú que nos permite realizar una serie de tareas como se puede observar en la figura3.13.
Figura 3.13: Aspecto visual del menú principal de la aplicación Android.
Como se puede observar, en dicho menú tenemos diferentes opciones las cuáles se resumen a continuación:
• Search: permite el acceso a la cámara del dispositivo para realizar el reconoci- miento de objetos mediante Open Source Computer Vision Library (OpenCV).
• Magazine: permite el acceso a la información de todos los recursos que pueden ser reconocidos por la aplicación.
• Help: permite el acceso a apartado Frequently Asked Questions (FAQ) donde aparecerán las consultas más frecuentes.
• About us: contiene información sobre el autor de la aplicación.
3.2. Aplicación Android
Figura 3.14: Aspecto visual de la tarea de reconocimiento de objetos de la aplicación Android.
3.2.4 Catálogo de información
Por lo que respecta aMagazine, en esta tarea se presentan los recursos de información, como aparece representado en la figura3.15mediante su nombre y la imagen asociada al recurso en cuestión.
Figura 3.15: Aspecto visual del catálogo de información de la aplicación Android.
3.2.5 Información en detalle
Una vez el usuario accede a un recurso específico, se envía al usuario a una nueva tarea donde se muestra información más detallada del recurso (figura3.16) y en caso
de contener geoposición se muestra su localización exacta mediante un mapa (figura 3.17).
Figura 3.16: Aspecto visual de la información detallada de un recurso de la aplicación Android.
3.2. Aplicación Android 3.2.6 Preguntas frecuentes
Por otra parte, tenemos también la sección de Frequently Asked Questions (FAQ) donde hay contenida la lista de preguntas como aparece en la figura3.18.
Figura 3.18: Aspecto visual listado de preguntas de la aplicación Android.
3.2.7 Pregunta en detalle
Cuando el usuario selecciona la pregunta en cuestión aparece la información asociada a la misma como aparece en la figura3.19.
Figura 3.19: Aspecto visual de la información de la pregunta de la aplicación Android.
C
APÍTULO4
C ONCLUSIONES
Una vez definido el problema y expuestos los resultados obtenidos durante el desarrollo del proyecto, entonces, se derivan diferentes conclusiones que permiten entender la finalidad de la aplicación final y los beneficios que esta reporta.
Como ya habíamos comentado en un inicio, la aplicación es capaz de funcionar de manera local gracias a la implementación del algoritmo de reconocimiento Brisk, que nos ofrece Open Source Computer Vision Library (OpenCV), en la misma aplicación por lo que no existe ningún tipo de comunicación con un servidor externo que procese la petición de reconocimiento. Esto ofrece unos resultados aceptables puesto que se han eliminado los tiempos de espera por comunicación. Sin embargo, se tienen otras ventajas como la disminución de uso de datos del teléfono a la hora de hacer uso de la misma, pues cada vez que se ejecuta la aplicación comprueba si existen nuevas versiones de datos, por lo que sólo se descargan los datos una única vez ofreciendo la posibilidad de usar la aplicación sin conexión. De esta manera, se cubre la posible pro- blemática de perdidas momentáneas de conexión que impidan el uso de la aplicación.
Además, dicho reconocimiento se realiza mediante tracking, por lo que el usuario únicamente deberá enfocar el objeto del cuál quiera obtener información, por lo que se eliminan los pasos de realizar la foto en primer lugar, y el de aceptación de la imagen para ser finalmente procesada, ofreciendo mayor comodidad al usuario y versatilidad en su uso.
No obstante, el diseño utilizado para la aplicación Android, permite que dicho reconocimiento se realice de manera totalmente independiente a la posición GPS, por lo que la aplicación desarrollada puede ser utilizada también en terminales que no disponen de esta tecnología. Este enfoque, nos reporta dos ventajas muy importantes, donde en primer lugar, ofrece un mayor espectro de ámbitos de uso posibles ya que si dicha aplicación quiere usarse en espacios cerrados, no sería funcional utilizar la geo-posición para la detección de elementos. Y en segundo lugar, el descarte de uso del
geo-localizador del dispositivo móvil permite que nuestra aplicación sea mucho más eficiente en términos energéticos ya que se usan menos recursos del mismo.
En cuanto al tratamiento que se realiza para la búsqueda de los elementos en una base de datos mediante el reconocimiento de objetos, esta puede realizarse de manera sencilla y rápida mediante la infraestructura diseñada en el apartado2.5. Se ha mos- trado como la aplicación Android hace uso de una base de datos de tipo SQLite que permite una mayor consistencia de los datos manejados entre aplicaciones ofreciendo a su vez una mejor estructuración. Cabe destacar que los datos podrían haber sido guardados en un simple fichero en el formato de entrada ofrecido por el protocolo Simple Object Access Protocol (SOAP), es decir, en formato eXtensible Markup Langua- ge (XML), pero de esta manera se posibilita que la aplicación ofrezca mejores tiempos de respuesta en el caso de que existiera una cantidad considerable de recursos de información.
Por otra parte, se tiene la estructura de procesamiento sobre el reconocimiento, que como se ha expuesto anteriormente se realiza sobre una matriz que contiene todas las imágenes relacionadas con cada uno de los recursos contenidos en la base de datos.
Es necesario destacar, que la construcción de la matriz se realiza en orden según el identificador de los recursos de información contenidos en la base de datos. En dicha matriz, se tienen cada uno de los puntos coincidentes que ha detectado el algoritmo y de esta manera se realiza un conteo sobre cada una de las celdas, que corresponde con una imagen limitada por las dimensiones especificadas anteriormente, y de esta manera se obtiene el numero de celda con más coincidencias que a la postre, dicho numero de celda, sirve para realizar la búsqueda en la base de datos por el identificador del recurso, que recordemos que están ordenados.
Sin embargo, las solución propuesta, ofrece unos resultados razonables, como se ha comentado en el apartado2.11, aunque hay que destacar que para grandes volúmenes de información la técnica propuesta quedaría incompleta. Por lo que una posible solu- ción para futuras actualizaciones del proyecto, sería realizar dicho reconocimiento en paralelo, de manera que repartieran las imágenes asociadas a cada uno de los recursos de información en diferentes matrices. Entonces, a la hora de realizar la búsqueda se debería realizar la búsqueda en cada una de las matrices por lo que supondría un mayor coste computacional, aunque aquí entraría en juego la posibilidad de adquirir los módulos que permiten el acceso a los algoritmos más actuales y por lo tanto más rápidos y eficientes. De esta manera, se podría reducir el impacto de dicho incremento en el coste de cómputo ofreciendo resultados similares a los obtenidos con una única matriz y con uno de los algoritmos más lentos.
Por lo que se refiere al aspecto personal, la realización de este proyecto ha supuesto una oportunidad de experimentar con el desarrollo de las aplicaciones para dispositi- vos móviles, más concretamente para Android, de las cuáles he podido ver la cantidad de alternativas que existen para realizar una misma acción. No obstante, considero que la estructuración que propone Android para el desarrollo de aplicaciones está muy bien pensado desde el punto en que se separa la lógica de la interfaz del programa, lo cuál, en mi opinión, es un punto a favor. Sin embargo, me gustaría destacar que el Android nativo, proporciona muchos recursos visuales, como las vistas de listas, o las vistas en forma cuadriculada, aunque si bien es cierto, que si se precisan de cosas más específicas se requiere cierta elaboración que puede llegar a resultar un tanto tediosa.
He podido descubrir un mundo como es el reconocimiento de imágenes, y una de las librerías más importantes a día de hoy como es Open Source Computer Vision Library (OpenCV), y la cantidad de aplicaciones que se le puede dar, como es el recono- cimiento de rasgos humanos (expresiones faciales, huellas dactilares, entre otras), por ejemplo. Por ello, actualmente existen cada vez mas aplicaciones que utilizan dicha tecnología para conseguir propósitos de diferente naturaleza gracias al potencial que esta ofrece.
Además, he visto como he podido poner en práctica los conocimientos que he podido adquirir a lo largo del grado y de que manera pueden ayudar a la creación de proyectos en cualquier tipo de entorno o lenguaje que se precise, sin la necesidad de tener conocimientos previos del mismo.
A
PÉNDICEA
A NEXO
A.1 Definiciones
En este apartado se presentan las diferentes definiciones de términos y conceptos utili- zados a lo largo del documento y, por tanto, necesarios para un correcto entendimiento del propósito del proyecto.
A continuación, aparecen detalladas las diferentes definiciones:
• Framework web: es un conjunto estandarizado de conceptos, prácticas y crite- rios diseñado para apoyar el desarrollo de sitios web dinámicos, aplicaciones web y servicios web.[45]
• Graphical User Interface (GUI): representa la parte visible de una aplicación que utiliza un conjunto de imágenes y objetos gráficos para representar la infor- mación y acciones disponibles a realizar.[38]
• Open Source Computer Vision Library (OpenCV): es una biblioteca libre de vi- sión artificial multiplataforma la cuál contiene más de 500 funciones que abarcan una gran espectro de áreas en el proceso de visión a diferentes niveles: recono- cimiento de objeto (incluido el facial), calibración de cámaras, visión estérea y visión robótica.[44]
• Modelo-Vista-Controlador (MVC): se considera un patrón de arquitectura soft- ware mediante la cual se realiza una separación de los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones.[39]
• Sistema Operativo (SO): es un conjunto de programas de bajo nivel que permite la abstracción de las peculiaridades del hardware específico de los diferentes dis- positivos móviles, además, provee servicios a las aplicaciones móviles ejecutadas sobre el mismo.[48]
• Simple Object Access Protocol (SOAP): es un protocolo estándar que define como dos objetos situados en procesos diferentes pueden comunicarse mediante un intercambio de datos en eXtensible Markup Language (XML).[40]
• Servicio Web (SW): es una tecnología que utiliza un conjunto de protocolos y estándares que sivern para intercambiar datos entre diferentes aplicaciones.[46]
• Sistema de Gestión de Bases de Datos (SGBD): es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas que permiten añadir, eliminar, modificar y analizar los datos contenidos en la misma.[47]
• Tracking: proceso de captura continua de imágenes, que permite realizar un procesamiento sobre cada una de ellas de forma directa.
• Smartphones o teléfonos inteligentes: es un tipo de teléfono móvil construido sobre una plataforma informática móvil con una mayor capacidad de almacena- miento de datos y ejecución de procesos.[37]
• eXtensible Markup Language (XML): es un meta-lenguaje que permite definir lenguajes de marcas desarrolado por el World Wide Web Consorcium (W3C) utilizado para almacenar datos en un formato legible.[41]
• World Wide Web Consorcium (W3C): es un consorcio internacional que genera recomendaciones y estándares que aseguran el crecimiento de la World Wide Web (WWW) a largo plazo.[42]
• World Wide Web (WWW): es un sistema de distribución de documentos de hi- pertexto o hipermedios interconectados y accesibles vía Intenet. [43]
B IBLIOGRAFÍA
[1] Developer.vuforia.com. (2017) Vuforia developer portal. [Fecha de acceso 25 Mayo 2017]. [Online]. Available:https://developer.vuforia.com1.2
[2] A. H. Nigel Davies. (2005) Understanding the role of image recognition in mobile tour guides. [Fecha de acceso 25 Mayo 2017]. [Online]. Availa- ble:https://www.researchgate.net/publication/221270459_Understanding_the_
role_of_image_recognition_in_mobile_tour_guides1.2
[3] us.playstation.com. (2017) Aplicación ar play, juegos de realidad aumentada para PlayStation®Vita - PlayStation®. [Fecha de acceso 25 Mayo 2017]. [Online].
Available:http://latam.playstation.com/psvita/apps/psvita-app-ar.html1.2 [4] Netbeans.org. (2017) Welcome to Netbeans. [Fecha de acceso 25 Mayo 2017].
[Online]. Available:https://netbeans.org2.4.1
[5] Apachefriends.org. (2017) Xampp Installers and Downloads for Apache Friends.
[Fecha de acceso 25 Mayo 2017]. [Online]. Available:https://www.apachefriends.
org/es/index.html2.4.2
[6] Developer.android.com. (2017) Como descargar Android Studio y SDK Tools.
[Fecha de acceso 25 Mayo 2017]. [Online]. Available:https://developer.android.
com/studio/index.html?hl=es-4192.4.3
[7] Wikipedia. (2017) Bootstrap (framework). [Fecha de acceso 25 Mayo 2017].
[Online]. Available:https://es.wikipedia.org/wiki/Bootstrap_(framework)2.4.4 [8] Javaee.github.io. (2017) Glassfish. [Fecha de acceso 25 Mayo 2017]. [Online].
Available:https://javaee.github.io/glassfish/2.4.5
[9] Docs.opencv.org. (2017) Feature Detection and Description - OpenCV 3.0.0-dev documentation. [Fecha de acceso 25 Mayo 2017]. [Online].
Available: http://docs.opencv.org/3.0-beta/modules/features2d/doc/feature_
detection_and_description.html2.10
[10] ——. (2017) Opencv: cv::BRISK Class Reference. [Fecha de acceso 25 Mayo 2017].
[Online]. Available:http://docs.opencv.org/trunk/de/dbf/classcv_1_1BRISK.html 2.10
[11] A. Developers. (2017) Primeros pasos | Android Developers. [Fecha de acceso 25 Mayo 2017]. [Online]. Available:https://developer.android.com/training/index.
html?hl=es