1. Foundations of Model Transformations A “lambda calculus” for MDD ? Reiko Heckel University of Leicester, UK

2. Motivation  At the heart of model- driven engineering are activities like maintaining consistency maintaining consistency evolution evolution translation translation execution execution of models  These are examples of model transformations  A math. foundation is needed for studying Expressiveness and complexity Expressiveness and complexity Execution and optimisation Execution and optimisation Well-definedness Well-definedness Semantic correctness Semantic correctness of transformations  This lecture is about graph transformations as one such foundation

3. Outline  Graph transformation why it is fun why it is fun how it works how it works  Model transformation  Theory and Tools

4. Why it is fun: Programming By Example StageCast (www.stagecast.com): a visual programming environment for kids (from 8 years on), based on www.stagecast.com behavioral rules associated to graphical objects behavioral rules associated to graphical objects visual pattern matching visual pattern matching simple control structures (priorities, sequence, choice,...) simple control structures (priorities, sequence, choice,...) external keyboard control 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  state space) :Marble cardinalities (specify additional constraints on well-typed instance graphs) typing Field PacMan marbles:int Ghost Marble 1 11 * * * neighbor

6. Rules of the PacMan Game: Graph-Based Presentation, PacMan PacMan’s rules: collect has priority over movePM 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 Ghost’s rules: kill has priority over moveGhost 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. How it works: Typed Graphs Directed graphs as algebraic structures G = (V, E, src, tar) with src, tar: E  V Graph homomorphism as pair of mappings h = (h V, h E ): G 1  G 2 with h V : V 1  V 2 h V : V 1  V 2 h E : E 1  E 2 h E : E 1  E 2 preserving src and tar Typed graphs given by fixed type graph TG fixed type graph TG instance graphs G typed over TG by homomorphism g: G  TG instance graphs G typed over TG by homomorphism g: G  TG :Ghost x:Field y:Field:Field g Field PacMan marbles:int Ghost Marble G TG

10. Rules p: L  R with L  R well-defined, in different presentations like above (cf. PacMan example) like above (cf. PacMan example) with L  R explicit [DPO]: L  K  R with L  R explicit [DPO]: L  K  R f1:Fieldf2:Field pm:PacMan movePM: f1:Fieldf2:Field pm:PacMan

11. Rules p: L  R with L  R well-defined, in different presentations like above (cf. PacMan example) like above (cf. PacMan example) with L  R explicit [DPO]: L  K  R with L  R explicit [DPO]: L  K  R with L, R integrated [UML]: L  R and marking with L, R integrated [UML]: L  R and marking  L - R as {destroyed}  R - L as {new} f1:Fieldf2:Field pm:PacMan movePM: {destroyed} {new}

12. Transformation Step: Operational 1. select rule p : L  R ; occurrence o L : L  G 2. remove from G the occurrence of L \ R 3. 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

13. Semantic Questions: Dangling Edges  conservative solution: application is forbidden invertible transformations, no side-effects invertible transformations, no side-effects  radical solution: delete dangling edges more complex behavior, requires explicit control more complex behavior, requires explicit control a:A :B ?

14. Semantic Questions: Conflicts  conservative solution: application is forbidden invertible transformations, no side-effects invertible transformations, no side-effects  radical solution: give priority to deletion more complex behavior, requires explicit control more complex behavior, requires explicit control a1:A a:A a2:Aa1:A ?

15. Advanced Features Dealing with unknown context set-nodes (multi-objects): match all nodes with the required connections set-nodes (multi-objects): match all nodes with the required connections explicit (negative) context conditions explicit (negative) context conditions (turns f1 into a trap by reversing all outgoing edges to Field vertices, but only if there is no Ghost) Control priorities: movePM only if collect is not possible priorities: movePM only if collect is not possible programmed transformation: IF NOT collect THEN movePm; programmed transformation: IF NOT collect THEN movePm; :Field f1:Field :Field f1:Field :Field :Ghost

16. Where it comes from and what it is good for Chomsky Grammars Term Rewriting Petri Nets Graph Transformation and Graph Grammars Diagram Languages Behaviour Modelling and Visual Programming Models of Computation

17. Outline  Graph transformation  Model transformation diagram languages diagram languages execution execution translation translation  Theory and Tools

18. Diagram Languages  theory and tools like for textual languages Graphical Elements Concrete Syntax scan layout parse render Abstract Syntax Semantic Domain denotational semantics feedback operational semantics Vector graphics Spatial Relationship Graph Abstract Syntax Graph evolution

19. SRG Metamodel (typed graph) SRG (Instance) Graph check availability receive order notify client calculate prize send receipt [product not available] [product available] Concrete Syntax Spatial Relationship Graph

20. Activity Metamodel SRG Graph ASG Concrete Syntax parse Abstract Syntax Abstract Syntax Graph

21. Semantics  Operational semantics (execution) concrete syntax: animation rules concrete syntax: animation rules abstract syntax: graph transformation rules abstract syntax: graph transformation rules  Denotational semantics (translation) Abstract Syntax Semantic Domain denotational semantics operational semantics

22. Operational Semantics  diagram syntax plus runtime state  visual rules to model state transitions  produce sequences of states / labels, visualized as animations Abstract Syntax operational semantics

23. Extended Meta Model: Original plus Runtime State Abstract Syntax operational semantics

24. Operational Rules: GT on Meta Model Instances Abstract Syntax operational semantics

25. Animation Trace:placeOrder;calcBill;placeOrder placeOrder calcBill placeOrder calcBill placeOrder Abstract Syntax operational semantics

26. Semantics  Operational semantics (execution)  Denotational semantics (translation) analyse model (compiler front-end) analyse model (compiler front-end) generate semantic representation (compiler back-end) generate semantic representation (compiler back-end) Abstract Syntax Semantic Domain denotational semantics operational semantics

27. Analysis: 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-Formed Activity Diagrams Abstract Syntax

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

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

30. Good Enough for Model Transformations?  Visual  abstract syntax or concrete syntax templates  Bi-directional  inherently symmetry  Declarative  Expressive ?  Context-free graph languages  Traceable ?  Naming conventions  Efficient ?  NP complete parsing problem  Incremental ? Cf. OMG’s QVT requirements

31. A Non-Well-Structured Example Actions Place_order, Pay_bill Processes A = Place_order  B B = if ‘non-empty’ then C else STOP C = Pay_bill  E E =if ‘paid’ then A else STOP [else] [non-empty] [paid] [else] Place order Pay bill A B C E

32. Correspondence Rules: Initial, Action, and Final Nodes A = … A = act  B B = … A = STOP act A B A A  Rule pairs, in condensed presentation Green/bf  {new} Green/bf  {new}  No restriction to context-freeness  Correspondence via common names

33. Correspondence Rules: Choice and Join A = if cond then B else C B = … C = … A = B B = … B [else] C [cond] B A A Negative application condition

34. Correspondence Rules: Connection to Existing Nodes A = BA = BA = BA = B A A act A B B B Either alternative is consistent with left side

35. Formally: Triple Graph Grammars  Meta model for correspondence  traceability  Symmetric rule triplets (left, corr, right), generating directed rules  Declarative  operational Target Metamodel Corresp. Metamodel Source Metamodel >

36. Example TGG Rule :ActivityEdge :Node label = act :ProcEdge :Proc name = A :Prefix name = act target {new} exp {new} act A B A = act  B B = … :ActivityEdge source {new} :ProcEdge :Proc name = B {new} :Var name = B {new} succ leftcorrright

37. Derived Operational GT Rule: right  left Alternatively: left  right left  right (left, right)  corr (left, right)  corr :ActivityEdge :Node label = act :ProcEdge :Proc name = A :Prefix name = act target exp {new} :ActivityEdge source :ProcEdge :Proc name = B {new} :Var name = B {new} succ leftcorrright

38. Outline  Graph transformation  Model transformation  Theory and Tools

39. Theory: Sources of Inspirations 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  Well-definedness  Termination  Confluence  Semantics of process calculi

40. Outline  Graph transformation  Model transformation  Theory and Tools General purpose modeling environments General purpose modeling environments  PROGRES, AGG, Fujaba, … Environments for specifying visual notations Environments for specifying visual notations  DIAGEN, GENGEd, … Analysis tools Analysis tools  Groove, …

41. PROGRES (PROgrammed Graph Rewriting Systems)  Graphical/textual language to specify graph transformations  Graph rewrite rules with complex and negative conditions  Embedded in programming notation for OO data base transactions  Cross compilation in Modula 2, C and Java

42. AGG (The Attributed Graph Grammar System)  Algebraic approach to graph transformation  Attribute computations in Java  Efficient graph parsing  Analysis facilities for critical pairs, consistency of rules and invariants

43. Fujaba (From UML to Java and Back Again)  Round trip engineering with UML, Java, and design patterns  Class and activity diagrams; GT rules as collaborations  Generates standalone Java classes  Various plugins, including triple graph grammars

44. DiaGen (The Diagram Editor Generator )  VL concrete / abstract syntax specified as CF hypergraph grammars  Generation of diagram editors, parsers, simulators

45. GenGED (Generation of Graphical Env.s for Design)  Roughly similar to the above, based on AGG

46. GRaphs for Object-Oriented VErification (GROOVE)  (bounded) generation of LTS from GT systems edge-labelled graphs edge-labelled graphs application conditions application conditions rule priorities rule priorities http://wwwhome.cs.utwente.nl/~groove/groove-index

47. Graph Transformation A “lambda calculus” for MDD ?  Expressiveness and complexity CF graph grammars: Rozenberg; Habel CF graph grammars: Rozenberg; Habel Relation with MSO logic: Courcelle Relation with MSO logic: Courcelle  Execution and optimisation Various tools Various tools Graph matching: Zuendorf 96; Varro et al 05 Graph matching: Zuendorf 96; Varro et al 05  Well-definedness Term graph rewriting: Plump Term graph rewriting: Plump Confluence, termination of attributed GT: Ehrig et al 04 Confluence, termination of attributed GT: Ehrig et al 04  Semantic correctness Requires formal semantics of the languages involved Requires formal semantics of the languages involved  operational: Hausmann et al  denotational: Kuester et al Verification through Verification through  proofs: several authors  model checking: Varro; Rensink  testing: Koenig et al 04

48. Inspired? Join us in Vienna! GT-VMT* 2006  Paper submission: 12 December 2005 *: 5 th Intl Workshop on Graph Transformation and Visual Modelling Techniques ETAPS 2006  The event: 25 March - 2 April 2006  Abstract submission: Friday 7 October 2005  Paper submission: Friday 14 October 2005

49. Questions ?