This paper reports on the design and implementation of Chianti, a change impact analysis tool for Java that is implemented in the context of the Eclipse environment. Chianti analyzes two versions of an application and decomposes their difference into a set of atomic changes. Change impact is then reported in terms of affected (regression or unit) tests whose execution behavior may have been modified by the applied changes. For each affected test, Chianti also determines a set of affecting changes that were responsible for the test’s modified behavior. This latter step of isolating the changes that induce the failure of one specific test from those changes that only affect other tests can be used as a debugging technique in situations where a test fails unexpectedly after a long editing session. We evaluated Chianti on a year (2002) of CVS data from M. Ernst’s Daikon system, and found that, on average, 52% of Daikon’s unit tests are affected. Furthermore, each affected unit test, on average, is affected by only 3.95 % of the atomic changes. These findings suggest that our change impact analysis is a promising technique for assisting developers with program understanding and debugging.

Impact analysis --- determining the potential effects of changes on a software system --- plays an important role in software engineering tasks such as maintenance, regression testing, and debugging. In previous work, two new dynamic impact analysis techniques, CoverageImpact and PathImpact, were presented. These techniques perform impact analysis based on data gathered about program behavior relative to specific inputs, such as inputs gathered from field data, operational profile data, or test-suite executions. Due to various characteristics of the algorithms they employ, CoverageImpact and PathImpact are expected to differ in terms of cost and precision; however, there have been no studies to date examining the extent to which such differences may emerge in practice. Since cost-precision tradeoffs may play an important role in technique selection and further research, we wished to examine these tradeoffs. We therefore designed and performed an empirical study, comparing the execution and space costs of the techniques, as well as the precisions of the impact analysis results that they report. This paper presents the results of this study.

Successful software systems tend to be long lived and evolve over time as requirements change and faults are detected. The number of times a system is updated and re-deployed may be in the hundreds, or even thousands. Re-validation of an updated system, before it is released, is a critical component of the software evolution process. This step ensures that the changes made to the software have their intended effects, and that no unintended behaviors were introduced. Given the size and complexity of modern software systems, re-validation is generally costly and time consuming. Characterizing the differences between software versions can help focus re-validation tasks, potentially reducing the cost and effort necessary to re-deploy the software. Change characterizations are also useful for other software evolution tasks, e.g., assessing the impact of the changes on other parts of the system. Existing change characterization techniques infer differences in program behaviors based on changes to the source code. This approach is imprecise, and therefore, can lead to unnecessary effort and cause delays in deployment. In this dissertation, we present a novel extension and application of symbolic

Dynamic analysis techniques are well established in the software engineering community as methods for validating, understanding, maintaining, and improving programs. Generally, this class of techniques requires developers to instrument programs to generate events that capture, or observe, relevant features of program execution. Streams of these events are then processed to achieve the goals of the dynamic analysis. The lack of high-level tools for defining program observations, automating their mapping to efficient low-level implementations, and supporting the flexible combination of different event-stream-based processing components hampers the development and evaluation of new dynamic analysis techniques. For example, mapping non-trivial program observations to existing low-level instrumentation facilities is a time-consuming and error-prone process that can easily result in poorly performing analyses. In this paper, we presentSofya- a framework that we have developed for building dynamic analysis tools. We describe the architecture of Sofya, and explain how it meets the challenges faced by developers of a wide-range of dynamic analyses. We survey existing dynamic analysis tools to show how they relate to the capabilities of the Sofya framework, and we show how Sofya improves on their shortcomings. Finally, to illustrate the flexibility and effectiveness of the framework, we describe our experiences developing several state-of-the-art dynamic analyses usingSofya. 1

Testing and code editing are interleaved activities during program development. When tests fail unexpectedly, the changes that caused the failure(s) are not always easy to find. We explore how change classification can focus programmer attention on failure-inducing changes by automatically labeling changes Red, Yellow, or Green, indicating the likelihood that they have contributed to a test failure. We implemented our change classification tool JUnit/CIA as an extension to the JUnit component within Eclipse, and evaluated its effectiveness in two case studies. Our results indicate that change classification is an effective technique for finding failure-inducing changes.

In many areas of computer architecture design and program development, the knowledge of dynamic program behavior can be very handy. Several challenges beset the accurate and complete collection of dynamic control flow and memory reference information. These include scalability issues, runtime-overhead, and code coverage. For example, while Tallam and Gupta’s work on extending WPP (Whole Program Paths) showed good compressibility, their profile requires 500MBytes of intermediate memory space and an average of 23 times slowdown to be collected. To address these challenges, this paper presents DEP (Detailed Execution Profile). DEP captures the complete dynamic control flow, data dependency and memory reference of a whole program’s execution. The profile size is significantly reduced due to the insight that most information can be recovered from a tightly coupled record of control flow and register value changes. DEP is collected in an infrastructure called Adept (A dynamic execution profiling tool), which uses the DynamoRIO binary instrumentation framework to insert profile-collecting instructions within the running application. DEP profiles user-level code execution in its entirety, including interprocedural paths and the execution of multiple threads. The framework for collecting DEP has been tested on real, large and commercial applications. Our experiments show that DEP of Linux SPECInt 2000 benchmarks and Windows SysMark benchmarks can be collected with an average of 5 times slowdown while maintaining competitive compressibility. DEP’s profile sizes are about 60 % that of traditional profiles.

Incremental software change adds new functionality to software. It is the foundation of software evolution, maintenance, iterative development, agile development, and other software processes. Highly interactive tool JRipples provides the programmer with the organizational support that makes the incremental change process easier and more systematic. JRipples supports impact analysis and change propagation, the two most difficult activities of the incremental change. 1.

Impact analysis -- determining the potential effects of changes on a software system -- plays an important role in helping engineers re-validate modified software. In previous work we presented a new impact analysis technique, PathImpact, for performing dynamic impact analysis at the level of procedures, and we showed empirically that the technique can be cost-effective in comparison to prominent prior techniques. A drawback of that approach as presented, however, is that when attempting to apply the technique to a new version of a system as that system and its test suite evolves, the process of recomputing the data required by the technique for that version can be excessively expensive. In this paper, therefore, we present algorithms that allow the data needed by PathImpact to be collected incrementally. We present the results of a controlled experiment investigating the costs and benefits of this incremental approach relative to the approach of completely recomputing prerequisite data.

Change impact analysis is a useful technique for software evolution. It determines the effects of a source editing session and provides valuable feedbacks to the programmers for making correct decisions. Recently, many techniques have been proposed to support change impact analysis of procedural or object-oriented software, but seldom effort has been made for aspect-oriented software. In this paper we propose a new change impact analysis technique for AspectJ programs. At the core of our approach is the atomic change representation which can precisely capture semantic differences between two versions of an AspectJ program. We also present a change impact model, based on static AsepctJ call graph construction, to determine the impacted program parts, affected tests and their responsible affecting changes. As an application of change impact analysis, we discuss how our model can help programmers locate the exact failure reason by narrowing down those affecting changes when debugging AspectJ programs. The proposed techniques have been implemented in Celadon, a change impact analysis framework for AspectJ programs. We performed an experimental evaluation of the proposed techniques on 24 versions of 8 AspectJ benchmarks. The results show that our proposed technique can effectively perform change impact analysis and provide valuable debugging information for AspectJ programs.

This paper reports on the design and implementation of Chianti, a change impact analysis tool for Java that is implemented in the context of the Eclipse environment. Chianti analyzes two versions of an application and decomposes their difference into a set of atomic changes. Change impact is reported in terms of affected tests whose execution behavior may have been modified by the applied changes. For each affected test, Chianti also determines a set of affecting changes that were responsible for the test’s modified behavior. We evaluated Chianti on 6 months of data from M. Ernst’s Daikon system, and found that, on average, 62.4 % of the tests is affected. Furthermore, each affected test, on average, is affected by only 5.6 % of the atomic changes. These findings suggest that change impact analysis is a promising technique for assisting developers with program understanding and debugging. 1.