Section 22.5. RELATED WORK

22.5. RELATED WORK

We compare our findings to earlier studies on the interaction of programmers with code during a program change task, and we describe the differences between our tools and previous tools intended specifically to help software developers identify features in source code and to assess the impact of a change. Comparisons of the features of each of the tools studied to a wider range of existing tools and previous work can be found in publications specific to each tool [10, 12, 23].

22.5.1. Studies About Program Change Tasks

Several researchers have studied the cognitive processes that programmers use when trying to understand a software system (e.g., [25, 28]). These studies can potentially provide input to developers building tools to support software maintenance tasks, including software change tasks. The work described in this paper does not attempt to study cognition; rather, it assumes searching tools are useful when performing software change tasks and provides specific design recommendations for such tools based on the results of an exploratory study.

Our belief that searching is an important activity is not unfounded. Singer and colleagues studied the work practices of software developers who were evolving a multi-million line real-time operating system [25]. They found that developers frequently performed searches across the source code comprising the system.

Sims and colleagues later studied through a web survey of programmers how and why programmers searched source code [24]. Some of the reasons reported by the 69 respondents included searching to aid the analysis of the impact of a change, maintenance, and feature additions. Of the searches described in these categories, only the impact analysis searches revealed a trend: Programmers often looked for all uses of a variable or a function. Each of the three concern elaboration tools we studied here provides some means of conducting this kind of search, lending credence to the design of the tools studied.

Empirical evidence also exists to suggest that programmers working with no or already-existing tools have difficulty dealing with non-localized pieces of code during software change tasks.

Letovsky and Soloway performed a study in which six programmers of varying experience were asked to make a change to an approximately 300 line of Fortran code system [17]. The programmers were videotaped and asked to think aloud. The researchers found that programmers had difficulty following delocalized plans, essentially changes that included code lines scattered across the code base.

Baniassad and colleagues investigated how developers manage crosscutting concernsissues that were not well-modularized in a program's structurethat emerge during software change tasks [5]. This study followed eight programmers from industry and academia as they worked on program change tasks on medium-sized systems. They found that crosscutting concerns tended to emerge as obstacles that a developer had to consider when trying to focus on the change. They also found that developers had difficulty determining how much of the code related to a concern they needed to understand, corroborating our observation that concerns are often difficult to delineate.

Some empirical work about the efficacy of the tools described in this paper has been undertaken. Griswold, Yuan, and Kato investigated the efficacy of the map metaphor as embodied in AspectBrowser, in helping a programmer manage crosscutting information when evolving a large system [10]. Robillard and Murphy studied the usefulness of Concern Graphs to guide a change task and the ability of developers to create Concern Graphs using FEAT [23]. This work shows that these tools have promise. The comparison of the use of the tools on common tasks discussed in this paper led to new possibilities for improving these tools.

22.5.2. Feature Location Approaches

Some approaches have been proposed to help a developer identify the parts of a code base related to a particular feature. In this literature, the term feature is typically used to refer to a unit of functionality in a system.

Researchers have proposed the use of an approach based on comparing execution information collected for test cases exercising a feature with execution information collected for test cases that do not exercise the feature [9, 29, 30]. The completeness of the code identified using this approach depends on the completeness of the test. The tools studied in this paper take a human-centric, static approach to elaborating a concern: a concern may or may not correspond to an easily identifiable executable piece of the system.

Chen and Rajlich advocate the determination of code related to a feature through a systematic exploration of an abstract program dependence graph representation of a system [6]. In their approach, a developer locates a starting component and a tool helps the developer manage the exploration of the dependence graph. This approach advocates a more systematic traversal over more detailed information than the concern elaboration tools in our study. It is unclear if a tool is available to support this approach.

22.5.3. Impact Analysis Approaches

Impact analysis approaches are intended to help a developer understand the scope of a software enhancement [1]. Given a seed point in the system's source code that is related to the enhancement, an impact analysis determines points in the system that are transitively dependent upon the seed. The points identified, which are sometimes called the impact domain, are intended to help a developer estimate the effort required to make the change and to determine the code that may need to be examined to make the change correctly, amongst other tasks. Early impact analysis approaches focused on call dependencies between modules.

Subsequent work has also considered dependencies in terms of data interactions in the code, as well as other artifacts, such as documents and test cases [20].

Our use of the term concern in this paper is similar to the term impact domain in that each refers to the scope of effect of a program change task. We use concern in a broader sense than impact domain in that we include all code related to a change and possible hook points within the code where functionality can be added. Impact analysis approaches typically limit the impact domain to points in the existing code related to the seed point. In contrast, our concern elaboration tools focus on source and do not consider other development artifacts.