Diseño de aplicación web para la gestión de los resultados de ensayos de laboratorio

DISEÑO DE APLICACIÓN WEB PARA LA GESTIÓN DE LOS RESULTADOS DE ENSAYOS DE LABORATORIO DESIGN OF A WEB APPLICATION FOR THE MANAGEMENT OF LABORATORY TEST RESULTS. TRABAJO FIN DE GRADO CURSO 2023-2024 AUTOR Sebastián Pinto Justiniano DIRECTOR YOLANDA GARCÍA RUIZ GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID RESUMEN El presente trabajo consiste en la especificación, diseño e implementación de una base de datos, una API, y una aplicación web realizadas para el Centro de Estudios y Experimentación de Obras Públicas (CEDEX), con el fin de estructurar, persistir, interactuar y visualizar datos relacionados con experimentos de laboratorio sobre aceros. Se han diseñado dos bases de datos, una base de datos siguiendo un esquema relacional para la gestión de los metadatos a partir de los cuales se diseñan las distintas pantallas de la aplicación web. La segunda base de datos sigue un esquema NoSql, en particular se trata de una base de datos orientada a documentos que garantizará la persistencia de los resultados obtenidos por los distintos ensayos que se realizan en el laboratorio y a partir de los cuales se generarán informes y estadísticas. Para poder interactuar con los datos disponibles, se utiliza una API. Por último, se creó una página web para facilitar el uso de dicha API, permitiendo además generar tablas y diagramas para poder visualizar los datos seleccionados. Tanto la API como la aplicación web tienen un sistema de autenticación para proteger los datos existentes. Palabras clave expedientes, ensayos, productos, científico, SQL, mongoDB, web, laravel, javascript. ABSTRACT The present work involves the specification, design, and implementation of a database, an API, and a web application developed for the Centro de Estudios y Experimentación de Obras Públicas (CEDEX), with the aim of structuring, persisting, interacting with, and visualizing data related to laboratory experiments on steel. Two databases have been designed: a relational database schema for managing the metadata from which the various screens of the web application are designed, and a NoSQL database, specifically a document-oriented database that ensures the persistence of results obtained from various laboratory tests, which will be used to generate reports and statistics. To interact with the available data, an API is used. Finally, a web page was created to facilitate the use of this API, also allowing the generation of tables and diagrams to visualize the selected data. Both the API and the web application have an authentication system to protect the existing data. Keywords records, tests, products, scientific, SQL, mongoDB, web, laravel, javascript. ÍNDICE DE CONTENIDOS Capítulo 1 - Introducción........................................................................................................... 1 1.1 Motivación..........................................................................................................................1 1.2 Objetivos............................................................................................................................2 1.2.1 Unificación de la estructura de los datos.................................................................. 2 1.2.2 Obtención de estadísticas relevantes.......................................................................2 1.3 Plan de trabajo...................................................................................................................3 1.4 Estructura de la memoria...................................................................................................6 Capítulo 2 - Estado de la cuestión............................................................................................8 Capítulo 3 - Tecnologías empleadas.......................................................................................10 3.1 Herramientas Frontend....................................................................................................10 3.1.1 HTML 5................................................................................................................... 10 3.1.2 CSS y Tailwind CSS................................................................................................10 3.1.3 JavaScript y TypeScript...........................................................................................11 3.1.4 DaisyUI 4.................................................................................................................11 3.1.5 AG Grid................................................................................................................... 11 3.1.6 Chart.js......................................................................................................................... 12 3.1.7 Svelte 4 y SvelteKit 1..............................................................................................12 3.2 Herramientas Backend.................................................................................................... 13 3.2.1 PHP y Laravel 10....................................................................................................13 3.2.2 PostgreSQL............................................................................................................ 13 3.2.3 MongoDB................................................................................................................14 3.2.4 Docker.....................................................................................................................14 3.2.6 AWS RDS............................................................................................................... 15 3.2.7 MongoDB Atlas.......................................................................................................15 3.2.8 Render.................................................................................................................... 15 3.3 Otras herramientas..........................................................................................................16 3.3.1 Visual Studio Code................................................................................................. 16 3.3.2 GitHub.....................................................................................................................16 3.3.3 DBeaver..................................................................................................................16 3.3.4 MongoDB Compass................................................................................................17 3.3.5 Postman..................................................................................................................17 Capítulo 4 - Modelo de datos...................................................................................................17 4.1 Modelo Entidad-Relación.................................................................................................17 4.2 Implementación de la base de datos...............................................................................19 4.2.1 Base de datos relacional.........................................................................................19 4.2.1.1 Productos.............................................................................................................21 4.2.1.2 Nominales............................................................................................................24 4.2.1.3 Ensayos............................................................................................................... 26 4.2.1.4 Atributos...............................................................................................................28 4.2.1.5 Usuarios...............................................................................................................30 4.2.1.6 Tokens Personales...............................................................................................32 4.2.2 Base de datos no relacional....................................................................................33 Capítulo 5 - Casos de uso........................................................................................................34 4.1 Actores.............................................................................................................................34 4.2 Diagrama de casos de uso..............................................................................................34 4.3 Especificación de requisitos............................................................................................ 35 4.3.1 Usuarios..................................................................................................................36 4.3.2 Expedientes............................................................................................................ 38 4.3.3 Productos................................................................................................................46 4.3.3 Ensayos.................................................................................................................. 56 4.3.5 Estadísticas.............................................................................................................67 Capítulo 6 - Arquitectura..........................................................................................................68 5.1 Arquitectura del sistema.................................................................................................. 68 5.2 Patrones Arquitectónicos.................................................................................................70 5.2.1 REST...................................................................................................................... 70 5.2.2 Modelo-Vista-Controlador.......................................................................................71 5.3 Patrones de diseño..........................................................................................................73 5.3.1 Dependency injection..............................................................................................73 5.3.2 Chain of Responsibility........................................................................................... 75 5.3.3 Observer................................................................................................................. 76 5.4 Vistas............................................................................................................................... 77 5.4.2 Template View.........................................................................................................77 5.4.2 Composite...............................................................................................................78 Capítulo 7 - Diseño................................................................................................................... 80 7.1 Autenticación................................................................................................................... 80 7.2 Expedientes.....................................................................................................................80 7.3 Estadísticas..................................................................................................................... 80 7.4 Productos.........................................................................................................................80 7.5 Ensayos...........................................................................................................................80 Capítulo 8 - Conclusiones y trabajo futuro............................................................................ 80 9.1 Conclusiones................................................................................................................... 80 9.2 Trabajo futuro...................................................................................................................81 Bibliografía.................................................................................................................................83 ÍNDICE DE ILUSTRACIONES Figura 1. Tablero de tareas Figura 2. Diagrama entidad-relación Figura 3. Migración de Productos Figura 4. Modelo de Producto Figura 5. Enumerador de Clase Figura 6. Migración de Nominales Figura 7. Modelo de Nominal Figura 8. Migración de Ensayos Figura 9. Modelo de Ensayo Figura 10. Migración de Atributos Figura 11. Modelo de Atributo Figura 12. Migración de Usuarios Figura 13. Modelo de Usuario Figura 14. Migración de Tokens Personales de Acceso Figura 15. Diagrama de casos de uso Figura 16. Arquitectura del sistema Figura 17. Diagrama de MVC Figura 18. Ejemplo de inyección de dependencias Figura 19. Código de Middleware de autenticación Figura 20. Ejemplo de componente de Svelte básico Figura 21. Ejemplo de componente Svelte usando el patrón Composite Figura 22. Inicio de sesión Figura 23. Cierre de sesión Figura 24. Búsqueda y Acciones de Expedientes Figura 25. Visualización de Expediente Figura 26. Formulario de creación y modificación de Expediente 1 Figura 27. Formulario de creación y modificación de Expediente 2 Figura 28. Formulario de creación y modificación de Expediente 3 Figura 29. Formulario de creación y modificación de Expediente 4 Figura 30. Formulario de creación y modificación de Expediente 5 Figura 31. Eliminación de Expediente Figura 32. Ejemplo de Histórico Figura 33. Ejemplo de Test de Grubbs Figura 34. Ejemplo de diferencia de medias Figura 35. Búsqueda de Productos Figura 36. Búsqueda de Ensayos Figura 37. Visualización de Productos Figura 38. Visualización de Ensayos Figura 39. Formulario de creación y modificación de Producto Figura 40. Formulario de creación y modificación de Ensayo ÍNDICE DE TABLAS Tabla 1. Iniciar sesión Tabla 2. Cerrar sesión Tabla 3. Ver Expediente Tabla 4. Crear Expediente Tabla 5. Modificar Expediente Tabla 6. Eliminar Expediente Tabla 7. Buscar Expedientes por ID Tabla 8. Buscar Expedientes mediante filtros Tabla 9. Ver Producto Tabla 10. Crear Producto Tabla 11. Modificar Producto Tabla 12. Eliminar Producto Tabla 13. Buscar Productos por ID Tabla 14. Buscar Productos por Clase Tabla 15. Buscar Productos por nombre Tabla 16. Obtener Nominales de un Producto Tabla 17. Ver Ensayo Una vez implementadas las acciones sobre un expediente, se ha usado este sprint para empezar a implementar funcionalidades sobre varios expedientes. Las primeras fueron un histórico de datos, mostrando la evolución de los resultados de los ensayos realizados en los expedientes seleccionados; y el Test de Grubbs, permitiendo averiguar la existencia de valores atípicos al compararlos con expedientes preexistentes. Sprint 5: Más estadísticas. El último sprint se ha centrado en añadir más estadísticas a la aplicación. La primera fue la comparación de los valores medios de los nominales de productos de distintos fabricantes, que permitía encontrar anomalías entre los productos de dos fabricantes, seleccionando una lista de expedientes como muestra. La otra fue la capacidad de ver un histórico sobre un conjunto de expedientes, que permite ver de forma gráfica la evolución de los resultados obtenidos en los ensayos comunes a dichos expedientes. 1.4 Estructura de la memoria A continuación se describen de forma breve los capítulos que constituyen la memoria: ●Capítulo 1 - Introducción: Este capítulo está dedicado a la motivación y objetivos del trabajo junto con el plan del trabajo seguido y la estructura de la memoria. ●Capítulo 2 - Estado del arte: Este capítulo está dedicado a la descripción de aplicaciones que ofrecen funcionalidades parecidas a las de este trabajo. ●Capítulo 3 - Tecnología implementada: Este capítulo está dedicado a explicar las tecnologías implementadas en el trabajo. 6 ●Capítulo 4 - Modelo de datos: Este capítulo está dedicado a la descripción del modelo de datos usado en el trabajo para realizar la persistencia de la información de la aplicación. ●Capítulo 5 - Casos de uso: Este capítulo está dedicado a la descripción de la especificación de requisitos y los actores que participan en ellos. ●Capítulo 6 - Arquitectura: Este capítulo está dedicado a la descripción de la arquitectura utilizada para la implementación del trabajo propuesto. ●Capítulo 7 - Diseño: Este capítulo está dedicado a la descripción de las principales funcionalidades implementadas junto con el diseño utilizado en ellas. ●Capítulo 8 - Conclusiones y trabajo futuro: Este capítulo está dedicado a las conclusiones del trabajo realizado seguido de el posible trabajo futuro a realizar. 7 Capítulo 2 - Estado de la cuestión Si bien es cierto no existen alternativas al proyecto, al desarrollar en este una aplicación muy específica, sí que existen otros productos que se podrían haber usado para implementar la solución de nuestro proyecto (productos software con acceso a una base de datos mediante una interfaz gráfica, permitiendo obtener estadísticas relevantes). En este apartado se nombran estos productos, y por qué se descartaron para el desarrollo de nuestra aplicación. ●Firebase [3]. Firebase es una plataforma en la nube para el desarrollo de aplicaciones web y móviles que pertenece a Google. Tiene herramientas para gestionar Bases de datos, autenticación de usuarios y de analíticas (aunque estas se centran más en información sobre los usuario que utilizan la aplicación, por lo que no nos serviría para nuestro propósitos estadísticos). El principal problema de FIrebase es que es un producto privativo y de pago, además de no contar con la opción de ser auto hosteado, lo cual significa que nuestros datos se encontrarán en la nube. ●Supabase [4]. Supabase es una alternativa a Firebase de código abierto, con opción de ser auto hosteado, y con un plan gratis, aunque este plan no nos serviría debido al tamaño de datos de nuestra aplicación. El precio también se ve reducido, pero al no contar tampoco con herramientas para obtener estadísticas relevantes también fue descartado. ●PocketBase [5]. Por último, PocketBase es otra alternativa a Firebase, muy similar a Supabase, solo que de manera completamente gratuita, pero usa como Base de datos SQLite, una Base de datos basada en ficheros en memoria, la cual no 8 es la mejor opción para grandes cantidades de datos, por lo que tampoco fue utilizada. 9 Capítulo 3 - Tecnologías empleadas Este capítulo está dedicado a presentar todas las tecnologías utilizadas para el desarrollo de los objetivos planteados en el apartado 1.2. 3.1 Herramientas Frontend 3.1.1 HTML 5 HTML 5 [6] (HyperText Markup Language, versión 5) es un lenguaje de marcado que se utiliza en el desarrollo de páginas web. En este proyecto se ha utilizado para definir la estructura, el diseño y el contenido de la página web. 3.1.2 CSS y Tailwind CSS CSS [7] (Cascading Style Sheets) es el lenguaje de estilos utilizado para describir la presentación de documentos HTML. CSS describe cómo debe renderizar el elemento estructurado en la pantalla. Es uno de los lenguajes base de la Open Web y posee una especificación estandarizada por parte del W3C (World Wide World Consortium) Por otra parte, Tailwind [8] CSS es un framework CSS basado en CSS atómico, proporcionando un conjunto de clases utilitarias. En vez de implementar estilos para cada elemento de nuestra aplicación, podemos utilizar las clases de tailwind predefinidas para agilizar el desarrollo de nuestra interfaz. Aunque su uso no es el más recomendable para grandes aplicaciones con interfaces muy complejas, para una interfaz sencilla como es la de nuestra aplicación es de gran ayuda. 10 3.1.3 JavaScript y TypeScript JavaScript [9] es un lenguaje de programación con tipado débil, al permitir declarar variables sin especificar su tipo, y dinámico, al ser posible cambiar el tipo de variables existentes. Debido a estas dos características, JavaScript siempre se ha visto como un lenguaje poco robusto, por lo que en 2012 Microsoft lanzó TypeScript [10], una extensión de JavaScript que intenta mejorar la seguridad del lenguaje mediante un tipado fuerte y estático. Además, mientras JavaScript es un lenguaje interpretado, TypeScript es uno compilado, permitiendo indicar errores antes de la ejecución del código. Se ha utilizado TypeScript para implementar toda la lógica del frontend de la aplicación. 3.1.4 DaisyUI 4 DaisyUI [11] es una librería de componentes web gratis y de código abierto basada en Tailwind CSS, proporcionándonos clases utilitarias más complejas y un amplio repositorio de componentes reutilizables que podemos usar en nuestra aplicación. El uso de esta librería ha servido como base de los componentes más complejos que usa nuestra aplicación. 3.1.5 AG Grid AG Grid [12] es la librería de tablas para Javascript más utilizada del mundo. Cuenta con versiones gratuitas y de pago, pero la versión gratuita cumple todos los requisitos que necesita nuestra aplicación, ya que nos permite crear tablas complejas y dinámicas de manera muy simple. 11 Se ha utilizado esta librería para crear las tablas existentes en las vistas de búsqueda y detalle de Expedientes, Productos y Ensayos, y en la selección de grupos para el estadístico de diferencia de medias mediante la distribución t de Student. 3.1.6 Chart.js Chart.js [13] es una librería de código abierto para la creación de gráficas. Cuenta con una interfaz muy simple pero completa, que nos permite crear varios tipos de gráficas de manera fácil y rápida. Se ha utilizado esta herramienta para mostrar de manera más visual los resultados de las estadísticas disponibles en este proyecto. 3.1.7 Svelte 4 y SvelteKit 1 Svelte [14] es un framework de desarrollo web diseñado para crear interfaces de usuario (UI). En este TFG se ha usado Svelte para desarrollar componentes de interfaz de usuario, como barras de navegación o formularios para crear expedientes. Los usuarios pueden ver e interactuar con estos componentes en sus navegadores. Svelte cuenta con un compilador, el cual convierte los componentes en JavaScript, que puede ejecutarse para generar el HTML de la página, y en CSS, que aplica estilos a la página. Es una alternativa a React, que es la librería para crear páginas web reactivas más utilizada. Por otra parte, Sveltekit [15] es un framework para desarrollar de manera rápida aplicaciones web robustas y con buen rendimiento, y utiliza Svelte para crear las interfaces de usuario. El uso de esta tecnología nos permite añadir rutas con variables, ejecutar código JavaScript al cargar rutas (para protegerlas o hacer llamadas a la Base de Datos por ejemplo), o tener variables globales, entre muchas otras cosas. De hecho, Sveltekit puede funcionar como un Backend completo, por lo que se pueden 12 construir aplicaciones full stack con él, aunque en este proyecto solo se ha utilizado para construir el frontend. 3.2 Herramientas Backend 3.2.1 PHP y Laravel 10 PHP [16] es un lenguaje de programación interpretado del lado del servidor y de uso general, con tipado débil y dinámico al igual que JavaScript. Laravel [17] es un framework de PHP lanzado en 2011, con el objetivo de facilitar el desarrollo de aplicaciones que sigan el patrón Modelo-Vista-Controlador. Laravel es un framework muy completo, que facilita mucho la interacción con los datos de la aplicación, al permitir crear entidades (llamadas Modelos) de manera muy sencilla, y contener un ORM (Object Relational Mapper) integrado, llamado Eloquent que relaciona los Modelos con Tablas (o Colecciones en caso de usar MongoDB) de nuestra Base de Datos. Además, Eloquent permite realizar cambios en nuestra Base de Datos mediante ficheros de migraciones, y acceder a ésta mediante una API muy sencilla, por lo que no nos tenemos que preocupar por vulnerabilidades en nuestras consultas. Aparte de Eloquent, Laravel contiene muchas funcionalidades más, como la de añadir Middleware a nuestras rutas, inyección de dependencias en los Controladores, o una validación de datos muy compleja. Por todos estos motivos, se decidió utilizar Laravel para el desarrollo del backend de este proyecto frente a otras alternativas como Java Spring Boot, ya que se habría necesitado configurar la dependencia de un ORM, y de un generador de consultas como QueryDSL, mientras que Laravel las incorpora nativamente. 13 3.2.2 PostgreSQL PostgreSQL [18], o también llamado Postgres, se considera un sistema de gestión de bases de datos objeto-relacional (ORDBMS) de código abierto, lo que significa que combina las capacidades de las bases de datos relacionales con algunas características orientadas a objetos. En este trabajo se ha usado para gestionar la parte relacional de la base de datos, encargada de guardar la estructura de las entidades y metadatos del proyecto. 3.2.3 MongoDB MongoDB [19] es un sistema de base de datos NoSQL, orientado a documentos y de código abierto. En lugar de guardar los datos en tablas, tal y como se hace en las bases de datos relacionales, MongoDB guarda estructuras de datos BSON (una especificación similar a JSON) con un esquema dinámico. Hemos hecho uso de MongoDB en este proyecto para la persistencia y gestión de los resultados obtenidos en los ensayos de Expediente. Esto es ideal para nuestra aplicación, ya que la estructura de los datos puede variar entre diferentes expedientes y ensayos. Dicha estructura será explicada con más detalle en el capítulo 4. 3.2.4 Docker Docker [20] es un proyecto de código abierto diseñado para automatizar el despliegue de aplicaciones mediante el uso de contenedores, proporcionando una capa adicional de abstracción y automatización al despliegue de tanto entornos de desarrollo como de producción. Docker automatiza la replicación de aplicaciones mediante ficheros .Dockerfile, los cuales encapsulan el entorno de una aplicación 14 (dependencias, variables de entorno, comandos a ejecutar para iniciar la aplicación, etc). Para poder ejecutar un contenedor Docker solamente se necesita tener Docker instalado, y compartir el mismo kernel que el contenedor (normalmente Linux, aunque es posible también con Windows). Se ha utilizado esta tecnología para automatizar el lanzamiento de las aplicaciones frontend y backend en los entornos de producción. 3.2.6 AWS RDS Amazon Web Services [21] es la colección de servicios de computación en la nube propiedad de Amazon. Uno de estos servicios es AWS Relational Database Service, encargado de proporcionar bases de datos relacionales en AWS. Se ha utilizado este servicio para albergar la base de datos Postgres de producción, ya que RDS cuenta con un plan gratuito que satisface las necesidades del proyecto. El cambio a otro servicio en la nube, o el uso de un servidor propio implicaría realizar cambios en las variables de entorno del servidor encargado de albergar el backend, indicando el host, puerto, usuario y contraseña del nuevo servicio. 3.2.7 MongoDB Atlas MongoDB Atlas [22] es el servicio en la nube de Mongo, el cual ha servido para almacenar la base de datos MongoDB de producción. Al igual que ocurre con la base de datos relacional, el CEDEX puede seguir usando este servicio, o decidir alojar esta base de datos en un servidor local, modificando las variables de entorno necesarias. 15 para adaptarse a futuros cambios y escalabilidad. Al combinar lo mejor de las bases de datos relacionales y no relacionales, se logra una solución robusta y versátil que satisface los diversos requerimientos de la aplicación. 4.2 Implementación de la base de datos 4.2.1 Base de datos relacional Para la implementación de la base de datos relacional, se ha utilizado Postgres 16.1, ya que es la versión más actual soportada por AWS en la fecha de creación de la base de datos. Para la creación de las tablas se ha utilizado la funcionalidad Schema de Laravel, que nos permite la creación y manipulación de tablas de todas las conexiones en la aplicación mediante el uso de ficheros de migración, que actúan como un sistema de control de versiones de la base de datos. Una vez creada una tabla, mediante el ORM Eloquent, podemos crear un Modelo asociado a dicha tabla, lo que nos permite utilizar el ORM para realizar consultas en vez de escribir código SQL a mano. Para ejecutar las migraciones, utilizamos Artisan, el CLI que nos provee Laravel. El comando a ejecutar es php artisan migrate:refresh. A continuación se mostrarán los ficheros de migración y los Modelos de las entidades de la base de datos. 22 4.2.1.1 Productos Figura 3. Migración de Productos (elaboración propia) * La función timestamps() utilizada en la creación de la tabla crea las columnas created_at y updated_at. 23 Figura 4. Modelo de Producto (elaboración propia) 24 La función nominals() declara una relación 1 a n con el modelo Nominal, lo que nos permite acceder a los Nominales pertenecientes a un Producto de manera directa. Además, el atributo $casts nos permite declarar que el atributo class de un Producto solo puede tomar los valores del enumerado ClassEnum, que es el siguiente: Figura 5. Enumerador de Clase (elaboración propia) 25 4.2.1.2 Nominales Figura 6. Migración de Nominales (elaboración propia) El uso de las funciones foreignId() y constrained() sirven para crear una clave foránea. Laravel buscará una tabla con el nombre del atributo sin el ‘_id’, y creará dicha clave. 26 Figura 7. Modelo de Nominal (elaboración propia) La función product() declara una relación de pertenencia entre un Nominal y un Producto, lo que nos permite acceder al Producto de un Nominal de forma directa. 27 4.2.1.3 Ensayos Figura 8. Migración de Ensayos (elaboración propia) 28 Figura 9. Modelo de Ensayo (elaboración propia) 29 4.2.1.4 Atributos Figura 10. Migración de Atributos (elaboración propia) 30 Figura 11. Modelo de Atributo (elaboración propia) 31 4.3. Modificar Ensayo 4.4. Eliminar Ensayo 4.5. Buscar Ensayos por ID 4.6. Buscar Ensayos por Clase 4.7. Buscar Ensayos por nombre 4.8. Buscar Ensayos de ciertos productos 4.9. Obtener Atributos de un Ensayo 5. Estadísticas 5.1. Grubbs 5.2. Diferencia de medias 5.3. Histórico 5.3.1 Usuarios Las tablas 1 y 2 muestran los casos de uso relacionados con los usuarios. 38 Requisito Iniciar sesión Identificador 1.1 Prioridad Alta Precondición NA Descripción Inicio de sesión de un usuario Entrada Correo electrónico y contraseñas del usuario. Salida Token de acceso personal para el uso de la API Tabla 1. Iniciar sesión 39 Secuencia Normal 1. El usuario sin sesión accede a la web, y esta le redirige a la página de inicio de sesión. 2. Se muestra en pantalla un formulario de inicio de sesión. 3. El Usuario rellena todos los campos y hace click en el botón de ‘Enviar’. 4. La página web envía una petición a la API con la información del usuario. 5. La API valida la información y genera un token de acceso para el usuario. 6. La página web recibe el token y lo guarda para las subsiguientes peticiones que realice el usuario. Postcondición Inicio de sesión del usuario Excepciones Paso 5 : No se ha podido realizar el inicio de sesión debido a una contraseña o usuario incorrecto, por lo que se le muestra un mensaje de error al usuario Comentarios NA Actores Usuario no registrado Requisito Cerrar sesión Identificador 1.2 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Tabla 2. Cerrar sesión 5.3.2 Expedientes Las tablas 3 - 8 muestran los casos de uso relacionados con los expedientes. 40 Descripción Cierre de sesión de un usuario Entrada Token de acceso personal del usuario Salida NA Secuencia Normal 1. El usuario presiona el botón de cierre de sesión en la barra de navegación de la página web. 2. La aplicación web envía una petición a la API con el token obtenido en el inicio de sesión. 3. La API valida el token y lo elimina de la base de datos. 4. Se redirecciona al usuario a la página de inicio se sesión. Postcondición Cierre de sesión del usuario Excepciones NA Comentarios NA Actores Usuario registrado Requisito Ver Expediente Identificador 2.1 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Tabla 3. Ver Expediente 41 Descripción Visualización gráfica de un Expediente Entrada ID del Expediente a visualizar Salida Vista de visualización del Expediente Secuencia Normal 1. El usuario accede a la página de visualización de un Expediente. 2. Al cargar dicha vista, la página web realiza una petición a la API para obtener toda la información del Expediente deseado. 3. Se muestra de forma gráfica la información del Expediente indicado. Postcondición NA Excepciones Paso 4: si no existe un Expediente con el identificador escogido, se redirecciona al usuario a la página de error de la aplicación web con el código 404 NOT FOUND. Comentarios La excepción anteriormente descrita no debería ocurrir a no ser que se intente acceder a la vista de visualización escribiendo manualmente la URL, ya que el usuario podría equivocarse al escribir manualmente el identificador. Actores Usuario registrado Requisito Crear Expediente Identificador 2.2 42 Prioridad Crítica Precondición El usuario ha de haber iniciado sesión Descripción Persistencia de un nuevo Expediente en la base de datos Entrada JSON con la información del Expediente a crear Salida Identificador del nuevo Expediente Secuencia Normal 1. El usuario accede a la página de creación de Expediente, en la que se le muestra un formulario dividido en 3 pasos (Información general, Productos y Ensayos) para rellenar con la información del nuevo Expediente. 2. El usuario rellena el formulario. 3. El usuario, una vez completado el formulario, presiona un botón que realiza una petición a la API con la información del nuevo Expediente. 4. La API valida la información. 5. Se crea un nuevo documento en la colección de la base de datos MongoDB de la aplicación. 6. La API devuelve el identificador del nuevo Expediente. Postcondición Se crea un nuevo Expediente en la base de datos Excepciones Pasos 2 y 4: si ocurre un fallo en las validaciones realizadas desde el cliente o el servidor, se muestra el mensaje de error pertinente al usuario. Tabla 4. Crear Expediente 43 Comentarios Las validaciones desde el cliente se centran en que todos los datos necesarios se encuentren rellenados, mientras que las validaciones realizadas desde el servidor se centran en la veracidad de los datos (no existe un expediente con el mismo número de expediente, todos los productos o ensayos ingresados existen en la base de datos, etc). Actores Usuario registrado Requisito Modificar Expediente Identificador 2.3 Prioridad Baja Precondición El usuario ha de haber iniciado sesión Descripción Modificación de un Expediente presente en la base de datos Entrada JSON con la información del Expediente modificado Salida NA Tabla 5. Modificar Expediente 44 Secuencia Normal 1. El usuario accede a la página de modificación de Expediente, en la que se le muestra el mismo formulario que en la creación del Expediente pero con los datos precargados. 2. El usuario modifica los datos del Expediente. 3. El usuario, una vez completado el formulario, presiona un botón que realiza una petición a la API con la información del Expediente modificado. 4. La API valida la información. 5. Se actualiza el Expediente con la nueva información proporcionada. Postcondición NA Excepciones Pasos 2 y 4: se realizan las mismas validaciones que en la creación de un Expediente. Paso 1: si no existe un Expediente con el identificador escogido, se redirecciona al usuario a la página de error de la aplicación web con el código 404 NOT FOUND. Comentarios La excepción anteriormente descrita no debería ocurrir a no ser que se intente acceder a la vista de modificación escribiendo manualmente la URL, ya que el usuario podría equivocarse al escribir manualmente el identificador. Actores Usuario registrado 45 Requisito Eliminar Expediente Identificador 2.4 Prioridad Baja Precondición El usuario ha de haber iniciado sesión Descripción Hard delete de un Expediente existente en la base de datos Entrada Identificador del Expediente a eliminar Salida NA Secuencia Normal 1. El usuario, ya sea desde la vista de visualización de expediente, o desde los resultados de una búsqueda de expediente, selecciona uno de ellos para su eliminación. 2. La página web muestra un mensaje de confirmación antes de eliminar el Expediente, ya que es una acción permanente. 3. Si el usuario confirma la acción, se envía una petición a la API para la eliminación del Expediente. Postcondición Se elimina el Expediente seleccionado de la base de datos Excepciones NA Comentarios El hard delete consiste en la eliminación física del registro seleccionado. La alternativa sería un soft delete, que marca el registro como eliminado/inactivo mediante una atributo de la entidad, pero no lo elimina de la base de datos. Tabla 6. Eliminar Expediente Tabla 7. Buscar Expedientes por ID 46 Actores Usuario registrado Requisito Buscar Expedientes por ID Identificador 2.5 Prioridad Media Precondición El usuario ha de haber iniciado sesión Descripción Búsqueda de Expedientes mediante una lista de identificadores Entrada Lista de identificadores de Expedientes Salida JSON con la información de los Expedientes búscados Secuencia Normal 1. Se buscan en la base de datos los Expedientes con los identificadores indicados 2. Se devuelve la información de los Expedientes mediante JSON. Postcondición NA Excepciones NA Comentarios Este caso de uso es de uso interno para diversas vistas de la aplicación. Se pueden ver todas en el diagrama de casos de uso de la aplicación. Actores Usuario registrado 47 Requisito Buscar Expedientes mediante filtros Identificador 2.6 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Descripción Búsqueda filtrada de Expedientes Entrada JSON con el criterio de búsqueda de los expedientes Salida Listado con los Expedientes resultantes de la búsqueda Secuencia Normal 1. El usuario accede a la página principal de expedientes, donde se encuentra una sección con diversos filtros para realizar una búsqueda. 2. El usuario rellena los filtros que quiera y realiza una búsqueda. 3. Se realiza una petición a la API que realiza la búsqueda pertinente. 4. La API devuelve el listado de Expedientes que cumpla el criterio de búsqueda. 5. Se muestran los resultados de manera tabulada. Postcondición NA Excepciones NA Comentarios Los filtros existentes son los siguientes: número de expediente, nombre del fabricante, conjunto de años Tabla 13. Buscar Productos por ID 54 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Descripción Búsqueda de Productos mediante una lista de identificadores Entrada Lista de identificadores de Productos Salida JSON con la información de los Productos buscados Secuencia Normal 1. Se buscan en la base de datos los Productos con los identificadores indicados 2. Se devuelve la información de los Productos mediante JSON. Postcondición NA Excepciones NA Comentarios Este caso de uso es de uso interno para diversas vistas de la aplicación. Se pueden ver todas en el diagrama de casos de uso de la aplicación. Actores Usuario registrado Requisito Buscar Productos por Clase Identificador 3.6 Prioridad Alta Tabla 14. Buscar Productos por Clase 55 Precondición El usuario ha de haber iniciado sesión Descripción Búsqueda de Productos pertenecientes a una Clase Entrada Clase de los Productos Variable booleana para obtener también los Nominales de los Productos (opcional) Salida JSON con la información de los Productos buscados Secuencia Normal 1. Se buscan en la base de datos los Productos pertenecientes a la Clase indicada. 2. Se devuelve la información de los Productos mediante JSON. Postcondición NA Excepciones NA Comentarios Este caso de uso es de uso interno para diversas vistas de la aplicación. Se pueden ver todas en el diagrama de casos de uso de la aplicación. Actores Usuario registrado Requisito Buscar Productos por nombre Identificador 3.7 Tabla 15. Buscar Productos por nombre 56 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Descripción Búsqueda de Productos mediante una cadena de texto que filtra los Productos por su nombre Entrada Cadena de texto para la búsqueda Variable booleana para obtener también los Nominales de los Productos (opcional) Salida JSON con la información de los Productos buscados Secuencia Normal 1. Se buscan en la base de datos los Productos cuyos nombres concuerdan con la cadena de texto proporcionada. 2. Se devuelve la información de los Productos mediante JSON. Postcondición NA Excepciones NA Comentarios Este caso de uso es de uso interno para diversas vistas de la aplicación. Se pueden ver todas en el diagrama de casos de uso de la aplicación. Actores Usuario registrado Tabla 16. Obtener Nominales de un Producto 57 Requisito Obtener Nominales de un Producto Identificador 3.8 Prioridad Alta Precondición El usuario ha de haber iniciado sesión Descripción Obtención de los Nominales de un Producto Entrada Identificador del Producto Salida Lista de Nominales del Producto seleccionado Secuencia Normal 1. Se buscan en la base de datos los Nominales pertenecientes al Producto indicado. 2. Se devuelve la información de los Nominales mediante JSON. Postcondición NA Excepciones NA Comentarios Este caso de uso es de uso interno para diversas vistas de la aplicación. Se pueden ver todas en el diagrama de casos de uso de la aplicación. Actores Usuario registrado 5.3.3 Ensayos Las tablas 17 - 25 muestran los casos de uso relacionados con los ensayos. 58 Requisito Ver Ensayo Identificador 4.1 Prioridad Baja Precondición El usuario ha de haber iniciado sesión Descripción Visualización gráfica de un Ensayo Entrada ID del Ensayo a visualizar Salida Vista de visualización del Ensayo Secuencia Normal 1. El usuario accede a la página de visualización de un Ensayo. 2. Al cargar dicha vista, la página web realiza una petición a la API para obtener toda la información del Ensayo deseado. 3. Se muestra de forma gráfica la información del Ensayo indicado. Postcondición NA Excepciones Paso 4: si no existe un Ensayo con el identificador escogido, se redirecciona al usuario a la página de error de la aplicación web con el código 404 NOT FOUND. Comentarios La excepción anteriormente descrita no debería ocurrir a no ser que se intente acceder a la vista de visualización escribiendo manualmente la URL, ya que el usuario podría equivocarse al escribir manualmente el identificador. Tabla 17. Ver Ensayo 59 Actores Usuario registrado Requisito Crear Ensayo Identificador 4.2 Prioridad Media Precondición El usuario ha de haber iniciado sesión Descripción Persistencia de un nuevo Ensayo en la base de datos Entrada JSON con la información del Ensayo a crear Salida Identificador del nuevo Ensayo Tabla 18. Crear Ensayo 60 Secuencia Normal 1. El usuario accede a la página de creación de Ensayo, en la que se le muestra un formulario para rellenar con la información del nuevo Ensayo. 2. El usuario rellena el formulario. 3. El usuario, una vez completado el formulario, presiona un botón que realiza una petición a la API con la información del nuevo Ensayo. 4. La API valida la información. 5. Se crean nuevas entradas para las tablas de Ensayos y Atributos de la base de datos relacional con la información del nuevo Producto. 6. La API devuelve el identificador del nuevo Ensayo. Postcondición Se crea un nuevo Ensayo en la base de datos Excepciones Pasos 2 y 4: si ocurre un fallo en las validaciones realizadas desde el cliente o el servidor, se muestra el mensaje de error pertinente al usuario. Comentarios Las validaciones desde el cliente se centran en que todos los datos necesarios se encuentren rellenados, mientras que las validaciones realizadas desde el servidor se centran en la veracidad de los datos (no existe un ensayo con el mismo nombre). Actores Usuario registrado 61 Requisito Modificar Ensayo Identificador 4.3 Prioridad Baja Precondición El usuario ha de haber iniciado sesión Descripción Modificación de un Ensayo presente en la base de datos Entrada JSON con la información del Ensayo modificado Salida NA Secuencia Normal 1. El usuario accede a la página de modificación de Ensayo, en la que se le muestra el mismo formulario que en la creación del Ensayo pero con los datos precargados. 2. El usuario modifica los datos del Ensayo. 3. El usuario, una vez completado el formulario, presiona un botón que realiza una petición a la API con la información del Ensayo modificado. 4. La API valida la información. 5. Se actualiza el Ensayo con la nueva información proporcionada. Postcondición NA Excepciones Pasos 2 y 4: se realizan las mismas validaciones que en la creación de un Ensayo. Paso 1: si no existe un Ensayo con el Tabla 19. Modificar Ensayo 62 identificador escogido, se redirecciona al usuario a la página de error de la aplicación web con el código 404 NOT FOUND. Comentarios La excepción anteriormente descrita no debería ocurrir a no ser que se intente acceder a la vista de modificación escribiendo manualmente la URL, ya que el usuario podría equivocarse al escribir manualmente el identificador. Actores Usuario registrado Requisito Eliminar Ensayo Identificador 4.4 Prioridad Baja Precondición El usuario ha de haber iniciado sesión Descripción Hard delete de un Ensayo existente en la base de datos Entrada Identificador del Ensayo a eliminar Salida NA Tabla 20. Eliminar Ensayo 63 Secuencia Normal 1. El usuario, ya sea desde la vista de visualización de ensayo, o desde los resultados de una búsqueda de ensayos, selecciona uno de ellos para su eliminación. 2. La página web muestra un mensaje de confirmación antes de eliminar el Ensayo, ya que es una acción permanente. 3. Si el usuario confirma la acción, se envía una petición a la API para la eliminación del Ensayo. Postcondición Se elimina el Ensayo seleccionado de la base de datos Excepciones Paso 3: solamente se podrá eliminar un Ensayo que no aparezca en ningún Expediente. En caso contrario, se mostrará al usuario un mensaje de error explicativo. Comentarios El hard delete consiste en la eliminación física del registro seleccionado. La alternativa sería un soft delete, que marca el registro como eliminado/inactivo mediante una atributo de la entidad, pero no lo elimina de la base de datos. Actores Usuario registrado Requisito Buscar Ensayos por ID Identificador 4.5 Tabla 26. Test de Grubbs 70 Secuencia Normal 1. Se realiza una búsqueda de Expedientes, y se seleccionan los deseados para la realización del estadístico. 2. Se accede a la vista del test de Grubbs. 3. Se selecciona el Ensayo, Atributo y nuevo valor, con la posibilidad de rellenar los filtros mencionados en la entrada. 4. Se presiona el botón de calcular, que realiza una llamada a la API, devolviendo el resultado del estadístico. 5. Se muestran los resultados de forma gráfica al usuario. Postcondición NA Excepciones NA Comentarios NA Actores Usuario registrado Requisito Diferencia de medias Identificador 5.2 Prioridad Alta Precondición El usuario ha de haber iniciado sesión La lista de Expedientes debe de ser de al menos 2 Los Expedientes deben de tener al menos 71 un Ensayo en común Los Expedientes deben de pertenecer a un máximo de 2 fabricantes Los Expedientes deben de tener al menos un producto con un tipo común Descripción Realización del test de diferencia de medias sobre los resultados de un atributo en varios expedientes, con el objetivo de ver si los valores medios sobre los datos elegidos son homogéneos. Entrada Lista de identificadores de Expedientes, separados en dos grupos Identificador del Ensayo Identificador del Atributo Tipo sobre el que se realizan los cálculos Filtros de tipo, grado y productos sobre los que realizar el estadístico (opcionales) Salida Resultado que indique si las medias de los dos grupos son homogéneas Secuencia Normal 1. Se realiza una búsqueda de Expedientes, y se seleccionan los deseados para la realización del estadístico. 2. Se accede a la vista del test de diferencia de medias. 3. Se dividen los Expedientes en dos grupos, y se seleccionan el Ensayo, Atributo y tipo sobre el que se realizarán los cálculos. 4. Se presiona el botón de calcular, que realiza una llamada a la API, devolviendo el resultado del estadístico. 5. Se muestran los resultados de forma gráfica al usuario. Tabla 27. Diferencia de medias 72 Postcondición NA Excepciones NA Comentarios El tipo es un identificador que da información sobre las propiedades mecánicas y químicas del acero. Se trata de una cadena de texto de 4 caracteres. Actores Usuario registrado Requisito Histórico Identificador 5.3 Prioridad Media Precondición El usuario ha de haber iniciado sesión La lista de Expedientes debe de ser de al menos 3 Los Expedientes deben de tener al menos un Ensayo en común Descripción Visualización gráfica de la evolución de los resultados sobre una serie de Expedientes. Entrada Lista de identificadores de Expedientes Salida Gráficas que muestran de manera visual la evolución de los resultados sobre una serie de Expedientes. Tabla 28. Histórico 73 Secuencia Normal 1. Se realiza una búsqueda de Expedientes. 2. Por cada Ensayo común entre los Expedientes, se muestra un apartado, en el que se muestran dos gráficas por atributo del Ensayo, una representando los resultados agrupados por expedientes, y otra mostrando la tendencia que han ido tomando los resultados. Postcondición NA Excepciones NA Comentarios NA Actores Usuario registrado Capítulo 6 - Arquitectura Este capítulo está dedicado a la descripción de la arquitectura utilizada para la implementación del trabajo propuesto. 6.1 Arquitectura del sistema La arquitectura del sistema sigue un doble modelo cliente-servidor. Existen dos servicios, la aplicación web con SvelteKit y la API con Laravel. Los usuarios hacen solicitudes GET a la aplicación web, encargada de mostrar las vistas. La aplicación de SvelteKit actúa en este caso como servidor, pero a la vez actúa como cliente, realizando llamadas HTTP a la API para interactuar con la base de datos. La representación gráfica del sistema se muestra en la Figura 16. 74 Figura 16. Arquitectura del sistema (elaboración propia) 75 6.2 Patrones Arquitectónicos 6.2.1 REST REST [29] (Representational State Transfer) es una serie de principios para la creación de servicios web, basándose en el uso del protocolo HTTP . El uso de RESTful APIs (nombre de las APIs que siguen los principios REST) es el más común en la web a día de hoy, y la opción que se ha seguido para la implementación de nuestra API. Los principios que debe seguir una API REST son los siguientes: ●Uso de interfaz uniforme: se deben agrupar los distintos recursos en URIs distintas, usando sustantivos para definirlos (por ejemplo /productos, o /ensayos/{id}/atributos. Se debe evitar utilizar verbos en la interfaz, y utilizar los distintos métodos HTTP disponibles (por ejemplo, en vez de usar GET /crear-producto, usar POST /productos) ●Cliente-servidor: el dominio del cliente es la UI y la recolección de peticiones, mientras que el dominio del servidor se centra en el acceso de datos, gestión de carga de trabajo y seguridad. Esta separación permite el desarrollo independiente de cada uno, disminuyendo el acoplamiento. ●Operaciones sin estado: el servidor no guarda información del estado del cliente. Este principio junto a la separación de los servicios, siguiendo el principio de cliente-servidor, impidió el uso de sesiones o cookies. Por eso se creó un middleware de autenticación utilizando cabeceras HTTP, que será explicado en el siguiente apartado. ●Almacenamiento de caché de recursos: debe de ser posible almacenar en caché el resultado de las peticiones, con el objetivo de mejorar la eficiencia y rendimiento. Para que esto sea posible, las peticiones GET deben de ser 76 idempotentes, ya que esto permite que llamadas subsecuentes devuelvan el mismo resultado, independientemente de que usuario las realice. Aunque era una posibilidad, no se realiza el uso de caché en este trabajo, ya que esta dinámica suele ser empleada al usar APIs externas, que normalmente cuentan con límite de peticiones o coste por uso. ●Sistema de capas: se recomienda dividir el sistema en diversas capas, lo que distribuye las funcionalidades de la aplicación permitiendo una mejor escalabilidad y mantenimiento. Aunque el sistema de 3 capas (Controlador, Servicio y Repositorio) es más común en Java, las APIs implementadas mediante Laravel suelen optar por un sistema de 2 capas, siendo estas la capa de Controlador y la de Repositorio, ya que Laravel cuenta inyección de dependencias en los controladores y con Eloquent, proporcionando una capa de acceso a datos muy completa, permitiendo prescindir de la capa de Servicio si no se cuenta con una lógica muy extensa. ●Código bajo demanda: mientras que el servidor suele devolver representaciones estáticas de los recursos (en este proyecto mediante el uso de JSON), se da la posibilidad de enviar ejecutables al cliente si es necesario. REST utiliza estos principios junto con el uso del protocolo HTTP para definir una comunicación estandarizada. 6.2.2 Modelo-Vista-Controlador El uso de MVC se basa en la separación de las funcionalidades de la aplicación en 3 capas: ●Modelo: encargado de las entidades de la aplicación, y su interacción con la base de datos. ●Vista: encargada de la representación visual de los datos. 77 ●Controlador: recibe las órdenes del usuario, y se encarga de interactuar con el Modelo, y comunicar los resultados a la Vista. MVC ha sido utilizado normalmente en aplicaciones monolíticas, ya que permite una implementación sencilla. En este proyecto, aunque se utilizan dos servicios, al separarlos en frontend y backend contamos con una arquitectura MVC un poco modificada, siendo: ●Modelo: usamos Eloquent para representar las entidades de la aplicación mediante las clases PHP mencionadas en el apartado 4.2.1, e interactuando con ellas gracias al ORM que nos proporciona el propio Eloquent. ●Vista: las vistas enviadas desde nuestra aplicación web. ●Controlador: los diversos controladores que existen en nuestra API. Las diferencias de este sistema con un MVC tradicional es que el usuario no interactúa directamente con el controlador. Este sistema es más común al usar aplicaciones web reactivas, ya que nos permite actualizar la interfaz gráfica de una parte de la vista sin tener que renderizar de nuevo toda la pantalla. El diagrama de la Figura 17 muestra las diferencias entre el MVC tradicional y el nuestro. Figura 17. Diagrama de MVC (elaboración propia) 78 6.3 Patrones de diseño 6.3.1 Dependency injection La Inyección de Dependencias es un patrón de diseño que resuelve el manejo de dependencias entre diferentes clases de una manera poco acoplada y fácil de mantener y escalar. Existen varios tipos de Inyección de Dependencias, pero la utilizada en este proyecto es la Method Injection, que consiste en pasar las dependencias de una función como parámetros de esta. De esta manera, las dependencias son creadas y proporcionadas fuera de la función, lo que reduce la complejidad de la función, y permite testear la funcionalidad de manera sencilla. Este patrón es utilizado por los controladores de Laravel, lo que nos permite inyectar dependencias como el cuerpo de una petición HTTP de manera automática. La Figura 18 muestra un ejemplo en el que se inyecta el objeto Request a la creación de un expediente. 79 Figura 21. Ejemplo de componente Svelte usando el patrón Composite (elaboración propia) 86 Capítulo 7 - Diseño Este capítulo está dedicado a mostrar el diseño de las funcionalidades desarrolladas durante la elaboración del proyecto. La interfaz visual se ha implementado mediante el uso de componentes Svelte y Tailwind CSS, buscando una interfaz sencilla, amigable y dinámica. 7.1 Autenticación En el apartado de Autenticación, solo existen dos funcionalidades. La primera es iniciar sesión, que ocurre cuando un usuario accede a la aplicación sin tener una sesión iniciada en el ordenador. En esta situación, se muestra al usuario un formulario en el que debe de introducir sus credenciales, que en el caso de nuestra aplicación son su correo electrónico y su contraseña. La Figura 22 muestra la vista de dicho formulario. La otra funcionalidad en el apartado de autenticación, es la de cerrar sesión. Esta acción ocurre cuando un usuario con sesión activa presiona el botón de cierre de sesión en la barra de navegación de la aplicación. La Figura 23 muestra la barra de navegación, donde se encuentra el botón de cierre de sesión. 87 Figura 22. Inicio de sesión (elaboración propia) Figura 23. Cierre de sesión (elaboración propia) 7.2 Expedientes El apartado de Expedientes es el más extenso y complejo. La página principal es la de búsqueda, donde se puede realizar una búsqueda mediante varios filtros, como clase de producto, fabricante o rango de años, entre otros. Los resultados se muestran de forma tabulada, usando la librería AG Grid, que permite al usuario reorganizar las columnas según el gusto personal, y ordenar los resultados por orden de las columnas que vea oportunas. La Figura 24 muestra un ejemplo de resultado de búsqueda, y un resumen de las acciones que se pueden realizar desde esta vista, que serán explicadas a continuación. Sobre un Expediente se pueden realizar varias acciones. 88 Figura 24. Búsqueda y Acciones de Expedientes (elaboración propia) La primera es visualizar el expediente, que redirecciona al usuario a una vista donde puede ver con más detalle la información del Expediente, al mostrarse la información completa de los productos que lo conforman, y tanto información de los ensayos que se han realizado, como los resultados de dichos ensayos sobre los productos del Expediente. Además, al hacer click en el id de un producto o ensayo, se abrirá en una nueva pestaña la vista de visualización de producto o ensayo. La Figura 25 muestra la vista de esta funcionalidad. 89 Figura 25. Visualización de Expediente (elaboración propia) La segunda es editar el Expediente. A esta vista se puede acceder desde los resultados de una búsqueda, o desde la vista detallada de un Expediente. Esta vista es una ligera modificación de la creación de un Expediente, que consta de un formulario dividido en 3 partes: Información general, Productos y Ensayos, que sirve para añadir un documento a la base de datos no relacional de la aplicación en el caso de crear un Expediente, o modificar un documento ya existente en el caso de editar. En el caso de que se quiera editar un Expediente, el formulario será precargado con la información de este para evitar que el usuario tenga que volver a rellenarlo entero de nuevo. Las Figuras 26, 27, 28, 29 y 30 muestran el proceso de creación y edición de Expedientes. La tercera acción posible es la eliminación del Expediente. Esta acción, al igual que la edición, puede realizarse tanto desde la búsqueda como desde la vista detallada de un Expediente. En ambos casos, se muestra un mensaje de advertencia, pidiendo al usuario confirmar la acción, ya que es una acción que no se puede deshacer. En caso de que el usuario confirme la acción, el expediente será eliminado de la base de 90 datos de la aplicación. La Figura 31 muestra el mensaje de confirmación que visualiza el usuario al eliminar un Expediente. Aparte de las acciones que se pueden realizar sobre un Expediente, en la aplicación existen 3 estadísticas que pueden realizarse sobre un conjunto de Expedientes, al seleccionarlos en la tabla de resultados, y presionar el botón de la estadística correspondiente, que estará activo si los Expedientes cumplen la precondición anotada en la Sección 4.3. Estos botones se pueden ver en la Figura 24, y sus vistas se explicarán en el siguiente apartado. Figura 26. Formulario de creación y modificación de Expediente 1 (elaboración propia) 91 Figura 27. Formulario de creación y modificación de Expediente 2 (elaboración propia) Figura 28. Formulario de creación y modificación de Expediente 3 (elaboración propia) 92 Figura 29. Formulario de creación y modificación de Expediente 4 (elaboración propia) Figura 30. Formulario de creación y modificación de Expediente 5 (elaboración propia) 93 Figura 31. Eliminación de Expediente (elaboración propia) 7.3 Estadísticas El apartado de estadísticas intenta dar un valor añadido a los datos existentes en la aplicación, permitiendo ver datos de manera gráfica, y obtener conclusiones de manera automatizada sobre los datos que el usuario considere oportunos. La primera funcionalidad de este grupo es el Histórico, que permite ver la evolución de los resultados en un conjunto de Expedientes. Para acceder a esta vista se necesita seleccionar al menos 3 expedientes, y que estos tengan al menos un ensayo común. Sobre cada atributo de estos ensayos comunes se realizan dos gráficos. El primero muestra los resultados agrupados por expediente, permitiendo ver tanto si los resultados de cada expediente son similares, como ver la evolución de los resultados a lo largo del tiempo. El segundo gráfico muestra los resultados de todos los productos de manera secuencial, y una línea de regresión para visualizar la tendencia de los resultados. La Figura 32 muestra un ejemplo de esta vista. 94 Figura 32. Ejemplo de Histórico (elaboración propia) La segunda estadística es el Test de Grubbs, que se utiliza para comprobar si un valor es aberrante. Se utiliza esta funcionalidad cuando al realizar un ensayo, se obtiene un resultado que el usuario piensa que puede ser anómalo. En este caso, se selecciona una conjunto de expedientes sobre los cuales se quiere comparar el nuevo valor. Este conjunto de expedientes debe tener al menos 3 elementos, y todos deben de tener el ensayo que se quiere comprobar. Al acceder a la vista, aparece un menú con los ensayos sobre los que se puede calcular el estadístico, el atributo del ensayo seleccionado que se quiere comprobar, y el valor que se piensa que es atípico. Además, existen dos datos más que se pueden rellenar de manera opcional, para filtrar los productos sobre los que se realizan los cálculos. Estos datos son el tipo y grado del producto. Una vez seleccionados los campos necesarios, se puede calcular el resultado. El cálculo es el siguiente: 95 Figura 40. Formulario de creación y modificación de Ensayo (elaboración propia) 102 Capítulo 8 - Conclusiones y trabajo futuro 9.1 Conclusiones En este Trabajo de Fin de Grado se ha desarrollado una aplicación destinada la gestión de resultados de laboratorio sobre diferentes tipos de aceros, mediante la creación de una base de datos, una API que permita interactuar con los datos, y una página web que facilite dicha interacción gracias a una interfaz gráfica dinámica. Esta aplicación busca resolver un problema real, proporcionando al CEDEX una forma de estructurar y guardar datos provenientes de varias decenas de años, siendo esta la funcionalidad más importante de la aplicación. Pero esta aplicación les permite además realizar búsquedas complejas sobre expedientes, productos y ensayos, pudiendo ver los resultados de estos de manera gráfica y tabulada, lo que proporciona un valor añadido a las alternativas que usaban anteriormente, como tablas Excel o ficheros físicos. Para la realización del proyecto, se han utilizado tecnologías actuales, y con presencia en el sector profesional. Además, el proyecto no solo se ha centrado en el desarrollo del código, sino en la puesta en producción de este. Se ha contenerizado la aplicación, para automatizar la replicación del sistema en caso de que el CEDEX decidiera utilizar la aplicación en sus servidores, y se han creado entornos de producción para la base de datos, API y página web, para permitir a los usuarios del CEDEX probar la aplicación mediante internet. 9.2 Trabajo futuro De cara al futuro, el proyecto podría ampliarse y mejorarse de diferentes maneras. Algunas de las posibles ampliaciones planteadas son: 103 ●Añadir más estadísticas: Uno de los objetivos futuros sería implementar más tipos de estadísticas, de manera que se pueda extraer más información sobre los datos contenidos en la aplicación. Debido a que se trata de un proyecto con fecha de finalización, se escogieron las estadísticas que más valor aportan al proyecto, pero si se tratara de un proyecto con continuidad en el tiempo, se trabajaría en añadir más estadísticas, con el objetivo de dar más valor a los datos existentes. ●Añadir filtros predefinidos para la búsqueda de expedientes: Sería muy interesante poder analizar los filtros que más utilizan los usuarios al buscar expedientes, para ver si se podrían implementar filtros predefinidos, con el objetivo de ahorrar tiempo a los usuarios y que no tengan que rellenar todos los campos que necesitan todas las veces. Pero para esta funcionalidad se necesitan datos continuados en el tiempo, de manera que se pueden obtener patrones entre multitud de usuarios. De todas maneras, es una ampliación que aportaría mucho valor a los usuarios de la aplicación. ●Añadir gestión de usuarios: Actualmente, la gestión de los usuarios se realiza de manera manual en la base de datos, ya que no se especificó ningún requisito en las reuniones con el cliente. Pero sería útil la posibilidad de gestionar los usuarios de la aplicación de manera gráfica. Probablemente se optaría por implementar un sistema de roles, y dotar a los administradores de una vista adicional que les permita interactuar con esta funcionalidad. ●Añadir página de usuario: de la misma manera que sería posible añadir una gestión de usuarios, se podría implementar una página dedicada a la información del mismo, permitiéndole actualizar algún campo como el correo y la contraseña, o mostrar información sobre su uso de la aplicación (fecha de registro, número de expedientes creados, etc). 104 ●Más personalización de la interfaz: Aumentar el grado de personalización de la interfaz podría hacer el uso de la aplicación más ameno y agradable. Esto se podría conseguir mediante el uso de temas, que cambien la apariencia visual de la aplicación, o guardando información sobre cómo le gusta distribuir las columnas de las tablas que existen en la aplicación, para no tener que moverlas cada vez que se actualice la interfaz. ●Añadir lógica de designaciones: Por último, existe la posibilidad de añadir a la base de datos las posibles designaciones de los productos. Existe una lógica asociada a las designaciones, pero se decidió no implementarla en el proyecto, ya que se le dió más importancia al resto de las funcionalidades existentes de la aplicación debido a las limitaciones de tiempo. 105 Bibliografía [1] CEDEX: disponible en https://www.cedex.es/ [2] Desarrollo ágil de software - Wikipedia: disponible en https://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software [3] Firebase: disponible en https://firebase.google.com/?hl=es [4] Supabase: disponible en https://supabase.com/ [5] PocketBase: disponible en https://pocketbase.io/ [6] HTML: disponible en https://developer.mozilla.org/es/docs/Glossary/HTML [7] CSS: disponible en https://developer.mozilla.org/es/docs/Glossary/CSS [8] Tailwind CSS: disponible en https://tailwindcss.com/ [9] JavaScript: disponible en https://developer.mozilla.org/es/docs/Web/JavaScript [10] TypeScript: disponible en https://www.typescriptlang.org/ [11] DaisyUI: disponible en https://daisyui.com/ [12] AG Grid: disponible en https://www.ag-grid.com/ [13] Chart.js: disponible en https://www.chartjs.org/ [14] Svelte: disponible en https://svelte.dev/ [15] SvelteKit: disponible en https://kit.svelte.dev/ [16] PHP: disponible en https://www.php.net/manual/es/intro-whatis.php [17] Laravel: disponible en https://laravel.com/docs/11.x/ [18] PostgreSQL: disponible en https://www.postgresql.org/ 106 [19] MongoDB: disponible en https://www.mongodb.com/ [20] Docker: disponible en https://www.docker.com/ [21] Amazon Web Services: disponible en https://aws.amazon.com/es/what-is-aws/ [22] MongoDB Atlas: disponible en https://www.mongodb.com/products/platform/atlas-database [23] Render: disponible en https://render.com/ [24] Visual Studio Code: disponible en https://code.visualstudio.com/ [25] GitHub: disponible en https://github.com/ [26] DBeaver: disponible en https://dbeaver.io/about/ [27] MongoDB Compass: disponible en https://www.mongodb.com/products/tools/compass [28] Postman: disponible en https://www.postman.com/ [29] REST, explicada por Red Hat: disponible en https://www.redhat.com/en/topics/api/what-is-a-rest-api 107