Model-Driven Engineering (MDE) is a Software Engineering paradigm that focuses all phases of the software development process in models. Therefore, the automated manipulation of models is essential in MDE. While many Domain-Specific Languages (DSLs) exist to specify model transformation, model simulation, or code generation, there is a lack of DSLs to specify and apply model mutations. A model mutation is a kind of model manipulation that creates a set of variants (or mutants) of a seed model by the application of one or more mutation operators. Model mutation has many applications (e.g., model transformation testing, automated generation of exercises, verification of software testing, etc.). The objective of this thesis is the creation of a DSL for model mutation, and its application to different domains like education, model-based testing and search-based software engineering.
Model-Driven Engineering (MDE) [
A model mutation is a kind of model manipulation that creates a set of
variants (or mutants) of a seed model by the application of one or more mutation
operators. Model mutation has many applications. For example, in model
transformation testing [
There are some frameworks for model mutation, but they are specific for a
language (e.g., logic formulae [
In this section, we review related works on the main line of related research: the application of mutation techniques to different contexts and domains.
Mutation is used in areas like model-based testing [
The mutation framework in [
To facilitate the specification and creation of model mutations in a metamodel independent way, we propose a DSL called Wodel. Fig. 1 shows the architecture of our approach. First, the user provides a set of seed models conformant to a meta-model. Then, they use Wodel to define the desired mutation operators and their execution details, like how many mutations of each
type should be applied in each mutant, or their execution order. In addition, each Wodel program needs to declare the meta-model of the models to mutate, which can be any meta-model because Wodel is meta-model independent. This allows type-checking the program to ensure it only refers to valid meta-model types and properties, and allows checking that the result of the mutation is valid.
WODEL program check
DSL metamodel seed models
«conforms» «refers-to» editor (Xtext) code completion, validator code gen (Xtend)
WODEL engine generate, compile, execute Java code
postProc model mutants
«refers-to» mutation registry
Fig. 1: Architecture of Wodel’s environment
Executing a Wodel program produces mutants of the seed models. These are still valid models (i.e., they conform to the seed models’ meta-model) as this is checked upon generating each mutant. If the mutant is not conforming to the meta-model, Wodel iterates the mutant generation until a maximum n number of times (that can be configured through the preferences page). The produced Java code, which is in charge of creating the mutants from the seed models as well as the registry of applied mutations, can be transparently executed from the Wodel IDE. The registry stores the applied mutations, along with references to the elements affected by the mutations in the seed model or in the mutants. This registry generation of the applied mutations is useful when we need to repeat the mutation process, or we have to generate natural language that describes the applied mutations. Finally, an optional post-processing step can be used to generate domain-specific artefacts for particular applications of the mutants. This will be provided by the Wodel environment through an extension point. This way, Wodel can also generate mutants in other formats different to EMF XMI (e.g., json, et.). We plan to extend Wodel to three different applications: automated generation of exercises; software testing verification; and search-based software engineering.
We plan to provide Wodel with correct and incorrect mutant generation: correct mutants are conforming to the same meta-model of the seed model, and incorrect mutants may violate some of its constraints (e.g., do not satisfy some association cardinality constraint). This set of correct and incorrect mutants will be useful in evolutionary computation (e.g., an incorrect mutant may have better fitness according to a given criterion than a correct one). Wodel will be able to distinguish the conforming mutants and the ones that are not conforming to the meta-model. Also, we will include mechanisms to identify duplicate mutants not only syntactically, but also semantically. These mechanisms ensure that the generated mutants will be unique and they are useful in the automated generation of exercises (e.g., we ensure that the selectable text options, or the set of diagrams, presented in an exercise correspond to different models), and also in software testing verification (e.g., we ensure that the mutants of a program to be verified are behaviourally different).
Wodel will provide mutation primitives: creation, deletion, edge redirection, cloning, etc.; and also model element selection strategies: random selection, and property-based selection (e.g., a selection with a fitness function as a property will be useful in evolutionary algorithms). We also plan to broaden Wodel with execution policies: parallel, sequential, distributed (e.g., two Wodel programs can be executed in parallel in different threads at the same time, so they generate different results which can be merged afterwards). Also, it will be useful to provide Wodel with libraries of reusable mutations for particular domains (e.g., a library of interesting mutations for the automated generation of exercises of a particular domain). We find it useful to provide Wodel with a registry generation of the applied mutations (e.g., to reverse a mutation, or for traceability reasons). It may also be beneficial to extend the mutations registry with additional behaviour: compacting the registry (e.g., it is irrelevant to store in the registry two mutations that cancel each other: one mutation creates an object and another one deletes it). The registry will also be useful for repeatability (e.g., it will be necessary in evolutionary computation, to be able to repeat the mutation process). It will be also interesting to extend this registry with some mechanisms to verbalize the applied mutations (e.g., verbalizing the applied mutations forward or backward will be useful to explain students how to do or undo the mutations in the automated generation of exercises, in order to create the correct answers that fix the mutant; or the wrong ones, that correspond to alternative mutants). 4
We have developed an environment which allows the creation of Wodel programs and their compilation into Java, and can be extended with post-processor steps for particular applications. Wodel can also generate a registry of the applied mutations. We also have created the Wodel-Edu extension to Wodel, an application on the automated generation of test exercises.
Wodel programs have two parts. The first one declares the number of
mutants to generate, the output folder, the seed models and their meta-model. The
second part defines mutation operators and how many times they should be
applied. Programs can also include a list of OCL constraints that all generated
mutants should fulfil. Details can be checked in [
Listing 1: A simple Wodel program
Wodel-Edu is an extension to Wodel for the automated generation of test exercises. It provides four DSLs to configure the text and style of exercises (eduTest), how model elements should be graphically rendered (modelDraw), how to represent a model element textually (modelText), and how to represent an applied mutation textually (mutaText). Wodel-Edu is also domainindependent and generates a web application with exercises for different domains (e.g., automata, class diagrams, electronic circuits, etc.). Currently, the generated exercises are of multiple response, but we plan to extend the framework to support more dynamic exercises, with a better interaction with the student. A preliminary evaluation of Wodel-Edu showed good results (the generated application can be accessed on-line at http://www.wodel.eu).
Wodel will ease the creation of applications based on mutations by providing support for their definition, execution and traceability. In addition, we will develop the following three post-processing extensions: 1. Automated generation of exercises that can automate the suggested answer.
This is our framework Wodel-Edu (see Section 4), which will be extended
with gamification features, and interactive exercises.
2. Software testing verification. The source code of a program (represented as a
model) will be mutated via a set of mutation operators. The quality of the
test cases will be evaluated by checking if they detect the generated mutants.
In addition, we will generate a library of Wodel encoded mutations. This
library will apply to any general-purpose programming language.
3. Search-and model-based software engineering. In this approach,
populationbased search is used to optimize a problem. Problems are represented with
models, and search is performed by mutating the models in the population.
We can use a similar approach as MOMoT [
We will evaluate the expressivity of Wodel using in this DSL the interesting
mutations both devised by us and found in the literature [
We have developed a preliminary version of Wodel which supports 7 types of mutation primitives and 4 selection strategies, and composite mutations. We also have included the registry extension to store which mutations have been applied to each seed model at the mutants’ generation. We have improved the Wodel DSL with new mutation primitives; conditional expressions for the specific selection of elements; and also the declaration of blocks inside Wodel programs, in order to generate mutants at different stages. These improvements were necessary for applying Wodel to the automated generation of exercises of the Wodel-Edu framework. Currently, Wodel-Edu supports three kinds of test exercises: alternative response, multiple diagram choice, and multiple emendation choice. The design and development of Wodel includes the evaluation of the expressivity of the DSL. The work should be finished by the middle of 2019, as it is shown in Fig. 2.