Section 22.2. STUDY FORMAT

22.2. STUDY FORMAT

Our study consisted of three cases, each consisting of a non-modularized (crosscutting) concern to be found to aid a specified change task on a Java system. To ensure the results would be analyzable, a targeted concern was to involve about 10 classes. Each participant contributed one case and was considered to be an expert for the concern on the system. In each case, each participant applied his tool to elaborate the concern of interest and reported five items: the code considered part of the concern, the queries performed in his tool, the strategy he employed with justification, the time taken, and the code viewed as part of the elaboration process. The reports included information about the order in which queries were performed and in which the code was viewed.

For each case, we describe the system and the change task posed. We present the cases in the order in which they were performed.

22.2.1. The Jex Case

Jex is a static analysis tool that produces a view of the exception flow in a Java program based on an analysis of source files [21]. It consists of 57,152 uncommented, non-blank lines of code organized in 542 classes and 18 packages.

To determine the targets of virtual method calls, Jex uses a simplified class hierarchy analysis algorithm [7] based on a user-defined set of classes. Using this algorithm, when a virtual call to method m is detected in the code, all the classes specified by the user are searched, and methods overriding the method signature m are considered a potential target.

The posed change was to perform class hierarchy analysis using a rapid type analysis algorithm [3]. This algorithm does not require a list of classes from the user. Instead, it looks at all the code reachable from a program's entry point(s) and builds the list of potential targets using an analysis of the classes that are instantiated in the program.

The task in this case was to find all of the code in Jex related to class hierarchy analysis, including code involved in discovering which implementations might be selected on a virtual method call.

22.2.2. The AMT Case

The code base for this case was Aspect Mining Tool (AMT) 0.5a, comprising 68,790 lines of code across 727 Java files. The change was to add to AMT the ability to display, via different colors, the code age of each line of code. Earlier work on the Seesoft visualization had hypothesized that such a display might be helpful to developers; for instance, to help a developer identify the age of specific parts of the code, or to help identify code that changed after a specific revision. Code age information is typically available from a version management system.

The task was to identify all code in AMT that might have to change when adding this display mode. Since this scenario was an addition rather than a refactoring task, the participants were also asked to identify portions of code that might change and places where extra code was needed. The task was divided into the following three subtasks:

1. A command-line option was to be added to specify if, where, and how the code age was to be found. For instance, a user might provide the location of the version repository for the system.

2. The code analyzer part of AMT was to be modified to output the age in addition to the type information for each line.

3. The AMT visualizer was to be modified to include a code age view that would be activated by clicking on a toggle button. This view was to ignore all search settings and display the lines of code in different shades of grey depending on their age.

A developer could assume the existence of a module that could provide the code age given a line of source code, a file name, and the version management system location. The age statistics were to be collected, along with the existing type information, during the code analysis phase.

22.2.3. The AspectBrowser Case

The code base for this case came from AspectBrowser 2.0-prealpha and consisted of 19,711 lines of code and 103 Java files. The task chosen for this case excluded the Emacs Lisp portion of AspectBrowser to permit AMT and FEAT to analyze all pertinent code.

This case had the hypothetical task of refactoring the traversal feature in AspectBrowser. The traversal feature moves a red cursor from one match to the next and displays the actual code at that location in Emacs. This feature supports several different modes of traversing through the aspects. The task was to focus on the modularization of the traversal feature through the creation of a class for each kind of traversal. Each of these classes was to inherit a common abstract class.