“…Here the differences are a comprehensive representation of code rather than editing operations; 2) The EMF models of T, T , U are translated into our specific UnCal graphs using Ecore's reflection API, and as a by-product, an UnQL+ transformation is generated from the meaningful differences between T and U using the algorithm in Fig. 10 [3] 3) The UnCal graphs of T, T , U are transformed into Dot graphs by GRoundTram, which preserves the paths from the graph root to any node on the UnCal graphs in the equivalent Dot graphs; 4) Using the generated UnQL+ transformation and the Dot graphs of U as inputs, the GRoundTram system also performs a forward transformation to output a group of Dot graphs that represent T , guaranteed by the one-pass optimisation described in Section V-C; 5) Backwards, using the same UnQL+ transformation on the Dot graphs of the modified template code T , and the internal graph traceability between T and U kept by the forward transformations that performs a backward transformation to output the Dot graphs that represent the merged user code, denoted by T ⊕ U ; 6) Path-equivalent Uncal graphs corresponding to T ⊕ U ; are re-generated from the resulting Dot graphs; 7) An equivalent EMF model of those Uncal graphs for T ⊕ U is obtained using an Xtext parser * * of Uncal to process its abstract syntax using EMF API; 8) Finally, the merged Java code T ⊕U is obtained from the EMF model using JaMoPP's pretty-print function. Since we have a TXL-based parser to generate Dot graphs [3], our presented technique is not limited to EMF based external representations of Java.…”