Desarrollo de un plugin para SemanticMerge para facilitar la integración de versiones de archivos Vensim

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA Menci´on en Ingenier´ıa del Software Desarrollo de un plugin para SemanticMerge para facilitar la integraci´on de versiones de archivos Vensim Alumno: Pablo Mart´ınez L´opez Tutora: Yania Crespo Gonz´alez-Carvajal A mis padres I II AGRADECIMIENTOS Agradecimientos A mi familia, por todo el apoyo durante este complicado a˜no de mucho trabajo. A mis amigos y compa˜neros de carrera, por animarme en todo momento, por ayudarme a desconectar del estr´es y por motivarme a aprender y a mejorar no s´olo este ´ultimo a˜no, sino durante toda la carrera. A mi pareja Laura, por haberme apoyado constantemente durante todo este a˜no y por ayudarme a manejar mis nervios y estr´es. A mi tutora Yania, por su labor como profesora y coordinadora de este Trabajo de Fin de Grado, que sin duda ha sido clave para mantener un trabajo constante y de calidad a lo largo de todos los meses del proyecto. A los miembros de Plastic SCM, concretamente a Pablo Santos, Violeta S´anchez y Borja Ruiz y con especial gratitud a M´ıryam G´omez; por toda la ayuda en la resoluci´on de las dudas y problemas relacionados con las herramientas de SemanticMerge y gmaster. Al proyecto LOCOMOTION y su financiaci´on de la beca asociada a este proyecto, y en especial a Ignacio de Blas Sanz, David Gonz´alez Antelo e ´ I˜nigo Capell´an P´erez, miembros del GIR GEEDS, por su participaci´on en las pruebas de aceptaci´on de usuarios. III AGRADECIMIENTOS IV RESUMEN Resumen Vensim es un lenguaje de modelado de din´amica de sistemas. Incluye una parte de definici´on de ecuaciones y otra parte visual. Trabajar en equipo, de forma coordinada, con control e integraci´on de versiones, en Vensim es un gran reto. Por su parte, SemanticMerge es una herramienta para visualizar diferencias y para mezclar versiones (merge) con ayuda para la resoluci´on de conflictos. El objetivo de este Trabajo de Fin de Grado es desarrollar un parser externo de Vensim para SemanticMerge, que a su vez ser´a utilizado por la herramienta de control de versiones gmaster. El parser funciona leyendo un archivo de entrada y generando un archivo YAML con la informaci´on necesaria para que SemanticMerge sea capaz de leerlo y reconstruir el archivo, obteniendo toda la informaci´on sem´antica y sint´actica del archivo en dicho proceso. Este proceso se realiza en ambas versiones de un archivo cuando se lleva a cabo una fusi´on o merge, para posteriormente resolver los conflictos y realizar el merge correctamente. El trabajo ha sido desarrollado utilizando ANTLR4 para el desarrollo de la gram´atica as´ı como Java como lenguaje de programaci´on principal. Para el desarrollo del proyecto se adapt´o SCRUM como marco de trabajo ´agil. Este proyecto forma parte del proyecto europeo H2020 LOCOMOTION que tiene como objetivo el desarrollo de un modelo de evaluaci´on integrado (Integrated Assesment Model, IAM), un modelo complejo basado en din´amica de sistemas, que permite la simulaci´on de escenarios diferentes que afectan a largo plazo a diferentes indicadores, lo que permite determinar los m´as favorables para un futuro sostenible. El IAM desarrollado en LOCOMOTION se programa en Vensim de forma coordinada, participando 30 programadores de 13 instituciones europeas diferentes. V RESUMEN VI ABSTRACT Abstract Vensim is a system dynamics modeling language. It includes two main parts: an equation definition section and a sketch definition section. Coordinated teamwork using integration and version control tools when programming in Vensim is a great challenge. On the other hand, SemanticMerge is a standalone application that allows to visualize changes between different versions of a file and then merge these versions, helping to solve the conflicts that arise. This Final Degree Project aims to develop an external parser for SemanticMerge that allows parsing Vensim files. This parser will also be used by the version control tool gmaster. The parser reads an input file and generates a tree descriptor YAML file containing the information needed for SemanticMerge to reconstruct the file obtaining all the semantic and syntactic information of the file in the process. This process is performed in both versions of the file when a merge operation is achieved, allowing conflict resolution, and enabling a successful merge. ANTLR4 is used for the development of the grammar as well as Java as the main programming language. SCRUM was applied as an Agile framework adapted for the development of the project. This project is part of the European H2020 project LOCOMOTION. This project aims to develop an Integrated Assessment Model (IAM), a complex model of the World and regions, based on system dynamics, that allows the simulation of different scenarios that long term affect different indicators and to determine the more favorable ones for a sustainable future. The IAM developed in LOCOMOTION is programmed in Vensim in a coordinated way by 30 programmers from 13 different European institutions. VII ´ INDICE GENERAL A.2.6. Advertencias sobre el nombrado de variables . . . . . . . . . . . . . . 116 A.2.7. Enlaces de inter´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.3. Manual de mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.3.1. Actualizaci´on de la gram´atica y del parser . . . . . . . . . . . . . . . . 117 A.3.2.Procesodetesting ............................. 118 A.3.3. Actualizaciones de SemanticMerge y gMaster. . . . . . . . . . . . . . . 119 B. Resumen de enlaces adicionales 121 Bibliograf´ıa 123 XIV LISTA DE FIGURAS Lista de Figuras 1.1. Representaci´on de un sistema peque˜no en Vensim. . . . . . . . . . . . . . . . 3 1.2. Elecci´on de par´ametros para un nuevo modelo. . . . . . . . . . . . . . . . . . 4 1.3. Men´u de opciones de una variable. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Esquema de metodolog´ıa git-flow. Tomada de [6] . . . . . . . . . . . . . . . . 7 1.5. Vista de espacio de trabajo principal en PlasticSCM . . . . . . . . . . . . . . 8 1.6. Vista de Cambios Pendientes en PlasticSCM . . . . . . . . . . . . . . . . . . 8 1.7. A˜nadir repositorio en gMaster. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.8. Vista principal de gMaster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.9. Vista principal en formato visual de gMaster. . . . . . . . . . . . . . . . . . . 11 1.10. Archivos a escoger en gMaster. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.11. Interfaz gr´afica de SemanticMerge. Tomada de [45] . . . . . . . . . . . . . . . 12 1.12. Significado de las letras en SemanticMerge. Tomado de [43] . . . . . . . . . . 13 1.13. Diferenciaci´on textual entre archivos de SemanticMerge . . . . . . . . . . . . 15 1.14. Diferenciaci´on sem´antica entre archivos de SemanticMerge . . . . . . . . . . . 15 1.15. Diferenciaci´on visual entre archivos de SemanticMerge . . . . . . . . . . . . . 16 1.16. Diagrama de clases de la estructura de parseo de SemanticMerge. Tomado de[40]........................................ 16 3.1. Proceso de comunicaci´on de SemanticMerge con el parser externo, [40] . . . . 39 5.1. Diagrama de actividad asociado al programa . . . . . . . . . . . . . . . . . . 48 XV LISTA DE FIGURAS 5.2. Esquema de cambios en el formato textual de gMaster . . . . . . . . . . . . . 55 5.3. Esquema de cambios en el formato sem´antico de gMaster . . . . . . . . . . . 55 5.4. Esquema de cambios en el formato visual de gMaster . . . . . . . . . . . . . . 56 5.5. Diagrama de clases simple del parser externo para archivos Vensim. . . . . . 57 5.6. Diagrama de clases detallado del parser externo para archivos Vensim. . . . . 58 5.7. Diagrama de clases de la herramienta encargada de a˜nadir los nombres de las vistas en las ecuaciones y delimitadores. . . . . . . . . . . . . . . . . . . . . . 59 5.8. Diagrama de clases de la herramienta encargada de eliminar los nombres de las vistas en las ecuaciones y delimitadores. . . . . . . . . . . . . . . . . . . . 59 A.1. Cambio de modo visual en gMaster a trav´es del bot´on Theme. . . . . . . . . 104 A.2. Selecci´on de cambio en modo iluminado. . . . . . . . . . . . . . . . . . . . . . 105 A.3. Selecci´on de cambio en modo oscuro. . . . . . . . . . . . . . . . . . . . . . . . 105 A.4. Diagrama del flujo de trabajo con la herramienta en la fusi´on de ramas. . . . 107 A.5. Diagrama de flujo trabajo con la herramienta en la diferenciaci´on de commits. 107 A.6. Pantalla principal de la interfaz de adici´on de nombres de las vistas y delimitadores. ....................................... 108 A.7. Pantalla secundaria de la interfaz de adici´on de nombres de las vistas y delimitadores....................................... 109 A.8. Tipos de cambios en gMaster y SemanticMerge. . . . . . . . . . . . . . . . . . 110 A.9. Interfaz de gmaster y sus correspondientes partes. . . . . . . . . . . . . . . . 111 A.10.Visualizaci´on de diferencias entre versiones de un .mdl basada en grafismos. . 111 A.11.Pantalla principal de la interfaz de eliminaci´on de delimitadores. . . . . . . . 112 A.12.Pantalla secundaria de la interfaz de eliminaci´on de delimitadores. . . . . . . 113 XVI LISTA DE TABLAS Lista de Tablas 2.1. Product Backlog inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2. Desglosedelatarea1................................ 22 2.3. Desglose de la tarea 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4. Desglose de la tarea 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5. Desglosedelatarea2................................ 23 2.6. ProductBacklogfinal. ............................... 24 2.7. Tabla de calendarizaci´on de sprints. . . . . . . . . . . . . . . . . . . . . . . . 25 2.8. Riesgo de falta de tiempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9. Riesgo de actualizaci´on de Vensim. . . . . . . . . . . . . . . . . . . . . . . . . 27 2.10. Riesgo de modificaciones de los requisitos. . . . . . . . . . . . . . . . . . . . . 27 2.11. Riesgo de necesidad de actualizar la gram´atica. . . . . . . . . . . . . . . . . . 27 2.12. Riesgo de modificaciones en la forma de interaccionar con SemanticMerge. . . 28 2.13.RiesgodeCOVID-19. ............................... 28 2.14. Presupuesto simulado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Escenarios a realizar en las interfaces de procesado de ficheros. . . . . . . . . 72 6.2. Escenarios a realizar en el parser externo a trav´es de gMaster. . . . . . . . . . 74 6.3. Competencias a adquirir en los escenarios . . . . . . . . . . . . . . . . . . . . 74 7.1. Tareasdelsprint1.................................. 80 XVII LISTA DE TABLAS 7.2. Tareasdelsprint2.................................. 82 7.3. Tareasdelsprint3.................................. 83 7.4. Tareasdelsprint4.................................. 84 7.5. Tareasdelsprint5.................................. 85 7.6. Tareasdelsprint6.................................. 86 7.7. Descanso de navidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.8. Sprint7........................................ 88 7.9. Sprint8........................................ 90 7.10.Sprint9........................................ 91 7.11.Sprint10. ...................................... 92 7.12.Sprint11. ...................................... 93 7.13. Tabla de calendarizaci´on de sprints final. . . . . . . . . . . . . . . . . . . . . . 94 7.14. Trabajo total realizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 XVIII CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on 1.1. Contexto Este Trabajo de Fin de Grado ha sido realizado como una beca, financiada por la Uni´on Europea, adscrita al proyecto de investigaci´on del programa marco Horizonte 2020 (H2020): “Low-carbon society: an enhanced modelling tool for the transition to sustainability” oLOCOMOTION [16]. En este proyecto participan 13 instituciones europeas de 10 pa´ıses diferentes, coordinado desde la Universidad de Valladolid por el GIR (Grupo de Investigaci´on Reconocido) en Energ´ıa, Econom´ıa y Din´amica de Sistemas (GEEDS). Con este proyecto de investigaci´on colaboran tambi´en algunos profesores del Departamento de Inform´atica de esta Universidad. Debido a la aceleraci´on del cambio clim´atico y todas las consecuencias que ello conlleva, en Europa se acord´o tratar de dise˜nar un conjunto de sistemas de modelado o IAMs (Integrated Assement Models) capaz de proporcionar una visi´on real del futuro del planeta a aquellas instituciones que tomasen medidas relacionadas con el devenir del planeta acorde al cambio clim´atico. Por ello se cre´o el proyecto MEDEAS [17] (Modelling the Energy Development under Environmental And Socioeconomic constraints), cuyo objetivo era crear un sistema computacional capaz de modelar la energ´ıa en Europa, a trav´es de constantes f´ısicas y sociales. Esto permitir´ıa transicionar a un modelo energ´etico m´as sostenible en un futuro. Este proyecto culmin´o en un modelo intermedio y ha evolucionado en el ´ultimo a˜no a su continuaci´on natural, con el ya nombrado proyecto LOCOMOTION. Tanto el anterior proyecto MEDEAS como el actual LOCOMOTION utilizan el software Vensim de desarrollo de modelos de simulaci´on basados en din´amica de sistemas. Actualmente, desde el Departamento de Inform´atica de la UVa se desarrollan varios sub-proyectos como partes del proyecto LOCOMOTION, tales como este Trabajo de Fin de Grado u otros destinados, por ejemplo, a la creaci´on de un juego educativo de concienciaci´on para adolescentes sobre el cambio clim´atico o plugins para SonarQube, herramienta que realiza controles de calidad sobre el c´odigo Vensim. 1 1.2. MOTIVACI ´ ON Este Trabajo de Fin de Grado se centra en c´omo mejorar el control de versiones, y la realizaci´on de merges o fusiones entre diferentes versiones de archivos Vensim. 1.2. Motivaci´on Los archivos con extensi´on .mdl de Vensim pueden dividirse en dos grandes partes, una secci´on de definici´on de ecuaciones y dem´as tipos de datos b´asicos, y una secci´on de definici´on de informaci´on de cada una de las vistas (diagramas de modelado de din´amica de sistemas) as´ı como las definiciones de gr´aficos para la visualizaci´on de los resultados de las simulaciones. En un escenario de control de versiones de archivos Vensim, al modificar un archivo .mdl en un proyecto, peque˜nos cambios como movimientos de variables en una vista generan problemas m´ultiples cambios en el fichero, muy desproporcionados respecto al tama˜no de las modificaciones lo que introduce una complejidad enorme a la hora de intentar fusionar o mergear los ficheros con los que un equipo ha estado trabajando. SemanticMerge [43] es un software capaz de tratar de forma sencilla y visual alteraciones de c´odigo entre ficheros, tales como movimientos, adiciones o eliminaciones de secciones de c´odigo o renombrados. Este software no est´a enfocado a un paradigma concreto de lenguajes de programaci´on sino a una estructura de contenedores y nodos, con la cual es posible tratar los archivos de Vensim. Se ha propuesto crear un plugin, herramienta o parser externo para la herramienta de SemanticMerge que permita solucionar dichos problemas de una forma sencilla. Se parte inicialmente de una gram´atica de Vensim encargada de procesar dichos archivos .mdl pero que s´olo trataba la primera parte de los mismos (la secci´on relacionada con la definici´on de ecuaciones). Por tanto, se hace necesario ampliar la gram´atica para poder procesar archivos .mdl en su totalidad, con una complejidad mucho mayor, con m´ultiples vistas y definiciones de gr´aficos. 1.3. Introducci´on a Vensim Vensim [56] es un software de simulaci´on basado en din´amica de sistemas que permite realizar grandes modelos y comprobar su rendimiento y progreso a lo largo de un periodo de tiempo. Dicho programa es un software gr´afico que nos permite representar nuestro sistema mediante diagramas en las que se relacionan variables, y otros elementos, con flechas que representan flujos, tal y como puede verse en la Figura 1.1, la cual muestra un sistema muy simple modelado con Vensim. Pese a la simplicidad del sistema ilustrado en la figura, en Vensim se pueden representar sistemas muy complejos a trav´es de varias vistas que se hacen referencia entre s´ı. Tambi´en es posible utilizar gr´aficos para ofrecer informaci´on de la simulaci´on de forma m´as visual. Los modeladores suelen trabajar de forma gr´afica con los archivos que representan los modelos. La extensi´on m´as com´un de Vensim, .mdl, permite exportar el modelo a un archivo 2 CAP´ ITULO 1. INTRODUCCI ´ ON Figura 1.1: Representaci´on de un sistema peque˜no en Vensim. completamente textual, transformando toda la parte gr´afica en datos num´ericos y metadatos. Tambi´en se pueden guardar los archivos en formato binario, con sus respectivas extensiones: .vpm y.vpf. Un proyecto en Vensim se corresponde con un modelo, el cual reside en un ´unico archivo que se compone por una serie de elementos relacionados entre s´ı, los cuales trataremos m´as adelante. Adem´as, un modelo puede estar compuesto por m´as de una vista, estando los elementos de todas las vistas relacionados. Las vistas suelen utilizarse para desglosar un modelo de grandes dimensiones, manteniendo una correlaci´on entre las vistas. Es posible tratar modelos separados en cada vista, aunque es muy poco recomendable. Al iniciar un nuevo modelo en Vensim, se lanza una ventana emergente donde configuraremos los par´ametros iniciales de nuestro sistema, as´ı como el ritmo al que evoluciona. Esto puede apreciarse en la Figura 1.2. Estas variables ser´an globales, por lo que ser´an comunes a todas las vistas. Podr´an ser usadas en las definiciones de ecuaciones o en ciertos casos como variables sombra o shadow variables, las cuales ser´an explicadas en secciones posteriores de la memoria. 1.3.1. Tipos b´asicos en Vensim Vensim presenta una serie de tipos b´asicos los cuales es importante conocer puesto que se nombrar´an en m´ultiples ocasiones a lo largo de esta memoria [55]: Variables auxiliares. Cambian a lo largo del tiempo y suelen incluir otras variables en sus ecuaciones. Suelen ser el tipo de dato m´as com´un en la mayor´ıa de modelos. Variables de datos. Cambian con el tiempo pero no dependen de otras variables del modelo. Se caracterizan por definir sus ecuaciones con el s´ımbolo :=. Variables de nivel. Variables con un valor inicial establecido, que actualizan su valor a lo largo de la simulaci´on a partir de su valor en la iteraci´on anterior y su ecuaci´on. 3 1.3. INTRODUCCI ´ ON A VENSIM Figura 1.2: Elecci´on de par´ametros para un nuevo modelo. Constantes. Valores est´aticos que no cambian con el tiempo. Sin embargo, es posible modificarlos a medida que avanza la simulaci´on. Constantes inmutables. Valores est´aticos que no cambian con el tiempo y que no pueden cambiarse durante el periodo de simulaci´on. Su asignaci´on es especial puesto que utilizan el s´ımbolo ==. Lookups o tablas. Funciones no lineares definidas a trav´es de par´ametros num´ericos: valores en el eje de abscisas con sus correspondientes valores en el eje de ordenadas. Cada tupla de datos se representa entre corchetes [ ] y el total del lookup se encuentra entre par´entesis. Subscripts. S´ımbolos especiales los cuales tienen definido un rango o un conjunto de valores que pueden tomar. Una variable puede estar asociada a un subscript o a un valor del subscript. En el caso de estar asociada a un subscript, cuando se referencia la variable se referencian todos los valores de dicho subscript. Estos valores suelen estar representados cada uno por su propia ecuaci´on o conjunto de ecuaciones. Una variable puede estar relacionada hasta un m´aximo de ocho subscripts. Elemento de un subscript. S´ımbolo asociado a un subscript y es uno de los valores que lo identifican. Reality checks. Ecuaciones l´ogicas que comprueban que una condici´on se cumple. Es comparable en cierto modo a los asertos de los lenguajes de programaci´on convencionales. Macros. Operadores especiales que el usuario puede definir para representar un concepto bien complicado o bien largo o que se repita mucho, y que es sustituido por un nombre que toma el valor de dicha expresi´on en todo el programa. 4 CAP´ ITULO 1. INTRODUCCI ´ ON Figura 1.3: Men´u de opciones de una variable. En la interfaz gr´afica de Vensim, al asociar una ecuaci´on a una variable se despliega el men´u que se muestra en la Figura 1.3, el cual resume muchos de los conceptos explicados en esta secci´on. Cada ecuaci´on tiene ciertos apartados, tal y como se puede apreciar en la Figura 1.3. En primer lugar, se encuentra el nombre de la ecuaci´on, el cual es utilizado para referenciar a la misma. Tras ello, encontramos las unidades en las que se mide la ecuaci´on. Tambi´en podemos definir otros par´ametros como valores m´aximo y m´ınimo as´ı como el alcance de los incrementos. Posteriormente, se encuentra el campo de definici´on de la ecuaci´on, donde se describe la f´ormula de la misma. En el caso de las tablas o lookups se utiliza tambi´en para introducir los valores por pares de la misma. Finalmente, se encuentra el campo de comentario, el cual no afecta a la ecuaci´on como tal, pero puede servir para clarificar el prop´osito de la misma u otros aspectos, como un mecanismo de autodocumentaci´on. 5 1.7. INTRODUCCI ´ ON A SEMANTICMERGE 1.7. Introducci´on a SemanticMerge SemanticMerge es una herramienta desarrollada por la empresa C´odice Software, se puede utilizar como herramienta independiente (standalone) o integrada en PlasticSCM o gMaster, como se ha visto en las dos secciones anteriores. Esta herramienta destaca por la gran facilidad que aporta al usuario para fusionar archivos o realizar merges que en un principio pudieran resultar muy complicados de resolver manualmente o mediante la ayuda de una herramienta de control de versiones basada en texto. Esta herramienta se diferencia del resto porque no intenta tratar bloques de texto planos, sino que intenta comprender la estructura del lenguaje para simplificar la tarea. Esto lo consigue a˜nadiendo informaci´on sem´antica sobre el lenguaje en el que est´a escrito el archivo, mediante un parser que analiza la gram´atica del lenguaje de los archivos y obtiene una representaci´on intermedia de los mismos. Figura 1.11: Interfaz gr´afica de SemanticMerge. Tomada de [45] El proceso por el cual los archivos se comparan viene dado por dos herramientas que la empresa desarroll´o anteriormente a SemanticMerge:XDiff yXMerge [46]. La primera de las herramientas, XDiff, es capaz de comprobar si un fragmento de c´odigo dentro de un archivo ha sido desplazado mediante un algoritmo que comprueba qu´e partes del c´odigo han sido modificadas. Por otro lado, XMerge permite detectar el c´odigo que partiendo de un archivo inicial, ha sido modificado paralelamente por dos desarrolladores diferentes, con un algoritmo similar al anterior. Esto incluye tambi´en movimientos de c´odigo. La uni´on de estas herramientas proporciona una metodolog´ıa de trabajo al estilo “Divide y vencer´as”, mediante el cual se intentan abordar los conflictos separ´andolos en m´odulos. Por ejemplo, pongamos que partiendo de un archivo base, dos desarrolladores modifican 12 CAP´ ITULO 1. INTRODUCCI ´ ON Figura 1.12: Significado de las letras en SemanticMerge. Tomado de [43] un m´etodo. El primer desarrollador mueve el m´etodo de sitio desplaz´andolo l´ıneas arriba. Por su parte, el segundo desarrollador desplaza el m´etodo l´ıneas abajo y adem´as lo modifica. Apoy´andose en las dos herramientas, SemanticMerge resuelve primero el problema del desplazamiento, tambi´en llamado “movimiento divergente” o “divergent move”. Para ello, comprueba la estructura de los dos ficheros y localiza el m´etodo en ambos. Tras ello, realiza el primer “sub-merge” entre los dos archivos. Una vez solucionado ese problema, comprueba que uno de los dos m´etodos ha sido modificado, resuelve el conflicto y realiza un segundo “sub-merge”, resolviendo completamente el conflicto [44, 45]. El funcionamiento correcto de este proceso se debe a que SemanticMerge utiliza un m´etodo de merge de tres partes o three-way merge [41]. Esto consiste, como se muestra en la Figura 1.11, en que, adem´as de utilizar los dos archivos a comparar en el merge, se utiliza un archivo inicial com´un a los dos otros archivos (source ydestination) para ser capaz de entender c´omo se ha llegado a ciertas situaciones. Por ejemplo, asegurarse de si una l´ınea ha sido incluida por un programador, o por el contrario si ya estaba y ha sido borrada por otro. La interfaz gr´afica de la aplicaci´on nos muestra los cambios ocurridos en los archivos respecto al original o base de forma simple en un men´u, utilizando la izquierda para el archivo source y la derecha para el archivo destination. De izquierda a derecha en la parte superior de la figura podemos ver tres paneles. El panel azul representa el fichero fuente o source, con una serie de cambios respecto al fichero del que se parte, el cual est´a representado en color verde en la parte derecha, destination. En color amarillo en medio se encuentra un fichero base, del cual han partido ambos ficheros. Este merge con tres archivos [41] utilizando un archivo ancestro de los archivos source y destination ayuda al usuario a elegir correctamente las partes que quiere conservar a la hora de resolver un conflicto. Por ejemplo, si s´olo se utilizasen los archivos source ydestination y se encontrase una l´ınea que s´olo aparece en uno de los dos archivos, podr´ıa generar problemas pensando si hay 13 1.7. INTRODUCCI ´ ON A SEMANTICMERGE que mantener dicha l´ınea o no. Al utilizar un archivo base ancestro com´un a los dos, se puede ver claramente si dicha l´ınea exist´ıa anteriormente y el problema desaparece. En la parte inferior de la figura se muestra el fichero final, tras haber aplicado los cambios ocurridos en los ficheros source ydestination, y por ende, haber realizado correctamente el merge. En el caso de que cualquiera de los tres archivos no pueda ser parseado correctamente por la aplicaci´on, el merge no podr´a ser realizado. En ese caso, SemanticMerge lanzar´a un mecanismo de fallback donde se informar´a al usuario de los errores que han impedido la correcta ejecuci´on del software [44]. Pese a ello, es posible completar su resoluci´on mediante la herramienta b´asica de texto plano. En SemanticMerge se definen cinco tipos de cambios: modificaci´on, adici´on, desplazamiento, renombrado y borrado. Estos tipos de modificaciones se muestran mediante marcas con unas letras y colores en la interfaz gr´afica tal y como puede verse en la Figura 1.11. En la Figura 1.12 se muestra un resumen de los colores y letras utilizados para marcar cada tipo de modificaci´on. SemanticMerge permite visualizar los cambios de tres maneras diferentes. La primera ser´ıa una manera en formato textual, al igual que lo hacen las herramientas tradicionales de control de versiones, ver Figura 1.13. La segunda forma incluye las caracter´ısticas que hacen especial a la herramienta, y es que a trav´es de un an´alisis al archivo, expone adem´as sus diferencias sem´anticas, ver Figura 1.14. La tercera forma utiliza la herramienta de diferenciaci´on sem´antica tambi´en, pero en vez de utilizar texto, utiliza una versi´on mucho m´as gr´afica donde relaciona los cambios, Figura 1.15. 14 CAP´ ITULO 1. INTRODUCCI ´ ON Figura 1.13: Diferenciaci´on textual entre archivos de SemanticMerge Figura 1.14: Diferenciaci´on sem´antica entre archivos de SemanticMerge 15 1.7. INTRODUCCI ´ ON A SEMANTICMERGE Figura 1.15: Diferenciaci´on visual entre archivos de SemanticMerge Figura 1.16: Diagrama de clases de la estructura de parseo de SemanticMerge. Tomado de [40] 16 CAP´ ITULO 1. INTRODUCCI ´ ON 1.8. Objetivos El objetivo de este proyecto es crear una herramienta externa (plugin) para la herramienta SemanticMerge, y con ello ser capaz de realizar comparaciones, encontrar diferencias entre archivos .mdl de Vensim y ser capaz de fusionarlos en un ´unico fichero (operaciones conocidas en la terminolog´ıa del control de versiones como diff and merge). Dicha herramienta deber´a ser capaz de tratar de forma completa archivos .mdl por lo que se definen los siguientes subobjetivos: construir una gram´atica capaz de reconocer y manejar archivos .mdl complejos con m´ultiples vistas y/o componentes gr´aficos. Dicha gram´atica ser´a utilizada para leer los archivos a procesar y en el proceso, analizar la estructura y la sem´antica del mismo, con el fin de identificar cada una de las partes del archivo, proporcionando a los usuarios una mayor claridad sobre los cambios realizados entre dos versiones de un mismo archivo Vensim. desarrollar dos herramientas de apoyo al plugin cuyo objetivo ser´a modificar los archivos Vensim a ser comparados para que su sem´antica sea reconocida con mayor facilidad a la hora de utilizar la herramienta, a˜nadiendo partes adicionales que aportan m´as informaci´on sem´antica; y tras realizar la comparaci´on/fusi´on con ´exito, eliminar dichas partes para obtener un archivo .mdl con el estilo habitual. 1.9. Estructura de la memoria Este documento se estructura de la siguiente forma: Cap´ıtulo 2 Requisitos y planificaci´on: Se describe la adaptaci´on del marco de trabajo ´agil SCRUM al contexto de este proyecto. Se definen los backlogs inicial y final as´ı como la planificaci´on de este trabajo y sus riesgos asociados. Por ´ultimo, incluye los presupuestos asociados al mismo. Cap´ıtulo 3 An´alisis: Describe el proceso seguido en el planteamiento de los distintos problemas de los que consta este trabajo, as´ı como explica distintos conceptos te´oricos asociados al mismo. Cap´ıtulo 4 Tecnolog´ıas utilizadas: Describe las tecnolog´ıas utilizadas, tanto para la gesti´on del proyecto como para el desarrollo del mismo. Cap´ıtulo 5 Dise˜no: Describe el dise˜no de la soluci´on basado en el an´alisis del proyecto. Incluye referencias al c´odigo realizado. Cap´ıtulo 6 Implementaci´on y pruebas: Describe el proceso de testing que ha sufrido el proyecto. Cap´ıtulo 7 Seguimiento del proyecto: Describe el desarrollo del proyecto, dividido en sprints de dos semanas siguiendo un desarrollo ´agil basado en una adaptaci´on de SCRUM. 17 1.9. ESTRUCTURA DE LA MEMORIA Cap´ıtulo 8 Conclusiones: Anexo A Manuales: Incluye manuales de mantenimiento, de instalaci´on, despliegue, y de uso. Anexo B Resumen de enlaces adicionales: Incluye enlaces de inter´es sobre el proyecto, como el repositorio de c´odigo ... 18 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON Cap´ıtulo 2 Requisitos y Planificaci´on 2.1. SCRUM y su adaptaci´on al proyecto Este proyecto se ha realizado mediante un desarrollo ´agil basado en una adaptaci´on de SCRUM [22]. SCRUM tiene la caracter´ıstica de poder dividir todo el trabajo en peque˜nos fragmentos denominados sprints, lo que permite reaccionar r´apidamente a los cambios que puedan ir surgiendo en el proyecto. Esto result´o id´oneo puesto que al principio del proyecto exist´ıa un cierto grado de incertidumbre acerca de ciertos aspectos del desarrollo del mismo. 2.1.1. Roles en SCRUM Product Owner. Este rol tiene como papel velar por la calidad del producto. Tiene consciencia de los requisitos y suele actuar como representante del cliente, realizando cambios y tomando decisiones que marcan el rumbo del producto final. SCRUM Master. Este rol es el encargado de gestionar todo el proceso de trabajo, gestionar los incrementos y las reuniones y agilizar al equipo de desarrollo para impedir bloqueos y aumentar la productividad. Equipo de desarrollo. Este rol puede estar formado por varias personas, y se encarga del desarrollo como tal del producto. 2.1.2. Artefactos Existen una serie de documentos o registros de trabajo de notoria importancia dentro de un proyecto SCRUM. 19 2.2. SCRUM ADAPTADO AL PROYECTO Product Backlog. Este documento contiene la lista de requisitos del cliente. Pese a que exista una versi´on inicial, esta puede evolucionar a lo largo del desarrollo del proyecto. Sprint Backlog. Este documento contiene las tareas a realizar durante un sprint o iteraci´on del proyecto. Incremento. Este documento contiene el trabajo real realizado al final de un sprint o iteraci´on. 2.1.3. Eventos Una de las caracter´ısticas de SCRUM es el constante control y revisiones sobre el trabajo realizado, tanto para comprobar la calidad del trabajo como para estar preparados para cambios en los requisitos [12]. Estas reuniones tambi´en tienen como objetivo facilitar la comunicaci´on entre equipos de desarrollo, pero al estar este proyecto realizado por una persona, no se toma en cuenta dicha caracter´ıstica. Los eventos suelen tener una duraci´on similar en cada una de las repeticiones y tienen una fecha y una frecuencia determinadas al inicio del proyecto. Sprint. Tambi´en llamado iteraci´on, es un periodo entre una y cuatro semanas en el que se desarrolla una parte del proyecto. Sprint Planning. Esta reuni´on tiene lugar al inicio del sprint y tiene como objetivo fijar las tareas que se deben realizar en dicha iteraci´on. Daily SCRUM. Esta reuni´on es de car´acter breve, entre quince y treinta minutos, y se realiza diariamente para sincronizar a los miembros de un mismo equipo de trabajo. Sprint Review. Esta reuni´on tiene lugar al final del sprint y tiene como objetivo revisar el trabajo realizado durante la iteraci´on. El feedback obtenido en estas reuniones puede llegar a afectar al Product Backlog. Sprint Retrospective. Esta reuni´on se realiza entre sprints, por lo que se realiza despu´es del Sprint Review de la iteraci´on N pero antes del Sprint Planning de la iteraci´on N+1. En este acto se debaten que aspectos han ido bien y cuales mal en el sprint, con el fin de realizar un mejor trabajo en la siguiente iteraci´on. 2.2. SCRUM adaptado al proyecto Habiendo explicado los distintos aspectos caracter´ısticos de SCRUM, se exponen ahora las adaptaciones a este proyecto. En el caso de los roles, la tutora del proyecto actuar´a tanto como Product Owner, haciendo de intermediario con los desarrolladores del proyecto LOCOMOTION H2020; como de SCRUM 20 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON Master, estableciendo las tareas a realizar en cada iteraci´on. El alumno toma el papel de equipo de desarrollo. En el caso de los sprints, se estableci´o que tendr´ıan una duraci´on de dos semanas. Se tendr´ıan reuniones semanales establecidas los lunes a las 11:00. Estas reuniones actuar´ıan como Sprint Planning,Sprint Review ySprint Retrospective en las semanas de inicio de sprint; y como Sprint Review en las semanas intermedias. Este horario se mantuvo durante el primer cuatrimestre acad´emico. En el inicio del segundo cuatrimestre, por motivos de compatibilidad de pr´acticas laborales del alumno, se modific´o el horario de reuniones a los martes a las 18:30. El Product Backlog Inicial se obtuvo a trav´es de un primer an´alisis de las tareas a realizar al comienzo del desarrollo del proyecto. Tanto las historias de usuario como el Product Backlog Final se confeccionaron a medida que el proyecto fue desarroll´andose y las tareas a realizar tomaban una forma cada vez m´as s´olida. 2.3. P´ublico objetivo del proyecto Pese a la complejidad inicial que este trabajo puede transmitir, el p´ublico al que va dirigida esta soluci´on es un p´ublico que si bien trabaja con ordenadores en su d´ıa a d´ıa, no tiene un conocimiento muy extenso en el ´ambito de la inform´atica en general, y menos a´un si se compara con un Ingeniero Inform´atico. Los principales usuarios que har´an uso de las herramientas desarrolladas son modeladores del proyecto LOCOMOTION H2020, que utilizan Vensim para programar los modelos utilizados para simular situaciones del planeta bajo varios par´ametros concretos. Dichos modelos suelen ser muy complejos, llegando a tener decenas de vistas, cada una poblada con multitud de variables y/o gr´aficos. Por ello, a la hora de comprobar los cambios entre versiones de los archivos, los usuarios ten´ıan grandes dificultades para entender las diferencias, puesto que los archivos Vensim en formato textual presentan una sintaxis complicada, especialmente en la definici´on de las vistas. Por estos motivos, el desarrollo del proyecto enfoc´o su parte visual como su facilidad de uso en usuarios no familiarizados con el desarrollo de software. Tambi´en se intent´o en la medida de lo posible, facilitar la comprensi´on de los archivos Vensim en su formato textual. Por ello, se tomaron decisiones como modificar el archivo para incluir el nombre de la vista a la que una ecuaci´on pertenece en el comentario de la misma, o utilizar par´ametros num´ericos de las variables para indicar su tipo, por ejemplo, distinguiendo entre variables convencionales o variables sombra (shadow variables). Las interfaces para modificar los archivos con el fin de facilitar la captura del valor sem´antico de los mismos se deben realizar de forma sencilla y con pocas opciones, con el fin de disminuir al m´ınimo la posibilidad de error. Estas interfaces de usuario, as´ı como el funcionamiento del proyecto deben quedar explicados de una manera compresible para usuarios noveles en ´ambitos de la inform´atica en los anexos de Manuales de Usuario. 21 2.8. PRESUPUESTO SIMULADO Riesgo 5 Modificaciones en la forma de interaccionar con SemanticMerge Tipo T´ecnico Probabilidad Muy baja Impacto Medio Descripci´on PlasticSCM podr´ıa actualizar su software y modificar la forma en que se incorporan los parsers externos a la aplicaci´on. Sin embargo, al haber estado siguiendo el mismo m´etodo durante una gran cantidad de a˜nos, lo consideraremos altamente improbable. Mitigaci´on Tratar de mantener flexibles las partes del proyecto, encapsul´andolo en formato JAR. Contingencia En el caso de actualizaci´on de versiones, se deber´ıa hablar con el cliente y determinar si el software debe estar enfocado a la versi´on actual, a la posible versi´on futura o a ambas. En funci´on de la decisi´on, se replantear´ıa la forma de desarrollo del proyecto. Tabla 2.12: Riesgo de modificaciones en la forma de interaccionar con SemanticMerge. Riesgo 6 Pandemia por COVID-19 Tipo Global Probabilidad Alta Impacto Medio Descripci´on Debido a la pandemia global del COVID-19, es posible que el Gobierno apruebe medidas excepcionales como un segundo confinamiento, lo cual obligar´ıa a replantear los m´etodos de trabajo. Mitigaci´on Preparar entornos de trabajo online alternativos. Contingencia Reorganizar las reuniones a un modo no presencial y reorganizar la carga de trabajo y la planificaci´on, pues en caso de confinamiento, es posible que la carga de trabajo de las asignaturas del cuatrimestre suba. Tabla 2.13: Riesgo de COVID-19. 2.8. Presupuesto simulado Consultando el Bolet´ın Oficial del Estado [33], en 2019 se estipul´o que el sueldo medio de un programador junior a 1 de noviembre de 2020 ser´ıa de 16539,38 eanuales trabajando 1800 horas al a˜no. Las empresas deben pagan a la Seguridad Social aproximadamente un 30 % del sueldo base del trabajador [24], por lo que el coste real para la empresa ser´ıa de 21501,2 e. Estimando el proyecto como unas pr´acticas de empresa, donde se emplean 300 horas, el presupuesto simulado ser´ıa de 3583,53 e. Adem´as, para este proyecto se requieren las herramientas de la empresa PlasticSCMl, concretamente gMaster ySemanticMerge. El coste mensual de la licencia de esta ´ultima es de 6,9$ (5,93 e) [36], y asumiendo que el proyecto se completar´ıa en los seis meses estipulados, el coste de la licencia constar´ıa de 35,58 e. El resto de software como Vensim o herramientas 28 CAP´ ITULO 2. REQUISITOS Y PLANIFICACI ´ ON para el desarrollo son gratuitas o se utiliza su versi´on gratuita. El proyecto se realizar´a desde la residencia personal del alumno y la Universidad, por lo que no se incluir´an costes de alquiler y similares, Tabla 2.14. Sueldo base 2756,56 e Seguridad social 826,97 e Licencia de SemanticMerge 35,58 e Total 3619,11 e Tabla 2.14: Presupuesto simulado. 29 2.8. PRESUPUESTO SIMULADO 30 CAP´ ITULO 3. AN ´ ALISIS Cap´ıtulo 3 An´alisis 3.1. An´alisis de la gram´atica de Vensim Este proyecto parte de una gram´atica inicial en ANTLR4 desarrollada por Daniel Bazaco [5], antiguo alumno del Grado en Ingenier´ıa Inform´atica en la Universidad de Valladolid y que con su Trabajo de Fin de Grado colabor´o tambi´en con en la finalizaci´on del proyecto MEDEAS y el inicio del proyecto LOCOMOTION. 3.1.1. Introducci´on a ANTLR4 ANTLR4 (ANother Tool for Language Recognition) es una herramienta capaz de generar reconocedores de texto o parsers muy potentes que permiten trabajar con archivos estructurados proporcionando una gram´atica que lo represente. Actualmente se encuentra en su cuarta versi´on, tal y como se indica en el nombre. ANTLR4 es capaz de trabajar con dos tipos de estructuras, bien con listeners o bien con visitors. A grandes rasgos podemos diferenciarlos en que los m´etodos listeners son llamados autom´aticamente por ANTLR mientras que los m´etodos visitors son invocados expl´ıcitamente. Adem´as, los listeners no pueden retornar valores y se deben utilizar variables externas para recuperar los valores necesarios, mientras que los visitors s´ı que son capaces de retornar valores. Por ´ultimo, los listeners utilizan un espacio reservado de memoria en el heap mientras que los listeners utilizan llamadas a la pila o stack [50]. Por todo el control que permiten, en este proyecto se utilizan visitors. ANTLR4 se compone de dos mecanismos principales: el lexer y el parser. El lexer es el encargado de framentar el archivo a tratar en prque˜nas etiquetas o tokens y el parser es el encargado de construir el ´arbol sint´actico a partir de dichos tokens.ANTLR4 construye el ´arbol de arriba a abajo (top-down) utilizando un mecanismo recursivo descendente y una gram´atica LL, por lo que no necesita utilizar backtracking. 31 3.1. AN ´ ALISIS DE LA GRAM ´ ATICA DE VENSIM Las reglas del parser se encuentran al principio del archivo ANTLR4 (con extensi´on .g4) y comienzan con letra min´uscula. Estas reglas son las encargadas de formar el ´arbol sint´actico. Las reglas del lexer se encuentran posteriormente a las del parser y deben comenzar con letra may´uscula. Estas reglas transforman el texto de entrada en tokens con los que construir el ´arbol. En el caso de que un predicado coincida con varias reglas, siempre tomar´a prioridad la regla con mayor similitud de coincidencia. Es decir, si la palabra text tiene coincidencias con dos reglas, una que toma todas las letras como expresi´on regular ([a-zA-Z]) y otra que directamente utiliza la palabra text, el ´arbol se construir´a con la segunda regla. En el caso de existir dos reglas con la m´axima coincidencia para un valor de entrada, tomar´a prioridad la regla que est´e declarada antes en el archivo .g4 [8]. 3.1.2. Gram´atica inicial de partida La gram´atica de partida trataba exclusivamente las definiciones de ecuaciones y estaba pensada para modelos con una ´unica vista. Pese a ello, la gram´atica puede resultar compleja en un inicio y a continuaci´on se explican los pilares fundamentales de la misma: Un fichero se subdivide inicialmente en dos partes, el contenido del fichero y el caracter End Of File (< EOF >), que indica cuando acaba el fichero y por tanto cuando acaba el ´arbol. A su vez, la parte del modelo se subdivide en una sucesi´on indeterminada de definiciones de s´ımbolos o de macros del archivo. Posteriormente se define la parte de sketches, la cual ha sido ampliada en este proyecto y se explicar´a m´as adelante. En la gram´atica inicial, la parte de sketches se limitaba a capturar la primera l´ınea que declaraba que comenzaba la definici´on de las vistas y los gr´aficos en el fichero .mdl. Por su parte los s´ımbolos se dividen en definiciones de s´ımbolos y comentarios y unidades asociados al s´ımbolo. En la definici´on de s´ımbolos encontramos todos los tipos b´asicos explicados en la secci´on de “Introducci´on a ANTLR4”, en el cap´ıtulo de “Introducci´on”. Dichos tipos son: lookup,subscript, ecuaci´on, constante, constante no modificable, ecuaci´on de datos, string o cadena de caracteres, copia de subscript yreality check. Cada uno de estos tipos de datos tiene su propia estructura definida, apoy´andose en ocasiones en m´as reglas. La gram´atica omite los comentarios o las definiciones de codificaci´on, caracterizadas por estar ambos descritos entre llaves “{ }”; as´ı como las l´ıneas de asteriscos utilizadas para separar secciones del documento .mdl. Tambi´en se ignoran los backslash (\), utilizados para indicar saltos de l´ınea dentro de los metadatos de los s´ımbolos; as´ı como cualquier tipo de espacio en blanco, v´ease espacios, tabulaciones o saltos de l´ınea. Las reglas de generaci´on de tokens del lexer se componen de un conjunto de definiciones de operadores y un conjunto de definiciones de tipos b´asicos, tales como identificadores (“Id”), constantes de tipos b´asicos o definiciones de tipos num´ericos, como n´umeros enteros, reales o racionales. Estas definiciones en su mayor´ıa de casos se realizan a trav´es de fragmentos o fragments, peque˜nas reglas que s´olo pueden ser utilizadas para definir otras reglas del lexer y que tienen como objetivo clarificar la gram´atica, como por ejemplo, la definici´on del conjunto de d´ıgitos: [0 −9]. 32 CAP´ ITULO 3. AN ´ ALISIS 3.1.3. Ampliaci´on de la gram´atica I Como se ha explicado anteriormente, la gram´atica inicial no trataba las definiciones de m´ultiples vistas y los gr´aficos que se pueden definir. Se expandi´o la parte de sketches de la gram´atica inicial tal y como se explica a continuaci´on [29]: Primeramente, se ampli´o la regla de definici´on del modelo, a˜nadiendo a los sketches el delimitador de la secci´on de gr´aficos, los gr´aficos y la secci´on de metadatos del fichero. En un fichero Vensim pueden existir varias vistas, pero todas ellas siguen la misma estructura. Las vistas comienzan con dos l´ıneas de texto, la primera anuncia que a continuaci´on se muestran los datos del sketch y la segunda muestra el c´odigo de versi´on, el cual en las versiones 3, 4 y 5 ser´a siempre el 300 (V300) [53]. Tras ello, la siguiente l´ınea contendr´a el nombre de la vista. Las siguientes l´ıneas contendr´an toda la informaci´on asociada a la vista. La primera l´ınea, distinguible pues empieza por ’$’, indica la configuraci´on de fuente y color de la vista, indicando el tama˜no de letra y color, las caracter´ısticas de las flechas y el fondo entre otros. Las siguientes l´ıneas definen variables, y pueden pertenecer a uno de los siguientes tipos: •Objetos. Es el tipo m´as com´un de variable, y tienen un n´umero indeterminado de campos. Representan variables, valves, comentarios, mapas de bits o metaarchivos, con los identificadores 10, 11, 12, 30 y 31 respectivamente. •Flechas o arrows. Representan las flechas o relaciones entre las variables del modelo. Se caracterizan por tener un campo final compuesto por un n´umero que representa el n´umero de puntos de la flecha, seguido de las coordenadas de dichos puntos por donde pasa la flecha y permite ser trazada. Los campos de las flechas no incluyen texto, son s´olo num´ericos. •Variables sombra o shadow variables. Variables que no est´an definidas en la propia vista, sino en otro lugar y por ello no pueden depender de otras variables, aunque otras variables pueden depender de ellas. Un ejemplo ser´ıa el tiempo. •Variables de texto. Variables objeto cuyo formato ha sido modificado, es decir, se ha alterado su color, fuente o tama˜no entre otros. El delimitador de la secci´on de gr´aficos es una l´ınea de texto con el formato “/// −−− \\\”, pero debido a que los backslash se omiten en la gram´atica, se utiliza ´unicamente “/// − −−”. La secci´on de gr´aficos es un tanto ambigua, puesto que al poder el usuario definir los campos que el quiere, la gran mayor´ıa de campos son opcionales en la gram´atica. Sin embargo, todos los gr´aficos comenzar´an con el campo “:GRAPH” que contendr´a el identificador del gr´afico; y el campo “:TITLE”, que contendr´a el nombre del gr´afico. Todos los apartados del gr´afico estar´an en may´usculas y precedidos por ’:’. Finalmente, la secci´on de metadatos contiene datos generales del archivo, tales como variables, unidades escogidas en la creaci´on del fichero u otros. Los metadatos se caracterizan por empezar con una l´ınea con el siguiente texto: “: L < %∧E!@”. Cada l´ınea en la secci´on de metadatos se caracteriza por utilizar primeramente un n´umero, seguidamente el s´ımbolo ’:’ y posteriormente un campo indeterminado que puede ser num´erico, cadena de caracteres o incluso nulo. 33 3.2. PAR ´ AMETROS DE LAS VISTAS 3.1.4. Ampliaci´on de la gram´atica II Tras una reuni´on con el alumno Juan Herruzo, el cual se encontraba realizando tambi´en un Trabajo de Fin de Grado para el proyecto LOCOMOTION H2020 y que tambi´en se le hab´ıa encargado ampliar la gram´atica de Daniel Bazaco, se llegaron a las siguientes conclusiones sobre el procesamiento de las l´ıneas que identifican los campos de cada vista: S´olo existen dos tipos de clasificaciones: flechas o variables. Todas las variables est´an representadas por hasta unos 25 campos, pero no todos son obligatorios. Varios de ellos son los campos de formato, donde en las variables comunes no aparecen, pero si modificamos su tipograf´ıa. color o tama˜no s´ı lo hacen. Sobre las variables sombra, se determin´o que el campo n´umero 9, bits, podr´ıa determinar si una variable es sombra o no. El primer bit de este campo (que hace que el n´umero en notaci´on decimal sea par o impar), define si pueden dirigirse flechas hacia una variable. Como las variables sombra no lo permiten, se determin´o que dicho n´umero ser´ıa par en las variables sombra e impar en variables comunes. Se clarific´o la gram´atica, a˜nadiendo etiquetas para distinguir mejor los campos de las variables y a˜nadiendo nuevas reglas para clarificar dichos campos. Adem´as, se a˜nadi´o la documentaci´on sobre los campos de las variables, expuesta en secciones posteriores. Sobre todo, se matiz´o la parte de la tipograf´ıa de las vistas para poder clasificar mejor las variables. Existen ocasiones donde el tercer campo de una l´ınea de definici´on de variable tiene un 0 en vez de contener el nombre de la variable. En esos casos, el nombre de la variable se indica por separado en la l´ınea siguiente. Se modific´o la gram´atica para a˜nadir la l´ınea separada a la anterior en vez de tratarlas como dos l´ıneas por separado. 3.1.5. Diferencias entre gram´atica inicial y final Las diferencias entre las dos gram´aticas pueden ser apreciadas con mayor detalle en: 3.2. Par´ametros de las vistas En los archivos .mdl de Vensim, en la parte donde quedan definidas las vistas, podemos observar una gran cantidad de l´ıneas de n´umeros, las cuales hay que diferenciar, saber qu´e significa cada par´ametro y conocer qu´e par´ametros son triviales y cuales no para a la hora de realizar un merge que genere conflictos graves, poder tomar las decisiones de conservar y eliminar con facilidad. Este apartado queda explicado con profundidad en el anexo de Manuales de Usuario de la memoria, secci´on A.2.4. 34 CAP´ ITULO 3. AN ´ ALISIS 3.3. Consideraciones sobre la eliminaci´on e inserci´on de variables Un problema planteado en el desarrollo del proyecto es el c´omo controlar las variables sombras. Las variables sombra se definen por ser variables que no se definen en la vista, sino en el proyecto en general. Son variables externas de las que pueden salir flechas, pero las flechas no pueden dirigirse hacia ellas [52]. Existen dos tipos de variables sombra, las “puras”, como puede ser el concepto del tiempo; y las “derivadas”, las cuales se crean a partir de las variables definidas. Las variables sombra puras tienen la caracter´ıstica de que no pueden eliminarse del modelo y las derivadas tienen la caracter´ıstica de que son eliminadas si su variable definida de la que procede es borrada. Surge entonces el siguiente problema: si una variable se elimina (arrastrando a otras o no), y posteriormente se procede a crear una nueva variable con el mismo nombre que la anterior, ¿c´omo podemos distinguir a trav´es del parser si realmente se ha borrado y creado una nueva variables o si simplemente se ha movido la variable? Esto es posible distinguirlo a trav´es del segundo campo que comparten tanto las flechas como las variables y que se ha explicado en la secci´on anterior, el id, el cual estipula el orden de aparici´on de la variable en la vista. Se exponen a continuaci´on dos posibles casos: La variable no es la ´ultima que se ha incluido a la vista. En este caso, si movi´esemos la variable, sus datos de posici´on y relativos cambiar´ıan, pero su id permanecer´ıa intacto. En el caso de borrar dicha variable y crear una nueva, se crear´ıa una nueva l´ınea al final de los datos de la vista con un nuevo id con el n´umero m´as alto hasta el momento. La variable es la ´ultima que se ha incluido a la vista. En este caso, movi´esemos la variable cambiar´ıan sus coordenadas, pero si borr´asemos la variable y cre´asemos una nueva, el id ser´ıa el mismo en ambas. Sin embargo, este escenario plantea que la creaci´on de la variable es el ´ultimo movimiento que hemos hecho, por lo que ambos mover la variable y borrarla para volverla a crear significar´ıan que de alguna forma el usuario se ha equivocado creando la variable y quiere rectificar su error, por lo que es un caso que podemos no tener en cuenta. 3.4. An´alisis de SemanticMerge y gMaster SemanticMerge no est´a enfocado a un paradigma de programaci´on concreto como podr´ıa ser la orientaci´on a objetos, a pesar de que los primeros lenguajes que la herramienta pudo tratar fueron C#, C++ y Java. El software es realmente efectivo ya que trata a todos los lenguajes por igual, utilizando una estructura de contenedores y nodos, o padres e hijos. Esta estructura es muy comparable al patr´on de dise˜no “Composite” [15], donde los hijos de un padre pueden ser a su vez el tipo del padre, Figura 1.16. Gracias a esto, un lenguaje basado en la orientaci´on al objeto como Java podr´ıa dividirse en clases y m´etodos, mientras que un lenguaje funcional como Scala podr´ıa dividirse en funciones y declaraciones. Esto 35 3.4. AN ´ ALISIS DE SEMANTICMERGE Y GMASTER es mayormente apreciable gracias al diagrama de clases que se muestra en la Figura 1.16, extra´ıdo directamente de la p´agina oficial de SemanticMerge [40]. El proceso interno que sigue SemanticMerge es el siguiente: 1. El archivo que es le´ıdo se fragmenta a trav´es de una gram´atica que represente el formato de dicho archivo. Una vez identificadas sus partes, se genera un archivo YAML 1que especifica d´onde y cuando empieza cada contenedor as´ı como la longitud en caracteres de cada uno de los nodos. 2. Tras generar este archivo, se comprueba tanto que su formato sea correcto, es decir, que se respete el indentado y la sintaxis propios del formato YAML; como que el archivo YAML represente de forma continua el archivo de entrada, esto es, que por ejemplo no pase del car´acter 200 al 300 sin haber le´ıdo todos los caracteres de por medio. 3. Tras esto, se procede a la reconstrucci´on del archivo inicial a trav´es del YAML y se comprueba que coincida con el archivo le´ıdo en primer lugar. En caso de no poder realizar la reconstrucci´on, la aplicaci´on notificar´a al usuario de que no se ha podido reconstruir dicho fichero, y no podr´a utilizarse la funcionalidad aportada por SemanticMerge. 3.4.1. Creaci´on de un parser externo para SemanticMerge Los parsers externos de SemanticMerge siguen la estructura de contenedores y nodos explicada en la secci´on anterior de forma interna, sin embargo, tambi´en se debe respetar una estructura externa a la hora de crear el parser [30]. El programa se debe ejecutar con dos argumentos adicionales. El primero es inmutable y es “shell”, indicando que se quiere seguir ejecutando el programa en la terminal hasta recibir la orden “end”. El segundo es el nombre de un archivo bandera o flag. Este archivo se utiliza para indicar al parser cuando se est´a listo para recibir los ficheros de entrada. Esto se hace escribiendo “READY” en el fichero flag. Borrar dicho fichero no es necesario al lanzar el programa. try (PrintWriter out = new PrintWriter(args[1])) { out.println("READY"); } catch (IOException ex) { ex.printStackTrace(); } Inicialmente y estrictamente en el orden en que se indica, el programa debe pedir al usuario el primer archivo a comparar, la codificaci´on que utiliza (normalmente UTF-8) y un primer archivo de salida donde escribir el archivo YAML asociado al primer archivo. Si se 1¿Qu´e son los archivos YAML? https://www.cloudbees.com/blog/yaml-tutorial-everything-youneed-get-started/ 36 CAP´ ITULO 3. AN ´ ALISIS ha realizado correctamente, el programa imprimir´a por pantalla “OK”, y en caso contrario imprimir´a ”KO”. Estos pasos se repetir´an para el segundo archivo. Tras completar el parseo de los dos ficheros, el programa deber´a escribir ”end” por pantalla. Es muy importante que los ficheros YAML de salida sigan la estructura planteada en la p´agina oficial de SemanticMerge [40] o una similar basada en contenedores y nodos para que se reconozcan dichos archivos correctamente. String firstFile = scanner.nextLine(); String firstEncoding = scanner.nextLine(); String firstFileOutput = scanner.nextLine(); ParseFile(firstFile, firstFileOutput); System.out.println("OK"); Como se puede observar, en este caso no se utiliza la codificaci´on pues se asume que siempre ser´a UTF-8. Sin embargo, es obligatorio pedirla por teclado para que el parser externo sea compatible con SemanticMerge. Finalmente, se debe transformar el programa realizado a un archivo ejecutable (.exe) o alg´un formato similar que sea compatible con las opciones de l´ınea de comandos de SemanticMerge. Por ejemplo, utilizando el lenguaje Java, el cual se utilizar´a en este proyecto, es posible comprimir el proyecto en un archivo JAR, el cual es compatible con SemanticMerge. .\semanticmergetool.exe --source=test1.code --destination=test2.code --externalparser="-jar mvnparser-1.0-jar-with-dependencies.jar" --virtualmachine="C:\Program Files\Java\jdk-11.0.8\bin\java.exe" En este caso, test1.code ytest2.code ser´ıan los archivos iniciales a comparar. Posteriormente se procesar´an y se generar´a un fichero YAML por cada archivo, cada cual conteniendo la estructura en ´arbol de su respectivo archivo inicial. 3.4.2. A˜nadir parsers externos a gMaster Para poder utilizar parsers externos en la herramienta gMaster debemos seguir un proceso muy sencillo [27]. Debemos situarnos en la carpeta config del directorio donde se encuentra ubicado gMaster y crear un archivo (si no ha sido creado ya) llamado externalparsers.conf. En este archivo debemos indicar para cada extensi´on de archivo que queramos procesar, la ubicaci´on del parser externo en nuestro equipo. Para ello deberemos escribir su ruta absoluta, y se recomienda escribirla con los directorios comunes a todas las m´aquinas en ingl´es, pues produce menos problemas a la hora de detectar la ruta. Esto es, utilizar Users oDesktop en lugar de Usuarios oEscritorio. Tras ello, deberemos de reiniciar gMaster si estaba abierta previamente, y con ello, la herramienta detectar´a autom´aticamente el nuevo formato. En el caso de este proyecto, el fichero externalparsers.conf tiene el siguiente aspecto: 37 4.2. TECNOLOG´ IAS PARA EL DESARROLLO 4.2.7. JUnit 5 Jupiter JUnit 5, versi´on tambi´en conocida como Jupiter [51], es un framework para el realizado de tests para Java, el cual tiene integraci´on con Maven. Se utiliz´o para comprobar la validez del software creado. 4.2.8. Astah Professional Astah Professional [23] es la versi´on profesional de una herramienta utilizado para el modelado y el dise˜no de software aplicando el lenguaje UML [20], el cual es un lenguaje universal para el desarrollo de diagramas para la ingenier´ıa del software. 44 CAP´ ITULO 5. DISE ˜ NO Cap´ıtulo 5 Dise˜no Tras analizar el alcance del programa se decidi´o dividir la estructura en tres herramientas. La primera de todas ser´ıa el parser en s´ı, programa principal del proyecto encargado de procesar los archivos Vensim. Las otras dos herramientas consisten en dos modificadores de archivos de texto. La primera herramienta tiene la funci´on de a˜nadir tanto los nombres de las vistas en las ecuaciones como ciertos delimitadores que ayudan a procesar la sem´antica de los archivos. La segunda herramienta tendr´ıa el efecto contrario, eliminando del archivo tanto los nombres de las vistas como los delimitadores. Mientras que a˜nadir los nombres de las vistas tiene una funci´on de apoyo para los modeladores para ayudarles a entender mejor los archivos .mdl en su formato textual,los delimitadores son una herramienta para ayudar a transformar el archivo de partida en un archivo YAML con mucha menor dificultad. 5.1. Automatizaci´on de la inserci´on de los nombres de las vistas en los comentarios de las ecuaciones. Inicialmente, se dividi´o esta tarea en tres partes debido a su potencial complejidad. Este proceso puede ser visto como una fragmentaci´on del archivo a leer para obtener las partes clave, en este caso vistas y ecuaciones, para posteriormente volver a montar su estructura inicial. Se destacan a continuaci´on las siguientes subsecciones: 5.1.1. Localizaci´on de las vistas. Para obtener los nombres de las vistas, en primer lugar se divide el archivo en dos secciones claramente diferenciadas: la parte de definici´on de ecuaciones y la parte con los datos de las vistas. Esta segunda parte se subdivide a su vez, dejando atr´as la informaci´on referida a los gr´aficos y a los metadatos. Tras esto, mediante la funci´on split() se obtiene un array con 45 5.1. AUTOMATIZACI ´ ON DE LA INSERCI ´ ON DE LOS NOMBRES DE LAS VISTAS EN LOS COMENTARIOS DE LAS ECUACIONES. los conjuntos de datos de cada vista. Esto es posible debido a que cada vista se separa por los s´ımbolos \\\ − − − ///. Tras hacer esta separaci´on, se obtiene el nombre de la vista a partir de la tercera l´ınea de la separaci´on anterior (se separan seg´un los saltos de l´ınea) y se a˜nade a un set. Tras esto, se leen el resto de l´ıneas que definen la lista, a˜nadiendo el tercer campo de la l´ınea separada por comas, o el primer campo en caso de que la l´ınea est´e definida por un ´unico valor. Todos estos valores son a˜nadidos a un segundo set, que a su vez es a˜nadido a un set que contendr´a todos los sets de valores de cada vista. De esta forma, habr´a dos sets paralelos, uno proporcionar´a el nombre de la vista, y el otro proporcionar´a todos los nombres de variables de dicha vista. Esto puede ser apreciado en el siguiente fragmento de c´odigo, el cual corresponde a la funci´on destinada a crear dichos sets: private static Set<String> crearSets(String views) { String[] lines = views.split("\n"); Set<String> set = new HashSet<String>(); for (int i = 4; i < lines.length; i++) { String[] positions = lines[i].split(","); if (positions.length > 2) { set.add(positions[2]); } else { set.add(positions[0]); } } return set; } 5.1.2. Modificaci´on del comentario de la ecuaci´on. Aprovechando la separaci´on realizada en el apartado anterior, tomamos la parte del fichero que contiene la declaraci´on de ecuaciones. A su vez, la dividimos en ecuaciones declaradas expl´ıcitamente y en ecuaciones declaradas por Vensim que representan la configuraci´on del archivo, como INITIAL TIME oTIME STEP. Cada ecuaci´on termina en un s´ımbolo |, por lo que fue f´acil dividirlas. Para identificar la vista a la que pertenece la ecuaci´on, se toma la primera l´ınea de cada ecuaci´on, qued´andose s´olo con la cadena de caracteres hasta llegar a el s´ımbolo ’=’. Existen ecuaciones que pueden estar definidas por par´ametros de entrada u otros argumentos, por lo que tras ello se eliminan todos los caracteres que vayan seguidos de un par´entesis ’(’ o un corchete de apertura ’[’, eliminando estos s´ımbolos inclusive. 46 CAP´ ITULO 5. DISE ˜ NO 5.1.3. Uni´on de las partes divididas. Tras esto, se compara la cadena obtenida por todos los sets de nombres de variables. Si se encuentra una coincidencia, se elimina dicha variable del set para evitar duplicaciones y se toma el ´ındice del set de nombres de variables dentro del conjunto de sets. Con ese ´ındice podemos obtener el nombre de la vista a trav´es del set de sombres de vistas. Obtenido ese nombre, se pasa a escribir tras el segundo s´ımbolo ’∼’ en la ecuaci´on, el cual precede al apartado de comentarios de la variable. Para diferenciar el nombre de la vista con el posible comentario que existiese con anterioridad, se precede al nombre de la vista con <[VIEW]>: y el comentario anterior con <[DESCRIPTION]>:. En el caso de ser un archivo ya procesado, se obviar´ıa la inserci´on de dichos diferenciadores, actualiz´andose simplemente el nombre de la vista. Tras este proceso, se vuelven a juntar las partes del fichero fragmentado, quedando como resultado el fichero original con los nombres de las vistas a˜nadidas en los comentarios de las variables. En el siguiente fragmento de c´odigo se puede observar la funci´on encargada de diferenciar si el archivo ha sido procesado previamente y en caso contrario, introducir el delimitador <[VIEW]>:. private static String modify(String equation, String viewName) { int position = StringUtils.ordinalIndexOf(equation, "~", 2); String appendix = viewName.trim(); if (equation.indexOf("<[VIEW]>:") == -1) { appendix = "<[VIEW]>: " + appendix; return insertString(equation, appendix, position); } else { return updateViewName(equation, appendix, position); } } 47 5.1. AUTOMATIZACI ´ ON DE LA INSERCI ´ ON DE LOS NOMBRES DE LAS VISTAS EN LOS COMENTARIOS DE LAS ECUACIONES. 5.1.4. Diagrama de actividad. A continuaci´on, se muestra un diagrama de actividad que trata de explicar el proceso que sigue la primera herramienta a la hora de introducir los nombres de las vistas en las ecuaciones, Figura 5.1. Figura 5.1: Diagrama de actividad asociado al programa 48 CAP´ ITULO 5. DISE ˜ NO 5.2. Desarrollo del primer parser externo a partir de la gram´atica de partida. Debido a la posible complejidad inicial, se decidi´o que inicialmente se realizar´ıa un primer parser b´asico que s´olo incluyese las partes definidas en la gram´atica de partida, es decir, las definiciones de ecuaciones. La estructura del ´arbol YAML se dividir´ıa en dos principales, equations ygraphs, conteniendo equations la definici´on de las ecuaciones, lookups,subscript ranges y dem´as elementos; ygraphs el resto del fichero, que ser´ıa definido en posteriores sprints. En el caso del apartado de ecuaciones, se utilizar´ıa como cabecera siempre la primera l´ınea del archivo, dedicada a la definici´on de la codificaci´on del texto, siendo en la mayor´ıa de archivos, por no decir en todos, UTF-8 (tras hablar con los desarrolladores de LOCOMOTION H2020, se confirm´o que todos los archivos del proyecto utilizar´ıan esta cabecera). El footer de este apartado siempre ser´an los dos ´ultimos caracteres de salto de l´ınea de la ecuaci´on TIME STEP, la cual est´a presente siempre en los archivos al ser una ecuaci´on que define los par´ametros del propio archivo Vensim y no del modelo (esto de nuevo se confirm´o con los desarrolladores del proyecto). En el caso de las ecuaciones, simplemente se van a˜nadiendo el n´umero de l´ıneas y de caracteres a variables globales para seguir la cuenta, pero se han de destacar dos cosas. La primera, es que normalmente la ´ultima l´ınea de cada ecuaci´on es un salto de l´ınea compuesto por dos caracteres, \r y \n. Sin embargo, existen casos en que esto no es as´ı, por lo que se comprueba para cada ecuaci´on esta posibilidad y mantener correctamente la cuenta de n´umero de l´ıneas y de caracteres. La segunda es que existen dos clases de ecuaciones, las definidas para las diferentes vistas y las propias del fichero. Estas suelen ser cuatro en los archivos m´as simples, FINAL TIME,INITIAL TIME,SAVEPER yTIME STEP, aunque en archivos de gran tama˜no existen gran cantidad de ecuaciones de este tipo, algunas definidas por el usuario y/o por subscripts. Estas variables est´an separadas del resto por dos l´ıneas de asteriscos, que a trav´es de la herramienta de charposition [28] se ha comprobado que ocupan 167 caracteres. Por lo tanto, la ecuaci´on que ocurra inmediatamente antes de esta estructura, tendr´a 167 caracteres adicionales. Este programa est´a enfocado a crear el archivo YAML que representar´a al archivo de entrada, por lo que sus funciones principales ser´an escribir en un fichero la estructura general del ´arbol y con el fin de realizar la primera tarea, mantener la cuenta del n´umero de l´ınea y n´umero de car´acter en que se encuentra la lectura del fichero. Esto se realiza a trav´es de dos variables principales que se van incrementando a lo largo del desarrollo del programa: locationSpanStartEq, la cual mantiene la cuenta de en qu´e l´ınea del archivo se encuentra el lector; e initCharEq, la cual mantiene la cuenta de en qu´e car´acter se encuentra el lector. Este parser inicial se basa en extraer el texto de cada ecuaci´on para poder calcular las dos variables anteriores. Pese a ello, en algunos casos como espaciados distintos a lo que suele ser lo general, hacen necesario recalcular las mismas. En el siguiente fragmento de c´odigo se puede observar la escritura del fichero YAML de una iteraci´on apoy´andose tanto en las variables comentadas anteriormente como en otras variables utilizadas espec´ıficamente para la iteraci´on. Posteriormente se actualizan las variables globales con las l´ıneas y caracteres de la iteraci´on. 49 5.3. DESARROLLO DEL SEGUNDO PARSER EXTERNO A PARTIR DE LA GRAM ´ ATICA DESARROLLADA. fw.write("locationSpan : {start: [" + locationSpanStartEq + ", 0], end: [" + (locationSpanStartEq + equationNewLines + extraLocationSpan) + ", " + endColumnLocationSpan+ "]}\r\n"); locationSpanStartEq = locationSpanStartEq + equationNewLines + 1; fw.write("span : [" + initCharEq + ", " + (endCharEq + initCharEq + extraCharsEq) + "]\r\n"); initCharEq = initCharEq + endCharEq + 1; locationSpanStartEq += extraLocationSpan; extraLocationSpan = 0; initCharEq += extraCharsEq; extraCharsEq = 0; La obtenci´on del texto asociado a la ecuaci´on incluyendo los espacios en blanco y saltos de l´ınea debe hacerse a trav´es de la clase Interval, y puede ser apreciado en el siguiente fragmento de c´odigo: int a = equations.get(indexOfEquations).start.getStartIndex(); int b = equations.get(indexOfEquations).stop.getStopIndex(); Interval interval = new Interval(a, b); String equation = ctx.start.getInputStream().getText(interval); 5.3. Desarrollo del segundo parser externo a partir de la gram´atica desarrollada. Tras desarrollar el primer parser inicial, se aument´o su funcionalidad, bas´andose en la gram´atica completa. La estructura ahora pasar´ıa a dividirse en cuatro hijos principales del nodo ra´ız file:equations, el cual es la parte desarrollada en la secci´on anterior y que parte de la gram´atica inicial [5]; sketches, el cual corresponde a las definiciones de las variables de las vistas en cuanto a formato; graphs, el cual corresponde a las definiciones de los gr´aficos; y por ´ultimo metadata, el cual corresponde a aquellos campos finales que definen ciertos par´ametros relativos al archivo en su conjunto. Tambi´en se mejor´o la parte de equations, puesto que en el parser inicial siempre catalogaba las ecuaciones como equation, pero se mejor´o para que fuese capaz de distinguir entre todos los tipos posibles, como subscriptRange,lookupDefinition...etc. Sin embargo, se present´o un problema al tratar de parsear las macros. Esto fue porque dichos clasificadores eran un hijo de SymbolWithDoc en la gram´atica de partida, sino que estaban a su misma altura. Se descart´o modificar la gram´atica pues se consider´o m´as complejo que modificar el c´odigo del parser. Se cre´o una bucle que tendr´ıa tantas iteraciones como elementos tuviesen la lista de macros ySymbolWithDoc conjuntamente. En cada iteraci´on se comprobar´ıa si el elemento 50 CAP´ ITULO 5. DISE ˜ NO a observar es una definici´on de una macro y de serlo, se aplicar´ıan ciertas modificaciones a las variables locationSpanStartEq einitCharEq. En el siguiente fragmento de c´odigo se muestra como se calcula un ArrayList de valores booleanos que identifican si el elemento del total de macros ySymbolWithDoc pertenece a una macro: private ArrayList<Boolean> checkForMacros(String input) { ArrayList<Boolean> array = new ArrayList<>(); try { String text = new String(Files.readAllBytes(Paths.get(input)), StandardCharsets.UTF_8); String[] noControl = text.split("\\\\\\---", 2); String[] equations = noControl[0].split("\\|"); for (int i = 0; i < equations.length; i++) { array.add(equations[i].indexOf(":MACRO:") != -1); } for (int i = 0; i < 4; i++) { // TIME STEP equations array.add(false); } } catch (IOException ex) { ex.printStackTrace(); } return array; } En la parte de sketches, se definen a su vez una serie de contenedores o nodos, cada cual corresponde a una vista. A su vez, cada uno de estos sub-nodos tiene tantos hijos como variables y flechas tenga definidas, diferenci´andose estas dos en el campo type del YAML. Se contemplaron aquellos casos donde el tercer campo de una variable tiene asignado el valor ”cero” y su nombre viene definido en la siguiente l´ınea, sin embargo, no se consideraron conceptos como las shadow variables y la relevancia de ciertos campos sobre otros debido a la complejidad del sprint. Sin embargo, dichas tareas quedaron fijadas para posteriores iteraciones. De manera similar, dentro del nodo de gr´aficos, existen varios hijos asociados a cada gr´afico. En el caso de los metadatos, cada l´ınea es independiente y describe un par´ametro concreto, por lo que son tratadas cada una como un hijo independiente. Debido a que al intentar establecer los apartados de headerSpan yfooterSpan en las secciones de sketches ygraphs resultaba muy engorroso, se decidi´o crear un segundo formateador del texto. El problema surge de que otras secciones tienen delimitadores claros (como es el caso de metadata, donde la l´ınea de : L < %∧E!@ hace de claro delimitador para el headerSpan y la ´ultima l´ınea en blanco del archivo hace de delimitador para el footerSpan), sin embargo estas dos no. Por ello, el nuevo formateador de texto tuvo como tarea a˜nadir l´ıneas de delimitado de inicio y final de dichas secciones: <[V IEW/GRAPH START/END]>respectivamente. Esta labor fue f´acil, ya que consisti´o simplemente en dividir el fichero en partes, introducir los delimitadores y volver a reconstruirlo. 51 5.3. DESARROLLO DEL SEGUNDO PARSER EXTERNO A PARTIR DE LA GRAM ´ ATICA DESARROLLADA. No obstante, durante la integraci´on tanto de este formateador como del anterior (Comment) surgi´o el problema de que SemanticMerge no era capaz de reconocer la estructura del parser, pese a aparentemente ser correcto. Despu´es de realizar una serie de pruebas y confirmar la hip´otesis de qu´e estaba causando el error con las ingenieras de C´odice Software, se comprob´o que el error era causado por que en la reconstrucci´on del YAML (explicado en detalle en el cap´ıtulo de Introducci´on) se compara el texto reconstruido con el archivo inicial. Sin embargo, el texto del archivo inicial se modificaba al a˜nadir tanto los comentarios de las vistas en las ecuaciones como los delimitadores, por lo que al reconstruir, la estructura era distinta. La soluci´on inicial propuesta fue realizar el formateo de los archivos en un programa distinto al parser externo. Tras profundizar en una reuni´on con la tutora de este Trabajo de Fin de Grado, se acord´o separar el programa en dos: uno inicial que cambiase el formato del documento y posteriormente el parser en s´ı mismo. Para poder realizar la resoluci´on de conflictos correctamente pero aun as´ı mantener una copia del archivo original a modo de backup, se decidi´o hacer una copia del archivo inicial y cambiarle bien el nombre o bien la extensi´on (utilizando una extensi´on propia para indicar que es un archivo de backup). El archivo modificado conservar´ıa el nombre inicial para poder realizar el merge sin problemas. Para poder mantener la coherencia de los archivos, se desarroll´o un tercer programa cuya tarea fue eliminar aquellos delimitadores introducidos artificialmente para formar m´as f´acilmente y con m´as claridad en el c´odigo el archivo YAML. El funcionamiento de este programa es muy simple: simplemente lee una a una todas las l´ıneas del programa, si esta coincide con un delimitador, la ignora, y en caso contrario, la escribe en un fichero. Tras comprobar que el parser funcionaba correctamente con archivos completos (es decir, con todas las partes que puede contener la gram´atica) y de extensi´on notable, se a˜nadieron ciertas mejoras sem´anticas para mejorar la comprensi´on a la hora de realizar el merge. Concretamente, se a˜nadi´o la posibilidad de distinguir entre variables convencionales, variables asociadas a gr´aficos y variables sombra o shadow variables. Esto se hace a trav´es de comprobar si pueden llegar flechas a una variable para descartar las variables convencionales y posteriormente, se comprueba la id asociada al tipo de variable para descartar las variables asociadas a gr´aficos. Esto puede ser apreciado en el siguiente fragmento de c´odigo: if (Integer.parseInt(viewVariablesList.get(viewVariablesIndex) .bits.getText()) % 2 == 0) { if (Integer.parseInt(viewVariablesList.get(viewVariablesIndex) .internalId.getText()) == 10) { fw.write(" - type : shadow variable\r\n"); } else { fw.write(" - type : graph variable\r\n"); } } else { fw.write(" - type : variable\r\n"); } 52 CAP´ ITULO 5. DISE ˜ NO 5.3.1. Refactor del visitor Tras realizar un parser funcional que abarcase toda la gram´atica se procedi´o a dividir el visitor principal en varios. Se crearon tres visitors adicionales encargados de procesar las definiciones de ecuaciones, las definiciones de las vistas y las definiciones de gr´aficos y metadatos respectivamente. A mayores, se mejor´o la documentaci´on y legibilidad de dichas clases, y se tradujeron todos los comentarios ´utiles al ingl´es para aumentar su comprensi´on global. En adici´on, se cre´o el paquete utils, el cual contiene todas las peque˜nas funciones en las que se apoyan los visitors, como por ejemplo, funciones que calculan el n´umero de l´ıneas de un archivo o que diferencia las definiciones de ecuaciones que corresponden a macros. 5.4. Desarrollo de interfaces gr´aficas de las aplicaciones auxiliares Tras desarrollar un parser funcional, se concluy´o que se deber´ıan realizar interfaces de usuario para los programas secundarios encargados de primeramente, introducir en el fichero los nombres de las vistas en cada ecuaci´on y los delimitadores, y posteriormente, eliminar dichos delimitadores. Dichas interfaces fueron desarrolladas de forma muy simple a trav´es de la biblioteca de Java Swing [61], puesto que la funcionalidad de la misma es simplemente abrir un archivo a trav´es del explorador de archivos. Ambas interfaces son pr´acticamente id´enticas, por lo que en un principio se opt´o por utilizar distintos colores en el fondo de las mismas para evitar confusiones en su uso y con ello posibles errores. Por ello, la primera interfaz cuenta con un fondo amarillo claro y la segunda tiene el fondo gris predeterminado de la clase JPanel. Las interfaces contaron en un principio con dos botones. El bot´on derecho serv´ıa para buscar el archivo, y es el que lanzaba el explorador de archivos. Al elegir un archivo cuya extensi´on no fuese .mdl, se notificaba al usuario de que el archivo seleccionado no ten´ıa el formato de Vensim con una tipograf´ıa llamativa en color rojo. En caso de elegir un archivo correcto, se mostraba el nombre del archivo. Se notificaba de la misma manera si el usuario cancelaba la operaci´on de elecci´on de fichero en el explorador de archivos. El bot´on de la izquierda por su parte, ten´ıa la funci´on de procesar el archivo y ejecutar los programas correspondientes por debajo. Tras acabar la operaci´on, se notificaba al usuario de que la operaci´on se hab´ıa realizado correctamente con una tipograf´ıa en color verde llamativo. Las interfaces deb´ıan de ser cerradas por el usuario, por lo que no finalizaban al procesar un archivo. Esto permit´ıa que se pudieran procesar varios archivos en una misma ejecuci´on de los programas. Tras la primera prueba con usuarios se decidi´o modificar las interfaces para que fuesen m´as sencillas de usar para los usuarios. Se decidi´o cambiar la disposici´on de los botones a un ´unico bot´on de abrir archivo inicialmente para posteriormente pasar a una pantalla que permitiese procesar el archivo o cancelar la selecci´on para escoger de nuevo el archivo. A 53 5.6. DIAGRAMAS DE CLASES DE DISE ˜ NO 60 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Cap´ıtulo 6 Implementaci´on y pruebas Este cap´ıtulo est´a dedicado a explicar la implementaci´on de ciertas herramientas en el proyecto, as´ı como todas las pruebas realizadas durante el transcurso del proyecto. Las pruebas de testing han sido divididas en diferentes categor´ıas, detallando en las primeras secciones pruebas espec´ıficas para cada programa desarrollado, y explicando en las secciones finales las pruebas de aceptaci´on de usuarios. 6.1. Implementaci´on de la integraci´on continua y el despliegue continuo Como se explic´o en el cap´ıtulo de Tecnolog´ıas Utilizadas, tanto la integraci´on continua como en despliegue continuo se realizaron a trav´es de las herramientas de GitLab. La herramienta permite realizar estas actividades a trav´es de un fichero denominado .gitlab-ci.yml. Respecto a la integraci´on continua, es proceso es bastante sencillo, ya que al estar utilizando un entorno Maven en el proyecto, GitLab se limita a recrear los tests realizados en la m´aquina local y los lanza en su propia m´aquina virtual, comprobando que las pruebas no son correctas ´unicamente en la m´aquina local. Respecto al despliegue continuo, a trav´es de ese mismo archivo se conecta con una m´aquina virtual proporcionada por la Escuela de Ingenier´ıa Inform´atica. Dicha m´aquina tiene instalados los programas necesarios para ser capaz de lanzar el parser en formato JAR y comprobar que funciona correctamente en otras m´aquinas. Para ello, se instal´o en la m´aquina virtual la herramienta Cygwin [42], la cual permit´ıa realizar comunicaciones ssh entre dicha m´aquina yGitLab. Para garantizar la seguridad del usuario y no exponer al p´ublico sus credenciales, la contrase˜na de la m´aquina virtual fue almacenada como variable de entorno de GitLab. En cuanto a la comprobaci´on del funcionamiento en la m´aquina virtual desde GitLab, se comprob´o que en caso de fallo no se lanzaba el programa en SemanticMerge, por lo que lo m´as ´optimo fue lanzar la herramienta en remoto, esperar un periodo de tiempo y probar a 61 6.1. IMPLEMENTACI ´ ON DE LA INTEGRACI ´ ON CONTINUA Y EL DESPLIEGUE CONTINUO terminar el proceso mediante un comando kill. Si esto era correcto, el despliegue continuo habr´ıa funcionado correctamente. Concretamente en este trabajo se utiliz´o una m´aquina virtual con una imagen de Windows 10, en la que estaba instalada una copia de SemanticMerge con el objetivo de probar el despliegue del plugin generado en forma de archivo jar. Ambas acciones se describen en el fichero .gitlab-ci.yml situado en el directorio ra´ız del proyecto. En este fichero se describen las diferentes etapas por las que pasar´a el proyecto tras actualizarse mediante commit &push. En estas etapas se encuentran acciones asociadas tanto a la integraci´on continua como al despliegue continuo. Estas etapas pueden ser tambi´en catalogadas como tuber´ıas o pipelines, defini´endose en cada una de estas una serie de tareas. Para comenzar una etapa, todas las tareas de la etapa anterior deben haber sido completadas. En el siguiente fragmento de c´odigo se c´odigo se muestra el archivo YAML utilizado para esta tarea en este proyecto: image: maven:3.6.3-jdk-11 variables: MAVEN_CLI_OPTS: "--batch-mode" MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository" before_script: - ’apt-get update && apt-get install sshpass’ stages: - build - test - deploy cache: paths: - .m2/repository - target/ build_job: stage: build script: - mvn $MAVEN_CLI_OPTS compile test_job: stage: test script: - mvn $MAVEN_CLI_OPTS test -P Unit deploy-master: 62 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS stage: deploy script: - mvn assembly:assembly - sshpass -p "$password" scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P 20012 target/mvntfg-1.0-jar-with-dependencies.jar [email protected]:C:\Users\Usuario\AppData \Local\semanticmerge - sshpass -p "PASSWORD" ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] -p 20012 "cd /cygdrive/c/Users/Usuario/AppData/Local/semanticmerge/ && ./script.bat && exit" only: - master #### deploy-develop: stage: deploy script: - mvn assembly:assembly - sshpass -p "$password" scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P 20012 target/mvntfg-1.0-jar-with-dependencies.jar [email protected]:C:\Users\Usuario\AppData \Local\semanticmerge - sshpass -p "$password" ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] -p 20012 "cd /cygdrive/c/Users/Usuario/AppData/Local/semanticmerge/ && ./script.bat && exit" only: - develop En la etapa de test se comprueban todos los tests asociados al proyecto. Esto se hace a trav´es de la categorizaci´on de los tests que Maven provee. La etapa de deploy est´a asociada al despliegue continuo. En esta etapa se env´ıa el fichero jar a la m´aquina virtual mediante scp y despu´es de accede a ella mediante ssh para ejecutar un script que lanzar´a SemanticMerge para comprobar la validez del parser. En este comando podemos ver que se utiliza la variable de entorno $password, la cual hace referencia a la contrase˜na de la m´aquina virtual y que por motivos de seguridad no se expone en el fichero al ser el repositorio p´ublico. La variable de entorno est´a asociada al usuario de GitLab y puede ser modificada desde la p´agina web. El script utilizado en la m´aquina virtual es el siguiente: START "" .\semanticmergetool.exe --source=Bunny1.mdl --destination=Bunny2.mdl --externalparser="-jar mvntfg-1.0-jar-with-dependencies.jar" 63 6.2. IMPLEMENTACI ´ ON DE LAS PRUEBAS DE EFICIENCIA REALIZADAS SOBRE EL PARSER --virtualmachine="C:\Program Files\java\jdk-11.0.8\bin\java.exe" && sleep 10 && taskkill -IM semanticmergetool.exe Los archivos Bunny1.mdl yBunny2.mdl son archivos de prueba muy simples cuyo ´unico fin es comprobar si se ha conseguido desplegar correctamente el parser. Como se puede apreciar, el script lanza el programa, espera 10 segundos e intenta finalizar el programa. En caso de fallo, no se realizar´an los ´ultimos dos comandos y el despliegue continuo fallar´a debido a un timeout. Este mecanismo debe de realizarse as´ı puesto que las alertas de fallo se realizan por la interfaz gr´afica, y no se consigui´o acceder a ellas a trav´es de la l´ınea de comandos. 6.2. Implementaci´on de las pruebas de eficiencia realizadas sobre el parser En cierto punto del desarrollo del programa se comprob´o que para archivos de una muy gran extensi´on, como puede ser 40.000 l´ıneas de c´odigo, la ejecuci´on del programa no llegaba a finalizar nunca, por lo que se trat´o de analizar la eficiencia del programa. Concretamente se realizaron pruebas con ficheros de distinto tama˜no. Primeramente se utilizaron ficheros de peque˜no tama˜no, con apenas 300 l´ıneas y un tama˜no entre 2 y 10 KBs. El procesamiento de estos ficheros fue instant´aneo. Aumentando cuantiosamente el tama˜no de los ficheros, con alrededor de unas 20.000 l´ıneas y un tama˜no de aproximadamente 550 KBs, el procesamiento del fichero se demoraba unos pocos segundos, pero no m´as de 5 o 6. Finalmente, utilizando un fichero de gran tama˜no, concretamente unas 40.000 l´ıneas y un tama˜no de casi 2 MB, el fichero no consigui´o procesarse, puesto que se cort´o la ejecuci´on de dicho procesamiento al cabo de aproximadamente treinta minutos. Este problema se encontr´o a lo largo del s´eptimo sprint y se arrastr´o el problema durante varios sprints consecutivos, en cada uno de ellos probando nuevas formas de analizar la eficiencia del c´odigo realizado. Inicialmente se examin´o en profundidad el c´odigo y pese que s´ı se encontraron ciertos puntos que podr´ıan mejorar, no se encontr´o ninguna estructura que pudiera estar causando semejante consumici´on de tiempo. Tampoco se detect´o ninguna clase de bucle infinito o problema similar donde el c´odigo pudiese encontrar un deadlock o quedarse atascado. Tras eso, se decidi´o utilizar una herramienta que analizase la eficiencia del c´odigo o profiler, eligiendo en este caso la herramienta JProfiler [57]. Sin embargo, tras configurar adecuadamente sus par´ametros, no se detect´o ning´un problema en el c´odigo que pudiese estar causando problemas de eficiencia. En cierto momento del desarrollo del proyecto se decidi´o utilizar SonarQube [49] para comprobar si exist´ıan brechas de eficiencia en el c´odigo. En dicha prueba se detectaron varios fallos de calidad asociados al tratamiento de ficheros y ciertas repeticiones de c´odigo asociadas a la escritura del ´arbol YAML, sin embargo, no eran problemas de eficiencia. Respecto a la complejidad cognitiva, se detectaron dos clases respectivas a los visitors que presentaban una gran complejidad por encima de lo permitido por la herramienta. No obstante, al revisar dichas clases, se comprob´o que muchas de las cl´ausulas que aumentaban la complejidad eran 64 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS bloques if-else destinados a categorizar las estructuras de c´odigo otorg´andolas tipo y nombre, en ocasiones, entre hasta ocho posibilidades. No se detectaron otros posibles problemas de eficiencia. En cierto punto del proyecto se realiz´o una reuni´on con desarrolladores de la empresa Plastic SCM para analizar la eficiencia del proyecto, pues con su experiencia podr´ıan ayudar a resolver los problemas. Sin embargo, se descubri´o que el problema no era una cuesti´on de eficiencia, sino que exist´ıa un error invisible. Al transformar el programa para ser utilizado en gMaster, se cambi´o el funcionamiento del mismo de aceptar un n´umero concreto de archivos a utilizar espera activa para utilizar un n´umero ilimitado de archivos. No obstante, esto provocaba que si el fichero fallaba en el reconocimiento de la gram´atica, el fallo pasara desapercibido. El fallo de parseo se solucion´o de forma sencilla, con dos l´ıneas de c´odigo. Por otro lado, se transform´o la clase principal del programa para que realizase un bloque try-catch en cada iteraci´on o archivo procesado. Esto no solucion´o el problema de no visualizar el error en la interfaz gr´afica de SemanticMerge, pero hizo que el proceso de debugging fuese mucho m´as eficiente. Durante el proceso de comprobar que el archivo de 40.000 l´ıneas fuese correcto se encontraron varios nombrados de variable problem´aticos que hac´ıan que el parser no funcionase correctamente. Estos nombrados se explican en el Anexo de Manuales de Usuario. 6.3. Pruebas referidas a la automatizaci´on de la inserci´on de los nombres de las vistas en los comentarios de las ecuaciones El proceso de testing fue muy similar al de la gram´atica, ya que se probaron la mayor´ıa de archivos que se utilizaron para comprobar que esta era correcta. A mayores, se realizaron una serie de tests unitarios comprobando que el n´umero de l´ıneas del fichero no variaba y que las escrituras se realizaban correctamente y en el lugar que se deb´ıa. Los escenarios probados fueron los siguientes: Escenario simple b´asico. Escenario que contiene una ecuaci´on que no aparece definida en el apartado de las vistas. Escenario donde las ecuaciones tienen comentarios previos. Escenario donde existen varias vistas. Escenario donde las ecuaciones tienen caracteres especiales como par´entesis, corchetes o barras bajas. Escenario donde el archivo ya ha sido procesado una vez y contiene los delimitadores <[VIEW>:> y<[DESCRIPTION]>:. 65 6.3. PRUEBAS REFERIDAS A LA AUTOMATIZACI ´ ON DE LA INSERCI ´ ON DE LOS NOMBRES DE LAS VISTAS EN LOS COMENTARIOS DE LAS ECUACIONES Escenario donde el fichero a procesar no existe. A continuaci´on se muestra el ejemplo del test del escenario m´as b´asico posible, donde se comprueba que el n´umero de l´ıneas no ha sido modificado y que los comentarios han sido introducido en las l´ıneas correctas: @Test public void lecturaCorrectaSimple() { String[] args = new String[2]; args[0] = "VensimExampleModels/SHODOR/Bunny.mdl"; args[1] = "outputs/comment/test1.mdl"; BufferedReader reader; try { Comment.main(args); reader = new BufferedReader(new FileReader( "VensimExampleModels/SHODOR/Bunny.mdl")); int lines = 0; while (reader.readLine() != null) lines++; reader.close(); assertSame(127, lines); // Last newline is not counted reader = new BufferedReader(new FileReader( "outputs/comment/test1.mdl")); Set<Integer> positions = new HashSet<Integer>(); positions.addAll(Arrays.asList(new Integer[] { 4, 9, 15, 21, 26, 31, 36, 41 })); for (int i = 0; i < 43; i++) { String line = reader.readLine(); if (positions.contains(i)) { assertTrue(line.indexOf("View 1") != -1); } } reader.close(); } catch (Exception e) { e.printStackTrace(); } } En el caso de este primer programa, el proceso de testing fue bastante r´apido puesto que todos los casos probados funcionaron correctamente en la primera prueba. 66 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS 6.4. Pruebas referidas al primer parser basado ´unicamente en la gram´atica de partida La gram´atica de partida s´olo ten´ıa en consideraci´on la parte de los ficheros .mdl dedicada a la definici´on de ecuaciones, por lo que no existen tests orientados a los datos definidos en las vistas y los gr´aficos. Se tuvo la limitaci´on de que la herramienta utilizada para contar tanto las l´ıneas como los caracteres de los archivos, charposition [28], no era capaz de leer archivos de gran tama˜no, limitando el n´umero de l´ıneas a aproximadamente 2500. Aun as´ı, se pudieron hacer muchas comprobaciones: Escenario simple b´asico. Escenario que contiene una ecuaci´on que no aparece definida en el apartado de las vistas y con un espaciado diferente por ello. Escenario con palabras clave utilizando guiones bajos. Escenario en el que se incluyen definiciones de subscript ranges. Escenario en el que se incluyen definiciones de tablas o lookups. Escenario en el que se incluyen definiciones de macros. Escenario en el que se incluyen definiciones de data equations. Escenario en el que se incluyen definiciones de unchangeable constants. Escenario en el que se incluyen definiciones de constraints. Escenario donde TIME STEP no es la ´ultima ecuaci´on declarada. Pese a que no se encontraron archivos de tama˜no lo suficientemente peque˜no para probar ciertos casos como reality checks, se asume que son correctos al utilizar la misma sintaxis que las ecuaciones, los subscript ranges o las definiciones de lookups. Inicialmente, los tests consistieron en recorrer l´ınea a l´ınea el archivo e ir comprobando ciertas l´ıneas cr´ıticas que proporcionaban informaci´on sobre si el archivo YAML se hab´ıa generado correctamente. Esto ocasion´o un problema con la integraci´on continua en GitLab, puesto que SemanticMerge es una herramienta desarrollada para Windows, por lo que utiliza el espaciado correspondiente a este sistema operativo, CRLF. Sin embargo, GitLab utiliza el espaciado convencional de Linux, LF. Esto provoc´o que los tests asociados al parser funcionasen en local pero no en la integraci´on continua. Por el momento, dicho problema se acept´o y se buscar´ıa una soluci´on en sprints posteriores del proyecto. Este proceso de testing fue bastante sencillo de nuevo, obteniendo problemas ´unicamente en el ´ultimo escenario. Esto se solucion´o contemplando todas las ecuaciones en vez de parar de comprobar al reconocer TIME STEP como se hac´ıa antes. Si bien en la gran mayor´ıa de archivos de Vensim se utilizan siempre las mismas cuatro variables como variables de control de la simulaci´on, en archivos de mucha mayor longitud, es posible encontrar variables definidas manualmente en este ´area. 67 6.5. PRUEBAS REFERIDAS AL SEGUNDO PARSER BASADO EN LA GRAM ´ ATICA DESARROLLADA Finalmente, con el objetivo de probar si el parser era aceptado por SemanticMerge, en cada test se introdujo un comando que lanzaba el jar del proyecto como parser, con el archivo que se estaba probando tanto como source como destination. Sin embargo, para permitir que los tests siguiesen siendo fluidos, este comando permanece siempre comentado salvo en las ocasiones que se quiera probar un fichero concreto. El comando se expone en el siguiente fragmento de c´odigo, utilizando el archivo del escenario base: Process process = Runtime.getRuntime() .exec("C:\\Users\\Propietario\\AppData\\Local\\semanticmerge. \\semanticmergetool.exe" + " --source=Formatted/BunnyFormat.mdl --destination=Formatted/BunnyFormat.mdl --externalparser=\"-jar target/mvntfg-1.0-jar-with-dependencies.jar\"" + " --virtualmachine=\"C:\\Program Files\\Java\\ jdk-11.0.8\\bin\\java.exe\""); 6.5. Pruebas referidas al segundo parser basado en la gram´atica desarrollada El segundo parser incluye la definici´on de las vistas y sus variables asociadas, los gr´aficos y los metadatos del programa. Como es una ampliaci´on del parser desarrollado y explicado en la secci´on anterior, el testing realizado incluye los expuestos en la secci´on anterior. Se incluyen a mayores los siguientes casos de pruebas: Escenario simple b´asico. Escenario donde no se utilizan gr´aficos. Escenario donde se utilizan m´ultiples vistas. Escenario donde se utilizan m´ultiples gr´aficos. Tras desarrollar los casos base, se probaron varios archivos de gran longitud para ver si el parser era capaz de procesarlos, y una vez procesados, capaz de ser utilizados por la herramienta de SemanticMerge. Se comenz´o probando el archivo que se utilizaba como modelo base en el proyecto LOCOMOTION, el archivo WILIAM.mdl. Sin embargo se encontr´o que pese a que los ficheros .mdl suelen utilizar la codificaci´on de texto UTF-8 (quedando indicado en la primera l´ınea del fichero), dicho fichero no la utilizaba, al incluir palabras con caracteres especiales como ‘˜n’ o ‘´a’. Sin embargo, dicho fichero tamb´ıen ten´ıa la declaraci´on de que utilizaba el est´andar de UTF-8, por lo que se anot´o como incidencia para tratar con los desarrolladores de LOCOMOTION. Probando otros ficheros se descubrieron y corrigieron dos bugs que aparec´ıan por casos no contemplados. El primero de ellos ocurr´ıa porque el parser s´olo contemplaba ecuaciones 68 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS definidas de forma compactada (sin utilizar la estructura por l´ıneas para declarar la ecuaci´on, las unidades y el comentario, y haci´endolo todo seguido en una ´unica l´ınea). Esto se debe a que en la mayor´ıa de ficheros de prueba, las variables que controlaban par´ametros de la simulaci´on eran siempre las mismas y estaban en el mismo formato (TIME STEP,FINAL TIME...), sin embargo, se vio que en archivos de mayor complejidad se pueden a˜nadir otro tipo de variables externas que es necesario contemplar. El segundo bug que se trat´o fue m´as costoso de encontrar, y es que ANTLR4 elimina los espacios que pueden existir detr´as de una coma, por lo que el span utilizado para contar los caracteres de las distintas partes del programa pod´ıa llegar a acumular una gran diferencia en un fichero con gran cantidad de comas. Se arregl´o para el caso de las comas, y se marc´o como incidencia el buscar otros caracteres que produjesen este bug. Tras la reuni´on se seguimiento asociada a este sprint se acord´o que ser´ıa conveniente modificar los tests de forma que en vez de recorrer el archivo y comprobar las l´ıneas cr´ıticas, se hiciese directamente un diff entre el archivo generado y una copia local y se comprobase que los archivos fuesen id´enticos. Esto har´ıa que los tests fuesen m´as sencillos y mucho m´as f´aciles de comprender. Adem´as, al realizar un diff en vez de comprobar el n´umero de caracteres, se solucion´o el problema producido por la diferencia en los saltos de l´ınea entre Windows y Linux que ocasionaba GitLab. A continuaci´on podemos observar un fragmento de c´odigo con el test utilizado para probar el escenario m´as simple: 69 6.7. PRUEBAS DE ACEPTACI ´ ON DE USUARIOS 6.7.4. Formulario para las pruebas de aceptaci´on de usuario. En dichas pruebas de usuario, se le proporcion´o al usuario un formulario para que aporte datos sobre su experiencia con la aplicaci´on en diversos puntos as´ı como sugerencias de mejora. Se comenz´o encuestando a los usuarios sobre la dificultad y el tiempo transcurrido en cada uno de los escenarios por separado. Adem´as se pregunt´o a los usuarios sobre fallos o posibles mejoras en dichos escenarios. Para cada escenario se formularon las siguientes preguntas: ¿C´omo de dif´ıcil te ha resultado realizar la tarea? [Escala de 0 (muy dif´ıcil) a 10 (muy f´acil)]. ¿Cu´anto tiempo te ha llevado realizar la tarea? [Escala de 0 (mucho tiempo) a 10 (poco tiempo)]. ¿Has detectado alg´un error o tienes alguna sugerencia de mejora? Tras esto, se realizaron preguntas de car´acter general sobre el desarrollo de la prueba. Las preguntas realizadas fueron las siguientes: Explica brevemente los programas que forman parte de la soluci´on. ¿C´omo de f´acil te ha sido diferenciar los diferentes programas que forman parte de la soluci´on? [Escala de 0 (muy dif´ıcil) a 10 (muy f´acil)]. ¿C´omo de f´acil te ha sido utilizar como un todo los diferentes programas que forman parte de la soluci´on? [Escala de 0 (muy dif´ıcil) a 10 (muy f´acil)]. ¿C´omo de f´acil te ha sido identificar en el archivo de texto los cambios realizados en el entorno gr´afico de Vensim utilizando Semantic diff? [Escala de 0 (muy dif´ıcil) a 10 (muy f´acil)]. ¿C´omo de f´acil te ha sido identificar en el archivo de texto los cambios realizados en el entorno gr´afico de Vensim sin utilizar Semantic diff? [Escala de 0 (muy dif´ıcil) a 10 (muy f´acil)]. ¿Cu´an ´utiles han sido para ti las aportaciones sem´anticas en el an´alisis de las diferencias entre versiones? [Escala de 0 (nada ´utiles) a 10 (muy ´utiles)]. ¿Qu´e elemento de la soluci´on te ha resultado m´as ´util en cuanto a analizar las diferencias? ¿Cu´an ´utiles han sido para ti las aportaciones sem´anticas en la integraci´on (merge)? ¿Qu´e elemento de la soluci´on te ha resultado m´as ´util en cuanto a realizar la integraci´on (merge)? En resumen, valora la soluci´on integrada en cuanto: F´acil de entender, f´acil de aprender, ´util, r´apida, original, c´omoda, satisfacci´on general. [Escala de 0 a 10]. 76 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS 6.7.5. Respuestas de los usuarios al formulario Pocas personas realizaron el formulario tras realizar las pruebas de aceptaci´on de usuario, pero las respuestas registradas reflejaron que la herramienta permit´ıa realizar los escenarios de manera muy intuitiva y en poco tiempo, pues todas las respuestas a las preguntas de facilidad y tiempo dedicado a las tareas se calificaron de 9, siendo 10 “Muy f´acil” y “Poco tiempo” respectivamente. Los errores y sugerencias de mejoras se comentaron directamente en una reuni´on telem´atica que tuvo lugar despu´es de la tercera prueba de usuarios. Se dio una puntuaci´on de 7 a la tarea de identificar en el archivo de texto los cambios realizados en el entorno gr´afico de Vensim utilizando Semantic Diff. Sin embargo, dichos problemas fueron comentados en la reuni´on mencionada anteriormente y se mejor´o la documentaci´on de loa Manuales de Usuario para evitar dichos problemas. Se calific´o de muy dif´ıcil entender los cambios realizados en un fichero utilizando ´unicamente la diferenciaci´on textual y se calific´o de muy ´util con la m´axima puntuaci´on la ayuda que proporciona este proyecto para entender los cambios realizados, destacando en especial las dos herramientas auxiliares, Adder yEraser. 6.7.6. Problemas o advertencias de uso encontrados durante la realizaci´on de las pruebas En las diferentes pruebas de aceptaci´on de usuarios realizadas se produjeron varios fallos sobre los cuales, tras investigarlos por separado, se concluy´o que eran debidos al funcionamiento de las herramientas de SemanticMerge yVensim. En concreto, varios de estos fallos se encontraron al investigar por qu´e al realizar un cambio simple como eliminar una variable, gMaster llegaba en algunos casos a mostrar que se hab´ıan realizado decenas de cambios. Esta secci´on se encuentra detallada en profundidad en el anexo de Manuales de Usuario, en la secci´on A.2.5. 77 6.7. PRUEBAS DE ACEPTACI ´ ON DE USUARIOS 78 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Cap´ıtulo 7 Seguimiento del proyecto 7.1. Introducci´on Este Trabajo de Fin de Grado comenz´o de forma oficial el 14 de septiembre de 2020, con la primera reuni´on organizativa del mismo. Sin embargo, durante el mes de agosto se comenz´o a trabajar con las tecnolog´ıas referentes al proyecto para amenizar la curva de aprendizaje inicial y reducir la carga de trabajo en los primeros meses. 7.2. Sprint 0 Con el fin de amenizar la carga de trabajo en el inicio del desarrollo del proyecto, durante el mes de agosto se estableci´o como objetivo el crear un parser externo para la herramienta SemanticDiff, el cual fuese capaz de procesar un peque˜no programa en un lenguaje imaginario aunque muy parecido a Java. Para ello, se investig´o acerca del funcionamiento de ANTLR4 y su funcionamiento con otros lenguajes de programaci´on. Al tener conocimiento de gram´aticas y otro tipo de software m´as antiguo como Lex oYacc, esto no supuso un gran problema. Adem´as, tras investigar acerca de ANTLR4, se observ´o que ten´ıa muy buena sincronizaci´on con Java, por lo que se utilizar´ıa dicho lenguaje de programaci´on para desarrollar el proyecto. A mayores, tambi´en se familiariz´o con el entorno de Vensim y se estudi´o la gram´atica proporcionada por el Trabajo de Fin de Grado del curso anterior de Daniel Bazaco [5]. En el caso de la creaci´on del plugin externo, existieron problemas debido a la falta de documentaci´on y a que la documentaci´on existente era antigua. Tras un tiempo sin lograr encontrar la soluci´on a varios problemas que surgieron, se cre´o un grupo de trabajo en BaseCamp 3con varios ingenieros de la empresa C´odice Software, los cuales ten´ıan conocimiento sobre la herramienta SemanticMerge. Con su ayuda se logr´o desarrollar un parser externo que 79 7.3. SPRINT 1 (14/9/2020 - 27/9/2020) utilizaba una gram´atica en ANTLR4 utilizando el framework de Maven. Dicho proyecto era capaz de generar un archivo .jar que SemanticMerge reconoce como archivo ejecutable y proporciona las diferencias entre dos archivos de prueba. Pese a no medirse este tiempo de preparaci´on, se estima un trabajo entre unas 40 y 45 horas. 7.3. Sprint 1 (14/9/2020 - 27/9/2020) La Tabla 7.1 muestra las tareas realizadas durante este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Entender un plugin de SemanticMerge de un lenguaje no orientado a objetos (Scala) 2h 1h 40min Completado Entender c´omo SemanticMerge gestiona los diferentes tipos de diferencias 4h 3h Completado Ampliar la gram´atica (*) 8h 24h 20min En proceso Valorar qu´e tests son posibles y si es posible una integraci´on continua/despliegue continuo 4h 4h 30min Completado Informarse de si es posible modificar las shadow variables 4h 50min En proceso Documentaci´on del sprint 10h 12h Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 34h 48h 20min 5/7 tareas completadas (*) Este tiempo incluye tambi´en el tiempo destinado a testear los cambios realizados en la gram´atica. Tabla 7.1: Tareas del sprint 1. Este sprint se caracteriz´o principalmente en la b´usqueda de informaci´on y documentaci´on de cara a futuros sprints del proyecto y a la ampliaci´on de la gram´atica de Vensim ya existente, centr´andose en las vistas y los gr´aficos. Al estar el desarrollo de la gram´atica explicado en profundidad en la secci´on de ”Dise˜no”, no se profundizar´a de nuevo en esta secci´on. Se comenz´o investigando el funcionamiento de SemanticMerge, pues todos los plugins externos encontrados y los lenguajes que actualmente soporta el software tienen en com´un que comparten una estructura t´ıpica de los lenguajes orientados al objeto. Sin embargo, Vensim tendr´ıa una estructura m´as parecida a lenguajes orientados al paradigma funcional como 80 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Python oScala. Tras encontrar un repositorio con un plugin externo de Scala y consultar la documentaci´on oficial de SemanticMerge, se concluy´o que la aplicaci´on utiliza una estructura de ´ambito general compatible con cualquier tipo de paradigma. Dicha estructura se caracteriza por utilizar dos elementos, contenedores y nodos, pudiendo contener los contenedores a su vez otros contenedores, estructura similar a la que utiliza el patr´on de dise˜no ”Composite”. En cuanto a los tests, se concluy´o que testear la gram´atica era inviable debido a la falta de documentaci´on y librer´ıas, y peque˜nos cambios en ella podr´ıan dejar in´utiles la mayor´ıa de los tests. Sin embargo, si que se podr´ıan testear los visitors de la gram´atica por separado as´ı como las reglas por separado, utilizando peque˜nos ficheros de prueba .mdl y comprobando que el output sea el esperado, puesto que todos los posibles errores encontrados al parsear un fichero se muestran por consola al principio. No existir´ıa problema en realizar integraci´on continua, sin embargo, para el despliegue continuo, si bien s´ı que es posible utilizar un contenedor Docker para instalar SemanticMerge y probar el parser en remoto, se concluy´o que era mucho m´as f´acil realizar un script que realizase las comprobaciones autom´aticas en la m´aquina local. Pese a ello, no se descartaron ninguna de las dos opciones. Finalmente, se estuvo investigando acerca de las variables sombra o shadow variables. Existen dos tipos de variables sombra, las puras como el tiempo, y las que dependen de otras variables creadas por el usuario. Estas ´ultimas dependen de sus variables iniciales y si estas se eliminan se eliminar´an tambi´en las variables sombra asociadas. Se determin´o que la gram´atica era capaz de tratar el problema a trav´es de SemanticMerge y el futuro c´odigo implementado. 81 7.4. SPRINT 2 (28/9/2020 - 11/10/2020) 7.4. Sprint 2 (28/9/2020 - 11/10/2020) La Tabla 7.2 muestra las tareas realizadas durante este sprint as´ı como el tiempo invertido en ellas. Este sprint se caracteriz´o por una parte por el trabajo dedicado a la compresi´on Tarea Tiempo estimado Tiempo invertido Estado Investigar c´omo analizar cobertura de gram´atica 2h 40min Completado Conocer qu´e significan cada n´umero/par´ametro en los objetos de las vistas 2h 1h Completado Ampliar la gram´atica (*) 8h 2h 20min Completado Conocer c´omo utilizar correctamente m´ultiples visitors 2h 30min Completado Informarse de si es posible modificar las shadow variables 4h 1h 50min Completado Comprender como funciona una tabla de s´ımbolos 2h 1h 10min Completado Entender estructura del TFG de Daniel Bazaco 2h 1h 30min Completado Documentaci´on del sprint 10h 3h 15min Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 34h 14h 15min 9/9 tareas completadas (*) Este tiempo incluye tambi´en el tiempo destinado a testear los cambios realizados en la gram´atica. Tabla 7.2: Tareas del sprint 2. del proyecto anterior del que parte este trabajo, as´ı como a la toma de contacto con los integrantes del proyecto LOCOMOTION gracias a una reuni´on por videoconferencia. En dicha conferencia se estableci´o contacto con tres miembros del proyecto, los cuales expresaron sus principales problemas y dificultades a la hora de trabajar con SemanticMerge con archivos Vensim. Principalmente exist´ıan dos problemas, la parte dedicada a definir las vistas y los gr´aficos en los ficheros .mdl es muy confusa, ya que se emplean l´ıneas individuales para cada variable con muchos par´ametros num´ericos, lo que hac´ıa muy complicado distinguir qu´e significa cada campo y qu´e campos son triviales a la hora de hacer un merge; y que la gram´atica actual, al estar enfocada ´unicamente a la parte de definici´on de ecuaciones, potencia el problema actual, siendo los bloques que SemanticMerge usa para resolver los conflictos en la parte de definici´on de las vistas muy grandes, haciendo casi imposible resolver conflictos con la herramienta y teni´endolos en consecuencia que hacer a mano. 82 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Estos problemas quedaron registrados en el backlog y enfocar el proyecto a dichos objetivos. Si bien la parte de tratamiento de las vistas por parte de la gram´atica ya era un objetivo previsto y desarrollado, se modific´o la gram´atica para distinguir las partes triviales de las l´ıneas de definici´on de variables en las vistas. No se profundizar´a en este tema pues qued´o explicado anteriormente en la secci´on de An´alisis. Tambi´en en esa secci´on, queda planteada la soluci´on al problema que surgi´o en el anterior sprint, el cual surg´ıa de no saber c´omo catalogar si una variable sombra ha sido borrada y creada de nuevo, o si simplemente se hab´ıa movido. Por otro lado, se realiz´o una labor de investigaci´on para afianzar conocimientos sobre la base de la que parte el proyecto, as´ı como del funcionamiento general de una gram´atica, su tabla de s´ımbolos y su ´arbol generado. Tras realizar las ´ultimas modificaciones a la gram´atica, se ampli´o en una gran medida el n´umero de tests, gracias a diferentes fuentes proporcionadas por la tutora [9] [21] [31]. Pese a ello y con el fin de estar seguros de que la gram´atica era correcta al 100 %, se intent´o buscar alguna forma o software para realizar un an´alisis de cobertura de la gram´atica. Desgraciadamente, no se encontr´o ninguna fuente que especificase c´omo hacerlo por lo que se descart´o. 7.5. Sprint 3 (12/10/2020 - 25/10/2020) La Tabla 7.3 muestra las tareas realizadas durante este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Realizar un programa que a˜nada al comentario de una ecuaci´on la vista a la que pertenece 14h 13h 10min Completado Configurar m´aquina virtual y planificar despliegue continuo 1h 30min 1h 20min Completado Decidir c´omo integrar el programa de resoluci´on de vistas en el parser 1h 30min 10min Completado Documentaci´on del sprint 2h 2h 10min Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 21h 18h 50min 5/5 tareas completadas Tabla 7.3: Tareas del sprint 3. 83 7.6. SPRINT 4 (26/10/2020 - 08/11/2020) Este sprint se caracteriz´o por el desarrollo de una de las tareas principales enunciadas en el backlog principal: desarrollar un programa que lea un fichero .mdl, reconozca qu´e variables pertenecen a una vista e introducir en el comentario de las ecuaciones de las variables a qu´e vista pertenece la misma. Como este proceso ha sido ya explicado en el cap´ıtulo de Dise˜no, no se profundizar´a m´as en ´el. Tambi´en se dedic´o tiempo a pensar c´omo se integrar´ıa dicho programa en el parser final. Se lleg´o a la conclusi´on de que el parser contendr´a una clase principal que leer´a los archivos y les aplicar´a el formateo. Tras ello, escribir´a el resultado en dos archivos, como por ejemplo arch1.mdl yarch2.mdl, que siempre ser´an le´ıdos por el visitor, independientemente de su nombre original. Se podr´a realizar una segunda escritura para reemplazar el contenido de los ficheros originales por su texto formateado. Tambi´en se trabaj´o en la configuraci´on de la m´aquina virtual para realizar el despliegue continuo en un futuro. Se instal´o el software de Vensim ySemanticMerge para poder realizar el trabajo, instalando tambi´en el JDK-11 de Java para poder ejecutar el parser externo en formato jar, puesto que no exist´ıa ninguna versi´on de Java. Para poder acceder a la m´aquina, se configur´o como servidor ssh, abriendo el puerto 22 e instalando openssh-server. Tras comprobar que el acceso era posible, se realiz´o un script en formato .bat que servir´ıa para poder ejecutar el parser externo desde l´ınea de comando en un futuro. 7.6. Sprint 4 (26/10/2020 - 08/11/2020) La Tabla 7.4 muestra las tareas realizadas durante este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Integrar TFG de partida 8h 1h 30min Completado Desarrollar parser b´asico inicial 14h 18h 5min Completado Incluir integraci´on continua funcional 2h 1h 10min En proceso Documentaci´on del sprint 2h 30min 3h 10min Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 26h 30min 25h 20min 4/5 tareas completadas Tabla 7.4: Tareas del sprint 4. Este sprint se caracteriz´o por el desarrollo de un primer parser basado ´unicamente en la gram´atica de partida. No se profundizar´a en exceso en este apartado al estar descrito extensamente en la secci´on de Dise˜no. Gracias al tiempo dedicado en verano durante el Sprint 0, no se obtuvieron errores propios de SemanticMerge, sin embargo, se obtuvieron errores que eran nuevos hasta la fecha, provenientes de una estructura err´onea del archivo YAML. Tras contactar con los ingenieros de PlasticSCM, se figur´o la fuente del problema y se solucion´o correctamente. 84 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Por otro lado, se comenz´o el proceso de incorporar al proyecto integraci´on y despliegue continuos. Sin embargo, pese a pasar correctamente los tests en la m´aquina local, en en proceso de despliegue continuo se obtuvieron errores desconocidos al generar los archivos YAML de forma diferente. 7.7. Sprint 5 (09/11/2020 - 22/11/2020) La Tabla 7.5 muestra las tareas realizadas durante este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Desarrollar un parser que incluya toda la gram´atica 18h 16h 5min Completado Testing avanzado del parser 4h 7h 20min En proceso Incluir integraci´on continua funcional 2h 1h 40min Completado Investigar c´omo integrar el parser en gMaster 1h 30min 15min Completado Integrar el programa de formateo del texto en el parser 3h 2h 40min Completado Documentaci´on del sprint 3h 4h Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 33h 30min 34h 6/7 tareas completadas Tabla 7.5: Tareas del sprint 5. Este sprint se caracteriz´o por el desarrollo de un parser que tratase los archivos .mdl al completo, esto es, haciendo uso de la gram´atica desarrollada en este proyecto. Para su realizaci´on se parti´o de la base del realizado en el sprint anterior, si bien, se modificaron los tests para adaptarlos a las nuevas caracter´ısticas del parser. Como ya se ha explicado en el cap´ıtulo de Dise˜no (y por ello no se profundizar´a en exceso), se obtuvieron problemas creando el parser puesto que al integrar el programa para a˜nadir los comentarios de las vistas a las ecuaciones y un segundo programa cuya funci´on es a˜nadir ciertas l´ıneas delimitadoras para organizar mejor el c´odigo y la estructura de la generaci´on del parser, no se pod´ıa reconstruir correctamente el fichero de entrada a trav´es del YAML generado, pues este hab´ıa sido modificado. La soluci´on fue dividir el proyecto en dos programas: uno que modificase el contenido del fichero y el parser en cuesti´on. En la integraci´on continua, se descubri´o que los errores de diferencia entre los tests local y los de GitLab se deb´ıa a que Windows utiliza el sistema de retorno de l´ınea CRLF yGitLab 85 7.13. SPRINT 10 (03/03/2021 - 17/03/2021) 7.13. Sprint 10 (03/03/2021 - 17/03/2021) La Tabla 7.11 muestra las tareas realizadas en este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Corregir bugs del proyecto 2h 6h 20min Completado Documentaci´on del sprint 2h 50min Completado Sesi´on de profiling con desarrolladores de Plastic SCM 1h 1h 30mih Completado Analizar la eficiencia del parser 2h 0min Completado Prueba de aceptaci´on de usuarios 2h 1h 10min Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 11h 11h 50min 6/6 tareas completadas Tabla 7.11: Sprint 10. Este sprint tuvo una menor carga de tarea, puesto que la reuni´on de profiling para analizar la eficiencia del parser tuvo lugar en la segunda semana del sprint. Pese a ello, si que se realizaron peque˜nas tareas de documentaci´on en la primera semana. Sobre la reuni´on para analizar el rendimiento, se concluy´o que no era un problema de rendimiento, sino un problema de parseo que estaba siendo invisible debido a que el programa utilizaba espera activa para leer los archivos en este punto del proyecto. Esto queda explicado en profundidad en el cap´ıtulo de Implementaci´on y pruebas. A mayores se intent´o buscar posibles bugs en los programas de adici´on y eliminaci´on de delimitadores, pues los usuarios encontraron algunos problemas en la tercera prueba de aceptaci´on de usuarios, la cual realizaron de forma independiente sin ninguna clase de reuni´on y tras la cual comunicaron dichos problemas por correo electr´onico. No obstante, no se encontraron bugs, por lo que se esper´o al siguiente sprint, donde se tendr´ıa una reuni´on donde se explicar´ıan dichos problemas en profundidad. El ´ultimo d´ıa del sprint tuvo lugar la tercera reuni´on de pruebas de aceptaci´on de usuario, aunque en esta ocasi´on, los usuarios ya hab´ıan realizado las pruebas por cuenta propia. Dicha reuni´on fue meramente de aclaraci´on de dudas y explicaci´on de c´omo fueron las pruebas, que en esta ocasi´on, resultaron haber tenido mucho ´exito. En ella se propuso investigar acerca del apartado de metadatos de los archivos .mdl para facilitar su compresi´on a los usuarios. 92 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO 7.14. Resumen del proyecto Tras finalizar el proyecto se ech´o la vista atr´as para comparar las marcas establecidas inicialmente en cuanto a tiempo y dinero, y se sumarizaron todas las horas dedicadas al realizar este Trabajo de Fin de Grado as´ı como las tareas realizadas. 7.15. Sprint 11 (18/03/2021 - Fin de proyecto) La Tabla 7.12 muestra las tareas realizadas en este sprint as´ı como el tiempo invertido en ellas. Tarea Tiempo estimado Tiempo invertido Estado Documentaci´on del sprint 6h 3h Completado Revisi´on de la documentaci´on 4h 1h 45min Completado Sprint planning + sprint review + revisi´on semanal 2h 2h Completado Total 11h 11h 50min 3/3 tareas completadas Tabla 7.12: Sprint 11. Este sprint final se dedic´o a completar la documentaci´on y a revisar la misma en busca de errores o partes que pudiesen mejorarse o completarse. Tambi´en se revis´o el c´odigo realizado para limpiar comentarios, aclarar partes del c´odigo o hacer algunos refactors enfocados a mejorar la legibilidad del mismo. 7.15.1. Calendarizaci´on final Pese a que se fueron cumpliendo las cuotas establecidas en el inicio del proyecto en lo referente al n´umero de sprints, debido a los problemas ocurridos en las pruebas de aceptaci´on de usuarios en el mes de febrero, la finalizaci´on del proyecto se retras´o aproximadamente un mes, que ser´ıa el equivalente a dos sprints. El cambio de horarios del segundo cuatrimestre hizo que dicha tabla se modificara ligeramente en las ´ultimas etapas, al pasar las reuniones semanales del lunes al martes. Por lo tanto, la Tabla de calendarizaci´on final 7.13 termin´o de la siguiente forma: 93 7.15. SPRINT 11 (18/03/2021 - FIN DE PROYECTO) Sprint 0 01/08/2020 - 13/09/2020 Sprint 1 14/09/2020 - 27/09/2020 Sprint 2 28/09/2020 - 11/10/2020 Sprint 3 12/10/2020 - 25/10/2020 Sprint 4 26/10/2020 - 08/11/2020 Sprint 5 09/11/2020 - 22/11/2020 Sprint 6 23/11/2020 - 06/12/2020 Descanso 07/12/2020 - 17/01/2021 Sprint 7 18/01/2021 - 02/02/2021 Sprint 8 03/02/2021 - 17/02/2021 Sprint 9 18/02/2021 - 02/03/2021 Sprint 10 03/03/2021 - 17/03/2021 Sprint 11 18/03/2021 - Fin de proyecto Tabla 7.13: Tabla de calendarizaci´on de sprints final. Tal y como se puede apreciar, el ´ultimo sprint se alarg´o de las dos semanas convencionales pues fue una etapa final dedicada a completar la documentaci´on y a revisar la misma. En cuanto a los riesgos establecidos en un principio, el riesgo que m´as se tem´ıa que ocurriese fue la falta de tiempo, en parte debida a compaginar las cinco asignaturas del primer cuatrimestre con el proyecto. Sin embargo, el hecho de utilizar metodolog´ıas ´agiles en el desarrollo del proyecto y el poder asistir a las clases de forma telem´atica y no gastar tiempo en desplazamientos permiti´o que el proyecto se desarrollase en las fechas previstas con una cantidad de estr´es aceptable. Si que existieron modificaciones en los requisitos o requisitos adicionales, pero por suerte, pudieron asignarse adecuadamente las tareas a los sprints. Muchos de estos nuevos requisitos no requirieron modificaciones del trabajo anterior, por lo que no supusieron demasiados problemas. En cuanto al resto de riesgos, no se produjeron actualizaciones en ninguno de los programas utilizados, por lo que no hubo impacto alguno. Desde un principio se instaur´o el trabajo y las reuniones de forma telem´atica, por lo que tampoco hubieron imprevistos relacionados con el COVID-19. 7.15.2. Trabajo total realizado En la Tabla 7.14 se recopilan las horas y las tareas totales dedicadas a la realizaci´on del proyecto: Trabajo total estimado Trabajo total realizado Total tareas completadas 300h 292h5m 65/65 Tabla 7.14: Trabajo total realizado. 94 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO 7.15.3. Costes reales El coste real se ajusta a la remuneraci´on de la beca, la cual consta de 300 euros brutos durante un periodo de seis meses, por lo que el presupuesto total ser´ıa en un principio de 1800 euros. Sin embargo, debido a que el alumno firm´o un contrato de pr´acticas incompatible con la beca, este renunci´o a la misma desde el mes de febrero, llegando a percibir ´unicamente la remuneraci´on correspondiente a cinco meses. Sin embargo, como el mes de septiembre se comenz´o el trabajo el d´ıa 14, s´olo se percibieron 16 d´ıas de trabajo. Por lo tanto, sin contar descuentos de la Seguridad Social e IRPF, se recibi´o un total de 1350 e. En el caso de la licencia de SemanticMerge, la empresa PlasticSCM decidi´o proporcionar una licencia de usuario para el desarrollo del proyecto de forma totalmente gratuita, por lo que no existieron gastos en este ´ambito. Cabe resaltar que a pesar de que la beca comenzase en Julio (por lo que terminar´ıa en diciembre), el proyecto se inici´o oficialmente el 14 de septiembre, por lo que su duraci´on llegar´ıa hasta el mes de marzo. Adem´as, durante el mes de agosto se realiz´o el sprint 0, el cual consisti´o en documentarse acerca de la realizaci´on del proyecto y en la creaci´on de peque˜nos parsers para familiarizarse con el entorno en que se iba a trabajar. 95 7.15. SPRINT 11 (18/03/2021 - FIN DE PROYECTO) 96 CAP´ ITULO 8. CONCLUSIONES Cap´ıtulo 8 Conclusiones Tras finalizar el proyecto se lograron cumplir todos los objetivos y requisitos iniciales y, adicionalmente, se pudieron cumplir los nuevos requisitos y necesidades que fueron surgiendo a lo largo del desarrollo del proyecto. Este proyecto no ha sido f´acil, puesto que la tarea a realizar era laboriosa y compleja, sin embargo se logr´o finalizar el proyecto cerca de la fecha estimada inicialmente. El proyecto comenz´o en el mes de agosto con una fase preparatoria, pero no fue hasta la segunda quincena de septiembre donde se empez´o verdaderamente el trabajo. Debido a todas las circunstancias ocasionadas por la pandemia del virus COVID-19, el trabajo se realiz´o completamente en remoto. Durante el primer cuatrimestre acad´emico, este trabajo se realiz´o en paralelo con las cinco asignaturas correspondientes al cuarto curso de la menci´on de Ingenier´ıa del Software, y durante el segundo cuatrimestre en paralelo con las pr´acticas de empresa del alumno. En el primer cuatrimestre se concentr´o el grueso del desarrollo del proyecto as´ı como las partes m´as tediosas del mismo, como el desarrollo de la gram´atica o los problemas iniciales para realizar el parser para SemanticMerge. Pese a poder realizar parte del desarrollo en d´ıas de diario, las asignaturas y sus correspondientes pr´acticas hicieron que gran parte del proyecto se realizase en fines de semana. Durante la primera mitad del segundo cuatrimestre tuvo lugar una fase m´as relajada destinada a la refactorizaci´on, correcci´on de bugs y pruebas de usuario, y a pesar de realizarse en paralelo con las pr´acticas de empresa, esta parte se realiz´o con mucho menos estr´es y presi´on que en el primer cuatrimestre. Pese a todas las dificultades ocasionadas por la pandemia, se consigui´o lograr un ritmo de trabajo constante y muy productivo, en gran medida gracias a utilizar metodolog´ıas ´agiles en el desarrollo, concretamente Scrum. Las reuniones semanales para marcar objetivos y revisar el trabajo realizado fueron de gran ayuda para conseguir realizar gran parte del proyecto en el primer cuatrimestre. Modularizar lo m´aximo posible el proyecto y dividirlo en sprints y a su vez en issues o tareas del sprint lograron que la presi´on general disminuyera al poder centrarse en tareas m´as peque˜nas en vez de en un gran todo global. Existieron dos puntos principales en el desarrollo del proyecto donde se encontraron las dificultades m´as relevantes. El primer punto fue en el inicio del programa, pues el alumno no 97 8.1. L´ INEAS DE TRABAJO FUTURAS hab´ıa trabajado nunca con ANTLR4, y pese a tener conocimientos b´asicos sobre gram´aticas como lex oyacc, completar la gram´atica de partida para que incluyese tambi´en las definiciones de vistas, gr´aficos y metadatos fue un proceso muy laborioso y tedioso, con una gran cantidad de archivos de prueba para asegurarse de que la gram´atica era correcta. El segundo punto de dificultad fue aproximadamente en los inicios del mes de noviembre, donde se comenz´o el desarrollo del parser y con ello se tuvieron las primeras dificultades reales con SemanticMerge. Pese a haber desarrollado varios parsers sencillos durante el mes de agosto como preparatoria para realizar este trabajo, las dimensiones y complejidades del proyecto dieron lugar a problemas no conocidos con los que hubo que lidiar. Cabe resaltar tambi´en dos grandes aciertos a la hora de plantear el proyecto. El primero se ha comentado anteriormente, y es el hecho de dedicar el mes de agosto previo al comienzo del proyecto a investigar acerca de Vensim,ANTLR4 ySemanticMerge y crear peque˜nos parsers funcionales. Pese a que posteriormente s´ı que existieron problemas relacionados con estos tres programas, hubieran sido mucho mayores de no ser por ese mes preparatorio. El segundo acierto fue realizar la memoria del proyecto en paralelo al trabajo realizado durante todos los sprints en vez de dejarlo todo para el final. Aparte de lograr una carga de trabajo m´as equilibrada, los conceptos explicados estar´ıan m´as recientes que si se hubiesen explicado ciertas partes del proyecto meses despu´es de su desarrollo. 8.1. L´ıneas de trabajo futuras Pese a que el proyecto es completo, existen ciertos puntos que podr´ıan ser objeto de mejora en un futuro: Mejorar el parser para no depender de delimitadores. Pese a que el parser es funcional gracias a estos delimitadores, podr´ıa ser posible no depender de ellos si se idease un patr´on o forma de conseguir separar las vistas y los gr´aficos, tanto entre ellos como entre s´ı. Intentar ampliar el parser para que abarque mayor cantidad de caracteres especiales. Pese a que la herramienta soporta acentos y similares en UTF-8, se podr´ıa apuntar a utilizar otro sistema de codificaci´on como UTF-16. Obtener m´as informaci´on acerca de los metadatos. Pese a que otras secciones como los sketches o los gr´aficos tienen soporte online sobre la informaci´on de los mismos, esto no es as´ı con los metadatos, y se debe obtener su significado mediante la comparaci´on entre diferentes archivos. Es una tarea laboriosa, pero podr´ıa ser informaci´on muy ´util para los modeladores de Vensim. Diferenciar campos de las l´ıneas de definici´on de variables en las vistas. Pese a que el programa actual diferencia las l´ıneas de definici´on de variable de las vistas y todo su significado se encuentra en los Manuales de Usuario de esta memoria, as´ı como en internet, podr´ıa intentarse separar cada campo individual de las l´ıneas de las vistas para hacer a´un m´as precisa la herramienta. 98 CAP´ ITULO 8. CONCLUSIONES Mejorar la captura de errores en caso de que la gram´atica falle. Existen ciertos casos donde SemanticMerge se queda en segundo plano al ocurrir un error interno por parte de un fallo de procesamiento de la gram´atica. No deber´ıa ocurrir casi con toda seguridad, pero actualizaciones de Vensim o similares puede que aumenten dicha probabilidad. Ampliar el proyecto con futuras actualizaciones de Vensim. Es posible que futuras actualizaciones de Vensim incluyan nuevos elementos que la gram´atica no es capaz de procesar. En este caso se deber´ıa de actualizar la gram´atica as´ı como el parser. Esto queda explicado en el Anexo de Manual de Mantenimiento. 99 8.1. L´ INEAS DE TRABAJO FUTURAS 100 AP´ ENDICE A. MANUALES Ap´endice A Manuales A.1. Manual de instalaci´on A.1.1. Prerrequisitos Se requiere contar con: Windows 10, arquitectura de 64 bits. 1 Java (versi´on 8 o superior) JRE. No es necesario el JDK. En el caso de utilizar tags en gmaster, se debe contar con la versi´on 0.9.289 o superior de gmaster [19]. En el caso de que se desee que para las diferencias entre versiones de archivos Excel, gmaster lance SpreadSheet Compare tool, se debe contar con la versi´on 1.0.663 o superior de gmaster [19]. Los archivos Vensim a procesar deben estar codificados en el formato de espaciado propio de Windows, es decir, CRLF. Se debe tener en cuenta que si se va a utilizar Vensim, se deber´a tener cuidado no manipular con la distribuci´on DSS archivos creados con la distribuci´on PLE, y viceversa. A.1.2. Descarga del software La soluci´on desarrollada consta de tres archivos .jar que deber´an descargarse de: 1Para comprobar la arquitectura del sistema: https://www.computerhope.com/issues/ch001121.htm#: ~:text=Press%20and%20hold%20the%20Windows,running%20the%2064%2Dbit%20version. 101 A.2. MANUAL DE USUARIO Figura A.6: Pantalla principal de la interfaz de adici´on de nombres de las vistas y delimitadores. al usuario a trav´es de un mensaje con un llamativo color rojo. En caso de seleccionarse un archivo al que ya se la han a˜nadido los nombres de las vistas y los delimitadores, tambi´en se indicar´a al usuario con un mensaje. Una vez cargado el archivo, se debe pulsar el bot´on de la izquierda, Process, el cual proceder´a a modificar el archivo y a conservar el backup del original con la extensi´on .2mdl. Cuando haya finalizado el proceso, se notificar´a al usuario con un mensaje en color verde. En caso de haber seleccionado un archivo que no era el deseado, se podr´a hacer uso del bot´on de Cancel para volver a la pantalla inicial (Figura A.6). Para permitir al usuario que pueda comprobar la ruta completa del archivo que ha seleccionado, se cuenta con el bot´on Show absolute path. Al pulsar la primera vez en dicho bot´on, se mostrar´a dicha ruta. Pulsando de nuevo en el mismo bot´on, se recuperar´a la vista del nombre del archivo sin ruta. Finalmente, y con el objetivo de hacer la experiencia de usuario m´as clara y concisa, se explicar´a en la parte inferior del nombre del archivo seleccionado qu´e efecto tiene procesar el archivo con este programa. Las dos interfaces gr´aficas de los programas AddViewNamesAndDelimiters yEraseViewNamesAndDelimiters son pr´acticamente id´enticas, por lo que se debe comprobar el nombre de la etiqueta del programa. A.2.2. El plugin de Vensim para SemanticMerge dentro de gmaster Una vez el(los) archivo(s) .mdl deseado(s) son modificados a˜nadiendo los nombres de las vistas en la descripci´on de las ecuaciones y los delimitadores de las partes de un .mdl, se 108 AP´ ENDICE A. MANUALES Figura A.7: Pantalla secundaria de la interfaz de adici´on de nombres de las vistas y delimitadores. deber´an asentar sus cambios en el repositorio mediante un commit (ver flujos de trabajo explicados en las Figuras A.4 y A.5). Es importante modificar los archivos con el “Adder”, puesto que sin ello gmaster no ser´a capaz de reconocer los archivos sem´anticamente, sino ´unicamente como texto plano. Es decir, se conservar´a la capacidad de lectura convencional de la herramienta, pero no se aplicar´an las mejoras que aporta el plugin para SemanticMerge. Ya sea en el flujo descrito para realizar fusi´on de ramas (merge), o en el descrito para permitir la visualizaci´on de diferencias entre commits en la misma rama, gmaster detectar´a que la extensi´on del archivo es .mdl y utilizar´a la herramienta externa VensimPlugin4SemanticMerge para realizar el an´alisis sem´antico. La herramienta nos mostrar´a las diferencias entre los dos archivos, proporcion´andonos informaci´on sobre qu´e significa cada l´ınea modificada. La Figura A.9 muestra las diferentes partes de la interfaz gr´afica de gmaster. En la primera secci´on se˜nalada con un recuadro rojo y el n´umero 1, podemos observar la primera nueva caracter´ıstica que a˜nade la herramienta. En esta secci´on se puede observar el recuento de cambios entre dos versiones de un mismo archivo. Como se puede ver en la figura, los cambios se distinguen en cinco apartados principales. Dentro de cada una de estas categor´ıas de cambios, a su vez podemos distinguir el tipo del elemento modificado como puede ser una ecuaci´on y una vista, as´ı como su nombre. Los distintos tipos de cambios se explican a continuaci´on: Adiciones. Se ha a˜nadido un nuevo elemento al archivo. Est´a representado por una letra Ade color verde, representando added en ingl´es. Modificaciones. Un elemento del archivo ha sido modificado. Est´a representado por una letra Cde color azul, representando changed en ingl´es. Eliminaciones. Se ha eliminado un elemento del archivo. Est´a representado por una letra Dde color rojo, representando deleted en ingl´es. 109 A.2. MANUAL DE USUARIO Movimientos. Se ha movido un elemento del archivo dentro del formato textual del mismo. Est´a representado por una letra Mde color morado, representando moved en ingl´es. Renombres. Se ha cambiado el nombre de un elemento del archivo. Est´a representado por una letra Rde color morado, representando renamed en ingl´es. Estas clases de modificaciones se pueden apreciar con mayor claridad en la siguiente figura, A.8: Figura A.8: Tipos de cambios en gMaster y SemanticMerge. En la segunda secci´on se˜nalada con un recuadro rojo y el n´umero 2, se observan las dos versiones del archivo que se est´a analizando, mostrando en la parte izquierda la versi´on m´as antigua y en la derecha la actual (en el caso de un merge se mostrar´ıa la versi´on de la rama de origen y la versi´on de la rama de destino). Se observan franjas coloreadas que relacionan los cambios visualmente entre ambas versiones del archivo. Al lado de cada cambio aparece una inicial, la cual indicar´a la categor´ıa de modificaci´on de entre las cinco posibles explicadas anteriormente. El recuadro en color azul etiquetado con 2.1 (en la parte de abajo de la secci´on 2), sirve para cambiar entre el modo convencional de diferencias entre versiones con texto plano, y el modo sem´antico propio de SemanticMerge. El segundo recuadro en color azul etiquetado con 2.2, permite ver los cambios de una forma m´as compacta y visual, utilizando ´unicamente los grafismos asociados a las cinco categor´ıas posibles de modificaciones. En la Figura A.10 se muestra el resultado de seleccionar esa forma de visualizar las diferencias. Por ´ultimo, en la tercera secci´on se aprecian los archivos modificados en la versi´on del proyecto o commit seleccionado. 110 AP´ ENDICE A. MANUALES Figura A.9: Interfaz de gmaster y sus correspondientes partes. Figura A.10: Visualizaci´on de diferencias entre versiones de un .mdl basada en grafismos. A.2.3. El programa auxiliar EraseViewNamesAndDelimiters El programa EraseViewNamesAndDelimiters.jar modifica los archivos Vensim a los que se les haya a˜nadido nombres de vistas en la descripci´on de las ecuaciones, y delimitadores de las partes de un .mdl (resultado de modificar un archivo .mdl con el programa 111 A.2. MANUAL DE USUARIO AddViewNamesAndDelimiters), eliminando todo lo que se le haya a˜nadido extra. Seg´un el flujo de trabajo de fusi´on de ramas, una vez tengamos la rama fusionada y hecho el commit de merge, debemos utilizar EraseViewNamesAndDelimiters y de esta forma, los archivos vuelven a ser visibles y modificables con Vensim. De no hacerlo, no se podr´a abrir correctamente el archivo con la interfaz gr´afica de Vensim. Esto mismo sucede si el flujo de trabajo es el que se utilizar´ıa para ayudar a visualizar las diferencias entre dos versiones de un .mdl en la misma rama, hay que volver siempre a un .mdl legible por Vensim para poder continuar con el trabajo de programaci´on de los modelos. La interfaz se comporta igual que la explicada con el primer programa auxiliar (AddViewNamesAndDelimiters). Se recuerda que son pr´acticamente id´enticas, por lo que se debe comprobar el nombre de la etiqueta del programa. La explicaci´on textual del efecto del bot´on Process tambi´en pretende ayudar en esta diferenciaci´on. EraseViewNamesAndDelimiters tambi´en se encarga de generar autom´aticamente un archivo (con extensi´on .2mdl) a modo de backup antes de realizar modificaciones. Pero en este caso lo llamar´a a˜nadiendo la palabra Delimiter al nombre del archivo original (NombreDeArchivoDelimiter.2mdl) para no reemplazar el backup creado con AddViewNamesAndDelimiters. El archivo una vez modificado, conservar´a tanto el nombre como la extensi´on originales. Las Figuras A.11 y A.12 muestran las pantallas de EraseViewNamesAndDelimiters. Figura A.11: Pantalla principal de la interfaz de eliminaci´on de delimitadores. Es muy ´util en el repositorio git a˜nadir el archivo .gitignore indicando que los archivos de backup no se tengan en cuenta en el control de versiones. El siguiente cuadro de texto muestra el contenido de .gitignore t´ıpico para un proyecto de programaci´on de modelos con Vensim: # Be careful and do not name an important file with temporal file extension *.tmp 112 AP´ ENDICE A. MANUALES Figura A.12: Pantalla secundaria de la interfaz de eliminaci´on de delimitadores. # Word temporary ~$*.doc* # Word Auto Backup File Backup of *.doc* # Excel temporary ~$*.xls* # Excel Backup File *.xlk # Vensim mdl Backup File *.2mdl # Vensim simulation *.vdf A.2.4. Par´ametros de las l´ıneas de definici´on de variables en las vistas. Aunque muchos de los par´ametros de las l´ıneas asociadas a las variables en la parte de definici´on de las vistas son triviales, es importante poder conocer qu´e representan cada uno de los campos de dichas l´ıneas. Podemos diferenciar dos claras estructuras diferentes [54]. Los campos de las variables marcados con (*) se han considerado no triviales e importantes a tener en cuenta a la hora de resolver un conflicto, ya que contienen datos importantes en la estructura de la vista y no son simples par´ametros que configuran aspectos triviales del dise˜no como pueden ser el color o la forma de una variable: 113 A.2. MANUAL DE USUARIO Variables. Esta estructura representa las variables, incluyendo sus variaciones como las variables sombra. Tambi´en se incluye en este grupo a las v´alvulas o valves y a los comentarios. Se componen de: •1. n →C´odigo num´erico que indica el tipo de variable. Los c´odigos 1, 10, 11 y 12 representan a flechas, variables, valves y comentarios respectivamente (*). •2. id →C´odigo num´erico ascendente que indica la posici´on respecto a otras variables en que se introdujo la variable a la vista (*). •3. name →Nombre de la variable. Si fuese un ’0’, el nombre de la variable aparecer´ıa aislado en la l´ınea siguiente. En el caso de las valves ser´a un n´umero irrelevante para el usuario y en el caso de los comentarios ser´a un n´umero que represente a la figura del comentario. En el caso de variables triviales, su campo es trivial, valga la redundancia (*). •4,5. x, y →Posici´on de la variable en el plano (*). •6,7. w, h →Ancho y alto de la variable en el plano (*). •8. sh →Forma alrededor de la palabra y caracter´ısticas relativas. Estas se disponen en un conjunto de bits que es representado en forma decimal. •9. bits →Conjunto de bits que indica si pueden entrar y/o salir flechas de la variable (*). •10. hid →Indica si la variable est´a oculta. Un valor distinto de cero indica el nivel de oculta en que se encuentra la variable. (*) •11. hasf →Indica si la variable tiene una fuente de texto especial. •12. tpos →Indica la posici´on del texto respecto a la forma que encierra la variable. •13. bw →Indica el ancho del borde de la caja o forma que rodea a la variable. •14. nav1 →Indica el n´umero de vista al que puede redireccionar la variable. •15. nav2 →En el caso de que haya m´as de 255 vistas, el n´umero de vista pasa a calcularse con: nav1 + 256 ∗nav2. •16. box →Color del borde de la caja o forma que rodea a la variable. •17. fill →Color de relleno de la caja o forma que rodea a la variable. •18. font →Tipograf´ıa de la variable. •19-24. Constantes num´ericas desconocidas. •25. visualInfo →Campo utilizado para anexar el nombre de la variable en caso de estar definido en la l´ınea siguiente. Flechas. Esta estructura representa las uniones y relaciones entre el resto de variables. Se componen de: •1. n →C´odigo num´erico que indica el tipo de variable. En las flechas o arrows siempre ser´a 1 (*). •2. id →C´odigo num´erico ascendente que indica la posici´on respecto a otras variables en que se introdujo la variable a la vista (*). •3,4. from, to →Ids de las variables de donde sale la flecha y a donde llega respectivamente (*). 114 AP´ ENDICE A. MANUALES •5. shape →Forma de la flecha (l´ınea recta, curvada...etc). •6. hid →Indica si la flecha est´a oculta. Un valor distinto de cero indica el nivel de oculta en que se encuentra la flecha (*). •7. pol →Indica la polaridad de la flecha. •8. thickness →Indica el grosor de la flecha. Un valor de m´as de 20 unidades indica que la flecha utiliza dos l´ıneas paralelas. •9. hasf →Indica cambios en el color y fuente que la vista trae como predeterminados. •10. dtype →Indica el delay de la flecha. •11. res →Valor reservado, deber´ıa ser 0. •12. color →Color de la flecha o ”−1− −1− −1”. •13. font →Fuente o color de la flecha. Este campo puede permanecer vac´ıo. •14,15. nc, pointlist →El primer valor representa el n´umero de puntos intermedios que tiene la flecha. El segundo valor es la vista de las coordenadas de dichos puntos intermedios (*). En el caso de el apartado catalogado como “metadatos”, esta secci´on apenas var´ıa y su tama˜no es muy reducido en comparaci´on del tama˜no total del fichero .mdl. No parece existir documentaci´on sobre esta ´ultima parte, pero son l´ıneas referentes a la configuraci´on del archivo y similares. Debido a su peque˜no tama˜no y que la gram´atica permite separar l´ınea por l´ınea este apartado, se considera que no deber´ıa generar problemas de comprensi´on. No obstante, se enumeran a continuaci´on ciertas l´ıneas identificadas con su correspondiente significado: Las l´ıneas que comienzan por 1indican archivos de simulaciones. La l´ınea que empieza por 5indica la ´ultima variable seleccionada. Existen l´ıneas que simbolizan los par´ametros de configuraci´on del archivo global. A.2.5. Advertencias sobre posibles cambios que puede realizar el programa Vensim en los ficheros Se listan a continuaci´on una serie de advertencias acerca del funcionamiento de las herramientas de SemanticMerge ygMaster sobre c´omo pueden llegar a afectar al formato textual de los archivos .mdl: En la parte donde se listan las variables asociadas a una vista, uno de los par´ametros de cada variable es su orden de aparici´on en el texto. Por ello, ciertas acciones como eliminar una variable o moverla de vista, modificar´an todas las l´ıneas que representan a variables en esa vista con un orden de aparici´on mayor. 115 A.2. MANUAL DE USUARIO Ciertas acciones provocan que se inserten o eliminen l´ıneas de metadatos en el final del archivo. Al mover variables entre vistas, la definici´on de la variable en la parte de ecuaciones aparecer´a como cambio, sin embargo, en la parte de definici´on en las vistas aparecer´a como eliminaci´on en la vista anterior e inserci´on en la nueva. En ciertas ocasiones, Vensim transforma la definici´on de una ecuaci´on de forma extendida (en tres l´ıneas) a forma compactada (una ´unica l´ınea) y viceversa. Borrar una vista sin borrar previamente las variables de dicha vista hace que las variables no se eliminen y queden como variables vac´ıas en el formato textual del archivo. En ciertas ocasiones, Vensim aumenta el n´umero de par´ametros de una variable, generalmente con par´ametros con valor cero. En ciertas ocasiones, mover variables modifica ciertos elementos que Vensim denomina v´alvulas. Eliminar ciertas partes de un modelo que hagan que el modelo no sea correcto respecto al funcionamiento de Vensim puede acarrear problemas en la definici´on de algunas variables. En el caso de las variables num´ericas como comentarios o valves, el campo del nombre lleva un valor num´erico asignado que seg´un la documentaci´on oficial, debe de ser ignorado [53]. Este valor cambia tras realizar ciertas operaciones como adiciones o eliminaciones de elementos. El renombrado de variables se debe de hacer desde el modo gr´afico de Vensim. En caso de realizarlo desde el modo textual, se debe cambiar el nombre en la definici´on de las ecuaciones y en su aparici´on en su vista concreta. Abrir el fichero con otra versi´on de Vensim puede provocar movimientos o redimensiones que pueden provocar una gran cantidad de cambios al alterar los par´ametros de posici´on de muchas variables y/o flechas. A.2.6. Advertencias sobre el nombrado de variables Existen ciertas formas de nombrar a las variables que hacen que el programa falle, consecuencia de una mala formaci´on del ´arbol descriptor del fichero en el archivo YAML o ciertos caracteres especiales no soportados por el sistema de codificaci´on del proyecto, UTF-8. Los nombrados de variable que causan o pueden llegar a causar problemas son los siguientes: Utilizar el car´acter ’:’ seguido de un espacio en blanco. Acabar el nombre de la variable en uno o varios espacios en blanco. Utilizar comillas, salvo en los casos en los que las comillas envuelvan todo el nombre de la variable. Se recomienda utilizar comillas dobles. Utilizar caracteres especiales no soportados. 116 AP´ ENDICE A. MANUALES A.2.7. Enlaces de inter´es En caso de querer conocer m´as acerca del funcionamiento espec´ıfico de SemanticMerge, PlasticSCM y/o gMaster o c´omo ambas herramientas incorporan herramientas o parsers externos, se recomienda consultar [27], [37], [39], [40], [43], [47], [53] y [54] en la bibliograf´ıa del proyecto. A.3. Manual de mantenimiento En esta secci´on se explican ciertos aspectos y pautas a seguir para posibles futuros desarrolladores que vayan a realizar labores de mantenimiento o de actualizaci´on en caso de que algunos de los programas utilizados reciba alguna actualizaci´on importante que haga a este proyecto obsoleto. A.3.1. Actualizaci´on de la gram´atica y del parser Existe la posibilidad de que se produzca una actualizaci´on de Vensim que incluya nuevos elementos de gran importancia y que mejoren el proceso de modelar sistemas, y que al ser algo nuevo, el proyecto no sea capaz de reconocer dichos elementos y por lo tanto no funcione. Los pasos a seguir ser´ıan los siguientes: Actualizaci´on de la gram´atica ANTLR4 Inicialmente se deber´ıa ampliar la gram´atica existente con las nuevas incorporaciones, con cuidado de no inducir fallos en la gram´atica de partida. Como ANTLR4 no tiene una forma sencilla de realizar tests autom´aticos, se recomienda probar con una variedad de archivos que tengan estructuras diferentes. Se pueden encontrar ejemplos en la carpeta VensimExampleModels en el repositorio del proyecto. Para hacer m´as f´acil el proceso de depuraci´on de errores se recomienda imprimir el ´arbol sem´antico generado, bien por salida est´andar de consola o por interfaz gr´afica. En el caso de salida por consola bastar´ıa con la l´ınea de c´odigo: System.out.println(tree.toStringTree(parser)); En el caso de salida por interfaz gr´afica ser´ıa: JFrame frame = new JFrame("Antlr AST"); JPanel panel = new JPanel(); TreeViewer viewer = new TreeViewer(Arrays.asList(parser.getRuleNames()), 117 BIBLIOGRAF´ IA [13] Norberto Figuerola. Riesgos: Plan de Mitigaci´on vs Plan de Contingencia vs Fallback Plan. https://articulospm.files.wordpress.com/2015/06/riesgos-planmitigacion-vs-plan-contingencia-vs-fallback-plan.pdf, 2015. Accesed: 20209-26. [14] Tobi G. Java Special Characters in RegEx. https://stackoverflow.com/question s/14134558/list-of-all-special-characters-that-need-to-be-escaped-in-aregex, 2019. Accesed: 2020-11-11. [15] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: Abstraction and reuse of object-oriented design. In European Conference on ObjectOriented Programming, pages 406–431. Springer, 1993. [16] Research Gate. LOCOMOTION H2020. https://www.locomotion-h2020.eu/, 2020. Accesed: 2020-9-16. [17] Research Gate. MEDEAS. https://www.medeas.eu/#home, 2020. Accesed: 2020-9-16. [18] GitLab.org. GitLab. https://gitlab.com/gitlab-org, 2020. Accesed: 2020-9-23. [19] gMasterRealeaseNotes. release notes. [20] Object Management Group. Unified Modeling Language. https://www.uml.org/, 2021. Accesed: 2021-11-02. [21] James P. Houghton. test-models. https://github.com/SDXorg/test-models, 2020. Accesed: 2020-9-30. [22] Joel Francia Huambachano. ¿Qu´e es Scrum? https://www.scrum.org/resources/bl og/que-es-scrum, 2017. Accesed: 2021-22-01. [23] Change Vision Inc. Astah Professional. https://astah.net/products/astahprofessional/, 2021. Accesed: 2021-11-02. [24] La informaci´on. ¿Cu´al es el coste real de tener un trabajador para una empresa? https: //www.lainformacion.com/practicopedia/cual-es-el-coste-real-de-untrabajador-para-una-empresa/6491464/#:~:text=Cotizaciones%20a%20la%20Seg uridad%20Social,26.300%20euros%20a%20la%20empresa., 2019. Accesed: 2020-9-26. [25] Jitsi.org. Jitsi Meet. https://meet.jit.si/, 2020. Accesed: 2020-9-23. [26] Bart Kiers. If/else statements in ANTLR using listeners. https://stackoverflow. com/questions/15610183/if-else-statements-in-antlr-using-listeners, 2013. Accesed: 2020-9-15. [27] Sergio L. Using external parsers with gMaster. http://blog.gmaster.io/2018/03/us ing-external-parsers-with-gmaster.html, 2018. Accesed: 2020-14-11. [28] Pablo Santos Luaces. charposition. https://github.com/PlasticSCM/charposition, 2016. Accesed: 2020-31-10. [29] Pablo Mart´ınez L´opez. Gram´atica en ANTLR4 para Vensim. https://gitlab.inf.u va.es/pamarti/proyecto-tfg/-/blob/master/src/main/antlr4/es/uva/inf/gram mar/Grammar.g4, 2020. Accesed: 2020-9-29. 124 BIBLIOGRAF´ IA [30] Pablo Mart´ınez L´opez. SimpleJavaParser-SemanticMerge. https://github.com/Hyl ianPablo/SimpleJavaParser-SemanticMerge, 2020. Accesed: 2020-9-29. [31] McGraw-Hill. Business Dynamics. http://www.mhhe.com/business/opsci/sterman/ models.mhtml, 2001. Accesed: 2020-9-30. [32] Microsoft. Visual Studio Code. https://code.visualstudio.com/, 2020. Accesed: 2020-9-23. [33] migraciones y seguridad social Ministerio de trabajo. Bolet´ın Oficial del Estado. III. Otras disposiciones. https://www.boe.es/boe/dias/2019/06/03/pdfs/BOE-A-20198222.pdf, 2019. Accesed: 2020-9-26. [34] MiryamGSM. External parser sample. https://github.com/PlasticSCM/externalparser-sample/tree/master-SCM20098, 2017. Accesed: 2020-8-28. [35] picodotdev. C´omo ejecutar un proceso del sistema con Java. https://picodotdev.g ithub.io/blog-bitix/2016/03/como-ejecutar-un-proceso-del-sistema-conjava/, 2016. Accesed: 2020-16-12. [36] PlasticSCM. SemanticMerge pricing. https://users.semanticmerge.com/Checkout, 2020. Accesed: 2020-9-26. [37] Plastic SCM. gMaster - Git GUI. https://gmaster.io/, 2021. Accesed: 2021-21-01. [38] Shodor. Vensim models. http://shodor.org/talks/ncsi/vensim/, 2005. Accesed: 2020-9-19. [39] C´odice Software. Custom languages in semantic version control. http://blog.plastic scm.com/2015/09/custom-languages-in-semantic-version.html, 2015. Accesed: 2021-15-02. [40] C´odice Software. External parsers. https://semanticmerge.com/documentation/ex ternal-parsers/external-parsers-guide, 2016. Accesed: 2020-9-19. [41] C´odice Software. Advanced version control - Pocket guide. https://www.plastics cm.com/documentation/advanced-version-control-guide#two-way-merge, 2020. Accesed: 2020-9-17. [42] C´odice Software. Cygnus Solutions. https://www.cygwin.com/, 2020. Accesed: 2021-24-02. [43] C´odice Software. SemanticMerge 2.0. https://semanticmerge.com/, 2020. Accesed: 2020-7-11. [44] C´odice Software. SemanticMerge features. http://www.semanticmerge.com/features, 2020. Accesed: 2020-9-17. [45] C´odice Software. SemanticMerge intro guide. https://semanticmerge.com/document ation/intro-guide/semanticmerge-intro-guide, 2020. Accesed: 2020-9-17. [46] C´odice Software. XDiff and XMerge. https://www.plasticscm.com/features/xmer ge, 2020. Accesed: 2020-9-17. 125 BIBLIOGRAF´ IA [47] C´odice Software. PlasticSCM. https://www.plasticscm.com/?utm source=plastics cm-blog&utm medium=blog-info&utm content=whoweare, 2021. Accesed: 2021-15-02. [48] C´odice Software. PlasticSCM - The Distributed Version Control for Big Projects. https: //www.plasticscm.com/, 2021. Accesed: 2021-2-10. [49] Sonarqube. Code Quality and Code Security. https://www.sonarqube.org/, 2021. Accesed: 2021-27-02. [50] Saumitra Srivastav. Antlr4 - Visitor vs Listener Pattern. https://saumitra.me/blog /antlr4-visitor-vs-listener-pattern/, 2017. Accesed: 2020-9-18. [51] Johannes Link Matthias Merdes Marc Philipp Juliette de Rancourt Christian Stein Stefan Bechtold, Sam Brannen. JUnit 5 User Guide. https://junit.org/junit5/doc s/current/user-guide/, 2020. Accesed: 2020-23-12. [52] Ventana Systems. Defined and shadow variables. https://www.vensim.com/documen tation/22890.htm, 2020. Accesed: 2020-10-6. [53] Ventana Systems. Sketch Information. https://www.vensim.com/documentation/r ef sketch format.html, 2020. Accesed: 2021-2-21. [54] Ventana Systems. Sketch Objects. https://www.vensim.com/documentation/index .html?23275.htm, 2020. Accesed: 2020-10-3. [55] Ventana Systems. Variable types. https://www.vensim.com/documentation/ref var iable types.htm, 2020. Accesed: 2020-9-16. [56] Ventana Systems. Vensim. https://vensim.com/, 2020. Accesed: 2020-23-12. [57] Ej Technologies. Java Profiler - JProfiler. https://www.ej-technologies.com/produ cts/jprofiler/overview.html, 2021. Accesed: 2021-24-02. [58] Linus Torvalds. Git. https://git-scm.com/, 2020. Accesed: 2020-9-23. [59] TutorialsPoint. Compiler Design - Symbol Table. https://www.tutorialspoint.c om/compiler design/compiler design symbol table.htm#:~:text=Symbol%20ta ble%20is%20an%20important,synthesis%20parts%20of%20a%20compiler., 2020. Accesed: 2020-10-7. [60] Wangdq. How to Display ANTLR Tree GUI. https://stackoverflow.com/question s/23809005/how-to-display-antlr-tree-gui, 2014. Accesed: 2020-9-24. [61] Wikipedia. Swing (biblioteca gr´afica). https://es.wikipedia.org/wiki/Swing (bi blioteca gr%C3%A1fica), 2021. Accesed: 2021-20-01. 126