Desarrollo de una aplicación de realidad aumentada para entornos educativos

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Desarrollo de una aplicaci´ on de realidad aumentada para entornos educativos Autor: Guillermo Mu˜noz Crespo Tutores: Alejandra Mart´ınez Mon´es Juan Ignacio Asensio P´erez 2 Resumen El presente trabajo aborda el redise˜no y actualizaci´on tecnol´ogica de la aplicaci´on BusketServer destinada a entornos educativos y cuyo prop´osito fundamental es dar soporte a los educadores en situaciones de aprendizaje ligadas a diferentes espacios, sean virtuales o f´ısicos. En el primer caso, el entorno formativo se basa en desarrollos de tipo web mientras que en el segundo se hace uso del paradigma de la realidad aumentada. El objetivo ´ultimo ha sido redise˜nar y actualizar aquellos componentes e interfaces que debido al transcurso del tiempo se han quedado obsoletos facilitando de este modo al usuario la interacci´on con la aplicaci´on. 3 4 Abstract This project deals with the redesign and technological update of the BusketServer application for educational environments, whose main purpose is to support educators in learning situations linked to different spaces, whether virtual or physical. In the first case, the training environment is based on web-based developments, while in the second case, the augmented reality paradigm is used. The ultimate goal has been to redesign and update those components and interfaces that, due to the passage of time, have become obsolete, thus facilitating the user’s interaction with the application. 5 6 ´ Indice 1. Introducci´on 15 1.1. Contexto .......................................... 15 1.2. Motivaci´on ......................................... 17 1.3. Alcanceyobjetivos..................................... 17 1.4. Estructuradeldocumento................................. 17 2. An´alisis de tecnolog´ıas de realidad aumentada 19 2.1. Criteriosdeselecci´on.................................... 19 2.2. Listado de tecnolog´ıas seleccionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3. Tabla de comparaci´on de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4. AR.js ............................................ 22 2.4.1. PosicionamientoGPS ............................... 23 2.4.2. Posicionamiento marcadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.3. Posicionamiento imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3. An´alisis de requisitos 27 3.1. Definici´ondeactores.................................... 27 3.1.1. Administrador ................................... 27 3.1.2. Profesor....................................... 27 3.1.3. Alumno ....................................... 27 3.1.4. Proveedor de artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2. Requisitosfuncionales ................................... 28 3.3. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Plan de proyecto 31 4.1. Planificaci´on ........................................ 31 4.1.1. Ciclo de vida del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2. Gesti´ondelproceso..................................... 32 4.2.1. Planinicial ..................................... 32 4.2.2. Plandetrabajo................................... 33 4.3. Plan de gesti´on de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1. Listadoderiesgos ................................. 41 4.4. Presupuesto......................................... 44 5. Modelo de an´alisis 45 5.1. Casosdeusodelsistema.................................. 45 5.1.1. Visualizar marcadores de los artefactos . . . . . . . . . . . . . . . . . . . . . . 47 7 5.1.2. ModoAR...................................... 47 5.2. Modelodedominio..................................... 49 6. Dise˜no 51 6.1. Arquitecturadelsistema.................................. 51 6.1.1. Arquitectura del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.1.2. Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.1.3. Arquitecturacliente ................................ 54 6.2. Patr´onArquitect´onico ................................... 54 6.3. Dise˜no de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.1. Interfaz modo AR marcador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.2. Interfaz modo AR localizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.3. Interfazmodoweb ................................. 56 6.4. Diagramasdesecuencia .................................. 58 6.4.1. Diagrama visualizar marcadores y c´odigos QR del artefacto . . . . . . . . . . 58 6.4.2. Diagrama leer QR para acceder al modo AR . . . . . . . . . . . . . . . . . . 59 6.4.3. Diagrama modo AR marcador . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4.4. Diagrama modo AR localizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.4.5. Diagrama acceder artefacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7. Implementaci´on 63 7.1. Entornodedesarrollo ................................... 63 7.2. Herramientasutilizadas .................................. 63 7.3. Controldeversiones .................................... 63 7.4. Librer´ıasutilizadas..................................... 64 7.5. Servidorutilizado...................................... 64 7.6. Basededatosutilizada................................... 65 8. Plan de pruebas y validaci´on 67 8.1. Pruebas vista marcadores y QRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 8.2. Creaci´on c´odigo QR para acceder al modo AR . . . . . . . . . . . . . . . . . . . . . 68 8.3. Pruebas modo AR marcador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8.4. Pruebas modo AR localizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.5. Pruebas de interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 9. Conclusiones y trabajo futuro 71 9.1. Conclusiones ........................................ 71 9.2. Trabajofuturo ....................................... 71 9.3. Valoraci´onpersonal..................................... 72 Anexos 75 I. Manual de instalaci´on 77 I.1. Requisitos.......................................... 77 I.2. Aplicaci´onBucketServer.................................. 77 I.3. Basededatos........................................ 78 I.4. ServidorApache ...................................... 79 I.4.1. Configuraci´on SSL Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 8 I.4.2. Configuraci´on proxy reverse Apache . . . . . . . . . . . . . . . . . . . . . . . 81 II. Manual de usuario 83 III. Enlaces de descarga 89 9 Dentro de la aplicaci´on BucketServer se utilizan Puntos de inter´es (POIs, de sus siglas en ingl´es, Points of Interest). Los POIs son puntos de ubicaci´on espec´ıfica que alguien puede encontrar ´util o interesante, para describir el espacio f´ısico donde se van a ubicar los buckets y artefactos que se creen. En la Figura 1.1 se muestra un ejemplo del funcionamiento de la aplicaci´on Bucketserver con la plataforma Moodle. En tiempo de dise˜no (Design Time), un profesor crea y configura el bucket seleccionando el n´umero m´aximo de artefactos que se pueden incluir en ´el, tipo de artefactos, tipo de posicionamiento... M´as tarde, durante la clase presencial los alumnos pueden crear artefactos y posicionarlos como se muestra en la actividad 1 (Activity 1 en la Figura). Para la creaci´on de artefactos la aplicaci´on BucketServer se conecta con los proveedores de artefactos (Artifacts providers), que son los encargados de la creaci´on de los artefactos y sus distintos tipos: Google Document, una foto, un enlace a Wikipedia... Una vez han sido creados, se puede acceder a ellos en diferentes espacios, con distintas aplicaciones de realidad aumentada, como pueden ser Junaio 2 oLayar 3 . El grupo 2 formado por alumnos como se muestra en la actividad 2 (Activity 2 en la Figura), acceden al posicionamiento de los artefactos con la aplicaci´on Junaio para visualizarlos en realidad aumentada y poder disfrutar de la actividad interactiva y educativa. En la actividad 3 (Activity en la Figura), se trata de una alternativa a la actividad 2 donde el grupo 2 accede al posicionamiento de los artefactos con la aplicaci´on Google Earth, para acceder a un mundo virtual en 3D. Adem´as de la aplicaci´on Junaio, en la actividad 2, BucketServer utilizaba otras aplicaciones de realidad aumentada. Con el paso del tiempo ´estas han quedado obsoletas y ha sido necesario buscar una alternativa tecnol´ogica para poder suplir esa carencia dentro de la aplicaci´on BucketServer. Figura 1.1: Sistema Bucket-Server y ejemplo de uso [24] 2 Junaio - Era una aplicaci´on m´ovil de un navegador AR para dispositivos m´oviles 3G y 4G: https://en.wikiped ia.org/wiki/Junaio 3 Navegador m´ovil que permite a los usuarios encontrar elementos en realidad aumentada: https://www.layar.com/ 16 1.2. Motivaci´on Actualmente existe la necesidad de actualizar la parte de realidad aumentada dentro de la aplicaci´on BucketServer debido a que las aplicaciones de realidad aumentada que utilizaba BucketServer han quedado obsoletas por diversos factores como: La venta de las aplicaciones a otras compa˜n´ıas y el cambio de funcionalidad de las aplicaciones. BucketServer es una aplicaci´on web educativa que se encarga de la creaci´on y configuraci´on de los buckets y artefactos, esta web almacena los datos en su base de datos. Estos datos eran utilizados en diversas actividades, como por ejemplo la visualizaci´on de un mundo virtual 3D o la visualizaci´on en realidad aumentada, en nuestro caso la actividad que m´as nos interesa es la de la realidad aumentada, que es en la que se centra la mayor parte del proyecto. La aplicaci´on BucketServer se conectaba con las aplicaciones de realidad aumentada Junaio,Layar... a trav´es de su API REST, creando un canal de comunicaci´on entre dichas aplicaciones, envi´andole los datos necesarios que hab´ıan sido almacenados con anterioridad en la base de datos de BucketServer, para poder crear puntos de inter´es dentro de la aplicaci´on de realidad aumentada y poder visualizarlos. Adem´as de la actualizaci´on de la parte de realidad aumentada dentro de la aplicaci´on BucketServer era necesario actualizar la documentaci´on, para poder ofrecer un mejor manejo de la aplicaci´on y que el usuario fuera consciente de todas las funcionalidades que le puede brindar. 1.3. Alcance y objetivos El objetivo del proyecto es renovar las partes en desuso de la aplicaci´on BucketServer, enfoc´andose en la parte de AR de la aplicaci´on. Finalmente, los objetivos definidos son los siguientes: Seleccionar la tecnolog´ıa AR m´as adecuada para suplir a las existentes. Actualizar la parte de realidad aumentada de la aplicaci´on BucketServer: • Disponer en la aplicaci´on BucketServer de una nueva funcionalidad de realidad aumentada, que permita reconocer marcadores para mostrar un artefacto de un bucket con la c´amara del dispositivo. • Disponer en la aplicaci´on BucketServer de una nueva funcionalidad de realidad aumentada, que permita visualizar los artefactos de un bucket con la c´amara del dispositivo en su ubicaci´on exacta. Actualizar la documentaci´on para que la aplicaci´on sea mantenible en un futuro. 1.4. Estructura del documento La estructura que se ha utilizado en la memoria es la siguiente: Cap´ıtulo 1. Introducci´on. Presenta el TFG. Cap´ıtulo 2. An´alisis de tecnolog´ıas realidad aumentada. An´alisis comparativo de las aplicaciones AR, caracter´ısticas y funciones. Cap´ıtulo 3. An´alisis de requisitos. Define requisitos funcionales y no funcionales. 17 Cap´ıtulo 4. Plan de proyecto. Organiza el proyecto, sus etapas y riesgos. Cap´ıtulo 5. Modelo de an´alisis. Describe casos de uso y diagramas de modelo de dominio. Cap´ıtulo 6. Dise˜no. Fase de dise˜no software. Cap´ıtulo 7. Implementaci´on. Explica las t´ecnicas y herramientas software utilizadas para el desarrollo del proyecto. Cap´ıtulo 8. Plan de pruebas y validaci´on. Presenta las diferentes pruebas ejecutadas y su validaci´on para la aplicaci´on. Cap´ıtulo 9. Conclusiones y trabajo futuro. Describe la conclusi´on final, objetivos conseguidos, trabajo futuro y valoraci´on personal. Anexo I. Manual de instalaci´on. Describe la instalaci´on de la aplicaci´on. Anexo II. Manual de usuario. Explica el uso de la aplicaci´on para el usuario. 18 Cap´ıtulo 2 An´alisis de tecnolog´ıas de realidad aumentada En este cap´ıtulo vamos a realizar un an´alisis de tecnolog´ıas AR, con el fin de seleccionar la m´as apropiada para las necesidades del proyecto. 2.1. Criterios de selecci´on Para el an´alisis de una tecnolog´ıa es necesario utilizar una serie de criterios, para escoger la mejor herramienta AR: App m´ovil AR/Bibliotecas AR web - Definir si se trata de una aplicaci´on m´ovil AR o bibliotecas AR, que permitan agregar nuevas funcionalidades dentro de la p´agina web. Es necesaria una aplicaci´on externa que se pueda vincular a BucketServer o utilizar bibliotecas que nos permitan introducir la funcionalidad de realidad aumentada. Comunidad Activa - La existencia de una comunidad que tenga una implicaci´on en el proyecto, d´andole apoyo y soporte, es muy importante, lo que supone la tecnolog´ıa AR no quede en desuso. Adem´as si va a existir un mantenimiento de la aplicaci´on, es necesario un soporte por si ocurre alg´un problema. Lenguajes de Programaci´on - Este criterio indica qu´e lenguaje de programaci´on utiliza la tecnolog´ıa que estamos analizando. Es importante, porque en igualdad de condiciones, se puede preferir una tecnolog´ıa compatible con los lenguajes de programaci´on utilizados en la aplicaci´on existente como Javascript,Java... API Web - Disponibilidad de una API (Application Programming Interfaces) web bien documentada, en la que la aplicaci´on m´ovil hace uso de un backend y se pueden realizar peticiones REST a esta API para obtener esos datos. Este criterio es fundamental porque sin la existencia de una API web no se pueden obtener los datos necesarios para el desarrollo de la funcionalidad de realidad aumentada. Coste - Especificar si la aplicaci´on es de uso gratuito o si es de pago. Este criterio es importante porque siempre tendr´a prioridad las tecnolog´ıas gratuitas a las de pago. Tipo de posicionamiento - Cada vez que se genere un artefacto y se quiera posicionar en un lugar de inter´es es necesario generar un POI con la herramienta AR que represente dicho artefacto. Este criterio es imprescindible para el uso de POIs en la aplicaci´on BucketServer. 19 Dentro de su importancia, existen varias categor´ıas de posicionamiento bas´andonos en los que ya ten´ıan BucketServer: •Geoposici´on - Permite crear puntos de inter´es, seleccionando las coordenadas GPS. •Marcador - Permite utilizar marcadores para posicionar puntos de inter´es. •Imagen - Utiliza una imagen como modo de posicionamiento para mostrar la informaci´on. 2.2. Listado de tecnolog´ıas seleccionadas Inicialmente, vamos a realizar un estudio detallado de qu´e aplicaciones de AR hay disponibles y cu´ales se adaptan mejor a nuestros criterios. En Google Scholar 1 yGoogle 2 fueron los motores de b´usqueda, para encontrar informaci´on. Se encuentraron varias p´aginas de las mejores apps AR para el desarrollo software [18] [17]. Tambi´en hice un estudio de las tecnolog´ıas que pudiesen a˜nadir la parte de AR, dentro de una aplicaci´on web. Los resultados de las tecnolog´ıas encontradas y que vamos a analizar son: Wikitude [7] Vuforia [6] ARCore [1] EasyAR [5] MaxST [15] ARToolkit [4] [9] Kudan [13] [14] ARpoise [12] [3] GeoAR [8] Layar [10] AR.js [12] 2.3. Tabla de comparaci´on de resultados En esta secci´on hemos creado una tabla para la comparaci´on de los resultados, para que se puedan observar las diferencias que hay de unas a otras tecnolog´ıas de forma clara, precisa y sencilla. Se puede observar en la Figura 2.1 Observando la Figura 2.1 podemos deducir, que muchas de las tecnolog´ıas que hay en el mercado o bien no se ajustan a nuestros criterios o se han quedado obsoletas. 1Google Scholar - https://scholar.google.es/schhp?hl=es 2Google - https://www.google.es/ 20 Figura 2.1: Tabla de comparaci´on de las tecnolog´ıas AR 21 Dentro de las aplicaciones AR, GeoAR yLayar no tienen una comunidad activa, por lo que quedan descartadas. El criterio del tipo de posicionamiento, se cumple en la mayor´ıa de aplicaciones que se crean de cero, a excepci´on de MaxST yARPoise. MaxST, carece de una API web cualificada para este fin, por lo tanto dentro de las aplicaciones AR la mejor opci´on es ARPoise. Dentro de las bibliotecas AR web se encuentra AR.js. Estas tienen una comunidad activa, su lenguaje de programaci´on es JavaScript, al igual que la aplicaci´on BucketServer. Tiene una API clara y detallada de su funcionamiento. Pudiendo crear tres tipos de posicionamiento, lo que permite aumentar el n´umero de posibilidades de las bibliotecas, siendo su uso es gratuito. Las dos opciones posibles de uso, son la aplicaci´on externa ARPoise o las bibliotecas de AR.js. ARPoise nos permite mantener la estructura del proyecto BucketServer de la parte de realidad aumentada, de la que se encargaba una aplicaci´on externa. AR.js se puede utilizar dentro de la propia aplicaci´on BucketServer y su lenguaje de programaci´on es compatible, adem´as permite crear tres tipos de posicionamiento, geoposici´on, marcador e imagen, mientras que ARPoise solo permite el tipo de posicionamiento de geoposici´on. La decisi´on final ha sido utilizar la tecnolog´ıa de bibliotecas AR de AR.js; con tres tipos de POIs ofrece un mayor n´umero de posibilidades, es compatible con el lenguaje de programaci´on que ya exist´ıa y su implementaci´on se puede hacer de forma sencilla ya que requiere de pocas lineas de c´odigo para disponer de una peque˜na demostraci´on de c´omo funciona. 2.4. AR.js AR.js es una biblioteca para realidad aumentada en web, que tiene unas caracter´ısticas de posicionamiento de im´agenes, ubicaci´on y marcadores [2]. Los puntos claves de esta biblioteca web son: Basado en web : Es una soluci´on web, que no requiere de ninguna instalaci´on. Utiliza Javascript basado en three.js +A-Frame +jsartoolkit5. Ar.js utiliza jsartoolkit5 para el seguimiento, pero puede mostrar contenido aumentado con three.js oA-Frame. C´odigo abierto: Es completamente gratuito y de c´odigo abierto. Requisitos: Funciona en cualquier tel´efono con webgl3ywebrtc4. Con esta tecnolog´ıa se pueden crear tres tipos de posicionamiento de realidad aumentada: posicionamiento en una imagen, posicionamiento en unas coordenadas GPS o posicionamiento en un marcador. 3 M´etodo de generar gr´aficos 3D usando JavaScript, acelerado a trav´es del hardware: https://caniuse.com/webgl 4 M´etodo para acceder a los datos de dispotivos externos como el v´ıdeo de una webcam: https://caniuse.com/st ream 22 2.4.1. Posicionamiento GPS Para este caso es necesario solamente crear un archivo html donde se van a importar las bibliotecas de AR.js y definir el punto de las coordenadas GPS donde aparecer´a el objeto. La etiqueta “a-scene” sirve para definir la escena de la c´amara donde se definen los elementos que van a aparecer en la c´amara. La etiqueta “a-text” es el texto que se va a mostrar, la cual tiene varios atributos: el valor que es el contenido del texto, look-at utiliza el GPS de la c´amara para ubicarse y comparar las coordenadas, su escala y gps-entity-place son las coordenadas donde va a estar situado el texto. <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <title>GeoAR.js demo</title> <script src="https://aframe.io/releases/1.0.4/aframe.min.js"></script> <script src="https://unpkg.com/[email protected]/ dist/aframe-look-at-component.min.js"></script> <script src="https://raw.githack.com/AR-js-org/AR.js/master/aframe/build/ aframe-ar-nft.js"></script> </head> <body style="margin: 0; overflow: hidden;"> <a-scene vr-mode-ui="enabled: false" embedded arjs="sourceType: webcam; debugUIEnabled: false;" > <a-text value="This content will always face you." look-at="[gps-camera]" scale="120 120 120" gps-entity-place="latitude: <add-your-latitude>; longitude: <add-your-longitude>;" ></a-text> <a-camera gps-camera rotation-reader> </a-camera> </a-scene> </body> </html> Dentro del dispositivo m´ovil solo es necesario activar el GPS m´ovil y navegar hasta la URL. Solo es necesario mirar alrededor y aparece un texto en la ubicaci´on GPS solicitada. 23 2.4.2. Posicionamiento marcadores Para este caso es necesario solamente crear un archivo html donde se van a importar las bibliotecas de AR.js y definir el tipo de marcador que se quiere usar para escanear. La etiqueta “a-scene” sirve para definir la escena de la c´amara donde se definen los elementos que van a aparecer en la c´amara. La etiqueta “a-marker” es para definir el tipo de marcador que se va a posicionar, la etiqueta “a-entity” es la entidad que se va a mostrar, la cual tiene varios atributos: la posici´on donde va a aparecer el elemento, su escala y el modelo que va a representar el elemento de la entidad. <!DOCTYPE html> <html> <script src="https://aframe.io/releases/1.0.4/aframe.min.js"></script> <!-- we import arjs version without NFT but with marker + location based support --> <script src="https://raw.githack.com/AR-js-org/AR.js/master/aframe/build/aframe-ar.js"> </script> <body style="margin : 0px; overflow: hidden;"> <a-scene embedded arjs> <a-marker preset="hiro"> <a-entity position="0 0 0" scale="0.05 0.05 0.05" gltf-model="https://arjs-cors-proxy.herokuapp.com/https://raw.githack.com/ AR-js-org/AR.js/master/aframe/examples/image-tracking/nft/trex/scene.gltf" ></a-entity> </a-marker> <a-entity camera></a-entity> </a-scene> </body> </html> Una vez se entra en la url solo se necesita enfocar al marcador con la c´amara del dispositivo y se podr´a visualizar el objeto. 24 2.4.3. Posicionamiento imagen Para este caso es necesario solamente crear un archivo html donde se van a importar las bibliotecas de AR.js y definir la imagen que se va usar. La etiqueta “a-scene” sirve para definir la escena de la c´amara donde se definen los elementos que van a aparecer en la c´amara, la etiqueta “a-nft” es para definir los atributos del marcador de la imagen cuyas propiedades son el tipo de marcador de imagen, la ruta de la imagen con la que se va a comparar, smooth es para definir si se activa el modo estabilizador de la c´amara para estabilizar la im´agen, smoothCount es para definir el n´umero de matrices que se van a utilizar para el modo de estabilizador cuantas m´as matrices mas lento ir´a el movimiento de la c´amara, smoothTolerance la distancia desde donde se va a reconocer la imagen utilizando el modo suave y por ´ultimo smoothThreshold es el umbral del estabilizador de la c´amara que se mantendr´a constante a menos que haya suficientes matrices por encima de la tolerancia. La etiqueta “a-entity” es la entidad que se va a mostrar, la cual tiene varios atributos: la posici´on donde va a aparecer el elemento, su escala y el modelo que va a representar el elemento de la entidad. <!DOCTYPE html> <html> <script src="https://cdn.jsdelivr.net/gh/aframevr/ aframe@1c2407b26c61958baa93967b5412487cd94b290b/dist/aframe-master.min.js"></script> <script src="https://raw.githack.com/AR-js-org/AR.js/master/ aframe/build/aframe-ar-nft.js"></script> <body style="margin : 0px; overflow: hidden;"> <div class="arjs-loader"> <div>Loading, please wait...</div> </div> <a-scene vr-mode-ui="enabled: false;" renderer="logarithmicDepthBuffer: true;" embedded arjs="trackingMethod: best; sourceType: webcam;debugUIEnabled: false;" > <a-nft type="nft" url="https://arjs-cors-proxy.herokuapp.com/https://raw.githack.com/ AR-js-org/AR.js/master/aframe/examples/image-tracking/nft/trex/trex-image/trex" smooth="true" smoothCount="10" smoothTolerance=".01" smoothThreshold="5" > <a-entity gltf-model="https://arjs-cors-proxy.herokuapp.com/https://raw.githack.com/ AR-js-org/AR.js/master/aframe/examples/image-tracking/nft/trex/scene.gltf" scale="5 5 5" position="50 150 0" > </a-entity> 25 5. Operaci´on y mantenimiento. El sistema se instala y se pone en pr´actica. El mantenimiento implica corregir los errores que no se descubrieron, mejorar la implementaci´on de las unidades del sistema en conjunto con los servicios del sistema a medida que se descubren nuevos requisitos. Figura 4.1: Modelo en cascada [26] El desarrollo de este proyecto no es un desarrollo a largo plazo que conlleve muchas horas, los requisitos est´an claros y bien definidos y no van a cambiar a lo largo del proceso. Adem´as las etapas del modelo en cascada se ajusta, a las necesidades del desarrollo, porque tenemos que realizar un an´alisis de las tecnolog´ıas AR en el mercado, estudiar los requisitos del software, crear un dise˜no software de la arquitectura del sistema, implementaci´on del sistema programando el software, b´usqueda de errores y pruebas unitarias, pruebas del sistema de su correcto funcionamiento y por ´ultimo la etapa en la que se entrega la aplicaci´on. 4.2. Gesti´on del proceso En este punto se especifican los distintos planes para la gesti´on del proceso. 4.2.1. Plan inicial La planificaci´on de este proyecto se realizar´a por estimaci´on, teniendo en cuenta como referencia la propia experiencia y otros de caracter´ısticas similares. Dado que el proyecto se realiza de forma individual, no es necesario coordinarse con otros grupos de trabajo. Para la realizaci´on son necesarias las siguientes habilidades: Conocimientos de JavaScript, HTML, CSS y Java. Conocimientos de MySQL y de lenguaje SQL. 32 Conocimiento sobre despliegue de aplicaciones y puesta en marcha de servidores Apache. Conocimientos sobre planificaci´on de proyectos. Para este TFG disponemos de los recursos del grupo de investigaci´on GSIC/EMIC. 4.2.2. Plan de trabajo En este punto vamos a detallar las diferentes actividades en las que se divide el proyecto, as´ı como el c´omputo de horas del mismo. Tambi´en tenemos que tener en cuenta que para el desarrollo de este proyecto se realiz´o la b´usqueda de tecnolog´ıas AR, la actualizaci´on de la documentaci´on sobre la aplicaci´on ya existente del BucketServer y el despliegue de esta aplicaci´on en un dispositivo personal, para poder trabajar luego con la aplicaci´on para el desarrollo software. Resumen total del proyecto ID: - Resumen total del proyecto Estimado: 276 horas Duraci´on: 313 horas Fase de an´alisis ID: - Resumen de la Fase de An´alisis Estimado: 73 horas Duraci´on: 95 horas ID: 01 Inicio de la Fase de An´alisis Predecesoras: - Estimado: - Duraci´on: - - ID: 02 Reconocimiento de la aplicaci´on BucketServer Predecesoras: 01 Estimado: 5 horas Duraci´on: 7 horas Esta actividad consiste en el reconocimiento de las tecnolog´ıas utilizadas y familiarizarnos con el c´odigo ya creado de la aplicaci´on BucketServer. ID: 03 Obtenci´on de requisitos para las tecnolog´ıas AR Predecesoras: 02 Estimado: 10 horas Duraci´on: 8 horas Obtenci´on de requisitos necesarios para la tecnolog´ıa AR y su acoplamiento con la aplicaci´on BucketServer 33 ID: 04 Listado de tecnolog´ıas AR disponibles Predecesoras: 03 Estimado: 28 horas Duraci´on: 56 horas Crear un listado de tecnolog´ıas AR con sus pros y contras, para poder seleccionar la m´as id´onea ID: 05 Validaci´on de tecnolog´ıas AR Predecesoras: 04 Estimado: 20 horas Duraci´on: 15 horas Realizar peque˜nos test a las tecnolog´ıas de como funcionan y finalmente cu´ales pueden ser de utilidad para la aplicaci´on BucketServer ID: 06 Planificaci´on de riesgos Predecesoras: 05 Estimado: 8 horas Duraci´on: 7 horas Se estudiar´an los riesgos del proyecto, cu´ales podr´ıan ser sus impactos y su plan de gesti´on ID: 07 Control de versiones Predecesoras: 06 Estimado: 2 horas Duraci´on: 2 horas Se utilizar´a un control de versiones para el proyecto y as´ı evitar p´erdidas de datos ID: 07 Fin de la fase de an´alisis Predecesoras: 07 Estimado: - Duraci´on: - - Fase de dise˜no ID: - Resumen de la Fase de Dise˜no Estimado: 72 horas Duraci´on: 59 horas ID: 08 Inicio de la Fase de Dise˜no Predecesoras: 06 Estimado: - Duraci´on: - - 34 ID: 09 Modelado de Casos de Uso Predecesoras: 08 Estimado: 12 horas Duraci´on: 16 horas Se redactar´an los casos de uso a partir del documento de requisitos, obteniendo adem´as el diagrama de casos de uso ID: 10 Modelo de dominio Predecesoras: 09 Estimado: 8 horas Duraci´on: 2 horas Se elaborar´a el modelo de dominio del proyecto con sus clases pertinentes ID: 11 Dise˜no de los diagramas de secuencia Predecesoras: 10 Estimado: 24 horas Duraci´on: 21 horas Se elaborar´a los diagramas de secuencia en funci´on de los casos de uso que han sido detallados ID: 12 Dise˜no de la arquitectura del sistema Predecesoras: 11 Estimado: 15 horas Duraci´on: 12 horas A partir de la arquitectura del sistema ya existente de la aplicaci´on BucketServer y con el modelo de dominio, se elaborar´a un nuevo dise˜no de la arquitectura del sistema ID: 13 Dise˜no de la interfaz de usuario Predecesoras: 12 Estimado: 13 horas Duraci´on: 8 horas Dise˜nar la interfaz de usuario de realidad aumentada para la aplicaci´on BucketServer ID: 14 Fin de la fase de dise˜no Predecesoras: 13 Estimado: - Duraci´on: - - Fase de Implementaci´on ID: - Resumen de la Fase de Implementaci´on Estimado: 116 horas Duraci´on: 144 horas 35 ID: 15 Inicio de la Fase de Implementaci´on Predecesoras: 14 Estimado: - Duraci´on: - - ID: 16 Configuraci´on del entorno de desarrollo Predecesoras: 15 Estimado: 56 horas Duraci´on: 76 horas En esta actividad se ha realizado la primera parte del ciclo de vida del proyecto. Utilizando ingenier´ıa inversa en la aplicaci´on BucketServer, se logr´o la instalaci´on y configuraci´on en un ordenador personal, junto a la instalaci´on de un servidor Apache para utilizarlo durante el desarrollo. ID: 17 Ampliaci´on del backend Predecesoras: 16 Estimado: 20 horas Duraci´on: 14 horas En esta actividad se han realizado cambios en el c´odigo que ya hab´ıa, creando nuevas funciones. ID: 17.1 A˜nadir una funci´on MarkerAR para obtener artefactos con marcadores barcode Predecesoras: 16 Estimado: 4 horas Duraci´on: 4 horas Nueva funci´on en los archivos JavaScript: que muestre solamente los artefactos que tengan marcadores barcode. ID: 17.2 A˜nadir una funci´on MarkerARView Predecesoras: 16 Estimado: 8 horas Duraci´on: 6 horas Nueva funci´on en los archivos JavaScript: que obtenga los par´ametros necesarios de los artefactos con marcadores barcode del backend. ID: 17.3 A˜nadir una funci´on LocationARView Predecesoras: 16 Estimado: 8 horas Duraci´on: 4 horas Nueva funci´on en los archivos JavaScript: que obtenga los par´ametros necesarios de los artefactos con posicionamiento de geoposici´on del backend. 36 ID: 18 Desarrollo frontend Predecesoras: 17, 17.1, 17.2, 17.3 Estimado: 40 horas Duraci´on: 54 horas Se desarrollar´a la parte de la vista de AR de la aplicaci´on BucketServer utilizando CSS,JavaScript yHTML. ID: 18.1 Desarrollo de la vista para los artefactos con posicionamiento basado en marcadores barcode Predecesoras: 17, 17.1, 17.2, 17.3 Estimado: 20 horas Duraci´on: 24 horas Desarrollo de una nueva vista para los artefactos con marcadores barcode, que muestren con la c´amara del dispositivo el artefacto en realidad aumentada. ID: 18.2 Desarrollo de la vista para los artefactos con posicionamiento de geoposici´on Predecesoras: 17, 17.1, 17.2, 17.3 Estimado: 20 horas Duraci´on: 30 horas Desarrollo de una vista para los artefactos con posicionamiento de geoposici´on, que muestren con la c´amara del dispositivo el artefacto en realidad aumentada. ID: 19 Fin de la fase de implementaci´on Predecesoras: 18, 18.1, 18.2 Estimado: - Duraci´on: - Fase de tests del sistema ID: - Resumen de la fase de tests del sistema Estimado: 15 horas Duraci´on: 15 horas ID: 20 Inicio de la fase de tests del sistema Predecesoras: 19 Duraci´on: - Estimado: - - 37 ID: 21 Pruebas finales de la aplicaci´on BucketServer Predecesoras: 20 Estimado: 4 horas Duraci´on: 5 horas Fase de testeo para comprobar el correcto funcionamiento de la aplicaci´on ID: 22 Elaboraci´on de un manual de instalaci´on Predecesoras: 21 Estimado: 6 horas Duraci´on: 6 horas Elaborar una gu´ıa para la instalaci´on de la aplicaci´on BucketServer ID: 23 Elaboraci´on de un manual de usuario Predecesoras: 22 Estimado: 5 horas Duraci´on: 4 horas Elaborar una gu´ıa para el uso de la aplicaci´on BucketServer ID: 24 Fin de la fase de tests del sistema Predecesoras: 23 Estimado: - Duraci´on: - Diagramas de Gantt A continuaci´on, se a˜naden los diagramas de Gantt de las diferentes fases del proyecto. Figura 4.2: Fase de an´alisis 38 Figura 4.3: Fase de dise˜no Figura 4.4: Fase de implementaci´on 1oparte Figura 4.5: Fase de implementaci´on 2oparte 39 Figura 4.6: Fase de tests del sistema 40 4.3. Plan de gesti´on de riesgos A continuaci´on se exponen tanto los riesgos detectados, con una descripci´on de los mismos, su impacto y probabilidad, como la matriz de exposici´on mostrada en la tabla 4.1 . Con ambos datos se obtiene la exposici´on al riesgo. Impacto\ Probabilidad Muy Alto Alto Medio Bajo Muy Bajo Catastr´ofico Alto Alto Moderado Moderado Bajo Cr´ıtico Alto Alto Moderado Bajo Ninguno Marginal Moderado Moderado Bajo Ninguno Ninguno Despreciable Moderado Bajo Bajo Ninguno Ninguno Tabla 4.1: Matriz Impacto/Probabilidad 4.3.1. Listado de riesgos Realizamos un listado con los distintos riesgos que hemos podido observar, que podr´ıan ocurrir durante el transcurso del proyecto. R01 - Enfermedad R01 Enfermedad Descripci´on No se puede trabajar seg´un lo planificado debido a enfermedad. Impacto Marginal Probabilidad Alto Exposici´on Moderado Plan de Protecci´on utilizar siempre mascarilla en espacios p´ublicos, distancia de seguridad m´ınima de 1,5 metros, lavarse con frecuencia las manos y sino es as´ı la utilizaci´on de geles hidroalc´oholico Plan de Contingencia Evaluar el tiempo perdido y replanificar la actividad del proyecto. Tabla 4.2: Riesgo 01 - Enfermedad R02 - P´erdida de datos R02 P´erdida de datos Descripci´on P´erdida de documentos o c´odigo con la consecuente p´erdida del trabajo y tiempo invertidos. Impacto Cr´ıtico Probabilidad Baja Exposici´on Baja Plan de Protecci´on Utilizar constantemente el control de versiones en un servidor principal y uno de respaldo para mantener la evoluci´on de los documentos o c´odigo en lugar seguro. Plan de Contingencia En caso de p´erdida de datos, habr´a que evaluar el impacto sobre el proyecto y, en consecuencia, hacer una replanificaci´on tan extensa como sea necesario. Tabla 4.3: Riesgo 02 - P´erdida de datos 41 CU-2.2 Modo AR marcador Actor Alumno, Profesor o Administrador Descripci´on El sistema deber´a permitir al Actor seleccionar el modo AR marcador para poder visualizar los artefactos en AR que han sido posicionados a trav´es de un marcador. Precondici´on El Actor debe estar dentro del modo AR. Secuencia Normal Paso Acci´on 1 El Actor selecciona el modo AR marcador. 2 El Sistema se actualiza para poder reconocer los marcadores. 3 El Actor enfoca con la c´amara de su dispositivo al marcador. 4 El Sistema analiza el marcador y comprueba que coincida con un artefacto. 5 El Sistema actualiza la vista del dispositivo mostrando el artefacto en realidad aumentada. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on 3b Si el Actor decide retornar al bucket accediento a ´el. 3.1b El sistema se actualiza y redirecciona al actor a la vista web del bucket. 5b Si el sistema comprueba que el marcador no coincide con el de ning´un artefacto, no se mostrar´a ning´un artefacto en realidad aumentada. Tabla 5.3: Caso de Uso 2.2 - Modo AR marcador CU-2.3 Acceder artefacto AR Actor Alumno, Profesor o Administrador Descripci´on El sistema deber´a permitir al Actor acceder al artefacto cuando este lo visualice en realidad aumentada. Precondici´on El Actor debe estar dentro del modo AR marcador y estar visualizando el artefacto en realidad aumentada. Secuencia Normal Paso Acci´on 1 El Actor visualiza el artefacto en realidad aumentada. 2 El Actor accede al artefacto. 3 El Sistema redirige al actor al artefacto. 4 El Actor puede ver el contenido del artefacto. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on Tabla 5.4: Caso de Uso 2.3 - Acceder artefacto AR 48 CU-2.4 Modo AR localizaci´on Actor Alumno, Profesor o Administrador Descripci´on El sistema deber´a permitir al Actor seleccionar el modo AR localizaci´on para poder visualizar los artefactos en AR que han sido posicionados a trav´es de coordenadas GPS. Precondici´on El Actor debe estar dentro del modo AR. Secuencia Normal Paso Acci´on 1 El Actor selecciona el modo AR localizaci´on. 2 El Sistema se actualiza para poder reconocer las coordenadas GPS. 3 El Actor enfoca con la c´amara de su dispositivo en unas coordenadas GPS. 4 El Sistema comprueba que esas coordenadas GPS coincidan con las de un artefacto. 5 El Sistema actualiza la vista del dispositivo mostrando el artefacto en realidad aumentada. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on 3b Si el Actor decide retornar al bucket accediento a ´el. 3.1b El sistema se actualiza y redirecciona al actor a la vista web del bucket. 5b Si el sistema comprueba que las coordenadas GPS no coinciden con las de ning´un artefacto, no se mostrar´a ning´un artefacto en realidad aumentada. Tabla 5.5: Caso de Uso 2.4 - Modo AR localizaci´on 5.2. Modelo de dominio En primer lugar, la aplicaci´on BucketServer al tratarse de una aplicaci´on ya creada, tiene su propio modelo de dominio ya definido. Este modelo de dominio se puede observar en la Figura 5.2 [25]. No ha sido necesaria la modificaci´on del modelo de dominio que ya exist´ıa, para crear las funcionalidades AR para la aplicaci´on BucketServer. Vamos a realizar una descripci´on del modelo de dominio de la aplicaci´on BucketServer. Para hacer posible el posicionamiento y el acceso a artefactos y buckets en diferentes espacios f´ısicos y virtuales, se utiliza la clase POI. Sus atributos describen el espacio f´ısico o virtual donde va a ser ubicado. Las clases Learning bucket yLearning artifact heredan de la clase POI, de forma que ambos puedan posicionarse en dichos espacios. La clase Learning bucket puede contener Learning artifact. Un Learning artifact puede ser de diferentes tipos, estos dependen de la configuraci´on de proveedores de artefactos de la aplicaci´on BucketServer, un ejemplo de un proveedor de artefactos para BucketServer es GLUE! que permite crear un Google Doc. El elemento ArtifactType identifica el tipo de artefacto, cu´al es su proveedor, y los campos de configuraci´on necesarios para configurar dicho artefacto. La clase Learning bucket dispone de atributos como visibility, para que el profesor pueda hacer que el bucket sea visible o no, adem´as de otros atributos que definen las posibilidades del bucket. 49 Figura 5.2: Modelo de dominio [25] 50 Cap´ıtulo 6 Dise˜no En este cap´ıtulo vamos a hablar de las decisiones del dise˜no, la arquitectura software del sistema, junto con cada componente y c´omo est´an relacionados. Este dise˜no se realiza teniendo en cuenta las restricciones y requisitos de cap´ıtulos anteriores. 6.1. Arquitectura del sistema Vamos a explicar la arquitectura del sistema que hab´ıa en BucketServer y cu´al es la arquitectura propuesta con dos Figuras 6.1 y6.2. Figura 6.1: Arquitectura del sistema BucketServer que exist´ıa [25] El manager es el controlador del sistema responsable de administrar los buckets, sus artefactos y almacenar la informaci´on en la base de datos. El manager proporciona una API para la comunicaci´on con external aplications. Tambi´en se comunica con artifacts providers a trav´es de otra capa de adaptadores. Estos adaptadores se encargan de estandarizar las operaciones de administraci´on sobre los distintos artifacts providers, de tal manera que el manager siempre pueda utilizar el mismo conjunto de instrucciones definidas, independientemente de la API de cada artifact provider. BucketServer tiene una interfaz de usuario (UI), que act´ua como cliente del manager, utilizando la API para interactuar con ´el. Dentro de la parte de external aplications es donde se encontraba la parte de realidad aumentada de BucketServer. El problema es que las aplicaciones AR quedaron anticuadas y hubo que buscar una nueva forma de implementar la parte de realidad aumentada. La Figura 6.2 muestra la arquitectura propuesta del sistema BucketServer como soluci´on. 51 Figura 6.2: Arquitectura del sistema BucketServer propuesto La nueva interfaz de usuario (UI AR) va a contener la parte de realidad aumentada dentro del propio BucketServer, utilizando las librer´ıas externas de realidad aumentada de AFRAME y AR.js. Esta UI AR act´ua como cliente para los usuarios que accedan, desde dispositivos m´oviles, para visualizar los artefactos de un bucket que est´en posicionados por localizaci´on o por un marcador, como muestra la Figura 6.2 con los dos iconos azules. 6.1.1. Arquitectura del servidor La Figura 6.3 se puede observar la arquitectura en capas del servidor. La capa manager controller se encarga de comunicarse con las capas DB,model yadapter artifacts provider. En la capa model se encuentran las clases definidas del modelo de dominio. La capa API se encargar de recibir y redirigir las peticiones que llegan al servidor desde las capas UI,UI AR yadapter external aplications, hacia otras capas para poder resolver estas peticiones. Las capas adapter external aplications yadapter artifacts provider son las capas cuya funci´on es comunicarse con las aplicaciones externas al servidor. Las capas UI yUI AR son las interfaces de usuario, cuya funci´on es mostrar un entorno gr´afico para que el usuario pueda utilizar la aplicaci´on. 52 Figura 6.3: Arquitectura servidor 6.1.2. Diagrama de despliegue El diagrama de despliegue se utiliza para modelar la disposici´on f´ısica de los artefactos software en nodos. El objetivo de estos diagramas es mostrar las relaciones f´ısicas entre los componentes software y hardware en el sistema. En la Figura 6.4 , se muestra el diagrama de despliegue del sistema. En ´el se puede observar c´omo hay un cliente que se conecta a la p´agina web, por medio de una petici´on HTTPS hacia el servidor web Apache. Este, al recibir la petici´on, utiliza una conexi´on proxy reverse con el servidor Java BucketServer, cuya petici´on se encargar´a el nuevo servidor. El server Java BucketServer se encargar´a del acceso a la base de datos o de comunicarse con los servicios externos de los servidores de external aplications yartifact providers, utilizando los adapters. Una vez realiza todas las operaciones, el server BucketServer devuelve la petici´on al servidor web Apache, para que le de una respuesta al cliente en la p´agina web. 53 Figura 6.4: Diagrama de despliegue del sistema 6.1.3. Arquitectura cliente Como la aplicaci´on BucketServer ya estaba desarrollada, nos hemos enfocado en la integraci´on de las nuevas funcionalidades en el frontend. Del backend casi no se han realizado cambios. El frontend se ha desarrollado con el framework Dojo Toolkit que se hab´ıa utilizado para el desarrollo del BucketServer, utilizando HTML,CSS,JavaScript, adem´as de librer´ıas externas de JavaScript. 6.2. Patr´on Arquitect´onico El patr´on arquitect´onico desarrollado para el sistema BucketServer es el patr´on MVC (Modelo Vista y Controlador). Para la nueva parte que hay que dise˜nar se ha tenido en cuenta el mismo patr´on arquitect´onico para su desarrollo. Como el trabajo a realizar es en el frontend, solo utilizaremos la Vista y el Controlador del patr´on MVC. Los controladores gestionan la entrada del usuario y se comunicar´a con el Modelo y la Vista. La Vista muestra la informaci´on que se env´ıa al cliente. Existen dos nuevos controladores: Controlador modo AR marcador: Este controlador se encargar´a del acceso a los artefactos, que tengan posicionamiento de marcadores. Reconocimiento de marcadores, acceso al artefacto, creaci´on, activaci´on y desactivaci´on. Controlador modo AR localizaci´on: Este controlador se encargar´a del acceso a los artefactos, que tengan posicionamiento de geoposici´on. Reconocimiento de coordenadas, activaci´on y desactivaci´on. Existen dos nuevas vistas: Vista modo AR marcador: Esta vista se encargar´a de mostrar la informaci´on en realidad aumentada de los artefactos, con posicionamiento de tipo marcador. Vista modo AR localizaci´on: Esta vista se encargar´a de mostrar la informaci´on en realidad aumentada de los artefactos, con posicionamiento de geoposici´on. 54 6.3. Dise˜no de la interfaz de usuario En esta secci´on se incluyen los bocetos de las nuevas pantallas del modo AR localizaci´on y modo AR marcador. 6.3.1. Interfaz modo AR marcador Esta interfaz es de un usuario con su dispositivo m´ovil, muestra por pantalla la c´amara del m´ovil y enfoca un marcador para mostrar un artefacto en realidad aumentada. Ver Figura 6.5. Figura 6.5: Interfaz modo AR marcador 6.3.2. Interfaz modo AR localizaci´on Esta interfaz es de un usuario que esta en un espacio p´ublico y accede con su dispositivo m´ovil, mostrando por pantalla la c´amara del m´ovil los artefactos que se encuentran cerca en realidad aumentada. Ver Figura 6.6. 55 Figura 6.6: Interfaz modo AR localizaci´on 6.3.3. Interfaz modo web Esta interfaz es de un usuario que esta dentro de un bucket en el modo web, mostrando en la pantalla las distintas funciones que puede realizar en este modo. Como se observa en la Figura 6.7 56 Figura 6.7: Interfaz modo web 57 Figura 7.1: Utilizaci´on de ramas Git [19] Como se puede observar en la figura anterior, para cada nueva funcionalidad de la aplicaci´on que se iba a desarrollar, se creaba una rama con el nombre de la funcionalidad. Una vez finalizaba el desarrollo de esa funcionalidad, se incorporaba el contenido de esa rama a la rama de development. Una vez se termina todo el desarrollo software se fusiona la rama development a la rama master. 7.4. Librer´ıas utilizadas Las librer´ıas externas utilizadas de Javascript para la realidad aumentada, han sido las siguientes: AR.js •https://raw.githack.com/AR-js-org/AR.js/master/aframe/build/aframe-ar-nf t.js •https://aframe.io/releases/1.0.4/aframe.min.js •https://unpkg.com/aframe-look-at-componen[email protected]/dist/aframe-look-at-com ponent.min.js •https://raw.githack.com/AR-js-org/AR.js/master/three.js/build/ar-nft.js Estas librer´ıas permiten que cuando un marcador es encontrado, pueda mostrar alg´un contenido encima del marcador. Adem´as de mostrar contenido de realidad aumentada en el dispositivo del usuario, dependiendo de su geoposici´on. 7.5. Servidor utilizado Para la implementaci´on es necesario la utilizaci´on de un servidor Apache HTTP Server 6 . Es un software de servidor web gratuito y de c´odigo abierto para plataformas Unix. Mantenido y desarrollado por Apache Software Foundation Se necesita la utilizaci´on de Apache HTTP Server para la aplicaci´on BucketServer. El servidor Apache HTTP Server sirve para mostrar el contenido web a trav´es del navegador, proporcionar una conexi´on segura SSL, para que funcione correctamente el acceso a la c´amara del dispositivo que necesitan las librer´ıas Javascript y para realizar una conexi´on proxy reverse, con el servidor Java del backend de la aplicaci´on BucketServer. 6Apache HTTP Server - Servidor web: https://httpd.apache.org/ 64 7.6. Base de datos utilizada La aplicaci´on BucketServer utiliza como sistema gestor de base de datos MySQL 7 . Es un gestor de bases de datos relacional y de c´odigo abierto desarrollado por Oracle. La versi´on instalada es MySQL Server 5.7. 7MySQL - Gestor de base de datos: https://www.mysql.com/ 65 66 Cap´ıtulo 8 Plan de pruebas y validaci´on En este cap´ıtulo se detallan las pruebas realizadas para comprobar el correcto funcionamiento de las funcionalidades implementadas. 8.1. Pruebas vista marcadores y QRs Prueba 1.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la vista, que muestra una lista de los marcadores barcode y c´odigos QR de los artefactos Acci´on Acceder a la vista de marcadores y c´odigos QR sin existir ning´un artefacto. Resultado Esperado No se muestra ning´un marcador o QR en la lista. Resultado Obtenido No se muestra ning´un marcador o QR en la lista. Prueba 1.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la vista, que muestra una lista de los marcadores barcode y c´odigos QR de los artefactos Acci´on Crear un artefacto posicion´andolo en un c´odigo QR, acceder a la vista de marcadores y c´odigos QR. Resultado Esperado Se muestra el c´odigo QR del artefacto. Resultado Obtenido Se muestra el c´odigo QR del artefacto. Prueba 1.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la vista, que muestra una lista de los marcadores barcode y c´odigos QR de los artefactos Acci´on Crear un artefacto posicion´andolo en un marcador, acceder a la vista de marcadores y QRs. Resultado Esperado Se muestra el marcador barcode del artefacto. Resultado Obtenido Se muestra el marcador barcode del artefacto. 67 8.2. Creaci´on c´odigo QR para acceder al modo AR Prueba 2.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del c´odigo QR para acceder al modo AR. Acci´on Accedemos a un bucket en el que no hay ning´un artefacto con el posicionamiento de marcador o geoposici´on. Resultado Esperado No se muestra ning´un c´odigo QR para acceder al modo AR. Resultado Obtenido No se muestra ning´un c´odigo QR para acceder al modo AR. Prueba 2.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del c´odigo QR para acceder al modo AR. Acci´on Accedemos a un bucket y creamos un artefacto con el posicionamiento de marcador. Escaneamos el c´odigo QR con el m´ovil y accedemos a la URL. Resultado Esperado Accedemos al modo AR. Resultado Obtenido Accedemos al modo AR. Prueba 2.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del c´odigo QR para acceder al modo AR. Acci´on Accedemos a un bucket y creamos un artefacto con el posicionamiento de geoposici´on. Escaneamos el c´odigo QR con el m´ovil y accedemos a la URL. Resultado Esperado Accedemos al modo AR. Resultado Obtenido Accedemos al modo AR. 8.3. Pruebas modo AR marcador Prueba 3.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Clickamos el bot´on ((volver al bucket)). Resultado Esperado El sistema nos redirige a la vista del bucket. Resultado Obtenido El sistema nos redirige a la vista del bucket. Prueba 3.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Clickamos el bot´on ((GPS)). Resultado Esperado El sistema nos redirige al modo AR localizaci´on. Resultado Obtenido El sistema nos redirige al modo AR localizaci´on. 68 Prueba 3.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Enfocamos un marcador que pertenece a un artefacto. Resultado Esperado El sistema muestra un cubo que representa el artefacto y un texto con su nombre. Adem´as, muestra un bot´on para acceder al artefacto. Resultado Obtenido El sistema muestra un cubo que representa el artefacto y un texto con su nombre. Adem´as, muestra un bot´on para acceder al artefacto. Prueba 3.4 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Enfocamos un marcador que no pertenece a un artefacto. Resultado Esperado El sistema no muestra nada. Resultado Obtenido El sistema no muestra nada. Prueba 3.5 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Clickamos el bot´on ((acceder artefacto)). Resultado Esperado El sistema redirige al usuario a la ubicaci´on del artefacto. Resultado Obtenido El sistema redirige al usuario a la ubicaci´on del artefacto. 8.4. Pruebas modo AR localizaci´on Prueba 4.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR localizaci´on. Acci´on Clickamos el bot´on ((volver al bucket)). Resultado Esperado El sistema nos redirige a la vista del bucket. Resultado Obtenido El sistema nos redirige a la vista del bucket. Prueba 4.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Clickamos el bot´on ((Marker)). Resultado Esperado El sistema nos redirige al modo AR marcador. Resultado Obtenido El sistema nos redirige al modo AR marcador. 69 Prueba 4.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Enfocamos la c´amara del m´ovil cerca de la ubicaci´on de un artefacto. Resultado Esperado El sistema muestra un icono que representa el artefacto y un texto con su nombre. Resultado Obtenido El sistema muestra un icono que representa el artefacto y un texto con su nombre. Prueba 4.4 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del modo AR marcador. Acci´on Enfocamos la c´amara del m´ovil lejos de la ubicaci´on de un artefacto. Resultado Esperado El sistema no muestra nada. Resultado Obtenido El sistema no muestra nada. 8.5. Pruebas de interfaz de usuario Prueba 5.1 Descripci´on Esta prueba est´a destinada a probar que la aplicaci´on es manejable con una sola mano desde un dispositivo m´ovil. Acci´on Se realizan diversas operaciones como crear un artefacto, eliminarlo, visualizarlo, con distintos perfiles de usuarios. Resultado Esperado Todos los usuarios han sido capaz de realizar las operaciones con una mano. Resultado Obtenido Todos los usuarios han sido capaz de realizar las operaciones con una mano. Prueba 5.2 Descripci´on Esta prueba est´a destinada a comprobar el porcentaje de errores al utilizar la aplicaci´on. Acci´on Realizamos diez operaciones para crear distintos artefactos, editamos los diez artefactos y despu´es eliminamos los diez artefactos. Resultado Esperado No se obtiene ning´un error al realizar estas operaciones. Resultado Obtenido No se obtiene ning´un error al realizar estas operaciones. 70 Cap´ıtulo 9 Conclusiones y trabajo futuro 9.1. Conclusiones En la realizaci´on de este TFG se han implementado diversas funcionalidades a una aplicaci´on ya existente, BucketServer. Se ha sustituido la funcionalidad de AR que utilizaba aplicaciones externas, que hab´ıan quedado anticuadas, por una nueva tecnolog´ıa de realidad aumentada dentro de la aplicaci´on. Los objetivos iniciales han sido cumplidos y para cada uno de ellos se han completado varios hitos: 1. An´alisis y selecci´on de tecnolog´ıas AR para implementar en la aplicaci´on BucketServer: B´usqueda de aplicaciones m´oviles AR compatibles con la aplicaci´on BucketServer. B´usqueda de librer´ıas AR web compatibles con la aplicaci´on BucketServer. 2. Implementaci´on de funcionalidades de realidad aumentada, sustituyendo a las aplicaciones externas de BucketServer. Implementaci´on software para crear artefactos dentro de un bucket que se puedan posicionar en marcadores AR o ubicaciones AR, utilizando las librer´ıas de AR.js. C´odigo QR para acceder al modo AR, desde cualquier dispositivo capaz de leer c´odigos QR. Implementaci´on de una vista para la visualizaci´on de los marcadores de los artefactos. Modificaci´on del modo web para mejorar la interfaz del usuario con el prop´osito de conseguir una mayor facilidad a la hora de seleccionar entre los dos modos de visualizaci´on y los distintos tipos de vista en el modo web. 3. Actualizaci´on de la documentaci´on BucketServer Creaci´on de un manual de instalaci´on Creaci´on de un manual de usuario 9.2. Trabajo futuro La aplicaci´on BucketServer puede aumentar sus funcionalidades y mejorar las existentes. Algunas de estas mejoras son: Actualizaci´on de las funciones de la librer´ıas de AR.js, permitiendo que cuando se detecte la ubicaci´on de un artefacto en realidad aumentada, se cree un evento para poder acceder a ese artefacto. 71 Implementaci´on de medidas de seguridad, creando roles de usuario para los actores profesores y usuarios. Actualizaci´on de la aplicaci´on BucketServer, utilizando tecnolog´ıas actuales para crear un c´odigo mas estructurado y legible. 9.3. Valoraci´on personal Los conocimientos adquiridos en el desarrollo de ese proyecto sobre realidad aumentada, me han hecho reflexionar sobre las posibilidades de esta tecnolog´ıa en el mundo actual, pudiendo ser una herramienta de gran utilidad para diversos sectores, no solo en el ´ambito educativo, adem´as de ser de gran utilidad en otros ´ambitos. La implementaci´on de nuevas funcionalidades dentro de un sistema que ya ha sido creado ha supuesto una gran dificultad t´ecnica. Sin embargo, me ha servido para mejorar mis habilidades y conocimientos como ingeniero inform´atico. 72 Referencias [1] API de ARCore. https://developers.google.com/ar/reference/ . [Online; accessed 28-March-2020]. [2] AR.js Documentation. https://ar-js-org.github.io/AR.js-Docs/ . [Online; accessed 8-September-2020]. [3] Augmented Reality point of interest service environment. https://github.com/ARPOISE/ARp oise/blob/master/README.md. [Online; accessed 26-March-2020]. [4] Documentaci´on de ARToolkit. http://www.artoolkitx.org/ . [Online; accessed 27-March2020]. [5] Documentaci´on EasyAR. https://www.easyar.com/. [Online; accessed 28-March-2020]. [6] Documentaci´on Vuforia. https://developer.vuforia.com/ . [Online; accessed 26-March2020]. [7] Documentaci´on Wikitude. https://www.wikitude.com/external/doc/documentation/st udio-api/. [Online; accessed 25-March-2020]. [8] Geoar. https://geoar.it/. [Online; accessed 26-March-2020]. [9] Github de ARToolKit. https://github.com/artoolkitx/artoolkitx/wiki . [Online; accessed 27-March-2020]. [10] Goodbye Blippar, welcome back Layar? https://sifted.eu/articles/goodbye-blippar-w elcome-back-layar/. [Online; accessed 25-March-2020]. [11] Gu´ıa de Proxy inverso. https://httpd.apache.org/docs/trunk/es/howto/reverse proxy .html. [Online; accessed 24-July-2020]. [12] How to create POI in ARPoise? https://github.com/ARPOISE/ARpoise/blob/master/REA DME.md. [Online; accessed 26-March-2020]. [13] Kudan. https://www.kudan.io/. [Online; accessed 26-March-2020]. [14] KudanAR. https://www.xlsoft.com/en/products/kudan/index.html . [Online; accessed 26-March-2020]. [15] MaxST. http://maxst.com/#/. [Online; accessed 28-March-2020]. [16] M´odulo Apache mod ssl. https://httpd.apache.org/docs/trunk/es/mod/mod ssl.html . [Online; accessed 24-July-2020]. [17] Top 10 AR Tools for App Development. https://arvrjourney.com/top-10-ar-tools-forapp-development-6dab56a833db. [Online; accessed 15-March-2020]. 73 sudo systemctl status apache2 4. Ahora vamos a configurar una conexi´on segura SSL y un proxy reverse, para conectar el servidor Apache con el servidor BucketServer. I.4.1. Configuraci´on SSL Apache Es necesario configurar una conexi´on con el protocolo SSL, para tener acceso a la c´amara del dispositivo y tener una conexi´on segura. 1. Generamos un certificado con la herramienta OpenSSL4, utilizamos el comando: sudo openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -out /etc/apache2/ssl/server.crt -keyout /etc/apache2/ssl/server.key 2. Activamos el m´odulo SSL de Apache mod ssl [16] con el comando: sudo a2enmod ssl 3. Creamos un enlace simb´olico en el directorio apache default-ssl: sudo ln -s /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-enabled/000-default-ssl.conf 4. Editamos el fichero 000-default-ssl.conf y a˜nadimos dos l´ıneas dentro del fichero: sudo vim /etc/apache2/sites-enabled/000-default-ssl.conf SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key 5. Por ´ultimo reiniciamos el servidor Apache: sudo systemctl restart apache2 4 OpenSSL es un proyecto software libre, tiene un paquete de herramientas de administraci´on y bibliotecas relacionadas con la criptograf´ıa: https://www.openssl.org/ 80 I.4.2. Configuraci´on proxy reverse Apache Nuestro servidor Apache HTTP Server no va a alojar los datos ´el mismo. En su lugar el contenido de los datos se obtendr´a del servidor backend, en este caso se trata del servidor Java de la aplicaci´on BucketServer. Cuando el servidor Apache recibe una petici´on de un cliente, se hace un proxy de esta petici´on al servidor backend, que genera el contenido y lo env´ıa de vuelta al servidor Apache. Finalmente este genera la respuesta HTTP que ir´a de vuelta al cliente [11]. Un ejemplo de implementaci´on t´ıpica es la Figura I.1. Figura I.1: Implementaci´on de un Proxy Reverse [11] 1. Instalamos los m´odulos que vamos a necesitar: sudo a2enmod proxy sudo a2enmod prox_balancer sudo a2enmod proxy_connect sudo a2enmod proxy_html sudo a2enmod proxy_http 2. Reiniciamos el servidor Apache: sudo systemctl restart apache2 3. Modificamos el archivo /etc/apache2/sites-enabled/000-default.conf con el siguiente comando: 81 sudo vim /etc/apache2/sites-enabled/000-default.conf 4. El fichero queda de la siguiente forma; ver Figura I.2 Figura I.2: Configuraci´on del archivo 000-default.conf 5. Por ´ultimo, volvemos a reiniciar el servidor Apache. sudo systemctl restart apache2 Una vez hemos realizado todos estos pasos, hemos terminado con la instalaci´on y configuraci´on del servidor Apache. 82 Anexo II Manual de usuario Para acceder al sistema el primer paso consiste en introducir la URL de la aplicaci´on en el navegador. Esta URL es de la forma https://dominio/bucket-server/gui/admin.html. Ver Figura II.1. Figura II.1: Captura de la p´agina para acceder y crear buckets Una vez en la p´agina del sistema puedes acceder a uno de los buckets ya creados o crea uno desde cero, haciendo click en el bot´on ((Crear bucket)). El panel que se mostrar´a es el de la Figura II.2. 83 Figura II.2: Panel para la creaci´on de un bucket 84 Si accedemos dento de un bucket la vista que se tendr´a es la de la Figura II.3. Figura II.3: P´agina web de un bucket 85 Si queremos cambiar el tipo de vista, para poner la vista de los marcadores artefactos o visualizar el contenido de los artefactos, tenemos que hacer click sobre los iconos de los tipos de vista web. Tambi´en podemos seleccionar el bot´on acceso por QR para poder escanear los c´odigos QR del bucket para acceder al bucket o del modo AR para accceder al modo AR. Si queremos crear un artefacto tenemos que hacer click en el bot´on (( Create artifact )) . El panel que se mostrar´a es el de la Figura II.4. Figura II.4: Panel para la creaci´on de un artefacto Para poder acceder al modo AR es necesario que haya creado alg´un artefacto con el posicionamiento marcador o de geoposici´on. Si es as´ı, en la vista de la Figura II.3 aparecer´a a mayores un c´odigo QR dentro del bot´on acceso por QR, como el de la Figura II.5 y un bot´on switch para cambiar entre el modo web y modo ar como el de la Figura II.6. 86 Figura II.5: Ejemplo de c´odigo QR para acceder al modo AR y al bucket Figura II.6: Vista dde un bucket con el interruptor switch para cambiar entre el modo AR y modo Web Dentro del modo de realidad aumentada la vista que veremos cambiara dependiendo de los artefacto que se hayan creado. Si solo existen artefactos geoposicionados o en marcadores barcode, solo mostrara un switch para cambiar entre el modo web y ar, si existen los dos tipos de artefactos aparecer´a otro switch para cambiar entre el reconocimiento de geoposici´on o marcadores barcode y si estamos reconociendo marcadores barcode y encontramos uno aparecer´a un bot´on para acceder al contenido del marcador barcode. Un ejemplo de la vista que se mostrar´ıa es el de la Figura II.7 87 Figura II.7: Vista del modo AR con un marcador barcode 88 Anexo III Enlaces de descarga Los ficheros del c´odigo fuente de la aplicaci´on BucketServer y de la documentaci´on en LaTeX se puede del siguiente enlace de Google Drive https://drive.google.com/drive/folders/1Oo5EfT iycKApHtzsqXRMniU-68GoHfZq?usp=sharing 89