Interfaz de usuario para un generador de informes estadísticos
60
0
0
Texto completo
(2) AGRADECIMIENTOS A mi familia, en especial a mi abuelo Nicolás por encaminarme en los estudios, a mi abuela Josefina por toda la comida y a mi madre por el apoyo económico. A mi amigo y compañero de andanzas Vicente. A Antonio, profesor y director del IES Ciudad de los Ángeles, por ser un modelo a seguir. A toda la gente que conocı́ en la universidad de Aalto.. 2.
(3) Índice general ABSTRACT. i. RESUMEN. ii. DEFINICIONES. iii. 1 INTRODUCCIÓN Y OBJETIVOS 1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 1 2. 2 TRABAJOS PREVIOS. 4. 3 DESARROLLO 3.1 Lenguajes y herramientas utilizados . . . . . . . . . . . . . 3.1.1 draw.io . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Eclipse IDE for Java Developers . . . . . . . . . . . 3.1.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 JavaFX . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 JSON . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.6 LATEX . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.7 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . 3.1.8 R . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Primera parte: Planificación . . . . . . . . . . . . . . . . . 3.2.1 Comparativa de diagramas de Gantt: primera parte 3.2.2 Comparativa de diagramas de Gantt: segunda parte 3.3 Segunda parte: Diseño inicial de la GUI . . . . . . . . . . . 3.3.1 Esquema básico de la aplicación . . . . . . . . . . . 3.3.2 Ventana de selección de ficheros . . . . . . . . . . . 3.3.3 Ventana de personalización de la salida . . . . . . . 3.3.4 Ventana de finalización . . . . . . . . . . . . . . . . 3.4 Tercera parte: Desarrollo de la aplicación . . . . . . . . . . 3.4.1 Ficheros de la aplicación . . . . . . . . . . . . . . . 3.4.2 Flujo de trabajo de la interfaz . . . . . . . . . . . . 3.4.3 Layout y navegación de la interfaz . . . . . . . . . . 3.4.4 Menú de opciones . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. 8 8 8 8 9 9 10 11 11 12 12 13 15 17 18 20 22 24 25 25 27 30 34.
(4) 3.4.5 3.4.6 3.4.7 3.4.8. Control de sesión . . . . . . . . Formato de los datos de entrada Manual del usuario . . . . . . . Clases y métodos de la interfaz. 4 CONCLUSIONES. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 37 40 42 43 48.
(5) Índice de figuras de salida de Dashzen. . . . . . . . . de pantalla de Power BI. . . . . . . de pantalla de SAP BusinessObjects de pantalla de Qlik Sense. . . . . . web. . . . . . . . . . . . . . . . . .. 2.1 2.2 2.3 2.4 2.5. Ejemplo Captura Captura Captura SpagoBI. . . . . . . . . . . Lumira. . . . . . . . . . .. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26. Logo de draw.io. . . . . . . . . . . . . . . . . . . . Logo de Eclipse. . . . . . . . . . . . . . . . . . . . . Logo de Java. . . . . . . . . . . . . . . . . . . . . . Logo de JavaFX. . . . . . . . . . . . . . . . . . . . Logo de JSON. . . . . . . . . . . . . . . . . . . . . Logo de LATEX. . . . . . . . . . . . . . . . . . . . . Logo de Overleaf. . . . . . . . . . . . . . . . . . . . Logo de R. . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Gantt planificado de la primera parte Diagrama de Gantt real de la primera parte . . . . Diagrama de Gantt planificado de la segunda parte Diagrama de Gantt real de la segunda parte . . . . Esquema básico de la interfaz. . . . . . . . . . . . . Ventana de selección de ficheros . . . . . . . . . . . Ventana de personalización de la salida . . . . . . . Ventana de finalización. . . . . . . . . . . . . . . . Ficheros de Tardis2 . . . . . . . . . . . . . . . . . . Archivos de la carpeta Source . . . . . . . . . . . . Diagrama de flujo. . . . . . . . . . . . . . . . . . . Escena 1. Selección de ficheros. . . . . . . . . . . . Escena 2. Selección de ficheros CSV. . . . . . . . . Escena 3. Personalización de la salida. . . . . . . . Escena 4. Finalización. . . . . . . . . . . . . . . . . Desplegable de “Data”. . . . . . . . . . . . . . . . . Desplegable de “Configuration”. . . . . . . . . . . . Créditos de la aplicación. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 5 5 6 6 7. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. 8 8 9 9 10 11 11 12 13 14 15 16 18 20 22 24 25 26 28 30 31 32 33 35 35 37.
(6) ABSTRACT This project exposes the development of a graphical user interface for a statistical report generator written in R. The purpose of this interface is making the aforementioned tool more accessible for a larger public with less experience and less knowledge regarding computer science, all without cutting the report’s customization freedom. As with just the core tool itself, once the user has finished the interface’s workflow, it will produce both a PDF file containing the report and a TEX template which the users can modify as they see fit. An intuitive graphical interface has been developed in order to soften the tool’s learning curve, as well as an user manual in which it is explained how to correctly install the tool’s dependencies. The general aim for this project has been the development of a software similar to what the regular user is used to, thus favouring accessibility.. i.
(7) RESUMEN El presente proyecto expone el desarrollo de una interfaz gráfica de usuario para un generador de informes estadı́sticos escrito en R. El propósito de esta interfaz es hacer más accesible la herramienta a un público más amplio con menos experiencia y conocimientos técnicos de informática, sin reducir la libertad de personalización del informe. De igual manera que con solo el generador, al finalizar el flujo de trabajo con la interfaz, el usuario obtendrá tanto un fichero PDF con el informe como una plantilla TEX que podrá modificar a su gusto. Se ha diseñado una interfaz gráfica intuitiva para suavizar la curva de aprendizaje de la herramienta, ası́ como un manual para el usuario en el que se explica cómo instalar correctamente las dependencias de la herramienta. La intención general ha sido la de desarrollar un software parecido a lo que un usuario medio esté acostumbrado en pos de su accesibilidad.. ii.
(8) DEFINICIONES UI: Del inglés User Interface (Interfaz de Usuario). Es el espacio en el que tienen lugar todas las interacciones entre la máquina y el usuario. El objetivo principal de cualquier UI es facilitar el control de un usuario sobre una máquina. GUI: Del inglés Graphical User Interface (Interfaz Gráfica de Usuario). Es una UI que permite al usuario interactuar con la máquina utilizando iconos gráficos e indicadores visuales como botones, campos de texto, etc. PDF: El formato PDF (Portable Document Format, en español Formato de Documento Portátil) es un formato de fichero desarrollado para la presentación de documentos de manera independiente de cualquier software y hadrware. TEX: TEX es una composición tipográfica diseñada para permitir la producción de documentos formateados de alta calidad con el mı́nimo esfuerzo. TEX fue diseñada de forma que dada una misma entrada, se produzca el mismo documento formateado en cualquier máquina y en cualquier momento. Lenguaje de marcado: Un lenguaje de marcado es un sistema para codificar un documento que, junto con el texto, incorpora etiquetas o marcas que contienen información adicional acerca de la estructura del texto o su presentación. LATEX: LATEX (acrónimo de Lamport TEX ) es un sistema de preparación de documentos en el que el usuario utiliza las convenciones de etiquetado de los lenguajes de marcado para definir la estructura general del documento. R: R es un lenguaje de programación utilizado para computación estadı́stica y generación de gráficos. Array: Un array es una estructura de datos que consiste en una colección de elementos (valores o variables) que se identifican dentro de dicha estructura mediante, como poco, un ı́ndice numérico. JSON: Del inglés JavaScript Object Notation (Notación de Objeto de JavaScript). Es un formato de ficheros abierto que utiliza texto legible para transmitir objetos de datos compuestos por pares atributo – valor y datos tipo array. iii.
(9) Rnw: El formato Rnw es un formato de fichero que soporta documentos que contienen una mezcla entre contenido genérico y código R que permite la ejecución del código R y la inyección del resultado en el documento final. Microsoft Windows: Microsoft Windows es una familia de sistemas operativos basados en GUIs desarrollada por Microsoft Corporation.. iv.
(10) Capı́tulo 1 INTRODUCCIÓN Y OBJETIVOS 1.1. Introducción. Se define como análisis de datos la tarea de inspeccionar, transformar y modelar información para, posteriormente, encontrar relaciones entre los datos analizados y/o interpretarlos y darles sentido. De unos años a esta parte, esta técnica se ha vuelto especialmente interesante a la hora de la toma de decisiones de todo tipo: desde adaptar el servicio al cliente dado un informe sobre el grado de satisfacción del consumidor, hasta aplicar una u otra estrategia comercial o polı́tica en función de datos obtenidos de un determinado público. Ası́, el trabajo de la persona encargada de analizar los distintos conjuntos de datos (es decir, el analista), consistirá en encontrar las relaciones entre los datos en bruto y proporcionar una interpretación de los mismos a partir de la cual se pueda sacar alguna conclusión relevante respecto a la toma de decisiones. No obstante y dada la efectividad que ha demostrado esta técnica, actualmente el volumen de los datos que se desea analizar es, simplemente, masivo; de esta forma, la tarea de formatear y visualizar dichos datos para su análisis resulta tediosa. Esto implica que el analista podrı́a dedicar más tiempo a la visualización y el formateo de los datos que al propio análisis de los mismos. En el Trabajo de fin de Grado “Informes para estudios estadı́sticos extensos” realizado para la Universidad Politécnica de Madrid[1] se aborda este problema con el desarrollo de una herramienta llamada Tardis que permite generar informes estadı́sticos en formato PDF (compilados de LATEX) a partir de un conjunto de datos y siguiendo las indicaciones de una serie de archivos de configuración (que se explican más detalladamente en la subsección 3.4.6). Esta herramienta es configurable por el usuario y ejecutable desde la consola de comandos o terminal, efectivamente ahorrando tiempo de redacción del informe al analista.. 1.
(11) Con este proyecto se pretende ir un paso más allá: utilizando como parte funcional la herramienta Tardis, se ha desarrollado una GUI que facilita aún más la tarea de configurar la salida que produce (es decir, el documento PDF). La decisión de expandir la herramienta Tardis se ha tomado basándose en varios factores: principalmente, en el hecho de que un analista no tiene por qué tener los conocimientos de informática necesarios para editar los ficheros que componen Tardis, siendo ası́ la curva de aprendizaje de la herramienta algo incómoda para analistas sin conocimientos de LATEX y R. Además, teniendo en cuenta que el objetivo principal de Tardis es el de ahorrar tiempo al analista, al haberle añadido una GUI se intenta acortar todavı́a más el tiempo de configuración y redacción del informe; ası́ pues, se ha decidido llamar a la aplicación resultante Tardis2 . Gracias a esta aplicación, el analista solo deberá preocuparse de introducir los datos de los que desea obtener un informe estadı́stico con gráficas y de seleccionar las opciones de configuración que más le interesen desde la GUI mediante el uso de botones, selectores y cajas de texto. O lo que es lo mismo, se ofrece la posibilidad al analista de no tener que editar manualmente ni los ficheros JSON de configuración, ni el fichero Rnw que da funcionalidad a Tardis. Además, se ponen a disposición del usuario funcionalidades adicionales tales como la capacidad de guardar y cargar la sesión de trabajo, consultar una guı́a de ayuda y cambiar el idioma de los textos de la aplicación. En general, la intención durante el desarrollo de este proyecto ha sido la de presentar al analista un entorno gráfico ejecutable en sistemas Microsoft Windows que sea sencillo y agradable con el que pueda generar sus informes prácticamente sin esfuerzo.. 1.2. Objetivos. Durante el desarrollo de este proyecto, se han tenido en cuenta una serie de objetivos principales que han servido para que el trabajo se haya podido realizar de manera constante y sin desviaciones en las tareas ni pérdidas de tiempo. Se pueden desglosar los siguientes objetivos fundamentales a la hora de alcanzar la meta que se ha propuesto: 1. Desarrollo de una GUI accesible para el usuario general: Este ha sido el objetivo principal: desarrollar una aplicación de escritorio con una GUI que resulte intuitiva y manejable para cualquier usuario, sin importar el nivel de conocimientos de informática que posea. 2. Dotar a la GUI con opciones de análisis, datos y selección de documentos: Se ha dotado a la GUI de opciones de personalización del análisis de los datos estadı́sticos, pudiendo ası́ el usuario elegir el tipo de análisis, el modelo de gráfica que se desea obtener y el conjunto de datos sobre el que se quiere trabajar. Se ha hecho uso de paneles de texto, formularios, botones, etc. para alcanzar este objetivo. 2.
(12) 3. Implementación de la aplicación local: Se ha desarrollado una versión de la aplicación que es ejecutable de manera local en cualquier máquina con sistema operativo Windows (es decir, una aplicación de escritorio con extensión .exe). 4. Análisis de los requisitos para la ejecución de la aplicación local: Se han analizado e identificado cuáles son los requisitos (dependencias) para que la aplicación local se ejecute correctamente: por un lado, es necesario que la máquina en la que se quiera ejecutar la aplicación tenga instalada Java 8 o superior, dado que la librerı́a utilizada para el diseño de la GUI (JavaFX) viene incluı́da a partir de la versión 8 de Java. Además, la máquina deberá tener instalado un compilador de R; sin este compilador, no se podrá ejecutar la herramienta Tardis, por lo que no se generará ninguna salida o informe estadı́stico. 5. Desarrollo de un manual de usuario: Finalmente, se ha redactado un manual para el usuario por si el usuario de la aplicación quisiera una guı́a práctica con detalles exhaustivos sobre cómo utilizar la aplicación.. 3.
(13) Capı́tulo 2 TRABAJOS PREVIOS En lo referente a introducción y procesamiento de datos para generación de informes estadı́sticos, se puede decir que se trata de una tarea proporcionalmente laboriosa al volumen de datos que se desea introducir y a la cantidad de gráficas estadı́sticas que se desea generar de cada conjunto de datos. Por ello, desde que la informática se ha vuelto accesible a un público más amplio, se han desarrollado múltiples herramientas para automatizar el proceso de generación mediante interfaces gráficas para el usuario. Esto se debe mayormente al hecho de que el analista no siempre tendrá conocimientos suficientes de informática como para, por ejemplo, generar sus informes en LATEX o introducir los datos utilizando lenguajes como Matlab. El trabajo del analista no es otro que el de dar sentido e interpretar los datos; ası́, no debe perder el tiempo en la introducción de los mismos. Es por esto por lo que el desarrollo de una interfaz gráfica intuitiva es fundamental. Se listan a continuación algunos de los entornos gráficos existentes y actualmente disponibles que han sido desarrollados para resolver este problema: • Dashzen: Dashzen es una plataforma basada en la nube diseñada para crear gráficos estadı́sticos a partir de datos en bruto. Esta herramienta se puede utilizar para generar múltiples visualizaciones de los datos de entrada: diagramas de barras, gráficos circulares, etc[2] .. 4.
(14) Figura 2.1: Ejemplo de salida de Dashzen (https://www.dashzen.com/, obtenida en noviembre de 2018). • Power BI: Power BI es un servicio de análisis de negocio desarrollado por Microsoft. Esta herramienta genera visualizaciones interactivas con las cuales el usuario puede crear informes sin necesidad de tener conocimientos informáticos avanzados[3] que, tal y como se ha explicado anteriormente, favorece enormemente al analista que se encargue de sacar conclusiones sobre los datos.. Figura 2.2: Captura de pantalla de Power BI (https://www.blastam.com/power-biconsulting, obtenida en noviembre de 2018). • SAP BusinessObjects Lumira: SAP BusinessObjects Lumira (también conocido simplemente como Lumira) es un software de negocio utilizado para manipular y visualizar datos[4] . La primera edición de este software solo podı́a utilizar la plataforma HANA de SAP como fuente de datos, lo que suponı́a un 5.
(15) grado añadido de dificultad para el analista. En cambio, la segunda edición se expandió para que se pudieran incluir como fuentes de datos ficheros CSV y ficheros Excel[5] .. Figura 2.3: Captura de pantalla de SAP BusinessObjects Lumira (https://www.sap.com/products/lumira.html, obtenida en noviembre de 2018). • Qlik Sense: Qlik Sense es una aplicación disponible para escritorio y también en lı́nea desarrollada por Qlik que permite combinar distintas fuentes de datos en una única vista interactiva. Este software cuenta además con un algoritmo asociativo que es capaz de indexar varias posibles relaciones entre los datos de entrada, haciendo todavı́a más fácil el trabajo del analista[6] .. Figura 2.4: Captura de pantalla de Qlik Sense (en escritorio) (https://www.flickr.com/photos/78532313@N06/15821662643, obtenida en noviembre de 2018). 6.
(16) • SpagoBI: SpagoBI es una plataforma orientada a la inteligencia de negocios que está desarrollada como código abierto[7] . SpagoBI ofrece una serie de soluciones para la presentación de informes, data mining [8] , análisis multidimensional, etc. Además, cuenta con herramientas para la extracción, transformación y carga de datos[9] que permitirá al analista no tener que preocuparse de el tratamiento de los datos, ahorrándole tiempo.. Figura 2.5: SpagoBI web (https://www.clipzui.com/video/h4c4f4e4p325r42474x4c4.html, obtenida en noviembre de 2018).. 7.
(17) Capı́tulo 3 DESARROLLO 3.1. Lenguajes y herramientas utilizados. En esta sección se da información sobre los lenguajes de programación y las herramientas que se han utilizado para el desarrollo del trabajo.. 3.1.1. draw.io. Figura 3.1: Logo de draw.io. draw.io es una herramienta de código abierto utilizada para crear diagramas[10] . Desarrollada inicialmente como una aplicación web, hoy en dı́a existe además una versión de escritorio, que es el software que se ha utilizado para generar los diagramas del diseño inicial de la interfaz gráfica. Se ha decidido utilizar esta herramienta de construcción de diagramas porque ofrece una interfaz sencilla de manejar que permite una alta precisión a la hora de colocar los elementos del diagrama, fundamental a la hora de realizar esquemas de interfaces gráficas, sitios web, etc.. 3.1.2. Eclipse IDE for Java Developers. Figura 3.2: Logo de Eclipse.. 8.
(18) Eclipse IDE es un entorno de desarrollo integrado (integrated development environment o IDE) desarrollado por The Eclipse Foundation [11] que ofrece una serie de herramientas para desarrollar software en múltiples lenguajes de programación, principalmente en Java. Es el entorno que se ha decidido utilizar para desarrollar el trabajo por varias razones: por un lado, ya se tenı́a cierta familiaridad con este IDE; por otra parte, las herramientas que tiene integradas (depurador, consola integrada, repositorio de add-ons, etc.) resultan especialmente útiles a la hora de desarrollar proyectos de mediano calibre como este.. 3.1.3. Java. Figura 3.3: Logo de Java. Java es un lenguaje de programación concurrente, basado en clases y orientado a objetos especı́ficamente diseñado para que tenga cuantas menos dependencias posibles[12] . Java sigue la filosofı́a de lenguajes de programación WORA (“write once, run anywhere”, o “escribir una vez, ejecutar en cualquier parte”). Es precisamente por este estilo de ejecución por lo que se ha elegido Java como lenguaje de programación principal para el desarrollo de la interfaz gráfica: la idea es que se pueda ejecutar en cualquier entorno Windows sin necesidad de recompilación.. 3.1.4. JavaFX. Figura 3.4: Logo de JavaFX. JavaFX es una librerı́a de Java desarrollada inicialmente por Sun Microsystems para el desarrollo de aplicaciones de escritorio ası́ como aplicaciones de Internet enriquecidas (rich internet applications ó RIAs). Es la sucesora de Swing, otra librerı́a 9.
(19) para el desarrollo de interfaces gráficas más antigua. JavaFX se basa en el uso de cajas horizontales y verticales para la alineación de los elementos de la interfaz y hace uso de escenas, que son la parte de la interfaz que puede ver en un momento dado el usuario[13] . Se ha utilizado JavaFX para el desarrollo de la parte visual de la interfaz gráfica porque se ha considerado que esta librerı́a es lo suficientemente sencilla de manejar como para que corregir errores o añadir modificaciones al trabajo no suponga un esfuerzo, lo que será importante si se desean añadir funcionalidades adicionales en un futuro. Por otra parte, ya se tenı́a experiencia previa desarrollando interfaces gráficas con esta librerı́a. Además, la cantidad de documentación disponible en internet es abundante, por lo que, definitivamente, se ha escogido este software.. 3.1.5. JSON. Figura 3.5: Logo de JSON. JSON es un formato de texto ligero para el intercambio de datos[14] . El formato JSON permite describir estructuras de datos con una sintaxis sencilla. Además de objetos simples, permite además definir estructuras de datos clásicas como arrays, además de dar soporte a anidación de datos. En este proyecto, JSON se ha utilizado en dos partes de la aplicación. Por un lado, la parte funcional de la aplicación utiliza JSON para gestionar los datos que se le pasarán al generador del informe. Por otra parte, se ha decidido utilizar este formato para el control de sesión: es decir, si el usuario decide guardar su sesión actual o cargar una sesión preexistente, la sesión que cargue/guarde será un fichero JSON de cuya estructura se habla en la sección 3.4.5.. 10.
(20) 3.1.6. LATEX. Figura 3.6: Logo de LATEX. LATEX es un sistema de preparación de documentos para tipificación de alta calidad[15] . Se utiliza mayoritariamente para producir documentos y artı́culos técnicos, pero se puede utilizar para generar cualquier tipo de publicación. LATEX es un procesador de texto que no se basa en WYSIWYG (“What You See Is What You Get” ó “Lo que ves es lo que obtienes”) como otros procesadores de texto más populares entre el público general (por ejemplo, Microsoft Word o LibreOffice Writer), si no que, mediante una baterı́a de algoritmos predefinidos, utiliza un lenguaje de marcado para generar texto legible y visualmente atractivo. En este proyecto, LATEX ha cumplido dos funciones principales: por una parte, es la herramienta que se ha utilizado para la generación de los documentos de planificación inicial, memoria de seguimiento, manual del usuario y esta memoria final. Por otro lado, LATEX es la herramienta que utiliza la parte funcional de la aplicación Tardis2 para generar el informe estadı́stico deseado.. 3.1.7. Overleaf. Figura 3.7: Logo de Overleaf. Overleaf es un sistema de escritura y publicación colaborativa en lı́nea[16] . Se trata de una herramienta accesible desde cualquier navegador para crear, editar y compartir proyectos LATEX. Una vez creado un documento de LATEXen esta plataforma, es posible descargar el documento PDF compilado sin necesidad de instalar nada en la máquina del usuario.. 11.
(21) En este proyecto, esta herramienta se ha utilizado para la realización del plan de trabajo. Se la elegido porque no es necesario tener el fichero fuente descargado en local y se han utilizado varios equipos durante el desarrollo del plan de trabajo.. 3.1.8. R. Figura 3.8: Logo de R. R es un sistema diseñado para la computación estadı́stica y de gráficos. Consiste de un lenguaje propio y de un entorno de desarrollo basado en ejecución con gráficos, un depurador, acceso a ciertas funciones del sistema y la capacidad de ejecutar programas guardados en archivos script. El núcleo de R es un lenguaje de programación interpretado que permite ramificación y bucles ası́ como programación modular utilizando funciones[17] . En este proyecto, R es el lenguaje al que se le pasan tanto los datos a analizar como las opciones de configuración para que genere el informe deseado.. 3.2. Primera parte: Planificación. La primera parte del trabajo, siguiendo las indicaciones de la realización del mismo propuestas por la asignatura, ha sido la confección de un plan de trabajo. Este plan de trabajo ha servido a modo de guı́a y calendario para realizar el resto de tareas. No obstante, el comienzo de su desarrollo no tuvo lugar hasta la tercera semana de septiembre. Esto se debió a una serie de complicaciones a la hora de la matriculación en el Trabajo de Fin de Grado que impidieron la asignación a tiempo del trabajo. Por otra parte, se ha sabido compensar adecuadamente la pérdida de las dos primeras semanas de septiembre. Esta primera parte de planificación se ha llevado a cabo a lo largo de dos semanas mediante sucesivas reuniones con el profesor. Técnicamente, para la generación de un documento PDF que cumpliera los requisitos que exigı́a la guı́a de la asignatura, se ha utilizado la herramienta Overleaf, explicada en la subsección 3.1.7.. 12.
(22) 3.2.1. Comparativa de diagramas de Gantt: primera parte. El diagrama de Gantt confeccionado en la Planificación de Trabajo ha servido como guı́a para el avance del proyecto y ha resultado de gran utilidad. Para la primera parte, que ha comprendido todo el trabajo realizado hasta mediados de noviembre de 2018, se han producido un par de modificaciones al tiempo dedicado a cada una de las tareas propuestas inicialmente. En la figura 3.9 se muestra la parte del diagrama de Gantt inicial correspondiente a estos primeros meses de trabajo y en la figura 3.10 se representa qué tiempo se ha dedicado a cada una de las tareas en realidad:. 2018 Sep. Oct. Nov. 1 2 3 4 1 2 3 4 1 2 3 4. Ciclo 1: Planificación Plan de trabajo Diseño inicial Ciclo 2: Desarrollo Desarrollo de un prototipo Enlace de la GUI con Tardis Pruebas funcionales Memoria intermedia Figura 3.9: Diagrama de Gantt del trabajo según la planificación inicial de la primera parte.. 13.
(23) 2018 Sep. Oct. Nov. 1 2 3 4 1 2 3 4 1 2 3 4. Ciclo 1: Planificación Plan de trabajo Diseño inicial Ciclo 2: Desarrollo Memoria intermedia Pruebas funcionales Desarrollo de un prototipo Enlce de la GUI con Tardis Figura 3.10: Diagrama de Gantt del trabajo realizado en realidad de la primera parte. Como se puede apreciar, en el primer ciclo (asociado a la planificación del trabajo) se invirtió exactamente el tiempo que se esperaba, de modo que el diagrama de Gantt del trabajo realizado en realidad es igual al diagrama de Gantt original hasta la primera semana de octubre inclusive1 . Los cambios en los tiempos se introdujeron a partir del comienzo de la segunda semana de octubre, es decir, a partir del segundo ciclo (asociado al desarrollo del trabajo). Se consideró en ese momento que la implementación de un prototipo de la GUI se podrı́a llevar a cabo en tan solo una semana, por lo que la semana 2 de octubre se dedicó al inicio de la redacción de la memoria de seguimiento y, dado que se ha ido documentando según han ido estando terminadas las tareas, se ha continuado con esta redacción hasta la fecha de entrega de esa memoria “intermedia” (18 de noviembre de 2018, finalización de la segunda semana de noviembre). Por otra parte, las pruebas funcionales comenzaron en el momento en el que se empezó a desarrollar el prototipo de la interfaz puesto que se llegó a la conclusión de que realizar una única tanda de pruebas al final del segundo ciclo, sin haber probado 1. La primera fila del diagrama corresponde al año, la segunda al mes y la tercera a la semana del mes.. 14.
(24) anteriormente todo lo que hubiera hecho hasta ese momento, podrı́a resultar una pérdida de tiempo considerable: en estos tipos de desarrollo, es de vital importancia asegurarse de que la aplicación va funcionando poco a poco, sin esperar a que avance su implementación para hacer pruebas. En efecto, las pruebas funcionales se han ido realizando paralelamente a la programación de la aplicación y hasta la semana 1 de noviembre inclusive. Finalmente, cabe destacar que tanto la fecha de finalización del desarrollo del prototipo como la fecha de inicio y tiempo empleado en el enlace de la interfaz gráfica con la herramienta Tardis, se ha ajustado con precisión a la planificación original: el desarrollo del prototipo terminó a comienzos de la semana 3 de octubre seguido de dos semanas de enlace de la interfaz con la herramienta.. 3.2.2. Comparativa de diagramas de Gantt: segunda parte. Continuando con la segunda parte del desarrollo del trabajo (es decir, desde la segunda semana de noviembre hasta la tercera semana de enero inclusive), se expone en la figura 3.11 el diagrama de Gantt del trabajo planificado inicialmente, mientras que en la figura 3.12 refleja el trabajo realizado en realidad: 2018 Nov. 2019 Dic. Ene. 1 2 3 4 1 2 3 4 1 2 3 4. Ciclo 3: Finalización Desarrollo de versión beta Obtención de feedback Ajustes para versión final Documentación y pruebas Memoria final Figura 3.11: Diagrama de Gantt del trabajo según la planificación inicial de la segunda parte.. 15.
(25) 2018 Nov. 2019 Dic. Ene. 1 2 3 4 1 2 3 4 1 2 3 4. Ciclo 3: Finalización Desarrollo de versión beta Obtención de feedback Ajustes para versión final Documentación y pruebas Memoria final Figura 3.12: Diagrama de Gantt del trabajo realizado en realidad de la segunda parte. Relativo a esta segunda parte correspondiente al tercer ciclo (finalización del proyecto), se aprecian tres cambios menores: en primer lugar, el desarrollo de la versión beta de la aplicación llevó tres semanas en lugar de dos. Este ligero retraso se ha debido a que, para la versión beta, se quisieron implementar la mayorı́a de las caracterı́sticas de la versión final; los elementos que se introdujeron en la interfaz fueron el menú con todas sus opciones, el control de sesión y un correcto control sobre la navegación (es decir, evitar que se pudiera avanzar de escena si no se cumplı́an los requisitos). Seguidas de esas tres semanas de desarrollo, siguió una semana de obtención y análisis del feedback. El trabajo realizado en esa semana consistió en dar a conocer el proyecto a voluntarios para que, el que ası́ lo quisiera, probase la aplicación aún en estado beta. De todos los voluntarios, dos probaron la aplicación. Si bien ambos voluntarios expresaron su deseo de permanecer en el anonimato, se valoraron sus opiniones llegando a una conclusión: de acuerdo a la experiencia de voluntarios, la interfaz de la aplicación era lo suficientemente sencilla como para que un usuario sin experiencia la pudiera utilizar, pero consideraron que era necesaria la redacción de un manual para el usuario a fin de que el usuario medio pudiera hacer uso completo de la aplicación (edición de ficheros, formato de los ficheros de entrada, etc.). Ası́, se pasó a la siguiente tarea, la cual abarca desde las semanas dos y tres de 16.
(26) diciembre. En este caso, la diferencia entre lo planificado y lo realizado no es un retraso, si no un menor consumo de tiempo del esperado, ya que se esperaba que esta tarea se realizase en tres semanas, pero llevó únicamente dos. Los ajustes que se realizaron en estas dos semanas fueron las distintas funcionalidades del menú de opciones de la interfaz y la capacidad de abrir los distintos ficheros seleccionados por el usuario desde la interfaz con el editor de texto por defecto del mismo usuario. La última diferencia entre el diagrama de Gantt planificado y el real, es el hecho de que se empezó dos semanas antes de lo que se esperaba a redactar la memoria final. Se decidió ası́ por utilidad, dado que en caso de haber tenido que corregir errores, se contarı́a con más tiempo.. 3.3. Segunda parte: Diseño inicial de la GUI. La segunda parte del trabajo ha consistido en el diseño inicial de la interfaz gráfica. Este diseño inicial, mientras ha servido de guı́a fundamental para el desarrollo de la interfaz, ha sufrido algunas modificaciones menores; el resultado final queda reflejado en la subsección 3.4.3. Esta parte se ha llevado a cabo con la herramienta draw.io y ha servido de guı́a a la hora del desarrollo de la interfaz, especialmente a la hora de visualizar los tamaños de los elementos de la interfaz y sus proporciones. A continuación se muestran una serie de figuras con la pertinente explicación de a qué escena de la aplicación corresponden además de una noción de la navegación.. 17.
(27) 3.3.1. Esquema básico de la aplicación 50. 35. Nombre de la aplicación. 30. Archivo. Informe. Preferencias. × Ayuda. 25 405. 720 25. (1) Padding. (4) Barra de menú. (2) Botón "Cerrar" (3) Barra de la aplicación. Figura 3.13: Esquema básico de la interfaz. En la figura 3.13 se muestra el esquema básico de la aplicación. En esta ventana no hay elementos, de modo que ha servido de “lienzo” para las subsecuentes escenas o ventanas. Aunque no aparezca explı́citamente en el esquema, las medidas están tomadas en pı́xeles, por lo que la aplicación se visualizará de manera óptima en escritorios con una resolución de 1080p. Ahora bien, si en un futuro se decide que la aplicación se va a utilizar en escritorios con otra resolución, bastará con cambiar las unidades de pı́xeles a, por ejemplo, milı́metros u otra unidad que se considere adecuada; lo importante es la proporción entre unos elementos y otros. Nótese que las dimensiones (largo y ancho) de la interfaz son de 720 pı́xeles de ancho por 405 pı́xeles de alto, resultando en una proporción de exactamente 16:9. Esto se ha decidido teniendo en mente que la inmensa mayorı́a de los escritorios de usuario mantienen esa misma proporción. 18.
(28) En este esquema se pueden apreciar algunos de los elementos que serán comunes a las demás ventanas: 1. Padding: Se trata de un margen interior de 25 pı́xeles. Se implementa para que los distintos elementos (botones, campos de texto, etc) no se encuentren pegados a los lı́mites de la interfaz; se trata de una mera cuestión estética. 2. Botón “Cerrar”: Es el botón que aparecerá en la parte superior derecha de la aplicación en todo momento. Al pulsarse, se cierra la aplicación. Se ha decidido que el botón de cerrar esté en la parte superior derecha porque en los entornos Windows, las aplicaciones (por norma general) tienen ese mismo botón en la misma posición, y dado que se desea que la aplicación se ejecute en entornos Windows, eso hará la funcionalidad del botón aún más intuitiva para el usuario. 3. Barra de la aplicación: Es la barra horizontal que aparecerá en la parte superior de la aplicación. Mostrará el nombre de la aplicación y permitirá desplazar la aplicación por el escritorio al mantener pulsado el ratón sobre ella y arrastrarla. 4. Barra de menú: Es una barra horizontal que se mostrará de manera fija debajo de la barra de navegación. Según el diseño inicial, la barra de menú mostrarı́a las siguientes opciones (el resultado final se puede consultar en la subsección 3.4.4): • Archivo: Al pulsar esta opción, aparecerá un desplegable con entradas referentes al estado de la aplicación como por ejemplo “Nueva sesión”, “Cargar sesión”, “Guardar sesión” y “Salir”. • Informe: Al pulsar esta opción, el desplegable tendrá las entradas “Configurar”, para configurar los ficheros JSON del informe o algún otro aspecto del mismo, “Seleccionar plantilla”, “Modificar plantilla” y “Generar”, que generará el informe. • Preferencias: En un principio, se pretende que las entradas de esta opción sean “Idioma”, para cambiar el idioma de la interfaz (es decir, los textos) de inglés a español y “Vista de paneles”, que permitirá al usuario decidir si quiere ver la aplicación como una sucesión de escenas o ventanas, o si desea verla con un scroll desde el principio hasta el final. • Ayuda: Al pulsar sobre esta opción, aparecerá un desplegable con varias opciones referentes al tipo de ayuda que requiera el usuario. Estas entradas serán “De la interfaz”, en la que se mostrará una pequeña descripción de la navegación y funcionalidad de los elementos de la interfaz, “Del generador”, que mostrará al usuario las indicaciones básicas de cómo trabajar con el generador y, finalmente, “Créditos”, que mostrará el nombre del trabajo, el nombre del autor de la interfaz y el nombre del profesor coordinador del trabajo.. 19.
(29) 3.3.2. Ventana de selección de ficheros 50. 35. Nombre de la aplicación. 30. Archivo. Informe. Preferencias. × Ayuda. 25 30 30. Ficheros de Configuración (json). Fichero R (stardis). Fichero Rnw (plantilla Latex+R). 30. Builder. ¬ stardis.R. ¬ main.Rnw. 30. ¬ builder.json. 30. Configuration. 30. ¬ configuration.json. 30. Data. 30. ¬ data.json. 10. Selección de ficheros. 10 405. 10 10 Continuar. 720 25. 210. 20. 210. 20. 210 120. (1) Padding. (4) Barra de menú. (2) Botón "Cerrar". (5) Label / Etiqueta (texto fijo). (3) Barra de la aplicación. (6) Botón. Figura 3.14: Esquema de la ventana de selección de ficheros para la aplicación. En esta ventana se le muestra al usuario una serie de desplegables con opciones correspondientes a los ficheros que puede elegir para el tratamiento de sus datos. Se dividen en tres columnas según la función que cumple cada fichero: • Ficheros de Configuración (json): En esta primera columna, situada a la izquierda, el usuario puede elegir qué ficheros JSON va a utilizar para que luego trabaje con ellos el programa Tardis. En un principio, se diseñó de manera que el usuario tuviera que elegir tres ficheros; no obstante, tras el análisis de los ficheros con los que trabaja la aplicación, solo debe seleccionar dos, de manera que la entrada “Builder” no existe en la versión final. Respecto a los otros dos ficheros, son los que siguien: el fichero de configuración, que sirve para indicar propiedades del fichero de salida final (siendo el fichero de datos un fichero CSV) y el autor, y el fichero de datos, que es donde se indica el tipo de. 20.
(30) gráfico asociado a cada variable y los estilos (colores, anchuras de las barras, etc.). • Fichero R: Se le da al usuario la opción de elegir una versión modificada del fichero R stardis original, que es a fin de cuentas el programa que se encarga de compilar y generar la salida. • Fichero Rnw: Además, se da también al usuario la opción de elegir una plantilla Rnw diferente a la que se ofrece por defecto. Nótese que no se le deja al usuario elegir la ruta exacta de los ficheros. En cambio, se le permite elegir de una lista. Estas listas o combos se rellenarán acorde a lo expuesto en la subsección 3.4.2. Finalmente, queda por aclarar que una vez el usuario haya elegido los ficheros que desee y a continuación pulse el botón de continuar, se ocultará esta ventana y se mostrará la ventana de personalización de la salida.. 21.
(31) 3.3.3. Ventana de personalización de la salida 50. 35. Nombre de la aplicación. 30. Archivo. Informe. Preferencias. × Ayuda. 25 30 30. Tipo de informe. 10. Personalización de la salida Variables target 1:N Summary. 30. Informe (long). Histogram. 30. Beamer (presentación). Boxplot. 405. 30. Artículo (short). Scatterplot Multiple Scatterplot ... 30. Atrás. Continuar. 720 25. 210. 20. 210. 120. 120. (1) Padding. (4) Barra de menú. (2) Botón "Cerrar". (5) Label / Etiqueta (texto fijo). (3) Barra de la aplicación. (6) Botón. (7) Checkbox o Radio button. Figura 3.15: Esquema inicial de la ventana de personalización de la salida En el diseño inicial de la figura 3.15, se puede apreciar que, en un primer momento, se pretendı́a enseñar al usuario dos columnas (una a la izquierda y una en el centro) con checkboxes (cajas de decisión) relativas a las opciones de personalización del informe. En la versión final de la interfaz, se ha añadido además una última columna a la derecha en la que se debe indicar el nombre del autor del documento y el tı́tulo del mismo (tal y como se muestra en la figura 3.22). De las dos columnas que se presentan en el esquema de la figura 3.15, cabe aclarar lo siguiente: • Columna de tipo de informe: Inicialmente, se pretendı́a dejar tres opciones para el usuario, de manera que él podrı́a elegir entre un informe largo (opción 22.
(32) “Informe (long)”), un informe corto (opción “Artı́culo (short)”) o una presentación haciendo uso del paquete beamer de LATEX; no obstante, la última opción no se acabó incluyendo en la verisón final. • Columna de variables 1:N: Las opciones que se presentan en esta columna permitirán al usuario decidir qué tipo de gráfico (histograma, boxplot, etc.) se generará para las variables 1:N del fichero de datos que haya elegido previamente. Finalmente, en la figura 3.15 se indica que los botones de navegación “Atrás” y “Continuar” irán en la parte inferior de la ventana, independientemente de la longitud vertical de la misma. Al pulsar el botón “Atrás”, se deberá esconder esta ventana y se enseñará la venta de selección de ficheros, y al pulsar el botón “Continuar”se guardarán las opciones seleccionadas por el usuario y se avanzará a la pantalla de finalización.. 23.
(33) 3.3.4. Ventana de finalización 50. 35. Nombre de la aplicación. 30. Archivo. Informe. Preferencias. × Ayuda. 25 30. Selección de ruta de fichero salida. 20 30. Fichero .tex. Mensajes de traza > > > >. 30 30. Fichero .pdf. 30. |. 80 30. Atrás. Finalizar/Guardar. 720 25. 120. 120. 430 230. 210. (1) Padding. (4) Barra de menú. (2) Botón "Cerrar". (5) Label / Etiqueta (texto fijo). (3) Barra de la aplicación. (6) Botón. 230. >. (8) "Consola" de salida. Figura 3.16: Esquema de la ventana de finalización. En la figura 3.16 se muestra cómo se ha planteado la ventana de finalización. Los elementos principales a destacar de esta última ventana son los selectores de ficheros de salida (uno para el fichero de salida TEX y el otro para el fichero de salida PDF) y una consola que sacará por pantalla una serie de mensajes de traza que darán información al usuario referente al estado de ejecución y/o finalización del programa. En cuanto a los selectores de fichero para los ficheros de salida, se plantean como dos campos de texto en los que el usuario podrá especificar la ruta absoluta en la que desee que se generen los ficheros de salida mencionados anteriormente. Adicionalmente, se podrán incluir dos botones, uno por campo de texto, que abran el explorador de archivos de Windows y que permitan al usuario decidir la ruta de los ficheros de salida desde el mismo explorador.. 24. 200. 10. 405. |. mensaje de traza 1 mensaje de traza 2 ... mensaje de finalización.
(34) La consola, por otra parte, consistirá en un panel de texto no editable por el usuario en el que la interfaz irá imprimiendo los mensajes de traza. Si bien no se trata de una consola como se concibe en entornos Linux, se le dará un estilo que el usuario pueda identificar con una consola tradicional a fin de hacer su funcionalidad más intuitiva. Por último, quedan por explicar los dos botones de navegación presententes en esta ventana. El botón “Atrás”, al pulsarse, ocultará esta ventana y mostrará la ventana de personalización de la salida, mientras que el botón “Finalizar/Guardar” tendrá la funcionalidad de recoger todo lo que el usuario haya introducido desde el inicio del programa, modificar los ficheros con los que trabajará el programa Tardis y invocarlo para producir la salida que desea el usuario.. 3.4 3.4.1. Tercera parte: Desarrollo de la aplicación Ficheros de la aplicación. Una vez instalada la aplicación en el equipo, el contenido de la carpeta principal será el que se muestra a continuación:. Figura 3.17: Ficheros de Tardis2 El ejecutable es el archivo llamado Tardis2.exe, sobre el que se deberá hacer doble click o bien doble click sobre un acceso directo al mismo para arrancar la aplicación. El fichero manual.pdf se trata del manual del usuario. Dentro de la carpeta Configuration se encuentran dos ficheros de configuración proporcionados por defecto. Estos son el fichero data.json y configuration.json. 25.
(35) Se tratan de dos archivos en formato JSON que modificará y leerá la parte funcional de la aplicación para la generación del informe. Dichos ficheros los proporciona la herramienta Tardis [1] . Dentro de la carpeta Data es donde se deben meter los ficheros de datos de los que se deseen obtener el informe estadı́stico. Sobre el formato que deben tener estos ficheros de datos se habla en la subsección 3.4.6. En la carpeta RnwFigs aparecerán, una vez ejecutado el generador, las figuras generadas en formato PDF. Dentro de la carpeta Source se encuentran las siguientes carpetas y ficheros:. Figura 3.18: Archivos de la carpeta Source En la carpeta Analysis se proporcionan dos ficheros JSON por defecto: uno es el fichero builder.json, que lo genera la propia aplicación al finalizar la ejecución y el otro fichero es main.Rnw, fichero por defecto parte de la parte funcional de la aplicación. Dentro de la carpeta Childs se encuentran los modelos de las figuras que se pueden seleccionar para que aparezcan en el informe. Por el momento, dichas figuras están asociadas a los ficheros barchart.Rnw, boxplots.Rnw, datasummary.Rnw, histograms.Rnw y rawdata.Rnw. Finalmente, en la carpeta Source se encuentra además el fichero stardis.R, fundamental para la parte funcional de la aplicación.. 26.
(36) 3.4.2. Flujo de trabajo de la interfaz. Se explica en esta subsección el flujo básico de trabajo de la interfaz: esto es, los pasos mı́nimos a seguir para obtener una salida. El diagrama de flujo es el que se muestra en la figura 3.19:. 27.
(37) Arrannque de la aplicación. Primera escena. Cuarta escena. Selección de ficheros de configuración, fichero R y fichero Rnw. Se pulsa "Continuar". Se pulsa "Atrás". Selección de la ruta de los ficheros de salida y finalización. Se pulsa "Finalizar". No. ¿Se han rellenado todos los combos?. No. ¿Se han elegido las rutas de los ficheros de salida?. Sí Sí Segunda escena Selección de ficheros de datos e introducción de la columna con la primera variable numérica. Se pulsa "Atrás". No. ¿Se puede generar una salida con los datos introducidos? Sí. Se pulsa "Continuar". Generación de los ficheros de salida. ¿Se han rellenado los combos y el campo de texto? Sí Tercera escena Opciones de personalización de la salida. No. Se pulsa "Atrás". Se pulsa "Continuar". ¿Se ha seleccionado el tipo de informe y los campos del autor y el título?. Sí. Figura 3.19: Diagrama de flujo de la aplicación.. 28. No.
(38) Como se puede apreciar, la navegación permite libertad total a la hora de ir hacia atrás y modificar algún aspecto de la configuración. En cambio, para ir hacia adelante, se tienen que cumplir una serie de requisitos (indicados en las cajas con forma de rombo) y, aún habiendo llegado a la última escena, no se garantiza que se pueda producir una salida. Esto podrı́a ocurrir si, por ejemplo, en la primera escena el usuario seleccionase algún fichero de configuración o plantilla que no fuera válido. En estos casos, se muestra en la consola de la cuarta escena cuál ha sido el problema para que el usuario pueda volver y corregir el error. También es de interés explicar la manera en la que la aplicación obtiene las opciones para los desplegables y cómo “sabe” qué ficheros modificar. Dado que no se ha considerado práctico agrupar todos los archivos que hacen que la aplicación funcione en un mismo directorio, se ha implementado una estructura de ficheros cuya organización es la que se explica en la subsección 3.4.1. De esta manera, al arrancar, la aplicación indexa el árbol sabiendo que “ella misma” se encuentra exactamente en la raı́z del árbol: es decir, la aplicación inicialmente conoce su propia ruta absoluta. Empezando por la primera escena, el desplegable correspondiente al fichero “Configuración” lo puebla indexando la carpeta /Tardis/Configuration/, escogiendo únicamente aquellos ficheros cuyo nombre empiece por la letra ‘c’ y termine con “.json”, mientras que el desplegable de “Data” lo puebla indexando ese mismo directorio, con la diferencia de que en este caso busca aquellos ficheros que empiecen por la letra ‘d’ y terminen por “.json”. Para poblar el desplegable de “Fichero R (stardis)”, se indexa el directorio /Tardis/Source/ y se guardan los nombres de todas las entradas que terminen con “.R”. El desplegable de “Fichero Rnw (LaTeX + plantilla)” lo puebla indexando /Tardis/Source/Analysis/. Una vez el usuario ha seleccionado los ficheros de esta primera ventana, la aplicación podrá obtener sus rutas absolutas y modificarlos según las indicaciones del usuario. Posteriormente, el usuario deberá elegir de qué ficheros CSV desea obtener el informe. De la estructura que deben tener estos dos ficheros se habla en la subsección 3.4.6. Estos ficheros los indexa del directorio /Tardis/Data/. El primer desplegable lo puebla con aquellas entradas que terminen en “.csv”, a excepción de las que cuyo nombre termine en “-build”, mientras que el segundo desplegable se puebla con las entradas cuyo nombre acabe en “.csv” y además su nombre termine en “-build”. 29.
(39) Para generar la salida del programa, se leerán estos ficheros sin modificarse.. 3.4.3. Layout y navegación de la interfaz. Figura 3.20: Escena 1. Selección de ficheros. Según se arranca la aplicación, se visualizará en el escritorio la primera escena tal y como se muestra en la figura 3.20. Se deben rellenar todos los desplegables para poder continuar a la segunda escena. El desplegable de “Configuration” se poblará con cuantas opciones como ficheros JSON cuyos nombres empiecen por la letra ‘c’ haya dentro de la carpeta Configuration (subsección 3.4.1). El desplegable de “Data” se poblará de manera análoga al anterior, solo que solo tendrá en cuenta aquellos ficheros JSON cuyos nombres empiecen por la letra ‘d’. El desplegable de “R file (stardis)” se poblará con tantas opciones como ficheros R haya en la carpeta Source (subsección 3.4.1). Finalmente, el desplegable de “Rnw file (LaTeX + R template)” se poblará con cuantas opciones como ficheros Rnw haya en la carpeta Analysis.. 30.
(40) Una vez rellenados todos los desplegables, se puede avanzar a la siguiente escena pulsando el botón de “Continuar”.. Figura 3.21: Escena 2. Selección de ficheros CSV. En la segunda escena se deben introducir tres datos: el fichero de datos en bruto y el fichero de diccionario (subsección 3.4.6) y el número de la primera variable numérica. El desplegable de “Data (CSV)” (correspondiente al fichero de datos en bruto) y el desplegable de “Data (CSV Build)”(correspondiente al fichero de diccionario) se poblarán con tantas opciones como ficheros CSV haya en la carpeta Data: el primero tendrá en cuenta aquellos ficheros que cuyo nombre no acabe en “-build”, mientras que el segundo desplegable tendrá en cuenta aquellos ficheros cuyo nombre sı́ acabe en “-build”. En cuanto al número de la primera variable o columna numérica, siguiendo el ejemplo de la sección 3.4.6, serı́a el número 3 dado que de las 5 variables propuestas, la primera numérica es la tercera (“Altura”). Una vez introducidos todos los datos, se puede pasar a la tercera escena pulsando el botón “Continuar”.. 31.
(41) Figura 3.22: Escena 3. Personalización de la salida. La tercera escena es en la que se puede personalizar la salida; es decir, las caracterı́sticas del fichero PDF/TEX resultante. Obligatoriamente, se debe escoger al menos una opción de la columna “Report type”, al menos una opción de la columna “Target variables 1:N” y se debe rellenar tanto el campo de texto de “Author” como el de “Document title”. Las dos opciones de la columna “Report type” son excluyentes, lo que quiere decir que solo se podrá seleccionar una. La opción “Article (short)” produce un informe sin descripciones largas, mientras que la opción “Report (long)” produce un informe con descripciones largas de las figuras que contiene. Las opciones de la columna “Target variables1:N” permiten elegir el tipo de figuras/información que contendrá el informe generado: • Raw data: Si se selecciona esta opción, en el informe aparecerá una tabla con los datos en bruto introducidos en el fichero de datos en bruto. • Summary: Si se selecciona esta opción, en el informe aparecerá una tabla con información relativa los datos de las variables numéricas introducidas en el fichero de datos en bruto. Esta información es: el número de datos por variable, la media, la desviación estándar, el mı́nimo, el primer cuartil, la mediana, el tercer cuartil y el máximo. • Histogram: Si se selecciona esta opción, se mostrará una figura con un gráfico de tipo histrograma por cada variable numérica que se indique. Adicionalmente, se debe indicar en la caja de texto de la derecha de esta opción de qué 32.
(42) variables se quiere obtener dicha figura separadas por comas (por ejemplo, Altura,Peso,Litros). • Boxplot: Si se selecciona esta opción, se mostrará una figura con un gráfico de tipo diagrama de cajas por cada variable numérica que se indique. La caja de texto de la derecha de esta opción funciona igual que el caso anterior. • Multi boxplot: Si se selecciona esta opción, se mostrará una única figura de tipo diagrama de cajas múltiple de las variables numéricas que se indiquen en la caja de texto de la derecha de esta opción. Finalmente, en las cajas de texto de “Author” y “Document title”, se debe escribir, respectivamente, el nombre del autor y el tı́tulo que se desee para el informe. Una vez rellenados los datos obligatorios, se puede avanzar a la cuarta y última escena de la aplicación.. Figura 3.23: Escena 4. Finalización. Para finalizar, se encuentra la cuarta escena de la aplicación. Las acciones requeridas para obtener el fichero PDF/TEX del informe son sencillas: Se debe elegir una ruta para el fichero TEX de salida haciendo click sobre el icono de la lupa de arriba, y una ruta para el fichero PDF haciendo click sobre el icono de la lupa de abajo. Una vez se hayan seleccionado las dos rutas, se puede pulsar el botón de “Finalizar”, situado en la esquina inferior derecha de la aplicación. En el panel negro de la derecha, se podrán ver, una vez finalizado el proceso de generación de la salida, una. 33.
(43) serie de mensajes de traza relativos al estado de la finalización del programa Tardis. Si todo ha ido bien (es decir, si el formato de los ficheros y las opciones de personalización de la salida son correctos), los ficheros PDF y TEX estarán donde se haya elegido.. 3.4.4. Menú de opciones. Se habla a continuación de las distintas opciones de menú de la aplicación.. Menú de Archivo El menú de Archivo es la primera opción de menú empezando por la izquierda de la barra de menú. En este menú se presentan 4 opciones: New session, Load Session, Save Session y Exit: • New Session: Al seleccionar esta opción, se borran de la interfaz los datos introducidos y se devuelve a la primera escena, es decir, a la escena de selección de ficheros. No se guardan los datos de manera automática, de modo que hay que estar seguro de que se desea empezar desde cero con la introducción de datos. • Load Session: Esta opción permite cargar una sesión preexistente. Las sesiones se guardan en formato JSON, de modo que intentar abrir cualquier tipo de archivo que no tenga esa extensión no tendrá ningún efecto. • Save Session: Con esta opción se pueden guardar los datos ya introducidos en la aplicación a un fichero JSON. • Exit: Cierra la aplicación.. Menú de Informe El menú de Informe es la segunda opción del menú empezando por la izquierda de la barra de menú. En este menú se presentan dos opciones con dos sub-opciones cada una: • JSON Configuration: “Configurar JSON” en español, esta opción de menú despliega otras dos opciones de menú de las que se habla a continuación. Estas dos opciones permiten ver y modificar el contenido de los ficheros seleccionados en la primera columna de la primera escena. ◦ Data file: “Archivo de datos” en español. Al seleccionar esta opción, se puede ver y modificar el contenido del fichero seleccionado en el desplegable de “Data” de la primera escena:. 34.
(44) Figura 3.24: Desplegable de “Data”. ◦ Configuration file: “Archivo de configuración” en español. Al seleccionar esta opción, se puede ver y modificar el contenido del fichero de configuración seleccionado en el despegable de “Configuration”:. Figura 3.25: Desplegable de “Configuration”. • Templates configuration: “Configurar plantillas” en español, esta opción de menú despliega otras dos opciones de menú análogamente a lo expuesto 35.
(45) anteriormente. Estas dos opciones permiten ver y modificar el contenido de los ficheros seleccionados en la segunda y tercera columna de la primera escena. ◦ R template: “Plantilla R” en español. Al seleccionar esta opción se puede ver y modificar el contenido del fichero stardis seleccionado en el desplegable de “R file (stardis)”; es importante tener en cuenta que este fichero es crucial para la correcta ejecución de la aplicación, por lo que se recomienda hacer una copia del mismo en la carpeta Source de la que se habla en la subsección 3.4.1. ◦ Rnw template: “Plantilla Rnw” en español. Al seleccionar esta opción se puede ver y modificar el contenido del fichero seleccionado en el desplegable de “Rnw file (LaTeX + R template)”. Al igual que el fichero anterior, este fichero es igualmente importante para el correcto funcionamiento de la aplicación, por lo que antes de modificar el que se provee por defecto, se recomienda hacer una copia del mismo fichero en la carpeta Analysis de la que se habla en la subsección 3.4.1.. Menú de Idioma El menú de Idioma es la tercera opción del menú empezando por la izquierda de la barra de menú. En este menú se muestran dos opciones con las que se puede cambiar el idioma de la aplicación de español a inglés y viceversa.. Menú de Ayuda El menú de Ayuda es la cuarta y última opción empezando por la izquierda de la barra de menú. En este menú se muestran dos opciones: • Tardis2 : Al seleccionar esta opción, se abre el manual del usuario con el lector de ficheros PDF por defecto en la máquina del usuario. • Credits: Al seleccionar esta opción, se muestra la siguiente escena con información relativa a la autorı́a de la aplicación:. 36.
(46) Figura 3.26: Créditos de la aplicación.. 3.4.5. Control de sesión. Se ha implementado además el control de sesión; esto es, la capacidad de guardar y cargar sesiones. Se ha decidido implementar este control de sesión porque cabe la posibilidad de que un usuario desee generar una serie de informes con opciones de configuración muy parecidas a lo largo de varias jornadas de trabajo. Si bien es poca la información a introducir en la interfaz, es cierto que resultarı́a más cómodo disponer de un sistema que permita al usuario guardar en algún fichero los datos introducidos. Ası́, se ha implementado un sistema para guardar la información introducida en la interfaz en un fichero JSON, que se podrá cargar en distintas sesiones en el futuro. Tanto la carga como el guardado de sesión se llevará a cabo con las opciones de menú “Save session” y “Load session” respectivamente, tal y como se explica brevemente en la subsección 3.4.4 - Menú de Archivo. En cuanto a la estructura del fichero de sesión, se trata de la estructura clásica de un fichero JSON. A continuación se explica más en detalle cada propiedad/objeto de este fichero: • stage1: Se trata de un sub-objeto JSON con información relativa a lo que el usuario haya introducido en la primera escena de la aplicación. Este objeto tiene a su vez las siguientes propiedades: 37.
(47) ◦ configJSON: Propiedad de tipo string. El valor que toma es el nombre del fichero de configuración seleccionado por el usuario (figura 3.25). ◦ dataJSON: Propiedad de tipo string. El valor que toma es el nombre del fichero se datos (JSON) seleccionado por el usuario (figura 3.24). ◦ R: Propiedad de tipo string. El valor que toma es el nombre del fichero R seleccionado por el usuario. ◦ Rnw: Propiedad de tipo string. El valor que toma es el nombre del fichero Rnw seleccionado por el usuario. • stage2: Se trata de otro sub-objeto JSON con información relativa a lo que el usuario haya introducido en la segunda escena de la aplicación. Este objeto tiene las siguientes propiedades: ◦ data: Propiedad de tipo string. El valor que toma es el nombre del fichero de datos en bruto seleccionado por el usuario. ◦ dataBuild: Propiedad de tipo string. El valor que toma es el nombre del fichero de diccionario seleccionado por el usuario. ◦ firstNumericalColumn: Propiedad de tipo integer. El valor que toma es el número de la primera columna numérica que haya introducido el usuario. • stage3: Finalmente, está el sub-objeto que contiene información relativa a lo que se haya introducido en la tercera escena de la interfaz. Este objeto tiene las siguientes propiedades: ◦ summary: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox (caja para marcar) asociada a la opción “Summary” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ histogram: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Histogram” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ boxplot: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Boxplot” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ reportTypeArticle: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Article (short)” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ reportTypeReport: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Report (long)” de 38.
(48) la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ multiBoxplot: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Multi boxplot” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ rawData: Propiedad de tipo boolean. El valor que toma depende del estado de la checkbox asociada a la opción “Raw Data” de la tercera escena de la interfaz. Si dicha caja está seleccionada, el valor de esta propiedad será true y false en caso contrario. ◦ multiBoxplotVariables: Propiedad de tipo array de string. Cada elemento de esta estructura de datos se corresponderá con cada una de las variables separadas por comas que haya escrito el usuario en la caja de texto asociada con la opción “Multi boxplot” de la tercera escena de la interfaz. ◦ boxplotVariables: Análogo al caso anterior, pero asociado a la caja de texto de la entrada “Boxplot”. ◦ histogramVariables: Análogo al caso anterior, pero asociado a la caja de texto de la entrada “Histogram”. ◦ author: Propiedad de tipo string. El valor que toma es lo que el usuario haya escrito en la caja de texto asociada al campo “Author” de la tercera escena de la interfaz. ◦ title: Análogo al caso anterior, pero asociado al campo “Document title” de la tercera escena de la interfaz. Ası́, un ejemplo de archivo de sesión podrı́a ser el que se muestra a continuación:. 1 { 2 3 4 5 6 7 8 9 10 11 12 13 14. ” stage1 ”: { ” configJSON ” : ” c o n f i g u r a t i o n . j s o n ” , ”dataJSON ” : ” data . j s o n ” , ”R” : ” s t a r d i s .R” , ”Rnw” : ”main . Rnw” }, ” stage2 ”: { ” data ” : ” c u e s t i o n a r i o 1 . c s v ” , ” d a t a B u i l d ” : ” c u e s t i o n a r i o 1 c u e s t i o n a r i o 1 −b u i l d . c s v ” , ” firstNumericalColumn ”: 7 }, ” stage3 ”: { ”summary ” : t r u e , 39.
(49) 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 }. ” histogram ” : f a l s e , ” boxplot ” : true , ” reportTypeArticle ” : true , ” reportTypeReport ” : f a l s e , ” multiBoxplot ” : true , ” rawData ” : f a l s e , ” multiBoxplotVariables ”: [ ”P1 ” , ”P2 ” , ”P4” ], ” boxplotVariables ”: [ ”P1 ” , ”P5 ” , ”P6 ” , ”P7 ” , ”P9” ], ” histogramVaraibles ”: [ ”” ], ” au tho r ” : ” John Doe ” , ” t i t l e ” : ” In for me de e n c u e s t a ” }. 3.4.6. Formato de los datos de entrada. Para que la aplicación genere un informe en formato PDF de los datos que se le indique, es necesario que estos datos sigan un formato definido que se describe en los dos siguientes apartados. Por un lado, la aplicación necesita de un fichero en el que se encuentren los datos en bruto y por otro lado, necesita otro fichero diccionario.. Datos en bruto Los datos en bruto se deben proporcionar en un fichero con extensión CSV. Para que la aplicación pueda identificar este fichero, se debe colocar dentro de la carpeta Data mencionada en la subsección 3.4.1. En la primera fila de este fichero, separados por comas (,), se deben indicar los nombres de las variables de las que se tienen los datos. Se tiene que tener en cuenta que no se deben mezclar variables numéricas con variables no-numéricas, debiendo escribir en primer lugar las variables no-numéricas seguidas de las numéri40.
(50) cas. Por poner un ejemplo, imagı́nese que se tienen las variables llamadas “Nombre”, “Ubicación”, “Altura”, “Peso” y “Litros”. Por simplicidad, se asume que las variables no-numéricas son “Nombre” y “Ubicación”. De esta forma, la primera lı́nea del fichero de datos en bruto podrı́a ser: Nombre,Ubicacion,Altura,Peso,Litros A continuación, las siguientes lı́neas del fichero de datos en bruto deben tener, separados por comas nuevamente, los valores de cada una de las variables en el orden en el que se han colocado las variables en la primera lı́nea. De nuevo, se propone un ejemplo. Se consideran las variables del ejemplo anterior. Imagı́nese que la variable “Nombre” tiene los valores “Alberto”, “Benito” y “Carlos”; la variable “Ubicación” tiene los valores “Planta1”, “Planta2” y “Planta5”; la variable “Altura” tiene los valores 174, 162 y 182; la variable “Peso” tiene los valores 40, 55 y 89; y finalmente la variable “Litros” tiene los valores 5.2, 4.9 y 6.1. Al tener tres valores por variable, harı́an falta tres lı́neas, que serı́an las que siguen: Alberto,Planta1,174,40,5.2 Benito,Planta2,162,55,4.9 Carlos,Planta5,182,89,6.1 Para finalizar con el ejemplo, el contenido total del fichero de datos en bruto deberı́a ser: Nombre,Ubicación,Altura,Peso,Litros Alberto,Planta1,174,40,5.2 Benito,Planta2,162,55,4.9 Carlos,Planta5,182,89,6.1. Diccionario Para complementar al fichero de datos en bruto sobre el que se habla en la sección anterior, es necesario proporcionarle a la aplicación un fichero ”diccionario”, en el que figurarán los acrónimos, nombres cortos y nombres largos para cada variable. Al igual que el fichero de datos en bruto, este fichero diccionario debe tener extensión CSV e igualmente se debe colocar en la carpeta Data mencionada en la subsección 3.4.1, con la particularidad añadida de que el nombre de este fichero debe, obligatoriamente, acabar en -build (por ejemplo, datos ejemplo-build.csv). Mientras este fichero siempre va a tener tres (3) columnas, el número de filas deberá ser igual al número de variables que se hayan considerado para el fichero de 41.
(51) datos en bruto más uno. Enlazándolo con el ejemplo anterior, el fichero diccionario asociado deberá tener tres (3) columnas y séis (6) filas, dado que en ese ejemplo se consideran 5 variables, más una primera fila diferente. La primera fila de este fichero debe contener, separadas por comas (,), las palabras “Acronym”, “Shortname” y “Longname”: Acronym,Shortname,Longname Ası́, cada una de las filas siguientes debe tener en primer lugar un acrónimo, en segundo lugar un nombre corto y en último lugar un nombre largo de la variable correspondiente. Volviendo al ejemplo, se tienen las variables “Nombre”, “Ubicación”, “Altura”, “Peso” y “Litros”. Una posible manera de organizar las filas siguientes a la primera fila podrı́a ser: N,Nombre,Nombre del candidato U,Ubicacion,Ubicacion del puesto de trabajo A,Altura,Altura del candidato en cm P,Peso,Peso del candidato en kg L,Litros,Litros de sangre del candidato Finalizando con el ejemplo, el contenido completo de este fichero diccionario serı́a: Acronym,Shortname,Longname N,Nombre,Nombre del candidato U,Ubicacion,Ubicacion del puesto de trabajo A,Altura,Altura del candidato en cm P,Peso,Peso del candidato en kg L,Litros,Litros de sangre del candidato. 3.4.7. Manual del usuario. Tal y como se menciona en la subsección 3.2.2, después de analizar el feedback de los voluntarios que probaron la aplicación, se decidió redactar un manual del usuario. En este manual se explica la estructura básica de los ficheros que componen la aplicación, qué dependencias son necesarias para que la aplicación funciones y cómo configurarlas correctamente, además de un ejemplo de uso práctico. El manual del usuario forma parte de los ficheros de la aplicación. Se adjunta a continuación dicho manual en formato PDF. Si se está leyendo esta memoria en formato digital, para abrirlo tan solo hace falta hacer doble click sobre el icono del clip de debajo:. Manual del usuario. 42.
Documento similar
Para recibir todos los números de referencia en un solo correo electrónico, es necesario que las solicitudes estén cumplimentadas y sean todos los datos válidos, incluido el
(Banco de España) Mancebo, Pascual (U. de Alicante) Marco, Mariluz (U. de València) Marhuenda, Francisco (U. de Alicante) Marhuenda, Joaquín (U. de Alicante) Marquerie,
The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,
d) que haya «identidad de órgano» (con identidad de Sala y Sección); e) que haya alteridad, es decir, que las sentencias aportadas sean de persona distinta a la recurrente, e) que
La siguiente y última ampliación en la Sala de Millones fue a finales de los años sesenta cuando Carlos III habilitó la sexta plaza para las ciudades con voto en Cortes de
Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de
En este trabajo estudiamos la obra poética en español del escritor y profesor argelino Salah Négaoui, a través de la recuperación textual y análisis de Poemas la voz, texto pu-
Las manifestaciones musicales y su organización institucional a lo largo de los siglos XVI al XVIII son aspectos poco conocidos de la cultura alicantina. Analizar el alcance y
