Program analysis for software engineering: new applications, new requirements, new tools

In order to play a bigger role in software engineering tools, static analysis techniques must take into account the speciic needs of this application area, in particular in terms of interaction with the user and scalability. This new perspective requires a reexamination of the eld of static program analysis both internally and in connection with related areas like theorem proving and debugging. Despite the very general nature of its principles 2], most of the applications of static analysis so far have been targeted towards optimising compilers. The ee-ciency of many implementations of languages on sequential and parallel machines relies in a crucial way on sophisticated static analysers and there is no reason why this importance should decrease in the future. However, we believe that static analysis should play a much bigger role in another large and very demanding application eld, namely software engineering. In this position paper, we argue that: |There is a large variety of tasks in the software engineering process that could beneet from techniques akin to static program analysis. |This application eld places new needs on static analysers, which should have an impact on their design, both at the conceptual and at the practical level. |This new perspective requires a reexamination of the eld of static program analysis both internally and in connection with related areas that have developed completely independently so far. 1. APPLICATIONS OF STATIC ANALYSIS TO SOFTWARE ENGINEERING We start with a quick review of applications of static program analysis techniques in the eld of software engineering: |Static debugging 5; 9; 1]: program slicing (for a better understanding of the code and the origin of the bugs); automatic proof of properties on deenition-use locations of variables, on the range of array indexes, or on pointer dereferences (to isolate potential errors in memory access), detection of dead code. |Testing 3]: static analysis of programs to help in the construction of eeective test sets, or to optimise non-regression and integration tests. |Proof of simple correctness properties 6; 4; 8]: functional (like dependencies between aspects of variables, or invariants on the shape of data structures) or non-functional (like conndentiality or integrity for security-critical applications). |Understanding and documenting programs, isolating diierences between two versions of a program and dependencies within applications to ease maintenance, software management, and help reverse engineering 5].

[1]  Bernhard Steffen,et al.  Generating Data Flow Analysis Algorithms from Modal Specifications , 1993, Sci. Comput. Program..

[2]  Pascal Fradet,et al.  Shape types , 1997, POPL '97.

[3]  Daniel Jackson ASPECT: an economical bug-detector , 1991, [1991 Proceedings] 13th International Conference on Software Engineering.

[4]  Daniel Le Métayer,et al.  Software architecture styles as graph grammars , 1996, SIGSOFT '96.

[5]  François Bourdoncle,et al.  Abstract debugging of higher-order imperative languages , 1993, PLDI '93.

[6]  Rajiv Gupta,et al.  A demand-driven analyzer for data flow testing at the integration level , 1996, Proceedings of IEEE 18th International Conference on Software Engineering.

[7]  Thomas W. Reps,et al.  The use of program dependence graphs in software engineering , 1992, International Conference on Software Engineering.

[8]  Patrick Cousot,et al.  Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints , 1977, POPL.