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. 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

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. 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

6. 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

7. 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

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

9. 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

10. 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

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 • 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

12. 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

13. 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 ?

14. A bit of History … Chomsky Grammars Term Rewriting PetriNets Graph Transformation and Graph Grammars Diagram Languages Models of Computation Behaviour Modelling and Visual Programming

15. 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

16. 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

17. operational semantics Operational Semantics: Idea Abstract Syntax • diagram syntax plus runtime state • GT rules to model state transitions

18. 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

19. 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 … …

20. 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

21. 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

22. 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

23. 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)

24. 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

25. 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

26. 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

27. Critical Pair Analysis in AGGdelegate vs operational rules

28. Critical Pair LHS ofinvoke vs delegate delete-use-conflict

29. 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

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

31. 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

32. 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

33. 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:

34. 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

35. 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

36. 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

37. 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

38. 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