Download presentation

Presentation is loading. Please wait.

Published byRachel Butter Modified over 2 years ago

1
ARTIST2 - MOTIVES Trento - Italy, February 19-23, 2007 Model Transformation and UML Reiko Heckel University of Leicester, UK Foundations of Model Transformation

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 onwww.stagecast.com – 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 Game: Graph-Based Presentation :Ghost :Field :PacMan marbles=3 instance graph (represents a single state; abstracts from spatial layout) type graph (specifies legal instance graphs) :Marble typing Field PacMan marbles:int Ghost Marble 1 11 * * *

6
Rules of the PacMan Game: Graph-Based Presentation, PacMan f1:Fieldf2:Field pm:PacMan f1:Fieldf2:Field pm:PacMan movePM pm:PacMan marbles=m f1:Fieldf2:Field :Marble f1:Fieldf2:Field pm:PacMan marbles=m+1 collect

7
Rules of the PacMan Game: Graph-Based Presentation, Ghost f1:Fieldf2:Field g:Ghost f1:Fieldf2:Field g:Ghost moveGhost g:Ghost f1:Fieldf2:Field :PacMan f1:Fieldf2:Field g:Ghost kill

8
Graph Transformation :Ghost :Field :Marble :PacMan marbles=3 :PacMan marbles=4 typing collect ; kill Field PacMan marbles:int Ghost Marble 1 11 * * *

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 g:Ghost :Field f:Field g Field PacMan marbles:int Ghost Marble G 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 f1:Fieldf2:Field pm:PacMan movePM: f1:Fieldf2:Field pm:PacMan

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 f1:Fieldf2:Field pm:PacMan movePM: {destroyed} {new}

13
Transformation Step select rule p: L R ; occurrence o L : L G remove from G the occurrence of L\ R add to result a copy of R \ L f1:Field f2:Field pm:PacMan marbles=3 m2:Marble oLoL G LR p pm:PacMan marbles=m f2:Fieldf1:Field m1:Marble f2:Fieldf1:Field pm:PacMan marbles=m+1 f3:Field m1:Marble oRoR pm:PacMan marbles=4 H f1:Field f2:Field m2:Marble f3:Field

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 a:A :B ?

15
A bit of History … Chomsky Grammars Term Rewriting Petri Nets 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 Abstract Syntax Semantic Domain denotational semantics operational semantics 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 Receive order Undo order Shipment Warehouse Office

18
Operational Semantics: Idea ● diagram syntax plus runtime state ● GT rules to model state transitions Abstract Syntax operational semantics

19
Operational Semantics: Formally GTS = (TG, P) with start graph G 0 defines transition system LTS(GTS, G 0 ) = (S, L, ) taking – as states S all graphs reachable from G 0 – observations on rules as labels – transformations as transitions

20
EdgeNode Basic op: String Structured Orch name: String Msg op: String id: String SwitchInvoke src tar current tofrom partner request Reply response Elem corresponds responsible Type Graph: Metamodel …… with runtime state Abstract Syntax

21
Rules: Invoke another Service e:Edge tar i:Invoke o1:Orcho2:Orch current partner e:Edge tar i:Invoke o1:Orcho2:Orch current partner m:Msg id=new() op=i.op from to req(i.id, m.id) request Abstract Syntax operational semantics

22
Rules: Answer the Invocation e:Edge tar r:Reply o1:Orcho2:Orch current m1:Msg op=r.op fromto e:Edge tar r:Reply o1:Orcho2:Orch current m1:Msg op=r.op fromto m2:Msg id=new() op=r.op from to reply(r.id, m1.id, m2.id) response src e:Edge src e:Edge Abstract Syntax operational semantics

23
Rules: Receive the Response i:Invoke o1:Orcho2:Orch current src m1:Msg to from m2:Msg to from e:Edge partner i:Invoke o1:Orcho2:Orch current src e:Edge partner resp(i.id, m2.id) request response Abstract Syntax operational semantics

24
Simulation :Edge tar i:Invokeo1:Orcho2:Orch current partner :Edge src :Edge tar r:Reply :Edge src current m1:Msg op=i.op from to request m2:Msg op=r.op from to response Observations:req(i.id, m1.id);reply(r.id, m1.id, m2.id);resp(i.id, m2.id)

25
Refactoring Executable Processes ● replace local control flow by message passing … Orch 1 Orch 2 … … Orch1 Orch 2 > Orch2.op > op > op … … … … … delegate

26
Semantic Compatibility Processes P 1 and P 2 are semantically compatible if they are weakly bisimilar after hiding labels not in alph(P 1 ) ⋂ alph(P 2 ) Show for trafo P 1 P 2 that P 2 simulates P 1, i.e. – P 1 obs Q 1 implies P 2 obs Q 2 – Q 2 simulates Q 1 and vice versa. Approach: – mixed (local) confluence – critical pair analysis P1P1 Q1Q1 P2P2 Q2Q2 obs obs

27
Critical Pairs and Local Confluence ● a pair of rules (p 1, p 2 ) 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 * G2G2 G1G1 * p1p1 p2p2

28
Critical Pair Analysis in AGG delegate vs operational rules

29
Critical Pair LHS of invoke vs delegate delete-use-conflict

30
Outline Graph Transformation why it is fun how it works ● Semantics-preserving Model Transformation operational – denotational Abstract Syntax Semantic Domain denotational semantics operational semantics transformation

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

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

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 do something out in Act Start graph: Act in out Act in out ::= Productions in EBNF-like notation: Act in out Act [c] [not c] Concrete syntax of well-structured activity diagrams Abstract Syntax

35
Analysis check availability receive order notify client calculate prize send receipt [product not available] [product available] 0 1 2 3 4 5 6 7 8

36
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 Abstract Syntax Semantic Domain denotational semantics

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 check availability receive order notify client calculate prize send receipt [product not available] [product available] 0 1 2 3 4 5 6 7 8

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 Andy’s lecture) Challenge: verify compositionality for more complex mappings

39
Relevant Theory Chomsky Grammars Term Rewriting Petri Nets 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

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google