foundations of model transformation

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


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


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


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


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



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


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

foundations of model transformation

Documents