merge incremental_slicing.tex

incremental_slicing.tex

@@ -1,6 +1,6 @@
-% !TeX encoding = UTF-8
-% !TeX spellcheck = en_US
-% !TeX root = paper.tex
+% !TEX encoding = UTF-8
+% !TEX spellcheck = en_US
+% !TEX root = paper.tex
 \chapter{Main explanation?}
 
 \section{First definition of the SDG}
@@ -10,6 +10,10 @@ The system dependence graph (SDG) is a method for program slicing that was first
 
 The language covered by the initial proposal was a simple one, featuring procedures with modifiable parameters and basic instructions, including calls to procedures, variable assignments, arithmetic and logic operators and conditional instructions (branches and loops): the basic features of an imperative programming language. The control flow graph was as simple as the programs themselves, with each graph representing one procedure. The instructions of the program are represented as vertices of the graph and are split into two categories: statements, which have no effect on the control flow (assignments, procedure calls) and predicates, whose execution may lead to one of multiple ---though traditionally two--- paths (conditional instructions). Statements are connected sequentially to the next instruction. Predicates have two outgoing edges, each connected to the first statement that should be executed, according to the result of evaluating the conditional expression in the guard of the predicate.
 
+\begin{definition}[Control Flow Graph~\cite{???}]
+	A \emph{control flow graph} $G$ of a program $P$ is a tuple $\langle N, E \rangle$.
+\end{definition}
+
 To build the PDG and then the SDG, some dependencies must be extracted from the CFG, which are defined as follows:
 
 \begin{definition}[Postdominance]
@@ -85,9 +89,9 @@ Therefore, one of the first additions contributed to the algorithm to build syst
 A naive representation would be to treat them the same as any other statement, but with the outgoing edge landing in the corresponding instruction (outside the loop, at the loop condition, at the method's end, etc.).
 An alternative approach is to represent the instruction as an edge, not a vertex, connecting the previous statement with the next to be executed.
 Both of these approaches fail to generate a control dependence from the unconditional jump, as the definition of control dependence (see Definition~\ref{def:ctrl-dep}) requires a vertex to have more than one successor for it to be possible to be a source of control dependence.
-A possible ---but difficult--- solution would be to redefine control dependence, as some\carlos{citation-needed} have done.
+From here, there stem two approaches: the first would be to redefine control dependency, in order to reflect the real effect of these instructions ---as some authors~\cite{DanBHHKL11} have tried to do--- and the second would be to alter the creation of the SDG to ``create'' those dependencies, which is the most widely--used solution.
 
-The most popular solution was proposed by Ball and Horwitz\cite{BalH93}, and represents unconditional jumps as a predicate.
+The most popular approach was proposed by Ball and Horwitz\cite{BalH93}, and represents unconditional jumps as a \textsl{pseudo--predicate}.
 The true edge would lead to the next instruction to be executed, and the false edge would be non-executable or \textit{dummy} edges, connected to the instruction that would be executed were the unconditional jump a \textit{nop}.
 The consequence of this solution is that every instruction placed after the unconditional jump is control dependent on the jump, as can be seen in Figure~\ref{fig:break-graphs}.
 In the example, when slicing with respect to variable $a$ on line 5, every statement would be included, save for ``print(a)''.