Added Comments in 3.3.2

Secciones/incremental_slicing.tex

@@ -275,7 +275,7 @@ The \texttt{try-catch} statement can be compared to a \texttt{switch} which comp
 \subsection{\texttt{throw} statement}
 
 The \texttt{throw} statement compounds two elements in one instruction: an
-unconditional jump with a value attached and a switch to an ``exception mode'', in which the statement's execution order is disregarded. The first one has been extensively covered and solved; as it is equivalent to the \texttt{return} instruction, but the second one requires a small addition to the CFG: there must be an alternative control flow, where the path of the exception is shown. For now\sergio{esto suena muy espanyol no? So far?}, without including \texttt{try-catch} structures, any exception thrown will exit its method with an error; so a new ``Error end'' node is needed.\sergio{No me convence esta frase, a ver como os suena esto (aunque no estoy muy convencido de ello) $\rightarrow$ So far, without including \texttt{try-catch} structures, any exception thrown will activate the mentioned ``exception mode" and leave its method with an error state. Hence, in order to represent this behaviour, a different exit point (represented with a node called ``Error end") need to be defined.} \deleted{T}\added{Consecuently, t}he pre-existing ``End'' node is renamed \added{as} ``Normal end'', \deleted{but now the}\added{leaving the} CFG \deleted{has}\added{with} two distinct sink nodes; which is forbidden in most slicing algorithms. To solve that problem, a general ``End'' node is created, with both normal and \deleted{exit}\added{error} ends connected to it; making it the only sink in the graph.
+unconditional jump with a value attached and a switch to an ``exception mode'', in which the statement's execution order is disregarded. The first one has been extensively covered and solved; as it is equivalent to the \texttt{return} instruction, but the second one requires a small addition to the CFG: there must be an alternative control flow, where the path of the exception is shown. For now\sergio{esto suena muy espanyol no? So far?}, without including \texttt{try-catch} structures, any exception thrown will exit its method with an error; so a new ``Error end'' node is needed.\sergio{No me convence esta frase, a ver como os suena esto (aunque no estoy muy convencido de ello) $\rightarrow$ So far, without including \texttt{try-catch} structures, any exception thrown would activate the mentioned ``exception mode" and leave its method with an error state. Hence, in order to represent this behaviour, a different exit point (represented with a node called ``Error end") need to be defined.} \deleted{T}\added{Consecuently, t}he pre-existing ``End'' node is renamed \added{as} ``Normal end'', \deleted{but now the}\added{leaving the} CFG \deleted{has}\added{with} two distinct sink nodes; which is forbidden in most slicing algorithms. To solve that problem, a general ``End'' node is created, with both normal and \deleted{exit}\added{error} ends connected to it; making it the only sink in the graph.
 
 In order to properly accommodate a method's output variables (global variables or parameters passed by reference that have been modified), variable unpacking is added to the ``Error exit'' node; same as the ``Exit''\sergio{Exit?End?Vaya cacao llevamos con esto xD} node in previous examples. This change constitutes an increase in precision, as now the outputted variables are differentiated\deleted{; f}\added{. F}or example\added{,} a slice which only requires the error exit may include less variable modifications than one which includes both.
 
@@ -305,18 +305,18 @@ double f(int x) {
 \subsection{\texttt{try-catch-finally} statement}
 
 The \texttt{try-catch} statement is the only way to stop an exception once it is thrown.
-It filters \added{each} exception by its type; letting those which do not match any of the catch blocks propagate to another \texttt{try-catch} surrounding it or outside the method, to the previous one in the call stack.
+It filters \added{each} exception by its type; letting those which do not match any of the catch blocks propagate to \deleted{another}\added{an external} \texttt{try-catch}\deleted{surrounding it}\added{block} or \deleted{outside the method,} to the previous \deleted{one}\added{method} in the call stack.
 On top of that, the \texttt{finally} block helps programmers guarantee code execution. It can be used replacing or in conjunction with \texttt{catch} blocks.
 The code placed inside a \texttt{finally} block is guaranteed to run if the \texttt{try} block has been entered.
 This holds true whether the \texttt{try} block exits correctly, an exception is caught, an exception is left uncaught or an exception is caught and another one is thrown while handling it (within its \texttt{catch} block).
 
 \carlos{This would be useful to explain that the new dependencies introduced by the non-executable edges are not ``normal'' control dependencies, but ``presence'' dependencies. Opposite to traditional control dependence, where $a \ctrldep b$ if and only if the number of times $b$ is executed is dependent on the \textit{execution} of $a$ (e.g. conditional blocks and loops); this new control dependencies exist if and only if the number of times $b$ is executed is dependent on the \textit{presence} or \textit{absence} of $a$; which introduces a meta-problem. In the case of exceptions, it is easy to grasp that the absence of a catch block alters the results of an execution. Same with unconditional jumps, the absence of breaks modifies the flow of the program, but its execution does not control anything. A differentiation seems appropriate, even if only as subcategories of control dependence: execution control dependence and presence control dependence.}
 
-The main problem when including \texttt{try-catch} blocks in program slicing is that \texttt{catch} blocks are not always strictly necessary for the slice (less so for weak slices), but introduce new styles of control dependence; which must be properly mapped to the SDG. The absence of \texttt{catch} blocks may also be a problem for compilation, as Java requires at least one \texttt{catch} or \texttt{finally} block to accompany each \texttt{try} block; though that could be fixed after generating the slice, if it is required that the slice be executable.
+The main problem when including \texttt{try-catch} blocks in program slicing is that \texttt{catch} blocks are not always strictly necessary for the slice (less so for weak slices), but introduce new styles of control dependence \sergio{De esto se habla luego? de estos ``new styles"? si es asi acuerdate de referenciarlo forward diciendo donde. Me imagino que es lo que pone en tu comentario de la presence control dependence.}; which must be properly mapped to the SDG. The absence of \texttt{catch} blocks may also be a problem for compilation, as Java requires at least one \texttt{catch} or \texttt{finally} block to accompany each \texttt{try} block; though that could be fixed after generating the slice, if it is required that the slice be \sergio{be or to be?} executable.
 
-A typical representation of the \texttt{try} block is as a pseudo-predicate, connected to the first statement inside it and to the instruction that follows the \texttt{try} block.
+A typical\sergio{La tipica o la de la propuesta de Horwitz? Si es la de Horwitz di que ellos lo hacen asi, que ya hemos dicho que es lo mas importante hasta la fecha en Java.} representation of the \texttt{try} block is as a pseudo-predicate, connected to the first statement inside it and to the instruction that follows the \texttt{try} block.
 This generates control dependencies from the \texttt{try} node to each of the instructions it contains.
-\carlos{This is not really a ``control'' dependency, could be replaced by the definition of structural dependence.}
+\carlos{This is not really a ``control'' dependency, could be replaced by the definition of structural dependence.}\sergio{Totalmente, pero para decir esto hay que definir la structural dependence, que imagino que estara en la seccion 4.}
 Inside the \texttt{try} there can be four distinct sources of exceptions:
 
 \begin{description}
@@ -325,6 +325,7 @@ Inside the \texttt{try} there can be four distinct sources of exceptions:
 		As \textit{checked} exceptions must be declared explicitly, method declarations may be consulted to see if a method call may or may not throw any exceptions.
 		On this front, polymorphism and inheritance present no problem, as inherited methods must match the signature of the parent method ---including exceptions that may be thrown.
 		If \textit{unchecked} exceptions are also considered, method calls could be analysed to know which exceptions may be thrown, or the documentation be checked automatically for the comment annotation \texttt{@throws} to know which ones are thrown.
+		\sergio{In case \textit{unchecked} exceptions would be also considered, a further analysis must be done  }
 	\item[\texttt{throw} statements.] The least common, but most simple, as it is treated as a
 		\texttt{throw} inside a method. The type of the exception may be obvious, as most \carlos{this is a weird claim to make without backup} exceptions are built and thrown in the same instruction; but it also may be hidden: e.g., \texttt{throw (Exception) o} where \texttt{o} is a variable of type Object.
 	\item[Implicit unchecked exceptions.] If \textit{unchecked} exceptions are considered, many
@@ -438,3 +439,4 @@ for the case where there is no active exception and another one for the case whe
 an exception active. An exception could also be thrown here, but that would be represented normally.
 
 % vim: set noexpandtab:ts=2:sw=2:wrap
+