\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={Evaluation the Quality of Software Design by Call Graph based 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{2014-01-15 (revised: 15 January 2014)}
\def\TheID{\makeatother }
\def\TheDate{2014-01-15}
\title{Evaluation the Quality of Software Design by Call Graph based 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]{Sanjeev Kumar  Punia}

             \author[2]{Dr. Anuj  Kumar}

             \author[3]{Amit  Sharma}

             \affil[1]{  NIMS University, Jaipur}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2013 Accepted: 2 January 2014 Published: 15 January 2014}

\maketitle


\begin{abstract}
        


The prediction of software defects was introduced to support development and maintenance activities to improve the software quality by finding errors early in the software development. It facilitates maintenance in terms of effort, time and more importantly the cost prediction for software evolution and maintenance activities.In this paper, we evaluate the quality related attributes in developed software products. The software call graph model is also used for several applications in order to represent and reflect the degree of their complexity in terms of understandability, testability and maintainability efforts. The extracted metrics are investigated for the evaluated applications in correlation with bugs collected from customers bug reports. Those software related bugs are compiled into datasets files to use as an input to a data miner for classification, prediction and association analysis.Finally, the analysis results is evaluated in terms of finding the correlation between software products bugs and call graph based metrics. We find that call graph based metrics are appropriate to detect and predict software defects so that the activities of testing and maintenance stages become easier to estimate or assess after the product delivery.

\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
he human abilities and creativities play a significant role in producing and directing the software products in software development life cycle with the help of the tools and methodologies. However, humans are also the main source of the errors and defects that occur in the software and discovered before or after the delivery of the product. The production of defect free software and projects is impossible. However, software developers struggle to keep such possible defects at minimum. Finding and fixing the defects and errors after delivery usually cost a large amount of the project budget and resources specially if compared with detecting them earlier. As try to predict the defects early is valuable specially if detected before the delivery of the software where that can also help the project to success in terms of cost and quality.\par
The coupling metrics play an important role in many software development and maintenance activities such as effort estimation, improving the quality of the software products, test planning and reducing future maintenance. These metrics assess the software quality by supporting the quality related factors after evaluating error proneness, changeability and reusability. The most relevant tools are available as independent or the part of a development environment to compute the coupling metrics statically by tracing possible problems in the source code.\par
The call graphs metrics represent the relationship between the modules and reflect the degree of complexity of the software. It also helps to find some software metrics such as coupling and cohesion metrics. In general, one way to reduce cost through defects prediction is by using software metrics. Particularly the call graph based metrics is used to predict and improve possible problems in software design and in coding finally.\par
In this research, we tried to evaluate the effectiveness and power of call graph based metrics in prediction and detection the defects in software products. A tool is developed to generate call graph attributes and metrics by using open source projects. We select three applications as J Edit 4.2, Velocity 1.4 and Velocity 1.6 based on two factors (i) open source projects and (ii) these projects include users bug reports for actual evaluation of the software products. This paper include, the programmed and evaluated call graph based metrics as LOC, Fan In, Fan Out, SGBR and IFC. The LOC, Fan In and Fan Out metrics are known and popular while SGBR and IFC not so popular but after that also we implement in our tool.\par
This paper is organized into six sections as follows: Section 2 introduces topic and research related studies. Section 3 describes the methodology steps. Section 4 presents the adopted analysis and evaluation measurements. Section 5 shows the conducted results of the experiments and finally Section 6 presents the conclusion and inference from the paper.  Abstract-The prediction of software defects was introduced to support development and maintenance activities to improve the software quality by finding errors early in the software development. It facilitates maintenance in terms of effort, time and more importantly the cost prediction for software evolution and maintenance activities. 
\section[{II.}]{II.} 
\section[{Literature Review}]{Literature Review}\par
In this paper, we evaluate the quality related attributes in developed software products. The software call graph model is also used for several applications in order to represent and reflect the degree of their complexity in terms of understandability, testability and maintainability efforts. The extracted metrics are investigated for the evaluated applications in correlation with bugs collected from customers bug reports. Those software related bugs are compiled into datasets files to use as an input to a data miner for classification, prediction and association analysis.\par
Finally, the analysis results is evaluated in terms of finding the correlation between software products bugs and call graph based metrics. We find that call graph based metrics are appropriate to detect and predict software defects so that the activities of testing and maintenance stages become easier to estimate or assess after the product delivery.\par
call graph based dependency metrics to improve the software quality by providing information for defect prediction and estimation. We list some related work in each step that has taken in our project and developed tool in the following sections. 
\section[{a) Call Graph Model}]{a) Call Graph Model}\par
Many researchers studied software modeling and found that modeling techniques are grouped into broadly two categories as (i) graphical modeling techniques and (ii) textual modeling techniques. Graphical modeling technique use a diagram with named symbols that represent the components, the symbols connecting arcs represent the relationship and other notations to represent the constrains. Textual modeling technique use standardized notations and keywords to define major aspects of software product call graph. J. Dollner and Bohnet et.al. \hyperref[b0]{[1]} Considered the extracting of process call dependencies as one of the most important step in the reengineering process. Therefore they built a tool based on OINK framework for call graph extraction. In addition, the tool also provides a set of hierarchal data, call type information methods definitions and output this information to impor Table formatted file. D. Reniers et.al. \hyperref[b1]{[2]} Made an enhancement in hierarchical edge bundling (HEB) technique and named candidate visualization (CV) technique in their framework. So they build an experiment to compare their enhancement hierarchical edge bundling and tulip graph visualization framework with several large systems like Bison, Mozilla Firefox, OINK and conclude that hierarchical edge bundling scheme perform better in typical comprehension tasks. M. Jahromi and E. Honar et.al. \hyperref[b2]{[3]} introduced a new framework for call graph construction for program analysis. They choose ASM and soot a byte code reader for their environment to store information about the structure of the codes such as classes, methods, files and statements.\par
They also proposed a framework where three algorithms have been implemented for call graph construction i.e. CHA, RTA and CTA and finally they conclude by an experimental study on a verity of source code programs by comparing two byte code reader. 
\section[{b) Code Metrics Extraction}]{b) Code Metrics Extraction}\par
By analyzing both the source code of any software and extracting code metrics is considered as the main preprocess for the reengineering operation. This information provides a clear view about the complexities and difficulties of the software as well as divides the milestones tasks into phases in order to start the reengineering process easily. On the other hand many researchers considered the code metrics and the system complexity information as a good defect tracker.\par
They setup a number of hypothesis related to defect probability and code metrics to prove the correlation between them but the hottest topics in this research is to define the set of metrics that we can considered them as the optimal defect predictor. The researchers shows many studies to define this set of metrics and try to view it's set as the perfect one that give justifications for their results. It is also find that code metrics, which plays a major role in many research fields and many tools deployed to handle extraction using different approaches.\par
F. Abreu and Baroni et.al. [4] Presented a new framework for metrics extraction by modeling the extraction data using UML Meta model called FLAME. They briefly mentioned the main characteristics of FLAME for fact extraction and recommended to use in firing a new tool for metrics extraction. The authors introduce an approach to formalize the metrics design in the optimal way where FLAME functions are used to extract well known sets of metrics as MOOD, MOOD2, MOOSE, EMOOSE and QMOOD metrics. 
\section[{c) Defect Prediction from Source Code Metrics and System History}]{c) Defect Prediction from Source Code Metrics and System History}\par
A number of approaches have been deployed for defect prediction based on different criteria and information. Some researchers turn to find bugs in software code by analyzing software source code and compute its complexity. They extracted call graph based metrics from source code and used to decide which part or module of the software code likely to be defected. While other researchers prefer to use the system history to decide which part of them has a big defect probability especially when the application has many releases. They find that the system history is more accurate to predict defected parts of the system more than the code complexity extraction predict. While some studies support the two approaches together and use both in finding systems bugs.\par
A. Bernstein et.al. \hyperref[b4]{[5]} compare the influence of different metrics used in defect prediction and defect prediction densities by using decision tree learners. They collected the needed data that is source code metrics and bugs report in the experiment from seven versions of open source code for Mozilla application. They applied J48 algorithm in WEKA data miner on the data set and setup a number of experiments to test their purposed hypothesis on defect predicting in software parts. They conclude that a simple tree learner can produce good results with various sets of input data.\par
N. Nagappan and T. Ball et.al. [6] introduce a new technique for prediction defect density by using code churn measures. The idea was drawn with a hypothesis that if code changes many times in the prerelease version then it also has a big chance to be defected in the post release. The authors build an experiment on W2K3 release with its service back and showed with its result that code churn is a good defect predictor. As they noticed that the increase of the code churn measures leads to an increase on the defect density in any software so they conclude that their metrics suit with line of code churned, deleted line of code, files churned, churn count and weeks of churn.\par
The aim of software developers is to evaluate the cost and quality of software before deliver to customers so that they can predict and find bugs or defects especially for critical systems. 
\section[{III.}]{III.} 
\section[{Methodology}]{Methodology}\par
Our methodology consists of six main phases as shown in Figure 1. This begin by phase 1 begin by "implementation of metric computing tool" to built a tool that can read source code of an application to compute some metrics coupling measurements. Phase 2 is "generation of call graph model" that utilizes the application model. Phase 3 is "calculation of call graph based metrics" used to compute some call graph based metrics for our application model. Phase 4 is "generation of data set" used to prepare data set consisted from metrics values for each class in application. Phase 5 is "refinement of data set with bug report" that assigns each data set record with its number of bugs. Finally, phase 6 is "Analysis and Evaluation of Data Set using WEKA" used for the purpose of evaluating its quality and find the correlation between its bug and call graph based metrics.\par
As the tool focus on extract the call graph based metrics so the developed tool generated data set does not contain bug attribute for each class. This phase is responsible to make some refinement on the comma separated values comma separate value (CSV) file.\par
Firstly, the tool automatically fill the bug attribute filed for each class by providing its previous comma separate value file for the same application under investigation and contains the bug report for each class. Then by mapping the name of classes between our comma separate value file and the previous worked comma separate value file. The source of previous comma separate value file gained from promise data repository which contains several data sets in comma separated values or attribute relation file (ARF) format. These files are created and prepared by researchers those worked at the topic of software defects prediction. In our research, we use bug attribute for the files which relate to the applications in our experiments.\par
IV. 
\section[{Analysis and Evaluation}]{Analysis and Evaluation}\par
Before you begin to format your paper, first write and save the content as a separate text file. Keep your text and graphic files separate until after the text has been formatted and styled. Do not use hard tabs and limit use of hard returns to only one return at the end of a paragraph. Do not add any kind of pagination anywhere in the paper.\par
After refine the generated comma separate value file that represent the data set of our research with bug attribute then it is ready to analyze and evaluate using WEKA 3.7.5 tool as data miner. Here we apply J48, logistic model trees (LMT) and support vector machine (SMO) classifier algorithms. The decision tree algorithms are chosen as we want to look at classifiers that were easy to understand and validate the correlation between call graph based metrics and bugs. 
\section[{a) Evaluation Measures}]{a) Evaluation Measures}\par
The evaluation process of our testing tool depends on five matrices in term of call graph based metrics measurement. The five matrices are line of code (LOC), Fan In, Fan Out, call graph based ranking (CGBR) and information flow complexity (IFC) as shown in Table \hyperref[tab_1]{1}. The metrics value for each type (LOC, Fan in, Fan Out, CGBR and IRC) depends on the functions that extracted from the application under investigation by which the higher metric value type achieves a higher complexity value. The values of metrics related to class level are computed by find the summation of all corresponded metrics to function level. For example: if we have 10 included functions at such class and each function has Fan In metrics value equal 1 then the class has Fan In metrics value equal the summation of all Fan  In metrics values related to functions of the class which equal to 10. The five metrics we use in this research are related to size of the software or coupling and dependency between the components and functions of the application under investigation. LOC metric value represents the number of execu Table and noncommented lines of code. FanIn metric value for such function represents the number of function calling for a given function. Fan Out metric value for such function represents the number of function being called by a given function. CGBR metric depends on the page ranking algorithm that used by almost all the search engines where the ranking methodology is adopted to functions of the software.\par
This metric hypothesis that more frequently used functions and less frequently used modules should have different defects and bugs characteristic. In the equation used to compute CGBR value, value of d represents damping factor and refer to probability of such function being called or used and can be computed as the ratio of actual function calls to all possible function calls. CGBR (Ti) is the call graph based rank of module Ti which Call for given function. C(Ti) is the number of outbound calls of function Ti. IFC metric represents the measurement of the total level of information flow for a given function. The value of this type of metric depends on the values of metrics LOC, Fan In and Fan Out for the given function. 
\section[{b) Principle Component Analysis using SPSS}]{b) Principle Component Analysis using SPSS}\par
The purpose of this analysis is to show the correlate metrics in developed tool. The PCA analysis for call graph based metrics in developed tool results in 2 orthogonal dimension components were identified from 5 call graph based metrics that have Eigen value more than 1 as shown in Table \hyperref[tab_3]{2}. The variance of Eigen values data set explained by the PC in percent and the cumulative variance are provided for each PC where values above 0.6 are set in boldface. The 2 PCs capture 89.963\% of the variance in the data set. The PCs are interpreted as follows:\par
? PC1: CBGR, LOC, FanIn and FanOut are coupling and size metrics. We have size and coupling metrics in this dimension. This shows that there are classes with high internal methods i.e. methods defined in the class and external methods i.e. methods called by the class. This means coupling is related to number of methods and attributes in the class.\par
? PC2: IFC measure the total level of information flow of a module and reflect the degree of flow complexity among classes. 
\section[{c) Experiments}]{c) Experiments}\par
At the first step, we collect the source code of the applications for the study i.e. JEdit 4.2, Velocity 1.4 and Velocity 1.6 application. We enter the source code for each application to a developed C\# tool in order to generate call graph model for each application. The developed tool computes the call graph based metrics for each extracted function. Then compute the same metrics to classes and output the results into comma separate value file that represent the data set to be tested. The next step is refining the data set with bug report related to each application under investigation.\par
Finally, evaluate the value of the metrics in terms of bug and defect detection the format of the data set should be ARRF file as the classifier algorithms such as J48 and M5P algorithm accepts only the files with that format. The accuracy is calculated with tenfold cross validation. The attributes of the file listed in the Figure  {\ref 2}. @attribute "Number" "numeric" @attribute "LOC" "numeric" @attribute "Fan In" "numeric" @attribute "Fan Out" "numeric" @attribute "CGBR" "numeric" @attribute "IFC" "numeric" Figure  {\ref 2} : Data set attributes The attribute bug is classified into three categories based on the number of bugs for each class as shown in Table \hyperref[tab_4]{3}. The experiments result shows that there is an obvious correlation between the call graphs based metrics, bugs and defects of the application. The result of all the nine experiments is summarizing by Table \hyperref[tab_5]{4}.  The correlation between bug and the call graph based metrics will be high when we split the bug class into small number of categories, like category three that split the bug class into two categories. So we take category three as criteria to compare the J48 classifier on the applications under investigation output to other classifier output such as logistic model trees (LMT) and support vector machine (SMO) classifier algorithm. 
\section[{Global}]{Global}\par
The results of three classifier algorithms have approximately similar values and we conclude that correlation is very high between the call graph metrics and bugs of the application under investigation as shown in Table \hyperref[tab_6]{5}. Finally, we make some normalization to our data set by excluding the non public functions such as private and protected functions from the computation of the call graph metrics for the applications under investigation and the results of analysis is shown in Table \hyperref[tab_7]{6}. The results of three classifier algorithm are approximately have similar values where that leads us to conclude that correlation is very high between the call graph metrics that computed without non public functions and bugs of the application under investigation as shown in Table \hyperref[tab_7]{6}.\par
After comparing the results of Table \hyperref[tab_6]{5} and Table \hyperref[tab_7]{6}, we show that excluding the non-public functions such as private and protected functions in order to compute the call graph based metrics for the classes of the application under investigation will raise the percentage of the supposed correlation between call graphs based metrics and bugs.\par
V. 
\section[{Conclusion}]{Conclusion}\par
In this paper, we present the effectiveness and the power of call graph based metrics in prediction and detection the defects in software through our developed tool. We choose three applications J Edit 4.2, Velocity 1.4 and Velocity 1.6. We extract the call graph based metrics such LOC, Fan In, Fan Out, SGBR and IFC from the selected applications and evaluate their correlation according to many categories of bugs for the applications. By all these experiments we discover that how much the extracted call graph metrics are necessary and important in lightening the expensive and time consumer obstacles and problems of software that may arise after delivery phase. Therefore, it will be more effective to predict them and find their solutions earlier before they occur at any time.\par
The results of our research improve the hypothesis of correlation between call graph based metrics and bugs in software design. The highest percentage of correlation was shown in results of the analysis J Edit 4.2 application using J48 algorithm classifier with metric correlation 86\%, while the metric correlation resulted in analysis velocity application with its versions 1.4 and 1.6 was 85\% and 72\% respectively. In addition, the results show that correlation between bugs and the call graph based metrics will be high when we split the bug class into small number. In addition, the results show that excluding non-public functions such as private and protected functions in order to compute the call graph based metrics for the classes of the application under investigation will raise the percentage of the supposed correlation.\par
By this approach, we proved that call based metrics are appropriate criteria for helping the maintenance and developing stages to be more effective and less costly at the same time for the systems those are very complex and hardly to understand. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}T}\end{figure}
   \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.11747967479674797\textwidth}P{0.732520325203252\textwidth}}
Metric Type\tabcellsep Measurement of Metrics\\
LOC\tabcellsep No of execu Table and non-commented lines of code for each function\\
Fan In\tabcellsep No of calling function list\\
Fan Out\tabcellsep No of called function list\\
CGBR\tabcellsep (1-d) + d *?i CGBR(T i ) C(T i )\\
IFC\tabcellsep IFC(M)=LOC(M)+ [Fan In(M)*Fan Out(M)]2\end{longtable} \par
 
\caption{\label{tab_1}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.316025641025641\textwidth}P{0.2887820512820513\textwidth}P{0.24519230769230765\textwidth}}
\tabcellsep \multicolumn{2}{l}{Component}\\
\tabcellsep 1\tabcellsep 2\\
Eigenvalue\tabcellsep 3.475\tabcellsep 1.063\\
\% of Variance\tabcellsep 69.768\tabcellsep 18.672\\
Cumulative \%\tabcellsep 68.362\tabcellsep 89.235\\
CGBR\tabcellsep 0.923\tabcellsep -0.112\\
LOC\tabcellsep 0.905\tabcellsep -0.131\\
IFC\tabcellsep -0.036\tabcellsep 0.923\\
FanIn\tabcellsep 0.836\tabcellsep 0.132\\
FanOut\tabcellsep 0.963\tabcellsep 0.021\end{longtable} \par
 
\caption{\label{tab_3}Table 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3} \par 
\begin{longtable}{P{0.1112565445026178\textwidth}P{0.7387434554973822\textwidth}}
Bug Categories\tabcellsep Metric Matrix\\
One\tabcellsep VL = 0 error / L = 1 error / M = 2 error / H = 3 errors / VH => 3 errors\\
Two\tabcellsep L = 0 error / M = 1-2 errors / H => 2 errors\\
Three\tabcellsep False = no error / True = error exist\end{longtable} \par
 
\caption{\label{tab_4}Table 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4} \par 
\begin{longtable}{P{0.28651685393258425\textwidth}P{0.3342696629213483\textwidth}P{0.1146067415730337\textwidth}P{0.1146067415730337\textwidth}}
\tabcellsep \multicolumn{2}{l}{bug categories}\tabcellsep \\
Bug\tabcellsep \tabcellsep \tabcellsep \\
Category Application\tabcellsep \multicolumn{3}{l}{Category 1 Category 2 Category 3}\\
Name\tabcellsep \tabcellsep \tabcellsep \\
JEdit 4.2\tabcellsep 81.34 \%\tabcellsep 80.84 \%\tabcellsep 86.93 \%\\
Velocity 1.4\tabcellsep 60.67 \%\tabcellsep 72.07 \%\tabcellsep 80.04 \%\\
Velocity 1.6\tabcellsep 66.59 \%\tabcellsep 67.36 \%\tabcellsep 73.83 \%\end{longtable} \par
 
\caption{\label{tab_5}Table 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5} \par 
\begin{longtable}{P{0.33706896551724136\textwidth}P{0.21982758620689655\textwidth}P{0.14655172413793105\textwidth}P{0.14655172413793105\textwidth}}
\tabcellsep \multicolumn{2}{l}{algorithm types}\tabcellsep \\
Classifier\tabcellsep \tabcellsep \tabcellsep \\
Algorithm Application\tabcellsep J84\tabcellsep LMT\tabcellsep SMO\\
Name\tabcellsep \tabcellsep \tabcellsep \\
J Edit 4.2\tabcellsep 86.142 \%\tabcellsep 84.926 \%\tabcellsep 82.547 \%\\
Velocity 1.4\tabcellsep 80.928 \%\tabcellsep 80.364 \%\tabcellsep 75.723 \%\\
Velocity 1.6\tabcellsep 72.152 \%\tabcellsep 71.029 \%\tabcellsep 66.487 \%\end{longtable} \par
 
\caption{\label{tab_6}Table 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6} \par 
\begin{longtable}{P{0.4430851063829787\textwidth}P{0.13563829787234044\textwidth}P{0.13563829787234044\textwidth}P{0.13563829787234044\textwidth}}
\multicolumn{3}{l}{excluding non-public functions}\tabcellsep \\
Classifier\tabcellsep \tabcellsep \tabcellsep \\
Algorithm Application\tabcellsep J84\tabcellsep LMT\tabcellsep SMO\\
Name\tabcellsep \tabcellsep \tabcellsep \\
JEdit 4.2\tabcellsep 86.924 \%\tabcellsep 85.196 \%\tabcellsep 83.537 \%\\
Velocity 1.4\tabcellsep 85.918 \%\tabcellsep 88.364 \%\tabcellsep 75.783 \%\\
Velocity 1.6\tabcellsep 72.125 \%\tabcellsep 70.709 \%\tabcellsep 67.467 \%\end{longtable} \par
 
\caption{\label{tab_7}Table 6 :}\end{figure}
 			\footnote{© 2014 Global Journals Inc. (US) Evaluation the Quality of Software Design by Call Graph based Metrics} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Abreu and Baroni ()]{b3}\label{b3} 	 		‘A formal library for aiding metrics extraction’.  		 			F B Abreu 		,  		 			A L Baroni 		.  	 	 		\textit{8th International Workshop on Object Oriented Reengineering}  		2013.  	 
\bibitem[Jahromi and Honar ()]{b2}\label{b2} 	 		‘A framework for call graph construction’.  		 			M Jahromi 		,  		 			E Honar 		.  	 	 		\textit{Student thesis At School of Computer Science}  		2012.  	 	 (Physics and Mathematics) 
\bibitem[Darbyshire and Prins ()]{b8}\label{b8} 	 		‘Call graph based program analysis with .Net’.  		 			P Darbyshire 		,  		 			W Prins 		.  	 	 		\textit{Procs of the IRMA International Conference},  				 (s of the IRMA International Conference)  		2012. p. .  	 
\bibitem[Usmani and Azeem ()]{b6}\label{b6} 	 		‘Defect prediction leads to high quality product’.  		 			S Usmani 		,  		 			N Azeem 		.  	 	 		\textit{Journal of Software Engineering and Applications}  		2011. 4 p. .  	 
\bibitem[Reniers et al. ()]{b1}\label{b1} 	 		‘Extraction and visualization of call dependencies for large C/C++ code bases: A comparative study’.  		 			D Reniers 		,  		 			A Telea 		,  		 			O Ersoy 		,  		 			H Hoogendorp 		.  	 	 		\textit{7th IEEE International Workshop on Visualizing Software for Understanding and Analysis},  				2011. 2011. p. .  	 
\bibitem[Bernstein et al. ()]{b4}\label{b4} 	 		‘Predicting defect densities in source code files with decision tree learners’.  		 			A Bernstein 		,  		 			M Pinzger 		,  		 			P Knab 		.  	 	 		\textit{Proceedings of the 2011 international workshop on Mining software repositories},  				 (the 2011 international workshop on Mining software repositoriesShanghai, China)  		2011. p. .  	 
\bibitem[Khare et al. ()]{b7}\label{b7} 	 		‘Static analysis and run-time coupling metrics’.  		 			A Khare 		,  		 			P Batra 		,  		 			M Kaur 		.  	 	 		\textit{International Journal of Information Technology and Knowledge Management}  		2013. 6 p. .  	 
\bibitem[Ball and Nagappan ()]{b5}\label{b5} 	 		‘Use of relative code churn measures to predict system defect density’.  		 			T Ball 		,  		 			N Nagappan 		.  	 	 		\textit{Proceedings of the 37th international conference on Software engineering},  				 (the 37th international conference on Software engineeringSt. Louis, MO, USA)  		2012. p. .  	 
\bibitem[Dollner and Bohnet ()]{b0}\label{b0} 	 		‘Visual exploration of function call graphs for feature location in complex software systems’.  		 			J Dollner 		,  		 			J Bohnet 		.  	 	 		\textit{Proceedings of 2010 ACM symposium on Software visualization},  				 (2010 ACM symposium on Software visualization)  		2010. 1 p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
