Change-driven model transformations

362 views
285 views

Published on

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
362
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Change-driven model transformations

  1. 1. Change‐Driven
Model
 Transforma5ons
 Derivaon
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. 2. Outline
of
the
talk
  Introduc5on
  Mo5va5on
  Overview
of
the
concept
  Change‐driven
transforma5ons
in
detail
  Summary
  Future
work

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

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

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

  6. 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
 Transformaon
for
the
Evoluon
of
Model‐driven
Systems.
 MODELS
2006.
 o Ráth‐Ökrös‐Bergmann‐Varró.
Live
model
transformaons
 driven
by
incremental
paCern
matching.
ICMT
2008.
 •  Transac5on‐oriented
approach
 •  Reac5ons
possible
to
arbitrarily
complex
changes

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

  8. 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:
 Transformaon
for
the
Evoluon
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”
 transformaons
driven
by
incremental
paCern
 matching.
ICMT
2008.
 •  Transac5on‐oriented
approach

  9. 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. 10. Mo5va5ng
scenario
 Source
 Target
 MA
 MB
 change
 ?
 IF
 MA’
 MB’
 Trace
 record
High
level
(domain‐ Deployed
process
 specific)
process
 template
(jPDL)
 model

  11. 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. 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. 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. 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. 15. Change
history
metamodel
 Historical
 record
 Weak
 references
Opera5on
categories

  16. 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. 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. 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. 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. 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. 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. 22. Manipula5ng
non‐materialized
models
with
VIATRA
 VIATRA
na5ve
func5ons
 allow
for
DOM‐style
 manipula5on
of
the
 deployed
jPDL
process
 template.

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


×