Software Metrics

Software metrics are essential to improve the quality of an application during the
development process. Coupling and Cohesion measures are used in tasks such as
impact analysis, assessing the fault proneness of classes, fault Prediction, re-
modularization, identifying of software component, design patterns, assessing
software quality etc.High Cohesion and low Coupling is better for good software
quality. Coupling and Cohesion is applied at the early phase of the development.
Coupling and cohesion is applied at the opposite end. This paper reviews Coupling
and Cohesion metrics used in Object Oriented environment.

Key words: - Software Metrics, Coupling, Cohesion,

Correlation, Interdependence.

1.INTRODUCTION
In field of Software engineering Coupling and Cohesion measures the degree or the
strength of interaction and relationships among elements of the source code,
elements can be classes, methods, and attributes in object-oriented (OO) software
systems [1].

Stevens et al. first introduced Coupling. According to definition of him 'Coupling is

the measure of the strength of association established by a connection from one
module to another' [2].To solve and modify a module separately, the module to be
loosely coupled with other module. Reusability and Maintainability are the
advantages of low coupling [3]. Cohesion is also defined by Stevens. In their
definition 'Cohesion can

advantages of low coupling[3]. Cohesion was first introduced by Stevens 'Cohesion

can be measured by inspecting the connection between all pairs of its processing
elements' [4]. Reusability, Maintainability and Extensibility are advantages of high
Cohesion [5]. Following tables describe the levels of Coupling and Cohesion [2].

Content(High) Where two modules branches into, changes data or alters a statement
in another modules
Common Where two modules access the same global variables.
External Where two modules access heterogeneous
Global data.
Control Where one module passes a parameter to a second module to control
behavior in the second module.
Stamp Where two modules accept the same record as a parameter.
Data Where two modules communicate via parameters.
No coupling Modules do not
Communicate at all with one another.

Table1:Coupling levels

Level Description

No association between two processing elements.

1 Coincidental
2 Logical At each invocation of the module, one of the elements is executed
3 Classical Weak association among sequential elements.
4 Procedural Both elements are sequentially part of the same iteration or operation.
5 Communicational Both elements use the same input and/or output data set.
6 Sequential The output of one element provides the input to another.
7 Functional The elements perform a single specific function.

Table2: Cohesion levels

2. REVIEW OF COUPLING METRICS

STATIC COUPLING METRICS

Different-different Coupling metrics were purposed by many authors .Each metric has
own definition.

2.1 Chidamber and Kemerer Metrics [6,7] C&K metrics are most accepted and widely
used metrics.

[2.1.1] Coupling between Object (CBO) Classes is the number of other classes with
which a class is coupled to. A class is coupled with another class if the methods of
class use the methods or attributes of the other or vice versa. It include inheritance
based coupling (i.e. coupling between classes related via inheritance). A previous
variant of CBO excludes inheritance-based coupling.
[2.1.2] Response for class (RFC)
RFC = | RS | where RS is the response set for the class. The response set for the
class can be expressed as:
RS = { M }''all i { Ri }
Where { Ri } = set of methods called by method i and { M } = set of all methods in the
class.
The response set of a class = A set of methods that can potentially be executed in
response to a message received by an object of that class. The cardinality of this set
is a measure of the attributes of objects in the class.

2.2 Li and Henry Metrics [8]Li and Henry's metrics can predict the maintainability of
a software design. They define two measures:-
[2.2.1]Message passing coupling (MPC) is the total number of function and procedure
calls to made to external unit.
[2.2.2] Data abstraction coupling (DAC) is count of total number of instance of other
classes within a given class.
2.3 Abreu et al.[9]. Coupling Factor (COF) for the design quality evaluation of object-
oriented software systems.COF can be defined as the actual number of client-server
relationships between classes that are not related via inheritance divided by the
maximum possible number of such client-server relationships. It is normalised to
range between 0 and 1 to allow for comparisons for systems of different sizes. This
metric not specified how to account for such factors as polymorphism.
2.4 Martin Metrics [10]. Martin gave two coupling metrics and these metrics can be
used to measure the quality of an object-oriented design in terms of the
interdependence between the subsystems of that design.
[2.4.1] Afferent Coupling (Ca) is the number of classes outside this category that
depend upon classes within this category. Afferent coupling is used to measure the
quality of an object-oriented design in terms of the interdependence between the
subsystems of that design.

[2.4.2] Efferent Coupling (Ce) is the number of classes inside this category that
depend upon classes outside this category. Where, a category is a set of classes
that belong together in the sense that they achieve some common goal. Martin does
not specify exactly what constitutes dependencies between classes.

2.7 Bansiya et al. QMOOD [11] purposed Direct Class Coupling Metric (DCC). It is a
count of different number of classes that a class is directly related to.

2.8 Chen et al. [12] Metrics used to know the behaviour of metrics in Object-Oriented
design.
[2.8.1]Class Coupling Metric (CCM)
[2.8.2]Operating Coupling Metric (OCM)

RUNTIME/DYNAMIC COUPLING MEASURE

2.9 Yacoub et al.[13] Yacoub proposed a set of dynamic metrics. These are
following.
[2.9.1]Export Object Coupling (EOCx(oi; oj)) for an object oi with respect to an object
oj, is defined as the percentage of the number of messages sent from oi to oj with
respect to the total number of messages exchanged during the execution of scenario
x.

[2.9.2]Import Object Coupling (IOCx(oi; oj)) for an object oi with respect to an object
oj , is the percentage of the number of messages received by object oi that were
sent by object oj with respect to the total number of messages exchanged during the
execution of a scenario x.

2.10 Arisholm et al.[14] List of number of dynamic coupling metrics defined by

Arisholm et al. Each dynamic coupling metric name starts with either I or E based on
the direction of the method calls. Here 'I' stands for import or 'E' stands for export.
The third letter C or O distinguishes whether entity of measurement is the object or
the class. The remaining letter distinguishes three types of coupling.

Variable Description

IC CC Import, Class Level, Number of Distinct Classes

IC CM Import, Class Level, Number of Distinct Methods
IC CD Import, Class Level, Number of Dynamic Messages
EC CC Export, Class Level, Number of Distinct Classes
EC CM Export, Class Level, Number of Distinct Methods
EC CD Export, Class Level, Number of Dynamic Messages
IC OC Import, Object Level, Number of Distinct Classes
IC OM Import, Object Level, Number of Distinct Methods IC OD Import, Object Level,
Number of Dynamic Messages
EC OC Export, Object Level, Number of Distinct Classes
EC OM Export, Object Level, Number of Distinct Methods
EC OD Export, Object Level, Number of Dynamic Messages

Table3:-Abbreviations for the dynamic coupling metrics of Arisholm et al.

C = counts the number of distinct classes that a method in a given class/object uses
or is used by.
M = counts the number of distinct methods invoked by each method in each
class/object while
D = counts the total number of dynamic messages sent or received from one
class/object to or from other classes/objects.

2.11 Hassoun et al[15] Dynamic Coupling Metric (DCM) was purposed by Hassoun et
al.It is used to measure the coupling of particular objects and/or the entire system at
runtime. The DCM is also used to predict the runtime complexity of a system.

2.12 Beszedes et al. [16] Dynamic Function Coupling (DFC) may be defined as the
minimal level of indirection between all possible occurrences of the two functions in
the traces.

2.13 Singh et al.[17] Singh and Singh proposed five class-level dynamic coupling
metrics to assess the quality of object oriented software systems.
[2.13.1]Dynamic Afferent Coupling (DCa) the percentage of number of classes
accessing the methods of a class at runtime to the total number of classes.
[2.13.2] Dynamic Key Server Class (DKSC) the percentage of number of calls sent to
a class at runtime to the total number of static calls sent to all the classes.'
[2.13.3] Dynamic Key Client Class (DKCC)the percentage of number of calls sent by a
class at runtime to the total number of static calls sent by all the classes.
[2.13.4] Dynamic Key Class (DKC) the percentage of sum of calls sent out from the
class and calls received by the class at runtime taken over the total number of static
calls sent and received by all the classes.
[2.13.5] Percentage Active Classes (PAC) the percentage of number of classes
sending or receiving at least one method calls from/to another class at runtime to
the total number of classes.
REVIEW OF COHESION METRICS

2.14 Chidamber and Kemerer Metrics [19]

[2.14.1]The Lack of Cohesion in Methods (LCOM1) the metric was proposed by

Chidamber and Kemerer. LCOM1 is defined by the number of pairs of methods that do
not share attributes.
[2.14.2]The metric was proposed by Chidamber and Kemerer.
LCOM2= P ' Q if P ' Q'0
0 otherwise.
Where, P=number of pairs of methods that do not share attributes. And Q=number of
pair of methods that share attributes.

2.12Briand et al. Metrics [20] purposed high level design metrics for Object-Oriented
system.
[2.15.1]Ratio of Cohesive Interactions (RCI)
The Ratio of Cohesive Interactions for sp is
RCI(sp) = |CL(sp)|

| M(sp) |
Where,CL(m)=The set of cohesion interaction in a module m.
M(sp)=The maximal set of cohesive interaction of the software part(sp) i.e. the set of
includes all of sp's possible cohesion interaction.
This metric satisfies the properties of Normalization, Monotonicity, Cohesive
modules.
[2.15.2] Neutral Ratio of Cohesive Interactions (NRCI).
Unknown CLs are not taken into account
NRCI(sp) = | K(sp)|
| M(sp)-|U(sp)|
Where, K(sp) = The set of known interactions of a software part (sp)
U(sp) = The set of unknown interaction.
[2.15.3] Pessimistic Ratio of Cohesive Interaction (PRCI).
Unknown CLs are considered as if they were known not to be actual interactions.
PRCI(sp) = | K(sp)|
| M(sp)|
This is equal to RCI(sp)
[2.15.4] Optimistic Ratio of Cohesive Interactions (ORCI).
ORCI = | K(sp)+|U(sp)|
| M(sp) |
2.16 Bieman and Kang Metrics [18]Their work was also based on the work of
Chidamber and Kemerer. Defined measurements known as:-
[2.16.1]Tight Class Cohesion (TCC)-is the relative number of directly connected pairs
of methods, wherein two methods are directly connected if they are directly
connected to an attribute.

[2.16.2]Loose Class Cohesion (LCC) - LCC defines the relative number of directly or
transitively connected pairs of methods, wherein two methods are transitively
connected if they are directly or indirectly connected to an attribute.

2.17 Li and Henry [18] LCOM3 is the number of connected components in graph that
represents each method as a node and the sharing of at least one attribute as an
edge.

2.18 Hitz and Montazeri [18] purposed LCOM4. It is similar to LCOM3, and additional
edges are used to represent method invocations.

2.19Henderson-Sellers [19] proposed a cohesion measure (LCOM5).

LCOM5= (kl-a) (kl-l)
Where, l=number of attributes
k=number of methods
a=summation of the number of distinct attributes that are accessed by each method
in a class.

2.20 Xu and Zhou Metric [21] Improved Cohesion Based on Member Connectivity
(ICBMC):
ICBMC (G) = Fc(G) ?? Fs(G)
Where, Fc (G) ='M (G)'/'N(G)'
M (G) = number of edges in the cut set of G,
N (G) = number of non-special methods represented in graph G multiplied by the
number of
attributes.
Fs (G) = [??ni =ICBMC (Gi)]/ 2
2.21 Yang Metric [22] gave their OLn measure. It is defined as the average strength
of attributes, wherein the strength of the attribute is the average strength of the
methods that reference that attribute. Where 'n' is the number of iterations that are
used to compute OL.

2.22 Badri et al.[23]purposed two metrics for Object-Oriented system.

[2.19.1] DCo- It defines the relative number of directly connected pairs of methods.

[2.19.2] DCi-It defines the relative number of directly or transitively connected pairs
of methods.

2.23 Bonja et al.[18] Class Cohesion (CC) metric is the ratio of the summation of the
similarities between all pairs of methods to the total number of pairs of methods.
The similarity between methods i and j is:
Similarity (I ,j) =| li ' lj /li U lj |
where, li , lj = sets of attributes that are referenced by methods i and j, respectively

2.24 Fernandez et al. [24] purposed Class Cohesion metric (SCOM).This metric is the
ratio of the summation of the similarities between all pairs of methods to the total
number of pairs of methods. The similarity between methods i and j is defined as:
Similarity (i,j) =| li ' lj| .| li U lj|

2.25 Jehad Al Dallal Metrics [18] purposed Path Connectivity Class Cohesion (PCCC)

PCCC = 0 if l = 0 and k >1,

1 if l > 0 and k = 0,
NSP (Gc )/ NSP(FGc) otherwise.
Where, l=no. of attributes
K=no. of methods
NSP = number of simple paths in graph Gc
FGc = corresponding fully connected graph

2.26Michael Bowman et al. [25] proposed an approach based on a multi-objective

genetic algorithm (MOGA) which uses class coupling and cohesion measurement for
defining fitness functions. Their work has some similarity with refactoring. They did
most of the work on source code refactoring, though it is believed that refactoring
achieves higher levels of abstraction, such as refactoring of UML models

2.27 Jehad et al. [18] purposed Method-Method through Attributes Cohesion (MMAC)
MMAC(C) = 0 if l = 0 and k =0,
1 if k = 1,
??li=1xi(xi-1) otherwise
lk(k-1)
where,
l = no. of attributes
k = no. of methods
xi = number of methods that have a or a return type j.

RUNTIME/DYNAMIC COHESION MEASURE

2.28 Gupta et al. Metrics [26,27] Bieman and Ott [26]purposed the concept of Strong
Functional Cohesion and Weak Functional Cohesion and their work is redefined by
Gupta et al. [27].Gupta et al commence the dynamic cohesion measurement using
program execution based approach on the basis of dynamic slicing.

2.30 Mitchell et al. [1] provide a new technique for collecting dynamic trace
information from Java GUI programs and a number of simple runtime metrics are
proposed.
[2.30.1]The exPubMet.Ob metric gives an estimation of level of coupling present in a
GUI program and The
[2.30.2]priMet.ob metric shows that simple programs devote a greater proportion of
their method access to the internal working of their classes than the GUI program.

3.CONCLUSION AND FUTURE WORKS

This paper does not purpose new measure. This is only a review paper. Some
Coupling and Cohesion Metrics are discussed. These metrics can be helpful for
researcher and developer. Future work can be on more metrics which are not
discussed in this paper. We have discussed a few dynamic metrics.So researchers
can do work on dynamic metrics.