Foundations of Model Transformation - PowerPoint PPT Presentation

About This Presentation
Title:

Foundations of Model Transformation

Description:

Rules of the PacMan Game: Graph-Based Presentation, Ghost. f1: ... pm:PacMan. Rules. p: L R with L R well-defined, in different presentations. like above (cf. ... – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 39
Provided by: ReikoH1
Category:

less

Transcript and Presenter's Notes

Title: Foundations of Model Transformation


1
Foundations of Model Transformation
ARTIST2 - MOTIVESTrento - Italy, February 19-23,
2007 Model Transformation and UML Reiko
Heckel University of Leicester, UK
2
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

3
Outline
  • Graph Transformation
  • why it is fun
  • how it works
  • Semantics-preserving Model Transformation

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
6
Rules of the PacMan GameGraph-Based
Presentation, PacMan
pmPacManmarblesm
pmPacManmarblesm1
Marble
collect
f1Field
f2Field
f1Field
f2Field
pmPacMan
pmPacMan
movePM
f1Field
f2Field
f1Field
f2Field
7
Rules of the PacMan GameGraph-Based
Presentation, Ghost
gGhost
PacMan
gGhost
kill
f1Field
f2Field
f1Field
f2Field
gGhost
gGhost
moveGhost
f1Field
f2Field
f1Field
f2Field
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
Outline
  • Graph Transformation
  • why it is fun
  • how it works
  • Semantics-preserving Model Transformation

10
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

Field
Field
gGhost
Field
Field
fField
Field
G
g
PacManmarblesint
Field
Ghost
Marble
TG
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

movePM
pmPacMan
pmPacMan
f1Field
f2Field
f1Field
f2Field
12
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

movePM
pmPacMan
destroyed
new
f1Field
f2Field
13
Transformation Step
G
f1Field
m1Marble
pmPacMan marbles3
f2Field
m2Marble
f3Field
  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

14
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

?
15
A bit of History
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars
Diagram Languages
Behaviour Modelling and Visual Programming
Models of Computation
16
Outline
  • Graph Transformation
  • why it is fun
  • how it works
  • Semantics-preserving Model Transformation
  • operational
  • denotational

transformation
17
Example Executable Business Process
  • refactoring of business processes, replacing
    centralised by distributed execution
  • How to demonstrate preservation of behaviour?
  • specify operational semantics of processes
  • define transformations
  • show that transformations preserve semantics

Warehouse
Office
Receiveorder
Undoorder
Shipment
18
Operational Semantics Idea
operational
semantics
Abstract
Syntax
  • diagram syntax plus runtime state
  • GT rules to model state transitions

19
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

20
Type Graph Metamodel
Abstract
response
Syntax
Msg op String id String
with runtime state
request
to
from
current
Orch name String
Elem
partner
responsible
src
Edge
Node
tar
corresponds
Basic op String
Structured
Switch
Invoke
Reply


21
Rules Invoke another Service
operational
semantics
Abstract
Syntax
tar
partner
eEdge
iInvoke
current
o1Orch
o2Orch
partner
tar
eEdge
iInvoke
current
request
req(i.id, m.id)
from
mMsg idnew() opi.op
to
o1Orch
o2Orch
22
Rules Answer the Invocation
operational
semantics
Abstract
tar
src
Syntax
eEdge
rReply
eEdge
current
m1Msg opr.op
from
to
o1Orch
o2Orch
tar
src
eEdge
rReply
eEdge
current
m1Msg opr.op
from
to
reply(r.id, m1.id, m2.id)
o1Orch
o2Orch
response
from
to
m2Msg idnew() opr.op
23
Rules Receive the Response
operational
semantics
Abstract
src
Syntax
iInvoke
eEdge
current
partner
request
to
from
o1Orch
o2Orch
m1Msg
response
to
from
m2Msg
src
iInvoke
eEdge
resp(i.id, m2.id)
partner
current
o1Orch
o2Orch
24
Simulation
Edge
Edge
tar
tar
current
current
partner
iInvoke
o1Orch
o2Orch
rReply
src
src
Edge
Edge
Observations
req(i.id, m1.id)
reply(r.id, m1.id, m2.id)
resp(i.id, m2.id)
25
Refactoring Executable Processes
Orch 1
Orch1
Orch 2
Orch 2
ltltreceivegtgt op
delegate




ltltinvokegtgt Orch2.op




ltltreplygtgt op
  • replace local control flow by message passing

26
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.
  • P1?obs Q1 implies P2 ?obs Q2
  • Q2 simulates Q1
  • and vice versa.
  • Approach
  • mixed (local) confluence
  • critical pair analysis

obs
P1
Q1
obs
P2
Q2
27
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
p2
p1
G2
G1


H
28
Critical Pair Analysis in AGGdelegate vs
operational rules
29
Critical Pair
LHS ofinvoke vs delegate
delete-use-conflict
30
Outline
  • Graph Transformation
  • why it is fun
  • how it works
  • Semantics-preserving Model Transformation
  • operational
  • denotational

transformation
31
Process Improvement
  • Motivation
  • transform process to increase flexibility,
    performance, ...
  • preserve behaviour!
  • Aim rule-level verification

32
Rule-level Verification
r
r/o
H
G
s(L)
s(R)
s(H)
s(G)
semantic domain
  • 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)

33
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

34
Context-Free Graph Grammar
Abstract
Syntax
Concrete syntax of well-structured activity
diagrams
Productions in EBNF-like notation
35
Analysis
0
1
3
receive order
4
check availability
product available
2
product not available
5
6
calculate prize
8
notify client
7
send receipt
36
Pair Grammar
Abstract
AAct
Syntax
Source well-structured activity diagrams
denotational
semantics
Semantic
Domain
in
not c
c
do something

out
if c then Proc(A1) else Proc(A2)
do something
37
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

receive order
check availability
product available
product not available
calculate prize
notify client
send receipt
38
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 Andys
lecture) Challenge verify compositionality for
more complex mappings
39
Relevant Theory
Chomsky Grammars
Term Rewriting
PetriNets
Graph Transformation and Graph Grammars
  • Concurrency theory
  • Causality and conflict
  • Processes, unfoldings
  • Event-structures
  • Stochastic concepts
  • Verification,
  • Formal language theory of graphs
  • Diagram compiler generators
  • Well-definedness
  • Termination
  • Confluence
  • Semantics of process calculi
Write a Comment
User Comments (0)
About PowerShow.com