scieee AI-readable full text Open interactive document viewer

Servicios REST, aplicación web y Android para la Gestión de Parkings con soporte para pagos PayPal y navegación con Google Maps

Galindo Rodríguez, José María

Abstract

En el mundo actual, el concepto de ciudad inteligente está ganando más interés y apoyo por parte del ser humano con el objetivo específico de enriquecer la eficiencia y la comodidad relacionadas con nuestras actividades diarias. Este fenómeno está respaldado por una variedad de avances tecnológicos que han redefinido nuestra relación con los elementos del entorno urbano. Toda esta evolución ha sido impulsada por la proliferación del uso de dispositivos móviles y el avance de la conectividad a Internet. Estos desarrollos nos han permitido poder tener la oportunidad de interactuar con los sistemas de parkings de nuestro entorno de otra forma distinta. En este proyecto se ha desarrollado una aplicación móvil que permite a los usuarios gestionar los vehículos, las reservas en los estacionamientos, visualizar en el mapa la información de los espacios de estacionamiento cercanos usando la API de Google Maps, control de entrada y salida del estacionamiento mediante el escaneo de QR y la posibilidad de realizar pagos de las tarifas a través de la plataforma de pago PayPal usando su API. Por otro lado, se han implementado dos servicios REST, uno para la gestión del centro de gestión de parkings y otro para la gestión del parking. Finalmente, se ha desarrollado una aplicación web para el gestor del parking la cual permite visualizar información para una gestión eficaz. El objetivo principal del proyecto es proporcionar a los usuarios herramientas fáciles y cómodas de usar para la interacción con los sistemas de estacionamiento. Además, proporcionar herramientas para la gestión del parking y los centros de gestión de parkings. Esto permitirá a los usuarios que la búsqueda de estacionamiento no sea una tarea dificultosa en los núcleos urbanos.

Full text

Equation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Servicios REST, aplicación web y Android para la Gestión de Parkings con soporte para pagos PayPal y navegación con Google Maps Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: José María Galindo Rodríguez Tutor: María Teresa Ariza Gómez Sevilla, 2024 iii Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Servicios REST, aplicación web y Android para la Gestión de Parkings con soporte para pagos PayPal y navegación con Google Maps Autor: José María Galindo Rodríguez Tutor: María Teresa Ariza Gómez Profesor titular Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 v Trabajo de Fin de Grado: Servicios REST, aplicación web y Android para la Gestión de Parkings con soporte para pagos PayPal y navegación con Google Maps Autor: José María Galindo Rodríguez Tutor: Maria Teresa Ariza Gómez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2024 El Secretario del Tribunal vii A mi familia A mis profesores ix Agradecimientos En primer lugar, agradecer a mi tutora Maria Teresa Ariza Gómez, por su ayuda, consejos, tiempo y conocimientos que me han ayudado a crecer tanto personal como académicamente. Además, agradecer la oportunidad de haber realizado este trabajo bajo su tutela. En segundo lugar, agradezco a mis padres, mi hermana y toda mi familia por confiar siempre en mí y por todo el esfuerzo y sacrificio que han realizado durante esta etapa de mi vida. Sus palabras cada día han sido una fuente de motivación y un apoyo incondicional durante todos estos años. Mi agradecimiento a mi pareja Censi, por ser el mayor apoyo día a día y a su vez por su infinita paciencia, motivación y ayuda. Su apoyo constante ha sido un faro de esperanza y fortaleza en cada paso de esta etapa. Por último, a todos mis compañeros con los que he compartido este camino durante estos años y las amistades que han surgido en esta etapa. Además, a todos los profesores por su ayuda y conocimiento brindado durante toda la carrera. José María Galindo Rodríguez Sevilla, 2024 4.2 Interfaz de usuario de la aplicación Android 63 4.2.1 Pantalla de inicio de sesión 64 4.2.2 Pantalla de registro 64 4.2.3 Pantalla principal 65 4.2.4 Pantalla de listar tus vehículos 66 4.2.5 Pantalla de ubicación de parkings 67 4.2.6 Pantalla de lista de reservas 68 4.2.7 Pantalla de entrada al parking 70 4.2.8 Pantalla de salida del parking 71 4.2.9 Salir de la aplicación 72 5 Aplicación web gestor de parking 73 5.1 Estructura y funcionalidad 73 5.2 Interfaz de usuario 77 5.2.1 Pantalla principal 77 5.2.2 Pantalla estado actual del parking 77 5.2.3 Pantalla para ver reservas solicitadas 79 5.2.4 Pantalla para crear nuevo parking 80 6 Conclusión y líneas futuras 83 6.1 Conclusiones técnicas 83 6.2 Conclusiones personales 83 6.3 Líneas futuras 83 6.3.1 Diseño 84 6.3.2 Funcionalidades 84 6.3.3 Seguridad 84 6.3.4 Despliegue e infraestructura 84 Anexo A: Instalación y Despliegue de los Servicios REST implementados 87 1. Instalación de los servidores REST 87 2. Inicio de las bases de datos 87 3. Despliegue de los servidores REST 87 Anexo B: Configuración de la API de PayPal y la API de Google Maps 89 1. Configuración de la API de PayPal 89 2. Configuración de la API de Google Maps 90 Referencias 93 xvii ÍNDICE DE TABLAS Tabla 3–1. Endpoints del servicio de centro de gestión de parkings 22 Tabla 3–2. Endpoints del servicio de gestión de parking 43 xix ÍNDICE DE ILUSTRACIONES Ilustración 1-1. Arquitectura del sistema 13 Ilustración 2-1. Portátil HP Omen 15-ax205ns 15 Ilustración 2-2. Android Studio 16 Ilustración 2-3. Ubuntu 22.04 16 Ilustración 2-4. Spring 16 Ilustración 2-5. Postman 17 Ilustración 2-6. PostgreSQL 17 Ilustración 2-7. Visual Studio Code 17 Ilustración 2-8. Wireshark 18 Ilustración 2-9. Emulador de Google Pixel 4 API 33 18 Ilustración 2-10. API Google Maps 19 Ilustración 2-11. API PayPal 19 Ilustración 2-12. Swagger OpenAPI 20 Ilustración 2-13. Spring Security 20 Ilustración 3-1. Endpoints en Swagger del centro de gestión de parkings 23 Ilustración 3-2. Respuesta petición GET a /api/parking 23 Ilustración 3-3. Petición POST a /api/vehículos 24 Ilustración 3-4. Respuesta exitosa del servidor a la petición POST 24 Ilustración 3-5. Petición PATCH a /api/reserva/confirmacion/{reserva_id} 25 Ilustración 3-6. Respuesta exitosa del servidor a la petición PATCH para confirmar 25 Ilustración 3-7. Respuesta exitosa del servidor a la petición PATCH para cancelar la confirmación 25 Ilustración 3-8. Petición DELETE a /api/reserva 26 Ilustración 3-9. Respuesta exitosa del servidor a la petición DELETE 26 Ilustración 3-10. Clases y estructura del servidor del centro de gestión de parkings 26 Ilustración 3-11. Application.java del servidor del centro de gestión de parkings 27 Ilustración 3-12. SwaggerConfig.java del servidor del centro de gestión de parkings 27 Ilustración 3-13. SecurityConfig.java del servidor del centro de gestión de parkings 28 Ilustración 3-14. Vehiculo.java del servidor del centro de gestión de parkings 28 Ilustración 3-15. VehiculoRepository.java del servidor del centro de gestión de parkings 29 Ilustración 3-16. ReservaRepository.java del servidor del centro de gestión de parkings 30 Ilustración 3-17. VehiculoService.java del servidor del centro de gestión de parkings 30 Ilustración 3-18. UsuarioService.java del servidor del centro de gestión de parkings 31 Ilustración 3-19. ReservaService.java del servidor del centro de gestión de parkings 31 Ilustración 3-20. ReservaService.java del servidor del centro de gestión de parkings 32 Ilustración 3-21. VehiculoController.java del servidor del centro de gestión de parkings 33 Ilustración 3-22. LoginController.java del servidor del centro de gestión de parkings 33 Ilustración 3-23. RegisterController.java del servidor del centro de gestión de parkings 34 Ilustración 3-24. Método reservar de ReservaController.java 35 Ilustración 3-25. Método obtenerInformacionReservaPorParking de ReservaController.java 35 Ilustración 3-26. Método confirmar de ReservaController.java 36 Ilustración 3-27. Método eliminarReserva de ReservaController.java 36 Ilustración 3-28. Diagrama entidad relación BBDD centro de gestión de parkings 38 Ilustración 3-29. Endpoints en Swagger de gestión de parking 43 Ilustración 3-30. Respuesta petición GET a /api/parking 43 Ilustración 3-31. Petición POST a /api/parking/entrada 44 Ilustración 3-32. Respuesta exitosa del servidor a la petición POST 44 Ilustración 3-33. Respuesta no exitosa del servidor a la petición POST 44 Ilustración 3-34. Clases y estructura del servidor de gestión de parking 45 Ilustración 3-35. Application.java del servidor de gestión de parking 45 Ilustración 3-36. SwaggerConfig.java del servidor de gestión de parking 46 Ilustración 3-37. EstadoActual.java del servidor de gestión de parking 46 Ilustración 3-38. EstadoActualRepository.java del servidor de gestión de parking 47 Ilustración 3-39. EstadoActualService.java del servidor de gestión de parking 48 Ilustración 3-40. ParkingService.java del servidor de gestión de parking 48 Ilustración 3-41. Método registrarEstadoActual de EstadoActualController.java servidor de gestión de parking 49 Ilustración 3-42. Método registrarSalida de EstadoActualController.java servidor de gestión de parking 49 Ilustración 3-43. Método registrarPago de EstadoActualController.java servidor de gestión de parking 50 Ilustración 3-44. ParkingController.java del servidor de gestión de parking 51 Ilustración 4-1. Casos de uso de la aplicación Android 55 Ilustración 4-2. Clases de la aplicación Android 56 Ilustración 4-3. Diagrama de secuencia aplicación Android para inicio de sesión y registro 58 Ilustración 4-4. Diagrama de secuencia aplicación Android para consultar parkings y consultar y dar de alta nuevos vehículos 59 Ilustración 4-5. Diagrama de secuencia aplicación Android para consultar, crear o eliminar reservas 61 Ilustración 4-6. Diagrama de secuencia aplicación Android para registrar una entrada o salida y realizar el pago de la tarifa 63 Ilustración 4-7. Pantalla de inicio de sesión 64 Ilustración 4-8. Pantalla de registro 65 Ilustración 4-9. Pantalla principal 66 Ilustración 4-10. Pantalla lista de vehículos 66 Ilustración 4-11. Pantalla registro de nuevo vehículo 67 Ilustración 4-12. Pantalla ubicación de parkings 68 Ilustración 4-13. Alerta con detalle del parking 68 xxi Ilustración 4-14. Pantalla lista de reservas 69 Ilustración 4-15. Pantalla nueva reserva 70 Ilustración 4-16. Pantalla entrada al parking 71 Ilustración 4-17. Pantalla salida del parking 71 Ilustración 4-18. Pantalla de pago PayPal 72 Ilustración 5-1. Casos de uso de la aplicación web 73 Ilustración 5-2. Estructura de la aplicación web 74 Ilustración 5-3. Diagrama de secuencia comunicación aplicación web, servidor centro de gestión de parkings y base de datos para dar de alta un nuevo parking, consultar y confirmar o cancelar reservas 75 Ilustración 5-4. Diagrama de secuencia comunicación aplicación web, servidor gestión de parking y base de datos para mostrar o modificar los datos del parking 76 Ilustración 5-5. Pantalla principal aplicación web 77 Ilustración 5-6. Pantalla estado actual del parking 78 Ilustración 5-7. Alerta cambios estado actual del parking 79 Ilustración 5-8. Pantalla reservas solicitadas 79 Ilustración 5-9. Pantalla dar de alta nuevo parking 80 Ilustración 5-10. Alerta al dar de alta nuevo parking correctamente 81 Ilustración 5-11. Alerta de error al dar de alta nuevo parking 81 Ilustración B-1. Configurar usuario en PayPal Developer 89 Ilustración B-2. Configurar aplicación en PayPal Developer 90 Ilustración B-3. Habilitar API Google Maps para Android 90 Ilustración B-4. Creación de clave para API Google Maps 91 Ilustración B-5. Código build.gradle a nivel de proyecto para API Google Maps 91 Ilustración B-6. Código build.gradle a nivel del módulo para API Google Maps 91 Ilustración B-7. Código AndroidManifest.xml para API Google Maps 91 xxiii Notación REST ART-IT QR HTTP API Transferencia de Estado Representacional Arquitectura de Referencia para el Transporte Cooperativo e Inteligente Código de Respuesta Rápida Protocolo de Transferencia Hipertexto Interfaz de Programación de Aplicaciones IDE Entorno de Desarrollo Integrado URL JPA DNI CRUD SQL Localizador Uniforme de Recursos API de Persistencia Java Documento Nacional de Identidad Crear, Leer, Actualizar y Borrar Lenguaje de Consulta Estructurado BBDD POM IP Base de Datos Modelo de Objetos de Proyecto Protocolo de Internet JSON NIF HTML Notación de Objetos JavaScript Número de Identificación Fiscal Lenguaje de Marcas de Hipertexto 11 1 INTRODUCCIÓN La ciencia de hoy es la tecnología de mañana. – Edward Teller – 1.1 Motivación ste proyecto surge ante la necesidad de transformar la experiencia de estacionamiento en entornos urbanos mediante la utilización de las nuevas tecnologías y convertirlo en un entorno más eficiente. Se implementa un sistema para que una tarea cotidiana como puede ser encontrar estacionamiento en grandes núcleos urbanos se haga más llevadera y no sea un desafío para los ciudadanos. Dicho sistema ayudará a realizar una búsqueda eficiente de espacios de estacionamiento, cobro de tarifas y gestionar los distintos estacionamientos, con tecnologías que se detallarán más adelante. Este proyecto no solo proporciona la ocasión especial de investigar, aprender y aplicar tecnologías avanzadas, como el desarrollo de servicios REST y la integración de un sistema para ciudades inteligentes, sino que también desempeña un papel esencial en mi desarrollo personal. Al participar en este proyecto a nivel académico, tengo la oportunidad de adquirir y perfeccionar mis habilidades en áreas fundamentales como el estudio de cómo funciona una ciudad inteligente, el diseño de aplicaciones móviles y la gestión de los espacios de estacionamiento, lo cual contribuirá significativamente a mi crecimiento y formación en estos campos clave. El objetivo principal del proyecto es proporcionar a los usuarios herramientas fáciles y cómodas de usar para la interacción con los sistemas de estacionamiento. Esto incluye reserva de estacionamiento, visualización de espacios de estacionamiento cercanos, control de entrada y salida del parking y la posibilidad de realizar pagos a través de plataformas de pago móvil. Además, proporcionar herramientas para la gestión del parking y los centros de gestión de parkings. Todo ello se realizará utilizando la tecnología que se describirá en los siguientes capítulos de este proyecto con el fin de mejorar la experiencia de estacionamiento del usuario e incrementar el uso de los recursos disponibles en estas áreas. Una solución beneficiosa para el usuario final y el medio ambiente. Este proyecto es una oportunidad para combinar nuevas tecnologías con un enfoque en la sostenibilidad y así dar ejemplo para futuras investigaciones y desarrollo sobre gestión inteligente de aparcamientos y ciudades inteligentes. 1.2 Objetivos En esta sección, se muestran los objetivos de este proyecto: • Implementar un servicio REST que permita simular el centro de gestión de parkings en el que se obtiene información de los diversos parkings del territorio donde se encuentre e información sobre los usuarios y los vehículos que hacen uso del sistema. • Implementar un servicio REST que permita monitorizar el estado en tiempo real del parking y comunicarse con el centro de gestión de parkings para el intercambio de información. • Desarrollar una aplicación Android intuitiva y centralizada con el fin de soportar las actividades diarias de los usuarios que hacen uso de la misma en su interacción con los parkings y el centro de gestión de parkings. Además, integrar los servicios de Google Maps y PayPal en la aplicación. E Recursos Utilizados 18 18 2.2.7 Wireshark Wireshark es un analizador de protocolos gratuito y de código abierto. Se utiliza para realizar análisis de redes de comunicaciones, desarrollo de software y protocolos y auditorías de seguridad. Este software captura todo tipo de paquetes que atraviesan una conexión y nos permite filtrar las capturas por tipo de protocolo. Es compatible con los principales sistemas operativos como Windows, IOS, Ubuntu, etc. [9] Ilustración 2-8. Wireshark 2.2.8 Emulador de Google Pixel 4 API 33 Android Studio proporciona una variedad de emuladores, y para este proyecto se ha seleccionado el emulador Google Pixel 4 API 33. Este emulador imita las características tanto de hardware como de software del dispositivo físico Android, facilitando así la prueba y depuración de las aplicaciones desarrolladas en el entorno de Android Studio de manera sencilla y comprensible. Ilustración 2-9. Emulador de Google Pixel 4 API 33 2.2.9 API Google Maps La API de Google Maps ofrece la posibilidad de personalizar mapas con imágenes y contenido propio para su visualización en páginas web y dispositivos móviles. Esta API incluye cuatro tipos de mapas básicos (ruta, satélite, híbrido y terreno) que pueden ser modificados con capas y diseños, controles y eventos, así como diversos servicios y bibliotecas. Para ello se necesita una cuenta de desarrollador de Google y una clave que proporciona la plataforma para hacer uso de esta API. [10] 19 Ilustración 2-10. API Google Maps 2.2.10 API PayPal La API de PayPal es una interfaz de programación de aplicaciones (API) proporcionada por PayPal que permite a los desarrolladores integrar funciones y servicios de PayPal en sus aplicaciones y sitios web. Con esta API, los desarrolladores pueden facilitar pagos en línea en su plataforma, administrar transacciones, acceder a información de cuentas, crear y enviar facturas, administrar listados y más. Esto brinda a los usuarios finales la capacidad de realizar pagos seguros y sin problemas sin abandonar el entorno familiar de la aplicación o el sitio web que utilizan. [11] Ilustración 2-11. API PayPal 2.2.11 Swagger OpenAPI La especificación OpenAPI, también conocida como Swagger, es un conjunto de reglas, especificaciones y herramientas de software de código abierto que nos ayudan a documentar servicios web RESTful. Esta herramienta permite documentar y definir claramente la estructura de las API REST que desees, esto conlleva una comprensión más fácil para los desarrolladores. Esta especificación posee una interfaz web que nos facilita la visualización de la estructura de la API REST y realizar las pruebas oportunas. [12] Recursos Utilizados 20 20 Ilustración 2-12. Swagger OpenAPI 2.2.12 Spring Security Spring Security es una biblioteca de seguridad diseñada para aplicaciones Java. Ofrece una amplia gama de herramientas que permiten autenticar y autorizar usuarios, así como proteger recursos y administrar sesiones de manera flexible. Gracias a sus características avanzadas, como la autenticación de usuarios, el control de acceso y la protección contra amenazas de seguridad. Spring Security ayuda a los desarrolladores a reforzar la seguridad de sus aplicaciones de forma efectiva. [13] Ilustración 2-13. Spring Security 21 3 SERVICIOS REST De vez en cuando, una nueva tecnología, un antiguo problema y una gran idea se convierten en una innovación. – Dean Kamen – 3.1 Servicio REST del centro de gestión de parkings sta sección es uno de los pilares fundamentales de este proyecto. Se explorarán minuciosamente las características fundamentales del servicio creado para la administración del centro de gestión de parkings. En este punto, se ofrecerá un análisis detallado tanto de la estructura completa de este servicio como de su interacción con la base de datos subyacente. Además, se abordará la documentación de los endpoints de este servicio mediante la herramienta Swagger. Este segmento proporcionará una descripción detallada sobre cómo opera el servicio REST del centro de gestión de parkings, destacando su relevancia dentro del panorama general de la aplicación al permitir la supervisión y control de este. 3.1.1 Servidor REST del centro de gestión de parkings Este subapartado se centra en explicar con detalle la estructura y configuración del servidor correspondiente con el centro de gestión de parkings. Se incluyen las dependencias en este servicio, la definición de endpoints y las clases de las que está compuesto. Por otro lado, se detallará cómo interaccionan las clases controladoras con la base de datos de este servicio. Para el manejo de los datos del parking se ha empleado el modelo de datos Fiware [14], en concreto, se usará el enfocado a las ciudades inteligentes y los parkings. Este modelo de datos define la estructura y el tipo de los datos en cada contexto, además, proporciona ejemplos. 3.1.1.1 Definición de endpoints En esta sección, se detallará un aspecto fundamental para el desarrollo del proyecto el cual consiste en detallar y explicar los endpoints de la API REST del centro de gestión de parkings implementada. Los endpoints se corresponden con los puntos de entrada a través de los cuales las aplicaciones se conectan con el servidor. Cada endpoint representa una acción particular que la API puede ejecutar, lo cual nos facilita el intercambio de datos y la comunicación de manera organizada y estructurada. Los diferentes endpoints del servicio REST correspondiente al centro de gestión de parkings pueden verse en la tabla 3-1 mostrada a continuación: PATH Método HTTP Descripción /api/login POST Permite autenticar a los usuarios en el sistema. E Servicios REST 22 22 /api/registro POST Permite dar de alta un nuevo usuario en el sistema. /api/parking GET Permite obtener una lista con todos los datos de los parkings de la base de datos. POST Permite dar de alta un nuevo parking en el sistema. /api/vehiculos GET Permite obtener una lista con todos los vehículos que tiene asociado un determinado usuario. POST Permite dar de alta en el sistema un vehículo asociado a un usuario. /api/reserva GET Permite obtener una lista con las reservas que tiene un determinado usuario asociadas al vehículo que tiene en propiedad. POST Permite crear una nueva reserva en la base de datos. DELETE Permite eliminar una reserva de la base de datos. /api/reserva/{id_parking} GET Permite obtener una lista con las reservas que están asociadas a un determinado parking. /api/reserva/confirmacion/{reserva_id} PATCH Permite a un parking confirmar o cancelar la confirmación de una reserva. Tabla 3–1. Endpoints del servicio de centro de gestión de parkings A continuación, se explicará cómo se utiliza Swagger para documentar el centro de gestión de parkings. Swagger es una herramienta que automáticamente genera documentación interactiva para las API REST. La documentación detallada proporciona información clara sobre los puntos finales de la API, los parámetros que aceptan y los formatos de respuesta esperados. La integración de Swagger facilita la comprensión y el uso de la API por parte de los desarrolladores, mejora la comunicación y la colaboración en el equipo de desarrollo. También ofrece una manera fácil de probar los puntos finales de la API directamente desde la interfaz de usuario de Swagger, lo que hace que el proceso de desarrollo y depuración sea más sencillo. La siguiente ilustración 3-1 nos muestra la vista desde la interfaz web de Swagger que nos permite visualizar los endpoints de un modo más gráfico. 23 Ilustración 3-1. Endpoints en Swagger del centro de gestión de parkings Algunos ejemplos de peticiones al servidor del centro de gestión de parkings son los siguientes: • Petición GET a http://localhost:8080/api/parking: esta petición se realiza para obtener los datos de los parkings del centro de gestión. La respuesta de esta petición sigue el formato del modelo de datos Fiware [14] para los parkings, se muestra en la siguiente ilustración 3-2: Ilustración 3-2. Respuesta petición GET a /api/parking Servicios REST 24 24 • Petición POST a http://localhost:8080/api/vehiculos: esta petición se realiza para dar de alta un nuevo vehículo en el centro de gestión. El cuerpo de la solicitud contiene, dni, matrícula, marca y modelo y número de plazas. En la ilustración 3-3 se puede ver el cuerpo de esta petición: Ilustración 3-3. Petición POST a /api/vehículos La respuesta obtenida la podemos ver en la ilustración 3-4. Obtenemos una respuesta exitosa con el código 200 OK en caso de que el registro se realice correctamente: Ilustración 3-4. Respuesta exitosa del servidor a la petición POST • Petición PATCH a http://localhost:8080/api/reserva/confirmacion/{reserva_id}: esta petición se realiza para modificar el estado de una reserva. En el cuerpo de esta petición se envía el estado de la reserva en el que confirmada puede ser true o false, ilustración 3-5: 25 Ilustración 3-5. Petición PATCH a /api/reserva/confirmacion/{reserva_id} La respuesta obtenida la podemos ver en la ilustración 3-6 para la confirmación. Obtenemos una respuesta exitosa con el código 200 OK en caso de que la modificación del estado se realice correctamente: Ilustración 3-6. Respuesta exitosa del servidor a la petición PATCH para confirmar La respuesta obtenida para cancelar la confirmación de la reserva la podemos ver en la ilustración 3-7: Ilustración 3-7. Respuesta exitosa del servidor a la petición PATCH para cancelar la confirmación Si queremos modificar el estado de una reserva con un identificador que no existe, el servidor nos devuelve una respuesta 404 NOT FOUND. • Petición DELETE a http://localhost:8080/api/reserva: esta petición se realiza para eliminar una reserva. En el cuerpo de esta petición se envía el identificador de la reserva, ilustración 3-8: Servicios REST 26 26 Ilustración 3-8. Petición DELETE a /api/reserva La respuesta obtenida la podemos ver en la ilustración 3-9. Obtenemos una respuesta exitosa con el código 200 OK en caso de que la eliminación se realice correctamente: Ilustración 3-9. Respuesta exitosa del servidor a la petición DELETE Si queremos borrar una reserva con un identificador que no existe, el servidor nos devuelve una respuesta 404 NOT FOUND. 3.1.1.2 Clases En este apartado se detallarán las clases que se utilizan en el servidor del centro de gestión de parkings. Están organizadas en directorios en función de su uso, se pueden distinguir por controladores, entidades, servicios y repositorios. En la ilustración 3-10 se puede observar la distribución de las mismas: Ilustración 3-10. Clases y estructura del servidor del centro de gestión de parkings 27 A continuación, se van a detallar las clases principales de este servidor: • Application.java (Ilustración 3-11): se corresponde con la clase principal que contine el método main. Ilustración 3-11. Application.java del servidor del centro de gestión de parkings • SwaggerConfig.java (Ilustración 3-12): esta clase configura la documentación de la API utilizando Swagger. Define un bean que especifica la ubicación de los controladores de la API, el tipo de documentación a generar y la información descriptiva de la API. Ilustración 3-12. SwaggerConfig.java del servidor del centro de gestión de parkings • SecurityConfig.java (Ilustración 3-13): esta clase se encarga de configurar la seguridad de la aplicación utilizando Spring Security. Se define un bean llamado passwordEncoder() que utiliza el algoritmo de encriptación BCrypt para encriptar las contraseñas. Esta encriptación garantiza un mayor nivel de seguridad al almacenar las contraseñas en la base de datos, lo que ayuda a proteger la información confidencial de los usuarios. Se describirá más en profundidad en un apartado posterior. Servicios REST 34 34 • RegisterController.java (Ilustración 3-23): gestiona las solicitudes de registro de usuarios. Su método registro() verifica si el usuario ya existe en la base de datos a través del DNI mediante una solicitud POST. Si el usuario no existe, encripta la contraseña proporcionada y guarda la información del usuario en la base de datos. Devuelve un mensaje indicando el éxito del registro si se completa correctamente. Si el DNI ya está registrado, devuelve un mensaje de error indicando que el DNI ya existe. Por otro lado, se usa passwordEncoder definido en SpringSecurity.java para la encriptación de la contraseña. Ilustración 3-23. RegisterController.java del servidor del centro de gestión de parkings • ReservaController.java: esta clase se corresponde con el controlador que gestiona las reservas en el centro de gestión de parkings. Contiene implementados los métodos que se detallan a continuación: - reservar (Ilustración 3-24): permite crear una nueva reserva de un vehículo en un parking específico, verificando previamente la existencia del vehículo y si existe una reserva para el mismo. Se implementa como restricción que las reservas son de días completos. Por otro lado, no se permite la reserva de un vehículo para la misma fecha en un parking. 35 Ilustración 3-24. Método reservar de ReservaController.java - obtenerInformacionReservaPorParking (Ilustración 3-25): se obtiene la información de las reservas de un parking. Ilustración 3-25. Método obtenerInformacionReservaPorParking de ReservaController.java Servicios REST 36 36 - obtenerInformacionReserva: este método es similar al anterior, en este caso, se obtiene la información de las reservas de un vehículo. - confirmar (Ilustración 3-26): permite confirmar o cancelar la confirmación de una reserva existente. Ilustración 3-26. Método confirmar de ReservaController.java - eliminarReserva (Ilustración 3-27): permite eliminar una reserva existente. Ilustración 3-27. Método eliminarReserva de ReservaController.java • ParkingController.java: esta clase gestiona las solicitudes de los parkings. Estos datos son manejados siguiendo el modelo de datos Fiware para los parkings. Presenta los siguientes métodos: - getAvailableParking: obtiene una lista con los datos de los parkings que tiene asociados el centro de gestión. Estos datos siguen la estructura y el formato definidos en el modelo de datos Fiware [14] para los parkings. 37 - updateParkingData: este método está marcado con @Scheduled para ejecutarse cada 2 minutos. Su función se corresponde con recopilar la información de los parkings para actualizarla en el centro de gestión de parkings mediante una petición a cada uno de ellos. - crearNuevoParking: este método permite dar de alta un nuevo parking en el centro de gestión verificando que no exista otro en la ubicación que se ha indicado. 3.1.1.3 Configuración del servidor Para acceder y utilizar la aplicación, se requiere establecer la dirección y el puerto en los cuales el servidor estará activo. En este proyecto, el servidor se ha configurado para escuchar en la dirección IP y el puerto específico: • Dirección IP del servidor: localhost (127.0.0.1). • Puerto del servidor: 8080 (indicado en el archivo application.properties). Con esta configuración, la aplicación se vuelve accesible a través de la dirección http://localhost:8080. 3.1.1.4 Dependencias Las dependencias en el servicio son elementos de vital importancia que permiten que el proyecto funcione correctamente. Estas dependencias han sido incluidas en el archivo POM (Project Object Model) del proyecto, las principales son las siguientes: • PostgreSQL: se ha incluido esta dependencia para facilitar la integración con la base de datos PostgreSQL, permitiendo así el acceso y la manipulación de datos de manera eficiente. • Spring Data JPA: esta herramienta simplifica el manejo de datos en aplicaciones Java utilizando el framework Spring. Proporciona una capa de abstracción sobre la base de datos, lo que facilita la escritura de consultas y la gestión de la persistencia de los objetos. Su objetivo es simplificar al desarrollador la persistencia de datos entre los distintos repositorios de información. • Swagger: se ha integrado Swagger para generar documentación interactiva de las API REST del proyecto. Esta herramienta simplifica la creación y el mantenimiento de la documentación, lo que mejora la comprensión y el uso de las APIs por parte de los desarrolladores y usuarios. • Spring Security: se ha incluido la dependencia de Spring Security para mejorar la seguridad de la aplicación, en concreto, enfocada a las contraseñas que se usan en la misma. A continuación, se muestra un fragmento del archivo POM en el que se pueden ver reflejadas estas dependencias: <!-- PostgreSQL --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> </dependency> <!-- Spring Data JPA --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <!-- Swagger --> <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger2</artifactId> Servicios REST 38 38 <version>3.0.0</version> </dependency> <!—Spring Security --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> 3.1.2 Base de datos del centro de gestión de parkings En este apartado se detallará la implementación de la base de datos del centro de gestión de parkings. Esta base de datos juega un papel fundamental en la conservación de la información del sistema como pueden ser los datos de los usuarios, los vehículos y los distintos parkings. Mediante un marco robusto, se consigue retener y gestionar información pertinente, lo que posibilita una gestión y análisis eficaz por parte del centro de gestión. La siguiente ilustración 3-28 muestra el diagrama entidad relación de la base de datos del centro de gestión de parkings: Ilustración 3-28. Diagrama entidad relación BBDD centro de gestión de parkings 3.1.2.1 Tabla usuarios La tabla “usuarios”, se utiliza para almacenar información sobre los usuarios dados de alta en el sistema del centro de gestión. Cada fila en la tabla representa los datos de un usuario y contiene detalles como el DNI, el nombre y los apellidos, la contraseña asociada a su cuenta y el email. El propósito de esta tabla es mantener un registro de los usuarios que hacen uso del centro de gestión. El código SQL es el mostrado a continuación: 39 DROP TABLE IF EXISTS usuarios; CREATE TABLE usuarios ( dni VARCHAR(20) NOT NULL, nombre VARCHAR(45) NULL, apellidos VARCHAR(255) NULL, contrasena VARCHAR(255) NULL, email VARCHAR(255) NULL, PRIMARY KEY(dni) ); Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO usuarios (dni, nombre, apellidos, contrasena, email) VALUES ('12345678A', 'Pepito', 'Apellido1 Apellido2', 'micontrasena123', '[email protected]'); 3.1.2.2 Tabla parking La tabla “parking”, se utiliza para almacenar información detallada sobre cada parking asociado a un centro de gestión. Cada fila en la tabla contiene detalles como el ID del estacionamiento, el tipo de estacionamiento, el nombre, la categoría, el tipo de tarifa de cobro, la moneda de la tarifa, el precio por minuto, la ubicación geográfica (latitud y longitud), el tipo de ubicación, el tipo de vehículo permitido, la dirección (incluyendo ciudad, país y código postal), el número total de plazas de estacionamiento, el número de plazas disponibles, el número de plazas ocupadas, la tasa de ocupación actual, la altura máxima permitida, el ancho máximo permitido y el tipo de estacionamiento. El propósito de esta tabla es mantener un registro detallado de los datos de cada estacionamiento asociado a un centro de gestión. Esto permite una gestión eficaz y proporciona información útil. El código SQL es el siguiente: DROP TABLE IF EXISTS parking; CREATE TABLE parking ( id INTEGER NOT NULL, type VARCHAR(255) NULL, name VARCHAR(255) NULL, category VARCHAR(255) NULL, chargeType VARCHAR(255) NULL, priceCurrency VARCHAR(255) NULL, priceRatePerMinute DECIMAL(5, 2) NULL, latitude FLOAT NULL, longitude FLOAT NULL, type_location VARCHAR(255) NULL, allowedVehicleType VARCHAR(255) NULL, address VARCHAR(255) NULL, city VARCHAR(255) NULL, country VARCHAR(255) NULL, postcode VARCHAR(20) NULL, totalSlotNumber INTEGER NULL, availableSlotNumber INTEGER NULL, occupiedSlotNumber INTEGER NULL, occupancy DECIMAL(5, 2) DEFAULT NULL, maximumAllowedHeight VARCHAR(20) NULL, maximumAllowedWidth VARCHAR(20) NULL, type_parking VARCHAR(255) NULL, PRIMARY KEY(id) ); Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO info_parking (id, type, name, category, chargeType, priceCurrency, Servicios REST 40 40 priceRatePerMinute, latitude, longitude, type_location, allowedVehicleType, address, city, country, postcode, totalSlotNumber, availableSlotNumber, occupiedSlotNumber, occupancy, maximumAllowedHeight, maximumAllowedWidth, type_parking) VALUES (3, 'Subterraneo', 'Parking Nervion', 'Public', 'Hourly', 'EUR', 0.14, 37.385345, -5.971967, 'Point', 'Car', 'Avd. Luis Montoto', 'Sevilla', 'Sevilla', '41009', 80, 0, 80, 1.00, '2 meters', '2.5 meters', 'OffStreetParking'); 3.1.2.3 Tabla vehiculo La tabla "vehiculo", se emplea para almacenar información sobre los vehículos registrados en el sistema del centro de gestión. Cada fila en la tabla representa los datos de un vehículo detallando la matrícula del vehículo, el DNI del usuario propietario, la marca y el modelo del vehículo, así como el número de plazas disponibles. El propósito de esta tabla es mantener un registro de los vehículos asociados a los usuarios que utilizan el centro de gestión. Además, la tabla incluye una clave externa que referencia la columna "usuarios_dni", la cual está vinculada a la clave primaria "dni" en la tabla "usuarios" explicada anteriormente. Esta relación establece una restricción referencial entre ambas tablas, asegurando que cada entrada en la tabla "vehiculo" esté asociada a un usuario existente en la tabla "usuarios". Esta restricción se configura con la opción "ON DELETE CASCADE", lo que significa que, si se elimina un usuario de la tabla "usuarios", también se eliminarán automáticamente todos los registros asociados en la tabla "vehiculo" para ese usuario. El código SQL es el mostrado a continuación: DROP TABLE IF EXISTS vehiculo; CREATE TABLE vehiculo ( matricula VARCHAR(20) NOT NULL, usuarios_dni VARCHAR(20) NOT NULL, marca VARCHAR(45) NULL, modelo VARCHAR(45) NULL, plazas INTEGER NULL, PRIMARY KEY(matricula), FOREIGN KEY(usuarios_dni) REFERENCES usuarios(dni) ON DELETE CASCADE ON UPDATE CASCADE ); Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO vehiculo (matricula, usuarios_dni, marca, modelo, plazas) VALUES ('1234ABC', '12345678A', 'Toyota', 'Yaris', 5); 3.1.2.4 Tabla reservas La tabla "reservas", se utiliza para almacenar información sobre las reservas realizadas en el sistema del centro de gestión. Cada fila en la tabla representa una reserva y contiene detalles como el ID de la reserva, la matrícula del vehículo asociado, el ID del parking donde se realiza la reserva, las fechas de inicio y fin de la reserva, el estado de confirmación y el precio de la reserva. Esta tabla, incluye una clave externa que referencia la columna "vehiculo_matricula", la cual está vinculada a la clave primaria "matricula" en la tabla "vehiculo" explicada anteriormente. Esta relación establece una restricción referencial entre ambas tablas, asegurando que cada entrada en la tabla "reservas" esté asociada a un vehículo existente en la tabla "vehiculo". Por otro lado, incluye una clave externa que referencia la columna "parking_id", la cual está vinculada a la clave primaria "id" en la tabla "parking" también, explicada anteriormente. El código SQL es el mostrado a continuación: DROP TABLE IF EXISTS reservas; 41 CREATE TABLE reservas ( reserva_id SERIAL, vehiculo_matricula VARCHAR(20) NOT NULL, parking_id INTEGER NOT NULL, fecha_inicio TIMESTAMP NULL, fecha_fin TIMESTAMP NULL, confirmada BOOL NULL, precio_reserva DECIMAL(5, 2) NULL, PRIMARY KEY(reserva_id, vehiculo_matricula, fecha_inicio), FOREIGN KEY (vehiculo_matricula) REFERENCES vehiculo(matricula) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (parking_id) REFERENCES parking(id) ON DELETE CASCADE ON UPDATE CASCADE ); Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO reservas (vehiculo_matricula, parking_id, fecha_inicio, fecha_fin, confirmada, precio_reserva) VALUES ('1234ABC', 3, '2024-04-17 10:00:00', '2024-04-17 22:00:00', true, 10.50); 3.1.3 Spring Security La seguridad de los datos y los recursos es esencial en el diseño de cualquier aplicación. Este apartado se centra en la implementación de la seguridad utilizando Spring Security en el servidor REST del centro de gestión de parkings. Se detallará el proceso utilizado para garantizar que las contraseñas de los usuarios estén almacenadas de manera segura en la base de datos mediante la encriptación. A través de esta medida de seguridad, se fortalece la integridad de la información y se promueve la confianza de los usuarios en la aplicación. La dependencia añadida está definida en el apartado 3.1.1.4 de esta memoria, para ello se crea la clase SecurityConfig que se va a explicar a continuación: • Se configura un bean llamado PasswordEncoder que utiliza un algoritmo para cifrar contraseñas de manera segura. • En la configuración de Spring Security el filtro permitirá el acceso a todas las URL sin necesidad de autenticación ya que en la aplicación móvil se requerirá previamente para acceder a todas las funcionalidades. @Configuration @EnableWebSecurity @ComponentScan(basePackages = {"parking", "parking.controller"}) public class SecurityConfig extends WebSecurityConfigurerAdapter { // Configuración de Spring Security @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/**").permitAll() // Permitir acceso sin autenticación a todas las URL .and() .csrf().disable(); // Deshabilitar CSRF para simplificar la configuración } Servicios REST 42 42 @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } } 3.2 Servicio REST de gestión de parking Esta sección al igual que la anterior, constituye otro de los elementos fundamentales de este proyecto. Se examinarán detalladamente las características esenciales del servicio desarrollado para la gestión de un parking concreto. Aquí se presentará un análisis exhaustivo tanto de la estructura integral de este servicio como de su interacción con la base de datos subyacente. Asimismo, se abordará la documentación de los endpoints de este servicio a través de la herramienta Swagger. Este apartado proporcionará una visión detallada de cómo funciona el servicio REST de gestión de parking, resaltando su importancia en el contexto general de la aplicación al permitir la supervisión y el control efectivo del mismo. 3.2.1 Servidor REST de gestión de parking Este subapartado se centra en explicar con detalle la estructura y configuración del servidor correspondiente con un parking concreto. Se incluyen las dependencias en este servicio, la definición de endpoints y las clases de las que está compuesto. Al igual que el apartado anterior, para el manejo de los datos del parking se ha empleado el modelo de datos Fiware [14], en concreto, se usará el enfocado a las ciudades inteligentes y los parkings. 3.2.1.1 Definición de endpoints En esta sección, se detallará un aspecto fundamental para el desarrollo del proyecto el cual consiste en detallar y explicar los endpoints de la API REST de gestión de parking implementada. Los endpoints se corresponden con los puntos de entrada a través de los cuales las aplicaciones se conectan con el servidor. Cada endpoint representa una acción particular que la API puede ejecutar, lo cual nos facilita el intercambio de datos y la comunicación de manera organizada y estructurada. Los diferentes endpoints del servicio REST de la gestión de un determinado parking pueden verse en la tabla 3-2 mostrada a continuación: PATH Método HTTP Descripción /api/parking GET Permite obtener una lista con los datos del parking almacenados en la base de datos. POST Permite modificar los datos del parking en la base de datos. /api/parking/entrada POST Permite registrar una nueva entrada de un vehículo al parking. /api/parking/salida POST Permite registrar una salida de un vehículo al parking. 43 /api/parking/pago POST Permite realizar el pago a los clientes tras indicar la salida del parking. Tabla 3–2. Endpoints del servicio de gestión de parking A continuación, se explicará cómo se utiliza Swagger para documentar el servicio de gestión de parking. La siguiente ilustración 3-29 nos muestra la vista desde la interfaz web de Swagger que nos permite visualizar los endpoints de un modo más gráfico. Ilustración 3-29. Endpoints en Swagger de gestión de parking Algunos ejemplos de peticiones al servidor de la gestión de parking son los siguientes: • Petición GET a http://localhost:8081/api/parking: esta petición se realiza para conocer los datos del parking a tiempo real y devuelve algunos datos como plazas ocupadas, precio por minuto, total de plazas, etc. En la ilustración 3-30 se puede ver un ejemplo de esta petición: Ilustración 3-30. Respuesta petición GET a /api/parking Servicios REST 50 50 - registrarPago (Ilustración 3-43): se registra el pago de un vehículo y se actualiza su estado en la base de datos. Ilustración 3-43. Método registrarPago de EstadoActualController.java servidor de gestión de parking • ParkingController.java (Ilustración 3-44): esta clase se corresponde con el controlador que se encarga de gestionar las solicitudes relacionadas con la información del parking. Contiene el método getInfoParking que devuelve detalles del parking como tipo de cargo, moneda de precio, tarifa por minuto, cantidad total de espacios, espacios disponibles, ocupados y su nivel de ocupación. Además, este controlador permite la actualización de la información de un estacionamiento específico mediante una solicitud POST en el mismo endpoint. El método updateParking recibe parámetros como el número total de espacios, espacios ocupados, tarifa por minuto y tipo de cargo, y actualiza los datos correspondientes en la base de datos a través del servicio ParkingService. Estos datos que se usan en esta clase siguen la estructura y el formato definidos en el modelo de datos Fiware [14] para los parkings. 51 Ilustración 3-44. ParkingController.java del servidor de gestión de parking 3.2.1.3 Configuración del servidor Para acceder y utilizar la aplicación, se requiere establecer la dirección y el puerto en los cuales el servidor estará activo. En este proyecto, el servidor se ha configurado para escuchar en la dirección IP y el puerto específico: • Dirección IP del servidor: localhost (127.0.0.1). • Puerto del servidor: 8081 (indicado en el archivo application.properties). Con esta configuración, la aplicación se vuelve accesible a través de la dirección http://localhost:8081. 3.2.1.4 Dependencias Las dependencias incluidas en este servicio son las mismas que las explicadas en el servicio anterior, excepto la de Spring Security ya que este servicio no requiere de autenticación. Estas dependencias han sido incluidas en el archivo POM (Project Object Model) del proyecto, las principales son las siguientes: • PostgreSQL: se ha incluido esta dependencia para facilitar la integración con la base de datos PostgreSQL, permitiendo así el acceso y la manipulación de datos de manera eficiente. • Spring Data JPA: esta herramienta simplifica el manejo de datos en aplicaciones Java utilizando el framework Spring. Proporciona una capa de abstracción sobre la base de datos, lo que facilita la escritura de consultas y la gestión de la persistencia de los objetos. Su objetivo es simplificar al Servicios REST 52 52 desarrollador la persistencia de datos entre los distintos repositorios de información. • Swagger: se ha integrado Swagger para generar documentación interactiva de las API REST del proyecto. Esta herramienta simplifica la creación y el mantenimiento de la documentación, lo que mejora la comprensión y el uso de las API por parte de los desarrolladores y usuarios. A continuación, se muestra un fragmento del archivo POM en el que se pueden ver reflejadas estas dependencias: <!-- PostgreSQL --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> </dependency> <!-- Spring Data JPA --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <!-- Swagger --> <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger2</artifactId> <version>3.0.0</version> </dependency> 3.2.2 Base de datos de gestión de parking En este apartado se detallará la implementación de la base de datos de un parking. Esta base de datos juega un papel fundamental en la conservación de la información del sistema como pueden ser los datos de los vehículos en su interior y los datos del mismo. Mediante un marco robusto, se consigue retener y gestionar información pertinente, lo que posibilita una gestión y análisis eficaz en cada parking. 3.2.2.1 Tabla estado_actual La tabla “estado_actual”, se utiliza para almacenar información sobre el estado actual del parking relacionado con los vehículos que contiene en el interior. Cada fila en la tabla representa el estado actual de un vehículo dentro del parking y contiene detalles como la matrícula del vehículo, la fecha y hora de entrada al estacionamiento, la fecha y hora de salida (si ya ha salido), la duración total de la estancia en minutos, el precio total a pagar, si la tarifa ha sido pagada o no, y el ID del pago asociado (si corresponde). El propósito de esta tabla es mantener un registro de los vehículos que están actualmente estacionados, así como de su tiempo de estancia y el estado de pago de la tarifa. El código SQL es el siguiente: DROP TABLE IF EXISTS estado_actual; CREATE TABLE estado_actual ( matricula VARCHAR(20) NOT NULL, fechayhora_entrada TIMESTAMP NOT NULL, fechayhora_salida TIMESTAMP DEFAULT NULL, total_minutos DECIMAL(5, 2) DEFAULT NULL, precio_total DECIMAL(5, 2) DEFAULT NULL, pagada BOOL NULL, id_pago VARCHAR(30) NULL, PRIMARY KEY(matricula, fechayhora_entrada) ); 53 Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO estado_actual (matricula, fechayhora_entrada, fechayhora_salida, total_minutos, precio_total, pagada, id_pago) VALUES ('1234ABC', '2024-04-17 10:36:28.807865', '2024-04-17 10:42:44.162696', 6.00, 0.24, TRUE, '9DB69837NJ7525606'); 3.2.2.2 Tabla info_parking La tabla “info_parking”, se utiliza para almacenar información detallada sobre el parking. Cada fila en la tabla contiene detalles como el ID del estacionamiento (proporcionado por el centro de gestión), el tipo de estacionamiento, el nombre, la categoría, el tipo de tarifa de cobro, la moneda de la tarifa, el precio por minuto, la ubicación geográfica (latitud y longitud), el tipo de ubicación, el tipo de vehículo permitido, la dirección (incluyendo ciudad, país y código postal), el número total de plazas de estacionamiento, el número de plazas disponibles, el número de plazas ocupadas, la tasa de ocupación actual, la altura máxima permitida, el ancho máximo permitido y el tipo de estacionamiento. El propósito de esta tabla es mantener un registro detallado de los datos del estacionamiento, incluyendo su ubicación, capacidad, tarifas y otros detalles relevantes. Esto permite una gestión eficaz y proporciona información útil. El código SQL es el siguiente: DROP TABLE IF EXISTS info_parking; CREATE TABLE info_parking ( id INTEGER NOT NULL, type VARCHAR(255) NULL, name VARCHAR(255) NULL, category VARCHAR(255) NULL, chargeType VARCHAR(255) NULL, priceCurrency VARCHAR(255) NULL, priceRatePerMinute DECIMAL(5, 2) NULL, latitude FLOAT NULL, longitude FLOAT NULL, type_location VARCHAR(255) NULL, allowedVehicleType VARCHAR(255) NULL, address VARCHAR(255) NULL, city VARCHAR(255) NULL, country VARCHAR(255) NULL, postcode VARCHAR(20) NULL, totalSlotNumber INTEGER NULL, availableSlotNumber INTEGER NULL, occupiedSlotNumber INTEGER NULL, occupancy DECIMAL(5, 2) DEFAULT NULL, maximumAllowedHeight VARCHAR(20) NULL, maximumAllowedWidth VARCHAR(20) NULL, type_parking VARCHAR(255) NULL, PRIMARY KEY(id) ); Un ejemplo de inserción en esta tabla puede ser el siguiente: INSERT INTO info_parking (id, type, name, category, chargeType, priceCurrency, priceRatePerMinute, latitude, longitude, type_location, allowedVehicleType, address, city, country, postcode, totalSlotNumber, availableSlotNumber, occupiedSlotNumber, occupancy, maximumAllowedHeight, maximumAllowedWidth, type_parking) VALUES (1, 'Subterraneo', 'Parking Plaza del Duque', 'Public', 'Hourly', 'EUR', 0.04, 37.39381408691406, -5.996476173400879, 'Point', 'Car', 'Plaza del Duque', 'Sevilla', 'Sevilla', '41003', 100, 1, 99, 0.99, '2 meters', '2.5 meters', 'OffStreetParking'); Servicios REST 54 54 55 4 APLICACIÓN ANDROID: ESTACIONA2 La paciencia es una virtud de la programación. Es necesario tomarse tiempo para comprender el problema antes de intentar resolverlo. – E.W. Dijkstra – n este capítulo, se describe la funcionalidad de la aplicación Android con detalle. La aplicación tiene como nombre “Estaciona2”. Los siguientes apartados de este capítulo detallan la estructura y funcionalidad de la aplicación y la vista para el usuario. En la siguiente ilustración 4-1, se muestran los casos de uso de la aplicación Android para el usuario: 4.1 Estructura y funcionalidad En este apartado, se explicarán con detalle las distintas clases de la aplicación, así como la funcionalidad de la misma. Además, se detallará la comunicación entre la aplicación Android, los servidores y la base de datos. Al ser clases muy extensas algunas de ellas, se va a detallar de cada clase sus métodos y utilidad de forma clara. E Ilustración 4-1. Casos de uso de la aplicación Android Aplicación Android: Estaciona2 56 56 Las clases que se van a explicar son las mostradas en la ilustración 4-2: • App La clase App es una extensión de la clase Application en Android que actúa como un contenedor de datos globales para la aplicación. Representa los siguientes atributos: - dni: DNI del usuario. - matriculaseleccionada: Matrícula seleccionada por el usuario. - precio: Precio asociado. - matriculas: Lista de matrículas. - nombreparkings: Lista de nombres de parkings. - idreservas: Lista de IDs de reservas. - nombreIdParkingMap: Mapa que relaciona nombres de parkings con sus identificadores correspondientes. La clase App proporciona métodos getter y setter para acceder y modificar estos atributos. Esta clase es fundamental para compartir datos en toda la aplicación ya que garantiza que sus datos permanezcan disponibles durante todo el ciclo de vida de la aplicación. • Constants La clase Constants es una clase que contiene constantes utilizadas en la aplicación, como la dirección IP y puerto del servidor. Se define una constante llamada API_URL que almacena la dirección IP y puerto del servidor. Esto nos facilita su mantenimiento y reutilización en toda la aplicación ya que en el caso de que cambie el valor de esta constante, solo es necesario actualizar el valor de la constante en esta clase, en lugar de buscar y modificar manualmente todas las referencias en el código. • HomeActivity La clase HomeActivity es una actividad de Android que se emplea para abrir las actividades desde el menú principal según el botón que sea pulsado por el usuario. Ilustración 4-2. Clases de la aplicación Android 57 • LoginActivity La clase LoginActivity es una actividad de Android que maneja el proceso de inicio de sesión en la aplicación. A continuación, se detallan los métodos y sus funciones en la clase: - onCreate(Bundle savedInstanceState): este método se invoca cuando se crea la actividad. Se inicializan y configuran los componentes de la interfaz de usuario que se corresponden con los campos de texto y los botones de inicio de sesión y registro. También se establecen los listeners para los eventos de click en los botones. - LoginTask: es una clase interna que extiende AsyncTask y se utiliza para realizar la autenticación del usuario en el servidor. - doInBackground(String... params): se ejecuta en segundo plano y realiza una solicitud HTTP POST al servidor con las credenciales que introduce el usuario. Devuelve un resultado que indica si el inicio de sesión es correcto o no. - onPostExecute(Integer resultado): se invoca posterior a finalización de la ejecución en segundo plano. Actualiza la interfaz de usuario en función del resultado del inicio de sesión. Si el inicio de sesión fue correcto, muestra un mensaje de "Login correcto" y redirige al usuario a la actividad HomeActivity. Si las credenciales son incorrectas, muestra un mensaje de "Usuario o contraseña incorrectos". - getPostDataString(Map<String, String> params): este método se utiliza para convertir los parámetros de la solicitud en una cadena de consulta que se envía al servidor. • RegisterActivity La clase RegisterActivity es una actividad de Android que se utiliza para el alta de nuevos usuarios en el sistema. Los métodos y sus funciones en esta clase son los mismos que los explicados en la clase anterior, LoginActivity, y por lo tanto no se entrará en detalle de nuevo. Se realiza una solicitud POST al servidor y la respuesta contiene el resultado del registro del nuevo usuario en el sistema. Muestra un mensaje de Toast con la respuesta del servidor. Por otro lado, se comprueba que los campos del formulario sean correctos y que las contraseñas introducidas coincidan. La siguiente ilustración 4-3 muestra el diagrama de secuencia entre la aplicación Android, el servidor del centro de gestión de parkings y su base de datos para el inicio de sesión y el registro en la aplicación: Aplicación Android: Estaciona2 58 58 • VehiculosActivity La clase VehiculosActivity es una actividad de Android que se utiliza para mostrar la lista de vehículos asociados a un usuario. A continuación, se detallan los métodos y sus funciones en la clase: - onCreate(Bundle savedInstanceState): se invoca cuando se crea la actividad y se configura la lista de vehículos y los botones para agregar vehículos y regresar al menú. Por otro lado, también obtiene el DNI del usuario actualmente autenticado y llama a la tarea GetVehiculosTask para obtener los vehículos asociados a ese usuario. - GetVehiculosTask: se emplea para realizar una solicitud GET al servidor y obtener la lista de vehículos asociados al usuario. Se ejecuta en segundo plano y devuelve una cadena JSON que consiste en la información de los vehículos. - mostrarListaVehiculos(String json): este método recibe una cadena JSON que contiene la lista de vehículos del usuario. Recorre esta cadena y muestra la lista de vehículos en la interfaz de usuario mediante un adaptador de lista. • NuevoVehiculoActivity La clase NuevoVehiculoActivity es una actividad de Android que se utiliza para permitir al usuario registrar un nuevo vehículo. Esta clase presenta los mismos métodos y funciones de RegisterActivity. Se realiza una solicitud POST al servidor y la respuesta contiene el resultado del registro del nuevo usuario en el sistema. Además, se muestra un mensaje de Toast con la respuesta del servidor. • MapsActivity La clase MapsActivity es una actividad de Android que muestra un mapa utilizando la API de Google Maps y coloca marcadores en ubicaciones de estacionamiento basadas en los datos obtenidos del servidor del centro de gestión de parkings. A continuación, se detallan los métodos y sus funciones: Ilustración 4-3. Diagrama de secuencia aplicación Android para inicio de sesión y registro 59 - onCreate(Bundle savedInstanceState): se invoca este método cuando se crea la actividad. Aquí se inicializan los componentes de la interfaz de usuario. - onMapReady(GoogleMap googleMap): se configura el mapa y se agrega un listener para los clicks en los marcadores. - GetParkingData: se utiliza para realizar una solicitud GET al servidor para obtener datos de los parkings. Se ejecuta en segundo plano y devuelve una cadena de texto que contiene la respuesta del servidor. - showParkingLocations(String json): muestra los marcadores de ubicaciones de estacionamiento en el mapa utilizando los datos obtenidos del servidor. - getMarkerColor(double occupancy): determina el color del marcador según el nivel de ocupación del estacionamiento. - ParkingInfoDialog(String title): muestra un cuadro de diálogo con información detallada sobre un estacionamiento cuando se hace click en su marcador en el mapa. La siguiente ilustración 4-4 muestra el diagrama de secuencia entre la aplicación Android, el servidor del centro de gestión de parkings y su base de datos para obtener la lista de los parkings que se muestran en el mapa y para consultar o dar de alta nuevos vehículos en el sistema: Ilustración 4-4. Diagrama de secuencia aplicación Android para consultar parkings y consultar y dar de alta nuevos vehículos Aplicación Android: Estaciona2 66 66 4.2.4 Pantalla de listar tus vehículos En la ilustración 4-10, se muestra la pantalla en la que se listan los vehículos que tiene asociados el DNI con el que se ha iniciado sesión en la aplicación: Esta pantalla presenta en la parte superior un título con el texto “Tus vehículos” y a continuación una lista con los vehículos (ListView) que tiene el usuario dados de alta en el sistema. En la parte inferior de la pantalla se Ilustración 4-9. Pantalla principal Ilustración 4-10. Pantalla lista de vehículos 67 muestran dos botones, el primero de ellos es para volver a la pantalla principal de la aplicación y el segundo de ellos para dar de alta un nuevo vehículo en el sistema. 4.2.4.1 Pantalla de registro de nuevo vehículo Esta pantalla se corresponde con el registro de un nuevo vehículo en el sistema y es consecuencia de haber pulsado el botón de agregar un nuevo vehículo explicado en el apartado anterior. En la ilustración 4-11 se muestra la vista: En el registro de un nuevo vehículo en el sistema, podemos observar en la parte superior un título con el texto de “Nuevo vehículo” y a continuación un logo de un vehículo. En la parte central de la pantalla se presenta un formulario con los campos (EditText): Matrícula, Marca, Modelo y Número de plazas. Estos campos del formulario son obligatorios de rellenar por lo que si se deja alguno incompleto salta una alerta en la aplicación que indica al usuario que debe rellenarlos. Finalmente, en la parte inferior de la pantalla aparece un botón para realizar el registro del nuevo vehículo y un texto “Volver a mis vehículos” que permite volver a la pantalla anterior. Cuando un usuario da de alta un nuevo vehículo en el sistema, la aplicación ya tiene guardado previamente el DNI con el que se ha iniciado sesión, esto conlleva que el usuario no tenga que volver a introducirlo tal y como se ha explicado en apartados anteriores. Se contempla el caso de que un usuario introduzca una matrícula que ya tiene dada de alta en el sistema que, en este caso, la aplicación muestra un mensaje de alerta de que esa matricula ya existe en el sistema. 4.2.5 Pantalla de ubicación de parkings En la ilustración 4-12, se muestra la pantalla en la que se muestra la ubicación de los parkings en el mapa: Ilustración 4-11. Pantalla registro de nuevo vehículo Aplicación Android: Estaciona2 68 68 En esta pantalla se puede observar un botón en la parte superior que nos permite volver a la pantalla principal de la aplicación. En el mapa mostrado aparecen las ubicaciones de los parkings y un color asociado que se corresponde con la ocupación de este, los colores son: verde si la ocupación es menor al 75%, naranja si está entre un 75% y un 90% y rojo si es mayor al 90%. En la esquina inferior derecha podemos solicitar que nos indique el camino para llegar al parking marcado en esta pantalla. Por otro lado, cuando queremos saber más información sobre un parking en concreto hay que dar click encima del mismo y nos muestra los datos: dirección, plazas libres, precio por minuto y la ocupación del mismo. Para cerrar el mensaje debemos pulsar en “OK”. Esto se puede ver en la siguiente ilustración 4-13: 4.2.6 Pantalla de lista de reservas La pantalla de reservas presenta la vista mostrada en la ilustración 4-14: Ilustración 4-12. Pantalla ubicación de parkings Ilustración 4-13. Alerta con detalle del parking 69 Esta pantalla, contiene en la parte superior un desplegable (Spinner) para seleccionar la matrícula asociada al DNI con el que se ha iniciado sesión de la que se quiere obtener la lista de reservas que tiene asociadas. Si esa matrícula tiene reservas en el sistema se muestran ordenadas de fecha más actual a más futura, en el caso de que no existan reservas se muestra un mensaje “No hay reservas para esta matrícula”. Cada elemento de la lista se compone de lo siguiente: fecha y hora del inicio de la reserva, fecha y hora del fin de la reserva, nombre del parking en la que se ha realizado, precio de la reserva y si está confirmada o no. Para crear la lista se usa el elemento ListView, en la que cada componente de la misma tiene un TextView con los datos correspondientes y un botón (Button). El botón de cada elemento de la lista contiene el icono de la papelera, cuando el usuario pulsa este botón se muestra un mensaje para confirmar la eliminación de la misma. En la parte inferior de la pantalla se muestran dos botones: botón volver a la pantalla principal de la aplicación y botón para crear una nueva reserva que se detalla en el punto siguiente. 4.2.6.1 Pantalla de realizar una nueva reserva Esta pantalla se corresponde con el registro de una nueva reserva en el sistema y es consecuencia de haber pulsado el botón de nueva reserva indicado en el apartado anterior. En la ilustración 4-15 se muestra la vista de esta pantalla: Ilustración 4-14. Pantalla lista de reservas Aplicación Android: Estaciona2 70 70 En el registro de una nueva reserva en el sistema, podemos observar en la parte superior un título con el texto de “Nueva reserva” y a continuación un logo de un vehículo. En la parte central de la pantalla se presenta un formulario con los campos: matrícula (Spinner con las matrículas asociadas al DNI del usuario), nombre del parking (Spinner con los parkings), fecha de inicio y fecha de fin de la reserva. Estos campos del formulario son obligatorios de rellenar por lo que si se deja alguno incompleto salta una alerta en la aplicación que indica al usuario que debe rellenarlos. Finalmente, en la parte inferior de la pantalla aparece un botón para realizar la reserva y un texto “Volver a mis reservas” que permite volver a la pantalla anterior. Los campos matrícula y nombre del parking son campos desplegables en los que el usuario puede elegir entre las matrículas que están asociadas a su DNI en el sistema y entre los parkings que hay existentes. Por otro lado, la fecha de inicio no puede ser inferior a la actual y además la fecha de fin de la reserva debe de ser igual o posterior a la de inicio, en el caso de que esto no se cumpla, la aplicación muestra una alerta al usuario. 4.2.7 Pantalla de entrada al parking La pantalla de entrada al parking se compone de un escáner de QR y un campo desplegable (Spinner con las matrículas asociadas al DNI del usuario) con un mensaje que le indica al usuario que debe seleccionar la matrícula con la que va a entrar al parking antes de escanear el QR. Una vez seleccionada y escaneado el QR, se muestra un mensaje de confirmación de la entrada en la que el usuario puede cancelar o aceptar. Finalmente, en la parte inferior de la pantalla se muestra un botón para volver a la pantalla principal de la aplicación. La ilustración 4-16 muestra la pantalla de entrada al parking y el mensaje de confirmación: Ilustración 4-15. Pantalla nueva reserva 71 4.2.8 Pantalla de salida del parking La pantalla de salida del parking es similar a la de entrada al parking explicada detalladamente en el apartado anterior por lo que no volveré a explicarla con detalle. Esta pantalla incluye un botón con el texto “Pagar” que se activa cuando se realiza una salida correctamente. La vista es la mostrada en la ilustración 4-17: Ilustración 4-16. Pantalla entrada al parking Ilustración 4-17. Pantalla salida del parking Aplicación Android: Estaciona2 72 72 4.2.8.1 Pantalla de pagos PayPal Esta pantalla se corresponde con la pantalla de pagos de PayPal y es consecuencia de haber pulsado el botón de pago indicado en el apartado anterior. En primer lugar, aparece una pantalla en la que te indica el precio de la estancia en el parking y un botón con el texto de “Pagar con PayPal” que te redirecciona a la página de pagos de PayPal. Posteriormente, en la página de pagos indicas tu cuenta de PayPal y realizas el pago pulsando en el botón correspondiente, esta pantalla (Custom Tabs), se corresponde con el navegador directamente integrado en la aplicación sin necesidad de ir a la aplicación del navegador. Finalmente, nos redirige a la vista de la confirmación del pago en la que aparece el importe a pagar, el identificador de la compra y un botón con el texto de “Confirmar Pago”. En la ilustración 4-18 se muestra la secuencia que sigue esta pantalla: 4.2.9 Salir de la aplicación Para salir de la aplicación, se debe pulsar el botón “Cerrar Sesión” mostrado en la pantalla principal de la aplicación tal y como se muestra en la ilustración 4-9. Ilustración 4-18. Pantalla de pago PayPal 73 5 APLICACIÓN WEB GESTOR DE PARKING La computadora fue diseñada para resolver problemas que antes no existían. – Bill Gates – n este capítulo, se describe la funcionalidad de la aplicación web para el gestor de parking con detalle. El gestor del parking se corresponde con el operario que administra el uso del mismo. Este operario realiza las funciones como el control de acceso, monitoreo de plazas y gestión de reservas en el estacionamiento. Los siguientes apartados de este capítulo detallan la estructura y funcionalidad de la aplicación y la vista para el usuario que se corresponde con el gestor del parking. En la siguiente ilustración 5-1, se muestran los casos de uso de la aplicación web para el usuario: 5.1 Estructura y funcionalidad En este apartado, se explicarán con detalle la estructura y la funcionalidad de la aplicación web. Además, se detallará la comunicación entre la aplicación web, los servidores y la base de datos. La estructura de esta aplicación web se muestra en la ilustración 5-2: E Ilustración 5-1. Casos de uso de la aplicación web Aplicación web gestor de parking 74 74 Como podemos observar en la ilustración anterior, cada archivo HTML se corresponde con una funcionalidad distinta de la aplicación web y los archivos dependientes de estos están separados por hojas de estilos, scripts e imágenes. Las funcionalidades van a ser descritas con más detalle a continuación: • index.html: se corresponde con el archivo principal HTML que se carga automáticamente cuando el usuario inicia la aplicación. En función de la actividad que desee realizar el usuario, en la aplicación se redireccionará a reservas.html, crear_parking.html o estado_parking.html. El script “index.js” es el encargado de realizar esta función de redirección. • reservas.html: este archivo se corresponde con el apartado de la gestión de las reservas que han realizado los usuarios en un parking concreto. Contiene un script llamado “reservas.js” que se encarga de realizar solicitudes al servidor para obtener los datos de las reservas. Además, se pueden gestionar las confirmaciones o cancelaciones de las reservas por parte del operador del parking. Este script utiliza la función fetch() que se encarga de realizar una solicitud GET al servidor y obtener los datos correspondientes a las reservas en formato JSON. Una vez obtenidas las reservas, las inserta dinámicamente en la tabla HTML ordenadas de fecha más reciente a fecha más posterior. Por otro lado, se definen dos funciones adicionales llamadas confirmarReserva() y noConfirmarReserva() que al ser pulsados los botones asociados a las mismas, se realizan solicitudes POST al servidor y confirma o cancela la confirmación de la reserva. Finalmente, estas funciones actualizan la interfaz de usuario y recargan la página después de completar las operaciones. • crear_parking.html: este archivo corresponde al apartado de creación de un nuevo parking en el sistema. Presenta un formulario que permite ingresar los detalles del nuevo parking. Además, se incluye un script llamado “crear_parking.js” que se encarga de validar el formulario antes de enviarlo y realizar la solicitud POST al servidor para crear el nuevo parking. El formulario contiene campos para ingresar información relevante, como tipo, nombre, categoría, tarifa por minuto, ubicación geográfica, cantidad de plazas disponibles, entre otros. También se incluye un botón "Crear Parking" que activa la función registrarNuevoParking() al ser pulsado. El script "crear_parking.js" contiene las siguientes dos funciones: - validarFormulario(): esta función valida que todos los campos del formulario estén Ilustración 5-2. Estructura de la aplicación web 75 completos antes de enviar la solicitud al servidor. Si algún campo está vacío, se muestra una alerta indicando al usuario que complete todos los campos necesarios. - registrarNuevoParking(): esta función se encarga de enviar una solicitud POST al servidor con los datos del nuevo parking ingresados en el formulario. Antes de enviar la solicitud, se valida el formulario utilizando la función validarFormulario(). Si el formulario está validado correctamente, se crea un objeto con los valores de los campos del formulario y se realiza la solicitud POST al servidor. Una vez completada la operación, se muestra una alerta indicando al usuario que el nuevo parking ha sido creado exitosamente o se maneja el error en caso de que ocurra algún problema durante la creación del parking. La siguiente ilustración 5-3 muestra el diagrama de secuencia entre la aplicación web para el gestor del parking, el servidor del centro de gestión de parkings y su base de datos para dar de alta un nuevo parking, consultar las reservas realizadas en el parking y confirmar o cancelar la confirmación de reservas: • estado_parking.html: este archivo representa el apartado que muestra y permite modificar el estado Ilustración 5-3. Diagrama de secuencia comunicación aplicación web, servidor centro de gestión de parkings y base de datos para dar de alta un nuevo parking, consultar y confirmar o cancelar reservas Aplicación web gestor de parking 82 82 83 6 CONCLUSIÓN Y LÍNEAS FUTURAS Como conclusión de esta memoria, resulta fundamental resaltar los hitos y progresos alcanzados por este proyecto en el desarrollo de una aplicación para Android, una aplicación web para el gestor de parking y la implementación de servicios REST, para el centro de gestión de parkings y para la gestión de parking. Esta sección de conclusiones recapitula las conclusiones técnicas y traza las posibles direcciones futuras que podrían elevar este proyecto a niveles superiores de innovación y rendimiento. 6.1 Conclusiones técnicas Para este proyecto se ha creado una aplicación Android con el nombre “Estaciona2” que permite a los usuarios interaccionar con el centro de gestión de parkings para dar de alta nuevos vehículos, realizar reservas y ver información relevante de los parkings de la red a través de la API de Google Maps. Por otro lado, permite la entrada y la salida del parking mediante el escaneo de QR, así como el pago de la tarifa correspondiente a la estancia en el mismo mediante la API de PayPal. Además, se han implementado dos servicios REST, uno de ellos correspondiente con el centro de gestión de parkings y el otro con la gestión de parking. Finalmente, para el gestor de parking se ha creado una aplicación web la cual permite la gestión del mismo. La integración de estos sistemas permite al usuario tener una mejor experiencia para interactuar con los estacionamientos. La integración con los sistemas de pago y los mapas permiten mejorar esta experiencia y hacerla más cómoda. Finalmente, este proyecto ha significado un relevante aprendizaje en el desarrollo de servidores REST, bases de datos y aplicaciones web y móviles Android. He podido aplicar los conocimientos teóricos y prácticos adquiridos en esta etapa educativa y además adquirir nuevos conocimientos en los sistemas de estacionamiento aplicados a ciudades inteligentes. 6.2 Conclusiones personales Este proyecto define una etapa en mi recorrido académico que muestra la dedicación y constancia durante este tiempo para llegar a conseguir nuevos logros. Puedo concluir que lo propuesto al inicio de este proyecto se ha cumplido con éxito y puede verse reflejado en el mismo. Por otro lado, me ha ayudado a mejorar y reforzar mis habilidades en el ámbito tecnológico. Además, supone una satisfacción personal la evolución que he tenido durante todo este periodo y el logro de haber superado los nuevos desafíos que ha supuesto. Este proyecto me ha permitido conocer nuevas tecnologías y reforzar mis conocimientos en otras en las que ya había tenido oportunidad de conocer previamente. A pesar de mi falta de experiencia en este tipo de proyectos, mis conocimientos adquiridos durante mi etapa académica en la Ingeniería y la ayuda de mi tutora han supuesto una ayuda fundamental para alcanzar los objetivos propuestos. Este proyecto ha mejorado mis habilidades para elaborar esta memoria técnica que abarca la estructura fundamental y análisis de las aplicaciones y servicios implementados. Además, ha enriquecido mi capacidad para tener una importante planificación y organización de todos los pasos del proyecto de forma ordenada. Me ha permitido conocer nuevos ámbitos tecnológicos aplicables a la mejora de la vida del ser humano. Además, he podido mejorar la confianza para afrontar nuevos proyectos similares a este y continuar en un futuro teniendo nuevas experiencias. 6.3 Líneas futuras En este apartado se definirán las posibles direcciones en las que este proyecto podría evolucionar y tener más funcionalidades. Se definirán nuevos aspectos y nuevas tecnologías en distintas áreas en las que el proyecto puede potenciar y enriquecer su alcance y funcionalidad. Conclusión y líneas futuras 84 84 6.3.1 Diseño En el apartado del diseño y sus posibles mejoras podemos continuar con las siguientes: • Creación e implementación de una barra lateral de navegación para que la experiencia del usuario sea más cómoda y gratificante. Por otro lado, aprovechar para mostrar como pantalla principal el mapa con los estacionamientos y usar la barra lateral para acceder a las otras funcionalidades. • Redefinir nuevas formas de figuras y alertas más atractivas visualmente para el usuario. 6.3.2 Funcionalidades Las funcionalidades futuras que puede implementar son las siguientes: • Añadir notificaciones mediante email y en la misma aplicación móvil para las reservas que realice el usuario. Esto permite que el usuario tenga presente en todo momento el estado de sus reservas mediante alertas. • Permitir el pago de tarifas mediante otras plataformas de pago como por ejemplo Bizum, transferencia bancaria, etc. • Añadir al servidor REST del centro de gestión de parkings una función para poder calcular las horas de máxima afluencia en los parkings y la ocupación promedio. • Añadir al servidor REST de gestión del parking la generación de informes para permitir al gestor del parking acceder a información detallada por periodos. Por otro lado, añadir un sistema de sugerencias o incidencias que puedan tener los usuarios que hacen uso del mismo. • Expandir el sistema para los estacionamientos en las vías urbanas y usar sensores para permitir conocer el estado de los mismos. • Adaptar la aplicación para el sistema operativo iOS. • Integrar nuevas conexiones con otros sistemas como el centro de gestión de tráfico definido por la Arquitectura de Referencia para el Transporte Cooperativo e Inteligente (ARC-IT) [1]. 6.3.3 Seguridad En el aspecto de la seguridad, se podrían mejorar los siguientes puntos: • Implementación de requerimiento de autenticación usando SpringSecurity para acceso a otras rutas que no sean /api/login o /api/registro. • Implementar el protocolo seguro HTTPS en las consultas al servidor. Esto implica obtener un certificado SSL/TLS y configurar el servidor y la aplicación para soportar esta funcionalidad. • Implementar mecanismos para limitar los intentos de inicio de sesión fallidos, como el bloqueo de cuentas temporalmente después de varios intentos fallidos. 6.3.4 Despliegue e infraestructura En el despliegue y la infraestructura podemos concluir con los siguientes aspectos que se podrían implementar: • Desplegar los servidores en plataformas como Azure o Google Cloud Platform. Estas plataformas ofrecen servidores virtuales y alojamiento para bases de datos relacionales. • Desplegar la aplicación móvil en la tienda de aplicaciones de Android, Play Store. Esto permitirá a cualquier usuario realizar su descarga desde la misma. 85 • Desplegar la aplicación web en plataformas como Netlify o Heroku que nos ofrecen herramientas sencillas para el despliegue de aplicaciones web. • Implementar herramientas para el monitoreo de logs de las aplicaciones y para obtener información sobre el uso de las mismas y las incidencias que pueda tener. Conclusión y líneas futuras 86 86 87 ANEXO A: INSTALACIÓN Y DESPLIEGUE DE LOS SERVICIOS REST IMPLEMENTADOS El código de los servicios REST implementados y las aplicaciones Android y web está disponible en el siguiente repositorio de GitHub: https://github.com/jmgalin/TFG_Parking_ETSI Desde este repositorio, descargue el archivo “serv_REST_TFG.zip” correspondiente a los servicios REST del proyecto y descomprímalo en la ubicación deseada del sistema. 1. Instalación de los servidores REST Antes de instalar los servidores REST, verifique que tenga Maven instalado en su sistema. Puede obtenerlo ejecutando el siguiente comando de descarga. sudo apt install maven Podemos comprobar que se ha instalado correctamente con el siguiente comando: maven -version Una vez instalado Maven, abra un terminal y navegue hasta el directorio donde descomprimió el proyecto utilizando el comando: cd ruta/directorio 2. Inicio de las bases de datos En el directorio del proyecto se encuentra un script que permite inicializar las bases de datos requeridas para el funcionamiento del proyecto. El script “bbddsetup.sh” crea las bases de datos correspondientes y a cada una de ellas les inserta las tablas y datos de ejemplo en ellas. Previamente a la ejecución del mismo debemos de darle los permisos adecuados de ejecución con el siguiente comando: chmod +x bbddsetup.sh Para la ejecución del mismo una vez concedidos los permisos hay que ejecutar el siguiente comando: ./bbddsetup.sh 3. Despliegue de los servidores REST Una vez iniciadas las bases de datos, podemos desplegar los servidores. Para ello hay que hacerlo desde el directorio del proyecto y cada uno en un terminal distinto. En primer lugar, debemos de desplegar el servidor asociado a un parking por lo que tenemos que ubicarnos en su directorio correspondiente: cd parking1 Una vez en esta ubicación podemos iniciar Spring con el siguiente comando: mvn spring-boot:run En segundo lugar, en otro terminal debemos de desplegar el servidor asociado al centro de gestión de parkings por lo que tenemos que ubicarnos en su directorio correspondiente: Anexo A: Instalación y Despliegue de los Servicios REST implementados 88 88 cd centro_gestion Una vez en esta ubicación podemos iniciar Spring con el siguiente comando: mvn spring-boot:run 89 ANEXO B: CONFIGURACIÓN DE LA API DE PAYPAL Y LA API DE GOOGLE MAPS En diversos apartados anteriores de esta memoria se ha detallado cómo se usa la API de PayPal para el pago de tarifas a través del dispositivo móvil y el uso de la API de Google Maps para la visualización de información de los distintos parkings de la red. A continuación, se va a detallar la configuración de ambas APIs. 1. Configuración de la API de PayPal En este apartado, se explicará la configuración [15] que se debe realizar en la API de PayPal para su uso en las aplicaciones. En primer lugar, se debe crear una cuenta personal en la plataforma PayPal Developer para poder gestionar tus aplicaciones. Posteriormente, se debe crear un usuario ficticio para poder probar la aplicación. Para ello, en el apartado Sandbox Accounts se debe pulsar sobre el botón “Create account” y crear una cuenta de tipo Business, ilustración B-1. Además, se puede crear una cuenta de tipo Personal para hacer uso de la aplicación, en esta cuenta se puede indicar un saldo ficticio para en futuras ocasiones realizar pagos en la aplicación y probar su uso. Posteriormente, en el apartado Apps & Credentials se debe pulsar sobre el botón “Create App” para crear un nuevo proyecto rellenando los campos correspondientes y asociando esta aplicación con la cuenta creada anteriormente. Una vez configurada la aplicación, se generan unas credenciales de cliente que contienen un identificador de cliente y una clave secreta que se deben guardar para su posterior uso, ilustración B-2. Ilustración B-1. Configurar usuario en PayPal Developer Anexo B: Configuración de la API de PayPal y la API de Google Maps 90 90 Una vez realizados los pasos detallados anteriormente, para que podamos hacer uso de la API en nuestro proyecto, debemos de obtener el token de acceso. Para ello, se debe realizar una solicitud POST a la URL https://api-m.sandbox.paypal.com/v1/oauth2/token con las credenciales de cliente generadas anteriormente con el formado “CLIENT_ID:CLIENT_SECRET. Se debe establecer el encabezado Content-Type a application/x-www-form-urlencoded y finalmente, definir el cuerpo de la solicitud para indicar que se está solicitando un token de acceso basado en las credenciales del cliente (grant_type=client_credentials). Una vez obtenido el token de acceso se puede usar en la aplicación para realizar futuras solicitudes a la API de PayPal, permitiendo así a la aplicación realizar operaciones como pagos, reembolsos y consultas de transacciones de manera segura y autorizada. 2. Configuración de la API de Google Maps En este apartado, se detallará la configuración [16] que se debe realizar para usar esta API de Google Maps. En primer lugar, se debe crear un proyecto en Android Studio que use como lenguaje Java. Se debe seleccionar una versión superior a la mínima requerida por el SDK de Maps para Android, en este caso, superior a la versión 18.0.x. Actualmente se corresponde con la API nivel 19 (Android 4.4). Una vez creado el proyecto, se debe tener presente el archivo AndroidManifest.xml ya que es el archivo de configuración de nuestra aplicación móvil. El paso siguiente consiste en crear una cuenta en la plataforma Google Cloud y crear un proyecto. El uso de esta plataforma es gratuito siempre y cuando no se exceda un límite. Como paso posterior, debemos habilitar en la plataforma la API de Google Maps para Android y debemos tener un resultado como el mostrado en la ilustración B-3: Ilustración B-2. Configurar aplicación en PayPal Developer Ilustración B-3. Habilitar API Google Maps para Android 91 Una vez habilitada la API, debemos dirigirnos a la pestaña de “Credenciales” y pulsar sobre el botón de “Crear credenciales” para crear una clave única que nos permitirá hacer uso de esta API. Finalmente, una vez creada tenemos que guardar la clave para su posterior uso. La vista de este paso se muestra en la siguiente ilustración B-4: Como paso siguiente y una vez obtenida la clave, abrir el archivo build.gradle a nivel del proyecto y agregar el siguiente código mostrado en la ilustración B-5. A continuación, abrir el archivo build.gradle a nivel del módulo y agregar el código mostrado en la ilustración B-6 dentro del elemento plugins. Una vez añadidos estos códigos anteriores, se debe guardar el proyecto y sincronizar con Gradle. Finalmente, en el archivo AndroidManifest.xml debemos agregar dentro de application la línea siguiente mostrada en la ilustración B-7 en la que debemos sustituir MAPS_API_KEY por la clave que hemos generado previamente. Ilustración B-4. Creación de clave para API Google Maps Ilustración B-5. Código build.gradle a nivel de proyecto para API Google Maps Ilustración B-6. Código build.gradle a nivel del módulo para API Google Maps Ilustración B-7. Código AndroidManifest.xml para API Google Maps