Your SlideShare is downloading. ×
0
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
iFL: An Interactive Environment for Understanding Feature Implementations
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

iFL: An Interactive Environment for Understanding Feature Implementations

468

Published on

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

No Downloads
Views
Total Views
468
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
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. 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.  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.  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. 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.  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.  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. 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.  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. 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. 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. Supporting Tool: iFL 11
  • 12. How iFL Works Inputting Query 12
  • 13. How iFL Works Calculating scoresEvaluated code fragments with their scores 13
  • 14. How iFL Works Associated method will be shown in the code editor when user selects a code fragment 14
  • 15. How iFL Works Calculating scores again 15 Adding hints
  • 16. How iFL Works Scores updated 16
  • 17. How iFL Works Code reading FL 17
  • 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. 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. # 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. # 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. # 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.  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. additional slides
  • 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. 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. 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. 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. 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. 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

×