Presented at MODELS2009. Received the Springer Best Paper Award and the ACM Distinguished Paper Award.

1. Change‐Driven Model
Transforma5ons
Deriva'on and Processing of Change Histories
István Ráth, Gergely Varró, Dániel Varró
rath@mit.bme.hu
Budapest University of Technology and Economics
Model Driven Engineering Languages and Systems 2009, Denver, Colorado, USA

2. Outline of the talk
 Introduc5on
 Mo5va5on
 Overview of the concept
 Change‐driven transforma5ons in detail
 Summary
 Future work

3. Mo5va5ng scenario: forward model synchroniza5on
Source Target
MA MB
change
MA’ MB’

4. Incremental model synchroniza5on and 'me
 On‐demand: batch transforma5ons
o The “tradi5onal” way

5. Incremental model synchroniza5on
Source Target
MA MB
change
MA’ MB’
• Re‐transform
• Target incrementality

6. Model synchroniza5on and 'me
 On‐demand: batch transforma5ons
o The “tradi5onal” way
 Instantly: live transforma5ons
o React instantly to context (model) changes
• “event‐driven” transforma5ons
o Hearnden‐Lawley‐Raymond. Incremental Model
Transforma'on for the Evolu'on of Model‐driven Systems.
MODELS 2006.
o Ráth‐Ökrös‐Bergmann‐Varró. Live model transforma'ons
driven by incremental paCern matching. ICMT 2008.
• Transac5on‐oriented approach
• Reac5ons possible to arbitrarily complex changes

7. Live model synchroniza5on
Source Target
MA MB
change
MA’ MB’
2. React to 3. Merge
1. Watch for changes
changes

8. Model synchroniza5on and 'me
 On‐demand: batch transforma5ons
o The “tradi5onal” way
 Instantly: live transforma5ons
o React instantly to context (model) changes
• “event‐driven” transforma5ons
o Hearnden‐Lawley‐Raymond. Incremental Model
Common assump5ons:
Transforma'on for the Evolu'on of Model‐driven
1. All models are available in
Systems. MODELS 2006. memory
2. Changes are propagated
o Ráth‐Ökrös‐Bergmann‐Varró. Live model
“synchronously”
transforma'ons driven by incremental paCern
matching. ICMT 2008.
• Transac5on‐oriented approach

9. Asynchronous synchroniza5on
 What if…
o Some models cannot (should not) be materialized in
memory?
• Models are too large
• Models have to be manipulated “inside” their na5ve
environment (tool)
o Changes are to be applied/reproduced “later”?
• Changes have to recorded for e.g. traceability
  Asynchronous (off‐line) synchroniza5on

10. Mo5va5ng scenario
Source Target
MA MB
change
? IF
MA’ MB’
Trace
record
High level (domain‐
Deployed process
specific) process
template (jPDL)
model

11. Case study and challenges
 Tool integra5on in a heterogeneous environment
o Developed for the SENSORIA and MOGENTES EU
research projects
 High level process models describe (complex)
development process segments
o E.g. automated test genera5on, deployment
configura5on genera5on
 Processes are executed in
o A distributed environment (worksta5ons, tool servers)
o Orchestrated by the jBPM process execu5on engine.

12. Challenges
 Challenge #1: high level models are edited 
changes have to be propagated to the deployed
process template
 Challenge #2: changes are mapped
asynchronously in 5me
o Not (necessarily) by the process engineer

13. Conceptual overview
3. Apply changes to
Source Target
external models
through an interface
MA MB (IF)
change CHMA CHMB
IF
MA’ MB’
1. Record changes 2. Map source changes to
into traceability target changes (=CHMs to
models (=CHMs) CHMs) instead of source
models to target models

14. Change history models
 Traceability models CHMA CHMB
o Opera5onal difference models
o Record historical opera5on sequences
• WHEN (5mestamps in a linked list structure)
• WHAT (CUDM)
• Context (referenced model elements)
o “weak” references
• IDs or FQNs
• Allows to reference external (non‐ or par5ally materialized)
models

15. Change history metamodel
Historical
record
Weak
references
Opera5on
categories

16. Genera5on of CHMs
 Live transforma5ons
Source o Editor‐independent!
 Generate trace model
MA
snippets as the user is
edi5ng the model
change CHMA
o Timestamps
o Contextual references
MA’

17. Genera5on of CHMs: Generic example
: parentFQN
Sample execu5on sequence:
Parent
CE: CreateEn5ty
{pre}
Timestamp: <sysTime()>
Name: <name(E)>
E:Type : targetFQN {new}
: typeFQN
Type
En5ty and Rela5on are
basic VIATRA concepts for
{pre}
: newSrcFQN
graph node and edge
Src
CR: CreateRela5on
R:Type Timestamp: <sysTime()>
Name: <name(R)>
Trg : newTrgFQN {new}
: typeFQN
Type

18. Genera5ng domain‐specific CHMs
{pre}
W: : parentID
2a. Create a compound
Workflow CJN: CreateJPDLNode
CHM sequence as
Timestamp: <sysTime()>
postcondi5on
I: Invoca5on : targetID {new}
: next
: parameters : returns
DI: DO: CJA: CreateJPDLAtribute
DataInput DataOutput targetID: CJN.targetID
+”.parameters”
1. Use a compound parentID: CJN.targetID
patern as 2b. Use a
targetTextValue: value(DI)
precondi5on, : next
“compressed” CHM
corresponding to a CJA: CreateJPDLAtribute
element corresponding
(complex) model to a complex domain‐
targetID: CJN.targetID+”.returns”
parentID: CJN.targetID
structure specific opera5on
targetTextValue: value(DO)

19. Change‐driven transforma5ons
 Input:
o Changes of the source
model
Source Target  Output
o Corresponding changes of
CHMA CHMB the target model
 May be formulated as:
MA’ o Live transforma5on
o Batch transforma5on
 Granularity?
o “one‐to‐one”
o “n‐to‐m”

20. Mapping CHMs
{pre}
Parent : parentFQN
CE: CreateEn5ty
Sample execu5on con5nued:
E:Invoca5on typeFQN = meta.Invoca5on
func5onName:<> : targetFQN
: typeFQN
Invoca5on
{new}
CJN: CreateJPDLNode
targetID: name(Parent)+”.”+name(E)
parentID: name(Parent)
For each newly created
Invoca5on, create a
: next corresponding JPDL node
CJA: CreateJPDLAtribute together with is “func5on”
targetID: CJN.targetID+”.fun5on” atribute (=domain‐specific
parentID: CJN.targetID
targetTextValue: E.func5onName mapping logic)

21. Applying CHMs to external models
 Applying CHMs = model
Target “interpreta5on”
 External models are
MB
manipulated through a
(service) interface
CHMB
o VIATRA: “na5ve func5ons”
IF
MB’

22. Manipula5ng non‐materialized models with VIATRA
VIATRA na5ve func5ons
allow for DOM‐style
manipula5on of the
deployed jPDL process
template.

23. Summary
 Change‐driven transforma5ons =
o An innova5ve synthesis of known techniques:
• Trace models
• Live transforma5ons
• Non‐materialized model manipula5on
o A solu5on for an engineering problem
o Lots of open ques5ons and new ideas…

24. Future work
 A beginning, rather than an end…
 Lots of open ques5ons
o How to write CDTs?
o How to generate CDTs from “tradi5onal”
transforma5ons?
 Are they useful?
o Efficient, intui5ve model synchroniza5on
o Change representa5on, processing ( (re)verifica5on,
change impact analysis)
o Model merging (~opera5onal merging)
 Thank you for your aten5on.