tfm-report/Secciones/motivation.tex

% !TEX encoding = UTF-8
% !TEX spellcheck = en_US
% !TEX root = ../paper.tex

\chapter{Introduction}
\label{cha:introduction}
\section{Motivation}
\label{sec:motivation}

Program slicing~\cite{Wei81} is a debugging technique \deleted{which}\added{that}, given a line of
code and a \added{set of} variable\added{s} of a program, simplifies such program so that the only parts
left of it are those that affect \added{or are affected by} the value\added{s} of the selected variable\added{s}.

\begin{example}[Program slicing in a simple method]
	If the following program is sliced on \added{(line 5, variable \texttt{x})} \deleted{line 5 (variable \texttt{x})}, the
	result would be the program of\josep{at?} the right, with the \texttt{if} block
	skipped, as it \added{does not}\deleted{doesn't} affect the value of \texttt{x}.
	\label{exa:program-slicing}
	\begin{center}
	\begin{minipage}{0.49\linewidth}
		\begin{lstlisting}[stepnumber=1]
void f(int x) {
	if (x < 0)
		System.err.println(x);
	x++;
	System.out.println(x);
}
		\end{lstlisting}
	\end{minipage}
	\begin{minipage}{0.49\linewidth}
		\begin{lstlisting}[stepnumber=1]
void f(int x) {


	x++;
	System.out.println(x);
}
		\end{lstlisting}
	\end{minipage}
	\end{center}
\end{example}

Slices are \deleted{an} executable program\added{s} whose execution \deleted{will} produce\added{s} the same values
for the specified line and variable as the original program, and \added{they} are used to
facilitate debugging of large and complex programs, where the data flow may not
be easily understandable.

Though it may seem a really powerful technique, the whole Java language is not
completely covered by it, and that makes it difficult to apply in practical
settings.  An area that has been investigated, yet doesn't have a definitive
solution yet is exception handling. Example~\ref{exa:program-slicing2}
demonstrates how, even using the latest developments in program
slicing~\cite{Allen03}, the sliced version doesn't include the catch block, and
therefore doesn't produce a correct slice.

\begin{example}[Program slicing with examples]
	If the following program is sliced in line 17, variable \texttt{x}, the
	slice is incomplete, as it lacks the \texttt{catch} block from lines 4-6.
	\label{exa:program-slicing2}
	\begin{center}
		\begin{minipage}{0.49\linewidth}
			\begin{lstlisting}[stepnumber=1]
void f(int x) {
	try {
		g(x);
	} catch (RuntimeException e) {
		System.err.println("Error");
	}

	System.out.println("g() was ok");

	g(x);
}	

void g(int x) {
	if (x < 0) {
		throw new RuntimeException();
	}
	System.out.println(x);
}
			\end{lstlisting}
		\end{minipage}
		\begin{minipage}{0.49\linewidth}
			\begin{lstlisting}[stepnumber=1]
void f(int x) {
	try {
		g(x);
	}





	g(x);
}	

void g(int x) {
	if (x < 0) {
		throw new RuntimeException();
	}
	System.out.println(x);
}
			\end{lstlisting}
		\end{minipage}
	\end{center}
\end{example}

As big a problem as this one is, it doesn't occur in all cases, because of how
\texttt{catch} blocks are generally treated when slicing. Generally, two kinds
of dependencies among statements are analyzed: control (on the result of this
line may depend whether another one executes or not) and data (on the result of
this line, the inputs for another one may change).

The problem described doesn't occur when the inside the \texttt{try} block there
exist outgoing data dependencies, but it does when there aren't, creating
problems for structures with side effects such as a write action to a file or
database, or a network request whose result isn't used outside the \texttt{try}.
As most slicing tools ignore side effects and focus exclusively on the code and
some \texttt{catch} blocks are erroneously removed, which leads to incomplete
slices, which end with an error that is normally caught.

\section{Contributions}

The main contribution of this paper is a complete solution for program slicing
in the presence of exception handling constructs for Java; but in the process we
will present a history of program slicing, specifically those changes that
have affected exception handling. Furthermore, we provide a summary of the
different contributions each author has made to the field.

The rest of the paper is structured as follows: chapter~\ref{cha:background}
summarizes the theoretical background required, chapter~\ref{cha:state-art}
provides a bird's eye view of the current state of the art,
chapter~\ref{cha:solution} provides a step by step description of the problems
found with the state of the art and the solutions proposed, and
chapter~\ref{cha:conclusion} summarizes the paper and provides avenues of future
work.

% vim: set noexpandtab:tabstop=2:shiftwidth=2:softtabstop=2:wrap