Grado en Ingenier´ıa Inform´ atica
Trabajo de Final de Grado
APLICACI ´ ON WEB PARA GESTIONAR EL CONTROL DE PRODUCCI ´ ON DE
UNA EMPRESA CER ´ AMICA
Autor:
Iv´an Mu˜noz L´opez
Supervisor:
Alejandro S´anchez-Camacho L´opez Tutor acad´emico:
Jos´e Luis Llopis Borr´as
Fecha de lectura: 16 de Septiembre de 2020 Curso acad´emico 2019/2020
Resumen
En el presente documento se describe el an´alisis, planificaci´on, dise˜no y la implementaci´on del proyecto de creaci´on de una aplicaci´on web orientada al control de producci´on de un laboratorio de una empresa cer´amica. La memoria presentada es parte del desarrollo del Trabajo de Fin de Grado del itinerario de Tecnolog´ıas de la Informaci´on y las Comunicaciones del Grado de Ingenier´ıa Inform´atica de la Universitat Jaume I.
El proyecto consisti´o en la renovaci´on completa de una aplicaci´on utilizada para el control de varios indicadores en el proceso de fabricaci´on de material cer´amico. Ya se contaba con una aplicaci´on anteriormente para este prop´osito, pero debido a las tecnolog´ıas empleadas esta se estaba quedando obsoleta. Por ello se ha optado por Node.js o el framework Angular entre otros como nuevas tecnolog´ıas para su desarrollo.
Gracias a la aplicaci´on implementada el trabajo del personal de laboratorio se ver´a simpli- ficado, ya que aporta muchas facilidades y mejoras respecto a la aplicaci´on anterior.
Palabras clave
Maven, Cliente-Servidor, Aplicaci´on Web, Spring-Boot, Java, Angular, Node.js, MySQL.
Keywords
Maven, Client-Server, Web Application, Spring-Boot, Java, Angular, Node.js, MySQL.
´ Indice general
1. Introducci´on 11
1.1. Contexto y motivaci´on del proyecto . . . 11
1.2. Objetivos del proyecto . . . 11
1.3. Alcance . . . 12
1.4. Descripci´on del proyecto . . . 13
1.4.1. Tecnolog´ıa empleada . . . 13
1.5. Estructura de la memoria . . . 14
2. Planificaci´on del proyecto 15 2.1. Metodolog´ıa . . . 15
2.2. Planificaci´on . . . 15
2.3. Estimaci´on de recursos y costes del proyecto . . . 17
2.4. Seguimiento del proyecto . . . 18
3. An´alisis y dise˜no del sistema 21 3.1. An´alisis del sistema . . . 21
3.2. Dise˜no de la arquitectura del sistema . . . 23
3.2.1. Dise˜no de la base de datos . . . 25
3.3. Dise˜no de la interfaz . . . 26
4. Implementaci´on y pruebas 35 4.1. Detalles de implementaci´on . . . 35 4.1.1. Estructura del proyecto . . . 35 4.2. Verificaci´on y validaci´on . . . 55
5. Conclusiones 57
5.1. ´Ambito formativo . . . 57 5.2. ´Ambito profesional . . . 57 5.3. ´Ambito personal . . . 58
6. Biblograf´ıa 59
´ Indice de figuras
2.1. Metodolog´ıa en cascada utilizada en el proyecto . . . 16
2.2. Planificaci´on temporal . . . 19
3.1. Estructura de un control . . . 22
3.2. Estructura Modelo Vista Controlador . . . 24
3.3. Base de datos MySQL . . . 27
3.4. Men´u lateral de la aplicaci´on web. . . 28
3.5. Maestro de medidas. . . 30
3.6. Ventana modificar medida. . . 31
3.7. Desplegable selecci´on de unidad en el maestro indicadores. . . 32
3.8. Cabecera de una secci´on . . . 32
3.9. Lista de indicadores de una secci´on . . . 33
4.1. Estructura general del back-end . . . 37
4.2. M´odulo de maestros del back-end . . . 37
4.3. Estructura del maestro de ´Areas del back-end . . . 38
4.4. Dominio de ´Areas del back-end . . . 40
4.5. Estructura general del front-end . . . 47
4.6. Estructura del maestro de medidas del front-end . . . 48
4.7. Captura del buscador de medidas de la aplicaci´on web. . . 51
4.8. Captura del detalle de una medida de la aplicaci´on web. . . 51
4.9. Captura del desplegable del maestro de indicadores en la aplicaci´on web. . . 54
4.10. Captura del configurador de secciones en la aplicaci´on web. . . 55
4.11. Captura de la cabecera del configurador de secciones en la aplicaci´on web. . . 56
´ Indice de cuadros
2.1. Costes del software y hardware . . . 18
2.2. Costes humanos . . . 18
2.3. Costes indirectos . . . 18
2.4. Costes totales . . . 19
3.1. Casos de uso . . . 23
´ Indice de listados
4.1. Control de ´Areas del back-end . . . 39
4.2. M´anager de ´Areas del back-end . . . 41
4.3. M´etodos del controlador de un control del back-end . . . 42
4.4. M´etodo principal del m´anager del Control del back-end . . . 43
4.5. M´etodo organizador de ´areas y de secciones del m´anager del control . . . 43
4.6. Empleo de streams en la clase m´anager de un Control . . . 44
4.7. M´etodo para modificar las medidas por iteraci´on . . . 44
4.8. Deserializado de medidas desde la base de datos . . . 45
4.9. Serializador ad hoc para las medidas del control . . . 45
4.10. Funci´on para modificar los indicadores de referencia. . . 46
4.11. Formulario del maestro medidas. . . 48
4.12. Modelo del maestro medidas del front-end. . . 48
4.13. Servicio del maestro de medidas del front-end . . . 49
4.14. Grid del maestro medidas del front-end. . . 50
4.15. Fichero HTML del detalle de una medida del front-end . . . 52
4.16. M´etodo para cargar las unidades del desplegable de un indicador del front-end. . 53
4.17. M´etodos del configurador de secciones en el front-end. . . 54
Cap´ıtulo 1
Introducci´ on
1.1. Contexto y motivaci´ on del proyecto
El proyecto detallado en este documento se basa en el desarrollo de una aplicaci´on web orientada al control de producci´on de una empresa cer´amica. Este proyecto se realiz´o como resultado de las pr´acticas externas del Grado en Ingenier´ıa Inform´atica.
La principal motivaci´on que dio lugar a este prop´osito fue la renovaci´on de una aplicaci´on ya existente que cumpl´ıa anteriormente con este cometido, pero debido a las tecnolog´ıas empleadas qued´o obsoleta y se opt´o por una implementaci´on completa de una nueva aplicaci´on.
1.2. Objetivos del proyecto
El principal objetivo de este proyecto se centr´o en mejorar la usabilidad y simplificar la aplicaci´on con respecto a la anterior, y as´ı mismo reducir la complejidad de la misma y fa- cilitar ciertas gestiones. Adem´as de este objetivo principal podemos nombrar otros de menor importancia pero que tambi´en se han tenido en cuenta:
Rehacer la aplicaci´on con tecnolog´ıas actuales. Puesto que la anterior estaba desarrollada en Java base y AngularJS. La nueva, sin embargo, cuenta con Spring-Boot, Node.js y Angular.
Modificar el aspecto visual de la nueva aplicaci´on, consiguiendo de esta forma que se vea m´as actual, sencilla y usable:
Simplificar la configuraci´on de nuevos controles de laboratorio. Mediante la utilizaci´on de men´us desplegables podemos a˜nadir varios elementos a un control sin la necesidad de insertar cada elemento uno a uno y con la posibilidad de hacerlo en varios pasos.
Simplificar el men´u haci´endolo ocultable y desplegable para que el acceso a ciertas partes de la aplicaci´on sea m´as r´apido, intuitivo y menos invasivo.
Facilitar la comprensi´on de ciertos componentes haci´endolos gen´ericos de esta manera su uso se puede extender a diversas partes de la aplicaci´on. En este caso los compo- nentes hacen referencia a diversos elementos gr´aficos como: botones, desplegables y pesta˜nas.
Utilizar iconos para diferenciar funciones y distintos apartados.
Emplear una distribuci´on responsiva, es decir, que la aplicaci´on se pueda visualizar correctamente tanto en un monitor como en una pantalla de una tableta u otro dispositivo m´ovil.
Realizar modificaciones para simplificar parte de la funcionalidad: como por ejemplo la creaci´on de un control completo, es decir, a˜nadir ciertos indicadores agrupados bajo unas etiquetas.
Facilitar la creaci´on de controles mediante el uso de plantillas que indica al sistema los indicadores, las medidas, las unidades y los valores de un control de producci´on.
Reducir la cantidad de clics para configurar un maestro, como puede ser un indicador.
Agrupar el men´u de controles en una barra lateral.
1.3. Alcance
El alcance de este proyecto abarc´o la implementaci´on completa de una nueva aplicaci´on basada en una anterior que qued´o obsoleta. Para detallar m´as este aspecto del plan se ha dividido en tres apartados: organizativo, funcional e inform´atico.
El alcance organizativo abarca el personal del laboratorio que realiza la supervisi´on de la producci´on de materiales cer´amicos, puesto que son ellos los que la emplear´an con el objetivo de realizar un seguimiento de ciertos valores.
El alcance funcional es muy parecido al de la aplicaci´on anterior, sin embargo se ha simpli- ficado parte de estas funcionalidades:
Creaci´on de controles con un fin determinado.
Configuraci´on con total libertad de medidas, unidades e indicadores.
Acceso a controles creados y al configurador de nuevos controles.
Introducci´on de valores en un control de producci´on.
Finalmente, el alcance inform´atico es limitado puesto que basta con emplear cualquier tipo de navegador web, ya sea desde un ordenador de sobremesa, port´atil, tableta o tel´efono inteligente.
1.4. Descripci´ on del proyecto
En esta secci´on se aporta informaci´on adicional sobre el proyecto y las tecnolog´ıas que se van a usar en el mismo, as´ı como una descripci´on de la situaci´on inicial de la que parte.
Este proyecto se ha basado en el desarrollo de una aplicaci´on web encargada de gestionar y supervisar ciertos indicadores de la producci´on de azulejos de una empresa de este sector. Esta labor ha sido realizada hasta ahora por una aplicaci´on con el mismo cometido que ha quedado desfasada. La parte m´as importante de esta idea es un control, es decir, una forma de agrupar ciertos indicadores en una estructura determinada. El esqueleto de un control es el siguiente:
Areas: Un control suele tener una o dos ´´ areas que son una agrupaci´on de ciertas secciones.
Secciones: Una secci´on contiene iteraciones, aunque la gran mayor´ıa solo tiene una, puede darse el caso de tener varias, por ejemplo m´ultiples temperaturas.
Iteraciones: Una iteraci´on contiene varios indicadores.
Indicador: Un indicador es una entidad de control, como puede ser temperatura o presi´on, adem´as contiene una o m´as medidas.
Medidas: Una medida contiene el valor a controlar por los operadores de la aplicaci´on adem´as de una unidad asociada a dicho valor.
En cuanto a la navegaci´on de la propia aplicaci´on se ha decidi´o cambiar por completo su funcionamiento. Antes se pod´ıa acceder a un control desde una pesta˜na en la cabecera y se desplegaba cada apartado haciendo clic sobre ´el. Ahora se ha optado por una barra de navegaci´on lateral con men´us que permite acceder a toda la funcionalidad.
La herramienta de configuraci´on se ha modificado de tal manera que se hace por partes, es decir, para crear un control desde cero antes se han de crear todos sus componentes: ´areas, secciones, indicadores, medidas y unidades. O si se desea usar componentes que ya existen, simplemente se pueden agregarlos mediante un men´u desplegable.
Adem´as se ha incluido una nueva funcionalidad en la que a partir de una plantilla se puede obtener un control con todos sus indicadores correctamente ordenados y con todas sus medidas.
1.4.1. Tecnolog´ıa empleada
Las tecnolog´ıas empleadas en este plan deben ser diferenciadas en dos grandes bloques, el primero de ellos es el back-end, el encargado de interconectar a la base de datos con el servido;
y el front-end, cuyo cometido es de visualizar la informaci´on del lado cliente y permite a los usuarios interactuar con la aplicaci´on web.
Back-end: la parte servidor se desarroll´o en el lenguaje de programaci´on Java[1], en concreto en su versi´on 13. Es un lenguaje orientado a objetos e independiente de la plataforma hardware donde se desarrolla. Adem´as, se us´o Spring-Boot[2] una herramienta que naci´o con la finalidad
de simplificar el desarrollo de aplicaciones. El sistema de gesti´on de base de datos utilizado es MySQL[5], es un sistema relacional de c´odigo abierto con un modelo cliente-servidor. Tambi´en se usa Hibernate[6], es una herramienta de mapeo objeto-relacional que facilita el mapeo de atributos en una base de datos tradicional y el modelo de objetos de la aplicaci´on, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones.
Front-end: la parte del cliente se desarrollo en el entorno de ejecuci´on Node.js. En concreto se utiliz´o Angular versi´on 8.2.5, adem´as se ha utilizado la biblioteca de estilos Material-Design.
Se han escogido estas tecnolog´ıas porque son las m´as habituales en la empresa durante el desarrollo de una aplicaci´on web como esta.
1.5. Estructura de la memoria
La memoria se encuentra divida en cinco cap´ıtulos principales.
Para empezar, en el primer cap´ıtulo se introduce el proyecto, por ello se definen los siguientes aspectos: el contexto y la motivaci´on del mismo, objetivos y subojetivos, el alcance funcional, organizativo e inform´atico, la descripci´on del mismo y las tecnolog´ıas utilizadas en sus diferentes partes y por ´ultimo esta misma estructura.
En el segundo cap´ıtulo encontramos la planificaci´on del proyecto. Se encuentra divido en cuatro partes: la metodolog´ıa utilizada, la planificaci´on, los recursos y costes del proyecto esti- mados y el seguimiento del plan inicial que se ha llevado a cabo.
M´as adelante, en el tercer cap´ıtulo, se analiza el sistema, su arquitectura y el dise˜no visual de su interfaz de usuario.
En el cuarto cap´ıtulo se explica con detalle toda la labor de implementaci´on del sistema as´ı como la verificaci´on y validaci´on del mismo.
Por ´ultimo, en el quinto cap´ıtulo se explican las conclusiones desde diferentes puntos de vista.
Cap´ıtulo 2
Planificaci´ on del proyecto
2.1. Metodolog´ıa
La metodolog´ıa empleada en este proyecto es la que suele usar la empresa para todos sus trabajos, una metodolog´ıa en cascada, como se puede ver en la figura 2.1. La forma de trabajo de esta metodolog´ıa es secuencial y destaca por la definici´on de las fases del proyecto a principio del mismo. Aunque en este proyecto en concreto alguna de las fases sufri´o alg´un tipo de modificaci´on debido a decisiones de implementaci´on que se tomaron sobre la marcha.
La empresa suele utilizar este tipo de metodolog´ıa debido a su simplicidad y eficacia en proyectos de tama˜no peque˜no o mediano. Es muy ´util para ir mejorando la aplicaci´on una vez se ha conseguido llegar a las fases finales, puesto que permite volver a pasar por las primeras fases de nuevo para mejorar lo realizado anteriormente.
Las etapas que forman este tipo de metodolog´ıa son cinco: an´alisis, dise˜no, implementaci´on, pruebas y mantenimiento. Y ,como podemos ver en la figura 2.1, despu´es de cada etapa se puede volver a cualquiera de las anteriores.
2.2. Planificaci´ on
La planificaci´on del proyecto est´a compuesta por pasos que se siguen de forma secuencial.
A continuaci´on detallar´e los pasos que se siguieron.
En el primer paso se analizaron todas las funcionalidades de la aplicaci´on antigua que se deb´ıan incluir en esta. Adem´as, desde el principio se ten´ıa claro las modificaciones necesarias para mejorar parte de la funcionalidad antigua, as´ı como parte del aspecto visual a mejorar.
En el segundo paso se desglos´o la aplicaci´on en partes, como pueden ser maestros, el confi- gurar de un control de producci´on y los mapeadores para poder asignar diferentes apartados al personal de la empresa y que cada uno pudiera centrarse en el m´odulo que se le asign´o. En este
Figura 2.1: Metodolog´ıa en cascada utilizada en el proyecto
caso en particular empezamos en el proyecto tres personas y posteriormente se uni´o una m´as.
En las primeras semanas tuve que realizar labor en la parte del servidor mientras que los otros compa˜neros implementaban tambi´en la parte del cliente.
El tercer paso consisti´o en la implementaci´on de todas las partes definidas en el dise˜no. Se comenz´o por mi parte por el desarrollo del back-end. La configuraci´on del proyecto Maven[7], una herramienta de software para la gesti´on y construcci´on de proyectos Java, se me otorg´o desde un inicio. Este proyecto ten´ıa el mismo esqueleto que el que usan en la empresa para la mayor´ıa de sus proyectos.
En el cuarto paso se realizan las labores de estimaci´on y valoraci´on del progreso realizado hasta ese momento, para ello hay reuniones semanales en las que se corrobora la correcta funcionalidad implementada hasta ese momento.
La quinta fase en este caso al desarrollar solo un m´odulo del proyecto sin llegar este a estar acabado del todo no se ha podido lanzar la aplicaci´on con toda su funcionalidad pero s´ı la parte desarrollada. As´ı pues se pudo probar el m´odulo principal del configurador de secciones y varios maestros.
Finalmente, en la fase de mantenimiento se han corregido varios aspectos que no funcionaban correctamente despu´es de probar el m´odulo de secciones. Los maestros por otro lado funcionaron como se esperaba.
2.3. Estimaci´ on de recursos y costes del proyecto
Para realizar la estimaci´on de recursos consideramos tres tipos: recursos humanos, materiales e indirectos.
Recursos humanos: en este caso el proyecto ha sido realizado por cuatro personas, tres de ellas desde el inicio y una cuarta se incorpor´o al mes. Cada uno de los miembros ha estado realizando m´odulos independientes en la fase apropiada de su elaboraci´on. Al principio del mismo todos realizamos labores del back-end y una vez estuvo el grueso completado de esta parte se empez´o el desarrollo del front-end conjuntamente.
EL autor de esta memoria realiz´o labores de desarrollo y dise˜no de software, tanto en la parte servidor como en la cliente. Aunque se realiz´o mucho m´as desarrollo en la parte del back-end que del front-end, puesto que ten´ıa m´as experiencia y habilidad de implementa- ci´on con Java y Spring-Boot[2] que con Typescript[8] y Angular[4].
Recursos materiales: en esta secci´on hay que remarcar la inclusi´on del software junto con el hardware empleado.
El hardware utilizado en concreto ha sido un ordenador de sobremesa Lenovo de la oficina de la empresa Integra Consultores, junto con perif´ericos de la misma marca.
El software empleado en el desarrollo en la parte servidor ha sido el IDE IntelliJ IDEA.
Por otro lado, el utilizado en la parte cliente ha sido el IDE Visual Studio Code. Para la visualizaci´on de la base de datos MySQL se ha utilizado el programa Navicat[9], es un administrador gr´afico de base de datos que cuenta con un explorador como interfaz gr´afica de usuario soportando m´ultiples conexiones para bases de datos locales y remotas.
Y como herramienta de gesti´on de c´odigo se ha usado Atlassian Bitbucket[10], un servicio de alojamiento basado en web, para los proyectos que utilizan el sistema de control de versiones Mercurial y Git. As´ı mismo para gestionar las subidas y descargas de c´odigo se ha dispuesto del programa SourceTree[11], este programa simplifica la forma con la que se interact´ua con los repositorios.
Recursos indirectos: estos medios fueron los dispuestos para crear el entorno de trabajo en la empresa como son: el alquiler del local, acondicionamiento del mismo, recursos como muebles y herramientas y por ´ultimo el consumo de agua y electricidad del local.
Continuando con los costes del proyecto se van a presentar unas tablas definiendo los costes del software, los recursos humanos, los recursos indirectos y la suma total de costes. Todos estos costes han sido calculados aplicando un porcentaje de uso o tiempo dedicado con ellos al coste real.
En la tabla 2.1 podemos observar los costes del software y del hardware empleado durante el desarrollo de la aplicaci´on web.
En la tabla 2.2 podemos ver los costes humanos asociados al desarrollo de la aplicaci´on web.
Hay que destacar que el precio por hora es el habitual de la empresa para programadores junior como es el caso.
Recurso Coste
IntelliJ IDEA Licencia Gratuita Visual Studio Code Licencia Gratuita SourceTree Licencia Gratuita Atlassian Bitbucket 5,00 e
Navicat 120,00 e
Ordenador 25,00 e
Monitor 10,00 e
Perif´ericos 3,00 e
Total 163,00 e
Cuadro 2.1: Costes del software y hardware
Recurso Horas Coste Coste Total
Desarrollo, dise˜no y an´alisis 300 8,50e 2.550,00 e Cuadro 2.2: Costes humanos
En la tabla 2.3 se puede ver la estimaci´on de los costes indirectos en funci´on del tiempo aprovechado en la oficina que fue todo el tiempo de desarrollo.
Recurso Coste
Alquiler 150,00 e
Mobiliario 125,00 e Consumo de agua 15,00 e Consumo el´ectrico 45,00 e
Limpieza 30,00 e
Total 365,00 e
Cuadro 2.3: Costes indirectos
Y por ´ultimo, en la tabla 2.4 podemos ver la suma de todos los costes.
2.4. Seguimiento del proyecto
Durante las primeras semanas se realizaron m´ultiples reuniones cada semana. Esto propici´o que los detalles y requisitos del sistema quedar´an claros antes de comenzar con el grueso de la implementaci´on. M´as adelante, seg´un se iban acabando m´odulos o partes de la aplicaci´on final, se realizaba una reuni´on para asegurarnos que se cumpl´ıan los requisitos de esa parte (ver la planificaci´on de la figura 2.2). Aunque cabe remarcar que el diagrama sufri´o alguna modificaci´on de fechas debido a los detalles de implementaci´on que fueron surgiendo durante el desarrollo del proyecto.
En la reuniones de las primeras semanas se me ense˜n´o el esqueleto base del proyecto Maven[7]
Recurso Coste Total Software y Hardware 163,00 e
Humanos 2550,00e
Indirectos 365,00 e
Total 3078,00e
Cuadro 2.4: Costes totales
Figura 2.2: Planificaci´on temporal
con el que la empresa suele trabajar, as´ı como la divisi´on de paquetes y su funcionalidad dentro del mismo. En las siguientes semanas se me fueron encargando desarrollar funcionalidades del back-end, una vez acabado era revisado por el supervisor. Hay que a˜nadir que en general se mantuvo una reuni´on semanal para valorar el progreso del proyecto y decidir los siguientes pasos a tomar.
Debido a la situaci´on de emergencia sanitaria provocada por el virus COVID-19 se opt´o por la modalidad de teletrabajo a partir del 23/03/2020. Justo antes de comenzar el teletrabajo se mantuvo una reuni´on en l´ınea para acabar de configurar todo lo necesario para realizar el trabajo de forma telem´atica. Adem´as coincidi´o este periodo con el comienzo por mi parte del desarrollo del front-end en Angular. Para ello de nuevo se mantuvo una reuni´on (a partir de este momento todas en l´ınea) para exponer la estructura del proyecto de la parte cliente. A partir de aqu´ı la forma de trabajo y revisi´on del mismo fue muy similar a la anterior, pues semanalmente se me informaban de mis tareas y una vez finalizadas se revisaban y se empezaban con otras.
Por ´ultimo, durante la ´ultima semana se realizaron labores de revisi´on del trabajo hecho hasta ese momento as´ı como la mejora y correcci´on de algunos detalles de implementaci´on y desarrollo.
Cap´ıtulo 3
An´ alisis y dise˜ no del sistema
3.1. An´ alisis del sistema
En este apartado se describen los requisitos funcionales del sistema as´ı como los casos de uso.
Para una mejor comprensi´on de estos requisitos se realizar´a un divisi´on por m´odulos.
Visor de controles: este m´odulo se emplea para el visionado de un control ya terminado, para ello es necesario disponer de una plantilla creada. En esta plantilla se encuentran todos los indicadores y par´ametros necesarios a incluir en el control, para ello la parte servidor se encargar de, a partir de una referencia, realizar una copia de indicadores, medidas y unidades a un control. Una vez esto se ha realizado tambi´en se debe de ordenar de una determinada manera, siendo esta la siguiente: ´area, secci´on, iteraci´on, indicador, medidas y unidad. Esta estructura se puede ver en la figura 3.1.
Modificaci´on de cabecera: cada control dispone de una cabecera situada antes de los indicadores en la parte superior de la p´agina, como se puede ver en la parte superior de la figura 3.1, esta cabecera ha de ser siempre visible y se debe poder editar en cualquier momento.
Configurador: es el apartado que dispone de mayor funcionalidad pues desde ´el se crean todos los componentes de un control (´areas, secciones, iteraciones, indicadores, medidas y unidades) y la creaci´on de controles en s´ı mismos. Tambi´en se puede ir a˜nadiendo m´odulos a un control de producci´on para formarlo desde cero. Hay que a˜nadir que es en todo momento modificable y se pueden eliminar o a˜nadir nuevas partes. Para explicarlo mejor se ha divido el configurador en tres partes:
Maestros: los maestros son las piezas que forman un control, cada uno de ellos es una entidad propia en la base de datos, por ello cada maestro tiene la funcionalidad b´asica de crear, modificar o borrar.
Generaci´on de plantillas: es la funcionalidad encargada de fabricar el esqueleto de un control, una vez se configuren todos sus m´odulos con partes ya existentes se puede
Figura 3.1: Estructura de un control
generar la vista del control para comenzar a realizar el seguimiento de los indicadores.
Editor: como se ha comentado anteriormente todos los m´odulos o controles creados pueden ser modificados, as´ı como su orden, pues ciertas partes, como son los indi- cadores, contienen medidas que seg´un su orden se mostrar´an de una determinada forma.
Iteraciones: una iteraci´on contiene varios indicadores.
Indicador: un indicador es una entidad de control, como puede ser temperatura o presi´on, adem´as contiene una o m´as medidas.
Medidas: una medida contiene el valor a controlar por los operadores de la aplicaci´on adem´as de una unidad asociada a este valor.
En este ´ultimo apartado se definen los casos de uso de la aplicaci´on web as´ı como los actores que la emplearan en cada ocasi´on. Hay que remarcar que las situaciones para emplear el sistema
est´an ´ıntimamente relacionadas con la funcionalidad descrita en la secci´on ??. Se ha optado por la tabla 3.1 para relacionar los casos de uso con los roles de usuario.
Casos de uso Rol de usuario
Iniciar sesi´on Todos los usuarios
Control de indicadores dentro de un rango Personal de laboratorio Creaci´on de ´areas, secciones, indicadores, medidas y unidades Personal de laboratorio
Revisi´on de temperaturas Operario de maquinaria de producci´on
Revisi´on de presi´on Operario de maquinaria de producci´on
Establecer rangos de control Personal de laboratorio
Creaci´on de plantillas de control Personal de laboratorio
Asignar roles Administrador
Gesti´on de usuarios Administrador
Cuadro 3.1: Casos de uso
3.2. Dise˜ no de la arquitectura del sistema
En este apartado se va a describir el dise˜no de la arquitectura del sistema. El esqueleto es el habitual en una aplicaci´on cliente-servidor como esta. Existen dos m´odulos principales, el primero de ellos el servidor se encarga de conectar con la base de datos y con el otro m´odulo,
´
este es el encargado de dibujar los datos de la aplicaci´on e interaccionar con el usuario.
Este tipo de sistemas tiene una arquitectura Modelo Vista Controlador[12], como se puede ver en la figura 3.2. ´Este es un estilo de arquitectura de software que separa los datos de una aplicaci´on, la interfaz de usuario, y la l´ogica de control en tres componentes distintos.
El modelo contiene una representaci´on de los datos que maneja el sistema, su l´ogica de negocio, y sus mecanismos de persistencia.
La vista, o interfaz de usuario, que compone la informaci´on que se env´ıa al cliente y los mecanismos de interacci´on con ´este.
El controlador, act´ua como intermediario entre el modelo y la vista, gestionando el flujo de informaci´on entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.
Visionando el patr´on Modelo Vista Controlador desde la perspectiva de la empresa hay que destacar que para todos los proyectos se utilizan dos m´odulos.
El primero de ellos representa la parte servidor. Est´a desarrollado en Java 13 adem´as del uso del framework Spring-Boot. Se encarga de la conexi´on con la base de datos mediante objetos JSON[15], este tipo de formato es de lectura y escritura simple para los humanos mientras que para las m´aquinas es simple interpretarlo y generarlo. Cada representaci´on o tabla del almac´en de datos tiene un retrato muy similar en este m´odulo. Estas representaciones se llaman maestros.
Su estructura es la siguiente:
Figura 3.2: Estructura Modelo Vista Controlador
Dominios: directorio de los datos, suele contener varios ficheros para el manejo de los mismos, su intercambio y su recepci´on desde el front-end
Entidades: son una copia de las tablas de la base de datos en la aplicaci´on. Se utilizan para la gesti´on de los datos.
Objectos de acceso a los datos: son interfaces que se usan para relacionarse con la base de datos. Su funci´on principal es obtener y almacenar los datos.
Objetos de transporte de datos: se utilizan para el intercambio de informaci´on con la parte cliente.
Managers: en esta parte se encuentran todas las operaciones que se realizan a los datos.
Normalmente se manipulan los objetos entidad y se crean a partir de ellos los objetos de transporte de datos para su posterior env´ıo.
Mapeadores: se encargan de transformar un objeto entidad en un objeto de transporte.
El segundo de ellos representa la capa de representaci´on de los datos, aunque tambi´en se
utiliza en ciertas partes como capa de control. Est´a desarrollado en el lenguaje de programaci´on Typescript (subconjunto de Javascript) integrado con Node.js[13], que es un entorno en tiempo de ejecuci´on multiplataforma, de c´odigo abierto, para la capa del servidor basado en el lenguaje de programaci´on JavaScript y as´ıncrono. Adem´as se ha utilizado el framework Angular, en su versi´on 8.
El proyecto desarrollado en Angular tiene un esqueleto muy diverso y amplio separando cada vista en componentes muy reducidos. La estructura del proyecto ser´ıa la siguiente:
Componentes: pueden ser gen´ericos, es decir, est´an disponibles para todos los proyectos y se suelen utilizar en la mayor´ıa de ellos. O bien pueden estar creados a prop´osito para un proyecto en concreto. En este caso los componentes son partes de una vista que se extrae de ella para simplificar su funcionamiento.
M´odulos: es la representaci´on de los datos en el front-end, aqu´ı se encuentra la informaci´on de cada maestro. Adem´as realizan las labores de mapeado con los datos que recibe del back-end.
Servicios: sirven como flujo de la informaci´on entre la parte cliente y la servidor. En este apartado se localizan las llamadas al controlador del back-end y se recogen sus resultados.
Vistas: se utilizan para mostrar la informaci´on deseada de la manera apropiada. Este apartado suele contener un fichero HTML, un archivo Typescript y opcionalmente un fichero de estilo CSS.
Formularios: en este apartado se encuentran los datos requeridos y su definici´on para ser recolectados.
3.2.1. Dise˜no de la base de datos
En este apartado se va a describir la base de datos utilizada durante este proyecto. Se han omitido algunas tablas de control de acceso y edici´on que no est´an relacionadas con la naturaleza del proyecto, adem´as de otras tablas referentes a otros m´odulos en los que no tuve participaci´on en ninguna parte de su proceso de implementaci´on.
Como se puede ver en la figura 3.3 existen nueve tablas y se pueden dividir en dos grandes grupos:
Maestros: en este apartado entran las tablas medidas, unidades, indicadores, secciones y
´
areas. Cada una de ellas representa unos datos que unidos formar´an un control. Contienen informaci´on para poder organizar los indicadores dentro de una estructura determinada, as´ı como mostrar y recoger valores. La tabla medidas se relaciona con las dem´as en la l´ogica de la aplicaci´on, tomando una referencia guardada en formato JSON de la tabla controles indicadores.
Configuradores: las tablas plantillas, plantillas indicadores, controles y controles indica- dores son las encargadas de agrupar los maestros dentro de una determinada estructura.
Por lo tanto la informaci´on que contiene son identificadores a la mayor´ıa de las tablas de maestros.
3.3. Dise˜ no de la interfaz
En esta secci´on se van a exponer los criterios de dise˜no utilizados en la elaboraci´on de la interfaz gr´afica de la aplicaci´on web. Para hacerlo de manera m´as sencilla se incluir´an capturas de la propia aplicaci´on para una mejor comprensi´on de los detalles. Aunque estas capturas se har´an solo de los m´odulos que realiz´o el autor de esta memoria.
Hay que destacar que no se realizaron bocetos previos, pues el aspecto visual desde un principio se analiz´o y decidi´o que iba a ser parecido al de otro proyecto de la empresa, por lo tanto se cogi´o esa base y sobre ella se realiz´o todo el trabajo de implementaci´on visual.
En la figura 3.4 podemos ver el men´u desplegable en el cual se puede observar el acceso a los maestros, al configurador de controles y a los propios controles.
Figura 3.3: Base de datos MySQL
Figura 3.4: Men´u lateral de la aplicaci´on web.
28
Poniendo el foco en los apartados desarrollado por el autor de esta memoria podemos ver en la figura 3.5 el maestro de medidas. Como se puede ver hay un grid o tabla paginada en la que se nos muestran todas las medidas existentes. Esta tabla es un componente gen´erico que se suele usar un muchos proyectos de la empresa. Como tambi´en lo es el bot´on de medida nueva que se puede observar. Si queremos realizar modificaciones sobre una medida simplemente hay que hacer clic sobre ella para ver la ventana detalle, como se puede observar en la figura 3.6.
Figura 3.5: Maestro de medidas.
30
Figura 3.6: Ventana modificar medida.
31
Como se puede observar en las figuras 3.4, 3.5 y 3.6 los colores predominantes son el blanco, el azul y el gris. Se reservan por otro lado el color rojo como es habitual para la acci´on eliminar, el color verde para crear y el color azul para la opci´on de modificar.
La mayor´ıa de los maestros son muy parecidos al de medidas, cada uno de ellos tiene una informaci´on requerida para su creaci´on, en el maestro indicadores se encuentra un men´u des- plegable para seleccionar una unidad como se ve en la figura 3.7. Por otro lado el configurador
Figura 3.7: Desplegable selecci´on de unidad en el maestro indicadores.
de secciones tiene m´as complejidad. En la figura 3.8 se pueden ver los datos de la cabecera de la secci´on en la que nos encontramos y en la figura 3.9 sus indicadores. Esto es as´ı puesto que dentro de una secci´on nos encontraremos con unos indicadores determinados y una lista que puede ser modificada. Estas listas a su vez contienen listas de medidas que pueden ser modifi- cadas, incluso su campo orden como se puede apreciar con los botones flecha de la figura 3.9.
Hay que remarcar que todos estos botones est´an creados a partir de iconos favicon[14], tambi´en conocidos como iconos de p´agina, es una peque˜na imagen asociada con una p´agina o sitio web en particular.
Figura 3.8: Cabecera de una secci´on
Figura 3.9: Lista de indicadores de una secci´on
Cap´ıtulo 4
Implementaci´ on y pruebas
En este cap´ıtulo se detalla la implementaci´on tanto de la parte back-end como la del front- end. Para ello veremos los requisitos de la aplicaci´on web y como estos se han modelado.
4.1. Detalles de implementaci´ on
En este cap´ıtulo inicial se presentan los detalles de implementaci´on, los patrones de progra- maci´on y las estrategias empleadas. Tambi´en se expondr´an las decisiones tomadas y los cambios que han surgido en el proyecto fruto de los problemas y dificultades que han ido surgiendo.
Para empezar se va a exponer la estructura del proyecto, tanto de la parte servidor como la cliente. Posteriormente se detallar´a la labor de programaci´on de los maestros y la parte del configurador de secciones.
4.1.1. Estructura del proyecto
Antes de entrar en detalle con la estructura de ficheros y carpetas de los proyectos hay que destacar que ambas estructuras siguen una l´ınea com´un que marca la empresa en la mayor´ıa de sus proyectos. Esto es as´ı ya que llevan tiempo incorporando mejoras y han optimizado esta estructura consiguiendo sencillez y potencia.
Back-end
El primer m´odulo desarrollado fue el back-end, fue implementado bajo el framework Spring- Boot que simplifica la estructura Modelo-Vista-Controlador. El lenguaje de programaci´on uti- lizado en esta parte fue Java en su versi´on 13 y se hizo servir Hibernate como herramienta de mapeo de datos entre la base de datos MySQL y los objetos que la propia aplicaci´on utiliza internamente.
Las labores de este m´odulo son diversas, siendo la m´as importante el intercambio de infor- maci´on entre la base de datos, en las que realiza labores de lectura y escritura, y el env´ıo y recepci´on de datos con el m´odulo front-end. El intercambio con la base de datos se realiza en formato JSON, sin embargo, con el m´odulo cliente se realiza mediante dos tipos de clases que se ver´an m´as adelante. Adem´as del manejo de los datos tambi´en realiza modificaciones sobre ellos, ya que es el m´odulo principal de la capa de control de datos.
Para mostrar la estructura de este componente se ver´a una visi´on general en la que se explicar´an los principales directorios y por otro lado el esqueleto completo de clases de un maestro en concreto, en este caso el de ´areas ya que todos los maestros tienen una estructura muy similar. Por ´ultimo se detallar´a la implementaci´on del configurador de controles as´ı como de varios m´etodos relevantes.
La estructura global de este m´odulo la podemos ver en la figura 4.1. Para exponer con m´as detalle cada directorio se expondr´a una lista de los mismos detallando los aspectos m´as relevantes y su principal labor.
Infra: contiene parte de la configuraci´on del proyecto as´ı como las clases administradoras que contienen todos los manager desarrollados durante el proyecto para poder ser usados en cualquier parte del mismo. Tambi´en se localizan en esta carpeta algunas clases abstrac- tas utilizadas en los mapeadores. Estas contienen elementos gen´ericos de cada tabla de la base de datos como son la fecha de creaci´on, la fecha de modificaci´on, el usuario creaci´on y el usuario modificaci´on, as´ı como el identificador interno que se utiliza para identificar una fila de la base de datos. En este caso los componentes son partes de una vista que se extrae de ella para simplificar su funcionamiento.
Archivos: este apartado no fue implementado por el autor de esta memoria pero para comprender el proyecto se dar´an algunos detalles sobre el mismo. Contiene un conversor de las clases l´ogicas de los controles a un documento, se utiliza para crear estos documentos a partir de un control.
Controles: en este directorio se realiza la gesti´on de un nuevo control a partir de una plantilla. Se realiza la copia de los indicadores y se crea la estructura definida por las ´areas y las secciones. A partir de los identificadores se completan todos los m´odulos necesarios para crear un control. En este apartado se realiza la organizaci´on mediante listas del esqueleto de un control. Es decir, se van ordenando los campos por indicador, iteraci´on, secci´on y finalmente por ´areas y de esta forma se estructuran adecuadamente.
Ensayos Clientes: este apartado no fue implementado por el autor de esta memoria. Este m´odulo fue el primero de varios que se implementar´an posteriormente, se utilizar´an para realizar distintos controles en funci´on de las distintas sedes de los clientes.
Maestros: en este apartado se encuentran todos los maestros del sistema, es decir los componentes que configuran un control, estas clases son representaciones de las tablas de la base de datos con las que se puede operar para realizar modificaciones sobre estos datos.
Plantillas: el m´odulo de plantillas es muy similar al de controles aunque es mucho m´as simple, pues la informaci´on de c´omo crear un control no est´a estructurada ni ordenada ya que de esto se encarga el m´odulo controles. Aqu´ı sin embargo se encuentran todos los componentes que debe tener un control sin estar organizados.
Figura 4.1: Estructura general del back-end
Una vez detallada la estructura general del proyecto vamos a exponer con m´as detalle el m´odulo de maestros, para ello se expondr´a detenidamente el maestro de ´Areas. Dado que todos los maestros son muy parecidos y las particularidades de cada uno son muy peque˜nas observando
´
este podemos entender como funcionan todos ellos. En la figura 4.2 se pueden ver todos los maestros, aunque el autor de esta memoria desarroll´o los siguientes: ´areas, indicadores, medidas, secciones y unidades.
Figura 4.2: M´odulo de maestros del back-end
En la figura 4.3 se pueden ver las distintas agrupaciones de clases de este m´odulo. Se des- cribir´a cada directorio por separado:
Controladores: estas clases son las encargadas del intercambio de informaci´on con el front- end para ello aqu´ı se definen los m´etodos que utilizar´a la parte cliente para realizar modificaciones e intercambio de datos. A su vez estos m´etodos llaman a otros definidos
Figura 4.3: Estructura del maestro de ´Areas del back-end
en el m´anager, este m´odulo se definir´a m´as adelante.
Por otro lado se utilizan anotaciones para diversas funciones, en el listing 4.1 podemos ver estas anotaciones y los m´etodos que contienen todos los maestros. Las anotaciones son las siguientes:
@RestController: esta anotaci´on es una forma simplificada de utilizar las anotaciones
@Controller y @ResponseBody, es una manera muy c´omoda de configurar nuestros servicios REST[16]. REST es una interfaz para conectar varios sistemas basados en el protocolo HTTP y nos sirve para obtener y generar datos y operaciones, devolviendo esos datos en formatos muy espec´ıficos, como XML y JSON. Despu´es de utilizarla cada m´etodo de esta clase serializa los objetos devueltos en objetos HttpResponse.
@RequestMapping: puede ser aplicada a nivel de clase o de m´etodo en este caso se est´a definiendo la ruta por la cual se va a llamar a los m´etodos de esta clase (api/v1/areas), es la forma por la que se asignan peticiones HTTP a m´etodos de un controlador MVC y REST.
@Autowired: esta potente anotaci´on realiza autom´aticamente la inyecci´on de los cam- pos que se quieran utilizar, en este caso de un AreaManager. Simplemente hay que tener cuidado de que no hayan dos beans que sean id´enticas puesto que no sabr´a cual de las dos utilizar.
@ResponseStatus: se usa para especificar la respuesta HTTP que se obtendr´a al uti- lizar este m´etodo.
@Get, @Post,@Put y @Delete: se utilizan para definir el tipo de petici´on HTTP del m´etodo.
Como vemos hay un total de cuatro m´etodos que son c´omunes para todos los maestros, aunque en alguno de ellos se incluye uno m´as para obtener un elemento por un identificador concreto. Estos m´etodos son: un tipo Get que obtiene una lista con todas las ´areas, un tipo Post para crear un ´area nueva, un tipo Put para modificar un ´area y uno del tipo Delete para eliminar un recurso.
@RestController
@RequestMapping(value = "/api/v1/areas") public class AreasController {
@Autowired
private AreasManager areasManager;
@ResponseStatus(OK)
@GetMapping
public List<AreaInfoDto> obtenerAreas() { return areasManager.obtenerAreas();
}
@ResponseStatus(CREATED)
@PostMapping
public AreaInfoDto crear
(@RequestBody @Valid AreaFormDto datos) { return areasManager.guardar(datos);
}
@ResponseStatus(CREATED)
@PutMapping(value = "{id:\\d+}")
public AreaInfoDto modificar(@PathVariable Long id,
@RequestBody @Valid AreaFormDto datos) { datos.setId(id);
return areasManager.guardar(datos);
}
@DeleteMapping(value = "{id:\\d+}")
public ResponseEntity borrar(@PathVariable Long id) { try {
areasManager.borrar(id);
return new ResponseEntity(OK);
} catch (NotFoundException e) {
return new ResponseEntity(NOT_FOUND);
} } }
Listing 4.1: Control de ´Areas del back-end
Dominios: esta agrupaci´on de clases son las transportadoras de informaci´on, cada una de ellas se utiliza para recibir, enviar o modificar datos. Se dividen en tres directorios como podemos ver en la figura 4.4:
DAOs o Data Access Object: son interfaces que extienden a una interfaz com´un para el proceso de copia desde la base de datos a los objetos del back-end para su manipulaci´on. En esta interfaz se definen m´etodos que implican inserciones, consultas o modificaciones.
DTOs o Data Transfer Object: son las clases de los objetos empleados en el inter- cambio de informaci´on entre el back-end y el front-end.
Siempre tenemos dos tipos, los que incluyen Form en su nombre son los objetos que nos devolver´a la parte cliente, en ellos se puede especificar mediante anotaciones que un campo no puede ser nulo con la anotaci´on @NotNull o que otro campo tiene que tener una longitud m´axima de 50 caracteres con la anotaci´on @Size("max=50") por ejemplo. El otro tipo son los que contienen info en su nombre. Estas son las clases que
la parte servidor env´ıa a la cliente, con la anotaci´on@Datade lombok se automatizan los setters y getters de todos los campos que definamos en la clase, por lo tanto nuestra clase queda muy limpia y su c´odigo se reduce a los campos que nos interesa enviar.
Entidades: las entidades son las clases que representan fielmente a las tablas de la base de datos y son de este tipo los objetos con los que vamos a operar principalmente en el back-end, ya que el proceso de manipulaci´on de los datos suele ser el siguiente, se obtiene un objeto Form del front-end se transforma a un objeto entidad para operar con ´el, una vez se ha operado sobre el objeto se transforma a un objeto de tipo Info para enviarlo de vuelta al cliente.
Figura 4.4: Dominio de ´Areas del back-end
M´anagers: estas clases se encargan de la transformaci´on de los datos, todos los procesos por los que pasan los datos ocurren en este m´odulo se puede decir que son el n´ucleo de control de datos del back-end.
Como se ha comentado anteriormente los controladores llaman a m´etodos de esta clase para que procesen unos datos y sean devueltos. Normalmente recibe objetos de tipo Form, los transforma a un objeto tipo Entidad para operar con ´el y env´ıa un objeto tipo Info con el resultado. Todas estas transformaciones de objetos las realiza la clase mapeadora que veremos a continuaci´on.
Por otro lado todos los m´anagers implementan una interfaz que contiene unos m´etodos que son utilizados en todos los proyectos de la empresa, estos m´etodos son:
Guardar: si el elemento ya existe lo modifica y si no existe lo crea.
Guardad nuevo: solo guarda el elemento si este no existe a´un.
Modificar: modifica el estado de un elemento si este existe.
Obtener Datos Salida: transforma un objeto Entidad en un objeto Info
Existe: devuelve si un elemento existe o no.
Obtener: obtiene un elemento por un identificador.
Borrar: elimina un elemento si este existe.
Adem´as de estos m´etodos se ha implementado otro adicional que devuelve una lista con todas las ´areas. Podemos ver en el listing 4.2 algunos de los m´etodos implementados adem´as de algunas anotaciones, en concreto la anotaci´on @Transaccional hace que la
operaci´on sea transaccional, en este caso adem´as se especifica que no se llevar´a a cabo la operaci´on si se produce una excepci´on de esta clase utilizando el par´ametro rollback.
@Service
public class AreasManager implements
BasicManagerInterface<AreaInfoDto, AreaEntity, AreaFormDto> {
@Autowired
private DaoManager daoManager;
@Autowired
private MapperManager mapperManager;
public List<AreaInfoDto> obtenerAreas() { return obtenerDatosSalida(
daoManager.getAreasDao().findAll());
}
@Transactional(rollbackFor = Exception.class)
@Override
public AreaInfoDto guardar(AreaFormDto datos) { try {
AreaEntity areaEntity = mapperManager.
getMapeadorAreas().toEntidad(datos);
if (!existe(areaEntity.getId())) { return
obtenerDatosSalida(guardarNuevo(areaEntity));
} else { return
obtenerDatosSalida(modificar(areaEntity));
}
} catch (Exception e) {
throw new NotFoundException(
InfoExceptionEnum.ERROR_GUARDANDO_CONTROL);
} }
@Override
public AreaEntity guardarNuevo(AreaEntity areaEntity) { return daoManager.getAreasDao().save(areaEntity);
}
Listing 4.2: M´anager de ´Areas del back-end
Mapeadores: como se ha especificado anteriormente el mapeador se encargar de la trans- formaci´on de objetos Form, Info y Entidad entre s´ı mismos, para ello se utiliza la anotaci´on
@Mapper(componentModel = "spring") que automatiza el mapeado de datos de aquellos atributos que tengan el mismo nombre y el mismo tipo en los dos objetos. Sin embargo si en un objeto tenemos contenido un dato que es del tipo de otra clase del proyecto debemos definir la clase origen y destino de mapeado de este objeto con la anotaci´on
@Mapping(source = ’AreaFormDto’, target = ’AreaEntity’).
En esta segunda parte del m´odulo servidor se va a detallar parte de la funcionalidad desa- rrollada en el m´odulo Control. Los m´etodos que se explicar´an a continuaci´on consiguen que a partir de una plantilla se pueda obtener un control con una organizaci´on y ordenaci´on correcta.
Adem´as de otras modificaciones sobre un control ya hecho.
En la clase controladora del control, listing 4.3, se pueden ver los tres m´etodos que detallar´e su funcionalidad general a continuaci´on:
@ResponseStatus(OK)
@GetMapping(value = "{id:\\d+}")
public ControlInfoDto obtenerControl(@PathVariable Long id) { return managerManager.
getSerializarControlManager() .obtenerControlSerializado(id);
}
@ResponseStatus(CREATED)
@PostMapping(value = "/modificar-iteracion") public ControlInfoDto modificarIteracionControl(
@RequestBody @Valid List<IndicadoresEnIteracionFormDto> datos) { return managerManager.getModificarIteracionControlManager() .modificarIteracionControl(datos);
}
@ResponseStatus(CREATED)
@PostMapping(value = "/indicador-referencia") public ControlInfoDto modificarIndicadorReferencia(
@RequestBody @Valid ControlIndicadorFormDto datos) {
return managerManager.getModificarIndicadorReferenciaControlManager() .modificarIndicadorReferencia(datos);
}
@ResponseStatus(OK)
@GetMapping(value = "/copiar-control/{id:\\d+}")
public ControlInfoDto copiarControl(@PathVariable Long id) {
return managerManager.getNuevoControlManager().copiarControl(id);
}
@DeleteMapping(value = "{id:\\d+}")
public ResponseEntity borrar(@PathVariable Long id) { try {
controlesManager.borrar(id);
return new ResponseEntity(OK);
} catch (NotFoundException e) {
return new ResponseEntity(NOT_FOUND);
} }
Listing 4.3: M´etodos del controlador de un control del back-end
Obtener control: en este m´etodo obtenemos una variable que viene desde la ruta especifi- cada, este par´ametro es un identificador de una plantilla desde la cual debemos crear el nuevo control.
Para ello, como se puede ver en el listing 4.3, en el primer m´etodo se llama a la funci´on de la clase Serializar Control M´anager, en esta clase se especifican todos los m´etodos para obtener un control bien estructurado. A continuaci´on se detallar´an todos los m´etodos que se utilizan para este cometido.
El primer m´etodo que observamos en el listing 4.4 es el que se utiliza en el controlador.
Como se puede ver en las primeras l´ıneas se utiliza el identificador proporcionado para obtener un nuevo control. Este control se encuentra vac´ıo pues a´un no tiene ´areas ni secciones, para ello lo que se hace es ir a˜nadiendo ´areas y a estas los identificadores por
secci´on, manteniendo en todo momento un control de no repetidos en ambos casos. Para ello se utiliza el m´etodo del listing 4.5. Este proceso se realiza con cada Control Indicador, este objeto tiene asociado un ´area, una secci´on, una iteraci´on y unas medidas, por lo que cada elemento se organiza en funci´on de todos estos par´ametro. Todos ellos se guardan en listas pues primero se intent´o la implementaci´on con diccionarios pero se desech´o por la complejidad extra que supon´ıan estos.
public ControlInfoDto obtenerControlSerializado(Long idControl) { ControlEntity control = obtenerControl(idControl);
List<ControlIndicadorEntity> listControlIndicadorEntity = control.getIndicadores();
List<ControlAreaInfoDto> listAreas = new ArrayList<>();
for (ControlIndicadorEntity controlIndicadorEntity : listControlIndicadorEntity) {
serializadoAreasSecciones(listAreas, controlIndicadorEntity);
serializadoIteracionesIndicadoresPorSeccion(
listAreas, controlIndicadorEntity);
}
ControlInfoDto controlInfoDto =
mapperManager.getMapeadorControles().toInfoDto(control);
listAreas.sort(
Comparator.comparing(ControlAreaInfoDto::getOrden));
controlInfoDto.setAreas(listAreas);
return controlInfoDto;
}
Listing 4.4: M´etodo principal del m´anager del Control del back-end
private void serializadoAreasSecciones(List<ControlAreaInfoDto> listAreas , ControlIndicadorEntity controlIndicadorEntity) {
ControlSeccionInfoDto controlSeccionInfoDto;
ControlAreaInfoDto controlAreaInfoDto =
getControlAreaInfoDto(listAreas, controlIndicadorEntity);
//Area nueva
if (controlAreaInfoDto == null) {
controlAreaInfoDto = getControlAreaInfoDto(controlIndicadorEntity);
controlSeccionInfoDto =
getControlSeccionInfoDto(controlIndicadorEntity);
controlAreaInfoDto.setSecciones(new ArrayList<>());
controlAreaInfoDto.getSecciones().add(controlSeccionInfoDto);
listAreas.add(controlAreaInfoDto);
} else { //anyadir seccion a una Area existente
controlSeccionInfoDto = getControlSeccionInfoDtoFromArea(
controlIndicadorEntity, controlAreaInfoDto);
//Solo la anyado en caso de que no la tenga if (controlSeccionInfoDto == null) {
controlSeccionInfoDto =
getControlSeccionInfoDto(controlIndicadorEntity);
controlAreaInfoDto.getSecciones().add(controlSeccionInfoDto);
} }
}
Listing 4.5: M´etodo organizador de ´areas y de secciones del m´anager del control
Justo despu´es se utiliza el m´etodo serializar iteraciones e indicadores por secci´on. Realiza una ordenaci´on de los indicadores por iteraci´on dentro de cada secci´on, aunque normal- mente cada secci´on suele tener solo una iteraci´on .Puede haber controles de m´ultiples
temperaturas dentro de una secci´on lo que ocasiona que hayan varias iteraciones de un indicador.
Cabe destacar la utilizaci´on de los streams de Java para la b´usqueda dentro de las listas, para ello los streams tiene el m´etodo filter que permite comparar cualquier atributo del objeto que se recorre. Esto es necesario puesto que se requiere la b´usqueda por varios par´ametros de los objetos, como son el identificador de un ´area o de una secci´on. Se puede observar un ejemplo del uso de streams para este prop´osito en el listing 4.6. Como se puede ver primero se extrae la lista de secciones de un ´area que concuerda con el identificador de ´area del control indicador pasado como par´ametros y finalmente antes de devolver la lista de secciones se filtra la secci´on por el identificador de secci´on del control indicador.
Por ´ultimo antes de devolver el control bien construido se transforma el objeto Entidad a InfoDto y antes de ser enviado la lista de ´areas se ordenan por su atributo llamado orden y se a˜nade al control.
private ControlSeccionInfoDto getControlSeccionInfoDtoFromArea(
ControlIndicadorEntity controlIndicadorEntity, List<ControlAreaInfoDto> listAreas) {
List<ControlSeccionInfoDto> listaSecciones = listAreas.stream()
.filter(area -> controlIndicadorEntity.getArea() .getId().equals(area.getId()))
.findAny()
.orElse(null).getSecciones();
return listaSecciones.stream()
.filter(seccion -> controlIndicadorEntity.getSeccion() .getId().equals(seccion.getId()))
.findAny() .orElse(null);
}
Listing 4.6: Empleo de streams en la clase m´anager de un Control
Modificar iteraci´on: esta funci´on se encarga de la modificaci´on concreta de una iteraci´on dentro de una secci´on cambiando sus medidas por la lista de medidas enviada como ar- gumento. La dificultad que entra˜naba este m´etodo es el hecho de que las medidas de un indicador est´an guardadas en base de datos en formato JSON, por lo tanto se me encarg´o la tarea de buscar una librer´ıa adecuada para el manejo de este tipo de datos. Por ello se utiliz´o la librer´ıa Gson[17] puesto que su uso m´as frecuente es para convertir un objeto en su representaci´on JSON y a la inversa.
Para realizar el cambio de medidas primero se necesitan deserializar las medidas existentes en base de datos para comprobar aquellas que coincidan con la lista pasada para modificar unicamente su valor. Se puede observar en el primer comentario del c´odigo del listing 4.7 como el primer paso es convertir los valores de la base de datos, que son un string en formato JSON, a una lista de objetos JSON de medidas.
public Long guardarIndicadoresPorIteracion(
IndicadoresEnIteracionFormDto iteracionIndicadoresFormDto) { ControlIndicadorEntity controlIndicadorEntity =
obtenerControlIndicador(iteracionIndicadoresFormDto.getId());
String valores = controlIndicadorEntity.getValores();
List<ValoresFormDto> listaValoresForm =
iteracionIndicadoresFormDto.getListaValores();
//Deserializar el JSON de la BBDD
List<MedidasJsonEntity> listaValores = getValoresDeserializados(valores);
//Setear el campo valor en los campos coincidentes.
addValorInListaMedidas(listaValoresForm, listaValores);
//Serializar la lista de medidas para guardarla en BBDD Gson customGson = getGsonCustom();
String valoresNuevos = customGson.toJson(listaValores);
controlIndicadorEntity.setValores(valoresNuevos);
//vemos si el indicador esta completado marcarIndicadorComoCompletado(
iteracionIndicadoresFormDto, controlIndicadorEntity);
//Guardar el control indicador en BBDD
if (existe(controlIndicadorEntity.getId())) { try {
daoManager.getControlesIndicadoresDao() .save(controlIndicadorEntity);
return controlIndicadorEntity.getControl().getId();
} catch (Exception e) { throw new
NotFoundException(
InfoExceptionEnum.ERROR_GUARDANDO_CONTROL);
} }
return null;
}
Listing 4.7: M´etodo para modificar las medidas por iteraci´on
Este proceso se encarga de hacerlo el m´etodo del listing 4.8 el funcionamiento es bastante trivial pues con un objeto Gson solo tenemos que indicarle el tipo de elemento al que tiene que convertir el string y los valores a convertir para que haga el proceso autom´aticamente, para ello los campos de JSON deben coincidir con los del objeto a transformar.
private List<MedidasJsonEntity> getValoresDeserializados(String valores) { Type listType =
new TypeToken<ArrayList<MedidasJsonEntity>>() {}.getType();
List<MedidasJsonEntity> listaMedidas = new Gson().fromJson(valores, listType);
return listaMedidas;
}
Listing 4.8: Deserializado de medidas desde la base de datos
Luego simplemente se recorre la lista de objetos y se cambia el campo valor de las medidas para aquellas con un identificador coincidente. A continuaci´on hay que volver a guardar el string JSON en la base de datos, para ello se utiliz´o un objeto Gson creado a prop´osito para este cometido. Como se puede ver en el listing 4.9 se indican el nombre de las propiedades y su valor a continuaci´on, para que este sea convertido a un formato cadena.
Por ´ultimo se comprueba que el indicador est´e completo y se guarda en base de datos la nueva cadena con los valores actualizados de las medidas, esto se puede ver en las ´ultimas l´ıneas de c´odigo del listing 4.7
private Gson getGsonCustom() {
GsonBuilder gsonBuilder = new GsonBuilder();
gsonBuilder.serializeNulls();
JsonSerializer<MedidasJsonEntity> serializer = new JsonSerializer<MedidasJsonEntity>() {
@Override
public JsonElement serialize(
MedidasJsonEntity src, Type typeOfSrc, JsonSerializationContext context) {
JsonObject jsonSeccionIndicador = new JsonObject();
jsonSeccionIndicador.addProperty("medida", src.getMedida());
jsonSeccionIndicador.addProperty("readOnly", src.getReadOnly());
jsonSeccionIndicador.addProperty("orden", src.getOrden());
jsonSeccionIndicador.addProperty("valor", src.getValor());
return jsonSeccionIndicador;
} };
gsonBuilder.
registerTypeAdapter(SeccionIndicadorValoresFormDto.class, serializer);
return gsonBuilder.create();
}
Listing 4.9: Serializador ad hoc para las medidas del control
Modificar indicador referencia: este m´etodo se encarga de modificar el indicador de referen- cia, listing4.10. Este indicador representa una relaci´on con un indicador con sus medidas vac´ıas, es decir, est´a por completar a´un. Este indicador puede ser uno o varios, por lo tanto como pasaba con el m´etodo anterior se guarda en formato JSON, por lo que el proceso es muy parecido al anterior.
Primero se busca el indicador a modificar, pero ahora los datos no se deserializan desde la base de datos ya que la cadena que obtenemos debemos macharla sobre la que hay en base de datos, por lo tanto solo tenemos que serializarla y guardarla en el lugar adecuado.
El c´odigo que realiza esta funci´on se puede observar en la figura
public ControlInfoDto modificarIndicadorReferencia(
ControlIndicadorFormDto datos) { ControlIndicadorEntity cie =
daoManager.getControlesIndicadoresDao().getOne(datos.getId());
// tenemos que modificar todos los registros
//que tengan la misma area, seccion, iteracion y control List<ControlIndicadorEntity>
listaIndicadoresModificar =
daoManager.getControlesIndicadoresDao().
obtenerIndicadoresIguales(
cie.getControl().getId(), cie.getArea().getId(), cie.getSeccion().getId(), cie.getIteracion());
String nuevoJson =
generarNuevoJsonIndicadorReferencia(cie, datos.getValor());
for (ControlIndicadorEntity controlIndicadorEntity : listaIndicadoresModificar) {
controlIndicadorEntity.setIndicadoresReferencia(nuevoJson);
daoManager.getControlesIndicadoresDao() .save(controlIndicadorEntity);
}
return managerManager.getControlesManager().
obtenerDatosSalida(
managerManager.
getControlesManager().obtener(cie.getControl().getId()));
}
Listing 4.10: Funci´on para modificar los indicadores de referencia.
Obtener Datos Salida: transforma un objeto Entidad en un objeto