Chapter 24 Technical Metrics for Object-Oriented Systems. OO metrics have been introduced to help a software engineer use quantitative analysis to assess the quality of the design before a system is built.
Chapter 24Technical Metrics forObject-Oriented Systems
OO metrics have been introduced to help a software engineer use quantitative analysis to assess the quality of the design before a system is built.
The focus of OO metrics is on the class—the fundamental building block of the OO architecture.
The first step in the measurement process is to derive the software measures and metrics that are appropriate for the representation of software that is being considered.
Next, data required to derive the formulated metrics are collected. Once computed, appropriate metrics are analyzed based on pre-established guidelines and past data.
The results of the analysis are interpreted to gain insight into the quality of the software, and the results of the interpretation lead to modification of work products arising out of analysis, design, code, or test.
The primary objectives for object-oriented metrics are no different than those for metrics
derived for conventional software:
• to better understand the quality of the product
• to assess the effectiveness of the process
• to improve the quality of work performed at a project level
Distinguishing Characteristics of OO Metrics
Berard argues that the following characteristics require
that special OO metrics be developed:
Information hiding—the way in which information about operational details is hidden by a secure interface. A well-designed OO system should encourage information hiding. Therefore, metrics that provide an indication of the degree to which hiding has been achieved should provide an indication of the quality of the OO design.
Inheritance—the manner in which the responsibilities of one class are propagated to another Because inheritance is a pivotal haracteristic in many OO systems, many OO metrics focus on it. Examples (discussed later in this chapter) include number of children (number of immediate instances of a class), number of parents (number of immediate generalizations), and class hierarchy nesting level (depth of a class in an inheritance hierarchy).
Abstraction—The mechanism that allows a design to focus on essential details .
Because a class is an abstraction that can be viewed at many different levels of detail and in a number of different ways (e.g., as a list of operations, as a sequence of states, as a series of collaborations), OO metrics represent abstractions in terms of measures of a class (e.g., number of instances per class per application, number or parameterized classes per application, and ratio of parameterized classes to nonparameterized
Metrics for OO Design
their structure, function, behavior, or purpose is indicated by this measure.
Proposed by Chidamber and Kemerer (CK Metrics):
Proposed by Lorenz and Kidd]:
Metrics Proposed by Lorenz and Kidd
Lorenz and Kidd divide class-based metrics into four broad categories: size, inheritance, internals, and externals.
Size-oriented metrics for the OO class focus on counts of attributes and operations for an individual class and average values for the OO system as a whole.
Inheritance-based metrics focus on the manner in which operations are reused through the class hierarchy.
Metrics for class internals look at cohesion and code-oriented issues, and external metrics examine coupling and reuse.
Number of operations overridden by a subclass (NOO). There are instances when a subclass replaces an operation inherited from its superclass with a specialized version for its own use. This is called overriding.
Large values for NOO generally indicate a design problem. As Lorenz and Kidd point out: Since a subclass should be a specialization of its superclasses, it should primarily extend
the services [operations] of the superclasses. This should result in unique new method names.
If NOO is large, the designer has violated the abstraction implied by the superclass.
This results in a weak class hierarchy and OO software that can be difficult to test and modify.
The MOOD Metrics Suite
Method inheritance factor (MIF)
MIF = Mi(Ci)/ Ma(Ci)
where the summation occurs over i = 1 to TC. TC is defined as the total number of classes in the architecture, Ci is a class within the architecture, and
Ma(Ci) = Md(Ci) + Mi(Ci)
Ma(Ci) = the number of methods that can be invoked in association with Ci.
Md(Ci) ) = the number of methods declared in the class Ci.
Mi(Ci) = the number of methods inherited (and not overridden) in Ci.
Coupling factor (CF)
CF = Σi Σj is_client (Ci, Cj)]/(TC2 TC)
is_client = 1, if and only if a relationship exists between the client class, Cc, and
the server class, Cs, and Cc ≠ Cs
= 0, otherwise
Polymorphism factor (PF)
The MOOD metrics suite defines PF in the following manner:
MIF = i Mo(Ci)/i [Mn(Ci) DC(Ci)]
where the summations occur over i = 1 to TC and
Md(Ci) = Mn(Ci) + Mo(Ci)
Mn(Ci) = the number of new methods.
Mo(Ci) = the number of overriding methods.
DC(Ci) = the descendants count (the number of descendant classes of a base class).
Proposed by Lorenz and Kidd [LOR94]:
Proposed by Binder [BIN94]:
OO Project Metrics
Proposed by Lorenz and Kidd [LOR94]: