Several contributions concentrate on dependencies, but do not consider testability explicitly.
3.3.1
Coupling Metrics
Fenton and Pfleeger One of the first coupling metrics for object-oriented software has been defined by Norman E. Fenton and Shari Lawrence Pflee- ger, called “coupling between object classes” (CBO) [Fent96]. This metric is defined as the number of other classes to which a class is coupled. Other coupling metrics vary in the level of gran- ularity and the coupling aspects they take into account. A frame- work for coupling measurement has been described in [Bria96]. Discussion
A coupling metric measures the degree to which a given class is coupled to other classes within the system. Coupling metrics can be used to evaluate the effect of the dependencies of a given class on its testability. However, the shortcomings of exist- ing coupling metrics are:
1 Coupling metrics are metrics at the class level, not at the dependency level. Therefore they are not able to highlight individual dependencies which are critical. The developer
1 A client class needs to call a static method of the singleton class if it wants to get a reference to its only instance.
Chapter 3: Related Work 27
has still to decide which dependency to remove in order to reduce coupling.
2 The majority of the coupling metrics neglect indirect depen- dencies and their effects on test tasks like test setup and fault isolation.
3 If coupling metrics take into account indirect dependencies, they are insensitive to dependencies which cause a depen- dency cycle (each class within a dependency cycle has just the same coupling value) and insensitive to classes which are crucial for the overall number of indirect dependencies (like hubs1). Therefore they do not help to identify the cause of high coupling values.
Example 1
The dependency from class H to class B in Figure 2 has the big- gest impact on overall indirect coupling: it causes an increase of 30% compared to the system without this dependency (Table 1). The classes involved in this dependency do neither have the highest direct coupling values (metric CBO2) nor the highest indirect coupling values (metric CBOi3).
Figure 2 Dependency structure
1 Hubs are classes that, if removed from the system, break the dependency graph into independent dependency subgraphs.
2 The number of other classes a class depends on. This definition is used by the IDE Together (from Borland Inc.) to calculate the metric value. 3 The number of other classes a class depends on directly or indirectly.
C A B D H E F G I
28 Chapter 3: Related Work
Table 1 Classes and values of metric CBO
4 Coupling metrics are general purpose metrics. They are insensitive to characteristics of dependencies which make a difference for testing (for example related to the ability to test a class in isolation). This discussion will be continued in Sec- tion 11.5.2.
3.3.2
ISO Standard 9126-2
ISO The draft standard [ISO9126-2] defines a system-level testability metric similar to coupling metrics which does not consider the coupling between classes but the number of dependencies to other systems.
Discussion
The metric mentioned above does not help to identify critical individual dependencies (because it is a system-level metric).
3.3.3
Design Guidelines
Liskov and Martin Barbara Liskov and Robert C. Martin described and proposed a number of design guidelines related to coupling:
• A client class should be able to collaborate with any sub- class of its supplier classes (“Liskov Substitution Principle”) [Lisk88].
• A high level component should not depend on the implemen- tation of low level components (“Dependency Inversion Prin- ciple”) but on the component interfaces [Mart96c].
class CBO CBOi
A 3 8 B 2 3 C 3 6 D 2 5 E 2 3 F 2 4 G 2 4 H 1 3 I 0 0
Chapter 3: Related Work 29
• The abstraction of a package (i.e. the degree to which a package consists of interfaces and abstract classes) should be in proportion to its stability (i.e. the difficulty of changing it based on incoming and outgoing dependencies) [Mart97]. This guideline is a refinement of the previous guideline. Martin additionally defined two simple metrics to measure abstractness and stability:
• Abstractness: the ratio of the number of abstract classes (and interfaces) to the overall number of all classes within a package.
• Stability: the ratio of the number of incoming dependencies to the overall number of (incoming and outgoing) dependen- cies of a package.
Discussion
The metric abstractness takes into account the type of depen- dencies because it distinguishes between dependencies to con- crete classes and dependencies to abstract classes or inter- faces. The shortcomings of the metrics abstractness and stability are:
• They are defined on package level. The developer still has to identify a meaningful set of classes and dependencies which should be refactored to obtain “good” metric values.
• The metric abstractness is based on a simple heuristic and does not take into account whether the classes of other packages actually use the interfaces defined within a given package or not. (It is easy to change the value of the metric abstractness by simply adding some interfaces to a pack- age.)
• The relationship between the metrics abstractness and sta- bility and the software characteristic testability has not been discussed by Martin.
3.3.4
Law of Demeter
Lieberherr et al. Lieberherr et al. [Lieb88] defined a design guideline called “Law of Demeter” to reduce direct coupling: A client class should not access the (“foreign”) supplier classes of its own direct supplier classes. The number of violations of this guideline can be used as a design metric.
Discussion
This guideline helps to reduce direct dependencies. However, reducing direct dependencies alone is not sufficient if indirect dependencies still remain.
31