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
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
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
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.
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