Change Impact Analysis / Change Dependencies

Dependencies between changes have been used in the context of change impact analysis. Chi- anti [Ren 2004] decomposes the difference between two versions of a Java system into a set of atomic changes. Change impact is then reported in terms of affected (regression or unit) tests whose behavior

7.6. Related Work 173

may have been modified by the applied changes. Chianti relies on syntactic dependencies between atomic changes for the change impact analysis. Other approaches extend Chianti and use dependen- cies for similar change impact analyses. Ren et al. [Ren 2006] extended the syntactic dependencies to three kinds of dependencies between atomic changes that capture syntactic and partially semantic dependencies to detect failure-inducing changes between two versions. While the dependencies pro- vided by Chianti and its derived approaches overlap with our change dependencies, they only apply to a single delta. These approaches do not offer characterization of deltas based on change and delta dependencies within a stream of changes.

CGIs [German 2009] determines the impact of historical code changes on a particular code seg- ment by means of dependence graphs. This approach guides developers to investigate failures in unchanged functions that are affected by bugs introduced in prior code changes. Structural dependen- cies between C functions are used to build the dependence graphs. These dependencies correspond to a subset of our change dependencies. GENEVA [Herzig 2011] uses dependencies to perform change impact analysis for providing recommendations to developers (e.g., predicting long-term change coupling). This approach builds change dependency graphs (known as change genealogies [Bru- daru 2008]) by ordering changes based on dependencies, and later applies model checking to the change genealogy. The dependencies are determined across transactions in version archives. While these dependencies are very similar to our change dependencies, GENEVA’s change genealogy and CGIs do not offer the notion of deltas and dependencies between deltas that can be used to character- ize sets of changes within a stream. Moreover, both determine dependencies that are not relevant in the context of integration or that can assist in understanding streams of changes and cherry picking.

7.6.4 Understanding Changes

Fritz and Murphy [Fritz 2010] present a study in which they interviewed developers regarding the different kinds of questions they need answered during development. They introduce the information fragment model and associated prototype tool for answering the identified questions. This model provides a representation that correlates various software artifacts (source code, work items, teams, comments, and so on). By browsing the model, developers can find answers to particular development questions.

While a number of the questions that developers need answered during development align with those they need answered during integration of changes, the information fragment model does not provide functionality to calculate dependencies between changes, which is necessary for integrating changes across branches.

The approaches performing change impact analysis presented above provide a means to better understand changes. However, some of them are limited to a single delta, and none of them support understanding streams of changes in the context of integration. JET could be complemented with a change impact analysis similar to the one provided by Chianti [Ren 2004].

We introduced Torch in Chapter 5. Torch is the tool support that we propose as part of our contributions to allow developers understand changes within a single delta. It visualizes how a delta is related to the structure of the system and characterize changes within a delta. JET generalizes and augments Torch’s philosophy: (1) a stream of changes is characterized, (2) a stream can be queried and navigated, (3) dependencies between the changes are computed and help driving change analyses.

Changes are not treated in isolation but within a stream of changes.

7.7

Conclusion

In this chapter we have presented an approach and (semi-) automated tool support for characterizing a stream of changes. Concretely, deltas, dependencies between changes, and dependencies between deltas are characterized within the stream. Our approach, named JET, is part of the requirements of our solution established in Section 2.4 as a means to assist integrators during the integration of changes. JET aims at assisting the integration across branches i.e., cherry picking changes from one branch to merge them with another branch.

We have presented five topics in this chapter. First, we explained how deltas and dependencies are characterized. Deltas are characterized based on the presence of dependencies: source, intermediate, island and end. Change dependencies are characterized based on the presence of changes on the stream: local and external, and based on the amount of potential changes existing in the stream that satisfy the dependency: unique and multiple. Delta dependencies are characterized based on the presence of change dependencies: needed, potential and external.

Second, we have presented the JET tools that allow an integrator to visualize and analyze de- pendencies between changes and deltas themselves. The dashboard performs the characterization of changes and provides most of the information to integrators. It offers lists of deltas, lists of changes per delta, lists of dependencies per change, lists of dependencies per delta, and metrics about the amount of changes, deltas and dependencies within the stream. Each change on the list also adds several metrics that extract information from the stream, the history and the working copy. The map is a visualization that displays deltas and their dependencies. It provides integrators with a general overview of the complexity of the stream. The query browser allows integrators to explore the evo- lution of an entity within the stream and its users within the stream and within the working copy. It reuses several components of the dashboard such as the list of dependencies per change or the source code diffs.

Third, we discussed how several questions (presented in Section3.3.2) are supported by JET. This part also served as a motivation for the features of JET in order to allow answering the questions.

Fourth, we presented the qualitative assessment of the capabilities of JET tools by performing an exploratory case study on a considerable five-year stream of changes: changes made to the Monti- cello version control system in Squeak with the goal of integrating them into Pharo. The evaluation consisted of two parts performed by an integrator and a developer of the Pharo project.

Fifth, we discussed several approaches related to JET in the areas of replaying changes, change characterization, change impact analysis, change dependencies and change understanding, and we compared these approaches with JET.

CHAPTER

8

Conclusion and Future Work

Contents

8.1 Summary . . . 175

8.2 Conclusion . . . 176

8.3 Integrator Questions Revisited . . . 176

8.4 Limitations and Future Work. . . 178

8.5 Contributions . . . 181

8.1

Summary

The motivation of this dissertation is that in a collaborative development environment where the use of branching and therefore merging is extensive, integrators lack adequate support to assist them in performing integration activities such as understanding changes, establishing the dependencies of changes, cherry picking changes, assessing the impact of changes, resolving merging conflicts, and so on.

The complexity of these tasks is aggravated by several factors: (a) the integrators may not be familiar with the code they need to integrate, (b) the changes may come from a branch that has drifted apart from the branch in which the changes need to be integrated (this is common when integrating changes between forks), (c) the support provided by versioning control systems regarding to merging is mostly limited to textual comparisons resulting in conflicts that need to be solved manually, (d) there is no support whatsoever to determine the requirements of a change in order to assist cherry picking, (e) there is no guarantee that after a successful integration the system is 100% functional or that in the future, prior changes do not negatively impact unchanged code.

The integration of changes is key in the development process, however, developers that play the role of integrators lack adequate support. Note that each of the tasks required to integrate changes may represent a problem by its own, making the whole integration process tedious and time consuming. There is a clear need for tools that can assist integrators in each of these tasks.

In this dissertation we introduced a novel approach that partially tackles the aforementioned problems by supporting assisted integration of changes within a branch and across branches. Our approach is based on an analysis of the integrators’ information needs when understanding and inte- grating changes. This analysis identifies which kinds of information an integrator potentially needs to characterize changes and streams of changes in their respective context. To provide integrators with access to this information, we provide a first-class representation of the history of a system, the changes made to the system, and an analysis of the dependencies between these changes. As a concrete implementation, we presented four meta-models: Ring, RingH, RingS and RingC.

On top of these meta-models and analysis, we provide tool support – by means of visualizations and advanced browsers – that allows an integrator to access the information regarding particular changes, and that aids in the decision making process when integrating changes. Two concrete tools have been implemented to support this idea, namely Torch that characterizes changes within a single delta and JET that characterizes a stream of changes and their dependencies.

8.2

Conclusion

Due to the importance of integration of changes in the software development process and even more in a collaborative development environment, it is necessary to provide integrators with approaches that can assist them in the different activities involved with integration. Throughout this dissertation we have argued that by providing integrators with access to their information needs at an adequate level of abstraction, and tool support to query such information we can assist integration.

Our approach aims at assisting integration as a first step towards supporting full, semantic merging across branches.

First, we performed this research in the context of a real development project – Pharo – and its community, therefore we focused on proposing an approach using scientific methodologies that can be applied in a realistic context. We did not apply our approach to toy examples, but rather to concrete examples of integration problems. We developed our contributions with the intention of integrating them in the core of this project, and we evaluated our contributions by consulting developers and integrators of the Pharo community.

Second, we proposed a language-independent solution that can be used to (semi-)automatically assist integration activities in the context of object-oriented applications. We do not target fully auto- mated support because human expertise is necessary to understand the impact on the semantics of a system. Depending on the context and complexity of the changes it may not be possible to automati- cally identify impact on semantics. For example, if we intend to integrate a method that impacts the lookup order of a particular call, it is required to have a human check to know if this method can or cannot be integrate.

Third, we presented an initial evaluation of our approach that suggests that our approach and tool support aid integrators in understanding changes in isolation and changes within a stream. Further- more, we also hypothesize based on our evaluation that our approach can also be used to provide a means to understand changes and stream of changes needed in other contexts. For example: (a) for maintenance tasks where developers may rely on the history of the system to understand the code that they need to change, (b) for aiding new team members to get acquainted with the evolution of the system, and (c) for helping committers to control their changes before committing.

Fourth, despite the fact that our approach only offers a simple change and dependency model along with a dependency analysis, it is able to provide integrators with a significant amount of their information needs. Therefore it can provide answers to most of the questions in the catalogue.