\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Impact of Mediated relations as Confounding Factor on Cohesion and Coupling Metrics: For Measuring Fault Proneness in Oo Software Quality Assessment},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2012-01-15 (revised: 15 January 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-01-15}
\title{Impact of Mediated relations as Confounding Factor on Cohesion and Coupling Metrics: For Measuring Fault Proneness in Oo Software Quality Assessment}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{  Amjan.Shaik}

             \author[2]{  Amjan.Shaik}

             \author[3]{  Dr.C.R.K.Reddy}

             \affil[1]{  JNTUH, Hyderabad, Andhra Pradesh, India.}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2011 Accepted: 1 January 2012 Published: 15 January 2012}

\maketitle


\begin{abstract}
        


Mediated class relations and method calls as a confounding factor on coupling and cohesion metrics to assess the fault proneness of object oriented software is evaluated and proposed new cohesion and coupling metrics labeled as mediated cohesion (MCH) and mediated coupling (MCO) proposed. These measures differ from the majority of established metrics in two respects: they reflect the degree to which entities are coupled or resemble each other, and they take account of mediated relations in couplings or similarities. An empirical comparison of the new measures with eight established metrics is described. The new measures are shown to be consistently superior at measure the fault proneness.

\end{abstract}


\keywords{}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
bject Oriented (OO) design and code, for instance, \hyperref[b0]{[1,}\hyperref[b1]{2,}\hyperref[b2]{3,}\hyperref[b3]{4,}\hyperref[b4]{5,}\hyperref[b5]{6,}\hyperref[b6]{7,}\hyperref[b7]{8,}\hyperref[b8]{9,}\hyperref[b9]{10,}\hyperref[b10]{11,}\hyperref[b11]{12,}\hyperref[b12]{13,}\hyperref[b13]{14,}\hyperref[b14]{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 \hyperref[b2]{[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 \hyperref[b15]{[16,}\hyperref[b16]{17,}\hyperref[b17]{18,}\hyperref[b18]{19,}\hyperref[b4]{5,}\hyperref[b19]{20,}\hyperref[b20]{21,}\hyperref[b21]{22,}\hyperref[b22]{23,}\hyperref[b7]{8,}\hyperref[b11]{12,}\hyperref[b23]{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.\par
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.\par
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.\par
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.\par
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. 
\section[{II.}]{II.} 
\section[{The Coupling and Cohesion in OO Programming a) Measuring Coupling}]{The Coupling and Cohesion in OO Programming a) Measuring Coupling}\par
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.\par
Though this seems like a difficult task, OO metrics can help you to measure the right level of coupling.\par
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.\par
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.\par
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.\par
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.\par
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.\par
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. 
\section[{Definition 3 (associate Class}]{Definition 3 (associate Class}): A class 1 C is an acquaintance class of method M attached to class 2 C , if 1\par
C is a supplier to M and 1 C is not one of the following:\par
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\par
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 . 
\section[{b) Measuring Cohesion}]{b) Measuring Cohesion}\par
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.\par
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. 
\section[{The LCOM Metric: Lack of Cohesion in Methods}]{The LCOM Metric: Lack of Cohesion in Methods}\par
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: 
\section[{(}]{(}\par
) ( ) 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\par
where m, a, mA, sum mA are as defined in LCOM2. 
\section[{= ? ?}]{= ? ?}\par
The following points should be noted about LCOM3:\par
The LCOM3 value varies between 0 and 2. LCOM3>1 indicates the shortage of cohesion and is considered a kind of alarm.\par
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).\par
Each of these different measures of LCOM has a unique way to calculate the value of LCOM.\par
An extreme lack of cohesion such as LCOM3>1 indicates that the particular class should be split into two or more classes.\par
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.\par
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. 
\section[{III.}]{III.} 
\section[{Mediated relations of classes and method calls as confounding factor a) Confounding Factor}]{Mediated relations of classes and method calls as confounding factor a) Confounding Factor}\par
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 \hyperref[b16]{[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 \hyperref[b17]{[18]}.\par
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 \hyperref[b15]{[16]}, \hyperref[b16]{[17]}, \hyperref[b18]{[19]}, \hyperref[b19]{[20]}, \hyperref[b20]{[21]}, \hyperref[b21]{[22]}. Among these models, the confounding factor analysis model based on linear regression techniques has been widely used in health sciences and epidemiological research \hyperref[b15]{[16]}, \hyperref[b18]{[19]}, \hyperref[b19]{[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 \hyperref[b15]{[16]}, \hyperref[b18]{[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 \hyperref[b15]{[16]}, \hyperref[b19]{[20]}. 
\section[{b) Mediated relation as dependent variable}]{b) Mediated relation as dependent variable}\par
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.  
\section[{Mediated coupling between objects[mcbo]}]{Mediated coupling between objects[mcbo]}\par
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 ? = ? ?\par
, the directed edge weight also can refer as degree of direct coupling (DDC) between two classes cw is always between 0 and 1.\par
b) Finding a degree of mediated coupling (DMC)\par
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\par
? 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 
\section[{C and k C c) Applying Confounding factor}]{C and k C c) Applying Confounding factor}\par
The confounding factor of path p is ( )p cf , that\par
assessed as follows:| | 1 ( ) ( , ) | | ( ) e p cf C C p j k e p ? = ?\par
Here in the above equation( ) p\par
e is set edges that belongs to the path p .\par
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 = ? ? ? ? + ? ? ? ? ? ? ? = ? ?\par
The following hypothesis is a convention from the empirical study conducted on applications that are confirmed as fault prone:\par
If ' mcw 'is the degree of mediated coupling between two objects O objects in application's fault proneness.\par
V. 
\section[{Mediated cohesion (mch)}]{Mediated cohesion (mch)}\par
The proposed cohesion metric is based on transitive function calls. The Hypothesis of the proposed cohesion metric can be defined as:\par
We build a graph based on the function calls between the functions of the same class.\par
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)\par
The Degree of Direct Cohesion Between two functions that represents the edge weight can be generalized as follows:  
\section[{Year}]{Year}\par
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 = ? ? ? ? + ? ? ? ? ? ? ? = ? ?\par
Since the class level cohesiveness is significant to predict the fault proneness than the method level cohesiveness.\par
The class level confounding factor of a class C measures as follows:( ) 1 1 | ' | | | C ccf P mC = ? ? ? ? ? ? ?\par
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 = ? ? ? + ? ? ? ? ? = ? ?\par
Here in the above equation  
\section[{Results analysis}]{Results analysis}\par
We conducted experiments on applications build under SDLC standards. We make sure the heterogeneity in of classes of the applications considered for experiments. We  
\section[{Conclusion}]{Conclusion}\par
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. 
\section[{Mediated Cohesion between the methods of a class}]{Mediated Cohesion between the methods of a class}\par
is having an impact of the number of paths build between any two methods of a class as confounding factors.\par
These two metrics MCBO and MCH are measuring as numeric values rather in binary quantity. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_3}}\end{figure}
   \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
39\\
Volume XII Issue XIII Version I\\
D D D D )\\
(\\
Global Journal of Computer Science and Technology\end{longtable} \par
 
\caption{\label{tab_0}}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US)Global Journal of Computer Science and Technology} 		 		\backmatter  			 \par
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:\par
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\par
? 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 ? .\par
p is one of the path out of set of paths P 			 			  				\begin{bibitemlist}{1}
\bibitem[Chidamber and Kemerer ()]{b5}\label{b5} 	 		‘A metrics Suite for Object-Oriented Design’.  		 			S Chidamber 		,  		 			C Kemerer 		.  	 	 		\textit{IEEE Trans. Software Engineering}  		1994. 20  (6)  p. .  	 
\bibitem[Tegarden et al. ()]{b14}\label{b14} 	 		‘A Software Complexity Model of Object-Oriented Systems’.  		 			D Tegarden 		,  		 			S Sheetz 		,  		 			D Monarchi 		.  	 	 		\textit{Decision Support Systems}  		1995. 13  (3-4)  p. .  	 
\bibitem[Briand et al. ()]{b1}\label{b1} 	 		‘A Unified Framework for Cohesion Measurement in Object-Oriented Systems’.  		 			L Briand 		,  		 			J Daly 		,  		 			J Wust 		.  	 	 		\textit{Empirical Software Engineering}  		1998. 3 p. .  	 
\bibitem[Briand et al. ()]{b2}\label{b2} 	 		‘A Unified Framework for Coupling Measurement in Object-Oriented Systems’.  		 			L Briand 		,  		 			J Daly 		,  		 			J Wust 		.  	 	 		\textit{IEEE Transactions on software Engineering}  		1999. 25 p. .  	 
\bibitem[Basili et al. ()]{b15}\label{b15} 	 		‘A Validation of Object-Oriented Design Metrics as Quality Indicators’.  		 			V Basili 		,  		 			L Briand 		,  		 			W Melo 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1996. 22  (10)  p. .  	 
\bibitem[Elemam et al. ()]{b20}\label{b20} 	 		\textit{A Validation of Object-Oriented Metrics},  		 			K Elemam 		,  		 			S Benlarbi 		,  		 			N Goel 		,  		 			S Rai 		.  		 ERB-1063.  		1999.  		 			National Research Council of Canada (NRC 		 	 	 (Technical Report) 
\bibitem[Cartwright and Shepperd (2000)]{b4}\label{b4} 	 		‘An Empirical Investigation of an Object-Oriented Software System’.  		 			M Cartwright 		,  		 			M Shepperd 		.  	 	 		\textit{IEEE Transactions of Software Engineering},  				Aug. 2000. 26 p. .  	 
\bibitem[Harrison et al. ()]{b7}\label{b7} 	 		‘An Evaluation of MOOD set of Object-Oriented Software Metrics’.  		 			R Harrison 		,  		 			S J Counsell 		,  		 			R V Nithi 		.  	 	 		\textit{IEEE Trans. Software Engineering}  		1998.  (6)  p. .  	 
\bibitem[Aggarwal et al. ()]{b0}\label{b0} 	 		‘Analysis of Object-Oriented Metrics’.  		 			K K Aggarwal 		,  		 			Yogesh Singh 		,  		 			Ruchikamalhotra Arvinderkaur 		.  	 	 		\textit{International Workshop on Software Measurement (IWSM)},  				 (Montréal, Canada)  		2005.  	 
\bibitem[Bieman and Kang ()]{b3}\label{b3} 	 		‘Cohesion and Reuse in an Object-Oriented System’.  		 			J Bieman 		,  		 			B Kang 		.  	 	 		\textit{Proc. CM Symp. Software Reusability (SSR'94)},  				 (CM Symp. Software Reusability (SSR'94))  		1995. p. .  	 
\bibitem[Gyimothy et al. (2005)]{b22}\label{b22} 	 		‘Empirical validation of object-oriented metrics on open source software for fault prediction’.  		 			T Gyimothy 		,  		 			R Ferenc 		,  		 			I Siket 		.  	 	 		\textit{IEEE Trans. Software Engineering}  		Oct. 2005. 31 p. .  	 
\bibitem[Briand et al. ()]{b17}\label{b17} 	 		‘Exploring the relationships between design measures and software quality’.  		 			L Briand 		,  		 			J Daly 		,  		 			V Porter 		,  		 			J Wust 		.  	 	 		\textit{Journal of Systems and Software}  		2000. 5 p. .  	 
\bibitem[Chidamber et al. ()]{b19}\label{b19} 	 		‘Managerial use of Metrics for Object-Oriented Software: An Exploratory Analysis’.  		 			S Chidamber 		,  		 			D Darcy 		,  		 			C Kemerer 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1998. 24  (8)  p. .  	 
\bibitem[Hitz and Montazeri ()]{b9}\label{b9} 	 		‘Measuring Coupling and Cohesion in Object-Oriented Systems’.  		 			M Hitz 		,  		 			B Montazeri 		.  	 	 		\textit{Proc. Int. Symposium on Applied Corporate Computing},  				 (Int. Symposium on Applied Corporate ComputingMonterrey, Mexico)  		1995.  	 
\bibitem[Lee et al. ()]{b12}\label{b12} 	 		‘Measuring the Coupling and Cohesion of an Object-Oriented program based on Information flow’.  		 			Y Lee 		,  		 			B Liang 		,  		 			S Wu 		,  		 			F Wang 		.  	 	 		\textit{International Conference on Software Quality},  				 (Maribor, Slovenia)  		1995.  	 
\bibitem[Li and Henry ()]{b11}\label{b11} 	 		‘Object-Oriented Metrics that Predict Maintainability’.  		 			W Li 		,  		 			S Henry 		.  	 	 		\textit{Journal of Systems and Software}  		1993. 23  (2)  p. .  	 
\bibitem[Henderson-Sellers ()]{b8}\label{b8} 	 		\textit{Object-Oriented Metrics, Measures of Complexity},  		 			B Henderson-Sellers 		.  		1996. Prentice Hall.  	 
\bibitem[Lorenz and Kidd ()]{b13}\label{b13} 	 		\textit{Object-Oriented Software Metrics},  		 			M Lorenz 		,  		 			J Kidd 		.  		1994. Prentice-Hall.  	 
\bibitem[Ping and Xiaoxing ()]{b23}\label{b23} 	 		\textit{Predicting Degree of Fault prone using OO Metrics: An Industrial Case Study},  		 			Yu Ping 		,  		 			Ma Xiaoxing 		,  		 			Lujian 		.  		2002. Budapest, Hungary. p. .  	 
\bibitem[Briand et al. ()]{b18}\label{b18} 	 		‘Replicated Case Studies for Investigating Quality Factors in Object-Oriented Designs’.  		 			L Briand 		,  		 			J Wüst 		,  		 			H Lounis 		.  	 	 		\textit{Empirical Software Engineering: An International Journal}  		2001. 6 p. .  	 
\bibitem[Elemam et al. ()]{b21}\label{b21} 	 		‘The Prediction of Faulty Classes Using Object-Oriented Design Metrics’.  		 			K Elemam 		,  		 			W Melo 		,  		 			J Machado 		.  	 	 		\textit{Journal of Systems and Software}  		2001. 56 p. .  	 
\bibitem[Chidamber and Kemerer ()]{b6}\label{b6} 	 		‘Towards a Metrics Suite for Object Oriented design’.  		 			S Chidamber 		,  		 			C Kemerer 		.  	 	 		\textit{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 p. .  	 	 (Published in SIGPLAN Notices) 
\bibitem[Lake and Cook ()]{b10}\label{b10} 	 		‘Use of factor analysis to develop OOP software complexity metrics’.  		 			A Lake 		,  		 			C Cook 		.  	 	 		\textit{Proc. 6th Annual Oregon Workshop on Software Metrics},  				 (6th Annual Oregon Workshop on Software MetricsSilver Falls, Oregon)  		1994.  	 
\bibitem[Binkley and Schach ()]{b16}\label{b16} 	 		‘Validation of the Coupling Dependency Metric as a risk Predictor’.  		 			A Binkley 		,  		 			S Schach 		.  	 	 		\textit{International Conference on Software Engineering (ICSE)},  				1998. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
