Secciones/background.tex

@@ -7,23 +7,23 @@
 
 \section{Program slicing}
 \textsl{Program slicing} \cite{Wei81,Sil12} is a debugging technique that
-answers the question: ``which parts of a program affect a given statement and
-variable?'' The statement and the variable are the basic input to create a slice
+answers the question: ``which parts of a program \added{do} affect a given statement and
+variable\added{s}?'' The statement and the variable\added{s} are the basic input to create a slice
 and are called the \textsl{slicing criterion}. The criterion can be more
 complex, as different slicing techniques may require additional pieces of input.
 The \textsl{slice} of a program is the list of statements from the original
 program ---which constitutes a valid program---, whose execution will result in
-the same values for the variable (selected in the slicing criterion) being read
-by a debugger in the selected statement.
+the same values for the variable\added{s} (selected in the slicing criterion)\deleted{ being read
+by a debugger in the selected statement}.
 There exist two fundamental dimensions along which the problem of slicing can be
-proposed:
+proposed \added{\cite{vocabulary}}:
 \begin{itemize}
 	\item \textsl{Static} or \textsl{dynamic}: slicing can be performed
 		statically or dynamically.
-		\textsl{Static slicing} \cite{Wei81} is a slice which considers all
+		\textsl{Static slicing} \cite{Wei81} \added{produces slices that}\deleted{is a slice which} consider\deleted{s} all
 		possible executions of the program, only taking into account the
 		semantics of the programming language.
-		In contrast, \textsl{dynamic slicing} \cite{KorL88} limits the slice to
+		In contrast, \textsl{dynamic slicing} \cite{KorL88} \added{considers a single execution of the program, thus, limiting} \deleted{limits} the slice to
 		the statements present in an execution log. The slicing criterion is
 		expanded to include a position in the log that corresponds to one
 		instance of the selected statement, making it much more specific. It may
@@ -35,8 +35,8 @@ proposed:
 		that affect the slicing criterion. In contrast, \textsl{forward slicing}
 		\cite{BerC85} computes the statements that are affected by the slicing
 		criterion. There also exists a mixed approach called \textsl{chopping}
-		\cite{JacR94}, which is used to find all statements that affect or are
-		affected by the slicing criterion.
+		\cite{JacR94}, which is used to find all statements that affect \added{some variables in the slicing criterion and at the same time they are affected by some other variables in} \deleted{or are
+		affected by} the slicing criterion.
 \end{itemize}
 
 Since the definition of program slicing, the most extended form of slicing has
@@ -73,25 +73,25 @@ of the program (i.e., for any input data).
 			for each of the variables in $v$ when executing $P$ is a prefix of
 			those produced while executing $S$ ---which means that the slice
 			may continue producing values, but the first values produced always
-			match up with the original program.
+			match up with \added{all those produced with} the original program.
 	\end{enumerate}
 \end{definition}
 
 Both definitions (\ref{def:strong-slice} and~\ref{def:weak-slice}) are
-used throughout the literature, with some cases favoring the first and some the
+used throughout the literature \added{(see, e.g., \cite{pending})}, with some cases favoring the first and some the
 second. Though the definitions come from the corresponding citations, the naming
 was first used in a control dependency analysis by Danicic~\cite{DanBHHKL11},
-where slices which produce the same output as the original are named
+where slices \added{that}\deleted{which} produce the same output as the original are named
 \textsl{strong}, and those where the original is a prefix of the slice,
 \textsl{weak} \carlos{Se podría argumentar que con el slice débil es suficiente
-para debugging, ya que si un error se presenta en el original, aparecerá también en el programa fragmentado}.
+para debugging, ya que si un error se presenta en el original, aparecerá también en el programa fragmentado}. \josep{Pues si. añade un parrafo. a continuacion explicando ese hecho, porque asi justificas la existencia de los dos. Un lector que no sepa de slicing ahora mismo se esta preguntando para que sirve la weak :-)}
 
 \begin{example}[Strong, weak and incorrect slices]
 	In table~\ref{tab:slice-weak} we can observe examples for the various
 	definitions. Each row shows the values produced by the execution of a
 	program or one of its slices.  The first is the original, which computes
 	$3!$. Slice A is one slice, whose execution is identical and therefore is a
-	strong slice. Slice B is correct but continues producing values after the
+	strong slice. Slice B \added{correctly produced the same values as the original program}\deleted{is correct} but \added{it} continues producing values after the
 	original stops ---a weak slice. It would fit the relaxed definition but not
 	a strong one. Slice C is incorrect, as the values differ from the original.
 	Some data or control dependency has not been included in the slice and the
@@ -112,8 +112,8 @@ para debugging, ya que si un error se presenta en el original, aparecerá tambi
 \end{table}
 
 Program slicing is a language--agnostic tool, but the original proposal by
-Weiser~\cite{Wei81} covers a simple imperative programming language.
-Since, the literature has been expanded by dozens of authors, that have
+Weiser~\cite{Wei81} \added{covered}\deleted{covers} a simple imperative programming language.
+Since \added{then}, the literature has been expanded by dozens of authors, that have
 described and implemented slicing for more complex structures, such as
 uncontrolled control flow~\cite{HorwitzRB88}, global variables~\cite{???},
 exception handling~\cite{AllH03}; and for other programming paradigms, such as
@@ -123,7 +123,7 @@ object-oriented languages~\cite{???} or functional languages~\cite{???}.
 \subsection{The System Dependence Graph (SDG)}
 
 There exist multiple approaches to compute a slice from a given program and
-criterion, but the most efficient and broadly use data structure is the System
+\added{slicing} criterion, but the most efficient and broadly use\added{d} data structure is the System
 Dependence Graph (SDG), first introduced by Horwitz, Reps and
 Blinkey~\cite{HorwitzRB88}. It is computed from the program's statements, and
 once built, a slicing criterion is chosen, the graph traversed using a specific

Secciones/motivation.tex

@@ -47,14 +47,14 @@ 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
+settings.  An area that has been investigated, yet \added{does not}\deleted{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.
+slicing~\cite{Allen03}, the sliced version \added{does not}\deleted{doesn't} include the catch block, and
+therefore \added{does not}\deleted{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
+	If the following program is sliced \josep{aqui podria colar no decir qué algoritmo usas (el de Horwitz, con su cita), pero en el paper no colará. Ponlo ya, no hace falta que lo expliques aún, pero así eres preciso.} \added{with respect to}\deleted{in} \added{(}line 17, variable \texttt{x}\added{)}, the
 	slice is incomplete, as it lacks the \texttt{catch} block from lines 4-6.
 	\label{exa:program-slicing2}
 	\begin{center}
@@ -105,30 +105,46 @@ void g(int x) {
 	\end{center}
 \end{example}
 
-As big a problem as this one is, it doesn't occur in all cases, because of how
+
+\josep{Explicar mejor el ejemplo. Ser generoso dando detalles, la ejecución, la diferencia, incluso el grafo de dependencias si hace falta... El motivating example es la parte mas importante de un paper. :-) Determina si van a seguir leyendote o no.}
+
+\added{If we consider the initial call {\tt f(0)}, then the execution history of the initial program is: 
+{\tt 1,2,3,13,14,15,4,5,6,7,8,9,10,13,14,15} (line 17 is never executed and {\tt f} returns with an exception). 
+In contrast, the execution of the slice is:   
+{\tt 1,2,3,13,14,15} (line 17 is never executed and {\tt f} returns with an exception).}
+
+\josep{Si no me he equivocado con esto anterior, este es un mal ejemplo, porque no se ejecuta el CS en ninguno de los dos programas (luego son equivalentes con respecto a ese punto con la informacion que das)}
+
+
+
+
+\josep{Lo siguiente me suena raro (el ingles). De hecho, no aparece ni una ocurrencia en Google. Reescribelo, please. Es dificil de entender.}As big a problem as this one is, it \added{does not}\deleted{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
+The problem described \added{does not}\deleted{doesn't} occur when \deleted{there
+exist outgoing data dependencies inside the \texttt{try} block}\deleted{the inside the \texttt{try} block there
+exist outgoing data dependencies}, but it does when there \added{are not}\deleted{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}.
+database, or a network request whose result \added{is not}\deleted{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
+The main contribution of this paper is a complete \added{technique}\deleted{solution} for program slicing
+in the presence of exception handling constructs for Java\added{. This technique extends the previous technique by Hortwitz et al. \cite{pending}. It considers all cases considered in that work, but it also provides a solution to cases not considered by them.}  
+
+\added{For the sake of completeness and in order to understand the process that leaded us to this solution, firstly,} we
+will \added{briefly} 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}
+summarizes the theoretical background required, \josep{y chapter 3?} 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