Testeo de modelos orientados a líneas de producto

TESTEO DE MODELOS ORIENTADO A LÍNEAS DE PRODUCTO MODEL TESTING BASED ON PRODUCT LINES TRABAJO FIN DE GRADO CURSO 2023-2024 AUTOR RAFAEL ALONSO GARCÍA DIRECTOR MARÍA ELENA GÓMEZ MARTÍNEZ JOSÉ IGNACIO REQUENO JARABO GRADO EN INGENIERÍA SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID ii iii TESTEO DE MODELOS ORIENTADO A LÍNEAS DE PRODUCTO MODEL TESTING BASED ON PRODUCT LINES TRABAJO DE FIN DE GRADO EN INGENIERÍA DE SOFTWARE AUTOR RAFAEL ALONSO GARCÍA DIRECTOR MARÍA ELENA GÓMEZ MARTÍNEZ JOSÉ IGNACIO REQUENO JARABO CONVOCATORIA: JUNIO 2024 GRADO EN INGENIERÍA DE SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 27 DE MAYO DE 2024 iv v AGRADECIMIENTOS A mis tutores Elena e Ignacio por la ayuda y guía constante para la elaboración del TFG y ampliar mis conocimientos en la finalización del grado. Tanto el testeo de modelos como las líneas de producto son conceptos que no los vi con anterioridad, por lo que siempre es de agradecer aprender cosas nuevas y que añadan utilidad para futuros proyectos. vi RESUMEN Testeo de modelos orientados a líneas de producto A partir de un metamodelo, se pretende formalizar y analizar un modelo recibido, con el fin de validarlo con respecto a dicho metamodelo y asegurarnos de su correcto funcionamiento Palabras clave Ingeniería Orientada a Modelos, Pruebas, EMF, metamodelo, Líneas de Producto, redes de Petri vii ABSTRACT Title Given a metamodel from a different project, the goal is to formalize and analyze another model received. That way we can validate the previous metamodel and make sure that it works as intended. Keywords Model, testing, emf, metamodeling, product lines. viii Tabla de contenido 1 Introducción .................................................................................................................................... 1 1.1 Motivación .............................................................................................................................. 1 1.2 Objetivos ................................................................................................................................. 2 1.3 Plan de Trabajo ....................................................................................................................... 2 1.4 Estructura de la memoria ....................................................................................................... 4 2 Introduction .................................................................................................................................... 5 2.1 Motivation ............................................................................................................................... 5 2.2 Goals ....................................................................................................................................... 6 2.3 Work Plan ................................................................................................................................ 6 2.4 Report structure ...................................................................................................................... 7 3 Conceptos previos ........................................................................................................................... 9 3.1 MDE ......................................................................................................................................... 9 3.2 DSL: Domain Specific Language ............................................................................................ 10 3.3 Variabilidad ........................................................................................................................... 11 3.4 Feature Models ..................................................................................................................... 12 3.5 Redes de Petri ....................................................................................................................... 13 3.6 PNPL ...................................................................................................................................... 14 4 Herramientas utilizadas ................................................................................................................ 15 4.1 GUI ........................................................................................................................................ 16 4.1.1 GraphWalker ................................................................................................................. 16 4.1.2 GraphStream ................................................................................................................. 17 4.2 Lectura de datos.................................................................................................................... 17 4.2.1 Acceleo .......................................................................................................................... 17 4.3 IDE ......................................................................................................................................... 18 4.3.1 Intellij ............................................................................................................................ 18 4.3.2 Visual Studio Code ........................................................................................................ 19 4.3.3 Log4j .............................................................................................................................. 19 5 Implementación ............................................................................................................................ 20 5.1 Inicialización del proyecto ..................................................................................................... 21 5.2 Controller .............................................................................................................................. 22 5.3 Parser .................................................................................................................................... 22 5.4 Utils ....................................................................................................................................... 23 5.5 Tester .................................................................................................................................... 23 ix 5.6 Clases de elementos ............................................................................................................. 24 5.6.1 PNPL .............................................................................................................................. 24 5.6.2 Node .............................................................................................................................. 24 5.6.3 Relation ......................................................................................................................... 24 5.6.4 Place .............................................................................................................................. 25 5.6.5 Transition ...................................................................................................................... 25 5.6.6 Arc ................................................................................................................................. 25 5.6.7 Viewer ........................................................................................................................... 25 6 Conclusiones y Trabajo a futuro ................................................................................................... 27 7 Conclusions and Future Work ....................................................................................................... 29 8 Referencias .................................................................................................................................... 31 Apéndice A: Instalación ......................................................................................................................... 33 6 A metamodel is the model of a model; it contains the structure and logic that the model is based on. To make sure that a model is built correctly, it is necessary that said model works accordingly to all metamodel features; that’s why, to validate models, a metamodel will always be mandatory [1]. 2.2 Goals Con este trabajo, se pretende encontrar una forma de extraer la información de los modelos y metamodelos, analizarla y validar que dicha información sea la adecuada y no entre en conflicto con el metamodelo; en caso contrario, se indicarán dichos errores. The main goal of this project is to find a way to extract the information out of models and metamodels, to analyze it and to make sure that the data is valid; otherwise, all errors will be displayed: That is why we can divide the main goal in several objectives: • To find tools that convert models into different file formats. • Translate the received metamodel to a valid format for the previous project. • To guarantee the quality and consistency of all product lines from the model. • Display a graph based on the functional model. 2.3 Work Plan This section describes the work plan to be followed in order to achieve the objectives described in the previous section, as well as secondary goals or additional work required. These tasks have been carried out using the agile methodology, through sprints and with flexibility to change certain requirements . The first part of the work consisted of gathering information and inquiring more about the product lines, how model testing works and even testing tools such as EMF (Entity Modelling Framework) to obtain a more practical utility on the use of models, metamodels and how product lines are applied to these situations. Later, the search 7 of tools to rely on for the reception of the data began as well as the output of the results and, optionally, the way in which the models could be tested. Once the preparations for the project were completed, the objective was to find different ways to translate the data received from the metamodel and model to process them into code. Apart from being able to use the previously mentioned data without any prior processing, there is also the possibility of using JSON files through the Acceleo tool. To understand this tool, a small tutorial was made before its implementation, which lasted no more than a week. The next step focused on reading the data and generating an appropriate structure that makes validation easier. At first, its parsing was adapted only for JSON files, but later the option was given both to send the metamodel's own ecore file and the model's xmi, as well as the ability to validate several models at once from the same metamodel. After having finished reading the data, the next step was to validate models themselves, separately and ensuring their proper implementation before moving on to other steps. First, validations were carried out that did not require the metamodel, and later, it was used in order to have a stricter testing. These validations are mainly focused on the objects, which must belong to valid classes and its attributes are built accordingly to the metamodel. 2.4 Report structure The report is formed by an initial introduction, mentioning the reason this project was done, its advantages and goals that are necessary to consider it done as well as the planning to complete it. The next chapter focuses on explaining the necessary ideas to have a better understanding of the subject, how it works, and all tools used in this project, formed by IDEs, libraries, and additional projects. After that, it is explained how the code works, the structure of each class, the way to parse all input files and how all necessary validations are solved. 8 Lastly, a conclusion is written in order to get a summary of the whole project and understand its benefits. There is also a section where it is explained the future work and how it can be improved. 9 3 Conceptos previos Para explicar el proceso de creación de este TFG, primero hay que explicar los conceptos previos necesarios en los que se basan las líneas de producto. 3.1 MDE Los modelos son la representación abstracta de un proyecto, el cual se usa para analizarse y entender el comportamiento de este. Suelen estar definidos usando diagramas de clase o diagramas entidad-relación, pero existen otras definiciones mediante algebras o gramáticas. Todos los modelos son una instancia de un metamodelo, sin embargo, para que esta sea válida, se deben cumplir ciertos, requisitos, como que tenga una estructura válida y que tanto los objetos como las relaciones del modelo sean instancias de clases y asociaciones del metamodelo respectivamente, que el modelo cumpla las mismas restricciones de cardinalidad, claves únicas [1]. Las restricciones de los metamodelos son los límites que se le marcan a los modelos que procedan de dicho metamodelo. Estos límites pueden ser desde límites de cardinalidad para respetar los valores mínimos o máximos de una relación, el uso de claves únicas para relacionar elementos entre sí, hasta restricciones OCL, las cuales utilizan lenguaje natural para limitar los modelos. Este lenguaje natural es parecido al que puede ser usado en operaciones lambda, por ejemplo: A.allInstances->(a | a.b->size = 0)Esta restricción indica que, para todos los elementos de A, el atributo b debe tener tamaño 0 [3] Para la creación de estos metamodelos y modelos, se utiliza la herramienta EMF (Entity Modeling Framework). Los proyectos que surgen a partir de EMF contienen archivos ecore, el cual contiene un objeto representando el modelo junto a sus paquetes correspondientes. Estos paquetes son los siguientes [1]: • EClass: Una clase con la capacidad de tener relaciones y atributos. • EAttribute: Un atributo con nombre y tipo, perteneciente a una clase • EReference: Una referencia entre clases • EDataType: El tipo de un atributo. 10 3.2 DSL: Domain Specific Language Los lenguajes específicos de dominio son lenguajes orientas a aplicaciones o problemas particulares, a diferencia de los lenguajes corrientes para abordar un mayor número de necesidades. Pueden estar creadas a partir de un lenguaje a más bajo nivel, lo que provoca un menor tiempo de desarrollo una vez creada la DSL y facilidad de uso en caso de conocer dicho lenguaje. Sin embargo, existe la opción de que sean creadas desde cero, cuya ventaja sería una mayor flexibilidad en cuanto a la sintaxis, no dependerían del lenguaje base mencionado, a cambio de un mayor tiempo de creación de la DSL por la carencia inicial de compilar, parseador y de más [4]. Independientemente de haber estado creadas a partir de otro lenguaje de más bajo nivel o no, existen dos tipos de sintaxis, las cuales están relacionadas entre sí: • Abstracta: Enfocado en las relaciones y atributos, surgen a partir de un metamodelo. • Concretas: Enfocado en la visualización de la sintaxis abstracta, pudiendo ser a través de texto o de forma gráfica Ilustración 1 Representación de la sintaxis abstracta y concreta a partir del mismo ejemplo [4] Para este TFG, se usa la representación concreta gráfica a partir del proyecto GraphWalker, el cual está principalmente formado por nodos y líneas. Dicha herramienta es explicada con mayor detenimiento en el capítulo posterior 11 3.3 Variabilidad La variabilidad es la capacidad que tiene un sistema para manejar distintos elementos y conjunto de productos que, pese a poder tener una estructura en común, estos difieren en distintos aspectos. Dichas diferencias repercuten sobre la lógica que mantiene cada elemento, por lo que el desarrollo de un proyecto debe estar preparado para mantener y haber pensado previamente en cómo se afectan dichas diferencias entre sí. Las líneas de producto se ven originadas por la variabilidad que pueda existir en un sistema; su objetivo es minimizar el coste de desarrollo y evolución de cada producto que forme parte del proyecto [5]. La información de todos los posibles productos se ve representada en los Feature Models a partir de nodos y relaciones. Su objetivo es guardar las relaciones de ascendencia y descendencia entre nodos además de las posibles exclusiones y requisitos que pueda tener cada uno [6]. El proceso de crear un producto software específico se le reconoce como ejemplificar o instanciar. Este proceso suele tener como punto de partida otra línea de producto en la que, a partir de ella, se suele seguir dos pasos. El primero es la selección, la cual tiene como objetivo deshacerse de todas las funcionalidades que no sean necesarias para la nueva línea de producto, por lo que puede darse el caso de que se tengan que mantener todas. En la segunda parte se ejecuta el caso contrario, es decir, se añaden las variantes que no existían previamente y que, por tanto, serán necesarias de ahora en adelante. De este modo, surgen un conflicto a la hora de crear nuevas líneas de producto: Estas líneas deben ser lo suficientemente flexibles como para diversificar todas sus instancias, y que, además, cada línea debe ser lo suficientemente funcional como para crear nuevos productos a partir de ellas con el esfuerzo mínimo. Sin embargo, la creación de dichas líneas requiere de cierto esfuerzo, por lo que, en caso de generar demasiadas líneas, puede llegar a un punto donde sea más sencillo utilizar una de las líneas ya creadas en vez de seguir diversificando [5]. 12 3.4 Feature Models Los Modelos de características (del inglés Feature Models, FM) son el conjunto de características de un sistema software, sirven para ordenar y estructurar dichas características de forma que contengan cierta lógica entre ellas. Cada característica puede contener subcaracterísticas, las cuales están relacionadas entre sí mediante una lógica parecida a la de puertas: • AND: Todas las subcaracterísticas deben ser elegidas • OR: Alguna característica debe ser elegida • ALTERNATIVE (XOR): Sólo una característica puede ser elegida • OPTIONAL: Se puede elegir esa característica en concreto • MANDATORY: Se tiene que elegir esa característica en concreto Ilustración 2 Figura sobre los distintos tipos de relaciones [7] Una vez seleccionadas todas las relaciones del modelo, existen dos formas de representarlo: Con árbol o gramática Ilustración 3 FM con estructura de árbol y gramática [7] En este ejemplo, “e” requiere de “r” y “s”, y a su vez, “r” requiere de sólo una entre G, H e I mientras que s requiere de A y C, de manera opcional B. El objetivo de los FM es obtener las relaciones existentes entre los distintos nodos para obtener los requisitos que debe tener cada uno para ser usado conforme al metamodelo. [7] [8] 13 Por otro lado, existen las fórmulas proposicionales, siendo estas un conjunto de variables booleanas y predicados de lógica proposicional. Aparte de las operaciones estándar ∧, ∨, ¬, ⇒, and ⇔, también existe choose1(𝑒1.. . 𝑒𝑘) para obligar a elegir a lo sumo una de las expresiones entre e1 y ek. De forma más general, 𝑐ℎ𝑜𝑜𝑠𝑒𝑁, 𝑀(𝑒1. . . 𝑒𝑘) significa que al menos N y como mucho M expresiones entre 1 y K se cumplen. En las fórmulas proposicionales también es posible asignar variables al nombre de un patrón. Asumamos del ejemplo del árbol anterior, la rama “r” junto a las características que parten de ella, obteniendo “r : A B”, lo cuál puede ser resumido en la variable P1. “r: 𝐺 𝐻 𝐼 ∶ : 𝑃1”. Si queremos utilizar la lógica proposicional anterior, se dispone de varias formas de hacerlo: Supongamos que queremos que de “r”, sólo una sea cierta: 𝑅 ⇔ 𝑐ℎ𝑜𝑜𝑠𝑒1(𝑃1, . . . , 𝑃𝑛) , siendo P cada una de las características que surgen de "r”, en este caso G, H e I. Si, por el contrario, queremos que se pueda 1 o más, la fórmula será 𝑟 ⇔ (𝑃1 ∨. . .∨ 𝑃𝑛) [7] 3.5 Redes de Petri Las redes de Petri son un modelo formal que describe estados y acciones, lo cual viene representado a través de forma gráfica mediante nodos, lugares y transiciones. Son reconocidos por su simplicidad, generalidad y localidad de estados y acciones. De esta forma, pueden ser definidas por la tupla 𝑃 𝑁 = (𝑃, 𝑇, 𝐴), donde P y T son conjuntos disjuntos de lugares y transiciones, y 𝐴 ⊆ (𝑃 × 𝑇) ∪ (𝑇 × 𝑃) son el conjunto de arcos que conectan lugares a transiciones y viceversa. Los lugares son los distintos estados por los que puede pasar un producto, mientras que las transiciones son las acciones que permiten cambiar de un lugar a otro. [9] Una vez obtenida una red de Petri, para cada uno de los distintos productos, el objetivo es superponer todas las redes en una, formando la red de Petri 150%. Con esta red de Petri 150%, el FM y un mapeo de cada elemento con respecto a su fórmula proposicional en el FM, se forma la red de Petri orientada a líneas de producto (PNPL). 14 Ilustración 4 red de Petri 150% [9] En la ilustración 4 se utilizan regiones con líneas discontinua para asignar la misma PC a todos los elementos de la región. Por ejemplo, PartA contiene la transición genA, al place cnvA y a los arcos que se dirigen o vienen del place cnvA. Su algún elemento no pertenece a un PC, asumimos que su PC es verdadero a la hora de analizar su lógica. 3.6 PNPL La PNPL es la unión de la red de Petri 150% junto al FM, la cual es formada por el conjunto de todas las redes de Petri disponibles. Además de ello, todos los elementos de dicha red de Petri 150% (Place, Transition o Arcos) pertenecen a un PC. [8] Para seleccionar un producto específico de la PNPL, como en el visto en Ilustración 4, es necesario un subconjunto de características en su FM. Esta selección es denominada configuración de características (del inglés feature configuration, FC). Una FC válida requiere que todas sus subcaracterísticas cumplen con las restricciones del FM [8]. Asumamos que, basándonos en el ejemplo anterior, se pretende obtener una red de Petri a partir de una FC, la cual contiene los PC de PartB y Prod1. Para la selección de elementos, sólo se tendrán en cuenta los que cumplan con el contenido de la FC; en este caso, el resultado será el siguiente. 15 Ilustración 5 Derivación de una red de Petri [8] Se puede observar cómo los elementos pack y assmbly no están incluidos pese a pertenecer al PC Prod1, esto se debe a que dichos elementos requieren tanto de Prod1 como de Prod2, por lo que nunca se incluirán mientras no se satisfaga la condición de cada PC. 4 Herramientas utilizadas Con el fin de validar modelos basados en líneas de producto, se ha optado por crear un proyecto que reciba un metamodelo y todos los modelos que se deseen validar, teniendo en cuenta que dichos modelos deberán ser instancias del metamodelo anterior. Se busca tanto poder leer directamente los archivos originales ecore y xmi, como buscar formas de parsearlos previamente para obtener una lectura más clara; para este segundo caso, se buscarán herramientas que faciliten la conversión de modelo a distintos formatos. Una vez completada la lectura y validado que los modelos sean correctos y cumplan las restricciones del metamodelo, se buscará una forma de visualizar el modelo con el fin de facilitar la representación gráfica del mismo. Es por ello, que se han utilizado distintas librerías e IDEs para encontrar las mejores opciones para el problema en cuestión. 22 Ilustración 9 Diagrama del proyecto para la validación de modelos 5.2 Controller Una vez recibidos los archivos, se llama al controller, encargado de inicializar dichos archivos de forma previa a la llamada del parseador. Después, por cada modelo recibido, se llama al Tester para que valide todos los requisitos necesarios que detecten potenciales errores, los cuales se muestran tanto por consola como en el log previamente mencionado. 5.3 Parser El parseo del objeto completo de cada modelo se compone por todos los elementos de la red de Petri, el FM formado por nodos y relaciones, y las PCs. Para reutilizar el código lo máximo posible independientemente del tipo de archivo que se reciba, se ha movido toda la lógica de seleccionar elementos, obtener listas y de más a una clase auxiliar, de esta forma, en caso de añadir nuevos formatos en el futuro, su adición sea mucho más simple y mantenible. El parseo de cada apartado particular suele seguir un mismo proceso, generalmente formado por el bucle de una lista con el parseo individual de cada elemento junto a sus atributos. En caso necesario, los atributos pueden necesitar 23 algún tratamiento adicional para su correcta obtención, como es el caso del parseo de los requisitos y exclusiones de cada nodo; en este caso, consiste en asegurarse de que el nombre de los nodos formado por varias palabras no sea tenido en cuenta como dos nodos distintos. Para el metamodelo, se sigue una estructura de parseo parecida, sin embargo, las principales diferencias son el tipo de datos que se recogen, es decir, obtener todos los tipos de elementos junto a qué tipo de atributos deben tener, el propio formato del archivo, ya que existe la posibilidad de que las especificaciones de los elementos se puedan encontrar repartidas en distintas zonas del metamodelo. 5.4 Utils Es la clase que contiene tanto posibles métodos auxiliares, como la que maneja los objetos del logger y la que interactúa con los distintos tipos de archivos que puedan contener información acerca de un modelo o metamodelo. De esta forma, tenemos toda esa lógica contenida en una misma clase, evitando repeticiones de código y dando una forma más sencilla de mantenerlo. 5.5 Tester Una vez parseados tanto el metamodelo como todos los modelos que se desean validar, uno por uno, se llaman a la clase Tester, el cuál devolverá una lista de errores a través del método check(). Dentro de este método, se validarán de forma individual cada apartado del modelo, es decir, los nodos, transiciones, places, arcos y elementos, aunque para estos últimos sólo se verificará que tienen una clase concreta asignada. Antes de utilizar el metamodelo para las validaciones, se comprueba que todas las relaciones que existen entre cada una de las clases mencionadas son correctas, es decir, que no existen valores inexistentes en la entidad referenciada o sean vacíos en caso de no permitirse. Esto se aplica para todos los atributos en los que se guarde información de otras entidades, como la lista de requisitos de los nodos o los PCs. Con respecto los arcos, además de realizar las validaciones previas, también se comprueba los tipos asignados a los atributos de origen y destino. Dependiendo del tipo de arco, el origen puede ser Place y el destino Transition o viceversa, por lo que 24 se comprobará que los tipos asignados por el metamodelo se cumplan para todos los arcos del modelo. También se comprueba que todos los elementos de la red de Petri tengan una clase asignada, en este caso, Place o Transition, por lo que se comprobará que la clase interna de los elementos sea uno de los indicados por el metamodelo. Para las relaciones, como se vio anteriormente, contienen un tipo para relacionar un nodo con otro, estos tipos están declarados por el metamodelo, por lo que se comprobará tanto que no sea vacío como que exista en el mismo. Cada error encontrado se añadirá a la lista de errores, la cual se escribirá en el log o se tratará de distinta forma en el futuro. 5.6 Clases de elementos A continuación, se explican las clases que han necesitado ser creadas para formar la estructura de datos necesaria de los modelos 5.6.1 PNPL Es la clase que recoge todos los datos de cada modelo, el cual se compone de una lista de nodos y otra para las relaciones para formar el FM, y otras para los arcos, places y PCs para la red de Petri. Estas listas cuentan con getters, sin embargo, para asignarlas, se debe usar la clase interna PNPLBuilder para devolver el objeto PNPL después de asignar cada dato de forma individual 5.6.2 Node Son los tipos perteneciente a los Feature Model. Se caracterizan con un nombre, dos condicionales para determinar si son abstractos u obligatorios, y por dos listas de nodos adicionales, siendo la primera sobre los nodos necesarios para que el actual pueda ser usado mientras que la segunda determina los nodos con los que impide coexistir. 5.6.3 Relation Es la clase que relaciona los nodos de la clase anterior. Tienen un valor para guardar el tipo de lógica predicativa, el nombre del nodo antecesor y una lista de nodos a los que se dirige, la cual puede estar vacía. 25 5.6.4 Place Es uno de los posibles tipos de elementos que pueden pertenecer a la red de Petri. Puede pertenecer a un Presence Condition y estar relacionado a otros tipos de elementos de la red a partir de una variedad de arcos. 5.6.5 Transition Es el otro tipo de elementos pertenecientes a la red de Petri. Tiene una funcionalidad parecida al elemento anterior ya que también pueden pertenecer a un Presence Condition y están relacionados con otros elementos. 5.6.6 Arc Son el tipo de objeto que relaciona todos los elementos de la red de Petri entre sí. Los dos tipos disponibles son ArcTP y ArcPT, teniendo el primero como origen una transición, un Place como destino y el caso contrario en el segundo tipo. Pese a solo usarse estos dos tipos en el metamodelo, el código permite la adaptación a potenciales nuevos arcos en caso de ser necesario en el futuro. La clase contiene el nombre del arco, el tipo anteriormente mencionado, el posible Presence Condition al que está vinculado, el elemento de origen, el cuál debe ser del tipo correspondiente al metamodelo, y el destino. 5.6.7 Viewer Es la capa de visualización del proyecto, donde se determina el estilo que van a tener los componentes del grafo a la vez que la inserción de los datos junto a sus asociaciones en estos. Para los estilos, GraphStream [11] utiliza un sistema parecido a los css, solo que implementado mediante una única variable string, sin embargo, es esta la que debe simular el formato del archivo css. Dicha variable se puede asignar tanto para el grado entero, para únicamente sus nodos o enlaces, o incluso para unos elementos específicos, siguiendo el sistema de clases en los archivos HTML. 26 Ilustración 10 Visualización de la red de Petri una vez validada El grafo de la ilustración superior muestra un modelo posterior a su validación. Los nodos visibles son el conjunto de sus places y transiciones, las cuáles forman su red de Petri. Estos elementos están unidos mediante los mismos arcos pertenecientes al modelo, siguiendo su mismo tipo y el origen y destino que les corresponde. Sin embargo, en caso de que un modelo no haya pasado la validación correctamente, este grafo no se creará, sino que se guardarán todos los errores en el log de la aplicación, indicando todos los errores de forma ordenada. 27 6 Conclusiones y Trabajo a futuro Debido a la importancia de las validaciones de un proyecto para poder asegurar una mayor calidad y estabilidad, se ha optado por trabajar en el testeo de modelos, orientado a líneas de producto. Dichas líneas de producto pueden generar una gran cantidad de variables, dificultando su validación en caso de optar por un testeo manual, además, se tiene como objetivo el testeo del propio modelo para poder detectar en una fase temprana del desarrollo cualquier problema de raíz que pueda haber surgido en el diseño, evitando así potenciales grandes costes de tiempo en caso de encontrar errores relacionados con el modelo en fases avanzadas del desarrollo. Una vez hayan finalizado todas las validaciones de cada modelo que haya sido deseado testear, se mostrará una ventana con una representación mediante grafos de todos los elementos pertenecientes a la red de Petri proporcionada. En cuanto a la transformación de modelos a distintos formatos, se optó finalmente por Acceleo [12]. Este permite la obtención de la gran mayoría de datos disponibles, sin embargo, no es posible obtener otros como la clase de los elementos que no pertenezcan a uno distinto de Place, Transition y Arc, por lo que de forma ideal se usará el modelo sin ninguna transformación previa. El proceso de validación también ha sido exitoso; se comprueba que no haya inconsistencias entre los datos y se asegure correcto diseño del modelo. Esto facilita las primeras fases del desarrollo ya que asegura que la base en la que se parte es la adecuada. Por último, pese a haber variado la herramienta a utilizar para la visualización, se acabó encontrando una mucho más accesible y con un mayor número de posibilidades a la hora de mostrar los datos [11]. Esto permitirá una mayor fluidez a la hora de crear nuevas características al proyecto. Por otro lado, este proyecto tiene el potencial de traer más funcionalidades que, debido. Actualmente, existe la posibilidad de introducir archivos derivados de XML 28 tanto para metamodelo como modelo, con la adición del tipo JSON para modelos; por ello, una posible adición sería la implementación de las lecturas de archivos JSON para metamodelos. Además, como ya existe una interfaz gráfica para la muestra de los resultados, se podría crear una interfaz completa tanto para la selección de archivos y evitar pasarlos por parámetro, una visualización estructurada de los errores y la incorporación de la gráfica ya creada con lo previamente mencionado. 29 7 Conclusions and Future Work Due to the importance of testing to assure a better quality and stability in the project, the aim has been placed on model testing, more specifically in product lines. These product lines can generate a large amount of variables, making its validation harder in case a manual testing method is chose, besides, the goal of testing models instead of the implementation is to detect any root problem that was generated in the design in an earlier stage of development, avoiding this way a bigger time cost in case there are problems related to the mode; the longer it takes to fix it, the more complex the project will be and thus the harder it will be to fix it. Once all desired models are tested, a frame with a graph representation of each one of them will be shown. This graph contains all elements that belong to the Petri net, distinguishing each type and section through colours. Por último, pese a haber variado la herramienta a utilizar en este sentido, se acabó encontrando una mucho más accesible y con un mayor número de posibilidades a la hora de mostrar los datos [11]. Esto permitirá una mayor fluidez a la hora de crear nuevas características al proyecto. When it comes to the model transformation into different formats, the chosen tool was Acceleo [12]. This tool allows us to obtain most of the desired data, nevertheless, it is not possible to obtain some of them, such us the class of elements which don’t belong to Place, Transition and Arc; this means that it is preferable to test the model without any previous conversion. The validation process was also successful; it is tested that no inconsistencies are found in the data as well as making sure that there is a correct model design. This makes the initial development phase easier to work with as we can confidently that its basis is correct. Finally, despite changing the visual tools used, the chosen one is more accessible and with a bigger number of possibilities to show all the data [11]. This will allow for a better working flow in case there are new features related to the GUI. 30 On the other hand, the project has the potential to bring new features that, due to them surging during the development of the project, they weren’t possible to implement on time. Right now, there is the possibility to use xml files for both the metamodel and model, with the option for the model to be input as a JSON file as well; that is why, a possible addition could be the implementation of JSON files reading for the metamodel. Besides, since there is already an existing UI to show the model results, the next step could be to introduce one with more features, such giving the option to upload those files through it instead of just as a parameter, and a more structured display of all errors detected during the analysis. 31 8 Referencias [1] E. G. E. G. Juan de Lara, Meta-modelling, Madrid. [2] A. Srivastava , S. Bhardwaj y S. , «2017 International Conference on Computing, Communication and Automation (ICCCA),» de SCRUM model for agile methodology, pp. 864869. [3] M. Richters y M. Gogolla, «Validating UML Models and OCL Constraints,» p. 13, 2000. [4] E. G. E. G. Juan de Lara, Domain-Specific Languages (DSLs), Madrid. [5] J. B. M. S. Jilles van Gurp, «On the Notion of Variability in Software Product Lines,» Department of Mathematics and Computing Science. University of Groningen,, PO Box 800, 9700 AV The Netherlands, 2001. [6] P. C. Clements y P. Bachmann, «Variability in Software,» Carnegie Mellon. Sofware Engineering Institute, Pittsburgh, PA, 2005. [7] D. Batory, «Feature Models, Grammars, and Propositional Formulas,» de Software Product Line Conference 2005, Austin, Texas 78712, 2005. [8] E. Gómez Martínez, J. de Lara y E. Guerra, «Extensible Structural Analysis of Petri,» Springer Berlin Heidelberg, Madrid, 2021. [9] E. Gómez Martínez, E. Guerra, J. de Lara y A. Garmendia, «Lifted structural invariant analysis of Petri net product lines,» Elsevier, p. 21, 2022. [10] K. Karl, «GraphWalker,» [En línea]. Available: https://graphwalker.github.io/. [11] S. Balev, A. Dutot, Y. Pigné y G. Savin, «GraphStream,» [En línea]. Available: https://graphstream-project.org/. [12] «Acceleo,» 2022. [En línea]. Available: https://projects.eclipse.org/projects/modeling.m2t.acceleo. [13] «Intellij,» [En línea]. Available: https://www.jetbrains.com/es-es/idea/. [14] «Visual Studio Code,» [En línea]. Available: https://code.visualstudio.com/. [15] M. Fowler, Domain-Specific Languages, Pearson Education, 2010. [16] B. R. Hans Grönniger, «Modeling Language Variability,» de Foundations of Computer Software. Modeling, Development, and Verification of Adaptive Systems, Redmond, WA, 2010. [17] Apache, «log4j,» [En línea]. Available: https://mvnrepository.com/artifact/log4j/log4j.