iFL: An Interactive Environment for Understanding Feature Implementations

677 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
677
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

iFL: An Interactive Environment for Understanding Feature Implementations

  1. 1. Shinpei Hayashi, Katsuyuki Sekine, and Motoshi Saeki Department of Computer Science, Tokyo Institute of Technology, Japan iFL: An Interactive Environment for Understanding Feature Implementations ICSM 2010 ERA 14 Sep., 2010 TOKYO INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE
  2. 2.  We have developed iFL − An environment for program understanding − Interactively supports the understanding of feature implementation using a feature location technique − Can reduce understanding costs Abstract 2
  3. 3.  Program understanding is costly − Extending/fixing existing features Understanding the implementation of target feature is necessary − Dominant of maintenance costs [Vestdam 04]  Our focus: feature/concept location (FL) − Locating/extracting code fragments which implement the given feature/concept Background [Vestdam 04]: “Maintaining Program Understanding – Issues, Tools, and Future Directions”, Nordic Journal of Computing, 2004. 3
  4. 4. FL Example (Search-based) …… public Time(String hour, …) { ...... } … public void createSchedule() { ...... } public void updateSchedule(…) { …… scheduler Source Code schedule time Search Feature Location (Search-based approach) FL I want to understand the feature converting input time strings to schedule objects… Reading these methods for understanding 4 A new maintainer
  5. 5.  Constructing appropriate queries requires rich knowledge for the implementation − Times: time, date, hour/minute/second − Images: image, picture, figure  Developers in practice use several keywords for FL through trial and error Problem 1: How to Find Appropriate Queries? Search FL How?? 5
  6. 6.  Complete (Optimum) FL results are rare − Accuracy of used FL techniques − Individual difference in appropriate code Problem 2: How to Fix FL Results? schedule time Search FL An FL result (code fragments) Optimum result (Code fragments that should be understood) Unnecessary code (false positives) Necessary code (false negatives) 6
  7. 7. Selection and understanding of code fragments Query Input Feature location (calculating scores) schedule Search 1st: ScheduleManager.addSchedule() 2nd: EditSchedule.inputCheck() … Updating queries Relevance feedback (addition of hints)  Added two feedback processes Our Solution: Feedbacks Finish if the user judges that he/she has read all the necessary code fragments 7
  8. 8.  Wide query for initial FL − By expanding queries to its synonyms  Narrow query for subsequent FLs − By using concrete identifies in source code Query Expansion Expand • schedule • agenda • plan schedule* date* Search 1st FL public void createSchedule() { … String hour = … Time time = new Time(hour, …); … } schedule time Search 2nd FL • list • time • date A code fragment in a FL result Thesaurus 8
  9. 9. Dependency Code fragment with its score  Improving FL results by users feedback − Adding a hint when the selected code fragments is relevant or irrelevant to the feature − Feedbacks are propagated into other fragments using dependencies Relevance Feedback i th result of FL 1 2 9 6 : relevant 1 8 11 6 (i+1) th result of FL propagation by dependencies 9
  10. 10. Supporting Tool: iFL  Implemented as an Eclipse plug-in − For static analysis: Eclipse JDT − For dynamic analysis: Reticella [Noda 09] − For a thesaurus: WordNet JDT Reticella iFL- core Eclipse Word Net Exec. Traces / dependencies Syntactic information Synonym Info. Implemented! 10
  11. 11. Supporting Tool: iFL 11
  12. 12. How iFL Works Inputting Query 12
  13. 13. How iFL Works Calculating scoresEvaluated code fragments with their scores 13
  14. 14. How iFL Works Associated method will be shown in the code editor when user selects a code fragment 14
  15. 15. How iFL Works Calculating scores again 15 Adding hints
  16. 16. How iFL Works Scores updated 16
  17. 17. How iFL Works Code reading FL 17
  18. 18.  A user (familiar with Java and iFL) actually understood feature implementations Preliminary Evaluation # Correct Events # FL execution Interactive costs Non- interactive costs Δ Costs Overheads # Query updating S1 19 5 20 31 0.92 1 2 S2 7 5 8 10 0.67 1 1 S3 1 2 2 2 0.00 1 0 S4 10 6 10 13 1.00 0 2 S5 3 6 6 15 0.75 3 2 J1 10 4 20 156 0.93 10 2 J2 4 6 18 173 0.92 14 3 5 change requirements and related features from Sched (home-grown, small-sized) 2 change requirements and related features from JDraw (open-source, medium-sized) 18
  19. 19. Evaluation Criteria # Correct Events # FL execution Interactive costs Non- interactive costs Δ Costs Overheads # Query updating S1 19 5 20 31 0.92 1 2 S2 7 5 8 10 0.67 1 1 S3 1 2 2 2 0.00 1 0 S4 10 6 10 13 1.00 0 2 S5 3 6 6 15 0.75 3 2 J1 10 4 20 156 0.93 10 2 J2 4 6 18 173 0.92 14 3 # selected, but unnecessary code fragments Reduced ratio of overheads between interactive and non-interactive approaches 19
  20. 20. # Correct Events # FL execution Interactive costs Non- interactive costs Δ Costs Overheads # Query updating S1 19 5 20 31 0.92 1 2 S2 7 5 8 10 0.67 1 1 S3 1 2 2 2 0.00 1 0 S4 10 6 10 13 1.00 0 2 S5 3 6 6 15 0.75 3 2 J1 10 4 20 156 0.93 10 2 J2 4 6 18 173 0.92 14 3  Reduced costs for 6 out of 7 cases − Especially, reduced 90% of costs for 4 cases Evaluation Results 20
  21. 21. # Correct Events # FL execution Interactive costs Non- interactive costs Δ Costs Overheads # Query updating S1 19 5 20 31 0.92 1 2 S2 7 5 8 10 0.67 1 1 S3 1 2 2 2 0.00 1 0 S4 10 6 10 13 1.00 0 2 S5 3 6 6 15 0.75 3 2 J1 10 4 20 156 0.93 10 2 J2 4 6 18 173 0.92 14 3  Small overheads − Sched: 1.2, JDraw: 12 in average Evaluation Results 21
  22. 22. # Correct Events # FL execution Interactive costs Non- interactive costs Δ Costs Overheads # Query updating S1 19 5 20 31 0.92 1 2 S2 7 5 8 10 0.67 1 1 S3 1 2 2 2 0.00 1 0 S4 10 6 10 13 1.00 0 2 S5 3 6 6 15 0.75 3 2 J1 10 4 20 156 0.93 10 2 J2 4 6 18 173 0.92 14 3  No effect in S3 − Because non-interactive approach is sufficient for understanding − Not because of the fault in interactive approach Evaluation Results 22
  23. 23.  Summary − We developed iFL: interactively supporting the understanding of feature implementation using FL − iFL can reduce understanding costs in 6 out of 7 cases  Future Work − Evaluation++: on larger-scale projects − Feedback++: for more efficient relevance feedback • Observing code browsing activities on IDE Conclusion 23
  24. 24. additional slides
  25. 25. Source code Execution trace / dependencies Dynamic analysis Methods with their scores Static analysis Evaluating eventsTest case Query schedule  Based on search-based FL  Use of static + dynamic analyses The FL Approach Events with their scores (FL result) Hints   25
  26. 26. Static Analysis: eval. methods  Matching queries to identifiers public void createSchedule() { … String hour = … Time time = new Time(hour, …); … } 20 for method names 1 for local variables • schedule • agenda • time • date Schedule time Search Thesaurus The basic score (BS) of createSchedule: 21 Expand Expanded queries 26
  27. 27. Dynamic Analysis  Extracting execution traces and their dependencies by executing source code with a test case e1: loadSchedule() e2: initWindow() e3: createSchedule() e4: Time() e5: ScheduleModel() e6: updateList() e1 e3 e6e2 e4 e5 Dependencies (Method invocation relations)Execution trace 27
  28. 28. Evaluating Methods  Highly scored events are: − executing methods having high basic scores − Close to highly scored events Events Methods BS Score e1 loadSchedule() 20 52.2 e2 initWindow() 0 18.7 e3 createSchedule() 21 38.7 e4 Time() 20 66.0 e5 ScheduleModel() 31 42.6 e6 updateList() 2 19.0 e1 e3 e6e2 e4 e5 52.2 (20) 18.7 (0) 19.0 (2) 42.6 (31) 66.0 (20) 38.7 (21) 28
  29. 29. Selection and Understanding  Selecting highly ranked events − Extracting associated code fragment (method body) and reading it to understand public Time(String hour, …) { … String hour = … String minute = … … } Events Methods Scores Rank e1 loadSchedule() 52.2 2 e2 initWindow() 18.7 6 e3 createSchedule() 38.7 4 e4 Time() 66.0 1 e5 ScheduleModel() 42.6 3 e6 updateList() 19.0 5 Extracted code fragments 29
  30. 30. Relevance Feedback  User reads the selected code fragments, and adds hints − Relevant (): maximum basic score − Irrelevant to the feature (): score becomes 0 Events Methods Hints Basic scores Scores Ranks e1 loadSchedule() 20 52.2 77.6 2 e2 initWindow() 0 18.7 6 e3 createSchedule() 21 38.7 96.4 4 1 e4 Time()  20 46.5 66.0 70.2 1 3 e5 ScheduleModel() 31 42.6 51.0 3 4 e6 updateList() 2 19.0 5 30

×