The Component Dependency (CD) for a component C is defined as the amount of other components that C depends on, either directly or indirectly.

There are two flavors of Component Dependency

There are two flavors of Component Dependency

- absolute CD, expressed as the number of other components
- relative CD, expressed as the percentage of other components

In other words, relative CD is absolute CD divided by the number of components (-1) multiplied with 100.

STAN shows you the (relative) Average Component Dependency (ACD) metric for libraries, packages and units (toplevel classes).

For symmetry reasons, we may note that

STAN shows you the (relative) Average Component Dependency (ACD) metric for libraries, packages and units (toplevel classes).

For symmetry reasons, we may note that

- ACD is the average amount of components that a component depends on
- ACD is the average amount of components that depend on a component

So far so good. But how is this related to testability?

Consider we have a code base with 1000 units and an ACD for units of 10%. That is, on average, a unit depends on 100 other units (and 100 other units depend on it), either directly or indirectly.

But this also means that

Consider we have a code base with 1000 units and an ACD for units of 10%. That is, on average, a unit depends on 100 other units (and 100 other units depend on it), either directly or indirectly.

But this also means that

- changing a unit may affect (and potentially break) 100 other units
- a unit may be affected (and potentially broken) by changes in any of 100 other units

This shows that ACD is indeed an interesting measure for testability: smaller values allow for simpler and more robust testing.

Finally, let me give some real world examples:

Finally, let me give some real world examples:

Project #units rel. ACD abs. ACD

Spring 2.5.1 1595 2.50% 40

Groovy 1.5.4 833 27.57% 229

Hibernate 3.2.6 1085 67.04% 727