How effective is modularization? Neil ThomasGail Murphy

Modular programming is a software design technique according to which the software is composed of separate components.

The primary construct of study is the use of bug reports as the logical unit of change to the analyzed system.

Problem

• Are Most Changes to a system contained in a module?

• When we change one module, do we need to look at the code, inside other ones?

• Can change patterns suggest a better modularization?

Solution

• Analysis of three open source software systems:

1. Evolution: an integrated email, address book, and calendar application included in the GNOME destop.

2. Mozilla firefox: A popular cross-platform web browser.

3. Mylyn: a task-focused interface for Eclipse.

Evaluation

• The Systems• Change • Module

The systems

Cont…

• Evolution: Is characterized by a period of slow change initially, followed by a long period of substantial activity.

Cont…

• Firefox: Changes less frequently and shows almost no activity after a certain point, as developers complete work on 3.5 version and moved to the next version.

Cont…

• Mylyn: appears to grow in periodic burst over the years.

Change

• Each report captures the notion of a single logical change to the system, which could be made either to fix a defect or to add new functionality to the system.

Cont…

Distribution of number of lines of code modified in each change of Firefox.

Module• Module is defined in terms of the directory structure

that is used by each system to store the code. Both Evolution and Firefox use simple directory structure that

matches the way other data is stored on the computer.

Mylyn has a different directory structure. Java source files are arranged in nested directory structure that matches there package declaration, resulting in much deeper folder hierarchy then we find in C/C++.

org.eclipse.mylyn.bugzilla.ui/src/org/eclipse/mylyn/internal/bugzilla/ui

/action/editor/search

Analysis/Results

• Change Locality: Number of modules affected by each change

Cont…Modules modified per change in each system.

• Examined Modules:

• Emergent Modularity:

Previous results: separation of the system into modules according to structure of its directory is sensible;

3 Scenarios:–Same top level directories changed together–Different top level, same name change together (browser/themes : toolkit/themes)–A module that always changes with several others (tasks in Mylyn)

Firefox: there are several ways how this system could be break into modules;

Mylyn: Not a perfect modular structure.

Limitations • Construct comes form the simple pattern-matching technique we use to

associate commits with bug reports, this does not guarantee that all of the links between bug reports and commits are found.

• Assumed that each bug report corresponds to a single logical change to

the system, but this does not hold for all bug reports.

• Very small set of systems from which to generalize.

• All the systems analyzed were open source, which may have different change pattern then industrial system.

• Different interpretations of what a module is could lead to different results

Putting the work into perspective

Tools that help guide developers to look at modules that their

colleagues have consulted to complete similar changes could help reduce time need to make changes.

Current modularization techniques seem to help developers in their work, there is still room for improvement.

Analysis of work patterns with modules could suggest remodularizations of the system.

Take away

• Most changes in the system are isolated in the single module, but require investigation into other modules.

Future Work

• Expand Variation and Sample Size of Systems to study.

Thank you