Package Based Cohesion Measurement in Component Based Software Development

The good software design is based on low coupling and high cohesion. Component based software engineering is based on the concept of component reuse but Every time it is not possible to adapt the component according to user requirementsso it’s better to check the reliability of components before using them. Packages are re-usable components for mostof object-oriented systems. To promote reuse in object-oriented systems and to make deployment and maintenance tasks easy, the standard relationship between the packages, classes and methods must be cohesive. Identification of reliable component can help to find the reusable components and also affecting the quality of software in component based development environment. In this pa-per, a new measure for the measurement of package cohesion is used on a real data set for the better results. The cohesion of a component is measured by considering the standard relationship between the packages, classes and methods. The hierarchical structure of packages has also been taken into account during the measurement. The used measure has been validated theoretically as well as empirically. An empirical study has been conducted using 25 packages taken from six open-source software projects developed in Java.

counting of number of methods in the class and weighting scheme was used at that time for the prioritization of methods that which have to usefirst The approach of mod-ule cohesion measurement that is based on data slices was proposed by Bieman and Ott [13]. Bieman and Kang came up with another metric defined as TCC(Tight class cohesion and LCC(Loose class cohesion) based on the usage of direct or indirect attributes by public methods of the class. A many number of methods or measures proposed for In-house or OSS components are summarized below:-  (1994) This method is based on counting Of number of methods in a class and no we scheme has been used For the prioritization of methods. This has been left as an implementation part S.Chidamber and C.F.Kemere, "A Metric object oriented Design" IEEE Transact Software Engineering" Vol 20,1994 Depth of Inheritance (DIT) This metric is somewhat to be uncertain because it is based on the hierarchy of the class to the root node and it may be as simple as well as complex for the different users. It also fails to satisfy the 4 th property of Weyuker's property of monotonicity.
S.Chidamber and C.F.Kemere, "A Metric Suite for object oriented Design"IEEE Transactions on Software Engineering" Vol 20,1994 Number of Children (NOC) It is also based on the concept of inheritance and will give only the approximation values.
S.Chidamber and C.F.Kemere, "A Metric Suite for object oriented Design"IEEE Transactions on Software Engineering" Vol 20,1994 CBO It is simply the count of number of classes to which it is coupled. It cannot be fruitful because generally we need the low coupling and high cohesion.

Theoretical Summarization of measurement
In the following section we provide the basics of packages, classes and methods as well as their standard hierarchy have to be taken in to consideration. Definition of packages, classes, methods For the purpose of cohesion measurement, a package is de-fined as a set of elements (classes, interfaces or packages) and relations between elements. Generally a software is made up of thousand number of lines of code and for placing the appropriate interfaces and methods in to appropriate way packages are required. Empty Packages When a package is having no element so no relations exist between the elements therefore termed as an empty package and in that case the cohesion value can be considered as zero. Classes can be called as bunch of objects or it's a way with the help of which objects can be defined. Package cohesion measurement approach using package cohesion component complexity metric (PC 3 M) Software metric plays a vital role in quantative assessment of any specific software development methodology and its impact on the maintenance of software. Component based software engineering (CBSE) is gaining substantial interest in the software engineering community. A lot of research efforts have been devoted to the coupling and cohesion metric for components in CBSE and a number of complexities metric have been proposed in the past. Complexity metric are calculated at package level by considering the relationship between the packages, classes and methods. Merely selection of less complex and reliable components is not sufficient but we have to select the optimal components for the software system including the factor of coupling and cohesion. We have proposed a new component coupling and component cohesion metric using the concept of component dependency to increase the reliability of software [10]. Various no of steps used in calculating the package cohesion component complexity metric will be as follows:-1) Considering the real data set. 2) Finding the parameters like DUM, IUM, and NDIUC. 3) Calculating the package cohesion complexity metric. This value comes out to be as higher as possible. Higher value of PC3M wills leads to low complexity of software. Parameters used in the metric are defined as follows:-DUM:-It is the set of all direct connections between classes and methods. NDIUC: -It is the number of used direct or indirect connections in the case study and it can be calculated as n(n-1)/2 where n is the total number of packages in the case study.The formula of n(n-1)/2 has been taken from the concept of TCC (Tight class cohesion) and LCC (Loose Class Cohesion) metric PC3M:-Package cohesion component complexity metric.

PC3M =
Where n is the number of elements(classes,methods) Other cases:-If n=0, there is no element so no possible relation therefore computed value of PC 3 M is also 0. If n=1 means a single element is existing so the relation existing will also be single, hence the value of PC 3 M is also 1 The computed value of cohesion measured by the PCoh Approach was 0.334 [22].Now the calculation by using the PC3M approach is as follows:-DUM:-Since the package myshapes is having a single method so a single direct connection is existing hence the value of DUM is 1. NDIUC=n (n-1)/2 Since no of packages used are 3 therefore n (n-1)/2 gives value 3 so 1/3=0.333 Therefore the value computed using PC3M Comes out to be less than PCOH.

Theoretical validation of package cohesion component complexity measure
The purpose of this section is to validate the package cohesion component complexity measure by using the four properties of Briand et al. [22].Many number of reviewers have used Weyuker's properties or framework for the validation of their proposed complexity metric. Some other evaluation frameworks such as Zuse framework [23] and Tian & Zelkowitz [24] axioms are also used for valida-tion of complexity measures.Briand et al. are the recent proposal for validating the metric.

Property 1:Non-Negativity and Normalization.
According to the above explanation given in the summarization of proposed measure the computed value of PC3M belongs to a specified interval of [0,10].Therefore the value computed by using above already defined measure will always be non-negative as well as normalized.

Property 2: Null Value and Maximum Value.
Whenever the component is empty then the value assigned to be as 0 because no relations between the packages classes and methods are existing in such a case so null value property is satisfied. If the component is having a single element then some types of relations between the packages, classes and methods are existing and the maximum value defined to be 1. Hence the measure satisfies the property 2. Since the adding of relations in to the component will increases the value of DUM but simultaneously the value of IUDM get also increased as (IUDM=direct connection + indirect connection).hence adding more number of relations will not decrease the cohesion value and hence it satisfies the property of monotonicity.

Property 4: Merging of Unconnected Packages.
According to this property the merging of two unconnected packages should not increase the value of cohesion. The package cohesion component complexity metric satisfies this property by the fact that if the packages are added or merged the value in the denominator will also increase with the value in the numerator and also the calculation of parameters are totally based on number of packages not on the merging or the connection of packages.

Experimental validation of proposed measure
In this section we are focussing on the experimental validation of package cohesion component complexity metric and showing the improved results of reliability with the impact on reusability. This would help us to evaluate the proposed package cohesion component complexity metric as a quality indicator. Experiment analysis The purpose of the following experimental study is to analyse experimentally the proposed metric for the purpose of evaluating the utility of the metric by comparing the values with the PCOh metric values. We used the template or guidelines provided for defining the measurement goas [25]. The measurement goal can defined as follows: • Object of study: Number of packages and the relation between the packages, classes and methods.
• Purpose: analysis and comparison with the pcoh metric values. • Quality focus: effort required to reuse a component (component Reusability).
• Environment: open-source software projects developed in Java. These above defined goals help to determine the type of data to be collected. Empirical hypotheses An empirical hypothesis is a statement believed to be true about the relation between one or more attributes of the object of study and the quality focus [26]. In this case, the hypotheses about the relationship between the packages, classes and methods and reusability of component (Quality focus) The analysis is based on the hypotheses: Hy 0 : q=0 (Null hypothesis)-There is no significant cor-relation between the proposed package cohesion component complexity metric and component reusability. Hy 1 : q=0 (Alternative hypothesis)-There is significantcorrelation between the proposed package cohesion component complexity metric and component reusability. Experimental environment There are a various number of open source software projects available on the web for a many number of purposes. "The sample used for this experimental study was taken from six open-source software projects whose source code was readily available for use. The major reason behind selection of these projects was that these software projects were developed in Java and were organized using packages. The presence of packages in these projects made it possible to apply package level metrics on them. Twenty-five pack-ages taken from six opensource projects were used in or-der to experimentally evaluate the proposed metric. Out of these six projects, four belonged to the Apache soft-ware foundation and eighteen packages belonging to these four projects were downloaded from Apache Jakarta web-site" [22,27]. Analysis methodology A statistical analysis is performed to correlate the proposed package cohesion component complexity metric with component reusability for component based software and also the computed values are also compared with the Pcoh metric for examine the improved results. For the empirical validation of metrics correlation is the suitable technique. Li and Henry studied the various metrics and also correlate them to determine their usefulness [28]. Karl person Correlation coefficient isused for measuring the correlation.
This method assumes that there is a linear relationship between two variables and one of the variables is independent while the other is dependent. Karl Pearson's coefficient of correlation is given by [29]: where X i = ith value of X variable, Y i = ith value of Y variable, X = mean of X, Y = mean of Y , n = number of pairs of observations of X and Y , σ x = standard deviation of X, σ y = standard deviation of Y . The value of correlation coefficient (r ) lies between −1 and +1 through 0, where 1 represents a perfect positive cor-relation between the variables; −1 denotes a perfect nega-tive correlation; and 0 indicates that there is no linear rela-tionship between the variables. The degree of the correlation is determined by the magnitude of the coefficient [22] The ratings for the cohesion can be defined as:-• 0 "minimum" • 1.0 to 2.0 "just above the minimum" • 2.0 to 0.5 "average" • 4.0 to 5.0 "Best" • 5.0 to 7.0 "optimum".  We are using the following facts as:-Number of elements consisting of interfaces and subpackages.so Total number of classes-no of elements=filtered classes Now because in this real data set only a single package is used in a single component so the direct connection between the classes and methods are the filtered classes.   From the above results it can be concluded that we can reject the null hypothesis and can trust on the alternative hypothesis. Hence there is a strong relation between the calculation of package cohesion component complexity metric and the component reusability.

Conclusions and future work
In this paper, we have analysed the package cohesion component complexity metric and he results are also compared with the previous Package cohesion metric. The PC3M is also validated using the recent used properties. The proposed measures are based on the direct and indirect relations between classes and methods. The standard hierarchal structures of package have also been taken in to consideration. We believe that this metric will help the other developers and OSS users for the calculation of complexity based on the concept of cohesion. In future rather than reusability, this metric can be used in order to establish the relations with some other factors in component based development environment like maintainability, adaptability.