Proceso y aplicación Web para la gestión de librerías de datos nucleares: Interfaz de usuario y herramientas

Texto completo

(1)Trabajo Fin de Grado Proceso y aplicación Web para la gestión de librerías de datos nucleares: Interfaz de usuario y herramientas. Daniel San Martín Duchen Grado en Ingeniería en Tecnologías Industriales Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros Industriales Unidad Docente de Informática Industrial. Tutor Prof. Santiago Tapia Fernández Fecha Julio, 2017.

(2)

(3) He sido un hombre afortunado en la vida: nada me fue fácil Sigmund Freud.

(4)

(5) Agradecimientos No quisiera dejar pasar la oportunidad de poder agradecer a varias personas que han influido, en mayor o menor medida, en la realización de este Trabajo Fin de Grado. En primer lugar, gracias a Raquel Martínez por presentarme este proyecto, a Santiago Tapia por brindarme la oportunidad de formar parte de él y a Samuel Ruiz por ser un gran compañero de equipo. En segundo lugar, gracias a Paola Duchen por enseñarme a ver la vida con otras gafas y a Pedro San Martín porque seguro que estaría muy orgulloso de su hijo. Por último, gracias a Sophie Lois por su apoyo incondicional, especialmente en esta última etapa del Grado; a Lorgio Duchen por enseñarme la filosofía del “PLVS VLTRA”; a mis amigos, porque sin ellos no sería yo mismo; y a mi querida Mia que me alegra la existencia.. 5.

(6)

(7) Índice general Resumen. 1. 1. INTRODUCCIÓN 1.1. Antecedentes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Formato ENDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Planteamiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . .. 3 3 3 4. 2. OBJETIVOS Y REQUISITOS 2.1. Objetivos generales del proyecto . . . . . 2.2. Requisitos del proyecto general por parte 2.3. Objetivos del Trabajo Fin de Grado . . . 2.4. Requisitos del Trabajo Fin de Grado . . 2.4.1. Requisitos funcionales . . . . . . 2.4.2. Requisitos no funcionales . . . . .. . . . . . .. 7 7 7 7 8 8 8. . . . de la . . . . . . . . . . . .. . . . NEA . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 3. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA 3.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. HTML . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.6. JavaScript . . . . . . . . . . . . . . . . . . . . . . . 3.2. Programas . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Apache Tomcat . . . . . . . . . . . . . . . . . . . . 3.3. Sistema de control de versiones . . . . . . . . . . . . . . . 3.3.1. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Bitbucket . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 11 11 11 12 12 13 13 14 17 17 17 17 19 20. 4. DESARROLLO E IMPLEMENTACIÓN 4.1. Descripción general de la aplicación NDTracker 4.2. Interfaz de usuario . . . . . . . . . . . . . . . . 4.2.1. Organización de los archivos . . . . . . . 4.2.2. Patrón modular. Closure . . . . . . . . . 4.2.3. Diseño web responsive: Bootstrap . . . . 4.2.4. API REST. SinglePage Application . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 21 21 23 24 25 26 27. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. i.

(8) Índice general. Índice general. 4.2.5. Funcionalidades de la aplicación . . . . . . . . . . . . . . . . . 4.3. Análisis de diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Estudio del archivo de texto . . . . . . . . . . . . . . . . . . . 4.3.2. Concepto de ULP. Comparación de números en coma flotante 4.3.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Presentación de resultados con D3 . . . . . . . . . . . . . . . . . . . . 4.4.1. Árbol de la función Análisis blame . . . . . . . . . . . . . . . 4.4.2. Árbol de la función Análisis de diferencias . . . . . . . . . . . 4.4.3. Árbol de la función Descarga . . . . . . . . . . . . . . . . . . 4.4.4. Árbol de diferencias en las funciones Propuesta y Librería de Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Seguridad con Spring Security . . . . . . . . . . . . . . . . . . . . . . 5. RESULTADOS 5.1. Login . . . . . . . . . . 5.2. Librerías . . . . . . . . 5.3. Análisis . . . . . . . . 5.4. Propuestas . . . . . . . 5.5. Testing . . . . . . . . . 5.6. Descargas . . . . . . . 5.7. Valoración de impactos 5.8. Responsabilidad social. 30 42 42 43 44 46 49 50 51 51 51. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 57 58 60 63 68 70 72 73 74. 6. PLANIFICACIÓN TEMPORAL Y PRESUPUESTO 6.1. Desarrollo ágil de software . . . . . . . . . . . . . 6.2. Planificación temporal . . . . . . . . . . . . . . . 6.3. Presupuesto del proyecto general . . . . . . . . . 6.3.1. Presupuesto simulado . . . . . . . . . . . . 6.3.2. Presupuesto real . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 75 75 77 79 80 80. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 7. CONCLUSIONES. 81. 8. ABREVIATURAS, 8.1. Abreviaturas 8.2. Unidades . . . 8.3. Acrónimos . .. UNIDADES y ACRÓNIMOS 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83. A. APÉNDICE 85 A.1. Patrón modular. Closures . . . . . . . . . . . . . . . . . . . . . . . . 85 Bibliografía. ii. 95.

(9) RESUMEN La Agencia de la Energía Nuclear (NEA), que depende de la Organización para la Cooperación y el Desarrollo Económicos (OECD), ha encargado a la UPM el desarrollo de un prototipo en forma de aplicación Web para la gestión de librerías de archivos nucleares que sea capaz de versionar, analizar y verificar archivos de tipo ENDF. Este tipo de archivos contienen información documentada sobre distintos procesos nucleares con un formato que puede ser leído por ordenador y además son utilizados como entrada para diversos programas de procesamiento de datos nucleares. El proyecto NDTracker tiene dos objetivos principales: 1. Diseño de una herramienta para el control y gestión de las distintas versiones de la librería JEFF de datos nucleares. 2. Diseño de un proceso automatizado para la creación de una versión de una librería, algo sin precedentes en la organización. Ha de cumplir los requerimientos del proceso primitivo no automatizado. Dentro del marco del proyecto que ha encargado la NEA, este Trabajo Fin de Grado tiene como objetivos específicos la creación de: 1. Un programa de análisis de diferencias entre dos versiones de un archivo con formato ENDF. 2. Una interfaz gráfica de la aplicación que sea coherente con el proceso de control y gestión de las librerías. 3. Los sistemas de seguridad dentro de la aplicación que sirvan para limitar el acceso a ciertas rutas URL en función del usuario registrado y el grupo al que pertenezca. Todo ello usando la librería de Java: Spring Security. 4. Una herramienta gráfica de visualización de resultados dentro de la aplicación mediante la librería de JavaScript D3. Para el desarrollo del Trabajo Fin de Grado se ha hecho uso de diversas tecnologías, como por ejemplo Eclipse, Git o Bitbucket, y lenguajes, como por ejemplo JavaScript, HTML, CSS, Java, etc, entre otros. Se han desarrollado más de 60 archivos de código que suman en total unas 5.500 líneas de código finales. El modelo de diseño seguido es el característico a proyectos de software ágiles, típicos de proyectos extensos y basados en iteraciones sucesivas hasta que se consigue el. 1.

(10) producto final. Durante todo este proceso ha habido mucha comunicación con la NEA y mucho feedback de futuros usuarios. El resultado de los distintos objetivos es satisfactorio para el cliente. Se resume en los siguientes puntos: Git con su comando git diff sólo es capaz de encontrar las líneas que han sido modificadas pero no es capaz de encontrar en qué parte de la línea se encuentra dicha modificación. El análisis de las diferencias entre 2 archivos ENDF ha llegado un paso más adelante al poder resaltar la parte modificada en cada línea. Se ha desarrollado una aplicación Web con una interfaz gráfica visualmente agradable e intuitiva con un diseño responsive y coherente con la filosofía RESTful. Además facilita y automatiza el proceso de creación de una versión y se encarga de la gestión de las distintas librerías. Se ha implementado un login propio basado en Spring Security que controla el acceso por rutas en función del grupo al que pertenezca el usuario y que protege a la aplicación de posibles ataques de CSRF. La presentación de los resultados es dinámica, interactiva y muy fácil de utilizar. Combina a la perfección con el diseño de la interfaz gráfica. Por último resaltar que este Trabajo de Fin de Grado se empezó en Septiembre de 2016 y ha finalizado en Julio de 2017 en el marco de los convenios de prácticas de estudiantes entre la Fundación para el Fomento de la Innovación Industrial (F2I2) y el Centro de Orientación e Información de Empleo (COIE ).. PALABRAS CLAVE NEA, archivos ENDF, librerías, versiones, materiales, nuclear, interfaz de usuario, diferencias, seguridad, árboles jerarquizados, JavaScript, Spring, Git, herramientas, proceso automatizado, Trabajo Fin de Grado.. 2.

(11) 1. INTRODUCCIÓN 1.1.. Antecedentes del proyecto. La NEA (Nuclear Energy Agency) es una agencia intergubernamental que se encuentra en el marco de referencia de la OECD (Organización para la Cooperación y el Desarrollo Económicos) y que facilita la cooperación entre países de infraestructura nuclear avanzada para buscar la excelencia en seguridad nuclear, tecnología, ciencia, medioambiente y legislación. Uno de los principales proyectos, dentro del banco de datos nuclear de la organización, es el JEFF (Joint Evaluated Fission and Fusion) Project que se encarga de producir un conjunto de archivos nucleares evaluados agrupados en librerías. Se entiende por archivos evaluados aquellos que son fruto de comparaciones, selecciones, filtros, normalizaciones y que sirven de punto de partida para un gran conjunto de aplicaciones nucleares y científicas. Están escritos en un riguroso formato denominado ENDF preparado para ser leído por ordenadores y que es muy útil para una gran cantidad de aplicaciones dentro del marco nuclear.. 1.2.. Formato ENDF. Tiene una estructura jerarquizada diferenciando: ’tape’, material, archivo y sección. Un ’tape’ ENDF es un archivo que contiene uno o más materiales ENDF. MAT hace alusión a un material ENDF MF se refiere a un archivo ENDF y éstos son utilizados para guardar distintos tipos de información como por ejemplo: • MF = 1 contiene información descriptiva. • MF = 2 contiene información sobre el parámetro de resonancia. • MF = 3 contiene información sobre la reacción de secciones eficaces vs energía. • MF = 4 contiene información sobre distribuciones angulares. • MF = 5 contiene información sobre distribuciones de energía. • etc.. 3.

(12) Capítulo 1. INTRODUCCIÓN. MT es una sección ENDF, que sirven para contener diferentes tipos de reacciones como por ejemplo: • MT = 1 es la sección eficaz total. • MT = 2 es la dispersión elástica. • MT = 18 es la fisión. • MT = 102 es la captura radiativa o radiante. • etc.. 1.3.. Planteamiento del proyecto. Como se ha podido ver, las librerías de datos nucleares JEFF contienen tipos de datos muy variados como datos de interacción de protones y neutrones, de desintegración radioactiva o de rendimientos de fisión. Existen distintas versiones de la librería JEFF con archivos nuevos o modificaciones de los ya existentes. El proceso de creación de una nueva versión de la librería o ’release’ es complejo. Comienza con el trabajo de los evaluadores, científicos encargados de investigar y probar los datos nucleares y de realizar propuestas con datos nuevos o modificados para la nueva versión de la librería. Seguidamente el staff de la NEA analiza esos cambios introducidos en las distintas propuestas y las aceptan si son coherentes con la actualización que se quiere realizar. Por último el grupo de coordinación de JEFF revisa todas las propuestas aceptadas y crea una nueva versión de la librería con las mejores. En este proceso se presentan tres problemas: 1. No tienen un sistema sencillo para identificar el origen de los datos, ya que la NEA es una agencia intergubernamental y en la que es común mezclar datos con otras organizaciones. 2. Un evaluador puede introducir cambios parciales, por ejemplo en una sola sección, que por un lado puede implicar cambios en otras secciones, y que por otro lado, resulta muy complicado separar los datos de origen de los nuevos o modificados. 3. El proceso de creación de una nueva librería es tedioso y no automatizado, dado el volumen de información y complejidad de los archivos de datos nucleares. Se ha visto que existen oportunidades muy claras para mejorar la gestión de las bases de datos de archivos nucleares y proveer de un mayor apoyo y eficacia a la hora de tomar decisiones en el proceso de lanzamiento de una nueva versión de una librería. Es por ello que la NEA plantea a la UPM: 1. El diseño de una herramienta en forma de aplicación web para el control y la gestión de las distintas versiones.. 4.

(13) 1.3 Planteamiento del proyecto 2. El diseño de un proceso normalizado para la creación de una versión de una librería, algo sin precedentes en la organización. Ha de cumplir los requerimientos del proceso primitivo no automatizado. Se necesita de un sistema de control de versiones para los archivos nucleares, que los analice, los verifique y los valide. Se propone por ello desarrollar un prototipo operacional y funcional de este sistema. Las actividades de datos nucleares en la NEA se llevan a cabo tanto en el Banco de Datos como en el Nuclear Science Division Working Party on International Nuclear Data Evaluation Co-operation (WPEC). En particular, a través del proyecto de librería de datos nucleares de la Joint Evaluated Fission and Fusion (JEFF), el Banco de Datos coordina la verificación, el testeo, la selección, la evaluación comparativa, el montaje y la distribución de archivos de datos nucleares en las versiones oficiales de la librería JEFF. Tanto la gestión de los archivos de datos nucleares por parte de la NEA como el trabajo en forma de contribuciones voluntarias por parte de una gran comunidad científica requieren de herramientas de software que asistan el proceso de subida, seguimiento y testeo de archivos de datos nucleares y que ayuden con el montaje final y el lanzamiento de una nueva versión de una librería de datos nucleares. El sistema de control de versiones para los datos nucleares cumplirá los siguientes objetivos: 1. Proporcionar un framework para la presentación de cambios en los archivos. 2. Registrar el historial de cambios. 3. Realizar un seguimiento, compartir actualizaciones e informar a la comunidad sobre los cambios en archivos evaluados y resultados de testeo sobre éstos. 4. Almacenar los metadatos1 asociados a los archivos evaluados. 5. El sistema debería proporcionar una herramienta que muestre todas las posibles opciones disponibles de los candidatos (por isótopos) y que muestre los resultados del análisis realizado por otros módulos (incluida la salida de NDEC), o de otras pruebas de una forma clara y accesible, proporcionando además indicadores (numéricos) que ayuden con la toma de decisiones a la hora de seleccionar un archivo candidato para una nueva versión de una librería de archivos de datos nucleares. El sistema de control de versiones establecerá de esta manera un flujo de trabajo claro para la subida de nuevos archivos o la actualización de cambios en los archivos. Se busca que tal flujo de trabajo formalice el proceso de preparación y creación de una nueva librería de datos nucleares de JEFF. Como tal, puede proporcionar un primer paso para establecer un estricto proceso para el ciclo de vida de las librerías. 1. del griego “meta” y del latín ”datum”. 5.

(14) Capítulo 1. INTRODUCCIÓN. El sistema de control de versiones debe tener la capacidad de poder ser complementado con otras herramientas en forma de módulos. Entre estas herramientas se encuentran: Sistema / módulo de seguimiento de problemas. Interfaz / enlace con la salida del NDEC. Un "módulo de análisis de los MF-MT". El propósito del "módulo de análisis de los MF-MT" es identificar que partes del archivo ENDF-6 son idénticas a las de otras versiones de otros archivos evaluados. Realizará una comparación de los datos proporcionados en el archivo presentado, con los archivos que ya existen en el sistema o plataforma, lo cual proporcionará información muy útil para la toma de decisiones y el seguimiento de datos nuevos o actualizados con cambios. Para todo ello se firma un convenio con la Fundación para el Fomento de la Innovación Industrial (F2I2) dentro del Laboratorio de Informática Industrial (LABI) de la ETSII siendo el coordinador del proyecto Don Santiago Tapia Fernández y el equipo de desarrollo va a estar formado por él mismo y dos estudiantes más de la ETSII cuya participación se enmarca en los convenios de prácticas de estudiantes entre la Fundación y el COIE. Los estudiantes son Samuel Ruiz Bernardo, graduado en Ingeniería de Tecnologías Industriales y estudiante del Máster de Electrónica Industrial, y Daniel San Martín Duchen, estudiante del Grado de Ingeniería de Tecnologías Industriales especializado en Técnicas Energéticas. Ambos realizarán sus Trabajos de Fin de Máster y de Fin de Grado respectivamente con este proyecto.. 6.

(15) 2. OBJETIVOS Y REQUISITOS 2.1.. Objetivos generales del proyecto. Como se ha visto con anterioridad, este Trabajo Fin de Grado se encuentra enmarcado dentro de un proyecto de mayor alcance cuyos objetivos son: 1. Diseño de una herramienta en forma de aplicación web para el control y la gestión de las distintas versiones. 2. El diseño de un proceso normalizado para la creación de una versión de una librería, algo sin precedentes en la organización. Ha de cumplir los requerimientos del proceso primitivo no automatizado.. 2.2.. Requisitos del proyecto general por parte de la NEA. Dado que el sistema va a ser utilizado por la NEA, el prototipo debe ser desarrollado con las tecnologías que utiliza la NEA normalmente, para asegurar la viabilidad del mantenimiento del prototipo o la continuación de su desarrollo. Esto se traduce en que para la realización de este proyecto la NEA pide una serie de requisitos para el entorno de desarrollo y la ejecución de la aplicación a saber: 1. ORACLE 11.2 como RDBMS1 . 2. Apache Tomcat 8 como servidor web. 3. El framework Spring de Java como librería y lenguaje de desarrollo. 4. Git 2.x. como base de datos y sistema de control de versiones. Hay dos opciones para usar Git: un host interno, es decir un host en la NEA; o uno externo, como Bitbucket que será la opción utilizada.. 2.3.. Objetivos del Trabajo Fin de Grado. Sin embargo, los objetivos específicos de este Trabajo Fin de Grado que ayudan a conseguir los objetivos generales del proyecto son los de diseñar: 1. Relational DataBase Management System, es un servidor de sql. El sistema actual no usa un RDBMS.. 7.

(16) Capítulo 2. OBJETIVOS Y REQUISITOS. 1. Un programa de análisis de diferencias entre dos versiones de un archivo con formato ENDF según distintos criterios de evaluación. 2. La interfaz gráfica de la aplicación siguiendo la filosofía de diseño web responsive mediante el uso de Bootstrap que sea coherente con el proceso de control y gestión de las librerías. 3. Los sistemas de seguridad dentro de la aplicación que sirvan para limitar el acceso a ciertas rutas URL en función del usuario registrado y el grupo al que pertenezca usando la librería de Java Spring Security. 4. Una herramienta gráfica de visualización de resultados dentro de la aplicación mediante la librería de JavaScript D3.. 2.4.. Requisitos del Trabajo Fin de Grado. Se van a distinguir dos tipos de requisitos de la aplicación web: los funcionales y los no funcionales.. 2.4.1.. Requisitos funcionales. La aplicación tiene que ser capaz de: 1. Controlar que el formato de los archivos que se suben a la aplicación sea el adecuado, y si no, no permitir la subida de ese archivo al sistema. 2. Analizar las diferencias entre dos archivos, es decir, comparar línea a línea los archivos para ver si presentan diferencias o no, según distintos criterios. 3. Llevar a cabo la gestión y el control de las librerías a través de una interfaz gráfica coherente con el sistema de control de versiones. 4. Autentificar a un usuario utilizando Spring Security. 5. Autorizar y restringir acciones en la aplicación en función de la identidad del usuario recogida en la autentificación, mediante Spring Security. 6. Mostrar las diferencias entre dos archivos línea a línea en una representación de tipo árbol desplegable e interactivo utilizando la librería de Javascript D3.. 2.4.2.. Requisitos no funcionales. Por otro lado, tiene que cumplir los siguientes requisitos no funcionales: 1. Que sea un diseño de web responsive, es decir, que se pueda visualizar de manera correcta en cualquier dispositivo. El diseño web responsive está basado en HTML y CSS.. 8.

(17) 2.4 Requisitos del Trabajo Fin de Grado 2. Que sea una aplicación de tipo API REST. Se entiende por API (Application Programming Interface) a un conjunto de funciones y procedimientos que cumplen una o muchas funciones con el fin de ser utilizadas por otro software. Permite implementar las funciones y procedimientos que se engloban en el proyecto sin necesidad de programarlas de nuevo. En términos de programación es una capa de abstracción. Una API REST es una biblioteca apoyada totalmente en el estándar HTTP. Visto de una forma más sencilla, es un servicio que provee de funciones que dan la capacidad de hacer uso de un servicio web dentro de la aplicación. [1, 2] 3. Que la aplicación no tenga recargas de contexto. 4. Utilización de closures en el diseño de toda la interfaz de usuario (en toda la parte de cliente). 5. Que el diseño de la aplicación sea ordenado y fácil de entender, es decir, que los HTML, CSS y Javascript estén separados en distintos documentos. 6. Crear un formulario de login, distinto al proporcionado por Spring Security, para la página Home, pero realizándose la autentificación a través del framework. 7. Que la presentación de resultados de la aplicación mediante árboles de D3 sea fácil de entender y manejar y sea interactiva y dinámica.. 9.

(18)

(19) 3. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA En este apartado se van a describir los principales lenguajes y tecnologías que se han utilizado durante la realización del Trabajo Fin de Grado.. 3.1.. Lenguajes. 3.1.1.. Java. Es uno de los lenguajes de programación más extendidos en el mundo de la programación ya que es independiente de la plataforma, lo que se traduce en que al hacer un programa en Java se podrá ejecutar en cualquier ordenador. Esto se consigue gracias a que existe una máquina de Java que hace de puente entre el sistema operativo y el programa de Java. Es un lenguaje orientado a objetos, es decir, que no está orientado a funciones o procesos. Los objetos están organizados en clases, que permiten que objetos individuales formen grupos juntos. Además los objetos se refieren a un tipo específico, o instancia, de una clase. Cada objeto tiene una estructura similar a los otros objetos de la misma clase, pero puede tener asignadas características individuales. Java es muy útil para aplicaciones web: el servidor recibe solicitudes desde un ordenador y envía al navegador, que actúa como cliente, páginas de respuesta. Otras características son que tiene su sintaxis inspirada en el lenguaje de programación C, requiere de compilación y es fuertemente tipado. [3] Un framework propiamente dicho es un marco para el desarrollo y/o la implementación de una aplicación. [4] Spring consiste en una plataforma Java que proporciona una infraestructura integral para el desarrollo de aplicaciones Java facilitando el trabajo. Es uno de los frameworks más utilizados. [5] Particularmente para este proyecto se van a utilizar dos módulos del framework Spring: Spring MVC y Spring Security.. 11.

(20) Capítulo 3 3.1.1.1.. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA Spring MVC. El módulo de Spring Web model-view-controller (MVC) más conocido como módulo de Web-Servlet, contiene el Spring MVC y la implementación de servicios web de tipo REST para aplicaciones web. [5] Se entiende por REST (REpresentational State Transfer) un servicio que no tiene estado (es stateless), lo que significa que cada llamada (HTTP Request) del cliente tiene toda la información necesaria y, en consecuencia, no depende de otras llamadas anteriores. Tanto el cliente como el servidor pueden tener su propio estado, pero el protocolo de comunicación entre ellos no tiene estado. Por otro lado en una API REST lo que tenemos son recursos, accesibles por identificadores (URIs). Sobre estos recursos podemos realizar acciones, generalmente diferenciadas a través de verbos HTTP distintos. [6] 3.1.1.2.. Spring Security. Spring Security proporciona servicios de seguridad para todo tipo de aplicaciones de software. Las dos principales áreas de la seguridad de las aplicaciones y de las que se encarga en especial Spring Security son la autentificación y la autorización, o control de acceso. La autentificación es el proceso por el cual se establece si un principal1 es quien dice ser. Por otro lado la autorización se refiere al proceso de decidir si un principal tiene permiso para realizar una acción en tu aplicación. Para llegar al punto de que se necesite tomar una decisión sobre la autorización para una determinada acción, la identidad del principal es necesaria y esta queda establecida por el proceso de autentificación. [7]. 3.1.2.. HTML. HTML2 es un lenguaje de marcado para describir la estructura de páginas web. Indica qué elementos componen cada página, y qué contiene cada uno de esos elementos. Es un estándar a cargo de la W3C. Se entiende por estándar web a un conjunto de reglas normalizadas que describen los requisitos que deben ser cumplidos por un producto, proceso o servicio, con el objetivo de establecer un mecanismo base para permitir que distintos elementos hardware o software que lo utilicen, sean compatibles entre sí.. 3.1.3.. CSS. CSS3 es un lenguaje que se utiliza para describir la presentación de las páginas web. Permite entre otras cosas, la adaptación de la presentación a distintos tipos de 1. Usuario, dispositivo o cualquier otro sistema que pueda realizar acciones en la aplicación HyperText Markup Language 3 Cascading Style Sheets 2. 12.

(21) 3.1 Lenguajes dispositivos y es independiente de HTML, una de sus principales ventajas, puesto que así queda separada la estructura o contenido de la presentación. Además CSS pueda controlar la disposición de muchas páginas web a la vez, ahorrando mucho trabajo. [8]. 3.1.3.1.. Bootstrap. Es un framework libre de HTML, CSS y JavaScript para realizar diseños web adaptativos4 , es decir que se adapten al tamaño de pantalla del dispositivo donde se use sin perder la funcionalidad de la aplicación ni la presentación de su interfaz gráfica. Contiene plantillas de diseño de tipografías, formularios, botones, navegación y otros componentes, así como extensiones de JavaScript. Algunas de las principales razones por las que los desarrolladores web prefieren el framework de Bootstrap son: Fácil de comenzar a utilizarlo, es intuitivo. Muy buen sistema de rejillas5 . Estilo básico para la mayoría de los elementos HTML. Gran lista de componentes para el diseño web. Posibilidad de instalación de plug-ins de JavaScript.. 3.1.4.. XML. XML (eXtensible Markup Language) es un lenguaje de etiquetas o marcado diseñado para describir información. Las etiquetas en XML no están predefinidas, hay que definirlas para el uso que se necesite. La principal diferencia con HTML es que se centra en lo que es en sí la información, en vez de como se presenta ésta, que es en lo que está basado HTML. Son dos lenguajes totalmente independientes.. 3.1.5.. SVG. SVG (Scalable Vector Graphics) es un formato de gráficos vectoriales bidimensionales, tanto estáticos como animados, en formato XML, cuya especificación es un estándar por el W3C. Su característica más relevante es que no pierden calidad de imagen al aplicarles un zoom o un cambio de tamaño. 4 5. del inglés “responsive” del inglés “grid system”. 13.

(22) Capítulo 3. 3.1.6.. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA. JavaScript. JavaScript es un lenguaje de programación que se usa con frecuencia en el desarrollo web. Es lenguaje ligero y ágil que no requiere de compilación, al ser interpretado directamente por los navegadores, y que tiene su principal uso del lado del cliente. A diferencia de Java no requiere de nada específico para programar en él pero tienen en común que su sintaxis también está inspirada en la del lenguaje de programación C. Por último resaltar que es un lenguaje débilmente tipado, es decir, que sus variables pueden no ser de un tipo específico y cambiar el tipo de contenido que almacenan. [9] JavaScript es muy amplio y está formado por un número muy grande de librerías para propósitos específicos. Para uno de los principales requisitos de la aplicación, la presentación de los resultados de una manera dinámica, interactiva y a la vez intuitiva, se hará uso de la librería D3. 3.1.6.1.. Librería D3. Data Driven Documents o más comúnmente conocida D3, es una librería de JavaScript que permite producir gráficos dinámicos e interactivos en navegadores web a partir de datos. Utiliza tecnologías bien sustentadas como SVG, HTML5 y CSS y se centra en enlazar los datos a elementos del DOM (Document Object Model). El DOM es en esencia: Una interfaz de plataforma que proporciona un conjunto estándar de objetos para representar documentos HTML, XHTML y XML. Un modelo estándar sobre cómo pueden combinarse dichos objetos. Una interfaz estándar para acceder a ellos y manipularlos. Gracias al DOM y lenguajes como JavaScript se puede acceder, añadir y cambiar dinámicamente contenido estructurado en documentos HTML y XML así como su estilo y estructura. [10] Los datos, a partir de los cuáles se crean los gráficos, hacen mucho más simple el código de D3 y de JavaScript si están escritos en formato JSON. Es por ello que se va a utilizar este formato siempre que se quiera intercambiar información en la aplicación entre el navegador y el servidor. 3.1.6.2.. JSON. JSON (JavaScript Object Notation) es un formato de texto ligero para el intercambio de datos que puede ser leído por cualquier lenguaje de programación y que consiste en una colección de pares nombre/valor. Es un subconjunto de la notación literal de objetos de JavaScript aunque debido a que es la principal alternativa a XML y tiene un fácil uso en JavaScript, se le considera un formato de lenguaje independiente.. 14.

(23) 3.1 Lenguajes Cuando se pretende intercambiar información entre un navegador y un servidor, es más común y sencillo que la información sea texto. JSON es texto, y la principal ventaja es que se puede convertir cualquier objeto de JavaScript en JSON, y viceversa, y así poder ser enviado al servidor sin traducciones ni análisis muy complicados. [11]. 3.1.6.3.. AJAX. Ajax no es una tecnología. Es realmente un conjunto de varias tecnologías, cada una aportando sus características y ventajas, juntándose para aportar nuevas soluciones.. Ajax incorpora distintas tecnologías todas ellas unidas mediante JavaScript:. Presentación basada en estándares haciendo uso de XHTML y CSS. Visualización dinámica y posibilidad de interacción usando el DOM6 .. Petición asíncrona de datos utilizando XMLHttpRequest.. Intercambio de datos y manipulación mediante XML y XSLT.. Una aplicación Ajax tiene la ventaja de que elimina la interacción natural “startstop-start-stop” con la Web introduciendo un intermediario - un motor de Ajax entre el cliente y el servidor. Permite realizar peticiones asíncronas (o síncronas, pero es menos usado) al servidor dejando que el usuario pueda seguir interactuando con la aplicación [12]. En la Subsección 4.2.4 se abordarán más ventajas de la utilización de Ajax en la aplicación.. 6. Document Object Model. 15.

(24) Capítulo 3. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA. Figura 3.1.: Modelo tradicional de aplicaciones web VS modelo Ajax. Figura 3.2.: Modelo síncrono VS modelo asíncrono. 16.

(25) 3.2 Programas 3.1.6.4.. jQuery. Es una librería de JavaScript rápida, pequeña y con muchas características. Permite el desplazamiento y manipulación de documentos HTML, manejo de eventos, animación y Ajax mucho más simple con una API fácil de usar que funciona en casi todos los navegadores [13].. 3.2.. Programas. 3.2.1.. Eclipse. Es lo que se denomina un IDE (Integrated Development Environment) o entorno de desarrollo integrado que es una aplicación informática que proporciona servicios integrales para facilitarle al desarrollador o programador el desarrollo de software. Consta de un editor de código fuente, herramientas de construcción automáticas, un depurador, un intérprete, un compilador y tienen auto-completado inteligente de código. Eclipse está basada en un modelo de plug-ins que sirven por ejemplo para utilizar APIs de otras tecnologías o que puedan funcionar en otros sistemas operativos sin cambios en las funcionalidades. [14]. 3.2.2.. Apache Tomcat. Es un contenedor web o contenedor de servlets desarrollado por la Apache Software Foundation (ASF) ya que implementa la API de Java Servlet y la de JavaServer Pages entre otras. Proporciona un entorno de servidor web HTTP puro en el cual puede funcionar código Java. La diferencia entre Apache y Apache Tomcat es que el primero es un servidor de HTTP, sirviendo HTTP, y que Tomcat es un Servlet y un servidor JSP sirviendo tecnología Java. Su principal ventaja es que nos sirve para trabajar el local con la aplicación.. 3.3.. Sistema de control de versiones. El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que se pueden recuperar versiones específicas más adelante. [15] Permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y. 17.

(26) Capítulo 3. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA. mucho más. Usar un sistema de control de versiones (VCS) también significa generalmente que un archivo se corrompe o se borra accidentalmente, puedes recuperarlos fácilmente. Además, se obtienen todos estos beneficios a un coste muy bajo. Por otro lado, la mayoría de los VCS están diseñados para proporcionar acceso compartido a los recursos (archivos) a un grupo de trabajo, estableciendo métodos y procesos indirectos para colaborar en un equipo. Para la mayoría de los equipos de software, el código fuente es un repositorio del conocimiento y la comprensión sobre el dominio del problema que los desarrolladores han recogido y refinado con cuidadoso esfuerzo. El control de versiones protege el código fuente de catástrofes y del error humano y proporciona seguridad para avanzar en el desarrollo mediante el seguimiento de los cambios. Los desarrolladores de software que trabajan en equipo están escribiendo continuamente código fuente nuevo y cambiando el código fuente existente. El código de un proyecto, aplicación o componente de software se organiza normalmente en una estructura de carpetas o "árbol de archivos". Un desarrollador del equipo puede estar trabajando en una nueva función mientras otro desarrollador puede estar arreglando otra, y cada desarrollador puede estar realizando sus cambios en varias partes del árbol de archivos. El control de versiones ayuda a los equipos a resolver este tipo de problemas, siguiendo cada cambio individual de cada contribuyente y ayudando a prevenir conflictos cuando hay un trabajo simultáneo en partes del código. Los cambios realizados en una parte del software pueden ser incompatibles con los cambios de otro desarrollador trabajando al mismo tiempo. Este problema debe ser reconocido y resuelto de una manera ordenada sin bloquear el trabajo del resto del equipo. Además, en todo desarrollo de software, cualquier cambio puede introducir nuevos errores y no se puede confiar en él hasta que sea testeado. En la creación de una nueva versión, el desarrollo y los test trabajan juntos. Un buen software de control de versiones admite el flujo de trabajo que prefiera un desarrollador sin imponer una manera particular de trabajar. También funciona en cualquier plataforma, en lugar de dictar qué sistema operativo deben utilizar los desarrolladores. Los buenos sistemas de control de versiones facilitan un flujo suave y continuo de cambios en lugar del frustrante y torpe mecanismo de bloqueo de archivos (luz verde a un desarrollador a expensas de bloquear el progreso de otros). Los equipos de software que no utilizan ningún tipo de control de versiones suelen tener problemas como el no saber qué cambios que se han hecho están disponibles para los usuarios o la creación de cambios incompatibles entre dos partes de trabajo no relacionadas que deben luego ser cuidadosamente y costosamente reelaboradas. El software de control de versiones es una parte esencial del trabajo diario de los equipos profesionales de software. Los desarrolladores de software que están acostumbrados a trabajar con un sistema de control de versiones suelen reconocer el valor increíble que tiene el control de versiones incluso para pequeños proyectos en solitario.. 18.

(27) 3.3 Sistema de control de versiones Aunque VCS se utiliza principalmente en el desarrollo de software, por supuesto, no está restringido solo al desarrollo de software, de hecho, cualquier tipo de proyecto de ingeniería podría beneficiarse de VCS siempre y cuando el resultado del proyecto consista en un conjunto de documentos (planes, esquemas, diagramas, etc.). Una vez acostumbrado a los poderosos beneficios del sistema de control de versiones, muchos desarrolladores (o ingenieros) no considerarían trabajar sin él incluso para proyectos que no son de software.. 3.3.1.. Git. Git da a sus usuarios la libertad de usar el VCS como ellos crean conveniente y soporta prácticas de desarrollo ágiles, como por ejemplo el desarrollo del kernel de Linux. Desde un punto de vista técnico, Git, su forma de almacenar datos, y las capacidades de uso están bien diseñadas y consideradas de última generación. Algunos de los beneficios que hacen Git atractivo para los desarrolladores son: Creación fácil y barata de ramas. La mayoría de los equipos de desarrollo manejan actividades de desarrollo paralelas en distintas ramas. Es raro que grandes equipos de desarrollo utilicen una única rama ya que requiere componentes estables e independientes. Como en la mayoría de los VCS distribuidos, Git hace un uso masivo de las ramas. A diferencia de los antiguos VCS, en Git es fácil crear ramas para asegurar el aislamiento del trabajo y mezclar los cambios más adelante. Las ramas locales también son muy útiles para los ingenieros que trabajan en varias tareas paralelas. Permitir hacer commits7 y revertirlos localmente. Esto es especialmente importante para el aislamiento de trabajo. Permite a los desarrolladores realizar commits más a menudo, para crear puntos de restauración local privada y combinarlos con ramas. Este podría ser el beneficio más poderoso para la mayoría de los desarrolladores. Estas características permiten a los desarrolladores de código trabajar de la manera que desean en lugar de estar obligados a trabajar de manera particular debido a las restricciones de una herramienta- En el contexto de este proyecto, todas estas características son necesarias para almacenar, actualizar, analizar y versionar los datos nucleares. Es interesante resaltar que el formato de archivo de los datos nucleares hacen de Git una solución perfecta, porque las bibliotecas de formato ENDF-6 son archivos de datos nucleares con formato de texto plano. ENDF es un formato basado en la normalización de líneas y secciones, muy similares a los archivos de código. Por último, pero no menos importante, Git también está disponible para ser implementado en cualquier aplicación Java con la biblioteca JGit, esto significa que es posible integrar comandos Git en el código Java por lo que no hay necesidad de llamar a ningún programa externo. 7. Se entiende por commit el guardado de los contenidos incluyendo un mensaje del usuario con los cambios que se han realizado.. 19.

(28) Capítulo 3. 3.3.2.. TECNOLOGÍAS APLICADAS. ESTADO DE LA TÉCNICA. Bitbucket. Bitbucket es un servicio gratuito de alojamiento basado en web que permite administrar proyectos usando el sistema de control de versiones Git pero en la nube.. 20.

(29) 4. DESARROLLO E IMPLEMENTACIÓN 4.1.. Descripción general de la aplicación NDTracker. NDTracker es la aplicación web que se va a desarrollar y debe contar con las siguientes funcionalidades: 1. Creación y visualización de librerías de archivos de datos nucleares. 2. Subida de archivos ENDF-6 de materiales a cualquier librería creada. 3. Versionado de los archivos que se suben al sistema. 4. Análisis de diferencias entre dos archivos de versiones subidas en librerías. 5. Análisis de “blame” de un archivo de una versión. 6. Gestión del proceso de creación de una nueva Propuesta para una librería existente. 7. Gestión del proceso de creación de una nueva Librería de Testing para una librería existente. 8. Descarga de archivos, Propuestas y Librerías de Testing. 9. Control de acceso a determinadas funcionalidades de la aplicación en función del grupo al que esté asociado un usuario y contraseña. Todas estas funcionalidades están agrupadas en 6 módulos: Inicio Librerías Análisis Propuestas Testing Descargas Se va a exponer con un grado mayor de detalle el proceso de creación de una nueva librería a partir de una propuesta realizada por un evaluador. El proceso de creación de una librería se divide en dos partes:. 21.

(30) Capítulo 4. DESARROLLO E IMPLEMENTACIÓN. Proceso de material individual (Figura 4.1): 1. Cualquier evaluador introduce una nueva Propuesta para una librería mediante la subida de un archivo ENDF de un material. 2. La Propuesta es analizada y como resultado del análisis el archivo puede ser aceptado e incluido dentro del sistema o rechazado y expulsado del sistema. 3. Tras ser aceptada una propuesta el siguiente paso es enviarla a NDEC 1 Como resultado se obtiene un informe de calidad y la actualización de la propuesta al estado “Testeada Individualmente”. 4. En este punto, el staff de la NEA decide si el informe sobre la propuesta es suficientemente bueno como para seleccionarla como candidata para formar parte de una Librería de Testing o no. Otra posibilidad que puede ocurrir es que dos o más Propuestas puedan ser complementarias luego pueden ser mezcladas en una única Propuesta. En este caso el mezclado deben realizarlo los evaluadores.. Figura 4.1.: Propuesta de material 1. Un módulo externo de la NEA para analizar los archivos de una propuesta. En la aplicación se ha utilizado un simulador de NDEC.. 22.

(31) 4.2 Interfaz de usuario Proceso de librerías de testeo (Figura 4.2): 1. Un experto crea una Librería de Testing dada una colección de materiales candidatos con la única restricción de que sólo se puede seleccionar una Propuesta candidata por material. 2. La Librería de Testing es registrada dentro del sistema NDTracker. 3. La Librería de Testing es enviada de nuevo a NDEC y después del proceso de análisis se recibe como respuesta un informe de calidad y la Librería de Testing se actualiza al estado de “Testeada Grupalmente”. 4. De todas las Librería de Testing, sólo una de ellas es seleccionada e incluida como nueva versión de la librería.. Figura 4.2.: Librería de Testing Por último se van a desarrollar los 4 objetivos a cumplir de este Trabajo Fin de Grado.. 4.2.. Interfaz de usuario. El diseño de cualquier interfaz de usuario ha de estar basado en unos principios fundamentales, a saber:. 23.

(32) Capítulo 4. DESARROLLO E IMPLEMENTACIÓN. 1. Uniformidad de los comandos y menús, de la manera en que estos conectan con la aplicación. Así el conocimiento aprendido en una sección de la aplicación es útil para toda ella. Le da coherencia y facilita al usuario su interacción con la aplicación. 2. Principio de mínima sorpresa. La aplicación cuenta con un diagrama de trabajo muy claro y especificado que ayuda una vez aprendido a entender como funciona el sistema y que limita las posibles acciones que interfieran en el correcto funcionamiento de la aplicación. 3. Guía de usuario. Para facilitar la comprensión de la interfaz de usuario esta cuenta con leyendas en algunos botones y descripción en todas las páginas que la componen. 4. Diversidad de usuarios. Está diseñada para que pueda ser utilizada por los evaluadores, el personal de la NEA y por el grupo JEFF. Además de los principios antes mencionados la interfaz de usuario de la aplicación web que se desarrolla está diseñada centrándose en cumplir algunos de los requisitos funcionales (1) y no funcionales (2-5) expuestos en Sección 2.4. Éstos son: 1. Llevar a cabo la gestión y el control de las librerías a través de una interfaz gráfica coherente con el sistema de control de versiones. 2. Que sea un diseño de web responsive, es decir, que se pueda visualizar de manera correcta en cualquier dispositivo. El diseño web responsive está basado en HTML y CSS. 3. Que sea una aplicación de tipo API REST. Se entiende por API (Application Programming Interface) a un conjunto de funciones y procedimientos que cumplen una o muchas funciones con el fin de ser utilizadas por otro software. Permite implementar las funciones y procedimientos que se engloban en el proyecto sin necesidad de programarlas de nuevo. En términos de programación es una capa de abstracción. Una API REST es una biblioteca apoyada totalmente en el estándar HTTP. Visto de una forma más sencilla, es un servicio que provee de funciones que dan la capacidad de hacer uso de un servicio web dentro de la aplicación. [2] 4. Utilización de closures en el diseño de toda la interfaz de usuario (en toda la parte de cliente). 5. Que el diseño de la aplicación sea ordenado y fácil de entender, es decir, que los HTML, CSS y JavaScript estén separados en distintos documentos.. 4.2.1.. Organización de los archivos. En la creación de la interfaz de usuario se van a utilizar lenguajes como HTML, CSS, JavaScript, combinando las capacidades de unos con las de otros para lograr el resultado deseado. Existen dos maneras de organizar los archivos, ambas correctas:. 24.

(33) 4.2 Interfaz de usuario 1. Juntar todos los lenguajes en un archivo HTML sabiendo que la parte de JavaScript ha de ir entre etiquetas script, y que la parte de CSS ha de ir dentro de las etiquetas style. 2. Separar los lenguajes en 3 archivos, uno para cada lenguaje, con el mismo nombre pero distinta extensión. Hay que tener en cuenta que para que se incluyan los archivos JavaScript y CSS en el archivo HTML, hay que dejarlo especificado en éste, mediante las etiquetas script y link respectivamente, tal y como se muestra a continuación. 1 2 3 4 5 6 7 8 9. < script type = " text / javascript " src = " / ndtracker / static / external / jquery - validate /1.15.0/ jquery . validate . min . js " > </ script > < script type = " text / javascript " src = " / ndtracker / static / external / bootstrap /3.3.7/ js / bootstrap . min . js " > </ script > < script src = " / ndtracker / static / external / d3js_org / d3 - hierarchy . v1 . min . js " > </ script > < script src = " / ndtracker / static / external / d3js_org / d3 . v3 . min . js " > </ script > < script src = " / ndtracker / static / external / d3js_org / d3 . v4 . min . js " > </ script > < script type = " text / javascript " src = " / ndtracker / static / libs / o n _ s u c c e s s _ g e t _ l i b . js " > </ script >. 10 11 12. < script type = " text / javascript " src = " / ndtracker / static / index / index . js " > </ script > </ html >. Para esta aplicación se ha elegido el segundo método. Aunque pueda parecer que tener tres archivos en vez de uno no es nada útil, la experiencia dice lo contrario, ya que los archivos de código que se manejan son bastante extensos y a la hora de corregir errores o facilitar su entendimiento por terceras personas, es mucho más fácil si cada lenguaje se encuentra en un archivo separado. Dado que la idea es que este prototipo sea para que la NEA lo utilice, lo mejore y realice las tareas de mantenimiento necesarias, es vital de importancia que el código esté ordenado y separado.. 4.2.2.. Patrón modular. Closure. El patrón modular es una filosofía de diseño del lenguaje JavaScript. En el apéndice se encuentra la explicación detallada de los conceptos previos que hay que tener para entender las ventajas que tiene el patrón modular que son: 1. Código limpio, separado y organizado. 2. Soportan datos privados. 3. Código escalable. El diseño de la aplicación está regido por este patrón como se verá posteriormente. Aquí dejamos el ejemplo del closure más pequeño que tiene la aplicación, dado que hay closures que cuentan con hasta 280 líneas de código. Ahí es donde se resaltan más las ventajas del patrón modular ya que tareas como el mantenimiento del código son facilitadas por esta filosofía de diseño.. 25.

(34) Capítulo 4. 1 2 3 4 5 6 7 8 9 10 11 12 13. DESARROLLO E IMPLEMENTACIÓN. f u n c t i o n i n i t _ a d d _ l i b r a r y () { var o n _ s u c c e s s = f u n c t i o n ( data ) { $ ( ’ body ’) . r e m o v e C l a s s ( ’ waiting ’) ; console . log (" result : " + JSON . s t r i n g i f y ( data ) ) ; $ ("# r e s u l t _ l i b s ") . html (" < code > < pre >"+ JSON . s t r i n g i f y ( data ) +" </ pre > </ code >") ; } var o n _ e r r o r = f u n c t i o n () { $ ( ’ body ’) . r e m o v e C l a s s ( ’ waiting ’) ; $ ("# r e s u l t _ l i b s _ h e a d e r ") . html (" Error ") ; $ ("# r e s u l t _ l i b s _ p a n e l ") . attr (" style " , " v i s i b i l i t y : visible ") ; $ ("# r e s u l t _ l i b s ") . html (" Error !") ; } var a d d _ l i b r a r y = f u n c t i o n () {. 14. $ ("# r e s u l t _ l i b s _ h e a d e r ") . html (" Result ") ; $ ("# r e s u l t _ l i b s _ p a n e l ") . attr (" style " , " v i s i b i l i t y : visible ") ; var l i b _ n a m e = $ ("# name ") . val () ; var d a t a _ o b j = {" name ": l i b _ n a m e }; $ ( ’ body ’) . a d d C l a s s ( ’ waiting ’) ; $ . ajax ({ c o n t e n t T y p e : ’ a p p l i c a t i o n / json ’ , data : JSON . s t r i n g i f y ( d a t a _ o b j ) , d a t a T y p e : ’ json ’ , success : on_success , error : on_error , p r o c e s s D a t a : false , type : ’ POST ’ , url : ’/ n d t r a c k e r / libs ’ , b e f o r e S e n d : f u n c t i o n ( request ) { request . s e t R e q u e s t H e a d e r (" X - CSRF - TOKEN " , $ ("# t h e _ c s r f ") . attr (" value ") ) ; } }) ;. 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39. } var w i r e _ b u t t o n = f u n c t i o n () { $ ("# submit ") . click ( a d d _ l i b r a r y ) ; } w i r e _ b u t t o n () ; } $ ("# a d d _ l i b r a r y ") . ready ( i n i t _ a d d _ l i b r a r y ) ;. 4.2.3.. Diseño web responsive: Bootstrap. Una de las mayores ventajas que proporciona el framework Bootstrap es que permite con cierta facilidad realizar diseño web responsive. Como se explico con anterioridad, responsive significa adaptativo, que se adapta a cualquier tamaño de dispositivo. Obviamente esto se consigue mediante hojas de estilo CSS, que una vez añadidas a nuestra aplicación y mediante la utilización de las clases correctas de Bootstrap podemos disfrutar de todas sus características. 1 2. 1 2 3. 26. < link rel = " stylesheet " href = " / ndtracker / static / external / bootstrap /3.3.7/ css / bootstrap . min . css " >. < script type = " text / javascript " src = " / ndtracker / static / external / jquery - validate /1.15.0/ jquery . validate . min . js " > </ script > < script type = " text / javascript ".

(35) 4.2 Interfaz de usuario. 4 5 6. src = " / ndtracker / static / external / bootstrap /3.3.7/ js / bootstrap . min . js " > </ script > < script src = " / ndtracker / static / external / d3js_org / d3 - hierarchy . v1 . min . js " > </ script > < script src = " / ndtracker / static / external / d3js_org / d3 . v3 . min . js " > </ script >. Figura 4.3.: Diseño web responsive. 4.2.4.. API REST. SinglePage Application. Una API es una forma de describir la forma en que los programas o los sitios webs intercambian datos. Normalmente es JSON o XML. Se necesita una API para ofrecer datos a la aplicación por ejemplo. Una API REST2 es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP. ¿Cómo funciona REST? A través de llamadas al API, las cuales se implementan como peticiones HTTP en las que: La URL representa el recurso. El método (verbos HTTP ) representa la operación. 2. REpresentational State Transfer. 27.

(36) Capítulo 4. DESARROLLO E IMPLEMENTACIÓN. El código de estado HTTP representa el resultado REST se compone de una lista de reglas que se deben cumplir en el diseño de la arquitectura de una API: Interfaz uniforme: la interfaz se basa en recursos. El servidor mandará los datos pero lo que tenga en su interior para el cliente es transparente. La representación del recurso que le llega al cliente, será suficiente para poder modificar el recurso, suponiendo que tenga permisos. Peticiones sin estado: HTTP es un protocolo sin estado, luego tiene un mejor rendimiento. Cada petición tiene toda la información para procesarla y no dependen de peticiones anteriores. Hay que resaltar que tanto el servidor como el cliente pueden tener estado, pero el protocolo no. Cacheable: en la web los clientes pueden cachear las respuestas del servidor. Separación de cliente y servidor: su unión es la interfaz uniforme. Mientras la interfaz no cambie, se podrá cambiar el cliente o el servidor sin problemas. Sistema de capas: el cliente puede estar conectado mediante la interfaz al servidor o a un intermediario, para el es irrelevante y desconocido. Al cliente sólo le preocupa que la API REST funcione como debe. Puede servir para aumentar la escalabilidad. Código bajo demanda: los servidores pueden ser capaces de aumentar o definir cierta funcionalidad en el cliente transfiriéndole cierta lógica que puede ejecutar, como por ejemplo JavaScript en cliente. En NDTracker la filosofía REST se evidencia en: El protocolo es stateless, sin estado. Cada petición tiene toda la información para procesarla y además no dependen de las anteriores. Tanto el cliente como el servidor pueden tener estado pero el protocolo no. Interfaz uniforme: la interfaz se basa en recursos. El servidor mandará los datos pero lo que tenga en su interior para el cliente es transparente. La representación del recurso que le llega al cliente, será suficiente para poder modificar el recurso mediante peticiones GET o POST, suponiendo que tenga permisos. Tanto el servidor como el cliente intercambian información de recursos en formato JSON. El planteamiento de la aplicación se realiza en función de los datos que se van a intercambiar, luego la interfaz gráfica es una consecuencia de los datos. Esto aporta más escalabilidad y más seguridad. La utilización de AJAX para realizar peticiones en el lado del cliente. Es coherente con la filosofía REST, orientada a recursos. Nos permite realizar peticiones sin hacer una recarga del contexto. 1 2 3 4. 28. $ . ajax ({ url : "/ n d t r a c k e r / libs / tags ? lib =" + library , type : " GET " , success : f u n c t i o n ( data ) {.

(37) 4.2 Interfaz de usuario. html = ""; var i ; for ( i = 0; i < data . length ; ++ i ) { version = data [ i ]. version ; html += " < option value =" + version + " >" + version + " </ option >"; } $ ("# t e s t i n g _ t a g s _ s e l e c t ") . html ( html ) ;. 5 6 7 8 9 10 11. }, error : f u n c t i o n () { $ ("# r e s u l t _ t e s t i n g ") . html (" Error !") ; }. 12 13 14 15 16. }) ;. AJAX y el realizar peticiones sin recarga de contexto nos lleva a otra característica reseñable de la aplicación. Cumple varios requisitos de una SPA (Single-Page Application) ya que la aplicación cabe en una sola página con el propósito de dar una experiencia más fluida a los usuarios como una aplicación de escritorio. En un SPA los recursos necesarios se cargan dinámicamente como lo requiera la página y se van agregando, normalmente como respuesta de las acciones del usuario.. Figura 4.4.: Ciclo tradicional VS Ciclo SPA. 29.

(38) Capítulo 4. DESARROLLO E IMPLEMENTACIÓN. Figura 4.5.: Diseño tradicional VS Diseño SPA. 4.2.5.. Funcionalidades de la aplicación. Las funcionalidades de la aplicación se reparten en los 6 módulos citados al comienzo del apartado: Inicio, Librerías, Análisis, Propuestas, Testing y Descargas. Dentro de cada una se trabaja con distintos tipos de formularios y sus respectivas respuestas. Se va a analizar cada uno de los grupos, explicar esquemáticamente que función realizan y aportar extractos del código desarrollado. Dado que no podemos mostrar todo el código de la aplicación, de cada módulo se van a elegir los extractos de código más representativos o interesantes. En el apartado de resultados se podrán ver imágenes del resultado final de la interfaz gráfica asociada a cada uno de los módulos. 4.2.5.1.. Inicio. Permite el acceso a los distintos módulos y la autentificación mediante un formulario de login. Cuadro 4.1.: Seguridad Función Entrada Actores Prerequisitos Descripción. 30. Seguridad Usuario y contraseña de un usuario Usuarios registrados Estar registrado en la base de datos de la NEA Autorización, roles y permisos. Evaluación de seguridad.

(39) 4.2 Interfaz de usuario El formulario de login que se utiliza es el siguiente, se destaca la aparición de la tecnología CSRF que se explicará con detalle en el apartado de seguridad Sección 4.5. < div id = loginForm > < form class = " navbar - form navbar - right " accept - charset = " utf -8 " action = " / ndtracker / login " method = " POST " > < div class = " form - group " > < input type = " text " class = " form - control " name = " username " placeholder = " Username " > </ div > < div class = " form - group " > < button type = " submit " id = " login " class = " btn btn - default " value = " login " > Sign In </ button > </ div > < div class = " form - horizontal " > < input type = " password " class = " form - control " name = " password " placeholder = " Password " > </ div > < input name = " $ { _csrf . parameterName } " value = " $ { _csrf . token } " type = " hidden " > </ form > </ div >. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19. La manera en que se accede a los distintos módulos es la siguiente, se muestra primero el extracto de la parte de código HTML y a continuación la parte de JavaScript que se ejecuta en cliente para realizar la petición deseada. < li > <a data - toggle = " tab " < li > <a data - toggle = " tab " A n a l y s i s </ a > </ li > < li > <a data - toggle = " tab " P r o p o s a l s </ a > </ li > < li > <a data - toggle = " tab " / a > </ li > < li > <a data - toggle = " tab " D o w n l o a d s </ a > </ li > </ ul >. 1 2 3 4 5 6. href = " # libs " id = " libs_tab " > Libs </ a > </ li > href = " # analysis " id = " analysis_tab " > href = " # proposals " id = " proposals_tab " > href = " # testing " id = " testing_tab " > Testing < href = " # downloads " id = " downloads_tab " >. 7. < div class = " tab - content " >. 8. 1. f u n c t i o n i n i t _ i n d e x () {. 2 3. var l i b s _ t a b = f u n c t i o n () {. 4. $ ("# f o r m _ l i b s ") . html ("") ; $ ("# r e s u l t _ l i b s ") . html ("") ; $ ("# f o r m _ l i b s _ p a n e l ") . attr (" style " , " v i s i b i l i t y : hidden ") ; $ ("# r e s u l t _ l i b s _ p a n e l ") . attr (" style " , " v i s i b i l i t y : hidden ") ;. 5 6 7 8 9 10. };. 4.2.5.2.. Librerías. Este módulo está formado por 3 archivos HTML y 4 archivos JavaScript estructurados de tal manera que cada archivo HTML corresponde a un formulario y los. 31.

(40) Capítulo 4. DESARROLLO E IMPLEMENTACIÓN. JavaScript se encargan de enlazar con el servidor y servir la respuesta. Se encargan de controlar y gestionar las librerías dentro del sistema con las siguientes acciones: creación y visualización de librerías, subida de archivos ENDF o versionado de la librería. Creación y visualización de librerías:. Cuadro 4.2.: Control de librerías Función Entrada Salida Actores Prerequisitos Descripción. Control de librerías Nombre de librería On success: Crea o muestra la/s librería/s On error: Excepción Usuarios registrados Crea o muestra librerías. La visualización de las librerías existentes se lleva a cabo con el siguiente código: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24. f u n c t i o n o n _ s u c c e s s _ g e t _ l i b ( data ) { $ ( ’ body ’) . r e m o v e C l a s s ( ’ waiting ’) ; if ( data . length > 0) { $ ("# r e s u l t _ l i b s ") . html (" < ul class = ’ list - group ’ > </ ul >") ; d3 . select ("# r e s u l t _ l i b s ") . s e l e c t A l l (" li ") . data ( data ) . enter () . append (" li ") . text ( f u n c t i o n ( d ) { var r e s p on s e = "" + d . name + ": "; for ( i = 0; i < d . v e r s i o n s . length ; i ++) { if ( i !=0) { r e s p o n s e += " - " + d . v e r s i o n s [ i ]; } else { r e s p o n s e += d . v e r s i o n s [ i ]; } } return r e s p o n s e ; }) ; $ ("# r e s u l t _ l i b s li ") . a d d C l a s s (" list - group - item ") } else { $ ("# r e s u l t _ l i b s ") . html (" No l i b r a r i e s found .") ; } }. Subida de archivos ENDF a una librería existente:. 32.

(41) 4.2 Interfaz de usuario Cuadro 4.3.: Subida de archivos Función Entrada Salida Actores Prerequisitos Descripción. Subida de archivos Archivos ENDF On success: Información del proceso On error: Excepción Usuarios registrados La existencia de al menos una librería Esta funcionalidad permite la comunicación con usuarios y otros sistemas porque admite archivos de entrada en el sistema NDTracker. Como ejemplo representativo de los distintos formularios HTML que hay en toda la aplicación se va a exponer el de la subida de archivos, ya que es uno de los más generales, con múltiples campos de distintos tipos y subida de archivo incluida. Además se le ha añadido una barra de progreso que una vez completa nos indica que se ha conectado con el servidor y éste empieza a trabajar. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37. < div id = " u p l o a d _ l i b r a r y _ l i b s " > < h1 > Upload new version for s e l e c t e d library </ h1 > < form class = " form - inline " id = " upload " method = " post " action = " / ndtracker / libs / versions " enctype = " multipart / form - data " > < div class = " form - group " > < label for = " library " > Select Library : </ label > < select class = " form - control " id = " library " name = " library " > </ select > </ div > < br > < br > < div class = " form - group " > < label for = " version " > Actual version : </ label > < input type = " text " class = " form - control " name = " version_ " id = " version_ " d i s a b l e d = " disabled " > < br > < br > < input type = " hidden " name = " version " id = " version " > < div class = " radio - inline " > < label class = " radio " > < input type = " radio " name = " newVersion " value = " major " checked = " checked " > New version </ label > </ div > < div class = " radio - inline " > < label class = " radio " > < input type = " radio " name = " newVersion " value = " minor " > New s u b v e r s i o n </ label > </ div > < div class = " radio - inline " > < label class = " radio " > < input type = " radio " name = " newVersion " value = " hotfix " > Hotfix </ label > </ div > </ div > < br > < br > < div class = " form - group " > < label for = " comment " > Comment : </ label > < t e x t a r e a class = " form - control " rows = " 2 " cols = " 26 " name = " message " id = " message " > </ t e x t a r e a > </ div > < br > < br > < div class = " container " > < div class = " table - responsive " > < table class = " table " id = " fileTable " >. 33.

(42) Capítulo 4. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58. DESARROLLO E IMPLEMENTACIÓN. < tbody > < tr > < td > < input name = " files [0] " type = " file " / > </ td > </ tr > </ tbody > </ table > </ div > </ div > < br > < br > < button type = " button " class = " btn btn - default " id = " b_upload " > Create New Version </ button > < div class = " container " id = " p r o g r e s s _ u p l o a d i n g " style = " display : none " > <p > U p l o a d i n g P r o g r e s s </ p > < div class = " progress " > < div id = " pr o gr es s_ b ar _i d " class = " progress - bar " role = " progressbar " aria - valuenow = " 0 " aria - valuemin = " 0 " aria - valuemax = " 100 " style = " width : 0 %" >0 %</ div > </ div > </ div > </ form > </ div >. 59 60 61. < script type = " text / javascript " src = " / ndtracker / static / libs / upl oad_libr ary . js " > </ script >. Dentro del JavaScript de la subida de archivos destacar que se utiliza XHR (XMLHttpRequest), una interfaz que sirve para realizar peticiones HTTP, proporcionar contenido dinámico y actualizaciones asíncronas en páginas web mediante el uso de tecnologías como Ajax. En NDTracker se utiliza también para añadir comentarios del estado de la subida para el cliente dado que este proceso puede tardar algunos minutos dado el tamaño de algunas librerías de datos nucleares (del orden de 1GB). 1 2 3 4 5 6 7 8 9 10 11. var fd = new F o r m D a t a ( d o c u m e n t . g e t E l e m e n t B y I d (" upload ") ) ; var xhr = new X M L H t t p R e q u e s t () ; xhr . open (" POST " , "/ n d t r a c k e r / libs / v e r s i o n s " , true ) ; xhr . s e t R e q u e s t H e a d e r (" X - CSRF - TOKEN " , $ ("# t h e _ c s r f ") . attr (" value ") ) ; xhr . r e s p o n s e T y p e = " text "; // Start u p l o a d i n g xhr . upload . a d d E v e n t L i s t e n e r (" l o a d s t a r t " , f u n c t i o n ( evt ) { console . log (" l o a d s t a r t event : %o " , evt ) ; $ ("# p r o g r e s s _ u p l o a d i n g ") . attr ( { " style " : " display : inline " } ) ; $ ("# r e s u l t _ l i b s ") . html (" U p l o a d i n g Started , please wait ...") ; } , false ) ;. Versionado de los archivos subidos:. Se encarga de asignar una etiqueta en forma del número de versión al que corresponden los archivos subidos, para que así sea más fácil encontrarlos y manejarlos.. 34.