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 class’s 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 module’s 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 class’s components. Components similitude is specified through an ensemble of properties which are present at all these components. Analytical expression of the LCOM indicator is:

        (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:

        (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 class’s methods use all the defined attributes.
LCOM2 indicator is derived from LCOM1 and has the following expression:

where:
•	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 graph’s points consisting of the c class’s methods;
-	M3 – set of graph’s 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 graph’s points consisting of the c class methods;
-	M4 – set of graph’s 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 graph’s edges, reaching the lowest level when 

        (4)

and the highest level when

       (5)

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

        (6)

where:
-	C – class of objects;
-	VC – set of the GC(VC, MC) graph’s points consisting of the c class’s methods;
-	MC – set of the GC(VC, MC) graph’s 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;
•	Co = 1, for ;
LCOM5 indicator and its improved variant are presented in [IVAN03]. Thus, LCOM5 indicator has the following analytical expression:

        (7)

where:
•	a – number of the class’s attributes;
•	m – number of the class’s methods;
•	 – 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 class’s method refer each of the class’s 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:

        (8)

where:
•	a – number of the class’s attributes;
•	m – number of the class’s methods;
•	 – 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 class’s 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 class’s methods. Thus, according to [IVAN03], LCC indicator has the following analytical form:

       (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:

       (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:

        (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 aren’t 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 (SSR’94), 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 (OOPSLA’91), 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