The Solution is hosted under https://bitbucket.org/mschmidt987/java-refactoring-case-ttc-2015-solution-fg-se-uni-kassel This paper describes the SDMLib solution to the Java Refactoring case for TTC2015 [2]. SDMLib provides a mechanism for generating an abstraction model of a provided java program. In addition, SDMLib provides code generation that transforms the whole model or parts of it into java code. Thus, for the Java Refactoring case we just added a Refactorer that reads a java project and transforms the program graph according to the intended refactorings. These transformations are collected and applied to the source code by the SDMLib generator afterwards.
olaf.gunkel|matthias.schmidt|zuendorf@cs.uni-kassel.de
Transforming java source code into an abstract model is a complex task that can be accomplished by using a powerful parser. To solve this, SDMLib provides a recursive descent parser that analyzes java source code files and create an abstract graph model. Using the parser is really easy due to the fact that, as shown in Listing 1, the source folder and the package name (of the program that should be abstracted) is required. 1 p u b l i c v o i d u p d a t e F r o m C o d e ( S t r i n g s r c F o l d e r , S t r i n g packageName ) { . . . }
Listing 1: Signature of the method that calls the parser for java programs After parsing the source code, SDMLib provides a model that contains all information required for the refactoring case. The parts of the model, which we use to solve the case, can be seen in Figure 1.
The SDMLib model provides nearly every information that we need for the case. The only missing
information, which is still missing in the solution, is the access-assoziation of class TMember as shown
in figure 2 of the case description[
To push our graph changes into the code, SDMLib supports us with its generator, that updates the parsed code. After creating a ClassModel by parsing a java project, every included class has its own parser instance, held by the ClassModel. The parsers are holding all relevant information about their class. For example, they have symbol tables in which, for every member, information about its position in the sourcecode are stored. By using this position information, its possible to extract, replace and insert parts of the sourcecode. Because of this relation, we can use the symbol table to delete, move or insert members in the source code. Listing 2 shows how to delete a member from the source file of a class. After replacing entries in the class, we set the boolean field fileChanged to true and commit the changes to the generating class CGUtil. Its printFile(Parser) Method writes the changes into the source code files. SymTabEntry memberToDelSTE = c l a z z P a r s e r . g e t S y m T a b E n t r y ( delMember ) ; c l a z z P a r s e r . r e p l a c e ( memberToDelSTE . g e t S t a r t P o s ( ) ,
memberToDelSTE . g e t E n d P o s ( ) + 1 , "" ) ; c l a z z P a r s e r . w i t h F i l e C h a n g e d ( t r u e ) ; C G U t i l . p r i n t F i l e ( c l a z z P a r s e r ) ;
Listing 2: How to push changes to the source code with SDMLib 3
Our solution covers the three major transformation steps (code to program graph, program graph refactoring and program graph to code) with support for create class-, pull up method-, pull up field- and extract superclass refactoring.
SDMLib already contains a mechanism to transform code into a program graph. So this part was quite easy to implement. The method createModelFromSource in Listing 3 shows how SDMLib can be used to generate a model out of given java source code. Just the path to the project is necessary. 1 p u b l i c C l a s s M o d e l c r e a t e P r o g r a m m G r a p h ( S t r i n g p a t h T o P r o j e c t ) 2 { 3 4 r e t u r n r e f a c t o r e r . c r e a t e M o d e l F r o m S o u r c e ( p a t h T o P r o j e c t ) ; 5 6 }
Listing 3: Creating a object model from source code in a given package path The resulted program graph now must be transformed according to the intended refactoring. Our algorithm is split into two parts here. The first part validates that the refactoring can be applied on the given object structure. For example a pull up method refactoring requires, that all child classes contain the method with the right signature. This requirement is checked for a valid match. The second step executes the graph transformation for the refactoring. Figure 2 shows an example situation for the pull up method refactoring. The method of the first child that should be pulled up gets his class relation changed to the parent. Furthermore we remove the matching methods of all other kids from the graph.
To complete the last step, we decided to add property change listeners to all relevant members of the object model. These are the methods, classes and attributes, because the refactorings cause changes to them. Our aim was to trace the changes. After the refactoring, the generator of SDMLib applies the traced transformations to the source code. For example our so called ClazzSuperClassPropertyFileListener reacts on changes of the inheritance field of a class. If a new superclass is set, this listener saves an object of the ClazzSuperClazzPropertyFileChangeStep Class in a Queue. This queue contains all events with their relevant information. To synchronize model and code, we execute all source code transformations according to the previous done model transformations. In this example, the generator changes the extends clauses of the affected classes or generates a new superclass.
Overall this case was made for us, because SDMLib already had many features to help us creating a program graph and updating the appropriate java source code. Especially the parser and the generator of SDMLib helped to complete these tasks. Furthermore the resulting program graph fullfilled all our needs for the refactorings.
In Table 1, all execution times und the result of the given cases are presented. Except of one hidden case, our program succeeds in all tests. The one that fails contains a test where a method of two child classes should not be pulled up, because one of them is accessing a field, that the other one do not have. Our program fails here, because our tool does not analyse the semantic of method bodies. So there are no access edges in our program graph.
By writing additional test cases, we make sure to cover many other cases. The pull up refactoring ensures that the parent class is available. Furthermore we detect whether the pull up method or field is already defined in it, that it has childs and that all childs own the method or field with the right set of parameters. The create superclass refactorer also filters out the corner cases. It ensures that the superclass is not already existing. In addition, the refactoring fails with a response if not all chosen classes have the same superclass.
Time(s) Result 0 SUCCESS 0,003 SUCCESS 0,001 SUCCESS 0,005 SUCCESS 0,007 SUCCESS 0,003 SUCCESS 0,001 SUCCESS 0,005 SUCCESS 0,002 FAILURE 0,002 SUCCESS 0 SUCCESS 0 SUCCESS 0,002 SUCCESS 0,006 SUCCESS 0,001 SUCCESS
Overall this case was easy for SDMLib as SDMLib already had many features helping us creating a class model graph and updating the appropriate java source code. Especially the parser and the generator of SDMLib helped to complete these tasks. The SDMLib parser and code generator are designed for simplicity. Thus, by default we do NOT use an abstract syntax tree for method bodies. Due to our experience with code generation in the Fujaba project, abstract syntax trees are very large and detailed and it is very tedious to maintain and modify them. For usual class model creation and manipulation, the analysis of method body is not necessary. And code generation for method bodies is much easier done using a template based approach. However without the abstract syntax tree of method bodies, certain refactorings like renaming an attribute or a method cannot be done. For such cases, the parser of SDMLib needs to be extended and the code generation must be able to replace single name tokens. Still we believe that for the manipulation of the program text, a template based approach and the replacement of text fragments is much easier than manipulating an abstract syntax tree.