\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={Comparison Study and Review on Object-Oriented Metrics},
 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-05-15 (revised: 15 May 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-05-15}
\title{Comparison Study and Review on Object-Oriented Metrics}
\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]{Amit  Sharma}

             \author[2]{Dr. Sanjay Kumar  Dubey}

             \author[3]{Prof. (Dr.) Ajay  Rana}

             \affil[1]{  Amity university}

\renewcommand\Authands{ and }

\date{\small \em Received: 7 April 2012 Accepted: 4 May 2012 Published: 15 May 2012}

\maketitle


\begin{abstract}
        


The best elucidations to software development problems are regularly touted as object-oriented processes. The popularity of object-oriented design metrics is essential in software engineering for measuring the software complexity, estimating size, quality and project efforts. There are various approaches through which we can find the software cost estimation and predicates on various kinds of deliverable items. Object-oriented metrics assures to reduce cost and the maintenance effort by serving as early predictors to estimate software faults. Such an early quantification augments the quality of the final software. This paper reviews object-oriented metrics. A comparison table is maintained via which we can analyze the difference between all the object-oriented metrics effectively.

\end{abstract}


\keywords{Object-Oriented, class, attributes.}

\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[{I. INTRODUCTION}]{I. INTRODUCTION}\par
bject-Oriented design is more beneficial in software development environment and objectoriented design metrics is an essential feature to measure software quality over the environment \hyperref[b0]{[1]}. object-oriented design is those design which contained all the properties and quality of software that is related to any large or small project \hyperref[b1]{[2]}. It is a degree through which a system object can hold a particular attribute or characteristics. object-oriented is a classifying approach that is capable to classify the problem in terms of object and it may provide many paybacks on reliability, adaptability, reusability and decomposition of problem into easily under stood objects and providing some future modifications \hyperref[b2]{[3]}. Software metrics makes it possible for software engineer to measure and predict software necessary resource for a project and project work product relevant to the software development effort. Metrics provide insight necessary to create and design model through the test. It also provide a quantative way to access the quality of internal attributes of the product, thereby it enables the software engineer to access quality before the product is build \hyperref[b3]{[4]}. Metrics are the crucial source of information through which a software developer takes a decision for design good software. Some metrics may be transformed to serve their purpose for a new environment. M. Alshayeb et al. \hyperref[b12]{[13]} have given two iterative procedures for the pragmatic study of object oriented metrics. They include the short-cycled agile process and the long cycled framework evolution process. By observing the results, it can be seen that the design efforts and source lines of code added, changed, and deleted were triumphantly predicted by object-oriented metrics in short-cycled agile process where as in the case long-cycled framework process the same features were not successfully predicted by it. This has shown that the design and implementation changes during development iterations can be predicted by objectoriented Metrics, but the same cannot be the case with long-term development of an established system. R.D. Neal et al. [20] also gives the study for the validation of the object-oriented software metrics and found that some of the proposed metrics could not be considered as the valid measure for the dimension then, they could be measured. He defined a model based on measurement theory of the validation through which they can proposed 10 new metrics -Potential Methods Inherited (PMI), Proportion of Methods Inherited by a Subclass (PMIS), Density of Methodological Cohesiveness (DMC), Messages and Arguments (MAA), Density of Abstract Classes (DAC), Proportion of Overriding Methods in a Subclass (POM), Unnecessary Coupling through Global Usage (UCGU), Degree of Coupling Between Class Objects (DCBO), Number of Private Instance Methods (PrIM), and Strings of Message Links (SML). R.  {\ref Harrison et al. [12]}suggested a statistical model which is obtained from the logistic regression for identifying threshold values for the Chidamber and Kemerer metrics. The process is authenticated empirically on a large Open-Source System-the Eclipse project. Their conclusion depending on the experimental results is that the Chidamber and Kemerer Metrics have threshold effects at different risk levels. The usefulness of these thresholds on later releases was authenticated with the aid of decision trees. Another conclusion by L.H. Ethzkorn \hyperref[b22]{[23]} is that the chosen threshold values were more precise than those were chosen depending on either intuitive perspectives or on data distribution parameters. object-oriented design metrics has also been assign the high level design quality attributes for the object-oriented software with the help of hierarchical model. H. Lieu. et al. \hyperref[b32]{[33]} have given perception that quality of software also plays an important role in terms of safety aspects and financial aspects. They bridged the gap between quality measurement and design of these metrics, with the help of measuring the excellence of object-oriented designs during development and redevelopment process of the software. M. Subramanyam et al. \hyperref[b33]{[34]} proposed some Metrics suites and concluded that for the developers, designs metrics are very important to know the design aspects of the software and to enhance the quality of software. Rachel Harrison et al. \hyperref[b34]{[35]} discussed about the six properties of metrics for object-oriented design (MOOD) Metrics and measured the object-oriented features like Inheritance, coupling, encapsulation, and polymorphism. In the result they showed that the metrics could be used to provide an overall assessment of the system. A. Goldberg et al. \hyperref[b45]{[46]} have experimentally checked size estimation models that are objectoriented. The pragmatic examination of object-oriented Function Points has been extended to a considerable amount with the aid of a bigger data set and by comparing Object Oriented Function Points with other predictors of LOC (Lines of Code) in their work. Linear models where the independent variable is either a conventional Object-Oriented entity or an Object-Oriented Function Points-related measure were built and assayed by using a cross validation approach. C. Shyam et al. \hyperref[b13]{[14]} suggests some software metrics through which we can calculating the quality of modularization of an object oriented software. They aimed that it provide a set of metrics for the large scale object oriented software system with having some dependencies and also provide some metrics for characterizing the quality for modularization regarding the APIs of the one side. On the another side, they provide some object-oriented dependencies like inheritance, associates relationship and base class designing. Y. Zhou et al. \hyperref[b53]{[54]} considered the fault severity using the machine learning methods with their experimental exploration of fault proneness which predict the capability of object-oriented design metrics and all of these of the predictions and the fault severity are also taken from the domain NASA data sets. J. Xu. et al. \hyperref[b52]{[53]} have proposed an object-oriented metrics which describes the fault estimation using empirical analysis and also used the CK metrics to apprise the number of faults in the particular program. This also includes some neural and fuzzy technique. At last, the result showed that we can get a dependable fault by using CBO, RFC, WMC, SLOC. Here SLOc is more considerable for the effect on the number of defects. C. Neelamegan et al. \hyperref[b44]{[45]} surveyed four object-oriented metrics and mostly focused on the measurements that are totally applied on the design and class characteristics. Dr. B.R. Sastry et al. \hyperref[b41]{[42]} trying to implement the graphics user interaction with the aid of software metrics and also tried to determine the quantity and quality of object oriented software development lifecycle. Metrics (i) and (iii) are very subjective in nature, Metrics (iv) and metric (vii) mostly involve the count of features; and metric (viii) is a Boolean (0 or 1) indicator metric. Therefore, all of the terminologies in object oriented language, consider as the basic components of the paradigm are objects, classes, attributes, inheritance, method, and message passing. They proposed all of that each object oriented metrics concept implies a programming behavior. defined the complexity of the object-oriented system in the form of the depth of the tree. Depth of the tree measures the number of the sub nodes of the tree. The more the number of sub nodes of tree the more complex the system. So, complexity of an object is equal to the depth of tree or total number of sub nodes. 
\section[{III. REVIEW OF METRICS}]{III. REVIEW OF METRICS} 
\section[{c) Lorenz \& Kidd Metrics}]{c) Lorenz \& Kidd Metrics}\par
Lorenz \& Kidd \hyperref[b18]{[19]} proposed a set of metrics that can be grouped in four categories are size, inheritance, internal and external. Size oriented metrics for object oriented class may be focused on count of the metrics, operations and attributes of an individual class and average value of object-oriented software as a whole. Inheritance based metrics is totally concentrated in which operations that are reused through the class hierarchy. Metrics for the class intervals are totally oriented towards the cohesion, while the external metrics were used to examine and reuse. It divide the class based metrics into the broad categories like size, internal, external inheritance and the main metrics which are focused on the size and complexity are class size (CS), Number of operations overridden by a subclass (NOO), Number of operations added by a subclass (NOA), Specialization index (SI), Average operation size (OS), Operation complexity (OC), Average number of parameters per operation (NP).\par
D. Metrics for Object-Oriented Software Engineering (MOOSE) : Chidamber and Kemerer (CK) et al. \hyperref[b10]{[11]} proposed some metrics that have generated a significant amount of interest and are currently the most well known object-oriented suite of measurements for Object-Oriented software. The CK metrics suite consists of six metrics that assess different characteristics of the object-oriented design are-(i)Weighted Methods per Class (WMC): This measures the sum of complexity of the methods in a class. A predictor of the time and effort required to develop and maintain a class we can use the number of methods and the complexity of each method. A large number of methods in a class may have a potentially larger impact on the children of a class since the methods in the parent will be inherited by the child. Also, the complexity of the class may be calculated by the cyclomatic complexity of the methods. The high value of WMC indicates that the class is more complex as compare to the low values.\par
(ii)Depth of Inheritance Tree (DIT): DIT metric is used to find the length of the maximum path from the root node to the end node of the tree. The following figure shows that the value of the DIT from a simple hierarchy. DIT represents the complexity and the behavior of a class, and the complexity of design of a class and potential reuse. Thus it can be hard to understand a system with many inheritance layers. On the other hand, a large DIT value indicates that many methods might be reused. A deeper class hierarchy indicates that the more methods was used or inherited through which this making more complex to predict the behavior of the class and the deeper tree indicates that there is high complexity in the design because all of the facts contained more methods and class are involved. A deep hierarchy of the class may indicates a possibility of the reusing an inherited methods.\par
(iii)Number of children (NOC) -According to Chidamber and Kemerer, the Number of Children (NOC) metric may be defined for the immediate sub class coordinated by the class in the form of class hierarchy \hyperref[b13]{[14,}\hyperref[b14]{15]}. These points are come out as NOC is used to measure that "How many subclasses are going to inherit the methods of the parent class". The greater the number of children, the greater the potential for reuse, since inheritance is a form of reuse. The greater the number of children, the greater the likelihood of improper abstraction of the parent class. The number of children also gave an idea of the potential influence for the class which may be design.\par
(iv)Coupling Between Objects (CBO) -CBO is used to count the number of the class to which the specific class is coupled. The rich coupling decrease the modularity of the class making it less attractive for reusing the class and more high coupled class is more sensitive to change in other part of the design through which the maintenance is so much difficult in the coupling of classes. The coupling Between Object Classes (CBO) metric is defined as "CBO for a class is a count of the number of non-inheritance related couples with classes". It claimed that the unit of "class" used in this metric is difficult to justify, and suggested different forms of class coupling: inheritance, abstract data type and message passing which are available in objectoriented programming.\par
(v)Response for class (RFC) -The response set of a class (RFC) is defined as set of methods that can be executed in response and messages received a message by the object of that class. Larger value also complicated the testing and debugging of the object through which, it requires the tester to have more knowledge of the functionality. The larger RFC value takes more complex is class is a worst case scenariovalue for RFC also helps the estimating the time needed for time needed for testing the class.\par
(vi)Lack of Cohesion in Methods (LCOM): This metric is used to count the number of disjoints methods pairs minus the number of similar method pairs used. The disjoint methods have no common instance variables in the methods, while the similar methods have at least one common instance variable. It is used to measuring the pairs of methods within a class using the same instance variable. Since cohesiveness within a class increases encapsulation it is desirable and due to lack of cohesion may imply that the class is split in to more than two or more sub classes. Low cohesion in methods increase the complexity, when it increases the error proneness during the development is so increasing.\par
E Each of the metrics was expressed to measure where the numerator defines the actual use of any one of the feature for a particular design \hyperref[b37]{[38]}. In MOOD metrics model, there are two main features are methods and attributes. Attributes are used to represent the status of object in the system and methods are used to maintained or modifying several kinds of status of the objects \hyperref[b4]{[5]}.\par
Metrics are defined as: (i)Method Hiding Factor (MHF): MHF is defined as the ratio of the sum of the invisibilities of all methods defined in all classes to the total number of methods defined in the system under consideration. The invisibility of a method is the percentage of the total classes from which this method is not visible.\par
(ii)Attribute Hiding Factor (AHF): AHF is defined as the ratio of the sum of the invisibilities of all attributes defined in all classes to the total number of attributes defined in the system under consideration.\par
(iii)Method Inheritance Factor (MIF): MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods (locally defined plus inherited) for all classes.\par
(iv)Attribute Inheritance Factor (AIF): AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes (locally defined plus inherited) for all classes.\par
(v)Polymorphism Factor (PF): PF is defined as the ratio of the actual number of possible different polymorphic situation for class Ci to the maximum number of possible distinct polymorphic situations for class Ci.\par
(vi)Coupling Factor (CF): CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance.\par
MIF \& AIF are used to measure the inheritance of the class \& also provide the similarity into the classes. CF is used to measure the coupling between the classes. the coupling are of two types static \& dynamic coupling, due to which is increase the complexity of the class \& reduce the encapsulation \& potential reuse that provide better maintainability. Software developers for the object-oriented system always avoid the high coupling factor. Polymorphism potential of the class are used to measure the polymorphism in the particular class \& also arise from inheritance G. Goal Question Metrics (GQM):V. L. Basili \hyperref[b17]{[18]} developed GQM approach. This approach was originally defined for evaluating defects for a set of projects in the NASA Goddard Space Flight Center environment. He has also provided the set of sequence which are helpful for the designers. The goal of GQM is to express the meaning of the templates which covers purpose, perspective and environment; a set of guidelines also proposed for driving question and metrics. It provides a framework involving three steps: i.\par
List major goals of the development or maintenance project. ii.\par
Derive from each goal the questions that must be answered to determine if the goals are being met. 
\section[{iii.}]{iii.}\par
Decide what must be measured in order to be able to answer the questions adequately.\par
Goal (Conceptual level): A goal is defined for an object, for a variety of reasons, with respect to various models of quality, from various points of view, relative to a particular environment. Objects of measurement are products, processes and resources.\par
Question (Operational level): A set of questions is used to characterize the way the assessment/achievement of a specific goal is going to be performed based on some characterizing model.\par
Metric (Quantitative level): A set of data is associated with every question in order to answer it in a quantitative way. This data can be objectives and subjective, if they depend only on the objects that can be measured and not on the viewport from which they may be taken. For example, number of versions of a document, staff hours spent on a task, size of a program. 
\section[{Global Journal of Computer Science and Technology Volume XII Issue VII Version I}]{Global Journal of Computer Science and Technology Volume XII Issue VII Version I}\par
The GQM approach define some goals, refine those goals into a set of questions, and the questions are further refined into metrics. Consider the following figure, for a particular question; G1 and G2 are two goals, Q2 in common for both of these goals. Metric M2 is required by all three questions. The main idea of GQM is that each metric identified is placed within a context, so metric M1 is collected in order to answer question Q1 to help achieve the goal G1. The QMOOD \hyperref[b24]{[25]} is a comprehensive quality model that establishes a clearly defined and empirically validated model to assess object-oriented design quality attributes such as understandability and reusability, and relates it through mathematical formulas, with structural object-oriented design properties such as encapsulation and coupling. The QMOOD model consists of six equations that establish relationship between six objectoriented design quality attributes (reusability, flexibility, understandability, functionality, extendibility, and effectiveness) and eleven design properties.  -The Number of Ancestor classes (NAC) metric proposed as an alternative to the DIT metric measures the total number of ancestor classes from which a class inherits in the class inheritance hierarchy. The theoretical basis and viewpoints both are same as the DIT metric. In this the unit for the NAC metric is "class", justified that because the attribute that the NAC metric captures is the number of other classes" environments from which the class inherits.\par
(ii)Number of Local Methods (NLM) -The Number of Local Methods metric (NLM) is defined as the number of the local methods defined in a class which are accessible outside the class. It measures the attributes of a class that WMC metric intends to capture. The theoretical basis and viewpoints are different from the WMC metric. The theoretical basis describes the attribute of a class that the NLM metric captures. This attribute is for the usage of the class in an objectoriented design because it indicates the size of a class"s local interface through which other classes can use the class. They stated three viewpoints for NLM metric as following:\par
1) The NLM metric is directly linked to a programmer"s effort when a class is reused in an Object-Oriented design. More the local methods in a class, the more effort is required to comprehend the class behavior.\par
2) The larger the local interface of a class, the more effort is needed to design, implement, test, and maintain the class.\par
3) The larger the local interface of a class, the more influence the class has on its descendent classes.\par
(iii)Class Method Complexity (CMC) -The Class Method Complexity metric is defined as the summation of the internal structural complexity of all local methods. The CMC metric"s theoretical basis and viewpoints are significantly different from WMC metric. The NLM and CMC metrics are fundamentally different as they capture two independent attributes of a class. These two metrics affect the effort required to design, implement, test and maintain a class.\par
(iv)Number of Descendent Classes (NDC) -The Number of Descendent Classes (NDC) metric as an alternative to NOC is defined as the total number of descendent classes (subclass) of a class. The stated theoretical basis and viewpoints indicate that NOC metric measures the scope of influence of the class on its sub classes because of inheritance. Li claimed that the NDC metric captures the classes attribute better than NOC.\par
(v)Coupling through Abstract Data Type (CTA) -The Coupling through Abstract Data Type (CTA) is defined as the total number of classes that are used as abstract data types in the data-attribute declaration of a class. Two classes are coupled when one class uses the other class as an abstract data type \hyperref[b15]{[16]}. The theoretical view was that the CTA metric relates to the notion of class coupling through the use of abstract data types. This metric gives the scope of how many other classes" services a class needs in order to provide its own service to others.\par
(vi)Coupling through Message Passing (CTM) -The Coupling through Message Passing (CTM) defined as the number of different messages sent out from a class to other classes excluding the messages sent to the objects created as local objects in the local methods of the class. Two classes can be coupled because one class sends a message to an object of another class, without involving the two classes through inheritance or abstract data type  {\ref [Li.,} {\ref 98]}. Theoretical view given was that the CTM metric relates to the notion of message passing in object-oriented programming. The metric gives an indication of how many methods of other classes are needed to fulfill the class" own functionality. a) SATC"s Metrics Rosenberg Linda \hyperref[b47]{[48]} proposed to select object oriented metrics that supports the goal of measuring the code, quality, result and they proposed many objectoriented metrics due to lack of theoretical basis and that can be validated. These metrics may be used to evaluate the object oriented concepts like methods, coupling and inheritance and mostly focus on both of the internal and external efficiency measures of the psychological complexity factors that affect the ability of the programmer. It proposed three traditional metrics and six new metrics for the object-oriented system metricsb) Traditional Metrics (i)Cyclomatic Complexity (CC): -Cyclomatic Complexity is used to measure the complexity of an algorithm in a method of class. Cyclomatic Complexity of methods can be combined with other methods to measure the complexity of the class. Generally, this is only used for the evaluation of quality attribute complexity.\par
(ii)Line of Code: -It is a method used to evaluate the ease of understandability of the code by the developer and the maintainer. It can easily be counted by the counting the number of lines for the code and so on. Generally, used to measure the reusability and maintainability. 
\section[{c) New Object Oriented Metrics}]{c) New Object Oriented Metrics}\par
The six new object oriented metrics are may be discussed as:\par
(i)Weight Method per Class (WMC):-It is used to count the methods implemented within a class. The number of methods and complexities involved as predictors, how many time and effort is required to develop and maintain the class.\par
(ii)Response for a Class (RFC):-It is used to the combination of the complexity of a class through the number of methods and the communication of methods with other classes. This is used to evaluate the understandability and testability.\par
(iii)Lack of Cohesion of Method (LCOM):-Cohesion is a degree of met hods through which all the methods of the class are inter -related with one another and provide a well bounded behavior. It also measures the degree of similarity of methods by data inputs variables and attributes. Generally, ii is used to evaluate the effi ciency and reusability.\par
(iv)Depth of Inheritance Tree (DIT):-Inheritance is a relationship between the class that enables the programmer to use previously defined object including the operators and variables. It also helps to find out the inheritance dept h of the tree from current node to the ancestor node. It is used to evaluate the reusability, efficiency, understandability and testability.\par
(v)Number of Children (NOC):-his is used to measure the subclass subordinate to a class in the hierarchy. Greater the number of children means greater reusability and inheritance i.e. in the form of reuse. Generally, it is used to measure efficiency, testability and reusability. SATC focused on some selected criteria for the object oriented metrics as: i.\par
Efficiency of constructor design to decrease architecture complexity.\par
ii. Specification of design and enhancement in testing structure iii.\par
Increase capacity of psychological complexity.  
\section[{V. COMPARISON TABLE}]{V. COMPARISON TABLE}\par
There is a comparison table through which, we can compare all the metrics with the multiples number of methods which are using in object-oriented design. These metrics can help for a software developer to measure the size, complexity and efforts by using these metric. They may be represented as- Source Metrics C H E N M O R R I S L \& K M O O S E E M O O S E M O O D G Q M Q M O O D L I W S A T C CCM Y - - - - - - Y - Y OXM Y - - - - - - - - - OACM Y - - - - - - - - - ACM Y - - - - - - - - - OCM Y - - - - - - - - - CM Y - - - - - - - - - CHM Y - - - - - - - - - RM Y - - - - - - - - - DIT -Y - Y - - - Y - Y LCOM -Y - Y - - - - - Y CBO -Y - Y - - - - - - CS -- Y - - - - - - - NOA -- Y - - - - Y - - NOO -- Y - - - - Y - - SI -- Y - - - - - - - OS -- Y - - - - - - - OC -- Y - - - - - - - NP -- Y - - - - - - - WMC -- - Y - - - - - Y © 2012April NOC -- - Y - - - Y - Y RFC -- - Y - - - - - Y MPC -- - - Y - - Y - - DAC -- - - Y - - Y - - NOH -- - - Y - - - - - MHF -- - - - Y - - - - AHF -- - - - Y - - - - MIF -- - - - Y - - - - AIF -- - - - Y - - - - PF -- - - - Y - - - - CF -- - - - Y - - - - NOH -- - - - - - Y - - NIC -- - - - - - Y - - NMI -- - - - - - Y - - NNC -- - - - - - Y - - CCP -- - - - - - Y - - NAC -- - - - - - - Y - NLM -- - - - - - - Y - CMC -- - - - - - - Y - NDC -- - - - - - - Y - CTA -- - - - - - - Y - CTM -- - - - - - - Y - VI. 
\section[{CONCLUSION AND FUTURE WORKS}]{CONCLUSION AND FUTURE WORKS}\par
This manuscript contributes to an increased understanding of the state of the software metrics. A mechanism is provided for comparing all the object oriented software metrics which define all the methods, attributes are used in software engineering environment. The increase is software development means the measurement was also so high. The increasing significance being placed software measurement which has to lead and increase amount of research on developing the new software measures. In this paper, we have presented all of the software metrics for object oriented development. They provided a basis for measuring all of the characteristics like size, complexity, performance and quality. In rely of some notions the quality may be increased by added some features like abstraction, polymorphism and inheritance which are inherent in object orientation. This paper provides some help for researchers and practitioners for better understanding and selection of software metrics for their purposes.\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Fig 1 :}\end{figure}
  \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.01957236842105263\textwidth}P{0.8304276315789474\textwidth}}
i.\tabcellsep Message Pass Coupling (MPC):-It means that the\\
\tabcellsep number of message that can be sent by the class\\
\tabcellsep operations.\\
ii.\tabcellsep Data Abstraction Coupling (DAC):-It is used to\\
\tabcellsep count the number of classes which an aggregated\\
\tabcellsep to current class and also defined the data\\
\tabcellsep abstraction coupling.\\
iii.\tabcellsep Number of Methods (NOM):-It is used to count\\
\tabcellsep the number of operations that are local to the\\
\tabcellsep class i.e. only those class operation which can\\
\tabcellsep give the number of methods to measure it.\\
iv.\tabcellsep Size1:-It is used to find the number of line of\\
\tabcellsep code.\\
v.\tabcellsep Size2:-It is used to count the number of local\\
\tabcellsep attributes \& the number of operation defined in\\
\tabcellsep the class.\end{longtable} \par
  {\small\itshape [Note: F. Metrics For Object-Oriented Design (MOOD): F.B. Abreu et al.\hyperref[b36]{[37]} defined MOOD (Metrics for Object-Oriented Design) metrics. MOOD refers a structural model of the object oriented paradigm like encapsulation as (MHF, AHF), inheritance (MIF, AIF), polymorphism (POF), and message passing (COF).]} 
\caption{\label{tab_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
Comparison Study and Review on Object-Oriented Metrics\\
2012\\
45\end{longtable} \par
 
\caption{\label{tab_4}}\end{figure}
 		 		\backmatter  			 
\subsection[{Appendix}]{Appendix}\par
Global Journal of Computer Science and Technology Volume XII Issue VII Version I 			 			  				\begin{bibitemlist}{1}
\bibitem[Bansiya and Davis ()]{b24}\label{b24} 	 		‘A Hierarchical Model for Object-Oriented Design Quality Assessment’.  		 			J Bansiya 		,  		 			C G Davis 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		2002. 28  (1)  p. .  	 
\bibitem[Shyam and Kemerer (1994)]{b14}\label{b14} 	 		‘A Metrics Suite for Object Oriented Design’.  		 			C Shyam 		,  		 			C F Kemerer 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		June 1994. 20  (6)  p. .  	 
\bibitem[Chidamber and Kemerer (1994)]{b40}\label{b40} 	 		‘A metrics suite for object oriented design’.  		 			S R Chidamber 		,  		 			C F Kemerer 		.  	 	 		\textit{IEEE Transactions on Software Engieneering}  		June 1994. p. .  	 
\bibitem[Chidamber and Kemerer (1994)]{b51}\label{b51} 	 		‘A metrics Suite for Object Oriented Design’.  		 			S Chidamber 		,  		 			C Kemerer 		.  	 	 		\textit{IEEE Transaction on Software Engineering}  		June 1994. p. .  	 
\bibitem[Shyam et al. ()]{b10}\label{b10} 	 		‘A Metrics Suite for Object-Oriented Design’.  		 			A Shyam 		,  		 			F Kemerer 		,  		 			Chris 		.  	 	 		\textit{M.I.T. Sloan School of Management}  		1993. p. .  	 
\bibitem[Chen and Lum (1993)]{b29}\label{b29} 	 		‘A New Metrics for Object-Oriented Design’.  		 			J Chen 		,  		 			Lum 		.  	 	 		\textit{Information of Software Technology}  		April 1993. 35  (4)  p. .  	 
\bibitem[Neelamegam and Punithavali ()]{b0}\label{b0} 	 		‘A survey on object oriented quality metrics’.  		 			C Neelamegam 		,  		 			M Punithavali 		.  	 	 		\textit{Global journal of computer science and technologies},  				2011. p. .  	 
\bibitem[Neelamegan et al. ()]{b44}\label{b44} 	 		‘A Survey-Object Oriented quality metrics’.  		 			C Neelamegan 		,  		 			. M Dr 		,  		 			Punithavalli 		.  	 	 		\textit{Global journal of Computer Sc. And Technology}  		2009. 9  (4) .  	 
\bibitem[Abreu and Fernando ()]{b30}\label{b30} 	 		 			B Abreu 		,  		 			Fernando 		.  		\textit{Proc. ECOOP'95 Workshop on Metrics},  				 (ECOOP'95 Workshop on Metrics)  		1995.  	 	 (The MOOD Metrics Set) 
\bibitem[Subramanian and Corbin ()]{b25}\label{b25} 	 		‘An Empirical Study of Certain Object-Oriented Software Metrics’.  		 			G Subramanian 		,  		 			W Corbin 		.  	 	 		\textit{Journal of Systems and Software}  		2001. 59  (1)  p. .  	 
\bibitem[Xu et al. ()]{b52}\label{b52} 	 		‘An Empirical Validation of Object-Oriented Design Metrics for Fault Prediction’.  		 			J Xu 		,  		 			H Danny 		,  		 			L Fernando Capretz 		.  	 	 		\textit{Computer Science}  		2008. 4  (7)  p. .  	 
\bibitem[Alshayeb (2003)]{b12}\label{b12} 	 		‘An empirical validation of object-oriented metrics in two different iteration software processes’.  		 			M Alshayeb 		,  		 			LiW 		.  	 	 		\textit{IEEE transactionod Software Engineering}  		Nov 2003. 29  (11) .  	 
\bibitem[Harrison et al. (1998)]{b34}\label{b34} 	 		‘An evaluation of the MOOD set of OOSM’.  		 			R Harrison 		,  		 			S J Counsell 		,  		 			R V Nithi 		.  	 	 		\textit{IEEE Transaction on Software Engineering}  		June 1998. 24  (6)  p. 67308.  	 	 (SD METRICS TOOL. in der Lache 17) 
\bibitem[Li (1998)]{b15}\label{b15} 	 		‘Another Metric Suite for Object-oriented Programming’.  		 			W Li 		.  	 	 		\textit{The Journal of System and Software}  		December 1998. 44  (2)  p. .  	 
\bibitem[Rosenberg and Hyatt (1998)]{b9}\label{b9} 	 		‘Applying and interpreting object oriented metrics’.  		 			L H Rosenberg 		,  		 			L Hyatt 		.  	 	 		\textit{Proceedings of software technology conference},  				 (software technology conferenceutah)  		April 1998.  	 
\bibitem[Briand et al. ()]{b6}\label{b6} 	 		‘Assessing the Applicability of Fault Proneness Models Across Object Oriented Software Projects’.  		 			L C Briand 		,  		 			W L Melo 		,  		 			J Wust 		.  	 	 		\textit{IEEE transactions on Software Engineering}  		2002. 28  (7) .  	 
\bibitem[Etzkorn et al. ()]{b22}\label{b22} 	 		‘Automated Reusability Quality Analysis of OO Legacy Software’.  		 			H Etzkorn 		,  		 			W E Hughes 		,  		 			C G Davis 		.  	 	 		\textit{Information and Software Technology},  				2001. 43 p. .  	 
\bibitem[Basili et al. ()]{b17}\label{b17} 	 		‘Avalidation of object-oriented Metrics as Quality Indicators’.  		 			V L Basili 		,  		 			L Briand 		,  		 			W L Melo 		.  	 	 		\textit{IEEE Transaction Software Engineering}  		1996. 22  (10)  p. .  	 
\bibitem[Abreu et al. (1993)]{b50}\label{b50} 	 		‘Candidate Metrics for Object -Oriented Software within a Taxonomy Framework’.  		 			Abreu 		,  		 			F Brito 		,  		 			Rogerio Carapuca 		.  	 	 		\textit{selected for reprint in the Journals of Systems and Software},  				 (Venice, Italy)  		October 1993. July 1994. 23 p. .  	 	 (Proceddings of AQUIS"93 (Achieving Quality In Software)) 
\bibitem[Fujiwara et al. (2003)]{b21}\label{b21} 	 		‘Case Studies To Evaluate a Domain Specific Application Framework Based on Complexity and Functionality Metrics’.  		 			H Fujiwara 		,  		 			S Kusumoto 		,  		 			K Inoue 		,  		 			A Suzuki 		,  		 			T Ootsubo 		,  		 			K Yuura 		.  	 	 		\textit{Information and Software Technology},  				Jan 2003. 45 p. .  	 
\bibitem[Harrison et al. (1996)]{b11}\label{b11} 	 		‘Comparing Programming Paradigms: An Evaluation of Functional and Object-Oriented Programs’.  		 			R Harrison 		,  		 			L G Samaraweera 		,  		 			Dobie 		,  		 			P Lewis 		.  	 	 		\textit{Software Eng. J}  		July 1996. 11 p. .  	 
\bibitem[Eder et al. ()]{b35}\label{b35} 	 		\textit{Coupling and Cohesion in ObjectOriented Systems},  		 			J Eder 		,  		 			G Kappel 		,  		 			M Schreft 		.  		1994.  		 			University of Klagenfurt 		 	 	 (Technical Report) 
\bibitem[Abreu ()]{b36}\label{b36} 	 		‘Design metrics for OO software system’.  		 			B F Abreu 		.  	 	 		\textit{ECOOP"95, Quantitative Methods Workshop},  				1995.  	 
\bibitem[Gurp and Bosch ()]{b20}\label{b20} 	 		‘Design, Implementation and Evolution of Object-Oriented Frameworks: Concepts and Guidelines’.  		 			V Gurp 		,  		 			J Bosch 		.  	 	 		\textit{Software-Practice and Experience}  		2001. 31  (3)  p. .  	 
\bibitem[Subramanyam and Krishnan ()]{b33}\label{b33} 	 		‘Emphirical Analysis of CK metrics for OOD complexity: Implication for software defect’.  		 			M Subramanyam 		,  		 			R Krishnan 		.  	 	 		\textit{IEEE transaction on software engineering},  				2003.  	 
\bibitem[Subramanyam and Krishnan ()]{b42}\label{b42} 	 		‘Empirical Analysis of CK metricsfor Object Oriented Design Complexity: Implications of Software defects’.  		 			R Subramanyam 		,  		 			M S Krishnan 		.  	 	 		\textit{IEEE transactions on Software Engineering}  		2003. 29  (4) .  	 
\bibitem[Zhou and Leung ()]{b53}\label{b53} 	 		‘Empirical Analysis of Object-Oriented Design Metrics for Predicting High and Low Severity Faults’.  		 			Y Zhou 		,  		 			H Leung 		.  	 	 		\textit{IEEE transaction on software engineering},  				2006. 32 p. .  	 
\bibitem[Jones ()]{b16}\label{b16} 	 		\textit{Estimating Software Costs: Bringing Realism to Estimating},  		 			C Jones 		.  		2007. New York: Mc Graw Hill.  	 	 (2nd Edition) 
\bibitem[Brito et al. (1996)]{b39}\label{b39} 	 		\textit{Evaluating the Impact of Object-Oriented Design on Software Quality},  		 			F Brito 		,  		 			E Abreu 		,  		 			W Melo 		.  		1996. March 1996. Berlin, Germany.  	 	 (3rd Int"l S/W Metrics Symposium) 
\bibitem[Kaur et al. (2009)]{b38}\label{b38} 	 		‘Evaluation and Metrication of Object Oriented System’.  		 			A Kaur 		,  		 			S Singh 		,  		 			K S Kahlon 		,  		 			; I Imecs 		.  	 	 		\textit{Proceedings of the International Multi Conference of Engineers and Computer Scientists},  				 (the International Multi Conference of Engineers and Computer ScientistsHong Kong)  		2009. 2009. March 18 -20, 2009.  	 
\bibitem[Briand et al. ()]{b5}\label{b5} 	 		‘Exploring the Relationships Between Design Measures and Software Quality In Object Oriented Systems’.  		 			L C Briand 		,  		 			J Wuest 		,  		 			J Daly 		,  		 			V Porter 		.  	 	 		\textit{Journal of Systems and Software}  		2000. 51.  	 
\bibitem[Baroni ()]{b49}\label{b49} 	 		\textit{Foramal Definition of Object Oriented Design Metrics},  		 			A L Baroni 		.  		2002.  		 			Vrije Universities Brussels-belgium 		 	 	 (MS Thesis) 
\bibitem[Dr et al. ()]{b41}\label{b41} 	 		‘Impact of software metrics on Object Oriented Software Development life cycle’.  		 			B R Dr 		,  		 			M V Sastry 		,  		 			Vijaya 		,  		 			Saradhi 		.  	 	 		\textit{International Journal of Engineering Science and Technology}  		2010. 2  (2)  p. .  	 
\bibitem[
			Alexander
		 (2003)]{b31}\label{b31} 	 		‘Mathematical Assessment of Object-Oriented Design Quality’.  		 			Alexander 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		2003. November 2003. 29  (11) .  	 
\bibitem[Manduchi and Taliercio ()]{b23}\label{b23} 	 		\textit{Measuring Software Evolution at a Nuclear Fusion Experiment Site: A Test Case for Applicability of OO and Reuse Metrics in Software Characterization},  		 			G Manduchi 		,  		 			C Taliercio 		.  		2002. 44 p. .  	 
\bibitem[Dr and Breesam ()]{b43}\label{b43} 	 		\textit{Metrics for Object Oriented design focusing on class Inheritance metrics},  		 			K M Dr 		,  		 			Breesam 		.  		2007.  	 	 (2nd International conference on dependability of computer system IEEE) 
\bibitem[Morris ()]{b26}\label{b26} 	 		\textit{Metrics for Object-oriented Software Development Environments},  		 			K Morris 		.  		1989. MIT.  	 	 (Masters Thesis) 
\bibitem[Li and Sallie ()]{b8}\label{b8} 	 		‘Metrics for Object-Oriented system’.  		 			W Li 		,  		 			Henry Sallie 		.  	 	 		\textit{Transactions on Software Engineering},  				1995.  	 
\bibitem[Coad and Yourdon ()]{b7}\label{b7} 	 		\textit{Object Oriented Analysis},  		 			P Coad 		,  		 			E Yourdon 		.  		1990. Yourdon Press.  	 
\bibitem[Henderson ()]{b2}\label{b2} 	 		\textit{object oriented metrices: measure of complexity},  		 			A Henderson 		.  		1996. Prentice Hall.  	 
\bibitem[Lorenz and Kidd ()]{b18}\label{b18} 	 		\textit{Object Oriented Software Metrics},  		 			M Lorenz 		,  		 			J Kidd 		.  		1994. Prentice Hall, NJ.  	 
\bibitem[Object-Oriented Analysis and Design with Applications ()]{b27}\label{b27} 	 		\textit{Object-Oriented Analysis and Design with Applications},  				 (Benjamin Cummings)  		1994.  	 	 (2nd ed.) 
\bibitem[Pressman]{b28}\label{b28} 	 		 			R S Pressman 		.  		\textit{Software Engineering},  				 	 	 (Fifth edition) 
\bibitem[Lilu et al. (2002)]{b32}\label{b32} 	 		‘Quality metrics of OOD for Software development and Re-development’.  		 			H Lilu 		,  		 			K Zhou 		,  		 			S Yang 		.  	 	 		\textit{First Asia-Pacific Conference on Quality Software},  				August 2002.  	 
\bibitem[Shaik et al. ()]{b3}\label{b3} 	 		 			A Shaik 		,  		 			C P K Reddy 		,  		 			B Manda 		,  		 			K Prakashine 		,  		 			Deepti 		.  		\textit{Journal of emerging trend in engineer and applied science (JETEAS)},  				2010. p. .  	 	 (Metrics for object oriented design software system:A Survey) 
\bibitem[Goldberg and Robson ()]{b45}\label{b45} 	 		\textit{Smalltalk-80: the language and its implementation},  		 			A Goldberg 		,  		 			D Robson 		.  		1983. Reading, MA: Addison Wesley.  	 
\bibitem[Fenton ()]{b4}\label{b4} 	 		\textit{Software metrices: a rigorous and practical approach},  		 			N Fenton 		.  		1996. International Thomson computer press.  	 
\bibitem[Deepak et al. (2011)]{b1}\label{b1} 	 		‘Software quality estimation through object oriented design metrics’.  		 			A Deepak 		,  		 			K Pooja 		,  		 			T Alpika 		,  		 			S Sharma 		.  	 	 		\textit{IJCSNS International journal of computer science and network security}  		april 2011. p. .  	 
\bibitem[Linda]{b47}\label{b47} 	 		‘Software Quality Metrics for Object Oriented System Environments’.  		 			Rosenberg Linda 		.  	 	 		\textit{A report of SATC"s research on OO metrics},  				 	 
\bibitem[Eliss and Stroustrup ()]{b46}\label{b46} 	 		\textit{The annotated C++ Reference manual},  		 			M A Eliss 		,  		 			\& B Stroustrup 		.  		1990. Reading MA: Addison-Wesley.  	 
\bibitem[Abreu et al. (1996)]{b37}\label{b37} 	 		‘The Design of Eiffel Program: Quantitative Evaluation Using the MOOD metrics’.  		 			B Abreu 		,  		 			Fernando 		,  		 			Miguel Rita 		,  		 			G 		.  	 	 		\textit{Proceeding of TOOLS"96},  				 (eeding of TOOLS"96USA, Santa Barbara, California)  		July 1996.  	 
\bibitem[Neal ()]{b19}\label{b19} 	 		\textit{The Measurement Theory Validation of Proposed Object-Oriented Software Metrics},  		 			R D Neal 		.  		1996. Dissertation, Virginia Commonwealth University.  	 
\bibitem[Shyam and Kemerer (1991)]{b13}\label{b13} 	 		‘Towards a Metrics Suite for Object Oriented Design’.  		 			A Shyam 		,  		 			C F Kemerer 		.  	 	 		\textit{Proceeding on Object Oriented Programming Systems, Languages and Applications Conference (OOPSLA"91), ACM},  				 (eeding on Object Oriented Programming Systems, Languages and Applications Conference (OOPSLA"91), ACM)  		Nov 1991. 26 p. .  	 
\bibitem[Brito et al. (1993)]{b48}\label{b48} 	 		‘Towards the Design Quality Evaluation of Object Oriented Software System’.  		 			A Brito 		,  		 			E Abreu 		,  		 			( Inesc/Iseg) 		,  		 			Miguel Goulao 		.  	 	 		\textit{Revised version: originally published in Proceedings of 5 th International Conference of Software Quality},  				 (Austin, Texas)  		23 to 26 October, 1993.  	 	 (Rita Esteves (INESC/IST)) 
\end{bibitemlist}
 			 		 	 
\end{document}
