IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

838

PAPER

Special Section on Knowledge-Based Software Engineering

A Class Cohesion Metric Focusing on Cohesive-Part Size
Hirohisa AMAN†a) , Member, Kenji YAMASAKI† , Nonmember,
Hiroyuki YAMADA† , Member, and Matu-Tarow NODA† , Nonmember

SUMMARY Cohesion is an important software attribute, and it is oneof significant criteria for assessing object-oriented software quality. Although several metrics for measuring cohesion have been proposed, there
is an aspect which has not been supported by those existing metrics, thatis “cohesive-part size.” This paper proposes a new metric focusing on“cohesive-part size,” and evaluates it in both of qualitative and quantitative ways, with a mathematical framework and an experiment measuringsome Java classes, respectively. Through those evaluations, the proposed
metric is showed to be a reasonable metric, and not redundant one. It cancollaborate with other existing metrics in measuring class cohesion, andwill contribute to more accurate measurement.
key words: object-oriented software, metrics, cohesion, mathematicalframework, correlation analysis

1. Introduction
Cohesion is one of important attributes for software module, representing the degree to which its components arefunctionally connected within the module [1]–[3]. This attribute could be applied to object-oriented software, wherea class corresponds to a module, and its attributes and methods correspond to the module components. In general, highlevel cohesion may lead to high maintainability, reusability
and reliability [4], [5], so that class cohesion would be oneof important criteria for assessing object-oriented software
quality.
For measuring class cohesion, several metrics havebeen proposed, such as “Lack of Cohesion in Methods (LCOM)” [6]–[10], “Information flow-based Cohesion(ICH)” [11], “Tight Class Cohesion (TCC)” and “LooseClass Cohesion (LCC)” [12]. These metrics are mainly
based on “the number of sets of connected methods,” or“the density of method-connections/attribute-accesses” in aclass. However there is an aspect of cohesion which has
not been supported by the above metrics. That is “size ofcohesive-part” in a class, in other words, “extent of associations among methods” through attribute-accesses and/or
method-invocations in a class. In order to support such lacking aspect, and to contribute more accurate measurement ofcohesion, this paper proposes a new cohesion metric focusing on cohesive-part size, and evaluates it in both of qualitative and quantitative ways.
Manuscript received June 20, 2003.
Manuscript revised September 26, 2003.
†
The authors are with the Department of Computer Science,
Faculty of Engineering, Ehime University, Matsuyama-shi, 790–
8577 Japan.
a) E-mail: aman@cs.ehime-u.ac.jp

The rest of this paper is organized as follows. Section
2 briefly describes the existing eight metrics for measuringclass cohesion. Section 3 presents a new cohesion metricfocusing on cohesive-part size, and Sect. 4 evaluates it inboth of qualitative and quantitative ways. Section 5 gives
our conclusions and future works.
2. Existing Class Cohesion Metrics
Several metrics are proposed in order to measure cohesionof object-classes [6]–[12]. This section presents some brief
descriptions of those existing metrics. See the literature [5]for their detailed discussion.
2.1 Lack of Cohesion in Methods (LCOM)“Lack of COhesion in Methods” (LCOM) is a well-knownclass cohesion metric which quantifies poorness of cohesion. The higher value represents the lower cohesion, andvice versa. LCOM has thus far been discussed by several
researchers [6]–[10]. Through their works, there are the following five diﬀerent types of LCOM. These metrics havestudied on usefulness as predictors or indicators of maintenance eﬀort [13], fault-proneness [14] and so on.
2.1.1 LCOM by Chidamber and Kemerer
The original LCOM is defined by Chidamber and Kemerer [6]. Their approach is based on whether the each pairof methods are sharing an attribute or not in a class. Those
attribute-sharing relationships mean that diﬀerent methods
are accessing to the same attribute. Chidamber and Kemerer
define LCOM as the number of method-pairs which are notsharing any attributes. LCOM value represents a weaknessof functional connections among methods in a class. For thesake of convenience, we will call the metric “LCOM1.”
Here is a formal definition of LCOM1.
Definition 1 (LCOM1):
Given a class C. Let M be the set of all methods in C, and A
be the set of all attributes in C. LCOM1 value of C is definedas LCOM1(C) = |P|, where
P = {m1 , m2 } | m1 , m2 ∈ M,a ∈ A s.t. both of m1 and m2 access to a .
AMAN et al.: A CLASS COHESION METRIC FOCUSING ON COHESIVE-PART SIZE

839

In the literature [7], Chidamber and Kemerer propose
another definition of LCOM. We will call it “LCOM2.”
LCOM2 takes into account the following two diﬀerent factors : (1) the number of method-pairs which are “not sharing” any attributes, and (2) the number of method-pairs
which are “sharing” an attribute. The above two factors havecomplementary meanings each other. The former is a weakening factor for cohesion, while the latter is a strengthening
factor for one. LCOM2 combines those factors.
The following is a formal definition of LCOM2.
Definition 2 (LCOM2):
Given a class C. Let M be the set of all methods in C, and A
be the set of all attributes in C. LCOM2 value of C is defined
as follows :|P| − |Q|, if |P| > |Q| ;LCOM2(C) =0,otherwise.
where P is the set described in Def. 1, and
Q = {m1 , m2 } | m1 , m2 ∈ M,

relationships are based on “direct” accesses to attributes bymethods. Hitz and Montazeri propose another LCOM taking into account such accesses via “access-methods.” We
will call it “LCOM4.”
The following is a formal definition of LCOM4.
Definition 4 (LCOM4):Given a class C. Let M be the set of all methods in C, andA be the set of all attributes in C. Consider an undirected
graph GC = (V, E) with V = M and
E = {m1 , m2 } | m1 , m2 ∈ M,(∃a ∈ A s.t. both of m1 and m2 access to a)or (m1 invokes m2 ) .
LCOM4 value of C is defined as LCOM4(C) = k(GC ), wherek(GC ) is the number of connected components in GC .

2.1.3 LCOM by Henderson-Sellers∃a ∈ A s.t. both of m1 and m2 access to a .


2.1.2 LCOM by Hitz and Montazeri
Hitz and Montazeri propose a diﬀerent LCOM [8] using thegraph theory. Their approach is also based on the above
attribute-sharing relationships, and those relationships are
represented by an undirected graph. Now a class corresponds to an undirected graph, where each vertex represents each method, and each edge means each attributesharing relationship. Hitz and Montazeri define LCOM as
the number of “connected components† [15]” in the undirected graph. We will call it “LCOM3.” LCOM3 value indicates the number of disjoint sets of methods in terms of theattribute-sharing relationship.
Here is a formal definition of LCOM3.
Definition 3 (LCOM3):Given a class C. Let M be the set of all methods in C, andA be the set of all attributes in C. Consider an undirected
graph GC = (V, E) with V = M and
E = {m1 , m2 } | m1 , m2 ∈ M,
∃a ∈ A s.t. both of m1 and m2 access to a .
LCOM3 value of C is defined as LCOM3(C) = k(GC ), wherek(GC ) is the number of connected components in GC .

Hitz and Montazeri also discuss some eﬀects of“access-methods” upon LCOM values [9]. Access-methods
are methods to provide reading/writing-accesses to attributes. These methods are sometimes called “accessors”
or “getters and setters.” When two or more methods accessto an attribute via “access-methods”, we have no attributesharing relationships, because the above attribute-sharing

Henderson-Sellers proposes LCOM in a diﬀerent way [10].
We will call it “LCOM5.” LCOM5 value is characterized
by the following two cases: (i) if each method accesses to“all” attributes, the LCOM5 value is 0; (ii) if each method
accesses to “only one” attribute, the LCOM5 value is 1. The
case (i) means the most cohesive class, while the case (ii)means a less cohesive one. LCOM5 represents cohesionlevels using these two cases as benchmarks.
Here is a formal definition of LCOM5.
Definition 5 (LCOM5):Given a class C. Let M be the set of all methods in C, and A
be the set of all attributes in C. For each a ∈ A, let µ(a) be
the number of methods accessing to the attribute a.
LCOM5 value of C is defined as follows :





1
1
µ(a) .
LCOM5(C) =|M| −|M| − 1
|A| a∈A

2.2 Information Flow Based Cohesion (ICH)
Lee et al. propose a cohesion metric based on information
flows between methods [11]. The approach focuses on thenumber of method-invocations weighted by the number of
their parameters. Using the number of method parameters,
the metric takes into account a strongness of link between
methods. The metric is called “Information flow based CoHesion (ICH).”The following is a formal definition of ICH.
Definition 6 (ICH):
Given a class C. Let M be the set of all methods in C. For
m1 , m2 ∈ M, let ν(m1 , m2 ) be the number of invocations of
m2 by m1 , and π(m2 ) be the number of m2 ’s parameters.
†
A connected component is a maximal sub graph in which allvertexes are reachable each other.

IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

840
Table 1

Summary of existing class cohesion metrics.

metricsummary

LCOM1
LCOM2
LCOM3
LCOM4
LCOM5
ICH
TCC
LCC

number of method-pairs which do not share any attributes.
LCOM1 − (the number of method-pairs which share an attribute).
number of method-sets in which the methods are connected in terms of attribute-sharing.
revised version of LCOM3 considering indirect attribute-sharing via access-method.
density of accesses to attributes by methods.
number of method-invocations weighted by the number of method parameters.
density of attribute-sharing relationships among public methods.
density of relationships among public methods,
where the relationships are in the transitive closure of attribute-sharing relationships.

ICH value of C is defined as follows : 
ICH(C) =(1 + π(m2 )) · ν(m1 , m2 ).
m1 ∈M m2 ∈M

3. A New Class Cohesion Metric

2.3 Tight Class Cohesion (TCC) and Loose Class Cohesion (LCC)
Bieman and Kang propose a couple of class cohesion
metrics which are called “Tight Class Cohesion (TCC)”
and “Loose Class Cohesion (LCC)” [12]. TCC represents
a density of attribute-sharing relationships between public methods in a class. LCC represents a density of extended attribute-sharing relationships between public methods, where those extended relationships are constructed by
the transitive closure of the above attribute-sharing relationships. These metrics have studied on usefulness as indicators of reusability for object classes [12].
We present definitions of TCC and LCC.
Definition 7 (TCC, LCC):
Given a class C. Let M p be the set of all public methods in
C, and A be the set of all attributes in C.
When a method m uses an attribute a in the method
body, we say “m directly accesses to a.” If a method m invokes another method m1 , m1 invokes m2 , . . ., mn−1 invokes
mn (n ≥ 1) and mn directly accesses to an attribute a, thenwe say “m indirectly accesses to a.” Now consider the following two sets :
T = {m, m } | m, m ∈ M p ,∃a ∈ A s.t. m and mdirectly or indirectly access to a ,andm = m1 , m = mk , k > 1,
{m j , m j+1 } ∈ T ( j = 1, . . . , k − 1) .
TCC and LCC values of C are defined as follows :|T | + |L||T |, LCC(C) =,TCC(C) =|M p ||M p |
22
where= |M p |(|M p | − 1)/2.

We have introduced eight metrics : LCOM1∼5, ICH, TCC
and LCC. Table 1 shows a summary of them. LCOM1∼4
are based on the numbers of pairs/sets of methods connectedby attribute-sharing relationships. LCOM5 presents a density of accesses to attributes by methods. ICH shows thenumber of method-invocations weighted by the number ofmethod parameters. TCC and LCC are based on densities
of attribute-sharing relationships among methods. However,they do not consider “extents” of attribute-sharing relationships among methods, in other words, “sizes of cohesiveparts” in a class. Since the higher cohesive class would havethe lager cohesive-parts, such aspect is also one of the cohesion aspects to be measured. This section proposes a cohesion metric focusing on cohesive-part size.
3.2 Preliminaries
Preliminary to the development of our metric, we define several underlying notions.
At first, we define a mathematical relation between
methods through method-invocations.
Definition 8 (binary relation on methods):
Given a class. Let M be the set of all methods in the class.
We define a binary relation S as follows :
S = (m1 , m2 ) | m1 , m2 ∈ M, m1 invokes m2 .
Now we can obtain the reflective transitive closure S ∗ asfollows :





∗
S =
(m1 , m2 )  m1 , m2 ∈ M,




 



n
(m1 = m2 ) ∨ m1 S m2  ,
L = {m, m } | ∃{mi ∈ M p }ki=1 s.t.

|M p |
2

3.1 Motivationn≥1

where S n = S n−1 ◦ S (n ≥ 2), and S 1 = S ; “◦” indicates thecomposition of relations [16].
S ∗ represents directly or indirectly method-invocations.
Now we define a relationship between a method and an
attribute.

AMAN et al.: A CLASS COHESION METRIC FOCUSING ON COHESIVE-PART SIZE

841

Definition 9 (accesses to attributes by methods):
Given a class. Let M be the set of all methods, and A be theset of all attributes, in the class. For any m ∈ M, a ∈ A, wedefine a predicate ac as follows :de fac(m, a) ⇐⇒∃m ∈ M s.t. (m S ∗ m ) ∧ (m accesses a) ,where an “access” means a direct access to an attribute by amethod.
The predicate ac considers not only direct accesses toattributes but also indirect accesses to ones via accessmethods. Using the predicate, we introduce a graph model.
Definition 10 (association-graph):
Given a class. Let M be the set of all methods, and A be theset of all attributes, in the class. We define the associationgraph as an undirected graph Ga = (V, E), where V = M
and
E = {m1 , m2 } | m1 , m2 ∈ M, m1  m2 ,∃a ∈ A s.t.
ac(m1 , a) ∧ ac(m2 , a) .

Using the association-graph and the sets of reachable methods, we propose a metric for measuring class cohesion,
which is called “Association-Extent based Class Cohesion(AECC).”
Definition 12 (AECC):
Given a class C. Let M be the set of all methods, and A be
the set of all attributes, in C. Consider the association-graph
Ga = (V, E) for C, where V = M and E is in Eq. (1). For
each method m ∈ M, let Ra (m) be the set of all methods
which are reachable by m in Ga (see Eq. (2)).
Define Association-Extent based Class Cohesion(AECC) value of C as follows :|Ra (m)|, (|M| > 1),
 max
AECC(C) = (3)m∈M|M| − 1
 0,(|M| = 1).
(1)

3.4 Meanings of the Proposed MetricFor each method m, |Ra (m)|/(|M| −1) denotes the percentage
of methods to be reachable by m in the association-graph;“−1” in the numerator represents excluding m itself from thepercentage calculation. AECC is the maximum percentage
for all methods in the class. Since Ra (m) forms a cohesivepart in which all methods are directly or indirectly linked
through attribute-sharing relationships, |Ra (m)|/(|M|−1) represents the relative size of the cohesive-part including m, inother words, |Ra (m)|/(|M|−1) denotes the extent of attributesharing relationships. That is, AECC quantifies the maximum extent of attribute-sharing relationships among methods in the class. Since the higher cohesive class would havethe lager cohesive-parts, AECC represents an aspect of classcohesion.
Although AECC is similar to TCC and LCC, AECC isessentially diﬀerent from them. TCC and LCC calculate“densities” of attribute-sharing relationships among methods. However, AECC represents the maximum “extent” of
attribute-sharing relationships. While the “density” is basedon the number of attribute-sharing relationships, the “extent” corresponds to the connectivity among methods via
attribute-sharing relationships.

When two or more methods access to one attribute, thosemethods seem to share the attribute. The association-graph
Ga represents those attribute-sharing relationships between
methods in a class. In Ga , if there is a path from a method
to another method, those methods share an attribute directly
or indirectly. Those relationships correspond to the reachabilities in the graph.
Definition 11 (set of reachable methods):
Given a class. Let M be the set of all methods, and A be theset of all attributes, in the class. Consider the associationgraph Ga = (V, E), where V = M and E is described in
Eq. (1).
For each method mi ∈ M (i = 1, . . . , |M|), define the setof reachable methods, Ra (mi ), as follows :Ra (mi ) = m j | ∃mk1 , . . . , mk p ∈ M s.t.
(mi = mk1 ) ∧ (m j = mk p ) ∧{mkt , mkt+1 } ∈ E
(t = 1, . . . , p − 1) .

3.3 Definition(2)Ra (mi ) is the set of all methods which are reachable by mi
in Ga . The methods belonging to Ra (mi ) seem to be associated with mi through their attribute-sharing relationships. In
other words, those methods are in the “chain of links” where
methods are directly or indirectly linked through attributesharing relationships. So the methods are functionally connected by the chain of links, and we should not decompose
the set into two or more smaller sets. Ra (mi ) seems to forma cohesive-part of the class including mi , and |Ra (mi )| is involved in the extent of attribute-sharing relationships.

3.5 Examples
We now present a simple example of calculating AECC
value. Consider a class shown in Fig. 1, who has sevenmethods M = {m1 , . . . , m7 } and four attributes A ={a1 , . . . , a4 }. Fig. 2 shows its structure† .
Here the following ten predicates are true :ac(m1 , a1 ), ac(m1 , a2 ), ac(m2 , a1 ), ac(m3 , a2 ),†For the sake of simplicity, we omit the existence of the superclass “java.lang.Object.”IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

842

public class Example1{
public int m1 (){ return a1 − a2 ; }public void m2 (int arg){ a1 = arg; }public void m3 (int arg){ a2 = arg; }public void m4 (int arg){ a3 = arg; m5 (arg); }public void m5 (int arg){ a4 = arg; }public int m6 (){ return a3 + m7 (); }Fig. 4

public int m7 (){ return a4 ; }}An example of class model (2).

private int a1 , a2 , a3 , a4 ;Table 2
Fig. 1

An example of class written in Java.

Fig. 2

An example of class model (1).

Fig. 3

association-graph for Fig. 2.

ac(m4 , a3 ), ac(m4 , a4 ), ac(m5 , a4 ), ac(m6 , a3 ),ac(m6 , a4 ) and ac(m7 , a4 ).
Then we can consider the association-graph Ga shown in
Fig. 3. From Fig. 3, we obtain |Ra (m1 )| = |Ra (m2 )| = |Ra (m3 )|= 2 and |Ra (m4 )| = |Ra (m5 )| = |Ra (m6 )| = |Ra (m7 )| = 3. Thus
AECC value of this class is calculated as follows :|Ra (m)|
AECC = maxm∈M|M| − 1


2
3
,
= max
7−1 7−1= 0.5.
This result means that the maximum cohesive-part of theclass makes up 50% of the whole.
We next consider another example, and compare withthe existing eight metrics described in Sect. 2. Fig. 4 shows
another example of class which is made by modifying theclass of Fig. 2 where m4 invokes m2 instead of m5 . In Fig. 4,
all methods are connected through attribute-accesses or
method-invocations, while Fig. 2 has two separated groups{m1 , m2 , m3 } and {m4 , m5 , m6 , m7 }. So the class shown in
Fig. 4 would intuitively be more cohesive than one in Fig. 2.
Table 2 shows metric values of the existing eight metrics

Metric values of the classes in Fig. 2 and Fig. 4.

metricFig. 2

Fig. 4

Fig. 2 → Fig. 4

LCOM1
LCOM2
LCOM3
LCOM4
LCOM5
ICH
TCC
LCC
AECC

17
13
3
2
0.833
3
0.429
0.429
0.5

17
13
3
1
0.833
3
0.333
1.0
1.0

no change
no change
no changeup
no change
no change
down
up
up

(see Table 1) and AECC† for the classes shown in Fig. 2
and 4, and describes their changes in cohesion level†† from
Fig. 2 to Fig. 4. ( For our calculation of ICH, we assume m4
invokes m2 once in the body. )In this case, LCOM4, TCC, LCC and AECC could besensible to the diﬀerence between Fig. 2 and Fig. 4.
LCOM4 represents the number of cohesive-parts in theclass, but it could not represent their sizes, so that LCOM4
essentially diﬀers from AECC.
TCC shows an evaluation which is counter to our intuition “Fig. 4 should have higher cohesion than Fig. 2.” Thereason TCC gives such unusual evaluation is that the total
number of attribute-sharing relationships decreases from 9(in Fig. 2) to 7 (in Fig. 4), i.e., the density of relationships
decreases while the extent of relationships becomes wider
through the change. It is an essentially diﬀerent point between TCC and AECC. Although LCC is also based on thedensity of relationships, LCC uses the transitive closure of
attribute-sharing relationships, so that it could evaluate thediﬀerence successfully.
LCC has a similar tendency to AECC in the above
examples. In order to show a diﬀerence in viewpoint between LCC and AECC, we consider additional two examples shown in Fig. 5 and Fig. 6.
Table 3 shows LCC and AECC values in the cases ofFig. 5 and Fig. 6.
AECC represents a diﬀerence between Fig. 5 andFig. 6, since the maximum extent of attribute-sharing relationships has changed through those examples : Fig. 5†
For the lack of space, we omit their calculation processes. Although we ignore the existence of the super class“java.lang.Object,” we have no inconsistency in comparisons of
those metrics.
††
Notice that LCOM1 ∼ 5 are “reverse” metrics in which thehigher values mean the lower cohesion.

AMAN et al.: A CLASS COHESION METRIC FOCUSING ON COHESIVE-PART SIZE

843

4.1 Qualitative Evaluation
4.1.1 Mathematical Framework

Table 3Fig. 5

An example of class model (3).

Fig. 6

An example of class model (4).

LCC value and AECC value of the classes in Fig. 5 and Fig. 6.
metricFig. 5

Fig. 6

Fig. 5 → Fig. 6

LCC
AECC

0.267
0.444

0.267
0.333

no change
down

has {m1 , m2 , m3 , m4 , m5 } as the largest method-set in which
the methods are connected by some attribute-sharing relationships, but Fig. 6 has smaller set {m1 , m2 , m3 , m4 } as thelargest one. However LCC has no change through those
two examples, because the total number of relationships(on the transitive closure of attribute-sharing relationships)
stays constant between Fig. 5 and Fig. 6. (While m5 has therelationships with m1 , m2 , m3 and m4 in Fig. 5, m5 loses
the relationships with them in Fig. 6. However m5 gets the
new relationships with m6 and m7 ; besides m10 obtains the
new relationships with m8 and m9 in Fig. 6.) Thus the density of relationships has no change. The above comparison
would show a major diﬀerence in viewpoint between LCC
and AECC. Moreover LCC does not take into account “nonpublic” methods while AECC uses all methods in the evaluation; it is also a diﬀerence between LCC and AECC.
Although the above examples are just simple examples,
they might show that AECC supports an aspect of cohesion
which has not been considered by the existing eight metrics.
We will evaluate it in both of qualitative and quantitative
ways in the next section.
4. Evaluations
This section presents evaluations of our AECC in the bothof qualitative and quantitative ways. The qualitative evaluation will describe that AECC satisfies mathematical necessary conditions of cohesion metrics, based on a mathematical framework. The quantitative evaluation will showthat AECC gives the metric values without depending on theother existing metrics described in Sect. 2.

Briand, Morasca and Basili propose a mathematical framework (BMB framework) including some properties to besatisfied by several types of software metrics [17]. The supported types of metrics are “size,” “length,” “complexity,”“coupling” and “cohesion.” Note that BMB framework provides necessary conditions of software metrics, because theframework does not include the all properties to be satisfied
by those metrics. We will use it for checking some mathematical necessary conditions of metrics.
In BMB framework, a software is represented by agraph model in which vertexes are corresponding to thecomponents, and edges are corresponding to coupling relationships between the components. BMB framework suggests the following four properties to be satisfied by cohesion metrics. For the sake of convenience, we will write thecohesion of a class C as “cohe(C).”Property 1 :For any class C, cohe(C) ∈ [0, max] , where max is apositive constant number.
Property 2 :Let G = (V, E) be the graph model of a class C, where
V and E are the vertex set and the edge set, respectively.
Then E = φ =⇒ cohe(C) = 0 .
Property 3 :Consider two classes C and C whose models are G =(V, E) and G = (V, E ), respectively. Then E ⊆ E =⇒cohe(C) ≤ cohe(C ) .
Property 4 :Consider two classes C1 and C2 whose models are
G1 = (V1 , E1 ) and G2 = (V2 , E2 ), respectively. Let C12
be a class whose model is G12 = (V1 ∪ V2 , E1 ∪ E2 ),i.e., C 12 is composed of C1 and C2 . Then∀{u, v} ∈ E1 ∪ E2 [u ∈ V1 ∩ V2 ⇐⇒ v ∈ V1 ∩ V2 ]=⇒ max[ cohe(C1 ), cohe(C2 ) ] ≥ cohe(C12 ) .

Property 1 represents a nonnegativity and a normalization. The nonnegativity is a basic property to be satisfied
by any of mathematical measures [18]. The normalization
brings us meaningful comparisons between diﬀerent metrics.
Property 2 is also a basic property of mathematicalmeasures : the measure of empty set is null. In our context,
if there is no relationships among components in a class,then the class cohesion is null.
Property 3 corresponds to a monotonicity. When somerelationships between components are added in a class,

IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

844

class
Math
Throwable
StringSecurityManager
ClassLoader
Package
StringBuﬀer
SystemThreadThreadGroup
BasicPermission
ArraysInteger
Date
Component
File
FileDescriptor
InputStream
Container
WriterStringWriter
PanelAppletBigInteger
SocketServerSocket
DatagramPacket
FileOutputStream
EventObject
Collections

LCOM1
526
28
1107
1081
1307
204
640
463
887
415
21
4641
269
507
29493
707
3
28
3834
5
21
6
304
3791
63
15
46
45
0
22376

Table 4 Metric values of Java classes.
LCOM2
LCOM3
LCOM4
LCOM5
TCC
524
31
29
1.01
0.0383
28
8
3
1.10
0.143
888
31
17
0.971
0.194
1081
47
10
1.01
0
1288
44
14
1.01
0.0216
198
16
10
0.995
0.0221
539
22
7
0.908
0.579
430
24
16
0.974
0.0260
871
33
11
1.01
0.0189
334
13
5
0.958
0.108
21
7
5
1.08
0
4626
92
19
0.979
0.00328
238
16
9
0.984
0.0217
486
24
5
0.994
0.296
28851
155
72
0.998
0.0928
424
18
6
0.959
0.206
3
3
3
1.38
0
28
8
7
1.07
0
3752
60
30
0.990
0.0648
4
3
3
1.11
0
6
4
2
0.688
0
6
4
4
1.22
0
283
20
12
0.933
0.277
3577
53
13
0.994
0.084
0
4
4
0.568
0
0
3
2
0.625
0.071437
440.9
0.0444
45
10
7
1
0
0
1
1
0
0
20442
115
97
0.993
0.000209

cohesion-level dose not go down.
Property 4 considers a situation combining a class withanother class, where they have no common component.
Such situation means that two classes cohabit, but they haveno relationship each other. Property 4 says that such combined class does not have a greater cohesion than the maximum of the original classes’ cohesion.
4.1.2 Results
AECC satisfies the above four properties (see Appendix for
their proofs), and be a metric holding necessary conditionsof cohesion metric. We will consider AECC to be one ofreasonable class cohesion metrics, and compare it with theother existing metrics in the following section.
4.2 Quantitative Evaluation
We have seen AECC holds the above necessary conditionsof cohesion metric. We next present some measurement dataof practical object classes, and evaluate AECC using thosedata, especially we will show that AECC measures classes
without depending on the other existing metrics, in otherwords, it is not redundant metric.
Table 4 presents metric values of Java classes which are
selected from “Sun J2SE SDK version 1.3.1” randomly.
Unfortunately any suﬃcient conditions of cohesion
metric have never been found nor proposed. Since we have

LCC
0.03830.09520.122
00.017300.025400.0170
0.171
0
0
0
0.257
0.03030.165
000.0244000
0.166
0.055900.07140.0444000.000209

ICH
5
10
54
82
87
14
66
21
50
36
10
674
22
50
339
24
0
10
179
16
5
6
27
267
0
2
2
10
2
58

AECC
0.625
0.286
0.725
0
0.157
0.1
0.789
0.129
0.310
0.871
0.167
0.0313
0.125
0.656
0.837
0.773
0
0
0.455
0
0
0
0.56
0.697
0
0.25
0.2
0
0
0.0227no suﬃcient condition, it is diﬃcult to present an objective and reliable discussion on the validity of AECC as acohesion metric, even if we use many experimental data.
(While highly reusable classes such as String, StringBuﬀer
and so on, seem to have relative high value of AECC, they
can not be any grounds for the validity as cohesion metric;
Rather they would be materials for investigating a usefulness of AECC.) So we have checked AECC by mathematicalproperties of cohesion metric in the above. As a quantitative evaluation of AECC, we analyze dependencies between
metrics using experimental data shown in Table 4, and weshow AECC is not redundant metric. For example, we now
see three classes shown in the head of Table 4. Although themodel of AECC is similar to the models of TCC and LCC,
those experimental data show a diﬀerent tendency between
AECC and TCC/LCC (e.g., see Fig. 7). In order to showsuch actual diﬀerences in tendency between metrics, we use
the following correlation analysis.
4.2.1 Correlation Coeﬃcient
When some diﬀerent software metrics measure a software
attribute, they have to capture diﬀerent aspects of the software attribute independently. In other words, metrics should
not depend on each other for providing their measurements.
If there is a strong correlation [19] between two metrics, oneof them is a redundant metric. We can explore such relationships between metrics by calculating their correlation coef-

AMAN et al.: A CLASS COHESION METRIC FOCUSING ON COHESIVE-PART SIZE

845
Table 5 Correlation coeﬃcients with AECC.
metrics
correlation coeﬃcients : r
LCOM1
0.202744
LCOM2
0.207895
LCOM3
0.259502
LCOM4
0.152871
LCOM5
0.085906
ICH
0.147297
TCC
0.695496
LCC
0.697812

Fig. 7

A comparison of AECC and TCC/LCC.

ficients.
The following is a brief description of calculating correlation coeﬃcients for verifying metrics.
Given two metrics and N sample data(software). Measure each of sample data using those metrics, then obtain
2-dimensional vector xi = (xi1 , xi2 ) for each data (i =1, . . . , N), where xi1 and xi2 are the metric values for the i-th
sample data, respectively. Now the correlation coeﬃcient r
is calculated as follows :N
i=1 (xi1 − x1 )(xi2 − x2 )
r= 
N

2 N (x − x )22,i=1 (xi1 − x1 )i=1 i2
N
N
where x1 = ( i=1 xi1 )/N and x2 = ( i=1 xi2 )/N.
The higher value of |r| means the stronger correlation
between two metrics. Now prepare a threshold value τ for|r|. If |r| ≥ τ, we will consider those two metrics are dependent on each other, and one of them is a redundant metric.
4.2.2 Experiments
We perform the following experiments in order to show that
AECC measures cohesion without depending on the otherexisting metrics (see Sect. 2), in other words, AECC is not
redundant metric.
Prepare a set of sample data (Java classes). Measurecohesion using the above eight metrics and AECC. For eachpair of AECC and the others, (i.e., for the following eightpairs: {AECC, LCOM1}, {AECC, LCOM2}, {AECC, LCOM3},{AECC, LCOM4}, {AECC, LCOM5}, {AECC, ICH}, {AECC, TCC},
and {AECC, LCC}, ) calculate their correlation coeﬃcients.

We now use τ = 0.8 [19]. If there is a correlation coefficient is grater than or equal to τ, we will regard AECC asa redundant metric. Otherwise, we will consider that AECC
can provide its measurements without depending on any of
the other existing metrics.
Now our set of sample data (Java classes) is shown in
Table 4.
4.2.3 Results
Tables 5 shows the correlation coeﬃcients calculated in theabove experiment† . From this table, we have no metric
whose correlation coeﬃcient with AECC is grater than orequal to τ(= 0.8), i.e., no metric who has a strong correlation with AECC :• LCOM1∼LCOM5 and ICH have some low correlationcoeﬃcients (|r| = 0.085906 ∼ 0.259502).
• TCC and LCC have some middle-level correlations(|r| = 0.695496, 0.697812), but not strong correlations. The reason they have such correlations is because their underlying model is similar to AECC’smodel : The models of TCC and LCC focus on “densities” of attribute-sharing relationships while AECC’smodel focuses on “extents” of those relationships.
Thus AECC is not redundant metric, and will be an important one. It measures an aspect of cohesion which is notsupported by the other existing eight metrics. AECC cancollaborate with those existing metrics in measuring classcohesion, and will contribute to more accurate measurement.
5. Conclusion and Future WorkA class cohesion metric, “Association-Extent based Class
Cohesion (AECC),” has been proposed in this paper.
AECC measures class cohesion using the maximum size ofcohesive-parts, which is an aspect has not been supported by
the other existing metrics. AECC has been evaluated in bothof qualitative and quantitative ways : it has been showed that
• AECC satisfies mathematical conditions of cohesion
metrics described in BMB framework,• AECC presents cohesion values without depending on
any of the other existing metrics : LCOM1∼5, ICH,
TCC and LCC.
Therefore, AECC is a reasonable class cohesion metric, andnot redundant metric. It can collaborate with the other existing metrics in measuring class cohesion, and will contributeto more accurate measurement.
Our future works include investigations into
(1) practical usefulness of AECC and other metrics, such aspredictors of software maintenance cost using class cohesion metrics,(2) relationships between reusability of software components and their cohesion, and so on.
†
For the lack of space, we omit the metric values for each ofsample data.

IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

846

Acknowledgement
The authors would like to thank the anonymous reviewers
for their thoughtful comments and helpful suggestions. This
research has been supported by the Kayamori Foundation ofInformation Science Advancement.
References[1] G.J. Myers, Software Reliability-Principles and Practices, John Wiley & Sons, New Jersey, 1976.
[2] M. Page-Jones, The Practical Guide to Structured Systems, 2nd ed.,Prentice Hall, New Jersey, 1988.
[3] E. Yourdon and L. Constantine, Structured Design, Englewood
Cliﬀs, Prentice Hall, New Jersey, 1979.
[4] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous andPractical Approach, PWS Publishing, Boston, 1997.
[5] L.C. Briand, J.W. Daly, and J. Wuest, “A unified framework forcohesion measurement in object-oriented systems,” Empirical Software Eng., vol.3, no.1, pp.65–117, 1998.
[6] S.R. Chidamber and C.F. Kemerer, “Towards a metrics suite for object oriented design,” Proc. 6th ACM Conf. Object Oriented Programming, Syst., Lang. and Appicat. (OOPSLA), pp.1970–221,
1991.
[7] S.R. Chidamber and C.F. Kemerer, “A metrics suite for object oriented design,” IEEE Trans. Softw. Eng., vol.20, no.6, pp.476–493,
June 1994.
[8] M. Hitz and B. Montazeri, “Chidamber and Kemerer’s metrics
suite: A measurement theory perspective,” IEEE Trans. Softw. Eng.,
vol.22, no.4, pp.267–271, April 1996.
[9] M. Hitz and B. Montazeri, “Measuring coupling and cohesion in
object-oriented systems,” Proc. Int. Symp. on Applied Corporate
Computing (ISACC’95), pp.25–27, Oct. 1995.
[10] B. Henderson-Sellers, Softare Metrics, Prentice Hall, Hemel Hempstead, U.K., 1996.
[11] Y.-S. Lee, B.-S. Liang, S.-F. Wu, and F.-J. Wang, “Measuring thecoupling and cohesion of an object-oriented program based on information flow,” Proc. Int. Conf. on Software Quality, pp.81–90, 1995.
[12] J.M. Bieman and B.-K. Kang, “Cohesion and reuse in an objectoriented system,” Proc. ACM Symp. on Software Reusability,
pp.259–262, 1995.
[13] W. Li and S. Henry, “Object-oriented metrics that predict maintainability,” J. Systems and Software, vol.23, no.2, pp.111–122, 1993.
[14] V.R. Basili, L.C. Briand, and W.L. Melo, “A validation of objectoriented design metrics as quality indicators,” IEEE Trans. Softw.
Eng., vol.22, no.10, pp.751–761, Oct. 1996.
[15] R.J. Wilson, Introduction to Graph Theory 4th ed., Addison-Wesley,
Boston, 1996.
[16] D.F. Stanat and D.F. McAllister, Discrete mathematics in Computer
Science, Prentice-Hall, New Jersey, 1977.
[17] L.C. Briand, S. Morasca, and V.R. Basili, “Property-based software
engineering measurement,” IEEE Trans. Softw. Eng., vol.22, no.1,
pp.68–86, Jan. 1996.
[18] M. Adams and V. Guillemin, Measure Theory and Probability,
Springer Verlag, Heidelberg, 1996.
[19] P.G. Hoel, Elementary Statistics, John Wiley & Sons, New Jersey,
1976.
[20] H. Aman, K. Yamasaki, H. Yamada, and M.T. Noda, “A proposal ofclass cohesion metrics using sizes of cohesive parts,” in Knowledgebased Software Engineering, ed. T. Welzer, S. Yamamoto, and I.
Rozman, pp.102–107, IOS Press, Amsterdam, 2002.

Appendix:

Proofs

The followings are the proofs of that AECC satisfies the four
properties of cohesion metrics described in Sect. 4.1.1 [20].
In these proofs, we will consider the association-graph to be
the graph model of a class.
Proof for Property 1 :Given a class C. Let M be the set of all methods in C.
(i) Case |M| = 1 :From Eq. (3), we obtain AECC(C) = 0.
(ii) Case |M| > 1 :For each m ∈ M, let Ra (m) be the set of methods
reachable by m (see Eq. (2)). From the definition, we have0 ≤ |Ra (m)| ≤ |M| − 1, for each m ∈ M. Thus, from Eq. (3),
we obtain 0 ≤ AECC(C) ≤ 1.
Therefore, we can get AECC(C) ∈ [0, 1], for any classC.

Proof for Property 2 :Given a class C. Let M be the set of all methods in C,
and Ga = (V, E) be the association-graph of C.
(i) Case |M| = 1 :From Eq. (3), we obtain AECC(C) = 0.
(ii) Case |M| > 1 :We assume E = φ. For each m ∈ M, let Ra (m) be theset of methods reachable by m (see Eq. (2)). Since E = φ,we have |Ra (m)| = 0 for each m ∈ M. Thus, we obtain
AECC(C) = 0.
Therefore, we can get AECC(C) = 0 for any class C
such that E = φ.

Proof for Property 3 :Given a class C. Let M be the set of all methods in C.
(i) Case |M| = 1 :Since we have only one vertex (method) in the graph,
we could not add any edges to the association-graph of C,
and each vertex is not allowed having a self-loop (an edge
from a vertex to the same vertex). Thus, the class C , described in the property 3, must be the same as C. Therefore,
we can obtain AECC(C) = AECC(C ).
(ii) Case |M| > 1 :Let Ga (C) = (V, E) be the association-graph of C.
Now we can consider a class C whose association-graphis Ga (C ) = (V, E ) where E ⊆ E . For each m ∈ M, let
Ra (m) and Ra (m) be the sets of reachable methods by m in
Ga and Ga , respectively (see Eq. (2)).
Since E ⊆ E , we obtain Ra (m) ⊆ Ra (m), for each m ∈M. Thus, we have |Ra (m)| ≤ |Ra (m)|, and we getmax |Ra (m)| ≤ max |Ra (m)| ,
m∈M

m∈M

i.e., AECC(C) ≤ AECC(C ), for each m ∈ M.
Therefore, we can get AECC(C) ≤ AECC(C ), for allpairs of classes such that E ⊆ E .
Proof for Property 4 :AMAN et al.: A CLASS COHESION METRIC FOCUSING ON COHESIVE-PART SIZE

847

Given a pair of classes C1 and C 2 , and consider aclass C 12 composed of C1 and C2 . Let M1 , M2 and M12(= M1 ∪ M2 ) be the sets of all methods in C1 , C2 andC12 , respectively. Let Ga1 = (V1 , E1 ), Ga2 = (V2 , E2 ) andGa12 = (V1 ∪ V2 , E1 ∪ E2 ) be the association-graphs of C1 ,C2 and C12 , respectively. For each m1 ∈ M1 , let Ra1 (m1 )be the set of reachable methods by m1 in Ga1 (see Eq. (2)).
Similarly, let Ra2 (m2 ) and Ra12 (m12 ) be the sets of reachable
methods by m2 ∈ M2 and m12 ∈ M12 , respectively.
(i) Case |M1 | = |M2 | = 1 :Since M12 = M1 ∪ M2 , we have |M12 | = 1. From
Eq. (3), we obtain AECC(C1 ) = AECC(C2 ) = AECC(C12 ) =0. Thus, we getmax[AECC(C1 ), AECC(C2 )] = AECC(C12 ).
(ii) Case |M1 | > 1 or |M2 | > 1 :This case could be |M1 | + |M2 | ≥ |M12 |, and we put|M1 | + |M2 | − |M12 | = p (≥ 0).
Let m1,i (i = 1, . . . , |M1 |), m2, j ( j = 1, . . . , |M2 |) andm12,k (k = 1, . . . , |M12 |) be the methods in C 1 , C2 and C12 ,respectively. Now we put the relations among {m1,i }, {m2, j }and {m12,k } as follows, without loss of generality :m1,k ,(k = 1, . . . , |M1 | − p),
m12,k =
m2,k−|M1 |+p , (otherwise),
where m2,k−|M1 |+p = m1,k (k = |M1 | − p, . . . , |M1 |).
From the assumption of the property 4, we have∀{u, v} ∈ E1 ∪ E2 [u ∈ V1 ∩ V2 ⇐⇒ v ∈ V1 ∩ V2 ]. That
is, Ga12 has no path from a method in C1 to one in C 2 , viceversa. Thus we obtain the following equation :Ra12 (m12,k )Ra1 (m1,k ),=Ra2 (m2,k−|M1 |+p ),


≤

max

k=|M1 |−p+1,...,|M12 |( j=1,...,|M2 |)|Ra2 (m2, j )||M2 | − 1
= AECC(C2 ).

Therefore, we get
AECC(C12 )|Ra12 (m12,k )|= max
k=1,...,|M12 ||M12 | − 1|Ra12 (m12,k )|= max max,
k=1,...,|M1 ||M12 | − 1|Ra12 (m12,k )|max
k=|M1 |−p+1,...,|M12 ||M12 | − 1≤ max { AECC(C1 ), AECC(C2 ) } ,for all classes such that ∀{u, v} ∈ E1 ∪ E2 [u ∈ V1 ∩ V2 ⇐⇒v ∈ V1 ∩ V2 ].


Hirohisa Aman
received the Dr. degree inEngineering from Kyushu Institute of Technology, Kitakyushu, Japan, in 2001. Since 2001,
he has been with Ehime University. He is currently a research assistant of the Faculty of Engineering, Ehime University. His primary research interest is in software maintenance costestimation using metrics. He is a member of Information Processing Society of Japan (IPSJ),
Japan Society for Software Science and Technology (JSSST), the Institute of Electrical andElectronics Engineering (IEEE), and Japan Society for Fuzzy Theory andIntelligent Informatics (SOFT).

(k = 1, . . . , |M1 | − p),(otherwise).

Since |M1 |, |M2 | ≤ |M12 |, we obtain|Ra1 (m1,k )||Ra12 (m12,k )|≤,|M12 | − 1|M1 | − 1

(k = 1, . . . , |M1 |),Kenji Yamasaki
received the Masters degree in Computer Science from Ehime University, Matsuyama, Japan, in 2004. He is currently
with Fujitsu System Solutions Ltd. He is a member of IPSJ.

and|Ra2 (m2, j )||Ra12 (m12,k )|≤,|M12 | − 1|M2 | − 1
(k = |M1 | − p + 1, . . . , |M12 |;j = k − |M1 | + p).
Thereby we get|Ra12 (m12,k )|max
k=1,...,|M1 ||M12 | − 1|Ra1 (m1,k )|≤ max= AECC(C1 ),k=1,...,|M1 ||M1 | − 1
and


max

k=|M1 |−p+1,...,|M12 ||Ra12 (m12,k )||M12 | − 1

Hiroyuki Yamada
received the Dr. degree
in Engineering from Osaka University, Suita,
Japan, in 1988. Since 1988, he has been with
Ehime University. He is currently an associate
professor of the Faculty of Engineering, Ehime
University. His primary research interests are in
the field of knowledge-based software engineering, especially, software requirements acquisition and software evolution. He is a memberof IPSJ, JSSST, IEEE, Association for Computing Machinery (ACM), and Japanese Society for
Artificial Intelligence (JSAI).

IEICE TRANS. INF. & SYST., VOL.E87–D, NO.4 APRIL 2004

848

Matu-Tarow Noda
received the Dr. of
Science from Osaka City University, Osaka,
Japan, in 1969. Since 1971, he has been with
Ehime University. He is currently a professor of
the Faculty of Engineering, Ehime University.
He also is a director of Center of Information
Technology, Ehime University(CITE). His primary research interests are in algorithm developments of symbolic-numeric combined computation, and Internet security in mobile environments. He received the Best Paper Award
from IPSJ in 1992. He is the president of Japan Society for Symbolic andAlgebraic Computation (JSSAC). He is a member of IPSJ, ACM, Japan Society for Industrial and Applied Mathematics (JSIAM), and International
Association for Mathematics and Computers in Simulation (IMACS).