Chapter 24 Technical Metrics for Object-Oriented Systems

1

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

Chapter 24Chapter 24Technical Metrics forTechnical Metrics for

Object-Oriented Object-Oriented SystemsSystems

2


OO metrics have been introduced to help a OO metrics have been introduced to help a software engineer use quantitative analysis software engineer use quantitative analysis to assess the quality of the design before a to assess the quality of the design before a system is built. system is built.

The focus of OO metrics is on the class—the The focus of OO metrics is on the class—the fundamental building block of the OO fundamental building block of the OO architecture.architecture.

3


The first step in the measurement process is The first step in the measurement process is to derive the software measures and to derive the software measures and metrics that are appropriate for the metrics that are appropriate for the representation of software that is being representation of software that is being considered. considered.

Next, data required to derive the formulated Next, data required to derive the formulated metrics are collected. Once computed, metrics are collected. Once computed, appropriate metrics are analyzed based on appropriate metrics are analyzed based on pre-established guidelines and past data. pre-established guidelines and past data.

The results of the analysis are interpreted to The results of the analysis are interpreted to gain insight into the quality of the software, gain insight into the quality of the software, and the results of the interpretation lead to and the results of the interpretation lead to modification of work products arising out of modification of work products arising out of analysis, design, code, or test. analysis, design, code, or test.

4


The primary objectives for object-oriented The primary objectives for object-oriented metrics are no different than those for metrics are no different than those for metricsmetrics

derived for conventional software:derived for conventional software:

• • to better understand the quality of the to better understand the quality of the productproduct

• • to assess the effectiveness of the processto assess the effectiveness of the process

• • to improve the quality of work performed to improve the quality of work performed at a project levelat a project level

5


Distinguishing Characteristics Distinguishing Characteristics of of

OO MetricsOO Metrics Localization—the way in which information is concentrated in a Localization—the way in which information is concentrated in a

programprogram Encapsulation—the packaging of data and processingEncapsulation—the packaging of data and processing

Information hiding—the way in which information about operational Information hiding—the way in which information about operational details is hidden by a secure interface. details is hidden by a secure interface. A well-designed OO A well-designed OO system should encourage information hiding. Therefore, metrics system should encourage information hiding. Therefore, metrics that provide an indication of the degree to which hiding has that provide an indication of the degree to which hiding has been achieved should provide an indication of the quality of the been achieved should provide an indication of the quality of the OO design.OO design.

Inheritance—the manner in which the responsibilities of one class Inheritance—the manner in which the responsibilities of one class are propagated to another are propagated to another Because inheritance is a pivotal Because inheritance is a pivotal haracteristic in many OO systems, many OO metrics focus on it. haracteristic in many OO systems, many OO metrics focus on it. Examples (discussed later in this chapter) include number of Examples (discussed later in this chapter) include number of children children (number of immediate instances of a class), number of (number of immediate instances of a class), number of parents (number of immediate parents (number of immediate generalizations), and class generalizations), and class hierarchy hierarchy nesting level (depth of a class in an inheritance nesting level (depth of a class in an inheritance hierarchy).hierarchy).

Berard argues that the following characteristics require that special OO metrics be developed:

6


Abstraction—The mechanism that allows a design to Abstraction—The mechanism that allows a design to focus on essential details .focus on essential details .

Because a class is an abstraction that can be viewed at Because a class is an abstraction that can be viewed at many different levels of detail and in a number of many different levels of detail and in a number of different ways (e.g., as a list of operations, as a different ways (e.g., as a list of operations, as a sequence of states, as a series of collaborations), OO sequence of states, as a series of collaborations), OO metrics represent abstractions in terms of measures of metrics represent abstractions in terms of measures of a class (e.g., number of instances per class per a class (e.g., number of instances per class per application, number or parameterized classes per application, number or parameterized classes per application, and ratio of parameterized classes to application, and ratio of parameterized classes to nonparameterizednonparameterized

classes).classes).

7


Metrics for OO Metrics for OO DesignDesign

Size Size ComplexityComplexity CouplingCoupling SufficiencySufficiency CompletenessCompleteness CohesionCohesion PrimitivenessPrimitiveness SimilaritySimilarity VolatilityVolatility

8


9


Sufficiency - a design component (e.g., a Sufficiency - a design component (e.g., a class) is sufficient if it fully reflects all class) is sufficient if it fully reflects all properties of the application domain object properties of the application domain object that it is modeling— that is, that the that it is modeling— that is, that the abstraction (class) possesses the features abstraction (class) possesses the features required of it.required of it.

Completeness considers multiple points of Completeness considers multiple points of view. Because the criterion for completeness view. Because the criterion for completeness considers different points of view, it has an considers different points of view, it has an indirect implication about the degree to indirect implication about the degree to which the abstraction or design component which the abstraction or design component can be reused.can be reused.

10


Cohesion. Like its counterpart in Cohesion. Like its counterpart in conventional software, an OO component conventional software, an OO component should be designed in a manner that has should be designed in a manner that has all operations working together to achieve all operations working together to achieve a single, well-defined purposea single, well-defined purpose

Primitiveness. A characteristic that is Primitiveness. A characteristic that is similar to simplicity, primitiveness (applied similar to simplicity, primitiveness (applied to both operations and classes) is the to both operations and classes) is the degree to which an operation is degree to which an operation is atomic—atomic—that is, the operation cannot be that is, the operation cannot be constructed out of a sequence of constructed out of a sequence of other other operations contained within a class.operations contained within a class.

11


Similarity. The degree to which two or Similarity. The degree to which two or more classes are similar in terms ofmore classes are similar in terms of

their structure, function, behavior, or their structure, function, behavior, or purpose is indicated by this measure.purpose is indicated by this measure.

Volatility of an OO design component Volatility of an OO design component measures the likelihood that a change will measures the likelihood that a change will occur.occur.

12


Class-Oriented Class-Oriented MetricsMetrics

weighted methods per classweighted methods per class depth of the inheritance treedepth of the inheritance tree number of childrennumber of children coupling between object coupling between object

classesclasses response for a classresponse for a class lack of cohesion in methodslack of cohesion in methods

Proposed by Chidamber and Kemerer (Proposed by Chidamber and Kemerer (CK Metrics))::

13


14


Depth of the inheritance tree (DIT). This Depth of the inheritance tree (DIT). This metric is “the maximum length from the node metric is “the maximum length from the node to the root of the tree”to the root of the tree”

As DIT grows, it is likely that lower-level As DIT grows, it is likely that lower-level classes will inherit many methods. This leads classes will inherit many methods. This leads to potential difficulties when attempting to to potential difficulties when attempting to predict the behavior of a class. A deep class predict the behavior of a class. A deep class hierarchy (DIT is large) also leads to greater hierarchy (DIT is large) also leads to greater design complexity. On the positive side, large design complexity. On the positive side, large DIT values imply that many methods may be DIT values imply that many methods may be reused.reused.

15


16


17


18


Lack of cohesion in methods (LCOM). Each method within a Lack of cohesion in methods (LCOM). Each method within a class, C, accesses one or more attributes (also called class, C, accesses one or more attributes (also called instance variables). LCOM is the number of methods instance variables). LCOM is the number of methods that that access one or more of the same attributes.4 access one or more of the same attributes.4

If no methods access the same attributes, then LCOM = 0. If no methods access the same attributes, then LCOM = 0. To illustrate the case where LCOM ≠ 0, consider a class with To illustrate the case where LCOM ≠ 0, consider a class with six methods. Four of the methods have one or more six methods. Four of the methods have one or more attributes in common (i.e., they access common attributes). attributes in common (i.e., they access common attributes). Therefore, LCOM = 4.Therefore, LCOM = 4.

If LCOM is high, methods may be coupled to one another via If LCOM is high, methods may be coupled to one another via attributes. This increases the complexity of the class design. attributes. This increases the complexity of the class design. In general, high values for LCOM imply that the class might In general, high values for LCOM imply that the class might be better designed by breaking it into two or more separate be better designed by breaking it into two or more separate classes. classes.

Although there are cases in which a high value for LCOM is Although there are cases in which a high value for LCOM is justifiable, it is desirable to keep cohesion high; that is, keepjustifiable, it is desirable to keep cohesion high; that is, keep

LCOM low.LCOM low.

19



class sizeclass size number of operations overridden by a number of operations overridden by a

subclasssubclass number of operations added by a subclassnumber of operations added by a subclass specialization indexspecialization index

Proposed by Lorenz and KiddProposed by Lorenz and Kidd]:]:

20


Metrics Proposed by Lorenz and KiddMetrics Proposed by Lorenz and KiddLorenz and Kidd divide class-based metrics into four Lorenz and Kidd divide class-based metrics into four

broad categories: size, inheritance, internals, and broad categories: size, inheritance, internals, and externals. externals.

Size-oriented metrics for the OO class focus on counts Size-oriented metrics for the OO class focus on counts of attributes and operations for an individual class of attributes and operations for an individual class and average values for the OO system as a whole. and average values for the OO system as a whole.

Inheritance-based metrics focus on the manner in Inheritance-based metrics focus on the manner in which operations are reused through the class which operations are reused through the class hierarchy.hierarchy.

Metrics for class internals look at cohesion and code-Metrics for class internals look at cohesion and code-oriented issues, and external metrics examine oriented issues, and external metrics examine coupling and reuse.coupling and reuse.

21


22


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 extendthe 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.

23


24


25


26



Method inheritance factor (MIF)Method inheritance factor (MIF) Coupling factor (CF)Coupling factor (CF) Polymorphism factor (PF)Polymorphism factor (PF)

The MOOD Metrics SuiteThe MOOD Metrics Suite

27



The degree to which the class architecture of an OO system makes The degree to which the class architecture of an OO system makes use of inheritance for both methods (operations) and attributes is use of inheritance for both methods (operations) and attributes is defined as:defined as:

MIF = MIF = Mi(Ci)/ Ma(Ci)Mi(Ci)/ Ma(Ci)

where the summation occurs over where the summation occurs over i = 1 to TC. TC is i = 1 to TC. TC is defined as the total number of defined as the total number of classes in the architecture, classes in the architecture, Ci is a class within the architecture, andCi is a class within the architecture, and

Ma(Ci) = Md(Ci) + Mi(Ci)Ma(Ci) = Md(Ci) + Mi(Ci)

WhereWhere

Ma(Ci) = the number of methods that can be invoked in Ma(Ci) = the number of methods that can be invoked in association with Ci.association with Ci.

Md(Ci) ) = the number of methods declared in the class Md(Ci) ) = the number of methods declared in the class Ci.Ci.

Mi(Ci) = the number of methods inherited (and not Mi(Ci) = the number of methods inherited (and not overridden) in Ci.overridden) in Ci.

Method inheritance factor (MIF)

28



The MOOD metrics suite defines coupling in the The MOOD metrics suite defines coupling in the following way:following way:

CF = Σi Σj CF = Σi Σj is_client (Ci, Cj)]/(TC2 TC)is_client (Ci, Cj)]/(TC2 TC) where the summations occur over where the summations occur over i = 1 to TC and j = 1 i = 1 to TC and j = 1

to TC. The functionto TC. The function

is_client = 1, if and only if a relationship exists is_client = 1, if and only if a relationship exists between the client class, Cc, andbetween the client class, Cc, and

the server class, the server class, Cs, and Cc ≠ CsCs, and Cc ≠ Cs

= 0, otherwise= 0, otherwise

Coupling factor (CF)

29



The MOOD metrics suite defines PF in the following The MOOD metrics suite defines PF in the following manner:manner:

MIF = i MIF = i Mo(Ci)/i [Mn(Ci) DC(Ci)]Mo(Ci)/i [Mn(Ci) DC(Ci)]

where the summations occur over where the summations occur over i = 1 to TC andi = 1 to TC and

Md(Ci) = Mn(Ci) + Mo(Ci)Md(Ci) = Mn(Ci) + Mo(Ci)

Also,Also,

Mn(Ci) = the number of new methods.Mn(Ci) = the number of new methods.

Mo(Ci) = the number of overriding methods.Mo(Ci) = the number of overriding methods.

DC(DC(Ci) = the descendants count (the number of Ci) = the descendants count (the number of descendant classes of a base class).descendant classes of a base class).

Polymorphism factor (PF)

30


Operation-Oriented Operation-Oriented MetricsMetrics

average operation size: average operation size: operation complexityoperation complexity average number of parameters per average number of parameters per

operationoperation

Proposed by Lorenz and Kidd [LOR94Proposed by Lorenz and Kidd [LOR94]:]:

31


Testability Testability MetricsMetrics

encapsulation relatedencapsulation related lack of cohesion in methodslack of cohesion in methods percent public and protectedpercent public and protected public access to data memberspublic access to data members

inheritance relatedinheritance related number of root classesnumber of root classes fan infan in number of children and depth of inheritance number of children and depth of inheritance

treetree

Proposed by Binder [BIN94]:Proposed by Binder [BIN94]:

32


OO Project OO Project MetricsMetrics

number of scenario number of scenario scriptsscripts

number of key classesnumber of key classes number of subsystemsnumber of subsystems

Proposed by Lorenz and Kidd [LOR94]:Proposed by Lorenz and Kidd [LOR94]:

Documents

Chapter 24 Technical Metrics for Object-Oriented Systems