Bidirectional Transformations a PL perspective BIRS meeting on - - PowerPoint PPT Presentation
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
1 – 1/1
2 – 2/11
2 – 3/11
2 – 4/11
2 – 5/11
2 – 6/11
2 – 7/11
2 – 8/11
2 – 9/11
◮ about connections
2 – 10/11
◮ about connections
◮ about the updates
2 – 11/11
◮ about connections
◮ about the updates
◮ get everybody into “BX mode” for the week ◮ set out basic premises of the PL approach,
◮ 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
4 – 13/19
◮ focus on the transformations/functions
4 – 14/19
◮ focus on the transformations/functions
◮ focus on extensional semantics and laws
4 – 15/19
◮ focus on the transformations/functions
◮ focus on extensional semantics and laws ◮ correctness by construction/derivation
4 – 16/19
◮ focus on the transformations/functions
◮ focus on extensional semantics and laws ◮ correctness by construction/derivation
◮ assuming a very clean setting (naive?)
4 – 17/19
◮ focus on the transformations/functions
◮ focus on extensional semantics and laws ◮ correctness by construction/derivation
◮ assuming a very clean setting (naive?) ◮ being driven by our favourite new PL techniques
4 – 18/19
◮ focus on the transformations/functions
◮ focus on extensional semantics and laws ◮ correctness by construction/derivation
◮ assuming a very clean setting (naive?) ◮ being driven by our favourite new PL techniques ◮ typically, algebraic data domains
4 – 19/19
5 – 20/20
◮ about connections
◮ about the updates
6 – 21/23
◮ single-side updates ◮ one-step updates
◮ 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
◮ single-side updates ◮ one-step updates
◮ 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
◮ single-side updates ◮ one-step updates
7 – 24/29
7 – 25/29
7 – 26/29
7 – 27/29
7 – 28/29
7 – 29/29
◮ 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,
8 – 30/30
10 – 32/33
10 – 33/33
foo 5 foo
project out string component
11 – 34/40
foo 5 bar foo
11 – 35/40
foo 5 bar bar foo
propagate updated string always set numeric field to 0
11 – 36/40
foo 5 foo foo
11 – 37/40
foo 5 foo foo foo
11 – 38/40
foo 5 foo foo foo
11 – 39/40
foo 5 foo foo foo
11 – 40/40
foo foo
project out string component
12 – 41/46
foo bar foo
12 – 42/46
foo blech 5 bar foo
return a constant
12 – 43/46
foo blech 5 bar foo blech
12 – 44/46
foo blech 5 bar foo blech
12 – 45/46
foo blech 5 bar foo blech
12 – 46/46
foo foo
project out and duplicate string component
foo
13 – 47/51
foo bar foo foo foo
13 – 48/51
foo bar bar foo
propagate "newest" string
foo foo
13 – 49/51
foo bar bar foo bar
foo foo bar
13 – 50/51
foo bar bar foo bar
foo foo bar
13 – 51/51
foo foo
project out string component
14 – 52/59
foo bar foo
14 – 53/59
foo bar 1 bar foo
increment numeric component if string component has changed
14 – 54/59
foo bar 1 quux bar foo
14 – 55/59
foo bar 1 quux 2 quux bar foo
translated updates produce "side effects" on source
14 – 56/59
foo bar 1 foo bar foo
restore original target
14 – 57/59
foo bar 1 foo 2 foo bar foo
is not restored
14 – 58/59
foo bar 1 foo 2 foo bar foo
is not restored
14 – 59/59
15 – 60/61
15 – 61/61
S V
17 – 63/69
S V
17 – 64/69
S V
17 – 65/69
S V
17 – 66/69
S V
17 – 67/69
S V
17 – 68/69
S V
17 – 69/69
S V
18 – 70/71
S V
18 – 71/71
19 – 72/75
19 – 73/75
19 – 74/75
19 – 75/75
◮ a lot of very nice definitive work on semantics ◮ successful methods for automatic derivation of
◮ combinator languages with powerful
◮ program transformations based on
◮ query languages with automatic tracing ◮ grammar-based approaches 21 – 77/77
◮ “How to deliver BX to the masses? Some
◮ “But I think to really achieve world domination,
22 – 78/78
◮ “Can we design a declarative language that can
◮ “We still lack effective, intuitive (user-friendly)
◮ “Ability to control the choice between multiple
23 – 79/79
◮ “[. . . ] still no effective solution for non-tree
◮ “Bx on ordered graphs (outgoing edges are
◮ “Handling of constraints over the domains (that
24 – 80/80
◮ scaling up in every way ◮ providing control over nondeterminism ◮ capturing user/programmer intentions ◮ handling richer structures/domains ◮ running efficiently
25 – 81/81