ACM Home Page
Please provide us with feedback. Feedback
Filtering out methods you wish you hadn't navigated
Full text PdfPdf (513 KB)
Source OOPSLA workshop on eclipse technology eXchange archive
Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange table of contents
Montreal, Quebec, Canada
Pages 11-15  
Year of Publication: 2007
ISBN:978-1-60558-015-9
Authors
Annie T. T. Ying  IBM Watson Research Center
Peri L. Tarr  IBM Watson Research Center
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 1,   Downloads (12 Months): 19,   Citation Count: 0
Additional Information:

abstract   references   collaborative colleagues  

Tools and Actions: Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1328279.1328282
What is a DOI?

ABSTRACT

The navigation of structural dependencies (e.g., method invocations) when a developer performs a change task is an effective strategy in program investigation. Several existing approaches have addressed the problem of finding program elements relevant to a task by using structural dependencies. These approaches provide different levels of benefits: limiting the amount of information returned, providing calling context, and providing global information. Aiming to incorporate these three benefits simultaneously, we propose an approach--called call graph filtering--to help developers narrow down the methods relevant to a change task. Our call graph filtering approach uses heuristics to highlight methods that are likely relevant to a change task on a call graph. The size of the set of relevant methods is reduced by our filtering heuristics, while global information and the calling context are provided by the call graph. We have performed two preliminary studies: a user study on identifying methods relevant to the understanding of JUnit tests on a small system, and an empirical study on how our results can help a developer perform a program navigation task with the Eclipse framework. The studies show that our approach can provide useful results: quantitatively in terms of size of the results, precision, and recall; and qualitatively in terms of finding non-trivial control-flow and being able to direct developer to the code of interest.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
JUnit: http://www.junit.org/index.htm.
 
2
WALA: http://wala.sourceforge.net/.
 
3
ATM application: http://www.math-cs.gordon.edu/courses/cs211/atmexample/.
4
 
5
6
 
7
P. Marschall. Detecting the methods under test in java. Bachelor thesis, 2005.
 
8
H. A. Müller and K. Klashinsky. Rigi - a system for programming-in-the-large. In ICSE, 1988.
9
10
 
11
12
 
13
M. Störzer, B. G. Ryder, X. Ren, and F. Tip. Finding failure-inducing changes in java programs using change classification. In FSE, 2006.
 
14
Collaborative Colleagues:
Annie T. T. Ying: colleagues
Peri L. Tarr: colleagues