In Model-Driven Engineering (MDE), model transformations are basic and primordial entities. An efficient way to assist the definition of these transformations consists in completely or partially learning them. MTBE (Model Transformation By-Example) is an approach that aims at learning a model transformation from a set of examples, i.e. pairs of transformation source and target models. To implement this approach, we use Formal Concept Analysis as a learning mechanism in order to extract executable rules. In this paper, we investigate two learning strategies. In the first strategy, transformation rules are learned independently from each example. Then we gather these rules into a single set of rules. In the second strategy, we learn the set of rules from all the examples. The comparison of the two strategies on the well-known transformation problem of class diagrams to relational schema showed that the rules obtained from the two strategies are interesting. Besides the first one produces rules which are more proper to their examples and apply well compared to the second one which builds more detailed rules but larger and more difficult to analyze and to apply.
Model Driven Engineering is a recent paradigm emphasizing the use of models
in the development process of an application. The models may be graphical or
not, but they are all structured conforming to particular models named
metamodels. In Model-Driven Development, several kinds of models are successively
handled (e.g. requirements, use cases, classes, etc.) and models may be obtained
one from each other, in an automated way, thanks to model transformations. A
Model Transformation is a program that takes as input a model conforming to a
source meta-model and produces as output another model conforming to a target
meta-model. Implementing a model transformation requires a strong knowledge
about model driven engineering (meta-modeling and model-transformation
environments) and about the specification of the transformation: the input domain,
⋆ This work has been supported by project CUTTER ANR-10-BLAN-0219
c 2012 by the paper authors. CLA 2012, pp. 45–56. Copying permitted only for private
and academic purposes. Volume published and copyrighted by its editors.
Local Proceedings in ISBN 978–84–695–5252–0,
Universidad de M´alaga (Dept. Matem´atica Aplicada), Spain.
the output domain and the transformation rules by themselves. Moreover, the
transformation rules are usually defined at the meta-model level, which requires
a clear and deep understanding about the abstract syntax and semantic
interrelationships between the source and target models [
Domain experts generally do not have sufficient skills in model driven
engineering. An innovative approach called Model Transformation By Example
(MTBE) [
In this context, we presented a Model Transformation By Example approach
that goes from examples to transformation patterns. The proposed learning
mechanism is based on Relational Concept Analysis (RCA) [
The remainder of this paper is structured as follows. Section 2 gives an overview of the approach. Section 3 briefly explains how RCA is used to generate transformation patterns from examples. Section 4 details how the pattern lattices are filtered and refined. Section 5 describes the two learning strategies, and an experimentation to compare them on a case study. Section 6 positions our work w.r.t. related work, and Section 7 concludes the paper and describes future work. 2
A model transformation is a program handling and transforming models. We focus here on transformations that take a model as input and result in another model as output. Model transformations are usually written in languages dedicated to model handling, or generic languages using adequate frameworks to handle models. Those transformations implement transformation rules, expressing for each kind of elements from an input model which kind of elements of the output model they will be transformed into. Model-Transformation By Example (MTBE) consists in learning those transformation rules from examples: instead of programming the model transformation, the user designs examples illustrating the behavior of the transformation, and the transformation rules are automatically learned from those examples.
Learning Model Transformations: One for All or All for One? Usually, an example is composed of a source model, the corresponding transformed model, and transformation links between those two models. To illustrate MTBE, we consider the well-known case of transforming UML class diagrams into entity relationship. An example for this transformation is thus composed of a UML model (the input model), a Relational model (the output model) and transformation links making explicit from which elements of the UML model, the elements of the entity relationship model stem from. Such an example is given in Figure 1. The input UML model is on the l.h.s., and is composed of two classes named Text and Style, each one owning an attribute (respectively named Title and Name) and linked with an association named Has a. The output model (on the r.h.s. of Figure 1) has two entities Text and Style, each one described by an attribute, linked with a relation named Has a. The dotted lines show some of the transformation links. For instance, there is a transformation link specifying that the class Text is mapped into the entity Text. 47
An MTBE process analyzes the examples and learns from them transformation rules such as a class is transformed into an entity, or a UML property linked to a class (i.e., an attribute and not a role) is transformed into a role of an entity.
We proposed an MTBE approach in which the learning mechanism relies on
Relational Concept Analysis [
As stated in Section 2, a key step in our MTBE approach consists in generating
transformation patterns. Such patterns describe how a source model element is
transformed into a target model element, within a given source context and a
given target context. To derive patterns from examples, a data analysis method
is used, namely Formal Concept Analysis (FCA) [
Definition 1 (Relational Context Family). A Relational Context Family R is a couple (K, R). K is a set of Object-Attribute Contexts Ki = (Oi, Ai, Ii) where Oi is a set of objects, Ai is a set of attributes and Ii ⊆ Oi × Ai. R is a set of Object-Object contexts Rj = (Ok, Ol, Ij, Sj) where (Ok, Ak, Ik) ∈ K, (Ol, Al, Il) ∈ K, Ij ⊆ Ok ×Ol, and Sj is a scaling operator, i.e. a boolean function taking as parameter an object from Ok, a concept extent e ⊆ Ol and the binary relation Ij.
RCA considers a Relational Context Family R = (K, R) as input of the lattice building process. This process applies iteratively FCA on each ObjectAttribute Context from K extended with the Object-Object contexts of R scaled with the lattices of the previous iteration.
Initialization step At the first step, FCA is applied on each Object-Attribute Context Ki = (Oi, Ai, Ii) to produce a lattice L0i. The output of this step is a Concept Lattice Family L0.
Step n+1 At step n+1, from each context Rj = (Ok, Ol, Ij, Sj) from R and the lattice Lnl we compute an Object-Attribute Context C(n+1)j = (Ok, {j} × Lnl, J(n+1)j) where J(n+1)j = {(o, (j, c))|o ∈ Ok ∧ c ∈ Lnl ∧ Sj(o, extent(c), Ij)}. Then each context Ki = (Oi, Ai, Ii) from K is extended to obtain K(n+1)i = (Oi, A(n+1)i, I(n+1)i) where A(n+1)i = Ai S{p,q|∃Rq=(Oi,Op,Iq,Sq)∈R}{q}×Lnp and I(n+1)i = Ii S{q|∃Rq=(Oi,Op,Iq,Sq)∈R} J(n+1)q. The lattice L(n+1)i is then obtained by applying FCA on K(n+1)i.
The process stops when an iteration does not add any new concept and we consider the last lattice family obtained as the output of the process.
We use RCA to classify: the source model elements, the target model elements and the transformation links. Which means that every one of them will be modelled as an Object-Attribute context in RCA. Those contexts will be linked by Object-Object contexts modelled after the following relations. Source and target model elements are classified using their metaclasses and relations. The transformation link classification relies on model element classifications and groups links that have similarities in their source and target ends: similar elements in similar contexts. From the transformation link classification, we derive a lattice of transformation patterns. Figure 2 shows an excerpt of the obtained pattern lattice for the transformation of UML class diagrams into relational models. The transformation patterns are represented by rectangles, and are named with the prefix TPatt, the number of the transformation pattern, and then the number of the corresponding concept.
In each concept representing a transformation pattern, we have two types in two ellipses connected by a bold edge. The source ellipse of the bold edge represents the type Ts of the element to transform by the pattern. It can be seen as the main type of the premise. For instance, in Concept TPatt_17-Concept_67, we see that the pattern aims at transforming generalizations (note that in the UML meta-model, there is a meta-class named Generalization, which represents an inheritance relationship, and which is linked to two classes (in fact: classifiers, Classifier being a superclass of the meta-class Class) : the specific one and the general one). This main type of the premise is linked, with non-bold edges, to the environment that an element of type Ts must have in order to be transformed by the pattern. Those edges are named according to the relationrole names between the type Ts and its environment in the meta-model. Those edges also have a cardinality defining the cardinality of the environment. Such an environment corresponds to the rest of the premise. For instance, in Concept TPatt_17-Concept_67, Generalization is linked to a specific Class and a general Class with a cardinality [1..*], meaning that the Generalization must have a specific and a general classes. The target ellipse of the bold edge represents the main type Tt of the conclusion of the pattern, i.e., a Ts will be transformed into a Tt (with a specific environment). For example, in the transformation pattern TPatt_17-Concept_67, the conclusion corresponds to a role, connected to a relationship, an entity, and zero or one cardinalities. Note that the conclusion of this pattern is quite long: this will be discussed in the next section. 4
The obtained lattice of transformation patterns has to be filtered to keep only the useful/relevant patterns or pattern fragments.
First, the empty concepts are removed. They do not contain information about the transformation. They are present in the lattice to link other concepts (representing patterns). We only keep the Bottom and Top to maintain the order structure. For the same reason, when an empty concept is removed, its children are connected with the Top concept.
Secondly, we noticed that some patterns contain a deep premise or conclusion,
i.e., a long chain of linked objects. After observing many patterns of this type for
many transformation problems, we found that after a certain depth, the linked
elements are not useful. For instance, in the pattern TPatt_17-Concept_67 in
Figure 2, the important information is that a generalization linked to two classes
(specific and general) must be transformed into a role linked to a relationship, an
entity and a cardinality. The other elements are details specific to some examples,
that are not relevant to the transformation. Starting from this observation, we
implemented a simplification heuristic that prunes the premises and conclusions
– In the first one, we use the experimentation of [
The goal is to compare in each fold i the results obtained from the two strategies. First, we compare the lattices generated from examples (lij), and the lattice generated from the union of those examples (Li). Then, we compare the results of executing the rules obtained from each strategy on the source models provided in the testing examples. 5.1
lij vs Li Compared to the first strategy, which produces small size lattices (from each lij we have about 9 patterns before simplification and 4 patterns after simplification), the second one produces large ones (from each Li we have about 100 patterns before simplification and 50 patterns after simplification). Although the lattices Li are larger and more difficult to analyze, they have more specific and complete transformation patterns compared to lij which are simple to analyze but contain transformation patterns that are proper to their examples. A single pattern of Li can combine several patterns that exist in lij .
Figure 3 shows examples of different patterns obtained from l1j . For instance, in the pattern of Fig. 3(a), a transformation link is given to specify that a class linked to an aggregation is mapped into a table linked to primary foreign key. Pattern of Fig. 3(b) shows that a class linked to a property is transformed into a table linked to a column. In the last pattern of Fig. 3(c), the transformation specifies that a class linked to a property and a generalization are transformed into a table linked to a column and a foreign key.
If we compare these patterns with the pattern of lattice L1 in Figure 4, we note that the information contained in the three patterns exist in the pattern of Figure 4. It is more complete. It combines all the informations of transformation existing in Fig. 3(a), Fig. 3(b) and Fig. 3(c).
So, if we combine various examples together, the generated lattice contains patterns which are more specific and combine different information. But, if we test each example separately, the obtained lattice contains less information. In addition, Li contains all the patterns needed to transform a class diagram to a relational schema. The lattices lij contain just the transformation pattern
TPatt_3 - Concept_83 (b)
TPatt_1 - Concept_77 proper to the transformation examples used. So, we need to merge several transformation examples to obtain all transformation rules of a class diagram into a relational schema.
Furthermore, in each fold, a Li lattice contains about 50 transformation patterns and the union of lij produces about 40 ones (4 transformation patterns * 20 minus the redundant ones which exist). If we examine the patterns as an expert, we note that Li contains about 12 relevant transformation patterns which are useful to the transformation. But they are less detailed and not applicable for all examples types. On the other side, the union of lij contains about 10 relevant transformation patterns. Those patterns are easy to read and to apply because each one contains a piece of information of the transformation compared to Li’rules which combine several pieces of information in the same pattern.
lij’s rules execution vs Li’s rules execution In this section, we compare the result of executing the rules obtained from the two strategies, which are transformed into Jess rules, on the source models provided in the testing examples. This comparison allows calculating the recall (Equation 1) and the precision (Equation 2) measures for each T. T represents the type of elements in the target meta-model (table, column, foreign key...) R(T ) = P (T ) = number of T with correct transf ormation
total number of initial T number of T with correct transf ormation total number of generated T (1) (2)
Table 1 shows precision and recall averages on all element types of the 10
generated transformations for the 3-folds. As mentioned in [
In the second strategy, precision and recall averages are low (less than 0.5) in the 3-folds. This is due to the fact that the generated rules are very large and contain different informations from different examples. Thus, the premises of the rules can not be matched for most of the examples because the examples are simple and do not contain all the transformation cases that have been learned. So, the Jess rule engine does not apply a part of the rule premise when it is executed on an example, it searches for each example its corresponding rule and this decreases the precision and the recall. 5.3
Discussion The study presented in this section is a comparison of two strategies for generating transformation rules using RCA. The first consists to generate from each example its rule lattice and the second consists to gather all the examples and generate only one rule lattice. Each one has its advantages and disadvantages: – The first strategy produces simple and small transformation patterns which are easy to analyze and to manipulate, but they are proper to their examples. On the other side, the second one produces larger patterns but they are more specific and more complete. They combine different information about the transformation. An analysis on those patterns shows that the two strategies have the same number of relevant patterns (about 12 transformation patterns). The relevant ones of the first strategy are simple and applicable for each example. On the contrary, the relevant patterns of the second strategy are larger and mainly applicable for larger examples.
Examples Examples 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10
Examples
Fold1 – The execution of the rules of the first strategy gives good results in our experiment. The rule engine searches and finds for each example the set of rules to apply. On the contrary the rules of the second strategy are more large and contain more information. Thus the rule engine does not find a rule to apply for the simple examples. We can work again on the obtained rules of Li to execute them on all types of examples (for example by separating into smaller pieces), but as we found good results with the union of lij, it is not a promising track. We obtained a non-intuitive result: before the experimentation, we thought the best rules would be obtained with the second strategy.
Although the example used is a classical one, it is a good example of typical model transformations that we aim to learn. To confirm what is the best strategy to produce transformation rules, additional experiments have to be conducted with other model transformation kinds. Besides, the obtained result depends on the models on which we execute the rules. If we use larger models, the second strategy may have better results. 6
Writing model transformations requires time and specific skills: the transformation developer needs to master the transformation language and both transformation source and target meta-models. Model Transformation by Example is a recent field of research that intends to use models as artifacts of development of the transformation.
Most of the research works consider all the examples at once. In [
Another track in MTBE consists in using the analogy to perform
transformations using examples [
In this paper, we studied an approach for inferring model transformations (composed of transformation rules) from transformation examples. We compare two strategies for applying this approach: inferring the rules from the example taken separately (then gathering the rules), or inferring the rules from the gathering of the examples. Although we thought the second strategy would produce better rules (more detailed), it appeared that the rules (less detailed) produced by the first approach execute better. Future work includes learning rules whose premise and conclusion have several main elements and design heuristics to determine the best rule to apply when several rules are candidate.