Slides

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
Outline
of
the
talk
 Introduc5on
 Mo5va5on
 Overview
of
the
concept
 Change‐driven
transforma5ons
in
detail
 Summary
 Future
work
Mo5va5ng
scenario:
forward
model
synchroniza5on
Source
Target
MA
MB
MA’
MB’
change
Incremental
model
synchroniza5on
and
'me
 On‐demand:
batch
transforma5ons
o The
“tradi5onal”
way
Incremental
model
synchroniza5on
Source
Target
MA
MB
MA’
MB’
change
• Re‐transform
• Target
incrementality
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
Live
model
synchroniza5on
Source
Target
MA
MB
MA’
MB’
change
1.
Watch
for
changes
2.
React
to
changes
3.
Merge
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
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
Mo5va5ng
scenario
Source
Target
MA
MB
?
change
MA’
High
level
(domain‐
specific)
process
model
Trace
record
IF
MB’
Deployed
process
template
(jPDL)
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.
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
Conceptual
overview
3.
Apply
changes
to
Target
external
models
through
an
interface
MB
(IF)
Source
MA
CHMA
change
CHMB
IF
MA’
1.
Record
changes
into
traceability
models
(=CHMs)
MB’
2.
Map
source
changes
to
target
changes
(=CHMs
to
CHMs)
instead
of
source
models
to
target
models
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
Change
history
metamodel
Historical
record
Weak
references
Opera5on
categories
Genera5on
of
CHMs
 Live
transforma5ons
Source
o Editor‐independent!
MA
CHMA
change
MA’
 Generate
trace
model
snippets
as
the
user
is
edi5ng
the
model
o Timestamps
o Contextual
references
Genera5on
of
CHMs:
Generic
example
Parent
{pre}
E:Type
CE:
CreateEn5ty
Timestamp:
<sysTime()>
Name:
<name(E)>
:
targetFQN
R:Type
Trg
{new}
:
typeFQN
Type
{pre}
Src
Sample
execu5on
sequence:
:
parentFQN
En5ty
and
Rela5on
are
basic
VIATRA
concepts
for
graph
node
and
edge
:
newSrcFQN
CR:
CreateRela5on
Timestamp:
<sysTime()>
Name:
<name(R)>
:
newTrgFQN
Type
{new}
:
typeFQN
Genera5ng
domain‐specific
CHMs
{pre}
W:
Workflow
I:
Invoca5on
:
parameters
DI:
DataInput
1.
Use
a
compound
patern
as
precondi5on,
corresponding
to
a
(complex)
model
structure
:
parentID
2a.
Create
a
compound
CJN:
CreateJPDLNode
CHM
sequence
as
Timestamp:
<sysTime()>
postcondi5on
:
targetID
:
returns
DO:
DataOutput
:
next
{new}
CJA:
CreateJPDLAtribute
targetID:
CJN.targetID
+”.parameters”
parentID:
CJN.targetID
targetTextValue:
value(DI)
2b.
Use
a
:
next
“compressed”
CHM
CJA:
CreateJPDLAtribute
element
corresponding
targetID:
CJN.targetID+”.returns”
to
a
complex
domain‐
parentID:
CJN.targetID
targetTextValue:
value(DO)
specific
opera5on
Change‐driven
transforma5ons
 Input:
o Changes
of
the
source
model
Source
CHMA
Target
CHMB
 Output
o Corresponding
changes
of
the
target
model
 May
be
formulated
as:
MA’
o Live
transforma5on
o Batch
transforma5on
 Granularity?
o “one‐to‐one”
o “n‐to‐m”
Mapping
CHMs
{pre}
CE:
CreateEn5ty
:
parentFQN
Parent
E:Invoca5on
Sample
execu5on
con5nued:
typeFQN
=
meta.Invoca5on
:
targetFQN
func5onName:<>
:
typeFQN
Invoca5on
{new}
CJN:
CreateJPDLNode
targetID:
name(Parent)+”.”+name(E)
parentID:
name(Parent)
:
next
CJA:
CreateJPDLAtribute
targetID:
CJN.targetID+”.fun5on”
parentID:
CJN.targetID
targetTextValue:
E.func5onName
For
each
newly
created
Invoca5on,
create
a
corresponding
JPDL
node
together
with
is
“func5on”
atribute
(=domain‐specific
mapping
logic)
Applying
CHMs
to
external
models
 Applying
CHMs
=
model
“interpreta5on”
 External
models
are
manipulated
through
a
(service)
interface
Target
MB
CHMB
o VIATRA:
“na5ve
func5ons”
IF
MB’
Manipula5ng
non‐materialized
models
with
VIATRA
VIATRA
na5ve
func5ons
allow
for
DOM‐style
manipula5on
of
the
deployed
jPDL
process
template.
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…
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.