A program slice consists of the parts of a program that (potentially) affect the values computed at some point of interest, referred to as a slicing criterion. The task of computing program slices is called program slicing. The original definition of a program slice was presented by Weiser in 1979. Since then, various slightly different notions of program slices have been proposed, as well as a number of methods to compute them. An important distinction is that between a static and a dynamic slice. The former notion is computed without making assumptions regarding a program's input, whereas the latter relies on some specific test case. Procedures, arbitrary control flow, composite datatypes and pointers, and interprocess communication each require a specific solution. We classify static and dynamic slicing methods for each of these features, and compare their accuracy and efficiency. Moreover, the possibilities for combining solutions for different features are investigated....

Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graph representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.

Software productivity has been steadily increasing over the last 30 years, but not enough to close the gap between the demands placed on the software industry and what the state of the practice can deliver [22,39]; nothing short of an order of magnitude increase in productivity will extricate the software industry from its perennial crisis [39,67]. Several decades of intensive research in software engineering and artificial intelligence left few alternatives but sofware reuse as the (only) realistic approach to bring about the gains of productivity and quality that the software industry needs. In this paper, we discuss the implications of reuse on the production, with an emphasis on the technical challenges. Software reuse involves building software that is reusable by design, and building with reusable software. Software reuse includes reusing both the products of previous software projects, and the processes deployed to produce them, leading to a wide spectrum of reuse approaches, from the building blocks (reusing products) approach on one hand, to the generative or reusable processor (reusing processes) on the other [68]. We discuss the implications of such appproaches on the organization, control, and method of software development and discuss proposed models for their economic analysis. Software reuse benefits from methodologies and tools to: 1) build more readily reusable software, and 2) locate, evaluate, and tailor reusable software, the latter being critical for the building blocks approach. Both sets of issues are discussed in this paper, with a focus on application generators and object-oriented development for the first, and a thorough discussion of retrieval techniques for software components, component composition (or bottom-up design) and transformational systems for the second. We conclude by highlighting areas that, in our opinion, are worthy of further investigation.

The first interprocedural modification side-effects analysis for C (MOD_C) that obtains better than worst-case precision on programs with general-purpose pointer usage is presented with empirical results. The analysis consists of an algorithm schema corresponding to a family of MODC algorithms with two independent phases: one for determining pointer-induced aliases and a subsequent one for propagating interprocedural side effects. These MOD_C algorithms are parameterized by the aliasing method used. The empirical results compare the performance of two dissimilar MOD_C algorithms: MOD_C(FSAlias) uses a flow-sensitive, calling-context-sensitive interprocedural alias analysis [LR92]; MOD_C(FIAlias) uses a flow-insensitive, calling-context-insensitive alias analysis which is much faster, but less accurate. These two algorithms were profiled on 45 programs ranging in size from 250 to 30,000 lines of C code, and the results demonstrate dramatically the possible cost-precision tradeoffs. This first comparative implementation of MODC analyses offers insight into the differences between flow-/context-sensitive and flow-/context-insensitive analyses. The analysis cost versus precision tradeoffs in side-effect information obtained is reported. The results show surprisingly that the precision of flow-sensitive side-effect analysis is not always prohibitive in cost, and that the precision of flow-insensitive analysis is substantially better than worst-case estimates and seems sufficient for certain applications. On average MODC (FSAlias) for procedures and calls is in the range of 20% more precise than MODC (F IAlias); however, the performance was found to be at least an order of magnitude slower than MODC (F IAlias).

We examine the functional cohesion of procedures using a data slice abstraction. Our analysis identifies the data tokens that lie on more than one slice as the "glue" that binds separate components together. Cohesion is measured in terms of the relative number of glue tokens, tokens that lie on more than one data slice, and super-glue tokens, tokens that lie on all data slices in a procedure, and the adhe- siveness of the tokens. The intuition and measurement scale factors are demonstrated through a set of abstract transfor- mations.

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.

We apply mathematical concept analysis in order to modularize legacy code. By analysing the relation between procedures and global variables, a so-called concept lattice is constructed. The paper explains how module structures show up in the lattice, and how the lattice can be used to assess cohesion and coupling between module candidates. Certain algebraic decompositions of the lattice can lead to automatic generation of modularization proposals. The method is applied to several examples written in Modula-2, Fortran, and Cobol; among them a>100kloc aerodynamics program.

Traditional, syntax-preserving program slicing simpli es a program by deleting components (e.g., statements and predicates) that do not aect a computation of interest. Amorphous slicing removes the limitation to component deletion as the only means of simpli cation, while retaining the semantic property that a slice preserves the selected behaviour of interest from the original program. This leads to slices which are often considerably smaller than their syntax-preserving counterparts.

©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted

this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research