Cohesion software quality characteristic

Ion Ivan
Zsolt Mark
Paul Pocatilu
Marius Popa
Doru Ungureanu
It is defined the software cohesion concept for the object oriented approach. It is built
the indicators system for the cohesion level evaluation of the program products. It is also
suggested generalization of the methods and techniques for the web applications development
whose components have a high cohesion level.
I. Software Quality
In [IVAN01], software quality is defined as a measure of the users requirements
satisfaction through the technical, economic and psycho-social product characteristics. This
definition is based on two related concepts: users requirements and software product
characteristics.
Software quality characteristics make up an integrated system and take into account
the following elements:
- correctness highlights the extent in which the software product respect the
requirements defined in the functional specifications, as well as the extent in
which this software is error free;
- maintainability highlights the software product ability to take new approaches of
the programming techniques, as well as the easiness with which the errors are
corrected;
- extensibility means the extension easiness of the program product with new
functions and procedures, data types, searching and recovering methods and
techniques, options and user interfaces;
- flexibility consists in the software product easiness to accept structural and
functional changes in order to accomplish some users particular requirements;
- efficiency relates the size of the effects obtained through program product use
with the efforts made for acquisition, implementation and maintenance;

robustness highlights the software product behavior at the execution in

conditions other than those foreseen in specifications, measuring its response in
functioning under unforeseen circumstances;
- reusability highlights the extent in which the whole software product and/or its
components are used in other program products in order to realize the same
processing;
- portability means the usage of a software product on different hardware and
software platforms.
Among the factors that influence the software quality size are included:
- complexity;
- interdependence;
- cohesion.
Complexity is defined from several points of view, depending on the way the program
is seen, being influenced by the other two attributes.
Interdependence is defined in [CHID94] as an ensemble of links between classes and
homogenous data subsets. Links between data are highlighted through the precedence-based
relations.
Cohesion is an attribute which is found in all the modern software development
techniques. Fenton and Pfleeger [FENT96] define cohesion in a module as the measure in
which distinct sequences are used together in order to realize a particular processing.
II. Software Cohesion Concept
Stevens was the first who introduced the cohesion concept in the context of the
structural techniques development. Cohesion is defined as a measure of the degree in which
elements in a module are linked. In a high cohesion module, all the elements are functionally
and structurally linked in order to accomplish one goal. The higher the level of cohesion in the
module, the easier the module is to develop, to maintain and to reuse, being less open to
errors.
The ability to quantify a series of elements, which are characteristic to the software
development process, has a big importance for the improvement of the software products
elaboration. As a result, focusing on software metrics development consists in identifying and
measuring the significant characteristics related to software quality.
Software development market places a stronger accent on software quality. This
orientation established the growth of the workload realized in establishing the software
metrics, especially in software quality analysis and ascertain. On the other hand, it took to the
appearance of a great number of indicators proposed for the quality standards, cohesion being
one of them. High quality software must also have a cohesion level.
Cohesion refers to the links between the components of a module and is primarily
known in the procedural context. Once with the appearance of the object oriented
technologies, it appeared the concept of class cohesion.
In the context of the procedural programming, the module cohesion is a software
quality characteristic. A low quality module is a vital issue in awarding a high level of quality
to the system. In order to develop good quality software, project managers and programmers
found themselves compelled to introduce cohesion metrics. Elaboration of high quality
software is the goal to be accomplished.

In the context of the object oriented programming, cohesion represents measuring the
intensity of the links between the classs elements. When the methods defined in a class use
similar sets of variables instances, that class is considered to have a high level of cohesion.
According to the analysis realized on modules with different levels of cohesion,
modules with stronger cohesion levels have less reported bugs than the modules with weaker
cohesion levels.
Researches in the field lead to the identification of eight general categories of the
cohesion [NICU03]:
- functional;
- information;
- sequential;
- communication;
- procedural;
- temporal;
- logic;
- coincidental.
Programmers talk about the program structure in terms of modules, functions,
subroutines, methods or procedures. When these structures cohesion is highlighted,
component parts analysis is required. These elements represent one or more lines of code
which give the modules objectives. The links between these components establishes the
cohesion levels of the modules.
III. Metrics of the Object Oriented Software Cohesion
Establishing the cohesion degree in the object oriented systems supposes the existence
of a terminology and a standard formalism. This framework is used for:
- facilitation of the comparison between cohesion indicators;
- evaluation and validation of the defined cohesion indicators;
- support for the definition of new cohesion metrics and selection from the existent
metrics based on measurements particular objectives.
In the specialty literature [IVAN03] there are defined indicators of the cohesion
evaluation for the object oriented software systems.
Thus, LCOM1 indicator is based on the idea of similitude between the classs
components. Components similitude is specified through an ensemble of properties which are
present at all these components. Analytical expression of the LCOM indicator is:
LCOM1(c)=|{{m1 ,m 2 , ..., m n }|
m1 ,m 2 , ..., m n M1 (c) mi mj AR(mi ) AR(mj)= , i j }|

(1)

where:
c class of objects;
mi, i = 1, 2, , n methods of the c class;
AR(mi) ensemble of attributes referred by the mi method.
Value of the LCOM indicator is reverse proportional with the cohesion degree of the c
class, reflecting the lack of cohesion. At the same time, the indicator takes into account only
the methods defined in the class, c class inherited methods not being included.
The following indicator give a measure for the class of objects cohesion, starting with
the attributes defined in it. The analytical expression of the Ca indicator is:

Ca

na
i 1

n nac

(2)

where:
nai number of attributes referred in i method;
n number of methods defined in class;
nac number of attributes belonging to the class of objects.
According to this indicator, cohesion reaches its maximum when all the classs
methods use all the defined attributes.
LCOM2 indicator is derived from LCOM1 and has the following expression:
P Q , if P Q
0, otherwise

LCOM 2(c)
where:

(3)

c class of objects;
P method matches number of the c class, without referring to the same
attribute;
Q method matches number of the c class, which refer together at least one
attribute.
If |P| < |Q|, than the value of the LCOM2 indicator is set to zero.
LCOM3 is also derived from LCOM1. This indicator definition takes into account
only the methods and attributes implemented in the c class of objects.
It is built the graph G3(V3, M3), where:
- V3 set of graphs points consisting of the c classs methods;
- M3 set of graphs edges which connect two methods of the c class if these refer
together at least one attribute.
According to this indicator, the cohesion level drops on behalf of the interface
methods growth. This issue was tackled through elaboration of the LCOM4 indicator, as an
improvement of the LCOM3 indicator.
It is built the simple non-oriented graph G(V4, M4), where:
- V4 set of graphs points consisting of the c class methods;
- M4 set of graphs edges which connect two methods of the c class if at least one
of them invokes the other one.
Thus, the cohesion level depends on the number of graphs edges, reaching the lowest
level when
M 4 V4 1

(4)

and the highest level when

M4

V4 (V4 1)
2

(5)

In [IVAN03] is defined an indicator with the following analytical expression:

| M C | (|VC | 1)
Co(c) 2
(|VC | 1) (| VC | 2)

(6)

where:
-

C class of objects;
VC set of the GC(VC, MC) graphs points consisting of the c classs methods;
MC set of the GC(VC, MC) graphs edges which connect two points if those
methods both refer at least one attribute and there is an edge between the points
representing two methods, from among at least one invokes the other one.
Co indicator is defined for the classes where LCOM4 = 1. It takes one of the following

values:

0 < Co < 1, for any MC value;

Co = 0, for MC = VC 1;
VC (VC 1)
MC
2
Co = 1, for
;
LCOM5 indicator and its improved variant are presented in [IVAN03]. Thus, LCOM5
indicator has the following analytical expression:
1 a
(a j ) m
a j 1
LCOM 5
1 m

(7)

where:

a number of the classs attributes;

m number of the classs methods;
(a j )

number of methods which accesses the aj attribute.

Cohesion is perfect if the value of the LCOM5 indicator is null. According to the (6)
analytical expression, this means that every classs method refer each of the classs attributes.
Value of the LCOM5 indicator is 1 if every method of the class refers only one attribute.
Improvement of the LCOM5 indicator is realized through Coh indicator:
a

Coh

(a )
j 1

m a

(8)

where:

a number of the classs attributes;

m number of the classs methods;
(a j )

number of methods which accesses the aj attribute.

Cohesion is perfect when Coh is zero that is every method of the class refers all the
classs attributes. If (8) indicator is 1 than every method refers a single attribute.
In the class of objects framework, cohesion is also measured through the following
indicator, which represents the connectivity degree of the classs methods. Thus, according to
[IVAN03], LCC indicator has the following analytical form:

LCC

NIC
NP

(9)

where:

NIC number of direct or indirect connections, established between the class of

objects methods.
NP maximum number of public methods pairs that belong to the class of objects;
Maximum number of public methods pairs that belong to the class of objects, NP, is
calculated as follows:
NP

N ( N 1)
2

(10)

where N represents the number of public methods pairs that belong to the class of objects.
LCC indicator represents a weight of the public methods pairs of the class, which use
the same attributes, in the maximum number of public methods pairs.
Another form of the LCC indicator is given through the TCC indicator, representing a
weight of the public methods pairs of the class, which use the same attributes, in the
maximum number of methods pairs:
TCC

NDC
NP

(11)

where:
NDC number of direct connections between the methods of the class;
NP maximum number of public methods pairs that belong to the class of objects.
Also, NP is calculated according to the relation (10).
A class of objects has a high cohesion level if its variables instances are referred by a
method, facet highlighted through LCOM5 and Coh indicators, or a number of methods pairs
refer the same variable instances, facet highlighted through LCOM1, LCOM2, LCOM3,
LCOM4, Co, LCC and TCC indicators.
IV. Conclusions
In the above paragraphs it was presented the framework that lays at the basis of the
cohesion indicators definition, evaluation and comparison in object oriented information
systems.
In practice, usage of the indicators presented in the above paragraphs is difficult
because they arent based on explicit empirical methods. Also, powerful empirical validations
exist only for a small number of indicators, being influenced by the results validity.
Cohesion tackling imposes development of practical experiments in order to quantify
this software quality characteristic.
Bibliography
[BIEM95] J.M. Bieman, B.K. Kang Cohesion and Reuse in an Object-Oriented System, in
Proc. ACM Symp. Software Reusability (SSR94), 259-262, 1995

[CHID91] S.R. Chidamber, C.F. Kemerer Towards a Metrics Suite for Object Oriented design,
in A. Paepcke, (ed.) Proc. Conference on Object-Oriented Programming: Systems,
Languages and Applications (OOPSLA91), SIGPLAN Notices 26 (11), 197-211,
1991
[FENT96] N. Fento, S. L. Pfleeger Software Metrics: A Rigorous and Practical Approach,
International Thomson Compute Press, London, 1996.
[IVAN03] I. Ivan, C. Niculae, P. Pocatilu Metrics for the cohesion evaluation of the object
oriented software, in Studies and Researches of Economic Calculus and Cybernetics,
Bucharest, 2003, coming soon
[HITZ95] M. Hitz, B. Montazeri Measuring Coupling and Cohesion in Object-Oriented
systems, in Proc. Int. Symposium on Applied Corporate Computing, Monterrey,
Mexico, October 1995
[IVAN01] L. Teodorescu, I. Ivan Software Quality Management, Inforec Publishing House,
Bucharest, 2001
[NICU03] C. Niculae, Cohesion software quality characteristic, License Diploma Thesis,
AES, Bucharest, 2003