Abstract Interprocedural dataflow analysis is useful in compiler optimization, automatic vectorization and parallelization, dataflow anomaly detection, and software maintenance applications such as program revalidation, and software tools that make a program more understandable by showing data dependencies. These applications require the solution of dataflow problems such as reaching definitions, live variables, available expressions, and definition‐use chains. When solving these problems interprocedurally, the context of each call must be taken into account. In this paper, a method to solve this kind of dataflow problem is presented. This method consists of special dataflow equations that are solved for a program flowgraph. In deference to calling context, separate sets, called entry and body sets, are maintained at each node in the flowgraph. The entry set contains calling‐context effects that enter a procedure. The body set contains effects that result from statements in the procedure. By isolating calling‐context effects in the entry set, a call's nonkilled calling context is preserved by means of a simple intersection operation done at the return node for that call. The main advantages of this method are its precision and low complexity, and the fact that the presence of recursion does not affect the accuracy of the result.

Abstract The maintenance or re‐engineering of a program usually begins with considerable effort in understanding the program structure. In this paper, an interactive tool for understanding the structure of non‐object‐oriented programs, known as the Object Finder, is presented. The structure of a program is defined in terms of the groupings of routines and data into modules within the program and the hierarchical relationships among the modules. The Object Finder incorporates two complementary approaches, one being top‐down and the other bottom‐up, to assist the software engineer in understanding the structure of a program based on the object‐like features found in the program. In the top‐down approach, the user obtains an overall understanding of the entire program as a collection of hierarchically organized objects. In the bottom‐up approach, the user obtains a view of the information which is closely related to the components under examination. In both approaches, two methods are used to identify the objects in a program written in a non‐object‐oriented programming language. These methods identify sets of objects based on the data bindings and on the type bindings found in a program. An object is considered as a collection of routines, types, and/or data items of the program. The Object Finder combines the top‐down and bottom‐up approaches while using human input to guide the object identification process. Two examples of using this Object Finder are also presented to demonstrate the capabilities of the approaches to assist the software engineer in attaining a high‐level understanding of the program structure.

A modified attribute-grammar language, to be used for specifying tools in a software maintenance environment, is proposed. This language is called Tool Specification Language (TSL). TSL allows an orderly sharing of specifications between different tools. It also allows the sharing of computed attribute values between different tools. For a suite of related tools that would support the maintenance programmer, using TSL as the specification language would result in a concise, shared specification. There would also be the benefit of less memory space and faster tool execution when computed attribute values are shared.>

The authors propose methodologies to aid in the design recovery of object-like features of a program written in a non-object-oriented language. Two complementary methods, based on an analysis of global data or of data types, are proposed, along with an interactive tool that would combine the two methods while using human input to guide the object identification process. The authors are constructing a prototype interactive software tool to implement these methods for the C language. The intention is to collect data on the user's decisions and reasons for making them so that improved heuristics or knowledge-based-methods could be developed to improve the process.>

A systematic approach for reducing the cost of regression testing and fault localization through the use of incremental data flow analysis is described. Incremental data flow analysis is used to identify that portion of a program affected by a change so that testing efforts can be focused accordingly. The analysis allows the partitioning of existing test cases into relevant, nonrelevant, and invalid classes. This greatly reduces the effort associated with validating a program following modification.>

An integrated life-cycle model is presented for use in a software maintenance environment. The model represents information about the development and maintenance of software systems, emphasizing relationships between different phases of the software life cycle. It provides the basis for automated tools to assist maintenance personnel in making changes to existing software systems. The model is independent of particular specification, design, and programming languages because it represents only certain 'basic' semantic properties of software systems: control flow, data flow, and data structure. The software development processes by which one phase of the software life cycle is derived from another are represented by graph rewriting rules, which indicate how various components of a software system have been implemented. This approach permits analysis of the basic properties of a software system throughout the software life cycle. Examples are given to illustrate the integrated software life-cycle model during evolution.>