[16] Ottenstein, K and Ottenstein, L The Program Dependence Graph in Software Development

Transcription

1 [16] Ottenstein, K and Ottenstein, L The Program Dependence Graph in Software Development Environments SIGPLAN Notices, 19(5), 177{184, [17] Stoy, JE Denotational Semantics: The Scott{Strachey Approach to Programming Language Theory MIT Press, [18] Strachey, C and Wadsworth, C Continuations: A Mathematical Semantics for Handling Full Jumps Technical Report, PRG{11, Oxford University Computer Laboratory, Programming Research Group, [19] Weiser, M Programmers Use Slices When Debugging Communications of the ACM, 25(7), pp446{452, [20] Weiser, M Program Slicing IEEE Transactions on Software Engineering, SE-10, part 4, pp352{357, [21] Wikstrom, A Functional Programming Using Standard ML Prentice Hall,

2 References [1] Agrawal, H and Horgan, J R Dynamic Program Slicing Proceedings of the SIGPLAN '90 Conference on Programming Language Design and Implementation, New York, June 20{22, [2] Aho, A and Ullman, J D Principles of Compiler Design Addison{Wesley, [3] Ashcroft, E and Manna Z The Translation of goto Programs into while Programs Proceedings of the IFIP Congress, Amsterdam, [4] Darlington, J and Burstall, R M A Transformation System for Developing Recursive Programs Journal of the ACM, 24(1), [5] Korel, B and Laski, J Dynamic Program Slicing Information Processing Letters, pp155{ 163, October, [6] Gallagher, K B and Lyle J R Using Program Slicing in Software Maintenance IEEE Transactions on Software Engineering, 17(8), pp , [7] Gopal, R Dynamic Program Slicing Based on Dependence Relations Proceedings of the IEEE Conference on Software Maintenance, pp191{200, [8] Harman, M Functional Models of Procedural Programs Ph.D. Thesis, University of North London, London, U.K., [9] Harman M, and Danicic S Projecting Functional Models of Imperative Programs SIG- PLAN Notices, 28(11), pp42-52, [10] Horwitz, S, Reps, T and Binkley, D Interprocedural Slicing Using Dependence Graphs Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, Atlanta, Georgia, June 22{24, pp35{46, [11] Jiang, J, Zhou, X and Robson, D J Program Slicing for C { The Problems in Implementation Proceedings of the IEEE Conference on Software Maintenance, Italy, pp182{190, [12] Kamkar, M Shahmehri, N and Fritzson, P Interprocedural Dynamic Slicing Proceedings of the 4th Conference on Programming Language Implementation and Logic Programming, pp370{384, [13] Kernighan, B W and Ritchie, D M The C Programming Language Second edition, (ANSI C), Prentice Hall, [14] Lu, Q, Zhang, F and Qian, J Program Slicing: Its Improved Algorithm and Application in Verication Journal of Computer Science and Technology, 3(1), pp29-39, [15] McCarthy, J Towards a Mathematical Theory of Computation Proceedings of the International Foundations of Information Processing Congress (Poppelworth, C M (ed.)), Munich, Germany,

3 main() { L1 : if (n==0) ; else { n=n-1; goto L1; } } which can be transformed into the while loop below using Ashcroft and Manna's algorithm [3]: main() { while (n!=0) n=n-1; } It is clear that transformation can be mixed with conventional slicing to produce good approximations to eect minimal slices. The side{eect removal transformations are a way of pre{processing a program in such a way as to improve the results obtained by conventional slicing. The goto removal transformations we used in section 4.4 are aimed at reducing several dierent slicing problems into one general one. 5 Conclusion Program slicing is a powerful tool for program abstraction, with which a program can be broken up into smaller programs (its slices), each of which can then be treated in isolation. Conventionally, a slice is constructed by deleting commands from the original program which cannot aect the value of the variables we choose in the slice set. This approach ensures that the slice is a subset of the original program from which it was constructed, but may not lead to the thinnest possible slice. In this paper we have separated the semantic property of a slice from the syntactic method of its construction, and in so doing we have abandoned the notion of slices as subsets of the original program. The denition of the eect minimal slice, being a purely semantic one, allows slicing algorithms to be constructed using, for example, a mixture of transformation, modelling and conventional slicing, which together can give rise to a thinner slice than would otherwise have been possible. We have justied our approach by appealing to the comparative thinness of the slices it produces. This has to be balanced against the fact that our slices are not subsets of the original program, which might be considered unacceptable in some circumstances { for example, isolating the line(s) which cause a known `bug'. The optimal solution is to use both conventional and eect minimal slicing in concert as a means of investigating, transforming, verifying, maintaining and correcting programs. More work is required to establish the most suitable algorithms for constructing eect minimal slices, and to explore and formalise their properties and relation to conventional slices. Acknowledgements We would like to thank Dominic Elliott and Yoga Sivagurunathan and Balasubramaniam Sivagurunathan for their help in implementing some of the work reported here. We would also like to acknowledge the support and advice of Ed Currie, John Darlington, Carol Kliem, Chris Sadler, Dan Simpson, Irek Ulidowski and Sam Valentine. 12

4 We consider a program like this to be a sequence of blocks. Each block is a sequence of commands. The rst command of a block is labelled, the last is a goto command, and all other commands in a block are unlabelled. The rst and last blocks of a program fragment are special cases: The rst requires no label, and the last requires no nal goto command. The rst step in transforming a fragment with goto commands into a fragment without them is to add `linkage' goto commands, creating a program in which all blocks (but the last) end with a goto. In this case, we need add only one linkage command: goto L1, which we add after the assignment: N=n. Next, we replace each labelled block with a parameterless procedure, named after the label and replace each command goto L by a call to procedure L. We must also ensure that, on return from any of these procedure calls, the program performs no further processing. This can be achieved by adding else clauses to if commands. Performing these steps on the program fragment above yields: void L2() { x=x/n; } void L1() { if(n==0) L2(); else { x=x+n; n=n-1; L1();} } main() { x=0; N=n; L1();} The transformed program is amenable to slicing using, for example, the approach described in [10]. For the slicing criterion < fng;l >, where L is the last line of the program, conventional slicing yields: void L1() { if (n==0) ; else {n=n-1;l1();} } main() { L1(); } The procedures we introduce to model goto commands are eectively the imperative equivalent of a continuation [18, 17], since they reect the eect of the `rest of the program'. Knowing that the procedure calls we have introduced model the eect of the `rest of the program' allows us to transform them back into goto commands. In this case we can transform the sliced program to: 11

5 Using eect minimal slicing we have thus separated the code fragment into the three subprograms: {sum = a[20];} {average=a[20]/20;} {biggest=a[0]; for(i=0;i<20;i++) if (a[i]>biggest) biggest=a[i];} Which are the eect minimal slices for sum, average and biggest respectively. Without a specication we cannot call the eect the program has on any of these variables `a bug'. However, it does seem highly suspicious that variables called sum and average mention only the twenty{rst value in the array a, and that this twenty{rst value is not included in the `search for the biggest' conducted by the fbiggestg eect minimal slice. Using conventional slicing we would have obtained thicker slices { the entire program for the variable average and all but the last line for biggest and sum. Using eect minimal slicing, the eect of the original program has upon the slice set is as simple and clear as possible, improving our comprehension and chances of bug detection. 4.4 Goto, Break and Continue Jiang, Zhou and Robson [11] have highlighted problems associated with conventional slicing using Weiser's algorithm [20] on programs (written in C) with break, continue and goto commands (giving a solution for each). When constructing an eect minimal slice we are free to exploit the homogenising power of transformation, reducing several separate problems for conventional slicing into a single problem in the eect minimal paradigm. Using transformation we can, for example, replace break and continue commands with equivalent goto commands. In turn, goto commands can be transformed into procedure calls (using a transformation rst suggested by McCarthy in [15] 7 ). We can then use conventional slicing to slice the transformed program. In this way we use transformation to simplify the task of constructing an eect minimal slicing algorithm. Consider the program fragment below: main() { x=0; N=n; L1: if(n==0) goto L2; x=x+n; n=n-1; goto L1; L2: x=x/n; } 7 This transformation is only possible if goto commands do not cause control to transfer from outside the body of a procedure into one, and provided that calculated goto commands are not permitted. This is the case with C programs (see page 224 of [13]). 10

6 We can improve the situation a little further. The assignment biggest=sum at line 3, has to be retained, thus forcing us to retain the assignment sum=a[0] at line 2, which otherwise would have been deleted. We can symbolically execute the rst three lines removing the need for an assignment to sum, giving: i=0; biggest=a[0]; while(i<20) { if (a[i]>biggest) biggest=a[i] ; i=i+1; } A nal transformation to a for loop might be considered appropriate in this case 6 : biggest=a[0]; for(i=0;i<20;i++) if (a[i] > biggest) biggest = a[i]; This is still only an approximation to an eect minimal slice for the original program, with the slice set fbiggestg, since the program aects the value of i, which is outside the slice set. 4.3 Bug Location Slicing can be used to help a programmer locate the line(s) which cause a known bug [19, 20, 6]. Clearly, since eect minimal slices are not subsets of the original program, it would be meaningless to speak of using an eect minimal slice to locate such line(s). However, because eect minimal slices are often thinner than conventional ones, it may be that a previously undetected bug becomes easier to spot. We can then use conventional slicing to help locate the line(s) which cause it. Constructing the fsumg eect minimal slice for example 4.1 we obtain: i=0; sum=a[0]; while(i<20) { i=i+1; sum=a[i]; } Using the code motion techniques associated with compiler optimisation as one of our transformations [2] we can produce the better approximation to a fsumg eect minimal slice: sum=a[20]; In a similar manner, we could construct the faverageg eect minimal slice: average=a[20]/20; 6 The justication for a `post processing' transformation such as this relies on the fact that the bounds of a loop in the form for(i=k 1 ;i<k 2,i++)... are clearly k 1 and k 2, whereas in other forms of for and while loop the bounds, if they exist, are less obvious. 9

7 Consider the program fragment below: if(++i && i--) x=1; which can be equivalently written without side eects as follows: if(i==-1) i=0; else x=1; 4.2 Combining Transformation and Conventional Slicing In this section we show how eect minimal slicing can be achieved using a combination of conventional slicing and transformations such as these. Consider example 4.1 below: Example 4.1 for(i=0,sum=a[0],biggest=sum;i<20;sum=a[++i]) if (a[i] > biggest) biggest = a[i] ; average=sum/20 ; Suppose that we are interested in the eect this program fragment has upon the variable biggest. Conventional slicing at the end of the program will produce: for(i=0,sum=a[0],biggest=sum;i<20;sum=a[++i]) if (a[i] > biggest) biggest = a[i] ; Which aects the value of sum and i as well as that of biggest. If instead we transform the side eects out of the program we obtain: i=0; sum=a[0]; biggest=sum; while(i<20) { if (a[i]>biggest) biggest=a[i] ; i=i+1; sum=a[i]; } average = sum/20 ; Conventional slicing at the last line of this program with the slice set fbiggestg yields: i=0; sum=a[0]; biggest=sum; while(i<20) { if (a[i]>biggest) biggest=a[i] ; i=i+1; } 8

8 3.4 Modelling Standard Imperative Constructs Where no side eects are present, functional modelling of standard constructs such as conditional and loops, presents little problems. The if command is modelled by a conditional expression and the loop constructs are modelled using recursive functions. Side eects must rst be transformed out of the imperative language prior to modelling. As we have demonstrated, functional modelling is appealing as a way of constructing eect minimal slices because of the rich algebraic properties of the pure functional style. However, such an approach involves the extra complication of compiling the imperative program into the pure functional notation. Whilst this is possible for a surprisingly large class of languages [8] there is the added problem of converting the projected model back into the imperative notation. We have found that staying within the imperative notation and attempting to combine transformation and conventional slicing avoids the problems associated with translation to and from the model notation. The exibility of eect minimal slicing lies in the way in which we are free to `mix and match' suitable techniques on a case by case basis. 4 Slice Construction Using Transformation If we are prepared to view a slice as any simpler program congruent to the original with respect to the slice set, then we can exploit imperative language transformations which will make the original program easier to slice, and which can often lead to thinner slices. 4.1 Side Eects in C Programs A side eect is an assignment that occurs when an expression is evaluated. Expressions with side eects inhibit the conventional production of the thinnest possible slice because they allow an individual command to have multiple assignments. This increases the likelihood that command inter{dependency will prevent the removal of unwanted eects by command deletion. Using transformation as a meaning preserving `pre{processing' phase, prior to conventional slicing, we can ameliorate the problem posed by side eects. Consider, for example, the assignment command x = i++ ; This can be transformed into the side{eect free program fragment: x = i; i = i+1; We have transformed a single command with two eects into two commands each with a single eect. This dis{entanglement of eects allows us to use conventional slicing to construct the thinnest possible slice for either aected variable. This is a trivial example of the problems posed by side eects. It is however, possible, for side eects to manifest themselves in less trivial ways. 7

9 3.2 Algebraic Laws One of transformations described in [4] is Any algebraic law concerning the operators in an expression, E, which can be used to show that this expression is equivalent to another expression, E 0, may be used to replace E with E 0. This simple connection between mathematical expressions and those found in a functional program is not maintained in the imperative paradigm. For example, in Pascal, the law of commutativity of multiplication cannot always be exploited in expression transformation, since the expressions may contain side eects. Using the algebraic properties of the pure functional notation, we can continue the transformation of our two line example as follows: fun f(x,y) = (x-y,2*(x-y)+y)) ; ) fun f(x,y) = (x-y,2*x-2*y+y) ; ) fun f(x,y) = (x-y,2*x-y) ; This model tells us that the nal value of p is x-y and the nal value of q is 2*x-y. 3.3 Projection The functional model above, computes the nal value of both the imperative program fragment's aected variables in terms of its needed variables. In order to construct an eect minimal slice, we project [9] the model function onto the value(s) of interest. A model for the variable p, is obtained by projecting onto the rst value of the model's result tuple: fun f(x,y) = x-y ; A model for q is obtained by projecting onto the second value: fun f(x,y) = 2*x-y ; In order to produce a fqg eect minimal slice of the original program, we convert the model for q back into Pascal, giving: q := 2*x-y By contrast, conventional slicing, with slicing criterion, < fqg; 4 >, makes no progress. The unfold transformations essentially give us a means of symbolically executing the program and the algebraic laws can be used to reduce expressions to a simpler form. 6

10 Given a program fragment, p, a functional model of p is a function written in a purely functional language 4. The parameters to the model are the initial values of the `needed variables' of p and the value returned is a tuple 5 containing the nal values of the variables `aected' by p. Assignments are modelled by let expressions. The Pascal fragment: begin p:=x-y; q:=2*p+y end has needed variables, fx; yg and aected variables, fp; qg. Its functional model is: fun f(x,y) = let val p = x-y in let val q = 2*p+y in (p,q) ; Modelling such a small program is a trivial process, but it does allow us to highlight a few of the benets of functional modelling, all of which arise because of the rich algebraic properties of pure functional notations. 3.1 Unfolding the Model The let expressions can be unfolded [4], giving us the following sequence of transformations: fun f(x,y) = ) let val p = x-y in let val q = 2*p+y in (p,q) ; fun f(x,y) = let val q = 2*(x-y)+y in (x-y,q) ; ) fun f(x,y) = (x-y,2*(x-y)+y) ; 4 In [8] we use a pure functional subset of ML [21]. 5`Tuple' is (roughly speaking) the functional programmers' equivalent of a record structure. 5

11 Example 2.4 begin z:= z+10; x:= z; z:= z-10 end Combining these two concepts we arrive at the K eect minimal slice which aects the variables in K and does so identically to the program for which it is constructed. Denition 2.3 (Eect Minimal Slice) Given a set of variables, K, a Keect minimal slice of p is any K eect minimal program which is K congruent to p. Example 2.3 above is an fxg eect minimal slice of example 2.1 above. 2.1 Relation to Conventional Slicing The semantic view of a program that we have taken has forced us to abandon the idea of slicing at a particular line number within a program. Since, for example, transformation is permitted, the concept of a line number within the original program may become meaningless after the rst transformation is performed. However, denition 2.3 does guarantee that an eect minimal slice preserves the eect of the original program upon the slice set, thus respecting the spirit of conventional slicing. The slicing criterion for an eect minimal slice is therefore simply the set of variables whose computation is preserved by the slice (the `slice set'). Clearly a conventional slice for <K;L>, where L is always the last line of the program to be executed 2 is K congruent with the original program for which it is constructed, since only commands which can have no eect upon variables in K (at the end of the program) can be deleted. As example 1.2 shows, conventional slicing may not produce an eect minimal slice, where it is possible to compute one 3. The reason why conventional slicing may not produce an eect minimal slice lies in the inter{dependencies between commands in a program. A line n, may aect the value of a variable in the slice set, in which case a conventional algorithm must keep this line in a slice. However, the denition at line n may reference the value of a variable, v aected at a line m, forcing us to keep the line m in the slice whether or not the variable v is in the slice set or not. In order to remove line m, in cases where v is outside the slice set, we must replace line n with an equivalent one which does not reference v. In many cases this can be achieved using meaning preserving transformations and symbolic execution, which we discuss in the next two sections. 3 Computing Eect Minimal Slices Using Functional Models In this section we show how functional models of imperative programs can be used to symbolically execute program fragments as part of an approach to constructing an eect minimal slice. 2 In initial states which give rise to non-terminating computations the `eects' of a program are undened and the eects of the slice when executed in a such a state, are likewise undened. 3 Both conventional and eect minimal slices are not, in general, computable. We therefore seek to approximate them as closely as possible. 4

12 the essential semantic property that the slice maintains the eect of the original program on variables mentioned in the slicing criterion. The rest of this paper is organised as follows:- In section 2 we dene the eect minimal slice and in section 3 we show how eect minimal slices can be computed by projecting functional models of imperative program fragments [9]. In section 4 we show how our new denition of program slice allows us to compose several dierent syntactic techniques in order to construct thinner slices. 2 The Eect Minimal Slice We shall call the set of variables for which a slice is constructed, the `slice set'. As for a conventional slice, our slice must maintain the eect that the original program has upon the slice set. Denition 2.1 below captures the congruence that exists between two programs which have the same eect on a certain set of identiers. Denition 2.1 (Congruence) Given a set of variables, K, two programs are Kcongruent if and only if they have the same eect upon all variables in K. Examples 2.1 and 2.2 below are fxg congruent: Example 2.1 begin x:= 1; y:= 22 end Example 2.2 begin z:= 10; x:= z-9 end Denition 2.1 weakens the normal semantic equivalence between two programs (that they agree on all variables) to the property of congruence (agree on a subset of all variables). In order to produce the simplest slice of a program p for the slice set K, we must therefore nd the simplest program which is K congruent to p.we wish to dene simplicity in a purely semantic way, to avoid inhibiting the syntactic process by which a slice is constructed. As slicing is concerned with the eect a program has upon its variables, we shall view `simple' programs as those which aect few variables, and `complex' ones as those which aect many. Ideally, we want a slice only to aect variables mentioned in the slicing criterion, so we seek a denition of `simplicity with respect to a set of variables'. Denition 2.2 (Eect Minimality) Given a set of variables, K, a Keect minimal program aects no variables outside K. Examples 2.3 and 2.4 below are both fxg eect minimal: Example 2.3 begin x:= 1 end 3

13 In dierent ways, several workers [1, 5, 7, 12] have adapted the original (static) slicing approach to the dynamic paradigm (where the input to the original program is known at slice construction time). Horwitz, Reps and Binkley [10] have adapted the program dependence graph [16] to a `system dependence graph' allowing the construction of slices across procedure boundaries. All approaches to slice construction seek to delete as many commands as possible, thereby producing the thinnest possible slice. Consider the Pascal program fragment below 1 : Example begin 2 z:= y+1 ; 3 p:= 2 ; 4 q:= p+2 5 end Slicing example 1.1 on < fpg; 5 > gives the simplied program fragment below: 3 p:= 2 In this case, there is no thinner fragment of Pascal that has the same eect as example 1.1 upon the variable p. However, the conventional approach of deleting commands often prevents us from obtaining the thinnest possible slice, as example 1.2 demonstrates: Example begin 2 x:= p ; 3 y:= x+1; 4 z:= y+3 5 end Conventional slicing of example 1.2 with the slicing criterion < fzg; 5 >, produces the entire program fragment as the slice. We can delete no commands, since the value of z depends upon the execution of every other line. However, since the value of z at the last line is simply p +4 it seems natural to modify the denition of slicing so as to allow the program fragment below as a valid slice of example 1.2 z:= p+4 There is no thinner program fragment expressible in Pascal which captures the eect example 1.2 has on z. Clearly, we cannot produce the thinnest slice if we restrict ourselves to deleting commands. The denition of eect minimal slice that we give in section 2 is purely semantic, so it removes the restriction to command deletion as a means of slice construction, whilst respecting 1 In order to form a slicing criterion it is conventional to number a program's commands. 2

14 A New Approach to Program Slicing M. Harman and S. Danicic School of Computing University of North London Eden Grove, London, N7 8DB tel: fax: Abstract A conventional program slice is constructed by deleting commands which cannot aect the values of a chosen set of variables. This yields a subset of the program which maintains the eect of the original upon the chosen set of variables. In this paper we introduce the eect minimal slice, which separates the semantic concept of a slice, from its syntactic denition. The denition of eect minimal slice respects the spirit of conventional slicing in the sense that an eect minimal slice maintains the eect of the original program upon a chosen set of variables, but it drops the constraint that a slice must be a subset of the original program. This allows for the construction of thinner program slices than are possible with command deletion. The denition of eect minimal slice is purely semantic, and so any syntactic process can be used to construct one. We show how eect minimal slicing can be implemented using a mixture of meaning preserving transformations, symbolic execution and conventional slicing algorithms. 1 Introduction Conventionally, a slice is constructed with respect to a slicing criterion, a pair, <V; n>, where V is a set of variables and n is a line number. The slice is constructed by deleting commands from the original program which have no eect upon the values of variables in V at line number n. Thus a conventional slice of the program p, is an executable subset of p, which has the same eect as p on all variables in V at line n. The motivation for slicing derives form the simplication achieved by command deletion. This simplication can be achieved because the slice only preserves the eect of the original program upon V. Several researchers have described the merits of slicing when used as a tool to assist in the various stages of software maintenance and modication. Gallagher and Lyle [6] have shown how slicing may be used to guide modications to a program during maintenance. Weiser [19] has shown empirically that maintainers use slicing implicitly when debugging. 1