Using Program Slicing in Software Maintenance.
Program slicing is applied to the software maintenance problem by extending the notion of a program slice (that originally required both a variable and line number) to a decomposition slice, one that captures all computation on a given variable, i.e., is independent of line numbers. Using the lattice of single variable decomposition slices ordered by set inclusion, it is shown how a slice-based decomposition for programs can be formed. One can then delineate the effects of a proposed change by isolating those effects in a single component of the decomposition. This gives maintainers a straightforward technique for determining those statements and variables which may be modified in a component and those which may not. Using the decomposition, a set of principles to prohibit changes which will interfere with unmodified components is provided. These semantically consistent changes can then be merged back into the original program in linear time.
Introduction
In "Kill that Code!," [32] Gerald Weinberg alludes to his private list of the world's most expensive program
errors. The top three disasters were caused by a change to exactly one line of code: "each one involved
the change of a single digit in a previously correct program." The argument goes that since the change
was to only one line, the usual mechanisms for change control could be circumvented. And, of course, the
results were catastrophic. Weinberg offers a partial explanation: "unexpected linkages," i.e., the value of the
modified variable was used in some other place in the program. The top three of this list of ignominy are
attributed to linkage. More recently, in a special section of the March, 1987 issue of IEEE Transactions on
Software Engineering, Schneidewind [30] notes that one of the reasons that maintenance is difficult is that it
is hard to determine when a code change will affect some other piece of code. We present herein a method
for maintainers to use that addresses this issue.
While some may view software maintenance as a less intellectually demanding activity than development,
the central premise of this work is that software maintenance is more demanding. The added difficulty is due
in large part to the semantic constraints that are placed on the maintainer. These constraints can be loosely
characterized as the attempt to avoid unexpected linkages. Some [4, 14] have addressed this problem by
attempting to eliminate these semantic constraints and then providing the maintainer with a tool that will
pinpoint potential inconsistencies after changes have been implemented. This makes maintenance appear to
be more like development, since the programmer does not need to worry about linkages: once the change is
made, the tool is invoked and the inconsistencies (if any) are located. One would expect that the tool would
proceed to resolve these inconsistencies, but it has been shown that this problem is NP-hard [14]. Thus, the
maintainer can be presented with a problem that is more difficult to resolve that the original change.
We take the opposite view: present the maintainer with a semantically constrained problem and let him
construct the solution that implements the change within these constraints. The semantic context with
which we propose to constrain the maintainer is one that will prohibit linkages into the portions of the code
that the maintainer does not want to change. This approach uncovers potential problems earlier than the
aforementioned methods, and, we believe, is worth any inconvenience that may be encountered due to the
imposition of the constraints.
Our program slicing based techniques give an assessment of the impact of proposed modifications, ease the
problems associated with revalidation and reduce the resources required for maintenance activities. They
work on unstructured programs, so they are usable on older systems. They may be used for white-box,
spare-parts and backbone maintenance without regard to whether the maintenance is corrective, adaptive,
perfective or preventive.
Background
Program slicing, introduced by Weiser, [33, 36] is a technique for restricting the behavior of a program
to some specified subset of interest. A slice S(v; n) (of program P ) on variable v, or set of variables, at
statement n yields the portions of the program that contributed to the value of v just before statement n
is executed. S(v; n) is called a slicing criteria. Slices can be computed automatically on source programs
by analyzing data flow and control flow. A program slice has the added advantage of being an executable
program. Slicing is done implicitly by programmers while debugging [33, 35]; slices can be combined to
isolate sections of code likely to contain program faults and significantly reduce debugging times [23, 24, 25].
There has been a flurry of recent activities where slicing plays a significant role. Horwitz, Reps, et al.
[15, 16, 28] use slices in integrating programs. Their results are built on the seminal work of Ottenstein and
Ottenstein [7, 27] combining slicing with the robust representation afforded by program dependence graphs.
Korel and Laski [20, 21, 22] use slices combined with execution traces for program debugging and testing.
Choi et al. [6] use slices and traces in debugging parallel programs. Reps and Wang [29] have investigated
termination conditions for program slices. Hausler [13] has developed a denotational approach to program
slicing. Gallagher [8] has improved Lyle's [23] algorithm for slicing in the presence of goto's and developed
techniques for capturing arbitrarily placed output statements. We will not discuss slicing techniques in this
paper and instead refer the interested reader to these works.
Since we want to avoid getting bogged down in the details of a particular language, we will identify a
program with its flowgraph. Each node in the graph will correspond to a single source language statement.
define YES 1
else if (inword == NO) f
22 g
26 g

Figure

1: Program to be Sliced
Henceforth, the term statement will mean a node in the flowgraph. Using a common representation scheme
makes the presentation clear, although it is clear that any tool based on these techniques will need to account
for the nuances of the particular language. In this paper, we also ignore problems introduced by having dead
code in the source program, and declare that the programs under consideration will not have any dead code.
See [8] for slicing based techniques to eliminate dead code.

Figures

2-6 illustrate slicing on the program of figure 1, a bare bones version of the Unix utility wc, word
count, taken from [19]. The program counts the number of characters, words, and lines in a text file. It has
been slightly modified to illustrate more clearly the slicing principles. The slices of figures 2-4 are complete
programs that compute a restriction of the specification. The slice on nw (fig. 2) will output the number of
words in a file; the slice on nc (fig. will count the number of characters in the input text file; the slice on
(fig. will count the number of lines in the file.
3 Using Slices for Decomposition
This section presents a method for using slices to obtain a decomposition of the program. Our objective
is to use slicing to decompose a program "directly," into two (or more) components. A program slice
will be one of the components. The construction is a two step process. The first step is to build, for one
variable, a decomposition slice, which is the union of certain slices taken at certain line numbers, on the given
variable. Then the other component of the decomposition, called the "complement," will also be obtained
from the original program. The complement is constructed in such a way that when certain statements of
the decomposition slice are removed from the original program, the program that remains is the slice that
define YES 1
else if (inword == NO) f
22 g
26 g

Figure

2: Slice on (nw,26): Word Counter
22 g
26 g

Figure

3: Slice on (nc,26): Character Counter
22 g
26 g

Figure

4: Slice on (nl,26): Line Counter
else if (inword == NO) f
22 g
26 g

Figure

5: Slice on (inword,26)
22 g
26 g

Figure

Slice on (
1 input a
6 print t

Figure

7: Requires a Decomposition Slice
corresponds to the complement (in a sense to be defined) of the given criteria, with respect to the variables
defined in the program. Thus the complement is also a program slice.
The decomposition slice is used to guide the removal of statements in a systematic fashion to construct
the complement. It is insufficient to merely remove the slice statements from the original program. Since
we require that a slice be executable, there will be certain crucial statements that are necessary in both the
slice and its complement. For example, if we start with the slice of figure 2 and remove all its statements
from the original program, the resulting object will not even compile!
We use this decomposition to break the program into manageable pieces and automatically assist the
maintainer in guaranteeing that there are no ripple effects induced by modifications in a component. We use
the complement to provide a semantic context for modifications in the decomposition slice; the complement
must remain fixed after any change.
The decomposition ideas presented in this section are independent of a particular slicing method. Once a
slice is obtained, by any slicing algorithm, a program decomposition may be computed. Clearly, the quality
of the decomposition will be affected by the quality of the slice, in the sense that more refined slices give a
finer granularity and also deliver more semantic information to the maintainer.
A program slice is dependent on a variable and a statement number. A decomposition slice does not
depend on statement numbers. The motivation for this concept is easily explained using the example of
figure 7. The slice S(t; 4) is statements 1, 2, 3, 4, while the slice S(t; 6) is statements 1, 2, 5, 6. Slicing at
statement last (in this case 6) of a program is insufficient to get all computations involving the slice variable,
t. A decomposition slice captures all relevant computations involving a given variable.
To construct a decomposition slice, we borrow the concept of critical instructions from an algorithm for
dead code elimination as presented in Kennedy [18]. A brief reprise follows. The usual method for dead
code elimination is to first locate all instructions that are useful in some sense. These are declared to be the
critical instructions. Typically, dead code elimination algorithms start by marking output instructions to
be critical. Then the use-definition [18] chains are traced to mark the instructions that impact the output
statements. Any code that is left unmarked is useless to the given computation.
v) be the set of statements in program P that output variable v, let last be the
last statement of P , and let flastg. The statements in
S(v) form the decomposition
slice on v, denoted S(v).
The decomposition slice is the union of a collection of slices, which is still a program slice [36]. We include
statement last so that a variable that is not output may still be used as a decomposition criteria; this will
also capture any defining computation on the decomposition variable after the last statement that displays
its value. To successfully take a slice at statement last, we invoke one of the crucial differences between the
slicing definitions of Reps, with those of Weiser, Lyle and this work. A Reps slice must be taken at a point,
with respect to a variable that is defined or referenced at p. Weiser's slices can be taken at an arbitrary
variable at an arbitrary line number. This difference prohibits Reps' slicing techniques from being applicable
in the current context, since we want to slice on every variable in the program at the last statement.
We now begin to examine the relationship between decomposition slices. Once we have this in place, we
can use the decomposition slices to perform the actual decompositions. To determine the relationships, we
take the decomposition slice for each variable in the program and form a lattice of these decomposition slices,
ordered by set inclusion. It is easier to gain a clear understanding of the relationship between decomposition
slices if we regard them without output statements. This may seem unusual in light of the above definition,
since we used output statements in obtaining relevant computations. We view output statements as windows
into the current state of computation, which do not contribute to the realization of the state. This coincides
with the informal definition of a slice: the statements that yield the portions of the program that contributed
to the value of v just before statement n is executed. Assuming that output statements do not contribute to
the value of a variable precludes from our discussion output statements (and therefore programs) in which
the output values are reused, as is the case with random access files or output to files that are later reopened
for input. Moreover, we are describing a decomposition technique that is not dependent on any particular
slicing technique; we have no way of knowing whether or not the slicing technique includes output statements
or not. We say a slice is output-restricted if all its output statements are removed.
restricted decomposition slices S(v) and S(w) are independent if
It would be a peculiar program that had independent decomposition slices; they would share neither
control flow or data flow. In effect, there would be two programs with non-intersecting computations on
disjoint domains that were merged together. The lattice would have two components. In Ott's slice metric
terminology, [26] independence corresponds to low (coincidental or temporal) cohesion.
Output-restricted decomposition slices that are not independent are said to be (weakly) dependent. Sub-
sequently, when we speak of independence and dependence of slices it will always be in the context of
output-restricted decomposition slices.
Definition 3 Let S(v) and S(w) be output-restricted decomposition slices, w 6= v, and let S(v) ae S(w). S(v)
is said to be strongly dependent on S(w).
Thus output-restricted decomposition slices strongly dependent on independent slices are independent.
The definitions of independence and dependence presented herein are themselves dependent on the notion
of a slice.
The analogous definitions are used by Bergeretti and Carr'e [3] to define slices. In Ott's metric terminology,
[26] strong dependence corresponds to high (sequential or functional) cohesion.
Strong dependence of decomposition slices is a binary relation; in most cases, however, we will not always
need an explicit reference to the containing slice. Henceforth, we will write "S(v) is strongly dependent" as
a shorthand for "S(v) is strongly dependent on some other slice S(w)" when the context permits it.
Definition 4 An output-restricted slice S(v) that is not strongly dependent on any other slice is said to be
maximal.
Maximal decomposition slices are at the "ends" of the lattice. This definition gives the motivation for
output restriction; we do not want to be concerned with the possible effects of output statements on the
maximality of slices or decomposition slices. This can be observed by considering the decomposition slices
on nw and inword, of figures 2 and 5. If we regarded output statements in defining maximal, we could force
the slice on inword to be maximal by the addition of a print statement referencing inword along with the
others at the end of the program. Such a statement would not be collected into the slice on nw. Since this
added statement is not in any other slice, the slice on inword would be maximal and it should not be.

Figure

8 gives the lattice we desire. S(nc), S(nl) and S(nw) are the maximal decomposition slices.
S(inword) is strongly dependent on S(nw); S(c) is strongly dependent on all the other decomposition
slices. The decomposition slices on S(nw), S(nc), and S(nl), figures 2 - 4 they are weakly dependent and
maximal, when the output statements are removed. There are no independent decomposition slices in the
example. Recall that independent decomposition slices cannot share any control flow: the surrounding
control statements would make them dependent.
We now begin to classify the individual statements in decomposition slices.
Definition 5 Let S(v) and S(w) be output-restricted decomposition slices of program P . Statements in
are called slice dependent statements.
S(nc) S(nl) S(nw)
S(inword)
S(c)

Figure

8: Lattice of Decomposition Slices.
Slice independent statements are statements that are not slice dependent. We will refer to slice dependent
statements and slice independent statements as dependent statements and independent statements. Dependent
statements are those contained in decomposition slices that are interior points of the lattice; independent
statements are those in a maximal decomposition slice that are not in the union of the decomposition slices
that are properly contained in the maximal slice. The terms arise from the fact that two or more slices
depend on the computation performed by dependent statements. Independent statements do not contribute
to the computation of any other slice. When modifying a program, dependent statements cannot be changed,
or the effect will ripple out of the focus of interest.
For example, statement 12 of the slice on nc (fig. 3) is a slice independent statement with respect to
any other decomposition slice. Statements 13 and 14 of the slice on nl (fig. are also slice independent
statements with respect to any other decomposition slice. The decomposition slice on c (fig. 6) is strongly
dependent on all the other slices, thus all its statements are slice dependent statements with respect to any
other decomposition slice. Statements 6 and 15-20 of the slice on nw (fig. 2) are slice independent statements
with respect to decomposition slices S(nc), S(nl), and S(c); only statement 19 is slice independent when
compared with S(inword). Statements 6, 15-18 and 20 of the decomposition slice on inword (fig. 5) are
slice independent statements with respect to decomposition slices S(nc), S(nl), and S(c); no statements are
slice independent when compared with S(nw).
We have a relationship between maximal slices and independent statements. This proposition permits
us to apply the terms "(slice) independent statement" and "(slice) dependent statement" in a sensible way
to a particular statement in a given maximal decomposition slice without reference to the binary relation
between decomposition slices that is required in definition 5.
Proposition 1 Let
1. Varset(P) be the set of variables in program P.
2. S(v) be an output-restricted decomposition slice of P.
3. Let
4. Let
The statements in S(v) \Gamma
u2U
are independent.
Proof
umg.
u2U
End.
There is a relationship between the maximal slices and the program. (Recall that dead code has been
excluded from our discussions.)
Proposition maximalg. Then
Proof
then the statements in P that are not in
[m2M S(m) are dead code.
End.
Maximal slices capture the computation performed by the program. Maximal slices and their respective
independent statements also are related:
Proposition 3 An output-restricted decomposition slice is maximal iff it has at least one independent statement

Proof
Suppose S(v) is maximal. By definition S(v) has at least one statement that no other slice has. This
statement is an independent statement.
Now suppose that S(v) has an independent statement, s. Then s is not in any other slice, and the slice
that contains s is maximal.
End.
Conversely, a slice with no independent statements is strongly dependent.
We also have another characterization of strongly dependent slices.
Proposition 4 Let
1. Varset(P) be the set of variables in program P.
2. S(v) be an output-restricted decomposition slice of P.
3. Let strongly dependent on S(w)g
4. Let
5. Let
An output-restricted decomposition slice S(v) is strongly dependent (on some S(d)) iff
u2U
Proof
Suppose S(v) is strongly dependent. We need to show that D has a maximal slice. Partially order D by
set inclusion. Let d be one of the maximal elements of D. The element d is maximal; if it is not, then it is
properly contained in another slice d 1
, which is in D and contains S(v). Then d 2 M, d 6= v, and S(v)
makes no contribution to the union.
Suppose
u2U
makes no contribution to the union. By proposition 3, S(v)
is strongly dependent.
End.
We are now in a position to state the decomposition principles. Given a maximal output-restricted
decomposition slice S(v) of program P, delete the independent and output statements of S from P. We
will denote this program
P (v) and call it the complement of decomposition slice S(v) (with respect to P).
Henceforth, when we speak of complements, it will always be in the context of decomposition slices. The
decomposition slice is the subset of the program that computes a subset of the specification; the complement
computes the rest of the specification.

Figures

9 - 11 give the complements of the slices on nw, nc and nl of figures 4. Using proposition 4
we obtain that the complement of both the slice on inword and the slice on c is the entire program.
22 g
26 g

Figure

9:
(nw). Complement of slice on nw: computes line count and character count
This yields the approximation of a direct sum decomposition of a program that preserves the computational
integrity of the constituent parts. This also indicates that the only useful decompositions are done
with maximal decomposition slices. A complement,
P , of a maximal slice can be further decomposed, so
the decomposition may be continued until all slices with independent statements (i.e. the maximal ones) are
obtained.
In practice, a maintainer may find a strongly dependent slice as a starting point for a proposed change.
Our method will permit such changes. Such a change may be viewed as properly extending the domain of
the partial function that the program computes, while preserving the partial function on its original domain.
4 Application to Modification and Testing
Statement independence can be used to build a set of guidelines for software modification. To do this, we
need to make one more set of definitions regarding variables that appear in independent and dependent
statements. With these definitions we give a set of rules that maintainers must obey in order to make
modifications without ripple effects and unexpected linkages. When these rules are obeyed, we have an
algorithm to merge the modified slice back into the complement and effect a change. The driving motivation
for the following development is: "What restrictions must be placed on modifications in a decomposition
slice so that the complement remains intact?"
Definition 6 A variable that is the target of a dependent assignment statement is called a dependent vari-
able. Alternatively, and equivalently, if all assignments to a variable are in independent statements, then the
variable is called an independent variable.
An assignment statement can be an independent statement while its target is not an independent variable.
In the program of figure 12 the two maximal decomposition slices are S(a) and S(e) (figures 13 and 14). Slice
(figure 15) is strongly dependent on S(a) and S(f) (figure 16) is strongly dependent on S(b) and S(a).
S(d) and S(c) (not shown) are strongly dependent on both maximal slices. In S(a), statements 8, 10, and 11
are independent, by the proposition. But variables a and b are targets of assignment statements 6 and 5,
respectively. So, in the decomposition slice S(a), only variable f is an independent variable.
define YES 1
else if (inword == NO) f
22 g
26 g

Figure

10:
(nc). Complement of slice on nc: computes word count and line count
define YES 1
else if (inword == NO) f
22 g
26 g

Figure

(nl). Complement of slice on nl: computes character count and word count
3 int a, b, c, d, e, f;

Figure

12: Dependent Variable Sample Program
3 int a, b, c, d, e, f;

Figure

13: Slice on a
3 int a, b, c, d, e, f;

Figure

14: Slice on e
3 int a, b, c, d, e, f;

Figure

15: Slice on b
3 int a, b, c, d, e, f;

Figure

16: Slice on f
A similar argument applies for independent control flow statements that reference dependent variables. A
dependent variable in an independent statement corresponds to the situation where the variable in question
is required for the compilation of the complement, but the statement in question does not contribute to the
complement. If a variable is referenced in a dependent statement, it is necessary to the complement and
cannot be independent.
If a decomposing on a single variable yields a strongly dependent slice, we are able to construct a slice
where the original slice variable is an independent variable.
Proposition 5 Let
1. Varset(P) be the set of variables in program P.
2. S(v) be a strongly dependent output restricted decomposition slice of P.
3. Let strongly dependent on S(w)g
4. Let
5. Let
u2U
The variable v is an independent variable in T .
In other words, when S(v) is a strongly dependent slice and T is the union of all the maximal slices upon
which S(v) is strongly dependent, then v is an independent variable in T .
Proof
We show that the complement of T , P - T has no references to v: if variable v is in the complement of T ,
then there is a maximal slice in the complement upon which S(v) is strongly dependent. This contradicts
the hypotheses, so the complement if T has no references to v and the variable v is independent in T .
End.
This can be interpreted as the variable version of proposition 1, that refers to statements.
This has not addressed the problem that is presented when the decomposition slice on variable is maximal,
but the variable itself remains dependent. This is the situation that occurred in the example at the beginning
of the chapter; the slice on variable a (figure 13) is maximal but the variable is dependent. The solution is
straightforward: we construct the slice that is the union of all slices in which the the variable is dependent.
Proposition 6 Let
1. Varset(P) be the set of variables in program P.
2. S(v) be an output restricted decomposition slice of P.
3. is a dependent variable in S(w)g
4. Let
We have two cases:
thus T is empty also) in which case v is an independent variable.
2. E 6= ;, so T is not empty and the variable v is an independent variable in T .
Proof
Case 1:
S(v) contains all references to v. In particular, S(v) contains all assignments to v. So v is an independent
variable in S(v). End Case 1
Case 2:
T contains all references to v. In particular, T contains all assignments to v. So v is an independent
variable in T . End Case 2
End.
This proposition is about variables.
4.1 Modifying Decomposition Slices
We are now in a position to answer the question posed at the beginning of this section. We present the
restrictions as a collection of rules with justifications.
Modifications take three forms: additions, deletions and changes. A change may be viewed as a deletion
followed by an addition. We will use this second approach, and determine only those statements in a
decomposition slice that can be deleted and the forms of statements that can be added. Again, we must rely
on the fact that the union of decomposition slices is a slice, since the complementary criteria will usually
involve more than one maximal variable. We also assume that the maintainer has kept the modified program
compilable and has obtained the decomposition slice of the portion of the software that needs to be changed.
(Locating the code may be a highly nontrivial activity; for the sake of the current discussion, we assume its
completion.)
Since independent statements do not affect data flow or control flow in the complement, we have:
Rule 1 Independent statements may be deleted from a decomposition slice.
Reason:
Independent statements do not affect the computations of the complement. Deleting an independent
statement from a slice will have no impact on the complement.
End.
This result applies to control flow statements and assignment statements. The statement may be deleted
even if it is an assignment statement that targets a dependent variable, or a control statement that references
a dependent variable. The point to keep in mind is that if the statement is independent it does not affect
the complement. If an independent statement is deleted, there will certainly be an effect in the slice. But
the purpose of this methodology is to keep the complement intact.
There are a number of situations to consider when statements are to be added. We progress from simple
to complex. Also note that for additions, new variables may be introduced, as long as the variable name
does not clash with any name in the complement. In this instance the new variable is independent in the
decomposition slice. In the following, independent variable means an independent variable or a new variable.
Rule 2 Assignment statements that target independent variables may be added anywhere in a decomposition
slice.
Independent variables are unknown to the complement. Thus changes to them cannot affect the computations
of the complement.
End.
This type of change is permissible even if the changed value flows into a dependent variable. In figure 13,
changes are permitted to the assignment statement a line 8 , which targets f. A change here would propagate
into the values of dependent variables a and b at lines 10 and 11. The maintainer would then be responsible
for the changes that would occur to these variables. If lines 10 and 11 were dependent, (i.e., contained in
another decomposition slice), line 8 would also be contained in this slice, and variable f would be dependent.
Adding control flow statements requires a little more care. This is required because control statements
have two parts: the logical expression, that determines the flow of control, and the actions taken for each
value of the expression. (We assume no side effects in the evaluation of logical expressions.) We discuss only
the addition of if-then-else and while statements, since all other language constructs can be realized by
them [5].
Rule 3 Logical expressions (and output statements) may be added anywhere in a decomposition slice.
We can inspect the state of the computation anywhere. Evaluation of logical expressions (or the inclusion
of an output statement) will not even affect the computation of the slice. Thus the complement remains
intact.
End.
We must guarantee that the statements that are controlled by newly added control flow do not interfere
with the complement.
Rule 4 New control statements that surround (i.e. control) any dependent statement will cause the complement
to change.
Suppose newly added code controls a dependent statement.
Let C be the criteria that yield the complement. When using this criteria on the modified program,
the newly added control code will be included in this complementary slice. This is due to the fact that the
dependent statements are in both the slice and the complement. Thus any control statements that control
dependent statements will also be in the slice and the complement.
End.
By making such a change, we have violated out principle that the complement remain fixed. Thus new
control statements may not surround any dependent statement.
This short list is necessary and sufficient to keep the slice complement intact. This also has an impact
on testing the change that will be discussed later.
Changes may be required to computations involving a dependent variable, v, in the extracted slice. The
maintainer can choose one of the following two approaches:
1. Use the techniques of the previous section to extend the slice so that v is independent in the slice.
2. Add a new local variable (to the slice), copy the value to the new variable, and manipulate the new
name only. Of course, the new name must not clash with any name in the complement. This technique
may also be used if the slice has no independent statements, i.e., it is strongly dependent.
4.2 Merging the Modifications into the Complement
Merging the modified slice back into the complement is straightforward. A key to understanding the merge
operation comes the the observation that through the technique, the maintainer is editing the entire program.
The method gives a view of the program with the unneeded statements deleted and with the dependent
statements restricted from modification. The slice gives smaller piece of code for the maintainer to focus
on, while the rules of the previous subsection provide the means by which the deleted and restricted parts
cannot be changed accidentally.
We now present the merge algorithm.
1. Order the statements in the original program. (In the following examples, we have one statement per
line so that the ordering is merely the line numbering.) A program slice and its complement can now
be identified with the subsequence of statement numbers from original program. We call the sequence
numbering from the slice, the slice sequence and the numbering of the complement the complement
sequence. We now view the editing process as the addition and deletion of the associated sequence
numbers.
2. For deleted statements, delete the sequence number from the slice sequence. Observe that since only
independent statements are deleted, this number is not in the complement sequence.
3. For statements inserted into the slice a new sequence number needs to be generated. Let P be the
sequence number of the statement preceding the statement to be inserted. Let M be the least value in
the slice sequence greater than P . Let Insert the new statement at sequence
number )=2. (Although this works in principle, in practice, more care needs to be taken in the
generation of the insertion sequence numbers to avoid floating point errors after 10 inserts.)
4. The merged program is obtained by merging the modified slice sequence values (i.e. statements) into
the complement sequence.
Thus, the unchanged dependent statements are used to guide the reconstruction of the modified program.
The placement of the changed statements within a given control flow is arbitrary. Again, this becomes clearer
when the editing process is viewed as modification to the entire program. The following example will help
clarify this.
4.3 Testing the Change
Since the maintainer must restrict all changes to independent or newly created variables testing is reduced
to testing the modified slice. Thus the need for regression testing in the complement is eliminated. There
are two alternative approaches to verifying that only the change needs testing. The first is to slice on the
original criteria plus any new variables minus any eliminated variables. and compare its complement with
the complement of the original: they should match exactly. The second approach is to preserve the criteria
that produced the original complement. Slicing out on this must produce the modified slice exactly.
An axiomatic consideration illumines this idea. The slice and its complement perform a subset of the
computation; where the computations meet are the dependencies. Modifying code in the independent part
of the slice, leaves the independent part of the complement as an invariant of the slice (and vice versa).
If the required change is "merely" a module replacement, the preceding techniques are still applicable.
The slice will provide a harness for the replaced module. A complete independent program supporting the
module is obtained. One of the principle benefits of slicing is highlighted in this context: any side effects of
the module to be replaced will also be in the slice. Thus the full impact of change is brought to the attention
of the modifier.
As an example, we make some changes to S(nw), the slice on nw, the word counter of figure 2. The
changed slice is shown in figure 17. The original program determined a word to be any string of "non-
white" symbols terminated by a "white" symbol (space, tab, or newline). The modification changes this
ch
* if (isspace(c) && isalpha(ch))
ch
22 g
26 g

Figure

17: Modified slice on nw, the word counter
to requirement to be alphabetical characters terminated by white space. (The example is illustrating a
change, not advocating it.) Note the changes. We have deleted the independent "variables" YES and NO;
added a new, totally independent variable ch, and revamped the independent statements. The addition
of the C macros isspace and isalpha is safe, since the results are only referenced. We test this program
independently of the complement.

Figure

shows the reconstructed, modified program. Taking the decomposition slice on nw generates
the program of figure 17. Its complement is already given in figure 9. The starred (*) statements indicate
where the new statements would be placed using the line number generation technique above.
5 A New Software Maintenance Process Model
The usual Software Maintenance Process Model is depicted in figure 19. A request for change arrives. It
may be adaptive, perfective, corrective, or preventive. In making the change, we wish to minimize defects,
effort, and cost, while maximizing customer satisfaction [12]. The software is changed, subject to pending
priorities. The change is composed of two parts. Understanding the code, which may require documentation,
code reading, and execution. Then the program is modified. The maintainer must first design the change
(which may be subject to peer review) then alter the code itself, while trying to minimize side effects. The
change is then validated. The altered code itself is verified to assure conformance with the specification. Then
the new code is integrated with the existing system to insure conformance with the system specifications.
This task involves regression testing.
The new model is depicted in figure 20. The software is changed, subject to pending priorities. The
change is composed of two parts. Understanding the code will now require documentation, code reading,
execution, and the use of decomposition slices. The decomposition slices may be read, and executed (a
decided advantage of having executable program slices). The code is then modified, subject to the strictures
outlined. Using those guidelines, no side effects or unintended linkages can be induced in the code, even by
accident. This lifts a substantial burden from the maintainer.
The change is tested in the decomposition slice. Since the change cannot ripple out into other modules,
regression testing is unnecessary. The maintainer need only verify that change is correct. After applying the
merge algorithm, the change (of the code) is complete.
ch
* if (isspace(c) && isalpha(ch))
ch
22 g
26 g

Figure

Modified Program
6 Future Directions
The underlying method and the tool based on it [9] needs to be empirically evaluated. This is underway
using the Goal-Question-Metric paradigm of Basili, et al [2]. Naturally, we are also addressing questions of
scale, to determine if existing software systems decompose sufficiently via these techniques, in order to effect
a technology transfer. We are also evaluating decomposition slices as candidates for components in a reuse
library.
Although they seem to do well in practice, the slicing algorithms have relatively bad worst case running
times, O(n e log(e)), where n is the number of variables and e is the number of edges in the flowgragh. To
obtain all the slices, this running time becomes O(n 2 e log(e)). These worst case times would seem to make
an interactive slicer for large (i.e., real) programs impractical. This difficulty can be assuaged by making the
data flow analysis one component of the deliverable products that are handed off from the development team
to the maintenance team. An interactive tool could then be built using these products. Then as changes are
made by the maintainers the data flow data can be updated, using the incremental techniques of Keables
[17].
Interprocedural slices can be attacked using the techniques in Weiser [36] and Barth [1]. The interprocedural
slicing algorithms of Horwitz, et al. [16] cannot be used since they require that the slice be taken at a
point where the slice variable id defed or refed; we require that all slices be taken at the last statement of
the program. For separate compilation, worst case assumption must be made about the external variables,
if the source is not available. If the source is available, one proceeds as with procedures.
Berzins [4] has attacked the problem of software merges for extensions of programs. To quote him:
An extension extends the domain of the partial function without altering any of the initially
defined values, while a modification redefines values that were defined initially.
We have addressed the modification problem by first restricting the the domain of the partial function to
the slice complement, modifying the function on the values defined by the independent variables in the slice,
Request
for
Change
Change
Software
Design
Change
Alter
Code
Test
Change
adaptive
perfective
corrective
preventive
minimize defects
minimize effort
minimize cost
maximize satisfaction
documentation
code reading
test runs
minimize side effects
regression
testing
pending
priorities
Integrate
Revalidate

Figure

19: A Software Maintenance Process Model
Request
for
Change
Change
Software
Design
Change
Alter
Component
Test
Change
Merge
adaptive
perfective
corrective
preventive
minimize defects
minimize effort
minimize cost
maximize satisfaction
documentation
code reading
test runs
decomposition slicing
no side effects
no regression
testing
pending
priorities

Figure

20: A New Software Maintenance Process Model
then merging these two disjoint domains.
Horwitz, et al. [15] have addressed the modification problem. They start with a base program and two
modifications it, A and B:
Whenever the changes made to base to create A and B do not "interfere" (in a sense defined
in the paper), the algorithm produces a program M that integrates A and B. The algorithm is
predicated on the assumption that differences in the behavior of the variant programs from that
of base, rather than the differences in text, are significant and must be preserved in M.
Horwitz, et al. do not restrict the changes that can be made to base; thus their algorithm produces an
approximation to the undecidable problem of determining whether or not the behaviors interfere. We have
side-stepped this unsolvable problem by constraining the modifications that are made. Our technique is
more akin to the limits placed on software maintainers. Changes must be done in a context: independence
and dependence provides the context. It is interesting to note, however, that their work uses program slicing
to determine potential interferences in the merge.
They do note that program variants, as they name them, are easily embedded in change control system,
such as RCS [31]. Moreover, the direct sum nature of the components can be exploited to build related
families of software. That is, components can be "summed" as long as their dependent code sections match
exactly and there is no intersection of the independent domains. We also follow this approach for component
construction.
Weiser [34] discusses some slice-based metrics. Overlap is a measure of how many statements in a slice
are found only in that slice, measured as a mean ratio of non-unique to unique statements in each slice.
Parallelism is the number of slices which have few statements in common, computed as number of slices
which have pairwise overlap below a certain threshold. Tightness is the number of statements in every slice,
expressed as a ratio over program length. Programs with high overlap and parallelism, but with low tightness
would decompose nicely: the lattice would not get too deep or too tangled.
We have shown how a data flow technique, program slicing, can be used to form a decomposition for
software systems. The decomposition yields a method for maintainers to use. The maintainer is able to
modify existing code cleanly, in the sense that the changes can be assured to be completely contained in the
modules under consideration and that no unseen linkages with the modified code is infecting other modules.



--R

A practical interprocedural dataflow analysis algorithm.
Experimentation in software engineering.

On merging software extensions.
Flow diagrams and languages with only two formation rules.
Techniques for debugging parallel programs with flowback analysis.
The program dependence graph and its use in optimization.
Using Program Slicing in Software Maintenance.
Surgeon's assistant limits side effects.
Using program decomposition to guide modifications.
A program decomposition scheme with applications to software modification and testing.
Measuring and managing software maintenance.
Denotational program slicing.
Integrating non-interfering versions of programs
Integrating non-interfering versions of programs
Interprocedural slicing using dependence graphs.
Data flow analysis and its application to software maintenance.
A survey of data flow analysis techniques.
The C Programming Language.
Dynamic program slicing.

Data flow testing in stad.
Evaluating Variations of Program Slicing for Debugging.
Experiments on slicing-based debugging aids
Automatic program bug location by program slicing.
The relationship between slices and module cohesion.
The program dependence graph in software development environ- ments

The semantics of program slicing.
The state of software maintenance.
RCS: A system for version control.
Kill that code!
Program Slicing: Formal
Program slicing.
Programmers use slices when debugging.
Program slicing.
--TR
Information-flow and data-flow analysis of while-programs
RCSMYAMPERSANDmdash;a system for version control
The C programming language
Experimentation in software engineering
On merging software extensions
The program dependence graph and its use in optimization
Experiments on slicing-based debugging aids
The state of software maintenance
Dynamic program slicing
Integrating noninterfering versions of programs
Integrating non-intering versions of programs
The relationship between slices and module cohesion
Interprocedural slicing using dependence graphs
Data flow testing in STAD
Using program slicing in software maintenance
Programmers use slices when debugging
A practical interprocedural data flow analysis algorithm
Flow diagrams, turing machines and languages with only two formation rules
Semantics-Based Program Integration
Program slicing
The program dependence graph in a software development environment
Program slices
Evaluating variations on program slicing for debugging (data-flow, ada)

--CTR
M. Samadzadeh , W. Wichaipanitch, An interactive debugging tool for C based on dynamic slicing and dicing, Proceedings of the 1993 ACM conference on Computer science, p.30-37, February 16-18, 1993, Indianapolis, Indiana, United States
Daniel Jackson, Abstract analysis with aspect, ACM SIGSOFT Software Engineering Notes, v.18 n.3, p.19-27, July 1993
Zhang , Jose Emilio Labra Gayo , Agustn Cernuda del Ro, A monadic program slicer, ACM SIGPLAN Notices, v.41 n.5, May 2006
Tomas Vagoun , Alan Hevner, Feasible input domain partitioning in software testing: RCS  case study, Annals of Software Engineering, 4, p.159-170, 1997
Melissa P. Chase , Steven M. Christey , David R. Harris , Alexander S. Yeh, Recovering software architecture from multiple source code analyses, ACM SIGPLAN Notices, v.33 n.7, p.43-50, July 1998
Csaba Farag , Tams Gergely, Handling pointers and unstructured statements in the forward computed dynamic slice algorithm, Acta Cybernetica, v.15 n.4, p.489-508, December 2002
Christian Lindig , Gregor Snelting, Assessing modular structure of legacy code based on mathematical concept analysis, Proceedings of the 19th international conference on Software engineering, p.349-359, May 17-23, 1997, Boston, Massachusetts, United States
Sandrine Blazy , Philippe Facon, Partial evaluation for program comprehension, ACM Computing Surveys (CSUR), v.30 n.3es, Sept. 1998
Jarrett Rosenberg, Problems and Prospects in Quantifying Software Maintainability, Empirical Software Engineering, v.2 n.2, p.173-177, 1997
Hee Beng Kuan Tan , Tok Wang Ling, Correct Program Slicing of Database Operations, IEEE Software, v.15 n.2, p.105-112, March 1998
Ettore Merlo , Pierre-Yves Gagn , Jean-Francois Girard , Kostas Kontogiannis , Laurie Hendren , Prakash Panangaden , Renato De Mori, Reengineering User Interfaces, IEEE Software, v.12 n.1, p.64-73, January 1995
Ramachenga R. Valasareddi , Doris L. Carver, A representation model for procedural program maintenance, Proceedings of the 1999 ACM symposium on Applied computing, p.580-585, February 28-March 02, 1999, San Antonio, Texas, United States
Jianjun Zhao , Hongji Yang , Liming Xiang , Baowen Xu, Change impact analysis to support architectural evolution, Journal of Software Maintenance: Research and Practice, v.14 n.5, p.317-333, September-October 2002
Keith Gallagher , Mark Harman , Sebastin Danicic, Guaranteed inconsistency avoidance during software evolution, Journal of Software Maintenance: Research and Practice, v.15 n.6, p.393-416, November
Mangala Gowri Nanda , S. Ramesh, Slicing concurrent programs, ACM SIGSOFT Software Engineering Notes, v.25 n.5, p.180-190, Sept. 2000
Jingde Cheng, The Task Dependence Net in Ada software development, ACM SIGAda Ada Letters, v.XII n.4, p.24-35, July/Aug. 1992
Daniel Jackson , Eugene J. Rollins, A new model of program dependences for reverse engineering, ACM SIGSOFT Software Engineering Notes, v.19 n.5, p.2-10, Dec. 1994
David Binkley, Precise executable interprocedural slices, ACM Letters on Programming Languages and Systems (LOPLAS), v.2 n.1-4, p.31-45, MarchDec. 1993
Paolo Tonella , Filippo Ricca, Web Application Slicing in Presence of Dynamic Code Generation, Automated Software Engineering, v.12 n.2, p.259-288, April     2005
Jen-Chieh Ou , Daniel G. Saab , Qiang Qiang , Jacob A. Abraham, Reducing verification overhead with RTL slicing, Proceedings of the 17th great lakes symposium on Great lakes symposium on VLSI, March 11-13, 2007, Stresa-Lago Maggiore, Italy
Fangjun Wu , Tong Yi, Slicing Z specifications, ACM SIGPLAN Notices, v.39 n.8, August 2004
Markus Mock , Darren C. Atkinson , Craig Chambers , Susan J. Eggers, Program Slicing with Dynamic Points-To Sets, IEEE Transactions on Software Engineering, v.31 n.8, p.657-678, August 2005
Tibor Gyimthy , rpd Beszdes , Istn Forgcs, An efficient relevant slicing method for debugging, ACM SIGSOFT Software Engineering Notes, v.24 n.6, p.303-321, Nov. 1999
Ettore M. Merlo , Giuliano Antoniol, A static measure of a subset of intra-procedural data flow testing coverage based on node coverage, Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research, p.7, November 08-11, 1999, Mississauga, Ontario, Canada
Xiaoxia Ren , Fenil Shah , Frank Tip , Barbara G. Ryder , Ophelia Chesley, Chianti: a tool for change impact analysis of java programs, ACM SIGPLAN Notices, v.39 n.10, October 2004
Jon Beck , David Eichmann, Program and interface slicing for reverse engineering, Proceedings of the 15th international conference on Software Engineering, p.509-518, May 17-21, 1993, Baltimore, Maryland, United States
Vivekananda M. Vedula , Jacob A. Abraham , Jayanta Bhadra , Raghuram Tupuri, A Hierarchical Test Generation Approach Using Program Slicing Techniques on Hardware Description Languages, Journal of Electronic Testing: Theory and Applications, v.19 n.2, p.149-160, April
Durga P. Mohapatra , Rajeev Kumar , Rajib Mall , D. S. Kumar , Mayank Bhasin, Distributed dynamic slicing of Java programs, Journal of Systems and Software, v.79 n.12, p.1661-1678, December, 2006
Martin P. Robillard, Automatic generation of suggestions for program investigation, ACM SIGSOFT Software Engineering Notes, v.30 n.5, September 2005
Houari A. Sahraoui , Hakim Lounis , Walclio Melo , Hafedh Mili, A Concept Formation Based Approach to Object Identification in Procedural Code, Automated Software Engineering, v.6 n.4, p.387-410, October 1999
Thomas Reps , Genevieve Rosay, Precise interprocedural chopping, ACM SIGSOFT Software Engineering Notes, v.20 n.4, p.41-52, Oct. 1995
Donglin Liang , Mary Jean Harrold, Equivalence analysis and its application in improving the efficiency of program slicing, ACM Transactions on Software Engineering and Methodology (TOSEM), v.11 n.3, p.347-383, July 2002
Bogdan Korel , Satish Yalamanchili, Forward computation of dynamic program slices, Proceedings of the 1994 ACM SIGSOFT international symposium on Software testing and analysis, p.66-79, August 17-19, 1994, Seattle, Washington, United States
Bogdan Korel, Computation of Dynamic Program Slices for Unstructured Programs, IEEE Transactions on Software Engineering, v.23 n.1, p.17-34, January 1997
Rob Law, An overview of debugging tools, ACM SIGSOFT Software Engineering Notes, v.22 n.2, p.43-47, March 1997
Jehad Al Dallal, Using computing-all-slices algorithm in measuring functional cohesion, Proceedings of the 25th conference on IASTED International Multi-Conference: Software Engineering, p.198-203, February 13-15, 2007, Innsbruck, Austria
Jehad Al Dallal, An efficient algorithm for computing all program static slices, Proceedings of the 4th WSEAS International Conference on Software Engineering, Parallel & Distributed Systems, p.1-5, February 13-15, 2005, Salzburg, Austria
Thomas Reps , Susan Horwitz , Mooly Sagiv , Genevieve Rosay, Speeding up slicing, ACM SIGSOFT Software Engineering Notes, v.19 n.5, p.11-20, Dec. 1994
Loren Larsen , Mary Jean Harrold, Slicing object-oriented software, Proceedings of the 18th international conference on Software engineering, p.495-505, March 25-29, 1996, Berlin, Germany
Paolo Tonella , Giuliano Antoniol , Roberto Fiutem , Ettore Merlo, Flow insensitive C++ pointers and polymorphism analysis and its application to slicing, Proceedings of the 19th international conference on Software engineering, p.433-443, May 17-23, 1997, Boston, Massachusetts, United States
Jingde Cheng, Task dependence nets for concurrent systems with Ada 95 and its applications, Proceedings of the conference on TRI-Ada '97, p.67-78, November 09-13, 1997, St. Louis, Missouri, United States
Markus Mock , Darren C. Atkinson , Craig Chambers , Susan J. Eggers, Improving program slicing with dynamic points-to data, ACM SIGSOFT Software Engineering Notes, v.27 n.6, November 2002
Markus Mock , Darren C. Atkinson , Craig Chambers , Susan J. Eggers, Improving program slicing with dynamic points-to data, Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering, November 18-22, 2002, Charleston, South Carolina, USA
Annie T. T. Ying , Gail C. Murphy , Raymond Ng , Mark C. Chu-Carroll, Predicting Source Code Changes by Mining Change History, IEEE Transactions on Software Engineering, v.30 n.9, p.574-586, September 2004
Tun Li , Yang Guo , Si-Kun Li, Automatic circuit extractor for HDL description using program slicing, Journal of Computer Science and Technology, v.19 n.5, p.718-728, September 2004
Hiralal Agrawal, On slicing programs with jump statements, ACM SIGPLAN Notices, v.29 n.6, p.302-312, June 1994
Anthony M. Sloane , Jason Holdsworth, Beyond traditional program slicing, ACM SIGSOFT Software Engineering Notes, v.21 n.3, p.180-186, May 1996
Martin P. Robillard , Gail C. Murphy, Concern graphs: finding and describing concerns using structural program dependencies, Proceedings of the 24th International Conference on Software Engineering, May 19-25, 2002, Orlando, Florida
Mangala Gowri Nanda , S. Ramesh, Interprocedural slicing of multithreaded programs with applications to Java, ACM Transactions on Programming Languages and Systems (TOPLAS), v.28 n.6, p.1088-1144, November 2006
J. M. Bieman , L. M. Ott, Measuring Functional Cohesion, IEEE Transactions on Software Engineering, v.20 n.8, p.644-657, August 1994
Gautier Bastide , Abdelhak Seriai , Mourad Oussalah, Adapting software components by structure fragmentation, Proceedings of the 2006 ACM symposium on Applied computing, April 23-27, 2006, Dijon, France
Ingo Brckner , Bjrn Metzler , Heike Wehrheim, Optimizing slicing of formal specifications by deductive verification, Nordic Journal of Computing, v.13 n.1, p.22-45, June 2006
David Binkley, Semantics Guided Regression Test Cost Reduction, IEEE Transactions on Software Engineering, v.23 n.8, p.498-516, August 1997
Erwan Jahier , Mireille Ducass, Generic program monitoring by trace analysis, Theory and Practice of Logic Programming, v.2 n.4-5, p.611-643, July 2002
John Field , G. Ramalingam , Frank Tip, Parametric program slicing, Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, p.379-392, January 23-25, 1995, San Francisco, California, United States
M. Harman , S. Danicic, Projecting functional models of imperative programs, ACM SIGPLAN Notices, v.28 n.11, p.33-41, Nov. 1993
Jens Krinke, Slicing, Chopping, and Path Conditions with Barriers, Software Quality Control, v.12 n.4, p.339-360, December 2004
Sebastian Danicic , Mark Harman , Rob Hierons , John Howroyd , Michael R. Laurence, Equivalence of linear, free, liberal, structured program schemas is decidable in polynomial time, Theoretical Computer Science, v.373 n.1-2, p.1-18, March, 2007
Hon F. Li , Juergen Rilling , Dhrubajyoti Goswami, Granularity-Driven Dynamic Predicate Slicing Algorithms for Message Passing Systems, Automated Software Engineering, v.11 n.1, p.63-89, January 2004
Ahmed E. Hassan , Richard C. Holt, Replaying development history to assess the effectiveness of change propagation tools, Empirical Software Engineering, v.11 n.3, p.335-367, September 2006
Roberto Giacobazzi , Isabella Mastroeni, Non-Standard Semantics for Program Slicing, Higher-Order and Symbolic Computation, v.16 n.4, p.297-339, December
Z. A. Al-Khanjari , M. R. Woodward , Haider Ali Ramadhan , N. S. Kutti, The Efficiency of Critical Slicing in Fault Localization, Software Quality Control, v.13 n.2, p.129-153, January   2005
Michael R. Laurence , Sebastian Danicic , Mark Harman , Rob Hierons , John Howroyd, Equivalence of conservative, free, linear program schemas is decidable, Theoretical Computer Science, v.290 n.1, p.831-862, 1 January
G. Griswold , David Notkin, Architectural Tradeoffs for a Meaning-Preserving Program Restructuring Tool, IEEE Transactions on Software Engineering, v.21 n.4, p.275-287, April 1995
Filippo Lanubile , Giuseppe Visaggio, Extracting Reusable Functions by Flow Graph-Based Program Slicing, IEEE Transactions on Software Engineering, v.23 n.4, p.246-259, April 1997
Gerardo Canfora , Aniello Cimitile , Ugo de Carlini , Andrea de Lucia, An Extensible System for Source Code Analysis, IEEE Transactions on Software Engineering, v.24 n.9, p.721-740, September 1998
G. B. Mund , Rajib Mall, An efficient interprocedural dynamic slicing method, Journal of Systems and Software, v.79 n.6, p.791-806, June 2006
Sebastian Danicic , Mark Harman, Espresso: a slicer generator, Proceedings of the 2000 ACM symposium on Applied computing, p.831-839, March 2000, Como, Italy
G. Griswold , David Notkin, Automated assistance for program restructuring, ACM Transactions on Software Engineering and Methodology (TOSEM), v.2 n.3, p.228-269, July 1993
Thomas W. Reps , Louis B. Rall, Computational Divided Differencing and Divided-Difference Arithmetics, Higher-Order and Symbolic Computation, v.16 n.1-2, p.93-149, March-June
Dave Binkley , Sebastian Danicic , Tibor Gyimthy , Mark Harman , kos Kiss , Bogdan Korel, Theoretical foundations of dynamic program slicing, Theoretical Computer Science, v.360 n.1, p.23-41, 21 August 2006
S. Ducasse , S. Tichelaar, Dimensions of reengineering environment infrastructures, Journal of Software Maintenance: Research and Practice, v.15 n.5, p.345-373, September-October
Ramkrishna Chatterjee , Barbara G. Ryder , William A. Landi, Complexity of Points-To Analysis of Java in the Presence of Exceptions, IEEE Transactions on Software Engineering, v.27 n.6, p.481-512, June 2001
Mark Harman , David Binkley , Sebastian Danicic, Amorphous program slicing, Journal of Systems and Software, v.68 n.1, p.45-64, 15 October
Sebastian Danicic , Mohammed Daoudi , Chris Fox , Mark Harman , Robert M. Hierons , John R. Howroyd , Lahcen Ourabya , Martin Ward, ConSUS: a light-weight program conditioner, Journal of Systems and Software, v.77 n.3, p.241-262, September 2005
Dave Binkley , Sebastian Danicic , Tibor Gyimthy , Mark Harman , kos Kiss , Bogdan Korel, A formalisation of the relationship between forms of program slicing, Science of Computer Programming, v.62 n.3, p.228-252, 15 October 2006
J. Hagemeister , B. Lowther , P. Oman , X. Yu , W. Zhu, An annotated bibliography on software maintenance, ACM SIGSOFT Software Engineering Notes, v.17 n.2, p.79-84, April 1992
M. G. J. van den Brand , P. Klint , C. Verhoef, Reverse engineering and system renovationan annotated bibliography, ACM SIGSOFT Software Engineering Notes, v.22 n.1, p.57-68, Jan. 1997
David Binkley , Nicolas Gold , Mark Harman, An empirical study of static program slice size, ACM Transactions on Software Engineering and Methodology (TOSEM), v.16 n.2, p.8-es, April 2007
Barbara G. Ryder , William A. Landi , Philip A. Stocks , Sean Zhang , Rita Altucher, A schema for interprocedural modification side-effect analysis with pointer aliasing, ACM Transactions on Programming Languages and Systems (TOPLAS), v.23 n.2, p.105-186, March 2001
David Binkley, Source Code Analysis: A Road Map, 2007 Future of Software Engineering, p.104-119, May 23-25, 2007
C. Verhoef, Towards automated modification of legacy assets, Annals of Software Engineering, v.9 n.1-4, p.315-336, 2000
Hafedh Mili , Fatma Mili , Ali Mili, Reusing Software: Issues and Research Directions, IEEE Transactions on Software Engineering, v.21 n.6, p.528-562, June 1995
Baowen Xu , Ju Qian , Xiaofang Zhang , Zhongqiang Wu , Lin Chen, A brief survey of program slicing, ACM SIGSOFT Software Engineering Notes, v.30 n.2, March 2005
set inclusion;linear time;program testing;software maintenance;line number;software maintenance problem;semantically consistent changes;program slice;program slicing;slice-based decomposition;single variable decomposition slices;unmodified components