This commit is contained in:
parent
ecb9f8ac32
commit
918f3f1a67
1 changed files with 14 additions and 14 deletions
|
@ -141,9 +141,9 @@ dependencies among nodes. Those edges represent various kinds of dependencies
|
|||
---control, data, calls, parameter passing, summary--- which will be defined in
|
||||
section~\ref{sec:first-def-sdg}.
|
||||
|
||||
To create the SDG, first a \textsl{control flow graph} is built for each method
|
||||
To create the SDG, first a \textsl{control flow graph} \added{(CFG)} is built for each method
|
||||
in the program, then its control and data dependencies are computed, resulting
|
||||
in the \textsl{program dependence graph}. Finally, all the graphs from every
|
||||
in the \textsl{program dependence graph} \added{(PDG)}. Finally, all the graphs from every
|
||||
method are joined into the 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}
|
||||
|
@ -170,8 +170,8 @@ lengths in section~\ref{sec:first-def-sdg}.
|
|||
%\end{description}
|
||||
An example is provided in figure~\ref{fig:basic-graphs}, where a simple
|
||||
multiplication program is converted to CFG, then PDG and finally SDG. For
|
||||
simplicity, only the CFG and PDG of \texttt{multiply} are shown. Control
|
||||
dependencies are black, data dependencies red and summary edges blue.
|
||||
simplicity, only the CFG and PDG of \texttt{multiply} are shown \josep{en realidad también está el SDG)} . Control
|
||||
dependencies are black, data dependencies red\added{,} and summary edges blue.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
|
@ -203,12 +203,12 @@ There are four relevant metrics considered when evaluating a slicing algorithm:
|
|||
|
||||
\begin{description}
|
||||
\item[Completeness.] The solution includes all the statements that affect
|
||||
the slice. This is the most important feature, and almost all
|
||||
the \added{slicing criterion}\deleted{slice}. This is the most important feature, and almost all
|
||||
publications 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 don't affect
|
||||
the slice. Most solutions are complete, but the degree of correctness is
|
||||
\item[Correctness.] The solution excludes all statements that \added{do not}\deleted{don't} affect
|
||||
the \added{slicing criterion}\deleted{slice}. Most solutions are complete, but the degree of correctness is
|
||||
what sets them apart, as smaller slices will not execute unnecessary
|
||||
code to compute the values, decreasing the executing time.
|
||||
\item[Features covered.] Which features or language a slicing algorithm
|
||||
|
@ -219,7 +219,7 @@ There are four relevant metrics considered when evaluating a slicing algorithm:
|
|||
language, and as such are less useful for commercial applications, but
|
||||
can be a stepping stone in the betterment of the field.
|
||||
\item[Speed.] Speed of graph generation and slice creation. As previously
|
||||
stated, slicing is a two-step process: build a graph and traverse it.
|
||||
stated, slicing is a two-step process: build\added{ing} a graph and travers\deleted{e}\added{ing} it.
|
||||
The traversal is linear in most proposals, with small variations. Graph
|
||||
generation tends to be longer and with higher variance, but it is not as
|
||||
relevant, because it is only done once (per program being analyzed). As
|
||||
|
@ -236,8 +236,8 @@ variation a different purpose:
|
|||
\item[Backward static.] Used to obtain the lines that affect a statement,
|
||||
normally used on a line which outputs an incorrect value, to narrow down
|
||||
the source of the bug.
|
||||
\item[Forwarde static.] Used to obtain the lines affected by a statement,
|
||||
used to identify dead code, to check the effects a line has in the rest
|
||||
\item[Forward\deleted{e} static.] Used to obtain the lines affected by a statement,
|
||||
used to identify dead code, to check the effects a line has \added{on}\deleted{in} the rest
|
||||
of the program.
|
||||
\item[Chopping static.] Obtains both the statements affected by and the
|
||||
statements that affect the selected statement.
|
||||
|
@ -266,7 +266,7 @@ consists of the following elements:
|
|||
\item[Throwable.] An interface that encompasses all the exceptions or errors
|
||||
that may be thrown. Child classes are \texttt{Exception} for most errors
|
||||
and \texttt{Error} for internal errors in the Java Virtual Machine.
|
||||
Exceptions can be classified in two categories: \textsl{unchecked}
|
||||
Exceptions can be classified in\added{to} two categories: \textsl{unchecked}
|
||||
(those inheriting from \texttt{RuntimeException} or \texttt{Error}) and
|
||||
\textsl{checked} (the rest). The first may be thrown anywhere, whereas
|
||||
the second, if thrown, must be caught or declared in the method header.
|
||||
|
@ -310,7 +310,7 @@ consists of the following elements:
|
|||
|
||||
In almost all programming languages, errors can appear (either through the
|
||||
developer, the user or the system's fault), and must be dealt with. Most of the
|
||||
popular object oriented programs feature some kind of error system, normally
|
||||
popular object\added{-}oriented programs feature some kind of error system, normally
|
||||
very similar to Java's exceptions. In this section, we will perform a small
|
||||
survey of the error-handling techniques used on the most popular programming
|
||||
languages. The language list has been extracted from a survey performed by the
|
||||
|
@ -389,7 +389,7 @@ emulate or replace exception handling:
|
|||
files and environment variables before exiting the program. Traps allow the
|
||||
programmer to react to a user or system--sent signal, or an exit run from
|
||||
within the Bash environment. When a trap is activated, its code run, and the
|
||||
signal doesn't proceed and stop the program. This doesn't replace a fully
|
||||
signal \added{does not}\deleted{doesn't} proceed and stop the program. This \added{does not}\deleted{doesn't} replace a fully
|
||||
featured exception system, but \texttt{bash} programs tend to be small in
|
||||
size, with programmers preferring the efficiency of C or the commodities of
|
||||
other high--level languages when the task requires it.
|
||||
|
@ -404,7 +404,7 @@ emulate or replace exception handling:
|
|||
error. The directive can be set and reset multiple times, therefore creating
|
||||
artificial \texttt{try-catch} blocks, but there is no possibility of
|
||||
attaching a value to the error, lowering its usefulness.
|
||||
\item[C] In C, errors can also be control via return values, but some of the
|
||||
\item[C] In C, errors can also be control\added{led} via return values, but some of the
|
||||
instructions it features can be used to create a simple exception system.
|
||||
\texttt{setjmp} and \texttt{longjmp} are two instructions which set up and
|
||||
perform inter--function jumps. The first makes a snapshot of the call stack
|
||||
|
|
Loading…
Reference in a new issue