WOLLO UNIVERSITY

KOMBOLCHA INSTITUTE OF TECHNOLOGY

DEPARTMENT OF SOFTWARE ENGINEERING
SOFTWARE METRICS GROUP ASSIGNMENT

Group Members
Yasin Mohammed Ali--------1228/09

Halid Yimer----------------------1548/09

Habib Indris---------------------1622/09

Abay Beyene--------------------1381/09

Chernet Lake--------------------1482/09

Yordanos Belayneh-----------1331/09

Daniel Destaw----------------- 1528/09

Shekur Mohammed-----------1374/09

Hadiya Seid---------------------1587/09

Hikma Mohammed-----------1565/09

Samia Abbas-------------------1652/09

i|Page
Abstract
Object oriented design is becoming more popular in software development environment and
object-oriented design metrics is an essential part of software environment. This study
focuses on a set of object-oriented metrics that can be used to measure the quality of an
object-oriented system.

ii | P a g e
Table of Contents
Introduction................................................................................................................................1
1. Object oriented metrics..........................................................................................................2
1.1 Measuring Coupling in Object-Oriented Systems............................................................2
1.1.1 METRICS 1: Coupling Between Object Classes (CBO)...........................................2
1.1.2 METRIC 2: Response for a Class (RFC)...................................................................3
1.1.3 METRICS 3: Message Passing Coupling (MPC)......................................................3
1.2 Measuring Cohesion in Object-Oriented Systems...........................................................4
1.2.1 METRICS 1: Lack of Cohesion Metric (LCOM)......................................................5
1.2.2 MERICS 2: Tight class cohesion (TCC) and loose class cohesion (LCC)................5
1.2.3 METRICS 3: Ratio of Cohesive Interactions (RCI)..................................................5
1.3 Object-Oriented Length Measures...................................................................................6
1.3.1 METRICS: Depth of Inheritance Tree (DIT)............................................................6
1.4 Object-Oriented Reuse Measurement...............................................................................7
1.4.1 METRICS: The Number of Children (NOC)............................................................7
1.5 MOOD (Metrics for Object Oriented Design).................................................................8
Conclusion..................................................................................................................................9
References..................................................................................................................................9

iii | P a g e
iv | P a g e
Introduction

In designing a complex software system, Object-Oriented Analysis and Design techniques

provide many benefits. These benefits include, but are not limited to, the following:
reusability, decomposition of a problem into easily understood objects, and the facility of
future modifications and enhancements.

Despite all of its benefits, the OOAD software development life cycle is by no means less
difficult than the typical procedural approach. In fact, it has become even more complicated.
Many software engineers are finding it troublesome to make the transition in to this new way
of thinking. In a variety of ways, it is orthogonal to the traditional procedural approach.
Therefore, it is necessary to provide dependable guidelines that one may follow to help
ensure good OO programming practices and furnish reliable code. One of the most difficult
problems in the software engineering realm is producing software that is within budget,
complete, on time, and that meets the requirements of the end user.

This paper presents a compilation of Object-Oriented programming metrics that we think

should be considered. In this instance, we mean metrics to be a set of standards against which
one can measure the effectiveness of Object-Oriented Analysis techniques in the design of a
system. Metrics are a useful means for monitoring progress, attaining more accurate
estimations of project milestones, and developing a software system that contains minimal
faults. Software metrics also help to quantify the problem complexity, design complexity, and
the program or product complexity

1|Page
1. Object oriented metrics

Object-oriented metrics are primarily applied to the concepts of classes, coupling, and
inheritance. For some of the object-oriented metrics discussed here, multiple definitions are
given, since researchers and practitioners have not reached a common definition or counting
methodology. In some cases, the counting method for a metric is determined by the software
analysis package being used to collect the metrics.

1.1 Measuring Coupling in Object-Oriented Systems

Coupling is a measure of the strength of association established by a connection from one

entity to another. Classes (objects) are coupled in three ways:

1. When a message is passed between objects, the objects are said to be coupled.
2. Classes are coupled when methods declared in one class use methods or attributes of
the other classes.
3. Inheritance introduces significant tight coupling between super classes and their
subclasses. Since good object-oriented design requires a balance between coupling
and inheritance, coupling measures focus on non-inheritance coupling. The next
object-oriented metric measures coupling strength.

Coupling Properties

2|Page
 1. Nonnegativity: Module coupling cannot be negative.
2. Null value: A module without links to elements that are external to the module has
zero coupling.
3. Monotonicity: Adding inter module relationships does not decrease coupling.
4. Merging modules: Merging two modules creates a new module that has coupling that
is at most the sum of the coupling of the two modules
5. Disjoint module additivity: Merging disjoint modules without links between them
creates a new module with coupling that is the sum of the coupling of the original
modules.

1.1.1 METRICS 1: Coupling Between Object Classes (CBO)

CBO is a count of the number of other classes to which a class is coupled. It is measured by
counting the number of distinct non-inheritance related class hierarchies on which a class
depends. Excessive coupling is detrimental to modular design and prevents reuse. The more
independent a class is, the easier it is reuse in another application.

The larger the number of couples, the higher the sensitivity to changes in other parts of the
design and therefore maintenance is more difficult. Strong coupling complicates a system
since a module is harder to understand, change or correct by itself if it is interrelated with
other modules. Complexity can be reduced by designing systems with the weakest possible
coupling between modules. This improves modularity and promotes encapsulation. CBO
evaluates Efficiency and Reusability.

There are several problems with CBO (Briand et al. 1999b). One problem is that the
treatment of inherited methods is ambiguous. Another problem is that CBO does not satisfy
property 5, disjoint module additivity, one of the coupling properties given above. If class A
is coupled to classes B and C, both classes B and C have CBO = 1, assuming no other
coupling connections. Now assume that classes B and C are merged creating new class D.
Class D will have CBO = 1, as it is only coupled to class A. Property 5 is not satisfied
because the original classes A and B were disjoint, and the property requires that the coupling
of the merged classes be the sum of their coupling. Property 5 would be satisfied if the
measure counted the number of connections rather than the number of classes that the class of
interest is coupled to.

1.1.2 METRIC 2: Response for a Class (RFC)

3|Page
Chidamber and Kemerer defined another coupling measure, response for class (RFC), The
RFC is the carnality of the set of all methods that can be invoked in response to a message to
an object of the class or by some method in the class. This includes all methods accessible
within the class hierarchy. This metric looks at the combination of the complexity of a class
through the number of methods and the amount of communication with other classes.

The larger the number of methods that can be invoked from a class through messages, the
greater the complexity of the class. If a large number of methods can be invoked in response
to a message, the testing and debugging of the class becomes complicated since it requires a
greater level of understanding on the part of the tester. This metric evaluates
Understandability, Maintainability, and Testability.

Consider again the merging of classes B and C that use methods in class A, and assume that
B and C are disjoint—they do not call each other’s methods. The RFC of the merged class D
will not be the sum of the RFC of B and C if classes B and C used one or more of the same
methods in class A. If RFC was measured by counting the number of uses of external
methods rather than counting the number of methods invoked, property 5 would be satisfied.

1.1.3 METRICS 3: Message Passing Coupling (MPC)

It was introduced by Li and Henry and formalized by Briand, Daly, and Wüst (Li and Henry
1993, Briand et al. 1999b). The MPC value of a class is a count of the number of static
invocations (call statements) of methods that are external to the class. MPC satisfies all of the
properties of cohesion including property 5.

Robert C. Martin defines two package-level coupling measures (Martin 2003). These indicate
the coupling of a package to classes in other packages:

1. Afferent coupling (Ca): “The number of classes from other packages that depends on
the classes within the subject package.” Only “class relationships” are counted, “such
as inheritance and association.” Ca is really the fan-out of a package.
2. Efferent coupling (Ce): “The number of classes in other packages that the classes in
the subject package depend on” via class relationships. Ce is a form of the fan-in of a
package. These measures satisfy all of the properties in Section including property 5
as long as a class can only belong to a single package.

4|Page
Martin suggests that high efferent coupling makes a package unstable as it depends on too
many imported classes. He defines the following instability (I) metric:

I= Ce/Ca+Ce.

Thus, a package becomes unstable as its efferent (fan-in) increases. This is because the
package depends on a relatively greater number of imported classes, which makes the
package more prone to problems due to changes, faults, etc. in imported classes. Martin does
not provide an empirical relation system or set of properties that we can use to evaluate the
intuition behind the instability metric.

1.2 Measuring Cohesion in Object-Oriented Systems

Cohesion is the degree to which methods within a class are related to one another and work
together to provide well-bounded behaviour. Effective object-oriented designs maximize
cohesion since it promotes encapsulation.

Class cohesion is an intraclass attribute. It reflects the degree to which the parts of a class—
methods, method calls, fields, and attributes belong together. A class with high cohesion has
parts that belong together because they contribute to a unified purpose. Most of the proposed
cohesion metrics are class-level metrics.

Cohesion Properties

1. Nonnegativity and normalization: Module cohesion is normalized so that it is between

zero and one.
2. Null value: A module whose elements have no links between them has zero cohesion.
3. Monotonicity: Adding links between elements in a module cannot decrease the
cohesion of the module.
4. Merging modules: Merging two unrelated modules creates a new module with a
maximum cohesion no greater than that of the original module with the greatest
cohesion.

5|Page
1.2.1 METRICS 1: Lack of Cohesion Metric (LCOM)

Here, the cohesion of a class is characterized by how closely the local methods are related to
the local instance variables in the class. LCOM is defined as the number of disjoint (i.e.,
nonintersecting) sets of local methods. Two methods in a class intersect if they reference or
modify common local instance variables. LCOM is an inverse cohesion measure; higher
values imply lower cohesion. Briand, Daly, and Wüst found that LCOM violates property 1
of Section 9.1.4, as it is not normalized (Briand et al. 1998). Since LCOM indicates inverse
cohesion, properties 2 through 4 are also not satisfied.

1.2.2 MERICS 2: Tight class cohesion (TCC) and loose class cohesion (LCC)

Are based on connections between methods through instance variables (Bieman and Kang
1995). Two or more methods have a direct connection if they read or write to the same
instance variable. Methods may also have an indirect connection if one method uses one or
more instance variables directly and the other uses the instance variable indirectly by calling
another method that uses the same instance variable. TCC is based on the relative number of
direct connections:

TCC(C) = NDC(C)/NP(C)

where NDC(C) is the number of direct connections in class C and NP(C) is the maximum
number of possible connections. LCC is based on the relative number of direct and indirect
connections:

LCC(C) = (NDC(C) + NIC(C))/NP(C)

where NIC(C) is the number of indirect connections. The measures do not include constructor
and destructor methods in the computation, since they tend to initialize and free all instance
variables and will thus artificially increase the measured cohesion. Both TCC and LCC
satisfy all four cohesion properties

6|Page
1.2.3 METRICS 3: Ratio of Cohesive Interactions (RCI)

It is defined in terms of cohesive interactions (CIs), which include interactions between

public data declarations and interactions between method parameters and return types in
public method interfaces (Briand et al. 1998). RCI is the relative number of CIs:

RCI(C) = NCI(C)/NPCI(C)

where NCI(C) is the number of actual CIs in class C and NPCI(C) is the maximum possible
number of CIs. RCI satisfies all four cohesion properties.

Robert C. Martin defines the cohesion of a package in a manner similar to that of class
cohesion (Martin 2003):

Package relational cohesion RC(P) = (R(P) + 1)/N(P)

where R(P) is the number of relations between classes and interfaces in a package and N(P) is
the number of classes and interfaces in the package. A one is added to the numerator so that a
package with one class or interface will have H = 1.

H does not satisfy property 1 of the cohesion properties in Section 9.1.4 because H is not
normalized between zero and one. Property 1 can easily be satisfied by changing the
denominator to the number of possible relations, which is N(P) × (N(P) − 1), assuming a
maximum of one relation between two classes or interfaces. H also does not satisfy property
2 of the cohesion properties since H cannot be zero.

However, it can approach zero as more unrelated classes are added. Thus, we revise package
relational cohesion as follows:

RC′(P) = (R(P) + 1)/NP(P)

7|Page
where NP(P) is the number of possible relations between classes and interfaces in the
package.

1.3 Object-Oriented Length Measures.

Length measures indicate the distance from one element to another. In object-oriented
systems, distances depend on the perspective and the model representing an appropriate view
of the system. One common application of distance measures involves inheritance trees as
depicted in UML class diagrams.

The DIT metric tells us how deep a class is in an inheritance hierarchy. We also learn
something about inheritance by determining the distribution of DIT values for all classes in a
system, subsystem, and package.

1.3.1 METRICS: Depth of Inheritance Tree (DIT)

A class diagram is represented as a hierarchy or tree of classes. The nodes in the tree
represent classes, and for each such class, the DIT metric is the length of the maximum path
from the node to the root of the tree. Chidamber and Kemerer claim that DIT is a measure of
how many ancestor classes can potentially affect this class. This claim could only pertain to
effects due to inheritance relations, and would not be accurate due to multiple inheritance in
C++ or the use of hierarchies of interfaces in Java (which were unknown in 1994).

The deeper a class is within the hierarchy, the greater the number methods it is likely to
inherit making it more complex to predict its behaviour. Deeper trees constitute greater
design complexity, since more methods and classes are involved, but the greater the potential
for reuse of inherited methods.

1.4 Object-Oriented Reuse Measurement

One of the key benefits of object-oriented development is its support for reuse through data
abstraction, inheritance, encapsulation, etc. This support helps developers to reuse existing
software components in several ways. Depending on the development language, they can
reuse existing packages and classes in a verbatim fashion without changes. Developers can
also reuse existing packages and classes as well as interfaces, types, generics, and templates

8|Page
in a leveraged fashion by overriding and overloading inherited methods, by implementing
interfaces, instantiating generic classes or templates.

Measurement of reuse involves an analysis of the structures and models used to design and
implement an object-oriented system. In addition, you can measure reuse from one or both of
two perspectives:

1. Client perspective: the perspective of a new system or system component that can
potentially reuse existing components, and
2. Server perspective: the perspective of the existing components that may potentially
be reused, for example, a component library or package (Bieman and Karunanithi
1995). From the client perspective, the potential reuse measures include the number
of direct and indirect server classes and interfaces reused.

1.4.1 METRICS: The Number of Children (NOC)

This metric relates to a node (class or interface) in an inheritance tree or UML class diagram.
NOC is computed by counting the number of immediate successors (subclasses or sub
interfaces) of a class or interface. NOC is a direct server reuse measure.

The number of children is the number of immediate subclasses subordinate to a class in the
hierarchy. It is an indicator of the potential influence a class can have on the design and on
the system. The greater the number of children, the greater the likelihood of improper
abstraction of the parent and may be a case of misuse of sub classing. But the greater the
number of children, the greater the reusability since inheritance is a form of reuse.

1.5 MOOD (Metrics for Object Oriented Design)

1. Method Hiding Factor (MHF) – MHF is defined as the ratio of sum of the
invisibilities of all methods defined in all classes to the total number of methods
defined in the system. The invisibility of a method is the percentage of the total
classes from which this method is not visible. MHF is proposed to measure the
encapsulation (the relative amount of information hidden). as MHF increases, the

9|Page
 defect density and the effort spent to fix is expected to decrease. Inherited methods
are not considered.

2. Attribute Hiding Factor (AHF) – AHF is calculated as the ratio of the sum of the
invisibilities of all attributes defined in all classes to the total number of attributes
defined in the system.

3. Method Inheritance Factor (MIF) – MIF measures the ratio of the sum of the
inherited methods in all classes of the system to the total number of available methods
for all classes.

4. Attribute Inheritance Factor (AIF) – AIF measures the ratio of sum of inherited
attributes in all classes of the system under consideration to the total number of
available attributes.

The impact of these metrics on different components of Object-Oriented system is

summarized below:

 Class – Class is the fundamental unit of object-oriented design. So, the class level
metrics can be a good judge on the quality of design. WMC measures the complexity
of the methods. LCOM reflects on the cohesiveness amongst classes.

 Attribute – Attributes define the properties of a data object. AHF and LCOM metric
are crucial metrics which reflect on the usage of attributes.

 Method – Methods are invoked to perform operations. WMC and LCOM reflect on
the design and usage of methods.

 Coupling and Cohesion – The most essential metrics are the ones related to
Coupling and Cohesion. They not only measure systems structural complexity but
also are used to assess design. A class is coupled with one more class if the methods
of one class use the methods or attributes of the other classes. Many maintenance
challenges can be directly attributed to high-level of coupling and low level of
cohesion.

Conclusion

10 | P a g e
Object-orientation affects the structure of most elements of a software implementation,
design, and requirements. In particular, we examined how coupling and cohesion can be
measured in object-oriented systems at various levels of abstraction. We applied specific
coupling and cohesion measurement properties, and examined the measurement of
inheritance, object-oriented reuse, and measurement involving design pattern use and misuse.

References
[1] Richard Leblanc. Software metrics: a rigorous and practical approach, Chair,
Department of Computer Science and Software Engineering, Seattle University.

[2] Chidamber, Shyam and Kemerer, Chris, “A Metrics Suite for Object-Oriented Design”,
IEEE Transactions on Software Engineering, June, 1994.

11 | P a g e