Towards Typechecking for Model Transformations by Monadic 2 nd -Order Logic

1. Towards Typechecking for Model Transformations by Monadic 2nd-Order Logic Kazuhiro Inaba (稲葉 一浩)@ NII Nov 16, 2009 Nov 24, 2009 Changsha 3rd Bi-Trans in ABCIPL Seminar

2. Checking Models Every Time ModelTransformation F Model A Model F(A) Typechecking Typechecking Metamodel M1 Metamodel M2

3. Checking TransformationOnly Once! ModelTransformation F “Any model satisfying M1 always outputs by F a model of M2!” Checkingof ModelTransformation Metamodel M1 Metamodel M2

4. Our Approach: Use Logic ModelTransformation F Covert to Logic Formula Metamodel M2 Metamodel M1 “output satisfies M2” Valid! (True for any model!) Solver “Input and Output are related by F” ⇒ & “input satisfies M1”

5. Simplified Example ( ∀e: inlabel_A(e) ∧∀e: ( outlabel_B(e) ⇔ inlabel_A(e) ∧ ￢outlabel_A(e) ) ) ⇒ ∀e: outlabel_B(e) Input Schema: “all edges are labeled A” Output Schema: “all edges are labeled B” Translation: “change all A to B”

6. Agenda • From Model Transformation to Logic • MSO Logic, Graphs, Schemas and UnCAL • Validation of MSO Logic Formula • Conclusion and Future Work • Application to Bidirectional Transformation

7. Monadic 2nd-Order Logic (MSO) connected(x,y) :=∃set P. (x ∈ P & y ∈ P & ∀u,v.(u∈P & edge(u,v)⇒ v∈P) & …) • MSO is a • Usual 1st order predicate logic • Boolean ops and quantifiers: ￢,　∧, ∨, ∀, ∃ • …extended with “set-quantifications”: ∀set∃set • E,g,.,

8. Graph (Model) a c a b c d • We regard models as edge-labeled graphs  i.e., we consider the problem of typechecking for graph transformation

9. Schema (Metamodel) class Customer { reference email [1-*] : String; reference order [0-*] : Order; } class Order { reference no [1-*] : Int; reference order_of [1-*] : Customer; } Only [0-*] and [1-*] are allowed Subset of KM3 [Jouault&Bezivin ‘06]

10. Converting Schema to MSO Customer class Customer { reference email [1-*] : String; reference order [0-*] : Order; } email order “a@b.c” order Order Order ∀e: label_Customer(e) ⇒ ∃set C1, C2. outgoing(e, C1∪C2) & |C1|≧1 & ∀f∈C1. (label_email(f) & …) & |C2|≧0 & ∀f∈C2. (label_order(f) &∃g. outgoing(f, {g}) & label_Order(g))

11. Transformation Language rec(λ($L, _). // for each edge if $L = a then {d: &} // if label=a change to d else if $L = c then & // if label=c, delete else {$L: &} // otherwise, keep unchanged) • UnCAL [Buneman&Fernandez&Suiciu ‘00] • Internal Graph Algebra of GRoundTram • Based on “Structural Recursion” on graphs

12. Converting UnCAL to MSO rec(λ($L, _). if $L = a then {d: &} else if $L = c then & else {$L: &} ) d a b b d d ε c outgraph_edge_d(v,e,u)⇔ ingraph_edge_a(v,e,u) ∨ ingraph_edge_d(v,e,u)∧outgraph_edge_a(v,e,u) ⇔ false ∧outgraph_edge_b(v,e,u) ⇔ ingraph_edge_b(v,e,u) ∧outgraph_edge_c(v,e,u) ⇔ false ∧outgraph_edge_ε(v,e,u) ⇔ ingraph_edge_c(v,e,u)

13. Converting UnCAL to MSO rec(λ($L, _). if $L = a then {d: {d: &}} else if $L = c then & else {$L: &} ) a b d c d b d d ε k-Copying MSO Transduction [Courcelle94]

14. d a b b d d d c ε outgraph_112_edge_d(v,e,u)⇔ u=v ∧ ∃u. ingraph_edge_a(v,e,u)∧ outgraph_221_edge_d(v,e,u) ⇔ ingraph_edge_a(v,e,u) ∧ outgraph_111_edge_d(v,e,u) ⇔ ingraph_edge_d(v,e,u) ∧ ￢outgraph_{121,122,211,212,222}_edge_d(v,e,u) ∧ outgraph_111_edge_b(v,e,u) ⇔ ingraph_edge_b(v,e,u) ∧ outgraph_111_edge_ε(v,e,u) ⇔ ingraph_edge_c(v,e,u)

15. Output Schema ∀e: label_Customer(e) ⇒ … ∀e: ( (outlabel_1_Customer(e) ⇒ …) ∧(outlabel_2_Customer(e) ⇒ …) ) • Basically as same as the input schema … ※ label_Customer(e)=∃u,v:ingraph_edge_Customer(e,u,v)) But we must make it “copy-aware”

16. [Revisited] Our Approach ModelTransformation F Covert to Logic Formula Metamodel M2 Metamodel M1 “output satisfies M2” Valid! (True for any graph!) Solver “Input and Output are related by F” ⇒ & “input satisfies M1”

17. Bad News Valid! (True for any graph!) Theorem [Trakhtenbrot 50]:Validness property is undecidable on graphs, even for 1st-order logic.

18. Not-so-bad News • MSO validness is decidable on trees. [Thatcher&Wright68] • Also decidable on tree-likegraphs (bounded tree-width),but it’s too tree-like • Models are general graphs!

19. Good News a c UnCAL Transformation Unfolding Unfolding a a a c c c ・・・ ∞ ・・・ ∞ UnCAL is bisimulation-generic. [BFS ‘00]

20. ※ Bisimulation-Generic • Two graphs (V1,E1) and (V2, E2) are bisimilariff there exists S ⊆ V1 × V2 s.t. • (u1, u2) ∈ S and (u1, σ, v1) ∈ E1implies ∃v2.( (v1, v2)∈S and (u2, σ, v2)∈E2 ) • (u1, u2) ∈ S and (u2, σ, v2) ∈ E2implies ∃v2.( (v1, v2)∈S and (u1, σ, v1)∈E1 ) • Transformation f is bisimulation-genericiff • For all bisimilar G1 and G2, f(G1) and f(G2) are also bisimilar

21. Our Approach:Infinite Trees Decidable! UnCAL and our schema do not distinguish a graph and its unfolded infinite tree Our MSO formulas are valid (true on all graphs) ifftrue on all infinite trees

22. Our Approach:Infinite Trees to Finite Trees ✂ c c c c ✂ ・・・ ∞ c c ✂ c c c ✂ ・・・ Bad: Deciding MSO on infinite trees is costy Good: Considering only Finite Cuts suffices

23. Type Correctness Metamodel Metamodel Transformation Validness of MSO Formula on Graphs Validness of MSO Formula on Infinite Trees Validness of MSO Formula on Finite Trees Checked by the Well-known Solver MONA ΦM1&ΦF⇒ΦM2 ΦM1&ΦF⇒ΦM2 Φ’M1&Φ’F⇒Φ’M2

24. Summary & ToDo rec(λ($L1,$G1).rec(λ($L2, $G2). … {x: $G1, y: $G2})($G1) ) • Typechecking is reduced to MSO Validity,using the Bisimulation-Genericity of UnCAL • Current Restriction • Slow (Mainly due to k-copying!) • Schema must be bisimulation generic • class Foo { reference bar[1] : Buz; } • No nested recursion