Component-level design metrics focus on internal characteristics of a software component and include measures of the “three Cs”—module cohe...
Component-level design metrics focus on internal characteristics of a software component and include measures of the “three Cs”—module cohesion, coupling, and complexity. These measures can help a software engineer to judge the quality of a component-level design.
The metrics presented in this section are glass box in the sense that they require knowledge of the inner working of the module under consideration. Component-level design metrics may be applied once a procedural design has been developed. Alternatively, they may be delayed until source code is available.
Cohesion metrics. Bieman and Ott define a collection of metrics that provide an indication of the cohesiveness of a module. The metrics are defined in terms of five concepts and measures:
Data slice. Stated simply, a data slice is a backward walk through a module
that looks for data values that affect the module location at which the walk
began. It should be noted that both program slices (which focus on statements
and conditions) and data slices can be defined.
Data tokens. The variables defined for a module can be defined as data
tokens for the module.
Glue tokens. This set of data tokens lies on one or more data slice.
Superglue tokens. These data tokens are common to every data slice in a module.
Stickiness. The relative stickiness of a glue token is directly proportional to the number of data slices that it binds.
Bieman and Ott develop metrics for strong functional cohesion (SFC), weak functional cohesion (WFC), and adhesiveness (the relative degree to which glue tokens bind data slices together). These metrics can be interpreted in the following manner :
All of these cohesion metrics range in value between 0 and 1. They have a value of 0 when a procedure has more than one output and exhibits none of the cohesion attribute indicated by a particular metric. A procedure with no superglue tokens, no tokens that are common to all data slices, has zero strong functional cohesion—there are no data tokens that contribute to all outputs. A procedure with no glue tokens, that is no tokens common to more than one data slice (in procedures with more than one data slice), exhibits zero weak functional cohesion and zero adhesiveness—there are no data tokens that contribute to more than one output.
Strong functional cohesion and adhesiveness are encountered when the Bieman and Ott metrics take on a maximum value of 1.
To illustrate the character of these metrics, consider the metric for strong functional cohesion:
SFC(i) = SG [SA(i))/(tokens(i)]
where SG[SA(i)] denotes superglue tokens—the set of data tokens that lie on all data slices for a module i. As the ratio of superglue tokens to the total number of tokens in a module i increases toward a maximum value of 1, the functional cohesiveness of the module also increases.
Coupling metrics. Module coupling provides an indication of the “connectedness” of a module to other modules, global data, and the outside environment. Coupling was discussed in qualitative terms.
Dhama has proposed a metric for module coupling that encompasses data and control flow coupling, global coupling, and environmental coupling. The measures required to compute module coupling are defined in terms of each of the three coupling types noted previously.
For data and control flow coupling,
di = number of input data parameters
ci = number of input control parameters
do = number of output data parameters
co = number of output control parameters
For global coupling,
gd = number of global variables used as data
gc = number of global variables used as control
For environmental coupling,
w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
r = number of modules calling the module under consideration (fan-in)
Using these measures, a module coupling indicator, mc , is defined in the following way:
mc = k/M
where k = 1, a proportionality constant and
M = di + (a ci) + do + (b co) + gd + (c gc) + w + r
where a = b = c = 2.
The higher the value of mc, the lower is the overall module coupling. For example, if a module has single input and output data parameters, accesses no global data, and is called by a single module,
mc = 1/(1 + 0 + 1+ 0 + 0 + + 0 + 1 + 0) = 1/3 = 0.33
We would expect that such a module exhibits low coupling. Hence, a value of mc = 0.33 implies low coupling. Alternatively, if a module has five input and five output data parameters, an equal number of control parameters, accesses ten items of global data, has a fan-in of 3 and a fan-out of 4,
mc = 1/[5 + (2 5) + 5 + (2 5) + 10 + 0 + 3 + 4] = 0.02
and the implied coupling would be high.
In order to have the coupling metric move upward as the degree of coupling increases , a revised coupling metric may be defined as
C = 1 - mc
where the degree of coupling increases nonlinearly between a minimum value in the range 0.66 to a maximum value that approaches 1.0.
Complexity metrics. A variety of software metrics can be computed to determine the complexity of program control flow. Many of these are based on the flow graph. A graph is a representation composed of nodes and links (also called edges). When the links (edges) are directed, the flow graph is a directed graph.
McCabe and Watson identify a number of important uses for complexity metrics:
Complexity metrics can be used to predict critical information about reliability and maintainability of software systems from automatic analysis of source code [or procedural design information]. Complexity metrics also provide feedback during the software project to help control the [design activity]. During testing and maintenance, they provide detailed information about software modules to help pinpoint areas of potential instability.
The most widely used (and debated) complexity metric for computer software is cyclomatic complexity, originally developed by Thomas McCabe .
The McCabe metric provides a quantitative measure of testing difficulty and an indication of ultimate reliability. Experimental studies indicate distinct relationships between the McCabe metric and the number of errors existing in source code, as well as time required to find and correct such errors.
McCabe also contends that cyclomatic complexity may be used to provide a quantitative indication of maximum module size. Collecting data from a number of actual programming projects, he has found that cyclomatic complexity = 10 appears to be a practical upper limit for module size. When the cyclomatic complexity of modules exceeded this number, it became extremely difficult to adequately test a module.
Zuse presents an encyclopedic discussion of no fewer that 18 different categories of software complexity metrics. The author presents the basic definitions for metrics in each category (e.g., there are a number of variations on the cyclomatic complexity metric) and then analyzes and critiques each. Zuse’s work is the most comprehensive published to date.
