Transcript Introduction to Graph Transformation

Foundations of Model Transformations
A “lambda calculus” for MDD ?
Reiko Heckel
University of Leicester, UK
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
Outline
 Graph transformation
 why it is fun
 how it works
 Model transformation
 Theory and Tools
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
States of the PacMan Game:
Graph-Based Presentation
:Ghost
:Field
:Field
:Field
:Field
:Field
:PacMan
marbles=3
:Marble
:Field
instance graph
(represents a
single state;
abstracts from
spatial layout)
typing
neighbor
Ghost *
cardinalities
(specify additional
constraints on well-typed
instance graphs)
1
1 * PacMan
Field
marbles:int
1
*
Marble
type graph
(specifies legal
instance graphs
 state space)
Rules of the PacMan Game:
Graph-Based Presentation, PacMan
pm:PacMan
marbles=m
:Marble
f1:Field
f2:Field
pm:PacMan
f1:Field
pm:PacMan
marbles=m+1
collect
f1:Field
pm:PacMan
movePM
f2:Field
f2:Field
f1:Field
f2:Field
PacMan’s rules:
collect has priority over movePM
Rules of the PacMan Game:
Graph-Based Presentation, Ghost
g:Ghost
:PacMan
f1:Field
f2:Field
g:Ghost
f1:Field
g:Ghost
kill
f1:Field
g:Ghost
moveGhost
f2:Field
f2:Field
f1:Field
f2:Field
Ghost’s rules:
kill has priority over moveGhost
Graph Transformation
:Field
:Ghost
:Field
:Field
:Field
:Field
:PacMan
marbles=3
marbles=4
:Marble
:Field
typing
Ghost *
1
Field
1
*
Marble
1 *
PacMan
marbles:int
collect ;
kill
How it works: Typed Graphs
Directed graphs as algebraic
structures G = (V, E, src,
x:Field
:Ghost
:Field
y:Field
:Field
:Field
tar)
with src, tar: E  V
Graph homomorphism as
pair of mappings
:Field
h = (hV , hE): G1  G2 with


hV : V 1  V 2
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
G
g
Ghost
Field
Marble
PacMan
marbles:int
TG
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
pm:PacMan
f1:Field
f2:Field
movePM:
pm:PacMan
f1:Field
f2:Field
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:
pm:PacMan
{destroyed}
f1:Field
{new}
f2:Field
Transformation Step: Operational
pm:PacMan
marbles=m
m1:Marble
f2:Field
f1:Field
L
p
pm:PacMan
marbles=m+1
R
f2:Field
oL
oR
G
H
f1:Field
m1:Marble
f2:Field
pm:PacMan
marbles=3
f2:Field
f3:Field
m2:Marble
f3:Field
1.
2.
3.
f1:Field
f1:Field
pm:PacMan
marbles=4
m2:Marble
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
Semantic Questions: Dangling Edges
a:A
a:A
:B
?
 conservative solution: application is forbidden
 invertible transformations, no side-effects
 radical solution: delete dangling edges
 more complex behavior, requires explicit control
Semantic Questions: Conflicts
a1:A
a2:A
a:A
a1:A
?
 conservative solution: application is forbidden
 invertible transformations, no side-effects
 radical solution: give priority to deletion
 more complex behavior, requires explicit control
Advanced Features
Dealing with unknown context


set-nodes (multi-objects): match all nodes with the required
connections
explicit (negative) context conditions
:Ghost
f1:Field
:Field
:Field
f1:Field
:Field
:Field
(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;
Where it comes from
and what it is good for
Chomsky
Grammars
Term
Rewriting
Petri
Nets
Graph Transformation and Graph Grammars
Diagram
Languages
Models of
Computation
Behaviour
Modelling and
Visual Programming
Outline
 Graph transformation
 Model transformation
 diagram languages
 execution
 translation
 Theory and Tools
Diagram Languages
 theory and tools like for textual languages
operational
semantics
scan
Graphical
Elements
parse
Concrete
Syntax
render
layout
Abstract
Syntax
feedback
Vector
graphics
Spatial
Relationship
Graph
Abstract
Syntax
Graph
evolution
denotational
semantics
Semantic
Domain
Spatial
Relationship
Graph
receive order
:Ellipse
has
has
:Polyline
from
:Line
to
has
to
:Line
from
has
:Rect
in
:Text
has
Concrete
Syntax
check availability
has
:Polyline
from
:Line
has
to
:Line
from
has
[product available]
[product not
available]
to
:Rect
in
:Text
has
has
SRG
(Instance) Graph
calculate prize
notify client
:Polyline
from
to
has
to
:Line
from
has
has
send receipt
:Line
:Line
:Polyline
to
has
to
has
has
:Polygon
from
:Line
has
has
:Line
:Polyline
to
:Rect
SRG
srg
SRG Metamodel
(typed graph)
0..1
has
in
:Rect
:Polyline
from
:Line
1
has
*
1
to from
1
1
1 has
*
Point
*
has
1
to
Text
Polygon
1
:Line
:Polyline
to
has
:Polygon
to
has
to
has
has
:Polyline
to
has
:Line
Rect
1
has
has
:Line
:Line
has
:Line
has
from
from
:Polyline
from
:Line
in
from
to
has
to
:Line
from
has
has
has
to
:Rect
from
1 in
1
:Text
from
has
1
Ellipse
in
has
:Text
has
Element
Line
from
has
*
Polyline
:Line
has
from
from
has
to
has
:Ellipse
in
:Ellipse
has
:Text
:InitialNode
:Ellipse
source
has
Abstract
Syntax
Graph
has
:Polyline
from
:Line
to
has
to
:Line
from
has
:Rect
in
:Text
:ActivityEdge
target
:ActivityNode
source
has
parse
has
:Polyline
from
:Line
to
has
to
:Line
in
Abstract
Syntax
Concrete
Syntax
from
has
:Rect
:ActivityEdge
target
:ActivityNode
:Text
source
has
:ActivityEdge
has
:Polyline
from
:Line
to
has
to
target
:Line
SRG Graph
from
has
has
:Line
:Polyline
to
has
to
has
has
:Polygon
from
:Line
has
has
:Line
:Polyline
to
:Line
:ActivityEdge
:Rect
has
in
:DecisionNode
source
:ActivityEdge
target
ASG
from
has
from
from
has
to
has
source
:ActivityNode
source
:Text
target
has
:ActivityNode
:ActivityEdge
has
:Text
in
:Rect
:Polyline
from
has
:Line
to
has
to
target
:Line
from
:Rect
from
:Polyline
has
to
has
:Polygon
to
has
has
to
has
:Polyline
has
to
has
to
:ActivityEdge
target
0..1
Activity
1
0..1
*
in
*
Node
activity
*
source
:Ellipse
guard
InitialNode
FinalNode
MergeNode
*
ActivityEdge
1
from
has
:Ellipse
:MergeNode
has
from
:Line
target
source
activity
:Polyline
:Line
:ActivityEdge
has
:Line
from
source
to
has
:Line
from
:Text
from
:Line
:Line
has
in
:ActivityNode
Activity
Metamodel
has
DecisionNode
1
1
ValueSpecification
target
:FinalNode
target
:ActivityEdge
Semantics
 Operational semantics
(execution)


concrete syntax: animation
rules
abstract syntax: graph
transformation rules
operational
semantics
Abstract
Syntax
 Denotational semantics
denotational
semantics
(translation)
Semantic
Domain
operational
semantics
Operational Semantics
 diagram syntax plus
runtime state
 visual rules to model state transitions
op(…)
op(…)
op(…)
 produce sequences of states / labels,
visualized as animations
Abstract
Syntax
operational
semantics
Extended Meta Model:
Original plus Runtime State
Abstract
Syntax
Runtime State
activity
target
0..1
Activity
active
0..1
*
1
*
Node
activity
ActivityEdge
1
*
source
guard
InitialNode
FinalNode
MergeNode
*
DecisionNode
1
1
ValueSpecification
Operational Rules:
GT on Meta Model Instances
operational
semantics
Abstract
Syntax
active
:Node
: Node
source
:Runtime State
: ActivityEdge
source
: Runtime State
target
: Node
: ActivityEdge
target
active
: Node
operational
semantics
Animation
Abstract
Syntax
placeOrder
calcBill
placeOrder
Trace:
placeOrder;
calcBill;
placeOrder
Semantics
 Operational semantics
(execution)
 Denotational semantics
(translation)


analyse model
(compiler front-end)
generate semantic
representation
(compiler back-end)
operational
semantics
Abstract
Syntax
denotational
semantics
Semantic
Domain
Analysis:
Abstract
Syntax
Context-Free Graph Grammar
Concrete Syntax of Well-Formed Activity Diagrams
Start Graph:
Act
Productions in EBNF-like notation:
in
in
in
[not c]
[c]
in
Act
Act
Act
::=
Act
do something
Act
out
out
out
out
Pair Grammar
Abstract
Syntax
denotational
semantics
Semantic
Domain
Target: CSP
in
in
A:Act
Source: well-structured
activity diagrams
in
[not c]
[c]
Proc(A)
in
A1:Act
A:Act
A1:Act
::=
A2:Act
do something
A2:Act
out
Proc(A)
out
::=
Proc(A1) 
Proc(A2)
out
if [c] then Proc(A1)
else Proc(A2)
out
do something
Generation
Proc(A0)
0
receive order
Proc(A1)  Proc(A2)
…
Proc(A3) 
Proc (A4) 
check availability
if [product available]
[product not
then Proc(A5)
available]
else Proc(A8)
…
receive order 
notify client
check availability 
if [product available]
then calculate prize
 send receipt
else notify client
1
3
4
[product available]
calculate prize
6 5
8
send receipt
7
2
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. OMG’s QVT requirements
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]
Correspondence Rules:
Initial, Action, and Final Nodes
A=…
 Rule pairs, in
A
condensed
presentation

A = act  B
B=…
A
act
B
A
A = STOP
Green/bf 
{new}
 No restriction to
context-freeness
 Correspondence
via common
names
Correspondence Rules:
Choice and Join
A = if cond
A
then B else C
B=…
C=…
A=B
B=…
[cond] B
A
[else]
C
[cond]
B
Negative
application
condition
Correspondence Rules:
Connection to Existing Nodes
A
B
A
A=B
act
B
A
Either alternative is
consistent with left side
B
Formally: Triple Graph Grammars
 Meta model for correspondence
 traceability
Target
Metamodel
<<use>>
<<use>>
Source
Metamodel
Corresp.
Metamodel
 Symmetric rule triplets (left, corr, right),
generating directed rules

Declarative  operational
Example TGG Rule
A
A = act  B
B=…
act
B
:Proc
name = A
:ProcEdge
:ActivityEdge
exp
:Prefix
name = act
{new}
target
succ
:Var
name = B
:Node
{new}
label = act
{new}
source
:Proc
name = B
{new}
left
:ProcEdge
:ActivityEdge
{new}
{new}
corr
right
Derived Operational GT Rule:
right  left
:Proc
name = A
:ProcEdge
:ActivityEdge
exp
:Prefix
name = act
target
succ
{new}
:Var
name = B
{new}
:Proc
name = B
:ActivityEdge
{new}
left
Alternatively:

source
:ProcEdge
{new}

:Node
label = act
left  right
(left, right)  corr
corr
right
Outline
 Graph transformation
 Model transformation
 Theory and Tools
Theory: Sources of Inspirations
Chomsky
Grammars
Term
Rewriting
Petri
Nets
Graph Transformation and Graph Grammars
 Formal language
theory of graphs;
 Well-definedness
 Termination
 Confluence
 Diagram compiler
generators
 Semantics of
process calculi
 Concurrency theory
 Causality and conflict
 Processes, unfoldings
 Event-structures
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, …
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
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
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
DiaGen
(The Diagram Editor Generator )
 VL concrete / abstract
syntax specified as CF
hypergraph grammars
 Generation of diagram
editors, parsers,
simulators
GenGED
(Generation of Graphical Env.s for Design)
 Roughly similar to the
above, based on AGG
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
Graph Transformation
A “lambda calculus” for MDD ?
 Expressiveness and
complexity


CF graph grammars:
Rozenberg; Habel
Relation with MSO logic:
Courcelle
 Well-definedness


 Semantic correctness

 Execution and optimisation


Various tools
Graph matching:
Zuendorf 96;
Varro et al 05
Term graph rewriting: Plump
Confluence, termination of
attributed GT: Ehrig et al 04
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
Inspired?
Join us in Vienna!
ETAPS 2006
 The event:
25 March - 2 April 2006
 Abstract submission:
Friday 7 October 2005
 Paper submission:
Friday 14 October 2005
GT-VMT* 2006
 Paper submission:
12 December 2005
*: 5th Intl Workshop on Graph
Transformation and Visual
Modelling Techniques
Questions ?