Bidirectional Transformations — a PL perspective BIRS meeting on BX, 2013
Bidirectional Transformations (BX) to A B from database source materialized view ⇔ software model code ⇔ document representation screen visualization ⇔ concrete syntax abstract syntax ⇔ abstract datatype actual implementation ⇔ program input program output ⇔ 1 – 1/1
Bidirectional Transformations to a 1 b 1 2 – 2/11
Bidirectional Transformations to a 1 b 1 b 2 2 – 3/11
Bidirectional Transformations to a 1 b 1 from a 2 b 2 2 – 4/11
Bidirectional Transformations to a 1 b 1 from a 2 b 2 a 3 2 – 5/11
Bidirectional Transformations to a 1 b 1 from a 2 b 2 to a 3 b 3 2 – 6/11
Bidirectional Transformations to a 1 b 1 from a 2 b 2 to a 3 b 3 2 – 7/11
Bidirectional Transformations to a 1 b 1 unless bijective, typically additional information needed/useful from a 2 b 2 to a 3 b 3 2 – 8/11
Bidirectional Transformations to a 1 b 1 unless bijective, typically additional information needed/useful: from a 2 b 2 ◮ about connections between A and B (objects) to a 3 b 3 2 – 9/11
Bidirectional Transformations to a 1 b 1 unless bijective, typically additional information ∆ needed/useful: from a 2 b 2 ◮ about connections between A and B ∆ (objects) to ◮ about the updates a 3 b 3 on either side ∆ 2 – 10/11
Bidirectional Transformations to a 1 b 1 unless bijective, typically additional information ∆ ∆ needed/useful: from a 2 b 2 ◮ about connections between A and B ∆ ∆ (objects) to ◮ about the updates a 3 b 3 on either side ∆ 2 – 11/11
Objectives for this Talk ◮ get everybody into “BX mode” for the week ◮ set out basic premises of the PL approach, paradigmatic problems ◮ introduce terminology and semantic principles ◮ no details of specific solutions ◮ relate to what “we” think is solved and what not ◮ open discussion 3 – 12/12
What’s specific about “the PL approach”, anyway? 4 – 13/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data 4 – 14/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data ◮ focus on extensional semantics and laws 4 – 15/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data ◮ focus on extensional semantics and laws ◮ correctness by construction/derivation (as opposed to a-posteriori verification) 4 – 16/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data ◮ focus on extensional semantics and laws ◮ correctness by construction/derivation (as opposed to a-posteriori verification) ◮ assuming a very clean setting (naive?) 4 – 17/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data ◮ focus on extensional semantics and laws ◮ correctness by construction/derivation (as opposed to a-posteriori verification) ◮ assuming a very clean setting (naive?) ◮ being driven by our favourite new PL techniques 4 – 18/19
What’s specific about “the PL approach”, anyway? ◮ focus on the transformations/functions themselves, not so much on the data ◮ focus on extensional semantics and laws ◮ correctness by construction/derivation (as opposed to a-posteriori verification) ◮ assuming a very clean setting (naive?) ◮ being driven by our favourite new PL techniques ◮ typically, algebraic data domains 4 – 19/19
Bidirectional Transformations to a 1 b 1 unless bijective, typically additional information ∆ ∆ needed/useful: from a 2 b 2 ◮ about connections between A and B ∆ ∆ (objects) to ◮ about the updates a 3 b 3 on either side ∆ 5 – 20/20
Bidirectional Transformations to a 1 b 1 focus on: ◮ single-side updates ∆ ∆ ◮ one-step updates from a 2 b 2 6 – 21/23
Bidirectional Transformations to a 1 b 1 focus on: ◮ single-side updates ∆ ∆ ◮ one-step updates from a 2 b 2 also, focus on asymmetric setting: ◮ to usually non-injective, henceforth called get ◮ from then called put , definitely needs extra info ◮ for simplicity, state-based ◮ “sources” and “views” 6 – 22/23
Bidirectional Transformations get v s focus on: ◮ single-side updates ∆ ∆ ◮ one-step updates put v ′ s ′ also, focus on asymmetric setting: ◮ to usually non-injective, henceforth called get ◮ from then called put , definitely needs extra info ◮ for simplicity, state-based ◮ “sources” and “views” 6 – 23/23
Bidirectional Transformations s v connections. A closer look at representing For example: get y x y z z u u v v 7 – 24/29
Bidirectional Transformations s v connections. A closer look at representing For example: get y x y z z u u v v 7 – 25/29
Bidirectional Transformations s v connections. A closer look at representing For example: get get y x y x y z y z or z u z u u v u v v v x 7 – 26/29
Bidirectional Transformations s v connections. A closer look at representing For example: get get y x y x y x y z y z y z or or z u z u z u u v u v u v v v v x 7 – 27/29
Bidirectional Transformations s v connections. A closer look at representing For example: get get y x y x y x y z y z y z or or z u z u z u u v u v u v v v v x Why is it not enough to look just at the data? x x y y z z u u v 7 – 28/29
Bidirectional Transformations s v connections. A closer look at representing For example: get get y x y x y x y z y z y z or or z u z u z u u v u v u v v v v x Why is it not enough to look just at the data? Because of: x x x x y y x x z z x x u u x x v x 7 – 29/29
Bidirectional Transformations Some further relevant aspects: ◮ What artifacts need to be specified? ◮ both get and put ◮ only one of them, the other derived ◮ a more abstract artifact, from which both derivable ◮ How are they specified, manipulated, analyzed? ◮ What properties are they expected to have? ◮ What influence does a user, modeller, programmer have? 8 – 30/30
Properties / Laws
Bidirectional Transformations Specific asymmetric setting, state-based: source view get s v update v ′ s ′ put get :: S → V put :: S → V → S 10 – 32/33
Bidirectional Transformations Specific asymmetric setting, state-based: source view get s v update v ′ s ′ put get :: S → V assumed put :: S → V → S total! 10 – 33/33
About Behavior under No-Change project out string component foo 5 foo 11 – 34/40
About Behavior under No-Change foo 5 foo bar 11 – 35/40
About Behavior under No-Change foo 5 foo bar 0 bar propagate always set numeric updated string field to 0 11 – 36/40
About Behavior under No-Change foo 5 foo = foo 11 – 37/40
About Behavior under No-Change foo 5 foo = ≠ foo 0 foo 11 – 38/40
About Behavior under No-Change foo 5 foo = ≠ foo 0 foo Principle: If the view does not change, neither should the source. To prevent this, the GetPut law: put s ( get s ) = s 11 – 39/40
About Behavior under No-Change foo 5 foo = ≠ foo 0 foo Principle: If the view does not change, neither should the source. To prevent this, the GetPut law: put s ( get s ) = s NB: For this, put must be surjective. 11 – 40/40
About Preservation of Changes project out string component foo 0 foo 12 – 41/46
About Preservation of Changes foo 0 foo bar 12 – 42/46
About Preservation of Changes foo 0 foo blech 5 bar return a constant 12 – 43/46
About Preservation of Changes foo 0 foo blech 5 bar ≠ blech 12 – 44/46
About Preservation of Changes foo 0 foo blech 5 bar ≠ blech Principle: Updates To prevent this, the PutGet law: should be translated exactly. get ( put s v ) = v 12 – 45/46
About Preservation of Changes foo 0 foo blech 5 bar ≠ blech Principle: Updates To prevent this, the PutGet law: should be translated exactly. get ( put s v ) = v NB: For this, put s must be injective for every s . 12 – 46/46
Somewhat more Challenging project out and duplicate string component foo 0 foo foo 13 – 47/51
Somewhat more Challenging foo 0 foo foo bar foo 13 – 48/51
Somewhat more Challenging foo 0 foo foo bar 0 bar foo propagate "newest" string 13 – 49/51
Somewhat more Challenging foo 0 foo foo bar 0 bar foo ≠ bar bar 13 – 50/51
Somewhat more Challenging foo 0 foo foo bar 0 bar foo ≠ bar bar If we want to allow such behavior, we need to weaken the PutGet law (and people have done so). 13 – 51/51
About Consistent Composition project out string component foo 0 foo 14 – 52/59
About Consistent Composition foo 0 foo bar 14 – 53/59
Recommend
More recommend
