1. How effective is modularization?
Neil Thomas
Gail 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.

2. 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?

3. 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.

4. Evaluation
• The Systems
• Change
• Module

5. The systems

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

7. 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.

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

9. 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.

10. Cont…
Distribution of number of lines of code modified
in each change of Firefox.

11. 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

12. Analysis/Results
• Change Locality:
Number of modules affected by each change

13. Cont…
Modules modified per change in each system.

14. • Examined Modules:

15. • 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.

16. 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

17. 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.

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

19. Future Work
• Expand Variation and Sample Size of Systems
to study.

20. Thank you