
\begin{figure*}[!t]
\footnotesize
\begin{center}
\begin{tabular}{|c|p{3.0in}|p{1.84in}|} \hline
\textbf{Measure} & \textbf{Description} & \textbf{Rationale for selection}
\\
\hline
\Bugs & Number of bugs as annotated in the source code control logs & Used to check our predictions\\
LOC & Lines of code in the class & Used to estimate inspection effort
\\\hline
%\LOC & Lines of code estimated from compiled bytecode & Volume of functionality 
%\\
\NOG & Number of get methods & Read responsibility allocation
\\
\NOS & Number of set methods & Write responsibility allocation
\\
\NOM & Number of methods & Breadth of functional decomposition
\\
\IDC & Number of other classes depending on this class & Coupling within design
\\
\ODC & Number of other classes this class depends upon & Breadth of delegation
\\
\CCC & Degree to which classes tend to cluster together & Density of design
\\
\hline
\end{tabular}
\end{center}
\caption{Measures used in this study (collected separately for each class).}\label{fig:metrics}
\end{figure*}


\section{Activity}
\label{sec:pop}

When do we call a software artifact, say a class, active? %At first glance, 
We contend that
activity arises when code is being modified, typically via enhancement or correction. This is change and we can detect and measure it through the evolution of the associated volumetric and structural properties of a class~\cite{Vasa10a}. 

However, one surprising observation from the Helix studies~\cite{vasa:09a,lumpe:10a,Vasa10a} has been that (a)~only a small set of highly active classes undergoes change frequently and (b)~predictable patterns of modification emerge very early in the lifetime of a software system. Therefore, we ask whether the metrics used in Helix can also guide defect discovery, since change and defects are closely related concepts. In particular, we argue that change can lead to defects via:

\bi
\item \emph{Defect discovery}: Since active classes are used more frequently by developers, then developers are most likely to discover their defects earlier.
\item \emph{Defect injection}: When developers work with active classes, they make occasional 
mistakes, some of which lead to defects. Since developers work on active classes more than other classes, 
then most developer defects accumulate in the active classes. 
\ei
(The second  point was first  proposed  by Nagappan \& Ball who say ``code that changes many times prerelease will likely have more post-release defects than code that changes less over the same period of time''~\cite{nag05}.)

\fig{metrics} shows our choice of measures of activity, each tagged with a rationale motivating its selection.
% why we believe that increasing the value of that measurement reflects the class
%popularity,  from the perspective of the code developers. 
These measures capture %the activity of a class as they encapsulate 
volumetric and the structural properties of a class and provide us with an empirical component for detecting and measuring change. Furthermore, these measures are sufficiently broad to encompass, from a design perspective, the amount of functionality as well as how the developers have structurally organized the solution, and how they chose to decompose the functionality.
%For details on how each of these are collected, see the Appendix.


The measures \NOM, \NOG, and \NOS define simple class-based counts (see \fig{mdefs}). For the complexity measures \IDC, \ODC, and \CCC, however, we need to construct a complete class dependency graph first. The class dependency graph captures the dependencies between these classes. That is, when a class uses either data or functionality from another class, there is a dependency between these classes. In the context of Java software, a dependency is created if a class inherits from a class, implements an interface, invokes a method on another class (including constructors), declares a field or local variable, uses an exception, or uses class types within a method declaration. Thus, a class dependency graph is an ordered pair $(N, L)$, where $N$ is a finite, nonempty set of \emph{types} (\ie, classes and interfaces) and $L$ is a finite, possibly empty, set of \emph{directed links} between types (\ie, $L \subseteq N \times N$) expressing the dependencies between classes. For the purpose of the metrics extraction, we analyze each node $n \in N$ in the graph to compute the structural complexity metrics of class $C$ type node $n$ represents as shown in \fig{mdefs}.

\begin{figure}[!b]
\centering
\footnotesize
\begin{tabular}{|p{1.3cm}|p{6cm}|} \hline
\bf{Metrics} & \bf{Definition} \\ \hline 
NoM & Counts all member functions defined by class $C$.
\\[1mm] 
Getters & Counts all non-overloaded member functions in class $C$ with arity zero, whose name starts with ``get." %Getters$(C) \subseteq$ NoM$(C)$.
\\[1mm]
Setters & Counts all non-overloaded member functions in class $C$ with arity one, whose name starts with ``set." %Setters$(C) \subseteq$ NoM$(C)$.
\\[1mm]
InDegree & Let $n$ be the type node for class $C$. Then $|\{ (n',n) \in L\ |\ n \neq n' \}|$ is the in-degree of class $C$. 
\\[1mm] 
OutDegree & Let $n$ be the type node for class $C$. Then $|\{ (n,n') \in L\ |\ n \neq n' \}|$ is the out-degree of class $C$.
\\[1mm]
Clustering Coefficient & 
Let $n$ be the type node for class $C$. Then
\begin{center}
$\frac{\displaystyle{2|\{ (n_i,n_j) \in L\ |\ n_i,n_j \in N_n \}|}}{\displaystyle{|N_n|(|N_n| - 1)}}$ %\\[2mm]
\end{center}
%& 
is the clustering coefficient of class $C$, 
where $N_n$ is the neighborhood of $n$ with 
\begin{center}
$N_n = \{ n'\ |\ (n',n) \in L \vee (n,n') \in L \}$.
\end{center}
%Thus, Clustering Coefficient is defined over an undirected image of the class dependency graph.
\\ \hline
\end{tabular}
\caption{Activity metrics definitions.}
\label{fig:mdefs}
\end{figure}



%The rationale for the collected information is given in \fig{metrics}. 

%\markus{say something about getter-setter relationship, add correlation of measures}

An important feature of these measures is that they are relatively easy to collect. For example, one measure we rely on for defect prediction is the \emph{Number of Getter Methods} that developers have added to a class. Parsers for such simple measures are easy to obtain from early design representation (\eg, UML models) and can, with little effort, be adapted to new languages. Moreover, all measures are pairwise independent~\cite{vasa:09a,lumpe:10a} (measured using Spearman's rank correlation). In particular, \NOG and \NOS do not occur in pairs and are not being used as a means to expose simply the private fields of a class~\cite{lumpe:10a}. In general, the odds are only 1:3  that if a class defines a getter, then this class will also provide a matching setter method.

%\begin{figure*}
%\caption{Spearman rank correlation coefficients.}
%\label{fig:mcorr}
%\end{figure*}

%% ML: we cannot make this argument. Our measures may be even more difficult to compute
%
%The same cannot be said for other measures. For example:
%\bi
%\item
%McCabe's cyclomatic complexity~\cite{mccabe76}, which requires a detailed
%parse of the internal structure of a function;
%\item
%Inter-procedural measures that struggle to build call graphs by
%disambiguating  pointers to functions (in ``C''-like languages).
%\ei 

%A disadvantage with using such simple metrics is, however, that they may be \emph{too} simple. As we define them
%below, the popularity metrics lack much of the information seen in the standard social metrics. For example, while
%our popularity metrics let us detect \emph{what} classes have been changed and to what extent, they are 
%uninformative about \emph{who} actually edited any particular class.
%Therefore, the task of this paper is to assess the value of the popularity metrics for defect prediction and develop a simple, yet effective, method for its application in the real world. An ideal approach for defect prediction would be relatively straightforward, based on simple measures, easy to understand, and directly associated with the developer's mental model for effective software development~\cite{Vasa10a}. Our pre-experimental expectation was that  popularity would be a \emph{lightweight metrics} quick to collect, simple to apply, and moderately useful, but outperformed by more heavyweight defect prediction methods. This turned out not to be the case.

%In \NSystems experiments with open-source data, we compared the performance of the popularity metrics against a theoretical upper bound on defect performance~\cite{cohen95}. To compute that upper bound, we adopt the defect inspection bias proposed by Arisholm and Briand~\cite{arisholm06} which aims at an optimal inspection policy in order to locate defects in the code base. Such a policy seeks to identify the \emph{most} faults while reading the \emph{least} amount of code and fits within the developer's workflow as it yields an inspection strategy that orders classes based on their defect probability.

%An ideal approach for defect prediction, we advocate, would be relatively straightforward, based on simple measures, 
%easy to understand, and directly associated with the developer's mental model for effective software 
%development~\cite{Vasa10a}. In this paper we demonstrate the value of using simple \emph{lightweight} metrics for 
%the specific task of defect prediction and, more specifically, present a technique that can guide the order in which 
%classes should be inspected for defect identification. We present evidence based on \NSystems experiments with 
%open-source data that shows that our selected popularity metrics perform very close to the theoretical upper bound
%on defect performance~\cite{cohen95}. To compute that upper bound, we adopt the defect inspection bias proposed 
%by Arisholm and Briand~\cite{arisholm06} which aims at an optimal inspection policy in order to locate defects in the 
%code base. Such a policy seeks to identify the \emph{most} faults while reading the \emph{least} amount of code
%and fits within the developer's workflow as it yields an inspection strategy that orders classes based on their defect 
%probability.
%
%Much to our surprise, 

