Foundations of Model Transformations A lambda calculus for MDD

1
Foundations of Model Transformations A lambda
calculus for MDD ?

• Reiko Heckel
• University of Leicester, UK

2
Motivation

• At the heart of model-driven engineering are
  activities like
• maintaining consistency
• evolution
• translation
• execution
• of models
• These are examples of model transformations

• A math. foundation is needed for studying
• Expressiveness and complexity
• Execution and optimisation
• Well-definedness
• Semantic correctness
• of transformations
• This lecture is about graph transformations as
  one such foundation

3
Outline

• Graph transformation
• why it is fun
• how it works
• Model transformation
• Theory and Tools

4
Why it is fun Programming By Example

• StageCast (www.stagecast.com) a visual
  programming environment for kids (from 8 years
  on), based on
• behavioral rules associated to graphical objects
• visual pattern matching
• simple control structures (priorities, sequence,
  choice, ...)
• external keyboard control
• intuitive rule-based behavior modelling
• Next abstract from concrete visual presentation

5
States of the PacMan GameGraph-Based
Presentation
Ghost
Field
Field
PacMan marbles3
Field
Field
Field
Marble
Field
neighbor
6
Rules of the PacMan GameGraph-Based
Presentation, PacMan
pmPacManmarblesm
pmPacManmarblesm1
Marble
collect
f1Field
f2Field
f1Field
f2Field
pmPacMan
pmPacMan
movePM
f1Field
f2Field
f1Field
f2Field

• PacMans rules collect has priority over movePM

7
Rules of the PacMan GameGraph-Based
Presentation, Ghost
gGhost
PacMan
gGhost
kill
f1Field
f2Field
f1Field
f2Field
gGhost
gGhost
moveGhost
f1Field
f2Field
f1Field
f2Field

• Ghosts ruleskill has priority over moveGhost

8
Graph Transformation
Field
Field
Ghost
collect kill
PacMan marbles3
PacMan marbles4
Field
Field
Field
Field
typing
PacManmarblesint
1
1


Field
Ghost
1

Marble
9
How it works Typed Graphs

• Directed graphs as algebraic structures G (V,
  E, src, tar) with src, tar E ? V
• Graph homomorphism as pair of mappings h (hV
  , hE) G1 ? G2 with
• hV V1 ? V2
• hE E1 ? E2
• preserving src and tar
• Typed graphs given by
• fixed type graph TG
• instance graphs G typed over TG by
  homomorphism g G ? TG

xField
Field
Ghost
yField
Field
Field
Field
G
g
PacManmarblesint
Field
Ghost
Marble
TG
10
Rules

• p L ? R with L ? R well-defined, in different
  presentations
• like above (cf. PacMan example)
• with L ? R explicit DPO L ? K ? R

movePM
pmPacMan
pmPacMan
f1Field
f2Field
f1Field
f2Field
11
Rules

• p L ? R with L ? R well-defined, in different
  presentations
• like above (cf. PacMan example)
• with L ? R explicit DPO L ? K ? R
• with L, R integrated UML L ? R and marking
• L - R as destroyed
• R - L as new

movePM
pmPacMan
destroyed
new
f1Field
f2Field
12
Transformation Step Operational
G
f1Field
m1Marble
pmPacMan marbles3
f2Field
m2Marble
f3Field

• select rule p L ? R occurrence oL L ? G
• remove from G the occurrence of L \ R
• add to result a copy of R \ L

13
Semantic Questions Dangling Edges

• conservative solution application is forbidden
• invertible transformations, no side-effects
• radical solution delete dangling edges
• more complex behavior, requires explicit control

?
14
Semantic Questions Conflicts

• conservative solution application is forbidden
• invertible transformations, no side-effects
• radical solution give priority to deletion
• more complex behavior, requires explicit control

a1A
a2A
a1A
?
aA
15
Advanced Features

• Dealing with unknown context
• set-nodes (multi-objects) match all nodes with
  the required connections
• explicit (negative) context conditions
• (turns f1 into a trap by reversing all outgoing
  edges to Field vertices, but only if there is no
  Ghost)
• Control
• priorities movePM only if collect is not
  possible
• programmed transformation IF NOT collect THEN
  movePm

16
Where it comes fromand what it is good for
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars
Diagram Languages
Behaviour Modelling and Visual Programming
Models of Computation
17
Outline

• Graph transformation
• Model transformation
• diagram languages
• execution
• translation
• Theory and Tools

18
Diagram Languages

• theory and tools like for textual languages

AbstractSyntax Graph
operational
semantics
scan
parse
Abstract
Graphical
Concrete
evolution
Elements
Syntax
Syntax
layout
render
denotational
feedback
semantics
Vector graphics
Spatial Relationship Graph
Semantic
Domain
19

Spatial Relationship Graph
receive order
Concrete
check availability
Syntax
product not available
product available
SRG (Instance) Graph
calculate prize
notify client
send receipt
SRG Metamodel(typed graph)
20
AbstractSyntax Graph
parse
Concrete
Abstract
Syntax
Syntax
SRG Graph
ASG
Activity Metamodel
21
Semantics

• Operational semantics (execution)
• concrete syntax animation rules
• abstract syntax graph transformation rules
• Denotational semantics (translation)

22
Operational Semantics
operational
semantics
Abstract
Syntax

• diagram syntax plus runtime state
• visual rules to model state transitions
• produce sequences of states / labels, visualized
  as animations

23
Extended Meta Model Original plus Runtime State
operational
semantics
Abstract
Syntax
24
Operational Rules GT on Meta Model Instances
operational
semantics
Abstract
Syntax
25
Animation
operational
semantics
Abstract
Syntax
placeOrder
placeOrder

• Trace
• placeOrder
• calcBill
• placeOrder

calcBill
calcBill
placeOrder
placeOrder
26
Semantics

• Operational semantics (execution)
• Denotational semantics (translation)
• analyse model (compiler front-end)
• generate semantic representation (compiler
  back-end)

27
AnalysisContext-Free Graph Grammar
Abstract
Syntax
Concrete Syntax of Well-Formed Activity Diagrams
Productions in EBNF-like notation
28
Pair Grammar
Abstract
Syntax
denotational
AAct
Source well-structured activity diagrams
semantics
Semantic
Domain
in
not c
c
do something

out
if c then Proc(A1) else Proc(A2)
do something
29
Generation

• Proc(A0)
• Proc(A1) ? Proc(A2)
• Proc(A3) ? Proc (A4) ?if product available
  then Proc(A5) else Proc(A8)
• receive order ?check availability ?if product
  available then calculate prize ?
  send receipt else notify client

receive order
check availability
product available
product not available
calculate prize
notify client
send receipt
30
Good Enough for Model Transformations?

• Visual
• abstract syntax or concrete syntax templates
• Bi-directional
• inherently symmetry
• Declarative

• Expressive ?
• Context-free graph languages
• Traceable ?
• Naming conventions
• Efficient ?
• NP complete parsing problem
• Incremental ?

Cf. OMGs QVT requirements
31
A Non-Well-Structured Example

• Actions
• Place_order, Pay_bill
• Processes
• A Place_order ? B
• B if non-empty then C else STOP
• C Pay_bill ? E
• E if paid then A else STOP

A
Place order
B
else
C
non-empty
Pay bill
E
paid
else
32
Correspondence RulesInitial, Action, and Final
Nodes

• A
• A act ? B
• B
• A STOP

• Rule pairs, in condensed presentation
• Green/bf ? new
• No restriction to context-freeness
• Correspondence via common names

A
A
act
B
A
33
Correspondence RulesChoice and Join
A

• A if cond then B else C
• B
• C
• A B
• B

else
C
cond
B
A
cond
B
Negative application condition
34
Correspondence RulesConnection to Existing Nodes

• A B

A
B
A
act
B
A
Either alternative is consistent with left side
B
35
Formally Triple Graph Grammars

• Meta model for correspondence
• traceability
• Symmetric rule triplets (left, corr, right),
  generating directed rules
• Declarative ? operational

Target
Source
Metamodel
Metamodel
ltltusegtgt
ltltusegtgt
Corresp.
Metamodel
36
Example TGG Rule
A
A act ? B B
act
B
Proc name A
ActivityEdge
ProcEdge
exp
target
succ
Prefix name act
Var name B
Node label act
new
new
new
source
Proc name B
ActivityEdge
ProcEdge
new
new
new
left
corr
right
37
Derived Operational GT Rule right ? left
Proc name A
ActivityEdge
ProcEdge
exp
target
succ
Prefix name act
Var name B
Node label act
new
new
source
Proc name B
ActivityEdge
ProcEdge
new
new
left
corr
right

• Alternatively
• left ? right
• (left, right) ? corr

38
Outline

• Graph transformation
• Model transformation
• Theory and Tools

39
Theory Sources of Inspirations
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars

• Concurrency theory
• Causality and conflict
• Processes, unfoldings
• Event-structures

• Formal language theory of graphs
• Diagram compiler generators

• Well-definedness
• Termination
• Confluence
• Semantics of process calculi

40
Outline

• Graph transformation
• Model transformation
• Theory and Tools
• General purpose modeling environments
• PROGRES, AGG, Fujaba,
• Environments for specifying visual notations
• DIAGEN, GENGEd,
• Analysis tools
• Groove,

41
PROGRES(PROgrammed Graph Rewriting Systems)

• Graphical/textual language to specify graph
  transformations
• Graph rewrite rules with complex and negative
  conditions
• Embedded in programming notation for OO data base
  transactions
• Cross compilation in Modula 2, C and Java

42
AGG(The Attributed Graph Grammar System)

• Algebraic approach to graph transformation
• Attribute computations in Java
• Efficient graph parsing
• Analysis facilities for critical pairs,
  consistency of rules and invariants

43
Fujaba(From UML to Java and Back Again)

• Round trip engineering with UML, Java, and design
  patterns
• Class and activity diagrams GT rules as
  collaborations
• Generates standalone Java classes
• Various plugins, including triple graph grammars

44
DiaGen(The Diagram Editor Generator )

• VL concrete / abstract syntax specified as CF
  hypergraph grammars
• Generation of diagram editors, parsers, simulators

45
GenGED(Generation of Graphical Env.s for Design)

• Roughly similar to the above, based on AGG

46
GRaphs for Object-Oriented VErification (GROOVE)

• (bounded) generation of LTS from GT systems
• edge-labelled graphs
• application conditions
• rule priorities

http//wwwhome.cs.utwente.nl/groove/groove-index
47
Graph TransformationA lambda calculus for MDD ?

• Expressiveness and complexity
• CF graph grammars Rozenberg Habel
• Relation with MSO logic Courcelle
• Execution and optimisation
• Various tools
• Graph matching Zuendorf 96 Varro et al 05

• Well-definedness
• Term graph rewriting Plump
• Confluence, termination of attributed GT Ehrig
  et al 04
• Semantic correctness
• Requires formal semantics of the languages
  involved
• operational Hausmann et al
• denotational Kuester et al
• Verification through
• proofs several authors
• model checking Varro Rensink
• testing Koenig et al 04

48
Inspired? Join us in Vienna!

• ETAPS 2006
• The event 25 March - 2 April 2006
• Abstract submission Friday 7 October 2005
• Paper submissionFriday 14 October 2005

• GT-VMT 2006
• Paper submission12 December 2005
• 5th Intl Workshop on Graph Transformation and
  Visual Modelling Techniques

49
Questions ?