cambios

Secciones/background.tex

@@ -133,7 +133,7 @@ object--oriented languages~\cite{???} or functional languages~\cite{???}.
 
 \subsection{The System Dependence Graph (SDG)}
 
-There exist multiple approaches to compute a slice\sergio{esto me suena raro, yo diria program representations o data structures that allow the use of program slicing techniques o algo asi, debatirlo} from a given program and
+There exist multiple approaches to compute a slice\sergio{esto me suena raro, yo diria program representations o data structures that allow the use of program slicing techniques o algo asi, debatirlo}\carlos{DENIED} from a given program and
 slicing criterion, but the most efficient and broadly used \josep{technique is based on a data structure called} data structure is the System
 Dependence Graph (SDG), first introduced by Horwitz, Reps\josep{,} and
 Blinkey \sergio{in 1988}\sergio{Todos los autores o los citamos con et al.? lo digo por seguir la misma regla durante todo el document}~\cite{HorwitzRB88}. It is computed from the program's statements\sergio{source code}, and
@@ -150,13 +150,15 @@ representing an \deleted{instruction}\added{statement} in the program ---barring
 introduced by some approaches--- and directed edges, which represent the
 dependencies among nodes. Those edges represent various\sergio{several} kinds of dependencies
 ---control, data, calls, parameter passing, summary--- which\josep{that are defined} will be defined\sergio{further explained?} in
-section~\ref{sec:first-def-sdg}.
+section~\ref{sec:first-def-sdg}. \carlos{add how a graph is sliced.}
 
 To create the SDG, first \josep{yo dejaria el a (como estaba)}\deleted{a}\added{the corresponding} \textsl{control flow graph} (CFG) is built for each method
 in the program, then\added{,} its \added{associated }control and data dependencies are computed, resulting
-in \added{a new graph representation known as }the \textsl{program dependence graph} (PDG)\sergio{cita??}\josep{si, a Ottenstein and Ottenstein}. Finally, all the graphs from every
-method are joined \added{by the appearance of a new kind of inter-procedural arcs, the argument-in argument-out arcs that link function definitions with function calls, obtaining}\deleted{into} the \added{final} SDG. This process will be explained at greater
+in \added{a new graph representation known as }the \textsl{program dependence graph} (PDG)\sergio{cita??}\josep{si, a Ottenstein and Ottenstein}\carlos{TENSTEIN, K. J., AND O’ITENSTEIN, L. M. The program dependence graph in a software development environment}. Finally, all the graphs from every
+method are joined \carlos{NO by the appearance of a new kind of inter-procedural arcs, the argument-in argument-out arcs that link function definitions with function calls, obtaining}\deleted{into} the \added{final} SDG. This process will be explained at greater
 lengths in section~\ref{sec:first-def-sdg}.
+
+\carlos{falta mencionar el recorrido del grafo.}
 %TODO: marked for removal --- this process is repeated later in ref{sec:first-deg-sdg}
 %\begin{description}
 	%\item[CFG] The control flow graph is the representation of the control

Secciones/incremental_slicing.tex

@@ -62,7 +62,7 @@ To build the PDG and then the SDG, there are two dependencies based directly on
 	Vertex $b$ is \textit{data dependent} on vertex $a$ ($a \datadep b$) if and only if $a$ may define a variable $x$, $b$ may use $x$ and there exists a \carlos{could it be ``an''??} $x$-definition free path from $a$ to $b$.
 	
 	Data dependency was originally defined as flow dependency, and split into loop and non--loop related dependencies, but that distinction is no longer useful to compute program slices \sergio{Quien dijo que ya no es util? Vale la pena citarlo?}.
-	It should be noted that variable definitions and uses can be computed for each statement independently, analyzing the procedures called by it if necessary. The variables used and defined by a procedure call are those used and defined by its body.
+	It should be noted that variable definitions and uses can be computed for each statement independently, analysing the procedures called by it if necessary. The variables used and defined by a procedure call are those used and defined by its body.
 \end{definition}
 
 With the data and control dependencies, the PDG may be built by replacing the
@@ -318,66 +318,76 @@ Inside the \texttt{try} there can be four distinct sources of exceptions:
 		types that inherit from \texttt{RuntimeException}, but those may only be explicitly thrown.
 		Their inclusion in program slicing and therefore in the method's CFG generates extra
 		dependencies that make the slices produced bigger.
-	\item[\added{Errors}\deleted{Erorrs}.] May be generated at any point in the execution of the program, but they normally
+	\item[Errors.] May be generated at any point in the execution of the program, but they normally
 		signal a situation from which it may be impossible to recover, such as an internal JVM error.
-		In general, most programs do not consider these to be ``catch-able''.
+		In general, most programs will not attempt to catch them, and can be excluded in order to simplify implicit unchecked exceptions (any instruction at any moment may throw an Error).
 \end{description}
 
-All exception sources are treated in a similar fashion: the statement that may throw an exception
+All exception sources are treated very similarly: the statement that may throw an exception
 is treated as a predicate, with the true edge connected to the next instruction were the statement
-to execute without raising exceptions; and the false edge connected to the \texttt{catch} node.
+to execute without raising exceptions; and the false edge connected to all the possible \texttt{catch} nodes which may be compatible with the exception thrown.
 
-\carlos{CATCH Representation doesn't matter, it is similar to a switch but checking against types.
-	The difference exists where there exists the possibility of not catching the exception;
+The case of method calls that may throw exceptions is slightly different, as there may be variables to unpack, both in the case of a normal or erroneous exit. To that end, nodes containing method calls have an unlimited number of outgoing edges: one to leads to a node labelled ``normal return'', after which the variables produced by any normal exit of the method are unpacked; and all the others to any possible catch that may catch the exception thrown. Each catch must then unpack the variables produced by the erroneous exits of the method.
+
+The ``normal return'' node is itself a pseudo-statement; with the \textit{true} edge leading to the following instruction and the \textit{false} one to the first common instruction between all the paths of length $\ge 1$ that start from the method call ---which translates to the instruction that follows the \texttt{try} block if all possible exceptions thrown by the method are caught or the ``Exit'' node if there are some left uncaught.
+
+\deleted{Carlos: CATCH Representation doesn't matter, it is similar to a switch but checking against types.
+	The difference exists where there exists the chance of not catching the exception;
 	which is semantically possible to define. When a \texttt{catch (Throwable e)} is declared,
 	it is impossible for the exception to exit the method; therefore the control dependency must
 	be redefined.}
 
-The filter for exceptions in Java's \texttt{catch} blocks is a type (or multiple types since
+\deleted{The filter for exceptions in Java's \texttt{catch} blocks is a type (or multiple types since
 Java 8), with a class that encompasses all possible exceptions (\texttt{Throwable}), which acts
-as a catch--all.
+as a catch-all.
 In the literature there exist two alternatives to represent \texttt{catch}: one mimics a static
 switch statement, placing all the \texttt{catch} block headers at the same height, all pending
 from the exception-throwing exception and the other mimics a dynamic switch or a chain of \texttt{if}
 statements. The option chosen affects how control dependencies should be computed, as the different
-structures generate different control dependencies by default.
+structures generate different control dependencies by default.}
 
-\begin{description}
+\deleted{\begin{description}
 	\item[Switch representation.] There exists no relation between different \texttt{catch} blocks,
-		each exception--throwing statement is connected through an edge labeled false to each
+		each exception-throwing statement is connected through an edge labelled false to each
 		of the \texttt{catch} blocks that could be entered. Each \texttt{catch} block is a
-		pseudo--statement, with its true edge connected to the end of the \texttt{try} and the 
+		pseudo-statement, with its true edge connected to the end of the \texttt{try} and the 
 		As an example, a \texttt{1 / 0} expression may be connected to \texttt{ArithmeticException},
 		\texttt{RuntimeException}, \texttt{Exception} or \texttt{Throwable}.
 		If any exception may not be caught, there exists a connection to the ``Error exit'' of the method.
-	\item[If-else representation.] Each exception--throwing statement is connected to the first
+	\item[If-else representation.] Each exception-throwing statement is connected to the first
 		\texttt{catch} block. Each \texttt{catch} block is represented as a predicate, with the true
 		edge connected to the first statement inside the \texttt{catch} block, and the false edge
-		to the next \texttt{catch} block, until the last one. The last one will be a pseudo--predicate
-		connected to the first statement after the \texttt{try} if it is a catch--all type or to the
+		to the next \texttt{catch} block, until the last one. The last one will be a pseudo-predicate
+		connected to the first statement after the \texttt{try} if it is a catch-all type or to the
 		``Error exit'' if it \added{is not}\deleted{isn't}.
-\end{description}
+\end{description}}
 
-\begin{example}[Catches.]\ \\
-	\begin{minipage}{0.49\linewidth}
+\begin{example}[Catches.]
+	Consider the following segment of Java code in figure~\ref{fig:try-catch}, which includes some statements that do not use data (X, Y and Z), and method call to \texttt{f} that uses \texttt{x} and \texttt{y}, two global variables. \texttt{f} may throw an exception, so it has been placed inside a \texttt{try-catch} structure, with a statement in the \texttt{catch} that logs the error when it occurs. Additionally, when \texttt{f} exits without an error, only \texttt{x} is modified; but when an error occurs, only \texttt{y} is modified.
+
+	Note how the 
+	\begin{figure}[h]
+	\begin{minipage}{0.35\linewidth}
 		\begin{lstlisting}
-			try {
-				f();
-			} catch (CheckedException e) {
-			} catch (UncheckedException e) {
-			} catch (Throwable e) {
-			}
+try {
+	X;
+	f();
+	Y;
+} catch (Exception e) {
+	System.out.println("error");
+}
+Z;
 		\end{lstlisting}
 	\end{minipage}
-	\begin{minipage}{0.49\linewidth}
-		\carlos{missing figures with 4 alternatives: if-else (with catch--all and without) and switch (same two)}\josep{Definitely!!!}
-%		\includegraphics[0.5\linewidth]{img/catch1}
-%		\includegraphics[0.5\linewidth]{img/catch2}
-%		\includegraphics[0.5\linewidth]{img/catch3}
-%		\includegraphics[0.5\linewidth]{img/catch4}
+	\begin{minipage}{0.64\linewidth}
+		\includegraphics[width=\linewidth]{img/try-catch-example}
 	\end{minipage}
+	\caption{A simple example of the representation of \texttt{try-catch} structures and method calls that may throw exceptions.}
+	\label{fig:try-catch}
+	\end{figure}
 \end{example}
 
+% \delete{From here to the end, move to solution chapter (CARLOS)}
 Regardless of the approach, when there exists a catch--all block, there is no dependency generated
 from the \texttt{catch}, as all of them will lead to the next instruction. However, this means that
 if no data is outputted from the \texttt{try} or \texttt{catch} block, the catches will not be picked
@@ -389,12 +399,12 @@ but are completely innocuous as they just stop the exception, without running an
 Another alternative exists, though, but slows down the process of creating a slice from a SDG.
 The \texttt{catch} block is only strictly needed if an exception that it catches may be thrown and
 an instruction after the \texttt{try-catch} block should be executed; in any other case the \texttt{catch}
-block is irrelevant and should not be included. However, this change requires analyzing the inclusion
+block is irrelevant and should not be included. However, this change requires analysing the inclusion
 of \texttt{catch} blocks after the two--pass algorithm has completed, slowing it down. In any case, each
 approach trades time for accuracy and vice--versa, but the trade--off is small enough to be negligible.
 
 Regarding \textit{unchecked} exceptions, an extra layer of analysis should be performed to tag statements
-with the possible exceptions they may throw. On top of that, methods must be analyzed and tagged
+with the possible exceptions they may throw. On top of that, methods must be analysed and tagged
 accordingly. The worst case is that of inaccessible methods, which may throw any \texttt{RuntimeException},
 but with the source code unavailable, they must be marked as capable of throwing it. This results on
 a graph where each instruction is dependent on the proper execution of the previous statement; save