Data Flow Analysis in Software Reliability* LLOYD D. FOSDICK and LEON J. OSTERWEIL INTRODUCTION
Total Page：16
File Type：pdf, Size：1020Kb
Data Flow Analysis In Software Reliability* LLOYD D. FOSDICK and LEON J. OSTERWEIL Department of Computer ~cience, University of Colorado, Boulder, Colorado 80809 The ways that the methods of data flow analysis can be applied to improve software reliability are described. There is also a review of the basic terminology from graph theory and from data flow analysis in global program optimization. The notation of regular expressions is used to describe actions on data for sets of paths. These expressions provide the basis of a classification scheme for data flow which represents patterns of data flow along paths within subprograms and along paths which cross subprogram boundaries. Fast algorithms, originally introduced for global optimization, are described and it is shown how they can be used to implement the classification scheme. It is then shown how these same algorithms can also be used to detect the presence of data flow anomalies which are symptomatic of programming errors. Finally, some characteristics of and experience with DAVE, a data flow analysis system embodying some of these ideas, are described. Keywords and Phrases: automatic documentation, automatic error detection, data flow analysis, software reliability CR Categories: 4.40, 5.24 INTRODUCTION over, during its construction advances were made in global optimization algorithms For some time we have believed that a that are useful to us, which for the same careful analysis of the use of data in a reasons could not be incorporated in the program, such as that done in global opti- system. Our purpose in writing this paper mization, could be a powerful means for is to draw these various ideas together and detecting errors in software and otherwise present them for the instruction and stimu- improving its quality. Our recent experience lation of others who are interested in the [27, 28] with a system constructed for this problem of software reliability. purpose confirms this belief. As so often The phrase "data flow analysis" became happens on such projects, our knowledge firmly established in the literature of global and understanding of this approach were program optimization several years ago deepened considerably by the experience through the work of Cocke and Allen [2, 3, gained in constructing this system, although the pressures of meeting various deadlines 4, 5, 6]. Considerable attention has also made it impossible to incorporate all of our been given to data flow by Dennis and his developing ideas into the system. More- co-workers [9, 29] in a different context, * This work supported by NSF Grant DCR advanced computer architecture. Our own 754)9972. interpretation of data flow analysis is simi- Copyright © 1976, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted provided that ACM's copyright notice is given and that reference is made to the publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Computing Machinery. Computing Surveys, Vol. 8, No. 3, September 1976 306 • Data Flow Analysis In Software Reliability CONTENTS after some designated computation step. If it is not to be used, space for that vari- able may be reallocated or an unnecessary assignment of a value can be deleted. To make this determination it is necessary to look in effect at all possible execution se- quences starting at the designated execution INTRODUCTION step to see if the variable under considera- BASIC DEFINITIONS--GRAPHS tion is ever used again in a computation. BASIC DEFINITIONS--PATH EXPRESSIONS TO REPRESENT DATA FLOW This is a difficult problem in any practical ALGORITHMS TO SOLVE THE LIVE VARIABLE situation because of the complexity of exe- PROBLEM AND THE AVAILABILITYPROBLEM cution sequences, the aliasing of variables, SEGMENTATION OF DATA FLOW DETECTING ANOMOLOUS PATH EXPRESSIONS the use of external procedures, and other CONCLUSION factors. Thus a brute force attack on this ACKNOWLEDGMENTS REFERENCES problem is doomed to failure. Clever al- gorithms have been developed for dealing with this and related problems. They do not require explicit consideration of all execution sequences in the program in order to draw correct conclusions about the use of variables. Indeed, the effort expended in T scanning through the program to gather information is remarkably small. We dis- lar to that found in the literature of global cuss some of these algorithms in detail, program optimization, but our emphasis because they can be adapted to deal with and objectives are different. Specifically, our own set of problems in software re- execution of a computer program normally liability, and turn to these problems now. implies input of data, operations on it, and Data flow in a program is expected to be output of the results of these operations in consistent in various ways. If the value of a sequence determined by the program and a variable is needed at some computation the data. We view this sequence of events step, say the variable a in the step as a flow of data from input to output in which input values contribute to inter- 'y ~--- a-t- 1, mediate results, these in turn contribute to other intermediate results, and so forth then it is normally assumed that at an until the final results, which presumably earlier computation step a value was are output, are obtained. It is the ordered assigned to a. If a value is assigned to a use of data implicit in this process that is variable in a computation step, for example to ~, then it is normally assumed that the central object of study in data flow analysis. that value will be used in a later computa- Data flow analysis does not imply execu- tion step. When the pattern of use of vari- tion of the program being analyzed. In- ables is abnormal, so that our expectations stead, the program is scanned in a syste- of how variables are to be used in a compu- matic way and information about the use of tation are violated, we say there is an variables is collected so that certain in- anomaly in the data flow. Examples of data ferences can be made about the effect of flow anomalies are illustrated in the fol- these uses at other points of the program. lowing FORTRAN constructions. The first An example from the context of global opti- is mization will illustrate the point. This ex- ample, known as the live variable problem, X=A determines whether the value of some X=B variable is to be used in a computation Computing Surveys, Vol. 8, No. 3, September 1976 L. D. Fosdick and L. J. Osterweil • 307 It is clear that the first assignment to X is similar anomalies could be embedded in a useless. Why is the statement there at all? large body of code in such a way as to be Perhaps the author of the program meant to very obscure. The algorithms we will de- write scribe make it possible to expose the pres- ence of data flow anomalies in large bodies of code where the patterns of data flow are X=A almost arbitrarily complex. The analysis is Y=B not limited to individual procedures, as is often the case in global optimization, but it extends across procedure boundaries to Another data flow anomaly is represented by include entire programs composed of many the FORTRAN construction procedures. The search for data flow anomalies can be- come expensive to the point of being totally SUBROUTINE SUB(X, Y, Z) impractical unless careful attention is Z=Y+W given to the organization of the search. Our experience shows that a practical approach Here W is undefined at the point that a begins with an initial determination of value for it is required in the computation. whether or not any data flow anomalies Did the author mean X instead of W, or are present, leaving aside the question of W instead of X, or was W to be in COM- their specific location. This determination of MON? We do not know the answers to the presence of data flow anomalies is the these questions, but we do know that there main subject of our discussion. We will see is an anomaly in the data flow. that fast and effective algorithms can be As these examples suggest, common constructed for making this determination programming errors cause data flow anoma- and that these algorithms identify the lies. Such errors include misspelling, con- variables involved in the data flow anomalies fusion of names, incorrect parameter usage and provide rough information about loca- in external procedure invocations, omission tion. Moreover, these algorithms use as of statements, and similar errors. The their basic constituents the same algorithms presence of a data flow anomaly does not that are employed in global optimization imply that execution of the program will and require the same information, so they definitely produce incorrect results; it im- could be particularly efficient if included plies only that execution may produce in- within an optimizing compiler. correct results. It may produce incorrect Localizing an anomaly consists in finding results depending on the input data, the a path in the program containing the operating system, or other environmental anomaly; this raises the question of whether factors. It may always produce incorrect the path is executable. For example, con- results regardless of these factors, or it sider Figure 1 and observe that although may never produce incorrect results. The there is a path proceeding sequentially point is that the presence of a data flow through the boxes 1, 2, 3, 4, 5, this path anomaly is at least a cause for concern be- can never be followed in any execution of cause it often is a symptom of an error.