This document describes a-posteriori typing for model-driven engineering. A-posteriori typing decouples an object's instantiation from its classification, allowing objects to have multiple classifiers and change classifiers at runtime. This is more flexible than traditional constructive typing. The document outlines the design space of possible MDE typings and proposes specifying typings at the type level and instance level. It also discusses analyzing type safety, applying typings to enable bidirectional model transformations through reclassification, and flexibly reusing operations across models. A-posteriori typing supports more flexible reuse, transformation, and analysis for model-driven engineering.

1. A-POSTERIORI TYPING
FOR MODEL-DRIVEN
ENGINEERING
J. de Lara, E. Guerra, J. Sánchez Cuadrado
Modelling&Software Engineering Research Group
http://miso.es
Universidad Autónoma de Madrid (Spain)
MODELS’2015, Ottawa (Canada)

2. Constructive typing
• Creation of objects and classification
are inseparable
Lacks flexibility
• Objects cannot change their type at
run-time (and retain its identity)
Hinders reuse
• An operation defined for a meta-model
cannot be used for another one
MOTIVATION
2
Task
start: Date
duration: int
review: Task
start= 8/5/15
duration=30
creation «instance of»
Tasks meta-model
model

3. Constructive typing
• Creation of objects and classification
are inseparable
Lacks flexibility
• Objects cannot change their type at
run-time (and retain its identity)
Hinders reuse
• An operation defined for a meta-model
cannot be used for another one
MOTIVATION
3
review: Task
start= 8/5/15
duration=10
model
Task
start: Date
duration: int
review: Task
start= 8/5/15
duration=30
creation «instance of»
Tasks meta-model
model

4. Constructive typing
• Creation of objects and classification
are inseparable
Lacks flexibility
• Objects cannot change their type at
run-time (and retain its identity)
Hinders reuse
• An operation defined for a meta-model
cannot be used for another one
MOTIVATION
4
Task
start: Date
duration: int
review: Task
start= 8/5/15
duration=30
creation «instance of»
Tasks meta-model
model
review: Task
start= 8/5/15
duration=0
model

5. Constructive typing
• Creation of objects and classification
are inseparable
Lacks flexibility
• Objects cannot change their type at
run-time (and retain its identity)
Hinders reuse
• An operation defined for a meta-model
cannot be used for another one
MOTIVATION
5
Task
start: Date
duration: int
review: Task
start= 8/5/15
duration=30
creation «instance of»
Tasks meta-model
model
review: Milestone
start= 8/5/15
duration=0
model

6. Constructive typing
• Creation of objects and classification
are inseparable
Lacks flexibility
• Objects cannot change their type at
run-time (and retain its identity)
Hinders reuse
• An operation defined for a meta-model
cannot be used for another one
MOTIVATION
6
Task
start: Date
duration: int
review: Task
start= 8/5/15
duration=30
creation «instance of»
Tasks meta-model
model
Measurable
quantity: int
Measuring MM
review: Milestone
start= 8/5/15
duration=0
model

7. A more flexible typing mechanism for MDE
Decouple instantiation from classification
• Interfaces in object-oriented programming
• Roles in role-based programming languages
Allow dynamic typing and multiple classifiers for objects
Type and instance-level reclassification specifications
• Transformation by reclassification
• Flexible reuse of model management operations
Prototype implementation in our MetaDepth tool
GOALS AND
CONTRIBUTIO
NS
7

8. design space of possible MDE typings
a-posteriori (AP) typing
• specification: type-level vs instance-level
• analysis
tool support & applications
conclusions and future work
AGENDA
8

9. DESIGN SPACE FOR
TYPINGS (1/2)
9
Typing in MDE
dynamicity
static dynamic
classification
time
creation
a-posteriori
#classifiers
single multiple
bounded
optional mandatory alternative
…
Can we add classifiers
for an object after it is
created?
Can an object change
its type at run-time?
How many classifiers
can an object have?
Defined a-priori?

10. DESIGN SPACE FOR
TYPINGS (2/2)
10
Typing in MDE
totality
total partial
#model
types
single multiple
levels
two multiple
optional mandatory alternative
Can a model be
typed by multiple
meta-models?
Can an object
lack type w.r.t.
a type meta-
model?
Is type equivalence
checked by name
or by structure?
type
equivalence
structural
nominal
How many
meta-levels at
the same time
can be used?

11. DESIGN SPACE FOR
TYPINGS (2/2)
11
Typing in MDE
totality
total partial
#model
types
single multiple
levels
two multiple
optional mandatory alternative
Can a model be
typed by multiple
meta-models?
Can an object
lack type w.r.t.
a type meta-
model?
Is type equivalence
checked by name
or by structure?
type
equivalence
structural
nominal
How many
meta-levels at
the same time
can be used?
Mainstream MDE
approaches have
made the less
flexible choices
in the typing space

12. AP TYPING MOTIVATION:
REUSE
12
Measurable
quantity: int
Schedulable
date: Date
review: Task
Scheduling MM Measuring MM
model
«instance of» «instance of»
start= 8/5/15
duration= 30
name= “rev”
«Schedulable,Measurable»
*
*
res
Task
start: Date
duration: int
name: String
Resource
Person
owner
assigned
1..*
creation meta-model
role meta-models
creation
«instance of»
a-posteriori typingcreation typing
operation
typing of operation
applicable to

13. 13
AP TYPING MOTIVATION:
FLEXIBLE REUSE
*topics
*
*
res
Task
start: Date
duration: int
name: String
Tasks meta-model (constructive types)
Resource
Person
owner
assigned
1..* 1..*
0..3
reviewsArticle
title: String
Conference meta-model (dynamic types)
Reviewer
Authorauthors
Topic
desc: String
«Author»
p2: Person
«Reviewer»
p1: Person
«Article»
r: Resource
:owner
t1:Task
start: 8/5/15
duration: 30
name: “rev”
:res
:assigned
«Author,Reviewer»
p2: Person
«Reviewer»
p1: Person
«Article»
r: Resource
:owner
t1:Task
start: 8/5/15
duration: 30
name: “rev”
:res
:assigned
«Author»
p3: Person
«Article»
s: Resource
:owner
t2:Task
start: 9/5/15
duration: 30
name: “rev”
:res
:assigned
the model
changes
and gets
retyped
creation «instance of»
model
• A Person (constructive type) is only a Reviewer (a posteriori type)
when some condition is met.

14. SPECIFYING AP TYPINGS
AT THE TYPE-LEVEL
14
Schedulable
date: Date
span: double
review: Task
Tasks meta-model ( MMC )
start= 8/5/15
/months= 1
duration= 30
name= “rev”
Scheduling MM ( MMR )
Task
start: Date
duration: int
name: String
Typing Specification
Task  Schedulable
self.start  date
/months: double=self.duration/30  span
«Schedulable»
«date»
«span»
creation «instance of»
(constructive)
«instance of»
(a-posteriori)
• Derived attributes (months) defined in the typing
specification.
• Typing rules: ensure correctness, see paper

15. TYPE-LEVEL AP TYPING
15
date: Date
span: double
writing: Task
start= 15/3/15
duration= 90
name= “wrt”
review: Task
start= 8/5/15
duration= 30
name= “rev”
Schedulable
Scheduling MM (MMR)
Instance model of Tasks ( MMC )
«instance of»
(a-posteriori)
“Scheduling glasses”
Operations
review:
Schedulable
date= 8/5/15
span= 1
{review, writing}
{1, 3}
Schedulable.allInstances()
writing:
Schedulable
date= 15/3/15
span= 3
Schedulable.allInstances()->
collect(span)

16. 16
TYPE-LEVEL TYPING IN THE
TYPING SPACE
type-level AP typing
totality
total partial
#model
types
single multiple
dynamicity
static dynamic
classification
time
creation
a-posteriori #classifiers
single multiple
bounded
• Objects with different creation type can have same AP type
• Objects with same creation type cannot have different AP
type

17. SPECIFYING AP TYPINGS
AT THE INSTANCE LEVEL
17
date: Date
span: double
writing: Task
start= 15/3/15
duration= 90
name= “wrt”
review: Task
start= 8/5/15
/months= 1
duration= 30
name= “rev”
«Schedulable»
«date»
«instance of»
(a-posteriori)
Schedulable
Scheduling MM (MMR)
Typing Specification
Task.allInstances()->select(duration<80)
 Schedulable
self.start  date
/months: double=self.duration/30  span
Instance model of Tasks ( MMC )
«span»
• Typing defined by queries.
• Derived attributes defined by queries as well.

18. INSTANCE-LEVEL AP TYPING
18
Operations
date: Date
span: double
writing: Task
start= 15/3/15
duration= 90
name= “wrt”
review: Task
start= 8/5/15
duration= 30
name= “rev”
Schedulable
Scheduling MM (MMR)
Instance model of Tasks ( MMC )
«instance of»
(a-posteriori)
review: Schedulable
date= 8/5/15
span= 1
Schedulable.allInstances()->
collect(span)
{review}
{1}
Schedulable.allInstances()
“Scheduling glasses”

19. INSTANCE-LEVEL AP TYPING
19
Operations
date: Date
span: double
writing: Task
start= 15/3/15
duration= 60
name= “wrt”
review: Task
start= 8/5/15
duration= 30
name= “rev”
Schedulable
Scheduling MM (MMR)
Instance model of Tasks ( MMC )
«instance of»
(a-posteriori)
review:
Schedulable
date= 8/5/15
span= 1
Schedulable.allInstances()->
collect(span)
{review, writing}
{1, 2}
Schedulable.allInstances()
“Scheduling glasses”
writing:
Schedulable
date= 15/3/15
span= 2

20. 20
instance-level AP typing
totality
total partial
#model
types
single multiple
dynamicity
static dynamic
classification
time
creation
a-posteriori #classifiers
single multiple
bounded
INSTANCE-LEVEL TYPING IN
THE TYPING SPACE
• Objects with same creation type can have different AP type

21. ANALYSIS
TYPE-LEVEL AP TYPING
21
Schedulable
date: Date
span: double
Tasks meta-model ( MMC ) Scheduling MM ( MMR )
Task
start: Date
duration: int
name: String
Typing Specification
Task  Schedulable
self.start  date
/months: double=self.duration/30  span
• Creation and role meta-models may have OCL constraints.
• Executability: Can some “Tasks” models become valid
Scheduling models?.
• Totality: Can all Tasks models become valid Scheduling
model?.
• Surjectivity: Can every Scheduling instance be obtained via
retyping some Tasks instance?
• Analysed “merging” both meta-models and using SAT solving
(details in paper)

22. ANALYSIS
INSTANCE-LEVEL AP TYPING
22
• Dynamic type safety: can an AP spec lead to unsafe typings?
• Can be statically analysed via query rewriting:
Can “reviews” contain objects not typed as “Article”? 
Can “res” (of appropriate Tasks) contain something not a “Resource”?
• Details in paper
Typing Specification
Resource.allInstances()  Article
self.owner  authors
Resource.allInstances()->collect(owner)  Author
Task.allInstances()->select(name=“rev”)
->collect(assigned)  Reviewer
Task.allInstances()->select(name=“rev” and
assigned->includes(self))->collect(res)  reviews
Conference meta-model (MMR)
Article
1..*
0..3reviews
ReviewerAuthor
authors
model
*
*
res
Task
start: Date
duration: int
name: String
Tasks meta-model (MMC)
Resource
Person
owner
assigned
1..*
creation

23. // Model
Tasks someTasks {
Task t0 {
start = "30/04/2015";
duration = 30;
name = "coding";
}
}
TOOL SUPPORT
23
MetaDepth
• Multi-level textual modelling
• Integrated with the Epsilon languages
Type and instance level specifications
• EOL for queries in instance-level specs
Dump of models with different typings
Analysis of type-level specs
• Integration with the USE validator
• Bidirectional reclassification
• Reclassification totality and surjectivity
// Meta-model
Model Tasks {
Node Task {
start : Date;
duration : int;
name : String;
}
}

24. APPLICATIONS:
BX MODEL TRANSFORMATIONS
Simple bidirectional model transformations by reclassification
24

25. APPLICATIONS:
BX MODEL TRANSFORMATIONS
Simple bidirectional model transformations by reclassification
25
type Factory PetriNet {
Conveyor::parts > Place::tokens,
Generator::outps > Transition::outs, Terminator::inps > Transition::ins,
Assembler::inps > Transition::ins, Assembler::outps > Transition::outs,
}

26. APPLICATIONS:
BX MODEL TRANSFORMATIONS
Simple bidirectional model transformations by reclassification
26
Forward reclassification

27. Factory example { // 1st typing
Conveyor p {}
Terminator t { inps= [p]; }
}
Factory example { // 2nd typing
Conveyor p {}
Assembler t { inps= [p]; }
}
APPLICATIONS:
BX MODEL TRANSFORMATIONS
27
PetriNet example {
Place p {}
Transition t { ins = [p]; }
}
MetaDepth console
> dump example as Factory
The typing specification can also be used backwards!
Might yield multiple AP typings for a model

28. // Model witness with no Petri net equivalent
Factory noRefinementWitness {
Assembler assembler2 { outps= [conveyor2, conveyor1]; }
Conveyor conveyor1 { name= "string1"; }
Conveyor conveyor2 { name= "string1"; }
Generator generator2 { outps= [conveyor1]; }
Part part2 {
qa = true;
} // This part would become a token outside any Place
}
APPLICATIONS:
BX MODEL TRANSFORMATIONS
28
The reclassification is not total
• Equivalently, the backwards reclassification is not surjective
The solver produces a witness
• A Factory model that cannot be reclassified into a Petri net

29. APPLICATIONS:
REUSE OF OPERATIONS
Simulator for Petri nets can be reused “as is” for Factory
• Provide an AP typing from Factory to Petri nets
• Factory models become typed as Petri nets
29
// EOL excerpt of the simulator
operation Transition enabled() : Boolean {
return self.ins.forAll(p| p.tokens.size()>0);
}
operation step() : Boolean {
var enabled : Set(Transition) := Transition.all.select( t | t.enabled());
... // fire one random Transition from enabled
}

30. APPLICATIONS:
FLEXIBLE REUSE
30
// Type parts as tokens only if QA is passed
type Factory PetriNet inst {
$Conveyor.all$ > Place with {
/sp : Token[*] = $self.parts.select(p|p.qa=true)$ > tokens
}
$Part.all.select( p | p.qa = true )$ > Token
}

31. CONCLUSIONS AND
FUTURE WORK
AP typing is a more flexible approach to typing in MDE
• Decoupled from creation type
• Dynamic
Flexible reuse, transformation by reclassification, analysis
Improve tool support
Exploit structural typing
Annotations to restrict features of AP typing specs:
• Non-overlapping role classes
31

32. THANKS!
Questions?
Juan.deLara@uam.es
32
http://www.miso.es
modelling &
software engineering
research group