Trace-based Approach to Editability and Correspondence Analysis for Bidirectional Graph Transformations

Overview

• The GRoundTram system, implemented in OCaml, that provides the core graph transformation functionality.
• The GRoundTram GUI, implemented in Java, that provides a graphical user interface for interacting with the GRoundTram system by calling commands provided by GRoundTram system.

Installation Instructions

Step 1:

Step 2:

Step 3:

These commands will need to be copied to the niiexe folder of the GRoundTram GUI so the GUI can call them.

Step 4:

Download the source code of GRoundTram GUI and build. See README file in the source on how to build using Eclipse JDT. As mentioned in Step 3, GRoundTram GUI has a folder called niiexe where commands of GRoundTram system should reside.

Download

• GRoundTram source (tgz; 3.43MB) MD5:ebbc94ada85e98730971573e33d292e2
• GRoundTram GUI source (tgz; 3.17MB) MD5:5f3a2abf38a2a73e4fdf753864d9fc92

Demo of Trace Highlighting and Editability

Country example

let $german = German in
let $europe = Europe in
 {
     country : {name: Japan,
                people : {ethnicGroup: Japanese},
                language: Japanese,
				continent: Asia
                },
     country : {name: Germany,
                people : {ethnicGroup: German},
                language: $german,
				continent: $europe
               },
     country: {name: Austria,
     	        people : {ethnicGroup: Austrian},
                language: $german,
				continent: $europe
	      }               
 }

select {result : {ethnic: $e, language: $lang, located : $cont}}
where {country : 
		{name   :$g, 
		 people : {ethnicGroup: $e},
	     language: $lang,
		 continent: $cont}} in $db,
	     {$l:$Any} in $cont,
	      $l = Europe
	
		

After pressing the forward transformation button and switching GRoundTram GUI to the 3-panel mode, the GRoundTram GUI should look like below:

When we click on the two edges (3, German, 1) and (13,language, 3) in the view graph (right panel), edges and code positions are highlighted. Moreover, some view edges are drawn as dashed lines. The explanation is as follows:

• The view edges drawn as dashed lines, e.g. (0,result,14), are constant edges meaning that their labels cannot be renamed.
• In the source graph in the left panel, the edge (1,German,0) is highlighted. This edge is the source edge, from which the view edge (3, German, 1) is copied.
• In the view graph, the edge (4,German,2) is highlighted in green. This indicates that the edges (3,German,1) and (4,German,2) can not be inconsistently modified, i.e. renamed to different labels.
• In the transformation on the bottom left panel, the edge constructor {language:$lang} is highlighted gray and graph variable $language are highlighted yellow. The edge constructor {language:$lang} creates the view edge (13,language,3) while the graph variable $language copies the source edge (1,German,0) of the source graph to the view graph, i.e. (3,German,1).

Editability supports in action

The screenshot on the right shows that the attempt to update the constant edge (0,result,14) rendered in dashed lines, as described in the above scenario, is prevented by graying out the "Edit Label" action in the context menu. The context menu is shown on the right part of the screenshot. Click on it to magnify.

The next screenshot shows the error message that prevent the inconsistent update scenario described above, i.e., the edge (3,German,1) is updated to (3, German (Germany) 1) (which is accepted by the editor) and then renaming (4,German,2) is further tried. The GUI warns the user saying "Inconsistent with modification German (Germany) of this equivalence class!". The message is shown on the top right part of the screenshot. Click on it to magnify.

The next scenario is to show the support to prevent failure caused by branch behavior change. The transformation selects the countries within the "Europe"an continent. What if user attempts to modify the edge that encode this affiliation? When the user tried to update the label of the view edge (8,Europe,6) to EuroAsia and execute backward transformation, the execution fails, because reflecting the update to change the source edge (3,Europe,2) to (3,EuroAsia,2) would make another forward transformation produce empty result, because no country belongs to "Europe"ean contentment. Since it violates well-behavedness property, the GRoundTram rejects such updates saying "branch behavior changed". In the transformation, the graph variable "$cont" is highlighted, indicating that the updated subgraph is bound to "$cont". Since the label variable "$l" is extracted from the "$cont" by one of the "where" clauses "{$l:$Any} in $cont", user can infer that changing the subgraph will impact the condition "$l = Europe" in the last line of the "where" clause. In this way, user could avoid such run-time error before executing backward transformation by looking at the highlighted variables in the transformation. Highlighting the exact branching condition ("$l = Europe") is our future work.

Customer2Order

Another interesting example is Customer2Order, which is adapted from a similar example in the textbook on model-driven software development:

O. Pastor and J. C. Molina. Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling. Springer-Verlag, 2007.

The UnCAL expression of the source graph:

&src @ cycle(
(
  &src :=
     { Customer: &customer1,
       Customer: &customer2
     },

  &customer1 :=
     { name: "Tanaka",
       email: "tanaka@biglab",
       email: "tanaka@gmail",
       add: &add1,
       order: &order1,
       order: &order2
     },

  &customer2 :=
     { name: "Kato",
       email: "kato@biglab",
       add: &add1,
       add: &add2,
       order: &order3
     },

  &add1 :=
     { type: "shipping",
       code: "200-777",
       info: "BiG office of Tokyo"
     },

  &add2 := 
     { type: "contractual",
       code: "100-888",
       info: "IPL of Tokyo"
     },

  &order1 :=
     { date: "16/07/2008",
       no: 1001,
       order_of: &customer1
     },

  &order2 :=
     { date: "16/10/2008",
       no: 1002,
       order_of: &customer1
     },

  &order3 :=
     { date: "16/12/2008",
       no: 1003,
       order_of: &customer2
     }
)
)

The following UnQL transformation shows the list of orders.

select 
  {Order: 
    {date: $date,
     no: $no,
     customer_name: $name,
     addr: $a}
  }
where 
  {Customer.order: $o} in $db,
  {order_of:$c, date:$date, no:$no} in $o,
  {add:$a, name:$name} in $c,
  {code:$code, info:$info, type:{$t:{}}} in $a,
  $t = "shipping"
	
		

The screenshot of GRoundTram GUI after the transformation has been executed is as follows:

In the view graph, we click on the view edges (42,addr,35), (35,code,24), (35, info, 18) and (35,type,30) and see that edges and code positions are highlighted. Moreover, some view edges are drawn as dashed line. The explanation for this is as follows:

• The view edges drawn as dashed lines, for example (0,Order,42), are constant edges. That means, their labels cannot be edited.
• The source edges (32,info,19), (32, type, 23) and (32,code,21) of the source graph are edges from which the view edges (35,info,18), (35, type, 30) and (35,code,24) are copied.
• The view edges (34,type,29), (34, code, 23) and (34,info,17) are drawn in green. This means, that the pairs of view edges (35,code,24) and (34,code,23), (35,info,18) and (34,code,14) as well as (35,type,30) and (34,type,29) cannot be inconsistently modified, e.g. renamed to different labels.
• The edge constructor {addr: $a} is highlighted gray because it creates the selected view edge (42,addr,35). The graph variable $a is highlighted because it produces the view edges (35,code,24), (35, info, 18) and (35,type,30) by copying from the source graph.

Class2RDB

Class2RDB is a model transformation proposed by Bézivin et al. [2005] as a common benchmark example for all the participants of the Model Transformation in Practice workshop for comparing and contrasting various approaches to model transformation. Class2RDB maps Class models to RDB models.

Jean Bézivin, Bernhard Rumpe, Andy Schürr, Laurence Tratt: Model Transformations in Practice Workshop, in Satellite Events at the MoDELS 2005 Conference, Lecture Notes in Computer Science, Vol. 3844, Springer-Verlag, 2006, pp. 120-127.

The UnCAL expression of the source graph:
Example Class Model

The following UnQL transformation maps each persistent class in a Class model to a table in the RDB model. Class2RDB Transformation

The screenshot of GRoundTram GUI after the transformation has been executed is as follows (click to magnify):

In the view graph, we click on the view edge (90,PrimitiveDataType,96) and, as in the previous examples, some view edges are drawn as dashed line. The green edges are the ones that share the same origin (60,PrimitiveDataType,68) in the source, so they cannot be inconsistently edited, and the GUI prohibits this kind of editing operations.

Difference between the paper and the implementation

1. Mechanism for correspondence analysis and editability analysis were separated, while present paper unifies them.
2. Correspondence traces mainly relied on the structured node ID, while current paper does not.

Reference