foundations of model transformation n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Foundations of Model Transformation PowerPoint Presentation
Download Presentation
Foundations of Model Transformation

Loading in 2 Seconds...

play fullscreen
1 / 38

Foundations of Model Transformation - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Foundations of Model Transformation' - artan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
foundations of model transformation

Foundations of Model Transformation

ARTIST2 - MOTIVESTrento - Italy, February 19-23, 2007

Model Transformation and UML

Reiko Heckel

University of Leicester, UK

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

Motivation: Model-driven Engineering
outline
Outline
  • Graph Transformation
    • why it is fun
    • how it works
  • Semantics-preserving Model Transformation
why it is fun programming by example
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

instance graph(represents a single state; abstracts from spatial layout)

typing

PacManmarbles:int

1

1

*

*

Ghost

Field

type graph

(specifies legalinstance graphs)

1

*

Marble

States of the PacMan Game:Graph-Based Presentation

:Ghost

:Field

:Field

:PacMan

marbles=3

:Field

:Field

:Field

:Marble

:Field

rules of the pacman game graph based presentation pacman
Rules of the PacMan Game:Graph-Based Presentation, PacMan

pm:PacManmarbles=m

pm:PacManmarbles=m+1

:Marble

collect

f1:Field

f2:Field

f1:Field

f2:Field

pm:PacMan

pm:PacMan

movePM

f1:Field

f2:Field

f1:Field

f2:Field

rules of the pacman game graph based presentation ghost
Rules of the PacMan Game:Graph-Based Presentation, Ghost

g:Ghost

:PacMan

g:Ghost

kill

f1:Field

f2:Field

f1:Field

f2:Field

g:Ghost

g:Ghost

moveGhost

f1:Field

f2:Field

f1:Field

f2:Field

outline1
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 graphTG

instance graphsGtyped over TGby homomorphismg

A Basic Formalism: Typed Graphs

:Field

:Field

g:Ghost

:Field

:Field

f:Field

:Field

G

g

PacManmarbles:int

Ghost

Field

Marble

TG

rules
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:

pm:PacMan

pm:PacMan

f1:Field

f2:Field

f1:Field

f2:Field

rules1
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:

pm:PacMan

{new}

{destroyed}

f1:Field

f2:Field

transformation step

pm:PacManmarbles=m

pm:PacManmarbles=m+1

L

R

m1:Marble

p

f2:Field

f1:Field

f2:Field

f1:Field

oL

oR

H

pm:PacMan

marbles=4

f1:Field

f2:Field

m2:Marble

f3:Field

Transformation Step
  • select rule p: L  R; occurrence oL: L  G
  • remove from G theoccurrence of L\ R
  • add to result a copy of R \ L

G

m1:Marble

f1:Field

pm:PacMan

marbles=3

f2:Field

m2:Marble

f3:Field

semantic questions dangling edges

a:A

:B

a:A

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 bit of history
A bit of History …

Chomsky Grammars

Term

Rewriting

PetriNets

Graph Transformation and Graph Grammars

Diagram

Languages

Models of

Computation

Behaviour

Modelling and

Visual Programming

outline2

operational

semantics

Abstract

Syntax

denotational

semantics

Semantic

Domain

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

transformation

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

Example: Executable Business Process

Warehouse

Office

Receiveorder

Undoorder

Shipment

operational semantics idea

operational

semantics

Operational Semantics: Idea

Abstract

Syntax

  • diagram syntax plus runtime state
  • GT rules to model state transitions
operational semantics formally
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
type graph metamodel

Abstract

Syntax

response

Type Graph: Metamodel

Msg

op: String

id: String

with runtime state

request

from

to

current

Orch

name: String

Elem

partner

responsible

src

Edge

Node

tar

corresponds

Basic

op: String

Structured

Switch

Invoke

Reply

rules invoke another service

operational

semantics

Rules: Invoke another Service

Abstract

Syntax

tar

partner

e:Edge

i:Invoke

current

o1:Orch

o2:Orch

partner

tar

e:Edge

i:Invoke

current

request

req(i.id, m.id)

from

m:Msg

id=new()

op=i.op

to

o1:Orch

o2:Orch

rules answer the invocation

operational

semantics

Rules: Answer the Invocation

Abstract

tar

src

Syntax

r:Reply

e:Edge

e:Edge

current

m1:Msg

op=r.op

to

from

o1:Orch

o2:Orch

tar

src

r:Reply

e:Edge

e:Edge

current

m1:Msg

op=r.op

to

from

reply(r.id, m1.id, m2.id)

o1:Orch

o2:Orch

response

from

to

m2:Msg

id=new()

op=r.op

rules receive the response

operational

semantics

Rules: Receive the Response

Abstract

src

Syntax

e:Edge

i:Invoke

current

request

partner

to

from

o1:Orch

m1:Msg

o2:Orch

response

to

from

m2:Msg

src

e:Edge

i:Invoke

resp(i.id, m2.id)

partner

current

o1:Orch

o2:Orch

simulation

request

to

to

from

m1:Msg

op=i.op

from

m2:Msg

op=r.op

response

Simulation

:Edge

:Edge

tar

tar

current

current

partner

o1:Orch

i:Invoke

o2:Orch

r:Reply

src

src

:Edge

:Edge

Observations:

req(i.id, m1.id);

reply(r.id, m1.id, m2.id);

resp(i.id, m2.id)

refactoring executable processes
Refactoring Executable Processes

Orch 1

Orch1

Orch 2

Orch 2

  • replace local control flow by message passing

<<receive>>

op

delegate

<<invoke>>

Orch2.op

<<reply>>

op

semantic compatibility
Semantic Compatibility

Processes P1 and P2are semantically compatible if they are weakly bisimilar after hiding labels not in alph(P1) ⋂ alph(P2)

Show for trafo P1 P2 thatP2 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

critical pairs and local confluence
Critical Pairs and Local Confluence
  • a pair of rules (p1, p2) in a minimal conflictsituation
  • 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

G1

G2

*

*

H

critical pair
Critical Pair

LHS ofinvoke vs delegate

delete-use-conflict

outline3

operational

semantics

Abstract

Syntax

denotational

semantics

Semantic

Domain

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

transformation

process improvement
Motivation:

transform process to increase flexibility, performance, ...

preserve behaviour!

Aim: rule-level verification

Process Improvement
rule level verification

L

R

L

R

Rule-level Verification

r

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)

r/o

H

G

s(L)

s(R)

s(H)

s(G)

semantic domain

works if
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

in

in

in

Act

Act

Start graph:

Act

Act

Act

out

out

out

in

[not c]

[c]

do something

::=

Act

out

Context-Free Graph Grammar

Abstract

Syntax

Concrete syntax of well-structured activity diagrams

Productions in EBNF-like notation:

analysis
Analysis

0

1

3

receive order

4

check availability

2

[product available]

[product not

available]

5

6

calculate prize

8

notify client

7

send receipt

pair grammar

in

in

in

A1:Act

A:Act

Target: CSP

Proc(A)

A1:Act

A2:Act

A2:Act

out

out

out

Proc(A1);

Proc(A2)

Proc(A)::=

Pair Grammar

Abstract

A:Act

Syntax

Source: well-structured activity diagrams

denotational

semantics

Semantic

Domain

in

[not c]

[c]

do something

::=

out

if [c] thenProc(A1)

elseProc(A2)

do something

synthesis
Proc(A0)

Proc(A1) ;Proc(A2)

Proc(A3) ;Proc (A4) ;if [product available]thenProc(A5)elseProc(A8)

receive order ;check availability ;if [product available]thencalculate prize ; send receiptelse notify client

0

1

3

4

2

5

6

8

7

Synthesis

receive order

check availability

[product available]

[product not

available]

calculate prize

notify client

send receipt

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

Good Enough … ?

 Triple Graph Grammars (see Andy’s lecture)

Challenge: verify compositionality for more complex mappings

relevant theory
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