Story Transcript
FACULTAD DE INGENIERÍA Y CIENCIAS AGROPECUARIAS
DESARROLLO DE INTERFAZ DE REALIDAD AUMENTADA PARA LOCALIZACIÓN DE PUNTOS DE INTERÉS DE UN CAMPUS UNIVERSITARIO
Trabajo de Titulación presentado en conformidad con los requisitos establecidos para optar por el título de Ingeniero Electrónico y Redes de la Información.
Profesor Guía Ing. Eduardo Mauricio Campaña Ortega
Autor Israel Francisco Torres Vinueza
Año 2016
ii
DECLARACIÓN DEL PROFESOR GUÍA
“Declaro haber dirigido este trabajo a través de reuniones periódicas con el estudiante, orientando sus conocimientos para un adecuado desarrollo del tema escogido, y dando cumplimiento a todas las disposiciones vigentes que regulan los Trabajos de Titulación.”
_________________
Eduardo Mauricio Campaña Ortega Ingeniero de Sistemas C.I.:1208856701
iii
DECLARACIÓN DE AUTORÍA DEL ESTUDIANTE
“Declaro que este trabajo es original, de mi autoría, que se han citado las fuentes correspondientes y que en su ejecución se respetaron las disposiciones legales que protegen los derechos de autor vigentes”.
________________
Israel Francisco Torres Vinueza C.I.: 1004017388
iv
AGRADECIMIENTOS A mi padre, madre y hermanos que desde un inicio han estado a lado mío orientándome a ser un buen hombre y a ser un buen profesional. Gracias por hacer esto posible. A mi tutor el Ing. Mauricio Campaña que me brindo sus conocimientos y cuya participación ha enriquecido el trabajo realizado. A la fuerza de ventas y a la gente que conforma
la
Empresa
Hewlett
Packard
Enterprise por brindarme la oportunidad de crecer en base a sus guías, consejos y experiencias.
v
DEDICATORIA A la memoria de mi abuela, a mis tías Esperanza, Silvia y a mi tío Guido que son y serán siempre mis símbolos de carácter, dedicación, humildad y amor.
vi
RESUMEN La realidad aumentada es un término (Rauterberg, 2012) acuñado por el investigador Thomas Caudell en 1990 dentro de las instalaciones de Boeing que es la empresa más importante de aeronáutica en el mundo donde él y su colega David Mizzell diseñaron una alternativa a los diagramas y dispositivos de señalización que utilizaban los obreros en las instalaciones con sofisticados dispositivos del tipo “Gafas” donde se combinan elementos virtuales con los físicos proporcionando una realidad diferente y útil. En la actualidad cada persona lleva un dispositivo inteligente, este dispositivo inteligente puede llevar una cámara, este dispositivo también puede procesar aplicaciones muy complejas que pueden ser muy útiles como lo es la localización de un destino partiendo de un punto a otro. Sin embargo se lleva a este dispositivo a un entorno poblado como lo es una institución universitaria nacen necesidades que de una u otra manera se puede satisfacer. Interrogantes tales como: “¿Dónde está el curso?”, “¿Dónde está la oficina del coordinador?”,” ¿Dónde consulto el estado de mi matricula?” que afectan no solo a los estudiantes sino también a los docentes e invitados relacionados a la institución. Si se trata de solucionar este problema con la señalética común de una institución se tardaría mucho tiempo en seguir de un punto a otro. Sin embargo con la realidad aumentada puede situar en un solo punto y visualizar los puntos de interés acortando distancias. Aplicaciones que tienen esta tecnología han sido utilizadas con propósitos publicitarios como la aplicación Aurasma que se ha convertido en una herramienta de desarrollo y en un almacén de campañas publicitarias para importantes compañías que quieren anunciar de una forma diferente en revistas. Herramientas como Metaio han podido desarrollar aplicaciones de realidad aumentada enfocada en la publicidad de manera que pueden ayudar a compañías como Audi o Ikea a presentar sus catálogos de sus productos. Otra categoría que se tiene en este tipo de aplicaciones es de geolocalización donde las aplicaciones más destacables son Wikitude y Layar que a su vez se comportan como tiendas de aplicaciones donde uno puede ver la integración de
vii
redes como Wikipedia, Twitter e Instagram en forma geográfica como por ejemplo las fotos fueron subidas en cierta distancia de donde se solicita la información del usuario. Otras categorías pueden ser la educación como Anatomy 4D donde se puede visualizar la anatomía humana, Sky Map de Google aplicación para ver los astros más representativos.
viii
ABSTRACT Augmented reality is a term coined by researcher Thomas Caudell in 1990 within the facilities of Boeing which is the largest aerospace company in the world where he and his colleague David Mizzell designed an alternative to the diagrams and signaling devices used by workers on site with sophisticated devices such as "Glasses" where virtual elements are combined with physical providing a different and helpful reality. Today every person carries an intelligent device, this smart device can carry a camera, and this device can also process complex applications that can be very useful as it is the location of a destination from a point to another. However it takes this device to a populated enviroment as it is a university environment born needs that one way or another can be satisfied. Questions such as: “Where the course”, “Where is the coordinator's office”, “Where do I check the status of my enrollment” that affect not only students but also teachers and guests related to the institution. If we try to solve this problem with common signage of an institution we could take a long time to go from one point to another. But with augmented reality we can put ourselves at a single point and viewing points of interests catching up. Applications that have this technology have been used for advertising purposes as Aurasma application that has become a development tool and a store advertising campaigns for major companies that want to advertise in magazines a different way. Tools like Metaio been able to develop augmented reality applications focused on advertising so they can help companies like Audi or Ikea to present their catalogs of its products. Another category that has this type of applications is geolocation where the most outstanding applications are Wikitude and Layar which in turn behave as app stores where one can see the integration of networks, such as Wikipedia, Twitter and Instagram in a geographical way as for example the pictures were uploaded in some distance from where the user information is requested. Other categories may be education as 4D Anatomy where you can visualize human anatomy, Google Sky Map application to view the most representative star.
ÍNDICE
1.
Introducción ................................................................ 1
1.1. Título del proyecto ................................................................ 1 1.2. Situación actual .................................................................... 1 1.3. Objetivo general .................................................................... 2 1.4. Objetivos específicos ............................................................ 2
2.
Marco Teórico ............................................................. 3
2.1. Levantamiento de información .............................................. 3 2.1.1 A quién se dirige el proyecto ............................................................. 3 2.1.2 Obtención de requerimientos ............................................................ 3
2.2. Metodología a usarse ........................................................... 3 2.2.1 metodología de desarrollo de software. ............................................ 3 2.2.2 Recolección de datos sobre los puntos de interés ............................ 8 2.2.3 Creación de un aplicativo móvil para la visualización de puntos de interés. ....................................................................................................... 8 2.2.4 Creación de una página web que permita almacenar y administrar la información que va a ser utilizada por el aplicativo móvil. ...................... 8 2.2.5 Pruebas de software iniciales que se enfocarán en determinar en términos muy básicos la funcionalidad de la aplicación móvil. ................ 9 2.2.6 Pruebas de rendimiento que se enfocaran en determinar en términos avanzados la funcionalidad de la aplicación móvil y el servicio web. ........................................................................................................... 9
2.3. Características del software .................................................. 9 2.3.1 Definiciones Previas ......................................................................... 9
2.4. Diagrama de componentes ................................................. 25 2.5. Diagrama de despliegue ..................................................... 27 2.6. Product backlog .................................................................. 28
2.7. Primer sprint planning ......................................................... 30 2.7.1 Primer sprint página web ................................................................ 30 2.7.2 Primer sprint sistema móvil ............................................................. 31
3.
Diseño ........................................................................ 32
3.1. Especificación de requerimientos ....................................... 32 3.1.1 Requisitos funcionales .................................................................... 33 3.1.2 Requisitos no funcionales ............................................................... 33
3.2. Introducción sistema web ................................................... 34 3.2.1 Propósito sistema web .................................................................... 34 3.2.2 Definiciones, acrónimos y abreviaturas del sistema web ................ 34 3.2.3 Identificación de roles y tareas del sistema web ............................. 34 3.2.4 Casos de uso por actor para el sistema web .................................. 35 3.2.5 Diagrama de secuencia por actor para el sistema web .................. 40 3.2.6 Especificaciones de diagrama de clases por actor para el sistema web .......................................................................................................... 44 3.2.6 Diagrama EER de la base de datos del sistema web ..................... 45
3.3. Introducción sistema móvil .................................................. 46 3.3.1 Propósito sistema móvil .................................................................. 46 3.3.2 Definiciones, acrónimos y abreviaturas del sistema móvil .............. 46 3.3.3 Identificación de roles y tareas del sistema móvil ........................... 47 3.3.4 Casos de uso por actor para el sistema móvil ................................ 49 3.3.5 Diagrama de secuencia por actor para el sistema móvil................. 53 3.3.6 Diagrama de clases para el sistema móvil ...................................... 56
4.
Desarrollo y Pruebas ................................................. 57
4.1. Implementación y pruebas de la aplicación web ................ 57 4.1.2 Visual Studio Community 2015 ....................................................... 57 4.1.3 Lenguaje de programacion C# ........................................................ 60 4.1.4 Instalación de la base de datos MySQL Community Server ........... 64 4.1.5 Construcción del sistema web en Visual Studio ............................. 66 4.1.6 Pruebas del sistema web ............................................................... 69
4.1.7 Pruebas del sistema móvil ............................................................. 82
5. Conclusiones y Recomendaciones ............................... 92 5.1 Conclusiones ....................................................................... 92 5.2 Recomendaciones ............................................................... 93
REFERENCIAS ................................................................. 94
ÍNDICE DE TABLAS Tabla 1. Cuota de mercado de sistemas operativos móviles ............................. 9 Tabla 2. Características de ubicación y los sistemas operativos soportados ... 10 Tabla 3. Resultados análisis de parámetros para elección de sdk ................... 11 Tabla 4. Listado de los sdk de ar en el mercado .............................................. 17 Tabla 5. Análisis de los sdk de realidad aumentada para el proyecto .............. 18 Tabla 6. Ficha del caso de uso 1 del usuario ................................................... 36 Tabla 7. Ficha del caso de uso 2 del usuario ................................................... 37 Tabla 8. Ficha del caso de uso 3 del usuario ................................................... 37 Tabla 9. Ficha del caso de uso 4 del usuario ................................................... 38 Tabla 10. Ficha del caso de uso 1 del sistema web ......................................... 39 Tabla 11. Ficha del caso de uso 2 del sistema web ......................................... 39 Tabla 12. Ficha del caso de uso 3 del sistema web ......................................... 39 Tabla 13. Ficha del caso de uso 1 del usuario ................................................. 50 Tabla 14. Ficha del caso de uso 2 del usuario ................................................. 50 Tabla 15. Ficha del caso de uso 3 del usuario ................................................. 51 Tabla 16. Ficha del caso de uso 1 de la interfaz del usuario ............................ 52 Tabla 17. Ficha del caso de uso 2 de la interfaz del usuario ............................ 52 Tabla 18. Ficha del caso de uso 2 de la interfaz del usuario ............................ 53 Tabla 19. Ficha comparativa de las ofertas de visual studio 2015 ................... 58 Tabla 20. Resultado de la prueba de velocidad de carga de página principal 71 Tabla 21. Resultado de la prueba de velocidad de carga del servicio web ...... 71 Tabla 22. Resultado de la prueba 1 de benchmarking ..................................... 81 Tabla 23. Resultado de la prueba 2 de benchmarking ..................................... 81 Tabla 24. Prueba comparativa de realidad aumentada en 1 minuto ................ 87 Tabla 25. Prueba comparativa de realidad aumentada en 15 minutos ............ 87
ÍNDICE DE FIGURAS Figura 1. Diagrama de funcionamiento de la solución ........................................ 2 Figura 2. Scrum logo .......................................................................................... 4 Figura 3. Proceso scrum .................................................................................... 4 Figura 4. Interfaz vivify scrum............................................................................. 7 Figura 5. Interfaz ibm rational modeler rhapsody 7.5 ......................................... 7 Figura 6. Arquitectura android .......................................................................... 12 Figura 7. Arquitectura de sistemas de realidad aumentada ............................. 13 Figura 8. Prueba del sdk de geolocalización look! ........................................... 15 Figura 9. Realidad aumentada basada en marcadores .................................... 15 Figura 10. Pruebas de realidad aumentada basada en nft rapid ...................... 16 Figura 11. Pruebas de rastreo 3d earthmine .................................................... 16 Figura 12. Pruebas de rastreo slam ................................................................. 17 Figura 13. Lentes inteligentes google glass ..................................................... 18 Figura 14. Prueba de la aplicación wikitude world browser .............................. 19 Figura 15. Arquitectura de wikitude sdk 5 ........................................................ 20 Figura 16. Arquitectura de .net framework ....................................................... 22 Figura 17. Cuadrante mágico de gartner de sistemas de administración de base de datos operacionales del 2015 ...................................................... 23 Figura 18. Arquitectura de mysql ...................................................................... 25 Figura 19. Diagrama de componentes página web .......................................... 26 Figura 20. Diagrama de componentes aplicativo móvil .................................... 27 Figura 21. Diagrama de despliegue página web .............................................. 27 Figura 22. Diagrama de despliegue aplicativo móvil ........................................ 28 Figura 23. Product backlog en vivifyscrum ....................................................... 29 Figura 24. Iconos de cada item vivifyscrum ..................................................... 30 Figura 25. Sprint 1 sistema web vivifyscrum .................................................... 31 Figura 26. Sprint 1 sistema móvil vivifyscrum................................................... 32 Figura 27. Actores sistema web ....................................................................... 35 Figura 28. Casos de uso del usuario del sistema web ..................................... 36 Figura 29. Casos de uso del interfaz del sistema web ..................................... 38 Figura 30. Diagrama de secuencia caso 1 usuario .......................................... 40
Figura 31. Diagrama de secuencia caso 2 usuario .......................................... 41 Figura 32. Diagrama de secuencia caso 3 usuario .......................................... 41 Figura 33. Diagrama de secuencia caso 4 usuario .......................................... 42 Figura 34. Diagrama de secuencia caso 1 interfaz de usuario ......................... 42 Figura 35. Diagrama de secuencia caso 2 interfaz de usuario ......................... 43 Figura 36. Diagrama de secuencia caso 2 interfaz de usuario ......................... 43 Figura 37. Diagrama de clases del sistema web .............................................. 44 Figura 38. Diagrama err de la base de datos del sistema web......................... 45 Figura 39. Actores sistema móvil ..................................................................... 48 Figura 40. Casos de uso del usuario del sistema móvil ................................... 49 Figura 41. Casos de uso del interfaz del usuario ............................................. 51 Figura 42. Casos de uso 1 del usuario ............................................................. 53 Figura 43. Casos de uso 2 del usuario ............................................................. 54 Figura 44. Casos de uso 3 del usuario ............................................................. 54 Figura 45. Casos de uso 1 del interfaz del usuario .......................................... 55 Figura 46. Casos de uso 2 del interfaz del usuario .......................................... 55 Figura 47. Casos de uso 3 del interfaz del usuario .......................................... 56 Figura 48. Diagrama de clases del sistema web .............................................. 57 Figura 49. Opciones de instalación de visual studio 2015 community ............. 59 Figura 50. Interfaz de visual studio community 2015 ....................................... 60 Figura 51. Menú de referencias del proyecto ................................................... 63 Figura 52. Tabla “poi” mysql serializada en formato json ................................. 64 Figura 53. Tabla de datos integrada en la página. ........................................... 68 Figura 54. Mapa integrado en la página. .......................................................... 68 Figura 55. Diagrama de actividades de prueba de rendimiento ágil................. 69 Figura 56. Diseño del sistema de la herramienta webpagetest.org .................. 73 Figura 57. Raspberry pi model b+ .................................................................... 74 Figura 58. Topología de conexión de pruebas con el servidor web raspberry pi model b+ ................................................................................................ 75 Figura 59. Topología implementada de conexión de pruebas con el servidor web raspberry pi model b+ ...................................................................... 75 Figura 60. Logo empresa weaved .................................................................... 76
Figura 61. Topología de conexión de pruebas con raspberry pi model b+ y el servicio weaved. ........................................................................................ 77 Figura 62. Resultado pagespeed página login ................................................. 78 Figura 63. Resultado pagespeed página pois.asmx......................................... 79 Figura 64. Prueba con gamebench presentación de la aplicación ................... 85 Figura 65. Prueba con gamebench realidad aumentada con 4 pois ................ 85 Figura 66. Prueba con gamebench realidad aumentada con carga de 60 pois 86 Figura 67. Prueba en ambiente cubierto .......................................................... 88 Figura 68. Prueba en ambiente semi abierto.................................................... 88 Figura 69. Prueba en ambiente abierto ............................................................ 89 Figura 70. Recolección de datos gps ............................................................... 89
1
1. INTRODUCCIÓN La realidad aumentada es una tecnología que puede utilizarse para varios propósitos como es la publicidad, el entretenimiento y la geo localización rama en la que se enfocara el proyecto. La geo localización tiene como propósito informar al usuario sobre las coordenadas geográficas de su dispositivo con funcionalidades de GPS o internet móvil. Las herramientas de geo localización y realidad aumentada permiten situar puntos geográficos virtuales y señalizarlos visualmente con una capa sobre la interfaz de una cámara digital. Los puntos geográficos virtuales se dibujan en la interfaz dependiendo de la localización del dispositivo físico. Si la cámara del dispositivo señala a una área en específico y si en esta área esta un punto geográfico virtual, la pantalla mostrara en la interfaz de la cámara con un símbolo gráfico. Los puntos geográficos virtuales pueden ser asignados a lugares que sean de interés para un grupo de personas que frecuentan estos lugares a diario. Al enfocar esta tecnología a un lugar educativo puede ser de ayuda dado que brindaría información sobre a donde la gente que estudia, trabaja o visita pueda dirigirse. 1.1. Título del proyecto “Desarrollo de Interfaz de realidad aumentada para localización de puntos de interés de un campus universitario” 1.2. Situación actual El reciente y futuro crecimiento que tienen las instituciones universitarias (El Universo, 2014) (Ortiz, 2015) públicas o privadas de la ciudad Quito obliga que las mismas inviertan en señalización de sus locaciones y enfocando en una inquietud general del alumnado sobre donde se encuentra las locaciones más concurrentes ya sean sus propias aulas donde van a tener clases como la oficina del coordinador y la secretaria académica, etc. Como adicional esta aplicación ayudara a la universidad a actualizar los datos del número de bloques o infraestructuras evitando que el alumnado se confunda cuando existan cambios repentinos.
2
En este proyecto se tomara como caso de estudio a la Universidad de Las Américas para el proceso de recolección de información y para la ejecución de pruebas. 1.3. Objetivo general Desarrollar una aplicación móvil con la tecnología de realidad aumentada para localizar puntos de interés de un establecimiento universitario. 1.4. Objetivos específicos
Realizar un aplicativo móvil basado en el sistema operativo de Google Android en la cual se va usar herramientas de desarrollo especializadas en geo localización, diseño y realidad aumentada.
Analizar herramientas destinadas al desarrollo de las aplicaciones de realidad aumentada.
Realizar un sitio web que esté conectado a una base de datos y que permita almacenar los datos de los puntos de interés en este caso información de la sede en términos de distancia entre sede y el usuario, información de centros de atención y servicios de la universidad.
Tomando en cuenta el último objetivo específico podemos diagramar el funcionamiento de la solución como se muestra en la Figura 1:
Figura 1. Diagrama de funcionamiento de la solución
Implementar la solución y ejecutar pruebas funcionales necesarias.
3
1. MARCO TEÓRICO 2.1. Levantamiento de información 2.1.1 A quién se dirige el proyecto Este proyecto de titulación va dirigido a los estudiantes, funcionarios y personas relacionadas a la Universidad de las Américas de Quito que como infraestructura sigue en crecimiento por la constante demanda de plazas de estudio. El principal objetivo es brindar al usuario la manera de guiarse por las instalaciones de una manera diferente haciendo uso de la tecnología.
Se menciona que va dirigido también a funcionarios de la universidad dado que en este proyecto va ejecutar pruebas y se registraran resultados que pueden ser útiles al implementar la tecnología de la realidad aumentada.
2.1.2 Obtención de requerimientos La obtención de requerimientos permite que los sistemas de software ya sea la plataforma móvil como la plataforma web tengan las funciones necesarias para satisfacer las necesidades del usuario. Esto lleva a realizar entrevistas a personas relacionadas al diario vivir de la institución académica y también a las personas que manejan los sistemas informáticos la misma.
2.2. Metodología a usarse En este proyecto se utilizaran metodologías experimentales (Ramirez, 2004, p. 5) las cuales permitirán generar eventos cuando se lo requiera y repetir pruebas con condiciones variables.
2.2.1 Metodología de desarrollo de software. En este proyecto va estar conformado por dos sistemas de software de las cuales van utilizar una metodología acorde al propósito del proyecto que en este caso es una aplicación móvil y web. Para este tipo de aplicaciones se necesitara una metodología ágil como Scrum.
4
2.2.1.1 Metodología Scrum. La definición de Scrum (Figura 2.) según la guía Scrum Guide (Schwaber & Sutherland, 2013, p. 3) dice: “Es un framework en el que la gente puede hacer frente a los problemas adaptativos complejos, mientras que productiva y creativamente entrega productos de un valor muy alto.”
Figura 2. Scrum logo Tomado de metodologiascrum.readthedocs.org, 2015
Scrum es una metodología que es fácil de entender y tiene elementos claros (Figura 3.) que permiten perfeccionar el desarrollo de una solución:
Figura 3. Proceso Scrum Tomado de Prijic, 2014
Equipo Scrum:
Jefe de producto.- Responsable de defender los mejores intereses del producto.
5
Equipo de desarrollo.- Grupo de profesionales encargados de minimizar y cumplir eficientemente los trabajos que se presenten en cada iteración.
Scrum Master.- Responsable de que todo el equipo entienda la metodología Scrum.
Eventos Scrum
“Sprint” o Iteraciones.- Es un periodo de tiempo donde se desarrolla el proyecto y se tiene como resultado un proyecto usable en su totalidad dependiendo de los objetivos que se haya definido en la planificación inicial del “Sprint”. Después de que se haya completado un Sprint se empieza con otro.
Planificación del “Sprint”.- Es un plan creado por el equipo Scrum y el Scrum Master tiene el rol de enseñar al equipo el mantenerse en los tiempos fijados. La planificación permite responder las preguntas: “¿Qué puede ser entregado en el resultado o incremento del próximo Sprint?” y “¿Cómo va ser el trabajo necesario para alcanzar la entrega del resultado o incremento?”.
Daily Scrum.- Evento de quince minutos donde se actualiza actividades con el equipo.
Sprint review.- Evento que sucede al final de cada Sprint con el objetivo inspeccionar el resultado y en base a eso se puede actualizar la lista de necesidades.
Sprint retrospective.- Evento donde el equipo tiene la oportunidad de inspeccionarse y crear un plan para mejoras para el próximo Sprint. Por lo general dura 3 horas en el caso de Sprints de un mes.
6
Artefactos Scrum
Product Backlog.- Es la lista dinámica donde se registra las necesidades que tiene el cliente o el equipo. Es considerada como la única fuente para cualquier cambio en el producto. El responsable de llevar y administrar la lista es el Product Owner.
Monitoreo del progreso.- En cualquier momento el trabajo restante para lograr la meta puede ser sumado con el fin de manejar el progreso. Esto lo maneja el Product Owner en cada Sprint Review.
Sprint Backlog.- Listado que se clasifico del Product Backlog y que va ser destinado a las acciones del Sprint actual. Este listado nace como un plan del equipo de desarrollo con el objetivo de tener una flexibilidad al momento de pronosticar como completar un Sprint.
Monitoreo del Sprint.- El trabajo restante de cada Sprint Backlog puede ser sumado con el objetivo de administrar el progreso. Esto lo maneja el equipo de desarrollo en cada Daily Scrum.
Incrementos.- Es la suma de todos los ítems del Product Backlog completados en
el Sprint y el valor
de los incrementos de los
anteriores Sprints.
Herramientas Agiles
VivifyScrum.- Herramienta web (Figura 4.) destinada la organización de proyectos con metodología Scrum. Cuenta con los artefactos Scrum más importantes que permiten tener la facilidad de contar con el servicio gratuito por la característica de ser basado en la nube.
7
Figura 4. Interfaz Vivify Scrum Tomado de Vivify Scrum, s.f.
IBM Rational Modeler Rhapsody 7.5.- Herramienta gratuita (Figura 5.) desarrollada por IBM basada en el diseño UML que permite al usuario documentar y visualizar su sistema, arquitectura y diseño de software usando lenguaje grafico estándar (IBM Corporation, 2015).
Figura 5. Interfaz IBM Rational Modeler Rhapsody 7.5
Antes de continuar con la metodología principal para este proyecto se especifica las metodologías experimentales que sus resultados formaran parte del Product Backlog:
8
2.2.2 Recolección de datos sobre los puntos de interés Se registrará información como nombre, descripción, distancia dependiendo de los requerimientos que solicite las herramientas de geolocalización. Además se realizará encuestas a la gente que frecuenta los establecimientos con el fin de filtrar los puntos importantes y a su vez los más visitados. 2.2.3 Creación de un aplicativo móvil para la visualización de puntos de interés. Se desarrollará el aplicativo en un kit de desarrollo de software “SDK” en específico tomando los siguientes parámetros que afectaran al proyecto:
SDK del sistema operativo móvil con la mayor cantidad de cuota de mercado. Parámetro que permitirá tener una mayor cantidad de usuarios en nuestro aplicativo.
SDK que permita el uso de interfaces de programación de aplicaciones “API” públicas y privadas con características de localización. Parámetro que permitirá el acceso a bibliotecas que van a ser usadas para acceder a servicios de geolocalización o mapas.
SDK de código abierto. Parámetro que permitirá un mayor control sobre la aplicación y sobre todo un gran material informativo a nuestra disposición de manera gratuita.
2.2.4 Creación de una página web que permita almacenar y administrar la información que va a ser utilizada por el aplicativo móvil. Se desarrollara la plataforma considerando los siguientes parámetros:
Plataforma que se tenga un mayor soporte en aplicaciones móviles.
Plataforma con mayor cantidad de controles para administración de base de datos.
Plataforma con capacidad de tener múltiples hilos de ejecución.
9
2.2.5 Pruebas de software iniciales que se enfocarán en determinar en términos muy básicos la funcionalidad de la aplicación móvil. La aplicación se someterá a pruebas iniciales y reiterativas de funcionabilidad que serán evaluadas por un grupo de personas con conocimiento técnico en base a métricas proporcionadas que permitirán identificar fallas críticas. 2.2.6 Pruebas
de rendimiento que se enfocaran
en determinar en
términos avanzados la funcionalidad de la aplicación móvil y el servicio web. La aplicación y plataforma se someterán a pruebas avanzadas de funcionabilidad que serán evaluadas por herramientas en base a métricas que permitirán identificar errores o sugerencias en cada aspecto de la aplicación con el fin de aplicar solución a errores importantes o tener opinión que van a ser consideradas para futuras versiones. 2.3. Características del software 2.3.1 definiciones previas 2.3.1.1 Análisis software del dispositivo móvil Tomando en cuenta los parámetros para determinar el software o sistema operativo para el dispositivo móvil se toma en cuenta las tres plataformas más utilizadas del primer cuarto del año 2015 (Tabla 1.) Tabla 1. Cuota de mercado de sistemas operativos móviles
Tomado de IDC Research, 2015
10
Como resultado de las estadísticas que genera la consultora IDC (Chau, Ryan, & Jitesh, 2015) muestra que Android está liderando la cuota de mercado con un 78.0 %, le sigue iOS con un 18.3% y se tiene a Windows Phone con un 2.7%. Se analiza también las características que usan interfaces de programación de aplicaciones o “API” privadas y públicas para tomar datos como localización y dirección. Un “API” (Christensson, 2015) es un conjunto de comandos, funciones y protocolos el cual los desarrolladores utilizan para crear programas en un sistema operativo en específico. Tabla 2. Características de ubicación y los sistemas operativos soportados
Tomado de Bloor, 2014
En la Tabla 2 los tres principales sistemas operativos móviles cumplen con las características de ubicación que permite a las API recolectar información básica para el consumo de la aplicación. Otro parámetro importante es verificar si los principales sistemas operativos y SDK tienen código abierto. Donde Android (Google, 2015) es de código abierto, Windows (Microsoft, 2015) no es de código abierto pero llega integrarse con tecnologías de código abierto y iOS (Apple, 2015) es de código cerrado con varios proyectos de código abierto.
11
El análisis se resume en los siguientes resultados de la Tabla 3: Tabla 3. Resultados análisis de parámetros para elección de SDK
Cuota de Mercado (Q1 2015) API de ubicación Código Abierto
Android SDK
iOS SDK
78.0%
18.3%
Windows Phone SDK 2.7%
Si Si
Si No
Si No
Para este proyecto se utiliza la SDK de Android para el desarrollo del aplicativo móvil. 2.3.1.1.1 Android SDK
Un “SDK” (Christensson, 2015) es un conjunto de herramientas que sirven para el desarrollo de aplicaciones para un sistema operativo. Los componentes claves de la arquitectura (Google, 2015) del sistema operativo Android son:
Núcleo Linux: El núcleo se encarga de manejar los controladores del dispositivo como los de la cámara, pantalla y usb. Esta versión del núcleo tiene componentes dedicados al entorno móvil como los wave locks, sistemas que administran la memoria con el objetivo de preservarla.
Capa de abstracción del Hardware (HAL): Es una interfaz que permite al sistema llamar dentro de la capa de los controladores del dispositivo.
Servicios del Sistema: Los servicios están enfocados en funcionalidades y se agrupan en:
Los servicios System que tienen funciones como los gestores de notificaciones.
12
Los servicios Media que están relacionados a funcionalidades de reproducción y grabación multimedia.
Comunicación ligada entre procesos (Binder IPC, Inter-Process Comunication): Es el medio en la que las API pueden interactuar con los servicios del sistema operativo
Framework de Android: Un “framework” (Christensson P. , Framework Definition, 2015) es una plataforma en la que se desarrolla aplicaciones de software. El framework de Android provee al desarrollador acceso para utilizar clases y funciones predefinidas.
Los componentes de la arquitectura del sistema operativo Android se pueden ver en la Figura 6:
Figura 6. Arquitectura Android Tomado de Alphabet, s.f.
13
2.3.1.2 Análisis software de realidad aumentada La realidad aumentada tiene el propósito de incrementar nuestra visión con información relacionada a lo que se está viendo en el lugar adecuado. Esta tecnología ha sido utilizada de formas creativas dado que se involucra la información con la posición geo localizada, combinación que ha sido utilizada por varias redes sociales para referenciar la localización del dispositivo de una persona y el contenido que quiere compartir. La realidad aumentada abreviada como RA tiene una arquitectura que gracias al estudio (Reicher, 2003, p. 2) echo en el Instituto de ciencias de la computación de la Universidad Técnica de Múnich donde se sintetizo una arquitectura de referencia de software de RA (Figura 7.) que sirve de base.
Figura 7. Arquitectura de sistemas de realidad aumentada Tomado de Reicher, 2003, p. 2
14
Los componentes de la arquitectura del software de RA son:
Aplicación: Contiene los contenidos, la lógica del sistema y acceso a sistemas y base de datos.
Contexto: Recolecta información en contexto y los hace disponibles para sub sistemas.
Control: Relacionado al procesamiento de los comandos del usuario.
Tracking: Rastrea al usuario y a los objetos.
Presentación: Relacionado a la representación gráfica que se va a utilizar.
Modelo del Mundo: Tiene la información sobre los objetos ya sean reales o virtuales.
La herramienta que permitirá la integración de la tecnología de realidad aumentada en este proyecto se basara en los siguientes parámetros:
Herramienta que tenga integración y rastreo GPS
Este parámetro es importante dado que la tecnología GPS permite mayor precisión en ambientes externos.
Herramienta que tenga propósito de geolocalización.
En el portafolio de herramientas de realidad aumentada existen herramientas
orientadas
a
la
publicidad,
marketing
y
geolocalización es necesario que esta última sea predominante en la especialización de la herramienta.
Herramienta que tenga compatibilidad con la SDK de Google Android.
Es necesario contar con este parámetro dado que se determinó al SDK Android en el análisis del software de dispositivo móvil.
Los tipos de rastreo que tiene el software de realidad aumentada se clasifican en la siguiente lista (O'Shaughnessey, 2014):
15
Integración con GPS, brújula, giroscopio y acelerómetro. Este tipo de rastreo (Figura 8.) utiliza los módulos que manejan el GPS, brújula, giroscopio y el acelerómetro de un teléfono celular inteligente. Dentro de la programación pueden proporcionar métodos referentes a coordenadas geográficas y a la actualización del posicionamiento del dispositivo.
Figura 8. Prueba del sdk de geolocalización look! Tomado de Lookar.net, s.f.
Marcador de referencia (Dartmouth College , 2015). Utiliza una imagen de referencia que sirve para activar y producir un resultado como una imagen en 3D, 2D o un enlace web al explorador móvil. Este marcador de referencia (Figura 9.) por lo general son códigos QR que son captados por un lector como la cámara del teléfono inteligente.
Figura 9. Realidad aumentada basada en marcadores Tomado de Artificial Life, INC., s.f.
16
NFT (Neumman & You, 1999, p. 1) (Natural Feature Tracking) Mediante de robustos sistemas que están conformados por algoritmos de múltiples etapas que detectan y rastrean características naturales (Figura 10.) como filos, texturas y puntos de interés en las imágenes de video
Figura 10. Pruebas de realidad aumentada basada en nft rapid Tomado de University of Oxford, 2006
3D (Lepetit & Fua, 2005) El rastreo en 3 dimensiones a diferencia del rastreo en 2 tiene la necesidad de recuperar la posición actual en el espacio del objeto. El rastreo en 3D (Figura 11.) utiliza herramientas matemáticas como la representación de la cámara y la parametrización de colocar la cámara, adicional usa de marcadores de referencia y técnicas que están relacionadas al rastreo de características naturales NFT.
Figura 11. Pruebas de rastreo 3d Earthmine Tomado de Western Australian Land Information Authority, 2015
17
SLAM (Simultaneous Localization and Mapping for Augmented Reality) Conjunto de métodos que resuelven el problema de la estimación de la posición, la orientación y la reconstrucción 3D simultáneamente mientras el sistema está moviéndose atreves del ambiente (Reitmayr, Graz Univ. of Technol., Langlotz, Wagner, & Mulloni, 2010). En realidad aumentada este tipo de rastreo (Figura 12) carece de información de la locación geográfica.
Figura 12. Pruebas de rastreo slam Tomado de CiteSeerX, 2015
En la Tabla 4 se lista las herramientas de realidad aumentada que actualmente están en el mercado y se ha clasificado según su propósito, tipo de rastreo, plataforma, gráficas y precio de licencias. Tabla 4. Listado de los sdk de AR en el mercado
Tomado de O'Shaughnessey, 2014
18
En la Tabla 5 se realiza el análisis de las herramientas que tienen integración y rastreo con el GPS, propósito de geolocalización y que sean compatibles con Android. Tabla 5. Análisis de los sdk de realidad aumentada para el proyecto
HP Aurasma GPS Propósito Para Geolocalización Plataforma
SI Bajo (2D) iOS, Android
Metaio SDK
Wikitude SDK SI SI Medio (2D, 3D, Alto GEO, QR) (GEO,2D) iOS, Eyewear iOS, Android
Para este proyecto se utiliza la SDK de Wikitude para la integración de la realidad aumentada. 2.3.1.2.1 Wikitude SDK 5 El SDK de Wikitude tiene las siguientes características generales (Wikitude GmbH, 2015):
Compatibilidad con dispositivos con sistema operativo Android y iOS. Además es compatible con lentes inteligentes como los Google Glass (Figura 13.) de Google, Moverio de Epson, M100 de Vuzix y Optinvent ORA1.
Figura 13. Lentes inteligentes Google Glass Tomado de Metz, 2015
19
El contenido puedo ser creado con estándares web como HTML 5, JavaScript y CSS.
Tiene funciones que simplifica el trabajo de información geo referenciada (Figura 14.) como los puntos de interés.
Figura 14. Prueba de la aplicación Wikitude World browser Tomado de Wikimedia Commons, 2011
Tiene reconocimiento de imágenes y rastreo.
Permite incluir imágenes, videos y hasta videos transparentes como contenido.
El SDK en su versión 5 (Figura 15.) tiene las siguientes funciones (Phil, 2015):
Rastreo de imagen extendido: Es un modo de rastreo en 2D sin marcadores de referencia que permite seguir rastrando la imagen objetivo a pesar de que la cámara ya no puede verla. Esto permite al usuario tener más movimiento.
Un API nativa para el SDK: El API nativo contiene el motor de la tecnología de la visión por computadora que genera Wikitude. Contiene las siguientes funciones:
20
Reconocimiento y rastreo de imágenes 2D en la nube.
Reconocimiento y rastreo de imágenes 2D sin conexión a internet.
Rastreo de imagen extendido 2D.
Complementos del framework.
Figura 15. Arquitectura de Wikitude sdk 5 Tomado de Phil, 2015
Complemento Unity3D: Permite la integración de las funcionalidades de Wikitude en la plataforma de juegos en 3D.
Rendimiento de 60fps en la representación de imágenes: Con el avance de las unidades de procesamiento grafico “GPU” y las unidades de procesamiento central “CPU” de los dispositivos móviles el SDK tiene algoritmos que permiten llegar a un rendimiento de 60fps.
Compatibilidad completa con Android Studio: En la versión 5 del SDK se optimiza para trabajar con Android Studio
21
2.3.1.3 Software para el sitio web 2.3.1.3.1 ASP.NET Framework
.NET Framework es: “Un entorno de ejecución de aplicaciones informáticas sobre el que se ejecuta cualquier programa desarrollado en .NET en cualquiera de sus lenguajes (VB.net, Visual C++.net, Visual C#.net, Visual J#, Net Cobol, etc.)” (Rodríguez, 2010) Los componentes de la arquitectura de .NET (Figura 16.) son:
Entorno común de ejecución (CLR).- Provee un ambiente de tiempo de ejecución el cual corre el código y brinda servicios que hace fácil el proceso de desarrollo. (Microsoft, 2015)
Biblioteca de clases base (BCL).- Contiene las clases que habilitan a todos los lenguajes de .NET realizar tareas comunes como entrada/salida, acceso a base de datos, interfaz de usuarios, etc. (Rodríguez, 2010)
Capa de datos (ADO.NET) y XML.- ADO.NET es un conjunto de clases que exponen servicios de accesos a datos para programadores de .NET. La información que pasa por .NET en una gran parte es administrada mediante XML (Microsoft, 2015)
Interfaz ASP.NET y Windows Forms. - ASP.NET usa de los elementos como lo son los Web Forms direccionado a las aplicaciones y servicios web basados en ASP. Windows Forms son un conjunto
22
Figura 16. Arquitectura de .net framework Tomado de Rodríguez, 2010
2.3.1.4 Software para la base de datos 2.3.1.4.1 Análisis base de datos
El uso de una base de datos es necesario para administrar la información que se quiera almacenar y que en un futuro esta pueda crecer. Se tiene como asignación principal la administración de las coordenadas de geolocalización de los puntos de interés del proyecto. Adicional es necesario el registro del usuario administrador y posterior autenticación para ingresar a la página web. En la Figura 17 se toma como referencia el cuadrante mágico de la empresa consultora Gartner del 2015:
23
Figura 17. Cuadrante mágico de Gartner de sistemas de administración de base de datos operacionales del 2015 Tomado de Gartner, 2015
Los resultados de la investigación de mercado de Gartner en el 2015 muestran claramente como Oracle y Microsoft están en las mejores posiciones del cuadrante de líderes. Oracle tiene las siguientes fortalezas:
Una amplia oferta de portafolio.
Funcionalidad.
Rendimiento y disponibilidad sólida.
Microsoft tiene las siguientes fortalezas:
Visión de mercado.
Una ejecución fuerte en posicionarse contra la competencia.
Rendimiento y soporte.
Para este proyecto se necesita una base de datos que tenga funcionabilidad para cliente y servidor. La base de datos para este proyecto debe ser simple dado que
24
solo se requiere administrar coordenadas geográficas de un espacio en específico. El producto que encaja con estas especificaciones es MySQL de Oracle dado que ha sido utilizado mundialmente por empresas que se enfocan en páginas web como Facebook o Google. 2.3.1.4.2 MySQL
MySQL es un sistema Open Source de la empresa Oracle que entrega un SQL (Lenguaje de Consulta Estructurado) robusto y que tiene funciones de múltiples hilos y múltiples usuarios. Se considera como el sistema de administración de base de datos libre más popular. Las funciones más representativas de la arquitectura MySQL (Figura 18.) son las siguientes:
Funcionamiento Interno y Portabilidad.- Destaca su origen escrito en lenguajes C y C++ y provee su servidor como un programa separado para el uso de un ambiente cliente servidor.
Tipos de datos.- Utiliza
varios tipos de datos como enteros INT,
FLOAT, DOUBLE, CHAR, VARCHAR, BINARY, VARBINARY, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, AÑO, SET, ENUM, etc.
Declaraciones y funciones.- Tiene soporte completo en operadores y funciones básicas y avanzadas para las consultas.
Seguridad.- Seguridad de contraseña por encriptación de todo el tráfico de contraseñas cuando se conecta al servidor.
Estabilidad y limites.- Soporte para grandes bases de datos.
25
Conectividad.- Clientes se pueden conectar al servidor usando varios protocolos.
Localización.- El servidor puede proveer mensajes de error en diferentes lenguajes.
Clientes y herramientas.- Soporta varios programas de utilidad como también clientes. Los que destacan son mysqldump, mysqladmin y MySQL Workbench. (Oracle, 2016)
Figura 18. Arquitectura de MySql Tomado de Palkovic, 2008
2.4. Diagrama de componentes
El diagrama de componentes (Bell, 2004) permite mostrar relaciones entre los componentes de un sistema. Los componentes son unidades autónomas que pueden tener dentro un sistema o un subsistema. La notación es simple dado
26
que está basada en diagramas UML 1.4 en la que se puede dibujar un componente y que este tome la identidad de sistema o subsistema y adicional se las puede relacionar dibujando una flecha interlineada. Es importante el incluir este tipo de diagramas por la ayuda que proporciona al entender la arquitectura de los sistemas web (Figura 19.) y del sistema móvil (Figura 18.) que comprende el proyecto.
Figura 19. Diagrama de componentes página web
27
Figura 20. Diagrama de componentes aplicativo móvil
2.5. Diagrama de despliegue El diagrama de despliegue modela la arquitectura cuando se está ejecutando el sistema. Los elementos que utiliza este diagrama son los nodos que permiten visualizar el hardware y el software que intervienen en un proceso tanto para el sistema web (Figura 21.) y para el sistema móvil (Figura 22.).
Figura 21. Diagrama de despliegue página web
28
Figura 22. Diagrama De Despliegue Aplicativo Móvil
2.6. Product Backlog El Product Backlog (Figura 23.) para el primer Sprint está conformado de 22 ítems o necesidades del usuario que al avanzar el proyecto pueden ser descartadas por falta de un retorno de la inversión o que pueden ser utilizadas como mejoras en próximos lanzamientos del proyecto:
Página web de administración sencilla.
Página web con conector SQL.
Aplicación móvil con página de presentación.
La realidad aumentada debe señalar un punto de interés.
Uso de Etiquetas para los puntos de interés.
Diagrama casos de uso web.
Diagrama casos de uso aplicación.
Diagrama de secuencia web.
Diagrama de secuencia aplicación.
Survey o encuesta en la aplicación.
Integración con redes sociales.
Diagramas de clase web.
29
Diagramas de clase aplicación.
Manual de usuario.
CD o DVD de los sistemas.
Realizar video demostrativo del sistema.
Creación de logos para los sistemas.
Recolección de puntos geográficos.
Uso de realidad aumentada por marcadores QR para propósitos publicitarios.
Uso de realidad aumentada por marcadores QR para propósitos informativos.
Identificar los requisitos funcionales y no funcionales del sistema web
Identificar los requisitos funcionales y no funcionales del sistema móvil
Figura 23. Product backlog en Vivifyscrum
En la Figura 24 se muestra un ítem en la herramienta, esta tiene iconos que permiten identificar indicadores que ayudan para la planeación del primer Sprint:
30
Código identificador de
Descripción del ítem
la tabla Scrum
Resumen del ítem
Fotografía del responsable
Nivel de dificultad de la tarea Descripción del ítem
Nivel de prioridad de la tarea
Tipo de tarea: Historia, tarea, Bug o error
Nivel de valor para el proyecto de la tarea
Figura 24. Iconos de cada item Vivifyscrum
2.7. Primer sprint planning En el primer Sprint Planning se determina detalles de cada ítem como la prioridad, puntos que señalan el nivel de dificultad, el tipo de ítem y el valor que va generar este ítem al ser realizado. Al especificar estos campos de cada ítem se puede clasificar que ítems pueden ser realizados para el primer Sprint. Para tener un mayor control de las asignaciones se va clasificar los Sprints en un Sprint para sistema web y otro Sprint para el sistema móvil. Los ítems que no hayan sido seleccionados para cada sprint deberán guardarse para el sprint backlog de las siguientes iteraciones. 2.7.1 Primer sprint página web En la Figura 25 se muestra el primer Sprint de la página web de la cual se ha clasificado los siguientes ítems por su valor que va proporcionar al proyecto final:
Página web de administración sencilla.
Página web con conector SQL.
31
Diagrama casos de uso web.
Diagrama de secuencia web.
Diagramas de clase web.
Figura 25. Sprint 1 sistema web Vivifyscrum
2.7.2 Primer sprint sistema móvil En la Figura 26 se muestra el primer Sprint sistema móvil donde se ha clasificado los siguientes ítems por su valor que va proporcionar al proyecto final:
Aplicación móvil con página de presentación.
La realidad aumentada debe señalar un punto de interés.
Diagrama casos de uso aplicación.
Diagrama de secuencia aplicación.
Diagramas de clase aplicación.
Recolección o reconocimiento de puntos geográficos.
32
Figura 26. Sprint 1 sistema móvil Vivifyscrum
2. DISEÑO 3.1. Especificación de requerimientos
La presente especificación de requerimientos pertenece al desarrollo del proyecto “Desarrollo de Interfaz de realidad aumentada para localización de puntos de interés de un campus universitario”, como tesis para la obtención del título de Ingeniería en Electrónica en Redes de la Información y está desarrollada siguiendo las directrices de la metodología Scrum y del Lenguaje Unificado de Modelado (UML).
33
3.1.1 Requisitos funcionales Se refieren a las funciones o componentes de un sistema. Una función es considerada como conjunto de entradas comportamientos y salidas. Pueden ser cálculos, detalles técnicos. Casos de uso:
El sistema móvil tendrá una interfaz sencilla de la cual se va acceder a la función de realidad aumentada con uno o varios botones.
El sistema móvil tendrá una página sobre la información del desarrollador y la aplicación.
La función de realidad aumentada mostrara información de las 3 edificaciones de una universidad.
El software mostrara información relacionada a los puntos de interés de cada sede.
El sistema móvil tomara información de las coordenadas del sistema web.
El sistema web tendrá una interfaz sencilla de administración.
La página web tendrá un conector web a una base de datos.
3.1.2 Requisitos no funcionales Sirven para juzgar la operación de un sistema. Los requisitos no funcionales son:
El sistema móvil funcionará bajo el sistema operativo Android (Google)
El sistema móvil requiere que el dispositivo esté conectado al internet.
El sistema móvil requiere que el dispositivo esté conectado al GPS.
El sistema web funcionará bajo el framework ASP.NET de Microsoft.
El sistema web utilizara una base de datos que funcionara bajo el sistema de MySQL
34
3.2. Introducción sistema web 3.2.1 Propósito sistema web El propósito del presente apartado es definir los requerimientos que debe tener sistema web la cual se llamara AR-Ministrator. Los requerimientos permiten que se especifique con mayor claridad las funciones de los sistemas. 3.2.2 Definiciones, acrónimos y abreviaturas del sistema web
AR: Abreviatura en idioma ingles que se usa para el termino Realidad Aumentada.
IDE: Se refiere al término ambiente de desarrollo integrado que permite al desarrollador de software utilizar herramientas y servicios para cumplir con objetivos.
Conector Visual Studio: Permite integrar la base de datos MySQL en la herramienta IDE de Visual Studio.
POI: Termino relacionado a los puntos de interés.
Master Page: Página web que se utiliza como plantilla para las demás páginas relacionadas al sistema web.
EER: Modelo entidad – relación extendido.
3.2.3 Identificación de roles y tareas del sistema web
Roles
Usuario
Usa la aplicación y sus funciones.
Sistema Web
Sistema que interacciona con el usuario.
35
En la Figura 27 se encuentra el diagrama de actores del sistema web:
Figura 27. Actores sistema web
Tareas
Usuario
Ingresar al sistema autenticando sus credenciales
Ingresar valores a una base de datos
Remover valores de una base de datos
Guardar valores de una base de datos
Sistema Web
Validar la información del usuario
Mostrar mensajes de información
3.2.4 Casos de uso por actor para el sistema web
Actor: Usuario Para el actor usuario (Figura 28.) se especifica los siguientes casos:
1.- Ingresar al sistema
2- Ver tabla con los puntos de interés
36
3.- Editar tabla con los puntos de interés
4.- Ver información acerca del sistema
Figura 28. Casos de uso del usuario del sistema web
CASOS DE USO DEL USUARIO En la Tabla 6, Tabla 7, Tabla 8 y Tabla 9 se especifican los casos para el actor usuario: Tabla 6. Ficha del caso de uso 1 del usuario
Ingresar al Sistema Resumen: El usuario señala que va ingresar al sistema Prioridad: Alta Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema permite autenticar al cliente y le presenta la página principal. Secundario: El sistema muestra un mensaje informativo para que se vuelva a ingresar las credenciales correctas. Pre Condiciones El usuario debe estar en la base de datos del sistema. Post Condiciones Ninguna.
37
Tabla 7. Ficha del caso de uso 2 del usuario
Ver tabla con los puntos de interés Resumen: Despliega una tabla con los puntos de interés almacenados. Prioridad: Alta Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema muestra una tabla informativa que está conectada con la base de datos y en específico con la tabla de los puntos de interés. Secundario: Ninguna. Pre Condiciones El usuario debió haber ingresado exitosamente al sistema. El usuario debió haber ingresado datos a la base de datos. Post Condiciones Ninguna.
Tabla 8. Ficha del caso de uso 3 del usuario
Editar tabla con los puntos de interés Resumen: Despliega controles de edición de la tabla que está conectada a la base de datos. Prioridad: Alta Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema muestra el término “Edit”, “Save” y “Cancel” para editar la base de datos. Secundario: El sistema muestra espacios para ingresar datos. Pre Condiciones El usuario debió haber ingresado datos a la base de datos para editarlos. Post Condiciones Ninguna.
38
Tabla 9. Ficha del caso de uso 4 del usuario
Ver información acerca del sistema Resumen: Despliega la información del sistema. Prioridad: Baja Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema muestra una página informativa de la aplicación y enlaces a las redes del desarrollador de la misma. Secundario: Ninguna. Pre Condiciones El usuario debió haber ingresado exitosamente al sistema. Post Condiciones Ninguna.
Actor: Sistema Web Para el actor sistema web (Figura 29.) se especifica los siguientes casos:
1.- Autenticar al usuario
2- Desplegar información del sistema
3.- Desplegar información de la base de datos
Figura 29. Casos de uso del interfaz del sistema web
39
CASOS DE USO DEL SISTEMA WEB En la Tabla 10, Tabla 11 y Tabla 12 se especifican los casos para el actor sistema web: Tabla 10. Ficha del caso de uso 1 del sistema web
Autenticar al usuario Resumen: Valida si el usuario está en la base de datos. Prioridad: Alta Actores Directos: Sistema web Escenarios Tipo Escenario Descripción Principal: Se conecta a la base de datos y valida si el usuario existe y da la acción de seguir con la página de inicio. Secundario: El sistema muestra un mensaje informativo para que se vuelva a ingresar las credenciales correctas. Pre Condiciones El sistema debe haberse conectado con la base de datos. Post Condiciones Ninguna.
Tabla 11. Ficha del caso de uso 2 del sistema web
Desplegar Información del Sistema Resumen: Muestra información acerca del sistema Prioridad: Baja Actores Directos: Sistema web Escenarios Tipo Escenario Descripción Principal: El sistema muestra una descripción del sistema y de las redes sociales del desarrollador. Secundario: Ninguna. Pre Condiciones El sistema debe haberse conectado con la base de datos. El usuario debe tener enlaces validos a sus redes sociales. El usuario debió haber ingresado con éxito al sistema. Post Condiciones Ninguna.
Tabla 12. Ficha del caso de uso 3 del sistema web
40
Desplegar Información de la base de datos Resumen: Muestra la tabla con los puntos de interés. Prioridad: Alta Actores Directos: Sistema web Escenarios Tipo Escenario Descripción Principal: El sistema se conecta a la base de datos y despliega en una tabla los campos que conforman un punto de interés. Secundario: El sistema actualiza la tabla y muestra nuevos valores. Pre Condiciones El sistema debe haberse conectado con la base de datos. El usuario debió haber ingresado con éxito al sistema. Post Condiciones Ninguna.
3.2.5 Diagrama de secuencia por actor para el sistema web
Actor: Usuario
1.- Ingresar al sistema (Figura 30.)
Figura 30. Diagrama de secuencia caso 1 usuario
41
2- Ver tabla con los puntos de interés (Figura 31.)
Figura 31. Diagrama de secuencia caso 2 usuario
3.- Editar tabla con los puntos de interés (Figura 32.)
Figura 32. Diagrama de secuencia caso 3 usuario
42
4.- Ver información acerca del sistema (Figura 33.)
Figura 33. Diagrama de secuencia caso 4 usuario
Actor: Interfaz de Usuario.
1.- Autenticar al usuario (Figura 34.)
Figura 34. Diagrama de secuencia caso 1 interfaz de usuario
43
2- Desplegar información del sistema (Figura 35.)
Figura 35. Diagrama de secuencia caso 2 interfaz de usuario
3.- Desplegar información de la base de datos (Figura 36.)
Figura 36. Diagrama de secuencia caso 2 interfaz de usuario
44
3.2.6 Especificaciones de diagrama de clases por actor para el sistema web
El sistema web tiene las siguientes clases:
MasterPage_ProyectoARministrator.- Pagina maestra donde está el diseño base para las sub páginas.
Login.- Sub página donde el usuario registrara sus datos para autenticarse.
Inicio.- Página principal donde se ven tablas conectadas a la base de datos.
POIS1.- Servicio web que transforma los datos de las tablas a cadenas de datos en formato JSON.
AcercaDe.- Sub página con información del desarrollador.
En la Figura 37 se muestra el diagrama de clases del sistema web:
Figura 37. Diagrama De Clases Del Sistema Web
45
3.2.6 Diagrama EER de la base de datos del sistema web EER (Modelo entidad – relación extendido) modelo (Cillero, s.f.) que permite diseñar de una manera completa en alto nivel (Figura 38.) las tablas de la base de datos.
La base de datos tiene las siguientes tablas:
Poi.- Tabla con información geográfica de las sedes de la Universidad.
Posteriormente se pueden crear varias tablas de este tipo para crear
categorías
(Se
crearon
poi_biblioteca,
poi_buses)
Usuario
Persona
Figura 38. Diagrama ERR de la base de datos del sistema web
poi_centros,
46
3.3. Introducción sistema móvil 3.3.1 Propósito sistema móvil El propósito del presente apartado es definir los requerimientos que debe tener sistema web la cual se llamará AR-Universidad. Los requerimientos permiten que se especifique con mayor claridad las funciones de los sistemas.
3.3.2 Definiciones, acrónimos y abreviaturas del sistema móvil El sistema web comparte con el sistema móvil los siguientes términos y que se especifica en el apartado 3.2.2:
AR (Realidad aumentada)
IDE (Ambiente de desarrollo integrado)
POI (Punto de interés)
En el sistema móvil se agregan los siguientes términos:
SDK: Abreviatura utilizada para definir el termino Kit de desarrollo de software (Software Develoment Kit) que se define como el conjunto de software que es usado para el desarrollo de aplicaciones para un sistema operativo y dispositivo en específico. (Christensson P. , SDK Definition, 2015)
Samples: Código realizado por el fabricante del SDK que permite probar las funcionalidades del mismo kit.
JavaScript: Lenguaje de programación comúnmente usado en desarrollo web que añade elementos dinámicos e interactivos a los sitios web. (Christensson P. , JavaScript Definition, 2014)
47
Wikitude Architect World: Es el contenido AR escrito en JavaScript que describe el ciclo de vida y funciones que tiene por defecto las aplicaciones desarrolladas en el SDK.
Android Class Activity: Son las clases Android que tienen la responsabilidad de crear una ventana para que el usuario pueda situar su interfaz gráfica. (Google, 2015)
Java Class Interface: Son tipos de referencia parecido a una clase que tiene como contenido solo constantes, métodos por defecto, métodos estáticos y tipos anidados. (Oracle Corporation, 2015)
GPS: El sistema de posicionamiento global es una tecnología adoptada por los dispositivos móviles para determinar la posición del equipo. (Christensson P. , GPS, 2006)
3.3.3 Identificación de roles y tareas del sistema móvil
Roles
Usuario
Usa la aplicación y sus funciones.
Sistema o Aplicativo Móvil
Sistema que interacciona con el usuario.
48
En la Figura 39 se encuentra el diagrama de actores del sistema móvil:
Figura 39. Actores sistema móvil
Tareas
Usuario
Ingresar en los menús de la aplicación.
Ingresar a los sub menús de cada punto de interés.
Utilizar la cámara.
Direccionar la cámara hacia los puntos de interés más cercano.
Sistema Móvil
Conectar con el sistema web.
Tomar la información de los puntos de interés del servicio web.
Mostrar mensajes de información.
49
3.3.4 Casos de uso por actor para el sistema móvil
Actor: Usuario Para el actor usuario se especifica los siguientes casos (Figura 40.)
1.- Iniciar Experiencia de Realidad Aumentada.
2.- Ver información de los puntos de interés.
3.- Ver información acerca del sistema.
Figura 40. Casos de uso del usuario del sistema móvil
50
CASOS DE USO DEL USUARIO En la Tabla 13, Tabla 14 y Tabla 15 se especifica los casos para el actor usuario: Tabla 13. Ficha del caso de uso 1 del usuario
Iniciar Experiencia de Realidad Aumentada Resumen: El usuario inicia la aplicación RA Prioridad: Alta Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema despliega la experiencia de realidad aumentada por medio de la cámara. Secundario: El sistema despliega otras capas de realidad aumentada (Experiencia Biblioteca, Centros, Transporte) Pre Condiciones El usuario debe ingresar a la opción Iniciar Realidad Aumentada Post Condiciones Ninguna.
Tabla 14. Ficha del caso de uso 2 del usuario
Ver información de los puntos de interés. Resumen: Despliega información del punto de interés Prioridad: Alta Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El punto de interés muestra información básica como su nombre, descripción y distancia entre el usuario y el punto seleccionado. Secundario: Ninguna Pre Condiciones El usuario debe ingresar a la opción Iniciar Realidad Aumentada El usuario debe ingresar a un punto de interés en específico. Post Condiciones Ninguna.
51
Tabla 15. Ficha del caso de uso 3 del usuario
Ver información acerca del sistema. Resumen: Despliega información sobre el sistema. Prioridad: Media Actores Directos: Usuario Escenarios Tipo Escenario Descripción Principal: El sistema muestra un resumen de la función de la aplicación y adicional muestra un enlace al portal del desarrollador. Secundario: El sistema muestra un enlace a una encuesta web para evaluar la calidad de la aplicación. El sistema muestra un botón para probar la realidad aumentada desde un equipo de un Raspberry Pi. Pre Condiciones El usuario debe ingresar a la opción Acerca De en el menú principal. Post Condiciones Ninguna.
Actor: Sistema Móvil Para el actor Interfaz gráfica del usuario se especifica los siguientes casos (Figura 41.)
1.- Desplegar información del sistema.
2.- Desplegar información del punto de interés.
3.- Desplegar en un radar los puntos cercanos.
Figura 41. Casos de uso del interfaz del usuario
52
CASOS DE USO DEL SISTEMA MÓVIL En la Tabla 16, Tabla 17 y Tabla 18 se especifican los siguientes casos: Tabla 16. Ficha del caso de uso 1 de la interfaz del usuario
Desplegar información del sistema. Resumen: Despliega información del sistema, de la conexión con la red y al GPS. Prioridad: Alta Actores Directos: Sistema móvil Escenarios Tipo Escenario Descripción Principal: Valida la conexión a la internet y al GPS. Secundario: El sistema muestra un mensaje informativo solicitando la conexión a una red y al GPS. El sistema muestra un botón para actualizar la conexión al servicio web. El sistema muestra un botón para manejar el rango de alcance de visión de los POIS en kilómetros. Pre Condiciones El sistema debe haberse conectado con el internet y al GPS. Post Condiciones Ninguna.
Tabla 17. Ficha del caso de uso 2 de la interfaz del usuario
Desplegar información del punto de interés. Resumen: Despliega información acerca de un punto de interés universitario. Prioridad: Alta Actores Directos: Sistema móvil Escenarios Tipo Escenario Descripción Principal: El sistema despliega información acerca de una edificación geo localizada. Secundario: El sistema muestra un mensaje informativo del número de puntos geo localizados Pre Condiciones El sistema debe haberse conectado con el internet y al GPS. El sistema debe detectar del servicio web los puntos de interés. Post Condiciones Ninguna.
53
Tabla 18. Ficha del caso de uso 2 de la interfaz del usuario
Desplegar en un radar los puntos cercanos. Resumen: Despliega en un radar grafico los puntos en un área de 50 Kilómetros. Prioridad: Media Actores Directos: Sistema móvil Escenarios Tipo Escenario Descripción Principal: El sistema despliega gráficamente los puntos de interés detectados. Secundario: Ninguna. Pre Condiciones El sistema debe haberse conectado con el internet y al GPS. El sistema debe detectar del servicio web los puntos de interés. Post Condiciones Ninguna.
3.3.5 Diagrama de secuencia por actor para el sistema móvil Actor: Usuario
1.- Iniciar Experiencia de Realidad Aumentada (Figura 42.)
Figura 42. Casos de uso 1 del usuario
54
2.- Ver información de los puntos de interés (Figura 43.)
Figura 43. Casos de uso 2 del usuario
3.- Ver información acerca del sistema (Figura 44.)
Figura 44. Casos de uso 3 del usuario
55
Actor: Interfaz Gráfica del Usuario
1.- Desplegar información del sistema (Figura 45.)
Figura 45. Casos de uso 1 del interfaz del usuario
2.- Desplegar información del punto de interés (Figura 46.)
Figura 46. Casos de uso 2 del interfaz del usuario
56
3.- Desplegar en un radar los puntos cercanos (Figura 47.)
Figura 47. Casos de uso 3 del interfaz del usuario
3.3.6 Diagrama de clases para el sistema móvil
El sistema móvil tiene las siguientes clases (Figura 48.)
MainActivity.- Contiene la presentación de la aplicación y los botones que enlazan a las sub páginas de la aplicación.
RealidadAumentadaActivity.- En esta actividad crea una capa de realidad aumentada destinada a conectarse con el servicio web y reflejar las sedes.
Posteriormente se pueden crear varias actividades de este tipo con el objetivo de crear categorías o capas (Se crearon actividades para Bibliotecas, Centros, Transporte y Pruebas)
AcercaDeActivity.- Contiene la información de la aplicación y enlaces a las páginas del desarrollador.
57
Clases Wikitude.- Contiene un conjunto de clases destinadas a la recolección de la información del dispositivo móvil como su ubicación y calibración entre otras cosas:
AbstractArchitectCamActivity
LocationProvider
ArchitectViewlHolderInterface
WikitudeSDKConstants
Figura 48. Diagrama de clases del sistema web
3. DESARROLLO Y PRUEBAS 4.1. Implementación y pruebas de la aplicación web 4.1.2 Visual Studio Community 2015 Visual Studio es un ambiente de desarrollo integrado creado por la empresa Microsoft que permite al desarrollador crear aplicaciones profesionales. En su versión Community 2015 tiene la característica de ser gratuito y destinado para desarrolladores individuales, para organizaciones que no pasen de 5 desarrolladores y proyectos de código abierto y de investigación académica. Visual Studio Community 2015 tiene las siguientes funciones (Tabla 19.)
Herramientas de desarrollo web, para móviles y en la nube
58
Compilar aplicaciones para Windows, Android e iOS
Diseñadores, editores, depuradores y generadores de perfiles integrados
Code en C#, C++, JavaScript, Python, TypeScript, Visual Basic, F#, etc.
Capacidad de implementar, depurar y administrar servicios de Microsoft Azure
Miles de extensiones, desde PHP hasta juegos (Microsoft, 2015)
Tabla 19. Ficha comparativa de las ofertas de Visual Studio 2015
Depuración y diagnóstico
Visual Studio Community 3 de 4
Visual Studio Professional 3 de 4
Visual Studio Enterprise 4 de 4
Visual Studio Test Professional 0 de 4
Platafor mas de MSDN 0 de 4
Herramientas de pruebas
1 de 4
1 de 4
4 de 4
2 de 4
2 de 4
Entorno de desarrollo integrado Soporte de plataforma de desarrollo Arquitectura y modelado
2 de 4
3 de 4
4 de 4
0 de 4
0 de 4
4 de 4
4 de 4
4 de 4
0 de 4
0 de 4
1 de 4
1 de 4
4 de 4
0 de 4
0 de 4
Lab Management
0 de 4
0 de 4
4 de 4
4 de 4
4 de 4
Team Foundation Server
0 de 4
3 de 4
4 de 4
4 de 4
4 de 4
Servicios de Visual Studio Online Herramientas de colaboración
2 de 4
2 de 4
4 de 4
3 de 4
3 de 4
4 de 4
4 de 4
4 de 4
3 de 4
3 de 4
Escenarios de uso admitidos
3 de 4
4 de 4
4 de 4
4 de 4
4 de 4
Servicios y software de suscripción a MSDN para uso de producción
0 de 4
3 de 4
4 de 4
3 de 4
3 de 4
Suscripción a MSDN: Software para desarrollo y pruebas Otros beneficios de la suscripción a MSDN
0 de 4
2 de 4
4 de 4
2 de 4
3 de 4
0 de 4
3 de 4
4 de 4
3 de 4
3 de 4
Adaptado de Microsoft, 2016
59
4.1.2.1 Instalación de Visual Studio 2015 Community
Ingresar en https://www.visualstudio.com/es-es/products/visual-studiocommunity-vs.aspx
Presionar el botón “Descargar Community 2015”
Luego de descargarse con el programa ejecutable de instalación este preguntara (Figura 49.) el tipo de instalación que puede ser “Typical” que incluye componentes básicos como C# y Visual Basic Web con opciones de escritorio. También existe la opción “Custom” que permite elegir los componentes
que
se
requieren
instalar
como
otros lenguajes,
herramientas y SDKs.
Figura 49. Opciones de instalación de Visual studio 2015 community Tomado de Microsoft, 2016
Para el proyecto se va instalar la versión “Typical” dado que se va usar los componentes básicos como son el lenguaje C# y las herramientas web.
60
Una vez seleccionado la versión se procederá a descargar el programa y se podrá utilizar de inmediato.
4.1.2.2 Interfaz de usuario de Visual Studio Community 2015 La Figura 50 muestra la interfaz principal de Visual Studio.
Figura 50. Interfaz de Visual studio community 2015
Visual Studio es una herramienta fundamental en el proyecto dado que contiene el framework ASP.NET para el desarrollo de aplicaciones y servicios web. Para crear aplicaciones ASP.NET se necesita un lenguaje de programación que en este caso se va utilizar C#
4.1.3 Lenguaje de Programación C# Visual C# es un lenguaje de programación orientado a objetos creado por Microsoft que se ejecuta en el .NET Framework y que parte de la evolución de los lenguajes C y C++.
61
Para (Ferguson, Patterson, Beres, Boutquin, & Gupta, 2003) este es el origen del lenguaje C#:
Microsoft diseño C# de modo que retuviera casi toda la sintaxis de C y C++. Los programadores que estén familiarizados con esos lenguajes pueden escoger el código C# y empezar a programar de forma relativamente rápida. Sin embargo, la gran ventaja de C# consiste en que sus diseñadores decidieron no hacerlo compatible con los anteriores C y C#. Aunque esto puede parecer un mal asunto, en realidad en una buena noticia. C# elimina las cosas que hacían que fuese difícil trabajar con C y C++. Como todo el código C es también C++. C++ tenía que mantener todas las rarezas y deficiencias de C. C# parte de cero y sin ningún requisito de compatibilidad, así que puede mantener los puntos fuertes de sus predecesores y descartar las debilidades que complicaban las cosas a los programadores de C y C++.
Las características de C# son las siguientes:
C# es un lenguaje de programación simple pero eficaz, diseñado para escribir aplicaciones empresariales.
El lenguaje C# es una evolución de los lenguajes C y C++. Utiliza muchas de las características de C++ en las áreas de instrucciones, expresiones y operadores. C# presenta considerables mejoras e innovaciones en áreas como seguridad de tipos, control de versiones, eventos y recolección de elementos no utilizados (liberación de memoria).
C# proporciona acceso a los tipos de API más comunes: .NET Framework, COM, Automatización y estilo C. Asimismo, admite el modo unsafe, en el que se pueden utilizar punteros para manipular memoria que no se encuentra bajo el control del recolector de elementos no utilizados. (Microsoft, 2015)
62
El entorno ASP.NET se beneficia de este lenguaje por el código que se maneja por detrás de las páginas web HTML haciendo más fácil la programación de servicios web. También ASP.NET al usar el .NET Framework tiene una mejor respuesta en niveles de velocidad por el compilador Just In Time (JIT).
Adicional ASP.NET con C# permite la integración de formularios y sus controles mejor conocidos como Windows Forms permitiendo al desarrollador tener un amplia gama de herramientas visuales y programables a su disposición. (Ferguson, Patterson, Beres, Boutquin, & Gupta, 2003)
4.1.3.1 Referencias importantes a utilizar
Dentro del proyecto se debe utilizar referencias a componentes que por ejemplo permiten que conectar la solución a una base de datos u otros servicios como:
Aplicaciones de la tienda de Windows.
Bibliotecas de clases o ensamblados de .NET Framework.
Componentes COM
Servicios Web XML
Otros ensamblados o bibliotecas de clases de proyectos de la misma solución. (Microsoft, 2015)
Para agregar una referencia se sitúa en el explorador de soluciones y se busca la sección “Referencias” se presiona click derecho y se selecciona “Agregar referencia” como se ve en la Figura 51:
63
Figura 51. Menú de referencias del proyecto
Las referencias importantes para este proyecto son:
MySQL.Data.- Esta referencia permite la conexión con la base de datos MySQL de la cual se va a utilizar para representar una tabla en una página del proyecto. No viene por defecto en el programa por lo cual se debe instalar MySQL for Visual Studio 1.2.4 por medio del programa MySQL Installer que contiene todos los productos relacionados a la base de datos MySQL de Oracle.
Json.Net.- Es un framework creado por la compañía Newtonsoft que tiene funciones importantes relacionadas a JSON. Para el proyecto se va utilizar la función de serialización de JSON que permite convertir una tabla obtenida de una base de datos de MySQL en una cadena de valores “String” (Figura 52.) esto con el propósito de que pueda ser leído por el sistema móvil que en base a los valores establecidos pueda representar los puntos de interés gráficamente por medio de la realidad aumentada.
64
Figura 52. Tabla “poi” mysql serializada en formato json
4.1.4 Instalación de la base de datos MySql Community server
MySQL es la base de datos que se va a utilizar en el proyecto y será la versión “Community” que incluye un grupo completo de funciones de manera gratuita para desarrolladores de código abierto. (Oracle Corporation, 2015)
Esta versión tiene estas ventajas:
Disponible en la mayoría de las plataformas.
Funciona con todos los principales lenguajes de desarrollo.
Ligero y fácil de usar.
Apoyada por una comunidad de usuarios activa, en todo el mundo. (Oracle Corporation, 2015)
El procedimiento para instalar MySQL en Windows es el siguiente:
Ingresar en http://dev.mysql.com/downloads/mysql/
Presionar el botón “Download Windows (x86, 32-bit), MySQL Installer MSI”
Luego de descargarse con el programa ejecutable de instalación este preguntara el tipo de instalación que se requiera como por ejemplo:
65
Instalar actualizaciones, Añadir o modificar productos y funciones y por ultimo eliminar productos.
Selecciona instalar MySQL Community Edition en el campo de búsqueda del catálogo de productos.
Selecciona el tipo de instalación: “Deafult Developer” para tener las herramientas básicas de MySQL como MySQl Workbench.
Se completa el proceso de instalación de MySQl siguiendo las instrucciones del instalador. Esto instalara los productos e iniciara el servidor.
Para instalar los componentes adicionales en este caso el conector para .NET que ayudara a la solución a tener una base de datos se requiere realizar estos procedimientos:
Se requiere que esté instalado el Microsoft .NET Framework reciente.
Se requiere que esté instalado Visual Studio reciente y que no sea la versión Express dado que MySQL no tiene soporte para esta versión.
Se debe descargar el instalador del conector desde esta página: https://dev.mysql.com/downloads/connector/net/ o desde el programa MySQL Installer.
Se comprueba si se tiene una conexión exitosa cuando se añade una conexión nueva a un servidor de base de datos en el proyecto de Visual Studio y este muestra la opción de conectarse a un servidor MySQL.
66
4.1.5 Construcción del sistema web en Visual Studio
El sistema web fue desarrollada en .NET y programada por medio del lenguaje C# de la cual se tiene las siguientes páginas:
MasterPage_ProyectoARministrator.Master: Esta página alberga el diseño general a manera de plantilla para las otras páginas que se creen.
Login: Presenta un formulario de acceso para los usuarios del sistema.
Inicio. Presenta la tabla de puntos de interés con controles de edición.
AcercaDe: Muestra información del propósito del sistema e información del desarrollador.
POIS: Este es el servicio web del sistema. Su nombre abreviado significa en inglés “Point Of Interest System” que en español seria “Sistema Punto de Interés” y en este servicio web se obtiene los puntos de interés de la tabla de la base de datos y se los convierte en una cadena de valores en formato JSON.
4.1.5.1 Consideraciones especiales de la programación del servicio web
El servicio web es parte fundamental en la solución dado que este muestra los puntos de interés de forma que la aplicación móvil pueda consumir esta información y permita mostrar los puntos de interés.
Para este propósito se optó por una alternativa que no sea compleja y que en efecto sea sencilla como lo es el tipo de servicio web ASMX.
ASMX tiene las siguientes características:
67
Fácil de entender.
Simple de escribir y configurar.
Se puede llamar solo desde el protocolo HTTP (Banik, s.f.)
Teniendo en cuenta este tipo de servicio como resultado al momento de construir el servicio web fue necesario toma en cuenta que se necesita tener estos componentes:
La conexión a la base de datos MySQL.
Un “DataTable” que es un objeto que representa una tabla de datos relacionales de memoria de las cuales se puede llenar de un origen de datos como MySQL Server por medio de un “DataAdapter” que es una clase con este tipo de funciones. (Microsoft, 2015)
Un serializador que convierta el objeto “DataTable” y lo convierta en una cadena del tipo “String” esto se logra con la referencia al framework Json.NET (Newtonsoft, 2015)
Por último se necesita que al momento de consumir el servicio web este no muestre etiquetas XML como común mente lo hace.
En la Figura 53 se muestra la integración que tiene la página web con la base de datos y esto fue posible gracias a las referencias de MySQL en Visual Studio:
68
Figura 53. Tabla de datos integrada en la página.
Adicional en la Figura 54 se muestra la integración que tiene la página web con Google Maps con el objetivo de obtener de una manera fácil los datos de latitud y longitud de los sectores en la que se encuentra la universidad.
Figura 54. Mapa integrado en la página.
El mapa se programó con la API de Google Maps de la cual se pudo especificar el sector y puntos de interés que en este caso las sedes y se añadió la funcionalidad de tener etiquetas con información geográfica
69
4.1.6 Pruebas del sistema web Para el sistema web se eligió una técnica ágil acorde a la metodología del proyecto. El proceso o ciclo de actividades se ha tomado de la guía de Microsoft “Performance Testing Guidance for Web Applications” (Meier, Farre, Bansode, Barber, & Rea, 2008) que se muestra en la Figura 55:
Actividades de prueba de rendimiento ágil 1.- Entender la visión del proyecto y contexto 2.- Identificar las razones para realizar una prueba de rendimiento 3.- Identificar el valor de realizar una prueba de rendimiento 4.- Configurar el ambiente de prueba 5.- Identificar y coordinar tareas 6.- Ejecutar tareas 7.- Analizar resultados y reportes
Figura 55. Diagrama de actividades de prueba de rendimiento ágil Adaptado de Meier, Farre, Bansode, Barber, & Rea, 2008
4.1.6.1 Entender la visión del proyecto y contexto Para tener un mejor entendimiento del proyecto en funcionamiento se debe repasar la visión del mismo y su contexto. Con este paso se evita desviarse del propósito del proyecto. Para la parte del sistema web se tiene la siguiente visión:
Desarrollar un sistema web conformado por un servicio web y paginas HTML con el objetivo de administrar una tabla de datos y mostrarla en formato JSON.
70
Para la parte del sistema web se tienen los siguientes contextos:
Presupuesto: El sistema en un inicio puede crearse a partir de herramientas con costo gratuito y que con la rentabilidad del producto se pueda pagar por funciones especiales para el sistema.
Ambiente de pruebas: El sistema puede implementarse en una infraestructura de pruebas sencilla como una Computadora de placa reducida como el Raspberry Pi, una computadora de escritorio o una solución empresarial compuesta de un servidor de arquitectura x86.
Herramientas: Las herramientas pueden estar conformadas por Kits de desarrollo, ambientes de desarrollo integrado IDE, Interfaces de programación de aplicaciones entre otras como servicios web de pruebas de páginas.
Para la parte del sistema web se tiene el siguiente entendimiento:
Al estar desarrollado en base a una metodología ágil este sistema va estar sujeto a cambios con el propósito de llegar a tener un producto final deseado.
4.1.6.2 Identificar las razones para realizar una prueba de rendimiento El identificar las razones permite conducir el rendimiento del sistema en un estado muy temprano porque pueden modificar las prioridades. Se tiene las siguientes razones:
Mejorar la experiencia del usuario.
El factor velocidad de carga de página es necesario para cumplir con una buena experiencia.
Medir el tiempo de carga de página.
71
Se utiliza la herramienta en línea WebPageTest.org para tener un análisis de velocidad:
Se ingresa la página web o el servicio web en el cuadro de texto.
Se especifica la locación de la prueba.
Se especifica el explorador.
Se inicia la prueba
En la Tabla 20 y Tabla 21 se observa las pruebas de velocidad de la página principal y del servicio web. Página Principal Login.aspx: Tabla 20. Resultado de la prueba de velocidad de carga de la página principal Document Complete
Fully Loaded
Load Time
First Byte
Start Render
DOM Elements
Time
Requests
Bytes In
Time
Requests
Bytes In
1.157s
1.069s
0.000s
63
1.157s
1
5 KB
1.157s
1
5 KB
Servicio POIS.asmx: Tabla 21. Resultado de la prueba de velocidad de carga del servicio web Document Complete
Fully Loaded
Load Time
First Byte
Start Render
DOM Elements
Time
Requests
Bytes In
Time
Requests
Bytes In
0.319s
1.069s
0.242s
4
0.319s
1
1 KB
0.531s
2
6 KB
Glosario de los resultados (WebPageTest.Org, 2015): Load Time.- Es el “tiempo de carga” que inicia desde la navegación inicial hasta el evento de inicio de carga de ventana.
72
First Byte.- El primer byte es el tiempo desde el inicio de la navegación inicial hasta que el primer byte de la página base es recibido por el navegador. Start Render.- Es el tiempo medido desde el inicio de navegación hasta que el primer contenido que no sea del color blanco sea pintado en la pantalla. DOM Elements.- “DOM” se refiere a Modelo de objetos de un documento que por ejemplo pueden ser las etiquetas “body”, “html” de la página web. Document Complete.- Cuando el documento está completamente cargado. Fully Loaded.- Cuando la página está completamente cargado.
Determinar ajustes en el sistema para aprovechar un rendimiento deseado.
Con la herramienta PageSpeed Insights de Google se obtiene recomendaciones para optimizar la velocidad como por ejemplo editar las imágenes grandes o seleccionar fuentes con tamaños que se puedan visualizar en un dispositivo móvil.
4.1.6.3 Identificar el valor de realizar una prueba de rendimiento Usando los resultados de las dos primeras actividades se puede tener como resultado el valor agregado de las pruebas con el objetivo de conceptualizar una estrategia que se replicaría como mejores prácticas durante el proceso de las pruebas. La estrategia se la realizaría en dos partes: 1. Correr prueba de velocidad WebPageTest.Org de la página inicial y del servicio web. 2. Correr prueba de análisis PageSpeed Insigths de la página inicial y del servicio web para obtener sugerencias en los ajustes del sistema.
73
4.1.6.4 Configurar el ambiente de prueba El ambiente de pruebas se lo puede identificar en la Figura 56:
Figura 56. Diseño del sistema de la herramienta webpagetest.org Tomado de Webpagetest, s.f.
El diseño de ambiente de pruebas que tiene WebPageTest.Org permite aprovechar de manera “en línea” las herramientas de análisis para medir el rendimiento de las páginas web lo cual es ideal para proyectos de bajos recursos. Los requisitos básicos para realizar este análisis son los siguientes:
La computadora del usuario donde se pueda acceder a un explorador web.
Estar conectado al internet.
Ingresar una página web dentro de la interfaz de la herramienta.
El servidor web de WebPageTest.com recibe la página web y realiza las pruebas.
74
Para este proyecto se diseñó un ambiente de pruebas con una computadora de placa reducida como lo es el Raspberry Pi:
Figura 57. Raspberry pi model b+
Para las pruebas realizadas se utilizó el modelo B+ (Figura 57.) como un servidor web. Este modelo tiene las siguientes especificaciones técnicas de hardware:
Chip: Broadcom BCM2835 SoC
Arquitectura del núcleo: ARM11
CPU: 700 MHz de Baja Potencia ARM1176JZFS Procesador de Aplicaciones
GPU: Doble Núcleo VideoCore IV® Multimedia Co-Procesador
Provee Open GL ES 2.0, hardware-accelerated OpenVG, y
1080p30 H.264 high-profile decode
Capaz de 1Gpixel/s, 1.5Gtexel/s o 24GFLOPs con filtro de textura
E infraestructura DMA
Memoria: 512MB SDRAM
Sistema Operativo: Arranca desde la tarjeta Micro SD, corre una versión del sistema operativo Linux
Dimensiones: 85 x 56 x 17mm
Poder: Micro USB socket 5V, 2A (Raspberry Pi Foundation, 2015)
75
Figura 58. Topología de conexión de pruebas con el servidor web Raspberry pi model b+ Tomado de Morgan, 2012
La topología para el ambiente de pruebas con el Raspberry Pi (Figura 58.) puede habilitarse usando la función de reenvió de puertos del enrutador, este procedimiento cambia dependiendo del fabricante del enrutador y es recomendable hacerlo por un corto tiempo o no hacerlo dado que expone al equipo a otros usuarios.
Figura 59. Topología implementada de conexión de pruebas con el servidor web Raspberry pi model b+
76
Otro procedimiento realizado como alternativa al ambiente de pruebas (Figura 59.) es utilizar el servicio de la empresa Weaved (Figura 60.)
Figura 60. Logo empresa Weaved Tomado de Weaved, 2016
Weaved (Figura 61.) se encarga de realizar una conexión segura y privada a dispositivos de placa reducida como el Raspberry Pi, BeagleBone, Intel Edison, Linino One, etc, esto con el objetivo de incentivar la tendencia del internet de las cosas o “IoT”. Los servicios que proporciona esta conexión en demanda en línea son:
Conexión Telnet.
Conexión SHH.
Conexión HTTP.
Conexión SFTP.
Conexión SCP.
Conexión RDP.
Conexión VNC.
Función WebIOPI (Exclusiva para el Raspberry Pi y destinada a IoT)
Todos estos servicios los hace sin necesidad de realizar el reenvió de puertos, lo que lo hace una alternativa segura.
77
Las limitaciones que tiene este servicio gratuito son que cada conexión tiene un tiempo de sesión de 30 minutos y una sola conexión simultánea. Estas condiciones pueden ser mejoradas actualizando el plan del servicio lo cual es tiene un precio. (Weaved Inc., 2016)
Figura 61. Topología de conexión de pruebas con Raspberry pi model b+ y el servicio weaved. Tomado de Weaved, 2016
Dentro del software que se cargó en el Raspberry Pi se tiene:
Apache Web Server.- Servidor web que permite albergar páginas web HTTP
PHP.- Lenguaje de programación orientado al desarrollo web
MySQL.- Se considera como el sistema de administración de base de datos libre más popular
Versión del sistema operativo Linux Debian llamado Raspian que es uno de las distribuciones estables del equipo.
Como consideración especial se desarrolló una versión del servicio web de este proyecto en PHP con la finalidad de subir de manera eficiente en pocas líneas de programación el servicio al servidor.
78
Adicional para este tipo de ambiente se requiere otro tipo de herramientas para analizar la velocidad y el tráfico de las páginas web que se cargan en Linux. La herramienta de análisis a usar es:
Seige.- Es una herramienta de pruebas de carga HTTP y utilidad de evaluación comparativa o “benchmarking”
Seige se instala vía un terminal Linux con el siguiente comando:
sudo apt-get install siege
Para correr pruebas se necesita realizar los siguientes pasos:
Generar un archivo de configuración con este comando: siege.config
Se prueba una página web con el siguiente comando: siege –c 10 http://www.example.com
4.1.6.5 Ejecutar tareas
Usando la herramienta PageSpeed Insights se tiene los siguientes resultados tanto para la página de principal (Figura 62.) y para el servicio web (Figura 63.) Página Principal Login.aspx:
Figura 62. Resultado Pagespeed página login
79
Servicio POIS.asmx:
Figura 63. Resultado Pagespeed página pois.asmx
4.1.6.6 Analizar resultados y reportes Los resultados que se recolectaron son positivos en la página de autenticación del usuario con 87 puntos como en el servicio web que tiene 100 puntos y se toma en cuenta que las páginas están albergadas en un dominio de pago como lo es GearHosting.com que maneja en su infraestructura para sus planes equipos empresariales como servidores de arquitectura x86 Intel Xeon E5 2600v3 o mejor (GearHost.com, 2016). Con los resultados obtenidos se tiene estas recomendaciones para mejorar en la interfaz de autenticación o “Login”:
Optimizar las imágenes
Especificar el cache del explorador
Eliminar el JavaScript que bloquea la visualización.
Eliminar el elemento CSS del contenido de la mitad superior de la página.
80
Los resultados del servicio web son aceptables dado que no tienen imágenes o código CSS o JavaScript y solo proporcionan una cadena de datos lo que la hace una página eficiente. Por otra parte los resultados en el ambiente de pruebas donde se usó un equipo Raspberry Pi B+ como servidor web se mostraron los siguientes resultados en comparación de la plataforma de la empresa de web hosting GearHost.com donde esta albergada la página: En base a estas configuraciones se ejecutaron las pruebas:
Prueba con 50 usuarios concurrentes, con puntos de referencia o llamados “Benchmarks” (Se configura la prueba para que no exista retrasos en las solicitudes) y se realiza las pruebas en un tiempo de 2 minutos.
Esto se traduce en un comando para Siege: Siege –c50 –b –t2M “URL”
Prueba con 200 usuarios concurrentes, con puntos de referencia o llamados “Benchmarks” (Se configura la prueba para que no exista retrasos en las solicitudes) y se realiza las pruebas en un tiempo de 2 minutos.
Esto se traduce en un comando para Siege: Siege –c200 –b –t2M “URL”
81
Tabla 22. Resultado de la prueba 1 de benchmarking
Servicio Web en servidor X86 GearHost.com
Servicio Web en servidor Apache Raspberry Pi
Transacciones :11997 accesos Disponibilidad: 99.58 % Tiempo transcurrido : 119.45 segundos Datos transferidos : 5.94 MB Tiempo de respuesta: 0.34 segundos Tasa de Transacción : 100.44 trans / seg Rendimiento: 0,05 MB / seg Concurrencia : 34.03 Transacciones exitosas: 11997 Transacciones fallidas : 50 Mayor transacción : 9.31 Más corta transacción : 0.23
Transacciones :7741 accesos Disponibilidad: 100.00 % Tiempo transcurrido : 120.18 segundos Datos transferidos : 0.86 MB Tiempo de respuesta: 0.77 segundos Tasa de Transacción : 64.41 trans / seg Rendimiento: 0,01 MB / seg Concurrencia : 49.72 Transacciones exitosas: 7741 Transacciones fallidas : 0 Mayor transacción : 4.86 Más corta transacción : 0.36
En la Tabla 23 muestran que el servidor Raspberry Pi permite llegar a un nivel de transacciones muy aceptable considerando el estrés que es sometido. Tabla 23. Resultado de la prueba 2 de benchmarking
Servicio Web en servidor X86 GearHost.com
Servicio Web en servidor Apache Raspberry Pi
Transacciones :536 accesos Disponibilidad: 64.11 % Tiempo transcurrido : 119.49 segundos Datos transferidos : 0.27 MB Tiempo de respuesta: 0.43 segundos Tasa de Transacción : 4.49 trans / seg Rendimiento: 0,00 MB / seg Concurrencia : 1.91 Transacciones exitosas: 536 Transacciones fallidas : 300 Mayor transacción : 1.02 Más corta transacción : 0.24
Transacciones :7463 accesos Disponibilidad: 100 % Tiempo transcurrido : 120.01 segundos Datos transferidos : 0.83 MB Tiempo de respuesta: 1.58 segundos Tasa de Transacción : 62.19 trans / seg Rendimiento: 0.01 MB / seg Concurrencia : 98.47 Transacciones exitosas: 7463 Transacciones fallidas : 0 Mayor transacción : 7.28 Más corta transacción : 0.08
82
En la Tabla 23 muestran que los dos servidores declinan sus transacciones al tener 100 usuarios concurrentes dado que por políticas del servicio GearHost.com permite una cantidad de 250 solicitudes concurrentes en su servicio gratuito (GearHost.com, 2016). En cambio el servidor Raspberry Pi declina el número de transacciones en comparación con la prueba número 1 en la que se tienen solo 50 usuarios, pero se mantiene en el rango 7000 accesos.
4.1.7 Pruebas del sistema móvil Para la parte del sistema móvil se usa la metodología que se aplicó para el sistema web. 4.1.7.1 Entender la visión del proyecto y contexto Para la parte del sistema web se tiene la siguiente visión:
Desarrollar un sistema móvil conformado por una página de presentación que la sigue la experiencia de realidad aumentada que toma la información del servicio web para representar puntos de interés.
Para la parte del sistema web se tienen los siguientes contextos:
Presupuesto: El sistema en un inicio puede crearse a partir de herramientas con costo gratuito y que con la rentabilidad del producto se pueda pagar por funciones especiales para el sistema como por ejemplo expandir la compatibilidad de la aplicación a teléfonos de la marca Apple y también usar características especiales del SDK.
Ambiente de pruebas: El sistema puede implementarse en un dispositivo móvil inteligente compatible con el sistema operativo Android.
Herramientas: Las herramientas pueden estar conformadas por Kits de desarrollo, ambientes de desarrollo integrado IDE, Interfaces de
83
programación de aplicaciones entre otras como servicios web de pruebas de páginas.
Para la parte del sistema móvil se tiene el siguiente entendimiento:
Al estar desarrollado en base a una metodología ágil este sistema va estar sujeto a cambios con el propósito de llegar a tener un producto final deseado.
4.1.7.2 Identificar las razones para realizar una prueba de rendimiento
Se tiene las siguientes razones:
Mejorar la experiencia del usuario. o El factor de imágenes por segundo (conocido por el termino Frames Per Second “FPS”) es importante para tener una experiencia fluida. Se puede capturar esta información con la aplicación para Android llamada GameBench. o La cantidad de puntos de interés va ser fundamental dado que esta puede ocupar toda la pantalla y no mostrar nada de información.
4.1.7.3 Identificar el valor de realizar una prueba de rendimiento El valor agregado de las pruebas tiene como objetivo el conceptualizar una estrategia que se replicaría como mejores prácticas durante el proceso de las pruebas. La estrategia se la realizaría en dos partes: 1. Correr prueba de desempeño con la aplicación Gamebench del sistema móvil.
84
2. Correr prueba de desempeño incrementando los puntos de interés de un área cercana al usuario.
4.1.7.4 Configurar el ambiente de prueba El ambiente de prueba para el sistema móvil es un dispositivo inteligente con las siguientes características:
Red: GSM 850 / 900 / 1800 / 1900 (SIM 1 & SIM 2 opcional) - HSDPA 850 / 900 / 1900 / 2100
Pantalla: LCD TFT touchscreen capacitivo, 16M colores
GPRS: Si
Cámara: 5 MP, 2592х1944 pixels, autofocus, flash LED, geo-tagging, foco táctil, estabilizador de imagen, HDR, video 720p@30fps, cámara frontal 1.3 MP
Wi-Fi 802.11 b/g/n; banda dual, DLNA
GPS con soporte A-GPS, GLONASS
Sistema Operativo: Android OS, v4.3 Jelly Bean (actualización a Android 4.4 KitKat asegurada)
8GB/16GB memoria interna, 1GB RAM
Procesador Qualcomm Snapdragon 400 quad-core 1.2 GHz, GPU Adreno 305
85
4.1.7.5 Ejecutar tareas En la Figura 64, Figura 65 y Figura 66 se realizar pruebas con la aplicación Gamebench y se tiene los siguientes resultados: Presentación:
Figura 64. Prueba con Gamebench presentación de la aplicación
Realidad Aumentada:
Figura 65. Prueba con Gamebench realidad aumentada con 4 pois
86
Figura 66. Prueba con Gamebench realidad aumentada con carga de 60 pois
4.1.7.6 Analizar resultados y reportes Se han realizado pruebas del sistema móvil tanto en su presentación como en el componente de realidad aumentada donde muestran valores en el rango de los 20 FPS y 30 FPS (Figura 66.) que es considerado como un nivel aceptable para que el ojo humano pueda reconocer movimiento fluido sin que se necesite un hardware avanzado, aunque es recomendable optimizar la aplicación para llegar a los 60 FPS que es considerado como el estándar en calidad para el usuario. (Alphabet, 2016) En la prueba de carga de POIS en una sola vista se usó el valor de 60 POIS con el objetivo de sobrepasar el rango recomendado de 50 puntos cuando se recupera desde un servicio web y obtener una prueba de estrés para el sistema y analizar el uso de recursos como el procesamiento, memoria RAM y de la unidad de procesamiento grafico GPU: (Wikitude GmbH, 2015)
87
Tabla 24. Prueba comparativa de realidad aumentada en 1 minuto
Recursos usados en prueba estándar Cantidad de POIS: 4 Tiempo de la prueba: 1 minuto con 3 segundos
Recursos usados en prueba de estrés Cantidad de POIS: 60 Tiempo de la prueba: 1 minuto con 4 segundos
En la Tabla 24 los resultados muestran que ambos escenarios ocupan una utilización de recursos del CPU en un 13%, en el segundo escenario se muestran un incremento de 3 megabytes en la memoria RAM y se aduce al incremento considerable de utilización de la unidad de procesamiento grafico que subió de 36% a un 57% de consumo por la creación de marcadores para los 60 POIS. Con la herramienta Gamebench proporciona un análisis más acertado cuando se prueba la aplicación en un tiempo de 15 o más minutos donde se puede considerar este escenario donde el usuario prueba la aplicación explorando cada punto de interés en un tour por la Universidad. Tabla 25. Prueba comparativa de realidad aumentada en 15 minutos
Recursos usados en prueba estándar Cantidad de POIS: 4 Tiempo de la prueba: 16 minuto con 1 segundos
Recursos usados en prueba de estrés Cantidad de POIS: 60 Tiempo de la prueba: 16 minuto con 4 segundos
En la Tabla 25 los resultados muestran un cambio considerable en la utilización de los recursos a nivel de procesamiento del hardware, la memoria RAM y en el GPU lo que permite constatar la utilización general del hardware al incrementar la cantidad de POIS en un tiempo prolongado.
88
Al probar la aplicación en el área donde están situados los puntos de interés se pudo constatar la diferencia grafica en probar la aplicación dentro de un establecimiento cubierto (Figura 67.) y probar a fuera en el aire libre:
Figura 67. Prueba en ambiente cubierto
Figura 68. Prueba en ambiente semi abierto
89
Figura 69. Prueba en ambiente abierto
Con esta serie de pruebas se identificó que el GPS del dispositivo móvil tuvo una recepción en valores de altura baja dentro de un establecimiento lo cual envió valores estandarizados con respecto al usuario e hizo ver los puntos de interés de manera lineal y uniforme. Por otro en el ambiente semi abierto (Figura 68.) los puntos de interés se mostraron levemente desubicados y en cambio en el ambiente abierto (Figura 69.) los puntos de interés se dibujaron en el suelo dado que el SDK de Wikitude pudo obtener datos de la altura y estos fueron registrados con valores de 100.0 metros lo cual hizo que se mostraran en el suelo. Para solucionar esta reacción se pueden especificar valores de altura más precisos recolectando esta información con aplicaciones como GPS Status (Figura 70.) que muestran la información del GPS.
Figura 70. Recolección de datos gps
90
Adicional a las pruebas de rendimiento se realizó una encuesta de satisfacción del usuario donde se realizaron las siguientes preguntas a 10 usuarios con el objetivo de recibir información útil sobre el la aplicación y funcionamiento: 1. ¿Le resulto sencillo acceder a la experiencia de Realidad Aumentada en esta aplicación?
Permite identificar si la aplicación tiene accesos fáciles a las funciones principales. Resultado: 90% Si y 10% No
2. ¿Pudo visualizar los puntos de interés de la universidad?
Permite identificar si la función principal de la aplicación es ejecutada con éxito. Resultado: 77.78% Si y 22.22% No
3. ¿Alguna etiqueta de los puntos de interés, no pudo ser identificada o leída?
Permite identificar si existe una sobre carga de POIS en la pantalla. Resultado: 30% Si y 70% No
4. ¿Cuántos puntos de interés pudo identificar?
Permite validar si los resultados que muestra la aplicación tienen relación con la base de datos del sistema web. Resultado: 44.44% Pudo identificar 4 POIS, 22.22% Identificó 6 POIS y 33.33% identificó 8 POIS
5. ¿Al ingresar a la aplicación sintió alguna falla de rendimiento, como lentitud?
Permite identificar por medio de la percepción de usuario si existe un nivel muy inferior en FPS. Resultado: 40% Identificó lentitud, 60% No identificó.
91
Los resultados de esta encuesta fue enfocada a un grupo selecto de usuarios que cumplían con las siguientes condiciones:
Usuarios de Android
Estudiantes Universitarios
Estudiantes de Ingeniería
Las condiciones ayudaron a tener respuestas más precisas sobre el sistema móvil y consecuente se pudo modificar fallas de rendimiento como la carga inmediata de la página principal y la aglomeración de POIS en la vista del usuario.
92
5. CONCLUSIONES Y RECOMENDACIONES. 5.1 Conclusiones La especificación de requisitos funcionales como no funcionales en el diseño de los sistemas es un paso importante por que determina una base en la que el proyecto se va a guiar para completar cada característica y función que se desee como resultado. El uso de una metodología ágil ayudo a que existiera un orden al crear el producto final y dio la posibilidad de ir mejorando dependiendo de los requerimientos u objetivos planteados. Wikitude SDK permitió que se tuviera un vasto conjunto de ejemplos de realidad aumentada orientada a la geolocalización de POIS y que se tuviera la capacidad de recuperarlos de información interna del sistema o que se conecte a un servicio web. Fue necesario utilizar un serializador JSON implementado en Visual Studio para que la información obtenida de la base de datos tenga el formato correcto para que el sistema móvil pueda leer los POIS. La realidad aumentada es una tecnología que depende en gran parte del rendimiento y capacidades de la infraestructura esto se da al estar implementada en una aplicación móvil que utiliza la geolocalización, la conexión a internet y la unidad de procesamiento CPU y GPU. El proyecto al estar enfocado en un ambiente universitario puede enfocarse en otras áreas y funciones relacionadas como por ejemplo el levantamiento de casos del departamento de TI visto en un enfoque más visual en donde el ingeniero pueda ver el bloque o sede donde se necesita su ayuda.
93
5.2 Recomendaciones Al realizar las pruebas del sistema web se recomienda en el caso de orientar el proyecto a un nivel empresarial utilizar servidores o contratar el servicio de hosting por las capacidades tecnológicas y de seguridad que se tienen y en el caso de orientar el sistema web a un entorno de pruebas se recomienda el uso de ordenadores de placa reducida como el Raspberry Pi por los beneficios de un menor costo. Para evitar la sobre carga de puntos de interés en la vista del usuario se puede optar por fijar una cantidad máxima en una capa que tendría el propósito de enfocar al usuario a encontrar algo en específico en conjunto como una capa donde se en encuentren solo las paradas de los buses. Wikitude SDK permite especificar con gran precisión la longitud y latitud de un área geográfica pero depende de la precisión y tecnología del GPS del teléfono para permitir que se visualice con alturas en específico los puntos de interés, por esto se recomienda probar las aplicaciones en lugares abiertos o a su vez mantener una sola altura. Para el ambiente de pruebas con la placa de dimensiones reducidas Raspberry Pi B+ se recomienda comprar o fabricar una caja que permita acceder a sus puertos y conexiones con el objetivo de manipular de forma segura el equipo evitando el riesgo que esta se dañe por el ambiente. Si se opta por utilizar al Raspberry Pi B+ se recomienda adicional incorporar un ventilador y disipadores de calor dado que la placa puede calentarse con el uso prolongado y sobre todo con la sobre carga de procesamiento gráfico.
94
REFERENCIAS
Alphabet. (2016). Testing display performance. Recuperado el 2 de enero de 2016 de http://developer.android.com/intl/es/training/testing/performance.html Alphabet. (s.f.). Android interfaces and architecture. Recuperado el 15 de agosto de 2015 de https://source.android.com/devices/ Apple. (2015). Swift. a modern programming language that is safe, fast, and interactive. Recuperado el 15 de septiembre de 2015 de https://developer.apple.com/swift/ Artificial Life, INC. (s.f.). Augemented reality tools. Recuperado el 27 de marzo de 2016 de http://www.artificial-life.com/en/intellectual/ar Banik, A. (s.f.). Difference between asp.net wcf services and asmx web services. Recuperado
el
8
de
junio
de
2015
de
http://www.encodedna.com/wcf/tutorial/difference-between-aspdotnet-wcfservices-and-asmx-services.htm Bell, D. (2004). Uml basics: the component diagram. Recuperado el 27 de mayo de 2015 de http://www.ibm.com/developerworks/rational/library/dec04/bell/ Bloor, R. (2014). Mapping it out: apis for location-based apps. Recuperado el 25 de junio de http://www.developereconomics.com/mapping-apis-location-based-apps/ Chau, M., Ryan, R., & Jitesh, U. (2015). Smartphone os market share, q1 2015. Recuperado
el
26
de
mayo
de
2016
de
http://www.idc.com/prodserv/smartphone-os-market-share.jsp Christensson, P. (2006). Gps. Recuperado el 10 de septiembre de 2015 de http://techterms.com/definition/gps Christensson, P. (2014). Javascript definition. Recuperado el 10 de septiembre de 2015 http://techterms.com Christensson, P. (2015). Api definition. Recuperado el 17 de enero de 2016 de http://techterms.com/definition/api Christensson, P. (2015). Framework definition. Recuperado el el 17 de enero de 2016 de http://techterms.com/definition/framework
95
Christensson, P. (2015). Sdk definition. Recuperado el el 10 de septiembre de 2015 de http://techterms.com/definition/sdk Cillero, M. (s.f.). Modelo entidad/relación extendido. Recuperado el 12 de diciembre de 2015 de http://manuel.cillero.es/doc/metrica-3/tecnicas/modelo-entidad-relacionextendido CiteSeerX. (2015). Simultaneous localization and mapping for augmented reality. Recuperado
el
27
de
marzo
de
2016
de
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.188.2678 Dartmouth College . (2015). Augmented reality: about ar. Recuperado el 27 de abril de 2015 de http://researchguides.dartmouth.edu/c.php?g=59732&p=382858 El Universo. (2014). Hoy se inaugura la matriz de la universidad de las artes. Recuperado el 12 de julio de 2015 de http://www.eluniverso.com/vidaestilo/2014/02/11/nota/2169081/hoy-se-inaugura-matriz-universidad-artes Ferguson, J., Patterson, B., Beres, J., Boutquin, P., & Gupta, M. (2003). La biblia de c#. Recuperado
el
28
de
mayo
de
2015
de
https://norbertomn.files.wordpress.com/2014/09/anaya1-la-biblia-de-c__libroprogramacion-espa_ol__muestras_gratis_para_que_pruebes_en_tu_cas.pdf Gartner. (2015). 2015 Gartner magic quadrant for operational database management systems.
Recuperado
el
27
de
marzo
de
2016
de
https://www.mongodb.com/collateral/gartner-mq-2015 GearHost.com. (2016). Difference between free, shared, and reserved plans. Recuperado
el
2
de
enero
de
2016
de
https://www.gearhost.com/documentation/difference-free-shared-reservedplans GearHost.com. (2016). Frequently Asked Questions. Recuperado el el 2 de enero de 2016 de https://www.gearhost.com/faq/technical/general Google. (2015). Android interfaces. Recuperado el 11 de agosto de 2015 de https://source.android.com/devices/ Google. (2015). Public class activity. Recuperado el 16 de enero de 2016 de http://developer.android.com/reference/android/app/Activity.html
96
Google. (2015). The android source code. Recuperado el 28 de mayo de 2015 de https://source.android.com/source/index.html IBM Corporation. (2015). Ibm rational modeler. Recuperado el 19 de diciembre de 2015 de http://www.ibm.com/developerworks/downloads/r/modeler/ IDC Research. (2015). Smartphone os market share, 2015 q2. Recuperado el 20 de junio de 2015 de http://www.idc.com/prodserv/smartphone-os-market-share.jsp Lepetit, V., & Fua, P. (2005). Monocular model-based 3d tracking of rigid objects: A Survey.
Recuperado
el
13
de
enero
de
2016
de
http://www.nowpublishers.com/article/Details/CGV-001 Lookar.net.
(s.f.).
Tutorial.
Recuperado
el
28
de
mayo
de
2015
de
http://www.lookar.net/tutorial/ Meier, J., Farre, C., Bansode, P., Barber, S., & Rea, D. (27 de Agosto de 2008). Patterns & practices performance testing guidance for web . Recuperado el 19 de diciembre
de
2015
de
http://perftestingguide.codeplex.com/downloads/get/17955 Metodologiascrum.readthedocs.org. Recuperado
el
5
(2015).
¿Que
de
es
abril
una
metodología
de
ágil?
2015
de
http://metodologiascrum.readthedocs.org/en/latest/Scrum.html#que-es-scrum Metz, C. (2015). Sorry, but google glass isn’t anywhere close to dead. Recuperado el 19 de diciembre de 2015 de http://www.wired.com/2015/02/sorry-google-glass-isntanywhere-close-dead/ Microsoft. (2015). Administrar referencias en un proyecto. Recuperado el 22 de agosto de 2015 de https://msdn.microsoft.com/es-ec/library/ez524kew.aspx Microsoft. (2015). Building apps for Windows devices using open source technologies. Recuperado el 22 de agosto de 2015 de https://msopentech.com/opentechprojects/building-apps-for-windows-devices-using-open-sourcetechnologies/#about Microsoft.
(2015).
Datatables.
Recuperado el
15
de
agosto
de
2015
de
https://msdn.microsoft.com/es-es/library/t31h6yhs(v=vs.110).aspx Microsoft. (2015). Herramientas para todos los desarrolladores y todas las aplicaciones. Recuperado el 22 de agosto de 2015 de https://www.visualstudio.com/
97
Microsoft. (2015). Common language runtime (CLR). Recuperado el 17 de octubre de 2015 de https://msdn.microsoft.com/en-us/library/8bs2ecf4(v=vs.110).aspx Microsoft. (2015). Ado.net. Recuperado el el 17 de octubre de 2015 de https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx Microsoft. (2015). Resumen de las características de C#. Recuperado el 27 de octubre de 2015 de https://msdn.microsoft.com/es-ec/library/aa287483(v=vs.71).aspx Microsoft. (2016). Compare visual studio 2015 offerings. Recuperado el 27 de marzo de 2016 de https://www.visualstudio.com/en-us/products/compare-visual-studio2015-products-vs.aspx Microsoft. (2016). Installing visual studio. Recuperado el 27 de marzo de 2016 de https://msdn.microsoft.com/en-us/library/e2h7fzkw.aspx Morgan, J. (2012). The Raspberry pi web server speed test. Recuperado el 19 de diciembre
de
2015
de
https://www.jeremymorgan.com/blog/programming/raspberry-pi-web-servercomparison/ Neumman, U., & You, S. (1999). Natural feature tracking for augmented reality. (1a. ed.). Los Angeles, Estados Unidos: IEEE. Newtonsoft. (2015). Serializing and deserializing json. Recuperado el 27 de marzo de 2015 de http://www.newtonsoft.com/json/help/html/serializingjson.htm Oracle. (2016). The main features of mysql. Recuperado el 10 de enero de 2016 de http://dev.mysql.com/doc/refman/5.7/en/features.html Oracle Corporation. (2015). Mysql community edition. Recuperado el 18 de julio de 2015 de https://www.mysql.com/products/community/ Oracle Corporation. (2015). Mysql community edition. Recuperado el 18 de julio de 2015 de http://www.oracle.com/us/products/mysql/mysqlcommunityserver/overview/inde x.html Oracle Corporation. (2015). The java tutorials: interfaces. Recuperado el 23 de mayo de 2015 de http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html
98
Ortiz, D. (2015). La Universidad de las Américas inauguró su nuevo campus. Recuperado
el
12
de
julio
de
2015
de
http://www.elcomercio.com/tendencias/universidaddelasamericas-campusudlapark-inauguracion-quito.html O'Shaughnessey, P. (2014). Mobile ar sdk tutorial - augmented world expo new york 2014.
Recuperado
el
13
de
junio
de
2015
de
http://www.slideshare.net/patrickoshaughnessey/2014-0325augmentedworldexpomobilearsdktutorial Palkovic, R. (2008). Sun and mysql: how it stacks up for developers. Recuperado el 18 de julio de 2015 de http://www.oracle.com/technetwork/articles/java/mysql-acq139875.html Phil. (2015). Introducing: Wikitude SDK 5. Recuperado el 28 de mayo de 2015 de http://www.wikitude.com/blog-wikitude-sdk-5-0/#android_studio Prijic, G. (2014). Introduction to scrum. Recuperado el 17 de septiembre de 2015 de http://www.vivifyideas.com/introduction-to-scrum/ Ramirez, E. (2004). Tema 6: El método experimental. Andalucia, España: Universidad de Jáen. Raspberry Pi Foundation. (2015). Raspberry Pi Model B+. Recuperado el 9 de enero de 2016 de https://www.adafruit.com/datasheets/pi-specs.pdf Rauterberg, M. (2012). History of HCI. Recuperado el 23 de mayo de 2015 de http://www.idemployee.id.tue.nl/g.w.m.rauterberg/presentations/hcihistory/sld096.htm Reitmayr, G., Graz Univ. of Technol., G. A., Langlotz, T., Wagner, D., & Mulloni, A. (2010). Simultaneous localization and mapping for augmented reality. Gwangju, Corea del Sur: IEEE. Rodríguez, L. (2010). Fundamentos de Interacción persona-ordenador. Madrid, España: Universidad Pontificia de Salamanca. Schwaber, K., & Sutherland, J. (2013). The Scrum guide™. Texas, Estados Unidos: Creative Commons.
99
Thomas Reicher, A. M. (2003). Results of a study on software architectures for augmented reality systems. Recuperado el 6 de junio de 2015 de http://www.computer.org/csdl/proceedings/ismar/2003/2006/00/20060274.pdf University of Oxford. (2006). 3D visual tracking of articulated objects and hands. Recuperado
el
25
de
marzo
de
2016
de
http://www.robots.ox.ac.uk/~teo/thesis/Thesis/deCampos3DHandTracking5.pdf Vivify
Scrum.
(s.f.).
How
it
works.
Recuperado
el
28
de
noviembre
de
https://www.vivifyscrum.com/feature/how-it-works Weaved. (2016). Connect your business. Recuperado el 13 de enero de 2016 de http://www.weaved.com/remote-connect-commercial-devices/ Weaved. (2016). Manage networked devices from anywhere. Recuperado el 13 de enero de 2016 de http://www.weaved.com/ Weaved
Inc.
(2016).
FAQ´s.
Recuperado
el
13
de
enero
de
2016
de
https://www.weaved.com/FAQ/ Webpagetest. (s.f.). System design. Recuperado el 19 de diciembre de 2015 de https://sites.google.com/a/webpagetest.org/docs/system-design/overview WebPageTest.Org. (2015). Webpagetest documentation. Recuperado el el 22 de diciembre de 2015 de https://sites.google.com/a/webpagetest.org/docs/usingwebpagetest/metrics Western Australian Land Information Authority. (2015). Plugin for quantum gis now available.
Recuperado
el
27
de
marzo
de
2016
de
https://www0.landgate.wa.gov.au/news/newsletter/land-lens/land-lens-april2015 Wikimedia Commons. (2011). Wikitude world browser . Recuperado el 25 de marzo de 2016
de
https://commons.wikimedia.org/wiki/File:Wikitude_World_Browser_@Salzburg_ Old_Town_3.jpg Wikitude GmbH. (2015). Wikitude SDK. Recuperado el 29 de agosto de 2015 de http://www.wikitude.com/products/wikitude-sdk/ Wikitude GmbH. (2015). Wikitude webservice documentation. Recuperado 29 de agosto de
2015
de
http://www.wikitude.com/developer/knowledge-
100
base?p_p_id=4_WAR_knowledgebaseportlet_INSTANCE_pQeXf2Lqbrmf&p_p _lifecycle=0&p_p_state=maximized&p_p_mode=view&_4_WAR_knowledgebas eportlet_INSTANCE_pQeXf2Lqbrmf_mvcPath=%2Fsection%2Fview_article.jsp &_4_WAR_knowl