Your SlideShare is downloading. ×
Detecting Occurrences of Refactoring with Heuristic Search
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Detecting Occurrences of Refactoring with Heuristic Search

2,605
views

Published on

Presented at APSEC 2008 …

Presented at APSEC 2008
http://dx.doi.org/10.1109/APSEC.2008.9

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,605
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 2008. 12. 5 TOKYO INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE APSEC 2008 Detecting Occurrences of Refactoring with Heuristic Search Shinpei Hayashi Yasuyuki Tsuda Motoshi Saeki Department of Computer Science Tokyo Institute of Technology Japan
  • 2. Abstract  Detecting Occurrences of Refactoring − Detecting where to and what kinds of refactoring were performed between two ver. of programs − From version archives such as CVS/Subversion  with Heuristic Search − We use a graph search technique for detecting impure refactorings  Results − (Semi-)automated tools have been developed − We have a simple case study
  • 3. Background  It is important to reduce the cost for understanding the changes of a program, which is continually modified I have to follow the changes of L... What do the changes mean? ver. 123 modify ver. 124 use Program L (a library) FOSS project Program S (FOSS: Free/Open Source Software) 3
  • 4. Aim  Categorization of modifications is useful − Detecting refactorings between two versions of a program The changes are: Extract Method + ver. 123 Move Method + α! modify ver. 124 use Program L (a library) FOSS project Program S (FOSS: Free/Open Source Software) 4
  • 5. Detecting Refactorings  Related work − with software metrics [Demeyer 2000] − by checking pre/post-conditions of source code properties [Weißgerber 2006]  Key issue − detecting impure refactorings [Görg 2005] • refactoring + refactoring • refactoring + other modifications 5
  • 6. Motivating Scenario  Example from Fowler’s book [Fowler 1999] Extract Move n0 Method n1 Method nm Customer Customer Customer statement() statement() statement() getCharge(Rental) Rental Rental Rental getCharge() 6
  • 7. Scenario: Lost of States Version Archive Rold Rnew lose commit intermediate state commit Extract Move n0 Method n1 Method n2 Customer Customer Customer statement() statement() statement() getCharge(Rental) Rental Rental Rental getCharge() 7
  • 8. Scenario: Diffs between revs  Hard to detect refactorings via mixed differences − Considering intermediate states is required Version Archive Rold Rnew Customer 1. Some code fragments in Customer statement() Customer#statement is removed statement() 2. a method invocation to Rental#getCharge is added to Rental Rental statement getCharge() 3. Rental#getCharge is added Mixed differences 8
  • 9. Our Approach  Generating intermediate states by actually applying refactorings to the program  Finding an appropriate path from Rold (= n0) to Rnew (= nm) by a graph search technique States (nodes): versions of the program Transitions (edges): refactoring operations n0 nm Initial state Final state (Rold) (Rnew) 9
  • 10. Procedure 1. Find likely refactorings 2. Evaluate the distance to the nm 3. Apply the best one and generate new state 6 n0 4 nm Initial state Final state (Rold) (Rnew) 8 10
  • 11. Procedure 1. Find likely refactorings 2. Evaluate the distance to the nm 3. Apply the best one and generate new state Terminate if the new state almost equals to Rnew 6 3 n0 2 nm Initial state Final state (Rold) (Rnew) 8 3 11
  • 12. Efficient Search 1. How to find candidates of refactorings? − They should be similar to the changes for nm 2. How to evaluate them? − The best one should generate new state closer to nm  We use structural differences between two states 6 3 n0 2 nm Initial state Final state (Rold) (Rnew) 8 3 12
  • 13. Structural Differences  Calculated by comparing two AST − 4 types: add, remove, change, move public class Customer { public class Customer { int id; int customerID; String name; String name; int[] phoneNum; } } change(Customer, the name customerID, the name id) add(FieldDeclaration int[] phoneNum, Customer) … 13
  • 14. Find New Refactorings  By matching between diffs. (D) and modifications representing a refactoring operation (R) − if a subset of D matches a subset of R, the refactoring operation is expanded. − Matching likelihood: (# of matched modifications) / (# of R) The differences (D): nm remove(Block, Customer#statement) add(MethodInvocation, Rental#statement) change(Rental, the name “n1”, the name“n2”) … Extract Method (R): remove(Block, ClassA#method1) Matching likelihood: add(MethodDeclaration, ClassA) 0.5 (1/2) 14
  • 15. Evaluation  Using f(n, o) = g(n) + h(n) / α(o) − g(n): # of applied refactorings for obtaining n − h(n): the size of differences between n and nm − α(o): likelihood of o  f(n2, o6) = 2 + 3 / (1/2) = 8 o6 α(o6) = 1/2 n2 o1 g(n2) = 2 o4 h(n2) = 3 n0 nm Initial State o2 n1 Goal State (Pold) o3 o5 (Pnew) 15
  • 16. Supporting Tools  Expanding and evaluating candidates of refactorings with REUSAR (implemented) − Input: Two versions of Java source code − Output: Candidates of refactorings with priority − Calculating differences with XMLdiff (an existing tool)  Applying refactorings by Eclipse − Checking pre/post-conditions − Modifying source code 16
  • 17. Case Study  Applying our technique to an existing version archive, REUSAR (supporting tool in this study) 1. Rename Method R1796 2. Remove Parameter R1799 DistanceCalculator DistanceCalculator calculateDistance(List<Diff>) calcDistance() 17
  • 18. Case Study: Result R1796 R1799 4 Rename Method n1 4 Remove Parameter n0 4 Remove n2 Parameter 7 Extract Method 8 Extract Method  Our technique is effective − It can correctly detect impure refactorings which were actually performed − Prioritizing the candidates reduces # of applications of refactoring operations 18
  • 19. Conclusion  Summary − Detecting refactorings by a graph search, based on heuristics with structural differences between two programs − Our technique can detect impure refactorings  Future Work − Tool integration − Evaluation: larger-scale case study 19