Program slicing is a decomposition technique that elides program components not relevant to a chosen computation, referred to as a slicing criterion. The remaining components form an executable program called a slice that computes a projection of the original program’s semantics. Using examples coupled with fundamental principles, a tutorial introduction to program slicing is presented. Then applications of program slicing are surveyed, ranging from its first use as a debugging technique to current applications in property verification using finite state models. Finally, a summary of research challenges for the slicing community is discussed.

Reverse engineering involves a great deal of effort in comprehension of the current implementation of a software system and the ways in which it differs from the original design. Automated support tools are critical to the success of such efforts. We show how program slicing techniques can be employed to assist in the comprehension of large software systems, through traditional slicing techniques at the statement level, and through a new technique, interface slicing, at the module level. 1

Large software systems are difficult to understand and maintain. Program dependency analysis plays a key role in both understanding and maintenance. This paper discusses hidden dependencies among software components that make both understanding and maintenance hard. Hidden dependency is a relationship between two seemingly independent components and it is caused by a data flow inside of a third software components. The paper uses Abstract System Dependence Graphs to define hidden dependencies. It discusses the impact of hidden dependencies on the process of change propagation and also discusses an algorithm that warns about possible presence of hidden dependencies.

In many projects, lexical preprocessors are used to manage different variants of the project (using conditional compilation) and to define compile-time code transformations (using macros). Unfortunately, while being a simple way to implement variability, conditional compilation and lexical macros hinder automatic analysis, even though such analysis is urgently needed to combat variability-induced complexity. To analyze code with its variability, we need to parse it without preprocessing it. However, current parsing solutions use unsound heuristics, support only a subset of the language, or suffer from exponential explosion. As part of the TypeChef project, we contribute a novel variability-aware parser that can parse almost all unpreprocessed code without heuristics in practicable time. Beyond the obvious task of detecting syntax errors, our parser paves the road for further analysis, such as variability-aware type checking. We implement variability-aware parsers for Java and GNU C and demonstrate practicability by parsing the product line MobileMedia and the entire X86 architecture of the Linux kernel with 6065 variable features.

This paper describes the first algorithm that calculates Interprocedural Def-Use Associations in C software systems. Our algorithm accounts for program-point-specific pointer-induced aliases, although it is currently limited to programs using a single level of indirection. We prove the NP-hardness of the Interprocedural Reaching Definitions Problem and point out the approximation made by our polynomial-time algorithm. Initial empirical results are also presented. 3 The research reported here was supported by Siemens Corporate Research and NSF grants CCR-8920078 and CCR-9023628 1/5. 1 Introduction Currently, most software tools ignore program constructs that involve pointers because extant analysis techniques are too approximate. Determining data dependences more precisely in the presence of pointers facilitates the construction of effective debugging, testing and maintenance tools for C systems. Our Interprocedural Def-Use analysis is the first step in solving useful data flow prob...

Interprocedural analysis requires a statically determinable call multigraph to represent the program. Programs that use function pointers or function-valued variables present a difficult problem for static analysis. In C, function pointers can be formal parameters, actual arguments to functions, or global/local variables. The difficulty of precisely determining the call multigraph of a program -- or statically determining the aliases of a function pointer at a call site -- depends on the types of function pointers used (i.e., local or global) [ZR94]. In this study, we have statically gathered empirical information on C function pointer usage to better predict appropriate interprocedural analyses required for C programs. 1 Introduction To interprocedurally analyze programs, the analyzer must be able to statically construct a call multigraph of a program; in other words, the analyzer must be able to statically bind function (or procedure) call sites to the function that will be called a...