foundations of model transformation
DESCRIPTION
Foundations of Model Transformation. ARTIST2 - MOTIVES Trento - Italy, February 19-23, 2007 Model Transformation and UML Reiko Heckel University of Leicester, UK. Focus and primary artifacts are models instead of programs Core activities include maintaining consistency evolution - PowerPoint PPT PresentationTRANSCRIPT
ARTIST2 - MOTIVESARTIST2 - MOTIVESTrento - Italy, February 19-23, 2007Trento - Italy, February 19-23, 2007
Model Transformation and Model Transformation and
UMLUML
Reiko HeckelReiko Heckel
University of Leicester, UKUniversity of Leicester, UK
Foundations of
Model
Transformation
Motivation: Model-driven Engineering
● Focus and primary artifacts are models instead of programs
● Core activities include
– 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
– preservation of semantics
of transformations
● Graph transformations can be one such foundation
Outline
● Graph Transformation– why it is fun
– how it works
● Semantics-preserving Model Transformation
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
:Field
:PacManmarbles=3
instance graph(represents a single state; abstracts from spatial layout)
type graph(specifies legalinstance graphs)
:Marble
typingtyping
FieldPacMan
marbles:intGhost
Marble
1
11 *
*
*
Rules of the PacMan Game:Graph-Based Presentation, PacMan
f1:Field f2:Field
pm:PacMan
f1:Field f2:Field
pm:PacManmovePM
pm:PacManmarbles=m
f1:Field f2:Field
:Marble
f1:Field f2:Field
pm:PacManmarbles=m+1collect
Rules of the PacMan Game:Graph-Based Presentation, Ghost
f1:Field f2:Field
g:Ghost
f1:Field f2:Field
g:GhostmoveGhost
g:Ghost
f1:Field f2:Field
:PacMan
f1:Field f2:Field
g:Ghostkill
Outline
● Graph Transformation why it is fun
– how it works
● Semantics-preserving Model Transformation
A Basic Formalism: Typed Graphs
Directed graphs
– multiple parallel edges
– undirected edges as pairs of directed ones
Graph homomorphism as mappings preserving source and target
Typed graphs given by
– fixed type graph TG
– instance graphs G typed over TG by homomorphism g
g:Ghost:Field
:Field :Field
:Field
:Field
f:Field
gg
FieldPacMan
marbles:intGhost
Marble
G
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
f1:Field f2:Field
pm:PacManmovePM:
f1:Field f2:Field
pm:PacMan
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, Fujaba]:
L R and marking● L - R as destroyed ● R - L as new
f1:Field f2:Field
pm:PacManmovePM:
{destroyed} {new}
Transformation Step
1. select rule p: L R ; occurrence oL: L G
2. remove from G the occurrence of L\ R
3. add to result a copy of R \ L
f1:Field
f2:Fieldpm:PacManmarbles=3
m2:Marble
oL
G
L Rppm:PacManmarbles=m
f2:Field f1:Field
m1:Marble
f2:Field f1:Field
pm:PacManmarbles=m+1
f3:Field
m1:Marble
oR
pm:PacManmarbles=4
H f1:Field
f2:Field
m2:Marblef3:Field
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
a:A
a:A :B ??
A bit of History …
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars
DiagramLanguages
BehaviourModelling and
Visual Programming
Models ofComputation
Outline
Graph Transformation why it is fun
how it works
● Semantics-preserving Model Transformation– operational
– denotational
AbstractSyntax
SemanticDomain
denotationalsemantics
operationalsemantics
transformation
Example: Executable Business Process
● refactoring of business processes, replacing centralised by distributed execution
● How to demonstrate preservation of behaviour?
1. specify operational semantics of processes
2. define transformations
3. show that transformations preserve semantics
Receiveorder
Undoorder
Shipment
Warehouse Office
Operational Semantics: Idea
● diagram syntax plus runtime state● GT rules to model state transitions
op(…) op(…)
op(…)
AbstractSyntax
operationalsemantics
Operational Semantics: Formally
GTS = (TG, P) with start graph G0
defines transition system
LTS(GTS, G0) = (S, L, )
taking
– as states S all graphs reachable from G0
– observations on rules as labels
– transformations as transitions
Edge Node
Basicop: String
Structured
Orchname: String
Msgop: Stringid: String
Switch Invoke
srctar
current
tofrom
partner
request
Reply
response
Elem
corresponds
responsible
Type Graph: Metamodel
……
with runtime statewith runtime state
AbstractSyntax
Rules: Invoke another Service
e:Edgetar
i:Invoke
o1:Orch o2:Orch
current
partner
e:Edgetar
i:Invoke
o1:Orch o2:Orch
current
partner
m:Msgid=new()op=i.op
fromto
req(i.id, m.id) request
AbstractSyntax
operationalsemantics
Rules: Answer the Invocation
e:Edgetar
r:Reply
o1:Orch o2:Orch
current
m1:Msgop=r.op
fromto
e:Edgetar
r:Reply
o1:Orch o2:Orch
current
m1:Msgop=r.op
fromto
m2:Msgid=new()op=r.op
from to
reply(r.id, m1.id, m2.id)
response
srce:Edge
srce:Edge
AbstractSyntax
operationalsemantics
Rules: Receive the Response
i:Invoke
o1:Orch o2:Orch
currentsrc
m1:Msg
tofrom
m2:Msgto from
e:Edge
partner
i:Invoke
o1:Orch o2:Orch
current
srce:Edge
partnerresp(i.id, m2.id)
request
response
AbstractSyntax
operationalsemantics
Simulation
:Edge
tar
i:Invokeo1:Orch o2:Orchcurrent partner
:Edge
src
:Edge
tar
r:Reply
:Edge
src
current
m1:Msgop=i.op
from
torequest
m2:Msgop=r.op
from
to
response
Observations:req(i.id, m1.id); reply(r.id, m1.id, m2.id); resp(i.id, m2.id)
Refactoring Executable Processes
● replace local control flow by message passing
…
Orch 1 Orch 2
… …
Orch1 Orch 2
<<invoke>>Orch2.op
<<receive>>op
<<reply>>op
… …
… …
…
delegate
Semantic Compatibility
Processes P1 and P2 are semantically compatible if they are
weakly bisimilar after hiding labels not in alph(P1) ⋂ alph(P2)
Show for trafo P1 P2 that P2 simulates P1, i.e.
– P1obs Q1 implies P2 obs Q2
– Q2 simulates Q1
and vice versa.
Approach:
– mixed (local) confluence
– critical pair analysis
P1 Q1
P2 Q2
obsobs
obsobs
Critical Pairs and Local Confluence
● a pair of rules (p1, p2) in a minimal conflict situation
● constructed by overlapping their left-hand sides so that they intersect in items to be deleted
● system is locally confluent if all critical pairs are
G
H *
G2G1
*
p1p2
Critical Pair Analysis in AGGdelegate vs operational rules
Critical Pair
LHS ofinvoke vs delegate
delete-use-conflict
Outline
Graph Transformation why it is fun
how it works
● Semantics-preserving Model Transformation operational
– denotational
AbstractSyntax
SemanticDomain
denotationalsemantics
operationalsemantics
transformation
Process Improvement
Motivation:
– transform process to increase flexibility, performance, ...
– preserve behaviour!
Aim: rule-level verification
Rule-level Verification
rL R
L Rr/o
s(L)s(L) s(R)s(R)
G H
s(G) s(H)
Approach: – check for each rule r if s(L) R s(R) – make sure that s(L) R s(R) implies s(G) R s(H)
semantic domainsemantic domain
Works if …
● we select semantic domain SD where relation R is compositional– trace or failures equivalence or refinement in CSP is
closed under context
● we can show that semantic mapping s: AS SD is compositional– maps union of graphs to composition of CSP processes
use GT to define mapping s
Context-Free Graph Grammar
do something
out
in
ActStart graph:
Act
in
out
Act
Act
in
out
::=
Productions in EBNF-like notation:
Act
in
out
Act
[c] [not c]
Concrete syntax of well-structured activity diagrams
AbstractSyntax
Analysis
check availability
receive order
notify client
calculate prize
send receipt
[product not available]
[product available]
0 1
2
3
4
56
7
8
Pair Grammar
A:Act
in
out
A1:Act
in
out
A2:Act
do something
out
in
::=
A:Act
A1:Act
in
out
A2:Act
[c] [not c]
Proc(A) ::=Proc(A1) ; Proc(A2)
if [c] then Proc(A1) else Proc(A2)
do something
Source: well-structured
activity diagrams
Proc(A)Target: CSP
AbstractSyntax
SemanticDomain
denotationalsemantics
Synthesis
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
check availability
receive order
notify client
calculate prize
send receipt
[product not available]
[product available]
0 1
2
3
4
56
7
8
Good Enough … ?
Visual
abstract syntax or concrete syntax templates
Bi-directional
swap source and target grammars
Declarative
Expressive ?
context-free graph languages only
Traceable ?
through naming conventions
Efficient ?
NP complete parsing problem
… Triple Graph Grammars (see Andy’s lecture)Triple Graph Grammars (see Andy’s lecture)
Challenge:Challenge: verify compositionality for more complex mappings verify compositionality for more complex mappings
Relevant Theory
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars
Formal language theory of graphs;
Diagram compiler generators
Concurrency theory Causality and conflict Processes, unfoldings Event-structures Stochastic concepts Verification, …
Well-definedness Termination Confluence
Semantics of process calculi