finished ch3 pass 1

Secciones/background.tex

@@ -260,6 +260,7 @@ dependencies are \added{represented with }black \added{arcs}, data dependencies
 	\item[Forward static.] Used to obtain the lines affected by a statement,
 		used to identify dead code, to check the effects a line has on the rest
 		of the program.\josep{la principal aplicacion de forward slicing es software maintenance: Predecir a que partes del programa va a afectar un cambio.}
+		\carlos{https://ieeexplore.ieee.org/document/83912}
 	\item[Chopping static.] Obtains both the statements affected by and the
 		statements that affect the selected statement.
 	\item[Dynamic.] Can be combined with any of the previous variations, and

Secciones/incremental_slicing.tex

@@ -78,6 +78,16 @@ examples, \added{data and control dependencies are represented by thin solid red
 	\label{def:pdg}
 	\josep{Given a program $P$,} The \textsl{program dependence graph} (PDG) \josep{associated with $P$} is a directed graph (and originally a tree\sergio{???}\josep{sobran las aclaraciones historicas en una definicion}) represented by \josep{a triple $\langle N, E_c, E_d \rangle$ where $N$ is...} three elements: a set of nodes $N$, a set of control edges $E_c$ and a set of data edges $E_d$. \sergio{$PDG = \langle N, E_c, E_d \rangle$}
 
+	Method $M$, CFG $C = \langle N, E \rangle$, the PDG is $P = \langle N', E_c, E_d \rangle$, where
+	% $$E_c = \{ (a, b) | a, b \in N' \wedge a \ctrldep b\}$$
+
+	\begin{enumerate}
+		\vspace{-1em}
+		\item $N' = N \backslash \{End\}$ \vspace{-1em}
+		\item $(a, b) \in E_c \iff a, b \in N' \wedge a \ctrldep b ~ \wedge \not\exists c \in N' ~.~ a \ctrldep c \wedge c \ctrldep b$ \vspace{-1em}
+		\item $(a, b) \in E_d \iff a, b \in N' \wedge a \datadep b$
+	\end{enumerate}
+
 	The set of nodes corresponds to the set of nodes of the CFG\josep{que CFG? no se puede dar por hecho que existe un CFG en una definicion}, excluding the ``End'' node.
 	
 	Both sets of edges are built as follows\josep{:}. There is a control edge between two nodes $n_1$ and $n_2$ if and only if $n_1 \ctrldep n_2$\sergio{acordarse de lo de evitar la generacion de arcos para prevenir la transitividad. Decidir si definimos Control arc como ua definicion aparte.}, and a data edge between $n_1$ and $n_2$ if and only if $n_1 \datadep n_2$. Additionally, if a node $n$ does not have any incoming control edges, it has a ``default'' control edge $e = (\textnormal{Start},n)$; so that ``Start'' is the only source node of the graph.
@@ -91,8 +101,9 @@ Finally, the SDG is built from the combination of all the PDGs that compose the
 program.
 
 \begin{definition}[System dependence graph]
-
 	\label{def:sdg}
+	Given a program $P$ composed of a set of $n$ methods $M = \{m_0 ... m_n\}$ and their associated PDGs (each method $m_i$ has a PDG $G_{PDG}^i = \langle N^i, E_c^i, E_d^i \rangle$), the \textit{system dependence graph} (SDG) of $P$ is a graph $G = \langle N', E'_c, E'_d, E_{fc}, E_s \rangle$ where $N = \bigcup_{i=0}^n N^i$, $ $, $ $, $ $, and $ $.
+
 	\josep{Arreglar esta definicion como la del PDG. Ahora mismo es totalmente informal. Deberia definirse encima del PDG. Es decir, una SDG es la conexion adecuada de varios PDGs, uno por método. Y solo definir lo nuevo: call arcs, parameter-in arcs, parameter-out arcs y summary arcs.}
 	The \textsl{system dependence graph} (SDG) is a directed graph that represents the control and data dependencies of a whole program. It has three kinds of edges: control, data and function call. The graph is built combining multiple PDGs, with the ``Start'' nodes labeled after the function they begin. There exists one function call edge between each node containing one or more calls and each of the ``Start'' node\josep{s} of the method called. In a programming language where the function call is ambiguous (e.g. with pointers or polymorphism), there exists one edge leading to every possible function called.\sergio{Esta definicion ha quedado muy informal no? Donde han quedado los $E_c,~E_d,~E_{fc},$ Nodes del PDG...?}
 \end{definition}
@@ -372,7 +383,7 @@ structures generate different control dependencies by default.}
 \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 
+	Note how the pseudo-statements act to create control dependencies between the \textit{true} and \textit{false} edges, such as the ``normal return'', ``catch'', ``try''. The statements contained after the function call, inside the \texttt{catch} and the \texttt{try} blocks are respectively control dependent on the aforementioned nodes. Finally, consider the statement \texttt{Z}; which is not dependent on any part of the \texttt{try-catch} block, as all exceptions that may be thrown are caught: it will execute regardless of the path taken inside the \texttt{try} block. \carlos{Consider critiquing the result, saying that despite the last sentence, statements can be removed (the catch) so that the dependencies are no longer the same.}
 	\begin{figure}[h]
 	\begin{minipage}{0.35\linewidth}
 		\begin{lstlisting}
@@ -394,7 +405,8 @@ Z;
 	\end{figure}
 \end{example}
 
-% \delete{From here to the end, move to solution chapter (CARLOS)}
+\carlos{From here to the end of the chapter, delete / move to solution chapter}
+
 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

img/try-catch-example.dot

@@ -23,7 +23,7 @@ digraph G {
         x_in [label = "x_in = x"];
         y_in [label = "y_in = y"];
         call [label = "f()"];
-        nr [style=dashed];
+        nr [style=dashed, label = "normal return"];
         data [style=dashed, label = "x = x_out"];
         y [label = "Y"];
         c [label = "catch"];