| As we showed in Chapter 28, we can quantify the attributes of cohesion, coupling, stability, generality, and conformance to the main sequence with a few simple metrics. But why should we want to? To paraphrase Tom DeMarco: You can't manage what you can't control, and you can't control what you don't measure.[1] To be effective software engineers or software managers, we must be able to control software development practice. If we don't measure it, however, we will never have that control. [1] [DeMarco82], p. 3
By applying the heuristics that follow, and by calculating some fundamental metrics about our OODs, we can begin to correlate those metrics with measured performance of the software and of the teams that develop it. The more metrics we gather, the more information we will have, and the more control we will eventually be able to exert. The metrics we describe have been successfully applied to a number of projects since 1994. Several automatic tools will calculate them for you, and they are not difficult to calculate by hand. It is also not difficult to write a simple shell, Python, or Ruby script to walk through your source files and calculate them.[2] [2] For an example of a shell script, you can download depend.sh from the freeware section of www.objectmentor.com.
H (relational cohesion) can be represented as the average number of internal relationships per class in a component. Let R be the number of class relationships that are internal to the component (i.e., that do not connect to classes outside the component. Let N be the number of classes within the component). The extra 1 in the formula prevents H = 0 when N = 1 and represents the relationship that the package has to all its classes: 
Ca (afferent coupling) can be calculated as the number of classes from other components that depend on the classes within the subject component. These dependencies are class relationships, such as inheritance and association. Ce (efferent coupling) can be calculated as the number of classes in other components that the classes in the subject component depend on. As before, these dependencies are class relationships. A (abstractness, or generality) can be calculated as the ratio of the number of abstract classes or interfaces in the component to the total number of classes and interfaces in the component.[3] This metric ranges from 0 to 1. [3] One might think that a better formula for A is the ratio of abstract methods to total methods within the package. However, I have found that this formula weakens the abstraction metric too much. Even one abstract method makes a class abstract, and the power of that abstraction is more significant than the fact that the class may have dozens of concrete methods, especially when DIP is being followed.
I (instability) can be calculated as the ratio of efferent coupling to total coupling. This metric also ranges from 0 to 1. 
D (distance from the main sequence) = |(A + I -1) ÷ D2|. The main sequence is idealized by the line A + I = 1. The formula calculates the distance of any particular component from the main sequence. It ranges from ~.7 to 0; the closer to 0, the better.[4] [4] It is impossible to plot any package outside the unit square on the A versus I graph, because neither A nor I can exceed 1. The main sequence bisects this square from (0,1) to (1,0). Within the square the points that are farthest from the main sequence are the two corners (0,0) and (1,1). Their distance from the main sequence is
D' (normalized distance from the main sequence) represents the D metric normalized to the range [0,1]. It is perhaps a little more convenient to calculate and to interpret. The value 0 represents a component that is coincident with the main sequence. The value 1 represents a component that is as far from the main sequence as is possible.
D'= |A + I - 1| |
