Secciones/problem_solution.tex

@@ -4,19 +4,23 @@
 \chapter{Proposed solution}
 \label{cha:solution}
 
-Even though the current state of the art considers exception handling, their treatment is not perfect. The mistakes made by program slicers can be classified in two: those that lower the completeness and those that lower the correctness.
+\josep{Antes de nada, felicidades Carlos. En esta sección se ha notado una mejora importante. Sobretodo al introudcir los problemas, los ejemplos, etc. Sigue así!}
 
-The first kind is the most important one, as the resulting slices may be incorrect ---as in produce different values than the original program--- making them invalid for some uses of program slicing. As an example, imagine a slice used for program debugging which does not reach the slicing criterion due to an uncaught exception.
+\josep{This chapter features different problems and weaknesses of the current treatment that program slicing techniques use in presence of exceptions. Each problem is described with a counterexample that illustrates the loss of completeness or precision. Finally, for each problem a solution is proposed.}
 
-The second kind is less important, but still useful to address, as the smaller a slice is, the easier it is to use it.
+\josep{With regards to the problems, }Even though the current state of the art considers exception handling, their treatment is not perfect. The mistakes made by program slicers can be classified in two: \josep{(1)} those that lower the completeness and \josep{(2)} those that lower the correctness.  \josep{Remarco el 1 y el 2 porque los referencias mas adelante, lejos, y así se sabe que las referencias vienen aqui.}
 
-The rest of this chapter features different errors found in the state of the art, each with a detailed description, example, and proposals that solve them.
+The first kind is the most important one, as the resulting slices may be incorrect \josep{(i.e., the behaviour of the slice is different from the behaviour of the original program)\deleted{---as in produce different values than the original program---}} making them invalid for some uses of program slicing. \josep{A good example of the effects that these wrong slices may produce happens when they are used for program debugging, but the the error that we want to debug does not appear anymore, or even the slicing criterion cannot be reached due to an uncaught exception. \deleted{As an example, imagine a slice used for program debugging which does not reach the slicing criterion due to an uncaught exception.}}
+
+The second kind is less \josep{critic\deleted{important}}, but still \josep{important because a wrong treatment of exceptions can cause the inclusion of wrong dependencies in the slice, thus producing unnecessary long slices that may turn to be useless for some applications\deleted{useful to address, as the smaller a slice is, the easier it is to use it}}.
+
+\deleted{The rest of this chapter features different errors found in the state of the art, each with a detailed description, example, and proposals that solve them.}
 
 \section{Unconditional jump handling}
 
-The standard treatment of unconditional jumps as pseudo-statements introduces two separate correctness errors: the subsumption correctness error and the structure-exiting jump, that is only relevant in the context of weak slicing.
+The standard treatment of unconditional jumps as pseudo-statements introduces two separate correctness errors: \josep{\emph{the subsumption correctness error}, which is relevant in the context of both strong and weak slicing, and the \emph{structure-exiting jump}}, \josep{which\deleted{that}} is only relevant in the context of weak slicing.
 
-\subsection{Subsumption correctness error}
+\subsection{\josep{Problem 1: }Subsumption correctness error}
 
 This problem has been known since the seminal publication on slicing unconditional jumps~\cite{BalH93}: chapter 4 details an example where the slice is bigger than it needs to be, and leave the solution of that problem as an open question to be solved in future publications. A similar example ---with \texttt{break} statements instead of \texttt{goto}--- is shown in example~\ref{exa:problem-break-sub}.
 
@@ -84,27 +88,29 @@ public void f() {
 		\label{fig:problem-break-sub}
 	\end{figure}
 
-	Now consider statement \texttt{C} (line 11) as the slicing criterion. Figure~\ref{fig:problem-break-sub-sdg} displays the SDG produced for the program, and the nodes selected by the slice. Figure~\ref{fig:problem-break-sub} displays the computed slice on the centre, and the smallest slice possible on the left. The inner \texttt{break} on line 9 and the \texttt{if} surrounding it (line 7) have been unnecessarily included. Their inclusion would not be specially problematic, if it were not for the condition of the \texttt{if} statement, which may include extra data dependencies, whose only task is to control line 3.
+	Now consider statement \texttt{C} (line 11) as the slicing criterion. Figure~\ref{fig:problem-break-sub-sdg} displays the SDG produced for the program, and the nodes selected by the slice. Figure~\ref{fig:problem-break-sub} displays the computed slice on the centre, and the \josep{minimal slice\deleted{smallest slice possible}} on the left\josep{en realidad hay otro minimal slice si dejamos el otro break y quitamos el que hemos dejado}. The inner \texttt{break} on line \josep{6\deleted{9}} and the \texttt{if} surrounding it (line \josep{4\deleted{7}}) have been unnecessarily included. Their inclusion would not be specially problematic, if it were not for the condition of the \texttt{if} statement \josep{(line 4)}, which may include extra data dependencies \josep{that are unnecessary in the slice and that may led to include other unnecessary statements, making the slice even more imprecise\deleted{, whose only task is to control line 3}}.
 
-	Line 6 is not useful, because whether or not it executes, the execution will continue on line 13 (after the \texttt{while}), as guaranteed by line 9, which is not guarded by any condition. Note that \texttt{B} is still control-dependent on line 5, as it has a direct effect on it, but the dependence from line 5 to line 9 introduces useless statements into the slice.
+	Line 6 is not useful, because whether or not it executes, the execution will continue on line 13 (after the \texttt{while}), as guaranteed by line 9, which is not guarded by any condition. Note that \texttt{B} is still control-dependent on line \josep{6\deleted{5}}, as it has a direct effect on it, \josep{no termino de entender esta frase}but the dependence from line 5 to line 9 introduces useless statements into the slice.
 
 	\begin{figure}[h]
 		\centering
 		\includegraphics[width=0.5\linewidth]{img/problem-break-sub-graph}
-		\caption{The system dependence graph for the program of figure \ref{fig:problem-break-sub}, with the slice marked in grey, and the slicing criterion in bold.}
+		\caption{The system dependence graph for the program of figure \ref{fig:problem-break-sub}, with the slice marked in grey, and the slicing criterion in bold.\josep{En las condiciones pones O,P,Q en lugar de X,Y,Z}}
 		\label{fig:problem-break-sub-sdg}
 	\end{figure}
 \end{example}
 
-The problem showcased in example~\ref{exa:problem-break-sub} can be generalized for any pair of unconditional jump statements that are nested and whose destination is the same. Formally, if a program $P$ contains a pair of unconditional jumps without any data (e.g. \texttt{goto label}, \texttt{continue [label]}, \texttt{break [label]}, \texttt{return}) $j_A$ and $j_B$ whose destinations (the instruction that will be executed after them) are $A$ and $B$, then $j_B$ is superfluous in the slice if and only if $A = B$ and $j_B$ is inside a conditional instruction $C$, and $j_A$ follows $C$ (not necessarily immediately). \carlos{Buscar mejor descripcion para la estructura ``nested''.} \carlos{Maybe use control dependencies between them.} Once $j_B$ is included, $C$ will also be included, and so will all of its data dependencies.
+The problem showcased in example~\ref{exa:problem-break-sub} can be generalized for any pair of unconditional jump statements that are nested and whose destination is the same. Formally, \josep{lo que sigue es bastante lioso. Yo crearia un entorno "problem" (como el de definition o example) y pondria el problema descrito formalmente en ese entorno. Despues, lo aclararia con una breve explicacion similar a la que hay entremezclada con la definicion formal}if a program $P$ contains a pair of unconditional jumps without any data (e.g. \texttt{goto label}, \texttt{continue [label]}, \texttt{break [label]}, \texttt{return}) $j_A$ and $j_B$ whose destinations (the instruction that will be executed after them) are $A$ and $B$, then $j_B$ is superfluous in the slice if and only if $A = B$ and $j_B$ is inside a conditional instruction $C$, and $j_A$ follows $C$ (not necessarily immediately). \carlos{Buscar mejor descripcion para la estructura ``nested''.} \carlos{Maybe use control dependencies between them.} Once $j_B$ is included, $C$ will also be included, and so will all of its data dependencies.
 
-\subsubsection*{Proposal}
+\subsubsection*{\josep{\deleted{Proposal}A solution for the subsumption correctness error}}
 
 As only the minimum amount of control edges are inserted into the PDG (according to definition~\ref{def:pdg}), the only edge that can be traverse to include the inner jump ($j_B$) is an edge $j_B \ctrldep j_A$. An exception can be included when generating the PDG, such that control edges between two unconditional jumps $j_X$ and $j_Y$ whose destinations are $X$ and $Y$ will not be included if $X = Y$.
 
 If the edge is not present, all inner unconditional jumps and their containing structures will be excluded from the slice, unless they are included for another reason.
 
-\subsection{Unnecessary instructions in weak slicing}
+\josep{pon a continuacion un ejemplo solucionando el problema (al menos di como quedaría el SDG)}
+
+\subsection{\josep{Problem 2: }Unnecessary instructions in weak slicing}
 
 In the context of weak slicing, as it is not necessary to behave exactly like the original program. This means that some statements may be removed, even if it means that a loop will become infinite, or an exception will not be caught. The following example describes a specific example which is generalized later in this section.