David W. Binkley

Interprocedural slicing using dependence graphs

The notion of a <italic>program slice</italic>, originally introduced by Mark Weiser, is useful in program debugging, automatic parallelization, and program integration. A slice of a program is taken with respect to a program point <italic>p</italic> and a variable <italic>x</italic>; the slice consists of all statements of the program that might affect the value of <italic>x</italic> at point <italic>p</italic>. This paper concerns the problem of interprocedural slicing—generating a slice of an entire program, where the slice crosses the boundaries of procedure calls. To solve this problem, we introduce a new kind of graph to represent programs, called a <italic>system dependence graph</italic>, which extends previous dependence representations to incorporate collections of procedures (with procedure calls) rather than just monolithic programs. Our main result is an algorithm for interprocedural slicing that uses the new representation. (It should be noted that our work concerns a somewhat restricted kind of slice: rather than permitting a program to be sliced with respect to program point <italic>p</italic> and an <italic>arbitrary</italic> variable, a slice must be taken with respect to a variable that is <italic>defined</italic> or <italic>used</italic> at <italic>p</italic>.) The chief difficulty in interprocedural slicing is correctly accounting for the calling context of a called procedure. To handle this problem, system dependence graphs include some data dependence edges that represent <italic>transitive</italic> dependences due to the effects of procedure calls, in addition to the conventional direct-dependence edges. These edges are constructed with the aid of an auxiliary structure that represents calling and parameter-linkage relationships. This structure takes the form of an attribute grammar. The step of computing the required transitive-dependence edges is reduced to the construction of the subordinate characteristic graphs for the grammars nonterminals.

Semantics guided regression test cost reduction

Software maintainers are faced with the task of regression testing: retesting a modified program on an often large number of test cases. The cost of regression testing can be reduced if the size of the program is reduced and if old test cases and results can be reused. Two complimentary algorithms for reducing the cost of regression testing are presented. The first produces a program called Differences that captures the semantic change between Certified, a previously tested program, and Modified, a changed version of Certified. It is more efficient to test Differences, because it omits unchanged computations. The program Differences is computed using a combination of program slices. The second algorithm identifies test cases for which Certified and Modified produce the same output and existing test cases that test new components in Modified. The algorithm is based on the notion of common execution patterns. Program components with common execution patterns have the same execution pattern during some call to their procedure. They are computed using a calling context slice. Whereas an interprocedural slice includes the program components necessary to capture all possible executions of a statement, a calling context slice includes only those program components necessary to capture the execution of a statement in a particular calling context. Together with Differences, it is possible to test Modified by running Differences on a smaller number of test cases. This is more efficient than running Modified on a large number of test cases. A prototype implementation has been built to examine and illustrate these algorithms.

Source Code Analysis: A Road Map

The automated and semi-automated analysis of source code has remained a topic of intense research for more than thirty years. During this period, algorithms and techniques for source-code analysis have changed, sometimes dramatically. The abilities of the tools that implement them have also expanded to meet new and diverse challenges. This paper surveys current work on source-code analysis. It also provides a road map for future work over the next five-year period and speculates on the development of source-code analysis applications, techniques, and challenges over the next 10, 20, and 50 years.

The application of program slicing to regression testing

Abstract Software maintainers are faced with the task of regression testing: retesting a program after a modification. The goal of regression testing is to ensure that bug fixes and new functionality do not adversely affect the correct functionality inherited from the original program. Regression testing often involves running a large program on a large number of test cases; thus, it can be expensive in terms of both human and machine time. Many approaches for reducing the cost of regression testing have been proposed. Those that make use of program slicing are surveyed.

A survey of empirical results on program slicing

Abstract A program slice extracts a semantically meaningful portion of a program, based upon a user-selected slicing criterion. As the study of program slicing has matured, a growing body of empirical data has been gathered on the size of slices, slicing tools and techniques, the applications of slicing, and the beneficial psychological effects of slices on the programmers who use them. Empirical work on these topics is surveyed, highlighting trends and areas where additional empirical investigation is desirable, either because of contradictory findings or scarcity of results in the existing body of empirical knowledge.

Program integration for languages with procedure calls

Given a program Base and two variants, A and B, each created by modifying separate copies of Base, the goal of program integration is to determine whether the modifications interfere, and if they do not, to create an integrated program that incorporates both sets of changes as well as the portions of Base preserved in both variants. Text-based integration techniques, such as the one used by the Unix diff3 utility, are obviously unsatisfactory because one has no guarantees about how the execution behavior of the integrated program relates to the behaviors of Base, A, and B. The first program integration algorithm to provide such guarantees was developed by Horwitz, Prins, and Reps. However, a limitation of that algorithm is that it only applied to programs written in a restricted language—in particular, the algorithm does not handle programs with procedures. This article describes a generalization of the Horwitz-Prins-Reps algorithm that handles programs that consist of multiple (and possibly mutually recursive) procedures. We show that two straightforward generalizations of the Horwitz-Prins-Reps algorithm yield unsatisfactory results. The key issue in developing a satisfactory algorithm is how to take into account different calling contexts when determining what has changed in the variants A and B. Our solution to this problem involves identifying two different kinds of affected components of A and B: those affected regardless of how the procedure is called, and those affected by a changed or new calling context. The algorithm makes use of interprocedural program slicing to identify these components, as well as components in Base, A, and B with the same behavior.

Evolutionary testing in the presence of loop-assigned flags: a testability transformation approach

Evolutionary testing is an effective technique for automatically generating good quality test data. However, for structural testing, the technique degenerates to random testing in the presence of flag variables, which also present problems for other automated test data generation techniques. Previous work on the flag problem does not address flags assigned in loops.This paper introduces a testability transformation that transforms programs with loop--assigned flags so that existing genetic approaches can be successfully applied. It then presents empirical data demonstrating the effectiveness of the transformation. Untransformed, the genetic algorithm flounders and is unable to find a solution. Two transformations are considered. The first allows the search to find a solution. The second reduces the time taken by an order of magnitude and, more importantly, reduces the slope of the cost increase; thus, greatly increasing the complexity of the problem to which the genetic algorithm can be applied. The paper also presents a second empirical study showing that loop--assigned flags are prevalent in real world code. They account for just under 11% of all flags.

A large-scale empirical study of forward and backward static slice size and context sensitivity

A large-scale study of 43 C programs totaling just over 1 million lines of code is presented. The study includes the forward and backward static slice on every executable statement. In total 2353598 slices were constructed, with an average slice size being just under 30% of the original program. The results also show that ignoring calling-context led to a 50% increase in average slice size and, in contrast to previous results, a 66-77% increase in computation time (due to the increased size). Though not the principal focus of the study, the results also show an average pace for the slicing engine, on a standard PC, of 3 million lines of code per second thereby providing additional evidence for static slicings practicability.

An empirical study of static program slice size

This article presents results from a study of all slices from 43 programs, ranging up to 136,000 lines of code in size. The study investigates the effect of five aspects that affect slice size. Three slicing algorithms are used to study two algorithmic aspects: calling-context treatment and slice granularity. The remaining three aspects affect the upstream dependencies considered by the slicer. These include collapsing structure fields, removal of dead code, and the influence of points-to analysis. The results show that for the most precise slicer, the average slice contains just under one-third of the program. Furthermore, ignoring calling context causes a 50% increase in slice size, and while (coarse-grained) function-level slices are 33% larger than corresponding statement-level slices, they may be useful predictors of the (finer-grained) statement-level slice size. Finally, upstream analyses have an order of magnitude less influence on slice size.

An empirical study of slice-based cohesion and coupling metrics

Software reengineering is a costly endeavor, due in part to the ambiguity of where to focus reengineering effort. Coupling and Cohesion metrics, particularly quantitative cohesion metrics, have the potential to aid in this identification and to measure progress. The most extensive work on such metrics is with slice-based cohesion metrics. While their use of semantic dependence information should make them an excellent choice for cohesion measurement, their wide spread use has been impeded in part by a lack of empirical study. Recent advances in software tools make, for the first time, a large-scale empirical study of slice-based cohesion and coupling metrics possible. Four results from such a study are presented. First, “head-to-head” qualitative and quantitative comparisons of the metrics identify which metrics provide similar views of a program and which provide unique views of a program. This study includes statistical analysis showing that slice-based metrics are not proxies for simple size-based metrics such as lines of code. Second, two longitudinal studies show that slice-based metrics quantify the deterioration of a program as it ages. This serves to validate the metrics: the metrics quantify the degradation that exists during development; turning this around, the metrics can be used to measure the progress of a reengineering effort. Third, baseline values for slice-based metrics are provided. These values act as targets for reengineering efforts with modules having values outside the expected range being the most in need of attention. Finally, slice-based coupling is correlated and compared with slice-based cohesion.