This document presents an approach for reusing model transformations through the extraction of typing requirements models (TRMs) from transformations. TRMs characterize the minimal requirements that source and target meta-models must satisfy for a transformation to be well-typed. The approach extracts TRMs from ATL transformations through an attribute grammar. Meta-models can then be checked for conformance to the TRMs to determine if a transformation can be reused. An evaluation of the approach on four transformations showed that it achieved high precision and recall in checking over 2,000 mutated meta-models for conformance.

1. REUSING MODEL
TRANSFORMATIONS THROUGH
TYPING REQUIREMENTS
MODELS
FASE’2017, Uppsala
J. de Lara1, J. Di Rocco2, D. Di Ruscio2, E. Guerra1, L. Iovino3,
A. Pierantonio2, J. S. Cuadrado1
1Universidad Autónoma de Madrid (Spain)
2University of L’Aquila (Italy)
3Gran Sasso Science Institute (Italy)

2. MOTIVATION &
OVERVIEW
Model driven engineering
• Domain-specific languages
• Proliferation of meta-models
Model to model transformations
• typed w.r.t. source and target
meta-models
• hard to reuse for other, similar
meta-models
2
Msrc Mtar
«conforms to» «conforms to»
Transformation
execution
MMsrc
Transformation
definition
to
MMtar
from
from
to

3. MOTIVATION &
OVERVIEW
3
Can I use my meta-model(s) with an existing transformation?
Msrc Mtar
«conforms to» «conforms to»
Transformation
execution
MMsrc
Transformation
definition
to
MMtar
from
from
to
Model driven engineering
• Domain-specific languages
• Proliferation of meta-models
Model to model transformations
• typed w.r.t. source and target
meta-models
• hard to reuse for other, similar
meta-models
MM’src
from
MM’tarto
?

4. MOTIVATION &
OVERVIEW
4
What are the (minimal) requirements for src/tar meta-models
to work with a transformation definition?
Msrc Mtar
«conforms to» «conforms to»
Transformation
execution
tofrom
Model driven engineering
• Domain-specific languages
• Proliferation of meta-models
Model to model transformations
• typed w.r.t. source and target
meta-models
• hard to reuse for other, similar
meta-models
MM’src MMtar
source
MM reqs
target
MM reqs
Transformation
definition
from to
compatibility
«conforms to» «conforms to»«typing reqs»
TRM

5. AGENDA
Example
Typing requirement models
Extracting typing requirements from ATL trafos
Implementation and validation
Related research
Conclusions and Future work
5

6. EXAMPLE:
JAVA METHOD CALLS TO TABLE
class Action {
public void do() {
if (this.pre()) this.exec();
}
public boolean pre() {…}
public void exec() {… this.do()…}
}
6
do()
pre()
exec()
do() pre() exec()
0 1 1
0 0 0
1 0 0
Action
Java
Source
NamedElement
name: String
Class
Declaration
Method
Definition
super
class
methods
*class
Method
Invocation
invocations*
method
classes
*
Table
Row
Cell
content: String
rows
cells
1..*
1..*

7. EXAMPLE (1/2):
JAVA METHOD CALLS TO TABLE
module JavaSource2Table;
create OUT : Table from IN : JavaSource;
rule Class2Table {
from s : JavaSource!ClassDeclaration
to t : Table!Table ( rows <- s.methods )
}
rule Method2Row {
from m : JavaSource!MethodDefinition
to row : Table!Row (
cells <- Sequence{JavaSource!MethodDefinition.allInstances()
->collect(md | thisModule.DataCells(md, m))}
)
}
7

8. EXAMPLE (2/2):
JAVA METHOD CALLS TO TABLE
lazy rule DataCells {
from md: JavaSource!MethodDefinition,
m: JavaSource!MethodDefinition
to cell: Table!Cell (
content <- m.computeContent(md)
)
}
helper context JavaSource!MethodDefinition def :
computeContent(col : JavaSource!MethodDefinition) : String =
self.invocations->select(i |
i.method.name = col.name
and i.method.class.name = col.class.name)
->size().toString();
8

9. REUSING THE
TRANSFORMATION
9
?
…
Can we reuse the
transformation
with different
meta-models?

10. DESCRIBING TYPING
REQUIREMENTS
Domain Typing Requirements (DRMs)
• Models to describe requirements from meta-models
• Characterize sets of meta-models
Classes
• Named and anonymous
• Abstract, concrete or don’t care
• Restrictions regarding inheritance
Features
• Name and optionally a type (reference or attribute)
• More mandatory fields allowed or not
• Several possible target classes for references
• Uncertainty in cardinalities
10

11. DRM META-MODEL
11
mandatoryAllowed: boolean
subsAllowed: boolean
isAbstract: UBoolean
Feature
name: String[1]*
feats
Reference
Cardinality
Number
value: int
allowLess: boolean
allowMore: booolean
Any
Cardinality
Many
min 1
max 1
Attribute
* targets
DataType
Numeric
Real Integer
StringAny
DataType
Enum Literal
name: String[1]name: String[0..1]
*
literals
dtype1
ancs
*
antiancs *
FeatureType
*
isOrdered: UBoolean
isUnique: UBoolean
<<enum>>
UBoolean
True
False
Any
Anonymous
Class
types
INVARIANTS:
context Feature inv: not self.min.oclIsTypeOf(Many)
Boolean
Class
Named
Class
name: String

12. SOURCE/TARGET DRMs
12
MethodDefinition
name: AnyDataType
class?..* invocations
method
name: AnyDataType name: AnyDataType
class
Class
Declaration
? methods
1
1
1
Table
Row
Cell
? rows
content: String
?..* cells
name: AnyDataType
C
C
C
AC AC
AC AC
AC AC
C concrete class
AC abstract or concrete class
anonymous class extra mandatory features forbidden
Conformance checking can be
deferred to subclasses
anti ancestor ? rows attribute or reference
Legend

13. META-MODEL
CONFORMANCE
13
…

14. CONFORMANCE
EXAMPLES
14
Method
Definition
name:String
NamedElement
Class
Declaration
methods * class1
Method
Invocationinvocations
*
method
1
Method
Definition
name:int
Class
Declaration
methods *
class1
invocations*
method
1
name:String
MethodDefinition
name:AnyDataType
class?..* invocations
method
name:AnyDataType name:AnyDataType
class
Class
Declaration
? methods
1
1
1
name:AnyDataType
AC AC
AC AC
AC AC

15. CONFORMANCE
EXAMPLES
15
MethodDefinition
name:AnyDataType
class?..* invocations
method
name:AnyDataType name:AnyDataType
class
Class
Declaration
? methods
1
1
1
name:AnyDataType
AC AC
AC AC
AC AC
Nested
Method
Method
Definition
Inner
Method
Public
Method
name:String
Class
Declaration
name:String
class 1
methods
class
methods
*
*
Method
Invocation
method
invocations
1
*
Class
Declaration
methods *
class1
name:String
1
Method
Definition
name:int
invocations*
method
1

16. COMPATIBILITY
REQUIREMENTS
16
JavaSource2Table
SourceDRM TargetDRM
ClassDeclaration.methods
Reference
Integer Real
Table.rows
ReferenceAttribute
MethodDefinition ClassDeclaration Table Row
Compatibility rules (source choices)
Integer (1) requires Integer (5) or Real (6)
Real (2) requires Real (6)
MethodDefinition (3) requires Row (8)
ClassDeclaration (4) requires Table (7)
Integer Real
1 2 3 4 5 6 7 8
Compatibility rules (target choices)
Integer (5) requires Integer (1)
Real (6) requires Integer (1) or Real (2)
Table (7) requires ClassDeclaration (4)
Row (8) requires MethodDefinition (3)
Attribute
Table
? rows
CClass
Declaration
? methods
AC rule Class2Table {
from s : JavaSource!ClassDeclaration
to t : Table!Table ( rows <- s.methods )
}

17. EXTRACTING REQUIREMENTS
FROM ATL TRAFOS
ATL attribute grammar
17

18. EXTRACTING REQUIREMENTS
FROM ATL TRAFOS
ATL attribute grammar
18

19. IMPLEMENTATION
Eclipse plugin called TOTEM
• http://github.com/totem-mde/totem
19

20. EVALUATION
Empirical, using mutation-based testing
Four transformations developed by third parties
• Extract TRM
• Generate mutants of original src/tar meta-models
• Check conformance to TRM
• Check well-typedness using anATLyzer1 as oracle
20
M-to-M
transform.
extract
TRM
TRM
MMs MMt mutate MM’s MM’t
«typed by» «conforms»?
M-to-M
transform.
«well typed»?
conf? well
typed?
Y
result
Y TP
Y N FP
N Y FN
N N TN
1 J.S. Cuadrado, E. Guerra, J. de Lara. “Static analysis of model transformations”. IEEE TSE 2017.

21. EVALUATION
21
FPTP
TP
precision
##
#
+
=
(indication of correctness) (indication of completeness)
FNTP
TP
recall
##
#
+
=

22. CONCLUSIONS OF THE
EVALUATION
High precision and 100% recall
We could reuse the trafos with around 2.000 meta-models
Some false positives
• Limitation in the extraction process (eg., mandatory
cardinalities relaxed to optional)
Threats to validity
• Low number of transformations
• Still, around 3.300 meta-model mutants
• Completeness of mutation operators?
• anATLyzer as oracle.
22

23. RELATED WORK
Concepts
• “minimal meta-model”
• binding (adaptation)
Zschaler
• typing requirements using logic
• in-place trafos
Transformation footprints
• slice of the meta-model
Transformation intents
• semantic properties
Model uncertainty
• model annotations
23
Zschaler. Towards constraint-based model
types: A generalised formal foundation for
model genericity. VAO’14,, ACM
Cuadrado, Guerra, de Lara. A component
model for model transformations. IEEE TSE
2014.
Jeanneret, Glinz, Baudry. Estimating
footprints of model operations. ICSE 2011.
Salay, Zschaler, Chechick. Correct reuse of
transformations is hard to guarantee. ICMT
2016.
Famelis, Salay, Chechick. Partial models:
towards modeling and reasoning with
uncertainty. ICSE 2012.

24. CONCLUSIONS
New approach to model transformation reuse
TRMs, extracted from the transformation
Conformance of MM with respect to TRMs
Prototype tool support (TOTEM)
Evaluation showing good results
24

25. FUTURE WORK
Add binding to conformance relation
• Resolve heterogeneities (eg., renamings)
Heuristics for MM generation from DRMs
Incorporate semantic notions
• Transformation intents?
Graphical modelling tools for TRMs
Correctness proofs of TRM extraction
25

26. THANKS!
Juan.deLara@uam.es
26
http://www.miso.es
@miso_uam