Desarrollo de un sitio web de información turística de Castilla y León

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM ´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI´ ON EN INGENIER´ IA DE SOFTWARE Desarrollo de un sitio web de informaci´on tur´ıstica de Castilla y Le´on Autor: Pablo Maniega Alonso Tutor: C´esar Gonz´alez Ferreras I II AGRADECIMIENTOS Agradecimientos Gracias a mi familia por el cari˜no y paciencia a lo largo de estos a˜nos de estudios. Gracias a mis amigos, por apoyarme en cualquier momento. Gracias a mis profesores por la formaci´on que me han dado. En especial a C´esar Gonz´alez Ferreras, por ser el tutor de este trabajo y ayudarme en ´el. III AGRADECIMIENTOS IV RESUMEN Resumen El objetivo de este Trabajo de Fin de Grado consiste en el desarrollo de una aplicaci´on, para la b´usqueda y aconsejamiento de ”que hacer” en Castilla y Le´on. Los principales puntos a desarrollar son, un mapa y tabla desde donde ver los diferentes lugares que visitar, y un sistema de favoritos y comentarios en los diferentes sitios. La aplicaci´on est´a disponible en https://turismocyl.herokuapp.com/ Palabras clave: Desarrollo Web, Angular, Firebase, Bootstrap, Datos abiertos, Turismo. V RESUMEN VI ABSTRACT Abstract The main objective of this Degree Final Project is to develop an application, for the search and counseling of ”what to do” in Castilla y Le´on. The main functionalities to develop are, a map and a table where you can see the diferent places to visit, and a favorites and comments system for the diferent places. The application is available at https://turismocyl.herokuapp.com/ Key words: Web Development, Angular, Firebase, Bootstrap, Open data, Tourism. VII LISTA DE IM ´ AGENES 5.1. Precio de Google Maps JavaScript API . . . . . . . . . . . . . . . . . . . . . . 53 5.2. Precio de Google Maps Geocoding API . . . . . . . . . . . . . . . . . . . . . 54 5.3. Limite de Google Maps JavaScript API . . . . . . . . . . . . . . . . . . . . . 54 5.4. Limite de Google Maps Geocoding API . . . . . . . . . . . . . . . . . . . . . 54 5.5. Estructura general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6. Estructura componente Angular ejemplo . . . . . . . . . . . . . . . . . . . . . 57 5.7. Estructura carpeta shared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.8. Instalaci´onAngular................................. 58 5.9. CrearproyectoAngular .............................. 59 5.10. Pregunta sobre routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.11. Pregunta sobre hoja de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.12. Lanzar aplicaci´on Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.13. Pregunta sobre compartir datos . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.14.P´aginaprincipal .................................. 61 5.15. P´agina principal Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.16. Crear Aplicaci´on Firebase nombre . . . . . . . . . . . . . . . . . . . . . . . . 62 5.17. Crear Aplicaci´on Firebase Analytics . . . . . . . . . . . . . . . . . . . . . . . 62 5.18. Crear Aplicaci´on Firebase Ubicaci´on Analytics . . . . . . . . . . . . . . . . . 63 5.19. Aplicaci´on Firebase creada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.20.Authenticationcorreo ............................... 64 5.21. RealTime Database nueva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.22. Nombre aplicaci´on web para Firebase . . . . . . . . . . . . . . . . . . . . . . . 65 5.23. C´odigo de Firebase a copiar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 XIV LISTA DE TABLAS Lista de tablas 1.1. Objetivos ...................................... 2 3.1. Actores ....................................... 7 3.2. Reglasdenegocio.................................. 9 3.3. Casos de Uso Usuario An´onimo . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Casos de Uso Usuario Registrado . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. CasosdeUsoGerente ............................... 11 3.6. Especificaci´on Caso de Uso CU-01 . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Especificaci´on Caso de Uso CU-02 . . . . . . . . . . . . . . . . . . . . . . . . 13 3.8. Especificaci´on Caso de Uso CU-03 . . . . . . . . . . . . . . . . . . . . . . . . 14 3.9. Especificaci´on Caso de Uso CU-04 . . . . . . . . . . . . . . . . . . . . . . . . 14 3.10. Especificaci´on Caso de Uso CU-05 . . . . . . . . . . . . . . . . . . . . . . . . 15 3.11. Especificaci´on Caso de Uso CU-06 . . . . . . . . . . . . . . . . . . . . . . . . 15 3.12. Especificaci´on Caso de Uso CU-07 . . . . . . . . . . . . . . . . . . . . . . . . 16 3.13. Especificaci´on Caso de Uso CU-08 . . . . . . . . . . . . . . . . . . . . . . . . 17 3.14. Especificaci´on Caso de Uso CU-10 . . . . . . . . . . . . . . . . . . . . . . . . 18 3.15. Especificaci´on Caso de Uso CU-10 . . . . . . . . . . . . . . . . . . . . . . . . 18 3.16. Especificaci´on Caso de Uso CU-11 . . . . . . . . . . . . . . . . . . . . . . . . 19 3.17. Especificaci´on Caso de Uso CU-12 . . . . . . . . . . . . . . . . . . . . . . . . 19 3.18. Especificaci´on Caso de Uso CU-13 . . . . . . . . . . . . . . . . . . . . . . . . 20 XV LISTA DE TABLAS 3.19. Especificaci´on Caso de Uso CU-14 . . . . . . . . . . . . . . . . . . . . . . . . 21 3.20. Especificaci´on Caso de Uso CU-15 . . . . . . . . . . . . . . . . . . . . . . . . 21 3.21. Especificaci´on Caso de Uso CU-16 . . . . . . . . . . . . . . . . . . . . . . . . 22 3.22. Definici´on de Usuario en DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.23. Definici´on de Sitio en DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.24. Definici´on de Comentario en DB . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.25.RNFSeguridad................................... 25 3.26.RNFUsabilidad .................................. 26 3.27.RNFRobustez ................................... 26 3.28.RNFDisponibilidad ................................ 26 3.29. Esquema del 1ºConjuntodeDatos........................ 30 3.30. Esquema del 2ºConjuntodeDatos........................ 31 3.31. Esquema del 3ºConjuntodeDatos........................ 32 4.1. TablaUsuario.................................... 37 4.2. TablaSitio ..................................... 38 4.3. TablaComentario ................................. 39 XVI CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on 1.1. Motivaci´on La finalidad del presente Trabajo de Fin de Grado es, por un lado, la de, utilizando los datos abiertos relacionados con el turismo, dados por la Junta de Castilla y Le´on, realizar una plataforma web donde los usuarios puedan buscar lugares, en Castilla y Le´on, donde realizar actividades de ocio y, a su vez, comentar y puntuar estos lugares para que otros usuarios se hagan una idea sobre que tal est´a el sitio. Tambi´en se permite a los usuarios guardarse los sitios que m´as les guste como favoritos. Por otro lado, la de aprender m´as sobre el uso de las herramientas utilizadas para su desarrollo, ya que a mi parecer son de las m´as utilizadas a d´ıa de hoy en las empresas de desarrollo web. 1.2. Objetivos y alcance Los principales objetivos buscados en el desarrollo de la aplicaci´on son los siguientes: 1 1.3. ENTORNO TECNOL ´ OGICO ID Objetivo OB-01 Desarrollo de un sitio web de informaci´on tur´ıstica de Castilla y Le´on. OB-02 Implementaci´on de un mapa y una tabla, desde los cuales poder buscar y visualizar los sitios. OB-03 Implementaci´on de un sistema de comentarios y puntuaciones para los sitios. OB-04 Implementaci´on de un apartado de favoritos donde los usuarios guarden los sitios que quieran. OB-05 Aumentar los conocimientos adquiridos en la carrera, sobre las tecnolog´ıas utilizadas en el trabajo. Cuadro 1.1: Objetivos 1.3. Entorno tecnol´ogico Esta aplicaci´on web se ha desarrollado, principalmente utilizando Angular 11, framework de javascript para el desarrollo de aplicaciones web, el cual incluye otras tecnolog´ıas como HTML5 o CSS3. Para el dise˜no de la p´agina se ha utilizado tambi´en bootstrap 4, el cual es un kit de herramientas open source para el desarrollo de p´aginas web responsive, el cual es utilizado en la mayor´ıa de aplicaciones web. Para la Base de Datos se ha utilizado la base de datos Realtime Database perteneciente a Firebase, el cual es una plataforma, perteneciente a Google, en la nube para el desarrollo de aplicaciones web y m´ovil. Dentro de las funcionalidades de Firebase nos encontramos Realtime Database, el cual es una base de datos NoSQL, con un formato JSON. Para la gesti´on de los usuarios se ha utilizado tambi´en Firebase, en concreto su apartado de Authentication. 1.4. Que son los datos abiertos Definici´on dada en la propia p´agina de la Junta de CyL [1]: Datos abiertos (open data en ingl´es) es una filosof´ıa y pr´actica que persigue que determinados datos est´en disponibles de forma libre a todo el mundo, sin restricciones de copyright , patentes u otros mecanismos de control. Los datos deben publicarse en bruto (sin procesar), bien estructurados y en formatos conocidos que faciliten la reutilizaci´on. El sector p´ublico produce una gran variedad de informaci´on interesante para los ciudadanos y empresas, como por ejemplo, informaci´on social, econ´omica, geogr´afica, estad´ıstica, meteorol´ogica o tur´ıstica y sobre empresas y educaci´on. Esta informaci´on tiene unas caracter´ısticas que la hacen particularmente atractiva para el sector de los contenidos digitales, ya que es completa, fiable y de calidad. 2 CAP´ ITULO 1. INTRODUCCI ´ ON La apertura de datos del sector p´ublico permite que cualquier persona u organizaci´on pueda construir sobre ellos una nueva idea que resulte en nuevos datos, conocimientos, mejorar procesos, dar valor a˜nadido a los existentes o incluso crear nuevos servicios. Por lo tanto, tiene un considerable potencial econ´omico y adem´as favorece la transparencia, participaci´on y colaboraci´on ciudadana, necesarios para contar con un gobierno m´as abierto. 3 1.4. QUE SON LOS DATOS ABIERTOS 4 CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTO Cap´ıtulo 2 Planificaci´on y Presupuesto En este cap´ıtulo, vamos a hablar de la metodolog´ıa utilizada para el desarrollo de la aplicaci´on, as´ı como de los costes del desarrollo de la aplicaci´on. 2.1. Metodolog´ıa del proyecto Para el desarrollo de la aplicaci´on, se ha optado por la metodolog´ıa de ”Modelo de prototipos” [30], el cual pertenece a los modelos de desarrollo evolutivo. Hemos elegido este tipo de metodolog´ıa, ya que, aunque ya se hab´ıan pensado las funcionalidades b´asicas de la aplicaci´on, no se hab´ıan cerrado del todo, adem´as de que, no se ten´ıa del todo pensado el como incluirlas en la aplicaci´on. Tambi´en, se planeaban desarrollar primero las funcionalidades, y una vez que la aplicaci´on fuese totalmente funcional, realizar los cambios para mejorar la calidad y la est´etica de la aplicaci´on. Por estos motivos, se decant´o hacia el ”Modelo de prototipos”. 2.2. Planificaci´on inicial del proyecto Para la planificaci´on inicial, no se ha seguido ning´un calendario para el desarrollo. Se ten´ıa como fecha de comienzo del desarrollo de la aplicaci´on principios de Febrero de 2021, ya que, en esas fechas ya se habr´ıa terminado con los ex´amenes. Como fecha final del desarrollo finales de Mayo de 2021, para as´ı tener tiempo para la realizaci´on de la memoria para su entrega en primera convocatoria. Habr´ıa que tener en cuenta que, durante los meses de Abril y Mayo, en su totalidad, se estar´ıan realizando las pr´acticas en empresa, las cuales consumir´ıan 7 horas diarias, de lunes a viernes, de trabajo, m´as el tiempo de ir y venir de la empresa, que teniendo en cuenta que no estaba ubicada en Valladolid, ser´ıa m´ınimo de 45 minutos ida y 45 vuelta; por lo tanto, habr´ıa que tener terminada, al menos, m´as de la mitad de la aplicaci´on para finales de Marzo. 5 2.3. COSTES DEL PROYECTO 2.3. Costes del proyecto Aunque el proyecto se ha desarrollado por una sola persona, vamos a dividir sus roles como si de dos personas se tratase. Analista: Se encarga de las tareas de an´alisis de requisitos, dise˜no de interfaces y diagramas, y la elaboraci´on de documentos. Programador: Se encarga de la implementaci´on de la aplicaci´on y de las pruebas de esta. Para los salarios de cada uno se ha escogido el salario medio en https://es.indeed.com/, seg´un el cual, un analista tendr´ıa un salario medio de 14.36€/hora, y un programador de 12.35€/hora. Con estos salarios medios y las horas dedicadas a cada parte del proyecto tenemos que, por la parte del programador ser´ıan 1525,225€(12.35*123.5=1525,225) y por la parte del analista 542,09€(37,75×14,36=542,09), lo cual dar´ıa un coste total de 2067,315€. Ha este resultado habr´ıa que a˜nadirle los costes de hardware y los costes de software, los cuales ascienden a 2176,82€, estos costes vienen dados por el ordenador, junto a la pantalla y teclado,(1000€), el dispositivo m´ovil (300€), el rat´on (50€), y los gastos en las API´s de Google (826,82€). Todos estos costes sumados dar´ıan que, la aplicaci´on tiene un coste total de desarrollo de 4244,135€, el cual vemos como un coste apropiado para una aplicaci´on de esta escala. 6 CAP´ ITULO 3. AN ´ ALISIS Cap´ıtulo 3 An´alisis En esta secci´on del documento especificaremos los distintos tipos de actores, requisitos o reglas obtenidos del an´alisis para desarrollar la aplicaci´on. 3.1. Actores del sistema Empezamos con el an´alisis de los distintos tipos de actores que pueden interactuar con la aplicaci´on. ID Nombre Descripci´on AC-01 Usuario an´onimo Este actor representa al usuario que accede a la aplicaci´on sin estar registrado. AC-02 Usuario registrado Este actor representa al usuario ya registrado en la p´agina y que accede como tal. AC-03 Gerente Este actor representa a un usuario con privilegios especiales, es decir, al encargado de subir el fichero de monumentos. Cuadro 3.1: Actores Su jerarqu´ıa, aunque simple, viene dada en el siguiente diagrama. 7 3.3. CASOS DE USO CU-03 Ordenar resultados Descripci´on El sistema permite al usuario ordenar por categor´ıa los resultados ya mostrados. Precondici´on El usuario debe haber visualizado alg´un sitio o los comentarios de alg´un sitio. Flujo normal 1. El usuario an´onimo solicita al sistema ordenar los resultados por una categor´ıa en concreto. 2. El sistema ordena los resultados por la categor´ıa y muestra los resultados correspondientes. 3.El flujo finaliza correctamente. Postcondici´on El usuario puede visualizar los resultados ordenados. Flujo alternativo Cuadro 3.8: Especificaci´on Caso de Uso CU-03 CU-04 Buscar por texto Descripci´on El sistema permite al usuario buscar por texto los resultados a mostrar. Precondici´on Flujo normal 1. El usuario an´onimo escribe el texto por el que desea buscar los resultados. 2. El sistema busca los resultados por el texto y muestra los resultados correspondientes. 3.El flujo finaliza correctamente. Postcondici´on El usuario puede visualizar los resultados. Flujo alternativo 2a No existen resultados: 1. El sistema notifica que no se han encontrado resultados. 2. Retorna al punto 1. Cuadro 3.9: Especificaci´on Caso de Uso CU-04 14 CAP´ ITULO 3. AN ´ ALISIS CU-05 Seleccionar por tipo Descripci´on El sistema permite al usuario seleccionar por tipo de establecimiento los resultados a mostrar. Precondici´on Flujo normal 1. El usuario an´onimo selecciona el tipo que desea visualizar. 2. El sistema busca los resultados por el tipo y muestra los resultados correspondientes. 3.El flujo finaliza correctamente. Postcondici´on El usuario puede visualizar los resultados. Flujo alternativo Cuadro 3.10: Especificaci´on Caso de Uso CU-05 CU-06 Seleccionar por provincia Descripci´on El sistema permite al usuario seleccionar por provincia los resultados a mostrar. Precondici´on Flujo normal 1. El usuario an´onimo selecciona la provincia, cuyos sitios, desea visualizar. 2. El sistema busca los resultados por la provincia y muestra los resultados correspondientes. 3.El flujo finaliza correctamente. Postcondici´on El usuario puede visualizar los resultados. Flujo alternativo Cuadro 3.11: Especificaci´on Caso de Uso CU-06 15 3.3. CASOS DE USO CU-07 Seleccionar por tipo y provincia Descripci´on El sistema permite al usuario seleccionar por tipo y provincia los resultados a mostrar. Precondici´on Flujo normal 1. El usuario an´onimo selecciona el tipo y la provincia cuyos sitios desea visualizar. 2. El sistema busca los resultados por el tipo y la provincia y muestra los resultados correspondientes. 3.El flujo finaliza correctamente. Postcondici´on El usuario puede visualizar los resultados. Flujo alternativo 2a Tipo seleccionado museo: 1. El sistema avisa al usuario que los museos no se pueden buscar con provincias. 2. Retorna al punto 1. Cuadro 3.12: Especificaci´on Caso de Uso CU-07 16 CAP´ ITULO 3. AN ´ ALISIS CU-08 Registrarse Descripci´on El sistema permite al usuario registrarse en la aplicaci´on. Precondici´on Flujo normal 1. El usuario an´onimo selecciona la opci´on de registrarse. 2. El sistema muestra los campos que debe rellenar el usuario an´onimo. 3. El usuario an´onimo rellena los campos. 4. El sistema valida los campos y registra al usuario. 5.El flujo finaliza correctamente. Postcondici´on El usuario an´onimo pasa a ser un usuario registrado Flujo alternativo 4a Contrase˜na d´ebil: 1. El sistema avisa al usuario que su contrase˜na es d´ebil. 2. Retorna al punto 1. 4b Contrase˜na y repetir contrase˜na no igual: 1. El sistema avisa al usuario que no ha escrito los dos campos de contrase˜na correctamente. 2. Retorna al punto 1. 4c Correo no valido: 1. El sistema avisa al usuario que el correo introducido no es v´alido. 2. Retorna al punto 1. 4d Correo en uso: 1. El sistema avisa al usuario que el correo introducido ya est´a en uso. 2. Retorna al punto 2. Cuadro 3.13: Especificaci´on Caso de Uso CU-08 17 3.3. CASOS DE USO CU-09 Visualizar en mapa Descripci´on El sistema permite al usuario visualizar un sitio ya buscado en el mapa. Precondici´on Haber buscado alg´un sitio en la tabla o haber entrado a favoritos. Flujo normal 1. El usuario an´onimo selecciona la opci´on de ver en el mapa. 2. El sistema cambia al mapa y carga el sitio en ´el. 3.El flujo finaliza correctamente. Postcondici´on El usuario an´onimo visualiza el sitio en el mapa. Flujo alternativo Cuadro 3.14: Especificaci´on Caso de Uso CU-10 CU-10 Abrir ventana informacion Descripci´on El sistema permite al usuario abrir una ventana con informaci´on en los marcadores del mapa. Precondici´on El usuario debe haber visualizado alg´un sitio en el mapa. Flujo normal 1. El usuario an´onimo clica un marcador en el mapa. 2. El sistema muestra una ventana con informaci´on del sitio correspondiente. 3.El flujo finaliza correctamente. Postcondici´on Flujo alternativo Cuadro 3.15: Especificaci´on Caso de Uso CU-10 18 CAP´ ITULO 3. AN ´ ALISIS Actor AC-02: Usuario Registrado CU-11 Identificarse Descripci´on El sistema permite al usuario identificarse en la aplicaci´on. Precondici´on Estar registrado en el sistema. Flujo normal 1. El usuario registrado selecciona la opci´on de identificarse. 2. El sistema muestra los campos que debe rellenar el usuario registrado. 3. El usuario registrado rellena los campos. 4. El sistema valida los campos e identifica al usuario. 5.El flujo finaliza correctamente. Postcondici´on El usuario registrado se ha identificado en el sistema Flujo alternativo 4a Contrase˜na incorrecta: 1. El sistema avisa al usuario que la contrase˜na introducida es incorrecta. 2. Retorna al punto 1. 4b Correo incorrecto: 1. El sistema avisa al usuario que el correo introducido no es v´alido. 2. Retorna al punto 1. Cuadro 3.16: Especificaci´on Caso de Uso CU-11 CU-12 Logout Descripci´on El sistema permite al usuario salir de sesi´on. Precondici´on Estar identificado. Flujo normal 1. El usuario registrado selecciona la opci´on de logout. 2. El sistema desloguea al usuario registrado y borra la informaci´on de la sesi´on. 3.El flujo finaliza correctamente. Postcondici´on El usuario registrado se ha deslogueado del sistema. Flujo alternativo Cuadro 3.17: Especificaci´on Caso de Uso CU-12 19 3.3. CASOS DE USO CU-13 Crear comentario Descripci´on El sistema permite al usuario crear un comentario. Precondici´on Ver comentarios (CU-01) y estar identificado. Flujo normal 1. El usuario registrado selecciona la opci´on de identificarse. 2. El sistema muestra los campos que debe rellenar el usuario registrado. 3. El usuario registrado rellena los campos. 4. El sistema valida los campos e identifica al usuario. 5.El flujo finaliza correctamente. Postcondici´on El usuario registrado se ha identificado en el sistema Flujo alternativo 4a Contrase˜na incorrecta: 1. El sistema avisa al usuario que la contrase˜na introducida es incorrecta. 2. Retorna al punto 1. 4b Correo incorrecto: 1. El sistema avisa al usuario que el correo introducido no es v´alido. 2. Retorna al punto 1. Cuadro 3.18: Especificaci´on Caso de Uso CU-13 20 CAP´ ITULO 3. AN ´ ALISIS CU-14 A˜nadir favorito Descripci´on El sistema permite al usuario a˜nadir un sitio a sus favoritos. Precondici´on Estar identificado y visualizar alg´un sitio. Flujo normal 1. El usuario registrado selecciona la opci´on de a˜nadir a favoritos. 2. El sistema comprueba que no exista ya ese favorito y lo a˜nade. 3.El flujo finaliza correctamente. Postcondici´on El usuario registrado ha a˜nadido un nuevo sitio a sus favoritos Flujo alternativo 2a Favorito existente: 1. El sistema detecta que ya exist´ıa ese favorito, por lo tanto no lo a˜nade de nuevo. 2. El flujo finaliza correctamente. Cuadro 3.19: Especificaci´on Caso de Uso CU-14 CU-15 Eliminar favorito Descripci´on El sistema permite al usuario eliminar un sitio de sus favoritos. Precondici´on Estar identificado y tener alg´un favorito. Flujo normal 1. El usuario registrado selecciona la opci´on de eliminar de favoritos. 2. El sistema borra ese favorito. 3.El flujo finaliza correctamente. Postcondici´on El usuario registrado ha borrado un sitio de sus favoritos Flujo alternativo Cuadro 3.20: Especificaci´on Caso de Uso CU-15 21 3.4. REQUISITOS DE INFORMACI ´ ON Actor AC-03: Gerente CU-16 Subir monumentos Descripci´on El sistema permite al gerente subir nuevos monumentos. Precondici´on Estar identificado como gerente. Flujo normal 1. El gerente selecciona el documento a subir. 2. El sistema selecciona los monumentos del documento y realiza el cambio en la base de datos. 3.El flujo finaliza correctamente. Postcondici´on El gerente ha modificado los documentos. Flujo alternativo 2a Tipo incorrecto: 1. El sistema detecta que el documento subido no es un json y avisa al gerente. 2. Retorna al punto 1. Cuadro 3.21: Especificaci´on Caso de Uso CU-16 3.4. Requisitos de Informaci´on En este apartado hablaremos sobre los datos utilizados en la aplicaci´on, aunque, como se ver´a, en esta aplicaci´on solo se tienen dos tipos de datos, los usuarios registrados y los sitios. Adem´as, todos los sitios, menos los monumentos, no est´an guardados en la base de datos de Firebase, sino que se piden a la API de la Junta en el momento de su solicitud por parte del usuario de la aplicaci´on. Tambi´en, los sitios y favoritos se guardan de la misma forma en la DB, por lo que solo ponemos la tabla de sitio. 22 CAP´ ITULO 3. AN ´ ALISIS RI-E01 Usuario Descripci´on Esta entidad define al usuario registrado de la aplicaci´on. Atributos ID Nombre Descripci´on Dominio Unique Null PK RI-E01.1 Correo Contiene el email del usuario. String Si No No RI-E01.2 Contrase˜na Contiene la contrase˜na del usuario. String No No No RI-E01.3 UID Contiene la clave primaria del usuario, generada por Firebase. String Si No Si Cuadro 3.22: Definici´on de Usuario en DB RI-E02 Sitio Descripci´on Esta entidad define al sitio de la aplicaci´on, en la DB. Atributos ID Nombre Descripci´on Dominio Unique Null PK RI-E02.1 email Contiene el email del sitio. String Si Si No RI-E02.2 accesibles minusvalidos Contiene si el sitio es accesible por minusv´alidos. Boolean No Si No RI-E02.3 categor´ıa Contiene la categor´ıa del sitio. String No Si No RI-E02.4 cp Contiene el c´odigo postal del sitio. String No Si No RI-E02.5 direcci´on Contiene la direcci´on del sitio. String No Si No RI-E02.6 establecimiento Contiene el tipo de establecimiento del sitio, dentro de los datos de la Junta. String No Si No 23 3.7. SOBRE LOS DATOS DE LA JUNTA Nombre Tipo Ejemplo establecimiento texto Alojam. Turismo Rural num registro texto 34/000225 codigo texto tipo texto Casa Rural de Alquiler categoria texto 2ª2 Estrellas especialidades texto clase texto nombre texto LA TOBA direccion texto Calle ALTA 4 cp texto 34247 provincia texto Palencia municipio texto Cevico Navero localidad texto CEVICO NAVERO nucleo texto CEVICO NAVERO telefono 1 texto 607516354 telefono 2 texto 979797574 telefono 3 texto email texto [email protected] web texto http://www.latobacasarural.com/ q calidad texto central reservas texto posada real texto plazas int 4 longitud decimal -4.1860705 latitud decimal 41.8614695 accesibles minusvalidos texto posicion geo point 2d 41.8614695, -4.1860705 Cuadro 3.29: Esquema del 1ºConjunto de Datos El segundo conjunto, el de los museos, ten´ıa un esquema muy similar al anterior, quitando algunos atributos que nunca aparecer´ıan o cambi´andole el nombre a otros, pero a 03/06/2021 decidieron cambiar el esquema, quitando algunos datos que se utilizaban en la aplicaci´on. 30 CAP´ ITULO 3. AN ´ ALISIS Nombre Que es Tipo descripcionblob Descripcion texto nombreentidad Nombre texto directoriorelacionado DirectorioRelacionado texto directoriorelacionado0 Latitud decimal column 5 Longitud decimal column 6 Zoom int directoriorelacionado1 ID DirectorioRelacionado int localidad Localidad texto localidad0 ID Localidad int soloclasificar SoloClasificar texto tipo de gestion Tipo de Gesti´on texto horario de apertura Horario de apertura texto requisitos especificos para el acceso Requisitos espec´ıficos para el acceso texto accesibilidad Accesibilidad texto servicios disponibles Servicios disponibles texto informacion adicional Informaci´on adicional texto codigo C´odigo texto directorio superior Directorio Superior texto identificador directorio superior Identificador Directorio Superior int identificador Identificador int ultimaactualizacion ultimaActualizacion fecha enlace al contenido Enlace al contenido texto posicion Posici´on geo point 2d Cuadro 3.30: Esquema del 2ºConjunto de Datos 31 3.7. SOBRE LOS DATOS DE LA JUNTA El tercer conjunto de datos, los monumentos, es el que menos atributos y datos contiene. Nombre Tipo Ejemplo identificador texto 23941 nombre texto Risco La Zorrera tipoMonumento texto Yacimientos arqueol´ogicos identificadorBienInteresCultural texto 696 calle texto Risco La Zorrera clasificacion texto Yacimiento tipoConstruccion texto Arte rupestre codigoPostal texto 5489 Descripcion texto Descubierto en 1986 consta de dos paneles verticales y un tercero horizontal que cubre los anteriores. Pueden distinguirse tres fases de ejecuci´on, predominando en la primera los trazos de color rojo, en la segunda destaca una figura de forma humana, y la tercera incluye figuras animales y humanas alargadas. Se ha interpretado como la representaci´on de un templo o altar. email texto estiloPredominante texto fax texto horariosYTarifas texto periodoHistorico texto Edad del Hierro,Neol´ıtico,Edad del Bronce provincia texto ´ Avila municipio texto Candeleda localidad texto Raso (El) telefono texto latitud texto 40.170041 longitud texto -5.339664 web texto Cuadro 3.31: Esquema del 3ºConjunto de Datos 32 CAP´ ITULO 4. DISE ˜ NO Cap´ıtulo 4 Dise˜no 4.1. Arquitectura l´ogica En este apartado se describir´a la arquitectura l´ogica de la aplicaci´on. Como se ha dicho anteriormente, la aplicaci´on consiste en un Front-End desarrollado con Angular 11, y un Back-End formado, tanto por Firebase, con la base de datos y la parte de autenticaci´on, como con los datos abiertos mantenidos por la Junta. Por ello, vamos a hablar de ambas partes. En lo que respecta al Back-End de la aplicaci´on, los datos abiertos de la Junta se consumen de forma f´acil, ya que la propia Junta da un acceso a ellos mediante una HTTP API-REST, la cual devuelve los datos pedidos en formato Json [3. Para la utilizaci´on de Firebase, utilizamos el paquete oficial de Google para integrar Firebase a nuestro proyecto Angular. En Firebase, como se ha dicho anteriormente, utilizamos el apartado de Realtime Database, la cual es una base de datos en tiempo real, NoSql con formato Json, y el apartado Authentication, el cual lleva a cabo la l´ogica con respecto a los usuarios registrados de la aplicaci´on. En lo que respecta al Front-End, Angular utiliza un patr´on basado en componentes. Cada componente contiene 3 partes: Un archivo formato TypeScript, el cual contiene la l´ogica de negocio del componente, un archivo HTML, el cual tiene la parte visual del componente, y un archivo CSS, con los estilos a ser usados en el HTML. Fuera de los componentes tenemos los modelos, los cuales contienen las estructuras de los objetos a tratar, y los servicios, en los cuales est´a la l´ogica de negocio correspondiente a la comunicaci´on con las API-REST y el servicio de Firebase. 33 4.1. ARQUITECTURA L ´ OGICA Figura 4.1: Diagrama Arquitectura L´ogica 34 CAP´ ITULO 4. DISE ˜ NO 4.2. Arquitectura f´ısica La arquitectura f´ısica representa los componentes hardware necesarios para desplegar satisfactoriamente la aplicaci´on. En nuestro caso tenemos una arquitectura Cliente-Servidor, en la cual el lado del cliente (Front-End) pide los datos necesarios al lado del servidor (Back-End). Figura 4.2: Diagrama Arquitectura F´ısica 4.3. Dise˜no Base de Datos En esta secci´on se mostrar´a el dise˜no de la base de datos, el cual ense˜naremos a trav´es del Diagrama de clases y, despu´es de esto, el detalle de cada tabla. 35 4.3. DISE ˜ NO BASE DE DATOS Figura 4.3: Diagrama de clases El detalle de cada tabla viene a continuaci´on. 36 CAP´ ITULO 4. DISE ˜ NO Tabla Usuario Atributos Nombre Descripci´on Dominio Unique Null PK Correo Contiene el email del usuario. String Si No No Contrase˜na Contiene la contrase˜na del usuario. String No No No UID Contiene la clave primaria del usuario, generada por Firebase. String Si No Si Cuadro 4.1: Tabla Usuario Tabla Sitio Atributos Nombre Descripci´on Dominio Unique Null PK email Contiene el email del sitio. String Si Si No accesibles minusvalidos Contiene si el sitio es accesible por minusv´alidos. Boolean No Si No categor´ıa Contiene la categor´ıa del sitio. String No Si No cp Contiene el c´odigo postal del sitio. String No Si No direcci´on Contiene la direcci´on del sitio. String No Si No establecimiento Contiene el tipo de establecimiento del sitio, dentro de los datos de la Junta. String No Si No localidad Contiene la localidad del sitio. String No Si No 37 4.3. DISE ˜ NO BASE DE DATOS Tabla Sitio municipio Contiene el municipio del sitio. String No Si No nombre Contiene el nombre del sitio. String No No Si nucleo Contiene el n´ucleo de poblaci´on del sitio. String No Si No num registro Contiene el n´umero de registro del sitio. String No No Si provincia Contiene la provincia del sitio. String No Si No telefono 1 Contiene el primer tel´efono del sitio. String No Si No telefono 2 Contiene el segundo tel´efono del sitio. String No Si No plazas Contiene el n´umero de plazas del sitio. Integer No Si No latitud Contiene la latitud del sitio. Integer No Si No longitud Contiene la longitud del sitio. Integer No Si No web Contiene la web del sitio. String Si Si No Cuadro 4.2: Tabla Sitio 38 CAP´ ITULO 4. DISE ˜ NO Tabla Comentario Atributos Nombre Descripci´on Dominio Unique Null PK comment Contiene el texto del comentario. String No No No score Contiene la puntuaci´on del comentario. Integer No No No date Contiene la fecha del comentario. String No No No Cuadro 4.3: Tabla Comentario Al ser RealTime Database una DB NoSql, no tenemos claves primaria o for´aneas. En la tabla usuario se ha marcado el uid como PK, ya que es la forma que tiene Firebase Authentication de identificar cada usuario ´unico. En la tabla sitio, por otro lado, se han marcado el num registro y el nombre como ´unicos, ya que es lo que se usa en la aplicaci´on para identificar un sitio. Esto es como se ve la base de datos, RealTime Database, en Firebase. Figura 4.4: RealTime Database Firebase La parte de Authentication, donde est´an los usuarios es la siguiente. 39 4.5. DIAGRAMAS DE INTERFAZ DE USUARIO Figura 4.11: Boceto de p´agina de favoritos 46 CAP´ ITULO 4. DISE ˜ NO Figura 4.12: Boceto de p´agina de subida de fichero de monumentos 47 4.5. DIAGRAMAS DE INTERFAZ DE USUARIO Figura 4.13: Boceto de PopUp de inicio sesi´on 48 CAP´ ITULO 4. DISE ˜ NO Figura 4.14: Boceto de PopUp de registrarse 49 4.5. DIAGRAMAS DE INTERFAZ DE USUARIO 50 CAP´ ITULO 5. IMPLEMENTACI ´ ON Cap´ıtulo 5 Implementaci´on En esta parte del documento hablaremos del desarrollo e implementaci´on del c´odigo de la aplicaci´on, asi como de las herramientas y tecnolog´ıas utilizadas para ello. 5.1. Herramientas y Tecnolog´ıas 5.1.1. Herramientas de desarrollo Visual Studio Code: Editor de c´odigo utilizado para el desarrollo de la aplicaci´on. Cuenta con soporte para utilizar Git. Google Chrome: Navegador utilizado para realizar las pruebas durante el desarrollo y el buen funcionamiento de la aplicaci´on al finalizarla. Git: Sistema de control de versiones creado por Linus Torvalds. Es el sistema m´as utilizado en el mundo. GitHub: Portal basado en Git, el cual permite gestionar proyectos software y controlar sus versiones. Permite crear repositorios que pueden enlazarse con los repositorios Git en local. Estos repositorios pueden ser p´ublicos o privados. Heroku: Heroku es una “Plataforma como Servicio” (PaaS: Platform as a Service), a su vez, es una de las m´as empleadas actualmente. Permite desplegar aplicaciones en la nube y permite una gran variedad de lenguajes de programaci´on. Tambi´en puede enlazarse con un repositorio de GitHub para utilizar la aplicaci´on subida en este. API-REST Junta CyL: Api utilizada para sacar datos abiertos, relacionados con el turismo, de la Junta de Castilla y Le´on. La Api en concreto es la ODS Search V1 o lo que es lo mismo OpenDataSoft search Api Version 1, la cual pertenece a OpenDataSoft. Google Maps JavaScript API: Api, perteneciente a Google, utilizada para el desarrollo del apartado del mapa en la aplicaci´on. 51 5.2. RENDIMIENTO Y PRECIOS DE FIREBASE Y API´S DE GOOGLE Google Maps Angular: M´odulo para Angular que, permite la utilizaci´on de la Api de Google Maps, ya que, Angular es TypeScript, lo cual da algunos problemas con la utilizaci´on directa de la Api de Google. Google Maps Geocoding API: Api, perteneciente a Google, utilizada para el desarrollo del apartado del mapa en la aplicaci´on. En concreto para la obtenci´on de la latitud y longitud de gran parte de los sitios de los datos de la Junta. 5.1.2. Herramientas de soporte Astah UML: Aplicaci´on que permite el desarrollo de diagramas UML. MockFlow: Herramienta online para la realizaci´on de Wireframes. Se ha utilizado para realizar los bocetos de la interfaz. Creately: Herramienta online para la realizaci´on de diagramas y gr´aficos. Se ha utilizado para realizar los diagramas de arquitectura. Overleaf: Herramienta online para realizar documentos, basada en Latex. 5.1.3. Tecnolog´ıas utilizadas Firebase: Firebase es una plataforma en la nube, perteneciente a Google, que, permite el desarrollo y monitorizaci´on de aplicaciones web y m´ovil. Sus funcionalidades son varias y se pueden agrupar en 4 grupos, aunque, para esta aplicaci´on hemos utilizado 2 de ellas. •RealTime Database: Base de datos en tiempo real, de tipo NoSQL con un formato parecido a Json. •Authentication: Sistema de autenticaci´on de usuarios provisto por Firebase. Este permite registrar usuarios tanto por correo electr´onico, como utilizando diferentes redes sociales, tales como Facebook o Twitter. Angular 11: Framework, perteneciente a Google, para facilitar la creaci´on de aplicaciones web SPA (Single Page Application), el cual hace uso del lenguaje TypeScript. TypeScript: Lenguaje de programaci´on basado en JavaScript, que hace una serie de cambios para reducir el n´umero de errores y hacerlo m´as f´acil de mantener. 5.2. Rendimiento y precios de Firebase y API´s de Google Para la aplicaci´on, hay que tener en cuenta que, tanto para Firebase como para las API´s de Google, se est´an utilizando, o el plan gratuito o el m´as barato, por lo que hay que tenerlo en cuenta a la hora de utilizar la aplicaci´on, esto siendo sobretodo cierto a la hora de hacer muchas peticiones en el mapa, ya que, la API de Geocoding limita las peticiones por minuto. 52 CAP´ ITULO 5. IMPLEMENTACI ´ ON 5.2.1. Firebase Para Firebase, de los dos planes disponibles, se esta usando el plan Blaze, el cual es de pago pero, que incluye los servicios del plan Spark, el cual es gratuito. Esto es as´ı ya que, al ser Firebase parte de Google y necesitar, tanto la API de mapas como la de Geocoding, de una tarjeta de cr´edito para su funcionamiento, el plan de Firebase se pone de forma autom´atica en Blaze. Para la aplicaci´on no es un problema, ya que, tanto RealTime Database como Authentication, se utilizan poco, por lo que no se tiene ning´un gasto por la parte de Firebase. En cuanto al rendimiento de Firebase. Authenticate: No hay l´ımite de peticiones de autenticaci´on en la aplicaci´on, por lo tanto no hay problemas de rendimiento por esta parte. RealTime Database: El plan Blaze permite hasta 200.000 conexiones simult´aneas con la base de datos y no hay un m´aximo de GB de almacenamiento ni de descargas mensuales; mientras que, el plan Spark permite hasta 100 conexiones simult´aneas, un m´aximo de 10 GB de almacenamiento y un tope de 10 GB descargados por mes. Como se ha dicho antes, primero se gasta la parte gratuita del plan Spark y luego se empieza a cobrar seg´un el plan Blaze, por lo que, para esta aplicaci´on, por lo menos para el desarrollo de la misma y las pruebas realizadas para su defensa, no se llegar´an a los topes de plan Spark. 5.2.2. API´s de Google Sobre las dos API´s de Google, mapas y geolocalizaci´on, ambas cobran por su uso, pero dando 500 $de gasto al crear la aplicaci´on, y 200 $para gastar cada mes. Durante la realizaci´on de la aplicaci´on, y las pruebas al finalizar esta, se ha superado este gasto total de 700 $, durante el mes de mayo, por lo que el uso de la aplicaci´on, en su parte del mapa, ha requerido de un gasto monetario. A continuaci´on, los precios de cada API. Figura 5.1: Precio de Google Maps JavaScript API 53 5.2. RENDIMIENTO Y PRECIOS DE FIREBASE Y API´S DE GOOGLE Figura 5.2: Precio de Google Maps Geocoding API En cuanto al rendimiento, a continuaci´on los l´ımites de llamadas a cada API. Figura 5.3: Limite de Google Maps JavaScript API Figura 5.4: Limite de Google Maps Geocoding API Los l´ımites en Google Maps JavaScript API no afectan a la aplicaci´on, para el uso dado actualmente; pero, los l´ımites en Google Maps Geocoding API si, ya que, algunas peticiones como, todos los bares o todos los restaurantes, necesitan de mas de 3000 peticiones a la API, esto provoca un cuello de botella y hace que la p´agina se ralentice intentando conseguir los 54 CAP´ ITULO 5. IMPLEMENTACI ´ ON datos de latitud y longitud de los diferentes sitios. La forma de arreglar esto ser´ıa aumentando ese l´ımite, pero entonces, se sobrepasar´ıa el l´ımite de 200 $muy r´apido. Si la aplicaci´on se llega a usar de forma comercial en alg´un momento se cambiar´ıa ese l´ımite pero, para el desarrollo de la misma no se ha tocado. 5.3. Estructura del Proyecto La estructura del proyecto general es la siguiente. 55 5.4. IMPLEMENTACI ´ ON Figura 5.16: Crear Aplicaci´on Firebase nombre Figura 5.17: Crear Aplicaci´on Firebase Analytics 62 CAP´ ITULO 5. IMPLEMENTACI ´ ON Figura 5.18: Crear Aplicaci´on Firebase Ubicaci´on Analytics Una vez creada la aplicaci´on, en el men´u izquierdo seleccionamos Compilaci´on, y dentro de ello Authentication. Figura 5.19: Aplicaci´on Firebase creada 63 5.4. IMPLEMENTACI ´ ON Dentro del apartado de Authentication, a˜nadimos el servicio y seleccionamos, de entre las opciones posibles para la autenticaci´on la de correo para habilitarla. Figura 5.20: Authentication correo Despu´es, en el men´u lateral, seleccionamos RealTime Database y a˜nadimos el servicio con las opciones predeterminadas, con lo cual, nos queda algo como lo siguiente. Figura 5.21: RealTime Database nueva 64 CAP´ ITULO 5. IMPLEMENTACI ´ ON Una vez creada la base de datos, volvemos a la p´agina de inicio de la aplicaci´on y seleccionamos a˜nadir aplicaci´on web. Primero nos pedir´a el nombre de la aplicaci´on y despu´es, nos dar´a un c´odigo que hay que copiar en la aplicaci´on para poder conectarla con Firebase. Figura 5.22: Nombre aplicaci´on web para Firebase Figura 5.23: C´odigo de Firebase a copiar 65 5.5. HEROKU 5.5. Heroku Para el despliegue del Front-End de la aplicaci´on hemos escogido Heroku para realizar el despliegue. Nos hemos decantado por esta herramienta ya que, como hemos explicado en el apartado de Herramientas de Desarrollo, Heroku permite conectar la aplicaci´on en Heroku con un repositorio de GitHub, con lo que, todo cambio realizado en el repositorio se va a ver aplicado en Heroku. Adem´as, al buscar posibles herramientas donde desplegar el Front-End, vimos que, desplegar una aplicaci´on Angular en Heroku es muy sencillo. Como ya se ha dicho en el resumen y el abstract, la aplicaci´on est´a desplegada en https: //turismocyl.herokuapp.com/. 66 CAP´ ITULO 6. PRUEBAS Cap´ıtulo 6 Pruebas En este cap´ıtulo se encuentran las pruebas realizadas para comprobar el correcto funcionamiento de la aplicaci´on. Para ello se han llevado a cabo pruebas de caja negra. 6.1. Pruebas de Caja Negra Las pruebas de caja negra se llevan a cabo de tal forma que, no es necesario saber como funciona la aplicaci´on o tener el c´odigo durante el desarrollo de las pruebas. A continuaci´on se encuentran las pruebas de caja negra realizadas, todas ellas con resultado satisfactorio. PCN-01: Registrar nuevo usuario. PCN-02: Buscar sitios, de primer conjunto de datos, por tipo en el mapa. PCN-03: Buscar sitios, de segundo conjunto de datos, por tipo en el mapa. PCN-04: Buscar sitios, de tercer conjunto de datos, por tipo en el mapa. PCN-05: Buscar sitios por provincia en el mapa. PCN-06: Buscar sitios, de primer conjunto de datos, por tipo y provincia en el mapa. PCN-07: Buscar sitios, de segundo conjunto de datos, por tipo y provincia en el mapa. PCN-08: Buscar sitios, de tercer conjunto de datos, por tipo y provincia en el mapa. PCN-09: Buscar sitios por texto en el mapa. 67 6.1. PRUEBAS DE CAJA NEGRA PCN-10: Ver ventana con informaci´on al clicar un marcador. PCN-11: Abrir ver comentarios, desde una ventana con informaci´on abierta. PCN-12: Error al intentar a˜nadir a favoritos, desde una ventana con informaci´on abierta, si no has iniciado sesi´on previamente. PCN-13: Buscar sitios, de primer conjunto de datos, por tipo en la tabla. PCN-14: Buscar sitios, de segundo conjunto de datos, por tipo en la tabla. PCN-15: Buscar sitios, de tercer conjunto de datos, por tipo en la tabla. PCN-16: Buscar sitios por provincia en la tabla. PCN-17: Buscar sitios, de primer conjunto de datos, por tipo y provincia en la tabla. PCN-18: Buscar sitios, de segundo conjunto de datos, por tipo y provincia en la tabla. PCN-19: Buscar sitios, de tercer conjunto de datos, por tipo y provincia en la tabla. PCN-20: Buscar sitios por texto en la tabla. PCN-21: Ordenar por atributo en una tabla con sitios previamente buscados. PCN-22: Pasar de grupo de 5 sitios, en una tabla con sitios previamente buscados. PCN-23: Buscar, por texto, entre los sitios previamente buscados. PCN-24: Ir al mapa, desde la tabla, con un sitio seleccionado. PCN-25: Abrir ver comentarios, desde una tabla. PCN-26: Error al intentar a˜nadir a favoritos, desde una tabla, si no has iniciado sesi´on previamente. PCN-27: Error al intentar a˜nadir un comentario si no has iniciado sesi´on previamente. PCN-28: Ordenar los comentarios por fecha o puntuaci´on. PCN-29: Iniciar sesi´on. PCN-30: A˜nadir un sitio a favoritos tanto, desde el mapa o desde la tabla. PCN-31: A˜nadir un nuevo comentario. PCN-32: Ver tus sitios favoritos. PCN-33: Borrar un sitio de favoritos. PCN-34: Ir al mapa, desde favoritos, con un sitio seleccionado. PCN-35: Abrir ver comentarios, desde favoritos. PCN-36: Ordenar por atributo en favoritos. PCN-37: Buscar, por texto, entre los sitios favoritos. 68 CAP´ ITULO 6. PRUEBAS PCN-38: Salir de sesi´on. PCN-39: Iniciar sesi´on como gerente. PCN-40: Actualizar los monumentos. 69 6.1. PRUEBAS DE CAJA NEGRA 70 CAP´ ITULO 7. CONCLUSIONES Cap´ıtulo 7 Conclusiones Este proyecto ten´ıa cinco objetivos principales, el primero hace referencia al prop´osito de la aplicaci´on, los 3 siguientes hac´ıan referencia al desarrollo de la aplicaci´on en si, mientras que el ´ultimo referenciaba la mejora de los conocimientos adquiridos en la carrera. Despu´es de haber finalizado el trabajo, concluyo que se han cumplido los 5 objetivos planeados. Sobre el primero concluyo que, se ha cumplido el objetivo de desarrollar una aplicaci´on web con el prop´osito de dar informaci´on tur´ıstica sobre diferentes sitios para visitar en Castilla y Le´on. Sobre los 3 siguientes, se han desarrollado todas las funcionalidades de la aplicaci´on, completando as´ı una aplicaci´on web sobre sitios que visitar en Castilla y Le´on utilizando los datos abiertos dados por la Junta, En relaci´on al ´ultimo, si que he desarrollado m´as mis conocimientos en las tecnolog´ıas utilizadas, las cuales ya hab´ıa usado en la carrera. Sin embargo, considero que la aplicaci´on tiene margen de mejora futuro en ciertos aspectos, los cuales trato en el siguiente cap´ıtulo. 71 BIBLIOGRAF´ IA [12] GitHub de Angular Maps. https://github.com/robisim74/angular-maps Fecha de ´ultimo acceso: 18/05/2021 [13] Documentaci´on oficial de las API´s de Google. https:// developers-dot-devsite-v2-prod.appspot.com/maps/documentation/ javascript/reference Fecha de ´ultimo acceso: 28/04/2021 [14] Cookies en Angular. https://itnext.io/angular-8-how-to-use-cookies-14ab3f2e93fc Fecha de ´ultimo acceso: 25/04/2021 [15] Documentaci´on oficial de Firebase. https://firebase.google.com/docs/web/setup Fecha de ´ultimo acceso: 13/04/2021 [16] Documentaci´on oficial de Angular. https://angular.io/ Fecha de ´ultimo acceso: 13/05/2021 [17] Documentaci´on oficial de Bootstrap 4. https://getbootstrap.com/docs/4.0/ getting-started/introduction/ Fecha de ´ultimo acceso: 13/05/2021 [18] P´agina sobre JSON en Node. https://attacomsian.com/blog/ nodejs-read-write-json-files Fecha de ´ultimo acceso: 15/05/2021 [19] Documentaci´on oficial de Material Design para Bootstrap 4 y Angular. https:// mdbootstrap.com/docs/angular/getting-started/installation/ Fecha de ´ultimo acceso: 28/05/2021 [20] GitHub del componente Angular para las estrellas en la puntuaci´on. https://github. com/BioPhoton/angular-star-rating Fecha de ´ultimo acceso: 28/05/2021 [21] Como desplegar una aplicaci´on Angular en Heroku. https://medium.com/@roliver_ javier/como-desplegar-tu-aplicacion-de-angular-en-heroku-7b9941b6d39 Fecha de ´ultimo acceso: 31/05/2021 [22] Como desplegar una aplicaci´on Angular en Heroku 2. https://betterprogramming. pub/how-to-deploy-your-angular-9-app-to-heroku-in-minutes-51d171c2f0d Fecha de ´ultimo acceso: 31/05/2021 [23] Generador de tablas para Latex, utilizado para la realizaci´on de la memoria. https: //www.tablesgenerator.com/ Fecha de ´ultimo acceso: 16/06/2021 [24] Informaci´on sobre el Hash de Firebase para Authenticate. https:// firebaseopensource.com/projects/firebase/scrypt/ Fecha de ´ultimo acceso: 24/04/2021 [25] Presentaci´on sobre datos abiertos, realizada en la Universidad. https://www.inf.uva. es/2021/05/26/se-celebro-en-el-salon-de-actos-del-edificio-tit-una-sesion-informativa-sobre-datos-abiertos/ Fecha de ´ultimo acceso: 19/06/2021 [26] P´agina utilizada para la creaci´on de diagramas. https://creately.com/es/lp/ software-de-diagrama-de-flujo/ Fecha de ´ultimo acceso: 09/06/2021 78 BIBLIOGRAF´ IA [27] Informaci´on sobre la facturaci´on y precios de las API´s de Google. https:// developers.google.com/maps/billing/gmp-billing?hl=es-419 Fecha de ´ultimo acceso: 12/06/2021 [28] Informaci´on sobre la facturaci´on y precios de las API´s de Google 2. https://cloud. google.com/maps-platform/pricing Fecha de ´ultimo acceso: 12/06/2021 [29] P´agina utilizada para la b´usqueda de precios medios. https://es.indeed.com/ Fecha de ´ultimo acceso: 19/06/2021 [30] P´agina de Wikipedia sobre el modelo de prototipos. https://es.wikipedia.org/wiki/ Modelo_de_prototipos Fecha de ´ultimo acceso: 19/06/2021 79