Advanced Science and Technology Letters Vol.99 (ITCS 2015), pp.31-34 http://dx.doi.org/10.14257/astl.2015.99.08
A Rule-Based Method to Trace Change History After Refactoring Seonghye Yoon1, 2, Chaeyoung Lee3, Sooyong Park2, Mansoo Hwang4 School of Computer Science, Kookmin University, Seoul, South Korea 2 Dept.of Comp. Sci. & Eng., Sogang University, Seoul, South Korea 3 Inst. of Convergence Techonology Service Laboratory, KT, Seoul, South Korea 4 School of IT Convergence Eng., Shinhan University, Gyeonggi, South Korea
[email protected],
[email protected],
[email protected],
[email protected] 1
Abstract. It is important the comprehension of source code changing for effective software maintenance. For this, the version control system provides the management of the source code which can trace the change history and reason. Unfortunately, there is a limit in existing version control systems which is impossible to trace the history of changes in the structural change. The previous researches, which overcome this, are the operation-based method or the rule-based method. However, it has many problems with excessive recording or not sufficient coverage. In this paper, we propose the rule-based tracing method of change history which is based on M. Fowler’s refactoring techniques. Even though it is impossible to trace through refactoring, our proposed method aims for extracting the origin function of the tracing function. Keywords: refactoring, structural change, trace change history
1
Introduction
Software has been constantly evolving and growing in size and complexity. Software maintenance is necessary for this reason [1]. The one of the most important activities is to comprehend source code for maintenance [2], and it is a complicated activity which spends about 50% of the software maintenance cost [3]. Currently, the software project makes use of a version control system (e.g. CVS, SVN, etc.) for supporting this. Therefore, a maintainer can trace reason owing to changed information in source code, like modifier, modified date, changed files, and changed lines with saving. Regrettably, up to now the existing version control systems have not been very successful to trace change history. The reason of not accessible history is from the structural change, such as rename or move function. The structural changes make up 35.6% [4] of the total changes. It is hard for finding origin functions without a maintainer’s analysis about the change if there is disconnected history as structural change. This reason is that the existing version system supports a diff method which is based on a line by line.
ISSN: 2287-1233 ASTL Copyright © 2015 SERSC
Advanced Science and Technology Letters Vol.99 (ITCS 2015)
To overcome this problem, there has been considerable work on capturing structural change. [5][6] are proposed operation-based method. The researches have limits: 1) a particular client tool is supported operation recordings. 2) excessive or missing record. [7][8][9] are proposed rule-based method. The researches only adapt a few refactoring techniques. In this paper, we propose an improved rule-based tracing method without the constraints of the development environment. To increase the refactoring technique coverage, the M. Fowler’s refactoring techniques [1] are classified traceable or nontraceable refactoring techniques at the function level. The non-traceable refactoring techniques are categorized four-rules in consideration of the pattern of change items. The result of comparing the nodes of the AST(Abstartc Syntax Tree)s, which are created by the revisions which are at before and after the disconnected tracing point, is matched with pre-defined rules. Then, the origin function is identified using similarity by the matched rule. The remainder of this paper is as follows: Chapter 2 describes the proposed rulebased method for tracing origin function, and Chapter 3 summarizes the paper with directions for our future research.
2
A rule-based method to trace origin function
The proposed method is fourfold to find the origin function of the non-tracking a function, as depicted in Fig. 1. The fourfold are: 1) inquiring into the change history of disconnected tracing function, 2) extracting the change item between the disconnected tracing revision and previous revision, 3) matching the pre-defined rules of refactoring type, 4) select of the origin function. 2.1
Inquiry into change history of the tracing function
The first step of our proposed process is automatically to find the revision which is broken trace. The last revision exist the function, which we want to trace, is searched in the source code repository. We select the inquired revision (revision N) and previous revision (revision N-1) as the input of the next step. 2.2
Extract of change items
After comparing with the selected revisions, this step is extraction processing for changed item of source code. We create ASTs of classes which compared with the revision N and the revision N-1 among changed classes, and extract changed item which compares with the ASTs is not included in other classes and AST is included by class with the tracing function. It means that changed item is the combination of
32
Copyright © 2015 SERSC
Advanced Science and Technology Letters Vol.99 (ITCS 2015)
Fig. 1. The overall process
source code elements, such as class, method, statement, and the status change, such as add, update, delete. 2.3
Match the rules of refactoring type
In this step, we select refactoring types by adapting predefined-rules. M.Flower’s seventy refactoring techniques that take the pre-defined rules into consideration. In the techniques, we select twenty refactoring techniques when it occurs structural change in function level. For instance, we remove the technique that there is no structural change when Remove Parameter, Replace Error Code with Exception is refactoring. The changed items are extracted through the node comparison of creating AST about before-and-after code about the selected techniques. The analyzing result categorizes four types which are Rename, Move, Merge, Extract. The changed items which were extracted in 2.2 matches pre-defined rules and selects a potential refactoring type. This step could be matched by more than two refactoring types in case. Origin function is selected in every matching refactoring type using similarity mechanism. The similarity mechanism is possible to adopt variously application. Even though there is a similar pattern of the changed items, it can't regard as the same origin function if there is low similarity between matching items. 2.4
Select of the origin function using similarity
Finally, we select high similarity function among the candidate origin functions. After that, 2.1 executes from relative functions again. The selected origin function becomes an input value of tracing function. This process repeats until origin function will not extract in 2.4.
Copyright © 2015 SERSC
33
Advanced Science and Technology Letters Vol.99 (ITCS 2015)
3
Conclusion
The purpose of this research supports to protect broken tracing for the change history of source code during the inquiry process because of structural change for efficient software maintenance. This approach is the method which extracts origin function according to matching between change items and pre-defined rules that are analyzed frequently using refactoring. Also, we filter the cases which are not refactoring, but a similar pattern by functional change through verifying function similarity. The proposed method makes a contribution through improving coverage of the refactoring techniques and excluding constraints of a development environment. The effectiveness of this approach, however, remains to be further verified through additional case studies. Forthcoming research is to be further focused on applying the method to open source system.
References 1. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA (1999) 2. Kim, M., Notkin, D., Grossman, D., Wilson, G.: Identifying and summarizing systematic code changes via rule inference. Software Engineering, IEEE Transactions on 39(1), 45--62 (2013) 3. Chikofsky, E., Cross J.H., I.: Reverse engineering and design recovery: a taxonomy. Software, IEEE 7(1), 13--17 (1990) 4. Kim, M., Notkin, D.: Discovering and representing systematic code changes. In: Proceedings of the 31st International Conference on Software Engineering, ICSE '09, pp. 309--319. IEEE Computer Society, Washington, DC, USA (2009) 5. Soetens, Q., Perez, J., Demeyer, S.: An initial investigation into change-based reconstruction of oss-refactorings. In: Software Maintenance (ICSM), 2013 29th IEEE International Conference on, pp. 384--387 (2013) 6. Robbes, R.: Mining a change-based software repository. In: Proceedings of the Fourth International Workshop on Mining Software Repositories, MSR '07, pp. 15--23. IEEE Computer Society, Washington, DC, USA (2007) 7. Godfrey, M., Zou, L.: Using origin analysis to detect merging and splitting of source code entities. Software Engineering, IEEE Transactions on 31(2), 166--181 (2005) 8. Kim, S., Pan, K., Whitehead Jr., E.J.: When functions change their names: Automatic detection of origin relationships. In: Proceedings of the 12th Working Conference on Reverse Engineering, WCRE '05, pp. 143--152. IEEE Computer Society, Washington, DC, USA (2005) 9. Antoniol, G., Di Penta, M., Merlo, E.: An automatic approach to identify class evolution discontinuities. In: Software Evolution, 2004. Proceedings. 7th International Workshop on Principles of, pp. 31--40 (2004)
34
Copyright © 2015 SERSC
