Module Metrics Fixture

Using the Module Metrics Fixture for FitNesse

The Module Metrics fixture is part of the JDepend Fixture that I talked about in my last blog. You can get the fixture here.

Over the last decade I have developed a set of metrics that can be used to control the dependency structure of modules. These metrics measure and relate the incoming and outgoing dependencies of a module with its abstractness. The overall goal is to measure the tendency of dependencies to flow towards abstractions. I consider dependencies on abstract classes to be "good", and dependencies on concrete classes to be "bad".

The metrics for any given module M are:

• Ca: Afferent Couplings. The number of modules that depend on M. (i.e. fan-in)
• Ce: Efferent Couplings. The number of modules that M depends upon. (i.e. fan-out)
• I: Instability. A measure of how difficult M is to change. This metric is in the range of [0,1].
• (0) means "hard to change (i.e. stable).
• (1) means "easy to change (i.e. instable).
• I is calculated as (Ce / (Ca+Ce))
• A: Abstractness. This metric is in the range [0,1]. A is calculated as A/N where A is the number of abstract classes in M, and N is the number of classes in M.
• (0) means that M is 100% concrete.
• (1) means that M is 100% abstract.
• D: Distance. D = |A+I-1|. A metric in the range of [0,1].
• (0) means that M is as stable as it is abstract.
• (1) means that M is either abstract and nobody depends on it, or concrete and lots of modules depend upon it.

The D metric is the key metric. We want our modules to have D close to zero. When D is zero it means that our modules are as abstract as they are depended upon. The more incoming dependencies such a module has, the more abstract that module is. if a module with D = 0 has no incoming dependencies, it must also be 100$ concrete. If a D = 0 module is 100% abstract, then it is depended upon, and does not depend on any other module.

I have written a number of papers and books that cover this topic, so I'll I won't repeat the justification for these metrics here.

The Module Metrics figure allows you to easily calculate and constrain these metrics for your project. The table that drives this fixture looks like this:

Module Metrics	moduleDependencyFixture.test
module	Ca?	Ce?	I?	D?
.a				<.1
.b				<.1
.c				<.1

The structure should be self evident. As in the Module Dependencies fixture, you can specify a prefix for all the module names. that prefix is placed in the second cell of the table. Any module name beginning with a . will use that prefix. Any module name that does not begin with a . will ignore the prefix.

The columns correspond to the four metrics. Note I left all the cells blank except for the D cells. I want FitNesse to tell me if any of these modules have a D that is greater than 0.1.

This fixture depends strongly on the Module Dependencies fixture. You must run a Module Dependencies table before you run a Module Metrics table. The names of the modules in the Module Metrics table must be the same as the names in the Module Dependencies table. No other names can appear in the Module Metrics table.

Conclusion.

Have fun with this fixture. I hope you find it useful for managing the dependencies between your modules. Remember that the prime motivation for using Object Oriented Design is to manage module dependencies.

!commentForm