This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis
September 2006 (vol. 32 no. 9)
pp. 718-732
ASCII Text
x 
 
Xiaoxia Ren, Ophelia C. Chesley, Barbara G. Ryder, "Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis," IEEE Transactions on Software Engineering, vol. 32, no. 9, pp. 718-732, September, 2006.
 
 
BibTex
x
 
@article{ 10.1109/TSE.2006.90,
author = {Xiaoxia Ren and Ophelia C. Chesley and Barbara G. Ryder},
title = {Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis},
journal ={IEEE Transactions on Software Engineering},
volume = {32},
number = {9},
issn = {0098-5589},
year = {2006},
pages = {718-732},
doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2006.90},
publisher = {IEEE Computer Society},
address = {Los Alamitos, CA, USA},
}
 
 
RefWorks Procite/RefMan/Endnote
x 
 
TY - JOUR
JO - IEEE Transactions on Software Engineering
TI - Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis
IS - 9
SN - 0098-5589
SP718
EP732
EPD - 718-732
A1 - Xiaoxia Ren,
A1 - Ophelia C. Chesley,
A1 - Barbara G. Ryder,
PY - 2006
KW - Fault localization
KW - semantic change impact analysis
KW - edit change dependence
KW - regression testing
KW - intermediate versions of programs.
VL - 32
JA - IEEE Transactions on Software Engineering
ER -
 
During program maintenance, a programmer may make changes that enhance program functionality or fix bugs in code. Then, the programmer usually will run unit/regression tests to prevent invalidation of previously tested functionality. If a test fails unexpectedly, the programmer needs to explore the edit to find the failure-inducing changes for that test. Crisp uses results from Chianti, a tool that performs semantic change impact analysis [1], to allow the programmer to examine those parts of the edit that affect the failing test. Crisp then builds a compilable intermediate version of the program by adding a programmer-selected partial edit to the original code, augmenting the selection as necessary to ensure compilation. The programmer can reexecute the test on the intermediate version in order to locate the exact reasons for the failure by concentrating on the specific changes that were applied. In nine initial case studies on pairs of versions from two real Java programs, Daikon [2] and Eclipse jdt compiler [3], we were able to use Crisp to identify the failure-inducing changes for all but 1 of 68 failing tests. On average, 33 changes were found to affect each failing test (of the 67), but only 1-4 of these changes were found to be actually failure-inducing.

[1] X. Ren, F. Shah, F. Tip, B.G. Ryder, and O. Chesley, “Chianti: A Tool for Change Impact Analysis of Java Programs,” Proc. ACM SIGPLAN Conf. Object Oriented Programming Languages and Systems (OOPSLA '04), pp. 432-448, Oct. 2004.
[2] M.D. Ernst, J. Cockrell, W.G. Griswold, and D. Notkin, “Dynamically Discovering Likely Program Invariants to Support Program Evolution,” IEEE Trans. Software Eng., vol. 27, no. 2, pp. 1-25, Feb. 2001.
[3] “The Eclipse IDE,” http://www.eclipse.org, 2006.
[4] B.G. Ryder and F. Tip, “Change Impact for Object Oriented Programs,” Proc. ACM SIGPLAN/SIGSOFT Workshop Program Analysis and Software Testing (PASTE '01), June 2001.
[5] O. Chesley, X. Ren, and B.G. Ryder, “Crisp: A Debugging Tool for Java Programs,” Proc. Int'l Conf. Software Maintentance, pp. 401-410, Sept. 2005.
[6] “Junit, Testing Resources for Extreme Programming,” http:/www.junit.org/, 2006.
[7] J. Gosling, B. Joy, G. Steele, and G. Bracha, The Java Language Specification, second ed. Addison-Wesley, 2000.
[8] X. Ren, F. Shah, F. Tip, B.G. Ryder, O. Chesley, and J. Dolby, “Chianti: A Prototype Change Impact Analysis Tool for Java,” Technical Report DCS-TR-533, Rutgers Univ., Dept. of Computer Science, Sept. 2003.
[9] S.A. Bohner and R.S. Arnold, “An Introduction to Software Change Impact Analysis,” Software Change Impact Analysis, S.A.Bohner and R.S. Arnold, eds., pp. 1-26, IEEE CS Press, 1996.
[10] M. Lee, A.J. Offutt, and R.T. Alexander, “Algorithmic Analysis of the Impacts of Changes to Object-Oriented Software,” Proc. 34th Int'l Conf. Technology of Object-Oriented Languages and Systems (TOOLS USA '00), 2000.
[11] D.C. Kung, J. Gao, P. Hsia, F. Wen, Y. Toyoshima, and C. Chen, “Change Impact Identification in Object Oriented Software Maintenance,” Proc. Int'l Conf. Software Maintenance, pp. 202-211, 1994.
[12] P. Tonella, “Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis,” IEEE Trans. Software Eng., vol. 29, no. 6, pp. 495-509, 2003.
[13] J. Law and G. Rothermel, “Whole Program Path-Based Dynamic Impact Analysis,” Proc. Int'l Conf. Software Eng., pp. 308-318, 2003.
[14] A. Orso, T. Apiwattanapong, and M.J. Harrold, “Leveraging Field Data for Impact Analysis and Regression Testing,” Proc. European Software Eng. Conf. and ACM SIGSOFT Symp. Foundations of Software Eng. (ESEC/FSE '03), Sept. 2003.
[15] F. Tip, “A Survey of Program Slicing Techniques,” J. Programming Languages, vol. 3, no. 3, pp. 121-189, 1995.
[16] A. Orso, T. Apiwattanapong, J. Law, G. Rothermel, and M.J. Harrold, “An Empirical Comparison of Dynamic Impact Analysis Algorithms,” Proc. Int'l Conf. Software Eng. (ICSE'04), pp. 491-500, 2004.
[17] V. Rajlich and P. Gosavi, “Incremental Change in Object-Oriented Programming,” IEEE Software, pp. 2-9, July/Aug. 2004.
[18] S. Gwizdala, Y. Jiang, and V. Rajlich, “Jtracker—A Tool for Change Propagation in Java,” Proc. Seventh European Conf. Software Maintenance and Reeng. (CVMR '03), pp. 223-229, 2003.
[19] J. Buckner, J. Buchta, P. Maksym, and V. Rajlich, “Jripples: A Tool for Program Comprehension during Incremental Change,” Proc. 13th IEEE Int'l Workshop Program Comprehension (IWPC '05), pp.149-152, May 2005.
[20] J. Gustavsson, “A Classification of Unanticipated Runtime Software Changes in Java,” Proc. 19th IEEE Int'l Conf. Software Maintenance (ICSM '03), pp. 4-12, 2003.
[21] A. Zeller, “Yesterday My Program Worked. Today, It Does Not. Why?” Proc. Seventh European Software Eng. Conf./Seventh ACM SIGSOFT Symp. Foundations of Software Eng. (ESEC/FSE '99), pp.253-267, 1999.
[22] J. Lyle and M. Weiser, “Automatic Bug Location by Program Slicing,” Proc. Second Int'l Conf. Computers and Applications, pp.877-883, 1987.
[23] R.A. DeMillo, H. Pan, and E.H. Spafford, “Critical Slicing for Software Fault Localization,” Proc. 1996 ACM SIGSOFT Int'l Symp. Software Testing and Analysis (ISSTA '96), pp. 121-134, 1996.
[24] P. Bunus and P. Fritzson, “Semi-Automatic Fault Localization and Behavior Verification for Physical System Simulation Models,” Proc. 18th IEEE Int'l Conf. Automated Software Eng., pp. 253-258, Oct. 2003.
[25] N. Gupta, H. He, X. Zhang, and R. Gupta, “Locating Faulty Code Using Failure-Inducing Chops,” Proc. Int'l Conf. Automated Software Eng., pp. 263-272, 2005.
[26] S.I. Feldman, “Make—A Program for Maintaining Computer Programs,” Software—Practice and Experience, vol. 9, no. 4, pp. 255-65, 1979.
[27] C. Chambers, J. Dean, and D. Grove, “A Framework for Selective Recompilation in the Presence of Complex Intermodule Dependencies,” Proc. 17th Int' Conf. Software Eng. (ICSE '95), pp. 221-230, 1995.
[28] R. Hood, K. Kennedy, and H.A. Muller, “Efficient Recompilation of Module Interfaces in a Software Development Environment,” Proc. Second ACM SIGSOFT/SIGPLAN Software Eng. Symp. Practical Software Development Environments (SDE 2), pp. 180-189, 1987.
[29] W.F. Tichy, “Smart Recompilation,” ACM Trans. Programming Languages and Systems, vol. 8, no. 3, pp. 273-291, 1986.
[30] R. Adams, W.F. Tichy, and A. Weinert, “The Cost of Selective Recompilation and Environment Processing,” ACM Trans. Software Eng. Methodology, vol. 3, no. 1, pp. 3-28, 1994.
[31] M. Burke and L. Torczon, “Interprocedural Optimization: Eliminating Unnecessary Recompilation,” ACM Trans. Programming Languages and Systems, vol. 15, no. 3, pp. 367-399, 1993.
[32] M. Dmitriev, “Language-Specific Make Technology for the Java Programming Language,” Proc. 17th ACM SIGPLAN Conf. Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '02), pp. 373-385, 2002.
[33] M. Stoerzer, B.G. Ryder, X. Ren, and F. Tip, “Find Failure-Inducing Changes Using Change Classification,” Technical Report DCS-TR-05-582, Dept. of Computer Science, Rutgers Univ., Sept. 2005.

Index Terms:
Fault localization, semantic change impact analysis, edit change dependence, regression testing, intermediate versions of programs.
Citation:
Xiaoxia Ren, Ophelia C. Chesley, Barbara G. Ryder, "Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis," IEEE Transactions on Software Engineering, vol. 32, no. 9, pp. 718-732, Sept. 2006, doi:10.1109/TSE.2006.90
Usage of this product signifies your acceptance of the Terms of Use.