\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={Quantitative Analysis of Fault and Failure Using Software 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-01-15 (revised: 15 January 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-01-15}
\title{Quantitative Analysis of Fault and Failure Using Software 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]{Shital  V.  Tate}

             \affil[1]{  Bharati Vidyapeeth Deemed University}

\renewcommand\Authands{ and }

\date{\small \em Received: 11 December 2011 Accepted: 31 December 2011 Published: 15 January 2012}

\maketitle


\begin{abstract}
        


It is very complex to write programs that behave accurately in the program verification tools. Automatic mining techniques suffer from 90â??"99% false positive rates, because manual specification writing is not easy. Because they can help with program testing, optimization, refactoring, documentation, and most importantly, debugging and repair. To concentrate on this problem, we propose to augment a temporal-property miner by incorporating code quality metrics. We measure code quality by extracting additional information from the software engineering process, and using information from code that is more probable to be correct as well as code that is less probable to be correct. When used as a preprocessing step for an existing specification miner, our technique identifies which input is most suggestive of correct program behaviour, which allows off-the-shelf techniques to learn the same number of specifications using only 45% of their original input.

\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
oftware remains buggy and testing is still the leading approach for detecting software errors. Incorrect and buggy behaviour in deployed software costs up to \$70 billion each year in the US \hyperref[b0]{[1]}. Thus debugging, testing, maintaining, optimizing, refactoring, and documenting software, while timeconsuming, remain significantly important. Such maintenance is reported to consume up to 90\% of the total cost of software projects \hyperref[b1]{[2]}. Maximum maintenance time is spent studying existing software since maintenance concern is incomplete documentation.\par
Consistently, however, verification tools require specifications that describe some aspect of program accuracy. Creating accurate specifications is difficult, time-consuming and error-prone. Verification tools can only point out disagreements between the program and the specification. Even assuming a sound and complete tool, an defective specification can still yield false positives by pointing out non-bugs as bugs or false negatives by failing to point out real bugs. Crafting specifications typically requires program-specific knowledge.\par
Specification mining can be compared to learning the rules of English grammar by reading essays written by high school students; we propose to focus on the essays of passing students and be doubtful of the essays of failing students. We claim that existing miners have high false positive rates in large part because they treat all code equally, even though not all code is created equal. For example, consider an execution trace through a recently modified, rarely-executed piece of code that was copied-and-pasted by an inexperienced developer. We argue that such a trace is a poor guide to correct behaviour when compared with a well-tested, infrequently-changed, and commonly-executed trace.\par
Various pre-existing software projects are not yet formally specified \hyperref[b2]{[3]}. Formal program specifications are difficult for humans to construct \hyperref[b3]{[4]}, and incorrect specifications are difficult for humans to debug and modify \hyperref[b4]{[5]}. Accordingly, researchers have developed techniques to automatically infer specifications from program source code or execution traces \hyperref[b5]{[6]}, \hyperref[b6]{[7]}, \hyperref[b7]{[8]}, \hyperref[b8]{[9]}. These techniques typically produce specifications in the form of finite state machines that describe legal sequences of program behaviours.\par
Unfortunately, these existing mining techniques are insufficiently precise in practice. Some miners produce large but approximate specifications that must be corrected manually \hyperref[b4]{[5]}. As these large specifications are indefinite and difficult to debug, this article focuses on a second class of techniques that produce a larger set of smaller and more precise candidate specifications that may be easier to evaluate for correctness. These specifications typically take the form of two-state finite state machines that describe temporal properties, e.g. "if event a happens during program execution, event b must eventually happen during that execution." Twostate specifications are limited in their expressive power; comprehensive API specifications cannot always be expressed as a collection of smaller machines \hyperref[b7]{[8]}.\par
Recognize and illustrate lightweight, automatically collected software features that fairly accurate source code quality for the purpose of mining specifications. In this approach explain how to lift code quality metrics to metrics on traces, and empirically measure the utility of our lifted quality metrics when applied to previous static specification mining techniques. To avoid false positives recommend two novel specification mining techniques that use our automated quality metrics to learn temporal safety specifications. The main contributions of this project are: ? A set of source-level features related to software engineering processes that capture the trustworthiness of code for specification mining. We analyze the relative analytical power of each of these features. ? Experimental evidence that our notions of trustworthy code serve as a basis for evaluating the trustworthiness of traces. We provide a characterization for such traces and show that offthe-shelf specification miners can learn just as many specifications using only 60\% of traces. ? A novel automatic mining technique that uses our trust-capturing features to learn temporal safety specifications with few false positives in practice. We evaluate it on over 800,000 lines of code and explicitly compare it to two previous approaches. 
\section[{II.}]{II.} 
\section[{On going methodology}]{On going methodology}\par
Our basic mining technique learns specifications that locate more safety-policy violations than previous miners (740 vs. 426) while presenting far fewer false positive specifications (107 vs. 567). When focused on precision, our technique obtains a low 5\% false positive rate, an order-of-magnitude improvement on previous work, while still finding specifications that locate 265 violations. To our knowledge, this is the first specification miner that produces multiple candidate specifications and has a false positive rate under 90\%. i. 
\section[{Approach}]{Approach}\par
In this approach present a specification miner that works in three stages: 1. Statically estimate the trustworthiness of each code fragment. 2. Lift that judgment to traces by considering the code visited along a trace. 3. Weight the contribution of each trace by its trustworthiness when counting event frequencies for specification mining.\par
The code is most trustworthy when it has been written by experienced Programmers who are familiar with the project at hand, when it has been well-tested, and when it has been mindfully written. 
\section[{b) Mining Temporal Specification for Error Detection}]{b) Mining Temporal Specification for Error Detection}\par
If we use implicit language-based specifications (e.g., null pointers should not be dereferenced) or to reuse standard library specifications then it can reduce the cost of writing specifications. More recently, however, a variety of attempts have been made to conclude program-specific temporal specifications and API usage rules automatically. These specification mining techniques take programs (and possibly dynamic traces, or other hints) as input and produce candidate specifications as output. Basically specifications could also be used for documenting, refactoring, testing, debugging, maintaining, and optimizing a program. Centre of attention is that finding and evaluating specifications in a particular context: given a program and a generic verification tool, what specification mining technique should be used to find bugs in the program and thereby improve software quality? Thus we are concerned both with the number of "real" and "false positive" specifications produced by the miner and with the number of "real" and "false positive" bugs found using those "real" specifications.\par
In this methodology propose a novel technique for temporal specification mining that uses information about program error handling. Our miner assumes that programs will generally adhere to specifications along normal execution paths, but that programs will likely violate specifications in the presence of some run-time errors or exceptional situations. Intuitively, error-handling code may not be tested as often or the programmer may be unaware of sources of run-time errors. Taking advantage of this information is more important than ranking candidate policies. i. 
\section[{Contributions}]{Contributions} 
\section[{? Propose a novel specification mining technique}]{? Propose a novel specification mining technique}\par
based on the observation that programmers often make mistakes in exceptional circumstances or along uncommon code paths. ? Present a qualitative comparison of five miners and show how some miner assumptions are not wellsupported in practice. ? Finally, we give a quantitative comparison of our technique's bug-finding powers to generic "library" policies. For our domain of interest, mining finds 250 more bugs. We also show the relative unimportance of ranking candidate policies. In all, we find 69 specifications that lead to the discovery over 430 bugs in 1 million lines of code. 
\section[{III.}]{III.}\par
Proposed system for quantitative analysis of fault and failure\par
In proposed system, aim to develop a system which can be used to measure the quality of the code considering different aspects affecting the quality of the code. The term quality of the code can be explained using different factors such as code clone, author rank, code churn, code readability, path feasibility etc.\par
To Present a new specification miner that works in three stages. First, it statically estimates the quality of source code fragments. Second, it lifts those quality judgments to traces by considering all code visited along a trace. Finally, it weights each trace by its quality when counting event frequencies for specification mining. 
\section[{Global Journal of Computer Science and Technology}]{Global Journal of Computer Science and Technology}\par
Volume XII Issue XII Version I develops an automatic specification miner that balances true positives -as required behaviours -with false positives -non-required behaviours. We claim that one important reason that previous miners have high false positive rates is that they falsely assume that all code is equally likely to be correct. For example, consider an execution trace through a recently modified, rarely-executed piece of code that was copied and-pasted by an inexperienced developer. We believe that such a trace is a poor guide to correct behaviour, especially when compared with a well-tested, stable, and commonly-executed piece of code. Patterns of specification adherence may also be useful to a miner: a candidate that is violated in the high quality code but adhered to in the low quality code is less likely to represent required behaviour than one that is adhered to on the high quality code but violated in the low quality code. We assert that a combination of lightweight, automatically collected quality metrics over source code can usefully provide both positive and negative feedback to a miner attempting to distinguish between true and false specification candidates.\par
Code quality information may be gathered either from the source code itself or from related artefacts, such as version control history. By augmenting the trace language to include information from the software engineering process, we can evaluate the quality of every piece of information supporting a candidate specification (traces that adhere to a candidate as well as those that violate it and both high and low quality code) on which it is followed and more accurately evaluate the likelihood that it is valid.\par
The system architecture of the system is as in following figure, which explains the modules to be generated.  
\section[{Conclusion}]{Conclusion}\par
Testing, maintenance, optimization, refactoring, documentation, and program repair these are the various applications of formal specification. Though human programmers should not produce and verify such specification manually. These technique is also problematic since it treat all parts of program as equally indicative as correct behaviour. We encode this intuition using dependability metrics such as analytical execution frequency, copy paste code measurements, code duplication software readability or path feasibility. We compare the bug finding power of various miners. This technique improves the performance of existing trace based miners by focusing on high quality traces. Our technique is also useful to improve the quality of code through specification mining. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_2}Figure 1 :}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[ J. ACM ()]{b13}\label{b13} 	 		\textit{},  	 	 		\textit{J. ACM}  		2005. 52  (3)  p. .  	 
\bibitem[Mccabe ()]{b18}\label{b18} 	 		‘A complexity measure’.  		 			T J Mccabe 		.  	 	 		\textit{IEEE Trans. Software Eng}  		1976. 2  (4)  p. .  	 
\bibitem[Chidamber and Kemerer ()]{b11}\label{b11} 	 		‘A metrics suite for object oriented design’.  		 			S R Chidamber 		,  		 			C F Kemerer 		.  	 	 		\textit{IEEE Trans. Softw. Eng}  		1994. 20  (6)  p. .  	 
\bibitem[Krinke ()]{b16}\label{b16} 	 		\textit{A study of consistent and inconsistent changes to code clones},  		 			J Krinke 		.  		2007. WCRE. IEEE Computer Society. p. .  	 
\bibitem[Whaley et al. (ed.) ()]{b8}\label{b8} 	 		\textit{Automatic extraction of object-oriented component interfaces},  		 			J Whaley 		,  		 			M C Martin 		,  		 			M S Lam 		.  		ISSTA (ed.)  		2002.  	 
\bibitem[Engler et al. ()]{b23}\label{b23} 	 		‘Bugs as inconsistent behavior: A general approach to inferring errors in systems code’.  		 			D R Engler 		,  		 			D Y Chen 		,  		 			A Chou 		.  	 	 		\textit{Symposium on Operating Systems Principles},  				2001. p. .  	 
\bibitem[Engler et al. ()]{b6}\label{b6} 	 		‘Bugs as inconsistent behaviour: A general approach to inferring errors in systems code’.  		 			D R Engler 		,  		 			D Y Chen 		,  		 			A Chou 		.  	 	 		\textit{Symposium on Operating System Principles},  				2001. p. .  	 
\bibitem[Kapser and Godfrey ()]{b15}\label{b15} 	 		\textit{Cloning Considered Harmful" in WCRE},  		 			C Kapser 		,  		 			M W Godfrey 		.  		2006. p. .  	 
\bibitem[Ammons et al. ()]{b4}\label{b4} 	 		‘Debugging temporal specifications with concept analysis’.  		 			G Ammons 		,  		 			D Mandelin 		,  		 			R Bod´?k 		,  		 			J R Larus 		.  	 	 		\textit{Programming Language Design and Implementation},  				2003. p. .  	 
\bibitem[Kayed and Chang (2010)]{b10}\label{b10} 	 		‘FiVaTech: Page-Level Web Data Extraction from Template Pages’.  		 			Mohammed Kayed 		,  		 			Chia-Hui Chang 		.  	 	 		\textit{IEEE Transactions On Knowledge And Data Engineering}  		February 2010. 22  (2) .  	 
\bibitem[Das ()]{b2}\label{b2} 	 		‘Formal specifications on industrial-strength code from myth to reality’.  		 			M Das 		.  	 	 		\textit{Computer-Aided Verification},  				2006. p. 1.  	 
\bibitem[Le Goues and Weimer]{b9}\label{b9} 	 		‘Measuring code quality to improve specification mining’.  		 			Claire Le Goues 		,  		 			Westely Weimer 		.  	 	 		\textit{IEEE Trans. Software Eng}  		 	 
\bibitem[Ammons et al. ()]{b5}\label{b5} 	 		‘Mining specifications’.  		 			G Ammons 		,  		 			R Bodik 		,  		 			J R Larus 		.  	 	 		\textit{Principles of Programming Languages},  				2002. p. .  	 
\bibitem[Weimer and Necula ()]{b22}\label{b22} 	 		‘Mining temporal specifications for error detection’.  		 			W Weimer 		,  		 			G C Necula 		.  	 	 		\textit{TACAS}  		2005. p. .  	 
\bibitem[Sanchez et al. (2007)]{b20}\label{b20} 	 		\textit{On the Sustained Use of a Test Driven Development Practice at IBM," in Agile},  		 			J C Sanchez 		,  		 			L Williams 		,  		 			E M Maximilien 		.  		2007. August 2007. IEEE Computer Society. p. .  	 
\bibitem[Weimer and Mishra ()]{b21}\label{b21} 	 		‘Privately finding specifications’.  		 			W Weimer 		,  		 			N Mishra 		.  	 	 		\textit{IEEE Trans. Software Eng}  		2008. 34  (1)  p. .  	 
\bibitem[Seacord et al. ()]{b1}\label{b1} 	 		 			R C Seacord 		,  		 			D Plakosh 		,  		 			G A Lewis 		.  		\textit{Modernizing Legacy Practices},  				2003.  	 
\bibitem[Chen et al. ()]{b3}\label{b3} 	 		‘Setuid demystified’.  		 			H Chen 		,  		 			D Wagner 		,  		 			D Dean 		.  	 	 		\textit{USENIX Security Symposium},  				2002. p. .  	 
\bibitem[Detlefs et al.]{b12}\label{b12} 	 		\textit{Simplify: a theorem prover for program checking},  		 			D Detlefs 		,  		 			G Nelson 		,  		 			J B Saxe 		.  		 	 
\bibitem[Goues and Weimer ()]{b17}\label{b17} 	 		‘Specification mining with few false positives’.  		 			C 		,  		 			Le Goues 		,  		 			W Weimer 		.  	 	 		\textit{TACAS},  				2009. p. .  	 
\bibitem[Gabel and Su ()]{b7}\label{b7} 	 		‘Symbolic mining of temporal specifications’.  		 			M Gabel 		,  		 			Z Su 		.  	 	 		\textit{ICSE},  				2008. p. .  	 
\bibitem[The economic impact of inadequate infrastructure for software testing (2002)]{b0}\label{b0} 	 		\textit{The economic impact of inadequate infrastructure for software testing},  		may 2002.  		 			National Institute of Standards and Technology 		 	 	 (Tech. Rep. 02-3) 
\bibitem[Nagappan and Ball ()]{b19}\label{b19} 	 		‘Using software dependencies and churn metrics to predict field failures: An empirical case study’.  		 			N Nagappan 		,  		 			T Ball 		.  	 	 		\textit{ESEM},  				2007. p. .  	 
\bibitem[Penta and German ()]{b14}\label{b14} 	 		‘Who are source code contributors and how do they change?’.  		 			M 		,  		 			Di Penta 		,  		 			D M German 		.  	 	 		\textit{in Working Conference on Reverse Engineering},  				2009. IEEE Computer Society. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
