# Introduction

bject Oriented (OO) design and code, for instance, [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]. These metrics offer ways to evaluate the excellence of software and their use in former phases of software development can help organizations in evaluating large software development quickly, at a low cost [3]. But how do we know which metrics are functional in capturing important quality attributes such as Degree of Fault prone, effort, efficiency or amount of maintenance adaptations. Experiential studies of real systems can provide relevant answers. There have been few empirical studies evaluating the effect of objectoriented metrics on software quality and constructing models that utilize them in predicting quality attributes in the system, such as [16,17,18,19,5,20,21,22,23,8,12,24]. More data based by empirical studies, which are capable of being verified by observation or experiment are needed. The evidence gathered through these empirical studies is today considered to be the most powerful support possible for testing a given hypothesis.

A well designed component, in which the functionality has been appropriately distributed to its various subcomponents, is more likely to be fault free and will be easier to adapt. Appropriate distribution of function underlies two key concepts of object-oriented design: coupling and cohesion. Coupling is the extent to which the various subcomponents interact. If they are highly interdependent then changes to one are likely to have significant effects on the behavior of others. Hence loose coupling between its subcomponents is a desirable characteristic of a component. Cohesion is the extent to which the functions performed by a subsystem are related. If a subcomponent is responsible for a number of unrelated functions then the functionality has been poorly distributed to subcomponents. Hence high cohesion is a characteristic of a well designed subcomponent.

Many metrics have been proposed to measure the coupling and cohesion to predict the fault-prone and maintainability of software. However, few studies had been done using coupling and cohesion to assess the quality of components.

In this context we therefore analyzed the mediated relations of the classes and method calls as a confounding factor for coupling and cohesion metrics and proposing two new metrics called Mediated coupling and Mediated cohesion to measure the fault proneness to assess the quality of the software.

The rest of the paper organized as, in section II the traditional cohesion and coupling metrics revealed, which followed by section III that explores transitivity as a confounding factor.


# II.


# The Coupling and Cohesion in OO Programming a) Measuring Coupling

The term coupling is usually used in a derogatory manner in design review meetings. Even so, it's not possible to design aefficient OO application without coupling. flexible, less scalable application software. However, coupling can be used so that it enables objects to talk to each other while also preserving the scalability and flexibility.

Though this seems like a difficult task, OO metrics can help you to measure the right level of coupling.

Coupling between Objects (CBO): CBO is defined as the number of non-inherited classes associated with the target class. It is counted as the number of types that are used in attributes, parameters, return types, throws clauses, etc. Primitive types and system types (e.g. Java.lang.*) is not counted.

Data Abstraction Coupling (DAC): DAC is defined as the total number of referring types in attribute declarations. Primitive types, system types, and types inherited from the super classes are not counted.

Method Invocation Coupling (MIC): MIC is defined as the relative number of classes that receive messages from a particular class. nMIC is the total number of classes that receive a message from the target class.

Demeter's Law: Ian Holland first proposed the Law of Demeter. The class form of Demeter's Law has two versions: a strict version and a minimized version. The strict form of the law states that every supplier class of a method must be a preferred supplier. The minimization form is more permissive than the first version and requires only minimizing the number of acquaintance classes of each method.

Definition 1 (Client): Method M is a client of method f attached to class C, if in M message f is sent to an object of class C , or to C . If f is specialized in one or more subclasses, then M is only a client of f attached to the highest class in the hierarchy.

Method M is a client of some method attached to C . Definition 2 (Supplier): If M is a client of class C then C is a supplier to M. In other words, a supplier class to a method is a class whose methods is called in the method. In Listing 1, the Product class is a supplier class to the client class Order.


# Definition 3 (associate Class
): A class 1 C is an acquaintance class of method M attached to class 2 C , if 1
C is a supplier to M and 1 C is not one of the following:

The same as 2 C ; A class used in the declaration of an argument of M A class used in the declaration of an instance variable of 2 C

Definition 4 (Preferred-supplier class): Class B is called a preferred-supplier to method M (attached to the class C ) if B is a supplier to M and one of the following conditions holds: B is used in the declaration of an instance variable of C B is used in the declaration of an argument of M , including C and its super classes. B is a preferred acquaintance class of M .


# b) Measuring Cohesion

In OO methodology, classes contain certain data and exhibit certain behaviors. This concept may seem fairly obvious, but in practice, creating welldefined and cohesive classes can be tricky. Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular classor of the application itself-the application software will eventually become unmanageable as more and more behaviors become scattered and end up in the wrong places.

Thus, one of the main goals of OO design is to come up with classes that are highly cohesive. Luckily, there's a metric to help to verify that the designed class is cohesive.


# The LCOM Metric: Lack of Cohesion in Methods

The Lack of Cohesion in Methods metric is available in the following three formats: LCOM1: Take each pair of methods in the class and determine the set of fields they each access. If they have disjointed sets of field accesses, the count P increases by one. If they share at least one field access, Q increases by one. After considering each pair of methods:


# (

) ( ) If the number of methods or variables in a class is zero (0), LCOM2 is undefined as displayed as zero (0). LCOM3: This is another improvement on LCOM1 and LCOM2 and is proposed by Henderson-Sellers. It is defined as follows:
RESULT P Q ? P Q : 0 => ? A low( ) ( ) ( ) ( ) LCOM3 m sum mA / a / m 1
where m, a, mA, sum mA are as defined in LCOM2.


# = ? ?

The following points should be noted about LCOM3:

The LCOM3 value varies between 0 and 2. LCOM3>1 indicates the shortage of cohesion and is considered a kind of alarm.

If there is only one method in a class, LCOM 3 is undefined and also if there are no attributes in a class LCOM3 is also undefined and displayed as zero (0).

Each of these different measures of LCOM has a unique way to calculate the value of LCOM.

An extreme lack of cohesion such as LCOM3>1 indicates that the particular class should be split into two or more classes.

If all the member attributes of a class are only accessed outside of the class and never accessed within the class, LCOM3 will show a high-value.

A slightly higher value of LCOM means that you can improve the design by either splitting the classes or re-arranging certain methods within a set of classes.


# III.


# Mediated relations of classes and method calls as confounding factor a) Confounding Factor

The term confounding refers to a situation in which an association between an independent variable and a dependent variable is thought to be the result of the influence of a third variable [17]. The suggestion is that an apparent association between the independent and dependent variables may be partly or completely accounted for by a third variable. By the same token, the absence of an apparent association between independent and dependent variables may be the result of a failure to account for the effects of a third variable. The third variable that distorts the true association between the independent and dependent variables is usually called a confounding variable. The distortion that results from perplexing may lead to overestimation or underestimation of an association, depending on the direction and magnitude of the relations that the confounding variable has with the independent and dependent variables [18].

To quantitatively analyze the confounding factor, a number of confounding factor analysis models using various modeling techniques, such as linear, logistic, and probity regression, have been developed [16], [17], [19], [20], [21], [22]. Among these models, the confounding factor analysis model based on linear regression techniques has been widely used in health sciences and epidemiological research [16], [19], [20]. Compared to models based on other modeling techniques, the linear-regression-based model has two main advantages: 1) A number of statistical methods have been developed for this model to test for a confounding variable [16], [19] and 2) it is easy to determine whether a confounding variable leads to overestimation or underestimation of the true association between the independent and dependent variables [16], [20].


# b) Mediated relation as dependent variable

The objective of this study is to empirically investigate to identify the cohesion and coupling metrics under consideration of mediated class relations and method calls as confounding factors and assessing the association between these cohesion and coupling metrics and degree of fault-proneDegree of Fault prone is an important external quality attribute and identifying faults-prone classes is very useful because: 1) It enables software developers to take focused preventive actions that can reduce maintenance costs and improve quality and 2) it helps software managers to allocate resources more effectively. In this study, Degree of Fault prone denotes the extent of class responsibility in component failure. We need to select the depth of the transitivity in class relations and method calls as the dependent variable for our study. 


# Mediated coupling between objects[mcbo]

We begin by regarding any object-oriented software system as a directed graph, in which the vertices are the classes comprising the system. Suppose such a system comprises a set of classes  
C (C |{ 1.. }) i C i m ? ? = . Let { } m(C ) m(C ) ( ) | ( 1.. ) j j i j m C i n ? ? =( ) ( ) 1 m mI mI C C C C j j i i = ? ? = ? a)( ) ( ) ( ) mI C C j i cw C C j i mI C C j ? = ? ?
, the directed edge weight also can refer as degree of direct coupling (DDC) between two classes cw is always between 0 and 1.

b) Finding a degree of mediated coupling (DMC)

Based on this degree of direct coupling between two classes, we can generalize the process of detecting the degree of mediated coupling mcw between any two classes j C and k C exists such that
( ) 0 mI C C j k ? ? , which follows: 1 1 ( , ) | | 1 mcw C C p e j k j k cw i i = ? ? ? ? ? ? ? ? ? ? = ? ? ( ) ( mI 0) j k C C iff ? ? In above equation e j k
? is the set of DDCs of edges, which are building path p between class j C and k C i cw is DDC of an edge i that belongs to j k e ? . p is one of the path out of set of paths P between j


# C and k C c) Applying Confounding factor

The confounding factor of path p is ( )
p cf , that
assessed as follows:
| | 1 ( ) ( , ) | | ( ) e p cf C C p j k e p ? = ?
Here in the above equation
( ) p
e is set edges that belongs to the path p .

Then the generalized degree of mediated coupling between class j C and k C
( ) mcw C C j k ? can be found as follows 1 1 ( ) | | ( ) ( , ) ( , ) 1 mcw C C P j k mcw cf C C i C C i j k j k i = ? ? ? ? + ? ? ? ? ? ? ? = ? ?
The following hypothesis is a convention from the empirical study conducted on applications that are confirmed as fault prone:

If ' mcw 'is the degree of mediated coupling between two objects O objects in application's fault proneness.

V.


# Mediated cohesion (mch)

The proposed cohesion metric is based on transitive function calls. The Hypothesis of the proposed cohesion metric can be defined as:

We build a graph based on the function calls between the functions of the same class.

The edge between any two functions represents thetotal number of similar properties used similar functions invoked in both functions. Finding Degree of Direct Cohesion(DDCH)

The Degree of Direct Cohesion Between two functions that represents the edge weight can be generalized as follows: 


# Year

If a method A invoking a method B and method B is invoking method C, then the connection between A and C can be considerable and their cohesiveness is transitive if and only if A,B and C belongs to a same class or classes in an inheritance hierarchy .
1 1 ( ) | | ( ) ( , ) ( , ) 1 mchw M M P j k mchw cf M M i M M i j k j k i = ? ? ? ? + ? ? ? ? ? ? ? = ? ?
Since the class level cohesiveness is significant to predict the fault proneness than the method level cohesiveness.

The class level confounding factor of a class C measures as follows:
( ) 1 1 | ' | | | C ccf P mC = ? ? ? ? ? ? ?
Since the the ration between number paths build in the graph and number of methods exists indicates the cohesiveness, if the majority of paths between same classes can be considered as a confounding factor. Hence the above equation justifies the measurement of the class level confounding factor. Then the class level mediated cohesiveness can be measured as follows:
1 1 ( ) | '| ( ) ( ) 1 mchw C P mchw ccf p C i i = ? ? ? + ? ? ? ? ? = ? ?
Here in the above equation 


# Results analysis

We conducted experiments on applications build under SDLC standards. We make sure the heterogeneity in of classes of the applications considered for experiments. We 


# Conclusion

These results clearly demonstrate that the proposed metrics MCBO and MCH for coupling and coherence are very good predictors for fault proneness. It is clearly identified that 1. Mediated coupling between two objects is having an impact of the number of connections and path length variation as confounding factors.


# Mediated Cohesion between the methods of a class

is having an impact of the number of paths build between any two methods of a class as confounding factors.

These two metrics MCBO and MCH are measuring as numeric values rather in binary quantity. 
![N isthe total number of classes defined within the project.](image-2.png "")
![value indicates high coupling between methods. This also indicates the potentially high reliability and good class design. Chidamber and Kemerer provided the definition of this metric in 1993. LCOM2: This is an improved version of LCOM1. Say you define the following items in a class: Volume XII Issue XIII Version I of methods in a class a : number of attributes in a class. mA : number of methods that access the attribute a. sum mA : sum of all mA over all the attributes in the class. LCOM2 1 sum mA / m *a = ?](image-3.png "")
![Finding a Degree of Directed Coupling (DDC)](image-4.png "")


39Volume XII Issue XIII Version ID D D D )(Global Journal of Computer Science and Technology
			© 2012 Global Journals Inc. (US)
			© 2012 Global Journals Inc. (US)Global Journal of Computer Science and Technology
		
		
			

then there an edge exists between these two methods. The graph is not a directed graph, since edge weight is not changing under any direction of direct connection between the two functions. The DDCH that referred as edge weight can be measured as follows:

Based on this degree of direct Cohesion between two methods, we can generalize the process of detecting the degree of mediated cohesion mchw between any two methods j M and k M of same class exists such that

? is the set of DDCHs of edges, which are building a path p between methods j M and k M i chw is DDCH of an edge i that belongs to j k e ? .

p is one of the path out of set of paths P 
			
			

				


* 
	
		Analysis of Object-Oriented Metrics
		
			KKAggarwal
		
		
			YogeshSingh
		
		
			RuchikamalhotraArvinderkaur
		
	
	
		International Workshop on Software Measurement (IWSM)
				Montréal, Canada
		
			2005
		
	




* 
	
		A Unified Framework for Cohesion Measurement in Object-Oriented Systems
		
			LBriand
		
		
			JDaly
		
		
			JWust
		
	
	
		Empirical Software Engineering
		
			3
			
			1998
		
	




* 
	
		A Unified Framework for Coupling Measurement in Object-Oriented Systems
		
			LBriand
		
		
			JDaly
		
		
			JWust
		
	
	
		IEEE Transactions on software Engineering
		
			25
			
			1999
		
	




* 
	
		Cohesion and Reuse in an Object-Oriented System
		
			JBieman
		
		
			BKang
		
	
	
		Proc. CM Symp. Software Reusability (SSR'94)
				CM Symp. Software Reusability (SSR'94)
		
			1995
			
		
	




* 
	
		An Empirical Investigation of an Object-Oriented Software System
		
			MCartwright
		
		
			MShepperd
		
	
	
		IEEE Transactions of Software Engineering
				
			Aug. 2000
			26
			
		
	




* 
	
		A metrics Suite for Object-Oriented Design
		
			SChidamber
		
		
			CKemerer
		
	
	
		IEEE Trans. Software Engineering
		
			20
			6
			
			1994
		
	




* 
	
		Towards a Metrics Suite for Object Oriented design
		
			SChidamber
		
		
			CKemerer
		
	
	
		Proc. Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'91)
				Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'91)
		
			1991
			26
			
		
	
	Published in SIGPLAN Notices




* 
	
		An Evaluation of MOOD set of Object-Oriented Software Metrics
		
			RHarrison
		
		
			SJCounsell
		
		
			RVNithi
		
	
	
		IEEE Trans. Software Engineering
		
			6
			
			1998
		
	




* 
	
		Object-Oriented Metrics, Measures of Complexity
		
			BHenderson-Sellers
		
		
			1996
			Prentice Hall
		
	




* 
	
		Measuring Coupling and Cohesion in Object-Oriented Systems
		
			MHitz
		
		
			BMontazeri
		
	
	
		Proc. Int. Symposium on Applied Corporate Computing
				Int. Symposium on Applied Corporate ComputingMonterrey, Mexico
		
			1995
		
	




* 
	
		Use of factor analysis to develop OOP software complexity metrics
		
			ALake
		
		
			CCook
		
	
	
		Proc. 6th Annual Oregon Workshop on Software Metrics
				6th Annual Oregon Workshop on Software MetricsSilver Falls, Oregon
		
			1994
		
	




* 
	
		Object-Oriented Metrics that Predict Maintainability
		
			WLi
		
		
			SHenry
		
	
	
		Journal of Systems and Software
		
			23
			2
			
			1993
		
	




* 
	
		Measuring the Coupling and Cohesion of an Object-Oriented program based on Information flow
		
			YLee
		
		
			BLiang
		
		
			SWu
		
		
			FWang
		
	
	
		International Conference on Software Quality
				Maribor, Slovenia
		
			1995
		
	




* 
	
		Object-Oriented Software Metrics
		
			MLorenz
		
		
			JKidd
		
		
			1994
			Prentice-Hall
		
	




* 
	
		A Software Complexity Model of Object-Oriented Systems
		
			DTegarden
		
		
			SSheetz
		
		
			DMonarchi
		
	
	
		Decision Support Systems
		
			13
			3-4
			
			1995
		
	




* 
	
		A Validation of Object-Oriented Design Metrics as Quality Indicators
		
			VBasili
		
		
			LBriand
		
		
			WMelo
		
	
	
		IEEE Transactions on Software Engineering
		
			22
			10
			
			1996
		
	




* 
	
		Validation of the Coupling Dependency Metric as a risk Predictor
		
			ABinkley
		
		
			SSchach
		
	
	
		International Conference on Software Engineering (ICSE)
				
			1998
			
		
	




* 
	
		Exploring the relationships between design measures and software quality
		
			LBriand
		
		
			JDaly
		
		
			VPorter
		
		
			JWust
		
	
	
		Journal of Systems and Software
		
			5
			
			2000
		
	




* 
	
		Replicated Case Studies for Investigating Quality Factors in Object-Oriented Designs
		
			LBriand
		
		
			JWüst
		
		
			HLounis
		
	
	
		Empirical Software Engineering: An International Journal
		
			6
			
			2001
		
	




* 
	
		Managerial use of Metrics for Object-Oriented Software: An Exploratory Analysis
		
			SChidamber
		
		
			DDarcy
		
		
			CKemerer
		
	
	
		IEEE Transactions on Software Engineering
		
			24
			8
			
			1998
		
	




* 
	
		A Validation of Object-Oriented Metrics
		
			KElemam
		
		
			SBenlarbi
		
		
			NGoel
		
		
			SRai
		
		ERB-1063
		
			1999
		
		
			National Research Council of Canada (NRC
		
	
	Technical Report




* 
	
		The Prediction of Faulty Classes Using Object-Oriented Design Metrics
		
			KElemam
		
		
			WMelo
		
		
			JMachado
		
	
	
		Journal of Systems and Software
		
			56
			
			2001
		
	




* 
	
		Empirical validation of object-oriented metrics on open source software for fault prediction
		
			TGyimothy
		
		
			RFerenc
		
		
			ISiket
		
	
	
		IEEE Trans. Software Engineering
		
			31
			
			Oct. 2005
		
	




* 
	
		Predicting Degree of Fault prone using OO Metrics: An Industrial Case Study
		
			YuPing
		
		
			MaXiaoxing
		
		
			Lujian
		
		
			2002
			
			Budapest, Hungary