Chapter22.Design Recommendations for Concern Elaboration Tools | Aspect-Oriented Software Development with Use Cases

Chapter 22. Design Recommendations for Concern Elaboration Tools

GAIL C. MURPHY, WILLIAM G. GRISWOLD, MARTIN P. ROBILLARD, JAN HANNEMANN, AND WESLEY LEONG

A software developer evolving a software system experiences first-hand the consequences of modularity decisions made during earlier development. All too often, the developer must expend a significant effort tracking code pertaining to the software change of interest that was not modularized. We refer to the code related to the change as a concern.

To help with the activity of elaborating a concern, a practicing software developer may use any of a number of existing tools, including standalone search tools, browsers integrated into a software development environment, or compilers.

We believe it is possible to offer more effective support for concern elaboration activity. The authors of this chapter have thus introduced three tools: AspectBrowser [10], AMT [11, 12], and FEAT [22, 23]. A developer using these tools formulates and runs a query over a model of the program and evaluates the query results. The results of the query often cause a developer to refine the query and repeat the process. These actions identify the code of interest. The tools differ in two fundamental ways. First, each tool uses a different model of the program over which queries are run. Hence, the kinds of queries supported by each tool differ. For example, AspectBrowser uses a program model composed of the lexical tokens in the code base, AMT augments the program model used by AspectBrowser with type information, and FEAT uses a program model composed of a graph of structural relationships derived from the code base. In essence, AspectBrowser supports a lexical approach to concern elaboration, AMT provides a combination lexical and structural approach, and FEAT supports a structural approach. Second, the tools differ in their presentation of the query results; these different views impact a developer's investigation. AspectBrowser and AMT provide a Seesoft view [8] of query results that shows a developer the results in the context of the entire code base. In comparison, FEAT shows results in the context of a representation of the concern.

To better understand the task of concern elaboration and how well our tools support that task, we undertook a study in which each tool author applied his tool to elaborate a concern for a change task in three different systems. For each concern elaboration task, we compared the concern code identified and the queries and navigation patterns used by each tool user. From this study, we gained three insights:

Regardless of the kind of tool support, the participants used the same basic strategy to identify the starting point, called the seed, for concern elaboration and then elaborated the code of interest. For the latter, they largely followed control flow (e.g., calls) in and out of code pieces.
All of the tools focus on identifying code in the program source that pertains to a concern. However, we found that the participants sometimes needed to specify a condition in the system, such as "the data has been read in," rather than code: this condition was true at multiple points in the source, and no single point was obviously more appropriate for indicating the concern than another. We refer to the points at which these conditions hold as execution points.
In each case, there was considerable variability about where the edges of the concern lay in the code. It was difficult to clearly delineate what code pertained to a concern because the change task at hand and the tools available led to a different choice about the extent of a concern.

These insights suggest three corresponding recommendations for designers of concern elaboration tools.

A concern elaboration tool should support a user in following control flow within the source.
A concern elaboration tool should help a user identify points in the source that correspond to conditions in the running system.
A concern elaboration tool should allow a user to determine when the concern has been adequately elaborated: the tool should not prescribe where the concern begins and ends.

These recommendations help define the design space for tools intended to aid concern elaboration tasks. Designers of future versions of searching and browsing tools may also benefit from a better understanding of this design space.

Reflecting upon why different descriptions of concerns arose during the study has also caused us to hypothesize that a concern consists of three parts: a core part, an interface, and execution points where the concern can be extended. Understanding more about the form of concerns could help researchers trying to solve problems in software maintenance and aspect-oriented software development [14].

We begin by introducing the tools used in the study. Next, we describe the study format, present the data, and synthesize results from the study. We then relate our work to previous efforts in the area and conclude with a brief summary.