Herramienta web para la gestión de informes automáticos

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA ESCOLA T´ ECNICA SUPERIOR DE ENXE ˜ NAR´ IA Herramienta web para la gesti´on de informes autom´aticos Autor: Daniel Montero Castelao Directores: Manuel Lama Pen´ın Juan Carlos Vidal Aguiar Victor Jos´e Gallego Fontenla Grado en Ingenier´ıa Inform´atica Febrero 2019 Trabajo de Fin de Grao presentado en la Escola T´ecnica Superior de Enxe˜nar´ıa de la Universidade de Santiago de Compostela para la obtenci´on del Grado en Ingenier´ıa Inform´atica. D. Manuel Lama Pen´ın, Profesor del Departamento de Electr´onica y Computaci´on de la Universidade de Santiago de Compostela, y D. Juan Carlos Vidal Aguiar, Profesor del Departamento de Electr´onica y Computaci´on de la Universidade de Santiago de Compostela, y D. Victor Jos´e Gallego Fontenla, Investigador Predoctoral FPU del Ministerio de Ciencia, Innovaci´on y Universidades. INFORMAN: Que la presente memoria, titulada Herramienta web para la gesti´on de informes autom´aticos, presentada por D. Daniel Montero Castelao para superar los cr´editos correspondientes al Trabajo de Fin de Grao de la titulaci´on de Grao en Enxe˜nar´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en el Departamento de Electr´onica y Computaci´on de la Universidade de Santiago de Compostela. Y para que as´ı conste a los efectos oportunos, expiden el presente informe en Santiago de Compostela, a 30 de enero de 2019: El director, El codirector, Manuel Lama Pen´ın Juan Carlos Vidal Aguiar El codirector, El alumno, Victor Jos´e Gallego Fontenla Daniel Montero Castelao i ii ´ Indice general 1. Introducci´on 1 1.1. Objetivos ............................... 2 1.2. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . 3 2. Gesti´on del proyecto 5 2.1. Gesti´on del alcance . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Descripci´on del alcance del producto . . . . . . . . . . . . 5 2.1.2. Criterios de aceptaci´on del producto . . . . . . . . . . . . 6 2.1.3. Entregables del producto . . . . . . . . . . . . . . . . . . . 7 2.1.4. Restricciones del proyecto . . . . . . . . . . . . . . . . . . 7 2.2. Gesti´onderiesgos........................... 8 2.2.1. Activos ............................ 8 2.2.2. Amenazas........................... 9 2.2.3. Especificaci´on de riesgos . . . . . . . . . . . . . . . . . . . 11 2.2.4. Identificaci´on de riesgos . . . . . . . . . . . . . . . . . . . 13 2.2.5. Tratamiento de riesgos . . . . . . . . . . . . . . . . . . . . 15 2.3. Metodolog´ıa de desarrollo . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Planificaci´on.............................. 21 2.4.1. Estructura de descomposici´on del trabajo (EDT) . . . . . 21 2.4.2. Cronograma (Planificaci´on inicial) . . . . . . . . . . . . . . 24 2.4.3. Cronograma (Planificaci´on real) . . . . . . . . . . . . . . . 25 2.5. Gesti´on de la configuraci´on . . . . . . . . . . . . . . . . . . . . . . 26 2.5.1. Elementos de configuraci´on . . . . . . . . . . . . . . . . . 27 2.5.2. Sistema de gesti´on de la configuraci´on . . . . . . . . . . . 27 2.5.3. Estructura del repositorio . . . . . . . . . . . . . . . . . . 28 2.5.4. Gesti´on de cambios . . . . . . . . . . . . . . . . . . . . . . 28 2.6. Gesti´ondecostes ........................... 29 2.6.1. Costes directos . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3. Costes totales . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.7. Gesti´on de las comunicaciones . . . . . . . . . . . . . . . . . . . . 31 2.7.1. Planificaci´on de las comunicaciones . . . . . . . . . . . . . 34 iii 3. An´alisis de requisitos 35 3.1. Actores del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.1. Intereses del usuario . . . . . . . . . . . . . . . . . . . . . 36 3.1.2. Perfil de conocimiento del usuario . . . . . . . . . . . . . . 36 3.1.3. Factores de rechazo del usuario . . . . . . . . . . . . . . . 37 3.2. Especificaci´on de requisitos . . . . . . . . . . . . . . . . . . . . . . 37 3.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 38 3.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . 44 3.2.3. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . 45 3.2.4. Casosdeuso ......................... 47 3.2.5. Matrices de trazabilidad . . . . . . . . . . . . . . . . . . . 53 4. An´alisis de tecnolog´ıas y herramientas 55 4.1. Serviciosweb ............................. 55 4.1.1. JerseyyJava ......................... 56 4.1.2. Express.js y JavaScript . . . . . . . . . . . . . . . . . . . . 57 4.1.3. RocketyRust......................... 57 4.1.4. Conclusi´on........................... 57 4.2. Tecnolog´ıas web est´andar . . . . . . . . . . . . . . . . . . . . . . . 58 4.2.1. HTML5 ............................ 58 4.2.2. CSS3.............................. 59 4.2.3. JavaScript........................... 59 4.2.4. JSON ............................. 60 4.3. Frameworks y librer´ıas . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3.1. TypeScript .......................... 60 4.3.2. React ............................. 61 4.3.3. Ant-Design .......................... 62 4.3.4. Recharts.js........................... 62 4.3.5. Material icons . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4. Base de datos documental . . . . . . . . . . . . . . . . . . . . . . 63 4.4.1. MongoDB y Mongoose . . . . . . . . . . . . . . . . . . . . 64 4.5. Herramientas ............................. 64 4.5.1. NPM.............................. 64 4.5.2. Docker............................. 65 4.5.3. PhantomJS .......................... 65 4.5.4. Git............................... 66 4.5.5. WebStorm........................... 66 4.5.6. TeXStudio........................... 66 5. Dise˜no e implementaci´on del sistema 67 5.1. Dise˜no de la arquitectura del sistema . . . . . . . . . . . . . . . . 67 5.1.1. Esquema de la arquitectura del sistema . . . . . . . . . . . 67 5.1.2. Arquitectura global . . . . . . . . . . . . . . . . . . . . . . 68 iv 5.1.3. Arquitectura del cliente web . . . . . . . . . . . . . . . . . 70 5.1.4. Arquitectura del servidor . . . . . . . . . . . . . . . . . . . 72 5.2. Patrones arquitect´onicos . . . . . . . . . . . . . . . . . . . . . . . 74 5.2.1. Arquitectura orientada a servicios . . . . . . . . . . . . . . 74 5.2.2. Flux .............................. 74 5.3. Modelodedatos............................ 75 5.4. Dise˜nodeclases............................ 77 5.4.1. Diagramas de paquetes . . . . . . . . . . . . . . . . . . . . 77 5.4.2. Dise˜no de clases del cliente web . . . . . . . . . . . . . . . 80 5.4.3. Dise˜no de clases del servidor . . . . . . . . . . . . . . . . . 93 5.5. Diagramas de interacci´on . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.1. Secuencia de llamadas para guardar una plantilla . . . . . 95 5.5.2. Secuencia de llamadas para cargar una plantilla . . . . . . 96 5.5.3. Secuencia de llamadas para imprimir una plantilla a PDF . 98 5.6. Dise˜no de interfaz de usuario . . . . . . . . . . . . . . . . . . . . . 100 6. Validaci´on y pruebas 103 6.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.2. Pruebas de integraci´on . . . . . . . . . . . . . . . . . . . . . . . . 108 6.3. Validaci´on de interfaz de usuario . . . . . . . . . . . . . . . . . . 111 6.3.1. Heur´ısticos de Nielsen . . . . . . . . . . . . . . . . . . . . 112 6.3.2. Cuestionario SUS . . . . . . . . . . . . . . . . . . . . . . . 114 6.4. Matriz de trazabilidad . . . . . . . . . . . . . . . . . . . . . . . . 116 7. Conclusiones y ampliaciones 117 7.1. Conclusiones.............................. 117 7.2. Ampliaciones ............................. 119 A. Manuales t´ecnicos 121 A.1. Manual de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . 121 A.2. Manual de configuraci´on . . . . . . . . . . . . . . . . . . . . . . . 122 A.2.1. Cambiar la URI de la capa de servicios . . . . . . . . . . . 122 A.2.2. Cambiar la URI de la base de datos . . . . . . . . . . . . . 123 A.2.3. Versiones utilizadas en el desarrollo . . . . . . . . . . . . . 123 B. Manual de usuario 125 B.1. Vista normal de la aplicaci´on . . . . . . . . . . . . . . . . . . . . 125 B.2. Crear nuevos componentes . . . . . . . . . . . . . . . . . . . . . . 126 B.3. Cambiar las propiedades de la plantilla . . . . . . . . . . . . . . . 127 B.4. Propiedades, tama˜no y posici´on de un componente . . . . . . . . 128 B.4.1. Propiedades de componentes de texto . . . . . . . . . . . . 129 B.4.2. Propiedades del componente imagen . . . . . . . . . . . . 130 B.4.3. Propiedades del componente lista . . . . . . . . . . . . . . 131 v B.4.4. Propiedades del componente malla . . . . . . . . . . . . . 132 B.4.5. Propiedades del componente tabla . . . . . . . . . . . . . . 133 B.4.6. Propiedades del componente gr´afica cartesiana . . . . . . . 134 B.4.7. Propiedades del componente gr´afica polar . . . . . . . . . 135 B.4.8. Propiedades del componete gr´afica de dispersi´on . . . . . . 137 B.5. Definici´on de variables . . . . . . . . . . . . . . . . . . . . . . . . 139 B.5.1. Secci´on de creaci´on de variables . . . . . . . . . . . . . . . 139 B.5.2. Tipos de variables . . . . . . . . . . . . . . . . . . . . . . . 139 B.5.3. Mapeador de variables . . . . . . . . . . . . . . . . . . . . 141 B.5.4. Cargador de JSON . . . . . . . . . . . . . . . . . . . . . . 143 B.6. Uso de variables y fuentes de datos . . . . . . . . . . . . . . . . . 144 B.7. Creaci´on, guardado y borrado de plantillas . . . . . . . . . . . . . 145 B.8. Impresi´on de plantilla . . . . . . . . . . . . . . . . . . . . . . . . . 145 C. Licencia 147 Bibliograf´ıa 149 vi ´ Indice de figuras 2.1. Primer nivel de la estructura de descomposici´on de trabajo . . . . 21 2.2. Descomposici´on del paquete de trabajo Definici´on del proyecto . . 22 2.3. Descomposici´on del paquete de trabajo Aplicaci´on web ...... 22 2.4. Descomposici´on del paquete de trabajo Capa de servicios ..... 23 2.5. Descomposici´on del paquete de trabajo Entorno y base de datos . 23 2.6. Cronograma general del proyecto . . . . . . . . . . . . . . . . . . 24 2.7. Cronograma del paquete de trabajo Definici´on del proyecto . . . . 25 2.8. Cronograma del paquete de trabajo Aplicaci´on web ........ 25 2.9. Cronograma del paquete de trabajo Capa de servicios ....... 25 2.10. Cronograma del paquete de trabajo Entorno y base de datos . . . 25 2.11. Planificaci´on real del proyecto . . . . . . . . . . . . . . . . . . . . 26 2.12. Estructura del repositorio . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Esquema de la arquitectura del sistema . . . . . . . . . . . . . . . 68 5.2. Arquitectura de alto nivel del sistema . . . . . . . . . . . . . . . . 69 5.3. Arquitectura de la aplicaci´on web . . . . . . . . . . . . . . . . . . 70 5.4. Arquitectura del servidor . . . . . . . . . . . . . . . . . . . . . . . 72 5.5. Diagrama de paquetes del cliente web . . . . . . . . . . . . . . . . 78 5.6. Diagrama de paquetes del servidor . . . . . . . . . . . . . . . . . 79 5.7. Diagrama de clases del n´ucleo de la aplicaci´on . . . . . . . . . . . 81 5.8. Diagrama de clases del paquete ComponentsPanel ......... 83 5.9. Diagrama de clases del paquete CRUDPanel ............ 84 5.10. Diagrama de clases del paquete LayoutComponents (1) . . . . . . 85 5.11. Diagrama de clases del paquete LayoutComponents (2) . . . . . . 86 5.12. Diagrama de clases del paquete PropsPanels (1).......... 88 5.13. Diagrama de clases del paquete PropsPanels (2).......... 89 5.14. Diagrama de clases del paquete VarsSection ............ 91 5.15. Diagrama de clases del paquete ReportLayout ........... 93 5.16. Diagrama de clases del servidor . . . . . . . . . . . . . . . . . . . 94 5.17. Diagrama de interacci´on para Guardar una plantilla ...... 96 5.18. Diagrama de interacci´on para Cargar una plantilla ....... 98 5.19. Diagrama de interacci´on para Imprimir a PDF ......... 99 5.20. Versi´on minimalista de la interfaz de la aplicaci´on . . . . . . . . . 100 5.21. Boceto de la disposici´on de los elementos en la interfaz completa . 101 vii 4CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 6:Validaci´on y pruebas, incluye las pruebas unitarias, pruebas de integraci´on, y validaci´on de interfaz de usuario. Cap´ıtulo 7:Conclusiones, incluye las conclusiones obtenidas tras la realizaci´on del trabajo realizado y las posibles ampliaciones del mismo. Ap´endice A:Manual de despliegue, incluye el manual de despliegue de la aplicaci´on junto las opciones de configuraci´on disponibles. Ap´endice B:Manual de usuario, incluye el manual de usuario para la utilizaci´on de la aplicaci´on. Ap´endice C:Licencia de uso, incluye la licencia de uso del software y de este trabajo. Cap´ıtulo 2 Gesti´on del proyecto La parte de gesti´on del proyecto es una fase gradual que se realiza durante todo el transcurso de un proyecto cualquiera. En esta fase se define el cronograma de las actividades, la gesti´on de los riesgos, los costes y las comunicaciones con los diferentes interesados en el proyecto. Puesto que este TFG es un proyecto inform´atico, tambi´en ser´a necesario especificar la gesti´on de los distintos elementos del software que se desarrollen durante el transcurso del proyecto, esto incluye, el modo de guardar la diferentes versiones que se generan as´ı como el modo de documentar los cambios que se realizan en el c´odigo desarrollado. 2.1. Gesti´on del alcance En esta secci´on se describe el alcance del producto, los criterios de aceptaci´on del producto por parte del cliente, los entregables del producto junto con sus restricciones. 2.1.1. Descripci´on del alcance del producto El producto en su conjunto consta de tres partes: Aplicaci´on web (Cliente) Capa de servicios y base de datos (Servidor) Documentaci´on de la aplicaci´on La aplicaci´on web es una interfaz de usuario ejecutada sobre un navegador web moderno cualquiera. Esta interfaz permite la creaci´on de plantillas de informes, el usuario podr´a seleccionar un rango de componentes para formar la plantilla, dichos componentes van desde p´arrafos y t´ıtulos, hasta im´agenes, listas, tablas y 5 6CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO gr´aficas. Adicionalmente el usuario podr´a modificar las propiedades de cada componente de la plantilla, incluyendo (pero no limit´andose) el tama˜no del componente, fuente, desplazamiento, decoraci´on, etc. La aplicaci´on web permite tambi´en la definici´on de variables por parte del usuario, una variable puede ser una cadena de texto, ua fecha o una fuente de datos de un componente (como una tabla o una gr´afica), el usuario definir´a la variable y asociar´a la variable a uno o m´as componentes de la plantilla que est´e editando. El usuario podr´a despu´es optar por cargar una archivo en formato JSON para darle valor a las variables y reemplazarlas de forma autom´atica en la aplicaci´on, generando de este modo un informe completo en base a la plantilla que ha especificado, obteniendo un PDF con las variables reemplazadas en la plantilla. La aplicaci´on permitir´a tambi´en generar m´ultiples informes dada la carga de m´ultiples archivos JSON para una misma plantilla, adicionalmente permitir´a crear, guardar, modificar y borrar plantillas de informes, dicha funcionalidad corresponder´a al servidor que utilizar´a una base de datos NoSQL para almacenar estos datos. El producto contendr´a documentaci´on, incluyendo esta los manuales de despliegue y uso del software. 2.1.2. Criterios de aceptaci´on del producto El producto entregado al cliente se considerar´a adecuado y aceptado cuando cumpla las siguientes condiciones: Permite la creaci´on de componentes de texto (inclusi´on de p´arrafos y t´ıtulos) en las plantillas. Permite la inclusi´on de listas y tablas en las plantillas. Permite la inclusi´on de im´agenes en las plantillas. Permite definir el tama˜no y la disposici´on de cada elemento que forme la plantilla. Permite la inclusi´on de gr´aficas (barras, ´area, l´ıneas, sectores, radar y dispersi´on en dos variables) en la plantilla. Permite la inclusi´on de variables en la plantilla. Permite la carga de fuentes de datos en las gr´aficas, tablas y listas de una plantilla. 2.1. GESTI ´ ON DEL ALCANCE 7 Permite modificar cualquier componente que forme parte de una plantilla. Permite crear, guardar, modificar y borrar plantillas. Permite generar informes en base a plantillas reemplazando las variables que est´en situadas en la plantilla dado un archivo en formato JSON. Permite generar m´ultiples informes en base a una plantilla dados m´ultiples archivos en formato JSON. Los informes generados por la aplicaci´on se descargan en formato PDF. 2.1.3. Entregables del producto El producto se compondr´a de un ´unico entregable final con todas las funcionalidades que el cliente haya especificado para pasar sus criterios de aceptaci´on, este entregable incluir´a: Aplicaci´on web (Cliente) Capa de servicios y base de datos (Servidor) Documentaci´on de la aplicaci´on Sin embargo se liberar´a versiones parciales durante el transcurso del proyecto que se utilizar´an para mostrar al cliente el estado de desarrollo de la aplicaci´on, estas versiones parciales est´an sujetas a cambios tanto por parte del cliente como por parte del desarrollador seg´un se estime conveniente para pasar los criterios de aceptaci´on del producto. Se define un n´umero m´ınimo de 3 versiones parciales al cliente para informarle del estado de desarrollo del producto. 2.1.4. Restricciones del proyecto Las restricciones del proyecto son las siguientes: El proyecto debe de realizarse en un tiempo aproximado de 421 horas. La aplicaci´on debe de estar desarrollada con tecnolog´ıas web est´andar (HTML5, CSS y JavaScript) o cualquier framework o librer´ıa que se derive de estas tecnolog´ıas. La base de datos utilizada debe de ser NoSQL Debe de utilizarse una arquitectura orientada a servicios REST para implementar las funcionalidades del servidor. La aplicaci´on debe de poder tratar los archivos de formato JSON. 8CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.2. Gesti´on de riesgos En todo proyecto de cierta consideraci´on es necesario realizar una gesti´on de los distintos riesgos que puedan aparecer y que por ello pueden afectar de alguna manera al transcurso del proyecto. Los riesgos que afectan a un proyecto pueden variar desde: Riesgos espec´ıficos del proyecto (Cambio de tecnolog´ıas, requisitos no correctamente especificados, dise˜nos incorrectos...) Riesgos gen´ericos (Cambios de legislaci´on, desastres naturales, bajas del personal, cancelaci´on del proyecto...) Cualquier riesgo que pueda afectar al proyecto debe de ser identificado y en caso de ser viable su tratamiento, tener alg´un plan para controlar el riesgo en caso de que se produzca. A continuaci´on se detallan los riesgos m´as importantes que pueden afectar a este proyecto. 2.2.1. Activos Antes de empezar a identificar riesgos vinculados al proyecto es necesario identificar aquellos activos que son importantes para la realizaci´on del proyecto. La tabla que representa un activo est´a compuesta por los siguientes campos: ID: C´odigo identificador ´unico del activo Nombre: Nombre del activo Descripci´on: Descripci´on del activo Los activos identificados son los siguientes: ID AC-001 Nombre Estaci´on de trabajo Descripci´on La estaci´on de trabajo es crucial para el desarrollo del proyecto tanto para generar la documentaci´on del proyecto como para realizar la implementaci´on de la aplicaci´on que se va a desarrollar durante el transcurso del mismo, solo se cuenta con una actualmente. 2.2. GESTI ´ ON DE RIESGOS 9 ID AC-002 Nombre C´odigo de la aplicaci´on Descripci´on El c´odigo de la aplicaci´on contendr´a absolutamente toda la implementaci´on que se ha dise˜nado en este proyecto, esto implica el c´odigo ejecutable que tanto el cliente como el servidor ejecutar´an en sus respectivas fronteras de desarrollo para llevar a cabo sus funcionalidades. ID AC-003 Nombre Base de datos Descripci´on La base de datos contendr´a toda la informaci´on de operaciones de manipulaci´on de datos que la aplicaci´on cliente solicite al servidor. ID AC-004 Nombre Repositorio del proyecto Descripci´on El repositorio contendr´a las sucesivas versiones del c´odigo y de la documentaci´on que se vayan generando durante el transcurso del proyecto. 2.2.2. Amenazas Ya identificados los activos se procede a identificar las diferentes amenazas que pueden producirse en el contexto del proyecto actual. La tabla que representa una amenaza est´a compuesta por los siguientes campos: ID: C´odigo identificador ´unico de la amenaza Nombre: Nombre de la amenaza Descripci´on: Descripci´on de la amenaza Las amenazas identificadas son las siguientes: ID AM-001 Nombre Cambio de tecnolog´ıas de desarrollo Descripci´on Las tecnolog´ıas que se utilizan para desarrollar la aplicaci´on est´an en constante evoluci´on, puede darse el caso de que salgan nuevas versiones de estas tecnolog´ıas y que est´as sean incompatibles con las versiones anteriores 10 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO ID AM-002 Nombre Actualizaciones del sistema operativo Descripci´on Si se produce una actualizaci´on del sistema operativo puede darse el caso de que ciertas tecnolog´ıas o programas que se utilizan para desarrollar el proyecto dejen de funcionar o funcionen parcialmente. ID AM-003 Nombre Fallo de hardware Descripci´on La documentaci´on o c´odigo generado pueden perderse completamente o parcialmente por un fallo de hardware de la estaci´on de trabajo, imposibilitando la opci´on de recuperaci´on. ID AM-004 Nombre Cambios de requisitos Descripci´on Se pueden producir cambios de requisitos a lo largo del transcurso del proyecto. ID AM-005 Nombre Planificaci´on optimista Descripci´on Cuando se planifica el proyecto se realizan estimaciones demasiado optimistas de modo que se tiene la idea de que las tareas se acabar´an antes de lo previsto cuando en realidad no va a ser as´ı. ID AM-006 Nombre Planificaci´on pesimista Descripci´on Cuando se planifica el proyecto se realizan estimaciones demasiado pesimistas, de modo que se tiene la idea de que las tareas acabar´an mucho despu´es de lo previsto cuando en realidad no va a ser as´ı. ID AM-007 Nombre Falta de implicaci´on por parte de los interesados del proyecto Descripci´on Los principales interesados del proyecto no se involucran lo suficiente en su desarrollo, faltando feedback sobre el estado actual del mismo. 2.2. GESTI ´ ON DE RIESGOS 11 ID AM-008 Nombre Uso de nuevas tecnolog´ıas Descripci´on El uso de nuevas tecnolog´ıas puede producir retrasos en la planificaci´on si no se cuenta con suficiente formaci´on para utilizarlas a la velocidad normal. ID AM-009 Nombre Alcance del proyecto sobredimensionado Descripci´on El alcance del proyecto es demasiado excesivo para el tiempo y presupuestos acordados, por lo que no se puede realizar de forma completa ID AM-010 Nombre Dise˜no poco escalable Descripci´on Un dise˜no poco escalable dificulta la posibilidad de ampliar la aplicaci´on durante el desarrollo de la misma, produciendo retrasos en la planificaci´on ID AM-011 Nombre Mala usabilidad de la interfaz Descripci´on Desarrollar una interfaz con mala usabilidad puede provocar el rechazo absoluto de la aplicaci´on por parte del cliente o del usuario final. 2.2.3. Especificaci´on de riesgos Una vez identificados los activos y las amenazas se procede a identificar los riesgos del proyecto, por lo tanto se relacionan las amenazas con los activos y se le da a cada relaci´on de este tipo una escala de probabilidad e impacto extrayendo de este modo un riesgo para el proyecto. La tabla que define un riesgo est´a compuesta por los siguientes campos: ID: C´odigo identificador ´unico del riesgo Amenazas involucradas: Lista de amenazas involucradas en el riesgo (ID de las amenazas) Activos involucrados: Lista de activos involucrados en el riesgo (ID de los activos) 12 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Probabilidad: Probabilidad del riesgo (Cuan probable es que suceda) Impacto: Impacto del riesgo (Si se produce cuando da˜no puede llegar a realizar) Exposici´on: Factor calculado entre la probabilidad y el riesgo A continuaci´on se indican las distintas escalas y opciones de tratamiento de riesgos contempladas y utilizadas en este proyecto. Las escalas de probabilidad que se han utilizado para medir los riesgos son las siguientes: Alta: El riesgo tiene una probabilidad muy alta de que pueda llegar a manifestarse, la posibilidad de aparici´on oscila entre el 81 % y el 100 %, ambos inclusive. Media: El riesgo tiene una probabilidad media de que pueda llegar a manifestarse, la posibilidad de aparici´on oscila entre el 36 % y el 80 %, ambos inclusive. Baja: El riesgo tiene una probabilidad baja de que pueda llegar a manifestarse, la posibilidad de aparici´on oscila entre el 0 % y el 35 %, ambos inclusive. Las escalas de impacto utilizadas para medir los riesgos son las siguientes: Catastr´ofico: El riesgo produce un gran impacto en el proyecto, pudiendo producir la cancelaci´on del mismo si llegase a producirse. Alto: El riesgo produce un gran impacto en el proyecto, pudiendo alterar enormemente su curso o su planificaci´on si llegase a producirse. Medio: El riesgo produce un impacto medio en el proyecto, pudiendo alterar puntualmente ciertas acciones de transcurso del mismo. Bajo: El riesgo produce un impacto bajo en el proyecto, pudiendo alterar levemente algunas opciones del mismo. Insignificante: El riesgo apenas produce impacto alguno en el proyecto, sus consecuencias pueden ser ignoradas. Las posibles acciones que se pueden realizar para tratar un riesgo en este proyecto son las siguientes: Asumir: No se toma ninguna acci´on con respecto al riesgo, simplemente se asume que va a suceder y que tendr´a consecuencias en el proyecto. 2.2. GESTI ´ ON DE RIESGOS 13 Prevenci´on: Se crea un plan para reducir la probabilidad de que el riesgo ocurra durante el transcurso del proyecto. Minimizaci´on: Se crea un plan para reducir el impacto que el riesgo produce en caso de manifestarse. Contingencia: Se crea un plan que se ejecuta una vez el riesgo se ha manifestado en el proyecto, con el objetivo de reducir los efectos del riesgo una vez se ha producido. Para priorizar los riesgos seg´un la exposici´on que producen, se utiliza la siguiente matriz en la que se representan las distintas escalas de impacto en las filas y las escalas de probabilidad en las columnas de la matriz. El valor de la exposici´on se calcula como el producto del valor cuantitativo asignado a cada escala, indicado entre par´entesis en la matriz. Alta (1) Media (0.65) Baja (0.15) Catastr´ofico (1) 1 0.65 0.15 Alto (0.8) 0.8 0.52 0.12 Medio (0.5) 0.5 0.325 0.075 Bajo (0.3) 0.3 0.195 0.045 Insignificante (0.1) 0.1 0.065 0.015 Los riesgos que presenten un valor de exposici´on m´as alto ser´an los que tengan la prioridad m´as alta para aplicarles medidas de tratamiento. Se consideraron las siguientes escalas de exposici´on: Alta: Valor mayor o igual que 0.65. Media: Valor menor que 0.65 y mayor o igual que 0.15. Baja: Valor menor que 0.15. 2.2.4. Identificaci´on de riesgos A lo largo del proyecto se han identificado los siguientes riesgos: ID RIE-001 Amenazas involucradas AM-001 Activos involucrados AC-002, AC-003, AC-004 Probabilidad Alta Impacto Alto Exposici´on Alta 20 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO decantaremos por programaci´on extrema, el motivo de esta elecci´on es que scrum delimita mucho el margen de maniobra en las iteraciones con los sprints, en cambio programaci´on extrema permite m´as flexibilidad al utilizar iteraciones cortas orientadas a prototipos. Adicionalmente, scrum requiere un gran n´umero de reuniones con los clientes, y aunque es posible reunirse con ellos no conviene saturar su agenda con reuniones constantes ya que tienen otros compromisos que atender. Por ello se selecciona como metodolog´ıa de desarrollo programaci´on extrema, esta metodolog´ıa se orienta a desarrollar desde un enfoque incremental utilizando iteraciones cortas para liberar funcionalidades de forma continua al cliente o usuario. Esto ´ultimo coincide con la necesidad de: 1) ense˜nar al cliente la evoluci´on del proyecto, 2) los requisitos no est´an bien especificados en las fases iniciales y 3) la planificaci´on tiende a cambiar seg´un los requisitos cambian. Adem´as, programaci´on extrema es una metodolog´ıa orientada a pruebas y centrada en la refactorizaci´on del c´odigo que se desarrolle durante el transcurso del proyecto, de modo que primero se programan las pruebas que deben de pasar las funcionalidades y luego se programa el c´odigo para que pase las pruebas programadas sin importar cuantas veces se tenga que reescribir, mejorar o evolucionar dicho c´odigo. De modo que se satisfacen las necesidades de: 1) se utilizan tecnolog´ıas nuevas y no se cuenta con experiencia en su uso y 2) solo se cuenta con un recurso para desarrollar todo el proyecto. Los incrementos que se contemplan en este proyecto son los siguientes: Incremento 1 (Aplicaci´on web): Constituye la realizaci´on de la aplicaci´on web de edici´on y creaci´on de informes y plantillas de informes con todas sus funcionalidades. Incremento 2 (Capa de servicios): Consta de la implementaci´on de la capa de servicios web que utilizar´a el cliente para enviar y recibir datos al servidor, en concreto almacenamiento y obtenci´on de plantillas e informes creados en la aplicaci´on web. Incremento 3 (Entorno y base de datos): Creaci´on de la base de datos para almacenar los datos recibidos en la capa de servicios junto con la puesta en marcha del entorno completo con la aplicaci´on web y la capa de servicios. 2.4. PLANIFICACI ´ ON 21 2.4. Planificaci´on En esta secci´on se especifica la planificaci´on de la duraci´on total del proyecto, esta viene especificada por la distribuci´on de las tareas que componen el desarrollo completo del proyecto junto con el n´umero de horas estimadas para su realizaci´on. La especificaci´on de las tareas, o paquetes de trabajo, se detalla en la Estructura de descomposici´on de trabajo mientras que la duraci´on de cada una de ellas y su distribuci´on en el tiempo se especifica en el Cronograma. 2.4.1. Estructura de descomposici´on del trabajo (EDT) Puesto que el proyecto incluye un amplio rango de tareas a realizar es preciso descomponer estas en paquetes de trabajo manejables y m´as peque˜nos que permitan estimar de forma efectiva su duraci´on y trabajo requerido para realizarlos, adem´as esta descomposici´on de tareas servir´a tambi´en para definir de forma esquem´atica el trabajo que se realizar´a durante el transcurso del proyecto. En la figura 2.1 se muestra el nivel m´as alto de la descomposici´on del trabajo a realizar, el proyecto en su conjunto est´a formado por 4 grandes paquetes de trabajo: la definici´on del proyecto, la aplicaci´on web, la capa de servicios y el entorno y la base de datos. Herramienta web para la gesti´on de informes autom´aticos Definici´on del proyecto Aplicaci´on web Capa de servicios Base de datos Figura 2.1: Primer nivel de la estructura de descomposici´on de trabajo El paquete de trabajo definici´on del proyecto definido en la figura 2.2 se compone de las tareas relativas a la gesti´on del proyecto, an´alisis de tecnolog´ıas y an´alisis de requisitos, esto incluye la gesti´on de riesgos del proyecto, la definici´on del alcance del proyecto, el an´alisis de requisitos de la aplicaci´on y el an´alisis de tecnolog´ıas que se utilizar´an durante la fase de desarrollo del proyecto. 22 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Definici´on del proyecto Gesti´on de riesgos A. de requisitos Definici´on del alcance A. de tecnolog´ıas Formaci´on Figura 2.2: Descomposici´on del paquete de trabajo Definici´on del proyecto El primer incremento corresponde a la Aplicaci´on web y est´a definido en la figura 2.3. Este incremento est´a compuesto de las tareas relativas a la realizaci´on de la interfaz web que dar´a soporte a la creaci´on y gesti´on de informes autom´aticos, se prev´e que est´e sea el paquete de trabajo m´as complejo y por ello el que m´as tiempo necesite para ser completado. Incremento 1: Aplicaci´on web Dise˜no de arquitectura Dise˜no de interfaz Pruebas P. unitarias P. de integraci´on Implementaci´on Figura 2.3: Descomposici´on del paquete de trabajo Aplicaci´on web En este incremento se engloban las tareas relativas a la elaboraci´on del dise˜no de la aplicaci´on, dividido en dos tareas, el dise˜no de la arquitectura del sistema que engloba el dise˜no interno y m´as funcional de la aplicaci´on y el dise˜no de la interfaz que engloba el dise˜no visual que el usuario observa para utilizar la aplicaci´on. Adem´as, se incluye en este paquete la tarea de implementaci´on del sistema que se realizar´a una vez se hayan completado los paquetes de dise˜no, este paquete se corresponde con la implementaci´on funcional de los requisitos y el enlace de dichas funcionalidades con la interfaz de usuario. Finalmente est´a el paquete correspondiente a la fase de pruebas, dividida en dos tareas, las pruebas unitarias, que comprueban las funcionalidades de forma aislada y las pruebas de integraci´on que comprueban que la aplicaci´on de forma aut´onoma funciona correctamente. 2.4. PLANIFICACI ´ ON 23 El segundo incremento corresponde a la Capa de servicios, representado en la figura 2.4. Este incremento comprende el desarrollo de las funcionalidades de almacenamien- to e impresi´on de informes situadas en el servidor, esta tarea est´a subdividida en los paquetes de dise˜no de la capa de servicios en la que se dise˜nar´a de forma abstracta los servicios que contendr´a el servidor y el modo de utilizarlos. A continuaci´on se realizar´a la implementaci´on de la capa de servicios en la que se incluir´an de forma funcional los dise˜nos anteriores, finalizando en las pruebas para comprobar que la capa de servicios funciona de forma correcta, componi´endose esta ´ultima fase a las pruebas unitarias y de integraci´on. Incremento 2: Capa de servicios Dise˜no de la capa de servicios Implementaci´on Pruebas P. unitarias P. de integraci´on Figura 2.4: Descomposici´on del paquete de trabajo Capa de servicios El tercer incremento es el Entorno y base de datos representado en al figura 2.5. Este incremento engloba las tareas relativas a montar el entorno de despliegue de la aplicaci´on junto con la base de datos utilizada por la capa de servicios, esta tarea se divide en los paquetes de trabajo: Implementaci´on del entorno y Implementaci´on de la base de datos. Incremento 3: Entorno y base de datos Implementaci´on del entorno Implementaci´on de la base de datos Figura 2.5: Descomposici´on del paquete de trabajo Entorno y base de datos El primer paquete engloba las tareas relativas a instalar, configurar e iniciar el entorno de despliegue de las aplicaciones mientras que el segundo est´a destinado a las acciones relativas a la selecci´on e implementaci´on de una base de datos NoSQL en el entorno previamente instalado. 24 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.4.2. Cronograma (Planificaci´on inicial) La planificaci´on que se muestra a continuaci´on es la planificaci´on inicial del proyecto, sin que se produjese ning´un riesgo durante el desarrollo y atendiendo ´unicamente a las estimaciones iniciales. Identificados y analizados los distintos paquetes de trabajo que componen el proyecto en su totalidad se procede a realizar la planificaci´on o distribuci´on temporal del proyecto, para ello se generaron los siguientes cronogramas indicando la duraci´on estimada en horas de cada uno de los paquetes de trabajo y de las tareas que componen dichos paquetes de trabajo. En la figura 2.6 se muestra el cronograma general del proyecto, la estimaci´on incluye una duraci´on total aproximada de 426 horas, el proyecto est´a compues- to de los paquetes de trabajo anteriormente identificados m´as la elaboraci´on de la documentaci´on del proyecto, esta ´ultima tarea se realiza en paralelo con los paquetes de trabajo durante todo el transcurso del proyecto. Figura 2.6: Cronograma general del proyecto La primera fase del proyecto es la definici´on del proyecto (Figura 2.7), esta tarea tiene una duraci´on aproximada de 32 horas, una vez finalizada esta tarea se procede a empezar con el paquete de trabajo m´as laborioso y complejo de todo el proyecto, la aplicaci´on web (Figura 2.8), este paquete de trabajo tiene una duraci´on aproximada de 338 horas y compondr´a el n´ucleo del proyecto, su duraci´on ser´a m´as elevada que la de los dem´as paquetes debido a que implica mayor esfuerzo de desarrollo y dise˜no para poder completarse. Una vez finalizada la implementaci´on de la fase anterior se procede a realizar el paquete de trabajo capa de servicios (Figura 2.9), este paquete de trabajo tiene una duraci´on aproximada de 36 horas debido a que las funcionalidades con- 2.4. PLANIFICACI ´ ON 25 templadas son pocas y f´aciles de programar, adicionalmente se cuenta experiencia por parte del desarrollador en esta parte. Finalmente, se procede a realizar el ´ultimo paquete de trabajo, entorno y base de datos (Figura 2.10), este paquete tiene una duraci´on estimada de 20 horas y consiste en implementar la base de datos y el entorno de despliegue fuera del entorno de desarrollo normal de la aplicaci´on, al acabar este paquete de trabajo y la documentaci´on asociada al proyecto se alcanzar´ıa el hito de Fin del proyecto y este quedar´ıa finalizado. Figura 2.7: Cronograma del paquete de trabajo Definici´on del proyecto Figura 2.8: Cronograma del paquete de trabajo Aplicaci´on web Figura 2.9: Cronograma del paquete de trabajo Capa de servicios Figura 2.10: Cronograma del paquete de trabajo Entorno y base de datos 2.4.3. Cronograma (Planificaci´on real) Durante la ejecuci´on del proyecto se produjeron dos variaciones significativas en el cronograma de la planificaci´on inicial, provocando un desajuste en la planificaci´on. Los riesgos que se produjeron fueron dos: 26 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Duraci´on estimada para una tarea demasiado optimista. Acumulaci´on de tareas para el ´unico recurso disponible. El primer riesgo produjo un desajuste de 15h en la implementaci´on de la aplicaci´on web, debido al tratamiento de minimizaci´on aplicado ante estas situaciones de planificaciones optimistas el desajuste no fue demasiado importante y apenas impact´o la planificaci´on. El segundo riesgo produjo un retraso de 1 mes en la planificaci´on (el mes de Mayo), debido a una acumulaci´on de tareas no relativas al proyecto por parte del desarrollador. En este mes no se pudo avanzar en el desarrollo del proyecto, lo que produjo que no se continuara con el hasta principios de junio. Este riesgo no estaba tratado debido a que no existen medidas posibles para solventarlo de forma satisfactoria, por lo que se decidi´o asumir sus consecuencias. La planificaci´on real se muestra en la figura 2.11 Figura 2.11: Planificaci´on real del proyecto 2.5. Gesti´on de la configuraci´on Los diferentes elementos que constituyen el software que se va a construir en este proyecto deben de estar sometidos a una gesti´on de la configuraci´on, esto incluye controlar las diferentes versiones del c´odigo o de los elementos del software que se generen durante el transcurso del proyecto, tambi´en se debe de asegurar la integridad de las versiones en caso de que sea necesario volver a alguna versi´on anterior del c´odigo generado. Adem´as, es necesario gestionar los cambios que se realizan durante la construcci´on 2.5. GESTI ´ ON DE LA CONFIGURACI ´ ON 27 del c´odigo del software, el modo de aplicar estos cambios debe de estar gestionado por un proceso de gesti´on de cambios en el que se indica el modo de realizar los cambios. En esta secci´on se indican las distintas herramientas o procesos que se utilizan para realizar la correcta gesti´on de la configuraci´on de los elementos del software de este proyecto. 2.5.1. Elementos de configuraci´on Antes de proceder a definir el sistema de gesti´on de la configuraci´on y el proceso de gesti´on de cambios es necesario identificar que elementos de configuraci´on ser´an los gestionados por nuestro proceso de gesti´on de la configuraci´on. Los elementos de configuraci´on que se han identificado en este proyecto son los siguientes: C´odigo de la aplicaci´on cliente C´odigo del servidor Memoria del proyecto Estos tres elementos son los que van a ser gestionados por el proceso de gesti´on de la configuraci´on puesto que son propensos a sufrir cambios y van a generarse distintas versiones de cada uno de ellos a lo largo del transcurso del proyecto, adicionalmente es crucial mantener su integridad en caso de que sea necesario volver a una versi´on anterior de uno de ellos. 2.5.2. Sistema de gesti´on de la configuraci´on Para gestionar la integridad de las versiones junto con las distintas versiones del c´odigo generado se utiliza el software de control de versiones Git. El repositorio de los archivos estar´a situado en la plataforma Bitbucket de Atlassian 1, que permite de forma gratuita la creaci´on de repositorios privados o p´ublicos seg´un las necesidades del usuario. En el repositorio se almacenar´a tanto el c´odigo del cliente y del servidor como la memoria del proyecto. 1https://bitbucket.org/ 28 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.5.3. Estructura del repositorio La estructura del repositorio que contendr´a los elementos de la configuraci´on es la siguiente: Repositorio Cliente Servidor Memoria Figura 2.12: Estructura del repositorio En la carpeta Cliente se incluye el c´odigo de la aplicaci´on relativo a la interfaz web (Front end), junto con sus pruebas y archivos auxiliares (im´agenes, iconos, librer´ıas, etc.). En la carpeta Servidor se incluye el c´odigo de la capa de servicios REST (Back end), adicionalmente se incluyen las librer´ıas o archivos auxiliares que se necesiten para que el c´odigo sea funciona. Finalmente en la carpeta Memoria se a˜naden los archivos relativos a la presente memoria, esto incluye el documento actual junto con las figuras y los diagramas que se incluyen en el. Para el cliente y el servidor se utiliz´o adicionalmente NPM (Node Package Manager), de modo que existe una carpeta llamada node modules que contiene los paquetes instalados por esta herramienta junto con el ´arbol de dependencias en un archivo llamado package.json, esto es utilizado por NPM para instalar y controlar las dependencias de la aplicaci´on, de modo que solo es necesario subir al repositorio el c´odigo fuente base de la aplicaci´on junto con el archivo que indica sus dependencias. 2.5.4. Gesti´on de cambios En este proyecto solo existe un colaborador, por lo que no se puede dar la posibilidad de incompatibilidades entre cambios a diferentes versiones del c´odigo, por ello no ser´a necesario aplicar un proceso de gesti´on de cambios complejo al proyecto ni ser´a necesario la creaci´on de un sistema de gesti´on de cambios completo. En su lugar los cambios en el c´odigo se limitan a simples anotaciones escritas por el propio colaborador para indicar los cambios, estas etiquetas ser´a registradas por el software de control de versiones, de modo que es posible seguir su 2.6. GESTI ´ ON DE COSTES 29 eliminaci´on y a˜nadido de forma sencilla. Las anotaciones contempladas son las siguientes: TODO: Indica que la funcionalidad o cambio aun no se ha realizado y est´a pendiente de realizarse. FIXME: Indicia que hay un fallo en una funcionalidad o secci´on del c´odigo que no est´a corregida. TESTME: Indica que falta comprobar el funcionamiento de la funcionalidad ante casos de prueba. 2.6. Gesti´on de costes En este apartado se proceder´a a realizar el an´alisis de los costes del proyecto, cabe mencionar que aunque este proyecto es de ´ambito acad´emico y solo ser´a desarrollado por una persona es importante realizar este tipo de gestiones pues seg´un The Standish Group [1], un 31 % de los proyectos de software fracasan y no se llegan a completar, mientras que un 52.7 % terminan con un 189 % de exceso de costes, quedando solo un 16 % de proyectos que terminan sin exceso de costes y en el tiempo asignado. El an´alisis que se realizar´a en esta secci´on tendr´a como objetivo contabilizar los costes del proyecto si este se desarrollase en un ´ambito no acad´emico. Los tipos de costes contemplados para este proyecto son los siguientes: Costes directos: Aquellos f´acilmente derivables de la realizaci´on del proyecto, son f´aciles de calcular y de estimar puesto que est´an relacionados con el propio proyecto, como el salario de los recursos humanos. Costes indirectos: Son dif´ıciles de calcular puesto que no est´an directamente relacionados con el proyecto y suelen ser tangenciales al mismo, como el consumo el´ectrico o de agua. 2.6.1. Costes directos Los costes directos atribuibles a este proyecto son los correspondientes al salario del desarrollador del mismo, los tutores del proyecto desempe˜nan el rol de clientes para este proyecto de modo que no se tienen en cuenta como posibles recursos humanos a la hora de calcular los costes del personal. Bas´andonos en el estudio realizado por Vitae Consultores [2], tomando como 36 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS le conceda a la aplicaci´on, tambi´en condiciona las comunicaciones con ellos en caso de que estos actores sean los clientes que encargan el proyecto. Enfocando el an´alisis con una base sobre los usuarios que van a utilizar nuestra aplicaci´on incrementa las probabilidades de ´exito del proyecto adem´as de disminuir los cambios posibles en los requisitos de la aplicaci´on. En caso de existir m´ultiples actores con distintos intereses, es de suma importancia intentar identificar conflictos de intereses entre los actores del sistema (en caso de que existan) que podr´ıan provocar, o bien que los requisitos de la aplicaci´on sufriesen cambios, o bien que apareciesen nuevos requisitos en momentos inesperados del proyecto. En nuestra aplicaci´on solo existe un actor, el cual llamaremos Usuario, por lo tanto no es necesario realizar un an´alisis de conflictos de intereses y adem´as se podr´a centrar el an´alisis del ´unico actor de una forma m´as exhaustiva, los siguientes apartados se centrar´an exclusivamente en analizar este actor. 3.1.1. Intereses del usuario Los intereses principales del usuario general de la aplicaci´on son los siguientes: Crear y editar plantillas de informes los m´as r´apido y c´omodamente posible. Reutilizar las plantillas de informes m´ultiples veces. Crear plantillas cuyo modelo de datos representado es f´acilmente alterable y editable. Introducir variables y fuentes de datos de un modelo de datos en el contenido de la plantilla. Generar un informe completo en base a una plantilla de forma c´omoda y simple. Con estos intereses identificados se pueden identificar requisitos no funcionales m´as f´acilmente, adem´as de extraer algunos requisitos funcionales no pedidos expl´ıcitamente por el cliente. 3.1.2. Perfil de conocimiento del usuario De media general, el usuario al que est´a destinada la aplicaci´on, poseer´a conocimientos altos en el sector de las TIC, adem´as su nivel t´ecnico es de nivel experto en cuanto a materias relacionadas con la generaci´on y manipulaci´on de informes de todo tipo. 3.2. ESPECIFICACI ´ ON DE REQUISITOS 37 Puesto que el usuario tiene un perfil alto de conocimientos en las TIC no va a ser necesario aplicar un nivel extremadamente alto de usabilidad. Adicionalmente, es posible incluir toda clase de tecnicismos relacionados con la materia en la aplicaci´on sin riesgo a que el usuario no los comprenda. 3.1.3. Factores de rechazo del usuario Los factores que pueden provocar que el usuario rechace la aplicaci´on de forma absoluta son los siguientes: Generar un informe dura mucho tiempo o directamente no generarlo. Editar el modelo de datos que representa la plantilla es extremadamente complejo. Falta de componentes que representen informaci´on estructurada como tablas o gr´aficas. Usar la aplicaci´on es dif´ıcil o tedioso. No poder inyectar variables o fuentes de datos en la plantilla. Con estos factores identificados, se pueden extraer una mayor cantidad de requisitos tanto funcionales como no funcionales y evitar posibles errores de dise˜no e implementaci´on en el futuro. 3.2. Especificaci´on de requisitos Con los usuarios analizados se puede proceder a realizar un an´alisis de los posibles requisitos que debe de cumplir la aplicaci´on, tanto desde un punto de vista funcional como de rendimiento, no funcional o de informaci´on. Los requisitos que se identifiquen tendr´an una prioridad, la prioridad depender´a del valor que el usuario o cliente conceda al requisito que se haya extra´ıdo. En esta secci´on se ha utilizado la siguiente escala: Cr´ıtica: El requisito es indispensable, la aplicaci´on no sirve si no se cumple. Alta: El requisito tiene un valor considerable para el cliente o usuario, su ausencia puede provocar el rechazo o inconformidad de uso. 38 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Media: El requisito tiene un valor medio para el cliente o usuario, su ausencia puede notarse aunque no implicar´ıa a grandes rasgos una carencia grave. Baja: El requisito tiene una prioridad baja para el cliente, su ausencia no provoca efectos negativos para el cliente o usuario. 3.2.1. Requisitos funcionales ID RF-01 Nombre Creaci´on de plantillas nuevas Descripci´on La aplicaci´on debe de permitir la creaci´on de plantillas nuevas cuyo contenido por defecto ser´a un folio de tama˜no A4 en blanco. Prioridad Cr´ıtica ID RF-02 Nombre Guardado de plantillas Descripci´on La aplicaci´on debe de permitir el guardado de las plantillas que se hayan generado en la base de datos. Prioridad Cr´ıtica ID RF-03 Nombre Carga de plantillas desde la base de datos Descripci´on La aplicaci´on debe de permitir al usuario la carga de plantillas previamente creadas. Prioridad Cr´ıtica ID RF-04 Nombre Borrado de plantillas Descripci´on La aplicaci´on debe de permitir al usuario borrar aquellas plantillas que ya no considere necesarias. Prioridad Cr´ıtica ID RF-05 Nombre Inserci´on de componentes de texto en las plantillas Descripci´on La aplicaci´on permitir´a al usuario la inserci´on o a˜nadido de un n´umero indeterminado de elementos de texto (t´ıtulos, p´arrafos y listas) a la plantilla que est´e editando. Prioridad Cr´ıtica 3.2. ESPECIFICACI ´ ON DE REQUISITOS 39 ID RF-06 Nombre Inserci´on de im´agenes en las plantillas Descripci´on La aplicaci´on permitir´a al usuario la inserci´on o a˜nadido de un n´umero indeterminado de im´agenes cargadas desde el almacenamiento local del usuario en la plantilla que est´e editando. Prioridad Alta ID RF-07 Nombre Inserci´on de tablas en las plantillas Descripci´on La aplicaci´on permitir´a al usuario la inserci´on o a˜nadido de un n´umero indeterminado de tablas en la plantilla que est´e editando. Prioridad Cr´ıtica ID RF-08 Nombre Inserci´on de gr´aficas de datos en las plantillas Descripci´on La aplicaci´on permitir´a al usuario la inserci´on o a˜nadido de un n´umero indeterminado de gr´aficas de datos (barras, ´area, disper- si´on, sectores, l´ıneas y radar) en la plantilla que est´e editando. Prioridad Cr´ıtica ID RF-09 Nombre Inserci´on de mallas de celdas en las plantillas Descripci´on La aplicaci´on permitir´a al usuario la inserci´on o a˜nadido de un n´umero indeterminado de mallas de celdas en la plantilla que est´e editando. Prioridad Alta ID RF-10 Nombre Definici´on de variables de contenido din´amico Descripci´on La aplicaci´on permitir´a al usuario la definici´on de un n´umero indeterminado de variables a nivel de plantilla. Prioridad Cr´ıtica ID RF-11 Nombre Mapeo de variables a rutas de JSON Descripci´on La aplicaci´on permitir´a al usuario realizar un mapeo de rutas del archivo en formato JSON que haya cargado en la aplicaci´on en las variables que haya declarado. Prioridad Cr´ıtica 40 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS ID RF-12 Nombre Carga de archivos JSON a nivel de aplicaci´on Descripci´on La aplicaci´on permitir´a al usuario la carga de archivos en formato JSON para su posterior mapeo de rutas en la secci´on de variables. Prioridad Cr´ıtica ID RF-13 Nombre Inyecci´on de variables en componentes de texto Descripci´on La aplicaci´on permitir´a al usuario la inyecci´on de variables en componentes de texto mediante la sintaxis {{nombre de la variable}}. Prioridad Cr´ıtica ID RF-14 Nombre Carga de fuente de datos en tablas Descripci´on La aplicaci´on permitir´a al usuario la carga de datos din´amicos desde una variable declarada, la fuente de datos ser´a seleccionada como una propiedad de la tabla. Prioridad Cr´ıtica ID RF-15 Nombre Carga de fuente de datos en gr´aficas Descripci´on La aplicaci´on permitir´a al usuario la carga de datos din´amicos desde una variable declarada, la fuente de datos ser´a seleccionada como una propiedad de la gr´afica. Prioridad Cr´ıtica ID RF-16 Nombre Reemplazo y carga de variables Descripci´on La aplicaci´on permitir´a a voluntad del usuario reemplazar las variables que ha inyectado en los componentes de texto y cargar las fuentes de datos de las tablas, listas y gr´aficas que haya declarado en la plantilla. Prioridad Cr´ıtica 3.2. ESPECIFICACI ´ ON DE REQUISITOS 41 ID RF-17 Nombre Impresi´on a PDF de la plantilla con variables reemplazadas Descripci´on La aplicaci´on permitir´a al usuario la opci´on de generar un archivo en formato PDF a partir de la plantilla que ha generado substituyendo todas la variables y cargando todas las fuentes de datos declaradas por el usuario, el PDF generado tendr´a un tama˜no por p´agina de un folio DIN A4 y podr´a ser descargado por el usuario una vez generado. Prioridad Cr´ıtica ID RF-18 Nombre Edici´on del tama˜no y desplazamiento de un componente Descripci´on La aplicaci´on permitir´a al usuario editar el ancho y el desplazamiento hacia la derecha que ocupan los componentes que haya en la plantilla. Prioridad Alta ID RF-19 Nombre Borrado de componentes y filas de componentes Descripci´on La aplicaci´on permitir´a al usuario borrar cualquier componente (o una fila entera de ellos) que haya a˜nadido a la plantilla que est´e editando. Prioridad Cr´ıtica ID RF-20 Nombre Opciones de decoraci´on, alineaci´on y enumeraci´on a los componentes de texto Descripci´on La aplicaci´on permitir´a al usuario definir la alineaci´on del contenido de los componentes de texto (centrado, izquierda, derecha, justificado) junto con las opciones de decoraci´on b´asicas (negrita, cursiva y subrayado), en caso de ser una lista se podr´a definir si es ordenada o no ordenada. Prioridad Alta 42 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS ID RF-21 Nombre Edici´on de componentes Descripci´on La aplicaci´on permitir´a al usuario la edici´on del contenido de cualquier componente presente en la plantilla (Cambiar el contenido, opciones de decoraci´on, a˜nadir/quitar filas de datos a las tablas o series de datos a las gr´aficas). Prioridad Cr´ıtica ID RF-22 Nombre A˜nadido de celdas en las mallas Descripci´on La aplicaci´on permitir´a al usuario el a˜nadido de un n´umero indeterminado de celdas en un componente de tipo malla. Prioridad Cr´ıtica ID RF-23 Nombre Edici´on de propiedades de las celdas de una malla Descripci´on La aplicaci´on permitir´a al usuario definir la altura que ocupa una celda, as´ı como su ancho, su posici´on dentro de la malla, as´ı como su contenido textual, aplic´andose las mismas propiedades que un componente de tipo texto, el usuario podr´a decidir en cualquier momento si borrar dicha celda de la malla. Prioridad Cr´ıtica ID RF-24 Nombre Inserci´on de componentes nuevos mediante Drag and Drop Descripci´on La aplicaci´on permitir´a al usuario la creaci´on de nuevos componentes utilizando la t´ecnica de Drag and Drop para arrastrarlos desde el men´u de componentes a la posici´on deseada en la plantilla. Prioridad Cr´ıtica ID RF-25 Nombre Alteraci´on de la posici´on de componentes existentes mediante Drag and Drop Descripci´on La aplicaci´on permitir´a al usuario alterar la posici´on de componentes existentes en la plantilla arrastr´andolos y solt´andolos en cualquier posici´on disponible en la plantilla. Prioridad Cr´ıtica 3.2. ESPECIFICACI ´ ON DE REQUISITOS 43 ID RF-26 Nombre Creaci´on de versiones de una plantilla Descripci´on La aplicaci´on permitir´a al usuario definir versiones para una plantilla determinada, de modo que estas se guardaran con el mismo nombre de plantilla en la base de datos, aunque su contenido ser´a diferente. Prioridad Media ID RF-27 Nombre Edici´on de versiones de una plantilla Descripci´on La aplicaci´on permitir´a al usuario cargar una versi´on que el seleccione de una plantilla determinada. Prioridad Media ID RF-28 Nombre Borrado de una versi´on Descripci´on La aplicaci´on permitir´a al usuario borrar una versi´on determinada de una plantilla que el seleccione. Prioridad Media ID RF-29 Nombre Carga de fuentes de datos en listas Descripci´on La aplicaci´on permitir´a al usuario la carga de datos din´amicos desde una variable declarada, la fuente de datos ser´a seleccionada como una propiedad de la lista. Prioridad Media ID RF-30 Nombre Carga de m´ultiples archivos JSON en la aplicaci´on Descripci´on La aplicaci´on permitir´a al usuario la carga de m´ultiples archivos en formato JSON, de modo que el usuario podr´a alternar entre uno o otro para su uso en la declaraci´on de variables. Prioridad Cr´ıtica 44 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS ID RF-31 Nombre Impresi´on de m´ultiples informes Descripci´on La aplicaci´on permitir´a al usuario la impresi´on de m´ultiples informes de forma simult´anea ante una plantilla determinada, de modo que la aplicaci´on generar´a un informe por cada JSON cargado en la aplicaci´on, reemplazando las variables por los valores de cada JSON. Prioridad Alta 3.2.2. Requisitos no funcionales ID RNF-01 Nombre La aplicaci´on debe de ser en Web Descripci´on La aplicaci´on debe de ser web para asegurar mayor compatibilidad y portabilidad. Prioridad Cr´ıtico ID RNF-02 Nombre La plantilla generada debe de guardarse en formato JSON Descripci´on La plantilla que genere el usuario se guardar´a como un objeto en formato JSON que represente la estructura y contenido de la plantilla. Prioridad Cr´ıtico ID RNF-03 Nombre Utilizaci´on de servicios Web Descripci´on Para implementar el lado servidor que se encargar´a de proporcionar las funcionalidades de guardado, carga y borrado de plantillas es necesario implementarlas como servicios RESTful para garantizar compatibilidad con la aplicaci´on web. Prioridad Cr´ıtico ID RNF-04 Nombre Uso de tecnolog´ıas web Descripci´on Puesto que la aplicaci´on ser´a en web, se deber´an de utilizar las tecnolog´ıas de desarrollo web como HTML5, CSS3 y JavaScript. Prioridad Cr´ıtico 3.2. ESPECIFICACI ´ ON DE REQUISITOS 45 ID RNF-05 Nombre Base de datos NoSQL Documental Descripci´on Para almacenar las plantillas en formato JSON se utilizar´a una base de datos documental. Prioridad Cr´ıtica ID RNF-06 Nombre Uso de Node.js Descripci´on Para imprimir el PDF del informe es necesario utilizar PhantomJS, el cual requiere de la utilizaci´on de Node.js para ejecutarlo. Prioridad Cr´ıtica ID RNF-07 Nombre El informe enviado al servicio de PDF debe estar en HTML Descripci´on El servicio de generaci´on de PDF debe ´unicamente recibir un HTML a partir del cual generar´a el PDF. Prioridad Cr´ıtica ID RNF-08 Nombre Uso de JSON a nivel interno Descripci´on La aplicaci´on debe de tratar todos sus datos a nivel interno en JSON, por lo tanto en caso de recibir datos desde bases de datos relacionales o CSV estos deber´an de ser traducidos a JSON. Prioridad Cr´ıtica 3.2.3. Requisitos de informaci´on ID RI-01 Nombre Variable de texto Descripci´on El sistema debe de almacenar las variables de texto que declare el usuario junto con la configuraci´on que el establezca. Requisitos asociados RF-10, RF-11 Datos espec´ıficos - Nombre de la variable - Configuraci´on de la variable - Ruta del JSON Prioridad Cr´ıtica 52 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS ID CU-10 Nombre Carga y reemplazo de variables Requisitos asociados RF-16 Descripci´on El sistema deber´a de permitir al usuario reemplazar las variables inyectadas por su valor. Precondiciones Existe una plantilla con un componente, este componente debe de tener inyectada una variable (como texto o como fuente de datos), la variable debe de estar definida y hay un archivo JSON cargado con datos. Postcondiciones Se reemplazan las variables de la plantilla por su valor. Pasos 1 - El usuario selecciona la opci´on de Reemplazar variables. 2 - La aplicaci´on busca las variables en los componentes y las reemplaza por su valor. 3 - La plantilla actualiza su estado para mostrar el contenido de todas las variables. Prioridad Cr´ıtica Criterio de validaci´on El usuario puede reemplazar las variables definidas en la plantilla. ID CU-11 Nombre Carga de archivos JSON a nivel de aplicaci´on Requisitos asociados RF-12, RF-30 Descripci´on El sistema deber´a de permitir al usuario cargar m´ultiples archivos JSON en la aplicaci´on para dar valor a las variables que el defina en la plantilla. Precondiciones Existe una plantilla creada Postcondiciones Se carga el archivo (o los archivos) JSON en la aplicaci´on Pasos 1 -El usuario selecciona la secci´on de Variables en el men´u de navegaci´on. 2 - La aplicaci´on cambia a la vista de variables. 3 - El usuario selecciona la opci´on de Cargar archivo JSON. 4 - El usuario selecciona los archivos JSON de su almacenamiento local que desea cargar en la aplicaci´on. 5 - La aplicaci´on carga los archivos JSON seleccionados. 6 - El usuario selecciona uno de los archivos cargados como archivo actual para dar valor a las variables. Prioridad Cr´ıtica Criterio de validaci´on El usuario pueda cargar un n´umero indeterminado de archivos JSON en la aplicaci´on. 3.2. ESPECIFICACI ´ ON DE REQUISITOS 53 ID CU-12 Nombre Impresi´on a PDF de informes Requisitos asociados RF-17, RF-31 Descripci´on El sistema deber´a de permitir al usuario la generaci´on de un informe por cada archivo JSON cargado en la aplicaci´on, substituyendo las variables definidas por los valores especificados en cada JSON. Precondiciones Existe una plantilla con componentes con variables inyectadas adem´as existe un archivo JSON cargado en la aplicaci´on. Postcondiciones Se crea un informe con las variables reemplazadas en PDF por cada archivo JSON cargado en la aplicaci´on Pasos 1 - El usuario selecciona la opci´on de Imprimir todos en la barra de acciones. 2 -La aplicaci´on substituye las variables en la plantilla y pasa el informe a formato PDF (Este paso se repite por cada archivo JSON presente en la aplicaci´on). Prioridad Cr´ıtica Criterio de validaci´on El usuario pueda obtener un informe en formato PDF con las variables reemplazadas por cada archivo JSON cargado en la aplicaci´on. 3.2.5. Matrices de trazabilidad OBJ-001 OBJ-002 OBJ-003 CU-01 X CU-02 X CU-03 X CU-04 X X X CU-05 X X X CU-06 X X CU-07 X X CU-08 X X CU-09 X X CU-10 X X CU-11 X X CU-12 X X X Cuadro 3.1: Matriz de trazabilidad Caso de uso - Objetivos 54 CAP´ ITULO 3. AN ´ ALISIS DE REQUISITOS Entregable 1 Entregable 2 Entregable 3 Entregable Final CU-01 X X X X CU-02 X X X X CU-03 X X X X CU-04 X X CU-05 X X CU-06 X X CU-07 X X CU-08 X X X CU-09 X X X CU-10 X X X CU-11 X X X CU-12 X Cuadro 3.2: Matriz de trazabilidad Caso de uso-Entregables Cap´ıtulo 4 An´alisis de tecnolog´ıas y herramientas A la hora de realizar la implementaci´on o dise˜no de un sistema siempre existen distintas alternativas tecnol´ogicas para hacerlo. Es importante analizar este tipo de tecnolog´ıas o herramientas antes de decidir cual utilizar para desarrollar el sistema, pues eligiendo una o otra produce alteraciones substanciales en las fases de dise˜no e implementaci´on y pruebas, lo que provoca que estas tengan que ser adaptadas a las decisiones tecnol´ogicas que se realicen en esta fase. Adicionalmente, destacar que la elecci´on de una tecnolog´ıa debe tener como criterio principal de selecci´on permitir que el sistema a desarrollar cumpla con los requisitos contemplados en el proyecto, adem´as de facilitar trabajo al desarrollador. 4.1. Servicios web A la hora de transmitir informaci´on entre distintas aplicaciones distribuidas nos encontramos con distintos paradigmas (paso de mensajes, llamada de procedimiento remoto, sockets, etc.), la decisi´on de cual aplicar depende del contexto de la aplicaci´on y del proyecto a desarrollar. Uno de los paradigmas m´as utilizados en desarrollo de aplicaciones web actualmente son los servicios web, que consiste en acceder a m´etodos remotos a trav´es de la web [3], generalmente utilizando HTTP y transmitiendo un mensaje de tex- to que debe de ser interpretado por el servidor para la realizaci´on de la operaci´on que el cliente ha solicitado, adicionalmente los mensajes de texto pueden ser documentos en formato XML o JSON, as´ı como texto plano o tramas de datos, el 55 56 CAP´ ITULO 4. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS formato que se utilice depende del servicio y del proveedor del mismo. Gracias a esto se garantiza interoperatividad entre distintos lenguajes de programaci´on o implementaciones de tecnolog´ıas, ya que todos ellos adoptar´an un est´andar para transmitir la informaci´on y entenderse. Para este proyecto, el requisito no funcional RNF-03 impone la restricci´on de que el paradigma a utilizar sean servicios web para cumplir las funcionalidades de almacenamiento y manipulaci´on de plantillas generadas con la aplicaci´on, por lo tanto el uso de este paradigma de computaci´on distribuida es obligatorio, y aunque no lo fuese es recomendable al tratarse de una aplicaci´on web. Adicionalmente se establece en ese mismo requisito que los servicios web deben de estar implementados como servicios RESTful, por lo tanto otras alternativas como SOAP quedan descartadas para implementar los servicios web. Para implementar una API que contenga los servicios web existen m´ultiples posibilidades o alternativas, debido a que existe desacoplamiento entre el cliente y el servidor se puede utilizar cualquier lenguaje de programaci´on para hacerlos y actualmente existen m´ultiples frameworks o librer´ıas para cada lenguaje que proporcionan facilidades para implementar servicios REST. A continuaci´on se muestran las distintas alternativas que se analizaron y cual se opt´o por utilizar en este proyecto. 4.1.1. Jersey y Java Jersey [4] es un framework que permite el desarrollo de servicios web REST- ful en Java. Permite programar los servicios como funciones Java est´andar, las operaciones de Jersey est´an implementadas siguiendo las especificaci´on de la API JAX-RS [5], por ello Jersey utiliza toda clase de anotaciones para describir como servicios web las funciones Java programadas. Mediante el uso de la anotaci´on @Path se definen las URIs de los servicios, adicionalmente las las anotaciones @POST,@GET,@PUT y@DELETE se define que tipo de operaci´on HTTP utilizan los servicios para invocarse. Se puede definir adicionalmente si el servicio produce o consume informaci´on mediante las anotaciones @Consumes y@Produces. Actualmente, esta bajo licencia de uso doble CDDL versi´on 1.1 y GPL ver- si´on 2. 4.1. SERVICIOS WEB 57 4.1.2. Express.js y JavaScript Express.js [6] es un framework de desarrollo web para Node.js, permite de forma muy sencilla implementar servicios REST mediante el uso de funciones JavaScript espec´ıficas del framework. Las funciones: express().post(), express().get(), express.put() y express().delete() permiten crear servicios con cada una de la operaciones HTTP permitidas para los servicios REST. Adicionalmente, se integra perfectamente con otras funcionalidades de Node.js y existen multitud de paquetes y librer´ıas para expandir su abanico de funcionalidades, en concreto, contiene paquetes para trabajar directamente con bases de datos documentales como MongoDB de forma sencilla. Su licencia de uso es MIT. 4.1.3. Rocket y Rust Rocket [7] es un framework para el reciente lenguaje Rust [8] que est´a siendo desarrollado por Mozilla, el cual es un lenguaje dise˜nado para ser seguro, concurrente y eficiente. Su funcionamiento esta basado en los principios de Jersey, mediante el uso de anotaciones de la forma #[] se pueden definir las funciones programadas en Rust como servicios web. En concreto se pueden utilizar las anotaciones: #[get()],#[post()],#[put()] y #[delete()] para definir el tipo de operaciones HTTP que se van a utilizar en la funci´on programada en Rust. Esta bajo licencia MIT y Apache 2.0. 4.1.4. Conclusi´on Analizando las tres posibilidades anteriores se ha determinado que el framework y el lenguaje que se va a utilizar para implementar los servicios REST es Express.js y JavaScript. Los motivos de esta decisi´on son los siguientes: Maneja de forma nativa el formato JSON utilizado por los servicios REST. Es extremadamente sencillo implementar servicios REST en el. 58 CAP´ ITULO 4. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS Soportado en la mayor´ıa de las plataformas puesto que corre en Node.js. Tiene toda clase de paquetes para trabajar con bases de datos NoSQL documentales con suma facilidad (RNF-05). Hay que usar Node.js para imprimir el PDF mediante el uso de PhantomJS (RNF-06). 4.2. Tecnolog´ıas web est´andar Los requisitos RNF-01 yRNF-04 establecen que la aplicaci´on de interacci´on directa con el usuario (Front end) debe de estar implementada usando tecnolog´ıas web. Las tecnolog´ıas web est´andar actuales son : HTML5,CSS3 yJavaScript. A lo largo de este apartado se definen las tres adem´as de su utilidad y funcionalidad en este proyecto. 4.2.1. HTML5 HTML es el lenguaje b´asico para representar los elementos de una aplicaci´on web. Se trata de un lenguaje desarrollado y estandarizado por W3C 1y WHATWG 2. HTML define una p´agina web como un conjunto de etiquetas o marcas, su anidamiento y orden en el documento definir´a el contenido de la p´agina web. Actualmente HTML se encuentra en su quinta entrega, m´as conocida como HTML5, esta versi´on incluye nuevas etiquetas sem´anticas que facilitan el desarrollo de aplicaciones web, como por ejemplo: main para el contenido principal, footer para el pie de p´agina, header para el encabezado de la p´agina o nav para la navegaci´on de la p´agina. Adicionalmente HTML dispone de nuevas APIs como canvas para el pintado de contenido en una p´agina web o Drag and Drop para arrastrar y soltar elementos HTML presentes en el documento de la p´agina web. 1https://www.w3.org/ 2https://whatwg.org/ 4.2. TECNOLOG´ IAS WEB EST ´ ANDAR 59 4.2.2. CSS3 La definici´on de la apariencia de un elemento definido en el lenguaje HTML se realiza mediante el uso de hojas de estilo en cascada, o m´as bien conocidas como Cascading Style Sheets (CSS). CSS permite mediante la definici´on de reglas aplicar estilo a los elementos HTML incluidos en una p´agina web, dichas propiedades abarcan desde el color de los elementos, tama˜no de fuente, bordes de los elementos y m´argenes a posici´on de los elementos, modo de visualizaci´on y tama˜no de los mismos entre otras propiedades. Mediante el uso de CSS se programa la visualizaci´on de una p´agina web de forma completa por parte del usuario final de la aplicaci´on. Actualmente la versi´on de CSS en la que se est´a trabajando es CSS3 3, aunque su implementaci´on no es absoluta en todos los navegadores si se ha alcanzado un gran progreso en las funcionalidades que contempla. 4.2.3. JavaScript JavaScript es el lenguaje de programaci´on de alto nivel utilizado a nivel web para dotar a las p´aginas web de contenido din´amico. Se trata de un lenguaje de tipado d´ebil y din´amico basado en prototipos, adem´as es multiparadigma ya que incorpora paradigmas de programaci´on imperativa, funcional y orientada a objetos. Fue desarrollado por Netscape Communications Corporation yMozilla Foundation 4y estandarizado por ECMA 5. JavaScript en conjunto con la API DOM permite acceder a los elementos HTML y CSS de la p´agina web y modificarlos, a˜nadiendo m´as elementos o elimin´andolos si es necesario. De este modo se puede modificar el contenido de la p´agina web de forma din´amica seg´un el usuario va produciendo eventos de interacci´on, como pulsar un bot´on o rellenar un formulario. Actualmente JavaScript est´a en la versi´on ES8, o conocido tambi´en como EC- MAScript 2017 [9], esta versi´on incorpora funcionalidades de programaci´on adicionales como funciones as´ıncronas, rellenado de cadenas de texto o obtenci´on de propiedades de objetos, esta versi´on est´a implementada actualmente en casi todos los navegadores modernos. Adicionalmente, ES8 incluye ES6, una de las actualizaciones m´as importantes de JavaScript, en la que se incluyen lambdas y se refuerza el paradigma de pro- 3https://developer.mozilla.org/en-US/docs/Web/CSS/CSS3 4https://www.mozilla.org/en-US/foundation/ 5https://www.ecma-international.org/ 60 CAP´ ITULO 4. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS gramaci´on funcional del lenguaje. Debido a su extenso uso existen multitud de librer´ıas y frameworks que permiten agilizar el desarrollo en JavaScript de p´aginas web. 4.2.4. JSON JSON [10] o JavaScript Object Notation es el formato de representaci´on e intercambio de datos utilizado por excelencia en JavaScript. La representaci´on de un objeto en formato JSON se basa en la utilizaci´on de pares {clave: valor}, de modo que es posible representar objetos complejos mediante el uso de un formato sencillo, siendo este formato f´acil de comprender por un humano y f´acil de traducir para una m´aquina. El formato JSON es utilizado en JavaScript para representar los objetos que manipula y crea, sin embargo el uso de JSON se ha propagado a algunas de las bases de datos documentales NoSQL, de modo que almacenan los documentos como un objeto en formato JSON, o en todo caso como un BSON (JSON en binario), y utilizan un sistema de consultas basadas en JSON. 4.3. Frameworks y librer´ıas Para agilizar el trabajo a realizar o poder realizar ciertas funcionalidades en un proyecto de software se pueden utilizar librer´ıas o frameworks. Puesto que esta aplicaci´on se sit´ua en el contexto web, existen multitud de frameworks y librer´ıas de uso libre que se pueden utilizar para realizar este proyecto. Debido a su enorme cantidad y a su diversidad no es posible definir todas las alternativas posibles en esta secci´on, por ello solo se van a mencionar aquellas que se seleccionaron junto a las razones que determinaron la decisi´on. 4.3.1. TypeScript TypeScript [11] es un lenguaje de superconjunto de JavaScript desarrollado y mantenido por Microsoft y bajo licencia Apache 2.0. El prop´osito de TypeScript es introducir tipado est´atico a JavaScript, de modo que el c´odigo programado se vuelve declarativo al introducir tipos de forma est´atica en el c´odigo JavaScript evitando errores comunes de programaci´on en JavaScript. 4.3. FRAMEWORKS Y LIBRER´ IAS 61 Puesto que es un lenguaje de superconjunto, la escritura de c´odigo TypeScript incluye tanto lenguaje JavaScript como c´odigo no-JavaScript, por ello TypeScript utiliza un compilador propio que traduce estas directivas no-JavaScript a c´odigo equivalente JavaScript que puede ser interpretado por cualquier navegador. Adicionalmente, TypeScript cuenta con un conjunto de funcionalidades adicionales como enums, interfaces, intersecci´on de tipos, tipos gen´ericos, namespaces, s´ımbolos, mapas, propiedades, etc. Adem´as, se puede integrar con los principales frameworks de desarrollo web, como AngularJS, React, Express.js o Vue.js de forma sencilla. Este lenguaje se ha seleccionado como tecnolog´ıa de desarrollo debido a su compatibilidad con JavaScript normal, f´acil integraci´on con frameworks de desarrollo web y a las funcionalidades de programaci´on orientada a objetos adicionales que proporciona. Tambi´en mencionar que la principal causa de esta elecci´on es el tipado est´atico que introduce, de modo que se puede desarrollar c´odigo declarativo libre de errores en tiempo de compilaci´on. 4.3.2. React React [12] es una librer´ıa de JavaScript declarativa y basada en componentes desarrollada por Facebook bajo licencia MIT, que permite desarrollar interfaces de usuario de forma r´apida, sencilla y escalable a costa de una curva considerable de aprendizaje para un desarrollador inexperto. React engloba la visi´on de una p´agina web como un conjunto de componentes peque˜nos que interact´uan entre s´ı, cada uno de ellos tiene su propio estado, el cual se altera seg´un el usuario va interactuando con la p´agina web. En base a esto resalta la principal caracter´ıstica de React que es la eficiencia de actualizaci´on de los componentes mediante su motor de seguimiento, el cual mantiene un seguimiento de los distintos componentes que existan en la p´agina web y solo actualiza aquellos cuyo estado interno cambia, sin necesidad de refrescar la p´agina entera. Al ser basado en componentes, React aplica el patr´on de dise˜no Composite Pattern [13], en el cual los componentes se van englobando unos dentro de otros formando al final un ´unico componente global, pero abstrayendo al programador de tener que realizar la composici´on global. Como consecuencia de lo anterior, es f´acil escalar la aplicaci´on y reutilizar componentes en distintas partes de la aplicaci´on sin necesidad de volver a programarlos. 68 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA esquema de la arquitectura completa del sistema se puede observar en la imagen 5.1 Figura 5.1: Esquema de la arquitectura del sistema El sistema en su conjunto es una aplicaci´on independiente de la plataforma ejecutada sobre un navegador web cualquiera (Google Chrome, Firefox, Safari...), el cliente web contendr´a la interfaz web con que el usuario interact´ua para la creaci´on de plantillas e informes. Mediante esta opci´on se permite la conexi´on de un n´umero indeterminado de clientes al servidor. Ciertas acciones del cliente requerir´an apoyo del servidor, estas acciones se invocan utilizando el protocolo de comunicaci´on HTTP para invocar las acciones de una API REST que el servidor expone. El servidor estar´a ejecut´andose en una m´aquina independiente del cliente y estar´a programado en NodeJS, como se ha dicho antes el servidor expondr´a una API REST con los servicios web de manipulaci´on de plantillas o impresi´on de informes. Finalmente el servidor se comunicar´a con un contenedor de Docker de una base de datos MongoDB para almacenar, extraer o manipular cualquier dato que los clientes necesiten. 5.1.2. Arquitectura global En el nivel m´as alto de abstracci´on tenemos la arquitectura completa del sistema, este dise˜no permite obtener una visi´on r´apida de los componentes principales 5.1. DISE ˜ NO DE LA ARQUITECTURA DEL SISTEMA 69 que forman el sistema sin necesidad de entrar en detalle de como est´a construido cada uno de ellos a nivel de implementaci´on. Figura 5.2: Arquitectura de alto nivel del sistema En la figura 5.2 se muestra un diagrama de arquitectura de alto nivel, en el que se muestran los componentes de mayor alto nivel que forman la aplicaci´on. El requisito RNF-01 establece que la aplicaci´on debe de ser Web, por lo tanto uno de los componentes primigenios que formar´an la aplicaci´on ser´a la interfaz de usuario, que estar´a programada como una aplicaci´on web. Adicionalmente el requisito RNF-03 establece que es necesario la utilizaci´on de servicios web para implementar el lado servidor, por lo tanto se puede extraer que otro componente primigenio que formar´a la aplicaci´on ser´a el Back end (Capa de servicios) que estar´a programado como una API en Node.js. La API del servidor expondr´a servicios web que consumir´a la aplicaci´on web para cumplir con las funcionalidades de manipulaci´on de plantillas que han sido contempladas en la fase de requisitos, como guardado, carga o borrado, adicionalmente proporcionar´a soporte para realizar la impresi´on de informes en formato PDF, tal como establece el requisito RNF-06 que indica que el PDF se debe generar mediante el uso de PhantomJS. En base a lo anterior y al requisito RNF-05, que indica que es necesario el uso de una base de datos NoSQL documental, se extrae el ´ultimo componente primigenio de la aplicaci´on, la base de datos MongoDB, esta base de datos ser´a la utilizada por el servidor para guardar y extraer datos que la aplicaci´on web demande con llamadas a servicios web. Adicionalmente se indica que el entorno en el que se ejecutan tanto el servidor, como la aplicaci´on web es Node.js, mientras que la base de datos MongoDB 70 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA estar´a contenida en un contenedor de Docker para facilitar la movilidad de la base de datos. Visto los componentes primigenios, o de m´as alto nivel, se procede a analizar cada uno de ellos bajando el nivel de abstracci´on, detallando su composici´on interna en mayor detalle y las dependencias externas o internas que presenten en su composici´on. 5.1.3. Arquitectura del cliente web Como se puede observar en la figura 5.3 que viene a continuaci´on, la arquitectura del cliente web se compone de un paquete principal, Layout Principal, en este paquete se integran paquetes m´as peque˜nos y espec´ıficos que componen en su conjunto la aplicaci´on. Figura 5.3: Arquitectura de la aplicaci´on web 5.1. DISE ˜ NO DE LA ARQUITECTURA DEL SISTEMA 71 Los paquetes que integran el Layout Principal son: Panel de componentes: Contiene el panel de los componentes que se pueden a˜nadir a la plantilla. Componentes: Contiene aquellos componentes funcionales que se a˜naden y modifican en la plantilla. Variables: Contiene todo lo relativo a la secci´on de variables y fuentes de datos que se cargan en el informe. Barra de operaciones CRUD: Contiene todo lo relativo a las acciones de creaci´on, guardado, carga y borrado de plantillas. Paneles de edici´on: Contiene paneles de edici´on asociados a cada tipo de componente que se a˜nada a la plantilla. Barra de navegaci´on: Contiene las distintas secciones de la p´agina. Editor: Contiene el layout donde est´a situada la plantilla que se est´a editando, contendr´a todas las operaciones l´ogicas para organizar los componentes que se sit´uen. Todos estos componentes de menor tama˜no se integran mediante composici´on en el componente principal App, de modo que al final quedar´a un ´unico componente que integre todos los dem´as. Adicionalmente, el paquete Layout Principal depende de librer´ıas o componentes adicionales para realizar sus funcionalidades, dichas librer´ıas o componentes est´an indicados en el diagrama mediante el color amarillo, los componentes externos son los siguientes: React: Librer´ıa de React, la aplicaci´on basa su funcionamiento en esta librer´ıa. Moment: Librer´ıa utilizada para formatear fechas como cadenas de texto. ReactDnD: Librer´ıa para implementar Drag and Drop en React. JSONPath: Librer´ıa para hacer consultas de rutas a objetos en formato JSON. Ant Desing Framework: Framework de CSS para React, la aplicaci´on utiliza sus componentes para dar funcionalidad a la interfaz. Reacharts.js: Librer´ıa para representaci´on de gr´aficas. 72 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA DownloadJS: Librer´ıa para ejecutar descargas de archivos en el lado cliente. TypeScript: Compilador de TypeScript, traduce el c´odigo escrito en TypeScript a c´odigo JavaScript ejecutable por el navegador. Los componentes anteriores en conjunto con el paquete Layout Principal permiten el funcionamiento integral de la aplicaci´on, siendo de este modo necesarios para que esta pueda funcionar de forma correcta. 5.1.4. Arquitectura del servidor En la figura 5.4 situada a continuaci´on se muestra la arquitectura del servidor, en su conjunto el servidor est´a formado por un ´unico m´odulo, el M´odulo de servicios web, que incluye todos los servicios web que la aplicaci´on puede invocar para realizar sus funcionalidades. Figura 5.4: Arquitectura del servidor 5.1. DISE ˜ NO DE LA ARQUITECTURA DEL SISTEMA 73 El M´odulo de servicios web a su vez est´a dividido en dos m´odulos, el M´odulo de servicios de impresi´on y el M´odulo de servicios de plantillas. El M´odulo de impresi´on contiene todos los servicios relativos a la impresi´on de archivos en formato PDF, de modo que ser´a el encargado de realizar las llamadas a PhantomJS. El M´odulo de servicios de plantillas incluye los servicios para crear, obtener, modificar y borrar plantillas, el cliente har´a uso de este m´odulo para guardar las plantillas, modificarlas o borrarlas, de modo que este m´odulo ser´a el que interact´ue con las base de datos MongoDB mediante el uso de la API de Mongoose. Ambos m´odulos ser´an integrados mediante composici´on en el componente principal App, que b´asicamente ser´a un enrutador de servicios, pues en el se colgar´an distintos endpoints de servicios, de modo que ser´a f´acil a˜nadir m´as servicios al lado servidor en caso de ser necesario. Las dependencias del M´odulo de servicios web son las siguientes: Express.js: Librer´ıa de Express.js, la API basa su funcionamiento en este framework, proporciona toda clase de funcionalidades y objetos para crear servicios. Cors: Librer´ıa que permite el uso de CORS (Cross Origin Resource Sharing), de modo que el servidor puede realizar llamadas a otros or´ıgenes distintos para obtener recursos. Mongoose: Librer´ıa que proporciona operaciones para trabajar con la base de datos MongoDB desde JavaScript. Phantom: Librer´ıa que expone una API de uso sencillo para trabajar con PhantomJS desde JavaScript. PhantomJS: Navegador sin interfaz gr´afica que puede ser ejecutado por el servidor para tareas de mantenimiento, impresi´on o navegaci´on r´apida. BodyParser: Usado por Express.js para traducir el cuerpo de peticiones HTTP. CookieParser: Usado por Express.js para traducir cookies de peticiones HTTP. Las librer´ıas anteriores en conjunto con los dos m´odulos de servicios forman el servidor al que el cliente har´a peticiones mediante el uso de servicios web para invocar operaciones de manipulaci´on de plantillas o impresi´on de informes. 74 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA 5.2. Patrones arquitect´onicos En esta secci´on se indican los patrones arquitect´onicos utilizados a la hora de desarrollar el sistema. 5.2.1. Arquitectura orientada a servicios El sistema estar´a basada en una arquitectura orientada a servicios, esto implica que se dividir´a la parte cliente (front end) de la parte servidor (back end), el servidor exportar´a un conjunto de funcionalidades como servicios web que el cliente utilizar´a como apoyo para proporcionar una mejor experiencia al usuario. Esta arquitectura permite desacoplar el cliente del servidor, de modo que se aumenta la escalabilidad y mantenimiento del mismo, adem´as permite utilizar lenguajes de programaci´on distintos tanto en el cliente como en el servidor al utilizar el protocolo HTTP para realizar la comunicaci´on entre ambas partes. 5.2.2. Flux Flux es una alternativa al modelo MVC 1tradicional utilizado en desarrollo web, este patr´on arquitect´onico es utilizado por React para estructurar los componentes de la aplicaci´on y el modo en el que ellos interact´uan. Flux se basa en una restricci´on, y es que el e flujo de datos de la aplicaci´on solo puede circular en una direcci´on, esto se logra mediante la definici´on de tres componentes principales: store,view component ydispatcher. Cada store contiene determinados datos que representan la l´ogica de negocio de la aplicaci´on, estos datos son representados por uno o varios view component, adicionalmente un view component puede extraer datos de varios stores, si un view component utiliza un store cualquiera se suscribe a el. Cuando se ejecuta una acci´on en un view component que implica la modificaci´on de los datos almacenados en uno o varios stores, este realiza una llamada al dispatcher, (solo existe un dispatcher en la aplicaci´on) el dispatcher identifica la acci´on y modifica el o los stores afectados por el cambio. Al cambiar un store, los view component que estaban suscritos a dichos stores sea actualizan para reflejar dichos cambios. 1Modelo Vista Controlador: Patr´on arquitect´onico que divide la aplicaci´on en Modelos de datos que contienen la l´ogica de negocio, vistas que representan dichos datos y controladores que definen que vista se representa. 5.3. MODELO DE DATOS 75 Esto permite que no existan complicaciones a la hora de escalar la aplicaci´on ya que hace muy predecible el flujo de datos de la misma. 5.3. Modelo de datos En esta secci´on se especifica la informaci´on que se almacena en la base de datos que utiliza el sistema, puesto que esta base de datos es NoSQL, el modelo de datos no estar´a constituido de tablas y de relaciones entre dichas tablas, si no de documentos, puesto que la base de datos elegida es MongoDB. La informaci´on que se almacena en cada documento es un objeto Plantilla, dicho objeto est´a compuesto por los siguientes campos: Nombre: El nombre que el usuario ha dado a la plantilla (Tipo string). Versi´on: La versi´on que el usuario ha seleccionado para la plantilla (Tipo string). Variables: Conjunto de variables que forman parte de la plantilla (Tipo Array<object>) Componentes: Conjunto de componentes que forman la plantilla (Tipo Array<object>) Las variables de una plantilla son un conjunto de objetos ordenados en un array, cada objeto del array representa una variable y sus campos var´ıan dependiendo de si la variable es de tipo texto o si es una fuente de datos, los campos posibles que tiene una variable son los siguientes: Nombre: Nombre que el usuario ha dado a la variable (Tipo string) Tipo: Tipo de variable (Tipo string controlado por enumerado) Ruta JSON: Ruta de mapeo de JSON (Tipo string oundefined) Propiedad de etiquetas (Columnas): Ruta del JSON para obtener las etiquetas de las columnas (Tipo string oundefined) [Solo en variable TABLE DATA SOURCE] Unidad del eje X: Define la unidad del eje X (Tipo string oundefined) [Solo en variable SCATTER DATA SOURCE] Unidad del eje Y: Define la unidad del eje Y (Tipo string oundefined) [Solo en variable SCATTER DATA SOURCE] Nombre del eje X: Define el nombre del eje X (Tipo string oundefined) [Solo en variable SCATTER DATA SOURCE] 76 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA Nombre del eje Y: Define el nombre del eje Y (Tipo string oundefined) [Solo en variable SCATTER DATA SOURCE] Opacidad de series: Define la opacidad de cada serie (Tipo Array<number> oundefined) [Solo en variables POLAR DATA SOURCE] Color de la series: Define el color de cada serie (TIpo Array<string>oundefined) [Solo en variables CARTESIAN DATA SOURCE, POLAR DATA SOURCE y SCATTER DATA SOURCE] Los distintos tipos de variables est´an controladas por el siguiente enumerado: STRING: La variable es una cadena de texto NUMBER: La variable es un valor num´erico DATE: La variable es una fecha en formato HH:MM (Hora y minuto) DATE DD MM Y: La variable es una fecha en formato DD/MM/AAAA (D´ıa, mes, a˜no) DATE MM DD Y: La variable es una fecha en formato MM/DD/AAAA (Mes, d´ıa, a˜no) LIST DATA SOURCE: La variable es una fuente de datos de una lista TABLE DATA SOURCE: La variable es una fuente de datos de una tabla CARTESIAN DATA SOURCE: La variable es una fuente de datos de una gr´afica cartesiana POLAR DATA SOURCE: La variable es una fuente de datos de una gr´afica polar SCATTER DATA SOURCE: La variable es una fuente de datos de una gr´afica de dispersi´on Los componentes de una plantilla est´an ordenados en un array de objetos, el orden en el que est´en situados los componentes dictamina su orden de aparici´on en la plantilla, adicionalmente cada componente puede tener dentro otros componentes, esto se puede aplicar de forma recursiva. Los campos de un componente de la plantilla son los siguientes: Tipo: Tipo de componente (Tipo string controlado por enumerado) Padre: Componente padre (Tipo object oundefined) 5.4. DISE ˜ NO DE CLASES 77 Hijos: Componentes hijos (Tipo Array<object>oundefined) Estado: Estado del componente (Tipo object) Los distintos tipos de componentes est´an controlados por el siguiente enumerado: ROW: Componente fila COL: Componente columna TITLE: Componente t´ıtulo PARAGRAPH: Componente par´agrafo TABLE: Componente tabla IMAGE: Componente image GRID: Componente malla LIST: Componente lista CARTESIAN CHART: Componente gr´afica cartesiana POLAR CHART: Componente gr´afica polar SCATTER CHART: Componente gr´afica de dispersi´on 5.4. Dise˜no de clases Los diagramas de clases ofrecen un nivel de abstracci´on menor que los diagramas de arquitectura al representar la estructuraci´on y comunicaci´on de los elementos de la aplicaci´on que se encuentren descritos en el diagrama. Es por ello que se suelen orientar m´as a los desarrolladores de la aplicaci´on o a personas con mayor nivel t´ecnico, tambi´en tienden a modificarse numerosas veces seg´un la fase de desarrollo progresa, pues los detalles de implementaci´on suelen variar el dise˜no de clases inicial. Los diagramas de clases que se representan a continuaci´on se asocian con los m´odulos contemplados en los diagramas de arquitectura anteriores. 5.4.1. Diagramas de paquetes A continuaci´on se detalla la estructuraci´on de las clases a nivel de paquete tanto para el lado servidor como para el lado cliente. 84 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA plantillas, adem´as de las impresi´on de informes. En la figura 5.9 se aprecia la presencia de la clase CRUDComponent, este componente es el que representar´a la barra de operaciones CRUD e impresi´on de plantillas, por ese motivo en su interfaz se incluyen funciones para convocar estas operaciones desde el componente App. Figura 5.9: Diagrama de clases del paquete CRUDPanel A su vez, la clase CRUDComponent est´a compuesta de otras dos clases, TemplateModal yNewTemplateModal, estas clases representan Modals que se muestran en la pantalla cuando el usuario ejecuta acciones en la barra de operaciones 5.4. DISE ˜ NO DE CLASES 85 CRUD. La clase NewTempalteModal se corresponde con el Modal que se muestra cuando el usuario ejecuta la acci´on de crear una plantilla nueva. La clase TemplateModal se corresponde con la lista de pantillas guardadas en la base de datos que el usuario puede cargar o borrar cuando ejecuta la acci´on de cargar plantilla existente. Paquete LayoutComponents El paquete LayoutComponents contiene los clases de los componentes que se compondr´an un informe, este paquete es el m´as complejo y m´as grande de toda la aplicaci´on puesto que incluye toda clase de casu´ısticas espec´ıficas para cada componente imposibilitando de modo extraer jerarqu´ıas estables de clases. En la figura 5.10 y 5.11 se muestra la jerarqu´ıa m´as elemental que se puede extraer de todos los componentes, la clase AbstractComponent hereda de React.Component y proporciona un m´etodo abstracto llamado setEditPanelContent, el cual ser´a utilizado por cada componente para crear su panel de edici´on en el men´u derecho de la aplicaci´on. Figura 5.10: Diagrama de clases del paquete LayoutComponents (1) 86 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA Figura 5.11: Diagrama de clases del paquete LayoutComponents (2) Posteriormente cada componente implementa dos interfaces, una para el estado y otras para sus propiedades, parte de los atributos de las propiedades de un componente son comunes a los atributos de su estado, esto es debido a que las propiedades no se pueden mutar y el estado si, por lo tanto para crear un componente existente es necesario pasar todas las propiedades que permitan reconstruir su estado original. Los componentes principales que integran este paquete son los siguientes: TitleComponent: Componente que representa un t´ıtulo o encabezado de documento, incluye opciones para editar su contenido, posici´on del texto, tipo de encabezado seg´un las etiquetas de HTML H1 a H6, y opciones de fuente como negrita, subrayado y cursiva. ParagraphComponent: Componente que representa un p´arrafo, incluye opciones para editar su contenido, posici´on de texto y opciones de fuente como negrita, subrayado o cursiva. ImageComponent: Componente que representa una imagen en el documento, incluye opciones para subir una imagen desde almacenamiento local 5.4. DISE ˜ NO DE CLASES 87 a la aplicaci´on, modificar la altura y modificar el ancho de la imagen. GridComponent: Componente que representa una malla de celdas no ordenadas, solo incluye opciones para a˜nadir celdas (GridCell). GridCell: Componente que representa una celda de una malla de celdas no ordenadas, incluye opciones para editar el contenido de la celda, definir la posici´on del texto de la celda o opciones de fuente como negrita, subrayado y cursiva. Adicionalmente cuenta con opciones para modificar el tama˜no, tanto alto como ancho de la celda adem´as de cambiar el orden en el que se encuentra dicha celda. ListComponent: Componente que representa una lista de elementos, incluye opciones para a˜nadir, quitar y modificar elementos de la lista a voluntad, adem´as permite editar la posici´on del texto y cuenta con opciones de fuente como negrita, subrayado y cursiva. Tambi´en cuenta con la opci´on de definir si la lista es ordenada o no ordenada, habilitando distintos tipos de encabezados para cada elemento de la lista. Finalmente cuenta con la opci´on de definir la lista como din´amica para generar su contenido desde una fuente de datos cargada desde JSON. TableComponent: Componente que representa una tabla de datos, incluye opciones para a˜nadir, modificar y borrar columnas o filas, permite cambiar el orden de las filas y columnas a voluntad. Este componente incluye la opci´on de definirse como din´amico, de modo que su contenido se carga desde una fuente de datos. CartesianChart: Componente que representa una gr´afica cartesiana mixta, de modo que permite la representaci´on combinada de series como barras, ´areas y lineas. Este componente permite a˜nadir, modificar y borrar series de datos, adicionalmente cuenta con opciones adicionales como activar o desactivar la leyenda, ejes de coordenadas y la malla cartesiana. Cuenta con la opci´on de definirse como gr´afica din´amica para cargar las series de datos desde una fuente de datos. PolarChart: Componente que representa una gr´afica polar, permite alterar entre dos tipos de gr´aficas, la gr´afica de sectores y la gr´afica de radar o spider-web. Incluye opciones para a˜nadir, modificar y borrar series de datos adem´as de opciones adicionales para activar o desactivar la leyenda, malla polar y muestra del radio de la gr´afica. Cuenta con la opci´on de definirse como gr´afica din´amica para cargar series de datos desde una fuente de datos. BubbleChart: Componente que representa una gr´afica de dispersi´on en dos variables, permite la creaci´on, modificaci´on y borrado de series de datos, incluye opciones para activar o desactivar la leyenda, malla cartesiana o ejes 88 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA de coordenadas. Cuenta con la opci´on de definirse como gr´afica din´amica para cargar series de datos desde una fuente de datos. Las acciones que modifican un componente se ejecutan desde su correspondiente panel de edici´on, situado en el paquete PropsPanels. Paquete PropsPanels El paquete PropsPanels contiene los componentes que representan los paneles de edici´on de cada tipo de componente que se pueda representar en la parte central de la aplicaci´on. En la figura 5.12 y 5.13 se muestran las distintas clases que conforman este paquete de componentes, como se puede observar existe un panel (una clase), por cada componente que se puede representar en la parte central de la aplicaci´on. Figura 5.12: Diagrama de clases del paquete PropsPanels (1) 5.4. DISE ˜ NO DE CLASES 89 Figura 5.13: Diagrama de clases del paquete PropsPanels (2) En resumen los componentes que forman este paquete son los siguientes: TitleEditPanel: Componente que representa el panel de edici´on de un t´ıtulo, contiene todas las acciones y llamadas a funciones para modificar el estado del componente t´ıtulo con el que est´a vinculado, incluy´endose las opciones de texto o contenido del mismo. ParagraphEditPanel: Componente que representa el panel de edici´on de un p´arrafo, contiene todas las acciones y llamadas a funciones para modificar el estado del componente p´arrafo con el que est´a vinculado, incluy´endose las opciones de texto o contenido del mismo. ImagenEditPanel: Componente que representa el panel de edici´on de una imagen, contiene las opciones para modificar el alto y ancho de la imagen adem´as de subir una imagen desde almacenamiento local, todo esto mediante realizaci´on de llamadas a funciones del componente imagen con el que est´a vinculado. GridEditPanel: Componente que representa un panel de edici´on de una malla de celdas, contiene opciones para a˜nadir m´as celdas a la malla. ListEditPanel: Componente que representa un panel de edici´on de una lista de elementos, contiene opciones para a˜nadir, borrar y editar los elementos 90 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA de la lista vinculada, tambi´en permite definir el tipo de lista (ordenada o no ordenada) adem´as de editar las propiedades de texto de los elementos y el encabezado de cada elemento de la lista, adem´as permite definir la lista como din´amica seleccionando la fuente de datos desde la que se obtendr´an los datos que representar´a la lista. TableEditPanel: Componente que representa un panel de edici´on de una tabla, contiene opciones para a˜nadir filas y columnas nuevas, permite definir la tabla vinculada como din´amica y seleccionar la fuente de datos que se cargar´a en ella. CartesianEditPanel: Componente que representa un panel de edici´on de una gr´afica cartesiana, contiene opciones para a˜nadir y borrar series de datos, adem´as de permitir editar su contenido y color, permite adem´as definir la gr´afica vinculada como din´amica y seleccionar la fuente de datos que se cargar´a en ella. PolarEditPanel: Componente que representa un panel de edici´on de una gr´afica polar, contiene opciones para a˜nadir y borrar series de datos, adem´as de permitir editar su contenido, color y opacidad, permite adem´as seleccionar el tipo de gr´afica polar (sectores o radar) y definir la gr´afica vinculada como din´amica seleccionado la fuente de datos que cargar´a los datos en ella. BubbleEditPanel: Componente que representa un panel de edici´on de una gr´afica de dispersi´on, contiene opciones para a˜nadir y borrar series de datos, adem´as de permitir editar su contenido, color y forma de representaci´on de los puntos, tambi´en permite definir la gr´afica vinculada como din´amica seleccionado la fuente de datos desde la que se cargar´an los datos. Paquete VarsSection El paquete VarsSection contiene los componentes que representan las secci´on de definici´on y manipulaci´on de variables y fuentes de datos de la aplicaci´on. En la figura 5.14 se muestran las clases que forman el paquete, la construcci´on de esta secci´on se basa en la utilizaci´on del componente VarsLayout como n´ucleo de la secci´on, de modo que las distintas partes que componen esta secci´on se integran en el como un componente m´as ejecutando cada una sus funcionalidades de forma aut´onoma pero pasando siempre por el componente n´ucleo para realizar modificaciones en las otras partes de la aplicaci´on. 5.4. DISE ˜ NO DE CLASES 91 Figura 5.14: Diagrama de clases del paquete VarsSection Este paquete reemplazar´a la secci´on central de la aplicaci´on cuando el usuario cambie de secci´on, de modo que los paneles de edici´on y creaci´on de componentes se ocultar´an hasta que el usuario decida volver a la vista del editor. Las clases que forman este paquete son las siguientes: VarsLayout: Componente n´ucleo de la secci´on, en ella se integran todos los dem´as componentes que forman la secci´on. JSONLoader: Componente que gestiona la carga de JSON en la aplicaci´on, tambi´en gestiona que JSON se est´a utilizando en ese momento, en caso de que el usuario realice una carga m´ultiple de JSONs en la aplicaci´on. VarsDisplay: Componente que muestra las variables ya declaradas en la aplicaci´on, permitiendo eliminar cualquiera que ya no sea necesaria. VarsCreator: Componente que se encarga de crear nuevas variables a petici´on del usuario, permite definir el nombre y el tipo de la variable que se va a crear. VarsMapper: Componente que se encarga de realizar el mapeado de una ruta de JSON a una variable, adem´as de permitir definir opciones adicionales dependiendo del tipo de variable que se est´e editando, las distintas 92 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA variables que se representan en este componente est´an agrupadas en Vars- MapperItem que son las encargadas de gestionar individualmente la variable que tengan vinculada. Variable: Clase que representa la estructura de datos de una variable, incluye toda clase de atributos para definir el nombre, ruta del JSON y tipo. Adicionalmente incluye toda clase de atributos opcionales que dependiendo del tipo que tenga la variable son cubiertos o no desde el VarsMapper. VarsTypes: Enum que indica los distintos tipos de variables que se pueden definir en el VarsCreator, dependiendo del tipo de variable que se defina se activaran unas opciones o otras en elVarsMapper. Paquete ReportLayout El paquete ReportLayout contiene los componentes que representan la parte central de la aplicaci´on, aquella donde se representan los componentes del paquete LayoutComponents. En la figura 5.15 se muestran las clases que conforman este paquete, el enfoque de construcci´on de la composici´on de este paquete viene dado por la representaci´on tradicional de una tabla, de modo que se divide el layout en filas y estas a su vez en columnas, los componentes se introducen en las columnas y el tama˜no que ocupan estar´a determinado por el tama˜no de la columna. 5.4. DISE ˜ NO DE CLASES 93 Figura 5.15: Diagrama de clases del paquete ReportLayout La clase principal es ReportLayout, esta tiene como ´unico cometido la creaci´on y eliminaci´on de filas de componentes en la plantilla que se est´a generando, las filas est´an representadas mediante la clase ReportRow. La clase ReportRow se subdivide en columnas y se encarga de gestionar el tama˜no que ocupa cada una de ellas, de modo que ninguna de ellas exceda el m´aximo tama˜no que tiene asignada la fila, tambi´en gestiona la eliminaci´on de columnas. La clase ReportColumn es la que representa una columna en la plantilla, su cometido es guardar el componente que se desea mostrar en la plantilla, se modo que se encarga de construirlo cuando recibe un evento de la API de Drag and Drop. Este componente tambi´en puede pasarse a la API de Drag and Drop de modo que se puede arrastrar para cambiarlo de posici´on en la plantilla. 5.4.3. Dise˜no de clases del servidor En dise˜no de las clases del servidor es m´as sencillo que el del cliente, pues en el simplemente se generan una serie de endpoints que invocan servicios REST, estos servicios utilizan por debajo funcionalidades ya implementadas de otros paquetes, como Mongoose para trabajar con la base de datos MongoDB o Phantom 100 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA 5.6. Dise˜no de interfaz de usuario En esta secci´on se muestran los distintos dise˜nos que se han realizado de la interfaz gr´afica. La realizaci´on de estos dise˜nos tiene su relevancia para indicarle al cliente o usuario final de forma abstracta la apariencia de la aplicaci´on junto con los elementos que la van a componer. Mediante la realizaci´on de estos dise˜nos se puede obtener feedback por parte del usuario y del cliente y de este modo mejorar el dise˜no inicial, adem´as en caso de que el dise˜no no satisfaga las demandas del cliente se puede rectificar con suficiente celeridad como para que el proyecto no fracase. Los dise˜nos iniciales de la interfaz se realizaron en HTML5 y CSS puesto que se cuenta con experiencia y conocimiento suficiente de ambas tecnolog´ıas como para crearlos de forma r´apida, adem´as se pueden reutilizar los componentes que se creen en futuras versiones de la aplicaci´on. Se crearon dos dise˜nos de la interfaz, uno inicial muy b´asico que solo intentaba reflejar la idea general de la aplicaci´on y uno completo en el que se representaban sin funcionalidad alguna los componentes que formar´ıan la aplicaci´on. La versi´on de la interfaz representada en al figura 5.20 fue la primera creada para su evaluaci´on por parte del cliente, la interfaz creada es minimalista y sencilla puesto que su ´unico prop´osito era mostrar la idea de disposici´on de los componentes que forman la aplicaci´on junto con el prop´osito de cada uno de ellos. Figura 5.20: Versi´on minimalista de la interfaz de la aplicaci´on 5.6. DISE ˜ NO DE INTERFAZ DE USUARIO 101 En este dise˜no inicial simplemente se mostraba una idea inicial y general de como ser´ıa la aplicaci´on, con un panel de componentes en la parte izquierda y un men´u de navegaci´on en la parte superior para cambiar de secci´on, los elementos creados se mostrar´ıan en la parte central de la aplicaci´on y se editar´ıan en esa misma parte. En base a ese dise˜no se obtuvo feedback del cliente y se aplicaron mejoras y cambios al dise˜no minimalista, las ideas se han basado en el boceto de disposici´on de elementos representado en la figura 5.21. En base a este boceto se cre´o una versi´on nueva y m´as avanzada de la interfaz que inclu´ıa todos los componentes situados de la misma manera que en el boceto. Figura 5.21: Boceto de la disposici´on de los elementos en la interfaz completa En la siguiente versi´on de la interfaz se aplicaron mejoras de usabilidad al dise˜no inicial, como uso de colores m´as claros para el contenido general y colores 102 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON DEL SISTEMA oscuros para contenido importante a resaltar, divisi´on de los men´us en paneles plegables y traslado de las opciones de edici´on de los componentes al men´u derecho en vez de editarlas en la parte central de la aplicaci´on. Como consecuencia de lo anterior se obtuvo el dise˜no de la interfaz presente en la figura 5.22. Este dise˜no convenci´o m´as al cliente por lo que se procedi´o a desarrollar las funcionalidades de la aplicaci´on en torno a este dise˜no de interfaz. Figura 5.22: Versi´on completa de la interfaz de la aplicaci´on Cap´ıtulo 6 Validaci´on y pruebas En esta secci´on se indican las distintas pruebas que se han realizado contra el software que se ha desarrollado a lo largo de este proyecto. Esta fase tiene dos objetivos principales: Comprobar que el software programado funciona correctamente ante las entradas y salidas contempladas y no contempladas en sus algoritmos y formularios, m´as conocido como fase de verificaci´on. Comprobar que el software construido cumple con las expectativas del cliente, esto es, que el software resuelve el problema que el cliente ha planteado de forma correcta seg´un sus criterios, tambi´en conocido como fase de validaci´on. A continuaci´on se muestran los distintos tipos de pruebas que se han realizado junto con sus resultados. 6.1. Pruebas unitarias Las pruebas unitarias tienen como objetivo comprobar que cada funcionalidad de la aplicaci´on comprobada de forma independiente funciona seg´un lo esperado ante par´ametros v´alidos e inv´alidos, estas pruebas tienen que ser lo m´as completas posibles, por lo que tienen que probar la mayor cantidad de c´odigo posible y el mayor rango posible de par´ametros de entrada. 103 104 CAP´ ITULO 6. VALIDACI ´ ON Y PRUEBAS ID PU-01 Descripci´on Se abre la interfaz web en la secci´on del editor y se selecciona la opci´on de Nueva, a continuaci´on se indica el nombre de la plantilla y la versi´on y se confirma la creaci´on. Casos de uso asociados CU-04 Criterio de aceptaci´on La parte central de la aplicaci´on cambia al contenido de una plantilla en blanco, adem´as el nombre y versi´on de la plantilla aparecen correctamente en el pie de p´agina Estado Superada ID PU-02 Descripci´on Se abre la interfaz web en la secci´on del editor y se selecciona la opci´on de Guardar. Casos de uso asociados CU-05 Criterio de aceptaci´on El contenido que existe en la plantilla es convertido a formato JSON y “enviado al servidor”. Estado Superada ID PU-03 Descripci´on Se abre la interfaz web en al secci´on del editor y se selecciona una versi´on de una plantilla para su carga. Casos de uso asociados CU-06 Criterio de aceptaci´on El contenido de la parte central de la aplicaci´on cambia para mostrar el contenido de la plantilla seleccionada, adem´as el pie de p´agina se actualiza con el nombre y versi´on de la plantilla seleccionada. Estado Superada ID PU-04 Descripci´on Se abre la interfaz web en la secci´on del editor y se selecciona la opci´on de borrado de una plantilla existente. Casos de uso asociados CU-07 Criterio de aceptaci´on La plantilla es borrada y desaparece de la lista para su selecci´on. Estado Superada 6.1. PRUEBAS UNITARIAS 105 ID PU-05 Descripci´on Se abre la interfaz web y se procede a arrastrar cualquier componente de texto (t´ıtulo, p´arrafo o lista) del panel de componentes a la parte central de la aplicaci´on donde posteriormente se suelta en una fila con espacio disponible. Casos de uso asociados CU-01 Criterio de aceptaci´on Se crea un componente de texto con contenido por defecto en la posici´on seleccionada. Estado Superada ID PU-06 Descripci´on En la secci´on de variables se procede a escribir el nombre de una variable y seleccionar cualquiera de los tipos disponible, posteriormente se pulsa la opci´on de a˜nadir variable. Casos de uso asociados CU-08 Criterio de aceptaci´on Se crea la variable con el nombre y tipo seleccionado y se a˜nade a la tabla de variables. Estado Superada ID PU-07 Descripci´on En la secci´on de variables, se pulsa el bot´on de cargar JSON y se selecciona un archivo en formato JSON para su carga. Casos de uso asociados CU-11 Criterio de aceptaci´on El JSON queda cargado en la aplicaci´on y se muestra su contenido. Estado Superada 106 CAP´ ITULO 6. VALIDACI ´ ON Y PRUEBAS ID PU-08 Descripci´on Se selecciona un componente ya creado en la parte central de la aplicaci´on y se procede a modificar su tama˜no y desplazamiento junto con sus opciones propias de contenido. Casos de uso asociados CU-02 Criterio de aceptaci´on El tama˜no y desplazamiento del componente aumenta o se reduce en base al espacio disponible y seg´un el criterio indicado por el usuario, adem´as el contenido del componente se modifica seg´un el criterio del usuario. Estado Superada ID PU-09 Descripci´on Se selecciona un componente ya creado y se pulsa en la opci´on de borrar componente. Casos de uso asociados CU-03 Criterio de aceptaci´on El componente es borrado completamente y queda su espacio como una columna vac´ıa. Estado Superada ID PU-10 Descripci´on Se selecciona una componente lista y se pasa su tipo a din´amico, a continuaci´on se selecciona una fuente de datos de las disponibles y se pulsa en el bot´on de cargar. Casos de uso asociados CU-09 Criterio de aceptaci´on La lista refleja el contenido de la fuente de datos seleccionada. Estado Superada ID PU-11 Descripci´on En la secci´on de variables se pulsa sobre el bot´on de cargar JSON y se seleccionan m´ultiples archivos en formato JSON para su carga. Casos de uso asociados CU-11 Criterio de aceptaci´on Se cargan en la aplicaci´on todos los JSON v´alidos y se muestra al usuario la lista de cual est´a seleccionado actualmente. Estado Superada 6.1. PRUEBAS UNITARIAS 107 ID PU-12 Descripci´on Se selecciona un componente de texto cualquiera y se procede a insertar una variable mediante la sintaxis {{nombre de la variable}}. Casos de uso asociados CU-09 Criterio de aceptaci´on La variable queda vinculada al texto, por lo que ser´a reemplazada cuando el usuario seleccione la opci´on de reemplazar variables. Estado Superada ID PU-13 Descripci´on Se selecciona un componente tabla y se cambia su tipo a din´amico, a continuaci´on se selecciona una fuente de datos y se pulsa el bot´on de cargar fuente de datos. Casos de uso asociados CU-09 Criterio de aceptaci´on El contenido de la tabla se modifica para representar la fuente de datos que se carga. Estado Superada ID PU-14 Descripci´on Se selecciona un componente gr´afica cualquiera y se cambia su tipo a din´amico, a continuaci´on se selecciona una fuente de datos y se pulsa el bot´on de cargar fuente de datos Casos de uso asociados CU-09 Criterio de aceptaci´on El contenido de la gr´afica se adapta a la fuente de datos seleccionada. Estado Superada ID PU-15 Descripci´on Con variables variables vinculadas a componentes de texto y fuentes de datos seleccionadas en gr´aficas y tablas se pulsa el bot´on de Reemplazar variables. Casos de uso asociados CU-10 Criterio de aceptaci´on Las variables vinculadas a componentes de texto se reemplazan correctamente y el contenido de las fuentes de datos se carga en los componentes correspondientes. Estado Superada 108 CAP´ ITULO 6. VALIDACI ´ ON Y PRUEBAS ID PU-16 Descripci´on Con una plantilla con ciertos componentes creados se pulsa el bot´on de Imprimir a PDF. Casos de uso asociados CU-12 Criterio de aceptaci´on Se recibe un PDF con el contenido de la plantilla. Estado Superada ID PU-17 Descripci´on Con una plantilla con ciertos componentes y m´ultiples JSON se pulsa el bot´on de Imprimir todos. Casos de uso asociados CU-12 Criterio de aceptaci´on Se recibe un PDF por cada JSON reemplazando las variables para cada JSON. Estado Superada 6.2. Pruebas de integraci´on Las pruebas de integraci´on tienen como objetivo comprobar que la interacci´on entre los distintos m´odulos que forman la aplicaci´on se realiza correctamente, de modo que tenemos la seguridad que la funcionalidad completa se realiza correctamente sin fallo alguno y que muestra los resultados correctos. ID PI-01 Descripci´on Con una plantilla con contenido ya creada se procede a pulsar en el bot´on de Guardar Criterio de aceptaci´on El contenido es transmitido por HTTP al servidor, este lo recibe y lo guarda en la base de datos, finalmente el cliente recibe una respuesta HTTP 200 indiciando que la operaci´on ha sido un ´exito. Estado Superada 6.2. PRUEBAS DE INTEGRACI ´ ON 109 ID PI-02 Descripci´on Se abre la interfaz de la aplicaci´on y se pulsa en el men´u de cargar para obtener todas las plantillas disponibles del servidor. Criterio de aceptaci´on Se transmite una petici´on HTTP GET al servidor para obtener todas las plantillas, este contesta con otra petici´on HTTP 200 con las plantillas obtenidas, a continuaci´on el cliente las muestra todas en forma de lista paginada. Estado Superada ID PI-03 Descripci´on Con el men´u de cargar plantillas abierto se selecciona una de las plantillas de la lista para obtener sus versiones. Criterio de aceptaci´on Se transmite una petici´on HTTP GET al servidor para obtener todas las versiones de la plantilla seleccionada, a continuaci´on el servidor responde con una petici´on HTTP 200 con las versiones de la plantilla obtenidas, el cliente muestra estas versiones en forma de lista paginada. Estado Superada ID PI-04 Descripci´on Con el men´u de cargar plantillas abierto se selecciona una de la versiones de una plantilla determinada y se pulsa en la opci´on de editar. Criterio de aceptaci´on Se transmite una petici´on HTTP GET al servidor para obtener el contenido de la versi´on de la plantilla seleccionada, el servidor responde con un HTTP 200 con el contenido de la versi´on, el cliente carga todos los datos recibidos y cambia la parte central de la aplicaci´on para que represente el contenido recibido. Estado Superada 116 CAP´ ITULO 6. VALIDACI ´ ON Y PRUEBAS Pregunta 1 Pregunta 2 Pregunta 3 Pregunta 4 Pregunta 5 Pregunta 6 Pregunta 7 Pregunta 8 Pregunta 9 Pregunta 10 Puntuaci´on Usuario 1 5 2 5 3 4 0 3 1 5 0 82/100 Usuario 2 4 1 4 3 5 1 4 2 4 1 76/100 Usuario 3 4 3 5 2 2 1 5 2 5 1 80/100 Usuario 4 5 2 5 0 4 3 2 3 4 3 72/100 Usuario 5 5 0 5 0 4 3 4 0 5 0 90/100 La media obtenida de la puntuaci´on de los usuarios es de 80 puntos, por lo que se considera que la interfaz es usable en su conjunto debido a que es superior al l´ımite de 75 puntos establecido. 6.4. Matriz de trazabilidad PU-01 PU-02 PU-03 PU-04 PU-05 PU-06 PU-07 PU-08 PU-09 PU-10 PU-11 PU-12 PU-13 PU-14 PU-15 PU-16 PU-17 CU-01 X CU-02 X CU-03 X CU-04 X CU-05 X CU-06 X CU-07 X CU-08 X CU-09 X X X X CU-10 X CU-11 X X CU-12 X X Cuadro 6.1: Matriz de trazabilidad Pruebas Unitarias - Casos de uso Cap´ıtulo 7 Conclusiones y ampliaciones En este apartado se comentan las conclusiones obtenidas tras la realizaci´on de este trabajo fin de grado, adicionalmente se indican las posibles ampliaciones que se le podr´ıan aplicar para conseguir que la aplicaci´on sea m´as funcional o presente mejoras de rendimiento. 7.1. Conclusiones Como principal conclusi´on mencionar que el uso de las tecnolog´ıas de Big Data y en especial de Business Intelligence ha provocado un aumento sustancial de la informaci´on que tenemos a nuestra disposici´on, provocando que sea necesario la implementaci´on de software adicional para mostrar dicha informaci´on de forma legible y directa para los usuarios, normalmente, en forma de informes. Dichos programas presentan el problema de que son construidos a medida para un sistema de BI concreto, provocando que sea necesario adaptarlos cuando sea necesario modificar el modelo de datos a mostrar, en este trabajo se ha desarrollado un software que permite la creaci´on de informes que no dependen de un modelo de datos concreto, proponiendo de este modo una soluci´on al problema anterior, aunque este software no es perfecto ni aplicable a absolutamente todos los contextos, la idea general de construir de forma gen´erica vistas asociadas a modelos de datos que el usuario cargue, y todo lo anterior de la forma m´as sencilla posible, permite solucionar la falta de flexibilidad de los sistemas anteriormente mencionados. Por una banda, destacar la importancia del uso de la computaci´on distribuida en el mundo actual, especialmente el paradigma de arquitecturas orientadas a servicios. Esto es debido a que es posible la creaci´on de aplicaciones cliente encargadas de realizar ciertas funcionalidades que antes solo se pod´ıan realizar en el servidor, de modo que es posible distribuir la carga que antes resid´ıa ple- 117 118 CAP´ ITULO 7. CONCLUSIONES Y AMPLIACIONES namente en los servidores entre el cliente y el servidor, ahorrando de este modo capacidad de c´omputo. Gracias a esto es posible crear arquitecturas escalables aplicables al mundo de informaci´on vol´atil actual en el que es necesario continuas adaptaciones para mantener la escalabilidad de los sistemas, adem´as de facilitar el desacoplamiento de funcionalidades y aumentar la seguridad de los servidores. Adicionalmente, durante este TFG se ha obtenido conocimiento sobre un gran abanico de tecnolog´ıas y frameworks, destacando que el uso correcto de estas tecnolog´ıas puede agilizar enormemente el desarrollo de cualquier sistema software actual, esto es debido a que se evita “reinventar la rueda” y por ello se puede invertir el tiempo de desarrollo desarrollando funcionalidades nuevas en vez de recrear las que ya se han implementado anteriormente. Por otra banda, destacar la importancia de la aplicaci´on y uso de patrones de dise˜no en el desarrollo de software, pues gracias a ellos es posible la realizaci´on de aplicaciones altamente escalables, f´aciles de mantener y cuyas partes pueden ser reutilizadas en otras aplicaciones distintas. En este trabajo se han aplicado distintos patrones de dise˜no, incluyendo composici´on, herencia y divisi´on modular (module pattern) los cuales han permitido agilizar el desarrollo de la aplicaci´on adem´as de facilitar la correcci´on de errores en fases m´as avanzadas del desarrollo sin necesidad de destruir gran parte del c´odigo. Finalmente, mencionar la importancia de la generaci´on de documentaci´on asociada al uso de un sistema software, tecnolog´ıa determinada o framework, pues ella es la que permite el uso correcto de todo lo anterior adem´as de agilizar la curva de aprendizaje requerida para usar correctamente lo documentado. Sin embargo, es necesario mencionar tambi´en las dificultades presentadas a la hora de desarrollar este proyecto. La principal dificultad presentada en el proyecto es el uso de tecnolog´ıas nuevas por primera vez por parte del desarrollador, en concreto el uso del lenguaje JavaScript. Aunque JavaScript es un lenguaje sencillo de comprender inicialmente puede llegar a ser complejo de depurar debido a que no est´a fuertemente tipado a diferencia de otros lenguajes de programaci´on como C++ o Java que tipifican de forma est´atica, sin embargo esto puede solventarse mediante el uso de lenguajes de superconjunto, como TypeScript, que a˜naden tipado est´atico a JavaScript. Otra de las grandes dificultades fue el uso del framework React, este framework escrito en JavaScript presenta una curva de aprendizaje muy elevada al introducir conceptos nuevos como ciclos de vida de componentes, patr´on de composici´on y renderizado que no son conceptos sencillos de comprender inicialmente. Esto ha provocado que fuese necesario esfuerzo adicional para empezar a utilizar este fra- 7.2. AMPLIACIONES 119 mework, adem´as de aplicar m´ultiples refactorizaciones al c´odigo de la aplicaci´on seg´un el conocimiento que se pose´ıa sobre el framework iba aumentando durante el transcurso del proyecto. 7.2. Ampliaciones Aunque se alcanzaron los objetivos contemplados en el alcance del proyecto y los requisitos propuestos por el cliente, el software desarrollado presenta carencias y faltas en ciertos aspectos. En primer lugar, el software solo permite cargar modelos de datos en formato JSON, una de las posibles ampliaciones ser´ıa generalizar la carga de modelos de datos para permitir de este modo la carga de modelos de datos en formato XML, CSV o incluso extra´ıdos desde bases de datos relacionales. Adicionalmente, el software cuenta con un conjunto limitado de opciones de edici´on, pues solo se ha contemplado opciones b´asicas y m´ınimas para dar legibilidad a un informe, otras de las posibles ampliaciones ser´ıa a˜nadir m´as opciones de edici´on a los componentes de la aplicaci´on, como por ejemplo cambiar el color de la fuente, cambiar el tama˜no de la fuente, cambiar el tipo de fuente o el color de fondo del componente. Otra de las posibles ampliaciones ser´ıa a˜nadir otro tipo de componentes a la aplicaci´on, como ´arboles, diagramas o a˜nadir otros tipos de gr´aficas que no est´an contempladas en el sistema actual. Tambi´en es posible aumentar las opciones de impresi´on, permitiendo que el informe generado sea utilizado para distintos tipos de folios como DIN A3, DIN A2 o formato carta. Como ´ultima posible ampliaci´on propuesta estar´ıa una mejora general del rendimiento de la aplicaci´on, pues en caso de usar un informe con muchas gr´aficas y tablas el rendimiento de la aplicaci´on se mina al provocar cambios de vista, principalmente la mejora de rendimiento implicar´ıa el uso de transformaciones CSS3 y uso de GPU para calcular las transiciones y animaciones de la interfaz y de este modo mantener el rendimiento. 120 CAP´ ITULO 7. CONCLUSIONES Y AMPLIACIONES Ap´endice A Manuales t´ecnicos En esta secci´on se adjuntan los manuales relativos a la parte t´ecnica del proyecto, incluy´endose el despliegue de la aplicaci´on junto con las opciones de configuraci´on que esta pueda presentar y el modo de configurarlas. A.1. Manual de despliegue Para desplegar la aplicaci´on es necesario las siguientes aplicaciones/entornos, estos no se proporcionan en el CD del c´odigo de la aplicaci´on y deben de ser instalados aparte: Node.js (Versi´on 9.11.1), es el entorno en el que se despliega la capa de servicios y la aplicaci´on web, se puede descargar desde https://nodejs. org/en/. NPM (Versi´on 6.1.0), gestor de dependencias utilizado en las aplicaciones, se puede descargar desde https://www.npmjs.com/get-npm. Docker (Opcional) (Versi´on 18.03.1-ce build 9ee9f40), utilizado para desplegar los contenedores de la base de datos MongoDB actual, se puede descargar desde https://www.docker.com/get-started. El uso de Docker es opcional si se opta por utilizar otro tipo de base de datos MongoDB en otra URI de acceso, el uso de Node.js y NPM es obligatorio si se desea desplegar la aplicaci´on web y la capa de servicios puesto que ambas fueron desarrolladas dentro de ese entorno. Para desplegar la aplicaci´on web: 1. Descomprimir su contenido en un directorio. 2. Abrir una terminal del sistema operativo (bash, xterm, powershell, ...). 121 122 AP´ ENDICE A. MANUALES T´ ECNICOS 3. Situar la terminal en el directorio donde est´a la aplicaci´on web y donde se sit´ua el archivo package.json de NPM. 4. Ejecutar el comando npm start. Para desplegar la capa de servicios: 1. Descomprimir su contenido en un directorio. 2. Abrir una terminal del sistema operativo (bash, xterm, powershell, ...). 3. Situar la terminal en el directorio donde est´a la capa de servicios y donde se sit´ua el archivo package.json de NPM. 4. Ejecutar el comando npm start. Para desplegar la base de datos mongoDB: 1. Abrir una terminal del sistema operativo (bash, xterm, powerhsell, ...). 2. Situar la terminal el directorio del archivo tar que contiene la imagen de la base de datos. 3. Ejecutar el comando docker load -i <nombre del archivo tar>. 4. Ejecutar el comando docker images para obtener el ID de la imagen que se ha cargado. 5. Ejecutar el comando docker run –name <nombre del contenedor>-i -t <ID de la imagen>para crear el contenedor e iniciarlo. 6. Ahora solo es necesario ejecutar el comando docker start <nombre del contenedor>para arrancar el contenedor anterior en caso de que se pare o se cierre la terminal anterior. A.2. Manual de configuraci´on A.2.1. Cambiar la URI de la capa de servicios En caso de que la capa de servicio se despliegue en una URI diferente a localhost es necesario modificar el archivo App.tsx oApp.js de la aplicaci´on web. Si se opta por modificar el archivo App.tsx es necesario utilizar el compilador de TypeScript para compilar el archivo a JavaScript interpretable por el navegador, la URI est´a especificada en la l´ınea export const globalAPI : string = “URI de capa de servicios”del archivo App.tsx. A.2. MANUAL DE CONFIGURACI ´ ON 123 Si no interesa compilarlo con TypeScript y se decide cambiar la URI de forma m´as directa, cambiar la l´ınea exports. globalAPI = “URI de capa de servicios” en el archivo App.js. A.2.2. Cambiar la URI de la base de datos En caso de utilizar otra base de datos MongoDB localizada en otra URI es necesario modificar el archivo db.js de la capa de servicios, en concreto la l´ınea var url = URI a la base de datos. A.2.3. Versiones utilizadas en el desarrollo En caso de necesitar modificar el c´odigo de la aplicaci´on o actualizar los entornos indicar que este proyecto se ha realizado bajo las siguientes versiones de entornos y lenguajes: Node.js (Versi´on 9.11.1) NPM (Versi´on 6.1.0) Docker (Versi´on 18.03.1-ce build 9ee9f40) TypeScript (Versi´on 2.9.2) React (Versi´on 16.3) JavaScript (ES2017) Navegadores (Firefox v60 y Google Chrome v64) En caso de utilizar versiones superiores o inferiores no se garantiza que el c´odigo pueda funcionar debido a la eliminaci´on de funcionalidades o cambios en las APIs de los entornos, se recomienda utilizar estas versiones para maximizar la compatibilidad. En referencia a los navegadores, se ha probado la aplicaci´on en Firefox v60 y Google Chrome v64 puesto que son actualmente los navegadores m´as utilizados y m´as estables en t´erminos de rendimiento. Probar con versiones anteriores no garantiza que el software funcione correctamente debido a faltas de funcionalidades de JavaScript o CSS. 124 AP´ ENDICE A. MANUALES T´ ECNICOS Ap´endice B Manual de usuario En esta secci´on se adjunta el manual de usuario de la aplicaci´on, en el se indican las opciones que contiene y el modo de usarlas as´ı como sus limitaciones. B.1. Vista normal de la aplicaci´on Figura B.1: Pantalla principal de la aplicaci´on Cuando se accede a la aplicaci´on se muestra la interfaz de la figura B.1, la aplicaci´on por defecto crea una plantilla vac´ıa cuyo nombre y versi´on es New Template y0.0.1 respectivamente, la plantilla est´a en blanco y solo contendr´a una fila vac´ıa para crear contenido. 125 132 AP´ ENDICE B. MANUAL DE USUARIO contando con distintos encabezamientos para las listas ordenadas y para las no ordenadas. Si se desea a˜nadir un elemento nuevo basta con introducir el contenido del elemento en la entrada de formulario inferior y pulsar Enter para crear el elemento, al realizar esta acci´on el elemento ser´a mostrado en la lista y se crear´a una entrada de formulario para ese elemento en la secci´on Editar elementos actuales. En la secci´on Editar elementos actuales se muestra una entrada de formulario por cada elemento presente en la lista, modificando la entrada del formulario aplica cambios directamente al componente de la lista. Para eliminar el elemento pulsar en el bot´on rojo situado al final del formulario. Las opciones de edici´on anteriores solo est´an disponibles cuando la lista es est´atica, es decir, su contenido no se obtiene desde una fuente de datos. B.4.4. Propiedades del componente malla Una malla permite la creaci´on de celdas independientes con dimensiones personalizadas por el usuario, el panel de edici´on de este componente solo cuenta con un bot´on para a˜nadir m´as celdas a la malla con dimensiones predefinidas, dichas celdas solo contienen componentes de texto simples. Para editar una celda situar el cursor encima de ella y pulsar en el bot´on de edici´on que se muestra, posteriormente se activar´a el panel de edici´on de la celda que se ha seleccionado mostrado en la figura B.8. Figura B.8: Panel de edici´on de una celda de una malla El panel permite editar el contenido de la celda y las propiedades del texto, adicionalmente se adjuntan entradas de formulario para editar el ancho y alto que ocupa la celda, el alto se mide el pixeles y solo puede tomar valores superiores a 10 pixeles, el ancho se mide en % y toma valores superiores al 10 % y como m´aximo 100 %. Adicionalmente se adjuntan dos botones que permiten desplazar la celda de izquierda a derecha en la malla o borrarla. Para confirmar los cambios B.4. PROPIEDADES, TAMA ˜ NO Y POSICI ´ ON DE UN COMPONENTE 133 de edici´on se debe de pulsar en el bot´on de check situado al final de la entrada del formulario de edici´on. B.4.5. Propiedades del componente tabla El panel de edici´on de una tabla est´atica se corresponde con la figura B.9, en este panel se permite al usuario a˜nadir filas vac´ıas a la tabla y crear columnas del mismo modo que un elemento de una lista, introduciendo el nombre de la columna en la entrada del formulario y pulsando enter. Figura B.9: Panel de edici´on de una tabla est´atica Cuando se a˜nade una columna o fila a la tabla desde este panel, este se ver´a reflejado inmediatamente en la tabla vinculada, para editar el contenido de la fila o columna se sigue el mismo procedimiento que en una celda de una malla, se sit´ua el cursor encima de la columna o fila pertinente y se selecciona la opci´on de editar, posteriormente se introduce el valor deseado en la entrada del formulario que se habilita para la edici´on y se pulsa enter o el bot´on de check para finalizar la edici´on. Adicionalmente se permite al usuario cambiar el orden de las filas y columnas que a˜nada a la tabla mediante el uso de las flechas de direcci´on que se habilitan cuando se sit´ua el cursor encima de una fila o columna. Las opciones de edici´on anteriores solo est´an disponibles cuando la tabla es est´atica, es decir su contenido no es cargado desde una fuente de datos. 134 AP´ ENDICE B. MANUAL DE USUARIO B.4.6. Propiedades del componente gr´afica cartesiana El componente gr´afica cartesiana permite representar gr´aficas de l´ıneas, barras y ´areas, todas ellas combinadas seg´un el usuario defina en las series del componente, el panel de este componente se refleja en la figura B.10. Figura B.10: Panel de edici´on de una gr´afica cartesiana En este panel se provee al usuario de un conjunto de opciones que permiten B.4. PROPIEDADES, TAMA ˜ NO Y POSICI ´ ON DE UN COMPONENTE 135 activar o desactivar elementos visuales de la gr´afica, como la malla cartesiana, ejes de coordenadas o la leyenda, estas opciones se encuentran en la secci´on de Propiedades de la gr´afica. Adicionalmente se permite editar el tama˜no de la altura de la gr´afica en la entrada num´erica del formulario de la secci´on Altura de la gr´afica. Si se quiere a˜nadir nuevas series de datos basta con introducir el nombre de la serie en la entrada del formulario de la secci´on A˜nadir nuevas series de datos y pulsas enter para crear la serie, al hacer esto se crea un bot´on en la secci´on Editar conjuntos de datos con el nombre de la serie que se acaba de introducir. Para editar el contenido de una serie basta con pulsar el bot´on de Editar serie <nombre de la serie>situada en la secci´on Editar conjuntos de datos, al hacer esto se desplegar´a el men´u de edici´on de esa serie, este panel est´a compuesto por una entrada de formulario donde se introducen los datos de la serie. Los datos de la serie deben de estar introducidos entre los corchetes y separados por comas, solo admiti´endose n´umeros para componer los valores de la serie. Un ejemplo de valores de una serie ser´ıa [1,2,3,4,5,6,7,8,9]. Adicionalmente el panel de edici´on permite definir el tipo de gr´afica que representar´an los datos adem´as del color de la serie. Los tipos de gr´aficas disponibles son : l´ınea,´area ybarras. Los colores deben de ser introducidos en formato hexadecimal RGB, un ejemplo de color v´alido ser´ıa #ff0000. Adicionalmente la gr´afica cartesiana permite editar las etiquetas del eje X, introduciendo cadenas de texto a voluntad del usuario. Para editarlas pulsar sobre el bot´on Editar etiquetas del eje X, e introducir en los corchetes las etiquetas separadas por comas y entre comillas dobles, un ejemplo v´alido de etiquetas ser´ıa [“Etiqueta 1”,“Etiqueta2”]. B.4.7. Propiedades del componente gr´afica polar El componente gr´afica polar permite representar gr´aficas de sectores o de radar, el panel de edici´on de este componente est´a reflejado en la figura B.11 para una gr´afica de sectores y en la figura B.12 para una gr´afica de radar. 136 AP´ ENDICE B. MANUAL DE USUARIO Figura B.11: Panel de edici´on de una gr´afica de sectores Ambos paneles funcionan del mismo modo que una gr´afica cartesiana, permitiendo el a˜nadido de series de la misma manera y permitiendo la personalizaci´on de opciones visuales en la misma localizaci´on que las gr´aficas cartesianas, adem´as de permitir cambiar el tama˜no de la altura de la gr´afica. El panel polar proporciona adem´as de lo anterior la opci´on de seleccionar que tipo de gr´afica se desea representar, siendo los posibles valores sectores oradar. Cabe destacar que existen diferencias en como se tratan los datos a nivel interno en cada uno de los dos tipos de gr´aficas disponibles. Las gr´aficas de sectores calculan su valor de representaci´on como el sumatorio de los valores de la serie de modo que la serie [5,5] es lo mismo que [10] en una gr´afica de sectores. Sin embargo en una gr´afica de radar, los valores de representaci´on se calculan como cualquier otra gr´afica de puntos, como una lista de valores, de modo que [5,5] no es equivalente a [10] en una gr´afica de sectores. B.4. PROPIEDADES, TAMA ˜ NO Y POSICI ´ ON DE UN COMPONENTE 137 Figura B.12: Panel de edici´on de una gr´afica de radar Adicionalmente la gr´afica de sectores permite editar las etiquetas de los v´ertices del radar de representaci´on, mientras que las gr´aficas de sectores no permiten este tipo de opci´on. Adicionalmente la gr´aficas polares permiten editar la opacidad del color de las series. B.4.8. Propiedades del componete gr´afica de dispersi´on El componente gr´afica de dispersi´on permite representar gr´aficas de burbujas o de dispersi´on en dos variables, el panel de edici´on est´a representado en la figura B.13. El panel de edici´on de una gr´afica de dispersi´on sigue los mismos procedimientos que una gr´afica cartesiana, contando con opciones de personalizaci´on visuales de la gr´afica y de edici´on y a˜nadido de series junto el tama˜no de la gr´afica. 138 AP´ ENDICE B. MANUAL DE USUARIO La diferencia radica en que la gr´afica de dispersi´on permite editar las etiquetas del eje X y del eje Y pulsando en los botones de Editar etiquetas del eje X y Editar etiquetas del eje Y respectivamente, el formato de las etiquetas es el mismo que el de las gr´aficas cartesianas, introduciendo las etiquetas entre comillas dobles y separadas por comas. Adicionalmente las series de datos de una gr´afica de dispersi´on cuentan con dos conjuntos de datos por serie, el primer conjunto de datos representa los valores que toma el punto en el eje X mientras que el segundo conjunto de datos representa los valores que toma el punto en el eje Y. Figura B.13: Panel de edici´on de una gr´afica de dispersi´on B.5. DEFINICI ´ ON DE VARIABLES 139 B.5. Definici´on de variables La aplicaci´on posee opciones para declarar e insertar variables en componentes existentes en la plantilla, el contenido de una variable puede ser una cadena de texto, un n´umero o un conjunto de datos, para configurar las variables que se pueden utilizar en la plantilla que se est´e editando basta con acceder a la secci´on de Variables en la barra de navegaci´on. La secci´on de variables se subdivide en secciones m´as peque˜nas, cada una de ellas con una funcionalidad concreta, dichas secciones se explican a continuaci´on. B.5.1. Secci´on de creaci´on de variables La primera secci´on es la secci´on de creaci´on de variables, la cual se encuentra bajo el t´ıtulo de Variables, dicha secci´on se puede observar en la figura B.14. Figura B.14: Panel de creaci´on de variables En esta secci´on se muestran las variables que hay definidas a nivel de plantilla en una tabla, en dicha tabla se indica el nombre de la variable el tipo de variable y se permite la opci´on de borrar la variable. Adicionalmente se permite crear variables nuevas introduciendo el nombre de la variable en la entrada del formulario inferior y seleccionando el tipo que la variable ocupar´a durante su estancia. B.5.2. Tipos de variables Las variables que se definen a nivel de plantilla tienen un tipo asignado, dependiendo del tipo su uso estar´a permitido en unos componentes y prohibido en otros, adicionalmente el tipo define las opciones de traducci´on de la variable de modo que es crucial definir el tipo adecuadamente o esta podr´ıa no mostrarse en los componentes. Los tipos de variables disponibles son: 140 AP´ ENDICE B. MANUAL DE USUARIO Cadena de texto: El contenido de la variable es una cadena de texto y se traducir´a literalmente su valor, de modo que se mostrar´a exactamente el valor obtenido de la ruta del JSON especificada. N´umero: El contenido de la variable es un n´umero, se traducir´a literalmente su valor pero esta traducci´on fallar´a si existen letras o si el n´umero est´a entre comillas como una cadena texto. Fecha y hora: El contenido de la variable es una fecha y una hora, la traducci´on de este tipo de variable se realiza tomando los milisegundos desde el epoch de los sistemas UNIX, de modo que el valor recibido ser´a un n´umero que represente estos milisegundos, en caso contrario se mostrar´a Invalid Date al traducir la fecha. Fecha (DD/MM/AAAA): El contenido de la variable es una fecha en formato d´ıa mes y a˜no, la traducci´on de este tipo de variable se realiza tomando los milisegundos desde el epoch de los sistemas UNIX, de modo que el valor recibido ser´a un n´umero que represente estos milisegundos, en caso contrario se mostrar´a Invalid Date al traducir la fecha. Fecha (MM/DD/AAAA): El contenido de la variable es una fecha en formato mes d´ıa y a˜no, la traducci´on de este tipo de variable se realiza tomando los milisegundos desde el epoch de los sistemas UNIX, de modo que el valor recibido ser´a un n´umero que represente estos milisegundos, en caso contrario se mostrar´a Invalid Date al traducir la fecha. F. Datos (Lista): El contenido de la variable es una fuente de datos para un componente tipo lista, este tipo de variable espera un array de objetos de los cuales solo mostrar´a una propiedad que el usuario seleccione en el Mapeador de variables. F. Datos (Tabla): El contenido de la variable es una fuente de datos para un componente tipo tabla, este tipo de variable espera un array de objetos, la tabla crear´a una columna por cada propiedad del objeto gen´erico del array y una fila por cada objeto presente en el array. F. Datos (Cartesiana): El contenido de la variable es una fuente de datos para un componente gr´afica cartesiana, este tipo de variable espera un array de objetos, la gr´afica cartesiana crear´a una serie por cada propiedad presente en el objeto gen´erico del array, los valores de la serie ser´an los valores de dicha propiedad en todos los objetos que componen el array recibido como par´ametro. F. Datos (Polar): El contenido de la variable es una fuente de datos para un componente gr´afica polar, este tipo de variable espera un array B.5. DEFINICI ´ ON DE VARIABLES 141 de objetos, la gr´afica polar crear´a una serie por cada propiedad presente en el objeto gen´erico del array, los valores de la serie ser´an los valores de dicha propiedad en todos los objetos que componen el array recibido como par´ametro. F. Datos (Dispersi´on): El contenido de la variable es una fuente de datos para un componente gr´afica de dispersi´on, este tipo de variable espera un mapa de arrays de objetos, la gr´afica de dispersi´on crear´a una serie por cada clave del mapa, los valores de cada serie son los arrays de la claves, dichos arrays deben de contener objetos que tengan dos propiedades, xpara definir el valor del punto en el eje x e ypara definir el valor del punto en el eje y. B.5.3. Mapeador de variables Figura B.15: Mapeador de variables La siguiente secci´on es el mapeador de variables, este se encuentra bajo el t´ıtulo Mapeo de variables, una posible representaci´on del panel se puede ob-