Model transformations play an important role in Model-Driven Engineering (MDE), and as their size and complexity grow, there is an increasing need to count on tool support for testing their correctness. In this work, we present TractsTool, a tool for specifying and testing several different kinds of model transformations, e.g., model-to-model, model-to-text, and text-to-model transformations, based on contracts.
The basis of the Model-Driven Engineering (MDE) paradigm is the usage of models. They have become key artifacts from which a system may be (semi-)automatically derived and implemented. Model transformations are the key mechanism of MDE for manipulating models. Model-to-model (M2M) transformations take as input models conforming to specific metamodels and transform them into other models conforming to other (or the same) metamodels. In addition to M2M transformations, model-to-text (M2T) and text-to-model (T2M) transformations are of major importance. The former are frequently used to produce code from models, while the latter are typically used for reverse engineering of legacy systems or injecting artifacts to the MDE technical space.
As the size and complexity of model transformations grow, there is an increasing
need to count on mechanisms and tools for testing their correctness [
The tool presented in this paper follows the latter approach. We generalize model
transformation contracts [
After this introduction, we have a glance at the foundations of the Tracts approach in Section 2. In Section 3 we describe how we consider to test M2T and T2M transformations, whereas in Section 4 we elaborate on how TractsTool is realized. We close the paper by presenting the conclusions and future work in Section 5. 2
In Fig. 1 we show the main ingredients of the Tracts approach [
For exemplifying how Tracts are defined, we make use of the well-known Classto-Relational transformation example3. In the following listing, we present for each constraint type, i.e., source, target, and source-target constraint, one example that the Class-to-Relational transformation should fulfill. For reasons of brevity, we only present some very basic constraints. For more complex ones the interested reader is referred to our project website4. -- SRC: Classes have to have unique names
Class . allInstances > unique ( c j c . name ) -- SRC/TRG: For each class, a table has to be produced
Class . allInstances > forall ( c j Table . allInstances > exists ( t j t . name = c . name ) ) -- TRG: The columns of a table have to have unique names
Table . allInstances > forall ( t j t . columns >unique ( c j c . name ) )
3 http://www.eclipse.org/atl/atlTransformations
4 http://atenea.lcc.uma.es/index.php/Main_Page/Resources/Tracts
Compared to testing M2M transformations, M2T and T2M transformations have not
gained much attention when it comes to testing. In our approach, we adopt current
techniques for testing M2M transformations to the problem of testing T2M and M2T
transformations. The prerequisite of using existing M2M transformation techniques is
to have metamodels for the input and output of the transformations. However, for the
side that is dealing with just text of M2T and T2M transformations, no metamodels are
usually available. Even more problematic, when considering T2M and M2T
transformations, a set of metamodels and T2M parsers may be required as a prerequisite to reach
the MDE technical space. To alleviate the burden from T2M and M2T transformation
engineers, we employ a generic approach that may be used for any transformation task
where text is involved as input or output of the transformations. The main mechanism
we employ is to represent text within a generic metamodel in order to transform M2T
and T2M transformation specification problems into equivalent M2M transformation
specification problems [
Artifacts involved in M2T and T2M transformations are normally organized in a hierarchical folder structure. For instance, the output of a M2T transformation may not be just a single file but several, which should be also arranged in a certain folder structure forming a repository of artifacts. Fig. 2 shows the metamodel for representing text artifacts stored in repositories. Meta-class Repository represents the entry point to the root folder containing folders and files. While folders just contain a name, files have in addition an extension as well as a content. The content of files is represented by lines that are sequentially ordered. By having this generic metamodel and an accompanying generic T2M parser, we are able to inject text artifacts into models and reuse model-based tools such as the TractsTool. Going back to the Class-to-Relational transformation example, assume that we are now using a M2T transformation for directly producing Data Definition Language (DDL) code. The following Tract may be defined for this scenario. For more complex Tracts the interested reader is again referred to our project website. -- SRC/TRG: For each class, a CREATE TABLE statement has to be produced File . allInstances > exists ( f j f . name = ’db_schema’ and Class . allInstances > forAll ( c j f . lines > exists ( l j l . text . matchesRE ( ’ˆCREATE TABLE ’ + c . name ) ) ) )
We have presented the foundations of TractsTool, a tool for light-weight verification of any kind of model transformation by following the Tracts approach.
There are several lines of research that are still subject to ongoing work. Firstly, we
plan to investigate how the Knowledge Discovery Metamodel (KDM) may be used for
defining contracts that are programming language independent and reusable for a
family of code generators. Secondly, the TractsTool’s internal transformations presented in
Section 4 are time-consuming when transforming very large models. Another objective
is to provide a mechanism to generate automatically the ASSL program that in turn
generates a set of default input models so that the user is not required to develop such
programs by hand. Another improvement that may be made is to change the information
that is displayed after the verification process. Specifically, diagnostic models are an
interesting line of research in this respect. Finally, we plan to include error tracking [