Lehman's laws state that dedicated efforts must be spent for any software artifact to prevent a loss of quality. For code, such efforts are called refactoring operations and are an important aspect of many software engineers day-to-day business. Many of these refactoring operations are specified on a much higher abstraction level than the actual source code of a given language like Java. To be able to specify these refactoring operations on a higher abstraction level as proposed in the Java Refactoring Case at the Transformation Tool Contest (TTC) 2015, we propose a solution using an incremental synchronization with NMF Synchronizations of the source code regarded as a model on the one side and a simplified program graph model on the other side.
NMF Synchronizations is a bridge between the model transformation language NMF
Transformations [
Although NMF Synchronizations offers support for bidirectional model transformations, we do not use this feature. The reason is that the model transformation task of the proposed case conflicts with our definition of a model transformation being basically a function from one metamodel to another. Therefore, we classify the task of the present case study rather as a model synchronization task. We transform the Java model (we use JaMoPP) to a Program Graph model, modify this Program Graph model and propagate these changes back to the original JaMoPP model.
Currently, NMF Synchronizations only supports online synchronization. This means, any changes in the Program Graph model are immediately reflected in the JaMoPP model. In particular, the model synchronization adds hooks into the Program Graph model and reacts on changes in that it applies these changes to the JaMoPP model. As a consequence, the backward transformation from the case description and the refactoring operation on the PG get merged.
However, we do not support a one-way change propagation mode in the opposite direction of the transformation, and so we have selected the two way change propagation mode. That is, any changes in either of the JaMoPP model or the Program Graph model will be reflected in the other model.
We are aware that this causes some overhead when the Program Graph model is used only for a onetime refactoring, and we will add a change propagation mode one way to source in the future. Originally, when NMF Synchronizations was designed, we could not think of a useful application for this change propagation mode, but the present case study offers a good one. 2.1
Model synchronizations in NMF Synchronizations are classes and the synchronization rules are represented by public non-abstract nested classes. Listing 1 shows an excerpt of the model synchronization that synchronizes classes. 1 class JavaPGSynchronization : ReflectiveSynchronization { 2 public class Class2Class : SynchronizationRule<IClass, ITClass> { 3 public override void DeclareSynchronization() { 4 Synchronize(cl => cl.Name, cl => cl.TName); 5 SynchronizeMany(SyncRule<Member2Member>(), 6 cl => cl.Members.Where(m => m is ClassMethod || m is Field), 7 cl => cl.Defines); 8 Synchronize(this, 9 cl => cl.Extends as IClassifierReference != null 10 ? (cl.Extends as IClassifierReference).Target as IClass 11 : null, RegisterNewBaseClass, 12 cl => cl.ParentClass); 13 } 14 } 15 }
5http://nmfexpressions.codeplex.com
In Line 2, we declare that Class2Class is a synchronization rule synchronizing JaMoPP classes with PG classes. Line 4 specifies that whenever we find such two classes that correspond (decided by another method called ShouldCorrespond), their names should be synchronized. Line 5-7 specify that each member of a JaMoPP class should correspond to a definition in the PG. The details for this correspondence are left to the Member2Member rule.
Lines 8-12 specify that the base classes should be synchronized. The current rule (Class2Class should be used to identify corresponding base classes as well, explaining the this parameter in Line 8. However, whereas the base class of a Java class in the PG metamodel is available directly as a reference, the base class in JaMoPP is encoded in a classifier reference, making the expression to obtain the base class slightly more complex. As a consequence, NMF Synchronizations is not able to infer how to revert the expression and we have to specify this (i.e. how a JaMoPP class is assigned another class as a base class) through another method, RegisterNewBaseClass. With this method, the behavior how to assign a JaMoPP class a new base class is implemented in regular imperative code.
The implementation of Member2Member for the case of methods is presented in Listing 2.
In this listing, again Line 1 declares Method2MethodDefinition as a synchronization rule from JaMoPP methods to PG method definitions. A JaMoPP method should correspond to a PG method definition in a given scope if the methods have the same name here. We specify the exact behavior in lines 2-8. Since the structure of the PG metamodel is very different to JaMoPP in this regard, the method is a few lines long.
Line 11 marks the synchronization rule instantiating for the Member2Member-rule. That is, if a member is a method, then the rule Method2MethodDefinition should be used to synchronize members, regardless of the transformation direction. Another rule Field2FieldDefinition is used for synchronizing fields.
Line 12 denotes that the name of a method in JaMoPP should be kept consistent with the name of the method in the PG model. If we changed the name of a method in JaMoPP, the change is propagated to the PG TMethod element. However, this change is propagated back to the JaMoPP model causing all methods that are connected to this PG method to change their name accordingly, regardless of their declaration scope or signature. So we have specified a very powerful rename refactoring in just a single line of code.
NMF Synchronizations under the hood uses the transformation engine of NMF Transformations. In particular, every synchronization rule is mapped to a pair of transformation rules, one for either direction of the synchronizations. Since these transformation rules are still accessible, we can add a dependency to the Method2MethodSignature that creates a TMethodSignature element for the given name and parameter list. For a given name and parameter list, the transformation engine ensures that only one method signature element is created. This transformation rule calls another rule Method2Method that creates a method element for each string that appears as a method name in the JaMoPP model.
These transformation rules Method2Method and Method2MethodSignature are called any time the LeftToRight rule of the synchronization rule Method2MethodDefinition are called. This is done either initially for each method in the JaMoPP model (restricted to at most once per input names and parameter lists) as well as for any new JaMoPP method that is added to the JaMoPP model afterwards. 2.2
The refactoring part of our solution uses straightforward imperative code to achieve the refactoring operations. As the Create Superclass is very simple to implement in classic C# code, we omit a description.
The implementation of the Pull Up Method refactoring is shown in Listing 3.
The solution utilizes the Language Integrated Query (LINQ) that is around for almost ten years now and used by thousands of developers. Given the conciseness of this specification based on the TypeGraph metamodel, we see no reason to use a specialized language for the refactoring. However, due to the online synchronization, we have to be careful to always keep the model in a consistent state, we must not discard the method that should stay as otherwise the connected implementation in the JaMoPP model would be lost. In particular, at least one method element of the PG model must be reused in the refactoring as otherwise no method body is attached to a newly created method element. 3
We did not manage to integrate our solution into the ARTE framework suggested by the case authors in order to get a reliable performance comparison, nor did the serialization of the JaMoPP model back to Java source code work. Therefore, we only validated the correctness of our solution manually. Hence, our solution only is a proof-of-concept.
The main insight from the Java Refactoring case for us is that the bidirectional model synchronization of structurally different models is a powerful yet dangerous tool. Powerful because it allows to specify some refactoring operations like renaming in a very concise way. It is dangerous because it is opaque to the developer that the code model is synchronized with a refactoring model, especially because it currently is impossible to break up the synchronization. This synchronization yields that when someone changes the name of a method in the code model, automatically all methods with the same name are renamed as well. On the other hand, if a method’s name is changed into one that already exists, then the method elements in the program graph model are not merged, leading to an inconsistent behavior. In particular, as soon as this operation is performed and one changes the name of such a method in the JaMoPP model, some methods are renamed but others are not as they are synchronized with a different method element in the program graph model.
This is of course a more general problem of unclear semantics synchronizing structurally heterogeneous models with overlapping semantics. It not only related to our solution. A solution for this dilemma would be to disable two-way synchronization but restrict to one-way synchronization against the transformation direction, i.e. that changes in the target model are propagated back to the source. 4
In this paper, we have presented our solution to the Java Refactoring case using NMF Synchronizations. In this solution, we refactor Java code by first loading it into memory as a JaMoPP model, synchronizing this model with a new Program Graph model and refactoring the resulting Program Graph model. As a consequence of the bidirectional synchronization, the original refactoring is automatically applied to the source code model. The advantage here is that the high-level program graph model can be used for a multitude of refactoring operations.
We identified this case as a premier use case for change propagation in the opposite of the primary transformation direction, a feature where we did not see application scenarios yet. This feature will be included in NMF Synchronizations in order to make it more flexible. The bidirectional synchronization that we have applied in the meantime offers powerful refactorings with a very concise implementation but yields consequences hard to foresee.
Our solution is not integrated into the ARTE framework and we therefore do not have any performance results comparing the solution alternative solutions.