The Case Study

The Method

The method used in our study is an adaptation of the approach proposed by Mattsson and Bosch for observing software evolution in object-oriented frameworks [Mattsson+1999]. Based on historical information about the subsystems, modules, and classes, they investigated the size, change rate, and growth rate of the system. The work of Mattsson and Bosch is based on a method proposed in [Gall+1997] that focused on observing macro-level software evolution using the version numbering of a system. Mattsson and Bosch adapted this approach for investigating object-oriented frameworks. The system was divided into a number of subsystems, which were themselves divided into several modules. In the adapted approach, each module consisted of several classes (instead of programs, as in the original approach).

Size is calculated by the number of classes in each module or subsystem. The calculations of change and growth rate are made in terms of changed classes as units. Class change is measured in terms of the change in the number of public methods for each class. The focus on public methods stems from the fact that a change in the public methods reflects a better understanding of the boundary of the system. Changes in private methods, however, mainly reflect refinements of implementation details and thus are of minor interest.

These are the steps of the method in the original approach.^[3]

^[3] See the Diagnosing Evolution and Test Infection section for our modifications.

1. Calculate, for all releases, the change and growth rate for the whole system.

2. Calculate, for all releases, the change and growth rate for each subsystem.

3. For those subsystems that exhibit high growth and change rates, calculate, for all releases, the change and growth rates for the modules.

4. Identify those modules that exhibit high change and growth rates as likely candidates for restructuring [Mattsson+1999].

For our study, we based our calculations for the system, subsystems, and modules on the package/subpackage structure of Java. The packaging feature of Java is a natural structuring mechanism provided by the language. In JWAM this mechanism is used to distinguish between the core and several noncore parts of the whole system, and inside the core to distinguish between the framework layers. We will discuss this in more detail later. Java interfaces are treated exactly the same way as Java classes.

The second important adaptation is that we changed the top-down approach to a bottom-up approach. Instead of starting with the top-level system, we calculate the values for every class and subsystem and go up to the top. We try to trace the development method in the code; therefore, we are interested in all developed artifacts. To be able to give advice on possible restructuring candidates (as in the approach by Mattsson and Bosch), we first have to widen the empirical base.

The third and most important adaptation is the introduction of the test coverage rate. If aggressive unit testing is one central part of test-infected programming, the results should depend on the number of system classes covered by unit tests.

The Investigated System

JWAM is a Java framework supporting the development of large-scale interactive software systems according to the tools-and-materials approach [Züllighoven1998]. The foundation of the JWAM framework was laid in 1997 by research assistants and students of the Software Engineering Group at the University of Hamburg [Lippert+2000]. In 1998 the commercialization of the framework began. In 1999 the team started to use XP techniques. Our study covers 254 individual integration versions of the whole system from April 2000 to December 2000, with roughly one version per day.

The top-level package structure of JWAM 1.5 differentiates between the framework core and several collections of other components, which are the following:

• de.jwam The framework core, which contains the interfaces and classes necessary to create a simple application according to the tools-and-materials approach

• de.jwamx JWAM components that provide technical or domain-oriented services

• de.jwamy Third-party components that provide technical or domain-oriented services

• de.jwamdev Tools used for working with the framework

• de.jwamalpha New JWAM components and new JWAM tools^[4]

  ^[4] Adapted from the program documentation of JWAM 1.5

The framework core in de.jwam is divided into several layers to separate different concerns. This is the most fundamental part for building new applications on top of JWAM and is the groundwork for the architecture of applications based on JWAM.