A Quality Indicator for Software
Interoperability
M.V.Vijaya Saradhi 1 B.R.Sastry 2
1
Assoc.Prof &HOD, Dept. of CSE, ASTRA, Bandlaguda, Hyderabad, India
2
Director, ASTRA, Bandlaguda, Hyderabad, India
ABSTRACT
Measuring the quality of software in terms of easiness in applying changes to that software is becoming primary concern. Most successful approach to measure this quality is finding design properties that can be used as Interoperability indicators and past research proved that coupling between classes is such an indicator. In this paper, we set out to investigate the relation between class cohesion and coupling and hence will be proved that class cohesion metric can considered as an indicator for measuring the software ability of accepting changes. Class cohesion is one of most important Object Oriented software attributes. Cohesion intended to measure the degree of relatedness between class members. Class cohesion will be captured in terms of connections between members within a class. Most of these metrics have been experimented and widely discussed. In this proposed model LCC and LCOM were considered as cohesion metrics, and Chidamber and Kemerer coupling metrics were used for measuring coupling.
Keywords: LCC, LCOM, TCC, CBO, RFC, NOC, stNOC , nstCBO, ubCBO, uCBO
1. Introduction
The application of Object-Oriented Technology for software development has become fairly popular. Research conducted so far has shown that Object Oriented practices guarantee a superior quality of software by way of maintainability, reusability and flexibility. In order to evaluate the software industrial buyers acquire, they want to ensure the quality of product. This is where Object Oriented measures come into play.
One of the important quality properties of Object Oriented designs is cohesion. A number of metrics have been suggested to quantify and measure this design property. In this chapter, we attempt to evaluate cohesion as an indicator of Interoperability. In a few earlier works, coupling has been corroborated as a quality indicator. By establishing a link between cohesion and coupling, we will be able to affirm that cohesion is quality indicator, as well.
2. Cohesion as Quality Indicator for Design
One of the imperatives to building a quality Object Oriented system is a good design. For this, quantification of the design property is required. Several software metrics have been developed to assess and control the design phase and its products. One of the most vital criteria in Object Oriented design is cohesion. A module is said to have a strong cohesion if it closely characterized with one task of the problem domain, and all its components contribute to this single task.
2.1 Cohesion and its Measuring Metrics
There is unanimity in the literature on the theory of class cohesion. A class is cohesive if it cannot be partitioned into two or more sets defined as follows
1. Each set contains instance variables and methods.
2. Methods of one set do not access variables of another set either directly or indirectly.
By way of defining cohesion metrics, many authors have effectually defined class cohesion. So far as the Object Oriented model is concerned, almost all of the cohesion metrics are influenced by the LCOM metric that is defined by Chidamber and Kemerer. According to them, “if an object class has different methods performing different operations on the same set of instance variables, the class is cohesive”. The LCOM (Lack of Cohesion in Methods) defined by them is the result gained from deducting the number of pairs of methods in a class having no common attributes from the number of pairs of methods in a class sharing at least one attribute. If the value reached in this calculation is in the negative, the metric is set to zero. This is one metric for assessing cohesion.
Likewise, Li and Henry defined LCOM as the number of disjoint sets of methods accessing similar instance variables. Hitz and Montazeri reaffirm Li’s definition of LCOM based on the graph theory which defines LCOM as the number of connected components of a graph. A graph consists of vertices and edges. Vertices represent methods. There is an edge between 2 vertices if the corresponding methods access the same instance variable. Hitz and Montazeri propose to divide a class into smaller, more cohesive classes, if LCOM > 1.
However, Bieman and Kang proposed TCC (Tight Class Cohesion) and LCC (Loose Class Cohesion) as cohesion metrics, based on Chidamber and Kemerer’s approach. Although they too consider pairs of methods using common instance variables, their way of defining attribute usage is different. Instance variable can be utilized directly or indirectly by methods. An instance variable is said to be directly used by a method M if it appears in the body of the method M. Likewise, an instance variable is said to be indirectly used, if it is directly used by another method M’ which is called directly or indirectly by M. Two methods are said to be directly connected if they use a common attribute directly or indirectly.
TCC is defined as the percentage of pairs of methods that are directly connected. It measures the ratio between the actual numbers of visible directly connected methods in a class divided by the number of maximal possible number of connections between the visible methods of a class. LCC counts the pairs of methods that are directly or indirectly connected. Constructors and destructors are not considered for computing LCC and TCC. [0, 1] interval is the perpetual range of TCC and LCC. Bieman and Kang also propose three methods for calculating TCC and LCC:
Inclusion of inherited methods and inherited instance variables in the analysis
Exclusion of inherited methods and inherited instance variables from the analysis
Exclusion of inherited methods but inclusion of inherited instance variables from the analysis
They did not, however, give any special preference to any one of the three particular method of calculating their metrics. We preferred to opt for the first method i.e. considering inheritance as an intrinsic facet of Object Oriented systems, for evaluation. Because LCC is more comprehensive extension of TCC, we selected LCC in tandem with LCOM as the key cohesion metrics of our trialing procedure.
2.2 Relationship between Cohesion and Coupling
One of the basic principles of a good Object Oriented design is that the components of a class must augment to any one particular task. A non-cohesive class indicates that its components have a tendency to support divergent tasks. Logical reasoning suggests that this kind of class has additional interconnections with the rest of the system as compared to classes that encapsulate a single functionality. Consequently, the coupling of this kind of class with the rest of the system will be more superior to the average coupling of the classes of the system.
CBO (Coupling between Object Classes): A class is coupled to another one if it uses its member functions and/or instance variables, and vice versa. CBO provides the number of classes to which a given class is coupled. It use links between classes to define the detailed architecture of the application, just as use links between packages define the highest level architecture. These use links play a determining role in design quality, notably in development and maintenance facilities. The CBO value is arrived at by getting ratio of the number of links to the number of classes.
RFC (Response for a Class): This is the number of methods that can potentially be executed in response to a message received by an object of that class. This measures the complexity of the class in terms of method calls. It is calculated by adding the number of methods in the class (not including inherited methods) plus the number of distinct method calls made by the methods in the class (each method call is counted only once even if it is called from different methods).
Briand and others explain coupling as the degree of interdependence among the components of a software system. They defined 18 coupling metrics. This suite takes into account the various Object Oriented design mechanisms provided by the C++ language [17]. Although the correlation between cohesion and quality has not been assessed quantitatively, numerous coupling metrics have exhibited themselves as good quality indicators with regard to a few specific quality aspects. We tried to ascertain the potential of cohesion metrics as Interoperability indicators by scrutinizing interactions between cohesion and coupling.
3. Validation of Cohesion and Coupling, an Empirical Approach
3.1 Objectives
A large number of software systems have longevity. With the passage of time, these software systems need improvisations vis-à-vis performance, adaptation to the dynamics of environment, and to address new requirements.
We stressed on carrying out our experiment with regard to the Interoperability factor because our industrial collaborator has a deep-rooted awareness of software Interoperability. A good way of evaluating the Interoperability of a software system is to detect some design properties that can be utilized as Interoperability indicators. In the dominion of Object Oriented Systems, experiments have been carried out that show coupling between classes as an indicator of Interoperability.
Chaumun and others defined a model of software changes and change impacts at the theoretical level. They detected a close link between Interoperability and some coupling metrics across diversified industrial systems and across diversified types of changes. Here again, no quantitative studies of class cohesion have been undertaken with respect to Interoperability. Weak class cohesion results in high coupling with the rest of the system which in turn leads to high change impact. Poor Interoperability is thus, a result of weak class cohesion. One technique for investigating cohesion as a Interoperability indicator is to establish if low cohesion is in fact correlated to high coupling. Such a proof would substantiate our perception that there is indeed a correlation between cohesion and Interoperability. We are aware that this second hypothesis would entail a study in its own right, which is outside the purview of this paper. 3.2 Metrics that Proves Low Cohesion is Correlated with High Coupling
To test our proposal “high coupling is out come cohesion is low”, we adopted some well-known cohesion and coupling metrics found in the literature. As cohesion metrics, we chose LCC and LCOM and CBO and RFC adopted as coupling metrics, since these two metrics claimed empirically as qualified indicators of quality [1] and Interoperability [2, 5]. To prove proposal empirically, the following must be tested statistically on considered software models:
How Loose class Cohesion relates with Coupling between objects
How Loose class Cohesion relates with response for class
How Lack of Cohesion of Methods relates with Coupling between Objects.
How Lack of Cohesion of Methods relates with Response for Class.
stNOC (sub tree NOC at Hierarchy level Number Of Children): The changes applied to class component, it may affect children of that component and hierarchy sub tree where component’s class acts as root.
nstCBO (no sub tree CBO): Since the considering the hierarchy where target class is root for change impacts is irrelevant. The CBO considers this hierarchy, thus to eliminate such “noise”, hierarch with target class root are not considered in stCBO.
ubCBO (CBO used By - classes that are using CBO): This represents the CBO in half way that consists the classes that are using the target class.
uCBO (CBO Using): represents CBO in half way that consists the classes that are used by target . To prove the hypothesis proposed, total seven metrics considered.
4 Empirical Study
To perform the Empirical Analysis of the proposal, we considered two open source java applications called jpcap and lucene. First we will measure the following on each application and measure the metrics involved in experimentation.
total Lines of code
total Lines of pure comments
total Blank lines
total effective classes
total classes
total files (.java)
total generalizations
total methods
total variables
total Size in repository
Finally statistical analysis will be conducted on the emerged metric values to conclude the validity of the hypothesis. To calculate the metrics involved in the experimentation, we used the tools.
4.2 Size Metrics of Systems Considered for Empirical Study
APPLICATION Lucene Jpcap
FILES 619 116
BLANK LINES 18819 2595
COMMENT LINES 35321 7965
CODE LINES 87996 12002
CLASSES 1191 185
FUNCTIONS 7404 1144
EFFECTIVE CLASSES 1154 182
GENERALIZATION 80 27
VARIABLES 18022 3641
Table 1.1 Size Metrics of Open Java Systems
4.3 Descriptive Statistics of the Experiential Study
Lucen min max mean median std.dev
NOC 0 14 0.82 0 2.34
stNOC 0 60 0.82 0 9.57
CBO 0 20 0.82 4 3.16
nstCBO 0 20 0.82 3 3.16
ubCBO 0 19 0.82 0 3.05
uCBO 0 9 0.82 4 1.95
Jpcap min max mean median std.dev
NOC 0 29 0.88 0 2.53
stNOC 0 266 3.42 0 18.51
CBO 0 707 32.49 21 36.14
nstCBO 0 707 29.36 18 34.96
ubCBO 0 707 7.06 1 29.48
uCBO 0 93 25.77 17 23.95
RFC 0 2735 171.02 47 286.85
Table 1.3 Descriptive Statistics of the Coupling Metrics for Jpcap System
Lucene LCC LCOM
Minimum 0 0
Maximum 1 208
Mean 0.62 5.81
Median 0.69 1
Std. Dev. 0.27 25.40
Table 1.4 Cohesion Metric Values for Lucene System
Jpcap LCC LCOM
Minimum 0 0
Maximum 1 11706
Mean 0.56 145.73
Median 0.61 10
Std. Dev. 0.31 695.72
Table 1.5 Cohesion Metrics Values for Jpcap System
4.4 Report on Correlation Coefficients of the Systems taken for Empirical Study
Lucene NOC stNOC CBO nstCBO ubCBO uCBO RFC
LCC 0.09 0.15 0.17 0.10 0.030 0.22 0.17
LCOM 0.12 0.01 0.06 0.11 0.17 0.17 0.33
Figure 1.1: Correlation Coefficient of the Metrics for Lucene System
Jpcap
NOC stNOC CBO nstCBO
ubCBO uCBO RFC
LCC
0.06 0.08 0.02 0.01 0.05 0.03 0.07
LCOM
0.08 0.21 0.28 0.30 0.32 0.07 0.36
Figure 1.3: Correlation Coefficient of the Metrics for Jpcap System
5 Results Analysis
The aim of our paper was to find a correlation between cohesion and coupling that have been slightly supported by our empirical study; we set out to reason about this weakness of this correlation, in the context of two metrics CBO and RFC that are genuine coupling metrics. Given results reported above, we can conclude the following
As per the experiment results, there is a weaken relationship between cohesion and coupling.
Alone this relation cannot be considered as QI (Quality Indicator), but this would be considerable attribute of the QI.
Conclusions
In this paper, our major goal was to validate cohesion metrics as QI (Quality Indicator) for Interoperability. In this context, we tried to prove that the correlation between cohesion and coupling metrics can be considered as QI (Quality Indicator) for software Interoperability. In our experiments we considered LCC and LCOM that comes under cohesion metrics, and CBO and RFC were chosen as coupling metrics. Our experimentation showed that there is correlation between cohesion and coupling metrics chosen but. According to Object Oriented design principles, a good design exhibiting high class cohesion goes together with low coupling between classes. A relationship should therefore exist between cohesion and coupling. We suspected that the cohesion metrics used in the experimentation do not reflect the real cohesion of a class. We decided to investigate manually classes with low cohesion metric values. A cohesion measure based on the variable sharing aspect is a special way of capturing class cohesion. This restricted definition misleads the cohesion measures when classes with abstract methods or when a class get number of methods or instance variables from its super class those are volume wise big. When taking into account these abstract methods or inherited components, the cohesion value of a class is reduced, resulting in misleading class cohesion values that reflects in correlation value of cohesion and coupling. In our experiments we finally concluding that measuring class cohesion based on exclusively common attribute usage and method invocation is not sufficient more over that, but also on patterns of interaction between class members, on the functionality of class methods, and on the conceptual unity of its instance variables.
References
[1] Victor R. Basili, Lionel C. Briand, and Walcelio L. Melo. A validation of Object- Oriented design metrics as quality indicators.
[2] M. Ajmal Chaumun, Hind Kabaili, Rudolf K. Keller, Francois Lustman, and Guy St-Denis. Design properties and Object-Oriented
software Interoperability.
[4] Lionel C. Briand, John Daly, and Jurgen Wust. A unified framework for cohesion measurement in Object-Oriented systems. In Empirical Software Engineering
[5] Heung Seok Chae and Yong Rae Kwon. A cohesion measure for classes in Object-Oriented systems,
[6] S. R. Chidamber and C. F. Kemerer. A Metrics Suite for Object Oriented Design
[7] Wei Li and Sallie Henry. Object Oriented metrics that predict maintainability.
[8] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual.
[9] James M. Bieman and Byung-Kyoo Kang. Cohesion and reuse in an Object Oriented system.
[10] Martin Hitz and Behzad Montazeri. Measuring coupling and cohesion in Object Oriented systems.
[11] Lionel Briand, Prem Devanbu, and Walcelio Melo. An investigation into coupling measures for C++.
[12] Edward Yourdon and Larry L. Constantine. Structured Design.
[13] Shyam R. Chidamber, David P. Darcy, and Chris F. Kemerer. Managerial use of metrics for Object-Oriented software
[14] Premkumar T. Devanbu. GENOA - a customizable, language- and front-end independent code analyzer
[15] M. Ajmal Chaumun, Hind Kabaili, Rudolf K. Keller, and Francois Lustman. A change impact model for Interoperability assessment in
Object-Oriented systems.
[16] Poet Software Corporation, San Mateo, CA. POET Java ODMG Binding.
[17] Xforms Library. Graphical user interface for X. Documentation Set, 1997.
Authors
M.V.Vijaya Saradhi is Currently Associated Professor in the Department of Computer Science and Engineering (CSE) at Aurora's Scientific, Technological and Research Academy, (ASTRA), Bandlaguda, Hyderabad, India, where he teaches Several Courses in the area of Computer Science. He is Currently Pursuing the PhD degree in Computer Science at Osmania University, Faculty of Engineering, Hyderabad, India. His main research interests are Software Metrics, Distributed Systems, Object-Oriented Modeling (UML), Object-Oriented Software Engineering, Data Mining, Design Patterns, Object- Oriented Design Measurements and Empirical Software Engineering. He is a life member of various professional bodies like MIETE, MCSI, MIE, MISTE.
