International Journal of Computer Science and EngineEngineeringering Open Access Research Paper Volume-2, Issue-4 E-ISSN: 2347-2693 Hypotheses Verification for High Precision Cohesion Metric Kayarvizhy N 1*, Kanmani S 2 and Rhymend Uthariaraj V 3 1*Department of Computer Science and Engineering, AMC Engineering College, India 2 Department of Information Technology, Pondicherry Engineering College, India 3Ramanujan Computing Centre, India www.ijcaonline.org Received: 03/03/2014 Revised: 19/03/2014 Accepted: 15/04/201x4 Published: 30/04/2014 Abstract— Metrics have been used to measure many attributes of software. For object oriented software, cohesion indicates the level of binding of the class elements. A class with high cohesion is one of the desirable properties of a good object oriented design. A highly cohesive class is less prone to faults and is easy to develop and maintain. Several object oriented cohesion metrics have been proposed in the literature. In this paper, we propose a new cohesion metric, the High Precision Cohesion Metric (HPCM) to overcome the limitations of the existing cohesion metrics. We also propose seven hypotheses to investigate the relationship between HPCM and other object oriented metrics. The hypotheses are verified with data collected from 500 classes across twelve open source Java projects. We have used Pearson’s coefficient to analyze the correlation between HPCM and the metrics in the hypotheses. To further bolster our results we have included p-value to confirm the statistical significance of the findings. Keywords—Object Oriented Metrics; Cohesion; High Precision I. INTRODUCTION values. Li and Henry [10] proposed their version of lack of Object oriented design and development continues to be the cohesion (LCOM3) as the number of connected components most widely used methodology for designing high quality in a graph with methods as node and edges between each software. Ensuring the quality of such systems is of prime pairs of methods with at least one common attribute. Hitz interest. Eliminating defects that affect quality in early stages and Montazeri [11] enhanced the LCOM3 to include edges of software development life cycle, like design, saves cost for method to method invocations as well and named it and effort [1] [2] [3]. Object oriented design-level metrics LCOM4. Henderson-Sellers [12] came up with LCOM5 and their associated quality prediction techniques attempt to which included the number of distinct attributes accessed by ensure quality during the design and early coding phase. each method. LCOM3, LCOM4 and LCOM5 show high Many object oriented metrics have been proposed to values of cohesion even with a single common attribute compute an underlying property like cohesion, inheritance among methods. After LCOM5, the cohesion metrics and coupling. Cohesion metrics indicate how well the class proposed were direct cohesion metrics compared to the elements bind with each other. Since a class consists of two inverse nature of lack of cohesion metrics proposed till then. basic sets of elements, attributes and methods, all of the The first direct cohesion metric, Connectivity (Co) was cohesion metrics revolve around the usage of these. A high introduced by Hitz and Montazeri [13]. Briand et al [21] cohesion value indicates that the class is well structured and proposed Coh which uses the concept of number of attributes provides the stated functionality with the help of well-knit used by each method. Bieman and Kang [14] introduced attributes and methods [4]. Conversely a low cohesive value TCC (Tight class cohesion) and LCC (Loose class cohesion) indicates a class that may need to be split or redesigned. A which captured the methods connected through attributes non-cohesive class is a maintenance nightmare and is prone directly and indirectly. Badri [15] introduced variations on to faults [5] [6] [7]. TCC and LCC naming them DCD and DCI which includes Several cohesion measures have been proposed in the method invocations also, directly or in the call trace literature. Chidamber and Kemerer [8] proposed the first respectively. TCC, LCC and their derivatives DCD and DCI cohesion metric. They presented an inverse metric, thus also give skewed cohesion values when a single common measuring the lack of cohesion (LCOM1). LCOM1 attribute exists in all methods. The metrics that were measures the number of pairs of methods that do not have proposed further were based on the similarity between any common attribute. Chidamber and Kemerer [9] revised methods based on the number of common attributes used their metric and came up with an altered version (LCOM2) between them. Bonja and Kidanmariam [16] defined Class which found the difference between the number of pairs of Cohesion (CC) based on this similarity of methods. The methods not sharing any attribute and those sharing at least concept was further enhanced by Fernandez and Pena [17] in one attribute. LCOM1 and LCOM2 do not have normalized their metric Sensitive Class Cohesion Metric (SCOM). Bansiya et al. [18] defined Cohesion among Methods in a Corresponding Author: Kayarvizhy N, [email protected] class (CAMC) as a modified version of Co. Counsell et al © 2014, IJCSE All Rights Reserved 238 International Journal of Computer Sciences and Engineering Vol.-2(4), pp ( 238-243) April 2014 , E-ISSN: 2347-2693 [19] also introduced Normalized Hamming Distance (NHD) shared by majority of its methods. This is not realistically and Scaled Normalized Hamming Distance (SNHD) based captured by CC and SCOM. on how many attributes each method accesses. Al Dallal and The motivation for a new metric is to have a fine grain value Briand [20] came up with Low-level design Similarity based for cohesion. HPCM differentiates classes with similar but Class Cohesion (LSCC) which finds out how many methods not identical cohesion. HPCM values are normalized on a access each attribute. SCOM, CAMC, NHD, SNHD and scale of 0 to 1. LSCC give high cohesion values in the presence of few B. Definition of HPCM common attributes across methods. In this paper, we propose a new cohesion metric, the High The High Precision Cohesion Metric (HPCM) is based on Precision Cohesion Metric (HPCM) to address the two related concepts – Average Attribute Usage (AAU) and limitations in the existing cohesion metrics. HPCM is Link Strength (LS). The AAU is a separate metric which designed to give precise cohesion values. We then analyze computes the average number of attributes used by each the proposed metric with hypotheses. This paper is organized method of the class directly or indirectly through a method as follows. Section 2 explains the High Precision Cohesion invocation. We consider only public, non-inherited methods Metric (HPCM) in detail. In Section 3 we propose seven of a class. Inherited attributes are also not considered for hypotheses capturing the relation between HPCM and other computation of AAU. Let ’c’ be the class in consideration. OO metrics. These hypotheses are verified empirically in Then is the set of non-inherited, overriding or newly Section 4. Section 5 lists the limitations and future work and implemented͇ ʚ͗ʛ methods of c. Further is the set of Section 6 concludes the study followed by a list of public methods of c. Public non-inherited͇+0 ʚ͗ ʛ or overridden references. methods are given by . The total number of methods in our case ͇is ʚthe͗ʛ ∩cardinality ͇+0 ʚ͗ʛ of such a set. It is II. HIGH PRECISION COHESION METRIC given by . The attributes referenced by a |͇ ʚ͗ʛ ∩ ͇+0 ʚ͗ʛ| A. Limitations of existing Cohesion Metrics method is given by AR(m) where m is the method. Hence total attributes referenced is given by , for each m LCOM1 and LCOM2 are not normalized in their value and in the set . Hence the∑ ̻͌ʚ͡ʛ AAU is given in hence it is difficult to compare their values between two Equation (1).͇ ʚ͗ʛ ∩ ͇+0 ʚ͗ʛ classes and understand their relative cohesion. Their values are dependent on the number of methods in a class. Hence their values can grow to very high values. Consider two ∑ ̻͌ ʚ͡ʛ (1) classes, c1 and c2 which have two and four methods each. ̻̻͏ = ʚ ʛ +0 ʚ ʛ The attributes accessed by the methods are listed here - c1m1 |͇ ͗ ∩ ͇ ͗ | {a1}, c1m2 {a2}, c2m1 {a1}, c2m2 {a2}, c2m3 {a3}, c2m4 Link Strength is a concept to capture the level of interaction {a4}. Each method accesses just a single unique attribute in between a pair of methods based on the number of attributes both the classes. But the values of LCOM1 and LCOM2 are commonly used between them. Link Strength (LS) is based very different for the classes. LCOM1(c1) = LCOM1(c2) = 1 on AAU. LS for a pair of methods m1 and m2 is given in and LCOM2(c1) = LCOM2(c2) = 6. Equation (2). LCOM3 and LCOM4 are also not normalized in their value but the range is improved over LCOM1 and LCOM2. But LCOM3 and LCOM4 suffer from a different issue. Consider ̻̽(ͥ(ͦ = |̻͌ ʚ͡1ʛ ∩ ̻͌ ʚ͡2ʛ| class c1 with the following method-attribute interactions - (2) ̻̽(ͥ(ͦ c1m1 {a1, a2, a4}, c1m2 {a3, a5, a4}, c1m3 {a6, a7, a4}, , ͚͝ ̻̽(ͥ(ͦ ≤ ̻̻͏ c1m4 {a7, a8, a4}, c1m5 {a9, a10, a4}, c1m6 {a11, a12, a4}. ͍͆ (ͥ(ͦ = ƥ ̻̻͏ The methods are not cohesive since they all share just one 1, ͚͝ ̻̽(ͥ(ͦ > ̻̻͏ common attribute between them and use their own unique set of attributes otherwise. However LCOM3 and LCOM4 HPCM is defined using Link Strength. We define HPCM as give the class a perfect cohesion value of 1. The same given in Equation (3) limitation applies to TCC, LCC, DCD and DCI. CC and SCOM cohesion metrics vastly improve on the idea of similarity.