PROPERTY DRIVEN PROGRAM SLICING REFINEMENT
Sukriti Bhattacharya and Agostino Cortesi
Ca’ Foscari University of Venice, Via Torino 155, 30170 Venezia, Italy
Keywords:
Abstract Interpretation, Program slicing, Semantics, Static analysis.
Abstract:
A slice is usually computed by analyzing how the effects of a computation are propagated through the code,
i.e., by inferring dependencies. The aim of this paper is to further refine the traditional slicing technique by
combining it with a static analysis in Abstract Interpretation based framework. This results into a deeper
insight on the strong relation between slicing and property based dependency.
1 INTRODUCTION
Program slicing is the study of meaningful subpro-
grams. Typically applied to the code of an existing
program, a slicing algorithm is responsible for pro-
ducing a program (or subprogram) that preserves a
subset of the original programs behavior. A specifica-
tion of that subset is known as a slicing criterion, and
the resulting subprogram is a slice. Generally speak-
ing, by applying a slicing technique on a program P
with a slicing criterion C (i.e. a line of code in P), we
get a program P
′
that behaves like P when focussing
only on the variables in C. The sliced program P
′
is
obtained through backward computation from P by
removing all the statements that do not affect neither
directly nor indirectly the values of the variables in C.
Very often, we are interested on a specific property
of the variables in the slicing criterion, not on their
exact actual values.
In this direction (Bhattacharya, 2011), our aim
is to further refine the traditional slicing technique,
(Weiser, 1984) by combining it with a static analysis
in Abstract Interpretation (Cousot and Cousot, 1977)
based framework that looks for the statements affect-
ing a fixed property of variables of interest rather than
values. This results into a deeper insight on the strong
relation between slicing and property based depen-
dency (Mastroeni and Zanardini, 2008) (Mastroeni
et al., 2010) (Cortesi and Halder, 2010).
The resulting proposal is a fixed point computa-
tion where each iterate has two phases. First, the con-
trol flow analysis is combined with a static analysis
in a Abstract Interpretation based framework. Hence,
each program point of the program is enhanced with
information about the abstract state of variables with
respect to the property of interest. Then, a backward
program slicing technique is applied to the augmented
program exploiting the abstract dependencies.
2 ABSTRACT SEMANTICS
The essential issue in program slicing is to define
what semantic relationship must exist between a pro-
gram and its slice in order that the slice is consid-
ered valid. Mark Weiser (Weiser, 1984) defined the
semantic relationship that must exist between a pro-
gram and its slice in terms of state trajectories. In this
section we provide the abstract semantics of the tra-
jectories. We consider the WHILE language for our
discussion (Nielson et al., 1999). The set of concrete
states Σ consists of functions σ : V → V which maps
the variables to their values from the semantic domain
Z
⊥
where, ⊥ represents an undefined or uninitialized
value and Z is the set of integers. If a program has k
variables x
1
,...,x
k
, we can represent states as tuples,
i.e., σ = hx
1
,...,x
k
i and Σ = V
k
.
The semantics of arithmetic expression a ∈ AExp
over the state σ is denoted by E [[a]]σ where, the func-
tion E is of the type AExp → (σ → V ). Similarly,
B [[b]]σ denotes the semantics of boolean expression
b ∈ BExp over the state σ of type BExp → (σ → T)
where T is the set of truth values.
D be an abstract domain on concrete values and
α and γ are abstraction and concretization functions,
respectively. The related abstract semantics on ex-
pressions , H [[a]]ϕ, is applied to abstract states ϕ =
hd
1
,...,d
k
i ∈ D
k
and is defined as the best correct ap-
proximation of E [[a]]σ as depicted in Table 1.
In Table 1 dop
a
is the abstract operation in D that
149
Bhattacharya S. and Cortesi A..
PROPERTY DRIVEN PROGRAM SLICING REFINEMENT.
DOI: 10.5220/0003490101490155
In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 149-155
ISBN: 978-989-8425-77-5
Copyright
c
 2011 SCITEPRESS (Science and Technology Publications, Lda.)

Table 1: Approximation of arithmetic expressions.
H [[a]]ϕ=



d
i
if a = x
i
∈ Var
α(n) if a = n ∈ Num
H [[a
1
]]ϕ dop
a
H [[a
2
]]ϕ if a = a
1
op
a
a
2
safely approximate op
a
, when we construct the ab-
stract semantics of programs, we need to define ab-
stract operations over the abstract domain, that ap-
proximate the corresponding concrete operations over
the concrete domain. The idea is that the abstract cal-
culation simulates the concrete calculation, and the
concretization of the abstract calculation is a correct
approximation of the values in the concrete result.
For example consider the following code fragment
in Figure 1 and consider the abstract domain where
the addition and multiplication are influenced accord-
ing to the well known rule of signs
1. x=2;
2. y=-5;
3. z = (x+3)*y;
Figure 1: Sample code fragment.
The sign of the variable z can be computed in the
abstract domain of Sign by,
H [[x+ 3∗ y]]ϕ = (H [[x]]ϕ
b
+ H [[3]]ϕ) ∗ H [[y]]ϕ
= (+
b
+ α(3))
b
∗ −
= (+
b
+ +)
b
∗ −
= +
b
+ −
= −
The abstract semantics H
b
[[b]]ϕ of boolean ex-
pression b is defined as the best correct approxima-
tion of B [[b]]σ in Table 2, where cop
r
: D × D →
{TRUE,FALSE,?} is the abstract operation that safely
approximate op
r
and ? (undefined) signifies that, the
abstract domain is not accurate enough to evaluate the
condition. For instance, abstract operations
b
< on Sign
domain is depicted in Table 3,
Table 2: Approximation of boolean expressions.
H
b
[[b]]ϕ=































TRUE if b = TRUE
OR
b = a
1
op
r
a
2
AND
H [[a
1
]]ϕ dop
r
H [[a
2
]]ϕ = TRUE
FALSE if b = FALSE
OR
b = a
1
op
r
a
2
AND
H [[a
1
]]ϕ dop
r
H [[a
2
]]ϕ = FALSE
? undefined otherwise
Table 3: Abstracting < operator.
b
<
⊤ ⊥ + 0 −
⊤ ? ? ? ? ?
⊥ ? ? ? ? ?
+ ? ? ? FALSE FALSE
0 ? ? TRUE ? FALSE
− ? ? TRUE TRUE ?
3 ABSTRACT TRAJECTORY
We now define the abstract trajectory semantics for
WHILE.
 For skip statement:
τ
D
[[l : skip]]ϕ = h(l,ϕ)i
h(l, ϕ)i represents the singleton sequence consist-
ing of the pair (l,ϕ). i.e statement level alone with
the properties of the variables.
 For assignment statement:
τ
D
[[l : x = a]]ϕ = (l,ϕ[x ← H [[a]]ϕ])
Where H [[a]]ϕ means the new value resulting
from evaluating expression a in abstract domain
and ϕ[x ← H [[a]]ϕ] is the abstract state ϕ updated
with the maplet that takes variable x to this new
abstract value.
 For sequences of statements: τ
D
[[l : S
1
;S
2
]]ϕ =
τ[[S
1
]]ϕ ⋄ τ
D
[[S
2
]]ϕ
′
Where ϕ
′
is the abstract state obtained after exe-
cuting S
1
in ϕ and ⋄ means concatenation.
 For if statement:
τ
D
[[l : if b then S
1
else S
2
]]ϕ = h(l,ϕ)i ⋄







⊥ if H
b
[[b]]ϕ =?
τ
D
[[S
1
]] if H
b
[[b]]ϕ = TRUE
τ
D
[[S
2
]] if H
b
[[b]]ϕ = FALSE
(τ
D
[[S
1
]]ϕ) ⊔ (τ
D
[[S
2
]]ϕ) otherwise
The first element is the label of the if in the cur-
rent abstract state. The rest of the trajectory is the
trajectory of one of the branches depending on the
abstract execution of the boolean expression eval-
uated in the current abstract state.
 For while statement:
τ
D
[[l : while b then S]]ϕ =



λ if H
b
[[b]]ϕ = FALSE
hl
i
,⊔
i≥0
(ϕ
i
)i otherwise
If the predicate b evaluated to be FALSE
there would be a empty trajectory at l other wise
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
150

a fixpont iteration on the abstract state of each
statements with in the loop body where ϕ
0
= ϕ
and ϕ
i+1
= τ
D
[[S]]ϕ
i
Definition 1. (Restriction of a state to a set of vari-
ables w.r.t a given property) Given a abstract state, ϕ
with respect to a property, ρ and a set of variables,
V ∈ Var, ϕ|
ρ
V
restricts ϕ so that it is defined by ρ only
for variables in V .
Definition 2. (Projection of a abstract trajectory to
a slicing criterion w.r.t a given property) For a pro-
gram point p
′
and a abstract state ϕ, the projection of
the abstract trajectory sequence element (p
′
,ϕ) to the
slicing criterion (p,V) w.r.t property ρ is
(p
′
,ϕ)|
ρ
(p,V)
=

(p
′
,ϕ|
ρ
V
) if p
′
= p
λ otherwise
where λ denotes the empty string.
The projection of the abstract trajectory τ
D
to the
slicing criterion (p,V) w.r.t a property ρ is
Proj
(p,V)
(τ
D
) =
h(p
0
,ϕ
0
)|
ρ
(p,V)
,(p
1
,ϕ
1
)|
ρ
(p,V)
,...,(p
k
,ϕ
k
)|
ρ
(p,V)
i
Definition 3. (Property driven program slicing) A
property driven slice P
ρ
of a program P on a slicing
criterion (p,V) and with respect to a given property
ρ is any executable program with the following two
properties:
 P
′
can be obtained from P by deleting zero or
more statements.
 Whenever P halts on an input state ϕ with a
abstract trajectory τ
D
then P
′
also halts on ϕ with
trajectory τ
D
′
where,
Red(Proj
(p,V)
(τ
D
)) = Red(Proj
(p,V)
(τ
D
′
)).
Where Red is defined in Table 4, given a abstract
trajectory τ
D
= h(p
0
,ϕ
0
),(p
1
,ϕ
1
),...,(p
k
,ϕ
k
)i
Red is obtained by applying the following reduc-
tion algorithm,
Table 4: Red.
begin
i=0;
while(i < n){
j=1;
while(p
i+ j
= p
i
) && (ϕ
i+ j
= ϕ
i
)
remove (p
i+ j
, ϕ
j
) from the trajectory
i=i+j;
}
Table 5: Property driven slicing on Sign.
St.No. Original Program Sliced Program
1 x = 5; x = 5;
2 y = 3; y = 3;
3 z = y− x; z = y− x;
4 if(x > z){ if(x > z)
5 y = x+ z
2
;
6 w = y ∗ z;} w = y∗ z;
7 else{
8 y = x
2
+ z;
9 w = y ∗ z;}
10 print f(”%d”, w); print f(”%d”, w);
Consider Table 5 for an illustration of the above
definitions,
The abstract state trajectory of program P with
respect to Sign property is denoted as τ
Sign
and the
abstract state trajectory of the sliced program P
Sign
with respect to the property Sign on slicing criteria
C = (10,w) is denoted as τ
Sign
′
.
τ
Sign
= h(1,{⊥,⊥,⊥,⊥}), (2,{⊥,+,⊥,⊥}), (3,{⊥,+,−, ⊥}),
(4,{⊥,+,−,−}), (5,{⊥,+, −,−}), (6,{−,+,+,−}),
(10,{−,+,+,−})i
τ
Sign
′
= h(1,{⊥,⊥,⊥,⊥}), (2,{⊥,+,⊥,⊥}), (3,{⊥,+,−, ⊥}),
(5,{⊥,+,−,−}), (6,{⊥,+,+,−}), (10,{−,+,+,−})i
Notice that,
Red(Proj
(10,w)
(τ
Sign
)) = Red(Proj
(10,w)
(τ
Sign
′
))
4 DATAFLOW BASED PROPERTY
DRIVEN PROGRAM SLICING
This notion of dependencies often loses some infor-
mation, because syntactic occurrence is not enough
to get the real idea of relevancy. For instance (Mas-
troeni and Zanardini, 2008), the value assigned to x
does not depend on y in the statement x = z + y − y,
although y occurs in the expression. The syntactic ap-
proach may fail in computing the optimal set of de-
pendencies, since it is not able to rule out this kind of
false dependencies. This results in obtaining a slice
which contains more statements than needed.The first
step towards a generalization of the way of defining
slicing is to consider semantic dependencies, where
intuitively a variable is relevant for an expression if it
is relevant for its evaluation.
Definition 4. (Semantic dependency) Let x,y ∈ Var,
then the semantic dependency between the expression
e and variable x is defined formally as,
∃σ
1
,σ
2
∈ Σ.∀y 6= x.σ
1
(y) = σ
2
(y) ∧
E [[e]]σ
1
6= E [[e]]σ
2
.
This semantic notion can then easily generalized
PROPERTY DRIVEN PROGRAM SLICING REFINEMENT
151

in what we will call abstract dependency, where a
variable is relevant to an expression if it affects a
given property of its evaluation. More precisely, This
notion of dependency is parametric on the properties
of interest. Basically, an expression e depends on a
variable x w.r.t. a property ρ if changing x, and keep-
ing all other variables unchanged with respect to ρ,
may lead to a change in e with respect to ρ.
Definition 5. (Abstract dependency) Let x, y ∈ Var,
then the abstract dependency between the expression
e and variable x with respect to an abstract domain ρ
(property) is defined formally as,
∃ϕ
1
,ϕ
2
∈ Σ
ρ
.∀y 6= x.ϕ
1
(y) = ϕ
2
(y) ∧
H [[e]]ϕ
1
6= H [[e]]ϕ
2
.
Dataflow based property driven program slicing is
a fixed point computation where each iterate has two
phases, first, the control flow analysis is combined
with a static analysis in a abstract interpretation based
framework. Hence, each program point of the pro-
gram is enhanced with information about the abstract
state of variables with respect to the property of in-
terest. Then, a backward program slicing technique is
applied to the augmented program exploiting the ab-
stract dependencies.
4.1 Phase 1: Static Analysis
Our representation of programs are def/use graphs.
The objective of a static analysis based on Abstract
Interpretation is to assign sets of possible abstract val-
ues to edges of a def/use graph. The def/use graph
consists of five different node types which represent
program points:
1. A designated start and end node representing the
beginning and end point of a def/use graph.
2. Expression nodes representing different expres-
sion types found in a concrete semantic model.
3. Condition nodes representing forks in a control
flow, i.e. this type of nodes has one incoming and
two outgoing edges.
4. Join nodes merging two paths of the def/use
graph, i.e. these nodes have two incoming and
one outgoing edge.
Like the classical approach, our analysis also be-
gins at the start node of the def/use graph and traverses
the graph during its static program analysis phase.
Depending on the encountered node type, a particular
set of rules which is based on Abstract Interpretation
is applied.
Based on the def/use graph, the classical approach
begins with the construction of a complete transition
system for the five node types. It defines how an ab-
stract state is transferred into one state to another state
at program point p:
T
p
:℘(Σ
A
) → ℘(Σ
A
)
The transition system T is used to construct a sys-
tem of equations which define the assignment of ab-
stract states to program points. A solution is found
by a fixed-point iteration. It begins with the least pos-
sible assignment T (⊥) where ⊥ is the least element
representing
/
0. The fixed-point iteration continues as
long as a further application of T does not compute
a new state: T
n−1
= T
n
.
Now we will define T for the different types of
edges in a def/use graph. For any edge e ∈ E we shall
denote its predecessor edges as e
pre
. For merge nodes,
which have two incoming edges, the second is de-
noted e
pre
′
. In the following, T is given for every
type of program point with respect to a given abstract
domain ρ. ∀ϕ
ρ
∈ Σ
ρ
denotes the abstract states asso-
ciated to program variables at each program point.
Start Edge. At the start edge e, nothing is known
about the values of variables. Having said this, the
natural definition of an abstract state associated
with the initial state should be as follows:
T
e
(ϕ
ρ
) = ⊥
Assignment Edge. An assignment edge is an
edge which emerges from an assignment node.
Let, an assignment node has an assignment x :=
a associated with it, where x ∈ Var and a ∈ AExp,
then T
e
(ϕ
ρ
) should be equal to the previous ab-
stract state with the variable x updated to the ab-
stract value of e (Table 1), as follows:.
T
e
(ϕ
ρ
) = T
e
pre
(ϕ
ρ
[x ← H [[a]]ϕ
ρ
])
Merge Edge. The problem of Abstract Interpre-
tation is that a termination of the fixed-point it-
eration can not be guaranteed. Due to the nature
of Abstract Interpretation which iteratively sim-
ulates each state transition, the fixed-point itera-
tion can consume a significant amount of time for
loops with large iteration counts. To overcome
both problems, the widening operator ∇ (Cortesi
and Zanioli, 2010) can be applied. Its applica-
tion typically enlarges the abstract states during
the fixed-point iteration leading to a correct but
also over-approximated solution which might be-
come infeasible as result for many applications.
Thus, a narrowing operator △ was introduced
(Cortesi and Zanioli, 2010) to restrict the over-
approximation afterwards.
A merge edge is an edge emerging from a merge
node. A merge node combines the analysis re-
sults of the two incoming edges. The least ab-
stract value which is correct with respect to both
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
152

incoming values is the supremum of the these. In
addition, if the merge node is the entry of a loop,
then that is a good place to put the widening based
on the abstract domain. Thus, the abstract transi-
tion function for merge nodes is
T
e
(ϕ
ρ
) =











T
e
(ϕ
ρ
)∇(T
e
pre
(ϕ
ρ
) ⊔ T
e
pre
′
(ϕ
ρ
))
if loop merge
T
e
pre
(ϕ
ρ
) ⊔ T
e
pre
′
(ϕ
ρ
)
otherwise
Conditional Edges. The conditional node has
two outgoing edges. Conditionals are resolved
by only boolean expressions with relational oper-
ators Op
r
, so for an abstract domain it is necessary
to have abstract version of all relational operators
d
Op
r
(Table 2).
T
e
(ϕ
ρ
) =



T
e
p
re
(ϕ
ρ
) ∧ H
b
[[b]]ϕ
ρ
= TRUE
T
e
pre
(ϕ
ρ
) ∧ H
b
[[b]]ϕ
ρ
= FALSE
The Abstract Interpretation may establish cer-
tain properties of a program through which we
can identify infeasible statements of the program
which will not be taken into account for program
execution by predicting predicates present in con-
ditional statements. By the following rules we
modify the program P in order to simplify the
control dependence, taking into account only the
statements that have impact on the property of in-
terest ρ.
Table 6: Rules for conditional nodes.
Rule 1 For S::= l : i f b then S
1
else S
2









(a)P
′
= P[S / S
1
] if H
b
[[b]]ϕ
ρ
= TRUE
(b)P
′
= P[S / S
2
] if H
b
[[b]]ϕ
ρ
= FALSE
(c)P
′
= P[S / S] No replacement otherwise
Rule 2 For S::= l : while b do S
1



(a)P
′
= P[skip / S] if H
b
[[b]]ϕ
ρ
= FALSE
(b)P
′
= P[S / S] No replacement otherwise
Let’s apply the rules in Table 6 on the following
code fragments, In Table 7, P
′
is obtained by apply-
ing rule 1(a) on P by statically analyzing the program
in Parity domain. Notice P
′
contains less statements
than P. Therefore, the above rules can often generate
a reduced CFG by statically analyzing the associated
program with respect to a certain property ρ.
Table 7: Application of rule 1(a) on program P.
P ϕ{w, x, y,z} P
′
Input z; (⊥, ⊥, ⊥, ⊥) Input z;
y = 15; (⊥, ⊥, ⊥, ⊤) y = 15;
x = 2 ∗ z; (⊥, ⊥, O, ⊤) x = 2 ∗ z;
if(x! = y) (⊥, E, O, ⊤)
w = x+ y; (⊥,E, O, ⊤) w = x + y;
else (⊥, E, O, ⊤)
w = x− y+ 1; (⊥, E, O, ⊤)
Output w; (⊤, E, O, ⊤) Output w;
4.2 Phase 2: Slicing Algorithm
This section introduces a backward slicing algorithm
that uses the extracted information from phase 1
at each program point. While traditional slicing
algorithms are typically syntactical dependency
based, this property driven approach must rely on
semantics dependencies and abstract dependencies.
In fact, the more abstract the property, the greater
the loss of precision of the syntactic approach with
respect to the actual semantic.
Algorithm: Property Driven Program Slicing
Input:
 G
P
: Statically analyzed (Phase 1) def/use graph of
the program P.
 C = (n,V): slicing criterion.
 ρ: Given property of interest.
Directly Relevant Variables (R
0
(C,ρ)
)
 The set of directly relevant variables at slice node,
n, is simply the slice set, V.
 The set of directly relevant variables at everyother
node i, is defined in terms of the set of directly
relevant variables of all nodes j leading directly
from i to j (i −→
G
P
′
j) in G
P
. R
0
(C,ρ)
(i) contains
all variables x such that, either,























(a) x ∈ R
0
(C,ρ)
( j) − def(i)
(b) if (def(i) ∩ R
0
(C,ρ)
( j) 6=
/
0) then
(∀y 6= x ∈ use(i)) ∧ (∀ϕ
i
ρ
,ϕ
j
ρ
∈ Σ
A
)
if(ϕ
i
ρ
(y) = ϕ
j
ρ
(y)) ∧ (ϕ
i
ρ
(def(i)) 6= ϕ
j
ρ
(def(i)))
then
R
0
(C,ρ)
(i) = R
0
(C,ρ)
(i) ∪ {x}
The directly relevant variables of a a node are the
set of variables at that node upon which the slicing
PROPERTY DRIVEN PROGRAM SLICING REFINEMENT
153

Table 8: Program P after Phase 1.
Stmt. No. Code x y l p m k c w
1 scanf(”%d”, &y); ⊥ ⊥ ⊥ ⊥ ⊥ ⊥ ⊥ ⊥
2 x=2*y+1 ⊥ ⊤ ⊥ ⊥ ⊥ ⊥ ⊥ ⊥
3 l=x+1; O ⊤ ⊥ ⊥ ⊥ ⊥ ⊥ ⊥
4 p=l; O ⊤ E ⊥ ⊥ ⊥ ⊥ ⊥
5 m=x+l; O ⊤ E E ⊥ ⊥ ⊥ ⊥
6 k= m+(x%2)-m; O ⊤ E E O ⊥ ⊥ ⊥
7 if(k!=0){ O ⊤ E E O O ⊥ ⊥
8 x=p+1; O ⊤ E E O O ⊥ ⊥
9 x=x+1; O ⊤ E E O O ⊥ ⊥
10 c=x+p;} E ⊤ E E O O ⊥ ⊥
else{ E ⊤ E E O O E ⊥
11 x=x-1;
12 p=l+1;
13 c=x-p;}
14 w=x+p E ⊤ E E O O E ⊥
15 printf(”%d”, c); E ⊤ E E O O E E
16 printf(”%d”, w); E ⊤ E E O O E E
criterion is transitively dependent based on a given
property ρ.
Directly Relevant Statements (S
0
(C,ρ)
)
In terms of the directly relevant variables, a set of di-
rectly relevant statements is defined:
if (def(i) ∩ R
0
(C,ρ)
( j) 6=
/
0) then
S
0
(C,ρ)
= S
0
(C,ρ)
∪ {i}
Indirectly Relevant Variables (R
k+1
(C,ρ)
,K ≥ 0)
In calculating the indirectly relevant variables, control
dependency is taken into account.
for each predicate node b in G
P
′
do
if (b∩ S
0
(C,ρ)
) 6=
/
0
B
K
(C,ρ)
= B
K
(C,ρ)
∪ {b}
B
K
(C,ρ)
is the set of all predicate nodes that control a
statement in S
0
(C,ρ)
.
R
K+1
(C,ρ)
(i) = R
K
(C,ρ)
(i) ∪
S
b∈B
K
(C,ρ)
R
0
(b,use(b),ρ)
(i)
Indirectly Relevant Statements (S
k+1
(C,ρ)
,K ≥ 0)
Adding predicate nodes to S
0
(C,ρ)
includes further in-
directly relevant statements in the slice:
if (def(i) ∩ R
k+1
(C,ρ)
( j) 6=
/
0) then
S
k+1
(C,ρ)
= S
k
(C,ρ)
∪ B
K
(C,ρ)
∪ {i}
Let us consider the following code in Table 8. No-
tice that, statements 7 and 11 to 13 can be ignored by
Rule 1(a) discussed in Table 6.
Table 9 shows the comparison between the value
based slice and property driven slice with respect to
slicing criterion C=(16, w) and a property ρ = Parity.
Since the property of x at statement 2 does not de-
pend on the property of y, statement 1 is irrelevant.
The property of x stays same before and after the ex-
ecution of statement 8, for that reason statement 8 is
also irrelevant in this context. And statement 6 and
statement 10 are deleted from the slice due to the tra-
ditional slicing rules.
5 CONCLUSIONS
The proposed slicing algorithm does not allow any
huge alteration on the traditional algorithm, it just em-
phasizes on the abstract dependencies rather than on
value based dependencies and has some significant
advantages over the traditional slicing algorithms.
On the practical side, property driven program
slicing is interesting since, in general, the slicing
based on a property of some variables is smaller than
the slicing technique based on the exact value of the
same variables, since, properties propagate less than
concrete values, some statements might affect the
values but not the property. This can make debug-
ging and program understanding tasks easier, since a
smaller portion of the code has to be inspected when
searching for some undesired behavior.
ACKNOWLEDGEMENTS
Work partially supported by RAS L.R. 7/2007 Project
TESLA.
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
154

Table 9: Property driven slice of P, P
Parity
(16,w)
, w.r.t ρ = Parity and C=(16,w), and value based slice of P, P
(16,w)
, w.r.t ρ = Parity
and C=(16,w).
Stmt. No. P P
Parity
(16,w)
P
(16,w)
1 scanf(”%d”, &y); scanf(”%d”, &y);
2 x=2*y+1; x=2*y+1; x=2*y+1;
3 l=x+1; l=x+1; l=x+1;
4 p=l; p=l; p=l;
5 m=x+l; m=x+l;
6 k= m+(x%2)-m; k= m+(x%2)-m;
7 if(k!=0){ if(k!=0){
8 x=p+1; x=p+1;
9 x=x+1; x=x+1; x=x+1;}
10 c=x+p;}
else{ else{
11 x=x-1; x=x-1;
12 p=l+1; p=l+1;}
13 c=x-p;}
14 w=x+p; w=x+p; w=x+p;
15 printf(”%d”, c);
16 printf(”%d”, w); printf(”%d”, w); printf(”%d”, w);
REFERENCES
Bhattacharya, S. (2011). Property driven program slicing
and water marking in the abstract interpretation frame-
work. PhD Thesis, Ca’ Foscari University of Venice,
Italy.
Cortesi, A. and Halder, R. (2010). Dependence condition
graph for semantics-based abstract program slicing. In
proceedings of the Tenth Workshop on Language De-
scriptions, Tools and Applications, ACM Press, (1):4–
17.
Cortesi, A. and Zanioli, M. (2010). Widening and narrow-
ing operators for abstract interpretation. Computer
Languages, Systems and Structures, 37(1):24–42.
Cousot, P. and Cousot, R. (1977). Abstract interpretation:
A unified lattice model for static analysis of programs
by construction or approximation of fixpoints. In Pro-
ceedings of the 4th ACM Symp. on Principles of Pro-
gramming Languages, pages 238–252.
Mastroeni, I., , and Nikolic’., D. (2010). Abstract program
slicing: From theory towards an implementation. For-
mal Methods and Software Engineering, LNCS 6467,
pages 452–456.
Mastroeni, I. and Zanardini, D. (2008). Data dependencies
and program slicing: from syntax to abstract seman-
tics. Proceedings of ACM SIGPLAN symposium on
Partial evaluation and semantics-based program ma-
nipulation, pages 123–134.
Nielson, F., Nielson, H., and Hankin, C. (1999). Principles
of program analysis. Springer Verlag.
Weiser, M. (1984). Program slicing. IEEE Transactions on
Software Engineering, 10(4):352–357.
PROPERTY DRIVEN PROGRAM SLICING REFINEMENT
155