Shinpei Hayashi, Katsuyuki Sekine,and Motoshi Saeki
Department of Computer Science,Tokyo Institute of Technology, Japan
iFL: An InteractiveEnvironment for Understanding
Feature Implementations
ICSM 2010 ERA14 Sep., 2010 TOKYO INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
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
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
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 understandthe feature
converting input timestrings to schedule
objects…
Reading these methodsfor understanding 4
A newmaintainer
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
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
Selection and understanding of code fragments
Query Input
Feature location(calculating scores)
schedule Search
1st: ScheduleManager.addSchedule()2nd: EditSchedule.inputCheck()…
Updatingqueries
Relevancefeedback
(addition of hints)
Added two feedback processesOur Solution: Feedbacks
Finish if the user judges that he/shehas read all the necessary code fragments 7
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 resultThesaurus
8
Dependency
Code fragmentwith 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
propagationby dependencies
9
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
WordNet
Exec. Traces /dependencies
Syntacticinformation
SynonymInfo.
Implemented!
10
Supporting Tool: iFL
11
How iFL Works
Inputting Query
12
How iFL Works
Calculating scoresEvaluated code fragments
with their scores
13
How iFL WorksAssociated method will be shown
in the code editorwhen user selects a code fragment
14
How iFL Works
Calculating scores again
15
Adding hints
How iFL Works
Scoresupdated
16
How iFL Works
Codereading
FL
17
A user (familiar with Java and iFL) actually understood feature implementations
Preliminary Evaluation
# CorrectEvents
# FLexecution
Interactivecosts
Non-interactive
costsΔ Costs Overheads # Query
updating
S1 19 5 20 31 0.92 1 2S2 7 5 8 10 0.67 1 1S3 1 2 2 2 0.00 1 0S4 10 6 10 13 1.00 0 2S5 3 6 6 15 0.75 3 2J1 10 4 20 156 0.93 10 2J2 4 6 18 173 0.92 14 3
5 change requirements and related featuresfrom Sched(home-grown, small-sized)
2 change requirements and related featuresfrom JDraw(open-source, medium-sized)
18
Evaluation Criteria
# CorrectEvents
# FLexecution
Interactivecosts
Non-interactive
costsΔ Costs Overheads # Query
updating
S1 19 5 20 31 0.92 1 2S2 7 5 8 10 0.67 1 1S3 1 2 2 2 0.00 1 0S4 10 6 10 13 1.00 0 2S5 3 6 6 15 0.75 3 2J1 10 4 20 156 0.93 10 2J2 4 6 18 173 0.92 14 3
# selected, but unnecessary code fragmentsReduced ratio of overheads
between interactive and non-interactive approaches
19
# CorrectEvents
# FLexecution
Interactivecosts
Non-interactive
costsΔ Costs Overheads # Query
updating
S1 19 5 20 31 0.92 1 2S2 7 5 8 10 0.67 1 1S3 1 2 2 2 0.00 1 0S4 10 6 10 13 1.00 0 2S5 3 6 6 15 0.75 3 2J1 10 4 20 156 0.93 10 2J2 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
# CorrectEvents
# FLexecution
Interactivecosts
Non-interactive
costsΔ Costs Overheads # Query
updating
S1 19 5 20 31 0.92 1 2S2 7 5 8 10 0.67 1 1S3 1 2 2 2 0.00 1 0S4 10 6 10 13 1.00 0 2S5 3 6 6 15 0.75 3 2J1 10 4 20 156 0.93 10 2J2 4 6 18 173 0.92 14 3
Small overheads− Sched: 1.2, JDraw: 12 in average
Evaluation Results
21
# CorrectEvents
# FLexecution
Interactivecosts
Non-interactive
costsΔ Costs Overheads # Query
updating
S1 19 5 20 31 0.92 1 2S2 7 5 8 10 0.67 1 1S3 1 2 2 2 0.00 1 0S4 10 6 10 13 1.00 0 2S5 3 6 6 15 0.75 3 2J1 10 4 20 156 0.93 10 2J2 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
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
additional slides
Sourcecode
Execution trace/ dependencies
Dynamic analysis
Methods withtheir scores
Static analysis
EvaluatingeventsTest
case
Queryschedule
Based on search-based FL Use of static + dynamic analyses
The FL Approach
Events withtheir scores(FL result)
Hints
25
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 queries26
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
Evaluating Methods Highly scored events are:
− executing methods having high basic scores− Close to highly scored events
Events Methods BS Scoree1 loadSchedule() 20 52.2e2 initWindow() 0 18.7e3 createSchedule() 21 38.7e4 Time() 20 66.0e5 ScheduleModel() 31 42.6e6 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
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 Ranke1 loadSchedule() 52.2 2e2 initWindow() 18.7 6e3 createSchedule() 38.7 4e4 Time() 66.0 1e5 ScheduleModel() 42.6 3e6 updateList() 19.0 5
Extracted code fragments
29
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 2e2 initWindow() 0 18.7 6e3 createSchedule() 21 38.7 96.4 4 1e4 Time() 20 46.5 66.0 70.2 1 3e5 ScheduleModel() 31 42.6 51.0 3 4e6 updateList() 2 19.0 5
30