towards typechecking for model transformations by monadic 2 nd order logic n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Towards Typechecking for Model Transformations by Monadic 2 nd -Order Logic PowerPoint Presentation
Download Presentation
Towards Typechecking for Model Transformations by Monadic 2 nd -Order Logic

Loading in 2 Seconds...

play fullscreen
1 / 24

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


  • 87 Views
  • Uploaded on

Towards Typechecking for Model Transformations by Monadic 2 nd -Order Logic. Kazuhiro Inaba ( 稲葉 一浩 ) @ NII Nov 16, 2009 Nov 24, 2009 Changsha 3 rd Bi-Trans in ABC IPL Seminar. Checking Models Every Time. Model Transformation F. Model A. Model F(A). Typechecking. Typechecking.

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 'Towards Typechecking for Model Transformations by Monadic 2 nd -Order Logic' - telyn


Download Now 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
towards typechecking for model transformations by monadic 2 nd order logic

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

checking models every time
Checking Models Every Time

ModelTransformation

F

Model

A

Model

F(A)

Typechecking

Typechecking

Metamodel

M1

Metamodel

M2

checking transformation only once
Checking TransformationOnly Once!

ModelTransformation

F

“Any model satisfying M1 always outputs by F a model of M2!”

Checkingof

ModelTransformation

Metamodel

M1

Metamodel

M2

our approach use logic
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”

simplified example
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”

agenda
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
monadic 2 nd order logic mso
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,.,
graph model
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

schema metamodel
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]

converting schema to mso
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))

transformation language
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
converting uncal to mso
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)

converting uncal to mso1
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]

slide14

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)

output schema
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”

revisited our approach
[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”

bad news
Bad News

Valid! (True for any graph!)

Theorem [Trakhtenbrot 50]:Validness property is undecidable on graphs, even for 1st-order logic.

not so bad news
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!
good news
Good News

a

c

UnCAL Transformation

Unfolding

Unfolding

a

a

a

c

c

c

・・・ ∞

・・・ ∞

UnCAL is bisimulation-generic. [BFS ‘00]

bisimulation generic
※ 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
our approach infinite trees
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

our approach infinite trees to finite trees
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

slide23

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

summary todo
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