This commit is contained in:
parent
eaad61965e
commit
59722faa7b
1 changed files with 22 additions and 19 deletions
|
@ -46,7 +46,7 @@ affect the value of a variable in a given statement, in all possible executions
|
|||
of the program (i.e., for any input data).
|
||||
\begin{definition}[Strong static backward slice \cite{Wei81,HorwitzRB88}]
|
||||
\label{def:strong-slice}
|
||||
\carlos{One of the citations is the correct one.}
|
||||
\carlos{One of the citations is the correct one.}\josep{la de Weiser}
|
||||
Given a program $P$ and a slicing criterion $C = \langle s,v \rangle$, where
|
||||
$s$ is a statement and $v$ is a set\sergio{los set no se representan con letras mayusculas?} of variables in $P$ (the variables may
|
||||
or may not be used in $s$), $S$ is the \textsl{strong slice} of $P$ with
|
||||
|
@ -60,10 +60,12 @@ of the program (i.e., for any input data).
|
|||
\end{enumerate}
|
||||
\end{definition}
|
||||
\sergio{Esta definicion no obligaba tambien a acabar con el mismo error en caso de que la ejecucion no termine? Si es asi, plantearse poner algo al respecto.}
|
||||
\josep{hay que revisar la definición de (1) Weiser, (2) Binkley y Gallagher y (3) Frank Tip. Mi opinion es que NO: Creo que no es necesario que el error se repita. Lo que dice es que el valor de las variables del SC debe ser el mismo, pero no dice nada del error.}
|
||||
|
||||
\begin{definition}[Weak static backward slice \cite{RepY89}]
|
||||
\label{def:weak-slice}
|
||||
\carlos{Check citation and improve ``formalization''?}
|
||||
\josep{Si esa cita no es, entonces puedes usar la de Binkley: \url{https://cgi.csc.liv.ac.uk/~coopes/comp319/2016/papers/ProgramSlicing-Binkley+Gallagher.pdf}}
|
||||
Given a program $P$ and a slicing criterion $C = \langle s,v \rangle$, where
|
||||
$s$ is a statement and $v$ is a set of variables in $P$ (the variables may
|
||||
or may not be used in $s$), $S$ is the \textsl{weak slice} of $P$ with
|
||||
|
@ -80,14 +82,15 @@ of the program (i.e., for any input data).
|
|||
\end{definition}
|
||||
|
||||
\sergio{$\forall~i~\in~I, v\in~V~\rightarrow~seq(i,v,P)~Pref~seq(i,v,S)$ where $seq(i,a,A)$ representa la secuencia de valores obtenidos para $a$ al ejecutar el input $i$ en el programa $A$. $I$ es el conjunto de todos los inputs posibles para $P$. Por ahi irian los tiros creo yo.}
|
||||
\josep{Si se formaliza con el uso de seq, entonces puedes mirar la definicion del paper de POI testing (Sergio sabe cual es).}
|
||||
|
||||
Both definitions (\ref{def:strong-slice} and~\ref{def:weak-slice}) are
|
||||
used throughout the literature (see, e.g., \cite{pending}\carlos{Which citation? Most papers on exception slicing do not indicate or hint whether they use strong or weak.}\sergio{Josep?}), with some cases \deleted{favoring}\added{favouring} the first and some the
|
||||
used throughout the literature (see, e.g., \cite{pending}\carlos{Which citation? Most papers on exception slicing do not indicate or hint whether they use strong or weak.}\sergio{Josep?}\josep{para Strong se puede poner a Weiser. Para Weak se puede poner a Binkley \url{https://cgi.csc.liv.ac.uk/~coopes/comp319/2016/papers/ProgramSlicing-Binkley+Gallagher.pdf}}), \josep{este final de frase lo quitaria:}with some cases \deleted{favoring}\added{favouring} the first and some the
|
||||
second. Though the definitions come from the corresponding citations, the naming
|
||||
was first used in a control dependency analysis by Danicic~\cite{DanBHHKL11},
|
||||
where slices that produce the same output as the original are named
|
||||
\textsl{strong}, and those where the original is a prefix of the slice,
|
||||
\textsl{weak}. Weak slicing tends to be preferred ---specially for debugging--- for two reasons: the algorithm can be simpler and avoid dealing with termination, and the slices can be smaller, narrowing the focus of the debugger. For some applications, \deleted{strong slices are preferred,} such as extracting a feature from a program, where there is a requirement that the resulting slice behave exactly like the original\added{, strong slices are preferred}. In this paper\sergio{??} we will indicate which kind of slice is produced with each new technique proposed. \sergio{Generamos alguna vez strong? Joder que cracks somos xD}
|
||||
\textsl{weak}. Weak slicing tends to be preferred ---specially for debugging--- for two reasons: the algorithm can be simpler and avoid dealing with termination \josep{termination no esta contemplada ni en weak ni en strong. Mas bien di que en debugging lo que importa es que el error se produzca. En general da igual cuantas veces se produzca o que se siga produciendo despues.}, and the slices can be smaller, narrowing the focus of the debugger. For some applications, \deleted{strong slices are preferred,} such as extracting a \josep{component or a specialized program}feature from a program, where there is a requirement that the resulting slice behave\josep{s} exactly like\josep{as} the original\added{, strong slices are preferred\josep{esto queda muy lejos ya. Yo partiria la frase en dos}}. In this paper we will \josep{Along the thesis, we indicate} indicate which kind of slice is produced with each new technique proposed. \sergio{Generamos alguna vez strong? Joder que cracks somos xD}
|
||||
|
||||
\begin{example}[Strong, weak and incorrect slices]
|
||||
\carlos{The table is labeled execution logs of... but the execution log is a different thing.}
|
||||
|
@ -98,7 +101,7 @@ where slices that produce the same output as the original are named
|
|||
Slice A's \deleted{execution log}\added{generated sequence of values} is identical to the original and therefore it is a strong slice.
|
||||
Slice B is a weak slice: its execution correctly produces the same \added{sequence of }values as the original program, but it continues producing values after the original stops.
|
||||
Slice C is incorrect, as the \added{generated sequence of} values differ\added{s} from the \added{sequence generated by the }original \added{program}.
|
||||
\sergio{Taking a closer look, one could think that }Some data or control dependency has not been included in the slice and the program produce different results, in this case the slice computes Fibonacci numbers instead of factorials.\sergio{Esto no parece muy relevante, plantearse quitarlo para no liar con Fibonacci.}
|
||||
\sergio{Taking a closer look, one could think that }Some data or control dependency has not been included in the slice \josep{lo que sigue quitarlo. Lia...}and the program produce\josep{s} different results, in this case the slice computes Fibonacci numbers instead of factorials.\sergio{Esto no parece muy relevante, plantearse quitarlo para no liar con Fibonacci.}
|
||||
\end{example}
|
||||
|
||||
\begin{table}
|
||||
|
@ -115,25 +118,25 @@ where slices that produce the same output as the original are named
|
|||
\end{table}
|
||||
|
||||
|
||||
Program slicing is a language--agnostic tool\sergio{program slicing es tool o technique?}, but the original proposal by
|
||||
\josep{Even though the original proposal by Weiser~\cite{Wei81} focussed on an imperative language, program slicing is a language--agnostic technique.} Program slicing is a language--agnostic tool\sergio{program slicing es tool o technique?}, but the original proposal by
|
||||
Weiser~\cite{Wei81} covered a simple imperative programming language.
|
||||
Since then, the literature has been expanded by dozens of authors, that have
|
||||
described and implemented slicing for more complex structures, such as
|
||||
uncontrolled control flow~\cite{HorwitzRB88}, global variables~\cite{???},
|
||||
exception handling~\cite{AllH03}; and for other programming paradigms, such as
|
||||
object--oriented languages~\cite{???} or functional languages~\cite{???}.
|
||||
\carlos{Se pueden poner más, faltan las citas correspondientes.}\sergio{Guay, hay que buscarlas y ponerlas, la biblio la veo corta para todos los papers que hay, yo creo que cuando este todo deberia haber sobre 30 casi, si no mas.}
|
||||
\carlos{Se pueden poner más, faltan las citas correspondientes.}\sergio{Guay, hay que buscarlas y ponerlas, la biblio la veo corta para todos los papers que hay, yo creo que cuando este todo deberia haber sobre 30 casi, si no mas.} \josep{Si. Muchas de esas referencias puedes sacarlas de los ultimos surveys de slicing. }
|
||||
|
||||
\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
|
||||
slicing criterion, but the most efficient and broadly used data structure is the System
|
||||
Dependence Graph (SDG), first introduced by Horwitz, Reps 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
|
||||
once built, a slicing criterion is chosen, the graph \added{is} traversed using a specific
|
||||
algorithm, and the slice \added{is} obtained. Its efficiency resides in the fact that\added{,} for
|
||||
once built, a slicing criterion is chosen \josep{and mapped on the graph, then} , the graph \added{is} traversed using a specific
|
||||
algorithm, and the slice \added{is} obtained. Its efficiency resides\josep{relies? on} in the fact that\added{,} for
|
||||
multiple slices \deleted{that share}\added{calculated for} the same program, the graph \deleted{must only be built}\added{generation process is only performed} once.
|
||||
On top of that, building the graph has a complexity of $\mathcal{O}(n^2)$ \carlos{uso $\mathcal{O}$ o $O$?}\sergio{Josep?} with
|
||||
On top of that, building the graph has a complexity of $\mathcal{O}(n^2)$ \carlos{uso $\mathcal{O}$ o $O$?}\sergio{Josep?\josep{$\mathcal{O}$}} with
|
||||
respect to the number of statements in \deleted{a}\added{the} program, but the traversal is linear
|
||||
with respect to the number of nodes in the graph (each corresponding to a
|
||||
statement) \sergio{footnote?}.
|
||||
|
@ -142,12 +145,12 @@ The SDG is a directed graph, and as such it has vertices or nodes, each
|
|||
representing an \deleted{instruction}\added{statement} in the program ---barring some auxiliary nodes
|
||||
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 will be defined\sergio{further explained?} in
|
||||
---control, data, calls, parameter passing, summary--- which\josep{that are defined} will be defined\sergio{further explained?} in
|
||||
section~\ref{sec:first-def-sdg}.
|
||||
|
||||
To create the SDG, first \deleted{a}\added{the corresponding} \textsl{control flow graph} (CFG) is built for each method
|
||||
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??}. Finally, all the graphs from every
|
||||
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
|
||||
lengths in section~\ref{sec:first-def-sdg}.
|
||||
%TODO: marked for removal --- this process is repeated later in ref{sec:first-deg-sdg}
|
||||
|
@ -173,8 +176,8 @@ lengths in section~\ref{sec:first-def-sdg}.
|
|||
%summarize the data dependencies between input and output variables.
|
||||
%\end{description}
|
||||
An example \added{of how an initial CFG is augmented and enhanced with all mentioned dependencies obtaining the corresponding PDG and the final SDG} is provided in figure~\ref{fig:basic-graphs}, where a \added{the process is illustrated for a} simple
|
||||
multiplication program\deleted{ is converted to CFG, then PDG and finally SDG}. For
|
||||
simplicity, only the CFG and PDG of \texttt{main} are omitted\sergio{no entiendo esto de main. Donde esta main?}. Control
|
||||
multiplication program\josep{pon el codigo del programa. asi pueden entender de que va esto los que no sepan de slicing. Sin el programa lo tienen mas complicado... Acabo de ver que ya esta el codigo. Entonces referencialo, presentalo: Consider the multiplication program in Figure X. The standard CFG and PDG generated for this code are... bla bla bla }\deleted{ is converted to CFG, then PDG and finally SDG}. For
|
||||
simplicity, \josep{quita el only}only the CFG and PDG of \texttt{main} are omitted\sergio{no entiendo esto de main. Donde esta main?}. Control
|
||||
dependencies are \added{represented with }black \added{arcs}, data dependencies \added{with} red \added{arcs}, and summary edges \added{are depicted with }blue \added{arcs}.
|
||||
|
||||
\begin{figure}
|
||||
|
@ -206,7 +209,7 @@ dependencies are \added{represented with }black \added{arcs}, data dependencies
|
|||
\sergio{Metrics o slicing indicators/features? }
|
||||
|
||||
|
||||
There are four relevant metrics considered when evaluating a slicing algorithm:
|
||||
\josep{The main four metrics used to assess a program slicing algorithm are:}There are four relevant metrics considered when evaluating a slicing algorithm:
|
||||
\sergio{Se me hace muy escueto esto, yo meteria algo de bullshit como dice Tama.}
|
||||
|
||||
\sergio{PROPOSAL:}
|
||||
|
@ -216,13 +219,13 @@ There are four relevant metrics considered when evaluating a slicing algorithm:
|
|||
\begin{description}
|
||||
\item[Completeness.] The solution includes all the statements that affect
|
||||
the slicing criterion. This is the most important feature, and almost all
|
||||
publications achieve at least completeness. Trivial completeness is
|
||||
publications\josep{techniques and implemented tools} achieve at least completeness. Trivial completeness is
|
||||
easily achievable, as simple as including the whole program in the
|
||||
slice.
|
||||
\item[Correctness.] The solution excludes all statements that do not affect
|
||||
the slicing criterion. Most solutions are complete, but the degree of correctness is
|
||||
what sets them apart, as solutions that are more correct will produce smaller slices, which will execute fewer instructions to compute the same values, decreasing the executing time and complexity.
|
||||
\item[Features covered.] Which features or language a slicing algorithm
|
||||
\item[Features covered.] Which features \josep{(polymorphism, global variables, arrays, etc.)} or language a slicing algorithm
|
||||
covers. Different approaches to slicing cover different programming
|
||||
languages and even paradigms. There are slicing techniques (published or
|
||||
commercially available) for most popular programming languages, from C++
|
||||
|
|
Loading…
Reference in a new issue