Advances
in COMPUTERS VOLUME 43
This Page Intentionally Left Blank
Advances in
COMPUTERS EDITED BY
MARVIN V. ZELKOWITZ Department of Computer Science and Institute for Advanced Computer Studies University of Maryland College Park, Maryland
VOLUME 43
ACADEMIC PRESS San Diego New York Boston London Sydney Tokyo Toronto
Find Us on the Web! http://www.apnet.corn
This book is printed on acid-free paper.
@
Copyright 0 1996 by ACADEMIC PRESS, INC
All Rights Reserved. No part of this publication may be reproduced or transmitted in any fonn or by any means, electronic or mechanical, including photocopy, recording, or any information storage and retrieval system, without permission in writing from the publisher.
Academic Press, Inc. A Division of Harcourt Brace & Company 525 B Street, Suite 1900, San Diego, California 92101-4495
United Kingdom Edition published hv Academic Press Limited 24-28 Oval Road, London NW 1 7DX
International Standard Serial Number: 0065-2458 International Standard Book Number: 0-12-012143-3 PRINTED IN THE UNITED STATES OF AMERICA 9 6 9 7 9 8 9 9 0 0 0 1 B C 9 8 7 6 5 4 3 2 1
Contents CONTRIBUTORS . . . . . . . . PREFACE
. . . . . . . . . . . . . . ix ... . . . . . . . . . . . . . . xiii Program Slicing
David W . Binkley and Keith Brian Gallagher
1. Introduction . . . 2. Computing Slices . . 3. Applications of Program References . . . .
. . . . . . . . . . Slicing . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. 2 . 4 . 34 . 45
Language Features for the Interconnection of Software Components Renate Motschnig-Pitrik and Roland T. Mittermeir
1. 2. 3. 4.
Introduction . . . . . . . . . . . . . Different Perspectives and Fundamental Issues . . . A Model for Component Interconnection Specification Survey of Language Paradigms for the Specification of Component Interconnection . . . . . . . . . 5 . Comparison of Features for Expressing Component Interconnections . . . . . . . . . . . . 6. Discussion . . . . . . . . . . . . . . 7. Summary . . . . . . . . . . . . . . Appendix . . . . . . . . . . . . . . References . . . . . . . . . . . . . .
. . . 53 . . . 57 .
.
62
. . .
67
. . . . .
.
. . . . .
. . . . .
86 125 130 132 133
Using Model Checking to Analyze Requirements and Designs
.
Joanne Atlee Marsha Chechik. and John Gannon
1. 2. 3. 4. 5. 6.
Introduction . . . . . . . . . . SCR Requirements . . . . . . . . Model Checking . . . . . . . . . Model Checking Requirements . . . . . Model Checking Designs . . . . . . . Case Study . . . . . . . . . . .
v
. . . . . . 142 . . . . . . 143
. . . . . . 147 . . . . . . 151 . . . . . . 156 . . . . . . 168
vi
CONTENTS
7. Conclusion . References .
. . . . . . . . . . . . . . . . 176 . . . . . . . . . . . . . . . . 177
Information Technology and Productivity: A Review of the Literature Erik Brynjolfsson and Shinkyu Yang
1. The “Productivity Paradox”-A Clash of Expectations and Statistics. . . . . . . . . . . . . . . . . 2. Research on Economy-wide Productivity and Information Worker Productivity . . . . . . . . . . . . . 3. Industry-Level Studies of Information Technology Productivity 4. Firm-Level Studies of Information Technology Productivity . 5 . Contribution to Consumer Surplus and Economic Growth . 6. Conclusion: Where Do We Go from Here? . . . . . . References . . . . . . . . . . . . . . . .
. 179 . 187 192 . 196 . 201 . 205 . 209
The Complexity of Problems William Gasarch
1. Introduction . . . 2. Decision Trees . . . 3. P versus N P . . . 4. Decidable. Undecidable. 5 . Summary . . . . References . . . .
. . . . . . . . . . . . . . . . . . . . . and Beyond . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
216 218 225 233 239 240
3-0 Computer Vision Using Structured Light: Design. Calibration. and Implementation Issues Fred W . DePiero and Mohan M. Trivedi
1. Introduction . . . . . . . . . . . . . . 2 . Introduction to Structured Light Ranging . . . . . . 3. Literature Review and Highlight of Critical Design Issues . 4. Structured Light Acquisition . . . . . . . . . 5 . Calibration of Structured Light Sensors . . . . . . 6. Sensitivity Analysis of Structured Light Sensors . . . . 7. Performance Benchmarks and Ranging Experiments . . 8. Related Research and Concluding Remarks . . . . . References . . . . . . . . . . . . . . .
. . 244 . . 245 . . 249 . . 252
. . 258 . . 264 . . 269 . . 272 . . 275
CONTENTS
AUTHOR INDEX
vii
. . . . . . . . . . . . . . . . 279
SUBJECT INDEX . .
. . . . . . . . . . . . . . . 287
CONTENTS OF VOLUMES I N THISSERIES .
. . . . . . . . 297
This Page Intentionally Left Blank
Contributors Joanne Atlee Currently an assistant professor of computer science at the University of Waterloo in Waterloo, Canada, Dr. Atlee received a B.S. in computer science and physics from the College of William and Mary, Williamsburg, Virginia, and an M.S. and a Ph.D. from the University of Maryland at College Park. Her research interests include requirements specification, automated verification of requirements and design, CASE tools, and feature interactions. David W. Binkley An assistant professor of computer science at Loyola College in Baltimore, Maryland, Dr. Binkley has been a member of the faculty since 1991. In the spring of 1992 he joined the National Institute of Standards and Technology (NIST) in Gaithersburg, Maryland, as a visiting faculty researcher. His research interests include a compiler feedback project, currently supported by the National Science Foundation, software maintenance cost-reduction tools, and software issues in high integrity software system assurance (at NIST). Erik Brynjolfsson As the Douglas Drane Career Development Associate Professor of Information Technology at the MIT Sloan School of Management, Dr. Brynjolfsson’s research analyzes how the structures of markets and firms are being transformed by advances in information technology and assesses the productivity of information technology investments. He has written numerous articles in academic journals, is on the editorial boards of the Communications of the A CM, Information Systems Research, the Journal of Electronic Commerce, and Information Technology and People, and has served as the editor of special issues of Management Science and Journal of Organizational Computing. Professor Brynjolfsson holds both a B.S. and an M.S. in applied mathematics and decision science from Harvard and a Ph.D. in managerial economics from MIT. Before joining the MIT faculty, he directed a software consulting and development firm and created two of the first courses on artificial intelligence at Harvard University. Marsha Chechik Ms. Chechik graduated summa cum laude from the University of Maryland Baltimore County in 1991,majoring in computer science and mathematics. She received an M.S. in computer science from the University of Maryland at College Park in 1994. She is the recipient of the Washington, D C Association for Computing Machinery Master’s grant and is currently pursuing a Ph.D. in computer science at the University of
ix
X
CONTRIBUTORS
Maryland. Her research interests include formal methods, program analysis and verification, and software safety. She is a student member of the IEEE Computer Society and the Association for Computing Machinery.
Fred W. DePiero Dr. DePiero received his B.S. and M.S. in electrical engineering from Michigan State University in 1985 and 1987, respectively. H e worked as a development associate at Oak Ridge National Laboratory until 1993. There he was involved in a variety of real-time image processing projects including a high-compression video transmission system for remote driving and various structured light measurement systems. His research goals focused on real-time performance and calibration techniques. He is currently a research associate and Ph.D. candidate at the University of Tennessee. His structured light work continues on a high-performance measurement system for railway maintenance and on a multipurpose ranging system for industrial applications. His research goals have broadened to include graph-based object recognition and real-time range image segmentation. Keith Brian Gallagher Dr. Gallagher received a B.A. in mathematics from Bucknell University, an M.S. in both mathematics and computer science from the University of Michigan, and a Ph.D. in computer science from the University of Maryland Graduate School at Baltimore. H e is now an associate professor of Computer Science at Loyola College in Baltimore, Maryland. His interests include software maintenance process modeling, empirical studies of maintainers, and software transformations. Dr. Gallagher has received the Research Initiation Award from the National Science Foundation, is a faculty research associate at the National Institute of Standards and Technology in Gaithersburg, Maryland, and dances in local ballet productions. John Gannon A professor and Chairman of the Department of Computer Science at the University of Maryland, Dr. Gannon has been a faculty member there since 1975. He conducts research on automated applications of formal methods to software development activities, e.g., proving that requirements enforce safety properties and deriving test oracles from formal specifications. Professor Gannon has also worked for the National Science Foundation directing the Software Engineering Program. He is a member of the editorial boards of IEEE Transactions on Software Engineering and ACM Computing Surveys and is currently serving as Vice Chair of ACM SIGSOFT. William Gasarch An associate professor in the Department of Computer Science and Institute for Advanced Computer Studies at the University of Maryland, College Park, Maryland, Dr. Gasarch received a Ph.D. from
CONTRIBUTORS
xi
Harvard University before joining the faculty at the University of Maryland. His research interests include recursion theory and complexity theory. Roland Mittermeir Dr. Mittermeir is currently Professor in Informatics at the Universitat Klagenfurt in Austria. As an Austrian, he received a Mag. SOC. oec. from the Wirtschaftsuniversitat Wien in Vienna, a Dip1.Ing. in Informatics from the Technische Universitat in Vienna, and a Ph.D. from the Wirtschaftsuniversitat Wien. His academic career started at the Technische Universitat Wien. After positions at the University of Texas at Austin and the University of Maryland at College Park, he joined the Universitat Klagenfurt in 1984 where he was founding chairman of the Department of Informatics. His research interests are in various areas of software engineering, notably in software reuse, software re-engineering, software process modeling, and design. Renate Motschnig-Pitrik An assistant professor of computer science at the Department of Applied Computer Science and Information Systems at the University of Vienna, Dr. Motschnig-Pitrik received a Dip1.-Ing. in 1982 in computer science and a Ph.D. in 1988 from the University of Technology in Vienna, where she has been on the faculty of the Department of Applied Computer Science and Systems Analysis. She has repeatedly been a visiting researcher at the Department of Computer Science at the University of Toronto. In the winter term of 1995/1996she joined the faculty of the Rheinisch-Westfalische Technische Hochschule Aachen, working as visiting professor at the Department of Information Systems. Her primary research interests include various aspects of software engineering and knowledge representation, in particular the specification of abstraction concepts, abstraction-based software development, and cognitive issues in the development of information systems. She currently works on viewpoint abstraction, the application of context mechanisms, and meta-modeling. Mohan M. Trivedi A professor in the Electrical and Computer Engineering Department of the University of Tennessee, Knoxville, Dr. Trivedi has established the Computer Vision and Robotics Research Laboratory there. H e and his team are engaged in a broad range of sponsored research studies in sensor-based mobile manipulators, active perception and machine vision, interactive graphical interfaces for human-machine systems, and remote sensing. He received the B.E. (Honors) in electronics from the Birla Institute of Technology and Science, Pilani, India, in 1974 and the M.E. and Ph.D. in electrical engineering from the Utah State University in 1976 and 1979, respectively. Dr. Trivedi serves as the Editor-in-Chief of Machine Vision and Applications, the official journal of the International Association of Pattern Recognition. He serves or has served as an associate editor of
xii
CONTRIBUTORS
IEEE Transactions on Systems, Man, and Cybernetics, Pattern Recognition, the International Journal of Applied Intelligence, the International Journal of Approximate Reasoning, and Optical Engineering Reports. He served as Chairman of the Robotics Technical Committee of the Computer Society of the IEEE (1987-1989). Currently, he chairs the Pattern Recognition, Image Processing and Computer Vision Committee of the IEEE Systems, Man, and Cybernetics Society.
Shinkyu Yang A graduate student at MIT Sloan School of Management working toward a Ph.D., Mr. Yang received a B.S. in physics at Seoul National University and an M.S. in management at MIT Sloan School. Before joining MIT, he worked as a software engineer and information systems planning manager. H e is studying information technology’s impact on various measures of economic performance.
Preface Advances in Computers, published since 1960, is an anthology of some of the most important developments within the information technology field over the past year. Each volume contains from five to seven chapters that describe in depth important facets of this increasingly significant component of our technological universe. This series of books fills an important place in the technical publication field. Authors are given the space to fully expound upon their expertise without the usual constraints of a journal article. This provides for a detailed analysis of the topic under discussion. The subject matter published here can range among all aspects of computer science and engineering. While my personal interest centers on software engineering, chapters on systems, hardware, languages, vision, artificial intelligence, business applications, and theory also have appeared. I am increasingly looking for papers on networking and distributed computing, given the emergence of the Internet in the mid-1990s as the major technological advance of the decade. This volume contains six chapters that cover the spectrum of business practices, software engineering, theory, and vision. I hope you find these topics of interest. In the first chapter, David W. Binkley and Keith Brian Gallagher discuss “Program Slicing.” In program slicing, a technique first described in the early 1980s, you isolate only those statements of a program that affect a given variable of interest. That limits the amount of information you need to look at from the entire source program to a manageable subset of those statements of interest. This allows you to find errors or other problems with a program more easily. Dr. Binkley and Dr. Gallagher give a short historical perspective on slicing and then give applications of slicing in the software development, software testing, and maintenance domains. In the second chapter, “Language Features for the Interconnection of Software Components,” by Renate Motschnig-Pitrik and Roland T. Mittermeir, the authors discuss important problems in linking components in large, complex systems. While we have technologies, such as structured programming, for the design of small modules, we still d o not have easy ways that limit the complexity of the interaction among the many modules of large systems. In particular, this chapter discusses language constructs, so-called Component Interconnection Languages, and describes the various ways language design can be used t o aid in this communication problem.
xiii
xiv
PREFACE
In the third chapter, the third software engineering chapter in this volume, “Using Model Checking to Analyze Requirements and Designs,” Joanne Atlee, Marsha Chechik, and John Gannon discuss the technique of model checking as an aid to software design. Model checking is a formal specification technique by which the requirements for a process are specified by state transitions. These transitions are then subject to execution by various testing tools in order to show that the specifications are consistent. Erik Brynjolfsson and Shinkyu Yang in “Information Technology and Productivity: A Review of the Literature” discuss the relationship between information technology and productivity. Although organizations rushed to computerize their operations in the 1970s and 1980s, the promised increases in productivity did not seem to occur at the same rate. This was seen as a damaging assessment of the “computer revolution.” However, a more careful analysis of the data shows that computers have had a positive effect. This chapter examines three dimensions of the productivity puzzle and reviews four possible explanations for it: mismeasurement, lags, redistribution, and mismanagement. One of the more intriguing questions to ask in computer science is “How long will that program run?” While we would all like to program more efficiently and have our programs run faster, it is important to know that there are limits to how short the computation time for a solution to a problem may be. In “The Complexity of Problems,” Professor William Gasarch discusses a hierarchy of problems that take an increasingly longer time to solve, no matter how clever a programmer you are or how fast a machine you purchase. Understanding these limits is an important criterion to meet before tackling any new program design. In the final chapter of this volume, “3-D Computer Vision Using Structured Light: Design, Calibration, and Implementation Issues,” Fred W. DePiero and Mohan M. Trivedi discuss an important aspect of computer vision. In robotic applications it is often necessary that the equipment be able to “see” in three dimensions, yet cameras provide a two-dimensional view of the world. This chapter discusses several computational methods by which three-dimensional objects can be developed from such twodimensional viewing. I thank the authors for their contributions to this book. Each chapter requires a significant effort, and I hope that you find the topics informative. Please let me know if you would like to see a topic covered in a future volume of this series. My Internet address is
[email protected]. MARVIN V. ZELKOWITZ
Program Slicing DAVID W. BINKLEY AND KEITH BRIAN GALLAGHER Loyola College in Maryland Baltimore, Maryland
A hundred times every day, I remind myself that my inner and outer life depends on the labors of other men, living and dead, and that I must exert myself in order to give in the measure as I have received and am still receiving. A. Einstein
Abstract Program slicing is a technique for reducing the amount of information that needs to be absorbed by a programmer. Given a point of “interest” in a program, described by a variable and a statement, a program slice gives all the statements that contributed to the value of the variable at the point, and elides unnecessary statements. This chapter surveys techniques for computing program slices and the applications of program slicing to development, testing, maintenance, and metrics.
Introduction. . . . . . . . . . . . . . . . , . . . . . . 1.1 A Brief History. . . . . . . . . . . , . . . . . . . 2. Computing Slices . . . . . . . . . . . . . . , . . . . . 2.1 Slicing Control-Flow Graphs. . . . . . . . . . . . . 2.2 Slicing as a Graph-Reachability Problem . . . . . . . 2.3 Dynamic Slicing as a Data-Flow Problem. . . . . . . 2.4 Dynamic Slicing as a Graph-Reachability Problem . . 2.5 Alternative Approaches to Computing Program Slices. 3. Applications of Program Slicing . . . . . . . . . . . . . 3.1 Differencing . . . . . . . . . . . . . . . . . . . . 3.2 Program Integration. . . . . . . . . . . . . . . . . 3.3 Testing. . . . . . . . . . . . . . . . . . . . . . . 3.4 Debugging . . . . . . . . . . . . . . . . . . . . . 3.5 Software Quality Assurance . . . . . . . . . . . . . 3.6 Software Maintenance. . . . . . . . . 3.7 Reverse Engineering . . . . . . . . . . . . . . . . 3.8 Functional Cohesion . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . 1.
. .
1 ADVANCES I N COMPUTERS, VOL. 43
. . . . .
.
. . . .
. . .
.
. . . . . . . . . . . . . .
. . . . .
. . . . . . . . . .
. . .. .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
...
. . . . . . ... . . . . . . . . . . . . . . . . . .
. . ............. I
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3 4 5 12 22 26 31 34 35 36 36 38 40 42 43 44 45
Copyright 0 1996 by Academic Press, Inc. All rights of reproduction in any form reserved.
2
DAVID W. BINKLEY AND KEITH B. GALLAGHER
1. Introduction At the fifteenth International Conference on Software Engineering (ICSE) in 1993, Mark Weiser received recognition for the best paper at the fifth ICSE. Weiser reported that “Program Slicing” [90], the conference paper, and its journal incarnation of the same name [93], were cited about 10 times a year from 1984 to 1989 and about 20 times a year in 1990 and 1991. Our search of the “Science Citation Index” found 9 citations in 1992; 9 citations in 1993; and 15 citations in 1994, and included universities in 10 countries and 8 industrial laboratories. This is a lower bound as our bibliography has only 7 items that do not cite [93]. Since so many researchers and practitioners have been citing this seminal work, herein we attempt to collate, summarize, and organize the results that have followed. Program slicing is a decomposition technique that extracts from a program statements relevant to a particular computation. Informally, a slice provides the answer to the question “What program statements potentially affect the computation of variable v at statements?” An observer viewing the execution of a program and its slice cannot determine which is which when attention is focused on statement s. It is as if the observer has a window through which only part of the program state can be seen as illustrated by the “clear window” in Fig. 1. The utility and power of program slicing comes from the ability to assist in tedious and error-prone tasks such as program debugging [l, 46, 50, 60-62, 84, 911, testing [3, 11, 15, 18, 27, 47, 50, 53, 831, parallelization [21, 921, integration [78, 39,76,77, 791, software safety [29], understanding [22, 52, 65, 711, software maintenance [28, 54, 66, 70, 73, 741, and software metrics [58, 59, 68, 671. Slicing does this by extracting an algorithm whose
I
-
I
?
FIG. 1. The programmer’s view of a slice.
PROGRAM SLICING
3
computation may be scattered throughout a program from intervening irrelevant statements. Consequently, it should be easier for a programmer interested in a subset of the program’s behavior to understand the slice.
1.1 A Brief History This section provides a brief history of program slicing and introduces the principal terminology. A slice is taken with respect to a slicing criterion <s, v > , which specifies a location (statement s) and a variable (v). This can be easily extended to slicing with respect to a collection of locations and a collection of variables at each location by taking the union of the individual slices. However, to simplify the exposition, we present definitions for the single statement and single variable case. Program slices, as originally introduced by Weiser [89, 90, 931, are now called executable backward static slices. Executable because the slice is required to be an executable program. Backward because of the direction edges are traversed when the slice is computed using a dependence graph. Finally, static because they are computed as the solution to a static analysis problem (i.e., without considering the program’s input). Weiser’s requirement that a slice be executable provided an empirical validation of the concept. Although this seems reasonable, many applications of program slicing (e.g., debugging) do not require executable slices. This issue is considered in Section 2. Weiser originally used a control-flow graph as an intermediate representation for his slicing algorithm. Ottenstein et al. [24, 691 later noted that backward slices could be efficiently computed using the program dependence graph as an intermediate representation by traversing the dependence edges backwards (from target to source). This observation was pursued vigorously and rigorously by Honvitz et al. [36-40,42-44,78,79,82], who introduced the notion of forward slicing in [44]. Informally, a forward slice answers the question “What statements are affected by the value of variable v at statement s?” Finally, Korel and Laski introduced the notion of dynamic slicing [49, 511: a slice computed for a particular fixed input. The availability of runtime information makes dynamic slices smaller than static slices, but limits their applicability to that particular input. As with Weiser’s algorithm, Korel and Laski’s algorithm uses a control-flow graph as an intermediate representation. Agrawal and Horgan later presented a dynamic slicing algorithm that used the program dependence graph as an intermediate representation [5, 61. This chapter is organized into three major sections. Section 2 discusses static slicing as a data-flow problem and as a graph-reachability problem; then we discuss dynamic slicing as a data-flow problem and as a graph-reachability
4
DAVID W. BINKLEY AND KEITH B. GALLAGHER
problem; and closes with a collection of alternative methods for computing slices. The third section looks at applications of the idea of program slicing, without regard to any particular method of computing the slice.
2. Computing Slices The following terminology is used in this section to discuss the computation of slices.
Definition 1: Graph. A directed graph G is a set of nodes N and a set of edges E C N X N. For edge (n, m ) E E, m is an immediate successor of n and n is an immediate predecessor of n. G contains two special nodes, ninitial, which has no predecessors, and which has no successors. Furthermore, there is a path from ninirial to every node in G and a path from nfinal W to every node in G-’, the inverse graph of G. Definition 2: Control-Flow Graph. A control-flow graph for program P is a graph in which each node is associated with a statement from P and the edges represent the flow of control in P. Let V be the set of variables in P. With each node n (i.e., each statement in the program and node in the graph) associate two sets: REF ( n ) ,the set of variables whose values are referenced at n, and DEF (n),the set of variables whose values are defined at n. Definition 3: Program Slice. For statement s and variable v, the slice of program P with respect to the slicing criterion <s,v> includes only W those statements of P needed to capture the behavior of v at s. Exactly what is meant by “capture” varies. The most intuitive definition is presented in the definition of an executable slice. Other definitions are examined later in this section.
Definition 4: Executable Program Slice. For statement s and variable v, the slice S of program P with respect to the slicing criterion <s, v > is any executable program with the following properties: 1. S can be obtained by deleting zero or more statements from P. 2. If P halts on input I, then the value of v at statement n each time n is executed in P is the same in P and S. If P fails to terminate normally’ n may execute more times in S than in P, but P and S compute the W same values each time n is executed by P.
’
A program fails to terminate normally if it diverges or terminates abnormally, for example, with a division by zero error.
PROGRAM SLICING
5
Note that every program has itself as a slice on any criterion.
Example. The program of Fig. 2 never executes Statement 5, while the slice on <5, c> includes only Statement 5, which is executed once. 2.1
Slicing Control-Flow Graphs
This section describes computing a slice as the solution to a data-flow problem using a control-flow graph as an intermediate representation. It considers a progression of harder slicing problems beginning with slicing straight-line programs, then considering structured control flow, unstructured control flow, data structures, and, finally, procedures. Computing a slice from a control-flow graph is a two-step process: First requisite data-flow information is computed and then this information is used to extract the slice. The data-flow information is the set of relevant variables at each node n. For the slice with respect to <s, v > , the relevant set for each node contains the variables whose values (transitively) affect the computation of v at s. The second step identifies the statements of the slice. These include all nodes (statements) II that assign to a variable relevant at n and the slice taken with respect to any predicate node that directly controls n’s execution.
2.1.1 Slicing Flow Graphs of Straight-L ine Programs Straight-line code contains only assignment statements executed one after the other. For such code the additional slices with respect to predicate nodes are not required. We begin by assuming that expression evaluation does not alter the values of its operands. Relevant sets for the slice taken with respect to
are computed as follows [60]:
1; 1 1
1. Initialize all relevant sets to the empty set. 2. Insert v into relevant(n). t;;;ats
1 2
c=o while ( TRUE )
4 endwhile 5 c=2 FIG. 2. “Sliceable” divergent program and the convergent slice taken with respect to <5, c>.
6
DAVID W. BINKLEY AND KEITH B. GALLAGHER
3. For m,n's immediate predecessor, assign relevant(m) the value (relevant(n) - DE F(m)) u (REF(m) if relevant(n) n DEF(m) # 0). 4. Working backwards, repeat step 3 for m's immediate predecessors until n,nit,u/is reached.
Example. Figure 3 shows the relevant sets for a slice taken with respect to <8, a>. The relevant sets are computed from line 8 to line 1. For example, relevant(7) = (relevant(8) - DEF(7)) U (REF(7) if relevant(8) n DEF(7) # 0) = ({a} - {a}) u ((6, c} if {a} f l {a} # 0) = {b, c}, and relevant (2) = ({b, c} - {c}) U (0 if (6, c} n {c} # 0) = {b}. If we were interested in some variable other than a, the computation of the relevant sets would be different; thus, different relevant sets must be computed for different slices. The relevant sets may be viewed as a flow of sets of variables; the slice is the set of statements that disturb this flow. If no relevant variables are defined at a statement, then the relevant set flows through unperturbed. On the other hand, if a relevant variable is defined, then the statement is added to the slice. In Fig. 3, for example, the slice with respect to <8, a> includes lines 7,6,2, and 1 (line 6 changes the b that is in the relevant set). Note that, in practice, the relevant sets and the statements in the slice are computed in a single pass.
-
2.1.2 Slicing Structured Programs In straight-line programs each statement has a single unique predecessor. In the presence of structured control flow, a statement may have multiple control predecessors. The preceeding algorithm requires three modifications to handle this: first, the inclusion of control sets; second, a rule for combining relevant sets at control join points; and, finally, iteration of the relevant set computation.
n
d=3 a=d
d=b+d b=b+1
print a
a
FIG. 3. Relevant sets for <8. a>.
7
PROGRAM SLICING
-
n statement 1 b=l 2 c=2 3 d=3 4 a=d 5 if ( a ) t h e n 6 d=b+d 7 c=b+d 8 else 9 b=b+1 10 d=b+1 11 endi f 12 a = h + c 13 print a -
control(n)
refs(,)
d a b,d b,d
5 5 5
b h
8 8
h,c a
FIG.4. Control sets.
The control set control(n) associates with node (statement) n, the set of predicate statements that directly controls n’s execution [60].The use of a set here facilitates the transition to unstructured control flow in Section 2.1.3. For a structured program, control(n)contains a single entry, the loop or conditional statement that controls the execution of n, or is emply, when n is a top-level statement. For example, in Fig. 4 control(6) includes statement 5, the if ( a ) then; the control sets for statement 9 includes statement 8, the else, whose control set also includes statement 5. Whenever a statement is added to the slice, the members of its control set, k, are added to the slice along with statements in the slice taken with respect to . At join points (where two nodes have the same predecessor), the relevant set is the union of the relevant sets of the two nodes. For example, in Fig. 5, relevant(5) is the union of relevant(6) and relevant(9). This assumes that n 1 2 3 4 5 6
7 8 9
10
control( n )
5 5 5 8 8
11
12 13 FIG.5. Relevant sets on a
at
13.
8
DAVID W. BINKLEY AND KEITH B. GALLAGHER
the expression in the conditional at the join point has no side effects. If it does, then after the union, step 3 of the relevant set computation must be performed to update the set to account for the side effects of the expression.
Example. Figure 5 shows the data necessary to calculate the slice with respect to <13, a> of the program shown in Fig. 4. The slice is normally computed in conjuction with the relevant sets: Working backward from l Refevant(l3) # 0, line 12 is included in the slice line 13, since DEF(12) f and its relevant set is assigned (b, c}. No change occurs at line 11. Line 10 in included in the slice because DEF(10) fl Refevant(l1)# 0; refevant(l0) is assigned {c, d}. Next, lines 5 and 8 are included in the slice because controf(l0) includes 8 and controf(8) includes line 5. Along with these lines, the lines in the slices with respect to <8, REF@)> = <8,0> and <5, REF(5)> = <5, a> are also included. These add to the slice lines 4 and 3. Finally, line 6 completes the slice. The third change is required to handle loops. The absence of loops allows a slice to be computed in a single pass over the control-flow graph; the presence of loops requires iteration over parts of the graph, in particular, iteration over each loop until the relevant sets and slice stabilize. Hausler [35] has shown that the maximum number of iterations is the same as the number of assignment statements in the loop. Figure 6 shows how the upper bound is reached.
2.1.3 Slicing Unstructured Programs The addition of goto statesments, and its restricted forms such as return, exit, break, and continue, complicates the construction of the control sets. One solution is to restructure the program as goto-less [56] and then slice. The drawback to this method is that the structured version may be significantly textually dissimilar from the original. Lyle [60] proposed a simple and conservative solution to slicing over unstructured control flows: if a goto statement has a nonempty relevant
x2 = XI
FIG. 6. A while statement that needs n passes to compute a slice when x , is in the criteria.
PROGRAM SLICING
9
set, include it in the slice. The targets of the goto are included, and so on until the slice stabilizes. An alternative approach [26] is to note that goto statements are associated with labels. Rather than look for goto statements to include in the slice, look for labeled statements that are included in the slice. Then include only the goto statements that branch to these labels. This algorithm was devised for a language in which the only labels are targets of goto’s,a labeled statement does no computation, and does not have explicit compound statements. That is, statements of the form
if ( b
then { /* compute X */ ) else { / * compute Y */
are replaced by the semantically equivalent:
if ( b )
goto L1 /* compute Y * / goto L2
Ll :
/ * compute X * / L2 : Each statement of the form
label :
statement ;
is transformed to the semantically equivalent
label : null ; statement ; Definition 5: Labeled Block. A labeled block is a basic block’ that begins with a labeled statement and ends when one of the following occurs.
* A basic block [48] is a sequence of consecutive instructions that are always executed from start to finish.
10
DAVID W. BINKLEY AND KEITH B. GALLAGHER
1. The basic block ends. 2. Another labeled block begins; that is, another labeled statement occurs.
Definition 6: Pseudo-Label. Let L be the label of the statement that begins a labeled block B. The remaining statements in B are said to have pseudo-label L. On the pass after a pseudo-labeled statement is added to the slice, as each goto statement is examined it is placed in the slice according to whether or not its target (pseudo-)label has already been added to the slice. The noncomputing labeled statements are added if the actual label matches a pseudo-label in the slice.
2.1.4 Arrays, Records, and Pointers The handling of composite structures and pointers requires a change to the DEF(n) and REF(n) sets. A simple approach for arrays is to treat each array assignment as both an assignment and a use of the array. For n: a[i] := x; one may naively assume that DEF(n) = {a} and REF(n) = {i, x}. But the new value of a also depends on the old value of a, so a must also be included. The correct value for REF(n) is {a, i, x}. However, this approach leads to correct, but unnecessarily large slices. To more precisely determine if there is a dependence between a statement that contains an assignment to alf(i)] and a statement that contains a use of a[&)], we must answer the question ‘‘Canf(i) = g(j)?” In general, this question is unanswerable, although it can be solved for some common index expression types. These solutions are often one sided: Algorithms exist to determine if the answer to the question is “no.” Otherwise, no information is obtained. To illustrate this, consider the greatest common divisor (GCD) test applied to the following loop:
i = O while (i < N)
{
*
i + . . . = X[bl * i i = i + 1
X[al
I
+
= ... bo J
1 If @(al, bl) does not divide (bo - ao) then the GCD test demonstrates the absence of a dependence between sI and s2, but if gcd(al, b,) divides
PROGRAM SLICING
11
(bo - a,,), the solution may lay outside the range 0. . . N. Other tests [64, 721 are similarly one sided. If none of these tests can prove the absence of a flow dependence, then one is assumed to exist. This provides a more precise, yet safe, approximation to the correct data relationships. Once this has been done, the slicing algorithm proceeds as in the absence of arrays. Records are simple, if not tedious, to treat in a slicing algorithm. Unlike arrays, each field of a record is identified by a constant (the field’s name). This allows occurrences of record.field to be treated as occurrences of the simple variable record field. The assignment of one record to another is modeled as a sequenceof field assignments. The multiple levels of indirection for both assignment and reference of pointers create difficult problems. One must obtain every possible location to which a pointer could point. If a variable is defined or referenced through a chain of pointers (e.g., *****a), then all intermediate locations in the accessing of the variable must be considered as refed locations. Lyle et al. [63] construct and then prune a pointer state graph (PSS) for expression *ka. The PSSk(a) is a directed graph with single source a and is defined recursively as
PSSk(a) =
(* {v {v
I * a = v}, I v E PSSl(u) A
ifk=O if k = 1 & edge(a, v) E PSSk(a) otherwise & edge(u, v) E PSSk(a).
u E PSS,-l(a)},
PSSk(a)gives the possible references of *ka.It is then pruned: R P ~ ~ k(w) ( a ,= {v E PSSk(a) A dist(v, w)Ik}, where dist (w,v) is the distance, measured in edges, between v and w.RPsSk(a,(w)is used to compute DEF(n) by eliminating the indirect definitions of w that cannot be reached via k levels of indirection from a. See [63] for a detailed discussion.
2.1.5 Interprocedural Slicing Slicing across procedures3 complicates the situation due to the necessity of translating and passing the criteria into and out of calling and called procedures. When procedure P calls procedure Q at statement i, the active criteria must first be translated into the context of Q and then recovered once Q has been sliced. To translate a set of criteria, C, into a called procedure, for each v E relevant(succ(Q)) n actual pararneter(Q) map v -+ w , the corresponding formal parameter of Q. Then generate new criteria . If v E relevant(succ(Q)) n local-definition(Q), that is, a local redefinition of v This section follows closely that of Weiser [93].
12
DAVID W. BINKLEY
A N D KEiTH B. GALLAGHER
occurs, change the line number of criteria involving v to i, the call-site of Q Q. When nZiriaris reached, unmap w + v, and replace ninirial with i. Weiser called this new set of criteria DOWNo(C). This is essentially an in-line replacement of each procedure occurrence, with appropriate substitutions. Globals pass into the called procedure undisturbed if their visibility is not blocked by a variable in Q; thus references to them inside the procedures are captured correctly. This method was introduced early in the development of the idea of slicing and does not address hard questions about pointers, aliasing, function parameters, etc. When P is called from statement j of Q, criteria must be generated to slice up into Q. The new criteria are generated in similar fashion to the calling context. Criteria involving local variables are discarded, so that no undefined references are passed. Criteria involving formal parameters are mapped into the corresponding actual of Q with new line number j. Weiser called this set UPo(C). The sets Downo(C) and UPo(C)are then mapped to functions from and ) UP(CC) = criterion to criterion: Down(CC) = U C E c ~ D O W N o ( C UC-CCUP,(C). Union and transitive closure are defined in the usual way for these relations. Thus (DOWNUUP)*(C)will give a complete set of criteria to obtain the interprocedural slice for any criteria. This conservative, but correct, approximation was improved by [44].
2.2
Slicing as a Graph-Reachability Problem
Ottenstein and Ottenstein [69] observed that the program dependence graph (PDG), used in vectorizing and parallelizing compilers and program development environments, would be an ideal representation for constructing program slices: “Explicit data and control dependence make the PDG ideal for constructing program slices’’ [69]. This section first discusses a variation of the PDG used to compute intraprocedural slices of structured programs and the extensions necessary to slice programs that contain procedures and procedure calls [39]. Both of these algorithms have three steps: 1. Construct a dependence graph from the program. 2. Slice the dependence graph. 3. Obtain a sliced program from the sliced graph.
The advantage of the dependence graph approach is that steps 2 and 3 are efficient. For example, step 2 is linear in the size of the graph. However, step 1, the construction of the PDG is, O(n’) in the number of statements in the program. To focus on the slicing algorithms, this section does not
PROGRAM SLICING
13
discuss how step 1, dependence graph construction, is accomplished (see [24, 34, 39, 44,57, 691 for details).
2.2.1 lntraprocedure Slicing The PDG used for intraprocedural slicing by Horwitz et al. [39] is a modified version of the dependence graph considered by Ottenstein and Ottenstein [69]. The PDG for program P, denoted by Gp, is a directed graph whose vertices are connected by several kinds of edges. The vertices of GPrepresent the assignment statements and control predicates that occur in program P. In addition, G P includes a distinquished vertex called the entry vertex. GP is a multigraph. Not only can it have more than one edge between two vertices, it can have more than one edge of a given kind between two vertices. Edges in GPrepresent dependences among program components. An edge represents either a control dependence or a flow dependence. Control dependence edges are labeled true or false, and the source of a control dependence edge is always the entry vertex or a predicate vertex. A control dependence edge from vertex u to vertex v, denoted by u -+ v, means that during execution, whenever the predicate represented by u is evaluated and its value matches the label on the edge to v, then the program component represented by v will eventually be executed if the program terminates. For structured languages, control dependences reflect the program’s nesting structure. Consequently, PDG GPcontains a control dependence edge from vertex u to vertex v of GP iff one of the following holds: 1. u is the entry vertex, and v represents a component of P that is not nested within any loop or conditional; these edges are labeled true. 2. u represents a control predicate, and v represents a component of P immediately nested within the loop or conditional whose predicate is represented by u. If u is the predicate of a while loop, the edge u -+ v is labeled true; if u is the predicate of a conditional statement, the edge u + v is labeled true or false according to whether v occurs in the then branch or the else branch, respectively. A flow dependence edge from vertex u to vertex v means that the program’s computation might be changed if the relative order of the components represented by u and v were reversed. The flow dependence edges of a PDG are computed using data-flow analysis. A PDG contains a flow
14
DAVID W. BINKLEY AND KEITH B. GALLAGHER
dependence edge from vertex u to vertex v, denoted by u the following hold:
-+
fv, iff all of
1. u is a vertex that defines variable x. 2. v is a vertex that uses x. 3. Control can reach v after u via an execution path along which there is no intervening definition of x. Flow dependences can be further classified as loop carried or loop independent. A flow dependence u -+ f v is carried by loop L, denoted by u -+ IccLiv,if in addition to items 1, 2, and 3 given, the following also hold:
4. There is an execution path that both satisfies the conditions of item 3 above and includes a back edge to the predicate of loop L. 5. Both u and v are enclosed in loop L. A flow dependence u -+ v is loop independent, denoted by u + [;v,if in addition to items 1,2, and 3 there is an execution path that satisfies item 3 above and includes no back edge to the predicate of a loop that encloses both u and v. It is possible to have both u Ic(Li v, and u -+ liv. When there is more than one loop-carried flow dependence edge between two vertices, each is labeled by a different loop that carries the dependence. Figure 7 shows an example program and its PDG. program Main SUM := 0 ;:= 1 whlle i c 1 1 do SUM := SUM+i i:=i+l
Edge Key control dependence d loop-independent Row dependence -I-= loop-carried flow dependence
-.
od prlnt (SUM) end
FIG. 7. An example program, which sums the integers from 1 to 10 and leaves the result in the variable sum, and its program dependence graph. The vertices of the slice of this PDG taken with respect to the final use of i are shown in bold.
PROGRAM SLICING
15
For vertex s of PDG G, the slice of G with respect to s, denoted by Slice(G, s), is a graph containing all vertices on which s has a transitive flow or control dependence (i.e., all vertices that can reach s via flow and/ or control edges): V(Slice(G, s))
=
{VE V ( G ) I v -+LT,,fs}.
The edges of Slice(G, s) are those in the subgraph of G induced by V (Slice(G,s)): E(Slice(G, S))
= {V+~U
U{v+,
E E(G) I v, u E V(Slice(G, S ) ) } u E E(G) I v, u E V(Slice(G, S))}
The vertices of the slice of the PDG shown in Fig. 7 taken with respect to the output vertex for i are highlighted in Fig. 7. Slicing programs with composite data structures involves changing the computation of the flow dependence edge only. Two methods for slicing in the presence of arbitrary control flow (programs containing goto’s) require modification of the control dependence subgraph of the PDG, but not the slicing algorithm. Choi and Ferrante [20] augment the control-flow graph that is used in the construction of the PDG with a set of fall-through edges, that is, the lexcial successor of the goto in the source text. The fall-through edges capture the requisite control flow when a goto statement is deleted from the slice. Ball and Horwitz [7] describe a similar technique in which jump statements are represented by pseudo-predicate vertices, which always evaluate to true. The outgoing control edge labeled true is connected to the target of the jump, while a false successor is connected to the jump statement’s continuation; that is, the statement that would be executed if the jump were a no-op. Harrold et al. [34] describe an efficient construction of PDG’s that captures exact control dependence (i.e., goto’s) but uses neither a control-flow graph or a postdominator tree as an auxiliary structure. This construction technique improves the methods of [7, 201 for construction of the PDG. During the parse, a partial control dependence subgraph, which incorporates exact control, is constructed. The partial control dependence subgraph manages control flow by ordering the nodes implicitly during construction or explicitly by the creation of control edges. The presence of goto’s does require a minor change to step 3 of the slicing algorithm (the projection of a program from the sliced PDG). This change ensures that labels of statements not in the slice are included in the resulting program if a goto to that label is in the slice. Another method for computing slices in the presence of arbitrary control flow avoids changing the PDG at the expense of modifying the slicing
16
DAVID W. BINKLEY AND KEITH 6. GALLAGHER
algorithm use in step 2 [2]. This method maintains two relations postdominator and lexical-successor. The algorithm computes a slice from the graph used by HPR algorithm using step 2 and then looks €or a jump statement not in the slice whose nearest postdominator in the slice is different from the nearest lexical successor in the slice. Such statements are then added to the slice. As with the algorithms in [7, 20, 341, step 3 must be modified to include any necessary labels.
2.2.2 Interprocedural Slicing of Dependence Graphs Interprocedural slicing as a graph-reachability problem requires extending of the PDG and, unlike the addition of data types or unstructured control flow, it also requires modification of the slicing algorithm. The PDG modifications represent call statements, procedure entry, parameters, and parameter passing. The algorithm change is necessary to account correctly for procedure calling context. This section describes the interprocedural slicing algorithm presented in [44], which is based on an extension of the PDG called the system dependence graph (SDG).4 Horwitz et al. [44] introduced the term system dependence graph for the dependence graphs that represents multiprocedure programs. The term system will be used to emphasize a program with multiple procedures. The SDG models a language with the following properties: 1. A complete system consists of a single main procedure and a collection of auxiliary procedures. 2. Parameters are passed by value-result. Techniques for handling parameters passed by reference and for dealing with aliasing are discussed at the end of this section. Horwitz et al. [44] make the further assumption that there are no call sites of the form P(x, x ) or P ( g ) , where g is a global variable. The former restriction sidesteps potential copy-back conflicts. The latter restriction permits global variables to be treated as additional parameters to each procedure; thus, they are not discussed explicitly. An SDG is made up of a collection of procedure dependence graphs connected by interprocedural control- and flow-dependence edges. Procedure dependence graphs are similar to program dependence graphs except that they include vertices and edges representing call statements, parameter The term “SDG” is used because the term “PDG” is associated with graphs that represent single procedure programs.
PROGRAM SLICING
17
passing, and transitive flow dependences due to calls (we will use the abbreviation “PDG” for both procedure dependence graphs and program dependence graphs). A call statement is represented using a call vertex; parameter passing is represented using four kinds of parameter vertices: On the calling side, parameter passing is represented by actual-in and actualout vertices, which are control dependent on the call vertex; in the called procedure, parameter passing is represented by formal-in and formal-out vertices, which are control dependent on the procedure’s entry vertex. Actual-in and formal-in vertices are included for every global variable that may be used or modified as a result of the call and for every parameter; formal-out and actual-out vertices are included only for global variables and parameters that may be modified as a result of the call. Interprocedural data-flow analysis is used to determine the parameter vertices included for each procedure [8, 101. Transitive dependence edges, called summary edges, are added from actual-in vertices to actual-out vertices to represent transitive flow dependences due to called procedures. These edges were originally computed using a variation on the technique used to compute the subordinate characteristic graphs of an attribute grammar’s nonterminals [44].Recently, Reps et al. [80] described a faster algorithm for computing summary edges. A summary edge is added if a path of control, flow, and summary edges exists in the called procedure from the corresponding formal-in vertex to the corresponding formal-out vertex. Note that the addition of a summary edge in procedure Q may complete a path from a formal-in vertex to a formalout vertex in Q’s PDG, which in turn may enable the addition of further summary edges in procedures that call Q. Procedure dependence graphs are connected to form an SDG using three new kinds of edges: 1. A call edge is added from each call-site vertex to the corresponding procedure-entry vertex. 2. A parameter-in edge is added from each actual-in vertex at a call site to the corresponding formal-in vertex in the called procedure. 3. A parameter-out edge is added from each formal-out vertex in the called procedure to the corresponding actual-out vertex at the call site.
Figure 8 shows an example system and the corresponding SDG. (In Fig. 8, as well as in the remaining figures in this article, the edges representing control dependences are not labeled; all such edges would be labeled true.) Interprocedural slicing can be defined as a reachability problem using the SDG, just as intraprocedural slicing is defined as a reachability problem
18
DAVID W. BINKLEY AND KEITH 6. GALLAGHER
procedure Main sum
=a
=I while i < I 1 do call A (sum,I ) I
procedure A ( x . y ) calIAdd(x. y ) call IncremenrQ)
procedureAdd(n, b ) a =a+b return
procedureIncremenr(r) cdIAdd(z, 1 )
return
return
od
print(sum)
intraprocedural flow
-
(loop-independent)
summary
using the PDG. The slices obtained using this approach are the same as those obtained using Weiser’s interprocedural slicing method 2931. However, his approach does not produce slices that are as precise as possible, because it considers paths in the graph that are not possible execution paths. For example, there is a path in the graph shown in Fig. 8 from the vertex of procedure Main labeled “xin : = sum” to the vertex of Main labeled ‘‘i : = Your.”However, this path corresponds to procedure Add being called by procedure A, but returning to procedure Increment, which is not possible.
19
PROGRAM SLICING
The value of i after the call to procedure A is independent of the value of sum before the call, and so the vertex labeled “xjn : = sum” should not be Figure included in the slice with respect to the vertex labeled ‘7: = You(’’ 9 shows this slice. To achieve more precise interprocedural slices, an interprocedure slice with respect to vertex s is computed using two passes over the graph.
‘ I
procedure Main i := I whllei < 11 do d l A (i) od end0
procedure A Cy) d l Increment Cy) return
procedure Add(a. b ) a:=a+b return
procedure /ncremenr(z) cdlAdd(z. 1 ) return
Edge Key
inIraprocedural flow
--k
- ->
(loop-independent)
inuaprwedural flow (Iwp-carried) summary
arheter-in
ammeter-odt
Q/..,Y :=Ym
d l Inc
Zi”
:=y
;
YO”,
=Y
Y”&,
_ _ - - -_ - _ - - -_ _ - -
FIG.9. The SDG from Fig. 8 sliced with respect to the formal-out vertex for parameter z in procedure Increment, together with the system to which it corresponds. Note that this slice correctly excludes the vertex labeled ‘‘x~,,:= sum” in Fig. 8.
20
DAVID W. BINKLEY AND KEITH B. GALLAGHER
Summary edges permit movement across a call site without having to descend into the called procedure; thus, there is no need to keep track of calling context explicitly to ensure that only legal execution paths are traversed. Both passes operate on the SDG, traversing edges to find the set of vertices that can reach a given set of vertices along certain kinds of edges. Informally, if s is in procedure P, then pass 1 identifies vertices that reach s and are either in P itself or procedures that (transitively) call P. The traversal in pass 1 does not descend into procedures called by P or its callers. Pass 2 identifies vertices in called procedures that induce the summary edges used to move across call sites in pass 1. The traversal in pass 1 starts from s and goes backward (from target to source) along flow edges, control edges, call edges, summary edges, and parameter-in edges, but not along parameter-out edges. The traversal in pass 2 starts from all vertices reached in pass 1 and goes backward along flow edges, control edges, summary edges, and parameter-out edges, but not along call or parameter-in edges. The result of an interprocedural slice consists of the sets of vertices encountered during by pass 1 and pass 2, and the set of edges induced by this vertex set. A worklist algorithm for finding the vertices of an interprocedural slice is stated in [44].The (full backward) interprocedural slice of graph G with respect to vertex set S, denoted by Slice(G, S), consists of the sets of vertices identified by pass 1 and pass 2, and the set of edges induced by this vertex set. Slice(G, S ) is a subgraph of G. However, unlike intraprocedural slicing, it may not be feasible (i.e., it may not be the SDG of any system). The problem arises when Slice( G, S) includes mismatched parameters: Different call sites on a procedure include difference parameters. There are two causes of mismatches: Missing actual-in vertices and missing actual-out vertices. Making such systems syntactically legal by simply adding missing parameters leaves semantically unsatisfactory systems [17]. To include the program components necessary to compute a safe value for the parameter represented at missing actual-in vertex v, the vertices in the pass 2 slice of G taken with respect to v must be added to the original slice. A pass 2 slice includes the minimal number of components necessary to produce a semantically correct system. The addition of pass 2 slices is repeated until no further actual-in vertex mismatches exist. The second cause of parameter mismatches is missing actual-out vertices. Because missing actual-out vertices represent dead code no additional slicing is necessary. Actual-out mismatches are removed by simply adding missing actual-out vertices to the slice. A system can now be obtained by projecting the statements of the original system that are in the original slice or added by the preceding two steps.
PROGRAM SLICING
21
These statements appear in the same order and at the same nesting level as in the original system. The details of this algorithm are given in [17].
2.2.3 lnterprocedural Slicing in the Presence of Call-by-Reference Parameter Passing and Aliasing The definitions of the system dependence graph and interprocedural slicing assume that parameters are passed by using value-result parameter passing. The same definitions hold for call-by-reference parameter passing in the absence of aliasing; however, in the presence of aliasing, some modifications are required. Two extreme methods for handling aliasing include transforming the system into an aliasing-free system and generalizing the definition of flow dependence. Translation is done by creating a copy of a procedure for each possible aliasing configuration that it may be called under. Because the number of aliasing configurations is potentially exponential, the cost of this transformation may, in the worst case, be exponential in the maximum number of formal parameters associated with any one procedure. Generalizing the definition of flow dependence makes the pessimistic assumption that any aliases that exist during a particular call to a procedure m a y exist during all calls to the procedure. Such aliases are referred to as m a y aliases. This requires the use of generalized definitions for flow dependence. For example, a flow dependence edge connects vertex v to vertex u iff all of the following hold: 1. v is a vertex that defines variable x. 2. u is a vertex that uses variable y. 3. x and y are potential aliases. 4. Control can reach u after v via a path in the control-flow graph along which there is no intervening definition of x or y.
Note that clause (4) does not exclude there being definitions of other variables that are potential aliases of x or y along the path from v to u. An assignment to a variable z along the path from v to u only over-writes the contents of the memory location written by v if x and z refer to the same memory location. If z is a potential alias of x, then there is only apossibility that x and z refer to the same memory location; thus, an assignment to z does not necessarily over-write the memory location written by v, and it may possible for u to read a value written by v. The first solution produces more precise (smaller) slices than the second at the expense of transforming the system. It is possible to consider interme-
22
DAVID W. BINKLEY AND KEITH B. GALLAGHER
diate solutions to the problem of slicing in the presence of aliasing. Binkley [16] presents an algorithm that is parameterized by a set of aliasing information. The more precise this information, the more precise the slice. In the case of exact information, the same slice is produced as by the transformation approach without replicating procedures. In the case of a maximal approximation (imprecise information), the same slice if obtained as by the generalized dependence approach. In between is a range of possible slices differing only in their precision.
2.3
Dynamic Slicing as a Data-Flow Problem
Korel and Laski [49] introduced the idea of dynamic slicing. Their solution, patterned after Weiser’s static slicing algorithm, solves the problem using data-flow equations. A dynamic slice differs from a static slice in that it makes use of information about a particular execution of a program. Thus, a dynamic slice contains “all statements that actually affect the value of a variable at a program point for a particular execution of the program” rather than “all statements that may affect the value of a variable at a program point for any arbitrary execution of the program” [49]. Most dynamic slices are computed with respect to an execution history (called a trajectory in [49]). This history records the execution of statements as the program executes. The execution of a statement produces an occurrence of the statement in the execution history. Thus, the execution history is a list of statement occurrences.
Example. Two example execution histories are shown in Fig. 10. Superscripts are used to differentiate between the occurrences of a statement. For example, statement 2 executes twice for the second execution producing occurrences 2’ and 22. w Korel and Laski define a dynamic slice, taken with respect to a set of Statement
Number
Program
1
read“) f o r i = l toNdo n=2 if cl then
2 3 4 5
if CZ then
6
a=4
I
else a =6 A
R 8
9
Execution History 1 Input N = l , cl and c2 both true. < I
I,
2’. 3 ’ . 4’. 5 ’ , 6 ’ .8 ’ . 2’. 9’>
Execution History 2 Input N=Z. cl and c2 false on the first iteration and true on the second. ~ 1 ’ . 2 ’ , 3 ’ , 48’.2’.3’,4’.5’,6’,8’,2’,9’> ~,
.?=a
od
printk)
FIG. 10. Two execution histories.
PROGRAM SLICING read(N) for i = 1 to N do a-2 od
23
Execution history of slice
< I 1 , 2 ' , 3 ' , 22, 3 2 2
FIG. 11. A dynamic slice of the program shown in Fig. 10 and its execution history.
variables V, an input Z, and a point P in the execution history (obtained by running the program on Z), as a reduced executable program. The execution history for the execution of this program on input I must satisfy the slice sublist property. Intuitively this property is satisfied if the execution history of the slice is equivalent to the execution history of the original program after removing occurrences of statement not in the slice. Figure 11 shows the Korel and Laski slice of the program shown in Fig. 10 taken with respect to ({a},2, 32). Notice that this slice imprecisely includes 3l, which does not affect the computation a t 3'. Why this occurrence is needed in the Korel and Laski framework and how Agrawal and Horgan remove it are discussed at the end of this section. To formalize the notion of a dynamic slice, we consider the relationship between the execution histories of the program and its slice (on the same input). The execution history of the slice should be obtained by removing occurrences from execution history of the original program. To do this we must remove occurrences of statements not in the slice and remove all occurrences after the occurrence with respect t o which the slice was taken. Formally, we make use of three operators: 1. colfect(list, predicate) = [I E list I predicate(/) = true] 2. front(list, li) = [li E list j <= i] 3. occurrence-of(li, P ) = true iff li is an occurrence of a statement of P.
I
Definition 7: Dynamic Slice. Program P' is the slice of program P taken with respect t o (V, I, p ) if L and L' are the execution histories for P and P', respectively, p' is the occurrence of p in L ' , and the following property is satisfied: front( L', p ' )
=
collect( front(& p), AI.occurrence-of(l, P ' ) )
m
Example. For the slice taken with respect to ({a},2,3') of the program shown in Fig. 10 we have (<1', 2', 3,, 22, 3' >, 3,) = < l', 2l, 3' > and collect (front (< l', 2', 3', 4l, 8', 22, 3*, 42, 9, 6', 82, 23, 9' >, 3'), Af.occurrence-of(f, P ' ) ) = collect( < 11,2', 3l >, Al.occurrence-of(l, P ' ) ) = < 1', 2', 31 >
24
DAVID W. BINKLEY AND KEITH B. GALLAGHER
While for the slice with respect to ({a}, 2, 3') front (< I', 2l, 3',
z2,3'
>, 32) = < I', 2', 3', z2, 32 >.
and collect(front(< 1', 2l, 3', 4', 8', 22, 32,4', 5 ' , 6', 82,23, 9' >, 32), Al.occurrence-of(l, P ' ) ) = collect(< l', 2l, 3', 4',8', 22, 32 >, hl.occurrence-of(l, P ' ) ) = < l', 2', 3', 22, 32 >.
w
Dynamic slices are computed from three data-flow relations computed from the program. The first two capture the flow and control dependences. Unlike static slicing, these definitions refer to the execution history: thus, they capture dependences that actually happened in the particular execution of the program rather than dependences that may occur in some execution of the program as is the case with static slicing. The final relation is explained later. The first definition captures flow dependences that arise when one occurrence represents the assignment of a variable and another a use of that variable. For example, in Fig. 10 when cl and c2 are both false, there is a flow dependence from s3 to sg.
Definition 8: Definition Use (DU). v'DU d w v' appears before in the execution history and there is a variable x defined at v', used at w uJ,but not defined by any occurrence between v' and uI. MI
The second definition captures control dependence. The only difference between this definition and the static control dependence definition is that multiple occurrences of predicates exist. Consequently, care must be taken t o avoid a statement appearing dependent on a predicate from an earlier iteration of a loop.
Definition 9: Test Control ( TC). v'TC ul H u is control dependent on v (in the static sense) and for all occurrences w k between v' and uJ,w is control dependent on v. The definition of a dynamic slice requires the use of front(,!,', p ' ) = collect(front(,!,, p ) , hl.occurrence-of(Z, P ' ) ) . The preceding two relations are insufficient to ensure this. For example, the slice obtained from the program in Fig. 10 taken with respect to ({a},2, 32)using only the preceding two relations is < l', 2', 22, 32 >, which omits 3'. In this example the omission would be benign, but in other examples the slice would not have the correct execution history. Korel and Laski solve this problem by including the following relation. Note that this produces a conservative solution to the problem. That is, some dynamic slices are bigger than they need t o be.
Definition 10: Identity Relation (IR). vr ZR UJ w v
= U.
m
PROGRAM SLICING
25
The relations DU, TC, and ZR are used to formulate the algorithm for a dynamic slicing by computing an ever-growing approximation to the occurrences in the slice. Let E be the execution history produced for program P when run on input I. In the following two equations, only the front of E is of interest to the dynamic slice, since only these occurrences may affect the point where the slice originates. The first approximation to the slice taken with respect to (V,I, li) contains the direct control and data influences: 9 = {v' E front(& ?) I vj TC }'Z U {vj E front(,!?, )'Z I x E V A x is defined at vj but not defined by any occurrence between vj and li}. The slice is found by iterating the following until a fixed point is reached: Si+l = s' U {d E front(E, ?) 1 3uk E S' s.t. v' (DU U TC U ZR) uk}.The iteration from earlier must terminate since E is finite and bounds each S'. To complete the slice, it is necessary to include the occurrence with respect to which the slice was taken. Finally, the sliced program P' is obtained by projecting out of P those statements that have occurrences in the fixed point solution.
Example. The dynamic slice of execution history 2 from Fig. 10 taken with respect to ({a}, 2, 3') is computed as follows DU TC
=
IR
=
=
so = S' =
S2 =
s=
{(l',2')(3', 8')(6', S2)(S2,9')) {(2', 3')(2', 4')(2l, S1)(2', 32)(21,42)(21,S2)(2', 32)(22,42)(22,S2) (42, 5')(5', 6l)) {(2', 2')(2', 23)(22,2')(3', 32)(4', 42)(8', S2)} (2') {l',2') {l',2') = S,; thus the iteration ends. (3') u {l',21) = {l',2', 3'}.
Similar to static slicing, handling unstructured control flow requires modifying the definition of control dependent as used in the definition of TC. Unlike static slicing, the handling of different data types can be done more precisely in a dynamic slice. First consider arrays. Because the subscript value is known at run time, the ambiguity of array accesses in static slicing is gone. The only complication this raises is that different occurrences of a statement may assign different variables (for simplicity, we consider each array element to be a different variable). Records are similarly handled by treating each component as a separate variable. Finally, consider dynamically allocated memory. This can also be handled by giving each newly allocated block of memory a pseudo name. At the end of the next section
26
DAVID W. BINKLEY AND KEITH B. GALLAGHER
we describe how Agrawal and Horgan replace the notion of (pseudo) variable name to improve dynamic slicing in debugging.
2.4
Dynamic Slicing as a Graph-Reachability Problem
Agrawal and Horgan presented the first algorithms for finding dynamic slices using dependence graphs [5].We first consider two simply dynamic slicing algorithms that are imprecise. We then consider two exact algorithms that differ only in their space complexity. The initial description of all four algorithms assumes scalar variables. The extensions necessary to handle complex data structures including, for example, (unconstrained) pointers, arrays, records, and unions are considered at the end of this section. The first two algorithms both mark some portion of a PDG as “executed.” The first marks executed vertices and the second marks executed edges. Both algorithms suffer because they summarize in one place (a vertex or an edge) all the times a statement or dependence edge between statements was executed. The first algorithm initially labels all vertices in the PDG as “unexecuted.” As the program runs, whenever a statement is executed, its corresponding vertex is marked as “executed.” After execution the slice is computed by applying the static slicing algorithm restricted to only marked vertices (and the edges that connect them). Thus, unexecuted vertices will not be in the dynamic slice. As illustrated in Fig. 12 by slice 1, this approach produces imprecise slices because it is possible for a vertex to be marked executed even though it does not actually affect a given computation. For slice 1, s3 is executed, but the assignment at s6 overwrites the value written to a. Therefore, s3 need not be in the dynamic slice. The second algorithm marks “executed edges.” This produces more precise answers by leaving out statements that were executed, but had no influence on the variables in the slice (the corresponding edges were not “executed”). Its imprecision comes in loops where different iterations execute different edges. In slice 1shown in Fig. 12, the marking of edges allows Slice 1: slice on z at s y for the input N = l . where cl and c2 both true: static slice contains s I-s9 dynamic slice (marking nodes) contains s sg, sp dynamic slice(marlringedges)containss,. s 2 , sq-sg. s g , s p Slice 2 slice on z at sp,for input N=2, where cl and c2 false on the first iteration and true on the second: static slice contains s I-sp dynamic slice (marking nodes) contains s I-s6. s 8 . s9 dynamic slice (marking edges) contains sI-sgl$ 8 . sp
FIG. 12. Two dynamic slices of the program of Fig. 10 that show the limitations of the first two dynamic slicing algorithms.
PROGRAM SLICING
27
the algorithm to leave out s3, because the flow dependence edge from s3 to sx is never executed. However, for slice 2, this edge is executed during the first iteration of the loop. Since the second iteration overwrites the value of a, s3 need not be in the dynamic slice. The problem is that different iterations require the marking of different edge occurrences. Summarizing all occurrences on a single edge introduces imprecision.
Example. Figure 12 compares static slicing with these two dynamic slicing algorithms for two different inputs. (Figure 13 shows the PDG for this program.) The static slice taken at (the vertex representing) statement s9 with respect to z contains the entire program because all three assignments to a may reach the use at statement sx.The node-marking dynamic slicing algorithm produces a smaller slice for both inputs because s7 does not execute in either case. These slices, however, unwantedly include s3, which does execute, but which does not affect the computation of z. The edge-marking algorithm correctly handles this in slice 1, because the flow dependence edge from s3 to sx is not executed. However, the weakness of the edge-marking algorithm is shown by slice 2: Although the assignment at s2 does not affect the output value of z, this flow edge is executed by the first iteration of the loop. Because it is marked executed, s2is included in the slice. To omit statements in loops like s3, it is necessary to have multiple occurrences of the vertices and edges in the loop. This is captured by the execution history of a program for a given input. For example, Slice 2 of the program in Fig. 12 produces the execution history < 1, 2', 3l, 4l, 8l,
FIG. 13. The PDG for the program shown in Fig. 10.
28
DAVID W. BINKLEY AND KEITH B. GALLAGHER
22, 3l, 42, 5*, 62, 8*, 23, 9 > where the superscripts are used to denote different executions of the same statement. A dynamic slice can now be defined in terms of a variable, an execution history, and an occurrence of a statement in the execution history. The slice contains only those statements whose execution had some effect on the value of the variable at the occurrence of the statement in the execution history. To obtain this slice a dynamic dependencegraph (DDG) is produced from the execution history. A dynamic dependence graph has a vertex for each occurrence of a statement in the execution history and contains only executed edges. Because a D D G separates the occurrences of the executed vertices and edges, a vertex in a loop may have multiple occurrences, which can have different incoming dependence edges. This removes the imprecision in the two simple approaches. Control dependence edges of the DDG are copies of the control dependence edges from the static dependence graph. There is a single dynamic flow dependence for each variable v referenced at a node n. The source of this edge is computed from the dynamic reaching definitions (DRDs), which are in turn computed from the execution history as follows: DRD(var, empty) = 0. DRD(var, < previous-history
{
I last-node
{last-node} D R D ( var, previous-history)
>) =
if var E def(last-node) otherwise.
Example. Figure 14 shows the DDG for slice 2 of the program shown in Fig. 12. This graph contains two occurrences of s8. The first has an
FIG. 14. The DDG for slice 2 in the example shown in Fig. 12.
PROGRAM SLICING
29
incoming flow dependence edge from sj, whereas the second has an incoming flow dependence edge from s6. Since the only occurrence of s9 has an incoming edge from the second occurrence of s8, s6 and not s3 is included in the slice. The disadvantage of this approach is its space requirement. Since a loop may execute an unbounded number of times, there may be an unbounded number of vertex occurrences. This is clearly unacceptable and, it turns out, unnecessary. A dynamic slice is a subset of the original program; consequently, there can be only a finite number of slices (subsets). The final dynamic slicing algorithm, which computes the same slices as the third algorithm, exploits this fact to limit the size of the dynamic dependence graph. The fourth algorithm considers each new vertex occurrence v as the DDG is built. If a suitable vertex occurrence u exists in the D D G then v is merged into u. Vertex occurrence u is suitable if its slice is the same as the slice of the new vertex occurrence. That is, the statements whose occurrences affect u are the same as the statements that affect v. Note that since the slice is a projection of the D D G back on to the original program, it is possible to combine vertices that are not created from the same statement. The algorithm maintains three sets: DeJinitionNode, which maps a variable’s name to the last vertex occurrence that defines it; PredicateNode, which maps a control statement to its most recent occurrence in the DDG; and ReachingStaternents, which, for each node n, contain all the statements of the original program with an occurrence that reaches n. The slice with respect to an occurrence of statements is simply those statements in ReachingStaternents(s), when the occurrence of s is created.
2.4.1 Dynamic Slicing of Programs with Unconstrained Pointers Agrawal and DeMillo [4] extended the notion of dynamic slicing to programs that contain unconstrained (C-like) pointers. The technique applies also to arrays, constrained (Pascal-like) pointers, records, and other data structures. What makes unconstrained pointers difficult is the loss of the 1-1 mapping from variables assigned and used and from memory locations assigned and used. This is no longer true in the presence of more complex data structures. Although aggregates such as records can be handled by treating each field as a separate variable, and even array elements can be treated as separate elements, since dynamic slicing has access to the run-time index value, pointers present a particularly difficult problem. If we ignore “pointer laun-
30
DAVID W. BINKLEY AND KEITH B. GALLAGHER
dering" through variant records, constrained pointers, such as those found in Pascal, always point to a nameable object of a particular type. Special names are given to objects allocated from the heap. As with records and arrays, runtime information allows us to identify the particular object pointed to by a given pointer. In contrast, unconstrained pointers, such as those found in C, may use or modify arbitrary (unnamed) memory locations. This forces us to generalize first the notion of a variable (var in the proceeding definition of a DRD) to memory cells. Each cell is composed of a starting address and a length. A flow dependence exists between a node that modifies cell, and a node that references cell2 if celll and cell2 overlap. This occurs when there is a nonempty intersection of the set of addresses celll.start, . . . , celll.start + celll.length and cel12.start, . . . , cel12.start + cel12.1ength.For example, if celll represents an assignment to a structure and cell2 represents a use of a field in this structure then the two cells overlap. Notice that an assignment to a field of the structure may only modify part of the cell (the same is true of assignments to an element of an array). In the following definition, the function PreCell(celll, cell2) denotes the part of cell] before cell2.Likewise, PostCell(cell,, cell2)denotes the part of cell] after cell2.
Definition 11: DRD in the Presence of Unconstrained Pointers. Let cell' = def(1ast-node). DRD(cel1, empty) = 0 DRD((address, 0 ) , history) = 0 DRD(cel1, < previous-history I last-node >) if cell r l cell' = 0 D R D (cell, previous-history ) last-node U DRD( PreCell(cel1, cell'),previous-history) U DRD(PostCell(cel1, cell'), previous-history) otherwise This technique works well when dealing with the kind of error shown in the following code (note that different compilers may lay memory out differently):
c i n t i, j,
aC41;
j = 2; f o r ( i = O ; i<=4; a C i l = 0; p r i n t j;
1
it+)
/* i n c o r r e c t l y assigns j=O when i = 4 * /
PROGRAM SLICING
31
When i = 4, the cell defined by a C i 1 = 0 and the cell for j overlap (they are identical in this example). A static slice with respect to j at the end of the program would only include the assignment j = 2. However, the dynamic slice using the preceding definition of a dynamic data definition includes the assignment “a[i]= 0” and the enclosing for loop, an indication that j is getting clobbered by the loop.
2.5 Alternative Approaches to Computing Program Slices 2.5.1 Denotational Program Slicing: Functional Semantics Hausler [35]has developed a denotational approach for slicing structured programs. This approach uses the functional semantics of the “usual” restricted structured language; one with scalar variables, assignment statements, if-then-else statements, and while statements. The Mills semantics [56]is defined for the language; the meaning of the program is determined by a mapping from the variables to values. In the Mills semantics, programs are constructed by composition of statements (i.e., functions from state to state). This permits the definition of a sliceable subprogram: any sequence of statements with the last j statements deleted. Thus slices can be taken at arbitrary points in the program. The function a, : statements X
variables -+ variables
captures the relevant sets, whereas the function 6 : statements x variables += statements
captures the slice. These two functions are defined semantically for each language construct. This yields a precise “Millsian” slice; moreover, it gives primitive recursive finite upper bounds on the number of times repetitive statements must be iterated to obtain the slice. These bounds are linear in the number of assignment statements in the program.
2.5.2
Denotational Program Slicing: Descriptive Semantics
Venkatesh [87] also looked at denotational slicing with the aim of separating semantically based definitions of a program slice from the justification of the algorithm to compute the slice. He has constructed a three-dimensional framework for the comparison and analysis of the definitions of a slice:
32
DAVID W. BINKLEY AND KEITH B. GALLAGHER
1. Executable o r closure5 2. Forward or backward 3. Static or dynamic and then gives semantic definitions of the eight combinations. In [87] the idea of “contamination” was introduced as an extension to the usual semantics of the language in order to clarify the differences of the concepts. This notion is further elaborated on in [30] as a form of error propagation to slice functional programs. In both instances, contaminated values are tracked via the semantics; in the end all contaminated expressions are those that are in the forward slice. Tip [85] gives an alternative characterization using four criteria: 1. 2. 3. 4.
Computation method: data flow, functional, or graph reachability Interprocedural solution or not Control flow: structured or arbitrary Data types: scalars, composites, pointers.
2.5.3 Information Flow Relations Bergeretti and CarrC [13] construct three binary information flow relations on a structured subset of a Pascal-like language. These relations are associated with each program statement (and, hence, inductively over the entire language). The first relation, A, over V X V, where V is the set of variables of the program, associates values of program variables on entry to a statement, S, with values of variables on exit from S. This can be loosely interpreted as “the value of v on entry to S may be used in the evaluation of the expression e in S.” This relation is a formalization of the results of Denning and Denning [23] in secure information flow. The second relation, p, also over V X V, associates values of variables on entry to statement S with the value(s) of the expression parts in S. That is, “the value of v on entry to S m a y be used in obtaining the value w on exit from S.” The entry value of v may be used in obtaining the value of some expression e in S, which in turn may be used in obtaining the exit value of w. The third relation, p, over E X V where E is the set of expressions in the program, associates an expression e with a variable v for statement S iff “a value of expression e in S may be used in obtaining the value of the variable v on exit from S.” For example, if S is the assignment statement “a : = b + c.” then
’ “Closure” comes from the graph-theoretic method used to compute the slice
PROGRAM SLICING
33
Transitive closure of the p relation permits construction of a partial program associated with a variable. This partial program is a program slice taken with respect to the variable at the last statement of the program. Relation p is related to the edges of a dependence graph. For example, it need only be computed once, after which a program slice can be computed in linear time.
2.5.4
Parametric Program Slicing
Parametric program slicing [25] uses graph rewriting to compute constrained slices. The constraint refers to the amount of input available. A fully constrained slice (where input has a fixed constant value) is a dynamic slice, while a fully unconstrained slice is a static slice. A partially constrained slice is computed when some inputs have known values. The resulting slice is smaller than a static slice, but does not require complete execution of the program as with a dynamic slice. Constrained slices are computed using a term graph rewriting system [9]. As the graph is rewritten, modified terms and subterms are tracked. As a result, terms in the final (completely rewritten) graph can be tracked back to terms in the original graph. This identifies the slice of the original graph that produced the particular term in the final graph. A minimal amount of syntactic postprocessing is necessary to convert this “term slice” into a syntactically valid sliced program.
2.5.5
Dynamic Slicing Using Dependence Relations
Gopal [31] describes a technique for computing dynamic slices using dependence relations. This approach abstracts from the program three relations at each statement S: 1. S,, the dependence of statement S on the input value of variable v. 2. v , the dependence of output variable v on statement S. 3. v,, the dependence of output variable w on the input value of variable u. Rules are given for different statement kinds (e.g., assignment and conditional statements) and for sequences of statements. For example, the rules for the composition of statements S’ and S2 are as follows (0 represents the composition operator):
34
DAVID W. BINKLEY AND KEITH B. GALLAGHER
1. s, = s: u ( $ 0 V l ) 2. V S ZE v; u (vf 0 V b ) 3. vU = (v, 0 s,) u ($
n st).
2.5.6 Parallel Slicing Danicic et al. [33] introduce a parallel algorithm for computing backward, static slices. This is accomplished by converting the CFG into a network of concurrent processes. Each process sends and receives messages that name the relevant sets of variables. The significant contribution of this work is that the algorithm outputs the entire set of criteria which would yield the computed slice. Thus the set of all criteria of a given program is partitioned into equivalence classes, with the slice itself used as the partitioning relation.
2.5.7 Value Dependence Graphs The value dependence graph (VDG) [88] is a data-flow-like representation that evolved from an attempt to eliminate the control-flow graph as the basis of the analysis phase and using demand dependences instead. The VDG is a representation that is independent of the names of values, the locations of the values, and when the values are computed. It is a functional representation that expresses computation as value flow. A value is computed if it is needed. Thus, VDG requires explicit representation of stack and heap allocators, I/O ports, etc., so that the value can be obtained. Loops are represented as function calls, so no backward pointing edges are required, as in the CFG. The VDG has two advantages that make it suitable for program slicing: All operands are directly connected to the inputs (via the functional semantics) and the computation is expressed as value flow, so a single VDG represents the slices for every possible computation. The drawback to this approach is that points of computation are lost; values are the only sliceable objects.
3. Applications of Program Slicing This section describes how program slicing is used in a collection of application domains. In applying slicing to these domains, several variations on the notions of program slicing as described in Section 2 are developed. The order of this section in not necessarily the historical order in which the problems were addressed. Rather, they are organized to facilitate presentation. For example, the differencing techniques described in Section 3.1 grew out of the integration work described in Section 3.2.
PROGRAM SLICING
3.1
35
Differencing
Programmers are often faced with the problem of finding the differences between two programs. Algorithms for finding textual differences between programs (or arbitrary files) are often insufficient. Program slicing can be used to identify semantic differences between two programs. There are two related programs differencing problems: 1. Find all the components of two programs that have different behavior. 2. Produce a program that captures the semantic differences between two programs. Dependence graph solutions to both problems have been given. The only reason for not using the data-flow approach is efficiency; the solutions require multiple slices of the same program, which can be done in linear time using dependence graphs. For programs old and new, a straightforward solution to problem 1 is obtained by comparing the backward slices of the vertices in old and new’s dependence graphs Goldand G,,,. Components whose vertices in G,,, and Goldhave isomorphic slices (see [41] for a definition of isomorphic slices) have the same behavior in old and new [82]; thus, the set of vertices from G,,, for which there is no vertex in Goldwith an isomorphic slice safely approximates the set of components new with changed behavior. This set is safe because it is guaranteed to contain all the components with different behavior. It is (necessarily) an approximation because the exact differencing problem is unsolvable. We call the vertices in G,,, with different behavior than in G o l d the set of affected points. The complexity of the straightforward solution for finding affected points outlined earlier is cubic in the size of G,,, (slice isomorphism can be determined in linear time [41]). This set can be efficiently computed in linear time using a single forward slice starting from the set of directly affected points: those vertices of G,,, with different incoming dependence edges than in Gold[19]. A solution to the second differencing problem is obtained by taking the backward slice with respect to the set of affected points. For programs with procedures and procedure calls, two modifications are necessary: First, the techniques described at the end of Section 2.2.2 are required t o ensure the resulting program is executable. Second, this solution is overly pessimistic: Consider a component c in procedure P that is called from two call sites cI and cz. If c is identified as an affected point by a forward slice that enters P through cl, then, assuming there is no other connection, we want to include c1 but not c2 in the program that captures the differences. However,
36
DAVID W. BINKLEY AND KEITH B. GALLAGHER
the backward slice with respect to c would include both c1 and c2. A more precise solution can be obtained by using a combination of the individual interprocedural slicing passes described in Section 2.2.2 [19].
3.2
Program Integration
The program integration operation concerns the problem of merging program variants [39, 19, 951. Given a program Base and two variants, A and B, each created by modifying separate copies of Base, the goal of program integration is to determine whether the modifications interfere, and if they do not, to create an integrated program that incorporates both sets of changes as well as the portions of Base preserved in both variants. The need for program integration arises in many situations: 0
0
0
When a system is “customized” by a user and simultaneously upgraded by a maintainer, and the user desires a customized, upgraded version. When a system is being developed by multiple programmers who may simultaneously work with separate copies of the source files. When several versions of a program exist and the same enhancement or bug-fix is to be made to all of them.
The integration algorithm uses program differencing to identify the changes in variants A and B with respect to Base. Preserved components are those components that are not affected in A or B. This set is safely approximated as the set of components with isomorphic slices in Base, A, and B. A merged program is obtained by taking the graph union of the (dependence graph for) the differences between A and Base, the differences between B and Base, and the preserved components. This program is then checked for interference. Interference exists if the changes in variant A and variant B are incompatible. If there is no interference, a merged program is produced that captures the changed behavior of A and B along with the preserved behavior of all three programs. An important property of the algorithm is that it is semantics based. Thus, the integration tool makes use of knowledge of the programming language to determine whether the changes made to Base to create the two variants have undesirable semantic interactions; only if there is no such interference will the tool produce an integrated program. The algorithm also provides guarantees about how the execution behavior of the integrated program relates to the execution behaviors of the base program and the two variants.
3.3 Testing Software maintainers are faced with the task of regression testing: retesting software after a modification. This process may involve running the
PROGRAM SLICING
37
modified program on a large number of test cases, even after the smallest of changes. Although the effort required to make a small change may be minimal, the effort required to retest a program after such a change may be substantial. Several algorithms based on program slicing have been proposed to reduce the cost of regression testing. The following algorithms assume that programs are tested using test data adequacy criterion: a minimum standard that a test suite (a set of test cases) must satisfy. An example is the all-statements criterion, which requires that all statements in a program be executed by at least one test case in the test suite. Satisfying an adequacy criterion provides some confidence that the test suite does a reasonable job of testing the program [ll,75, 181. Gupta et al. [32],present an algorithm for reducing the cost of regression testing that uses slicing to determine components affected transitively by an edit at point p . They consider a variety of different types of edits (statement addition, statement deletion, modification of the variables used in a statement, etc.) While some of these require simplified versions of the following procedure, in general two slices are used. The first slice is a backward slice from p . Definitions in this slice of variables used at p are recorded. The second slice is a forward slice also starting from p . Uses in this slice of variables defined at p are recorded. Def-Use pairs from a definition in the first slice to a use in the second are potentially affected by the change and must be retested. Bates and Horwitz [ll]present test case selection algorithms for the all vertices and the all flow edges test data adequacy criteria. The key to their algorithm is the notion of equivalent execution patterns. Two program components with equivalent execution patterns are executed by the same test cases [ll].Consider, for example, a component old from a tested program and component new of a modified version of this program. If test case t tests old, and old and new have equivalent execution patterns then test case t is guaranteed to test new. No new test case need be devised (even if new does not exist in the original program). The algorithms only select tests that test changed portions of the modified program. Components with equivalent execution patterns are identified using a new kind of slice called a control slice. A control slice, which is essentially a slice taken with respect to the control predecessors of a vertex, includes the statements necessary to capture “when” a statement is executed without capturing the computation carried out at the statement. The notion of equivalent execution patterns is too strong in the presence of procedures and procedure calls because it does not separate different calling contexts (i.e., different chains of call sites). Consider a simple program with two procedures, main and P, where main calls P. If another call to P is added to main, then the control slice for any component in P will
38
DAVID W. BINKLEY AND KEITH B. GALLAGHER
include this new call and therefore cannot be isomorphic with any control slice from the original program. Consequently, two such components cannot have equivalent execution patterns. Calling context is more accurately accounted for by replacing equivalent execution patterns with the weaker notions of common execution patterns [18]. Components with common execution patterns have equivalent execution patterns in some calling context. These components are identified using another kind of slice called a calling-context slice, which applies the second pass of backward slicing algorithm described in Section 2.2.2 “back” through the sequence of call sites that makes up a calling context. Program differencing can be used to further reduce the cost of regression testing by reducing the size of the program on which the tests must be run [HI. After a modification to a previously tested program, the resulting program is typically run on a large number of test cases to ensure the modification did not inadvertently affect other parts of the program. For a small change, the program produced using the program differencing techniques described in Section 3.1 is considerably smaller and consequently requires fewer resources to retest, especially when run on the reduced test set produced by any of the preceding algorithms.
3.4
Debugging
Program slicing was discovered as an operation performed by experienced programmers when debugging code [9l, 891. Programmers, given a piece of code with a bug in it, were asked to describe the code after removing the bug. They could reproduce certain “parts” of the code almost exactly, while others they could not. These parts were not continuous blocks of text (e.g., files, procedures, or functions), but rather they were what we now call program slices. Formalization of this debugging activity lead to the first algorithms for program slicing [89, 901. Turning this around, a tool that computes program slices is a valuable aid in debugging. It allows the programmer to focus attention on those statements that contribute to a fault. In addition, highlighting a slice assists in uncovering faults caused by a statement that should be in a slice but is not. Several kinds of slices are useful in debugging. First, dynamic slicing is one variation of program slicing introduced to assist in debugging [49,50]. When debugging, a programmer normally has a test case on which the program fails. A dynamic slice, which normally contains less of the program than a static slice, is better suited to assist the programmer in locating a bug exhibited on a particular execution of the program. As seen in Section 2.4.1, dynamic slicing can even assist in finding bugs caused by invalid pointers or array subscripts.
PROGRAM SLICING
39
Slicing is also useful in algorithmic debugging, which applies the following algorithm to the debugging process: Starting from an external point of failure (e.g., an arrant output value), the debugging algorithm localizes the bug to within a procedure by asking the programmer a series of questions. These questions relate to the expected behavior of a procedure. For example, “should add(4,2) return 6?” Based on these answers, procedures that have the expected output are treated as working, while procedures that produce unexpected answers are “opened.” This means the debugger attempts to determine if the calls in the procedure produce expected results. Algorithmic debugging terminates at a procedure with no calls or in a procedure in which all the calls produce the expected output. One drawback of algorithmic debugging is that it asks questions about procedures that do not affect a buggy result. Program slicing can be of assistance here [46]: Any call not in the slice with respect to the buggy output can be ignored; it cannot affect the buggy result. Further, parameters that are not in the slice, even for a call that is, can also be ignored. Debugging was also the motivation for program dicing and latterprogram chopping. Dicing uses the information that some variables fail some tests, while other variables pass all tests, to automatically identify a set of statements likely to contain the bug [62]. A program dice is obtained using set operations on one or more backward program slices. Some dices are more interesting than others. The interesting ones include the intersection of two slices, and the intersection of slice A with complement of slice B. The first dice, which identifies common code, is helpful in locating bugs when two computations are both incorrect assuming all incorrectly computed variables are identified and no program bug masks another bug [62]. This dice is also useful in ensuring software diversity in safety critical systems. If, for example, the computation of trip-overtemperature-sensor and tripoverpressure-sensor includes the same computation (often a function call) then this Computation is in the dice taken with respect to the two trip signals. Such a computation is of interest in safety critical systems because a bug in this computation may cause both sensors to fail. The second dice, which yields code unique to A, is helpful in locating bugs in computation on A if computation of B is correct. For example, consider a program that counts the number of words and characters in a file. If the final value of c h a r a c t e r-c o u n t is correct, but the final value of wo rd-coun t is not, then the second kind of dice could be applied. In this case, it contains statements that affect the value of word-count but not the value of c ha r a c t e r-c oun t . This implies that the looping and reading of characters from the file need not be considered. The original work on dicing considered only backward slices. Incorporating forward slices increases the usefulness of dicing. For example, the notion
40
DAVID W. BINKLEY AND KEITH B. GALLAGHER
of program chopping identifies the statement that transmits values from a statement t to a statement s [45]:chop(t, s ) includes those program points affected by the computation at program point c that affect the computation at program point s. A program chop is useful in debugging when a change at t causes an incorrect result to be produced at s. The statements in chop([,s) are the statements that transmit the effect of the change at t to s. Debugging attention should be focused there. In the absence of procedures, chop([,s) is simply the intersection of the forward slice taken with respect to t and the backward slice taken with respect to s and can be viewed as a generalized kind of program dice. The same is not true for interprocedural chopping [81]. As initially introduced, s and t must be in the same procedure P, and only components from P are reported. This was later generalized to allow s and t to be in different procedures and to contain components for procedures other than P [81]. It is interesting to note that for interprocedural chopping the dicing idea of intersecting a forward and backward slice is imprecise. Interprocedural versions of other set theoretic operations on slices that work with intraprocedural slices have eluded researchers [77]. Precise interprocedural chopping is addressed in [81].
3.5
Software Quality Assurance
Software quality assurance auditors are faced with a myriad of difficulties, ranging from inadequate time to inadequate computer-aided software engineering (CASE) tools (291. One particular problem is the location of safety critical code that may be interleaved throughout the entire system. Moreover, once this code is located, its effects throughout the system are difficult to ascertain. Program slicing is applied to mitigate these difficulties in two ways. First, program slicing can be used to locate all code that contributes to the value of variables that might be part of a safety critical component. Second, slicing-based techniques can be used to validate functional diversity (i.e., that there are no interactions of one safety critical component with another safety critical component and that there are no interactions of nonsafety critical components with the safety critical components). A design error in hardware or software, o r an implementation error in software may result in a common mode failure of redundant equipment. A common mode failure is a failure as a result of a common cause, such as the failure of a system caused by the incorrect computation of an algorithm. For example, suppose that X and Y are distinct critical outputs and that X measures a rate of increase while Y measures a rate of decrease. If the computation of both of the rates depends on a call to a common
PROGRAM SLICING
41
numerical differentiator, then a failure in the differentiator can cause a common mode failure of X and Y. One technique for defending against common mode failures uses functional diversify. Functional diversity in design is a method of addressing the common mode failure problem in software that uses multiple algorithms on independent inputs. Functional diversity allows the same function to be executed along two or more independent paths. One technique to solve this problem combines fault-tree analysis and program slicing. Once the system hazards have been identified, the objective of fault-tree analysis is to mitigate the risk that they will occur. One approach to achieving this objective is to use system fault-tree analysis. Under the assumption that there are relatively few unacceptable system states and that each of these hazards has been determined, the analysis procedure is as follows. The auditor assumes that a hazard has occurred and constructs a tree with the hazardous condition as the root. The next level of the tree is an enumeration of all the necessary preconditions for the hazard to occur. These conditions are combined with a logical AND and OR as appropriate. Then each new node is expanded “similarly until all leaves have calculable probability or cannot be expanded for some reason” [55]. System fault-tree analysis gives the auditor the subcomponents of the system that must be carefully examined. Part of this examination is the validation that there are no interactions with noncritical functions. The determination of the specific components that will be examined is up to the auditor. This information should be obtainable from the design documentation. Slicing is used as an aid to validating safety as follows. First, the auditor uses system fault-tree analysis to locate critical components. The software that is invoked when a hazardous condition occurs is identified in the system. The auditor then locates the software variables that are the indicators of unsafe conditions. Program slices are extracted on these “interesting” variables. These slices can be used to validate that there are no interactions between critical components or with noncritical components using program dicing. Program slices can also be used to assure diversity: Slices computed from the outputs of individual hazards can be examined to determine the logical independence of the events. For instance, if A and B are two critical conditions, the dice computed by intersecting the program slices on these wo conditions provides partial information on whether or not both conditions can occur simultaneously. If the dice is empty, then there is no way that the software can guarantee that both will not occur simultaneously there may be other ways the verify that both will not occur). If the dice
42
DAVID W. BINKLEY AND KEITH B. GALLAGHER
is not empty, inspection of the overlap may prove that both conditions cannot occur together (although the functional diversity of such computations is suspect). These program projections can also be highlighted for more vigorous analysis, inspection, and testing. A static program slice can be further refined by examining the trajectory of specific inputs through the program; dynamic slices are used to observe individual instances of the computation. This simplifies the tedious task of the auditor and permits undivided attention to be focused on the analytic portions of the audit. The utility of a slicing tool comes from automating the task of finding statements that are relevant to a computation. Without any tool, the software quality assurance auditor evaluating functional diversity would examine the program under consideration until outputs were identified that should be computed independently. The auditor would then try to verify independence by reading code. Unravel [63] is a static program slicer developed at the National Institute of Standards and Technology as part of a research project. It slices ANSIC programs. Its only limitations are in the treatment of unions, forks, and pointers to functions. The tool is divided into three main components: a source code analysis component to collect information necessary for the computation of program slices, a link component to link flow information from separate source files together, and an interactive slicing component that the software quality assurance auditor can use to extract program components and statements for answering questions about the software being audited.
3.6 Software Maintenance Software maintainers are faced with the upkeep of programs after their initial release and face similar problems as program integrators-understanding existing software and making changes that fix bugs or provide enhancements without having a negative impact on the unchanged part of the software. As illustrated by Unravel, slicing is useful in understanding existing software [63]. A new kind of slice, called a decomposition slice [28], is useful in making a change to a piece of software without unwanted side effects. While a slice captures the value of a variable at a particular program point (statement), a decomposition slice captures all computations of a variable and is independent of program location. A decomposition slice is useful to a maintainer when, for example, variable v is determined to have an incorrect value. A differencing tool based on decomposition slicing, called the Surgeon’s Assistant [26], partitions a program into three parts (assume the computation of variable v is to be changed):
PROGRAM SLICING
43
Independent part: Statements in the decomposition slice taken with respect to v that are not in any other decomposition slice. Dependentpart: Statements in the decomposition slice taken with respect to v that are in another decomposition slice. Compliment: Statements that are not independent (i.e., statements in some other decomposition slice, but not v’s).
For a maintainer trying to understand the code, only independent and dependent statements (i.e., the decomposition slice taken with respect to v) are of interest. Furthermore, the Surgeon’s Assistant only allows modifications of the independent part. This prevents adverse side effects to computations in the compliment. One advantage of this approach is that after making a modification only the independent part need be tested; the complement is guaranteed to be unaffected by the change. The cost of this testing can be significantly lower than testing the entire program. Finally, a program is formed by combining the modified independent part and the unchanged compliment. This can be done in linear time [96]. The merges of [39] are NP-hard. The result is a modified and tested program.
3.7
Reverse Engineering
Reverse engineering concerns the problem of comprehending the current design of a program and the way this design differs from the original design. This involves abstracting out of the source code the design decisions and rationale from the initial development (design recognition) and understanding the algorithms chosen (algorithm recognition). Program slicing provides a toolset for this type of reabstraction. For example, a program can be displayed as a lattice of slices ordered by the is-a-slice-of relation [28, 77, 121. Comparing the original lattice and the lattice after (years of) maintenance can guide an engineer toward places where reverse engineering energy should be spent. Because slices are not necessarily contiguous blocks of code, they are well suited for identifying differences in algorithms that may span multiple blocks or procedures. Beck and Eichmann observe that elements “toward the bottom” of this lattice are often clichb [12]. For example, in the word count program, the slice that reads the characters from a file is contained in (is-a-slice-of) three other slices (these slices count the number of words, lines, and characters in the input). The common slice is the read-a-file clichk. Beck and Eichmann also propose the notion of interface slicing for use in reverse engineering. Understanding a program often requires identifying its major abstractions and their interfaces. An interface slice is essentially a forward slice taken with respect to the entry vertices in a collection of
44
DAVID W. BINKLEY AND KEITH B. GALLAGHER
procedures [12]. This projection of a general software module (e.g., a set, list, or window widget) captures the particular behaviors required for a particular use. An interface slice is computed from an interface dependence graph as a forward graph traversal. The dual of this operation uses a backward graph traversal (i.e., traverses the dependence edges from target to source). Starting from all calls on procedure P, this “backward” interface slice includes the public interfaces for those procedures (from other modules) that require P. While interface slicing is useful in reverse engineering, it seems more useful in reshaping the development process. In particular, as Beck and Eichmann observe, a programmer with access to a large repository of software modules often wants only part of the functionality of a module in the repository. Presently, the programmer has two unsatisfactory options: (1) Create a special copy of the module or (2) include unwanted code. The first option requires access to the source code, which may not be possible. It also creates multiple copies of some functions from the module, which complicates later updates. The second option increases the code size and may degrade the performance of the compiler when optimizing the code. Interface slicing can be used to provide a third alternative that has neither of these deficiencies: The complete module is made available to the interface slicer. A programmer, desiring partial functionality from a module, tells the interface slicer which exported functions are required. The interface slicer then produces the public interface for the required functions without releasing the source for their implementation. Thus a specialized version of the original is made available to the programmer without introducing a new copy or releasing proprietary source code.
3.8 Functional Cohesion Cohesion is an attribute of a software unit that purports to measure the “relatedness” of the unit. Cohesion has been qualitatively characterized as coincidental, logical, procedural, communicational, sequential, and functional, with coincidental being the weakest and functional being the strongest [94]. Yourdon and Constantine note that functional cohesion “is an integral part of, and is essential to, the performance of a single function” P41. To construct a slicing-based measure of functional cohesion, Bieman and Ott [14] define data slices, a backward and forward static slice that uses data tokens (variable and constant definitions and references) rather than statements as the unit of decomposition. This definition ensures that any change will impact at least one slice and leads to a slice abstraction model
PROGRAM SLICING
45
of the procedure under consideration: one can regard the slice as the sequence of variable tokens contained within it. The tokens that are in every data slice are referred to as superglue; tokens that are in more than one data slice are referred to as glue. The metrics are based on the ratios of the appearance of glue and superglue tokens in a slice. Strong functional cohesion is the ratio of superglue tokens in the slice to the number of tokens in the slice. Weak functional cohesion is the ratio of glue tokens in the slice to the number of tokens in the slice. Another method for measuring cohesion is to measure the adhesiveness of the individual tokens. A token that glues five data slices together is more adhesive than a token that glues only two data slices together. Thus, the adhesion of an individual token is the ratio of number of slices in which the token appears to the number of data slices in a procedure. Bieman and Ott show that these metrics form a well-defined, ordinal measure of the functional cohesion of a program. That is, they show that the orderings imposed match one's intuition. They are unable to show that the metrics are on a ratio scale (that meaningful composition of the metrics exits). The measures are not additive. The study of the relationship of these metrics to product attributes such as reliability and maintainability is ongoing.
REFERENCES 1. Agrawal, H. (1989). Towards automatic debugging of computer programs. Technical Report SERC-TR-40-P, Purdue University. 2. Agrawal, H. (June 1994). On slicing program with jump statements. In Proc. ACM SIGPLAN 94 Conference on Programming Language Design and Implementation, pp. 303-312, ACM. 3. Agrawal, H., DeMillo, R., and Spafford, E. (1988). A process state model to relate testing and debugging. Technical Report SERC-TR-27-P, Purdue University. 4. Agrawal, H., and DeMillo, R. A. (1991). Dynamic slicing in the presence of unconstrained pointers. In Proc. ACM Symposium on Testing and Verification, October 1991. 5. Agrawal, H., and Horgan, J. (1989). Dynamic program slicing. Technical Report SERCTR-56-P, Purdue University. 6. Agrawal, H., and Horgan, J. (1990). Dynamic program slicing. In Proc. ACM SIGPLAN '90 Conference. 7. Ball, T., and Horwitz, S. (1993). Slicing programs with arbitrary control-flow. In Proc. 1st International Workshop on Automated and Algorithmic Debugging, Lecture Notes Computer Sci. 149,206-222. 8. Banning, J. P. (1979). An efficient way to find the side effects of procedure calls and the aliases of variables. In Conference Record of the Sixth ACM Symposium on Principles of Programming Languages, San Antonio, TX, Jan. 29-31, 1979. 9. Barendergt, H., van Eekelen, M., Glauert, J., Kennawar, J., Plasneijer, M., and Sleep, M. (1987). Term graph rewriting. In Proceedings PARLE Conference, Vol 11: Parallel Languages.
46
DAVID W. BINKLEY AND KEITH B. GALLAGHER
10. Barth, J. M. (1978). A practical interprocedural dataflow analysis algorithm. Comm. ACM 21(9), 724-726. 11. Bates, S., and Horwitz, S. (1993). Incremental program testing using program dependence graphs. In Conference Record of the Twentieth ACM Symposium on Principles of Programming Languages, ACM. 12. Beck, J., and Eichmann, D. (1993). Program and interface slicing for reverse engineering. I n Proc. Fifteenth International Conference on Software Engineering. Also in Proceedings Working Conference on Reverse Engineering. 13. Bergeretti, J.-F., and Carre, B. (1985). Information-flow and data-flow analysis of whileprograms. ACM Trans. Programming Languages Syst. 7(1), 37-61. 14. Bieman, J., and Ott, L. (1994). Measuring functional cohesion. IEEE Trans. Sofrware Eng. 20(8), 644-6.57. 1.5. Binkley, D. (1992). Using semantic differencing to reduce the cost of regression testing. In Proc. Conference on Software Maintenance-1992, pp. 41-50, November, 1992. 16. Binkley, D. (1993). Slicing in the presence of parameter aliasing. In Software Engineering Research Forum, Orlando, FL, November 1993. 17. Binkley, D. (1994). Precise executable interprocedural slices. ACM Lett. Programming Languages Syst. 1-4(2), 31-45. 18. Binkley, D. (1995). Reducing the cost of regression testing by semantics guided test case selection. In IEEE International Conference on Software Maintenance. 19. Binkley, D., Horwitz, S., and Reps., T. (1995). Program integration for languages with procedure calls. ACM Trans. Software Eng. Method. 4(1), 3-35. 20. Choi, J., and Ferrante, J. (1994). Static slicing in the presence of G O T 0 statements. ACM Trans. Programming Languages Syst. 16(4), 1097-1113. 21. Choi, J.-D., Miller, B., and Netzer, P. (1988). Techniques for debugging parallel programs with flowback analysis. Technical Report 786, University of Wisconsin-Madison. 22. Cutillo, F., Fiore, R., and Visaggio, G. (1993). Identification and extraction of domain independent components in large programs. In Proc. Working Conference on Reverse Engineering, pp. 83-92, June 1993. 23. Denning, D. E., and Denning, P. J. (1977). Certification of programsfor secure information flow. Comm. ACM 20(7), 504-513. 24. Ferrante. J., Ottenstein, K., and Warren, J . (1987). The program dependence graph and its use in optimization. ACM Trans. Programming Languages Syst. 9(3), 319-349. 25. Field, J., Ramalingam, G., and Tip, F. (1995). Parametric program slicing. In Conference Record of the Twenty-Second ACM Symposium on Principles of Programming Languages, pp. 379-392. 26. Gallagher, K. B. (1990). Surgeon’s assistant limits side effects. IEEE Sofrware, May 1990, p. 9.5. 27. Gallagher, K. B. (1991). Using program slicing to eliminate the need for regression testing. In Eighth International Conference on Testing Computer Software, May 1991, pp. 114-123. 28. Gallagher, K. B., and Lyle, J. R. (1991). Using program slicing in software maintenance. IEEE Trans. Software Eng. 17(8), 751-761. 29. Gallagher, K. B., and Lyle, J. R. (1993). Program slicing and software safety. In Proc. Eighth Annual Conference on Computer Assurance, pp. 71-80, June 1993. 30. Gandle, M., Santal, A., and Venkatesh, G. (1993). Slicing functional programs using collecting abstract interpretation. In First Symposium on Algorithmic and Automated Debugging, Linkoping, Sweden. 31. Gopal, R. (1991). Dynamic program slicing based on dependence relations. In Proc. IEEE Conference on Software Maintenance, pp. 191-200.
PROGRAM SLICING
47
32. Gupta, R., Harrold, M. J . . and Soffa, M. L. (1992). An approach to regression testing using slicing. In Proc. IEEE Conference on Software Maintenance, pp. 299-308. 33. Harman, M., Danicic, S., and Sivaguranathan, Y. (1996). A parallel algorithm for static program slicing. Info. Proc. Lett. in press. 34. Harrold, M. J., Malloy, B., and Rothermel, G. (1993). Efficient construction of program dependence graphs. In International Symposium on Software Testing and Analysis (ISSTA '93). 35. Hausler, P. (1989). Denotational program slicing. In Proc. 22nd Hawaii International Conference on System Sciences, Volume 11, Software Track, pp. 486-494, January 1989. 36. Horwitz, S., Prins, J . , and Reps, T. (1988). Integrating non-interfering versions of programs. I n Proc. SIGPLAN 88 Symposium on the Principles of Programming Languages, January 1988. 37. Horwitz, S., Prins, J., and Reps, T. (1988). On the adequacy of program dependence graphs for representing programs. In Proc. SIGPLAN 88 Symposium on the Principles of Programming Languages, January 1988. 38. Horwitz, S., Prins, J., and Reps, T. (1988). Support for integrating program variants in an environment for programming in the large. In Proc. International Workshop on Software Version and Configuration Control 88, Grassau, Germany, January 1988. 39. Horwitz, S., Prins, J., and Reps, T. (1989). Integrating non-interfering versions of programs. ACM Trans. Programming Languages Syst. 11(3), 345-387. 40. Horwitz, S., and Reps, T. (1990). Efficient comparison of program slices. Technical Report 983, University of Wisconsin-Madison. 41. Horwitz. S., and Reps, T. (1991). Efficient comparison of program slices. Acra Info. pp. 713-732. 42. Horwitz, S., and Reps, T. (1992). The use of program dependence graphs in software engineering. In Proc. Fourteenth International Conference on Software Engineering. 43. Horwitz, S., Reps, T., and Binkley, D. (1988). Interprocedural slicing using dependence graphs. In Proc. ACM SIGPLAN 88 Conference on Programming Language Design and Implementation, Atlanta, Georgia, June 1988. 44. Horwitz, S., Reps, T., and Binkley, D. (1990). Interprocedural slicing using dependence graphs. ACM Trans. Programming Languages Syst. 12(1), 35-46. 45. Jackson, D., and Rollins, E. J. (1994). A new model of program dependences for reverse engineering. In Proc. Second ACM SIGSOFT Symposium on the Foundations of Software Engineering, New Orleans, LA, December 1994. 46. Kamkar, M. (1993). Interprocedural dynamic slicing with applications to debugging and testing. Ph.D. Thesis, Linkoping University, Sweden. 47. Kamkar, M., Fritzson, P., and Shahmehri, N. (1993). Interprocedural dynamic slicing applied to interprocedural data flow testing. In Proc. Conference on Software Maintenance-93, pp. 386-395. 48. Kennedy, K. (1981). A survey of data flow analysis techniques. I n Program Flow Analysis: Theory and Applications. (Steven S. Muchnick and Neil D. Jones, eds), Prentice Hall, Englewood Cliffs, NJ. 49. Korel, B., and Laski, J. (1988). Dynamic program slicing. Info. Proc. Leu. 29(3), 155-163. 50. Korel, B., and Laski, J. (1988). STAD-A system for testing and debugging: User perspective. In Proc. Second Workshop on Software Testing, Verification and Analysis, pp. 13-20, Banff, Alberta, Canada, July 1988. 51. Korel, B., and Laski, J. (1990). Dynamic slicing of computer programs. J. Syst. Software, pp. 198-195. 52. Lanubile, F., and Visaggio, G. (1993). Function recovery based on program slicing. In Proc. Conference on Software Maintenance-1993, pp. 396-404, September 1993.
48
DAVID W. BINKLEY AND
KEITH 8. GALLAGHER
53. Laski, J. (1990). Data flow testing in STAD. J . Syst. Svfrware 12, 3-14. 54. Laski, J., and Szermer, W. (1992). Identification of program modifications and its application in software maintenance. In Proc. Conference on Software Maintenance--1992, pp. 282-290, November 1992. 55. Leveson, N., Cha, S., and Shimeall, T. (1991). Safety verification of Ada programs using software fault trees. IEEE Cvrnpufer 8(4), 48-59. 56. Linger, R., Mills, H., and Witt, B. (1979). “Structured Programming: Theory and Practice.” Addison-Wesley, Reading, MA. 57. Livadas, P., and Croll, S. (1994). A new method in calculating transitive dependences. 1. Software Maintenance, pp. 1-24. 58. Longworth, H. (1 985). Slice based program metrics. Master’s Thesis, Michigan Technological University, Houghton, MI. 59. Longworth, H., Ott, L., and Smith, M. (1986). The relationship between programcomplexity and slice complexity during debugging tasks. I n Proc. COMPSAC 86. 60. Lyle, J. R. (1984). Evaluating variations of program slicing for debugging. PhD Thesis, University of Maryland, College Park, MD. 61. Lyle, J. R., and Weiser, M. D. (1986). Experiments on slicing-based debugging aids. I n “Empirical Studies of Programmers,” (Elliot Soloway and Sitharama Iyengar, Eds.), Ablex Publishing Corporation, Norwood, NJ. 62. Lyle, J. R., and Weiser, M. D. (1987). Automatic program bug location by program slicing. I n Proc. Second International Conference on Computers and Applications, pp. 877-882, Peking, China, June 1987. 63. Lyle, J. R., Wallace, D. R., Graham, J. R., Gallagher, K. B., Poole, J. E., and Binkley, D. W. (1995). A CASE tool to evaluate functional diversity in high integrity software. U.S. Department of Commerce, Technology Administration, National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD. 64. Maydan. D., Hennessy, J., and Lam, M. (1991). Efficient and exact data dependence analysis. I n Proc. ACM SIGPLAN 91 Conference on Programming Language Design and Implementation, Toronto, Ontario, June 1991. 65. Merlo, E., Girard, J., Hendren, L., and De Mori, P. (1993). Multi-valued constant propagation for the reengineering of user interfaces. I n Proc. Conference on Software Maintenance-1993, pp. 120-129, September 1993. 66. Ono, K., Maruyama, K., and Fukazawa, Y.(1994). Applying a verification method and a decomposition method to program modification. Trans. IEICE, J77-D-I( 1l), November 1994. 67. Ott, L., and Bieman, J. (1992). Effects of software changes on module cohesion. In Proc. Conference on Software Maintenance-1992, pp. 345-353, November 1992. 68. Ott, L., and Thuss, J. (1989). The relationship between slices and module cohesion. I n International Conference on Software Engineering, May 1989. 69. Ottenstein, K., and Ottenstein, L. (1984). The program dependence graph in software development environments. In Proc. ACM SIGSOFT/SlGPLAN Software Engineering Symposium on Practical Software Development Environments, pp. 177-184, May 1984. L. Ottenstein is now known as L. Ott. 70. Platoff, M., and Wagner, M. (1991). An integrated program representation and toolkit of the maintenance of c programs. In Proc. Conference on Software Maintenance, October 1991. 71. Pleszcoch, M., Hausler, P., Hevner, A,, and Linger, R. (1990). Function theoretic principles of program understanding. I n Proc. Twenty-third Annual Hawaii Conference on System Sciences, Vol. 4, pp. 74-81.
PROGRAM SLICING
49
72. Pugh, W., and Wonnacott, D. (1992). Eliminating false data dependences using the omega test. I n Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, pp. 140-151. 73. Ramalingam, G.. and Reps, T. (1991). A theory of program modifications. In Proc. Colloquium on Combining Paradigms for Software Development, pp. 137-152, SpringerVerlag, Berlin. 74. Ramalingam, G., and Reps, T. (1992). Modification algebras. I n Proc. Second International Conference on Algebraic Methodology and Software Technology, SpringerVerlag, Berlin. 75. Rapps, S., and Weyuker, E. J. (1985). Selecting software test data using data flow information. IEEE Trans. Software Eng. SE-11(4), 367-375. 76. Reps. T. (1989). On the algebraic properties of program integration. Technical Report 856, University of Wisconsin-Madison. 77. Reps, T. (19Y1). Algebraic properties of program integration. Sci. Computer Programming 17, 139-215. 78. Reps, T., and Bricker, T. (1989). Semantics-based program integration illustrating interference in interfering versions of programs. In Proc. Second International Workshop on Software Configuration Management, pp. 46-55, Princeton, NJ, October 1989. 79. Reps, T., and Horwitz, S. (1988). Semantics-based program integration. I n Proc. Second European Symposium on Programming (ESOP '88), pp. 133-145, Nancy, France, March 1988. 80. Reps, T., Horwitz, S., Sagiv, M., and Rosay, G. (1994). Speeding up slicing. I n Proc. Second ACM SIGSOFT Symposium on Foundations of Software Engineering, pp. 11-20. Published in ACM SIGSOFT Notes 19(4). 81. Reps, T., and Rosay, G. (1995). Precise interprocedural chopping. I n Proc. Third ACM Symposium on the Foundations of Software Engineering, Washington, DC, October 1995. 82. Reps, T.. and Yang, W. (1988). The semantics of program slicing. Technical Report 777, University of Wisconsin-Madison. 83. Rothermel, G.. and Harrold, M. J. (1994). Selecting tests and identifying test coverage requirements for modified software. I n Proc. ACM SIGSOFT International Symposium on Software Testing and Analysis, pp. 169-84, August 1994. 84. Shimomura, T. (1992). The program slicing technique and its application to testing, debugging, and maintenance. J . IPS Japan, 9(9), 1078-1086. 85. Tip, F. (1995). Generation of program analysis tools. Ph.D. Thesis, University of Amsterdam. 86. Venkatesh, G. (1995). Experimental results from dynamic slicing of C programs. ACM Trans. Programming Languages Syst. 17(2), 197-216. 87. Venkatesh, G. A. (1991). The semantic approach to program slicing. In Proc. ACM SIGPLAN 91 Conference on Programming Language Design and Implementation, Toronto, Ontario, June 26-28, 1991. 88. Weise, D., Crew, R., Ernst, M., and Steensgaard, B. (1994). Value dependence graphs: Representation without taxation. In Proc. ACM SIGPLAN-SIGACT Twenty-first Symposium on Principles of Programming Languages, pp. 297-310, January 1994. 89. Weiser, M. (1979). Program slicing: Formal, psychological and practical investigations of an automatic program abstraction method. Ph.D. Thesis, The University of Michigan, Ann Arbor. 90. Weiser, M. (1981). Program slicing. I n Proc. Fifth International Conference o n Software Engineering, pp. 439-449, May 1981. 91. Weiser, M. (1982). Programmers use slices when debugging. CACM 25(7), 446-452.
50
DAVID W. BINKLEY AND KEITH B. GALLAGHER
92. Weiser, M. (1983). Reconstructing sequential behavior from parallel behavior projections. Info. Proc. Lett. 17(5), 129-135. 93. Weiser, M. (1984). Program slicing. IEEE Trans. Software Eng. 10,352-357. 94. Yourdon, E., and Constantine, L. (1979). “Structured Design.” Prentice Hall, Engfewood Cliffs, NJ. 95. Berzins, B. (1991). Software merge: Models and methods for combining changes to programs. Int. J . Sys. Integ. 1, 121-141. 96. Gallagher, K. B. (1991). Conditions to assure semantically correct consistent software merges in linear time. In Proc. Third International Workshop on Software Configuration Management, pp. 80-84, May 1991.
Language Features for the Interconnection of Software Components RENATE MOTSCHNIG-PITRIK Department of Applied Computer Science and Information Systems University Vienna Vienna, Austria
ROLAND T. MlTTERMElR Department of In forma tics Klagenfurt University Klagenfurt, Austria
Abstract The increasing size and complexity of software systems calls not only for methods to determine their optimal breakdown into components but also for clear and precisc techniques to specify (and control) the interconnections among these components. In the various subfields involved with this issue-software engineering, programming languages, conceptual modeling, and knowledge representation-different backgrounds lead to different approaches for modeling component interconnection. We review different language paradigms for specifying component interconnection and provide a unifying framework for comparing linguistic features for interconnection specification. Examples of such features are different kinds of components, semantic categories of interconnection relations, the granularity and precision of interconnection specifications. and the structure of interconnections. Besides a feature comparison, the framework presented allows for a focused choice of expressing those aspects of component interconnection that are deemed critical for understanding the cooperation of components in development or maintenance efforts of very large systems. We concludc with a discussion of the role of interconnection specification in software development and with hints for problems worthy of further investigation.
1. lntroduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 1.2 The Roots of Component Interconnection Languages (CILs) . . . . . . . . 55
51 ADVANCES IN COMPU1t.KS. VOI.. 43
Copyrighl 0 1996 hy Academic P r e s Inc. All right5 ot reproduction in any iorm reserved
52
2.
3. 4.
5.
6. 7.
R . MOTSCHNIG-PITRIK AND R . T . MITTERMEIR 1.3 From Modules to Components . . . . . . . . . . . . . . . . . . . . . . . 55 56 1.4 Organization of the Article . . . . . . . . . . . . . . . . . . . . . . . . Different Perspectives and Fundamental Issues . . . . . . . . . . . . . . . . . 57 2.1 Software Engineering/Programming Language Background to CI . . . . . . . 57 2.2 The Data Modeling and Knowledge Representation Background . . . . . . . 59 2.3 CASE Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.4 Components and Resources . . . . . . . . . . . . . . . . . . . . . . . . 60 2.5 Component Interconnections (CI) . . . . . . . . . . . . . . . . . . . . . 61 A Model for Component Interconnection Specification . . . . . . . . . . . . . . 62 Survey of Language Paradigms for the Specification of Component Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.1 CIL as a Compiler Option . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2 Component Interconnection Specifications Embedded into Various Languages and Notations . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3 CILs as Independent Languages . . . . . . . . . . . . . . . . . . . . . . 72 4.4 Generic Features of Component Interconnection in Software Environments and Metamodeling . . . . . . . . . . . . . . . . . . . . . 84 4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Comparison of Features for Expressing Component Interconnections . . . . . . . . . . . . . . . . . . . . . . . . . . 86 86 5.1 Kinds of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Nesting of Components . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3 Encapsulation and Separation of Specification and Implementation Parts . . . 90 5.4 Granularity and Precision of Interconnection Relationships . . . . . . . . . 96 5.5 Structure of Interconnection Relationships . . . . . . . . . . . . . . . . 100 5.6 Categories of Interconnection Relationships . . . . . . . . . . . . . . . 100 5.7 Comparison of Features of Languages Expressing Component Interconnections . . . . . . . . . . . . . . . . . . . . . . 124 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 132 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface issues have been key issues in computing ever since the issue of systematically decomposing systems into their components arose . Early accounts addressing this issue are the seminal paper by Parnas (1972) on decomposing systems into modules and the paper by Stevens. Myers. and Constantine (1974) that gave a set of clear criteria for decomposing systems and evaluating their decomposition . As dated as these references are. they still can be used as the basis for neat decompositions. even if the programming paradigms might have changed. for example. to object oriented (Eder et al., 1994). However. all the works referenced thus far consider software systems developed according to a single design paradigm and following a single architectural model . The word “architecture. ” however. just was not part of standard computing terminology when interface-and hence interconnection-issues were first discussed. neither was “systems integration.” Both terms refer to new
INTERCONNECTION
OF SOFTWARE COMPONENTS
53
disciplines and new perspectives within the computing and software engineering field. Both disciplines emerged in the early 1990s (see Tichy et al., 1993) and deal with special issues that are intrinsic within very large systems. Also, both disciplines are still in a kind of formative stage and there is still argument about the semantics of these terms (Garlan and Perry, 1994). However, it is not only size that gave rise to these new disciplines. It is the heterogeneity inherent within very large systems. This heterogeneity comes partially from the evolutionary nature in which these systems have been developed in contrast to the advice for single-shot developments we saw 20 years ago); it comes from such aspects as software development with reuse (Garlan et al., 1995) and from distribution aspects. The spectrum of issues to be addressed on the architectural level is given by Shaw (1995) and further detailed by Shaw and Garlan (1995) and Allen and Garlan (1994). If we consider architectural issues under the distributed systems perspective (Magee et al., 1995), we come close to systems integration issues. This new field is extremely broad. Considering the scope of the Proceedings of the Third International Conference on Systems Integration, the term “systems” is understood in a very general way, far beyond a purely technological notion (Ng et al., 1994). If we reduce our focus to computing issues though, the notion of integration architectures become prevalent (Rossak and Ng, 1991). The scope remains broad though, ranging from process aspects (Yeh et al., 1991) to issues emerging in the development of very large systems (Kirova et al., 1994; Schepers, 1994). Standards, apparently play a key role in this context (Kuhn, 1990). So as not to lose sight of the wealth of interconnection issues popping up in this vast realm of systems development and systems evolution issues, we focus on component interconnection in local software systems. Thus, we leave the field of distributed computing to those working in the broader context of software architecture (see, e.g., Allen and Garlan, 1994). We do consider, though, systems containing components that have been built according to standard software engineering paradigms, components built on data engineering paradigms, and components built according to paradigms from artificial intelligence. Considering these three notions seems particularly warranted, because the boundaries between these subdisciplines become blurred to a certain degree anyway if one follows an objectoriented development paradigm.
1. Introduction
1.I
Motivation
The issues of size, complexity, and longevity of software systems as well as efforts to build systems from reusable components call for methods
54
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
that will help designers to choose the best breakdown of systems into components. Clear and precise techniques to specify, control, and maintain the interconnections among these components are equally important during system development and during maintenance. In the various computer science subfields involved with this issue-software engineering, programming languages, conceptual (data) modeling, and knowledge representation-different starting points as well as backgrounds lead to different approaches for modeling component interconnection. Here, we provide a unifyingiframework for the various interconnection notions used in these fields. The differences in the expressive power of various mechanisms to describe interconnections between components is all but surprising, since each of the subdisciplines of computing just mentioned builds on a different history and serves to attack different problems. Systems at the turn of the century, however, are expected to be based on more than one paradigm. Multiple-paradigm systems, combining aspects of artificial intelligence with large databases, combining databases with complex algorithmic aspects, or combining algorithmic aspects with declarative elements, become increasingly important. Here, a feature analysis of interconnection mechanisms that is independent of this breakdown into historically established fields is needed. In addition to mergers of architectural styles, even systems styled in a single purist way according to a nonclassical architecture (such as rule based or object-oriented) call for renewed attention to interconnection mechanisms. The reason is that the interconnection of components is to be modeled in more dimensions than the traditional hierarchicaldecomposition/input-output(-control) plane (Mittermeir and Rossak, 1987). This, in conjunction with the ubiquitous argument that large systems can only be developed and maintained by team efforts and that these team efforts need mechanisms to communicate the “interface contract” in a well-defined and efficient way, provide classical motivations for precisely describing component interconnection. Another compelling reason for an increased focus on component interconnection is the evolutionary nature of software. To make software adaptable to an ever-changing environment, precise descriptions concerning what is interconnected in which manner and for which purpose are necessary. Such descriptions are expected to provide room for transparent maintenance, sound configuration management, and quick reconfiguration. A further reason for the importance of CI in complex systems is the fact that there is a strong endeavor to reuse components or even larger units such as subsystems, being composed of several interrelated components. To be
INTERCONNECTION OF SOFTWARE COMPONENTS
55
able to reuse a component, one has to know exactly what services it provides and in what ways, if at all, it depends on other components-its environment.
1.2 The Roots of Component Interconnection Languages (CILs) Historically, interest in component interconnection started in the field of programming languages in recognition of the need to distinguish two different activities in developing large systems, namely, programming-inthe-large, dealing with the specification of interconnections among modules, and programming-in-the-small, the traditional coding of individual modules. In the design of the first influential module interconnection language MIL-75 (DeRemer and Kron, 1976), the authors clearly separated the issues of the two activities and demonstrated the feasibility of this conceptual separation by specifying MIL-75 to be quite independent of any accompanying language employed for programming-in-the-small. Containing the basic concepts to deal with module interconnection in a programming languageindependent way, MIL-75 laid the foundation for a whole generation of successor MILS, which refine and/or extend the language features provided by their ancestor. The most important extensions concern the management of configurations and versions of software systems, the provision of automated tools to support system construction as well as distribution, and the provision of linguistic means to express the semantics of components (Wolf et al., 1985; Goguen, 1986; Yau and Tsai, 1987; Perry, 1987; Zand et al., 1993; Purtilo, 1994). Moreover, these interconnections are not restricted to hold only between code level modules, but also between components belonging to different phases of the life cycle.
1.3 From Modules to Components We are now ready to distinguish between the terms module and component for the purposes of this article. The term module is reserved for designating a component with high coherence and low coupling at the design o r programming language level (Parnas, 1972; Yourdon and Constantine, 1979). The term component is used more generally, allowing us to refer to any conceptual building block of a software system at any stage of the life cycle, be it an object in some object-oriented language, a subsystem of the conceptual model of some system, or a library package. Following the same line of reasoning, the term component interconnection (CI) generalizes the term module interconnection(MI) to stand for intercon-
56
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
nection relationships between components, which are not necessarily modules or belong to the same kind. Components constituting a system at some early phase will differ significantly from modules with respect to various factors such as the language used for their specification, their size, and their degree of formality. In response to these differences, it appears quite natural that the interconnections between components will play different roles too and hence will carry different semantics when compared with code level interconnections. As examples of interconnections relevant in early phases consider the part-of relationship between a component and its decomposition into constituents, or the specialization relationship holding between some generic component and categories thereof. Clearly, these relationships greatly contribute to the understandability of a system model. Hence, their existence is motivated by factors other than, for example, supporting separate compilation or allowing for an efficient recompilation strategy, which-being traditional reasons for the specification of module interconnections-no doubt are essential for code level modules and their interconnections, but are of no concern to components not yet containing actual code. In short, both components and their interconnections need to be considered throughout the whole systems engineering process, and the roles they play may differ from phase to phase. Consequently, modeling CIS requires one to take into account both the representational issues at the outset, as well as their gradual replacement by more implementation and distributionoriented mechanisms later in the process. In other words, the subfields concerned with world modeling complement the traditional interconnection mechanisms, such as import-export or input-output relationships by providing means to express various semantic aspects. The need to integrate the software engineering and data/knowledge modeling perspectives on CI into a common framework seems well warranted (Motschnig-Pitrik, 1990).
1.4 Organization of the Article This article is organized as follows: The next section discusses the software engineering and data/knowledge modeling perspectives on CI and introduces central issues concerning CI specification. This sets the scope for Section 3, where the notion of CI is defined in more formal terms by introducing a simple abstract model to express CIS. The primary purpose of this model is to provide a general framework into which individual languages capable of expressing CIS can be mapped. As a result of this mapping, individual features of CI can be expressed, and individual instantiations of these features can be compared, regardless of the specific syntax of the language from which they originate. Since the abstract model largely
INTERCONNECTION OF SOFTWARE COMPONENTS
57
facilitates the comparison and discussion of CI features scattered throughout a broad spectrum of languages, it will serve as a language-independent frame of reference throughout the article. The fourth section reviews diverse language paradigms allowing for the specification and support of CIS.This section is primarily aimed at introducing the broad spectrum of mechanisms available for expressing CIS considered for detailed discussion in Section 5, which is the central section of the article. In that section special features of CI specification, such as the degree of precision, the syntactic structure of interconnections, and particularly, specific interconnection relationships, are described, demonstrated by examples, and discussed in terms of the abstract model. The primary motivation behind this mapping is to raise CI features to a level that is independent of their realizations in specific languages and (graphic) notations. This allows for a systematic analysis and comparison of CI features, resulting in the recognition of trade-offs in choosing between different manifestations. Finally, a schema for comparing the instantiations of diverse CI features in several languages, chosen to represent different language paradigms, is presented. A summary and a discussion suggesting topics for further research conclude the article. It is assumed that the reader is familiar with basic concepts of software engineering (such as design techniques, modularization, software quality), and procedural and object-oriented languages. Readers interested only in specific features of CIS may want to scan Section 4 and proceed directly to Section 5.
2.
Different Perspectives and Fundamental Issues
2.1
Software E nginee ring/Prog ra mm ing La ng uage Background to CI
The last decade saw a rapid increase in languages supporting modular units. This can be seen as a proof of the importance of modular, objectbased architectures, which, in turn, are a prerequisite for following an incremental or evolutionary life cycle. Languages belonging to this category, such as Ada (Ada, 1981) or MODULA-2 (Wirth, 1982), support the construction of a system by the composition of individual modules by providing linguistic means to express module-like building blocks and to specify the interconnections between them. Typically, modules are interconnected in such a way that some modules (servers) implement and provide or export resources, for example, operations, whereas others (clients) require or import these resources.
58
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
Focusing on the implementation level, the specification of CI is a prerequisite for separate compilation (Wirth, 1982; Booch, 1983). Individual components are compiled on a one-to-one basis in such a way that each component’s interconnection specifications, which constitute a contract specifying a component’s cooperation with, or dependence on, other components, are checked for consistency and completeness (Wolf et al., 1989). This is essential in order to ensure that separately developed components fit together. Object-oriented languages go beyond these object-based notions of modularity (Wegner, 1990; Nierstrasz, 1989) in supporting a dimension for capturing similarity between “modules” and in restricting communication between clients and servers to a rather rigid (messaging) scheme [c.f., Eiffel (Meyer, 1988, 1992) or Smalltalk (Goldberg and Robson, 1983) for pure object-oriented languages: C + + (Stroustrup, 1986), MODULA-3 (Cardelli et al., 1992; Harbison, 1992), or Oberon (Mossenbock and Wirth, 1991; Reiser, 1991) for hybrids]. As a consequence, different models (processes) for software construction emerge (Meyer, 1990; Henderson-Sellers and Edwards, 1990). It is important to note, though, that considerations about CI are not confined to the code level or to detailed design. Their leverage on upstream software products for reuse and evolution has been pointed out, among others, by Goguen (1986), Ramamoorthy et al., (1990), and Mittermeir and Kofler (1993). Hence, the description of C1 and its graphic visualization is also one of the key aspects of the various CASE tools developed in research labs or already present on the market. See the work of Dart et al. (1987) for a taxonomy or the series of ACM SIGSOFT (/SIGPLAN) symposia on “Software Development Environments” for progress in the state of research and application. Furthermore, complex systems are likely to change-evolve-over time as errors are fixed and new needs are accommodated. During maintenance and evolution, precise knowledge about component interconnection is highly valuable for indicating the propagation of changes triggered by updates in some component. Ideally, this propagation should point to all components that are affected by the change and hence have to be adapted. With “all components” we refer in this context not only to components related by structural aspects of a system on a given level of abstraction but also to the various representations a component may occupy during different stages of development. This is necessary in order to keep the code consistent with its specification. Evolution looks slightly different when a system is implemented using object-oriented technology. In this case, the introduction of new components in the form of new (sub)classes is likely to supplant changes performed within components (Meyer, 1988; Rum-
INTERCONNECTION OF SOFTWARE COMPONENTS
59
baugh et al., 1991). Nevertheless, the interconnections of a newly created class with its super- or subclasses have to be established, in order to specify the intended paths for the inheritence of resources. It is noteworthy, though, that inheritance paths have to be designed and managed carefully in order to be effective.
2.2
The Data Modeling and Knowledge Representation Background
Viewing C1 from the software engineering perspective, we have argued that the specification of CI plays a crucial role both in the construction and the maintenance of complex systems. Thus, CI is a great deal more than an implementation issue. Considering its representational dimension significantly contributes to the understanding of a system by transparently mirroring its architecture and by revealing which building blocks are used and how they fit together. This representational dimension is strongly present in those subfields of computer science that are concerned with world modeling, most prominently conceptual and semantic modeling (Brodie et al., 1984; Hull and King, 1987) and knowledge representation (Levesque, 1986). These subfields are focused on capturing and representing knowledge about a given subject matter to build faithful models of some aspects of the real world (Mylopoulos, 1990). Such models aim to be understood and reasoned about by humans and/or “artificially intelligent” systems. This task has been addressed in the respective subfields by devising interconnection mechanisms that enable one to capture as much of the semantics of the domain of interest as possible and simultaneously are cognitively grounded. Most recently, fields like domain and organization modeling advocate several advantages of modeling the environment in which information systems are to be applied (Yu et al., 1995). Semantic models enrich traditional ones by providing the means to organize components (classes or types) along structural dimensions such as generalization/specialization, aggregation/decomposition, or the memberof relationship. Object-oriented (00)models emphasize the organization of components along generalization/specialization relationships. In addition to the structural aspects already present in semantic models, components in object-oriented databases (OODBs) encompass operations to capture the behavior of objects. This additional behavioral aspect gives rise to further interconnection relationships based on the invocation of operations encapsulated within components. Due to the tight coupling between structure and behavior and due to the correspondence of the basic building blocks in OODBs and 00 programming languages (OOPLs), many OODBs use an OOPL as their data definition and data manipulation lan-
60
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
guage. In this case the interconnection mechanisms of the respective OOPL coincide with those of the OODB. This double role of OOPLs is highlighted by our emphasis on them in the remainder of this article.
2.3
CASE Environments
While today it is a standard requirement that modern computer-aided software engineering (CASE) environments available on the market help to model both static and evolutionary aspects of systems, their ability to describe component interconnection in either of these dimensions is biased toward their ancestral origin. The features to “interconnect,” say, the data modeling portion with the process modeling portion are with most systems only supported in such a rudimentary way, such that neither automatic propagation of change (in an arbitrary direction) nor selective notification for the need of change due to ripple effects of changes in the “other realm” are supported (Brown and McDermid, 1992). Since a detailed and fair treatment of the extent to which this kind of interconnection is supported would be far beyond the scope of this article, we focus here only on those interconnection aspects that are actually materialized in the target system t o be developed or maintained. Since it would be more than desirable to have a wealth of them also supported by development tools such that a high-level description of any of the interconnection aspects discussed later would be substantially more than a notification of intent to the human reader, the framework defined in this article is also designed as a taxonomic Structure into which various existing CASE tools can be mapped.
2.4
Components and Resources
Before proceeding, it is necessary to define some key terms and delineate the focal issues of CI to be discussed. The central term software component has already been introduced as a generalization of the term module. This conception is consistent with the one given by Penedo in the context of the Project Master Database (PMDB) project (Penedo and Stuckle, 1985). There, a software component is specified to be an artefact that encompasses any component of a software system, from a high-level description (used during design) to the unit or routine level (implementation). Note, that this definition does not contain any restriction on the size of a component. Specifically, a component can be either atomic or composed of several components, in which case it is also referred to as a (sub)system. Note further, that the term software component is tightly coupled with the software development and maintenance point of view. It does not, however, encompass other kinds of software documents or fragments thereof, such
INTERCONNECTION OF SOFTWARE COMPONENTS
61
as time schedules or project management information, which definitely play an important role in providing support for the software process (Ramamoorthy et al., 1990) but, for reasons of focus, are not discussed here. A component can be either monolithic, consisting of one part only, or it can be composed of two parts: an interface or specification part, providing the public view, and a body or implementation part, containing and hiding the internals of the component. In any case, a component defines a set of resources to be used within a component and/or in other components, its clients. Resources, in the most general sense, are nameable entities expressed in some language, depending on the phase of development, the purpose of the specification, and the domain of application. Thus, at the code level of programming languages, typical resources are procedures or methods, type names, variables, constants, etc. Other examples of resources include slots and rules in knowledge representation languages, specifications of constraints, declarative descriptions of methods, deductive rules, etc. Note, that a component may essentially be empty, that is, not define any resources. In this case it serves purely structural reasons, namely, to compile information on other components’ resources and interconnections. Such a component is termed structural.
2.5
Component Interconnections (CI)
We should emphasize that the task of CI, namely, the specification of the ways in which components are interconnected in order to perform the system’s function, involves two complementary aspects, a static and an evolutionary one. Whereas static issues concern individual language features provided in order to allow for the specification of CI, most notably the relationships provided to interconnect components, the evolutionary perspective deals with system generation tools, such as those for version management and configuration control. These allow for and enforce proper CI when generating a system, that is, when actually putting the components together. System generation tools alleviate the programmer or system engineer from a number of laborious tasks that otherwise would have to be performed manually. Examples of such tasks are the checking of interfaces for consistency and completeness, the tracing of the effects a change has on other components, or, specifically at the code level, the determination of a proper sequence of module (re)compilation. A precondition for all these conveniences is, however, that both the actual and the optional (permitted) CIS be specified at the static level. Taking this perspective, the linguistic means to specify CI are even more fundamental than the evolutionary ones, since the latter build on the former. To make this paper both as focused and as
62
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
self-contained as possible, we have chosen to provide an in-depth analysis of language features for CI-the static aspect-while giving annotated references and brief discussions with respect to the evolutionary aspect. Keeping reuse and object-oriented modeling in mind, components can be arranged into taxonomies (IS-A hierarchies) by interconnecting them with generalization/specialization links. This results in an organizational structure that is orthogonal and complementary to the “composed-of ” relationship resulting from decomposition (Kim, 1990). Furthermore, to allow for the reuse of components, the latter must be stored in a library or project database (Biggerstaff and Perlis, 1989). Irrespective of the phase of development, a key issue for reuse is to provide effective algorithms to facilitate the retrieval of components intended for reuse, refinement, or adaptation (Boudriga et af., 1992). Such algorithms tend to make use of a taxonomical organization of components and hence heavily depend on interconnections modeling generalization/specialization. Note that reuse and retrieval are not tied to the implementation level. Given a proper specification of the interconnections among corresponding components from different phases-it is feasible and even recommended-to reuse components from early phases of the development process (Mittermeir and Oppitz, 1987; Mittermeir and Rossak, 1987; Rossak, 1989; Biggerstaff and Perlis, 1989). One of the central issues of this article is to argue that CI relationships essentially contribute to the conceptual integration of data- and knowledgebased systems with programming languages (Bobrow and Stefik, 1983; Greenspan and Mylopoulos, 1983; Pitrik, 1988; Moss, 1989). As is shown in Section 5 , this is mainly because the same basic set of interconnections is suitable for describing CI in all three fields. Nevertheless, despite these evident conceptual similarities, at present, the precise semantics that individual languages associate with analogous interconnection relations are similar but not identical (Lenzerini et al., 1991; Borgida, 1991; MotschnigPitrik, 1993, 1994, 1995). This has caused some confusion, particularly in languages subscribing to the object-oriented paradigm since it addresses all three fields mentioned (LaLonde and Pugh, 1991).
3. A Model for Component Interconnection Specification In this section we define an abstract model that will enable us to express the basic concepts underlying any language, providing us with a means to specify CI. Thus, the model can be seen as defining the universe of discourse of a generic CIL. Later, this model will serve as a basis for comparing representative CILs as well as languages incorporating means to express
INTERCONNECTION OF SOFTWARE COMPONENTS
63
CIS. We proceed by deriving the kernel of the basic model, which gradually will be refined and extended to cover the diverse aspects of CI. To arrive at a useful model for CI, let us informally explain the universe of discourse of a simple CIL. Many ideas presented in this context are derived from DeRemer and Kron’s presentation on MIL-75 (DeRemer and Kron, 1976). Basically, a CIL deals with three sets: components, interconnection paths, and resources, the “currencies of exchange” among components (via their interconnection paths). Components already have been defined to encapsulate a number of resources, nameable entities used to specify o r encode the individual belongings of a component. For example, a resource of a component at the design stage might be the pseudocode of a procedure or an entity specification according to JSD (Jackson, 1982). In the requirement specification phase a resource could be the specification of a procedure using pre- and postconditions or any (in)formal description of well-identified requirements. However, the most prominent feature of a resource with respect to CI specification is the fact that it is a component’s part that can be referenced. Resources are derived from or exchanged between components on directed interconnection paths, whereby an arc or link from component A to component B indicates that B depends on (for example, uses) resources provided by A. The following discussion on CI will be restricted to categories of relationships that are general enough to interconnect-in the sense of to organizesoftware components irrespective of a particular application. This subclass of semantic relationships will be called organizational or structural relationships, as opposed to (application-specific) reference relationships, also known as association relationships (Fig. I). Thus, the organization of classes in terms of generalization/specialization relationships is an example of an organizational aspect, whereas the relationship between an “employee” class and a “company” class in “employee works for company” constitutes a reference relationship that is specific to enterprise modeling. To be able to discuss CI throughout different phases of development, yet another category of semantic relationships needs to be considered. semantic relationships
organizational relationships
I
1 Ireference relationships 1 Irepresentational relationships
pZKzlW]
..
FIG. 1. Categorization of semantic relationships.
64
R. MOTSCHNIG-PITRIK
AND R. T. MIlTERMEIR
Relationships of this third category are called representational in order to indicate that they constitute interconnections among different representations applied in subsequent developmental phases. Following this dimension, components identified in the analysis phase need to be interconnected with design-level components that again are linked to their code level counterparts. Having informally described the universe of discourse of a simple model of component interconnection, a more formal definition can now be given. Although CILs can be defined using attributed grammars, as was done by Knuth (1968), or the model-based specifications of Rice and Seidman (1994), we prefer a definition via graphs, since these seem to be visually more appealing for displaying the structure of a system. The graph model is aimed at providing a common representation of CI and related issues, in order to facilitate the comparison of different approaches for expressing CIS. The basic interconnection path (BIG) denotes the kernel of the abstract model. The BIG is defined as a four-tuple: BIG = ( C , R, Cr, Ic) where C = finite set of nodes labeled by the unique names of the components R = finite set of resources, R = { r l , r2, . . ., r,}, 0 5 n < co Cr = mapping C + P(R) (the powerset of R) so that each component is associated with a set of resources (being a subset of R) Ic = finite set of ordered pairs of nodes (q,cj), the edges in the graph, denoting some interconnection relationship (e.g., “uses,” “subclass”) between the components. The edges are labeled by the name of the relationship Ic.
The four components of the BIG serve as a framework for the discussion of interconnection structures. This discussion can be conducted on the level of programming and interconnection languages as well as on that of specific applications. Such discussions lead to different interpretations of the BIG. An example of such an interpretation at the application level is given in Fig. 2, which shows an example of an application Ap, consisting of three components referred to as X, Y, and 2. With each component a (possibly empty) set of resources is associated, Rx, Ry, and Rz, respectively. The components are linked in such a way that X is “interconnected with” Z and Y is “interconnected with” Z , where “interconnected with” might be an arbitrary but well-defined relationship (labeled “ic” in the figure).
&
INTERCONNECTION OF SOFTWARE COMPONENTS
c
65
= {X, Y. Z)
R = RxURyURz
Rx FIG. 2. A BIG with three nodes and a generic interconnection relationship “ic.”
Mapping this application into the BIG framework yields the following interpretation:
It should be understood that this interpretation of the BIG is based on the inherent properties of the application at hand, properties that are not constrained by the constructs built into some particular language. Hence, we refer to this particular interpretation as the AIG (Ap), the application interconnection graph of Ap. Any particular language capable of expressing CIS will, however, be biased to some specific aspects of interconnection and might conversely not express others (c.f. Section 5). Hence, we can also give a rather orthogonal interpretation of the BIG by mapping the features of a given language into the BIG framework. Consider, for example, Ada. The BIG model defined so far is already sufficient to describe the “with” relationship in Ada. This is accomplished by associating:
C with the set of compilation units making up some system, R with the variables, constants, types, procedures and functions of that system, Cr with a function association with each unit a subset of R, and Ic with the “with” relation denoting the import of units. Given these associations, the example in Fig. 2 can be interpreted to describe a library unit Z, such as a package that implements some mathematical functions being imported (used) by two program units X a n d Y, performing coordinate transformations and plotting function graphs, respectively. In a different setting, say, in object-oriented programming, the BIG model defined so far is capable of describing the subclass hierarchy in object-
66
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
oriented languages such as in SmallTalk. This is achieved by identifying the set C with the classes of the system, R with the instance, class, global, and pool variables and the instance and class methods, Cr with a function associating to each class a subset of R, and Ic with the “is-subclass-of” relationship having a tree structure (in the case of SmallTalk). Thus, interpreting the example from Fig. 2 in the context of SmallTalk, we could say that X and Y are subclasses of class 2. In general, in the languagespecific interpretation of the BIG model, the individual features that languages provide for expressing CIS are mapped onto the components of the BIG. Essentially, this interpretation leads to partitions of the sets of C, R, Cr, and Ic, making it possible to express precisely those CI features (discussed in section 5 ) provided by a particular language. In general, the graph resulting from any language-specific interpretation of the BIG will, due to the partitioning induced by the respective language, be more refined than the BIG. We refer to this more refined framework as the RIG, the refined interconnection graph. Whenever necessary, we use the particular language that defines this refinement as a suffix. Taking the sequential subset of Ada as an example again, RIGAde,the language-specific interpretation described later consists of the following partitionings:
C
Cpac U Cprg U C m a i n , packages, programs, and the main program; R = Rvar U Rcon U Rtypc U Rsuhp U Rlah, variables, constants, types, subprograms, and labels; Cr = Crpuhl U CrprlvU Crimp, public and private resources, and resources imported via a with or a uses clause. =
Focusing on the refinements of Ic, we identify the following for Ada (discussed further in Section 4.6):
Ic
= ICwilh
u Icuse, u Ic “is separate” u Ic “is new“ u IClocal-to,
the with, the uses, the “is separate,” the “is new” clauses, and the nesting of (local) components. Our discussion of diverse categories of Ic relations focuses on static interconnections. This means that control flow and topics concerning the order
INTERCON NECTlO N OF SOFTWARE COMPONENTS
67
of execution are not addressed. For an excellent survey on communication mechanisms in a concurrent environment see Andrews and Schneider (1983). Concurrency in object-oriented languages is discussed, for example, by Tomlinson and Scheevel (1989), and various dynamic aspects in objectoriented languages are described in several chapters of Kim and Lochovsky (1989). The focus here is on the specification of different categories of interconnection relationships, such as provisioniacquisition of access or generalization/specialization. Furthermore interconnection relationships are discussed with respect to two further dimensions; the syntactical structure and the degree of precision. The latter deals with the question of how precisely a contract on interconnection is specified. An alternative approach to the formalization of MILs is presented by Rice and Seidman (1994). The authors take a model-theoretic approach by providing a collection of Z-schema type definitions, in order to formalize the design of module structures. Particular MILs can be described by specifying the values of specific parameters and completing the generic schemas. While the model proposed by Rice and Seidman is primarly targeted at describing the process of constructing hierarchical module structures, the BIG-RIG model focuses on exposing the similarities and differences of language features employed for the specification of CIS.
4.
Survey of Language Paradigms for the Specification of Component Interconnection
This sections classifies language features for expressing CIS in terms of language paradigms. The goal is to expose the reader to the whole spectrum of languages and language fragments considered in this report and, furthermore, to present alternative solutions to questions such as these: In which phase is the information on CI specified? T o what degree does a CIL depend on other languages? How is the specification of CI incorporated into some host language or software development environment?
4.1
CIL as a Compiler Option
Historically, one of the first possibilities to share resources among compilation units and thus to compose a program from different files was the provision for compiler directives. These are language extensions consisting of keywords known to a compiling system that control the compilation of resources shared among compilation units. For example, in VAX-Pascal
68
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
(Digital, 1983) the keywords global and external are used to share routines and variables, whereas environment and inherit enable the incorporation of whole files into compilation units. In the compiler directives approach, the whole “CIL” consists only of some keywords directing the linking process of independently compiled units. The most important advantages of using compiler directives as the CI mechanism are their simplicity and generality. However, since the same directives may be used with different languages (e.g., Pascal, FORTRAN, COBOL) there is nearly no possibility for checking the consistency of types and parameter lists. Directives tend to be bound to a specific compiling system resulting in a decreased portability of programs using directives. A further severe disadvantage of the directives’ approach lies in the fact that the component interconnection specification is buried within the rest of programming code and may be overlooked, leading to disastrous effects when updating shared resources. To overcome the lack of consistency checking and portability, facilities for the specification of CIS have been designed into more modern languages.
4.2
Component Interconnection Specifications Embedded into Various Languages and Notations
This subsection provides an overview of the means that various languages and, more generally, (graphic) notations use for expressing component interconnection. A more detailed discussion is presented in Section 5, where specific interconnection mechanisms are analyzed in terms of individual aspects (e.g., precision and locality) of interconnected information.
4.2.1 Component Interconnections in Requirements Specification and Design Languages Data Flow Diagrams. Data flow diagrams and related techniques [e.g., SA (Yourdon and Constantine, 1979), SADT (Ross, 1977), D F D (Gane and Sarson, 1979)] are often used to express (functional) system requirements. If the nodes (“bubbles,” activities, processes) of a data flow diagram are identified with components, the interconnections among components are established via data flows, directed arcs labeled with the names of data resources. Thereby full flexibility with respect to interconnections is provided, the only constraints being the actual data requirements of each component. In terms of the BIG, an arc between components c1 and c2, labeled with the data resource r, can be interpreted as c1 providing r (to
INTERCONNECTION OF SOFTWARE COMPONENTS
69
the environment) and c2 requiring r (provision and requisition will be dealt with in more detail in Section 5.6.2). The high degree of flexibility of data flow diagrams in determining what should be classified as a component and which data flows are to be specified makes formal data flow techniques well suited for modeling the problemrelated, functional view of a system (which is neither data structure oriented nor computing intensive). The detailed semantics of CI can, however, only partially be given on a fully abstract level. They are often obtained by project- or company-specific standards.
System Structure Descriptions. Since the decomposition of systems into modules and the specification of module interconnections are the central activities of the design phase, design languages have always incorporated means to express module interconnections. In traditional design languages [e.g., SD (Yourdon and Constantine, 1979), H I P 0 (Stay, 1976), Plasma/D (Balzert, 1982)], modules (components) are organized in a hierarchy. The interconnections between modules are constrained to lead along the edges defining the hierarchy and are specified in module interfaces. An interface specification holds three (possibly empty) sets of parameters, namely, in, out, and inout parameters, naming the required, provided, and transient resources, respectively. Besides these explicitly stated interconnections “hidden” ones may also exist, resulting from the scoping rules typically provided by procedural languages with nested components. Since the interconnections specified in a design exactly correspond to those in the program, recent CASE environments provide tools to transform automatically the CI information contained in a formal design into skeletons of programs (Martin and Odell, 1992). Object-Oriented Analysis and Design. A quite different philosophy of software construction is followed in object-oriented development. As the term object oriented indicates, design is centered around objects, which, typically, but not necessarily (Kim and Lochovsky, 1989) are grouped into classes according to similarities among their properties and their behavior (Mittermeir, 1986; Wegner, 1987). Components in object-oriented systems correspond either to classes, or to encapsulated groups of related classes (Booch, 1991; Rumbaugh et al., 1991). These components are preferably referred to as modules. Using, for instance, the 00 structured design (OOSD) notation (Wasserman et al., 1990), the modeling of a situation in which a class (module) U2 has access to the class (module) U1 via procedure pr results in the graph shown in Fig. 3. Drawing procedure pr to overlap Ul’s class box causes pr to be visible (i.e., global), whereas pr’s visibility in U2 (the fact that U2
70
R . MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
FIG.3. Simple example of modeling CI in OOSD
may use pr) is established by drawing a thick arrow from U2 to U1. Note that Fig. 3 shows only one aspect of CI in 00 notations, others being generalization/specialization, inheritance, instantiation, and generics (see Section 5 ) . In general, a wealth of graphic notations is suggested for objectoriented analysis (OOA) and object-oriented design (OOD). Compare, for instance, Wasserman et al. (1990), Coad and Yourdon (1991), Booch (1991), Rumbaugh et al. (1991), and Embley et al. (1992), and Martin and Odell (1992). Examples of widely used notations are object-flow diagrams as a counterpart to data-flow diagrams and object-relationship models as a counterpart to entity-relationship models (Martin and Odell, 1992).
4.2.2 Component lnterconnection Specification in Data/Knowledge Modeling Traditional data models (DMs) such as the relational model do not foresee linguistic means for the specification of organizational interconnections among entity types. Instead, the interconnections described are special-purpose ones (see “reference relations” in Fig. l), such as “employee works for company.” A similar characterization applies to early semantic networks, which provided a graph-based notation for expressing relationships between concepts (components) by special-purpose links. Later semantic networks and frame-based systems, however, complemented the special-purpose links by more general, organizational interconnections such as “is-a” links and “part-of” links (Brachman, 1979). It is these interconnections that were introduced to the database community by Smith and Smith (1977) and that remained characteristic for the whole generation of semantic models. Organizational relationships such as generalization/specialization and aggregation/decomposition have also been adopted in the field of objectoriented approaches. In particular, some OODBs such as ORION (Kim, 1990) offer their own data model into which a set of relationships for
INTERCONNECTION OF SOFTWARE COMPONENTS
71
interconnecting classes (components) is embedded. Alternatively, OODBs use an OOPL as a data definition and data manipulation language. In this case, the component interconnection mechanism of the OODB coincides with that of the underlying OOPL (see next subsection). Examples following this approach are the OODB Gemstone (Purdy et al., 1987) with the OOPL Opal, which is a dialect of SmallTalk, or the OODB ONTOS with C + + (Andrews and Sinkel, 1991). Due to the importance of SmallTalk and C+ + not only as OOPLs but also as data definition and data manipulation languages of OODBs, special emphasis is given to the interconnection mechanisms of these two languages.
4.2.3 Component Interconnection Specification in Programming Languages Having recognized the impact of explicitly expressing module interconnection information on software quality, programming languages have been designed to incorporate linguistic facilities to specify interconnection information. This applies not only to procedural languages such as Ada (Ada, 198l), MODULA-2 (Wirth, 1982), and to object-oriented languages such as Smalltalk (Goldberg and Robson, 1983) and C + + (Stroustrup, 1986), but also to database programming languages such as TAXIS (Mylopoulos et al., 1980) and ADAPLEX (Smith et a/., 1983), and to knowledge representation languages, for example, KEE (Fikes and Kehler, 1985), LOOPS (Bobrow and Stefik, 1983). Interestingly, languages significantly differ in their support of specific issues of interconnection specification (to be discussed in Section 5). Nevertheless, some common features characteristic of the above-mentioned languages are the following:
0
Languages provide constructs for partitioning a system into single components (compare the set of nodes of the BIG), often referred to as compilation units. Examples include packages, programs, and separate program parts in Ada; classes and metaclasses in SmallTalk, TAXIS, and LOOPS; classes in C++; units in KEE, etc. Within the program there exist designated locations for expressing specific aspects of interconnection information. Examples include package specifications in Ada; and partitioning of classes (units) into sections, whereby the first contains interconnection information, such as SmallTalk, TAXIS, LOOPS, KEE. Compiler support is provided for consistency checking. The compatibility of types and parameter lists of shared resources is checked by the compiler. Name clashes can be detected.
72 0
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
Compared with compiler directives, CI specifications provided by programming languages share the capability of expressing more finegrained and diversified interconnection information. Consider, for example, Ada’s means for specifying CI. These include concepts such as packages, use clauses, with clauses, is-separate clauses, private resources, limited private resources, generics. Most of these concepts are revisited in Section 5.
Compared with the compiler directives approach, the incorporation of CI specifications as integral parts of programming languages has these advantages: 0
0
0
They lead to better portability of programs due to their independence of diverse extensions to compilers. They allow for rigorous consistency checking, make utilities (Feldman, 1979), smart recompilation (Tichy, 1986), and efficient recompilation (Hood et af., 1986). They provide more expressive power. They support the understandability of the high-level program structure.
Disadvantages arise from the fact that the CI specification is restricted to be used only within ‘‘its” language. As a result, modules written in different languages can only be combined, if at all, with great difficulty. Further, programming languages grow in size and hence are more difficult to learn and to support. At the same time the CI portion is forced to have the level of detail of a programming language, making the former unsuitable for earlier phases of specification. These observations, accompanied by the finding that programming-in-the-large and programming-in-the-small are different intellectual activities (DeRemer and Kron, 1976), have led to the design of CILs independent of programming languages, yet with more expressive power than compiler directives.
4.3
ClLs as Independent Languages
This subsection discusses self-contained languages that have the goal of being designed to describe architectural properties of software systems. We start with a detailed description of MIL-75 and its mapping into the BIG model resulting in a RIG for MIL-75. The successors of MIL-75 are then described mainly in terms of the extensions to MIL-75 they provide. T o comply with the previous literature and to point to the phase in which the respective languages are applied, we call them MILs instead of using the more general term CIL. Readers interested in further details regarding these MILs are referred to the references given in this section as well as
INTERCONNECTION OF SOFTWARE COMPONENTS
73
to a detailed survey on these MILs (Prieto-Diaz and Neighbors, 1986). The emphasis here is on the features MILs provide for the description of components and their interconnections. Further, we aim at providing insight into the ways in which CILs are integrated in software development environments (SDEs) in order to be helpful in actually constructing and maintaining systems in conformance with the CI specifications.
4.3.1
MIL-75
One of the first influential MILs, MIL-75, was developed by DeRemer and Kron. Although the universe of discourse of MIL-75 has already informally been described in the introduction, we now use our abstract BIG model to allow for a more precise specification of the most important features of MIL-75. We have two main reasons for a thorough discussion of MIL-75 in terms of the BIG: First, it serves as an example of the transformation of a complete MIL into the BIG model. Thereby a clear understanding of the relation between a MIL and the components of the BIG model can be established. Second, since MIL-75 was a pioneering language, many features of successor MILs (and CILs) can be explained as generalizations, refinements, extensions, and simplifications of features of MIL-75, so that a precise conception of these basic features is essential. To demonstrate MIL-75, consider an abbreviated form of an example from DeRemer and Kron (1976). Figure 4 holds a description of one node, called “Input,” from a part of a theorem-proving system (Wirth and Hoare, 1966). The corresponding part of the graphic representation (omitting the system Language-extensions and its links) is sketched in Fig. 5. Figures 4 and 5 are intended to serve as prototypical examples of a textual and corresponding graphic representation of a MIL specification. In MIL-75, the nodes of the graph, depicted as ovals in Fig. 5 , are called systems. Systems are identified by unique names and, with the exception of (purely) structural systems, are associated with modules (shown as rectangular boxes in Fig. 5 ) holding resources. The bold edges in Fig. 5 constitute the system tree such that each edge connects a system to its subsystem. Dotted lines going upward by the bold edges indicate that resources provided by a subsystem are also provided by its parent (compare, e.g., the declaration “provides Input-parser” in Fig. 4). Solid arrows between the child nodes of a system denote sibling accessibility links (compare, e.g., “has access to Scan” in the.subsystem “Parse” of Fig. 4). Dashed arrows indicate that the node on the head of the arrow uses resources provided by a node at the tail of the arrow (corresponding, e.g., to the “must provide” and “uses derived” declarations in Fig. 4). In general, a system description of a node n in MIL-75 consists of statements specifying the following:
74
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
system lnput author 'Sharon Sickel' date 'July, 1974' provides lnput parser consists of root module originates
Input parser
uses derived
Parser, Post-processor
uses nonderived
Language-extensions
subsystem Scan must provide Scanner subsystem Parse must provide Parser has access to Scan subsystem Post must provide Post-processor FIG.4. Description of a node in MIL-75.
0
0 0
0
The name of the node (followed by the designer's name and a date as shown in Fig. 4) Pr(n), the set of resources provided by n Mod(n), the module associated with n (if any), together with three sets: Or(n), resources originating from n; Ud(n) derived resources used in n (whereby a resource is called derived by n, if it is provided by some child of n);and Und(n), nonderived resources used in n (meaning resources being provided by sibling or inherited access) For each child m of n: its name and the resources it must provide, Mp(m); the set of all nodes k such that m has sibling access to k, Legend
-
--
system tree
_c accessibility
used resources
......c
provided resources (not shown in this figure) FIG.5. Graph displaying a fraction of the system structure of a theorem proving program in MIL-75. [Redrawn from DeRemer and Kron (1976)l.
INTERCONNECTION OF SOFTWARE COMPONENTS
75
written as m Sac k; and the set of all nodes k such that rn inherits access to k, m Iac k. Let us now map the MIL-75 description given above into a refinement (RIG) of the BIG model resulting in the tuple RIGMIL-75 = (C,R,Cr,Ic), whereby C, R, Cr, and Ic are defined as follows:
C. The set of nodes denoting the descriptive components of a system has to be partitioned into three sets: 0
0
A set with a single element holding the single node called “rootsystem.” This is a distinguished node due to the fact that in MIL-75 a system tree is postulated. A set holding “structural nodes,” i.e., nodes without a “module”; for each structural node n, the sets Or(n), Ud(n), Und(n), and Mp(n) are empty. A set of nodes that holds modules containing resources, whereby all leaf nodes must hold modules.
R. The set of resources need not be partitioned, since different kinds of resources are not distinguished in MIL-75. The only characteristic of a resource with respect to the MIL is its role as an individually referenceable entity serving as the currency of exchange between nodes. Cr. MIL-75 has five ways to associate resources to a system ( n ) ,namely, Or(n), Ud(n), Und(n), Pr(n), and Mp(n). Integrity constraints, such as Pr(n) 2 Mp(n) for all nodes in C, or, for example, Or(n) n Or(k) = 0 for every n, k in C, are defined in MIL-75, but are not discussed here. Ic. In MIL-75 there exist four categories of interconnections relationships (compare Fig. 5): 0
0
0
0
The “parent function” associates each node (except the “root”) with its parent such that the resulting structure forms a tree. The parent function constrains the paths denoting the “flow” of provided resources from a child to its parent (compare the pairs of declarations “uses derived”-“must provide”). The Sac and Iac relationships specify sibling and inherited access between nodes, respectively. The usage links (shown as dashed arrows in Fig. 5): If a node n has access to a node p and the module m at n uses a resource provided by p , then a usage link originating in p leads to m. By this mechanism a node rz may be provided access to nonderived resources [Und(n)].
76
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
In the case of the set Pr(n), which corresponds, for example, to the export clause in MODULA-2, two kinds of interpretations are possible: On one hand, from the view of node n, Pr(n) denotes the set of those resources that n provides to its environment and thus Pr(n) stands for a specific kind of association (Cr) of resources to the node n. On the other hand, viewed as an interconnection relation, Pr(n) can be interpreted as a set of arcs (pairs of nodes) (n, ci) originating at node n and leading to all other nodes cj of the system such that resources from Pr(n) generally are made visible to the environment. This example shows that the notions of Cr and Ic depend on each other.
4.3.2 Second-Generation MILS Having described MIL-75, we briefly scan the evolution from MIL-75 to the incorporation of MIL concepts into SDEs such as the Gandalf SDE (Habermann and Notkin, 1986) or Inscape (Perry, 1989), concentrating on the basic system structures supported by the respective MILS and investigating the ways in which CI mechanisms depend on these system structures. Although most of the features of MIL-75 can be expressed (and are further refined) in its successors, the fact that the overall system structure must be an oriented tree is not postulated in any of its successors. In Thomas’s MIL (Thomas, 1976), a system is modeled as a layered decomposition into components, whereas Cooprider’s MIL (Cooprider, 1979) advocates the nesting of components and provides two further CI mechanisms: external clauses and environment definitions. These two relationships loosely correspond to the accessibility of resources among siblings and resources from parents passed to children in the MIL-75 hierarchy. Whereas MIL-75 established the most important basic features of CI, the issue of integration of a MIL into a SDE has not been dealt with. Thus, the main benefits of MIL-75 are in describing the system structure, including all foreseen accesses to resources across module boundaries, and in having the MIL compiler check this description for consistency. In this way, wrong design decisions as well as inconsistencies regarding the access to resources by individual modules can be detected before coding and construction begin. Thomas’s MIL goes further by allowing one to establish a direct connection between the MIL specification and a particular implementation of a module by incorporating the clause “using ” in the syntax of his MIL. Note, however, that the interconnection is performed after the compilation of the module only. Although the MIL processor can be used to check whether resources are accessed consistently in a first step, the coding of individual modules is required to be completed prior to a further
INTERCONNECTION OF SOFTWARE COMPONENTS
77
call to the MIL processor to do the binding and perform the necessary module interconnections. Unlike Thomas’s MIL, which depends on the compile/link paradigm, Cooprider’s and Tichy’s MIL (Tichy, 1979) facilities are built on top of a database (DB) manager. This provides additional flexibility by allowing module coding to be interleaved with system design. The use of a DB further serves as a basis for extending the pure module interconnection aspects provided by Cooprider’s and Tichy’s MILs by facilities for software construction and version control. T o demonstrate the interplay of these three aspects within an extended MIL we proceed by presenting selected features of the system version control facilities of an extended MIL, building on the concepts of Cooprider’s and Tichy’s MILs, which have been incorporated into the Gandalf prototype (GP).
4.3.3 The Gandalf Prototype GP is a prototype of a full-fledged Gandalf SDE that uses a common development database to allow for the integration of various tools, among others, a collection of tools for system version description and control, as well as tools for incremental compilation. In GP, the module interconnections are specified in a module’s interface along with the set of versions that implement the interface. Consider, for example the following two interfaces: module M p r o v i d e s r l , r 2 ; i m p l M I w i t h X; i m p l M 2 w i t h Y;
module N p r o v i d e s r3; i m p l N 1 w i t h X, Z; end N
end M
In the example, module M has two versions, M1 and M2. The two could differ either in terms of the programming language used for their implementation, or they may simply use different data structures and/or algorithms to realize the resources r l and r2. In any case, each M1 and M2 has to implement both resources r l and r2 as specified in the provides clause of M. The implementation is essentially a source program defining bodies for all resources listed in the module interface. Note, that the with clausedenoting the required resources-is associated with the individual implementations instead of the module as a whole. This is because different implementations may require resources from different modules in order to realize the provided resources. An essential objective of GP’s extended MIL facilities is the automatic generation of executable system versions. This is accomplished by instantiating a module, a version, or a revision. The process of generation proceeds
78
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
automatically, such that the minimal steps required for system generation are derived from the system description without human intervention. Compared with the “make” facility of UNIX, in GP the implementor specifies the dependencies among (logical) modules instead of having to deal with files.
4.3.4 PIC PIC (Wolf et al., 1985, 1989), a language designed for Precise interface Control, is a self-contained extension to the module interconnection portion of Ada focusing on high granularity and precision of interconnection information. In PIC, two kinds of components (called modules) are distinguished: packages and programs, corresponding to their Ada namesakes. To separate module interconnection and interface control information from algorithmic detail, a module (unlike in ADA) always consists of a specification submodule and a body submodule. Note, however, that in PIC there is a one-to-one correspondence between specification and body parts such that module families, like those in the GP and Intercol, are not supported. While a package’s specification submodule [compare Fig. 6 (Wolf et al., 1985)] describes the entities encapsulated by the package, a subprogram’s specification submodule holds the information needed to invoke the subprogram. Both kinds of specification submodules (unlike in Ada) completely package PrintQueue i s request LinkedList.(ListElement,List); type Jab i s new LinkedList. ListElement provide to Reorder;
type Queue i s new LinkedList. List provide to Reorder;
procedure Enqueue (J: in Job; Q in out Queue) request Linked List. Append, _... procedure Dequeue (J:out Job Q in out Queue) request LinkedList.Delete provide to Printer; private procedure Util (...) request LinkedList. Statistics,
..,
end Print Queue;
FIG.6. Example of a specification submodule in PIC.
INTERCONNECTION OF SOFTWARE COMPONENTS
79
capture the description of the module’s interconnections with other modules via sets of request and provide clauses. To gain precision, it is possible to attach a request clause not only to the whole specification submodule, but also to a single entity of a specification submodule. For instance, the clause “request LinkedList.Append” (in Fig, 6) is attached to the procedure “Enqueue.” Also provision of access to entities need not to be given on an “all or none” basis, but can be controlled by naming the modules being allowed access to some entity. For example, the module “Printer” (in Fig. 6) is the only module (besides PrintQueue itself) that has access to the procedure “Dequeue.” Even more degrees of control over provided packaged entities can be expressed concerning type definitions: A provided type can be associated with two provide clauses, one referring to the provision of the name, the other to the provision of the representation.
4.3.5
MlLs Incorporating Specifications of Semantics
L/L. Whereas PIC is focused on precise control of provided (exported) and required (imported) resources, the Library Interconnection Language (LIL) (Goguen, 1986) has been designed with special emphasis on supporting the reuse of components. This goal is approached by incorporating novel concepts into LIL. These new concepts point in two directions. The first basic idea underlying LIL is the incorporation of semantics into component specification in order to allow one to describe what each component is supposed to do. This information may consist of formal specifications, such as sets of axioms, and/or less formal descriptions, that can be associated with system requirements. The second core idea of LIL is to raise modularization issues to higher levels of specification. Analogous to how Ada’s package construct serves to modularize code, Goguen claims that formal specifications, documentation, requirements, and designs should also be modularized, since they too can be difficult to understand if presented monolithically. In analogy to module interconnections, predefined relationships and statements could then be used to assemble specifications and other documents. This idea is reflected in LIL in several ways: LIL’s abstract syntax used to specify packages, the distinction between package specifications and versions which realize the specifications (in analogy to families of components), and finally LIL’s way of addressing vertical (sometimes called hierarchical) development activities. These concern interconnections allowing one to move between different levels of specification or representation and are supported in LIL in addition to horizontal activities-already discussed in the context of the
80
R. MOTSCHNIG-PITRIK AND R. T. MlTERMElR
preceding MILS-directed toward imposing structure and interconnections at one level of specification.
NuMIL. Whereas LIL is focused on the reuse of components, the language NuMIL (Narayanaswamy and Scacchi, 1987) has been designed with special emphasis on the evolution and hence also configuration management of software systems. The key problem addressed in NuMIL is that of maintaining the integrity of systems’ configurations during maintenance. This task requires consideration of static aspects of CI-in other words, the ways in which components depend on each other-from the point of view of preserving dependencies between the components in the course of system evolution. This results in a rigorous coupling of static and evolutionary issues of CI in NuMIL. Due to this focus, NuMIL contributes some innovative features to the CIL area. We discuss them briefly in the sequel. A detailed example of NuMIL’s way of interconnecting component specifications with their versions follows in Section 5.6.7 where versioning is discussed. As already advocated in Cooprider’s MIL and its successors, the key notion in capturing the evolutionary view of software systems is that of a system family. The family members, called implementations or versions of that family, are related systems created during system evolution. But where the criterion for family membership in the preceding MILs is the syntactic conformance with a family’s interface, in NuMIL, as in LIL, semantic properties govern family membership: Versions, in addition to displaying suitable syntax, are required to fulfill semantic properties specified in the interface of a family. In spite of several resemblances, NuMIL differs from LIL, the GP, and other MILs in a number of subtleties, such as the way in which it incorporates semantics, the structure of its components, its basic system structure, and, as already indicated, the structure of versions and the criteria for their association with a family. In NuMIL each node in the system graph that models a software system denotes not just a single component, but a set of components that make up the whole family. Specifically, module family interfaces differ from traditional interfaces in essentially two aspects:
0
First, different implementations may embody completely different methods for doing the same thing. Therefore, in NuMIL different implementations (versions) may require different resources and provide resources with the same functionality but using different syntax. Second, since syntactic assurances about module interfaces are considered inadequate for the characterization of resources provided across module boundaries, as well as for determining family membership
INTERCONNECTION OF SOFTWARE COMPONENTS
81
[compare also Perry (1987) and Perry and Kaiser (1991) and LIL], in NuMIL semantic properties of resources govern family membership. Both differences are motivated by the observation that, traditionally, all implementations share the same interface being determined by the syntax of the resources a module provides and, in most languages, also the syntax of the resources it requires. This is seen as an inadequacy in NuMIL and is responded to in the following way: In NuMIL, interface specification is approached in an abstract style, similar to the specification of abstract data types (Guttag, 1975), following the style of Hoare (1969) and Jones (1980), resulting in a module family template. This module family template constitutes the first, abstract, part of a family specification and unites all of the different versions or members of the family. The second part of a module family specification, however, holds information peculiar to each version or member (implementation) and is called the concrete interface or the implementation specification. Thus, the description of a module family in NuMIL, the structure of which is outlined in Fig. 7, unites a family template with the corresponding implementation specifications in one descriptive component. Thereby the interconnection between the family and its members (versions) is established. Specifically, note that the family template characterizes the resources provided by the family and specifies their properties in an implementation-independent way, whereas the concrete interface reveals the details peculiar to each implementation and depends on module family m-name is provides /* list of names of provided resources * I ; properties I* abstract specification of resources complemented by their semantics */; I* end of abstract template * I
implementations version vl-name { realization / * name of source file * I ;
provides /* implementation dependent specification of provided resources */; requires /* implementation dependent specification of required resources */; properties
I* semantics of required operations in pre- and p t condihon style*/;} version vZ-name {-..}
end m-name
FIG. 7. Outline of the structure of a module family specification.
82
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
the programming language used for the implementation of the respective version. Each implementation specification provides at least the resources advertised in the template specification and typically requires some resources to implement the provided ones. Summarizing, NuMIL integrates many of the ideas of previous CILs. Perhaps the most significant departure between NuMIL and previously mentioned MILS and CILs can be stated as follows: In NuMIL the interconnection between a family and its members is based on semantic rather than syntactic grounds. Since the module family template is written in an abstract style, independent of any implementation language, no two members of one family need to share the same syntax for the resources they provide and require. Consequently, different versions may supply the same resources by using different syntax, as long as the abstract interface is adhered to. This is appealing since, during evolution, different implementation languages may be used to realize a module. Further, modules can evolve in a flexible way, solely bound to obey the abstract interface. The authors report that a prototype system is available at the University of Southern California-Los Angeles and has been tested in the course of the System Factory Project (Scacchi, 1986).
RMTIL. The more recent MIL called RMTIL [ROPKO Module Template Interconnection Language (Zand et al., 1993)] has been designed as an integral part of the ROPCO (Reuse Of Persistent Code and Object code) environment. The primary objective of RMTIL is the reuse of both fine- and coarse-grained units of program code. This is why modules, the basic units of interconnection, are further decomposed into templates, which serve as complementary units of reuse. Templates are segments of code corresponding to a syntactic construct of a high-level language. Thus, besides specifying version and family information and, in particular, interconnections between modules in the style of Inscape (Perry, 1989), RMTIL modules carry intraconnection information that is required for specifying dependencies between individual templates, such as control flow and local variables. Furthermore, in order to enhance the potential of verification and reuse, RMTIL modules incorporate pre- and postconditions in the style of Hoare’s input-output predicates, providing a formal specification of a module’s semantics. The !‘oLYL/TH MIL. The POLYLITH system (Purtilo, 1994) extends the notion of CI to components that may execute in heterogeneous environments, such as distributed networks or shared-memory multiprocessors. The separate treatment of functional requirements from interfacing requirements allows programmers to write code that can be adapted for reuse in
INTERCONNECTION OF SOFTWARE COMPONENTS
83
another environment by automatic techniques. This is achieved by introducing a programming language-independent MIL and an abstract decoupling agent, referred to as a software bus, to which all components are interfaced. In the POLYLITH MIL, the basic components that hold interconnection specifications are called modules. Besides the declaration of provided and required resources (see also Section 5.6), the POLYLITH MIL allows attributes of the general form “SYMBOL = value” to be associated with modules. Regarding the distribution aspect, attributes of the category “LOCATION = address” allow designers to declare abstractly a desired location for the execution of modules. If the designer chooses not to supply these attributes, then the system applies default guidelines for allocation. The most important refinement of the BIG that is necessary in order to model the POLYLITH MIL is induced by the association of attributes to components. Assume that A = {a,, a2, . . . , ak}, 0 5 k < m, is the set of all attributes in a POLYLITH system. In analogy to the mapping Cr in the BIG, we define Ca to be the mapping C -+ P(A) (the powerset of A) such that each component is associated with a set of attributes that is a subset of A. The specification of interconnection relationships (Ic) in the POLYLITH MIL is further discussed in Section 5.6.
4.3.6 Features of Self-contained CILs Having presented some representative, self-contained CILs, one can observe that the latter embody features not provided by other languages. Most significantly, CILs integrate static issues of CI with evolutionary ones. In this way, they not only aid in specifying dependencies among components, but also support system configuration and version management. This support tends to be extended to cover preimplementation phases of software development and, in most CILs, is realized as an integrated set of tools operating on top of an environment database. This is in contrast to programming languages that incorporate means to express CIS,but still depend on the compilellink paradigm. Further, more recent CILs offer a formal, programming language-independent style of specifying component interfaces (Rice and Seidman, 1994; Purtilo, 1994), such that individual component versions written in different languages can be integrated without having to sacrifice consistency checking, as is the case in the compiler directives approach. Moreover, the fact that CIL descriptions of component interfaces are kept (largely) independent of some language for programming-in-the-small allows one to use the same tools to support a CIL (e.g., browsing, consistency checking, graphical display) within several programming-in-the-small environments. Of course, extra preprocessing is necessary when compared with languages incorporating their “own” CI
84
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
expressions (see Section 4.2). Furthermore, recent MILs are extended to deal with high-level specifications of the allocation of processes in heterogeneous, distributed environments. Examples of systems incorporating MILs that deal with the aspect of decentralization are Conic by Magee et al. (1989) and POLYLITH by Purtilo (1994). One disadvantage remaining in CILs, as described in this section, is their lack of extensibility. If one realizes that the CIL of one’s choice does not cover a certain aspect of interconnection (see Section 5 ) considered important in a particular application, the respective CILs do not provide any linguistic means to incorporate that additional aspect. This shortcoming does not exist in approaches described next. Although there is no strict borderline between this and the following section, the approaches discussed next carry the idea of life-cycle coverage even further, since they constitute integral parts of software environments covering a broader scope than environments supporting the CILs as described in the previous section.
4.4
Generic Features of Component Interconnection in Software Environments and Metamodeling
Software environments typically use an environment database to provide support for all of the activities that are concerned with the software process (or different software processes). One essential requirement on environment DBs is that diverse but interrelated data from different aspects of the software process be unified within a single data model. Thus, on the conceptual DB level we can view components as entities and interconnections as relationships of some data model. In the ALMA environment (Lamsweerde et af., 1988), for example, an entity such as a component, a programmer, or a deadline, may be (meta)designed to be used in connection with some specific life-cycle model. Besides holding information on module interconnection as expressed, for example, by a uses clause, an entity also contains relationships describing interconnections with external entities, such as to which programmer a module is assigned and when it was updated for the last time. Whenever it appears that relationships should be added, redefined or removed, the underlying data model allows for these changes. Using a data model to define components and interconnections in terms of entities and relationships makes it possible to produce a self-tailored CIL covering all those aspects that should be supported when following a specific life-cycle approach and employing specific languages and techniques. To mention just a few approaches to software environments centered around an environment DB and providing support for the specification of component interconnection (in the more general sense), let us consider the ALMA
INTERCONNECTION OF SOFTWARE COMPONENTS
85
(Lamsweerde et al., 1988), CACTIS (Hudson and King, 1988), and RIGI (Miiller and Klashinsky, 1988) projects. The ALMA environment has been designed with the primary goal of providing generic life-cycle support in order to remain open toward different life-cycle methodologies. In ALMA this kind of genericity is achieved by providing an (extension of the) entity relationship metamodel designed for defining particular life cycles as input to the metasystem. The output then is an instantiated project D B tailored to support the specific lifecycle model given as input. Whereas the CACTIS DB employs a data model specifically tailored to manage the complex and derived data typically appearing in software environments, the RIGI project focuses o n programming-in-the-large issues of software environments such as organization and representation of system structure, module decomposition, component dependence analysis, change and interface control, and version control. In emphasizing these aspects, RIGI stands somewhere between the approaches reported in this and in the previous section. This becomes even more apparent when we note that in addition to providing “premodeled” syntactic component interconnections (e.g., structural and compilation dependencies), the RIGI model supports semantic dependencies, intended to allow for the modeling of any relationship between two components that a designer might like to express and document. Metamodeling is yet another approach used to achieve genericity regarding CIS. It is easy to obtain within the 00 paradigm since a metalevel is inherent in most 00 models. This is because classes (also system-defined ones) can be viewed as instances of metaclasses such that their structure and behavior can be (pre)specified within a single model. In particular, interconnections can be metadefined on the metalevel and instantiated at the application level. Besides several OOPLs, O O A according to Embley el al. (1992) and Martin and Odell(l992) are two examples of 00 notations that are characterized by a metamodel employing the same set of linguistic and graphic primitives as are provided at the application level. In the field of 00 knowledge representation, Telos (Mylopoulos et al., 1990) provides an example of a fully extensible language. Extensibility in Telos is achieved by organizing (meta)classes into a stratified hierarchy and by handling attributes as first-class building blocks, analogous to classes that describe entities. In the rest of the article we do not deal with problems concerning environment DB approaches, since these stand on a higher level of genericity concerning CI. More specifically, these approaches (except to some degree RIGI) do not include predefined CI information but rather rely (among others) on the knowledge and ‘‘input’’ of a well-designed model on CI.
86
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
4.5
Discussion
Compiler directives and CI specification as part of a programming, design, or requirements specification language are each concerned with just a single phase of software development. CILs as independent languages, however, are designed to be applicable in multiple phases. Hence, the latter have the advantage of providing coherent and uniform means to model diverse aspects of CI throughout the software process. Moreover, since many Ic relations (see Section 5.6) are relevant to more than one phase, their specifications can be preserved across phases. Consequently, phase transitions become easier and developers need not learn different languages to express the same issues. It is worth noting that according to the objectoriented design philosophy, the object-oriented paradigm often is followed throughout the whole life cycle (Booch, 1991). Thus, CIS identified in early phases are preserved until the implementation. However, one has to consider that different phases are governed by different requirements. For example, whereas conceptual transparency plays a major role in early phases, late phases call for maintainability, efficiency, and a high degree of code reuse. Such conflicting requirements must be resolved, for example, by introducing new objects and by adapting or redefining the semantics of interconnection relationships, most notably generalization/specialization (discussed in Section 5.6.2).
5. Comparison of Features for Expressing Component Interconnections To describe systematically individual features for expressing CIS, each of the following subsections is devoted to one specific aspect of CI. Thereby each feature/aspect is described informally as well as in terms of the BIG, which often needs specialization and/or extension to provide expressive adequacy. Also, for each feature its instantiation in one or more languages capable of expressing CIS is discussed. Note that in this place we consider the description of a given partitioning and the linguistic means relevant for such descriptions rather than criteria o n how to produce a “good” partitioning of a system. The latter are discussed in the literature (e.g., Parnas, 1972; Myers, 1978; Yourdon and Constantine, 1979; Jackson, 1982; Balzert, 1982; Meyer, 1987, 1988; Wand and Weber, 1991).
5.1 Kinds of Components Many languages capable of expressing CIS allow for the distinction of two or more predefined kinds of components, such as packages and subpro-
INTERCONNECTION OF SOFTWARE COMPONENTS
87
grams in Ada. To express this distinction in the BIG model, the set of components, C, has to be partitioned according to the different kinds of components. In many descriptions of MILS and CILs, such as in those of DeRemer and Kron (1976), or in Wolf et al. (1985) a generic term, for example, subsystem (compilation), unit, module, component is introduced to subsume different kinds of components. This seems reasonable and can be explained by the fact that, although different kinds of components are distinguished, almost all CI features are defined in the same way for each kind of component. In particular, features concerning the specification of interconnections tend to be independent of the kind of the component involved. Nevertheless, distinguishing different kinds of components clearly increases the conceptual clarity of system models by providing linguistic means to express the architectural and/or pragmatic roles that individual building blocks play within a system model. Further, the different kinds of components provide hints on searching for components, for example, in order to reuse them. Next, we investigate some languages with respect to the way in which they allow one to distinguish different kinds of components. In some wellknown languages the distinguishing criterion is whether a component stands for a data or a procedural abstraction. For example: 0 0
In C+ +, classes are provided to model data abstractions. In Ada and PIC, the package construct is used to model data abstractions, procedural abstractions being specified as (sub)programs.
A different philosophy of distinguishing components is followed, for example, in MIL-75, NuMIL, and most OOPLs. In these languages the difference comes from whether a component itself implements resources: 0
0
In MIL-75, a component implementing resources is referred to as a subsystem with a module, whereas components not having a module attached are called abstract (virtual) subsystems. In most OOPLs and 00 design techniques abstract classes, in contrast to concrete classes, can be defined. The former are characterized by the constraint that they must not possess instances. This results from the rule that abstract classes may hold abstract specifications of resources without providing implementations for the latter. Typically, abstract classes have concrete subclasses that implement the abstract resource specifications they inherit from their superclass(es). Concrete classes, then, possess instances. Due to the abstraction from implementation and the factoring of abstract resources, the use of abstract superclasses is known to improve the reusability of classes (Johnson and Foote, 1988).
88
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
More than two kinds of components are distinguished in design languages and notations incorporating CI expressions, for example: 0
0
In TAXIS (Mylopoulos et al., 1980; Greenspan and Mylopoulos, 1983) four kinds of components are defined at the design level, namely, data, transaction, script, and exception classes. Data classes serve to specify information about (real-world) entities. Both transaction and script classes are used for modeling activities, short term and long term, respectively. Exception classes are introduced to allow for the description of prerequisites to be associated with transaction classes. Whenever a prerequisite does not apply, an appropriate exception handler is called. In Booch’s OOD (Booch, 1991) components with different grain sizes are distinguished: classes, modules, and (sub)systems. These three kinds of components induce three levels of granularity such that, at the most refined level, classes are interconnected by various organizational relationships; at the next level ICs describing compilation dependencies among modules are specified, whereas at the coarsest level, interconnections among subsystems are indicated. Note that components at successive levels are interconnected by aggregation/decomposition and that at each level a special set of interconnection relations is relevant.
So far we have dealt with kinds of components that are syntactically and semantically predefined by some language. In most object-oriented languages components are simply modeled as classes all following the same syntax. Nevertheless, different kinds of classes can be distinguished via the metaclass construct: Classes are viewed as instances of metaclasses, which are themselves classes. In this way, properties common to a set of classes can be described in their metaclass. As a consequence, languages allowing one to model metaclasses are extensible with respect to introducing new kinds of components (Mylopoulos et al., 1990; Motschnig-Pitrik and Mylopoulos, 1992). Since the association of classes to metaclasses forms a special case of an interconnection relationship (a specialization or subset of the set Ic as defined in the BIG), it is dealt with in an independent section (see Section 5.6.5).
5.2 Nesting of Components By nesting of components we refer to the capability of declaring local components as parts of some other component, in a manner similar to declaring local subprograms in block structured languages such as in Pascal or Ada. Components not nested within any other component will be referred to as global. Every language designer is confronted with the decision
INTERCONNECTION OF SOFTWARE COMPONENTS
89
of whether to support nesting of components in order to express the aggregate structure of more complex components. Before discussing the advantages and disadvantages of either solution and the refinements of the BIG necessary for modeling local components, let us demonstrate the transformation of a nested structure into a flat structure (with an equal number of components), which is possible in all cases. Figure 8a shows a component X-nest having a local component XZ-nest declared inside itself. This means that X-nest implicitly has access to the resources provided by its child Xl-nest, whereas other components, for example, Y, may acquire access to XI-nest only if X-nest provides (resources from) XI-nest. The resuit of transforming X-nest into a flat structure is depicted in Fig. 8b showing two global components X-flat (corresponding to X-nest) and Xl-flat (corresponding to XZ-nest). XZ-flat explicitly provides its resources to X-jlut and X-flat holds a uses clause requiring XZ-flat. To provide resources from XZ-jlat to other components, e.g., Y, Y has to require XI-flat, which itself has to provide its resources to Y (or to the whole environment). This example is intended to outline that, in the flat structure, component interconnection is explicitly specified for all cases, whereas in the nested structure aparent component is ascribed a special role regarding interconnection with its local child components. To further demonstrate the difference between the nested and the flat structure, let us consider the Cr and Ic relationships from the BIG. To X-nest
X-flat
XI-flat
X-nest interface
X-flat interface
Xl-flat interface
I* including *I
uses X I-flat XI-nest
X1-flat implernentatlon
XI-nest interface X I-nest implementation
X-flat implementation end XI-flat
end XI-nest X-nest implementation
end X-flat
end X-nest 8a
8b
FIG. 8. (a) Nested and (b) Hat component structure
90
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
allow for the specification of local components, at least the following partitionings have t o be provided, which are not necessary in the flat case:
0
Within the Cr relationship different kinds of associating resources to components, resources originating in a component have to be distinguished from resources provided by some child of this component. The Ic relation, used to model the interconnection between nodes, has to allow for the modeling of a parent function in order to allow for distinguishingparent-child interconnections from interconnections between global components and from child-child interconnections,
These arguments confirm that the linguistic means to support a nested component structure are more sophisticated than those for a flat structure, both providing equal expressive power. Nevertheless, nesting of components allows one to (implicitly) constrain the scope of resources. If such scope constraints are to be maintained in a flat structure, for example, as a result of a transformation, special precautions must be taken (Preschern, 1991). We conjecture that the support of a nested component structure may be the right choice in cases where the problem structure is inherently hierarchic, and/or the complexity (e.g., the number of global components and the amount of their interaction) of some very large system can be reduced significantly by allowing for local components. In all other cases, the flat structure appears to be simpler and more transparent, since all component interconnections can be defined on a single intercomponent level. This is particularly helpful if components will be considered for reuse. First, search algorithms for finding matching components are simpler and, second, the embedding of the reused components is straightforward. As a further argument for the greater simplicity of the flat approach suppose that, in a nested structure, a local component (e.g., XI-nest) shall additionally be provided access to another component that does not enclose XI-nest. In this case the interfaces of all components enclosing XZ-nest have to be extended (in addition to the extension of XZ-nest), whereas in the flat structure, only a single change (in XI-flat) is required. While languages such as MIL-75, MODULA-2, Ada, and C + + (regarding the class construct) support nesting of components, designers of objectoriented languages such as SmallTalk, KEE (Fikes and Kehler, 1985), LOOPS (Bobrow and Stefik, 1983), and Eiffel (Meyer, 1988) tend not to support the nesting of components in the sense of declaring classes within classes.
5.3
Encapsulation and Separation of Specification and Im p lementation Parts
Another capability of modular languages and CILs is concerned with the construction of a “visibility fence” around a component (module),
INTERCONNECTION OF SOFTWARE COMPONENTS
91
usually referred to as encapsulation. This effect can best be described by the mapping Cr (from the BIG model) associating each component with a set of resources. Since, in general, a component needs to communicate with other components of the system via some-but not all-of its resources, a common partitioning of Cr allows for distinguishing Crprlv(private resources) and Crpubl(public resources). As the names indicate, private resources of some component (c E C) are known (i.e., visible) only within c, whereas public resources are also (potentially) visible to the environment of c, that is, to components at the same or a higher level of nesting. While the distinction between private and public resources helps considerably to limit the name space in a system, a further partitioning of public resources is desirable, primarily in order to allow for information hiding (Parnas, 1972) and modeling of abstract data types (Liskov, 1977). It should be possible to distinguish between two degrees of public: public name of a resource (possibly with an associated parameter list) only and public resource (i.e., name plus implementation).The two mappings resulting from this distinction will be denoted by Crpubl,namr and Crpuhl.impl, respectively. If, for example, some module provides only the name of an abstract data type “stack” and the headers of the procedures “push” and “pop,” the users of “stack” may access variables of type “stack” only by “push” and “pop.” The actual implementation of “stack,” “push,” and “pop” remains hidden to the users and thus may be changed (as long as the semantics remain identical) without affecting the users of the abstract data type. So far we have motivated the distinction of Crprlv,Crpubl,namc, and Crpubl,lmpl by providing means for limiting the name space, for information hiding, and the modeling of abstract data types. In many programming languages and the OODB Vbase, a more profound separation of the declaration of private and public resources is considered important (Andrews, 1991; Damon and Landis, 1991). This is achieved by allowing for the division of a component into a speciJication part, often referred to as interface, and an implementation part, also called body. The slightly higher effort in constructing a component out of two parts is highly justified for the following reasons: 0 0 0
0
Locality OC specification. More distinct information hiding due to textual separation. Possibility of having multiple implementations fulfilling one specification part. Separate compilation of both parts (with consistency checking) supporting an incremental life cycle. Specification parts may be provided and compiled already at a point of time when the implementations are still unfinished and implementations may be changed without necessitating the recompilation of a component’s clients.
92
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
Representation abstraction; since the specification part does not have to embody implementation details, it can be kept on a higher level of abstraction concerning its representation (notation). In this way also programming language independence (compare also Section 4.3) can be achieved. To be able to express the separation of specification and implementation parts in the BIG model, it has to be extended such that, for each member c, of the set of components C, a specification part c , , , ~and ~ ~a (set of) corresponding implementation part(s) c,l.impl, c ~ ~. . ,. ,~can~be~distin~ , guished. To demonstrate the ideas mentioned earlier, let us consider some examples concerning declarations of private and public resources and their arrangement within (interfacedbodies of) components resulting in specific intracomponent structures. Languages intended for programming-in-thelarge such as MIL-75, PIC, NuMIL, and design languages such as SD (Yourdon and Constantine, 1979) or Plasma/D (Balzert, 1982) typically provide means for the specification of interfaces only, leaving the rest to the realm of languages for programming-in-the-small. Only some languages designed for programming-in-the-large as well as for programming-in-the-small (i.e., languages incorporating their own CI expressions) allow for the splitting of a component into an interface and a body subcomponent. Well-known programming languages that provide splitting facilities are MODULA-2 and Ada, whereas in the field of OODBs, Vbase exemplifies the separation of the interface and implementation of type components. Languages typically not supporting the separation of interface and body parts are, for example, SmallTalk, Eiffel, C++, and knowledge representation languages (e.g., KEE, LOOPS, ART). Nevertheless, these languages syntactically enforce a disciplined arrangement of all declarations expressing CI by placing them at the beginning of a component in a defined order. As indicated previously, Ada and MODULA-2 provide means for splitting components into specification and implementation parts and for separate compilation of these parts. Perhaps the most significant difference between the two languages with respect to separation is the following. In MODULA-2 only the so-called module may be partitioned into a spec8cation module (the interface) and an implementation module. Each can be compiled separately. In Ada procedural abstractions may also be split. This is done by specifying just the header of a subprogram and declaring the body as separate, in which case it can be supplied at some later point in time and compiled separately. Ada’s construct corresponding to MODULA-2’s module is the package. Since MODULA-2 and A D A differ only in minor (and mainly syntactic) aspects concerning the philosophy of partitioning, we only discuss an example in Ada.
INTERCONNECTION OF SOFTWARE COMPONENTS
93
Figures 9a and b give examples of a stack that imports (requires) resources (in particular, the typename GRAPH) from the package GRAPHS specified in Ada. We use these two figures to demonstrate the following points: 1. The optional with clauses at the beginning of a package and its body are used to indicate those components (i.e., packages or subprograms), in the example GRAPHS, from which resources are required. The semantics are such that (resources of) components mentioned in the with clause of a package are also automatically accessible in the corresponding body. The body, however, can require additional resources by naming the corresponding components in its own with clause (compare the comment in Fig. 9). 2. Having two with clauses means that there are two places in which to specify the Ic relationship denoting a component’s resource requirements. This has the advantage that different bodies of one package are free to require different resources without any change to the package interface. This argument applies in spite of the fact that A D A dictates a one-to-one relationship between an interface and its body: One can conceive a body to be replaced by a different one during evolution or maintenance. But the splitting of information on required resources also has a severe disadvantage. To determine the interconnections of a component with other components, it does not suffice to consider the (package) specification, one has to investigate the body as well. This means that the specification part gives an incomplete component interface. In this case, new resource requirements in the body do not affect the interface. 3. In addition to the optional with clause, and an optional use clause (stating that resources from listed components may be accessed without putting the component’s name as a prefix to an accessed resource), the interface holds the specification of public resources provided to the package itself and to its environment, that is, the components at the same or a higher level of nesting. The corresponding body contains the implementation of the resources specified in the interface as well as additional private resources accessible only within the package. An exception to this rule is discussed later. 4. Ada packages are designed to have aprivatepart. From the conceptual point of view, this seems to be a contradiction, since, in the first place, an interface of some component c should provide a visibility fence between c and its environment. This is achieved by indicating the components from which c requires resources (via the with and, possibly, the use clause) and by revealing just the necessary information on resources provided by c-public resources-such that they can properly be used by the environment. T o allow for information hiding, an interface should neither reveal information about resources restricted to private use nor about internal
94
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR with GRAPHS package GRAPH-STACK is type BUFFER is private; procedure PUSH (ELEMENT: in GRAPHS.GRAPH; O N in out BUFFER); procedure POP(ELEMENT: out GRAPHS.GRAPH; FROM in out BUFFER); pnvale MAXIMUM-ELEMENTS: constant INTEGER:= 100; type LIST is array(1NTEGER range l..MAXIMUM-ELEMENTS)of GRAPHS.GRAPH; type BUFFER is record STRUCTURE: LIST; TOP
: INTEGER range
I..MAXIMUM-ELEMENTS;
end record; end GRAPH-STACK;
-- a with clause in this place could list the names of packages and/or subprograms -- the resourcesof which are required by the body part only package body GRAPH-STACK is procedure PUSH (ELEMENT: in GRAPHS.GRAPH; ON: in out BUFFER) is begin
-- statements end PUSH; procedure POP (ELEMENT: out GRAPHS.GRAPH; FROM. in out BUFFER) is begin
-- statements end POP;
begin
-- statements for initialization
end GRAPH-STACK; (b)
FIG.9. Example of a stack holding graphs in Ada. (a) Specification of the stack package, (b) body of the stack package.
INTERCONNECTION OF SOFTWARE COMPONENTS
95
details, such as the representations of data types or the implementations of operations of public resources. Nevertheless, an exception is necessary in the case of declarations of private, static data types. These have to be specified in the private part of the interface for purely technical reasons, namely, to supply the compiler with information needed for the reservation of storage space. If, for example, we chose to declare the buffer from Fig. 9 as a dynamic data structure, its type declaration could, and should, be given in the body of GRAPH-STACK, where it remains hidden from the environment. PIC and NuMIL differ slightly with respect to the partitioning of interface and implementation when compared with Ada (and MODULA-2). In PIC the interface is complete in that all resources provided and required by a package (this means, interface and body) must be explicitly indicated in the interface. In NuMIL, on the other hand, the interface of a component (called specification template) only specifies the (minimal set of) provided resources (any version of) the component is obliged to provide. Specifically, the interface does not contain any information o n requested resources at all, but leaves this to the implementation part so that different implementations are free to request the resources they need without any effect on the interface. Besides PLs and CILs, the discussion on data abstraction and encapsulation has spread to the field of OODBs. In the following, the O O D B Vbase (Andrews, 1991) is used to illustrate how a fully abstract specification of types can be achieved by separating interfaces from implementation descriptions. Unlike most OODBs, which use an OOPL as data definition and data manipulation language, Vbase provides distinct linguistic means for the abstract specification of a type’s interface and for its implementation. This is achieved by providing two different languages: TDL (Type Definition Language) for the abstract specification of a type’s interface and COP, an 00 extension of C, for the implementation of resources. Interface specification amounts to providing information about operation invocation, property accesses, and about all (other) types involved. In analogy to NuMil, an interface in Vbase specifies the resources which are provided to the whole environment. Since no implementation is ever written in TDL, the interface does not contain any information on required resources. The preceding discussion demonstrates that it is by no means evident which kind of separation between interface and body is best. The benefits of having complete interfaces must be weighed against the flexibility in implementations as well as increased effort in recompilation whenever changes concerning the requisition of access to resources occur.
96
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
5.4 Granularity and Precision of Interconnection Relationships In the next three sections we investigate interconnection relationships (Ic relationships). Two components are interconnected, ( c ~c,) , E Ic or (c,, c,) E Ic, whenever there exists at least one resource “belonging to” one component that is accessible in, or derived by, another component. Thus, besides establishing the system structure and the dependencies between components, an important task fulfilled by Ic relationships is the explicit control of the name space of components. To characterize an Ic relationship adequately, three dimensions are required: 0 0
The syntactic structure of the Ic relationship Its semantics The degree of precision with which the interconnection is expressed
In this section we focus on the degree ofprecision for defining interconnections, whereas the next two sections deal with the structure and with different semantic categories of Ic relationships, respectively. Referring to the BIG, in Section 5.6 different categories of interconnection relationships (modeled as the set Ic in theBIG; c.f. Section 3) are introduced as a partitioning of the set Ic such that each category groups individual Ic relationships having similar semantics. For example, Icprovstands for the category of provision relationships that share the following semantics: If the pair (c,, c,) is a member of the set Icprov.then the component c, provides resources to c,. Note that the distinction between categories and instances of Ic relationships is unavoidable if the (often minimal) semantic differences individual languages associate with Ic relationships are respected. In the sequel, the term Ic relationship is used in a generic sense, denoting some arbitrary instance of an interconnection relationship. The next three sections are closely related insofar as they constitute orthogonal discussions on interconnections among components: Each instance of an Ic relationship (see Section 5.6) has to be associated with some structure (see Section 5.5) and with a particular degree of precision (see later). To explain the notion of precision and to adapt the BIG to express this notion, we first introduce the termgranufarity to allow one to distinguish three different grain sizes of entities. According to an increasing level of granularity we have: 0
Resources, being associated to Components, being units for building a whole System (or different systems)
INTERCONNECTION OF SOFTWARE COMPONENTS
97
These three levels will be referred to as the resource, component, and system level, respectively. To arrive at the notion of precision of an Ic relationship, note that the three levels of granularity are also suitable for defining the granularity of the source and target entities of arcs denoting some Ic relationship. In this way, different degrees of precision result from allowing for different grain sizes of source and target entities. So far we are able to think about arbitrary interconnection relationships as specific kinds of channels transmitting information on three levels of granularity and being directed either to the whole environment (i.e., all components of the system) or, with increasing precision, to specific components or even resources. This, in fact, already means both a generalization and a refinement to the definition of the Ic relationship within the BIG as defined in Section 3. Recall that interconnection relationships in the BIG, that is, the set Ic, have been defined as directed arcs at the component level only. But note that, as discussed earlier, different grain sizes of source and target entities are conceivable in order to specify some interconnection relationship. More specifically, Ic has been defined as a set of ordered pairs (c,, c,), whereby c,, c, are two components from C, the system’s set of components. As a generalization, an interconnection relationship between some component c, and its environment could be denoted by the pair (c!,c) subsuming all the pairs (cj,c,), such that c , c, E C , i f j. To refine the set Ic to allow for the specification of interconnections among resources, we adopt the following notation: The pair (c,.rl, c,.r2) will be used to define an interconnection between the resource rl of the component c, and the resource rz of c,; the short form (c,.rl, c,) will subsume the interconnection between the resource rl from c, with (potentially all resources from) c,. In any case, the particular category of Ic relationship expressed depends solely on the specific set I c ~ ~for, example, ~ ~ ~ ~ ~ ~ , I c ~ ~ ~ ~which , \ , ~holds , ~ , the pair (c,.rl, c,.r2) as a member.
Figures 10a to e depicts the five levels ofprecision used with interconnection relationships. In the figure, S stands for source component, shown as a circle, while the circles surrounding T1 and T2 denote different (target) components from the environment of S. The small rectangles within the components named x,y, z, a, b, c stand for resources such that the resources implemented by a component are delimited by double lines (such as x in S), and resources derived from some other component (by some interconnection relationship) are in single lines (as for example x in T1 of Fig. 1Oc). On the least precise level (Fig. 10a) a whole component is interconnected with its environment. In the figure, the resources of S are made available to arbitrary components of the system. In practice, this corresponds, for
98
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
b
d
e
FIG. 10. (a-e) Levels of precision of interconnection relationships.
example, to the use of include files that may be included by any other file. This level is also realized in library modules that are available for import by any other component. On a more detailed level, specific kinds of resources or even single resources (e.g., x and z from Fig. lob), can be interconnected with the environment. A specific realization of level b is for example the export
INTERCONNECTION OF SOFTWARE COMPONENTS
99
clause in MODULA-2, the public part of an Ada package or C + + class, or the define interface name clause in the POLYLITH MIL. A third level of detail (Fig. 1Oc) defines interconnections between components as originally defined in the BIG: All resources provided by S are available to the component(s) with which S is connected. This intermediate level may be considered most important from the point of view of defining the structure of a system. In practice, it is realized in various categories of Ic relationships such as the subclassisuperclass relationship, Ada's with clause, MODULA-2's import clause naming components (e.g., import S appearing in T l ) , etc. A yet more detailed level (Fig. 10d) interconnects single resources with single components (e.g., x with T1 and y and z with T2). An example for level d can be found in PIC, where each resource may have a provide t o clause naming those components, to which the resource shall be provided. As another example, consider the following variant of MODULA-2's import clause: To specify the contents of the example in Fig. lOd, FROM S IMPORT x would appear in T1 and FROM S IMPORT y, z would appear in T2. The highest precision is reached by establishing interconnections between single resources (Fig. 1Oe). A realization of that level can be found in PIC, where a resource (e.g., a) may require access to only a specific resource (e.g., x) from some component (e.g., S) that has to provide x. An even higher degree of precision is possible with types in PIC: A structured data type may be provided by its name only, or by name and implementation. For both cases the target may be the environment or a single component that, in turn, may have a resource that holds a require clause naming that data type. Languages allowing one to express CISusually model individual interconnection relationships at different levels of precision. Nevertheless, some languages allow one particular category of interconnection relationship to be expressed at different levels of precision. As an example (already mentioned earlier), consider the import clause of MODULA-2: it may be used to import whole components (e.g., IMPORT S), in which case it resides on level three, or it can be employed to import individual resources from some component (e.g., FROM S IMPORT x), thus occupying the fourth level. A similar situation applies tofriends in C + + , where either individual functions or a whole class may be declared as friends of some class c. A friend, by definition, is provided access to all resources of c. Consequently, friend classes reside on the third level of precision whereas friend functions operate on level four. An excellent treatment of precision with respect to the provision and requisition of access is given by Wolf et al., (1988) and focuses on visibility
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
100
(and hence access) control in general, such that other possibilities (e.g., nesting) of controlling the name spaces of program parts are discussed and evaluated in terms of their precision.
5.5
Structure of Interconnection Relationships
This section discusses the notion of the syntactic structure of interconnection relationships. In graph theory it is common to classify graphs with respect to structure as:
0 0
General graphs or nets (arbitrary interconnections among nodes allowed) Directed acyclic graphs modeling partial orderings (no cycles allowed) Trees (each node has a unique path to the root)
We adapt this terminology in considering components as nodes and interconnection relationships as arcs. In general, trees, being most constrained with respect to the interconnections allowed, exhibit the most simple and transparent structure. As a result, algorithms operating on trees can exploit the constraints imposed by the structure and hence tend to be simpler and more efficient than algorithms processing general graphs. However, many real-world situations exemplify a general (or partially ordered) structure so that a more constrained structure would not allow for building a “natural” model having the problem structure isomorphic to the “program” structure. Because of this trade-off between simplicity and generality, in practice, different structures are provided for different categories of interconnections in order to satisfy user needs.
5.6
Categories of Interconnection Relationships
Besides the purely syntactical notion of structure of interconnection relationships, different categories of the latter can be distinguished, each carrying specific semantics. With regard to the catalog of structuring concepts used in software development as discussed by Pitrik (1988) and Motschnig-Pitrik (199O), the following categories of relationships appear worth considering:
0 0 0
Provisionirequisition of access (compare exporthmport) Generalizationispecialization Aggregationidecomposition and part-of relationships The member-of relationship Metaknowledge
INTERCONNECTION OF SOFTWARE COMPONENTS
0
0
101
Representation abstraction (levels of specification) Versions of components Perspectives (views) on components
The BIG model can be refined for modeling these different categories of Ic relationships simply by a partitioning of Ic into Icagg,Icdrc,Icprov,IcrCqu, Icgcn,. . . , using subindices to denote the various categories of relationships that can be expressed. Typically, every language capable of expressing CI provides means to specify instances of some of the interconnection relationship categories listed. Note that the discussion of (language-specific) instances of Ic relationships amounts to giving language-specific interpretations (c.f. Section 3 ) of the set Ic of the BIG. The different categories as well as language-specific instances of Ic relationships, their syntactic structure, and the degree of precision are discussed with the goal of providing both practical and theoretical insight into component interconnection.
5.6.1 Provision/Requisition of Access By access to a resource we mean the right to reference or use that resource in declarations or statements. Access to a resource r is possible only within the scope of r, whereby scope refers to the region of “code” over which the declaration of r is potentially visible. Thus visibility is a sufficient precondition to (potential) accessibility so that the terms visibility and (potential) accessibility may be used interchangeably [see also Wolf et al. (198S)l. Nesting of subprograms forms a “traditional” implicit mechanism of controlling visibility. For example, variables of some programs are visible (accessible) to nested subprograms. However, in this article we restrict our attention to explicit mechanisms designed to control accessibility across component boundaries. Note that in the case of a one-to-one correspondence between the interface and the implementation part of a component, these two parts will be considered integral partitions of a single component. Given such a partitioning into the two subparts it is understood that all resources declared in the interface part are also accessible in the implementation part. Provision and requisition of access are two complementary interconnection relationships employed for controlling accessibility (Wolf et al., 1988). The provision relationship, Icprov,often also called “export,” is used to offer the rights necessary (for another component) to potentially refer to (resources specified in) some component. Accordingly, the requisition relationship, Icrequ,also called “import,” is used to enable a component to acquire the rights to potentially refer to (use) some set of resources. Using
102
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
the notions of provision and requisition, resources declared in a component c, are actually accessible in a component c, if and only if c, provides access to c, and c, requires access to c,, or formally,
and (cpci) E Icrequ. Adopting the notation from Section 5.4 a specific resource r from c, is actually accessible in c, if and only if (ci,cj)
E ICprov
and (c,,cP) E Icrequ* So far we have established the role of 1cpmvand Icrequas explicit mechanisms to control accessibility across component boundaries. Closely connected with that capability are further features derivable from the specification of provision/requisition: (c,.y,cI)E ICprov
0
Side effects are explicitly made visible, facilitating debugging. Name clashes can be detected by the compiler. Components can be compiled separately ensuring the proper (compatible) use of imported resources. Smart (Tichy, 1986) and efficient (Hood et af., 1986) recompilation is facilitated so that after a change only those components that actually refer to a changed resource have to be recompiled. (A more detailed treatment of recompilation can be found in the literature mentioned.) Alternative system designs can be evaluated based on the criterion of (static) communication among components.
Various CILs employ quite different approaches and degrees of precision in specifying provision/requisition of access. We discuss specific realization of these relationships in Ada, MODULA-2, Smalltalk, C+ +, the knowledge representation language LOOPS, and O O D according to Booch (1991). Note, that the degree of precision plays an essential role when considering reuse and maintenance. This is because high precision allows one to constrain the actual effects of changes much stronger than just low precision (Wolf et af., 1989).
Ada. In considering Ada, we restrict our discussion on access control to library units, that is, components (compilation units) at the outermost level of nesting. This choice was made because very similar mechanisms are used with nested units, supplying no additional insights for this article. Ada only allows access to the resources of some unit cI (i.e., subprogram or package) if c, declares those resources to be visible (by specifying them in the visible part of its interface), and, other units, for example, c,, request access t o c, (via a with clause in c,). So both provision and requisition must coincide to enable actual usage.
INTERCONNECTION OF SOFTWARE COMPONENTS
103
More precisely, Ada’s provision mechanism is inherent in its encapsulation mechanism: 0
A subprogram unit, by default, provides its name to its whole environment. A package consists of a visible and a private part. All resources from the visible part (none of the private part) are provided to the environment.
Requisition in Ada is controlled by the with clause (or the use clause, relieving the user of employing the dot notation to indicate the source unit when referencing foreign resources). Each unit c,, requiring access to a unit c,, (i.e., to its visible resources) has to mention c, in its with clause. Regarding the structure of the requisition relationship, an arbitrary set of units may be specified so that the resulting graph has a general structure. As to precision, a more detailed level, namely, component to component, can be expressed for requisition rather than for provision, the latter working at the (component to) environment level. As an example, consider the GRAPH-STACK package from Fig. 9 and the subprogram “stackuser” sketched in Fig. 11.
MODULA-2. The provisionhequisition mechanisms of MODULA-2 are quite similar to those of Ada with only one major difference. The requisition relationship has a more detailed level of granularity in MODULA-2, since it can be specified to work at the resource level. In MODULA-2 either all of the resources provided by a component (module) may be required in an IMPORT clause stating, for example: IMPORT g r a p h s t a c k ;
or only a subset of the resources provided by a component may be imported via the FROM clause, for example: F R O M g r a p h s t a c k IMPORT push,
pop;
with GRAPH-STACK
STACKUSER i s
-- declarations and statements of STACKUSER -- including accesses to GRAPH-STACK via ‘buffer’,‘push’, ‘pop’
end STACKUSER FIG. 11. Example of an Ada unit requiring access to GRAPKSTACK from Fig. 9.
104
R. MOTSCHNIG-PITRIK AND R. T. MlUERMElR
Sma//ta/k. One characteristic feature of object-oriented languages in general, and Smalltalk in particular, is the organization of components, more specifically classes, along subclass hierarchies, mostly modeling generalization/specialization relationships between classes [for subtle differences between subclass and generalization/specialization relationships in Smalltalk see, for example, LaLonde and Pugh’s study (1991)l. This organizational structure allows for the realization of inheritance in the sense that, informally speaking, more specific classes (or subclasses) inherit resources from more general ones. Although inheritance is a mechanism used to deal with accessibility, its nature and semantics are quite different from that of provision/requisition relationships. Therefore, discussion of inheritance will be deferred until Section 5.6.2. In Smalltalk there is no visibility control on methods (resources comparable to subprograms), except for excluding private methods from a class instance and class protocol (see Fig. 12). Each object from a system may send a message to (i.e., invoke a method within) any arbitrary object, including itself. An object can respond to all messages that activate methods defined in “its” class or those that are inherited from a chain of superclasses. In contrast to the unrestricted access to (nonprivate) methods, there exist more subtle access control mechanisms for variables. Whereas instance variables, which describe the state of an object, are accessible only in response to messages sent to that object, class variables are shared by all instances of a class and can be accessed in response to messages sent to the corresponding containing class. Furthermore, pools of shared variables can be defined such that a class can require access to the variables of a class name superclass name class vanable names instance vanable names indexed instance variables shared pools
class methods instance methods ”class-name” class protocol I* names and parameters of class methods of the class ”class-name” * I
”class-name” instance protocol /* names and parameten of non-private instance methods * I
FIG.12. Skeleton of a Smalltalk class.
INTERCONNECTION OF SOFTWARE COMPONENTS
105
pool by specifying the name of that pool in its class description (see Fig. 12). Also, variables can be declared to be global in which case they are shared by all instances of all classes. In short, in Smalltalk all resources being methods are, by default, provided to the whole system. Requisition is specified only in the case of names of pools of shared variables and provision of variables is expressed only at a very coarse-grained level, namely, by providing variables to the whole system. Accessibility along the subclass hierarchy is controlled via inheritance mechanisms discussed in Section 5.6.2. A thorough discussion of accessibility in the context of inheritance in object-oriented languages is given by Snyder (1986b) and Wegner (1990).
c++, Among OOPLs, C + + is equipped with the most refined mechanisms for specifying the provision of access to the resources of a class. First, C + + allows for a partitioning of R, the set of resources of some class, into public, protected, and private ones. Essentially, the courier resources (both variables and methods) of some class C are provided to the whole environment, whereas courier resources of C are provided to all subclasses of C. Courier resources are not provided at all, being accessible within the class C only. Note, that the mechanism of distinguishing protected resources of some class C is situated at a level of precision lying between levels two and three (see Section 5.4). This is because the target of the arc denoting the provision relationship is a specific set of classes (all successors of c with respect to the subclass relationship) rather than the environment (which would mean level two precision) or one specific component (indicating level three precision). Second, friend functions and friend classes in C + + provide additional means to control explicitly the provision of access to the resources of a class. Any class may specify other classes or functions to be friends, thereby providing these friends with the right to access a class’s private and protected resources. The POL YLlTH System. POLYLITH MIL provides two clauses that allow one to declare interfaces between modules. The provision of a resource “name” to the environment is declared by: d e f i n e i n t e r f a c e name,
whereas a module interface that requires access to a nonlocal resource “name” contains the specification: use i n t e r f a c e name.
Note that, unlike in most other languages, it suffices to name the required resource without indicating its encompassing module.
106
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
LOOPS. While following an even less restrictive philosophy regarding provisionhequisition than Smalltalk-also variables may be accessed from any object-the KR language LOOPS (Bobrow and Stefik, 1983) allows for the specification of requisition at the component-to-component level in one specific case: So-called “rulesets,” classes holding sets of production rules, contain a “workSpace” clause naming all those objects that are referenced by the rules. Booch’s OOD. In the realm of 00 modeling, Booch’s OOD (Booch, 1991) provides perhaps the most versatile mechanism for the explicit specification of the provisionhequisition of access. In OOD this specification is expressed at two levels of components: the using relationships among classes specified in class diagrams and class templates on the one hand and the compilation dependencies among modules described in module diagrams and module templates on the other hand. There are two flavors of using relationships: a class’s interface can use another class, or a class’s implementation can use another class. In the first case, access to the used class must also be provided to any clients. In the second case, the used class is hidden as part of the private portion of the using class. As an example consider a class Library that uses two other classes, namely Book and List (see Fig. 13). Whereas the class Book is used in the interface, for example, in order to specify a signature of a checkout method for books, the List class is used in the implementation part only, for instance, to implement collections of books. Note that Booch’s use of relationships strongly resembles Ada’s with clauses. Both mechanisms specify requisition on a component-to-component level. In Ada additional precision is gained by attaching with clauses to either package interfaces or bodies. The analogous concept in Booch’s OOD is the distinction of the two kinds of using relationships as discussed earlier and illustrated in Fig. 13.
FIG. 13. Using relationships i n Booch’s OOD.
INTERCONNECTION OF SOFTWARE COMPONENTS
107
As previously indicated, OOD provides yet further means to specify provision/requisition. This is due to the fact that besides classes, components at higher levels of magnitude, such as modules and (sub)systems, can be distinguished. While subsystems are mainly defined by their composition of modules, the latter are the units of physical design. It is the module level where compilation dependencies among modules (files) resulting from the usage of classes play a dominant role. OOD addresses the task of specifying compilation dependencies among modules by introducing module diagrams, which reflect the physical design of a system: A link from module A to module B indicates that A requires access to B. the syntactic structure of a module diagram is a partial order. A further notational element for specifying CIS in module diagrams is adornments on module names. An unadorned name represents a module that is private to its enclosing subsystem. A name framed by a rectangle reflects a module that is exported from a subsystem-indicating provision-whereas an underlined name represents a module that is imported from another subsystem, denoting requisition. In this way a coarse, physical structure of a system is represented whereby provision is specified at the module-to-environment level of precision and requisition is described at the module-to-subsystem level.
Discussion. Several advantages resulting from the increased effort of explicitly specifying provision/requisition with an adequate degree of precision are well known and have been listed previously. Here, we mention some aspects demanding special consideration. The specification of provision with a target location other than the environment level is problematic with reusable library components. This is because higher precision with respect to the target would require one to know the names of the addressees, which typically are not known in advance. The situation is somewhat different in object-oriented languages, which organize classes along a subclass hierarchy or lattice. This organizational mechanism makes it meaningful to distinguish-for each class c-a subset of all the classes of a system that are reachable from c by traversing subclass links. As exemplified by C + + (via the protected category), provision then may be restricted to this specific subset without having to name its members explicitly. Since the requisition needs of a component may vary from implementation to implementation, the specification of requisition in an interface part is subject to the problem of 0
Either leaving the interface incomplete-in the case of providing a requisition clause in the implementation part-or Having to update the interface holding the requisition clause also in cases where different resources are requested in the implementation part only.
108
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
The second choice, providing a complete interface, calls for smart recompilation mechanisms in order to keep the number of components to be recompiled as small as possible (Tichy, 1986).
5.6.2 Generalization/Specialization Generalization and its inverse relationship specialization (in brief G/S) have their roots in semantic data modeling (Smith and Smith, 1977) and semantic network formalisms in KR (Findler, 1979). They form an important structuring concept allowing for the organization of components, in this context mostly referred to as classes, into levels of genericity. The resulting hierarchy is called G/S hierarchy, taxonomy, subclass hierarchy, inheritance hierarchy, or IS-A hierarchy (Brachman, 1983; Borgida et al., 1984; Goldberg and Robson, 1983; Lenzerini et al., 1991). The multitude of terms already indicates that G/S has been adopted in various fields and contexts. This widespread use of G/S, unfortunately, let the concept of G/S acquire several more or less different semantics. Consequently, G/S as well as the related concepts, most outstandingly inheritance, are heavily overloaded with closely related, but nevertheless distinct meanings. Since a precise definition of all the relationships based on the various semantics of G/S-like relationships is outside the scope of this article, we provide only references containing attempts to resolve ambiguities in the context of G/S. Further, we take the freedom to use the terms CIS, subclass, and inheritance in an informal, generic sense in the introduction to this section. Later, some specific instantiations of G/S-like relationships are discussed. As to the references, a juxtaposition of G/S, subclasses, and subtypes in the context of Smalltalk is given by LaLonde and Pugh (1991). In the area of KR, Brachman (1983) discusses the various semantics associated with “is-a” links and relates them to inheritance. Goldstein and Storey (1992) aim at unraveling the various semantics of “is-a” relationships taking a database design perspective. They distinguish four different kinds of “isa” relationships according to the semantic constraints associated with each kind. Finally, Lenzerini et af. (1991) give a comprehensive and detailed account on numerous aspects related to inheritance. To introduce the basic terminology, consider a class (component) c,. The classes being more general than ciand residing on the generalization level immediately above c, are called superclasses of c,. Similarly, classes being specializations of c, are referred to as its subclasses. If a class is allowed to have a single superclass only, the G/S relationship forms a tree, the classical structure associated with the term hierarchy. The permission of multiple superclasses results in a syntactic structure being a lattice reflecting the corresponding partially ordered graph. Referring to our BIG model, the
INTERCONNECTION OF SOFTWARE COMPONENTS
109
interconnection relationship of generalization, oriented from a class c, to its superclass c,, will be denoted by Icgen(c,,c,,)and is well known as c, isa c, [more precisely, one interpretation of “is-a” (Brachman, 1983)l. Note, however, that these explanations are strongly simplified insofar as they reflect just one among several interpretations. Specifically, the generalization and superclass relationships need not always match. One important aspect closely related to G/S is inheritance: Informally, more specific classes can be characterized by (and hence are said to inherit) resources from their superclasses. As a consequence, the inherited resources (data and operations) need not be specified again in the subclass so that the designer of a subclass can concentrate on those features that are specific to the subclass. In this way, high notational efficacy is achieved. We refer to the above-mentioned interpretation of inheritance that follows G/S or subclass relationships as classical, static inheritance. Because various languages differ in their realization of interconnections among classes based on G/S, subclasses, and inheritance, we chose SmallTalk as a reference to demonstrate the basic classical inheritance mechanisms, leaving alternative solutions for subsequent discussion. Later, the importance of G/S for the increased reuse of components is discussed.
Smalltalk. A Smalltalk class description consists of a class name, a superclass clause, six sections for the declaration of six kinds of resources, namely, named and indexed instance variables, shared pools, class variables, instance methods, class methods, and, respectively, a section on the class and the instance protocol. In addition, each class is associated with a metaclass, which may hold a specification of its instance variables. A skeleton of a class description is depicted in Fig. 12. Since each class may be associated with one superclass only, the syntactic structure of the subclass relationship forms a tree. Smalltalk’s inheritance mechanism extends the scope of the resources of a class c, to all of its direct and indirect subclasses c, ( j = 1, . . . , n). However, an inherited method m can be redefined, that is, given a new definition in a subclass; c k ( k = 1, . . . , m). This redefinition is called overriding and has the effect that in the subclass ck the new, in most cases specialized, declaration of m is introduced and inherited to the subclasses of Ck, their subclasses, and so on until m is overridden again or the leaves of the subclass hierarchy are reached. From this example we can see that inheritance works: 0
Only along the links established by the subclass relationship IC,,,,~ At a level of precision best described as component to (whole subtree of) subcomponents, with the option of overriding methods at the “target” subcomponent
110
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
Note that, although rules of good style (Johnson and Foote, 1988) suggest that subclasses be specializations and superclasses be generalizations, this is not enforced in Smalltalk. Moreover, inheritance is tied to the subclass relationship rather than to specialization. As a consequence, in cases where subclasses are not specializations, conceptual transparency is traded for an increase in the reuse of code via inheritance. Inheritance and requisition/provision have in common their ability to control the scope of resources across component boundaries. Important differences between the two mechanisms are the following:
0
Resources may only be inherited to those classes that are reachable from a class by traversing the links established by Ic,,~. k s , b is transitive, i.e.: (cl k s u b c2) and (c2 IcSubcn) 3 (c1 kSub c3) but Icrequand Icprovare not. Consequently, using inheritance, resources may be propagated to several lower levels (as long as they are not redefined). Conversely, every component requiring resources from another one must state this explicitly.
Multiple Inheritance. In many KR and object-oriented languages, such as LOOPS, KEE, ART, TAXIS, C++, and Eiffel, a component ci may have multiple supercomponents (e.g., cj, c k ) such that the superclass relationship IcsUpis the set {(cj,ci),(ck,ci). . .}. In this case, ciinherits resources from all of its superclasses, the mechanism involved being referred to as multiple inheritance. Multiple inheritance being permitted, the graph spanned by IcsUp(or its inverse relationship IcSub)forms a lattice. In cases where there exist instance resources having equal names in cj and ck, some conflict resolution strategy must be specified, for example, precedence lists (Stefik and Bobrow, 1986; Snyder, 1986a). Unfortunately, such resolution strategies are language or even implementation dependent, resulting in the loss of conceptual clarity. This problem can be illustrated by considering the levels of precision of interconnection relationships as shown in Fig. 10. Hierarchic inheritance basically works at the component-to-component level' of precision: It uniquely indicates the superclass (chain) from which a component inherits resources. Considering multiple inheritance, however, name clashes in the superclasses of some component enforce a resource to the component level of precision, since it has to be stated which resources shall be inherited from which component. lnheritance Roles. Some KR and object-oriented languages, such as KEE, allow for the specification of a higher degree of control over the
'
More exactly, all instance resources of a class c are inherited to the hierarchy of subclasses originating in c, unless a subclass chooses to redefine a resource.
INTERCONNECTION OF SOFTWARE COMPONENTS
111
value-content of inherited slots. This is achieved by associating with each slot an inheritance role that controls the way in which the contents-as opposed to the name-of an inherited slot may or may not be modified in the inheriting class. In KEE, slots are attached predefined annotations, one of which is foreseen to indicate an inheritance role. For example, the annotation “Inheritance: OVERRIDE-VALUES” indicates that values of a slot may be overridden (modified) in subunits.
Alternative Approaches to ”’Inheritance.” While classical inheritance strictly depends on the organizational structure among classes, as reflected in a G/S or subclass hierarchy or lattice, several alternative approaches to “inheritance” have been suggested, which depart from G/S or subclassing as the underlying structure. Languages such as Common Objects (Snyder, 1986a) allow for partial inheritance. With the help of this mechanism, it is possible for a component to inherit just some resources from its superclass(es). In Common Objects a class can explicitly exclude individual operations provided by its parent(s). The increase in granularity (from the component to the resource level) results in a higher degree of flexibility with respect to code sharing. With partial inheritance one could, for example, define a Queue to inherit from a List a length and a display operation but not the insert operation and to inherit only the print operation from OpenArray. In general, partial inheritance combined with multiple inheritance and overriding make it possible for any class to inherit any combination of resources considered useful. Although flexibility is extremely useful for code sharing, a severe disadvantage lies in the fact that the role of the Icgenrelationship as a conceptual aid for the organization of classes is almost completely lost in such approaches. Other languages go even further in departing from classical inheritance. They are designed to provide flexible mechanisms for sharing resources so as to support prototyping and exploratory programming. These situations, in which the interconnections among components typically cannot be anticipated, are less well served by the static (“hard-wired”) hierarchic patterns discussed so far. Therefore, object-oriented languages such as Actors (Agha, 1987) and Self (Ungar and Smith, 1987) allow for dynamic interconnections referred to as dynamic inheritance or delegation. This means that, potentially, any component may be interconnected with any other one, the actual interconnection being established at run time only. A good survey on dynamic inheritance mechanisms in object-oriented languages is presented by Stein et al. (1989). The high flexibility of thus establishing interconnections appears similar to the situation in data flow languages (see Section
112
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
4.2.1), in which interconnections are subject only to the actual data requirements of a component.
Ada. In Ada a G/S-like concept, called generics or parametric polymorphism, is supported (Cardelli and Wegner, 1985). It is based on textual replacement of generic parameters in generic components by concrete ones and is realized via the generic and is new constructs. While the former serves to declare a component to be generic, that is, a sort of template, the latter establishes the interconnection between the generic template and the newly derived concrete component. Generic packages and subprograms are characterized by containing at least one generic parameter (resource). Consider, for example, a generic stack, the contents of which should be left generic, such that it could be specified as integer, character, etc., in specializations of STACK. The interconnection between the specialized unit, for example, INTSTACK, and the generic unit STACK is then established by the following declaration: package I N T S T A C K i s new S T A C K ( I N T E G E R 1 ;
The is new clause has the effect that the generic parameter(s) in STACK will be replaced by the concrete parameter(s) included in parentheses following the identifier of the generic unit (STACK). Similar mechanisms for implementing the concept of generics are provided, for example, in Eiffel and C + + . In C + + generic classes are called templates. For a detailed comparison of generics, subclassing, and inheritance consult Cardelli and Wegner (1985), Meyer (1988), and Wegner (1990).
Embley's OSA. It has already been mentioned that GIS is the fundamental organizational concept in 00 approaches. Hence it is supported by all 00 languages and notations. It is less common, however, for 00 modeling notations to provide the means to distinguish between different kinds of GIS according to different semantic constraints associated with GIS links. An example of a method and notation supporting such a distinction and thus enriching is-a links with application semantics is OSA (00 systems analysis) according to Embley e f al. (1092). In OSA, three kinds of G/S relationships, all working at the component-to-component level of precision, can be distinguished (for examples, see Fig. 14): 0
0
A union constraint declares that the union of a group of specializations constitutes the entire membership of the corresponding generalization. A mutual exclusion constraint indicates that a group of specializations of one generalization is mutually disjoint.
INTERCONNECTION OF SOFTWARE COMPONENTS
UniversityPerson
Student
FacultyMember
StaffMember
Computer
PC
Workstation
113
Employee
FullTimeEmployee
PartTimeEmployee
FIG. 14. Examples of three kinds of G/S relationships using the notation suggested by Embley et nl. (1992).
0
A partitioning constraint requires that the partitioning classes (i.e., specializations) be pairwise disjoint and that their union constitute the generalization.
Mapping this distinction into the BIG model amounts to further refining the set Icgen.In particular, besides the unconstrained generalization relationship category Icgcn,three more specific generalization categories must be introduced in order to allow for the modeling of G/S with the union, mutual exclusion, and the partitioning constraint, respectively.
Discussion. Concerning precision, an argument, similar to that already discussed for provision, applies to inheritance: Viewed from the side of the source (superclass), a higher degree of precision than having a target being “all subclasses” imposes problems on having libraries of reusable components. This is because the specific subclasses (target components) may not yet be known. In object-oriented systems organized along G/S hierarchies, it is common to distinguish between two kinds of resources being governed by different interconnection relationships: Procedural abstractions (e.g., methods mentioned in the class and instance protocols in Smalltalk) are visible in (i.e., provided to) the whole system, whereas data abstractions (e.g., instance variables in Smalltalk) are subject to inheritance mechanisms working only along the links established by the G/S or subclass relationship. An exception in this context is C+ +, which, in addition to allowing for inheritance, provides fine-grained mechanisms for specifying the provision of resources. As discussed earlier, these mechanisms are friends along with a distinction of three categories of resources: public, protected, and private. Furthermore, C+ allows for a distinction of the same three categories with regard to the derivation of subclasses from superclasses.
+
Reuse. G/S (in combination with encapsulation) is a conceptual structuring mechanism that supports the reuse of components in both conventional
114
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
and object-oriented settings. A software archive (Mittermeir and Rossak, 1987), for example, consists of software components for potential reuse organized along a G/S hierarchy. The fact that most object-oriented systems are inherently based on G/S hierarchies facilitates the reuse of components, inheritance itself being an important reusability mechanism. It is noteworthy that object-oriented systems tend to be designed to support reuse by extension rather than via updates. Thereby new classes are created that are either more general or more specialized than some existing class. In the latter case, resources are either added, or resources from the more general class are specialized or overridden and adapted to characterize the newly created class. This is in contrast to conventional systems, which rely more on modifications of existing, almost suitable components. In object-oriented systems there is an interesting trade-off between the number of resources reused, as constrained by the specific inheritance mechanism employed, and conceptual clarity, as established by the G/S relationship. Flexible, dynamic inheritance mechanisms allow for a high degree of sharing (i.e., reuse). Thus, they are extremely useful in exploratory and prototyping situations. Conversely, classical inheritance supports the construction of high-quality software by preserving the clear conceptual structure established by the G/S relationship.
5.6.3 Aggregation/Decomposition, and Part-0f-Relationships In data/knowledge models, the relationship established by associating components (resources being attributes or relationships) with classes or types is called aggregation and its inverse decomposition. In one form or another, aggregation is one of the most broadly used abstractions in computer science. It manifests itself in traditional, semantic, and 00 data models, the record structure in programming languages, and in all software development methods. The relationship interconnecting subcomponents with an aggregate component is traditionally also called the part-ofrelationship. Due to more recent developments discussed later, we prefer the term component-of to denote aggregation relationships. In accordance with Kim (1990), we suggest that the termpart-ofbe reserved to distinguish a specific category of composed-of relationships. Part-of relationships are characterized by carrying additional semantics resulting from the observation that only some of an aggregate’s subcomponents are (physical or logical) parts (Storey, 1993; Motschnig-Pitrik, 1993; Rumbaugh, 1994; Odell, 1994). To understand the difference, consider the real-world concept of a vehicle as shown in Fig. 15. Whereas the drivetrain and the wheels are parts of a vehicle, the company manufacturing the vehicle clearly is not a part of the
INTERCONNECTION OF SOFTWARE COMPONENTS
115
VehcleDnvetrain
components: manufacturer: Company
name: Stnng location: String president: Employee
FIG. 15. Example of an aggregation (composed-of) and a part-of relationship.
real-world concept of a vehicle, but just a subcomponent of its representation. Thus, manufacturer may point to a subcomponent, for example, Company, of the data structure holding the representation of Vehicle. The advantage of distinguishing parts from other subcomponents comes from the fact that parts carry specific semantics that can be exploited for issuing constraints. For example, a part may be shared or exclusive. Whereas a shared part may be purl-of more than one aggregate, an exclusive part is constrained to be part-of one aggregate only. The semantics of part-of links, either exclusive or shared, can further be refined on the basis of whether the existence of the part depends on the existence of the corresponding aggregate. This means that a part may be dependent or independent. A dependent part-of link means that the existence of the part depends on the existence of ‘‘its’’ aggregate. Thus, the deletion of an aggregate will trigger the deletion of all parts linked to it by dependent part-of links, whereas independent parts remain untouched. Only a few 00 techniques provide the means to distinguish parts from other subcomponents of an aggregate object. In particular, the OODB ORION has been a pioneer in superimposing the semantics of parts on component-of interconnections. In the OOA scene some OOA methods such as those of Rumbaugh ef al. (1991), Embley ef al. (1992), and Martin and Ode11 (1992) provide specific notations for distinguishing part-of links from other reference relationships (called associations). These OOA methods, however, do not explicitly support the specific semantics of shared versus exclusive and dependent versus independent links. In brief, in 00 modeling aggregation/decomposition tends to be expressed via the class-attribute structure. Textual nesting of components is not supported, although models are called “nested” in the case for which attribute domains may be structured classes or types. In models not supporting the specification of part-of links, the interconnection between an aggregate and its subcomponents (the composed-of relationship, as inverse to
116
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
the component-of relationship) is established by the equivalence of the names of some component and its appearance as an attribute domain (compare Fig. 15). It is interesting to observe that, unlike in traditional languages and notations where aggregation/decomposition is the most fundamental interconnection dimension, object-oriented languages emphasize a different structural dimension, namely, generalization/specialization. The latter is claimed to be better suited for building up hierarchies in data- and object-oriented designs and for facilitating maintenance.
5.6.4 The Member-Of-Relationship The member-of relationship allows for the realization of the notion of sets as collections of entities, having some features (resources, slots) in common. In data/knowledge modeling, member-of plays an important role in the modeling of sets. It has been introduced and formally defined by Brodie (1981) and is well known as the association abstraction, which abstracts the properties of individual set members in favor of the properties of the whole set. Thus the member-of relationship interconnects two classes, a member class and a set class. For example, the association (set class) Management can be defined as a set of Employee members, whereby Employee takes the role of the member class. Whereas typical properties of Employee are name, age, salary, etc., a typical property of Management is size, indicating the number of employees who are managers, or averageSa1ary, revealing the average salary of a manager. Although the member-of relationship as defined by Brodie has been adopted in many semantic data models, it has hardly penetrated into 00 modeling. In general, 00 approaches do not explicitly support the memberof relationship. Two exceptions to this rule are Rumbaugh’s OMT (Object Modeling Technique) (Rumbaugh et al., 1991) and Embley’s OSA (Embley et al., 1992), which both support member-of relationships in the sense of Brodie. Note that, unfortunately, in 00 modeling and OODBs the term member-of is heavily semantically overloaded. Often, it is not a synonym of the mathematical notion of set membership. Besides other meanings, it is used synonymously with instance-of in order to refer to the set of direct and/or indirect instances of some class. Also the term association has received different interpretations in 00 modeling: Besides denoting the abstraction of a set class as defined earlier, it is frequently used to denote any relationship (link) between two classes. An in-depth analysis of the member-of relationship is given by Motschnig-Pitrik and Storey (1995). A comparison of member-of, part-of, and component-of relationships is given by Motschnig-Pitrik (1994).
INTERCONNECTION OF SOFTWARE COMPONENTS
117
5.6.5 Metaknowledge The term metaknowledge has its roots in artificial intelligence and is defined as “knowledge about knowledge.” In this sense it differs from the application-specific knowledge contained within components (as discussed so far) in providing a “metalevel” holding information about the encoding, structure, and processes of application-specific knowledge. From this point of view, components can be partitioned into two levels, the metalevel (Ml) and the application level (Al). Thus it is possible for an Al component to refer to its M1 description, usually specified in some M1 component. From the numerous motivations for specifying metaknowledge described (Davis and Buchanan, 1985; Davis et af., 1985) we pick just those important for CIS: 0
0
0
The specification of metacomponents introduces additional structure into system descriptions being an important conceptual aid. M1 knowledge can be applied to encode strategic information on controlling the evaluation of rules in production rule systems (Waterman and Hayes-Roth, 1978) increasing the performance in rule-based systems. Common features of Al-components, for example, their structural constraints, can be described in one place-following the principle of locality-and hence be understood, maintained, and reused more easily.
To be able to model metaknowledge in the BIG, we partition the set of components C into M1-components C,,,, and Al-components Cappl.Further we introduce an interconnection relationship Ic,,,, such, that each component c E Capplmay be connected to a metacomponent. The case for which c, E Capplis to be linked to c, E C,,,, is denoted by inserting the pair (ca,c,) into the set Ic,,,,. The Ic,,,, specification given above reflects the MI-A1 interconnection as commonly realized in languages capable of expressing this interconnection. Whereas in Smalltalk every class is implicitly associated with a metaclass, in LOOPS (Bobrow and Stefik, 1983), TAXIS (Mylopoulos et al., 1980), Telos (Mylopoulos et af., 1990), and Booch’s O O D (Booch, 1991), for example, a class contains a metaclass clause to provide means for indicating its M1 description. Metaclasses play an important role in object-oriented languages in that they allow one to describe t h e properties (structure and behavior) common to a set of classes in their metaclass (Ferber, 1989). In this way, extensibility of a language with regard to new categories of classes is provided within one language. As an example, for a realization of metaclasses in an 00 setting consider Booch’s OOD. There, the interconnection of a class with its metaclass is established via the metaclass link appearing in class diagrams. As a textual
118
R. MOTSCHNIG-PITRIK AND R. T. M l T E R M E l R
counterpart, class templates hold a specific field called “Metaclass” to indicate the corresponding interconnection. 00 development as suggested for example by Martin and Ode11 (1992) and Embley et at. (1992) does not foresee notational elements for modeling metaclasses. Nevertheless, both methods possess a metalevel specification that metadefines all constructs used in the respective notations. Turning to OODBs it can be observed that different systems embody totally different philosophies regarding metaclass architectures. While GemStone/OPAL (Purdy et al., 1987) shares Smalltalk’s philosophy of implicitly associating a metaclass with each (simple) class, ORION (Kim, 1990) provides a single metaclass “CLASS” that is the metaclass of all classes. Yet, IRIS (Fishman, 1989) allows every class to be an instance of a metaclass such that infinite chains of metaclasses can be constructed. This variety of metaclass architectures, reaching from no support at all to the capability of defining multiple metaclasses for each class [such as in Telos (Mylopoulos et al., 1990)], indicates that researchers are still experimenting with the metaclass interconnection (Motschnig-Pitrik and Mylopoulos, 1992). In any case, metaclasses constitute a powerful concept in three respects: They provide an elegant mechanism for raising the expressive power of languages and notations; they facilitate extensibility; and they provide means for precise self-definitions.
5.6.6 Representation Abstraction The term representation abstraction was first used by Smith and Smith (1977) and later has been used by Borgida et al. (1984), Mittermeir and Rossak (1987), and Pitrik (1988) to refer to the provision for different levels of specification used during software development. There is no doubt that different developmental phases impose different requirements on representational formalisms. Whereas, in early phases, a formalism, among others, should allow for problem-oriented modeling and not enforce the expression of (implementation) detail, a programming language has to provide means to encode a model such that it can be processed by a machine with acceptable performance. Hence, different levels of representation are distinguished in most life-cycle methodologies. These levels differ mainly in: 0
0 0
The degree of precision and detail to be expressed Problem versus implementation orientedness The degree of formality required
From the point of view of expressing CIS,we are particularly interested in language features for establishing the interconnection between components at the at different levels of representation, for example, a component qdes
INTERCONNECTION OF SOFTWARE COMPONENTS
119
design level and a corresponding component c,,$odeat the implementation at the requirement specification level and two level, or a component components, c,l,des, C,Z,des (derived form at the design level. Note that the capability of specifying interconnections among components situated at different levels of representation does not include any commitment to some specific software process, nor to the number and consistency of formalisms employed throughout development. For process models heavily relying on iterations between phases, such as models suggested for object-oriented development (Booch, 1991), however, such interconnections are essential, since they transparently tie corresponding components together. Furthermore, keeping track of the development history, for example, via interconnecting corresponding components situated on different levels of representation, is a precondition for the reuse of components stemming from early phases. In short, the main motivations for expressing interconnections between components situated at different levels of representation are the following: 0
Coverage of more than one phase of some life cycle accompanied with the transition(s) between representations Support of a stepwise specification of details Consistency checking and requirements tracing Searching and reuse of components from preimplementational stages of development (Rossak, 1989).
To express the CIS between components situated on different levels of representation, we define an interconnection relationship Icder(“der” standing for derived form) such that whenever (c,,c,) € ICder, (cI,c, € C), it holds that c, has c, as its ancestor, and c, is situated at the level of representation just above that of c,. The ICder relationship works at the component-tocomponent level of precision and, in general, forms a partial ordering. In CILs allowing for the specification of k d e r relationships being partial orderings, the component at the lower level usually holds some derived from clause providing means to list its ancestors (Lamsweerde et al., 1988). To demonstrate specific realizations of representation abstraction in CILs, consider, for example, PIC/Ada, which is focused on the design phase. In PIC, the relationship is realized in a very straightforward way. A package in PIC (at the design level of representation) is identified by the same name as the corresponding Ada package. This is possible, since a oneto-one correspondence between PIC and Ada components is obligatory.
Traditional Software Development and Database Design. Traditional analysis and design methods typically use different notations for
120
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
the individual phases of the software process and even further notations for DB design. Hence, a major problem in traditional software development is to bridge the gaps between the various notations while proceeding from analysis to implementation and from a conceptual to a physical data model. Numerous CASE tools and DB design methods have been developed to help transform documents from earlier, more abstract phases to later, more concrete ones. Such tools help to establish and to keep track of the interconnections between the different levels of representation. Although tools definitely are indispensable for most realistically sized applications, the use of even the best tools remains somewhat problematic. This is because current tools work at a rather mechanistic level only (Brown and McDermid, 1992) and most additional details required at more concrete levels must be supplied by the human designerlprogrammer. Unfortunately, these details have to be incorporated into system-generated documents, which employ different structures compared with the documents at more abstract levels and hence are hard to understand.
Object-Oriented Development. One advantage of 00 development methods over traditional ones is their interphase consistency with regard to the core concepts and notations used for analysis and design. As a direct consequence, 00 development can be characterized by a smooth transition between developmental phases with an emphasis on G/S and reuse of components instead of heavy restructurings. Thus, the derivation relationship interconnecting components from different phases often will be one of the following: 0
0
0
0
A one-to-one transformation of a component (class) from an earlier to a later phase with the addition of (implementation) detail Generalization: the introduction of a new, more abstract class to factor out the resources (properties and behavior) that a number of classes have in common Specialization: the introduction of a new, more concrete class with additional and/or specialized resources The adaptation of an existing (library) class to implement some concept identified in the analysis or design phase.
00 development is very transparently described, for example, by Booch (1991) who offers a graphic as well as textual notation employing templates for all kinds of components (classes, modules, and subsystems; see Section 5.1) and for operations. In particular, Booch suggests that details be filled in as the design proceeds. This demonstrates that 00 development is a continuous process rather than one that proceeds in discrete stages. This
INTERCONNECTION OF SOFTWARE COMPONENTS
121
philosophy is shared, among others, by the model-driven OSA as described by Embley et af. (1992). Unlike many other 00 methods, Embley’s OSA provides explicit (graphical) means, such as high-level views, in order to support representation abstraction. In general, in 00 development the only explicit and clear-cut change in representation is the transition from some graphic or schematic representation used for analysis and design to an OOPL. Further aspects of uniformity result from the fact that the 00 design notation tends to be the same for application programs as well as for OODBs and, furthermore, that the target OOPL often coincides with the data definition and data manipulation language of the OODB used. To support the (only) design-to-code transition, CASE tools help to perform the notational transformation while relying on a consistent set of 00 concepts throughout the process. In particular, tools are capable of transforming the information contained in the (mostly graphic) design notation into code skeletons of the target OOPL. In this way tools realize and help to maintain the interconnection between two levels of representation.
5.6.7
Versions of Components
Version control, a subfield from software configuration management, is supported by operating systems (e.g., UNIX), software engineering environments [e.g., DSEE (Leblang and McLean, 1984), ROPKO (Zand er al., 1993)], and some CILs, such as Cooprider’s MIL, Intercol, and NuMIL (see Section 4.3). For reasons of focus, we do not deal with versioning in general. For a detailed discussion of versions in diverse application areas consult the literature [e.g., Habermann and Notkin (1986), Habermann (1990), Katz (1990), Kim and Lochovsky (1989), Sciore (1991)l. In this place, we discuss only one linguistic aspect, namely, the coordination of multiple implementations referred to as versions, or, more precisely, variants obeying one interface. In general, the advantages of having multiple implementations for one interface have been advocated as arguments for information hiding and for the separation of interface and implementation. Few languages, however, really support multiple implementations, examples being Intercol and NuMIL. NuMIL (see also Section 4.3), for example, focuses on the support of evolving software systems and thus provides means for establishing the interconnections between the interface and its multiple implementations. NuMIL describes a system as an evolving family of related subsystems, the criterion for membership in a family being shared interface characteristics specified in a(n) (abstract) family template. As an example, the module family template consists of
’122
0
0
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
A header indicating the kind of component (“module family”) and its name A provision clause listing the (minimal) set of resources to be provided by the family A property section encompassing a nonprocedural specification of each resource provided.
In NuMIL one module family may have several implementations, each of which is considered a different member or version of the family. The interconnections between a template (abstract interface) and the implementations (versions) are established simply via explicit version clauses. More precisely, the implementation specification consists of a list of version descriptions each consisting of three parts:
0
The realization specification, indicating the name of the source file that realizes the implementation The “concrete interface,” consisting of a list of provided and required resources, with the syntactic attributes of each resource described in the target implementation language The functional properties of each operation given in the form of preand postcondition assertions
In NuMIL, implementation specifications can be omitted completely in early developmental phases such that only templates are described. Later, these are complemented by implementations supplying further details.
5.6.8 Perspectives and Views In real-world modeling it is conceivable that the information on some conceptual entity does not come as a single, coherent unit, rather, it is distributed among a number of components, each revealing some aspects of the conceptual entity. Some KR and object-oriented languages respond to this modeling need by supporting the specification of partial and/or derived information on conceptual entities, giving rise to the notion of perspectives. In other words, a perspective is a conceptual entity viewed from a specific point of view. It is this point of view that determines by which resources .a perspective can be characterized. In general, it holds that the union of all perspectives is necessary to fully characterize the respective conceptual entity. From the conceptual point of view, perspectives provide an important structuring mechanism by supporting a natural partitioning of complex information (Motschnig-Pitrik, 1989). In this way, they contribute to a better understanding of systems structured along this dimension.
INTERCONNECTION OF SOFTWARE COMPONENTS
123
The semantics of perspectives, namely, the representation of different points of view on the same conceptual entity, is similar to that of (user) views in relational databases. Nevertheless, perspectives differ from views in relational DBs (Date, 1986; Vinek et al., 1982; Ullman, 1983) in a number of important aspects: 0
0
0
Whereas DB views may contain information derived from several relations, perspectives as described above hold partial information on exactly one object (class, component). Perspectives usually have independent name spaces, i.e., disjoint resources, whereas D B views clearly share resources with the base relations from which they are derived. DB views are defined by expressions in relational algebra, i.e., queries, operating on relations. These expressions establish kinds of interconnections between views and base relations. Perspectives, however, are interconnected by explicitly specifying some interconnection relationship.
Interpreting perspectives as specific kinds of components in the BIG leads to the consideration of a further interconnection relationship, say, isperspective-on, which allows one to determine the set of components (perspectives) whose members collectively describe a specific conceptual entity. Languages differ in their mechanisms of supporting this interconnection relationship (Motschnig-Pitrik, 1995); in most cases, however, the perspectives are linked to the name of the conceptual entity they describe in part (to be modeled as an empty component in the BIG). In this case, the syntactic structure of the is-perspective-on relationship is a tree, its precision being component to component. Perspectives are realized, for example, in the KR language LOOPS (see later) and have been suggested as an extension to object-oriented programming, where they are referred to as views (Shilling and Sweeney, 1989). Views, in the general sense of the term, are also an emerging topic in OODBs and hence are briefly discussed later.
Views in OODBs. Whereas views belong to the core functionalities in relational databases, they still constitute a research issue in OODBs (Bertino, 1992; Motschnig-Pitrik, 1996). This is mainly due to the higher complexity of 00 data models when compared with relational ones. More precisely, the additional expressive power 00 data model calls for a functionality of 00 views that exceeds that of relational views. Such additional functionality concerns predominantly two aspects: schema reorganization and provision of multiple interfaces to an object. Unlike in the relational approach, where every view can be expressed by a query, additional linguistic means are necessary for view definition in
124
R. MOTSCHNIG-PITRIK AND
R. T. MITTERMEIR
OODBs. This is because schema reorganization (such as the introduction of a new superclass) and multiple interfaces to an object cannot be expressed simply by query expressions. Furthermore, OODB views depend on concepts such as inheritance, overloading, and object creation. Thus, the derivation relationship Icderbetween some base component(s) and views is, in general, significantly more sophisticated than in traditional DBs such that a more detailed discussion is outside the scope of this article. The interested reader will find a more detailed discussion and reference list on views in OODBs when consulting Motschnig-Pitrik, 1996. An analysis and formalization of contexts and perspectives in software development, AI, and databases is given by Motschnig-Pitrik (1995).
5.7
Comparison of Features of Languages Expressing Component Interconnections
Having discussed the individual features of languages allowing for the specification of CIS and illustrated the former by examples in specific languages, Table I (pages 126-127) contains a feature by feature comparison of some representative languages based on the notions developed so far. The choice of languages included in the table was driven by the following three criteria:
1. Incorporation of “interesting” CIL features 2. Emphasis on object-based and object-oriented approaches 3. Coverage of the fields: software development, programming languages, databases, and knowledge representation Since each of these fields is represented by two or three approaches, the table can also be used to identify the predominant application andor instantiation of a CIL feature according to the different fields, or paradigms used in the respective field. TAXIS, falling into the category of a semantic data model, has also been included to illustrate that a data model built on software engineering and KR principles typically addresses a number of features discussed earlier. Note that the columns for Smalltalk and C + + could equally well represent OODBs having one of these languages as data definition and data manipulation languages, such as Gemstone and ONTOS. It is noteworthy that languages explicitly supporting provisionlrequisition, in general, do not support generalizationhpecialization. Exceptions are Ada and PIC, since they include the generics concept, which allows one to model restricted aspects of G/S via parametric polymorphism; further, LOOPS allows for the requisition of objects in ruleset components: and Vbase requires type specifications to be imported into code sections. Finally,
INTERCONNECTION OF SOFTWARE COMPONENTS
125
C + + incorporates a rich set of mechanisms for fine-grained control over provision/requisition besides supporting G/S in the form of derived classes and multiple inheritance. Means to specify aggregation relationships, which associate a component with attributes and/or components, are provided by all languages surveyed in this article. However, few languages allow for an explicit distinction of part-of relationships, intended to model the composition of a component of physical or logical subcomponents. Also, very few languages allow for the expression of interconnections of components at different levels of representation: In NuMIL two levels of representation are covered by the language so that the more concrete representation is intended to implement the more abstract template specifications; in TAXIS components at the design level can be recognized as successors of requirement level components in cases of name equivalence. In general, 00 approaches differ from conventional ones in offering the same or an incremental set of modeling primitives and suggesting a stepwise addition of implementation details. In this way they support a smooth transition between developmental phases. Unlike in other approaches where components are transferred from one level of representation to another, in Vbase different responsibilities-type specification versus type implementation-are expressed at different levels of detail that coexist in the final product. As mentioned earlier, the interconnection between the two levels is established by imports of type specifications into program code. Most importantly, Table I helps to provide some insight into the large variety of component interconnection mechanisms. It demonstrates that the field of language features for CISis by far not settled yet and that further research and experience are needed to establish more rigid guidelines on the design of CILs and CI features of languages used for software development.
6. Discussion While the role that individual CI features play in supporting software development and maintenance has already been described in the course of Section 5, here we address two basic questions concerning the specification of CIS: 1. Is a universal CIL, which optimally supports the construction and maintenance of high-quality software, feasible? 2a. If it is, which features, especially relationships, should it include? 2b. If it is not, which features, especially relationships, should every language supporting the specification of CIS include?
TABLE I COMPARISON OF SOME LANGUAGES REGARDING FEATURES FOR EXPRESSING CIS CI Feature Language independence of CI specification Nesting of componenls Kinds of components
ADA
MODULA-2
MIL-75
NuMlL
C+ +
PIC
TAXIS
No
No
Yes
Yes
Yes
No
No
Nesting
Nesting
Nesting
Nesting
No
Yes
No
Subprogram/ package
Procedure/ module
Subsystem/ Subsystem/ virtual module subsystem
Subprogram/ package, incomplete components Types, others
Class, (sub)program
Metadass. four kinds of classes
Private. pubic. protected instance vs. class (static) resources
No. although property categories exist, class properties are defined in melaclasses
Kinds of Privatelpublic Opaque, No, just No. just resourceh types. others transparent, "resource" "resource" handled types, others differently with respect to CIS
Separation interfacebody
Yes
Module: yes Program: no
No
Yes
Yes
No
No
Provision/ requisition (explicitly)
Yes
Yes
Yes
Yes
Yes
Public resources, friends
No
Completc interface
No
No
NA"
NA
NA
Generalization/ specialization
Gcnerics
No
No
Abstract Ycs interface: no, concrete interface: yes No Generics
Yes, derived class
Yes. IS-A
Part-of relationship Mrmbrr-of
No
NO
No
No
Nu
NO
NO
No
No
No
No
Nu
No
No
Metaknowlcdge No intcrconncction
No
No
No
No
No
Yes. metaclass
Interconnection between different levels of representation Views. perspectives
No
No
No
Via template
By PIC environment via names
No
Via name
No
No
No
No
(Incomplete "views" via
No
No
Tree via nesting. lattice via requisition
Tree via nesting, lattice via requisition
Tree via "parent" function, nesting
Subsystem tree Lattic via with requisition modules in leaves
Nesting of components. subclass lattice
GIS lattice
"stubs")
Overall system Structure
"A,
not applicable.
b
KEE
SMALLTALK
I OOPS
ORION
IRIS
OOD (Booch)
Vbase
C1 embedded in CI embedded design model in analysis model
No
No
No
CI embedded in DDL. DML
CI emhedded CI embedded i n d d t d m o d e ~ in T D L and COP
Nu
No
No
No
Obiect
linit
MctaclasP, class. ruleset
Object: class or instance
N o components Object: type or Object: type o r Object: class or instance instance instance, module, (sub)system Function Property, Fieldioperation operation public. private, protected
Class variahles Own slots. and member methods. slots. instance methods variahles and methods. pool variahles No No
Provision of No methods via class/ inStancc protocol. requis. of shared pools NA NA
classVariables, Instance instanceVariables at1rib.i method, class attribute/ mcthod, shared/ default attr.
No
Yes
Via higher level Object, class, event, view
Relationship. set, action. operation
No
Yes
No
Yes, via import Yes, via uses relationship
No
NA
NA
Yes
Yes
NA
Yes, union, partitioning, mUtUd1 exclusion Yes
No, hut all methods No are implemented outside the class def. No, except No requisition: workspace in rulrSeis
NA
No
OSA (Embley et al )
NA
Yes. suhclass
Yes. subclass Yes. subclass
Yes
Yec
Yes
Yes
No
No
Yes
Yes
No
No
No
No
YCS
No
No
No
No
No
No (imp1 metaclass)
No
Yes, MetaClass
Types viewed as objects
Not explicitly
No
No
No
One metaclass CLASS No
No
Yes. T D L and COP
No
No
Yes
No
No
No
No
Subclass hierarchy
CIS and
Cis lattice
CIS lattice,
CIS lattice
CIS lattice
Class G/S CIS lattice lattice, module compil. dependencies, subsystem composition
membero f lattice
class composition hierarchy
Yes, “association” Yes, metaclasses O S A metamodel exists Gradual introd. Yes, via views; of detail “model during design integration”
Yes, views
128
R. MOTSCHNIG-PITRIK AND
R. T. MlTTERMElR
Whereas the complete answers to these questions are left to further research, partial answers can be deduced from the investigation underlying this paper. Firstly the analysis indicates that building a “generic” CIL is a challenging research issue. Such a CIL should support all the interconnection relationships, provide all meaningful degrees of granularity and precision, and be extendible, such as to be adaptable to particular application needs. Of course, a different question in this context is how such a language (or language fragment) could be introduced in order to be of practical value. Care must be taken while constructing generic CI mechanisms, since individual approaches tend to employ similar but nevertheless different components for system construction, such as types and classes (or both) in the case of object-oriented systems. Clearly, a formal and universal specification of CI is feasible only, if the domains and codomains of interconnection relationships are well defined in the first place. With respect to the second question, we observe that languages expressing CIS, in general, tend to support either provision/requisition or generalization/specialization along with some kind of inheritance exclusively and, in addition, a combination of other interconnection relationships, depending on the application. This is not surprising, since provision/requisition and inheritance both support the same goal, namely, code sharing, such that the choice is either in favor of the one or the other. But the borderline is not strict at all: The less inheritance mechanisms depend on kgen [compare, for example, delegation, dynamic inheritance (Stein et al., 1989) and partial inheritance] the more they resemble provision/requisition mechanisms, with the main difference often residing in terminology. An exception in this context is C + + , which includes mechanisms to specify both provision/ requisition and derived classes. Although the latter support (classical) inheritance, a combination of both kinds of mechanisms allows for more detailed control over code sharing, for example, by providing only a subset of a class’s resources. We conclude that, whereas G/S has proved to be an indispensable structuring mechanism on the conceptual level, further research is necessary to decide on a proper choice or combination of provision/requisition and inheritance mechanisms on the detailed design and implementation levels. Regarding the other interconnection relationships we note that they all are directed toward different targets and hence d o not interfere with one another. The more complete their support is, the better met are essential issues in software development, maintenance, and evolution. Finally we give some concluding remarks that attempt to interpret the results and suggest areas for further research. Let us, therefore, try to characterize the present scene of language features for CI by indicating some resolved and some still unresolved issues.
INTERCONNECTION OF SOFTWARE COMPONENTS
129
The benefits of specifying individual categories of CIS are quite clear, but precise rules on which features to include in which instantiation, possibly in response to the problem size and complexity and life-cycle phase, etc., are missing. Also, the precise semantics of interconnection relationships have not always been defined (Monarchi and Puhr, 1992). Consequently, each new language and software engineering environment offers new solutions, being perfect with respect to some features but much less than perfect regarding (or even discarding) other features. This is why so many scattered solutions exist, but there is no coherent framework. To demonstrate some open issues consider, for example, the objectoriented languages Smalltalk and LOOPS. In Smalltalk no direct access to variables of an object other than by methods of this object is allowed. In LOOPS, however, variables of an object may be freely accessed from any other object. Is one of them generally preferable? Proponents of strict encapsulation, as in SmallTalk, base their arguments on keeping the information on the internal representation private. A counter argument is that in a knowledge representation style of programming (as well as in conceptual modeling) the structure of an object is not considered an implementation detail but essential problem knowledge, such that access to it is particularly useful, for example, for comparing two objects. As another example of open issues, consider the following: Is it preferred to have a complete and precise interface, such as in PIC, or an incomplete interface that does not include any information on requisition at all, but allows multiple versions to specify their own resource requirements? Despite many open questions, a number of features exist such as those discussed throughout Section 4, which have already turned out to be of great practical value in specific contexts and hence are worth support. These are, among others: 0
0
0
0
Separate interfaces, allowing for the hiding of implementation details during detailed design and programming The explicit specification of prowisiodrequisition interconnections, providing more transparent and precise access control than pure nesting of components The separation of code that implements functional requirements from the specification of component interconnections as well as from the distribution of processes in some (distributed) environment The modeling of generalizatiodspecializafion-like relationships, reflecting the conceptual similarity of components and supporting a stepwise addition of details, known to facilitate the reuse, evolution, and organization of components
130
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
Specification of metaknowledge, in particular metaclasses, allowing one to characterize categories of classes by describing features shared by all classes which are instances of a category The interconnection of components represented in different notations, mirroring the developmental history a component goes through when passing through the life cycle Support of versions facilitating the actual construction of systems and, optionally, also the integration of components realized in different languages The modeling of perspectives, in allowing one to distinguish and to interconnect components resulting from different points of view on the same conceptual entity, thereby supporting a natural structuring technique Furthermore, experience with existing languages and tools has already demonstrated both the potentials and limitations of different modes of addressing C1 issues, such as their incorporation into different language paradigms (see Section 4).
7. Summary The overall goal of this article was to provide an in-depth investigation of the concepts and mechanisms various languages and notations provide to express interconnections among software components. Thereby the point of view of software engineering and programming languages has been complemented by that of data modeling and knowledge representation. The reasons for the emerging interest in concepts and techniques allowing for the interconnection of components are numerous. In traditional software engineering it has been proven that a thorough specification of component interconnection has profound effects on software quality. Besides this traditional aspect, more recent topics such as
0
software reuse, integration of different paradigms of programming within one frameworkiapplication, integration of techniques from software engineering, databases, and Al, generic environment architectures, providing the software engineer with a metalevel to specify the entities and relationships required to support the software process of his or her choice,
have attracted the attention of the software community. Since these topics ultimately rely on a proper specification of component interconnection (CI), they have been given special attention throughout.
INTERCONNECTION OF SOFTWARE COMPONENTS
131
The first part of the article concentrated on introducing the notion of CI and on establishing the scope of the article by providing a survey on different paradigms of languages that include linguistic means to express CIS. Since the range of such languages (covering specification, design, programming, and knowledge representation languages as well as selfcontained CI languages) appeared to be broad, we felt the need to introduce a common, abstract model to serve as reference (common denominator) as well as to provide a common, graph-based representation of the various features of CI. To accommodate these needs, basic interconnection graph has been defined. Successive refinements of the basic model have allowed for transforming various CI features into a common model. This has facilitated a straightforward comparison, revealing the essence of features regardless of their specific representations in different languages. A systematic feature-by-feature investigation on CI (Section 5 ) constitutes the core of the article that aims to provide a deeper understanding of the problems and solutions concerning CIS.A comparison of 10 representative languages with regard to the individual interconnection relationship categories identified in Section 5 concludes the survey, followed by a brief discussion of issues for further research. Besides providing a survey on CI features, the article has shown that CI can be addressed separately (although not independently) from programming languages. This has been demonstrated by discussing self-contained CI languages as well as by the BIG model. Although the primary reason to include the BIG (in this survey) has been the comparison of CI features, the abstract model gives further evidence of the feasibility of addressing major issues of CI in a systematic way, decoupled from the bulk of more or less interfering details, which any realistic (programming) language cannot dispense with. This is not to suggest that specific instantiations of CI features-finally-should not depend on a particular kind of language. In this respect, further research should be devoted to combining existing knowledge and experience on CIS in order to allow for establishing common guidelines for the design of CI frameworks. Specifically, further research is needed to filter out proper combinations of these features and their instantiations as well as to find an appealing representation and a useful “toolbox” to support adequately the various features. But there is no doubt that the effort put into the development of a consistent and well-founded (both language and tool) support of CI issues will pay off. It will bring us closer to the realization of the requirements of high software quality, reuse of components, integration of different paradigms-requirements we have to keep in mind when using or designing a component interconnection mechanism, or incorporating it into a language and/or CASE environment.
APPENDIX: Abbreviations and Miniglossary BIG
Basic interconnection graph (Section 2)
CI
Component interconnection (Section 1)
CIL
Component interconnection language (Sections 1 and 3.3)
GP
Gandalf prototype (Section 3.3)
G/S
Generalization/specialization (Section 4.6.2)
Ic
One of the four components constituting the BIG; Ic is a set holding interconnection relations
MIL
Module interconnection language (Section 3.3)
00
Object-oriented
OODB 00 database OOPL
00 programming language
OOA
00 analysis
OOD
00 design
RIG
Refined interconnection graph (Section 2)
132
INTERCONNECTION OF SOFTWARE COMPONENTS
133
ACKNOWLEDGMENTS Special thanks are due John Mylopoulos and Salvatore March for thier helpful detailed comments on an earlier version of this article. In particular, we would like to thank Veda Storey for her valuable suggestions and stylistic comments. Renate Motschnig-Pitrik thanks Gunther Vinek and her colleagues at the department, in particular Martin Hitz, Thomas Muck, and Gunther Pernul for insightful discussions.
REFERENCES Ada (1981). The programming language Ada. Reference Manual, “Lecture Notes in Computer Science,” Springer Verlag, Berlin. Agha, G. A. (1987). “ACTORS: A model of concurrent communication in distributed systems,” The MIT Press, Cambridge, MA. Allen, R., and Garlan, D. (1994). Formalizing architectural connection. Proc. 16th International Conference on Software Engineering, pp 71-80, Sorrento. Italy, IEEE Comp. SOC. Press. Andrews, G. R., and Schneider, F. B. (1983). Concepts and notations for concurrent programming. ACM Computing Surveys 15(1), 3-43. Andrews, T. (1991). Programming with Vbase. I n “Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD” (R. Gupta and E. Horowitz, Eds.), Prentice Hall. Englewood Cliffs, NJ. Andrews, T., and Sinkel, K. (1991). ONTOS: A persistent database for C + + . I n “ObjectOriented Databases with Applications to CASE, Networks, and VLSI CAD” (R. Gupta and E. Horowitz, Eds.), Prentice Hall, Englewood Cliffs, NJ. Balzert, H. (1982). “Die Entwicklung von Software Systemen.” Bibliographisches Institut Mannheim. Bertino, E. (1992). A view mechanism for object-oriented databases. Lecture Notes in Computer Science, No. 580, pp. 136-151, Springer Verlag, Berlin. Biggerstaff, T. J., and Perlis, A. J., Eds. (1989). “Software Reusability,” Vols. I and 11, ACM Press, New York. Bobrow, D. G., and Stefik, M. J. (1983). “The LOOPS Manual,” Xerox Corporation. Booch, G. (1983). “Software Engineering with ADA,” BenjaminiCummings, San Francisco. Booch, G. (1 991). “Object-Oriented Design with Applications,” 2nd ed. Benjaminicummings, San Francisco. Borgida, A. (1991). Knowledge representation, semantic modeling: Similarities and differences. I n “Entity-Relation Approach: The core of Conceptual Modelling” (H. Kangassalo, ed.), Elsevier Science Publishers, The Netherlands. Borgida, A,, Mylopoulos, J., and Wong, H. K. T. (1984). Generalization specialization as a basis for software specification. I n “On Conceptual Modelling,” (M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, Eds.), Springer Verlag, Berlin. Boudriga, N., Mili, A,, and Mittermeir, R. (1992). Semantic-based software retrieval to support rapid prototyping. Structured Programming 13, 109-127. Brachman, R. J. (1979). On the epistemological status of semantic networks. I n “Associative Networks: Representation and Use of Knowledge by Computers” (N. V. Findler, ed.), Academic Press, San Diego. Brachman, R. J. (1983). What is-a is and isn’t: An analysis of taxonomic links in semantic networks. IEEE Computer, October, 30-36. Brodie, M. L. (1981). Association: A database abstraction for semantic modelling. I n “ER Approach to Information Modeling and Analysis,” (P. P. Chen, ed.), ER Institute.
134
R. MOTSCHNIG-PITRIK AND R. T. MlTTERMElR
Brodic, M. L., Mylopoulos, J., and Schmidt. J. W., Eds. (1984). “On Conceptual Modelling,” Springer Verlag, Berlin. Brown. A. W.. McDermid, L. A. (1992). Learning from IPSE’s mistakes. I E E E Software 9(2), 23-28. Cardelli. L.. Donahuc, J., Glassman, L.. Jordan, M., Kalsow, B., and Nelson, G. (1992). Modula-3 languagc rcport. SigPlun Notices 27(8), 15-42, Cardelli, L., and Wegner, P. (1985). On understanding types, data abstraction. and polymorphism. A C M Comprrring Surveys 17(4), 471-522. Coad, P.. and Yourdon. E. (1991). “Object-Oriented Analysis.” Prcntice Hall, Englewood Cliffs. NJ. Cooprider, L. W. (1979). “The representation of families of softwarc systems,” Ph.D. Thesis. CMU-CS-79-I 16, Carnegic-Mellon University. Damon, C., and Landis G. (1991). Abstract state and representation in Vbase. In “ObjectOriented Databases with Applications to CASE, Networks, and VLSI CAD” (R. Gupta and E. Horowitz, eds.). Prentice Hall, Englewood Cliffs, NJ. Dart, S. A,. Ellison, R. J., Feiler, P. H.. and Habermann, A. N. (1987). Software development environments. IEEE Computer, 20( 11). 18-28. Date, C. J. (19x6). “An Introduction to Database Systems,” 4th ed.. Addison-Wesley, Reading, MA. Davis, R., and Buchanan, B. G. (1985). Meta-level knowledge: Overview and applications. In “Readings in Knowledge Representation” (R. J . Brachman and H. J. Levesque. Eds.), Morgan Kaufmann. Davis. R., Buchanan, B., and Shortliffe, E. (1985). Production rules as a representation for a knowledge-based consultation program. In “Readings in Knowledge Representation” (R. J. Brachman and H. J. Levesque, Eds), Morgan Kaufmann. DeRemcr, F., and Kron, H. H. (1976). Programming-in-thc-large versus programming-inthe-small. I E E E Truns. Software Eng. SE-2(2), 321-327. Digital (1983). “Programming in VAX 11 Pascal,” Digital Equipment Corporation. Eder, J., Kappel, G.. and Schrefl, M. (1994). “Coupling and Cohesion in Object Oriented Systems.” TR Klagenfurt University. Embley, D. W., Kurtz, B. D., and Woodfield, S. N. (1992). “Object-Oriented Systems Analysis-A Model-Driven Approach,” Prenticc Hall, Englewood Cliffs. NJ Feldman, S. I. (1979). Makc-A program for maintaining computer programs. SoftwurePructice Exper. 9, 225-265. Ferbcr, J. (19x9). Computational reHection in class based object orientcd languages. Proc. OOPSLA 89%pp. 317-326. Fikes, R. E., and Kehler, T. P. (1985). The role of frame-based representation in reasoning. C A C M September. 28(Y). Findler. N. (1979). “Associative Networks: Representation and Use of Knowledge by Computers,” Academic Press, San Diego. Fishman, D. H., et a/. (1989). IRIS: An object-oriented database management system. In “Readings in Object-Oriented Databases” (S. Zdonik and D. Maier, Eds.), MorganKaufmann. Cane, C., Sarson, T. (1979). “Structured System Analysis: Tools and Techniques,” Prentice Hall, Englewood Cliffs, NJ Garlan, D.. Allen. R., and Ockerbloom, J. (1995). Architectural mismatch or why it’s hard to build systems out of existing parts. Proc. 17th International Conference on Software Engineering, pp. 179-185. Seattle. WA, IEEE Comp. Soc. Press. Garlan, D., and Perry, D. (1994). Software architecture: Practice, potential, and pitfalls. Proc. 16th International Conference on Software Engineering. pp. 363-364, Sorrento. Italy, IEEE Comp. Soc. Press.
INTERCONNECTION OF SOFTWARE COMPONENTS
135
Goguen. J. A. (1986). Reusing and interconnecting software components. IEEE Computer, pp. 16-28. Goldberg, A,, and Robson, D. (1983). “SMALLTALK-80, The Language and Its Implementation,” Addison-Wesley, Reading, MA. Goldstein, R. C., and Storey, V. C. (1992). Unravelling is-a structures. Info. Syst. Res. 3(2), 99-125. Greenspan. S., and Mylopoulos. J. (1 983). A knowledge representation approach to software engineering: The TAXIS project. Proc of the Conference of the Canadian Information Processing Society, pp. 163-174, Ottawa. Guttag, J. V. (1975). “The specification and application to programming of abstract data types,” Ph.D. Dissertation, University of Toronto. Habermann, A. N. (1990). Engineering large knowledge-based systems. Data Knowl. Eng. 5,105-117. Habermann, A. N., and Notkin, D. (1986). Gandalf: Software development environments. Trans. Software Eng. SE-12(12), 1117-1127. Harbison, S. P. (1992). “Modula-3,” Prenticc Hall, Englcwood Cliffs, NJ. Henderson-Sellers, B., and Edwards, J. M. (1990). The object-oriented systems life cycle. CACM 33(9), 142-159. Hoare, C. A. R. (1969). An axiomatic basis for computer programming. CACM 12(10), 576-580. Hood, R., Kenedy. K., and Muller, H. A. (1986). Efficient recompilation of module interfaces in a software development environment. ACM SlCPLAN Notices 22(1), 180-189. Hudson. S., and King, R. (1988). l h e CACTIS project: Database support for software environments. IEEE Trans. Software Eng. SE-14(6), 709-719. Hull, R.. and King, R. (1987). Semantic database modeling: Survey, applications, and research issues. ACM Computing Surveys 19(3), 201-260. Jackson, M. A. (1982). “System Development,” Prentice Hall, Englewood Cliffs. NJ. Johnson, R. E., and Foote, B. (1988). Designing reusable classes. J . Object Oriented Programming, pp. 22-35. Jones, C. B. (1980). “Software Development-A Rigorous Approach,” Prentice Hall, Engelwood Cliffs, NJ. Katz. R. H. (1990). Toward a unified framework for version modelingin engineering databases. ACM Computing Surveys 22(4), 375-408. Kim, W. (1990). “Introduction to Object-Oriented Databases,” The MIT Press, Cambridge, MA. Kim, W., and Lochovsky, F. H., Eds. (1989). “Object-Oriented Concepts, Databases, and Applications.” ACM Press, New York. Kirova, V., Rossak, W., and Jololian, L. (1994). Software architectures for mega-system development: Basis concepts and possihlc specification. Proc. 3rd International Conference on Systems Integration, pp. 38-45, Sao Paulo, Brazil. IEEE Comp. Soc. Press, Vol. I . Knuth, D. E. (1968). Semantics of context-free languages. Mathematical Systems Theory 2. Kuhn, D. R. (1990). On the effective use of software standards in systems integration. Proc. 1st International Conference on Systems Integration, pp. 455-461, IEEE Comp. SOC.Press. LaLonde, W., and Pugh, J. (1991). Subclassingfsubtypingfis-a. J. Object Oriented Pmgramming, pp. 57-62. Lamsweerde, A., Delcourt, B., Delor, E., Schayes, M.-C., Champagne, R. (1988). Generic lifecycle support in the ALMA environment. IEEE Trans. Software Eng. SE-14(6), 720-741. Leblang, D. B., and McLean, G . D. (1984). Computer-aided software engineering in a distributed workstation environment. Proc. of the ACM SIGSOFTlSIGPLAN Software Engineer-
136
R. MOTSCHNIG-PITRIK AND R. T. MllTERMElR
ing Symposium on Practical Software Development Environments, SIGPLAN Notices, 19(5), 104-112. Lenzerini, M., Nardi, D., and Simi, M., Eds. (1991). “Inheritance hierarchies in Knowledge Representation and Programming Languages,” John Wiley & Sons, New York. Levesque, H. (1986). Knowledge representation and reasoning. Ann. Rev. Computer Sci. pp. 255-287. Liskov, B., et al. (1977). Abstraction mechanisms in CLU. CACM 20(8), 569-576. Magee, J., Dulay, N., Eisenbach, S., Kramer, J. (1995). Specifying distributed software architectures. Proc. ECSE ’95. Lecture Notes in Computer Science, Springer Verlag, 137-153. Magee, J., Kramer, L., and Sloman, M. (1989). Constructing distributed systems in conic. IEEE Trans. Software Eng. 15(6), 663-675. Madhavji, N. H. (1988). Fragtypes: A basis for programming environments. IEEE Trans. Software Eng. 14(1), 85-97. Martin, J., and Odell, J. J. (1992). “Object-Oriented Analysis and Design,’’ Prentice Hall, Englewood Cliffs, NJ. Meyer, B. (1987). Reusability: The case for object-oriented design. IEEE Software, 4(2), 315-328. Meyer. B. (1988). “Object-Oriented Software Construction,” Prentice Hall, Englewood Cliffs, NJ. Meyer, B. (1990). Lessons from the design of the Eiffel libraries. CACM 33 (9). 68-88. Meyer, B. (1992). “Eiffel: The Language,” Prentice Hall, Englewood Cliffs, NJ. Mittermeir, R. T. (1986). Object-oriented software design. International Workshop on Software Engineering Environments, Beijing, China. Mittermeir, R. T., and Kofler, E. (1993). Layered specifications to support reusability and integrability. J . Syst. Integration 3, 272-302. Mittermeir, R., and Oppitz, M. (1987). Software bases for the flexible composition of application systems. IEEE Trans. Software Eng. SE-13(4), 440-460. Mittermeir, R. T., and Rossak, W. (1987). Software bases and software-archives-Alternatives to support software reuse. Proc. Fall Joint Comp. Conference 87’, pp. 21-28, Dallas, TX. Monarchi, D. E., and Puhr, G. E. (1992). A research typology for object-oriented analysis and design. CACM 35(9), 35-47. Moss, J. E. B. (1989). Object orientation as catalyst for language-database integration. I n Kim and Lochovsky (1989). Mossenbock, H., and Wirth, N. (1991). The programming language Oberon-2. Structured Programming. Motschnig-Pitrik, R. (1989). Toward a common structural level for software, database, and knowledge based systems. Appl. Artificial Intell. 3(4), 405-426. Motschnig-Pitrik, R. (1990). A framework for the support of a common structural level for software, database, and knowledge based systems. J . Syst. Software, 12(12), 157-165. Motschnig-Pitrik, R. (1993). The semantics of parts versus aggregates in data knowledge modelling. Proc. CAiSE’93, Lecture Notes in Computer Science, No. 583, Springer Verlag, Berlin, 352-373. Motschnig-Pitrik, R. (1994). Analysing the notions of attribute, aggregate, part, and member in datalknowledge modelling. Proc. 4th International Conference on Information Systems Development ISD’94, pp. 40-52, Bled, Slovenia; also in Special Issue of J. Syst. Software (1996) (in press). Motschnig-Pitrik, R. (1995). An integrating view on the viewing abstraction: Contexts and perspectives in software development, AI, and databases. J. Syst. Integration 5, 23-60. Motschnig-Pitrik, R. (1996). Requirements and comparison of view mechanisms for objectoriented databases. Information Systems, (in press).
INTERCONNECTION OF SOFTWARE COMPONENTS
137
Motschnig-Pitrik. R., and Mylopoulos, J. (1992). Classes and instances. fnr. J . Intell. Cooperative Info. Syst. 1(1), 61-92. Motschnig-Pitrik, R., and Storey, V. C. (1995). The grouping: An cffective construct for modelling sets. Data Knowledge Eng. 16, 147-185. Miiller, H., and Klashinsky, K. (1988). Rigi. a system for programming-in-the-large. Proc. 10th IEEE Int. Conf. on Software Engineering, pp. 80-86. Myers, G. J. (1978). “Reliable Software through Compositc Design,’’ Van Nostrand Reinhold, New York. Mylopoulos, J. (1990). Object-orientation and knowledgc representation. Proc. IFIP-TC 2 Working Conference on Database Semantics: Object-Oriented Databases-Analysis, Design and Construction (R. Mcersman and w . Kent, Eds.), Windermere, UK. Mylopoulos, J., Bernstein, P., and Wong. H. (1980). A language facility for designing interactive, database-intensive applications. ACM Trans. Database Syst. 5(2), 185-207. Mylopoulos, J., Borgida, A., Jarkc, M., and Koubarakis, M. (1990). Telos: Representing knowledge about information systems. ACM Trans. Info. Syst. 8(4), 325-362. Nardyanaswamy, K., and Scacchi, W. (1987). Maintaining configurations of evolving software systems. I E E E Trans. Sofrware Eng. SE-13(3), 329-339. Ng. P. A,. et al., Eds. (1994). “Proceedings of the Third International Conference on Systems Integration,” Sao Paulo, Brazil, IEEE Comp. Soc. Press. Nierstrasz, 0. (1989). A survey of object-oriented concepts. In “Object-Oriented Concepts, Databases. and Applications” (W. Kim, and F. Lochovsky, Eds.), ACM Press, New York. Odell, J. (1994). Six different kinds of composition. J . Object-Oriented Programming 6(8), 10-15. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. CACM 15(12), 1053-1058. Peckham, J., and Maryanski, F. (1988). Semantic data models. ACM Compiiting Surveys 20(3), 153-189. Penedo, M. H.. and Stuckle. E. D. (1985). PMDB-A project master database for software cngineering environments. Proc. 9th Int. Conf. on Software Engineering, pp. 150-1 57. Perry, D. E. (1987). Software interconnection rnodcls. Proc. 9th IEEE Int. Conf. on Software Engineering, pp. 61-69, Montcrey, CA. Perry, D. E. (1989). The Inscape environment. Proc. I lth IEEE International Conference on Software Engineering, pp. 2-12, New York. Perry. D. E., and Kaiser, G. E. (1991). Models of software development environments. I E E E Trans. Software E n g 17(3), 283-295. Pitrik. R. (1988). “Strukturierung in Software-, Datenbank- und Wissensbasierten Systemen Entwurf einer Sprache zur Strukturspezifikation,” Ph.D. Thesis, University of Vienna, Austria. Preschern, K. (1991). “Entwurf eines Modula-2-C Uebersetzers,” Masters Thesis, lnstitut fuer Informatik, Universitaet Klagenfurt. Pricto-Diaz, R.. and Neighbors, J. M. (1986). Module interconnection languages. J . Sysr. Software. 6, 307-334. Purdy, A,, Schuchardt, B., and Maier, D. (1987). Integrating an object server with other worlds. ACM Trans. O f i c e Info. Syst. 5( l), 27-47. Purtilo, J. (1994). The POLYLITH software bus. ACM Trans. Programming Languages Syst. 16(1), 151-174. Ramamoorthy, C. V., Usuda. Y., Prakash, A,, and Tsai, W. T. (1990). The evolution support environment system. I E E E Trans. Software Eng. SE-16(12), 1125-1234. Reiser, M. (1991). “The Oberon System; User Manual and Programmer’s Guide,” AddisonWesley, Reading, MA.
138
R. MOTSCHNIG-PITRIK AND R. T. MITTERMEIR
Rice, M. D., and Seidman, S. B. (1994). A formal model for module interconnection languages. IEEE Trans. Software Eng. ZO(1). 88-101. Ross, D. T. (1977). Structured analysis (SA): A language for communicating ideas. IEEE Trans. Software Eng. SE-3(1), 15-39. Rossak, W. (1989). “Ein Konzept zur anwendungsunabhangigen Ablage und Suche von Software in einem Modularchiv,” Ph.D. Thesis, University Klagenfurt, Dept. of Computer Science. Rossak, W., and Ng, P. A. (1991). Some thoughts on systems integration: A conceptual framework. Int. J. Syst. Integration 1(1), 97-1 14. Rumbaugh, J. (1994). Building boxes: Composite objects. J . Object-Oriented Programming 7(7), 12-22. Rumbaugh, J., Blaha. M., Premerlani, W.. Eddy. F., and Lorensen. W. (1991). “ObjectOriented Modeling and Design,” Prentice Hall, Englewood Cliffs, NJ. Scacchi, W. (1986). A software engineering environment for the system factory. Proc. 19th Hawaii Int. Conf. Syst. Sciencc and Software, Vol. 2. pp. 822-829. Schepers, J . (1994). SIGMA: A generic scheme for systems integration. Proc. 3rd International Conference on Systems Integration. Vol. 1, pp. 584-593, Sao Paulo. Brazil, IEEE Comp. SOC.Press. Scholl. M., Laasch, C., and Tresch, M. (1990). Views in object-oriented databases. Proc. 2nd Workshop on Foundations of Models and Languages for Data and Objects, Aigen. Austria. Sciore, E. (1991). Multidimensional versioning for object-oriented databases. Proc. DOOD ’91, Lecture Notes in Computer Science, No. 566, pp. 355-370. Springer-Verlag. Berlin. Shaw, M. (1995). Architectural issues in software reuse: It’s not just the functionality, it’s the packaging. Proc. ACM SigSoft Symp. Software Reusability, SSR ’95. pp. 3-6, ACM Press. Shaw, M., and Garlan, D. (1995). “Software Architecture: Perspectives on an Emerging Discipline,” Prentice Hall, Englcwood Cliffs. NJ. Shilling, J . J., and Sweeney, P. F. (1989). Three steps to views: Extending the object-oriented paradigm. OOPSLA ’89 Proc. pp. 353-360. Smith, J. M., Fox. S., and Landers, T. (1983). “ADAPLEX: Rationale and Reference Manual,” 2nd ed., Computer Corporation of America, Cambridge, MA. Smith, J. M., and Smith, D. C. P. (1977). Database abstractions: Aggregation and gcneralization. ACM Trans. Database Syst.. 2(2), 105-133. Snyder. A. (1986a). ComonObjects: An overview. A C M SICPLAN Notices, 21(10), 19-28. Snyder, A. (1986b). Encapsulation and inheritance in object-oriented programming languages. Proc. OOPSLA ’86, SICPLAN Notices Zl(11). Stay, J. F. (1976). H I P 0 and integrated program design. IBM Syst. J . No. 2, 143-154. Stefik, M., and Bobrow, D. G. (1986). Object-oriented programming: Themes and variations. The A I Magazine 6(4). 40-62. Stein, L. A., Liebermann, H.. and Ungar, D. (1989). A shared view of sharing: The treaty of Orlando. In Kim and Lochovsky (1989). Stevens, W. P., Myers, G. J.. and Constantine, L. L. (1974). Structured design. ISM Syst. J . 13(2), 115-139. Storey, V. C. (1993). Understanding semantic relationships. Very Large Data Bases J. 2(4). 455-488. Stroustrup, B. (1986). “The C + + Programming Language,” Addison Wesley, Reading, MA. Thomas, J . W. (1976). “Module interconnection in programming systems supporting abstraction,” Ph.D. Thesis, Brown Univcrsity. Tichy, W. F. (1979). Software development control based on module interconnection. Proc. 4th Int. Conf. on Software Engineering, pp. 29-41.
INTERCONNECTION OF SOFTWARE COMPONENTS
139
Tichy, W. F. (1 986). Smart recompilation. ACM Trans. Programming Languages Syst. 8(3), 273-291. Tichy, W. R., Habermann, N.. and Prechelt, L. (1993). Future directions in software engineering-Summary of the Dagstuhl Workshop. Software Eng. Notes 18(1), 35-48. Tomlinson, C., and Scheevel, M. (1989). Concurrent object-oriented programming languages. In Kim and Lochovsky (1989). Ullman, J. D. (1983). “Principles of Database Systems,’’ 2nd ed., Computer Science Press, Rockville, MD. Ungar, D., and Smith, R. B. (1987). Self: The power of simplicity. Proc. 2nd ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, SIGPLAN Notices, 22(10), 227-242. Vinek, G . , Rennert, P. F., and Tjoa, A. M. (1982). “Datenmodellierung: Theorie und Praxis des Datenbankentwurfs,” Physica-Verlag. Wand. Y., and Weber, R. (1991). A unified model of software and data decomposition. Proc. Eleventh Annual International Conference on Information Systems, Copenhagen. Wasserman, A. I., Pircher, P. A,, and Muller, R. J. (1990). The object-oriented structured design notation for software design representation. I E E E Computer, pp. 50-63. Waterman, D. A., and Hayes-Roth F., Eds. (1978). “Pattern-Directed Inference Systems,” Academic Press, San Diego. Wegner, P. (1987). Dimensions of object-bascd language design. Proc. OOPSLA ’87, pp. 168-182, ACM. Wegner, P. (1990). Concepts and paradigms of object oriented programming. OOPS Messenger 1(1), 7-87. Wirth, N. (1982). “Programming in Modula-2,” Springer-Verlag, Berlin. Wirth, N., and Hoare, C. A. R. (1966). A contribution to the development of ALGOL. CACM 6. Wolf, A. L., Clarke, L. A,, and Wileden, J. C. (1Y85). Ada-based support for programming in-the-large. l E E E Software, 58-71. Wolf, A. L., Clarke, L. A., Wildeden, J. C. (1988). A model of visibility control. IEEE Trans. Software Eng. SE-14(4), 512-520. Wolf. A. L., Clarke, L. A,, and Wileden, J. C. (1989). The AdaPIC tool set: Supporting interface control and analysis throughout the software development process. IEEE Trans. Software Eng. SE-15(3), 250-263. Yau, S. S., and Tsai, J. J. (1987). Knowledge representation of software component interconnection information for large-scale software modifications. IEEE Trans. Software Eng. SE13(3), 355-361. Yeh, R. T., Schlemrner, R. A,, and Mittermeir. R. T. (1991). A systemic approach to process modelling. Int. J. Syst. Integration 1(2), 265-282. Yourdon, E., and Constantine, L. L. (1979). “Structured Design-Fundamentals of a Discipline of Computer Program and Systems Design,” Prentice Hall, Englewood Cliffs, NJ. Yu, E., Du Bois, P., DuBoui, E., and Mylopoulos, J. (1995). From organization models to system requirements: A cooperative agents’ approach. Proc. 3rd International Conference on Cooperative Information Systems, Vienna, May 1995. Zand, M. K., Saiedian, H., George, K. M., and Samadzadeh, M. H. (1993). An interconnection language for reuse at the template module level. J . Syst. Software 23, 9-26.
This Page Intentionally Left Blank
Using Model Checking to Analyze Requirements and Designs JOANNE ATLEE Department of Computer Science University of Waterloo Waterloo, Ontario, Canada
MARSHA CHECHIK AND JOHN GANNON Department of Computer Science University of Maryland College Park, Maryland
Abstract Precise notations have been developed to specify unambiguous requirements and ensure that all cases of appropriate system behavior are considered and documented. Using one such notation, we have developed techniques to analyze software artifacts automatically at early stages of the software development life cycle. We use model checking as our verification technique because it can be fully automated and can check properties of large systems. This paper describes model checking and summarizes our efforts to use it to analyze software requirements and designs. Wc prove that requirements model system safety properties and that designs model consistency properties derived from requirements by creating abstractions of these software artifacts and using model checking to determine if the abstractions are models of the properties. We present results from a case study in which we analyzed the requirements and design of a small but realistic system.
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. SCR Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Behavioral Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Environmental Assumptions. . . . . . . . . . . . . . . . . . . . . . . 2.3 Systcm Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Model Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Model Checking Requirements. . . . . . . . . . . . . . . . . . . . . . . . 4.1 SCR Logic Model of Mode Transitions. . . . . . . . . . . . . . . . . . 4.2 Behavioral Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Environmental Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4.4 System Goals and Model Checking. . . . . . . . . . . . . . . . . . . . 5. Model Checking Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141 ADVANCES IN COMPUTERS, VOL. 43
142 143 144 146 146 147 151 152 153
154 155 156 156
Copyright 0 1996 by Academic Press, Inc. All rights of reproducuon in any form reserved.
142
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
5.2 Design Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Creating an Abstraction, . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Verifying Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 The Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Design Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
159 160 163 168 168 171 174 176 177
1. Introduction Precise documentation of software requirements has several potential benefits [27]: Designers know what they are to build; reviewers can check that customers’ intentions are met; testers can formulate test cases independently from the system’s implementation; and maintainers can use the original requirements to learn about the system before making their changes. Several formal requirements notations (e.g., the Software Cost Reduction (SCR) notation [2, 20, 221, the Requirements State Machine Language [24], and Statecharts [18] have been used to specify the requirements of large, real-world avionics applications (the A-7E aircraft, the FAA’s Traffic Collision and Avoidance System, and the Lavi fighter’s avionics system, respectively). These requirements notations describe systems as sets of concurrently executing state machines that respond to events in their environments. The keys to winning acceptance for employing precise documentation during system development include demonstrating that its use improves software quality, amortizing the cost of its creation across several different analysis activities, and reducing the cost of analysis through automation. Our research has focused on developing techniques that use formal methods to enable automatic analysis of program artifacts at early stages of the software development life cycle [4, 6, 28, 5, 10, 111. In this article, we summarize our work to analyze program requirements and designs. We use model checking [14] because it can be fully automated and can check properties of large systems. Developers are more likely to understand a proof technique like model checking, which is based on search and which produces counterexamples when proofs fail, than a technique based on inductive theorem proving. Model checking has been successfully applied to verifying and debugging hardware designs (e.g., [8, 7, 131). More recently it has been used to analyze software artifacts. Model checking has been used to detect design flaws in software architecture designs [l] and Z specifications [23], and to prove properties of cache coherence protocols [30] and concurrent Ada programs [9]. The key to success in these endeavors
MODEL CHECKING
143
is creating an appropriate abstraction of a system so that results obtained from analyzing the abstraction also apply to the system. We analyze safety properties of software requirements and designs by creating models from such artifacts and using model checking techniques to determine if the safety properties are true for the model. We have developed automated techniques to translate SCR requirements into a logical model. We represent a system’s safety assertions as logical formulas in a branching-time temporal logic, Computation Tree Logic (CTL) [15], and use existing CTL model checkers [8, 251 to check our models. Analyzing the safety properties of system’s requirements, however, fails to tell us whether its implementation preserves these properties. To verify that a system design is consistent with its requirements, we would like to ensure that the design’s state transitions are enabled by the same events as those of the requirements, and the requirement’s safety properties also hold in the design. To judge global properties like these, we need to determine the possible system states that exist at different program points. The detailed bookkeeping necessary to do this exceeds the capabilities of human reviewers for all but small implementations. We present a language for specifying detailed designs and an analysis technique to create a model of a design through abstract interpretation of the language constructs. We also show how to use requirements information to generate properties automatically, which ensure that required state transitions appear in the design and systems goals hold, and how these properties are checked against the design model. The rest of the article is organized as follows. Section 2 introduces the requirements specification format. Section 3 explains basic principles behind model checking. In Section 4, we show how to create a logic-model semantics that precisely models the operational semantics of SCR modes and mode transitions, so that system goals can be translated into temporal logic formulas and model checking techniques used to verify that these formulas hold in the requirements. Section 5 presents our techniques for verifying designs: how to generate temporal logic properties from SCR tables, how to build finite-state abstractions of designs, and how to model check the properties using a special-purpose model checker. Section 6 describes a case study in which we analyzed the requirements and design of a waterlevel monitoring system [29]. We present our conclusions in Section 7.
2. SCR Requirements The SCR requirements notation was developed by a research group at the Naval Research Laboratory as part of the Software Cost Reduction
144
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
project [2,22]. A complete SCR requirements specification contains behavioral, functional, precision, and timing requirements of a software system as well as assumptions about the environment in which the system will operate. In this section, we describe SCR behavioral requirements and environmental assumptions, and the system goals they are meant to ensure.
2.1
Behavioral Requirements
An SCR requirements specification models a system as a set of eventdriven, state-transition machines. The machine’s environment is abstracted as a set of monitored state variables and controlled state variables [26, 291. Changes to monitored variables may cause the system t o change its mode o r to alter the values of its controlled variables. The input language of each machine is a set of conditioned events. A condition is a predicate on monitored or mode class variables: an event occurs when the value of a condition changes. Let condition SwitchOn represent predicate [On/Off switch = On], and condition PumpFail represent predicate [Pump failure = true]. Primitive events @T(SwitchOn) and @F(SwitchOn) represent condition SwitchOn becoming true and becoming false, respectively. Conditioned event @T(SwitchOn) WHEN [-PumpFail] describes the event SwitchOn becomes true while PumpFail remains false. Formally, conditioned event @T(SwitchOn) WHEN [PumpFail] occurs at time f if and only if primitive event @T(SwitchOn) occurs at time t and condition PumpFail is true for some nonzero interval of time leading up to and including time t [2]. SwitchOn is called the triggering event and PumpFail is called the event’s WHEN condition. A state of the monitored environment is defined by the current values of the conditions, and the state space is the set of possible combinations of values of conditions. However, the behavior of the system is rarely affected by the values of all the conditions at once. A mode class defines a set of states, called modes, that partition the monitored environment’s state space. One mode is designated as the initial mode. Assumptions about the initial state of the environment are specified with the initial mode. Transitions between pairs of modes are activated by conditioned events. If a conditioned event can trigger two or more transitions from the same mode, then the mode class is nondeterministic. An SCR requirements document contains the specification of one or more mode classes. At all times, the system is in exactly one mode of each mode class. Each mode class specifies one aspect of the system’s behavior,
145
MODEL CHECKING
and the system’s global behavior is defined to be the composition of the specification’s mode classes. Table I shows a mode transition table for a simplified water-level monitoring system (SWLMS). A switch controls whether the system is on or off. If the system is on and its sensors detect too much (too little) water, a pump is turned on for a fixed period to remove (add) some water. If the sensor or the pump fails, the system enters an error state. This simplified version of the system has no error recovery, so there are no transitions from the error state. This system has one mode class (MC) with modes Off, Operating, and Error; four monitored variables, Switchon, PumpFail, TooHigh, and TooLow; and a single controlled variable, PumpOn. Below the mode transition table is the specification of the system’s initial mode. Mode class MC starts in mode Off, and all monitored variables are initially false. The specification of a mode class’s transition relation has a tabular format. Each row in the table specifies a conditioned event that activates a transition from the mode on the left to the mode on the right. For example, a table entry of “@T” (or “@F”)under a column represents a triggering event for the condition represented by the variable labeling the column, a table entry of “t” (or “f”) represents a WHEN condition for the condition. If the value of a condition does not affect the occurrence of a conditioned event, then the table entry is marked with a dash (“-”). If during time interval [t - E , t ) the system is in mode Off, the switch is in the Off position and the pump is operating; and if at time t the switch is moved to the On position while the pump continues to operate; then the system is in mode Operating at time t. Values of controlled variables change in response to events when the system is in particular modes. Table I1 shows an event table for the controlled variable PumpOn, which represents the pump being turned on or off. This variable starts with value false and becomes true when the system is in mode Operating and either event @T(TooHigh) or @T(TooLow)occurs. TABLE 1 MODETRANSITION TABLE FOR SWLMS ~
Current Mode SwitchOn PumpFail New Mode Off
@T -
Operating
@F -
f
@T f @T
Operating error Off error
Initial: Off (-Switchon & -PurnpFail & -TooHigh & -TooLow) Assumptions: TooLow- >>-TooHigh
146
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
TABI E 11 EVENr
TABLE FOR
Mode
PUMPON
Triggering Event
Operating
Off PumpOn
CONTROLLED VARIABLE
=
@T(TooHigh) @T(TooLow) True
-
@F(TooHigh) @F(TooLow) @T(PumpFail) @T(PumpFail) False
Initial: False
2.2
Envi ro nme nta I Assumptions
An SCR requirements document also specifies assumptions of the behavior of the environment. Similar to the NA Trelation in Parnas’s four-variable model of system requirements [26], an assumption specifies constraints on the values of conditions, imposed either by laws of nature or by other mode classes in the system. As such, assumptions are invariant constraints that must hold in all system states. The syntax and semantics of assumption specifications are described in [ 3 ] ; for the purposes of this article, symbol ‘‘I” denotes exclusive-or, “ - >” denotes implication, “ - > >” denotes strict implication, and “<” denotes an ordering on the lengths of time that conditions are true.’ The assumption specified in Table 1 states that the water level cannot be too high and too low at the same time.
2.3 System Goals Finally, an SCR requirements specification often includes a set of goals that the system is required to meet. These goals are not additional constraints on the required behavior; it is expected that the SCR tabular specification enforces these goals. Specified goals are redundant information and are included in the specification because the reader might not deduce these properties from the tabular specifications. Most of the goals specified in the SWLMS example are mode invariants:
’
In a - >> 6 the state space in which a is true is a strict subset of the state space in which b is true. As with implication, whenever a is true, 6 must also be true. Because of the relationship between their state spaces, 6 must be true whenever a is changing value, and a must be false whenever b changes value.
147
MODEL CHECKING
If the system is in mode Off, then conditions SwitchOn and PumpFail are false.
Other goals express global behavioral requirements on the occurrence of an event: 0
I f event @T(SwitchOn) occurs, the system cannot remain in mode Off.
Temporal requirements on state changes can also be specified. 0
When the water level becomes too high while the system is in mode Operating, the pump will immediately be turned on.
3. Model Checking Temporal logic permits us to make statements about changes in time, for example, that a formula may be true at some point in the future. Computational tree logic (CTL) is a propositional branching time logic, whose operators permit explicit quantification over all possible futures [15]. The syntax for CTL formulas is summarized here: 1. Every atomic proposition is a CTL formula. 2. If f and g are CTL formulas, then so are J f E X f , AlfUgl, ElfUg1,AF.L E F f , A G f , EGF
-
A
g,
f V g, A X J
Note that temporal operators occur only in pairs in which a quantifier A (always) or E (exists) is followed by F (future), G (global), U (until), or X (next). The value of a formula is defined with respect to a model M = (V, S, so, R, Z ) where V is a set of propositional variables, S is a set of states, so E S is the start state, R is a transition relation, and Zis a set of interpretations specifying which propositions are true in each state. Temporal logic formulas are evaluated with respect to a state in the model. For example, formula E X f ( A X f ) is true in state s, if formula f is true in some (every) successor state of s,. Formula Elf U g] (Alf U g ] ) is true in state s, if along some (every) path emanating from s, there exists a future state s, at which g holds and f is true until state s, is reached. EF f ( A F f ) is true in state si if along some (every) path from s,there exists a future state in whichfholds. Finally, EG f (AG f ) is true in state s, iff holds in every state along some (every) path emanating from s,. We capture these ideas more formally with the following definitions. If formula f is true in state s of model M, we write M , s & A formula f is true for the model, if it is true in the model’s start state, that is,
148
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
M , so /= f: When we are concerned with a single model, we abbreviate M , s f a s s k f: Let p E V be a proposition, s E S be a state, and f be a formula. s I= P t= -f
iff iff iff iff iff iff
(Z(S))(P)
s f s k f m sI=forskg so EX f for some s; along some path (SO, sl, . . .), si f so /= A X f for all s; along some paths (so, sl,. . .), si /=f so E ( f U g ) for some s; along some path (so, sl, . . .), s; g and for all j < i, si k f so A(f U g ) iff for all si along all paths (so, sl, . . .), si /= g and for all j < i, sj f. s
+
Several abbreviations will also be used to write formulas. These include abbreviations for propositional formulas, abbreviations for commonly used until operations (e.g., reachability and invariance), and universally quantified temporal formulas (defined in terms of existentially quantified temporal formulas).
( f A 8 ) = -(-f v -gz ( f g ) = (-fv d +
AXf -EX(-f) EF f = E[true U f ] A F f = A[true U f ] EG f = -AF(-f) A G f -EF(-f).
The abbreviation for invariance, AG, is used often in this article. A G f is true in state si if for all paths (s;, s;+~, . . .), formula f holds in all states. Model checking evaluates a formulaffor a particular model M by computing the set of states in which the formula is true: {s I M , s k f } .For example, formula EF f represents the set of states from which a state satisfyingfcan be reached in some number of state transitions:
f V EXf V E X ( E X f ) V . . ., where f is the set of states from which an f state can be reached in zero state transitions, E X f is the set of states from which an f state can be reached in one state transition, E X ( E X f ) is the set of states from which an fstate can be reached in two state transitions, etc. This set of states can be computed using the following least fixed-point definition:
149
MODEL CHECKING
EFf
=
p.Y ( f v E X Y )
starting with false as the value for Y . By way of example, consider checking so E F ( - a A -b) for model M in Fig. 1.1. The first iteration computes the set of states in which the formula ( - a A -6) holds, {sj}. This set, which is shaded in Fig. 1.2, corresponds to computing ( - a A -b) v E X false. During the second iteration, s2 is added to the set because the formula is true in its successor, s3.A t this point, we have computed the set of states satisfying ( - a A -b) v E X ( - a A -b). The third iteration adds so and sl to the set since each state has a successor that is already a member of the set. Thus far we have computed ( - a A -b) V E X ( ( - a A 4 )v E X ( - a A 4)). Since no new states are added during the fourth iteration, we reach a fixed point and the algorithm terminates. Automating model checking is quite easy, except that the entire state space of the model must be constructed before the fixed-point algorithms can be applied. Model checking can be performed symbolically by manipu-
1. Model
2. (-a A -b) V EX (false)
n
3. (-a A -b) V E X (-a A -b) 4. (-a A -b) V E X ((-a A -b) V E X (-a A -b)) FIG. 1. Model checking so EF(-aA - b ) .
150
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
lating quantified boolean formulas without constructing a model’s state space [25].To perform symbolic model checking, sets of states and transition relations are represented by formulas, and set operations are defined in terms of formula manipulations. As before, a system state represents an interpretation (i.e., truth assignment) for a set of propositional variables V. Formulas represent sets of states that satisfy the formula. For example, in Fig. 1.1 the formula a represents the set of states in which a is true ({so, s,}), the formula b represents the set of states in which b is true ({sl, sZ}), and the formula a V b represents the union of these sets ({s,), sl, sz}). State transitions are described by relations over two sets of variables, V and V‘.The variables in V represent values in a transition’s source state, while those in V’ represent values in the destination state. For example, the transition from s2 to s3 in Fig. 1.1 is described by the formula (-a A bA - a ‘ A -b’). This describes a transition from a state containing {-a, b} to another state containing {-a, -b}. The formula ( a A b’) describes the transitions from so to sI and s2, and from s1 to s2 and to itself. The formula describing the transition relation R for Fig. 1.1 is (U
A b’) V (-a A bA -u’ A -b’).
The meaning for CTL formulas can be redefined in terms of sets of states: s
s
kp
t=-f
st=fVg s k EX f s
s s
I=
AXf E(fUg) A(fUg)
iff iff iff iff iff iff iff
s E p wherep E V
s E -p sE(fVg) s E (3V‘(RA f ( V / V ’ ) ) ) s E- ( 3 V ’ ( R A-f(V/V’))) s E P y ( g v ( f A EX Y ) ) s E pY(g v ( f A AXY)).
A CTL formula f is evaluated for a model by deriving a propositional logic expression that describes the set of states satisfying the CTL formula for the model. The model checker verifies that the interpretation of the model’s initial state so satisfies the expression. For example, we check so EX(-aA 4 ) by computing a propositional logic formula representing the states that have successors where (-aA -b) is true. For this, we use the formula 3u’, b’(R A (f(a, Mu’, b’))),where R represents the transition relation, f is the formula being checked ( - a A -b), and f(a, b/u’, b‘) represents substitutions of a’ and b’ for corresponding free occurrences of a and b in f (effectively changing f to be a formula about the next states’
151
MODEL CHECKING
truth assignments, - a ‘ A -b’). In doing the evaluation, we replace formulas of the form 3 v ( f ) by (f(v/true) v f(v/’alse)): E X ( - ~ A-b) =
- - - - -
3a’, b’( ( ( a A b’) V ( a A bA
a’A
3a’,b’(((aAb’)V(-aAbA-a’A
b‘)) A (( aA b)( a , b/a‘, b’))) = -b’))A(-a’A-b‘)) =
3a’,b’((aAb’A-a’A~b‘)V(-aAbA-a’A-b’h-~’A-b’))
=
- -- -- - - -
3a’, b’((false) V ( - a A bA - a ’ A -b’)) = 3a’, b’( a A bA a’A b’) = 3a’((-a A b A a‘A true) V ( a A bA a’A f a l s e ) ) = % ’ ( - a A bA -a’) = ( - a A bA - t r u e ) V ( - a A bA - f a l s e ) = - a A b
The computed propositional logic formula represents the set of states whose interpretations satisfy EX(-aA -b) is true, that is, {s2}.EX(-aA -b) is a theorem (i.e., so EX(-a A -b)) if the values of a and b in so (a=true and b=false) satisfy --a A b, but this is not the case. In the following example, we calculate EF(-aA -b) for the model in Fig. 1.1: 1.
(-uA
2.
(-aA-b)VEX(-aA-b)=(-aA-b)V(-aAb)=
3.
-b) V E X ( - a ) = ( - a A -b) V 3a’,b’(((a A b‘) V ( - a (-aA b) V 3a‘, b’(((a A b’) V ( - a
-b)
V
E X f a l s e = ( W a A -b)
-
4.
-a
(-aA
bA -a‘A -b’)) A ( ( - a ) ( a / a ‘ ) ) )= bA - a ’ A -b’))A - a ’ ) = (-aA-b)V3a’,b‘((aAb’A-a’)V(-aAbA-~’A-b’)) = ( - a A - b ) V 3 a ’ ( ( ( a A trueA - a ‘ ) V (-a A bA - a ‘ A - t r u e ) ) V((aAfalseA -a’)V(-aAbA ~ ~ ‘ A - f a f s e ) ) )= ( - a A W b ) V 3 d ( ( a A -a’) V ( - a A bA - a ’ ) ) = ( - a / \ -a) V ( ( a A - t r u e ) V ( - a A bA - t r u e ) ) V ( ( u A - f a l s e ) V ( - a A b A - f a l s e ) ) = ( - a A -b) V ( ( f a l s e ) V (false))V ( ( a )V ( - a A b ) ) = ( - a A -b) V ( - a A b ) V a = true ( - u A -b) V E X ( t r u e ) = true A
A
Note that the formulas at the end of each step correspond to the set of states that is shaded after that step. The first formula ( - a A -b) corresponds to {s3}, the second (-a) to {sz, s3}, and true to the set of all states.
4.
Model Checking Requirements
In this section, we define a logic-model semantics for SCR specifications that precisely models the operational semantics of SCR modes and mode
152
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
transitions. System goals are translated into temporal logic formulas, and model checking is used to determine whether the requirements are a model of each of the formulas.
4.1
SCR Logic Model of Mode Transitions
System modes and environmental conditions are represented by temporal propositional variables. A propositional variable representing a condition is true if and only if the condition is true. Similarly, a propositional variable representing a mode is true if and only if the mode is the current mode of its mode class. An interpretation maps propositional variables to truth values. Because the values of conditions and current modes vary over time, the logic model consists of a sel of interpretations and a transition relation among the interpretations. Formally, a logic model of an SCR mode class is a tuple (V, S, so, R, I ) , where 0
0 0
0
V is the set of modes and conditions. S is the set of possible states. so C S is the set of possible initial states R C ( S X S ) is a binary transition relation on S. I is an interpretation function. I(s) assigns a truth value to each mode and condition in state s.
A conditioned event is modeled by any pair of states s, and s, related by R [i.e., (s, s,) E R ] ,in which the event’s triggering conditions are unsatisfied in state s,, the triggering conditions are satisfied in state s,, and the event’s WHEN conditions are satisfied in both states. If the conditioned event triggers a mode transition, then the pair of states must also model the mode change: in state s,, the source mode must be true and the destination mode false; and in state s, the source mode must be false and the destination mode true. Our logic-model representation of an SCR requirements specification deviates from its operational semantics in two respects. First, SCR operational semantics forbids the simultaneous occurrence of two or more primitive events, because its operational model assumes that the implemented system will react to events one at a time, regardless of when the events occur. Traditionally, implementations of reactive systems queue primitive events as their occurrences are detected; when a primitive event reaches the head of the queue, the system checks the values of other conditions to determine if a significant conditioned event (e.g., one that might activate a mode transition) has occurred [19].
MODEL CHECKING
153
An unconditional restriction on the occurrence of simultaneous events may violate environmental assumptions. Rather than incorporating a restriction on simultaneous events into the semantics of an SCR logic model, we express the restriction as an environmental assumption of the specification. This arrangement allows us to specify and analyze a system that does not assume that events will be reported sequentially. In addition, it allows the specification of tailored restrictions that model both the sequential occurrence of independent events and the simultaneous occurrence of related events. The second difference between operational and logic-model semantics of SCR specifications pertains to the value of WHEN conditions at the time of a conditioned event. In an SCR logic model, WHEN conditions must be satisfied both immediately before and during the occurrence of a conditioned event. According to the latest operational semantics of SCR, a W H E N condition must be satisfied immediately before the occurrence of a conditioned event, but its value at the time of the event is unknown [21]. Given the preceding restriction on the occurrence of simultaneous events, one can infer the value of most WHEN conditions: WHEN conditions that are unrelated to the triggering event have the same value during the event as they had immediately before the event. However, WHEN conditions that are related to the triggering event may or may not be changing value along with the triggering event. We chose to model the older conditioned-event semantics [2] because we found it easier to write a correct SCR specification given these semantics. If one wants to write a specification that guarantees a particular formula f i s always true in a particular mode M , one needs to specify that fis always true upon entry into M and that the system always exists mode M i f f becomes false. Such a specification is difficult (if not impossible) to write if one cannot infer from a WHEN condition WHEN^^] on a transition into the mode that f is true when the mode is entered.
4.2
Behavioral Requirements
We express the logic model of SCR mode transition requirements as a temporal logic formula. A logic-model state is expressed as a conjunction of the conditions and modes interpreted to be true in that state. The transition relation R is expressed as a formula over conditions and modes in both the current and the next state. Consider the SCR mode transition table presented in Table I. The following formula specifies the logic formula that holds in the initial state so. Since only mode transitions are being modeled, we have simplified the initial state to include only those monitored variables that affect mode transitions.
154
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
so+ (Off A
- SwitchOn A - PumpFail).
Each row in the mode transition table is expressed as a conjunction of the current mode, the conditioned event, and the next mode. For example, the first row in the mode transition table is represented by the following formula: Off A -Switchon A -PumpFail A Switchon’ A -PumpFail ’ A Operating’, where unprimed and primed versions of a variable indicate the value of this variable in the current and the next states, respectively. Each row in a mode transition table specifies an element in the logic model’s transition relation. The set of mode transitions is expressed as a disjunction of the transitions’ formulas. Finally, the table also states implicitly that if a conditioned event occurs that does not trigger any of the transitions leaving the current mode, then the current mode remains the same. To capture this latter behavior, we add a new transition for each mode. The new transition states that the mode is true in the current state, all of the conditioned events triggering transitions leaving the mode are false in the next state, and the mode remains true in the next state. The resultant transition relation is a tautology; thus, an SCR logic model has a total transition relation. Figure 2 shows a partial logic model for the SCR mode transitions of the SWLMS specified in Table I. If an SCR specification consists of several mode classes, then the logic model of the specification is a conjunction of the logic models of the mode classes. so
-+
(Off
A
SwitchOn A
N
N
PumpFail)
A (
(Off A
N
SwitchOn A
(Off A
N
PumpFail
(Off A
N
A
N
PumpFail‘ A Error’)
(- SwitchOn A N
(w
PumpFail A Switchon’ A
N
(OperatingA (Operating A N
N
-
PumpFail A Switchon’ A
N
PumpFail A
N
(Switchon A A
N
PumpFail A
v
N
PumpFail’) A
V
SwitchOn’ A
PumpFail A PumpFail’ A Error’)
(- PumpFail
PumpFail’ A Operating’)
v
PumpFail A PumpFail’) A Off’)
(Operating A SwitchOn A
N
N
N
PumpFail‘ A Off’)
v
v
Switchon’ A
PumpFail’) A Operating’)
N
PumpFail’) A
v
(Error A Error‘)
FIG. 2. SCR logic model of SWLMS mode transition table.
1
155
MODEL CHECKING
4.3
Environmental Assumptions
The formula in Fig. 2 represents the unconstrained transition relation of the SWLMS. For example, the formula expresses no constraints on the number of modes that can be true in any logic-model state. Furthermore, the SCR specification’s environmental assumptions are not represented in the logic model. Environmental assumptions can be represented as logic formulas: (Off V Operating V Error) A (Off + (- Operating A (Operating + (- Off A Error)) A (Error -+ (- Off A Operating)) A (Too Low +- TooHigh).
-
- Error)) A
Because the environmental assumptions hold invariantly and constrain the specification’s transition relation, each of the assumptions’ representative formulas is conjoined with the formula representing the mode transition table.
4.4
System Goals and Model Checking
Most of the SWLMS system’s goals can be easily expressed as CTL formulas and proved using the SMV model checker [25].The following formulas state properties that hold invariantly when the system is in a particular mode. For example, if the system is in mode Operating, it is invariantly true that the switch is on and the pump is working. AG(0ff + (-SwitchOnA -PumpFail)) AG(0perating + (SwitchOnA -PumpFail)) AG(Error -+PumpFail). The last formula is false, and the SMV checker produces a counterexample in which the system remains in mode Error while PumpFail changes value from true to false. We could rewrite the last formula as AG(PumpFai1 -+ Error), which can be verified. The following goal of the SWLMS example is more difficult to express as a CTL formula because it refers to the occurrence of a conditioned event: 0
I f event @T(SwitchOn) occurs, the system cannot remain in mode Off.
Since conditioned events are represented by consecutive logic-model states, a CTL formula referring to the occurrence of a conditioned event must refer to the values of the event’s conditions in two states.
156
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
AC(-SwitchOn
t
-EX(SwitchOn A Off)).
If SwitchOn is false, there is n o next state in which SwitchIsOn is becoming true and mode Off is true. To ease the phrasing of CTL formulas that refer to the occurrence of conditioned events, we use unary logic connectives @Tand @Fto express propositional formulas that are becoming true and becoming false, respectively. We could simulate the new connectives using their definitions: evaluation of their operands in the current and next states. SMV, however, can only check formulas with respect to the current values of variables. Therefore, the SMV behavioral requirements must evaluate events using the current and next values of their operands. Let f b e an arbitrary propositional CTL formula (i.e., a CTL formula with n o modal operators). The connectives have the following definitions: @T(f) iff - f A f ' @F(f) iff fA f ' .
-
The preceding invariant is more simply expressed when formulated using the new connectives. A G((@T(SwitchOn) + --EX(Off))).
5.
Model Checking Designs
Once we verify that system goals hold in a set of requirements, we are interested in showing that these and other properties are preserved in a design (and further in an implementation) of the system. The rest of this section presents a technique for discovering instances of inconsistency and incompleteness in detailed designs of programs with respect to their requirements.
5.1 Consistency We say that a detailed design is consistent with its requirements if it accomplishes the following: 1. Implements all state transitions specified in the requirements. 2. Does not implement any state transitions which are not specified in the requirements. 3. Satisfies all assumptions and system goals. A requirements specification can be translated into a list of properties that capture this notion of consistency. To prove that a design is consistent
157
MODEL CHECKING
-a, b
a, b, M I
M2
FIG.3. Behavioral model of a mode transition.
with its requirements, we demonstrate that the design is a model of all these properties. To facilitate that, we have to make some changes to the original SCR semantics. First, no program can implement mode transitions that occur instantaneously with event detections. Instead, event detections and mode transitions usually occur in different statements. We modify the SCR semantics discussed in Section 2 accordingly. For example, a behavioral model of a transition between modes M1 and M 2 triggered by a conditioned event @T(a) WHEN [ b ] ,is as shown in Fig. 3. We capture the meaning of this transition in a formula a A a’ A b A h’ A M1’ A M2”, where the unprimed version of condition a denotes a in the current state, the primed version denotes a in the next state, and the double-primed version denotes a in the next next state. Second, the notion of “next state” used in the requirements indicates either all or some next states. Since we are interested in generating properties that can be captured in a real program, we want to make a clear distinction between all and some next states by using CTL operators EX and AX.
-
5.1.1 Automatically-Generated Safety Properties Properties that an SWLMS design would have to satisfy appear in Figs. 4 and 5. Property Po is generated from environmental assumptions of the
-
-
Po = AG((0ff V Operating V Error) A (Off -+ Operating A Error)) A (Operating -+ ( w Off A Error)) A (Error + ( w Operating A Off)) (TooLow +- TooHigh)) P, = A G ( ( 0 f f V EX(0ff)) 4 (Off V (Operating & @F(SwitchOn) & ~ P u r n p F a i l ) ) ) ) Pz = AG( E X ( 0 p e r a t i n g ) + (Operating V (Off & @T(SwitchOn) & WPumpFail))) P3 = AG(EX(Error) + (Error V (Operating & @T(PumpFail)) V (Off & BT(PumpFai1)))) P4 = E F ( 0 f f & @T(SwitchOn) & NPumpFail & E X ( 0 p e r a t i n g ) ) Ps = E F ( 0 f f& @T(PumpFail) & EX(Error)) Ps = E F ( 0 p e r a t i n g & OF(Switch0n) & -PumpFail & E X ( 0 f f ) ) P, = E F ( 0 p e r a t i n g & @T(PumpFail) & EX(Error)) (W
N
FIG.4. Assumptions and properties for mode class.
A
158
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
Ps
= AG(wPump0n V EX(WPump0n)
P9
=
P ~ o= = PI* = P11
=
PIS = PIS =
-+ (-Pumpon V (QF(TooHigh) & Operating) V (QF(TooLow) & Operating) V (QT(PumpFai1) & Operating) V (QT(PumpFai1) & Off)))) A G ( E X ( P u m p 0 n ) -+ (PumpOn V (@T(TooHigh)& Operating) V (@T(TooLow)& Operating))) E F ( P u m p 0 n & QF(TooHigh) & Operating & E X ( N P u m p 0 n ) ) E F ( P u m p 0 n & @F(TooLow)& Operating & EX(-PumpOn)) E F ( P u m p 0 n & QT(PumpFai1) & Operating & EX(-PumpOn)) E F ( P u m p 0 n & QT(PumpFai1) & Off & E X ( w P u m p 0 n ) ) EF(WPump0n & QT(TooHigh) & Operating & E X ( P u m p 0 n ) ) EF(-PumpOn & @T(TooLow) & Operating & E X ( P u m p 0 n ) ) FIG.5. Properties for controlled variable PumpOn.
system and is used to check that these assumptions are preserved. We call this property “constraints are met” (CAM). Properties PI-P3 ensure that the only transitions to a mode are those specified in the requirements. Such properties are called “only legal transitions” (OLT). There is one property of this type generated for every requirements mode (of every mode class). Property P2 asserts that if the system will be in mode Operating in its next state, then it either must already be in that mode or the transition from Off on @F(SwitchOn) WHEN [-PumpFail] is occuring. P2 is obtained by composing the rows in the mode transition table of mode class MC that have Operating in their right columns. P I differs slightly from P2 since it captures the fact that MC starts in mode Off. Properties P4-P7 ensure that all transitions specified in the requirements appear in designs and are called “all legal transitions” (ALT) properties. P4 and P5 correspond to the two transitions leaving mode Off and are obtained by composing the rows of the MC mode transition table that have Off in their left columns. There is one ALT property for every row of every mode transition table specified in the requirements. Properties generated for the controlled variable PumpOn are shown in Fig. 5. P8 and P9 are OLT properties, which ensure that PumpOn changes value only as a result of specified events, and Plo-Pl5 are ALT properties, which ensure that all changes to PumpOn specified in the requirements appear in the design. There are two OLT properties generated for each controlled variable, reflecting changes of value to true and false, respectively, and one ALT property generated for each row of every table.
5.1.2 System Goals We use a shorthand notation for stating system goals. The following are the types of goals that can be specified and trivially translated into CTL formulas (P, P I , and P2 represent propositional logic formulas):
MODEL CHECKING
0
0
0
0
159
smi(M, P ) = A G ( - M v P ) (strong mode invariant) is satisfied if P holds in every state where the system is in mode M . wmi(M, P ) = A C ( ( - M V P ) V A X ( - M ) ) (weak mode invariant) is satisfied if P holds when the system is in mode M , but not while the system is exiting mode M . For example, wmi(Operating, Switchon) holds even though an event @F(SwitchOn) occurs when the system is in mode Operating, since the system leaves this mode in all of its next states.2 cause(P1, P2) = AG(-P, v ( P 2 v A X ( P 2 ) ) )is satisfied if whenever PI is true, either P2 is true or the next transition of the system will establish a state in which P2 holds. For example, the property cause(0perating & TooHigh, PumpOn) in SWLMS specifications indicates that as soon as the system reaches a state where it is in mode Operating and the water level is too high, the pump is immediately turned on in all next states. reach(P) = E F ( P ) is satisfied if the system can reach a state in which P holds. The reach properties are usually used to ensure that mode invariants are not satisfied vacuously.
These types of system goals frequently appear in requirements documents, and during our case studies we did not need to verify any other types of properties. Requirements specifications of realistic size and complexity (such as [2]), however, contain global properties that cannot be expressed using only these assertions. Allowing the user to specify a richer set of properties is relatively easy, although not every CTL-expressible formula can be verified during our analysis (see [12]).
5.2
Design Language
T o create a design, programmers use a mixture of control-flow constructs, comments and annotations-special statements that record mode transitions and changes to the values of controlled and monitored variables. These changes are local (rather than invariant) and therefore are relatively easy to specify. An Initial annotation indicates the starting state of each mode class. It unconditionally assigns values to variables. This annotation corresponds to initialization information specified in the requirements. An The CTL translations clearly identify the difference between smi and wmi properties. Property smi(M, P ) means that for every state of the system P holds whenever the system is in mode M . In contrast, property wrni(M, P ) means that P holds only in those states where the system is in mode M and remains in M in at least one of its next states. The concept of a weak mode invariant was not needed at the requirements level because mode transitions are considered to occur at the same time as their triggering events.
160
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
Update annotation assigns values to variables, identifying points at which the program changes its state. An Assert annotation reflects a programmer’s knowledge that variables have particular values in the current system state. Static analysis usually gives imprecise results because system states are aggregated. Assert annotations improve the precision of analysis based on what the programmer believes to be true. A designer might also use other statements in addition to annotations and control-flow constructs. We do not process the former since they do (should) not reflect changes of values of requirements variables. To differentiate between statements and annotations, the later start with @@. Designs of programs implementing SCR requirements typically consist of an Initial annotation marking the starting state, and a loop in which the system reads relevant monitors, tests their values, and then changes its mode and the values of controlled variables. Figure 6 shows the design of the SWLMS from Section 2 written by following this method. Assert annotations are inserted at locations where predicates are tested, and Update annotations are inserted where program changes occur. Annotations in the form @@ Update Top(V) are used to indicate that V has been assigned some unknown value (true or false). Mode transitions and changes to the values of controlled variables occur after events have been detected. In Fig. 6, controlled variables are updated on lines 17, 34, 38, and 44. Such a design could have been automatically generated. Unfortunately, generating designs for complex systems with several mode classes is not a trivial task, and we make no attempts to automate it. Experienced designers might want to hand-optimize their designs by “factoring out” common actions for different states. Figure 7 shows the result of such a handoptimization. Here we noticed that the pump can be turned on only when the system is in mode Operating, and thus the system reads the water level and determines the state of the pump in the inner while loop, exiting it when the switch is turned Off. For the remainder of this section we show how we can check consistency between our designs and requirements. After a detailed design is completed and verified, it can be further refined to build an implementation.
5.3 Creating an Abstraction The detailed design (DD) is used to create a design flow graph (DFG), which is abstracted into a finite-state machine (FSM) (see Fig. 8). Afterwards, the FSM is used to check system properties. We construct a DFG from annotations and control-flow information and then propagate the state information about the requirements variables throughout the DFG.
MODEL CHECKING
QQ Initial Off & -Suitchon & -PumpFail & -TooHigh & -TooLou & -PumpOn; while (1) if (IN-OFF(System)) { QB Assert Off; /* the system is in mode Off */ / * read switch monitor */ READ-SWITCH(); Od Update Top(Suitch0n); if (SWITCH-ON() && !PUMP-FAIL()) I QQ Assert SuitchOn & PumpFail; OQ Update Operating;
2: 3: 4: 5: 6: 7: a: 9: 10: 11: 12: 13: 14: 15: 16: 17:
5 h s e
I
READ-DEVICE(); / * read s t a.te of the pump * / BQ Update Top(PumpFai1) ; if (PUMP-FAIL()) { QQ Assert PumpFail; QQ Update Error & ‘Pumpon;
ia :
19: 20: 21: 22 : 23: 24: 25: 26 : 27: 20: 29: 30: 31 : 32: 33: 34: 35: 36: 37: 3a : 39: 40: 41: 42: 43: 44: 45: 46: 47 : 40: 49: 50:
161
3
3
>
e l s e if (IN-OPERATING(System))
QO Assert Operating;
{
READ-SWITCH() ; (00 Update Top(Suitch) ; if (!SWITCH-ON() && !PUMP-FAIL()) I 00 Assert -SuitchOn & PumpFail; QQ Update Off;
>else
.I /* compute water l e v e l * / GET-WATER-LEVEL (&Water); QQ Update Top(TooHigh1 t Top(TooLou) ; if (IS-HICH(Water) 1 1 IS-LOW(Water)) c OQ Assert TooHigh 1 TooLou; QQ Update Pumpon; 5 i
else { QQ Assert -TooHigh & -TooLou;
QQ Update -Pumpon; 1 READ-DEVICE() ; 00 Update Top(PumpFai1) ; if (PUMP-FAIL01 I QQ Assert PumpFail; QQ Update Error & -Pumpon;
3
3
1
... FIG.6. lnitial SWLMS design.
Definition 5.1 A DFG of a program design DD is a directed graph G = (S, E, so) where S is a finite set of nodes corresponding to splits, joins, and annotations of DD. E S x S is a set of directed edges, s.t. (s,, s2) E E iff s2 can immediately follow s1 in some execution sequence; and so E S is an entry node.
162 1: 2: 3: 4: 5: 6: 7: 8: 9: 10 : 11: 12: 13 : 14: 15: 16 : 17: 18 : 19: 20 : 21: 22: 23 : 24: 25 : 26 : 27 : 28 : 29 : 30 : 31: 32: 33: 34: 35: 36 : 37: 38: 39 :
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
.c ...
40: 41: }
QQ Initial Off & -Suitchon & 'PumpFail & -TooHigh & "TooLou & -Pumpon; while (I) { 00 Assert -PumpFail; /* assume no device failure6 * / READ-SWITCH ( ) ; / * read switch monitor * I 00 Update Top(Switch0n) ; if (SWITCH-ON0 kb IN-OFF(System)) I QQ Assert SuitchOn C Off; 00 Update Operating; 1
else if (IN-OPERATING(System)) QQ Assert Operating; vhile (1) READ-SWITCH0 ; OQ Update Top(Switch0n) ; if (!SWITCH-ON()) I QQ Assert Switchon; 00 U date Off; breaK ;
C
}
GET-WATER-LEVEL (Water); /* compute water level * /
06 Update Top(TooHigh1 & Top(TooLov);
if (IS-HIGH(Water) I I IS-LOW(Water)) 00 Assert TooHigh I TooLou; 00 Update PumpOn;
>else
C
{
0% Assert -TooHigh & -TooLou;
QQ Update -Pumpon;
1 ) 3 READ-DEVICE() ;
a0 Update Top(PumpFai1);
I* read device monitor */
if (PUMP-FAIL()) C QQ Assert PumpFail; 00 Update Error & -Pumpon;
I
... FIG. 7 . Final SWLMS design.
S and I C S be sets of nodes containing Update and Initial Let U annotations, respectively. (Sets U and I are disjoint.)
We interpret annotations in the design to create a set-based approximation of attainable values for each requirements' variable [16,17]. The details of building a DFG are given in [12]. The DFG that we create contains nodes that do not reflect state changes (e.g., decision nodes, joins, and nodes containing Assert annotations). We use the DFG to construct an FSM. We start with all nodes of the DFG and remove those not representing state changes. The resulting FSM is then used as a model for verifying system properties.
Definition 5.2 An FSM over a detailed design D D is a Kripke structure M
=
(V, S, so,R, I), where
MODEL CHECKING
163
Finite-State Machine
Design Flow Graph
<*Detailed Design
FIG. 8. Layers of abstraction
V is a set of modes and conditions; S = U U I is a finite set of nodes; so E S is an entry node; R C S X S is a total transition relation,3 i.e., Vx E S 3 y E S s.t. (x, y ) E R; R is obtained by connecting nodes of S s.t. (there is an Update-clear path between them in DFG); and I: S -+ 2" is a function associating each node with a truth assignment rn for each variable in V. When constructing this machine, we connect all predecessors of a removed node in DFG to all of this node's successors. Figure 9 shows the FSM that abstracts the SWLMS design in Fig. 6. A label for each node consists of its I n f o and g e n u sets. For a state s, we use the notation gen.(s) and I n f o(s) to refer to these sets separately. g e n u sets specify changes made to state information at the node (generated by Update statements), and I n f o sets contain all information about system variables available at this point. 5.4 Verifying Properties
In this section we describe how automatically generated properties and system goals are verified. During the process described in the previous section, we took a detailed design and built an FSM from it, combining all possible values of each variable at every program point and removing nodes that do not correspond to state changes. Unfortunately, since our analysis We add loops at terminal states since our specifications describe only infinite behaviors.
164
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
snul2) ={(OH,(True)). (Error, (False ), (Operating, {False)). Y i t c h O n , {False) , (PumpFail, (Fake11 {TwHigh. False)), TooLow, /False}), (Pumpon, a se))))
fo(2) =((OH {True)) Error (False)) 0 erating
-
(False)), (SwitchOn,' Lalsej), Pumpdait)(Falsej), (TwHigh. (False)), (iooLow, [False)), (PumpOn,
((SwitchOn. (True,False))J
?nu(9) =((Off, {False)), (Error, {False)), (Operating, (True)))
genu(l5)
-
((TwHigh. True,False)), (TooLow. {(True.False))) fo(22) = { Off False ((Error False)) (Operating True ) (&wit&On k~e,Fal;e\), PumpFail. (True', alse ( T w H i h, rue,False)), ($ooLow, (True, kals,)), (Pump8n. irue.False)))
3nu(22)
);
\
-
((SwilchOn. (True,False)))
genu(29) = {(PumpOn. (False)))
3nu(25) = {(Pumpon. {True)))
x 3 I*
enu(34) = ((PumpFail, (True.False))) ifo(34) = ((011,(True,False)), (Error, (False)). (Operatin True.False)). SwitchOn, True,FalseJ), (PumpFaf; (rue False)) ((TmHigh jrue,False)), (TooLow. (~rue,False)).[Pumpon, jtrue.False)))
genu(l8) = ((Off, (True)). (Error, {False)), (Operating. (False) Inlo(l8) =((OH, (True)), (Error, {False ), (Operating, [False)), SwitchOn (False) (PumpFail (False)) (TwHigh True Lake)). (T~oLow./True.False)i. (Pumpon. (True.
g e n W 7 ) = i\;fI;;;;;j~$~;,
-
(True)). (Operating, {False))
lnlo(37) {(Olf,(False 1, (Error, (True ), Operating. False)], [SwnchOn, (TrueFake)), (Pum Fa/, (true)), TooLi h. True, False)), (TwLow. {True.&lse)). (Pump'!In, (Fdse)))
FIG. 9. Finite-state abstraction.
is static, we are unable to determine which paths through the resulting FSM are feasible, and thus we cannot verify properties exactly, that is, we cannot claim that a property is violated if and only if we report a violation. We have built our own model checker t o facilitate property verification since our method for constructing finite-state abstractions from designs produces sets of values for each program variable. Available model checkers were not able to interpret these sets correctly. Since we knew which properties we were interested in verifying, we were able to optimize the verification, so that automatically generated properties can be checked in a single traversal of the FSM; however, separate traversals are required for userspecified system goals.
Definition 5.3 A design is analyzed pessimistically if all (plus perhaps some nonexistent) violations present in the design are reported. A design is analyzed optimistically if all reported violations (plus perhaps some w others) are present in the design. Thus, if a pessimistic analysis reports no violations of property P, then we know that P holds in the design; and if an optimistic analysis reports any violation of P, then we know that P does not hold in the design. A property P is verified inconsistently if no valid conclusion can be made when a violation of P is reported or when no violations of P are reported.
165
MODEL CHECKING
The OLT properties (like P,-P3 in Fig. 4) involve quantification over every possible state. Since reported violations might occur on infeasible paths, we analyze these properties pessimistically. ALT properties (like P4-P7), however, are existentially quantified. Since a state satisfying these properties in the model might occur on an infeasible path, we analyze these properties optimistically. During property verification, we need to determine if a first-order formula holds in a state [e.g., to verify a formula A G ( a ) ,we need to check that a holds in every state], making sure that no properties are verified inconsistently. Variables in states have values represented by sets, so we treat atomic (or negated atomic) propositions in formulas as assertions about sets of values, for example, PumpOn is treated as PumpOn = {True}and -Operating is treated as Operating
=
{False}& Off
=
{True,Fulse} & Error
=
{True,False}
because the system must be in one of the three modes. We define two interpretations for a proposition P holding in a state s, one for pessimistic interpretations (s k p P ) and another for optimistic interpretation (s k,, P ) . To check if a state s is a model of a proposition P, we compare P's asserted value ( P f )with its value in state s ( P ( s ) )(see Fig. 10). For optimistic analysis, if there are common values between Pf and P(s), that is, P f n P ( s ) # 0, we assume that Pf holds in s. In pessimistic analysis we do not want to overlook any errors, and thus we consider Pf to hold in a state s only if ( P ( s ) # {}) A ( P ( s ) C P f ) ,that is, all values of P(s) are present in Pr. For a temporal formula P we write FSM, so P (or FSM, so # P ) to indicate that FSM is (is not) a model of P. Finally, for both types of analysis, we assume that an event @T(a) (@F(a)) occurs at a node containing an annotation that sets a to true (false).
5.4.7
Checking Automatically-Generated Properties
To verify the automatically generated properties, we take advantage of their rather restricted forms and verify all these properties in a single
s I=,P s kPP
s I=,P s l#pP
s l#oP s I3P
FIG. 10. Interpretations of a proposition P holding in state s.
166
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
traversal of the FSM. The CAM property is checked pessimistically by examining every state of the FSM. The remaining properties involve state transitions that occur only in response to events. To calculate a node's event, we look for predecessors of the node and construct triggering and WHEN conditions from corresponding g e nu and I n f o sets, respectively. For example, consider calculating the event that results in transition to Error at node 37 of Fig. 9. Node 37 corresponds to line 37 of the design in Fig. 7. Its predecessor is node 34. The triggering condition for the transition from 34 to 37 is computed from the information specified in g e n "(34) set: @T(PumpFail) & @F(PumpFail). The WHEN conditions are generated from I n f 0(34), resulting in the set of events in Fig. 11. Controlled variables are not part of events: thus, PumpOn is excluded from the event's conditions. Error, Off and Operating in node 34 become starting modes for a transition. Finally, since PumpFail is restricted to {True} in node 37 because of the Assert annotation at line 36, only the triggering condition @T(PumpFail) could have occurred.
Verification of OLTProperties. One of the OLT properties automatically generated from the requirements of SWLMS was P3 = AG(EX(Error) -+ (Error V (Operating & @T(PumpFail)) V (Off & @T(PumpFail)))) All such properties have the general form P = AG(EX(F) + ( F V G)). SinceAG(EX(F) -+( F V G)) = AG(AX(-F) V ( F V G)), these properties are universally quantified and thus can be verified pessimistically, possibly identifying illegal transitions even if they actually occur on infeasible paths. Thus, we use a pessimistic interpretation of a property holding in a state. We need to examine only those states in which F is false and in whose successors F is true (node 34 in our example). We check the formula only for predecessors of states labeled with Update annotations for F. In our
11 : QT(PumpFai1)
WHEN
Transition from Off to Error: [Switchon = { T r u e , False} & TooHigh = { T r u e , False} & TOOLOW = { T r u e , False} & off = {True, False} & Operating = { True,Fal se} & Error = { F a l s e } ]
Transition from Operating to Error:
12 : OT(PumpFai1)
[SwitchOn = { T r u e , False} & TooHigh = {True, False} & TOOLOW = { T r u e , False} & Off = { T r u e , False} & Operating = { T r u e , False} & Error = {False}] FIG. 11. Events and transitions discovered for node 34. WHEN
MODEL CHECKING
167
example, both calculated events ( I I and I*) establish P3 for node 34. We check all OLT properties in one traversal of FSM using the algorithm in [12].
Verification of A L T Properties. properties for SWLMS:
The following are some of the ALT
Ps = EX(0ff & @T(PumpFail) & EF(Error)) P, = EX(0perating & @T(PumpFail) & EF(Error)).
These properties hold in the model because node 34 satisfies them via transitions II and Z2, respectively (see Fig. 11). We mark ALT properties indicating that they have been satisfied if the design’s calculated event contains values that would cause a requirement’s state transition. Any properties remaining unmarked at the end of analysis are reported as errors. This analysis is optimistic since it considers state transitions to satisfy a property even if they occur on infeasible paths. Thus, we might not report all unimplemented transitions. We use an optimistic interpretation for a property holding in a state to ensure that no extra errors are identified.
5.4.2 Verifying System Goals Each of the system goals specified in the requirements is verified in a separate traversal of FSM. Reach properties are existentially quantified CTL formulas and are verified optimistically. All other properties are universally quantified CTL formulas and are verified pessimistically. We start by verifying the system goals stated in Section 4.4, plus one new goal involving a controlled variable: 0 0
0
wmi (Operating, (Switchon & -PumpFail)) wmi (Off, (-Switchon & PumpFail)) wmi (Error, PumpFail) cause (@T(SwitchOn), -Off) cause (Operating & @T(TooHigh), PumpOn)
Each of these properties is verified in a separate search of the FSM. For example, wmi(M,P) is equivalent to AG((-M v P ) v A X ( - M ) . Thus, we search the FSM for the nodes such that M holds in the node and in at least one of its successors, check that P holds in this node, and stop as soon as an error is discovered. As was the case in requirements analysis, wmi(Error, PumpFail) fails to hold. The system transits to mode Error in node 37 (line 37 on Fig. 7). Figure 9 shows that node 6 (line 6) is a successor of node 37 in the FSM. Since In f o(6) contains (PumpFail, {False}),we report that the property is
168
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
violated at node 6. The alternative invariant wmi(PumpFai1,Error) holds for the model.
6. Case Study T o demonstrate our analysis techniques on more realistic applications, we conducted a case study on a water-level monitoring system (WLMS) that had been specified using SCR requirements and subsequently implemented [29]. Our usual analysis process starts by merging information from environmental assumptions into mode transition tables, and continues by trying to prove that the logic model derived from this combined information is a model of the system goals using model checking. This analysis often results in changes to the mode transition tables and/or to the system goals. After this we proceed with the creation of a design corresponding to the new mode transition tables and any controlled variables’ event tables. We make changes to our design to ensure that it is consistent with the properties automatically generated from the requirements and the stated system goals. We deviated from this process in our case study by reverse engineering a design from an existing implementation in order to determine what, if any, errors might be detected with our analysis technique.
6.1 The Application WLMS monitors and displays the water level in a container. It also raises visual and audio alarms, and shuts off its pump when the level is out of range or when the monitoring system fails. Two push buttons, Selffest and Reset, permit the operator to test the system and return it to normal operations. WLMS has two mode classes, Normal and Failure, whose modes are described in Table 111. Conditions indicate whether the water level in the container is within its limits ( WithinLimits) and its more stringent hysteresis (InsideHysR). Other conditions indicate the lengths of time that buttons have been pressed (SelffestPressed.500-SelfTest button pressed for 500 ms) or that the system has been in a mode (InTest14000-in mode Test for 14 s). Table IV summarizes the environmental assumptions that we deduced from descriptions of conditions in the requirements. The system starts in mode Standby of mode class Normal and mode AllOK of mode class Failure. A mode transition table for mode class Normal is shown in Table V. Controlled variables are set to trigger alarms and to display the water level to the operator. Table VI shows the settings for the controlled variable
169
MODEL CHECKING
TABLE 111 WLMS MODES Mode Class Normal
Meaning
Mode Operating Shutdown Standby Test
Failure
AllOK BadLevDev HardFail
The system is running properly. The water level is out of range and the system will be shutdown unless conditions change. The system is waiting for the operator to push a button to select test or operating mode. The system is not operating, but controlled variables are being checked. N o device failures. The water level cannot be measured. Unrecoverable failure.
LowWindowOn, which represents the annunciation window labeled “Water Level Low.” When LowWindowOn is true, the annunciator displays a value. This happens when the water level falls below its limits (i.e., LevelLow) or when the water level cannot be measured (BadLevDev) and a certain amount of time has passed (FlashOffS00). The WLMS requirements document did not contain a list of system goals. We inferred that the following four properties should be invariant and corroborated this with the requirements designer. If the Selffest button has been pressed for 500 ms or more, the system is either in mode Test or will be in mode Test after its next transition. When the system is in mode Standby, the Selffest button has not been pressed for SO0 ms. If the system is in mode Operating, then the Selffest button has not been pressed for 500 ms, and either the water level is within limits or the Selffest button is being pressed. TABLE IV
ENVIRONM~N ASSUMPT~ONS TAL ABOUT WLMS CONDITIONS Environmental Assumptions InsideHysR - >> WithinLimits SelffcstPressed < SelffcstPressed500 Resetpressed < ResetPressed3000 InTestO < InTest2000 < InTest4000 < lnTest14000
TABLE V ORIGINAL MODETRANSITION TABLE FOR MODECLASSNORMAL Current Mode Standby
Inside HysR
Within Limits
Selffest Pressed
Selffest Pressed500
InTest 14000
Reset Pressed3000
Shutdown LockTime200
t -
Operating Shutdown
-
f
-
f f
@T -
Test ~
~ ~ _ _ _ _ _
Initial: Standby (-SelffestPressed500 & -ResetPressed3000 & -1nTest14000 & -ShutdownLockTime200)
f @T
New Mode Operating Test Shutdown Test Operating Standby Test Standby
171
MODEL CHECKING TABLE VI FOR CONTROLLED VARIABLE LOWWINDOWON EVENT TABLE
Mode
Triggering Event
Operation A AllOK Shutdown A AllOK Test A AllOK BadLevDev LowWindowOn =
@T(LevelLow) @T(LevelLow) @T(InTest2000) @F(FlashOff500) True
@T(Inmode)
WHLN
[-LevelLow]
@T(lnTest4000) @T(FlashOff500) False
Initial: True
4. If the system is in mode Shutdown, then the SelfTest button has not been pressed for 500 time units (or the system would have transitioned into the Test mode); and either the system has been in the Shutdown mode for less than 200 time units, during which the water level has remained outside the hysteresis water-level range, or the Selffest button is being pressed (indicating an imminent transition to mode Test).
6.2
Requirements Analysis
The first step in our requirements analysis is to add information from the environmental assumptions to mode transition tables. The relationships (InsideHysR- >>WithInLimits) and (Selff estPressed<SelffestPressed500) add information to seven transitions. For example, consider the transition from Operating to Shutdown. InsideHysR must already be false if WithinLimits is becoming false, and SelffestPressed500 must be false since SelfTestpressed is false. Table VII is a mode transition table with the environmental assumption information added. From the detailed mode transition table, we create a logic model and translate our invariants into CTL formulas. 1. AG((SelfTestPressed500 A -Test) + AX(Test)) 2. AG(Standby + -SelffestPressed500) 3. AG(0perating -+ (-SelfTestPressed500 A (WithinLimits // SelfTestPressed))) 4. AG(Shutdown (-SelfTestPressed 500 A ((-InsideHysR A -ShutdownLockTime200) // -SelfT estpressed)))
-
These assertions are processed using the techniques in Section 3 since AG(f) is just - E F ( - f ) . The SMV model checker found counterexamples to each of these invariants.
TABLE VII DETAILED MODETRANSITION TABLE FOR MODECLASSNORMAL Current Mode Standby Operating Shutdown
Test
Inside HysR
Within Limits
t f
t @F
-
-
Selffest Pressed
Shutdown LockTime200
Selffest Pressed500
InTest 14000
Reset Pressed3000
-
-
-
@T
-
@T f @T f f @T
-
-
-
-
-
-
-
-
@T
t
-
-
-
-
t f t f f t
-
-
-
-
-
@T
-
f @T -
-
-
Initial: Standby (-SelffestPressed500 & -ResetPressed3000 & -1nTest14000 & -ShutdownLockTime200)
New Mode Operating Test Shutdown Test Operating Standby Test Standby
MODEL CHECKING
173
The first formula failed because the two transitions leaving mode Standby can be simultaneously enabled if both SelffestPressed500 and ResetPressed3000 become true at the same time while their respective WHEN conditions are also true. To make the first formula hold, we gave priority to the transition to Test by adding the W H E N condition -SelffestPressed500 to the transition from Standby to Operating. The second formula is not invariant because SelffestPressed500 is not always false on entry to Standby. If the operator presses the Selffest button when the system is in mode Test, the button may have been pressed long enough to make SelflestPressed500 true before the system transitions from mode Test to mode Standby. Adding the WHEN condition -SelfTestPressed500 to the transition between modes Test and Standby ensures that SelffestPressed500 is always false, but may cause the system to remain in mode Test indefinitely. If the operator is pressing the Selffest button when InTest14000 becomes true, not only will the transition leaving mode Test not be activated, but it will never be activated since InTest14000 will never be satisfied again. To avoid this, we add a second transition from Test to Standby that is activated if the operator releases the Selffest button after the system has already spent 14 s in mode Test. The failure of the third formula is critical because it meant to ensure that the system does not remain in mode Operating with the water level outside its limits. If the system is in mode Operating and the Selffest button is being pushed, the system will remain in this mode even if the water level goes outside its limits because of the expectation that the next mode transition should be to mode Test. However, if the button is released before 500 ms pass, the system remains in Operating mode regardless of the water level. The transition from Operating to Shutdown should depend on the button not being pressed long enough to enable a different transition from Operating (to Test), rather than just on the button being pressed. Thus we replace -SelfI'estPressed with -SelffestPressed500 in this transition's WHEN condition. We also change the invariant to AG(0perating -+ WithinLimits) since we do not care if the button is being pressed. The fourth formula fails for the same reason as the third one did. InsideHysR or ShutdownLockTime200 becoming true will fail to trigger events if the Selffest button is depressed. We make the same replacements in the WHEN conditions for the events these conditions trigger as
174
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
we did for the transition from Operating t o Shutdown, and change the invariant to AG(Shutdown -+ (-InsideHysR A -ShutdownLockTime200)).
6.3 Design Analysis From the corrected requirements in Table VIII and invariants, we would usually proceed to create a design. However, in this case study we were interested in finding errors in the existing system. Since the existing implementation used the original transition tables and invariants, we did not modify them for our study either. T o build a design, we reverse engineered an existing implementation of WLMS originally consisting of roughly 1300 lines of FORTRAN and assembler code. The resulting design was about 700 lines long, with 19 Update annotations corresponding to monitored variables, 30 Update annotations corresponding to mode class and controlled variables, and 60 Assert annotations. Out of 54 functions in the original program, only 8 had state changes and thus were included in the design. After we eliminated annotation errors in the design, we used the original mode transition table (Table V, which had also been used by the original programmer) t o perform our analysis. Our tool reported a number of inconsistencies between the requirements and the design (see Table IX). These numbers overestimate the actual errors in the design. First, some mode transitions and controlled variable value changes resulted in a number of OLT property violations. For example, three illegal mode transitions generated four violation messages because several illegal transitions were detected at one location. All of the mode transition problems can be attributed to three principal causes: The wrong monitored variable was checked to enable mode transitions (WithinLimits rather than InsideHysR), the times that the operator pressed the Selffest and Reset buttons were not calculated or checked, and no transitions to a mode corresponding to complete system failure were implemented. Most of the illegal assignments to the controlled variables occurred because the order of triggering events in the design differed from that in the requirements. We started with the same four invariants as in our requirements analysis, but adapted them to our tool’s assertion notation: 1. cause(@T(SelfTestPressed500), Test) 2. wmi(Standby, -Selff estPressed500) 3. wmi(Operating, (-SelffestPressed500 Pressed)))
& (WithinLimits
I
Selffest-
TABLE VIII CORRECTED MODETRANSITION TABLE FOR MODECLASSNORMAL Current Mode Standby Operating Shutdown
Test
Inside HysR
Within Limits
SeltTest Pressed
t
t
-
-
t
f
@F
-
-
-
@T
t
t -
-
-
-
t f OF
-
-
-
-
-
-
Selffest Pressed500 f @T f @T f f @T f f
InTest 14000
Reset Pressed3000
Shutdown LockTime200
-
@T
-
-
-
-
-
-
-
-
f
-
-
@T
@T t
-
-
-
-
Initial: Standby (-SelffestPressed500 & -ResetPressed3000 & -1nTest14000 & -ShutdownLockTime200)
-
-
New Mode Operating Test Shutdown Test Operating Standby Test Standby Standby
176
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
TABLE IX
RESULTS01: ANALYZING THE WLMS Property Type
Violations
Locations
OLT properties for mode classes OLT properties for controlled variables ALT properties for mode classes ALT properties for controlled variables User-defined uroDerties
4 53 9 28 1
3 7
4. wmi(Shutdown, (-SelffestPressedSOO & ((-InsideHysR downLockTime200) I -SelffestPressed)))
& -Shut-
Each of the first three user-defined properties was verified by Analyzer. These results are not particularly interesting because all the safety properties included a negated monitored variable (SelffestPressed500) that was never assigned a value true in the design. Thus, the first two formulas hold trivially. The third formula was verified since WithinLimits was set to true before each transition to Operating, and whenever WithinLimits and SelffestPressed were set to false, the system immediately transitioned to mode Shutdown. Analyzer reported a violation of the fourth property because InsideHysR received the value {True,False} as a result of its relationship to WithinLimits. This value was propagated throughout the graph, and, since wmi properties are verified pessimistically, Analyzer reported a potential fault. In fact, InsideHysR is never explicitly set to true in the code, and thus this property holds in the design.
7 . Conclusion This paper presented our work on using model checking to verify requirements and designs, which is part of an ongoing effort to develop automated techniques that use formal methods to verify program artifacts. We have presented a logic-model semantics for SCR behavioral requirements specifications and have proposed modal logic operators for expressing formulas over modes, conditions, and events. This enables us to verify CTL-expressed system goals with respect to an SCR logic model using the SMV model checker. We have also defined a notion of consistency between SCR-style requirements and a detailed design and presented an automated technique that uses transition tables to generate temporal logic formulas capturing this notion. We have shown how to create a finite-state abstraction
MODEL CHECKING
177
of a detailed design and model check it against these formulas. We have applied these techniques to analyze the requirements and design of a waterlevel monitoring system, uncovering several errors. ACKNOWLEDGMENTS This research was supported by the Air Force Office of Scientific Research under contract F49620-93-1-0034and by the Natural Sciences and Engineering Research Council under grant OGP0155243. We thank David Parnas and John van Schouwen for providing the requirements and an implementation of the water-level monitoring system. Rich Cerber and Bill Pugh gave us valuable technical suggestions about model checking and abstract interpretation. We also benefited from discussions with Connie Heitmeyer about the semantics of SCR, and with Stuart Faulk about creating designs from SCR specifications. REFERLNCES 1. Allen, R., and Carlan, D. (1994). Formalizing architectural connection. Proc. Sixteenth International Conference on Software Engineering, May 1994. 2. Alspaugh, T., Faulk, S . , Britton, K., Parker, R., Parnas. D., and Shore, J. (1988). Software Requirements for the A-7E Aircraft. Technical Report, Naval Research Laboratory. 3. Atlee, J. (1992). “Automated analysis of software requirements.” Ph.D. Thesis, University of Maryland, College Park, MD. 4. Atlee, J. M.. and Cannon, J. (1993). State-based model checking of event-driven system requirements. l E E E Trans. Softwure Eng., 19(7), 22-40. 5. Atlee, Joanne M., and Buckley, Michael A. (1906). A logic-model semantics for SCR software requirements. Proc. 1996 International Symposium on Software Testing and Analysis (ISSTA), pp. 280-292, January 1996. 6. Atlee, Joanne M., and Cannon, John (1993). Analyzing timing requirements. Proc. 1993 International Symp. on Software Testing and Analysis (ISSTA), pp. 117-127, Cambridge, MA, June 1993. 7. Barrett, C . (1995). Model checking in practice: The t9000 virtual channel processor. I E E E Trans. Software Eng. 21(2), 69-78. 8. Browne, M. (1989). “Automatic verification of finite state machines using temporal logic.” Ph.D. Thesis, Carnegie Mellon University, 1989. 9. Bultan, Tevfik, Fischer, Jeffrey, and Gerber, Richard (1 996). Compositional verification by model checking for counter-examples. Proc. 1996 International Symp. on Software Testing and Analysis (ISSTA), pp. 224-238, January 1996. 10. Chechik, M., and Cannon, J. (1994). Automatic verification of requirements implementations. Proc. 1994 International Symp. on Software Testing and Analysis (ISSTA), pp. 1-14, Seattle, WA, August 1994. 11. Chechik, M., and Cannon, J. (1995). Automatic analysis of consistency between implcmentations and requirements: A case study. Proc. 10th Annual Conference on Computer Assurance, pp. 123-131, June 1995. 12. Chechik, M., and Cannon, J. (1995). Automatic analysis of consistency between requirements and designs. Technical Report CS-TR-3394.1, Dept. of Computer Science, University of Maryland, College Park. 13. Clarke, Edmund M., Crumberg, Orna, and Long, David E. (1992). Model checking and abstraction. Proc. Ninth Annual Symp. on Principles of Programming Languages, pp. 343-354, August 1992.
178
JOANNE ATLEE, MARSHA CHECHIK, AND JOHN GANNON
14. Clarke, E. M., and Emerson, E. A. (1981). “Synthesis of Synchronization Skeletons for Branching Time Temporal Logic.” Vol. 131 of “Lecture Nodes in Computer Science,” Springer-Verlag, Berlin. 15. Clarke, E. M., Emerson, E. A., and Sistla, A. P. (1986). Automatic verification of finitestate concurrent systems using temporal logic specifications. ACM Trans. Programming Languages Syst. 8(2), 244-263. 16. Cousot, Patrick, and Cousot, Radhia (1976). Static determination of dynamic properties of programs. Proc. Colloque sur la Programmation, April 1976. 17. Cousot, Patrick, and Cousot, Radhia (1977). Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints. Proc. 4th POPL, pp. 238-252, Los Angeles, CA. 18. Harel, David (1987). StateCharts: A visual formalism for complex systems. Sci. Computer Programming 8, 231-274. 19. Heitmeyer, C. (1994). Tools for analyzing requirements: A formal foundation, paper presented at the Fourth International SCR Workshop, December 1994. 20. Heitmeyer, C., and Labaw. B. (1993). Consistency checks for SCR-style requirements specifications. Technical Report NRL 93-9586. Naval Research Laboratory. 21. Heitmeyer, C., Labaw, B., and Kiskis, D. (1995). Consistency checking of SCR-style requirements specifications. Proc. RE’95 International Symp. of Requirements Engineering, March 1995. 22. Heninger, K. (1980). Specifying software requirements for complex systems: New techniques and their applications. IEEE Trans. Software Eng. SE-6(1), 2-12. 23. Jackson, Daniel, and Damon, Craig A. (1996). Elements of style: Analyzing a software design feature with a counterexample detector. Proc. 1996 International Symp. on Software Testing and Analysis (ISSTA), pp. 239-249, January 1996. 24. Leveson, N. G . ,Heimdahl, M. P. E.. Hildreth, H.. and Reese, J. D. (1994). Requirements specification for process-control systems. IEEE Trans. Software Eng. 20(9), 684-707. 25. McMillan, K. L. (1993). “Symbolic Model Checking,” Kluwer Academic. 26. Parnas, D., and Madey, J. (1991). Functional documentation for computer systems engineering (version 2). Technical Report CRL 237, McMaster University, Department of Electrical and Computer Engineering. 27. Parnas, D. L. (1993). Some theorems we should prove. Proc. 1993 International Conference on HOL Therem Proving and Its Applications, Vancouver, BC, August 1993. 28. Sreemani, Tirumale, and Atlee, Joanne M. (1995). Feasibility of model checking software requirements: A case study. Technical Report CS-95-48,Department of Computer Science, University of Waterloo. 29. van Schouwen, A. J. (1990). The A-7 requirements model: Re-examination for real-time systems and an application to monitoring systems. Technical Report TR-90-276, Queen’s University, Kingston, Ontario. 30. Wing, Jeannette, and Vaziri-Farahani, Mandana (1995). Model checking software systems: A case study. Proc. 3rd Symp. on the Foundations of Software Engineering, pp. 128-139, October 1995.
Information Technology and Productivity: A Review of the Literature ERIK BRYNJOLFSSON AND SHINKYU YANG MIT Sloan School of Management Cambridge, Massachusetts
Abstract In recent years, the relationship between information technology (IT) and productivity has become a source of debate. In the 1980s and early 1990s, empirical research on IT productivity generally did not identify significant productivity improvements. More recently, as new data are identified and more sophisticated methodologies are applied, several researchers have found evidence that IT is associated not only with improvement in productivity, but also in intermediate measures, consumer surplus, and economic growth. Nonetheless, new questions emerge as old puzzles fade. This survey reviews the literature, identifies remaining questions, and concludes with recommendations for applications of traditional methodologies to new data sources, as well as alternative, broader metrics of welfare to assess and enhance the benefits of IT.
1. The “Productivity Paradox”-A Clash of Expectations and Statistics . . . . . . 2. Research on Economy-wide Productivity and Information Worker Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Industry-Level Studies of Information Technology Productivity. . . . . . . . . 4. Firm-Level Studies of Information Technology Productivity . . . . . . . . . . 4.1 Service Sector Studies. . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Studies of Manufacturing Sector and Cross-Sector Studies. . . . . . . . . 5. Contribution to Consumer Surplus and Economic Growth . . . . . . . . . . . 6. Conclusion: Where Do Wc Go from Here? . . . . . . . . . . . . . . . . . . Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. The “Productivity Paradox”-A
179 187 192 196 196 198 201 205 209
Clash of
Expectations and Statistics During the past decade, both academics and the business press have periodically revisited the so-called “productivity paradox” of computers:
179 ADVANCES IN COMPUTERS. VOL 43
Copyright 0 1996 by Academic Pre%, Inc All rights of reproductinn In any form rewved
180
ERIK BRYNJOLFSSON AND SHINKYU YANG
While delivered computing power in the United States has increased by more than two orders of magnitude since the early 1970s (Fig. l),productivity, especially in the service sector, seems to have stagnated (Fig. 2). Despite the enormous promise of information technology (IT) to effect “the biggest technological revolution men have known” (Snow, 1966), disillusionment and frustration with the technology are evident in headlines like “Computer Data Overload Limits Productivity Gains” (Zachary, 1991). Interest in the “productivity paradox” has engendered a significant amount of research. Although researchers analyzed statistics extensively during the 1980s, they found little evidence that information technology significantly increased productivity. As Robert Solow quipped, “you can see the computer age everywhere but in the productivity statistics.”’ 80
70
20
10
0 1955
1960
1965
1970
1975
1980
1985
1990
1995
Year
FIG.1. Investment in information technology is growing at a rapid pace. [Note: Constant dollars (base year 1987) calculated by hedonic price method, see Dulberger (tYXY).] [Based on data from BEA, National Income and Wealth Division, and adapted from Jorgenson and Stiroh (1995).]
’
Solow, Robert M., “We’d Better Watch Out,” New York Times Book Review, July 12, 1987, p. 36.
INFORMATION TECHNOLOGY AND PRODUCTIVITY
181
3
5
1945
1955
1965
1975
1985
Mfg. Non Mfg.
1995
Year
FIG. 2. Productivity in the service sector has not kept pace with that in manufacturing. (Based on data from Bureau of Labor Statistics, Productivity & Testing Division.)
Now, after some researchers found firm-level evidence that IT investments earned hefty returns, the media pendulum has swung in the opposite direction. Businessweek’s proclamation of “the productivity surge” due to “information technology,”2 and Fortune magazine’s headline heralding the arrival of “technology payoff”-’ represent the latest trend. A growing number of academic studies also report positive effects of information technology on various measures of economic performance. Just as the business media’s premature announcement of a “productivity paradox” was out of proportion to the more carefully worded academic research, the current cover stories on “productivity payoff” are often overblown. A consensus on the relationship between IT investment and economic performance is still elusive. More than a decade ago, one of the earliest surveys concluded that we still had much to learn about measuring the effects of computers on organizations (Attewell and Rule, 1984). A more recent survey also reports a “sobering conclusion: our understanding of how information technology affects productivity either at the level of the firm o r for the economy as a whole is extremely limited” (Wilson, 1995).
* Wildstrom, Stephen H. “The Technology Payoff,” Businessweek June 14, 1993, p. 56-68. Mandel, Michael J., “The Digital Juggernaut,” Businessweek, The Information Revolution, May 18,1994,Bonus Issue, pp. 22-31. Businessweek recently ran another cover story, “Productivity to the Rescue,” October 9, 1995. Magnet, Myron, “Productivity Payoff Arrives,” Fortune, June 27, 1994, pp. 77-84.
182
ERIK BRYNJOLFSSON AND SHINKYU YANG
As more research is conducted, we are gradually developing a clearer picture of the relationship between IT and productivity. However, productivity measurement is not an exact science; the tools are blunt, and the conclusions are not definitive. Thus, while one study shows a negative correlation between total factor productivity and high share of high-tech capital formation during the 1968-86 period (Berndt and Morrison, 1995), another study suggests that computer capital contributes to growth more than ordinary capital (Jorgenson and Stiroh, 1995). More recently, Brynjolfs o n and Hitt (1996) report positive effects of IT based on firm-level evidence. This article seeks to summarize what we know; distinguish the central issues from peripheral ones; and clarify the questions that future research should explore. Results and implications of different studies should be interpreted in the context of specific research questions. The question of aggregate economic performance differs from the question of firm-level economic performance. Data sources and performance measures may also depend on the level of aggregation. Even within one level of aggregation, results may depend on the measure of performance or research method. It is hoped that the process of reviewing studies of the productivity mystery will serve as a useful springboard for examining alternative methodologies and the broader issues involved. As a prelude to the literature survey, it is useful to define some of the terms used and to highlight some of the basic trends in the economics of IT.
Definitions: 0
0
Information technology can be defined in various ways. In terms of capital, among the most common is the BEA’s (U.S. Bureau of Economic Analysis) category “Office, Computing and Accounting Machinery” (OCAM), which consists primarily of computers. Some researchers look specifically at computer capital, whereas others consider the BEA’s broader category, “Information Processing Equipment (IPE).” IPE includes communications equipment, scientific and engineering instruments, photocopiers, and related equipment. In addition, software and related services are sometimes included in the IT capital. Recent studies often examine the productivity of information systems staff, or of workers who use computers. Labor productivity is calculated as the level of output divided by a given level of labor input. Multifactor productivity (sometimes more ambitiously called total factor productivity) is calculated as the level of output for a given level of several inputs, typically labor, capital, and materials. In principle, multifactor productivity is a better measure
INFORMATION TECHNOLOGY AND PRODUCTIVITY
0
183
of a firm or industry’s efficiency because it adjusts for shifts among inputs, such as substituting capital equipment for labor. However, the data needed to calculate multifactor productivity are more complex. In productivity calculations, output is defined as the number of units produced times their unit value, proxied by their real price. Determining the real price of a good or service requires the calculation of individual price deflators to eliminate the effects of inflation.
Trends:
0
0
The price of computing has dropped by half every 2-3 years (Figs. 3a and b).4 If progress in the rest of the economy had matched progress in the computer sector, a Cadillac would cost $4.98, while 10 minutes’ labor would buy a year’s worth of groceries.’ There have been increasing levels of business investment in information technology equipment. These investments now account for more than 10% of new investment in capital equipment by American firms (Fig. 4, Table II).6 Information processing continues to be the principal task undertaken by America’s workforce. More than half the labor force is employed in information-handling activities (Fig. 5 ) Overall productivity growth appears to have slowed significantly since the early 1970s and measured productivity growth has fallen especially sharply in the service sectors, which account for 80%of IT investment (Fig. 2, Table 4). White collar productivity statistics have been essentially stagnant for 20 years (Fig. 6).
This relationship has been dubbed “Moore’s law” after John Moore, who first documented the trend in microprocessors. It is widely projected to continue at least into the next century. In the last 35 years, the quality-adjusted costs of computing have decreased over 6000-fold relative to equipment prices outside the computer sector (Gordon, 1987b). This comparison was inspired by the slightly exaggerated claim in Forbes Magazine 11980) that “If the auto industry had done what the computer industry has done, . . . a Rolls-Royce would cost $2.50 and get 2.000,OOO miles to the gallon.” The $4.98 Cadillac is based on a price of $30,890 for a 1991 Sedan de Ville divided by 6203, the relative deflator for computers. The grocery comparison is based on a wage of $10 an hour and $10,000 worth of groceries, each in 1991 dollars. Some studies estimate that as much as 50% of recent equipment investment is in information technology (Kriebel, 1989). This higher figure seems to be partly due to a broader definition of IT. A discrepancy also arises when recent investments are expressed in 1982 dollars, when IT was relatively more expensive. This has the effect of boosting IT’S real share over time faster than its nominal share grows. The recent change by BEA to a chain-weighted index, instead of a fixed-weight index, will largely alleviate this problem.
’
’
1ooO.O
lW.0
10.0
1.o
0.1
1955
1960
1965
1970
1975
1980
1985
1990
Year
b 52%/year growth 42%iyear growth
Year
-#-Mcroprocessor
A
DRAM
FIG.3. (a) The cost of computing has declined substantially relative to other capital purchases. PDE, producer’s durable equipment. (Based on data from U.S. Department of Commerce, Survey of Current Business.) (b) Microchip performance has shown uninterrupted exponential growth. (P6, P7 microprocessors and 256M, lG, 4G DRAMS are estimated by Intel and the Semiconductor Industry Association.) [Based on data from Grove (1990), and Intel data. Trend lines are by authors’ estimations.]
185
INFORMATION TECHNOLOGY AND PRODUCTIVITY
0.2
0.16
0.14
0.12 u
fr
t
0.1 0.08
0.06
0.04 0.02
0 1558
1963
1968
1973
1978 Year
1983
1988
1993
1998
FIG. 4. Computers comprise about 10% of current-dollar investment in PDE. (Based on data from BEA, National Income and Wealth Division.)
These trends suggest the two central questions of the productivity paradox: (1) Why would companies invest so heavily in information technology if it did not add to productivity? (2) If information technology does contribute to productivity, why is its contribution so difficult to measure? This article builds on a number of earlier literature surveys.’ This review considers more than 150 articles, but is not comprehensive. Rather, we aim
’
Much of the material is adapted from a previous paper by Brynjolfsson (1993). Crowston and Treacy (1986) surveyed 11 articles from 1975 to 1985 on the impact of IT on enterpriselevel performance and conclude that attempts to measure the impact of IT were surprisingly unsuccessful. They attribute this to poorly defined variables, a result of inadequate reference disciplines and methodologies. A review of research combining information systems and economics, by Bakos and Kemerer (1992), includes particularly relevant work. In addition, many papers that seek to assess IT productivity directly begin with a literature survey: the reviews by Brooke (1992), Barua ef al. (1991), and Berndt and Morrison (1995) were particularly useful. Most recently, the first part of Landauer (1995) details research on the productivity puzzle. Wilson (1995) also provides a useful survey of articles.
186
ERIK BRYNJOLFSSON AND SHINKYU YANG
50
_c_
-+.-..
Infomation Agricultum
Industry !bNb
0
1850
1800
in50
2000
Year
Fic. 5. Information processing is the largest category of employment. The defining criterion for information workers is whether the primary activity is knowledge creation, warehousing, or dissemination. [Based on data from Porat (1977).]
120
.* P %I10
Y Q
e
8 PI
3
100
go
80
-
:
-
White Collar Productivity
INFORMATION TECHNOLOGY AND PRODUCTIVITY
187
to clarify the principal issues surrounding IT and productivity. We assimilate the results of a computerized literature surrounding IT and productivity. We assimilate the results of a computerized literature search of 30 leading journals in information systems and economics.8 In addition, many of the leading researchers in this area identified recent research that has not yet been published. The productivity of IT can be measured using data on the whole economy, on specified industries, or on individual firms. In the 1980s and early 1990s, disappointment in information technology was chronicles in articles disclosing broad negative correlations with economy-wide productivity. Several econometric estimates also indicated low IT capital productivity in a variety of manufacturing and service industries. More recently, researchers began to find positive relationships between IT investment and various measures of economic performance at the level of individual firms. The principal empirical research studies of IT and productivity are listed in Table I.
2. Research on Economy-wide Productivity and Information Worker Productivity Economists have been unable to explain the slowdown in measured productivity growth that began in the early 1970s. Labor productivity grew about 2.5% per year from 1953 to 1968, but dropped to about 0.7% per year from 1973 to 1979. Multifactor productivity growth declined from 1.75% a year to 0.32% (Baily, 1986b). Even after accounting for factors such as the oil price shocks, changes in the quality of the labor force, and potential measurement errors, most researchers still find an unexplained residual drop in productivity that roughly coincides with the rapid increase in the use of information technology. Jorgenson and Stiroh's (1995) more recent growth accounting confirms this correlation. They calculate that average multifactor productivity growth dropped from 1.7%per year for the 1947-73 period to about 0.5% for the
'
The journals searched were American Economic Review, Bell (Rand)Journal of Economics, Brookings Papers on Economics and Accounting, Econometrica, Economic Development Review, Economica, Economics of Innovation and New Technology, Economics Journal, Economist (Netherlands), Information Economics & Policy, International Economics Review, Journal of Business Finance, Communications of the A C M , Database, Datamation, Decision Sciences, Harvard Business Review, IEEE Spectrum, IEEE Transactions on Engineering Management, IEEE Transactions on Software Engineering, Information & Management, Interfaces, Journal of MIS, Journal of Systems Management, Management Science, MIS Quarterly, Operarions Research, and Sloan Managemenr Review. Articles were selected if they indicated an emphasis on computers, information systems, information technology, decision support systems, expert systems, or high technology combined with an emphasis on productivity.
TABLE I PRINCIPAL EMPIRICAL STUDIES OF IT A N D PRODUCT~VITY Cross-sector Aggregate-level studies (economy-wide and industry-level)
Micro-level studies (firm and workers)
Jonscher (1983, 1994) Baily (1986b), Baily & Chakrabarti (1988). Baily & Gordon (1988) Roach (1987, 1989b) Brooke (1992) Lau & Tokutsu (1992) Oliner & Sichel (1994) Jorgenson & Stiroh (1995) Osterman (1986) Dos Santos er al. (1993) Krueger (1993) Brynjolfsson & Hitt (1994) Hitt & Brynjolfsson (1994) Lichtenberg (1995) Brynjolfsson & Hitt (1996)
Manufacturing
Services
Morrison & Berndt (1991) Berndt et al. (1992) Berndt & Morrison (1995) Siegel & Griliches (1992) Siegel (1994)
Brand & Duke (1982) Baily (1986a)
Loveman (1994) Weill (1992) Dudley & Lasserre (1989) Barua er al. (1991) Brynjolfsson & Hitt (1993, 1995, 1996)
Cron & Sobol (1983) Pulley & Braunstein (1984) Bender (1986) Bresnahan (1986) Franke (1987) Strassmann (1985, 1990) Harris & Katz (1991) Parsons et al. (1990) Diewert & Smith (1994)
Roach (1987, 1989a, 1991)
INFORMATION TECHNOLOGY AND PRODUCTIVITY
189
1973-92 period. At the same time, OCAM capital as a percentage of all producers’ durable equipment (PDE) investment rose from about 0.5% in the 1960s to 12% in 1993. A broader category of IT capital, information processing equipment (IPE), now constitutes 34.2% of all P D E investment (Table 11). Although productivity growth, especially in manufacturing, has rebounded somewhat recently, the overall negative correlation between productivity and the advent of computers underlies many arguments that information technology has not helped the United States’ productivity and that information technology investments have been counterproductive. [see, for example, Baily (1986b)l. This argument was made more explicitly by Stephen Roach (1987,1988) who focused on the productivity of information workers. In the past, office work was not very capital intensive, but recently the level of IT capital per “white collar” information worker has approached that of production capital per “blue collar” production worker. Concurrently, the ranks of information workers have ballooned and the ranks of production workers have shrunk. Roach shows that output per production worker grew by 16.9% between the 1970s and 1986, while output per information worker decreased by 6.6%. He concludes: “America’s productivity shortfall [is] concentrated in that portion of the economy that is the largest employer of white-collar workers and the most heavily endowed with high-tech capital.” Roach’s analysis provided quantitative support for widespread reports of low office productivity.’ But the economy’s productivity record in the 1970s and 1980s cannot be blamed on the investment in information technology; many other factors also affect productivity and, until recently, computers were not a major share of the economy. Consider an order of magnitude estimate. In 1992, IT capital stock (OCAM) was equal to about 10% of G D P (with a base year of 1987). If, hypothetically, IT’Smarginal product were 50% (exceeding the return to most other capital investments), then the level of gross domestic product (GDP) would be directly increased about 5% (10% X 50%) because of the current stock of IT. However, information technology capital stock did not jump to its current level in 1 year; rather, the increase must be spread over about 30 years, suggesting an average annual contribution to aggregate G D P growth of 0.15%.This contribution would be very difficult to isolate because so many other factors affected GDP, especially in the relatively turbulent 1970s and 1980s. Indeed, if the marginal product of IT For instance, Lester Thurow (1987) has noted that “the American factory works, the American office doesn’t,’’ citing examples from the auto industry indicating that Japanese managers are able to get more output from blue collar workers (even in American plants) with up to 40% fewer managers.
'190
ERIK BRYNJOLFSSON AND SHINKYU YANG
TABLE I1 SELECTED INVESTMENT COMPONENTS I N 1970 A N D 1993 (CURRENT. DOLLARS) Percentage of
Item \ Year Fixed investment Nonresidential investment PDE (nonresidential) information processing OCAM Computer equipment Industrial equipment Transportation
Investment 1970 ($ Billion)
Fixed Investment (910)
148.1 106.7
100.0 72.05
66.4
44.83
14.3
Percentage of Investment 1993 ($ Billion)
Fixed Investment
866.7 616.1
100.0 71.1
100.00
442.7
51.1
100.0
9.66
21.54
151.5
17.5
34.2
4.1 2.7
2.77 1.82
6.17 4.07
53.7 47 .O
6.2 5.4
12.1 10.6
20.2
13.64
30.42
96.7
11.2
21.8
16.1
10.87
24.25
104.2
12.0
23.5
PDE (%)
PDE (%)
Sources: Survey of Current Business, July 1994; U.S. Bureau of Economic Analysis (1992, Vol. 2. Tables 5.4 and 5.8); adapted from Oliner and Sichel (1994). Note: Information processing equipment: OCAM (office, computing and accounting machinery), communication equipment, and scientific and engineering equipment.
capital were anywhere from 0 to +65%, it would still not have affected aggregate GDP growth by more than about 0.2% per year." More comprehensive growth accounting exercises confirm this estimate (see Section 5). Thus, very large changes in capital stock are needed to change total output measurably, although computers may have had significant effects in specific activities, such as transaction processing, and on other characteristics of the economy, such as employment shares, organizational structure, and product variety. However, as the information technology stock continues to grow and the share of the total economy accounted for by computers becomes substantial, we should begin to find changes in the level of aggre-
'"
Each white collar worker is endowed with about $10,000 in IT capital, which at a 50% ROI, would increase his or her total output by about $5000 per year over precomputer levels of output. In contrast, it costs about $100,000 or so in salary and overhead to employ a white collar worker.
INFORMATION TECHNOLOGY AND PRODUCTIVITY
191
gate GDP.” Some recent studies report a high contribution of computers to GDP growth [see, for example, Jorgenson and Stiroh (1995)l. Just as it is hard to isolate information technology’s effect on the economy, white collar productivity cannot be directly inferred from the number of information workers per unit of output. For instance, if a new delivery schedule optimizer allows a firm to substitute one clerk for two truckers, the increase in the number of white collar workers is evidence of an increase in their relative productivity as well as the firm’s productivity. Osterman (1986) suggests that such efficiency improvements can explain why firms often hire more clerical workers after they introduce computers, and Berndt et al. (1992) confirm that information technology capital is, on average, a complement for white collar labor and is correlated with fewer blue collar workers. Berman etal. (1994) also find that the “increased use of nonproduction workers is strongly correlated with investment in computers and R&D.” Unfortunately, it is exceedlingly difficult to measure directly the productivity of office workers. Independent of its implications for productivity, growth in the white collar workforce cannot be attributed solely to information technology. Although almost half of workers now use computers in their jobs (Katz and Kreuger, 1994), the ranks of information workers began to surge even before the advent of computers (Porat, 1977). In fact, Jonscher (1994) argues that the increased demand for information technology created economies of scale and learning in the computer industry, thereby reducing the cost of computers. In line with this argument, the unbalanced growth hypothesis may provide a sensible economic explanation.’* Economic growth may slow down because of intrinsically slow technical progress in the white colalr sector, since it is less subject to automation. Then why is the white collar sector’s share in the economy growing? One possible answer is the higher income elasticity (and lower price elasticity) of demand for services of this sector. As income
” An important study of computer-using workers by Krueger (1993) indirectly supports this view. He found that computer-using workers earned wages 10 to 18%higher than nonusers. In 1984, 24.6% of workers were using computers at work. By 1989, this number had grown to 37.4%. Katz and Krueger (1994) also report that this share of workers had risen to 47% by 1993. Assuming that workers are paid according to their productivity, this implies that computers at work increase GDP level by 3% (3% = 0.7 X 0.1 X 37.4%. 0.1 is the excess marginal product, and 0.7 is the labor share of GDP). Although this numbcr is not sufficient to compensate for the annual 1% productivity slowdown after the early 1970s. it indicates that information technology may boost office worker productivity. Sce. for example, Baumol (1967), and Baumol et al. (1985).
’’
192
ERIK BRYNJOLFSSON AND SHINKYU YANG
increases, people demand more services of white collar sectors. Thus, even if information technology does not add to productivity, companies in developed countries may be forced to invest in it. Since it is difficult to measure white collar sector output, the story becomes complicated. Companies invest in computers to produce “unmeasurables,” as argued in Griliches (1994). In short, the increased IT use may not be a source of the productivity slowdown, but simply a response to the overall transformation of the economy. Furthermore, the main benefits from using computers appear to be in areas such as improved quality, variety, timeliness, and customization, which are not well-measured in official productivity statistics (Brynjolfsson, 1994).
3.
Industry-Level Studies of Information Technology Productivity
The preceding section has shown that contrasting the economy-wide productivity slowdown with increasing IT investment is an obtuse approach, because so many other factors may intervene. Going down to the firm level helps to control many problems that arise from aggregation, but it is often difficult to find data representative for the whole economy. Industry-level studies may provide a middle-of-the-road alternative. Table I11 summarizes some of the important studies. We start with studies on service sectors. It has been widely reported that most of the productivity slowdown is concentrated in the service sector (Schneider, 1987; Roach, 1987, 1991). Before about 1970, service and manufacturing productivity growth rates were comparable, but since then the trends have diverged significantly.I3 Meanwhile services have dramatically increased as a share of total employment and, to a lesser extent, as a share of total output. Because services use up to 80% of computer capital (Table IV), the slow growth of productivity in the service sector has been taken as indirect evidence of poor information
’’
According to government statistics, from 1953 to 1968, labor productivity growth in services averaged 2.56% versus 2.61% in manufacturing. For 1973 to 1979, the figures are 0.68% versus 1.53%, respectively (Baily, 1986b). However, Gordon and Baily (1989) and Griliches (1994,1995) suggest that measurement errors in US.statistics systematically understate service productivity growth relative to manufacturing. More recently, computers definitely have caused some divergence in the statistics on manufacturing and service productivity, but for a very different reason. Because of the enormous quality improvements attributed to the computers, the nonelectrical machinery category (containing the computer-producing industry) has shown tremendous growth. Partly, as a result, overall manufacturing productivity growth has rebounded from about I S % in the 1970s to 3.5% in the 1980s.
TABLE 111 INDUSTRY-LEVEL STUDIES Study
Sector
Data Source
Brand (1982) Roach (1987, 1989a, 1991)
Services Services
BLS" Principally BLS, BEAU
Morrison & Berndt (1991) Berndt etnl. (1992), Berndt & Morrison (1995) Siegel & Griliches (1992)
Manufacturing Manufacturing
BEA BEA, BLS
Manufacturing
Multiple government sources
Siegel (1994)
Manufacturing
Multiple government sources
a
BLS, U.S. Bureau of Labor Statistics; BEA, U.S. Bureau of Economic Analysis
Findings Productivity growth of 1.3%/yr in banking Vast increase in IT capital per information worker and a decrease in measured output per worker IT marginal benefit is 80 cents per dollar invested IT not correlated with higher productivity in most of industries, but correlated with more labor IT-using industries tend to be more productive; government data are unreliable A multiple-indicators and multiple-causes model captures significant MFP effects of computers
194
ERIK BRYNJOLFSSON AND SHINKYU YANG
TABLE IV
INVESTMENTIN COMPUTERS (OCAM) I N THE U S . ECONOMY (PERCENTAGE OF TOTAL IN CURRENT DOLLARS) 1979
1989
1992
Industry
(%)
(%)
(%)
Agriculture Mining Manufacturing Construction" Nonservice Total Transportation Communication Utilities Trade" Finance" Other Services" Services Total Unmeasurable Sectors' Plus consumer and government purchases Unmeasurable sector output
0.1 2.4 29.4 0.1 32.0 1.3 1.5 1.2 19.9 32.5 11.6 68.0 64.1 67.7
0.1 1.1 20.3 0.3 21.8 2.0 1.4 2.8 16.3 38.7 17.0 78.2 72.3 77.6
0.1 0.9 20.2 0.2 21.4 1.0 1.5 2.8 20.0 37.8 13.9 78.6 71.9 77.0
63
69
70
Source: BEA, adapted from Griliches (1995). Unmeasurable sectors: construction, trade, finance and other services; in these sectors outputs are difficult to measure, relative to measurable sectors.
technology productivity. Roach's research (1987, 1989a, 1989b, 1991) on white collar productivity, discussed earlier, focused principally on IT'S performance in the service sector. He argued that IT is an effective substitute for labor in most manufacturing industries, but has been associated with bloating white collar employment in services, especially finance. He attributed this to relatively keener competitive pressures in manufacturing, and he foresees a period of belt-tightening and restructuring in services as they begin to face international competition. However, studies of manufacturing also found evidence that computers may not increase productivity. Berndt and Morrison analyzed a broader data set from the U.S. Bureau of Economic Analysis (BEA) that encompasses the whole U.S. manufacturing sector. In their first paper (Morrison and Berndt, 1991), they examined a series of parameterized models of production and found evidence that every dollar spent on IT delivered, on average, only about $0.80 of value on the margin, indicating a general overinvestment in IT. Their later paper (Berndt and Morrison, 1995) exam-
INFORMATION TECHNOLOGY AND PRODUCTIVITY
195
ined broad correlations of IT investment with labor productivity and multifactor productivity. This approach did not find a significant difference between the productivity of IT capital and other types of capital for a majority of the 20 industry categories examined. They did find that investment in IT was correlated with increased demand for skilled labor. Siegel and Griliches (1992) used industry and establishment data from a variety of sources to examine several possible biases in conventional productivity estimates. They found a positive simple correlation between an industry’s level of investment in computers and its multifactor productivity growth in the 1980s. They did not examine more structural approaches, in part because of troubling concerns about the reliability of the data and government measurement techniques. Their findings contrast with those of Berndt and Morrison (1995). However, Berndt and Morrision (1995) also document positive correlations between IT capital and some measures of economic performance in the specifications where cross-sectional effects were emphasized. In addition, Berndt and Morrison’s level of aggregation (two-digit SIC code) is broader than that of Siegel and Griliches’ (fourdigit SIC code). Many researchers working on industry-level data express concerns about data problems, which are often caused by aggregation. For example, the BEA data are mainly used for industry-level analyses, but it is subject to subtle biases due to the techniques used to aggregate and classify establishments. One of Siegel and Griliches’ (1992) principal conclusions was that “after auditing the industry numbers, we found that a non-negligible number of sectors were not consistently defined over time.” Siegel (1994) attempts to tackle the data problems that arise from two possible sources of measurement error. The first kind of error occurs when computer price and quantity are measured with error. The second source of error is more subtle: Firms invest in computers not only for cost reduction but also for quality i m p r ~ v e m e n t .Because ‘~ the quality improvement is not fully taken into account in traditional statistics, the errors in output measurement are correlated with computer investment. These two kinds of errors cause bias and inefficiency in estimation. After controlling these errors using a “multiple-indicators and multiple-causes’’ model, Siegel found a significant positive relationship between multifactor productivity growth and computer investment. He also found that computer investment is positively correlated with both product quality and labor quality, a result that is consistent with Brynjolfsson (1994), Berndt and Morrison (1995), and Berman et al. (1994). l4
See also Brynjolfsson (1994)
196
ERIK BRYNJOLFSSON AND SHINKYU YANG
4.
Firm-Level Studies of Information Technology Productivity
During the past 10 years, many studies examined the relationship between firms’ IT investment and their performance. Interestingly, studies that have used larger and more recent data sets have found evidence that IT positively affects firm performance. Research results in manufacturing often show stronger effects than studies of services, probably because of better measurement.
4.1
Service Sector Studies
Strassmann (1985) reports disappointing evidence in several studies (see Table V for a list of service sector studies). In particular, he found that there was no correlation between IT and return on investment in a sample of 38 service sector firms: Some top performers invest heavily in IT, others do not. In his later book (1990), Strassmann concludes that “there is no relation between spending for computers, profits and productivity.” Several studies have examined IT’s impact on the performance of financial services firms. Parsons et al. (1990) estimated a production function for banking services in Canada. They found that the impact of IT on multifactor productivity was quite low between 1974 and 1987. They speculated that IT has positioned the industry for greater growth in the future. Similarly, Franke (1987) found that IT was associated with a sharp drop in capital productivity and stagnation in labor productivity, but remained optimistic about the future potential of IT, citing the long time lags associated with previous “technological transformations” such as the conversion to steam power. In contrast, Brand and Duke (1982) used Bureau of Labor Statistics (BLS) data and techniques and found that moderate productivity growth had already occurred in banking. Harris and Katz (1991) and Bender (1986) examined data on the insurance industry from the Life Office Management Association Information Processing Database. They found positive but sometimes weak relationships between IT expense ratios and various performance ratios. Aipar and Kim (1991) studied 759 banks and found that a 10% increase in IT capital is associated with a 1.9% decrease in total costs. Several case studies of IT’s impact on performance have also been done. Weitzendorf and Wigand (1991) developed a model of information use in two service firms; and Pulley and Braunstein (1984) studied an information services firm and found an association between IT investment and increased economies of scope. Estimating a production function, Brynjolfsson and Hitt (1993) found that for the service firms in their sample, gross marginal product averaged
TABLE V STUDIES OF FIRMS IN THE SERVICE SECTOR Study Pulley & Braunstein (1984) Clarke (1985) Strassmann (1985, 1990) Bender (1986) Franke (1987) Harris & Katz (1991) Noyelle (1990) Parsons er al. (1990) Alpar and Kim (1991) Weitzendorf & Wigand (1991) Diewert & Smith (1994) Brynjolfsson & Hitt (1995)
Data Source
Findings
An info service firm Case study Computerworld survey of 38 companies LOMA insurance data on 132 firms Finance industry data
Significant economies of scope Major business process redesign needed to reap benefits in investment firm No correlation between various IT ratios and performance measures
LOMA insurance data for 40 U.S. and French industry Internal operating data from two large banks Large number of banks Interviews at two companies A large Canadian retail firm IDG, Compustat, BEA
Weak relationship between IT and various performance ratios
IT was associated with a sharp drop in capital productivity and stagnant labor productivity Weak positive relationship between IT and various performance ratios Severe measurement problems in services IT coefficient in translog production function small and often negative IT is cost saving, labor saving, and capital using Interactive model of information use Multifactor productivity grows 9.4% per quarter over six quarters Marginal products of IT do not differ much in services and in the manufacturing; firm effects account for 50% of the marginal product differential
198
ERIK B R Y N J O L F S S O N AND SHINKYU Y A N G
more than 60% per year. Their 1995 study reports that IT contributes as much output in the service sector as in the manufacturing sector (Brynjolfsson and Hitt, 1995). Because they used firm-level data, this result suggests that the productivity “slowdown” in the service sector may be an artifact of the mismeasurement of output in aggregate data sets. Indeed, even when firms were classified into “measurable” and “unmeasurable” sectors as defined by Griliches (1994), no noticeable difference in IT productivity between the sectors was found using this firm-level data. Diewert and Smith (1994) provide an interesting case study of a large Canadian retail distribution firm. They found that the firm experienced an astounding 9.4% quarterly multifactor productivity growth for six consecutive quarters starting at the second quarter of 1988. They argue that “these large productivity gains are made possible by the computer revolution which allows a firm to track accurately its purchase and sales of inventory items and to use the latest computer software to minimize inventory holding costs.” Measurement problems are more acute in services than in manufacturing, partly because many service transactions are idiosyncratic, and therefore not amenable to statistical aggregation. Even when data are abundant, classifications sometimes seem arbitrary. For instance, in accordance with one standard approach, Parsons et al. (1990) treat time deposits as inputs into the banking production function and demand deposits as outputs. The logic for such decisions is sometimes tenuous, and subtle changes in deposit patterns or classification standards can have disproportionate impacts. The importance of variables other than IT is also particularly apparent in some of the service sector studies. In particular, researchers and consultants have increasingly emphasized the need to reengineer work when introducing major IT investments.” As Wilson (1995) suggests, it would be interesting to know whether reengineering efforts are the main explanation for Brynjolfsson and Hitt’s (1993, 1995) findings that IT is correlated with increased output. A recent survey found that, in fact, firms that had reengineered were significantly more productive than their competitors (B rynjolfsson, 1994).
4.2
Studies of Manufacturing Sector and Cross-Sector Studies
There have been several firm-level studies of IT productivity in the manufacturing sector. Some of the important results are summarized in Is See, for example. Davenport (1990), Davenport and Short (1993), Hammer (1990). Hammcr and Champy (1YY3). and Champy (19%).
INFORMATION TECHNOLOGY AND PRODUCTIVITY
199
Table VI. A study by Loveman (1994) provided some of the first econometric evidence of an IT productivity shortfall, when he examined data from 60 business units using the Management Productivity and Information Technology (MPIT) subset of the Profit Impact of Market Strategy (PIMS) database. As is common in productivity literature, he used an ordinary least squares regression and assumed that production functions could be approximated by a Cobb-Douglas function. Loveman estimated that the contribution of information technology capital to final output was approximately zero over the 5-year period he studied in almost every subsample. His findings were fairly robust to a number of variations on his basic formulation. Barua et al. (1991) traced Loveman’s results back a step by looking at IT’S effect on intermediate variables such as capacity utilization, inventory turnover, quality, relative price, and new product introduction. Using the same data set, they found that IT was positively related to three of these five intermediate measures, but that the effect was generally too small to affect final output measurably. Dudley and Lasserre (1989) also found econometric support for the hypothesis that better communication and information reduce the need for inventories, without explicitly relating this to bottom-line performance measures. Using a different data set, Weill (1992) disaggregated IT by use and found that significant productivity could TABLE VI STUDIES OF MANUFACTURING FIRMSA N D CROSS-SECTOR FIRMS Study Loveman (1994) Dudley & Lasserre ( 1989) Weill (1992)
Barua et al. (1991) Brynjolfsson & Hitt (1993) Brynjolfsson & Hitt (1995) Lichtenberg (1995) Kwon & Stoneman (1995)
Data Source PIMS/MPIT U S . and Canadian Aggregate Data Valve manufacturers
Findings IT investments added nothing to output IT and communication reduces invcntories
Contextual variables affect IT performance: transaction processing IT produce positive results PlMSiMPIT IT improved intermediate outputs, if not necessarily final output 1DG; Compustat: B E A The gross marginal product of IT capital is over 50% per year in manufacturing IDG: Compustat: B E A Firm effects account for half of the productivity benefits of earlier study IDG; Informationweek IT has excess return; IT staff‘s substitution (cross sector) effect is large U K survey New technology adoption, cspccially computer use, has a positive impact on output and productivity
200
ERIK BRYNJOLFSSON AND SHINKYU YANG
be attributed to transactional types of information technology (e.g., data processing), but was unable to identify gains associated with strategic systems (e.g., sales support) or informational investments (e.g., e-mail infrastructure). In a series of studies utilizing large firm-level surveys by International Data Group (IDG), Brynjolfsson and Hitt report that IT improves productivity. Their 1993 study found that while the gross marginal product of noncomputer capital ranges from 4.14 to 6.86%, that of computer capital averages 56 to 68%. The results of this and their later study (Hitt and Brynjolfsson, 1994) imply that the following three null hypotheses can be rejected: H1: IT capital has a zero gross marginal product. H2: IT capital has zero net marginal benefit, after all costs have been subtracted. H3: IT capital’s marginal product is not different from that of other capital. Their point estimates of gross marginal products indicate that at the margin computer capital generates 10 times more output than other capital of equal value. Brynjolfsson and Hitt (1995) show that up to half of the excess returns imputed to IT could be attributed to firm-specific effects. If gross marginal product of information technology capital is really so large, what friction or market failure prevents firms from investing in more computers, until the marginal products of all capital goods become equal?I6 One reason is that computer capital has a higher user cost. According to Oliner and Sichel (1994), from 1970 to 1992 the user cost of computer capital averaged 36.6% per year, while that of other types of capital was 15.4%.” The remaining portion of the answer may come from adjustment or hidden costs of information technology investment, such as the complementary organizational investments required to realize the benefits of IT.’’ Lichtenberg (1995) confirms the results of Brynjolfsson and Hitt, using similar data and methods. He also analyzes Informationweek survey data and uncovers essentially the same results. His formal tests reject the above null hypotheses. Importantly, Lichtenberg extends his study to report the See, for example, Robert J. Gordon’s comment on Oliner and Sichel (1994). The differential is largely due to the rapid decline in computer prices. Take 60% per year as Brynjolfsson and Hitt’s (1993) estimate of gross marginal product of information technology capital. IT’S marginal product is more than 50% higher than that of other types of capital. About 20% (36.6-15.4%) is explained by the user costs of capital differential. Because the unexplained portion is large, we may expect a considerable amount in adjustment costs when implementing IT investment-annual 30% of computer capital stock. I‘
’*
INFORMATION TECHNOLOGY AND PRODUCTIVITY
20 1
marginal rate of substitution between IT and non-IT workers. A t the sample mean, one IT worker can apparently be substituted for six non-IT workers. Research in manufacturing generally finds higher returns t o IT investment than in the services, probably because of better measurement. Yet the MPIT data, which both Loveman (1994) and Barua et al. (1991) use, must be scrutinized. Although the point estimates for IT’S contribution were quite low, the standard errors were very high so that the 95% confidence interval often exceeded 2200% for Loveman’s estimates. These studies may also be unrepresentative, since the period covered by the MPIT data, 1978-83, was unusually turbulent. The IDG data set, which is among the largest data sets used in this research area, substantially mitigates data problems, although it contains data on large firms only, and so may not be a representative random sample. Indeed, Brynjolfsson and Hitt (1993) attribute the statistical significance of their findings partly to the large size of the IDG data set, which enables them to more precisely estimate returns for all factors. Utilizing comprehensive surveys of the UK engineering industry undertaken in 1981, 1986, and 1993, Kwon and Stoneman (1995) also find that the use of computers and numerical control machines has increased output and productivity.
5. Contribution to Consumer Surplus and Economic Growth Some researchers have identified sizable contributions of IT t o consumer surplus and to economic growth. Some important studies are summarized in Table VII. Growth accounting and consumer surplus analysis are techniques t o identify and measure “pecuniary externalities,” which Griliches (1992,1994) distinguishes from “non-pecuniary externalities of spill-overs.’’ Pecuniary externalities arise when the price of some input declines. For example, when computer prices are declining exogenously, profit-maximizing firms substitute computer systems for other input factors, such as labor or warehouse space. Lowered prices of computers and other inputs shift marginal cost curves downward. These marginal cost curves result in higher output and lower prices. The output increase is a measure of the pecuniary externality; the benefits created by the computer sector are reflected in greater output of computer-using industries. A second measure of the pecuniary externality is consumer surplus. As computer prices fall, many firms and customers that could not afford computers become able to purchase them, whereas the customers who were willing to pay higher prices enjoy a windfall of price reduction.
202
ERIK BRYNJOLFSSON AND SHINKYU YANG
TABLE VII STUDIESO N CONTRIBUTION TO CONSUMER SURPLUS A N D ECONOMIC GROWTH
Study Bresnahan (1986) Lau & Tokutsu (1992) Brynjolfsson & Hitt (1994) Oliner & Sichel (1994) Jorgenson & Stiroh (1995) Brynjolfsson (1995)
Data Source Financial service firms Multiple government sources IDG," Compustat Principally BEA"
Principally BEA BEA
Findings Large gains in imputed consumer welfare Computer capital contributes half of output growth Growth contribution of computers is 1% per year among 367 U S . large firms Growth contribution of computers is 0.16-0.38% per year varying by different assumptions Growth contribution of computers for the 1979-92 period is 0.38-0.52% per year $70 billion consumer surplus is generated annually in the late 1980s.
IDG, International Data Group; BEA, US. Bureau of Economic Analysis.
Pecuniary externalities directly increase labor productivity, yet they do not necessarily increase multifactor productivity. Pecuniary externalities d o not change the production function, rather they change the input mix. In contrast, nonpecuniary externalities, or spill-overs, arise from technical change; people may have found smarter ways of making goods and services using information t e c h n ~ l o g y . The ' ~ production possibility frontier shifts out; both labor productivity and multifactor productivity should go up. Bresnahan (1986) estimated the benefits to consumers of declining computer prices. Using the hedonic price index method?' he calculates that the consumer surplus was five or more times that of computer expenditures in the late 1960s financial sector. Adopting similar assumptions, Brynjolfsson (1995) estimates that, in 1987, between $69 billion and $79 billion consumer surplus was generated by $25 billion in expenditures on information technology capital. Now we turn to several growth accounting results. Jorgenson and Stiroh's (1995) comprehensive growth accounting found that from 1979 to 1985 computers and peripherals contributed to output growth by 0.52% per year, and that from 1985 to 1992, the contribution was 0.38% per year (see Table
''
Bresnahan and Trajtenberg (1995) argue that "general purpose technologies," like computers, engender waves of smaller and complementary innovations. This creates the potential for positive externalities from IT, and thus the possibility that IT investment is too low, compared to the socially optimal level. The hedonic price index method is an attempt to incorporate quality changes when constructing price indices using the regression technique. See Chapter 4 in Berndt (1991).
'"
INFORMATION TECHNOLOGY AND PRODUCTIVITY
203
VIII).21 Because they assume that computers maintain their full ability until retirement, their estimation of computer capital’s contribution becomes larger than that of Oliner and Sichel (1994). Oliner and Sichel(l994) carefully examine how the various excess return hypotheses of computer capital affect growth. As a baseline they estimate that the contribution of computer capital to output growth is 0.16% per year for the 1970-92 period. Using Romer’s (1986, 1987) assumption that physical capital provides a positive externality, the contribution goes up to 0.32%. Brynjolfsson and Hitt’s (1993) higher estimate for the return on computer capital raises the contribution to 0.35%. They also try to incorporate Alan Krueger’s (1993) result of return on workers’ computer use. If the return is equal to the difference in the marginal product between computer-using workers and nonusing workers, the contribution is 0.38%. Oliver and Sichel claim that an annual contribution of up to 0.38% is not large enough to offset the approximately 1% drop in output growth since the 1 9 7 0 ~ ~ ~ The following rough calculation may provide some intuition about the size of the contribution of computers to national output. From Jorgenson and Stiroh (1995), we take the simple average contribution for the 1979-92 period o r 0.45%. We compare it with the 0.72% contribution of other capital. The share of computers in total capital stock was 1.6% in 1993, implying that 1 unit of computer capital contributes as much to the growth of output as 98 units of other forms of capital. In 1993, GDP grew by $173 billion.23 Computers contributed $29 billion; other capital contributed $46 billion. The unexplained residual (MFP) contribution is $40 billion. A rough estimate shows that the implicit marginal product of computer capital in Jorgenson and Stiroh’s study is more than 60%.24 Using data from 367 large firms that together generated $1.8 trillion in output per year from 1982 to 1992, Brynjolfsson and Hitt (1994) provide
*’
The contribution dropped because the growth rate of real computer capital is lower for the 1079-85 period than for the 1985-92 period; nominal investment of computers did not increase much during the 1985-92 period. 22 However, an alternative view is that the glass is half-full; Jorgenson calls 0.38% “a pretty hefty contribution” (personal letter, Feb. 7, 1995). 23 Survey of Current Business, March 1994, Table 1-1, nominal dollars. 24 One of the standard growth accounting assumptions is that factors are paid according to their marginal product. Jorgenson and Stiroh report 0.38% growth contribution for the period 1985-92. The 0.38% is computers’ nominal income share times computer capital’s growth rate. By their data, we can also estimate computer capital’s growth rate during the 1985-87 period (24%).Now computers’ nominal income share is equal to (computers capital’s marginal product X computer capitaliGDP). In 1987, computer capital stock amounted to $1 13.24 billion and GDP was $4.5399 trillion, thus the implicit marginal product of computers is estimated to 63% = (0.38%)* ($4539.9/$113.24)/(24%).
TABLEVIII GROWTH RATESOF AGGREGATE OUTPUTA N D CONTRIBUTION OF FACTORS (1947-92) Value Added
Growth Contribution
Variable Period
Annual Growth
Noncomp Share
Computer Share
Capital
Noncomp Share
Computer Share
Labor
Multifactor Productivity
47-92 47-53 53-57 57-60 60-66 66-69 69-73 73-79 79-85 85-92
3.42 5.46 2.14 2.39 5.38 2.61 3.67 2.63 2.89 2.49
3.33 5.46 2.14 2.37 5.30 2.54 3.60 2.50 2.65 2.38
0.09 0.00 0.00 0.02 0.08 0.07 0.08 0.12 0.24 0.12
1.47 1.92 1.42 0.83 1.46 1.93 1.64 1.45 1.28 1.26
1.26 1.92 1.42 0.83 1.36 1.74 1.40 1.19 0.76 0.88
0.21 0.00 0.00 0.00 0.10 0.20 0.24 0.26 0.52 0.38
0.92 1.26 0.19 -0.01 1.44 1.16 0.74 1.28 0.83 0.76
1.03 2.27 0.53 1.57 2.48 -0.49 1.29 -0.10 0.78 0.47
~
~
~
Source: Adapted from Jorgenson and Stiroh (1995).
INFORMATION TECHNOLOGY AND PRODUCTIVITY
205
an interesting growth accounting result. For their sample of firms, IT capital contributes about 1%per annum to output growth-a larger growth contribution than that of ordinary capital in absolute value. Lau and Tokutsu (1992) calculate an even bigger contribution to growth, attributing approximately half of the real output growth (1.5% growth per annum) during the past three decades to computer capital. They also argue that the annual rate of inflation dropped by 1.2% per year because of the rapid decline in computer prices. In line with these studies, Roy Radner suggests that “productivity growth has slowed down for other reasons, unrelated to the IT story. Without IT, things would have been worse, and output growth would have been lower” (Griliches, 1995). In summary, the weight of evidence from various studies indicates that information technology capital generates billions of dollars annually for the U.S. economy, both in terms of output growth and consumer surplus. Meanwhile, the recent firm-level analyses of Brynjolfsson and Hitt (1993, 1995) and Lichtenberg (1995) have begun to remedy the shortfall of evidence regarding the productivity contribution of IT.
6. Conclusion: Where Do We Go from Here? Sections 2, 3 , 4, and 5 reviewed the principal empirical literature on the productivity of information technology. Looking at the simple relationship between the productivity slowdown of the whole U.S. economy and the rapid growth of computer capital is too general an approach. Poor data quality for IT outputs and inputs has exacerbated this problem. Due to the application of improved methodologies and the identification of more reliable and larger data sets, researchers have made some progress with industry-level and firm-level studies. Recently, some researchers have found positive effects of IT. Careful growth accounting exercises and estimation of production and cost functions for specific sectors or industries can provide sharper insights. Consumer surplus analyses are useful exercises for identifying alternative ways to triangulate IT value. These studies suggest that without IT, the U.S. economy would probably be in a worse situation than it is. This section proposes further research questions and methodologies. The first priority is to improve the data and the measurement techniques. Government statistics, especially in services and for information workers, have not kept up with the growing importance and complexity of these sectors. Therefore, researchers may have to perform their own corrections on the data, turn to private sources of secondary data, or gather data themselves. Researchers should make their data available to other researchers so that a cumulative tradition can be maintained. The studies of Weill
206
ERIK BRYNJOLFSSON AND SHINKYU YANG
(1992), Dos Santos et al. (1993), and Brynjolfsson and Hitt (1993, 1995) are examples of new data identification and development. One effective way to identify possible gaps in the data is to compare them with the benefits that managers and customers expect from IT, such as quality, timeliness, customer service, flexibility, innovation, customization, and variety. In principle, many of these benefits are quantifiable. In fact, some firms already attempt such an analysis in their capital budgeting and justification processes. In addition, many companies have developed elaborate measurement programs, for example, as part of total quality management. These programs augment or even supersede financial accounting measures and can serve as a foundation for more refined metrics (Kaplan and Norton, 1992). Many economists also have tried various methods to overcome the shortfall of government statistics, and to incorporate quality changes when estimating price indices. The long history of hedonic price index method is a good example, but some economists argue that even the hedonic method does not capture all the benefits associated with product innovation and differentiation. Trajtenberg (1990) devises a new method of qualityadjusted price index calculation, adopting the discrete choice model.2s Fisher and Griliches (1995) argue that if new inexpensive (quality-adjusted) goods are introduced and gain market share at the expense of existing goods, the official statistics by the BLS will seriously overestimate inflation.26 Hausman (1994) also reports a 20 to 25% overestimation of the consumer price index for ready-to-eat cereals, based on his analysis of Apple Cinnamon Cheerios. Unfortunately, for many services, even basic output measures must be created, because government and accounting data records only inputs. Baily and Gordon (1988) and Noyelle (1990), among others, have done much to improve measurement in areas such as banking and retailing, while relatively good statistics can be compiled from private sources in areas such as package delivery. Unfortunately, the individualized nature of many services defies aggregation. The output of a lawyer, manager, or doctor cannot be extrapolated from the number of meetings attended, memoranda written, or medications provided. The complexity of the “diagnostic-related group” approach to valuing medical care is both a step in the right direction and a testament to these difficulties. A researcher who seeks to measure
*’
For the period of 1973-82, Trajtenberg’s price deflator for the computed tomography scanner industry averages minus 55&; in contrast, the hedonic price index shows a 13%decline and government price statistics indicate a 9% increase. Empirical evidence for their argument is presented in Griliches and Cockburn (1994). They show that the adjusted price index for the cephalexin drug during the 1987-91 period dropped by 30 to 53%; the official figure records a 14% increase.
’‘
INFORMATION TECHNOLOGY AND PRODUCTIVITY
207
rigorously the productivity of service industries generally must undertake this detailed work before jumping to conclusions based on input-based statistics. Similarly, disaggregating heterogeneous types of IT by use, as Weill (1992) did in a manufacturing study, can increase the resolution of standard statistical techniques. Because so many factors affect firm performance, it is generally impossible to distinguish the impact of IT using simple bivariate correlations, It is essential to control for other factors such as other inputs and their prices, the macroeconomic environment, demand schedules for output, and the nature of competition. Because many unobservable factors affect either the whole industry or one firm persistently, examining a panel consisting of both time series and cross-sectional data is the best approach, where feasible. Importantly, we must remember that our tools are still blunt. Managers do not always recognize this and tend to rely too much on any one study of IT and productivity. While the studies usually state the limitations of the data and methods, sometimes only the surprising conclusions are reported by the media. Because significant investment decisions are based on these conclusion^,^^ researchers must be doubly careful to communicate the limitations of their work. Researchers might also look to business for profitable research questions. A recurrent theme in the business press is the idea that information technology should not so much help us produce more of the same things as allow us to do entirely new things in new ways.28 For instance, Watts (1986) finds that information technology investments cannot be justified by cost reductions alone, but that instead managers should look to increased flexibility and responsiveness, whereas Brooke (1992) writes that information technology leads to greater variety but lower productivity as traditionally measured. Diewert and Smith’s (1994) study makes another interesting point with respect to variety. They show that while IT facilitates great efficiency in inventory management, aggregate inventory level of the U S . economy did not shrink during the past 40 years, as reported by Blinder and Maccini (1991). Diewert and Smith argue that “a wide spread proliferation of new products into the world economy” results in no macro-level inventory change even when great micro-level improvements have been made. 27 For instance. the stock prices of major IT vendors appeared to change significantly in response to a Wall Street Journal article on IT productivity (Dos Santos et al., 1991). ” See, for example, Applegate and Mills (1988). Benjamin era/. (1984), Champy (1995). Cecil and Hall (1988) Davenport (lYY3), Hammer and Champy (19Y3), Malone and Rockart (1991), Porter and Miller (1985), and Watts (1986).
208
ERIK BRYNJOLFSSON AND SHINKYU YANG
This literature highlights how difficult and perhaps inappropriate it would be to translate some of the benefits of information technology into quantifiable productivity measures of output. Intangibles such as better responsiveness to customers and increased coordination with suppliers do not always increase the amount or even intrinsic quantity of output, but they do help make sure it arrives at the right time, at the right place, with the right attributes for each customer. Berndt and Malone (1995) suggest that “we need to spend more effort measuring new forms of value-such as capabilities for knowledge creation-rather than refining measures of productivity that are rooted in an Industrial Age mindset.” Just as managers look beyond “productivity” for some of the benefits of IT, so must researchers be prepared to look beyond conventional productivity measurement techniques. For instance, because consumers are generally assumed to be in the best position to assess the utility they gain from their purchases, so researchers might look to IT buyers for an estimate of I T value, as Bresnahan (1986) and Brynjolfsson (1995) did. As another example, if rational investors value both the tangible and intangible aspects of firms’ revenue-generating capacity, then changes in stock market value should approximate the true contribution of IT to the firm, not only in cost reductions, but also in increased variety, timeliness, quality, and, in principle, even in the effectiveness of the firm in foreseeing and rapidly adapting to its changing en~ironment.’~ While relying on consumer or stockholder valuations begs the question of actual IT productivity to some extent, at a minimum these measures provide two additional benchmarks that can help triangulate IT value (Hitt and Brynjolfsson, 1994). While the value of IT remains controversial, it is clear that the measurement problem is becoming more severe. Developed nations are devoting increasing shares of their economies to service- and information-intensive activities for which output measures are poor.’O The emerging “information age” has promoted a new approach to management accounting (Beniger, 1986; Kaplan, 1989). Similarly, researchers should take the opportunity to rethink how we measure productivity and output. ACKNOWLEDGMENTS
This research was sponsored by the MiT Center for Coordination Science, the MIT International Financial Services Research Center, and the Sloan Foundation. Portions of this paper 29 Unfortunately, stock market valuation also reflects the firm’s relative market power, so where IT leads to more efficient markets or greater customer bargaining power, the relationship between IT and stock price is ambiguous. 3o The BEA’s SIC codes classify manufacturing in relatively rich detail; only the broadest measures exist for services, which comprise more than 80% of the economy.
INFORMATION TECHNOLOGY AND PRODUCTIVITY
209
are based on an article titled, “The Productivity Paradox of Information Technology,” which originally appeared in Communications of the ACM, in December 1993. Special thanks to Lorin Hitt and Miriam Avins for numerous valuable comments.
REFERENCES Ahituv, N., and Giladi, N. (1993). Business success and information technology: Are they really related. Proc. 7th Annual Conference of Management IS, Tel Aviv University. Allen, T. J., and Scott Morton, M. S. (1994). Information Technology and the Corporation of the IYYOs, Oxford University Press. Alpar, P., and Kim, M. (1991). A microeconomic approach to the measurement of information technology value. Journal of Management Information Systems 7(2), 55-69. Alpar,P., and Kim, M. (1990). A comparison of approaches to the measurement of information technology value. Proc. Twenty-Second Hawaii International Conference on System Science, Honolulu, HI. Applegate, L., Cash, J., and Mills, D. Q. (1988). Information technology and tomorrow’s manager. Harvard Business Review, November-December, pp. 128-136. Attewell, P.. and Rule, J. (1984). Computing and organizations: What we know and what we don’t know. Communications of the ACM. 27,1184-1192. Ayres, R. U. (1989). Information, computers, CIM and productivity. Organization for Economic Co-operation and Development Paper (June). Baily, M. N. (1986a). Taming the information monster. Bell Atlantic Quarterly, Summer, pp. 33-38. Baily, M. N. (1986b). What has happened to productivity growth?” Science 234, 443-451. Baily, M. N., and Chakrabarti, A. (1988). Electronics and white-collar productivity. In Innovation and Productivity Crisis, Brookings Institution, Washington, DC. Baily, M. N., and Gordon, R. J. (1988). The productivity slowdown, measurement issues and the explosion of computer power. Brookings Papers in Economic Activity (2), 347-431. Bakos, J . Y. (1987). “Inter-organizational information systems: Strategic implications for competition and cooperation.” Ph.D. Dissertation, MIT School of Management. Bakos, J. Y., and Kemerer, C. F. (1992). Recent application of economic theory in information technology research. Decision Support System 8, 365-386. Banker, R. D., and Kauffman, R. J. (1988). Strategic contributions of information technology: An empirical study of ATM networks. Proc. Ninth International Conference on Information Systems, Minneapolis, Minnesota. Barua, A,, Kriebel, C., and Mukhopadhyay, T. (1991). Information technology and business value: An analytic and empirical investigation. University of Texas at Austin Working Paper (May). Baumol, W. J. (1967). Macroeconomics of unbalanced growth: The anatomy of urban crisis. American Economic Review 57(3), 415-426. Baumol, W. J., Blackman, S. A,, and Wolff, E. N. (1985). Unbalanced growth revisited: Asymptotic stagnancy and new evidence. American Economic Review 74(4), 806-81 7. Bender, D. H. (1986). Financial Impact of Information Processing. 3(2), 22-32. Beniger. J. (1986). The Control Revolution. Harvard University Press, Cambridge, MA. Benjamin, R. I., Rockart, J. F., Scott Morton, M. S., et al. (1984). Information technology: A strategic opportunity. Sloan Management Review, Spring, pp. 3-10. Berman, E.. Bound, J., and Griliches. Z. (1994). Changes in the demand for skilled labor within U.S. manufacturing: Evidence form the annual survey of manufacturers. Quarterly Journal of Economics 109(2), 361-397.
210
ERIK BRYNJOLFSSON AND SHINKYU YANG
Berndt, E. R. (1991). The Practice of Econometricx Classic and Contemporary, AddisonWesley, Reading. MA. Berndt, E. R.. and Malone, T. W. (1995). Information technology and the productivity paradox: Getting the questions right; guest editor’s introduction to special issue. Economics of Innovation and New Technology 3, 177-182. Berndt, E. R.. and Morrison, C. J. (1995). High-tech capital formation and economic performance in 17,s.manufacturing industries: An exploratory analysis. Journal of Econometrics 65, 9-43. Berndt, E. R., and Morrison, C. J. (1991). Computers aren’t pulling their weight. Compurerworld, December 9. pp. 23-25. Berndt. E. R., Morrison, C. J.. and Rosenblum. L. S . (1992). High-tech capital formation and labor composition in U.S. manufacturing industries: An exploratory analysis. National Bureau of Economic Research Working Paper No. 4010 (March). Blinder, A. S . . and Maccini, L. J. (1991). Taking stock: A critical assessment of recent research on inventories. Journal of Economic Perspcctives 5,73-96. Brand, H.. and Duke, J. (1982). Productivity in commercial banking: Computers spur the advance. Monthly Labor Review 105, 19-27 (December). Bresnahan, T. F. (1986). Measuring spillovers from technical advance: Mainframe computers in financial services. American Economic Review 76(4). Bresnahan, T. F., and Trajtenberg. M. (1995). General purpose technologies and aggregate growth. Journal of Econonietrics 65, 83-108. Brooke, G. M. (1992). The economics of information technology: Explaining the productivity paradox. MIT Sloan School of Management Center for Information Systems Research Working Paper No. 238 (April). Brynjolfsson, E. (1995). Some estimates of the contribution of information technology to consumer welfare. MIT Sloan School of Management Working Paper (August). Brynjolfsson, E. (1994). Technology’s true payoff. Informationweek, October 10, pp. 34-36. Brynjolfsson, E. (1 993). The productivity paradox of information technology: Review and assessment. Comniiinications of ACM 36( 12). 67-77. Brynjolfsson, E., and Hitt, L. (1996). Paradox lost? Firm-level evidence on the returns to information systems spending. Management Science (April). Brynjolfsson, E., and Hitt, L. (199.5). Information technology as a factor of production: The role of differences among firms. Econoniics of Innovation and New Technology 3,183-199. Brynjolfsson, E., and Hitt, L. (1994). Computers and economic growth: Firm-level evidence. MIT Sloan School of Management Working Paper No. 3714 (August). Brynjolfsson, E., and Hitt, L. (1993). Is information systems spending productive? New evidence and new results. Proc. 14th International Conference on Information Systems, Orlando, FL. Brynjolfsson, E., Malone, T.. Gurbaxani. V.. and Kambil. A. (1991). Does information technology lead to smaller firms’! Management Science 40(12), 1628-1644. Champy. J. (1995). Reengineering Managemenl, HarperBusiness, New York. Cecil, J. L.. and Hall, E. A. (1988). When IT really matters to business strategy. McKinsev Quarterly, Autumn, p. 2. Chismar, W. G., and Kriebel, C. H. (1985). A method for assessing the economic impact of information systems technology on organizations. Proc. Sixth International Conference on Information Systems. Indianapolis, IN. Clarke, R. F. (1985). “The application of information technology in an investment managcment firm.” Masters Thesis, Massachusetts Institute of Technology. Cambridge, MA. Clemens, E. K. (1991). Evaluation of strategic investment in information technology. Communicarions of the ACM 34(1), 22-36.
INFORMATION TECHNOLOGY AND PRODUCTIVITY
21 1
Cooper, R. B., and Mukhopadhyay, T. (1990). Research in MIS effectiveness: A microeconomic production view. Carnegie Mellon University Working Paper. Cron, W. L., and Sobol, M. G. (1983). The Relationship Between Computerization and Performance: A Strategy for Maximizing the Economic Benepts of Computerization. Vol. 6, 171- 181. Crowston, K., and Malone, T. W. (1988). Information technology and work organization. Chapter 49 in Handbook of Human-Computer Interactions (M. Helander, Ed.). Elsevier Science, Amsterdam. pp. 1051-1070. Crowston, K., and Treacy. M. E. (1986). Assessing the impact of information technology on enterprise level performance. MIT Center for Information Systems Research Working Paper No. 143 (October). Curley, K. F., and Pyburn, P. J. (1982). Intellectual technologies: The key to improving whitecollar productivity. Sloan Management Review, Fall, pp. 31 -39. Davenport, T. H. (1993). Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press, Boston. Davenport, T. H. and Short, J. (1990). The new industrial engineering: Information technology and business redesign. Sloan Management Review 31(4), 11-27. David, P. A. (1990). The dynamo and the computer and dynamo: A historical perspective on the modern productivity paradox. American Economic Review 80(2), 355-361. Denison. E. E. (1989). Estimates of productivity change by industry. an evaluation and an alternative. Brookings Institution, Washington, DC. Denison, E. E. (1985). Trends in American economic growth, 1929-1982. Brookings Institution. Washington. DC. Diewert. W. E., and Smith, A. M. (1994). Productivity measurement for a distribution firm. National Bureau of Economic Research Working Paper No. 4812 (July). Dos Santos, B. L., Peffers, K. G.. and Mauer, D. C. (1993). The impact of information technology investment announcements on the market value of the firm. Information Systems Research 4(1), 1-23. Dos Santos. B. L., Peffers, K. G., and Mauer, D. C. (1991). The value of investments in information tcchnology: An event study. Kannert Graduate School of Management, Purdue University. Dudley, L., and Lasserre, P. (1989). Information as a substitute for inventories. European Economic Review 31, 1-21. Dulberger, E. R. (1989). The application of hedonic model to a quality adjusted price index for computer processors. In Technology and Capital Formation (Jorgenson and Landau, Eds.), MIT Press, Cambridge, MA. Fisher, F. M., and Griliches, Z. (1995). Aggregate price indices, new goods, and generics. Quarterly Economics CX(l), 229-244. Franke, R. H. (1987). Technological revolution and productivity decline: Computer introduction in the financial industry. Technological Forecasting and Social Change 31, 143-154. Gordon, R. J. (1990). The Measurement of Durable Goods Prices. University of Chicago Press, Chicago (see especially Chapter 6, Electronic Computers). Gordon, R. J. (1987a). Productivity, wages, and prices inside and outside of manufacturing in the U.S.,Japan, and Europe. European Economic Review 31(3). 685-739. Gordon, R. J. (1987b). The postwar evolution of computer prices. National Bureau of Economic Research Working Paper No. 2227. Gordon, R. J., and Baily, M. N. (1989). Measurement issues and the productivity slowdown in five major industrial countries. International Seminar on Science, Technology and Economic Growth, Paris, France.
212
ERIK BRYNJOLFSSON AND SHINKYU YANG
Gremillion, L. L., and Pyburn, P. J. (1985). Justifying decision support and office automation systems. Journal of Management Information Systems 2( 1). Griliches, Z. (1995). Comments on measurement issues in relating IT expenditures to productivity growth. Economics of Innovation and New Technology 3, 317-321. Griliches, Z. (1994). Productivity, R&D. and data constraints. American Economic Review
W). Griliches, Z. (1992). The search for R&D spillovers. Scandinavian Economics 94, Supplement, pp. 29-47. Griliches, Z., and Cockburn, I. (1994). Generics and new goods in pharmaceutical price indexes. Americun Economic Review LXXXIV. Griliches, Z. (Ed.) with the assistance of Ernst R. Berndt, Timothy F. Bresnahan, and Marilyn E. Manser. (1992). Output Measurement in the Service Sectors. NBER Studies in Income and Wealth, Vol. 56. University of Chicago Press. Grove, A. S. (1990). The future of the computer industry. California Management Review 33(1), 148-160.
Gurbaxani, V.. and Mendelson. H. (1989). The use of secondary data in MIS research. University of California, Irvine. Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, July-August, pp. 104-1 12. Hammer, M., and Champy, J. (1993). Reengineering the Corporation, HarperBusiness, New York. Harris, S. E., and Katz, J. L. (1991). Organizational performance and information technology investment intensity in the insurance industry. Organizational Science 2(3), 263-296. Hausman, J. A. (1994). Valuation of new goods under perfect and imperfect competition. National Bureau of Economic Research Working Paper No. 4970 (December). Hitt, L., and Brynjolfsson, E. (1994). Three faces of IT value: The theory and evidence. Proc. Fifteenth International Conference on Information Systems, December. Jonscher, C. (1994). An economic study of the information technology revolution. In Information Technology and the Corporation of the 1990s: Research Studies (Thomas J. Allen and Michael S. Scott Morton, Eds.), Oxford University Press, pp. 5-42. Jonscher, C. (1983). Information resources and economic productivity. Information Economics and Policy 1, 13-35. Jorgenson, D. W., and Landau, R. (Eds.) (1989). Technology and Capital Formation, MIT Press, Cambridge, MA. Jorgenson, D. W., and Stiroh, K. (1995). Computers and growth. Economics of Innovation and New Technology 3,295-316. Kaplan, R. (1989). Management accounting for advanced technological environments. Science 245, 819-823.
Kaplan, R., and Norton, D. P. (1992). The balanced scorecard-Measures that drive performance. Harvard Business Review, January-February, pp. 71-79. Katz, L. F., and Krueger, A. B. (1994). How computers have changed the workplace, 19841993. Unpublished paper, Harvard University. Kemerer, C. F., and Sosa, G. L. (1YY1). Systems development risks in strategic information systems. Information and Software Technology 33(3), 212-223. Kriebel, C. H. (1989). Understanding the strategic investment in IT. In Information Technology and Management Strategy (K. Lauden and J. A. Turner, Eds.), Prentice Hall, Englewood Cliffs, NJ. Krueger, A. B. (1993). How computers havc changed the wagc structure: Evidence from micro-data, 1984-1989. Quarterly Journal of Economics 108(1), 33-60.
INFORMATION TECHNOLOGY AND PRODUCTIVITY
213
Kwon, M. J., and Stoneman, P. (1995). The impact of technology adoption on firm productivity. Economics of Innovation and New Technology 3,219-233. Landauer, T. K. (1995). The Trouble with Computers, The MIT Press, Cambridge, MA. Lasserre, P. (1988). Project on the impact of information on productivity. Unpublished Paper, MIT. Lau, L. J., and Tokutsu, I. (1992). The impact of computer technology on the aggregate productivity of the United States: An indirect approach. Unpublished Paper. Stanford University. Lichtenberg, F. R. (1995). The output contributions of computer equipment and personnel: A firm-level analysis. Economics of Innovation and New Technology 3, 201-217. Loveman, G. W. (1994). An assessment of the productivity impact of information technologies. In Information Technology and the Corporation of the 1990s: Research Studies, (Thomas J. Allen and Michael S. Scott Morton, Eds.), Oxford University Press, pp. 84-110. Malone, T., and Rockart, J. (1991). Computers, networks and the corporation. Scientific American 265(3), 128-136. Mark, J. A. (1982). Measuring productivity in the service sector. Monthly Labor Review, June. McKersie, R. B., and Walton. R. E. (1991). Organizational change. In The Corporation of rhe 1990s (M. S. Scott Morton, Ed.), Oxford University Press, pp. 244-277. Morrison, C. J.. and Berndt, E. R. (1991). Assessing the productivity of information technology equipment in U.S. manufacturing industries. National Bureau of Economic Research Working Paper No. 3582 (January). Nelson, R. R. (1981). Research on productivity growth and productivity differences: Dead ends and new departures. Journal of Economic Literature 29, 1029-1064. Noyelle, T. (1990). Skills, Wages, and Productivity in the Service Sector. Westview Press, Boulder, CO. Oliner, S. D., and Sichel, D. E. (1994). Computers and output growth revisited: How big is the puzzle? Brookings Papers on Economic Activity (2), 273-334. Osterman, P. (1986). The impact of computers on the employment of clerks and managers. Industrial and Labor Relations Review 39, 175-186. Parsons, D. J.. Gotlieb, C. C., and Denny, M. (1990). Productivity and computers in Canadian banking. University of Toronto Department of Economics Working Paper No. 9012 (June). Porat, M. (1977). The Information Economy: Definition and Measurement. U S . Government Printing Office, Washington, DC. Porter, M. E., and Miller, V. E. (1985). How information gives you competitive advantage. Harvard Business Review, July-August, pp. 149-1 60. Pulley, L. B., and Braunstein, Y. M. (1984). Scope and scale augmenting technological change: An application in the information sector. Juswalla and Ebedfield. Roach, S. S. (1991). Services under siege: The restructuring imperative. Harvard Business Review 39(2), 82-92. Roach, S. S. (1989a). Pitfalls of the new assembly line: Can service learn from manufacturing? Morgan Stanley Special Economic Study, New York (June 22). Roach, S. S. (1989b). America’s white-collar productivity dilemma. Manufacturing Engineering, August, pp. 104. Roach, S. S. (1987). America’s technology dilemma: A profile of the information economy. Morgan Stanley Special Economic Study (April). Romer, P. M. (1987). Crazy explanations for the productivity slowdown. In NBER Macroeconomics Annual: I987 (Stanley Fisher, Ed.). MIT Press, Cambridge, MA. Romer, P. M. (1986). Increasing returns and long-run growth. Journal of Political Economy 94(5), 1002-1037.
214
ERIK BRYNJOLFSSON AND SHINKYU YANG
Scherer, F. (1980). Industrial Market Structure and Economic Performance, Rand-McNally, Chicago. Schneider, K. (1987). Services hurt by technology: Productivity is declining. The New York Times, June 29, pp. D1, D6. Scott Morton, M. S . (Ed.) (1991). The Corporation of the 1990s: Information Technology and Organizational Transformation. Oxford University Press. Siegel, D. (1994). The impact of computers on manufacturing productivity growth: A multipleindicators, multiple-causes approach. SUNY at Stony Brook Working Paper (May). Siegel, D., and Griliches, Z. (1992). Purchased services, outsourcing, computers, and productivity in manufacturing. In Output Measurement in the Service Sectors ( Z . Griliches et al., Eds.), University of Chicago Press, Chicago. Snow, C . P. (1966). Government science and public policy. Science 151,650-653. Stabell, C. B. (1982). Office productivity: A microeconomic framework for empirical research. Office: Technology and People 1,91-106. Strassmann, P. A. (1 990). The Business Value of Computers: A n Executive’s Guide. Information Economics Press, New Canaan, CT. Strassmann, P. A. (1985). Information Payoff The Transformation of Work in the Electronic Age. Free Press, New York. Thurow, L. (1987). Economic paradigms and slow American productivity growth. Eastern Economic Journal 13,333-343. Trajtenberg, M. (1990). Product innovations, price indices and the (mis)measurement of economic performance. National Bureau of Economic Research Working Paper No. 3261 (February). Watts, L. (1986). What price automation? Northeastern University Alumni Magazine, pp. 21-24. Weill, P. (1992). The relationship between investment in information technology and firm performance: A study of the valve manufacturing sector. Information Systems Research 3(4), 307-333. Weitzendorf, T., and Wigand, R. (1991). Tasks and decisions: A suggested model to demonstrate benefits of information technology. Institute for Information Science Working Paper, Graz, Austria. Wilson, D. D. (1995). IT investment and its productivity effects: An organizational sociologist’s perspective on directions for future research. Economics of Innovation and New Technology 3,235-251. Zachary, G. P. (1991). Computer data overload limits productivity gains. Wall Srreet Journal, November 11, p. B1.
The Complexity of Problems WILLIAM GASARCH Department of Computer Science University of Maryland College Park, Maryland
Abstract We investigate problems that arise in computer science in terms of their execution times. We are concerned with both upper bounds (which are demonstrated by algorithms) and lower bounds (which are demonstrated by proof) on the execution time. The problems we study come from three realms. First, we investigate problems where getting an exact answer is important and can be done quickly. Finding the maximum element of a list is such a problem. Second, we investigate problems where getting a feasible solution (or showing that one cannot be obtained) is of interest. The problem of two-coloring a graph is feasible, while the problem of three-coloring a graph is thought to not be feasible. Third, we investigate problems that cannot be solved. Even in this realm one can have a notion of one problem being harder than another.
1 . Introduction. . . . . . . . . . . . . . , . . . . . . . . . 1.1 Definitions and Notation . . . . . . . . . . . . . . . 2. Decision Trees. . . . . . . . . . . . . . . . . . . . . . . 2.1 Finding the Maximum. . . . . . . . . . . . . . . . . 2.2 Finding the ith Largest Element . . . . . . . . . . . . 2.3 MED, . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 HI-LO,. . . . . . . . . , , . . . . . , . . . . . . 2.5 SORT,,. . . . . , , . . . . . . . . . . . . . . . . . 2.6 Questioning the Model . . . . . . . . . . . . . . . . 3. P versus NP. . . . . . . . . . . . . . . . . . . . . . . . 3.1 Polynomial Time and Nondeterministic Polynomial Time 3.2 The Relevance of NP-Completeness . . , . . . . . . . 3.3 So Your Problem Is NP-complete . . . , . . . . . . . 4. Decidable, Undecidable, and Beyond . . . . . . . . . . . . 4.1 Unsolvable Problems . . . . . . . . . . . . . . . . . 4.2 Logical Theories . . , . . . . . , . . . , . . . . . . 4.3 Recursively Enumerable Sets . . . . . . . . . . . . . 4.4 Reductions . . . . . . . . . . . . . . . . . . . . . . 4.5 The Arithmetic Hierarchy . . . . . . . . . . . . . . .
215 ADVANCES IN COMPUTERS. VOL. 43
. . .. . . . . . . . . . . . . . . , . . . . .
. . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . ...
. 216 .
217
. 218 . 218 . 220 221
. 222
.
.
. . . . . . . . . .
223 223 225 227 230 232 233 233 234 236 237 238
Copyright Q 1996 by Academic Press. Inc. All rights of reproduction in any form reqerved.
216
WILLIAM GASARCH
5. S u m m a r y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
239 240
1. Introduction A fundamental question in computer science is (informally) “Given a problem A, how much time will it take to solve it?”
Typical problems are (1) sorting a list of numbers, (2) given constraints on availability of timeslots and locations, schedule classes t o take exams, and ( 3 ) given a program, determine if it is going to halt. We usually do not know exactly how much time it takes to solve a problem. Hence we try to get upper and lower bounds on the time. For x, an input for A , let n, be an appropriate measure of the size of x. For example, if A is the problem of sorting a list of numbers then x would be a list and n, would be the number of elements on the list. We can state our fundamental questions more formally as follows: 1. Find an algorithm d for A and a function U such that d ( x ) terminates within U(n,) steps. The function U is an upper bound. 2. Find a function L such that for all algorithms d for A there is some x such that d ( x ) will take at least L(n,) steps. The function L is a lower bound. 3. We would like L and U to be close to each other. If L = U then we have pinned down the complexity of the problem exactly. Item 1 is commonly done in computer science both formally and informally. Item 2 requires mathematical precision. For example, the statement “Sorting requires at least n log n steps” lacks precision since the notion of “step” is not well defined. A model 0.f computation is needed. This model will specify what operations are allowed and how much they cost. In the case of sorting we will define a decision tree (see Definition 2.2), which counts a comparison as one step, data movement is free, and no other numeric operations are allowed. Having defined this model we can now make meaningful statements like “sorting requires at least n log n comparisons.” The model should be chosen such that all of the algorithms known for the problem fit the model. This leads to meaningful lower bounds that can be stated informally as follows: The types of algorithms that have been used to solve problem A in the past cannot take less than L ( n ) steps. This kind of statement is helpful in several ways:
THE COMPLEXITY OF PROBLEMS
217
1. No more energy should be wasted trying to obtain performance better than L ( n ) using the usual approach. 2. If better performance is needed you may consider changing the problem. 3. The model and lower bound together clarify the assumptions and limitations of the underlying technology. This may lead to alternative technology. For example, if only comparisons are used then sorting n numbers requires n log n comparisons; however, if arithmetic operations are allowed, this can be improved. In this article we investigate problems in terms of models for algorithms for them, and upper and lower time bounds on those models. We do not present proofs, however, references for such are given. We study three realms: 1. Decision trees: The decision tree model of complexity is appropriate when we want to know the exact complexity up to additive constants. A standard problem for this model is that of finding the maximum number from a list of numbers. 2. P vs. NP: P and NP are classes of problems to be defined later. They are appropriate for problems where our major concern is feasibility: Can the problem be solved in reasonable time? Two examples: (1) Determining if a graph is connected can be solved in reasonable time. (2) Finding the fastest route through an entire network seems infeasible; most people do not think the problem can be solved in reasonable time. 3. Recursive, recursively enumerable, and the arithmetic hierarchy: These are classes of problems to be defined later. They are appropriate for problems where our major concern is decidability: Can they be solved at all? In addition there are ways of taking undecidable problems and measuring just how undecidable they are.
Definitions and Notation Notation 1.1 N denotes the set (0, 1, 2, . . .} of natural numbers. rn 1.I
Definition 1.2 Let f and g be functions from N to N. 1. f = O ( g ) means that f i s less than g if you ignore constants. Formally there exists c,nOsuch that ( V n 2 no>lf(n) 5 cg(n)l. 2. f = O( g ) means thatfis greater than g if you ignore constants. Formally there exists c,no such that
218
WILLIAM GASARCH
(Vn 2 no)lf(n)
=1 cg(n>l.
3. f = o ( g ) means that f i s much smaller g. Formally lim,, -+
CQ
fo = 0. s(n>
Definition 1.3 If S is a set and n z 1 than S" is a list of n elements from S. The elements need not be distinct.
2. Decision Trees In this section we study simple problems. The algorithms for these problems motivate a simple model of computation (decision trees) on which we can prove matching upper and lower bounds. These problems arise when compiling large data sets. Here are the problems we will consider.
Definition 2.1 Let 1 5 i 5 n. Let S be an ordered domain (e.g., numbers using their natural order or words in alphabetical order). The following functions take n elements from S (formally an element of Sfl) as input. MAX,, (xl, . . . , x,,) is the largest element of (xl,. . . , x,J. SEL;(x,, . . . , x,,) is the ith largest element of (xl, . . . , x,,). MED,(xl, . . . ,x,) is the [;]th element of (x,, . . . , x,,). HI-LO,(x,, . . . , x,) returns both the maximum and minimum element of (x,, . . . , x,,). 5. SORT,,(xl, . . . , x,) returns the elements of (xl,, . . , x,,) in sorted order. rn
1. 2. 3. 4.
2.1
Finding the Maximum
The following algorithm finds MAX,(xl,
. . . , x,,):
tmax := x I fori:= 2 t o n if xi > tmax then tmax := xi output(tmax) The bulk of the algorithm's time is spent making comparisons. We will measure algorithms for MAX,, (and other problems) in terms of the number of comparisons made by the algorithm.
THE COMPLEXITY OF PROBLEMS
x,)
219
Definition 2.2 Let P be any problem whose input is (xl, . . . , E S". A decision tree for P is a full binary tree labeled and interpreted
as follows. (See Fig. 1 for an example of a decision tree that finds the maximum of three elements.) 1. Every nonleaf is labeled with a comparison of the form " x , < x,?" 2. Every leaf is labeled with a potential output. 3. Let ( x l , . . . ,x,) E S". We interpret the tree as an algorithm acting on (XI, . . . , x,) by thinking YES as GO LEFT ON THE TREE, and N O as GO RIGHT O N TREE. This leads to a leaf of the tree that is labeled with the answer P(xl, . . . , x,,).
Definition 2.3 A problem P can be solved with f(n) comparisons if there exists a decision tree for P where no branch has more than f ( n ) edges. The algorithm for MAX,, can be phrased as a decision tree where each branch has n - 1 edges. Since we have a model of computation that captures the known algorithm we can pose the question of lower bounds intelligently. This is given as: Theorem 2.4
[ZZJ Let n E N.
1. MAX,, can be solved with n - 1 comparisons. 2. MAX,, cannot be solved with fewer than n - 1 comparisons. In fact, any decision tree that solves MAX,, has at least n - 1 comparisons on X I
<x2
FIG. 1. Decision tree.
220
WILLIAM GASARCH
every branch. Hence the best case and the average case require n 1 comparisons. To summarize, initially an algorithm for MAX, was formulated that took n - 1 comparisons. A model was developed to capture this algorithm, and in that model the algorithm is optimal.
2.2
Finding the ith Largest Element
The problem of MAX, asked for the largest element of a list. We now look at the more general problem of finding the ith largest element of a list. Consider the problem of finding the second largest element of (xlr . . . , x,). The problem can be done in 2n - 3 comparisons: First find x = MAX,(xl, . . . , x,) (using n - 1 comparisons). Then find the maximum of {xI,. . . ,x,} - { x } (using n - 2 comparisons). Is this the best possible? No! We present an algorithm that uses at most n + log n comparisons: 1. Input (xi, . . . , x,). 2. Form a tournament of pairs of comparisons: compare (xI,x2), ( x 3 , x4), etc. Then compare the winners in pairs. Then compare the winners of that competition in pairs. Keep doing this until y l = MAX,(xl, . . . , x,) is found. This will take n - 1 comparisons. Note that this is not the algorithm we used in Section 2.1. While both algorithms find MAX, in n - 1 comparisons, this one leaves behind a residue of information that will be helpful in finding SEL;,(x,, . . , , x,). 3. Replace the element x , that has the value yi in the tournament by - CQ. Redo the part of the tournament that this changes. This takes log n steps and yields the second largest element y2. Note that both algorithms given for finding the second largest element can be expressed as decision trees. Hence, the question of whether you can do better with “the same kind of algorithm” can be expressed intelligently. The next theorem (the i = 2 case) states that the n + log n algorithm is essentially optimal. Theorem 2.5 [S, 171 Let i be a constant. Then the following happens: 1. SEL,!, can be solved with n + (i - 1) log n + O(I) comparisons. (This is similar to the algorithm we gave for finding the second largest element.) 2. There exists a (small) constant c such that, for all i, SELA cannot be solved with fewer than n + (i - 1) log n + c comparisons.
Both the algorithm and the lower bound can be modified to handle the following similar problem: Given a list (xi, . . . , x,) find the lst,
THE COMPLEXITY OF PROBLEMS
22 1
2nd, . . . , and ith largest element. The upper and lower bounds are the same for this problem as they are for SELL except that the additive constant changes. To summarize: we first obtained an algorithm for finding the second largest element of a list that took 2n - 3 comparisons, and we then improved this to n + log n. Both algorithms can be expressed as decision trees. We then stated a theorem that gave matching upper and lower bounds for the general SELX problem, and implied that our algorithm for second largest is optimal.
2.3 MED, In the last section we looked at finding the ith largest element of a list. We thought of i as fixed and n as the measure of size. We now consider the problem of finding the [flth element of a list (the middle or median element). This problem has a different character since i varies with n. If the algorithm in Theorem 2.5 is used to find the median of (x,,. . . , x,) then this will take n + log n = O(n log n ) comparisons. Can we do better? The lower bound in Theorem 2.5 does not apply here since i is not constant. We exhibit an algorithm that finds MED, in linear time. Actually we present an algorithm that will, given ((XI, . . . , x,),i), find the ith largest element of (x,,. . . , x,). We plan on having the program call itself recursively. The algorithm is from [2]: 1. Input((xl, . . . , x,),i). Let A be the array (xl,. , . ,x,). 2. Group the elements into groups of five. There are at most four elements left over. We will ignore them for purposes of exposition. (The choice of five is not important-any odd number larger than three would work.) 3. Find the median of every group of five. (This can be done by the algorithm for SELX.) Put the set of medians into an array B of length roughly f. This step takes c11 comparisons for some constant c. 4. Find the median x of the elements in B. This is done by calling this algorithm recursively. 5. Compare all elements to x. Put the elements that are less than x into an array C,,, and all those that are greater than x into an array C,,. Note that at this point we know j such that x is the jth largest element. If j = i then output(x) and stop. (This could be done in a more spaceefficient manner.) 6. If j < i then we know the ith largest element of A is in the ith largest element of C,,. Call the algorithm recursively on (C,,, i).
222
WILLIAM GASARCH
7. If j > i then we know the ith largest element of A is the ( j - i)th element of C<,. Call the algorithm recursively on (C>*,j - i).
One can show that C<, and C,, both have less than 6 n elements. Hence, if T is the number of comparisons the algorithm makes on arrays of length IZ then
T(n) 5 cn
+ T(:) + T ( 2 ) .
T(n) can be shown (by induction) to be O ( n ) . This algorithm can be expressed by a decision tree. Hence the question of whether it is optimal can be raised intelligently. The following results provide upper and lower bounds on the problem; however, at this time no matching bounds are known. Theorem 2.6
Let n E N.
1. MED, can be solved with 5.43n + O(1) comparisons (See (21. This essentially fine tunes the preceding algorithm.) 2. MED, can be solved with 2.97n + o(n) comparisons. (See (71. This is a rather complicated algorithm. The term o(n) means a function of n that is substantially less than n.) 3. There is a constant c such that MED, cannot be solved with fewer than 2n - c 6 comparisons [ I ] .
2.4
HI-LO,
In Section 2.2 we briefly note that we have upper and lower bounds for the problem of, given (x,, . . . , x,), find the lst, 2nd, . . . , ith largest elements. We consider a variant of this problem, the problem of finding the maximum and the minimum of a list. The problem can be done in 2n - 3 comparisons: First find x = MAX,(x,, . . . , x,) (using n - 1 comparisons). Then find the minimum of {xl, . . . , x,} - {x} (using n - 2 comparisons). Is this the best possible? No! The following algorithm solves the problem with approximately $ comparisons [16]: 1. Input(xl, . . . ,x,). 2. Compare (x,, x2), (x3, x4), etc. This takes 2 comparisons. 3. Let W be the set of elements that were greater and let L be the set of elements that were lesser i2 the comparisons from step 1. Note that Wand L are both of size 2.
THE COMPLEXIW OF PROBLEMS
223
4. Find the maximum element in W. This takes i - 1 and is also the maximum element in the original list. 5. Find the minimum element in L. This takes 5 - 1 and is also the minimum element in the original list.
Clearly this algorithm takes only $ + 0 ( 1 ) comparisons. Since a “trick” allowed us to go from 2n - 3 comparisons to f + O(1) it is entirely plausible that another trick will lower the number of comparisons even further. However, this is not the case [16], as shown in the following: Theorem 2.7 (161 There exists a (small) constant c such that HI-LOn cannot be solved with fewer than $ + c comparisons.
To summarize, the “obvious” algorithm for finding the HI-LO, element of a list turned out to not be optimal. Hence the need for lower bounds on the better algorithm is more acute than usual. Such a lower bound does exist. We end up with matching upper and lower bounds for the general HI-LOn problem.
2.5 SORT, The problem of sorting a list of numbers (or names) is one of the most important problems in computer science. As such it is also one of the most well studied. We make just a few comments on it and urge the interested reader to look at Refs. [ l l ] and [5] for more details. Theorem 2.8
I . The problem of sorting a list of n numbers can be solved in O(n log n) comparisons. (The constant is quite low.) 2. There exists a constant c such that any algorithm for sorting requires at least cn log n comparisons.
2.6 Questioning the Model Now that we have matching upper and lower bounds for several problems it is time to question the model. What if comparisons are replaced by some other type of query? Does this lead to faster algorithms? We can answer this with the following result [14]: Theorem 2.9. If IS1 is large compared to n, then any lower bound obtained for decision trees will apply to decision trees that use any type of query of arity 2, that is, a query that involves two elements at a time.
The two assumptions to question are (1) what if queries of arity larger than 2 are used, and ( 2 ) what if IS1 is not large compared to n?
224
WILLIAM GASARCH
2.6.1 Allowing Other Types of Queries If your machine has powerful processors or perhaps parallelism, then you may be able to do more interesting operations than comparisons in a unit time step. We consider now the possibility of being able to obtain the maximum of three elements as a basic query. With this model we can compute MAX, substantially faster than n - 1 operations. 1. Input (xi,. . . , x n ) . 2. Find the max of (xi,x2, xj), (x4, xs,x6), etc. This takes operations. 3. We now have candidates for the maximum. Repeat the procedure in step 2 to get it down to Keep doing this until only one element is left. 4. Output the element.
5
5
5.
5
.:
This algorithm’s run time is bounded by + + . . . I This is also a lower bound (up to an additive constant). The preceding algorithm can be generalized to the case where each operation finds the maximum of k elements; the resulting algorithm runs in & comparisons. This is also a lower bound (up to an additive constant). The above algorithm can be adjusted to obtain better upper bounds on all the other problems discussed in this section. For most of them the corresponding lower bound is unknown.
2.6.2 Cutting Down the Size of the Domain We look at the problem of finding the maximum in the case where the domain is small. We take an extreme case. Let the domain be S = (0, 1, 2). The following algorithm clearly solves MAX,,: Go through the list checking, for each i, if x, = 2. If every such i is found then stop and output 2. If no such i is found then repeat the procedure, checking if x, = 1 ever occurs. If such is found, then stop and output 1. If none is found, then output 0. The worst case of this algorithm is 2n checks. However, the average case is quite good: fewer than two iterations. If S is small compared to n, then similar algorithms to the one above can be worked out. There are inputs for which these algorithms take more than n comparisons, but they are far better in the average cases. For the other problems discussed in this section there are also algorithms that work better than the lower bound if the domain is small. These also tend to have worse worst cases but far better average cases. The problem of sorting can be solved faster than O(n log n ) if we assume a bound on the input and use operations other than comparisons. We d o
THE COMPLEXITY OF PROBLEMS
225
not discuss this here but point the reader to the discussion of counting sort and radix sort in Ref. [5].
3.
Pversus NP
In this section we study problems that are more complicated than those in the previous section. The algorithms for these problems are complicated and hence the model of computation is not easy to work with. In fact, virtually no lower bounds are known. However, there is a conjecture that seems to be true that would imply many lower bounds. There are (literally) thousands of problems for which the model in this section is relevant. They come from many branches of computer science, applied mathematics, and mathematics. We concentrate on two problems to motivate our model but mention more problems later. Before describing the two problems we need a definition.
Definition 3.1 A graph is a set of vertices V and a set of edges that are unordered pairs of vertices. A directed graph uses ordered pairs. A weighted graph adds a cost to every edge in the graph. A weighted directed graph can easily be defined. The number of nodes in a graph is usually denoted by n and is our measure of the size of a graph. Example 3.2 We give an example of a weighted directed graph. Let V be the set of cities in America. There is an edge (x, y ) if there is an airline flying from x to y. The cost of the edge will be the cost of the flight. We give two examples of problems on graphs. 1. The s-t connectivity problem (s-t)is the problem of, given a graph and two vertices s and t, determine whether there is a way of getting from s t o t in the graph. 2. The traveling salesperson problem (TSP) requires us to determine the cheapest route through a weighted directed graph that visits every node exactly once. Although these problems look similar they will turn out to be very different. We examine algorithms for both of them. Before presenting an algorithm for s-t we need the following definitions:
Definition 3.3 If two nodes are connected by an edge they are called neighbors. If x is a node then nbhs(x) is the set of all the neighbors of x.
226
WILLIAM GASARCH
If A is a set of nodes, then nbhs(A) is the set of all neighbors of vertices in A . The following is an algorithm that solves the s-t problem: 1. Input (G, s, t ) where G is a graph, s and t are nodes in the graph. 2. Let A . = {s} and A l = A . U nbhs(Ao). 3. i: = 1 While (Ai # A , - l ) do Ai + 1 := Ai U nbhs(Ai) i:= i + 1 end 4. If t E A , then output YES, else output NO. Note that A; will be the set of nodes that are of distance i from s. Hence, the while loop is iterated fewer than n + 1 times. Each time it is iterated it takes at most n steps (this depends on how graphs are represented). Hence, the algorithm runs in O(n2)steps. This is an informal statement since no model has been specified. We now present an algorithm for TSP. First, we need a definition.
Definition 3.4 If G is a graph then a route in G is a sequence of nodes ( v l ,. . . ,v,) such that (1) every node of G is specified exactly once, (2) for all i, the nodes vi and vi + form an edge, and (3) v, and v1 form an edge. If the graph is weighted then the cost ofthe route is sum of the costs of the edges (vl, v2), (v2,v 3 ) , . . . , ( v , - 1, v,,), and (v,,, v l ) . 1. Input (G = (V, E ) where G is a weighted graph. We assume G's nodes are {1,2, . . . , n}. We also assume that every pair of vertices forms an edge. If initially {vl, v2}@ E then we insert { v l ,v2} into the edge set and give it such a large weight that the minimum cost route will not use it. Note that every sequence of n distinct vertices is now a route. 2. Keep two variables MINCOST and BESTROUTE. Initially BESTROUTE is the route (1, 2,. . . , n ) and the MINCOST is the cost of that route. 3. Go through all possible routes. For each route R, if the cost of R is less than MINCOST then replace BESTROUTE with R and MINCOST with the cost of R. 4. Output BESTROUTE.
227
THE COMPLEXITY OF PROBLEMS
This algorithm looks at all possible routes. The number of routes is n! = 1 . 2 * 3 * . . n. Hence the algorithm takes at least n! steps. This is an underestimate because each iteration takes some time as well. This algorithm is rather simplistic. It is a brute-force search over all possibilities. The execution time makes the algorithm infeasible. The questions arises as to whether there is an algorithm whose execution time is small enough so that the algorithm is feasible. Would an algorithm running in time ( n - S)! be feasible? Would an algorithm running in time V% be feasible? The following table shows that even though these functions are smaller than n ! ,they still grow too fast to make algorithms with those run times feasible. We assume that every step takes 1 ns s). n 10 20 30 40 50 60 70 80
f
i 1.9 x 1.6 X 1.6 X 9.0 X 1.7 x 9.1 x 1.1 x 2.7 x
(n
lo3 ns 10' = 1.6 s 1016 = 12.4 yr lo2' = 6.9 X loRyr = 1.4 X lOI7 yr lo4" = 7.0 x yr los0 = 8.3 x loT4yr lo5' = 2.0 x yr
-
2 4.8 X 1.1 x 2.6 x 1.4 X 8.0 x 3.1 X 6.1 X
8)! lon 1021
1035 10" 1067 10"
n! 3.6 X 2.4 X 2.7 x 8.2 x 3.0 x 8.3 X 1.2 x 7.6 X
lo6 lo'* 1032
1047 1064
10"
1O1Ix
A feasible algorithm would have to avoid the brute force search. In the next section we define the notion of polynomial time,which we believe pins down the notion of avoiding a brute-force search.
3.1
Polynomial Time and Nondeterministic Polynomial Time
We need to define a model of computation that is flexible enough so that both algorithms given earlier can fit the model. Formally this is done with Turing machines or some other model of computation (see [15, 18, 201). We will omit the formal definition of a Turing machine but we will state several facts about them.
Fact 3.5 1. A Turing machine consists of (a) a finite number of states to store information and (b) a tape to read input from, write output to, and use for intermediary storage. The tape is unbounded-we think of it as unlimited storage. There is a head that, at any point in a computation, is focused on one tape square. A program written for a Turing machine is essentially a set of instructions telling the head where to move (right, left, or stay where it is), what to write in that square, and what state
228
2.
3. 4.
5.
WILLIAM GASARCH
to change to, given the current symbol it is scanning and state the machine is in. One can easily define what a step of a Turing machine is, hence one can define what it means for a computation to take a certain number of steps. Any computer program can be expressed by a Turing machine. There are several models of computation that tried to pin down the notion of “computable.” All of them have a notion of what a step is and all of these models are equivalent to the Turing machine. The equivalence of the models are efficient in the following sense: If M is one of these models, then there exists a polynomial p such that if a problem A can be solved in time t(n) in model M then A can be solved in time p(t(n))on a Turing machine.
Since we will need a general definition we will talk about sets of strings. Strings can encode graphs, weighted graphs, and virtually anything else that might arise.
Definition 3.6 A string is a finite sequence of bits. If y is a string then IvI is the length of y. The set of all strings is often denoted (0, I}*. rn Definition 3.7 A set A of strings is in P if there exists a Turing machine M and a polynomial p such that the following happens: 1. If x E A then M ( x ) will terminate and output YES. 2. If x 6Z A then M ( x ) will terminate and output NO. 3. If M is run on x then the computation terminates within ~(1x1)steps. By Fact 3.5.4 one can replace a Turing machine by any of a number of models of computation. If a problem A is in polynomial time using a program (like the one for s - t ) then A is in polynomial time using a Turing machine model, and hence A is in P. ( P stands for poiynomid time.)
Polynomial time is a reasonable definition of feasible. A brute-force algorithm usually takes n ! or 2” steps. Polynomial time indicates that we are not doing a brute-force search. Hence some cleverness was involved. In many cases this cleverness can be used to fine tune the algorithm to your needs (e.g., the execution time can be reduced for the problems you care about, or for all problems). Hence, polynomial time seems to be (empirically) a good definition of feasibility. We would like to say the following: “We can now state the problem of whether there is a good algorithm for TSP formally: Is TSP in P?” However
THE COMPLEXITY
OF PROBLEMS
229
this is not quite true. We have defined P to be a set of sets, whereas the TSP problem is a function. Hence we redefine TSP as a set. From now on TSP will refer to the following problem: given (G, k) where G is a weighted graph and k is a number, does there exist a route for G that costs less than k? The following algorithm solves it: 1. Input (G, k ) . 2. G o through all possible routes. For each route R, if the cost of R is less than k then output YES and stop. 3. (If you reach this step then no route costs less than k ) . Output NO. This algorithm may look at all possible routes. The number of routes is n! = 1 . 2 . 3 . . . n. Hence, the algorithm takes at least n! steps. This is an underestimate because each iteration takes some time as well. Note that the time spent checking a particular route is small. In fact, that time is polynomial in n. Hence the reason this algorithm takes so long is that the number of elements in the search space is so large, even though evaluating any one of them is easy. We can now phrase the lower bound question about TSP properly: Is TSP in P? This is an open problem in computer science; however, most computer scientists think that TSP is not in P. We look at the evidence for this. We define a class called NP, but first we need to motivate it. Imagine that someone gave you an instance (G, k ) of TSP and claims that the instance is positive (i.e., a route exists that takes fewer than k steps). Could he or she convince you of this? Yes-he or she need only give you the route R. Given the route R, it will not take much time for you to check that its cost is less thank. Note that this scenario is unrealisticfinding R is the hard part-but at least IF one had an R THEN one could check it. This leads to the definition of NP. The key intuition is that if x is a positive instance then there exists evidence for this which is easily verified.
-
Definition 3.8 A set A of strings is in N P if there exists a set B of ordered pairs of strings, and a polynomial p , such that x fA
x
€zA
(3Y)[lYl 5 P(lXl)
=3 (VY)[lYl9 P(lXl)
(4Y ) E B1;
(x,Y )
4.
(The abbreviation NP stands for nondeterministic polynomial time, which stems from an alternative definition. See Ref. [9]. The string y serves as evidence that x E A. Since B E P it is easy to determine if a particular string y is indeed evidence. Note that putting a problem in NP does not make it easy since there are still many (around 2’’(14))witnesses to check.
230
WILLIAM GASARCH
Example 3.9 TSP is in N P by using the set
B
=
{((G, k ) , R): R is a route in G of cost less than k}.
Example 3.10 Let SAT be the set of all Boolean formulas for which there exists a satisfying truth assignment, that is, a way to assign T R U E and FALSE to the variables in the formula such that the formula comes out TRUE. SAT E N P using the following set B: B
=
{(+, y ) : 4 is a boolean formula, y is a truth assignment and + ( y ) evaluates to TRUE}.
TSP and SAT are both in N P but we do not know which problem is harder, or even if either one is hard. We need a notion of being “the hardest problem in NP.”
Definition 3.11 If A and B are both sets of strings than A s g B if there exists a function fthat can be computed in polynomial time such that x E A iff f ( x ) E B.
Note that if A 5,$B and B E P then A E P. (The “p” stands for polynomial time and the “m” stands for many-one, indicating that f can be many-one and need not be 1 - 1. This is not important for our discussion.) We now define what it means to be NP-complete. NP-complete sets will be the hardest sets in N P in that if they are in P then everything in N P is also in P.
Definition 3.12 A set of strings A is NP-complete if the following hold: 1. A E NP, 2. for all B E NP, B 5 g A . Note that if A is NP-complete and A E P then P
=
NP.
This definition looks like it is very hard for a set to be NP-complete since all the sets in N P have to reduce to it. It also does not look very useful since we do not have any evidence (yet) that P f N P so even if a set is NP-complete it could still be in P. In the next section we refute both of these points.
3.2 The Relevance of NP-Completeness In 1971, Cook proved the following [4,9] by using the formal definition of a Turing machine.
THE COMPLEXITY OF PROBLEMS
Theorem 3. I3
231
SAT is NP-complete.
In 1972 Karp [lo] proved 21 problems to be NP-complete. Because SAT was already known to be NP-complete, Karp did not need to use Turing machines. To show that a set A was NP-complete he showed A E N P (this is usually trivial) and showed that, for some known NP-complete problem B (initially SAT), B 5%A . The problems Karp showed NP-complete were all natural problems. Since then thousands of problems have been shown to be NP-complete. Many of them are problems people have been trying to solve quickly for decades. If any of them are in P, then they are all in P. This is evidence that P # NP. Even though it is not mathematical evidence, it is still a highly plausible argument: If P = N P then one of those problems would probably have yielded to a polynomial time algorithm by now. We now give some examples of problems that are NP-complete. The list is a sublist of the appendix of [9]. For references for where these problems were proven NP-complete, see [9]. Some of the entries on the following list are types of problems instead of actual problems. 1. Graph coloring: Given a graph G, is it three-colorable (that is, can you assign colors to the nodes of G so that you only use three colors and no two neighbors have the same color)? It is known that two-coloring is in P. 2. Clique: Given a graph G and a number k, does G have k points all pairs of which have an edge (such a set of points is called a clique)? 3. Hamiltonian path: Given a graph G, does there exist a path through the graph that hits every node exactly once? 4. Network reliability: The input is a weighted graph G (weights are between 0 and 1, and we interpret them as probabilities of failure) and a number 4 (between 0 and 1). Assume the edges all fail with the assigned probabilities and that they are all independent of each other. The network survives if for every edge (x, y ) there is a path from x to y where none of the edges on the path fails. Determine if the probability of failure is less than 4. (This problem is not known to be in NP, however it is known that if it is in P then P = NP.) 5. Traveling salesperson problem: Discussed earlier. Many variations of it are also NP-complete. 6. Integer programming: Given an integer-valued matrix A and integer valued vector 6 does there exist an integer valued such that A x 5 6. (The same problem with allowed to be rational valued is in P. Both problems have many applications in business.) 7. Dynamic storage allocation: The input is a set of triples (s, a, d ) of natural numbers, and a natural number D. We think of each triple as an
x
x
232
WILLIAM GASARCH
item to be stored which has size s, arrival time a, and departure time d. We think of D as a storage capacity. The problem is to determine if there is a way to allocate space for each item so that we never need more than D units of space. Two items can use the same space if they will be stored at nonoverlapping times. Once an item is put into a space it cannot be moved unless it is departing. (This problem models the problem of allocating space for processors as they come in. The problem here is actually easier since we know ahead of time the sizes, arrivals, and departures of the items.) 8. Minimum cardinality key: The input is a set A of attribute names, a collection F of functional dependencies (ordered pairs of subsets of A ) , and a positive integer M . The problem is t o determine if there is a key of cardinality at most M for the relational system (A, F)? [That is, a minimal subset K C A with IK1 I: M such that the ordered pair ( K , A ) belongs to the closure F* of F defined by (1) F C F*, (2) B C C A implies (C, B ) E F*, ( 3 ) (B, C ) , (C, 0 )E F* implies ( B , 0 ) E F*, and (4) (B, C ) , (B, D ) E F* implies ( B , C U D ) E F*.] 9. Scheduling: The input is a set of triples (t, r, d ) . We think of each triple as a task where t is how long the task takes, r is the release time (i.e., when the task will be ready to be worked on), and d is the deadline (i.e., upper bound on when you need to finish the task). The problem is to determine if there is a way to schedule the tasks to meet all the deadlines. 10. MIN A UT: Given two sets of strings S and T, and a number N, does there exist a finite automaton M with fewer than N states such that M accepts all the strings in S and rejects all the strings in T.
3.3 So Your Problem Is NP-complete .
..
We have discussed several real problems that are NP-complete. Once you know that a problem you are working on is NP-complete, what can you do? 1. Do not look for a polynomial time solution. 2. See if the problem you really want to solve may have some restrictions on it (e.g., only uses numbers that are less than 12). This new problem may have a polynomial time solution. 3. If there is a statement true about “most” of your inputs, then you may be able to use this to get a solution that is fast “most” of the time (e.g., most of the time the graph is planar, but not always). 4. If you do not need an exact solution, then see if you can obtain an approximate solution. 5. Look in the literature for techniques specific to your problem (e.g., there has been much work done on the traveling salesperson problem).
THE COMPLEXITY OF PROBLEMS
4.
233
Decidable, Undecidable, and Beyond
Some problems cannot be solved at all. Even so, we are able to intelligently compare and classify such problems. We do (of course) not use time or space as a measure of complexity. Instead we use the number-ofquantifiers needed to describe the problem. For a more detailed treatment, and for definitions of terms we leave undefined, see [18,20]. First we need to define what it means to be computable. Formally this is done with Turing machines or some other model of computation; however we will speak informally about programs. Fact 3.5 is strong evidence that every function that is computable is computable by a Turing machine. (This assumption is called Church’s thesis.)
Notation 4.1 Throughout this section cpo, cpl, p, . . . , will be a list of all (say) C + + programs. The notation cpi(x) .1 means that cp;(x) is w defined; the notation q i ( x ) t means that cp,(x) is undefined. Definition 4.2 A partial function is a function that is allowed to be undefined on some points of its domain. I f f is such a function then we denote that f ( x ) is undefined by f ( x ) t , and that f(x) is defined by f ( x ) 1. A partial function is total if it is defined on all points of its domain. w Definition 4.3 A partial function f is computable if there exists a program cp such that (1) when f ( x ) is defined q ( x ) halts and outputs f ( x ) , w and (2) when f(x) is undefined p(x) does not halt. Definition 4.4 A set A is solvable if there exists e such that x EA x @A
+ qe( x) = 1
0 Such sets are also called decidable or recursive. A set A is unsolvable if it is not solvable. Such sets are also called undecidable or nonrecursive. w
4.1
~ p i ( x )=
Unsolvable Problems
The following problems are unsolvable. HALT = {(e, x ) I cpe(x) 1}= {e I (3t)[cpe(x)halts in less than t steps]}. TOT = {e I cpe is total} = {e I (Vx)(3t)[cpe(x)halts in t steps]}. COF = {e I cpe halts on all but a finite number of values}.
Notice that there is a naive algorithm for HALT: Given e run q&) and, if it halts, output YES. The trouble is that if cpe(x) never halts this will not be discovered. The undecidability of HALT says far more than that this particular algorithm will not solve HALT; it says that no algorithm whatsoever will solve HALT.
234
WILLIAM GASARCH
These examples are essentially the problem of trying to tell if a program has a certain property. Generally such problems are unsolvable. We pin this down.
Definition 4.5 A set A is an index set if, for all x, y, if cpx and cpy compute the exact same partial function then either x, y E A or x, y 4 A . Hence the question of whether x E A depends only on the behavior of cpx. Theorem 4.6
Zf A is an index set, A # 0, and A # N then A is un-
so lva ble.
All the unsolvable problems encountered so far have to do with programs themselves. The next example is more natural, but it requires a brief look at its background. In 1900, David Hilbert, one of the leading mathematicians of his day, proposed 23 problems for future mathematicians to work on (see Ref. [3]). Even though the notions of decidability and undecidability were not known yet he stated (informally) that these problems should be solved or shown to be unsolvable. For the problems that asked for an algorithm this can be taken to mean that either an algorithm should be found or the problem should be proven unsolvable. For the problems that did not involve an algorithm a proof that it could not be solved can be taken to mean some kind of independence result (i.e., neither the theorem, nor its negation, can be proven from the common axioms in use). Hilbert’s tenth problem (in modern terminology) was to devise an algorithm to determine, given a polynomial p ( x l , . . . ,x,) with integer coefficients, if there exists al, . . . , a, E N such that p ( a l , . . . , a,) = 0. It is now known that no such algorithm exists [6, 121. This can be phrased by saying that the set of polynomials with integer coefficients that have an integer solution is unsolvable. This is commonly stated as “Hilbert’s tenth problem is unsolvable.” This is a natural example of an unsolvable problem since the concepts used to define it are not from computability theory (as opposed to HALT, ZNF, and COF). There is a book on Hilbert’s tenth problem by Matijasevic [13] for nonlogicians.
4.2
Logical Theories
We describe several problems whose decidability is of interest. These problems are not about programs hence they are more natural than HALT, INF, and COF.
Definition 4.7 A logical language contains the usual logical symbols (A, v, -, 3, and V) and variables that we think of as ranging over N. These
THE COMPLEXITY OF PROBLEMS
235
variables are denoted by lowercase letters (as opposed to capital letters). We will allow auxiliary symbols but they will be some subset of {+, X, S, S } where S is interpreted as successor (S(x) = x + 1). We may also allow second-order quantifiers and variables that range over subsets of N. We denote second-order variables by capital letters. We denote a language by the auxiliary symbols. If second-order quantifiers are allowed then we will and [S, X, 21 both include “2” as an auxiliary symbol. For example [ X , I] denote languages.
Definition 4.8 Let L be a logical language. A sentence in L is an expression using the symbols in L where every variable is quantified over. Note that every sentence is either T R U E or FALSE. Example 4.9 1. Let L = [ X , +, ‘-1. The following sentence means that there is no largest number. It is TRUE.
( v x ) ( g Y ) [ x< Yl. The following sentence asks if there is a solution to a certain polynomial. Because the quantifiers range over the natural numbers, the sentence is asking for a solution in the natural numbers. It is FALSE since the left-hand side is always greater than 0 (in fact, greater than 16).
( 3 4 y, z)[x2 + 3xy
+ z’ + 17 = 01.
2. Let L = [S, S , 21. The following sentence says there exists an infinite set:
( 3 X ) W ) ( 3 Y ” < Y A Y E XI. The following sentence says there exists two sets that partition the natural numbers:
( 3 X ) ( 3 Y ) ( V x ) [ ( xE
xvx
E
Y )A (x
fzx v x CE Y ) ] .
A logical language is decidable if there is a program that will, given a sentence in that language, output YES if that sentence is TRUE, and NO if that sentence is FALSE. The following results are known: 1. The language [S, 5 , 21 is decidable. 2. The language [+, 5 1 is decidable. 3. The language [+, 5 , 21 is not decidable. 4. The language [+, X I is not decidable.
236
WILLIAM GASARCH
The undecidability of [ +, X ] can be derived from Godel’s incompleteness theorem (see any text in mathematical logic) as we briefly describe in Theorem 4.11.
Definition 4.10 An axiom system is a set of statements in a logical language. A consistent axiom system is a set of axioms such that it is impossible to derive a contradiction from it. A decidable axiom system is H a set of axioms that forms a solvable set. Godel’s incompleteness theorem is as follows: Theorem 4.1 I I f AX is a consistent decidable axiom system for [+, then there exists a statement S such that S is true of the natural numbers but is not provable from AX. X]
From this we can derive that the language [+, X I is not recursively enumerable. We later see that this language is far harder than that.
4.3 Recursively Enumerable S e t s Recall that we had a naive algorithm for HALT: Given e run cpc.(x) and if it halts then output YES. Modify this algorithm to also output the number of steps that were required. This algorithm still does not work because if (e, x ) 4 HALT then the algorithm does not halt. However, if (e, x ) E HALT, then this algorithm discovers evidence that (e;x) E HALT, namely, the number of steps needed for cp,(x) to halt. This is evidence in that the statement ‘ ‘ C P , ( X ) halts in s steps” can be tested. The set HALT has a nice property: If (e, x ) E HALT then there is finite evidence for this fact. We generalize this property.
Definition 4.12 A set is recursively enumerable if it satisfies any of the following four equivalent conditions. We abbreviate recursively enumerable by r.e. 1. A = 8 or A is the range of a recursive function. (This definition is why such sets are called “recursively enumerable”-we think o f f as enumerating the set.) 2. There exists a solvable set B N X N such that
A
=
{x I (3Y”X,
Y > E BII.
We think of the y as being finite evidence that x E A .
H
It is known (and not hard to prove) that if A is r.e. and not recursive then is not r.e. This is used to prove certain sets are not r.e.
THE COMPLEXITY OF PROBLEMS
237
The following are examples of r.e. sets: 1. HALT. 2. {e 1 cpr halts on some prime } = {e I (3, t ) [ x is prime Ape(x)halts in t steps]}. 3. {e I cpr halts on at least 100 numbers}. The following are examples of sets that are not r.e. but their complements are r.e. Since we think of a set and its complement as being of the same complexity, we do not think of these as being harder than r.e. sets. 1. HALT 2. {e I (pe halts on at most 100 numbers}.
The following are examples of sets that are neither r.e., nor are their complements r.e. We think of these as being harder than r.e. sets. Let A be any of these sets. If x E A there may not be finite evidence for this, and if x g A there may not be finite evidence for this either. 1. {e I pehalts on all primes}. 2. TOT. 3. COF. We look at the case of TOT more carefully. To show that x E TOT one would need to show that for all y M,(y) halts. There can be no finite evidence for this. To show that x 6C TOT, one would need to show that there is a y such that M,( y ) does not halt. There can be no finite evidence for this either.
4.4
Reductions
We need a way to compare two problems, both of which may be undecidable, to each other. In particular, we need a notation for the cncept “If I had access to B then I could solve A.”
Definition 4.13 A sTB if A can be solved given a “black box” for B. This is pronounced “A is Turing-reducible to B.” In the definition of A I T B we allow unlimited access to B. The following definition restricts that access by only allowing one query to B and saying how it is to be used.
Definition 4.14 A smB if there exists a recursive function f such that x E A iff f ( x ) E B. This is pronounced “ A is rn-reducible to B.” The
238
WILLIAM GASARCH
m indicates that the function f m a y be many-to-one. (This is an historical anachronism.) rn
4.5 The Arithmetic Hierarchy We define a measure of difficulty of sets (that are already undecidable) based on the number of quantifiers required to define them. We then state how complex the sets introduced in this section are in this measure.
Definition 4.15 1. A E
XI if there exists a solvable set B C N2such that A = b I (3Y)[(4Y > E BII.
This is the same as r.e. 2. A E if there exists a solvable set B C N3 such that
x2
3. 4.
5. 6.
{x I (3Y)(VZ)[(&Y , z> E BI). A E is defined similarly to XI and &. A E II, if A E 2,. A is in the arithmetic hierarchy if there exists n such that A E 2,. A is X,-complete if A E 2, and (VB E C , ) [ B 5 rn A ] . The notion w of II,-complete is defined similarly.
x,
A
=
The following are well-known facts:
I. 2. 3. 4. 5. 6. 7. 8.
Cl c C2 c C, . . . (proper inclusion).
n,cn,cn,.
z,
...
IIo = and this is the class of all solvable sets. (Vn 2 l)[n, # X,]. If A E 2, f l II, then A is recursive. If A E n n2then A sTK . If A E 2, n II, then for all C,-l-complete sets B, A sTB. If A is &complete and B s,,? A then B E 2,. Hence A 4 II, U
x2
z,-,.
We can now state the complexity of several sets introduced in this section. 1. HALT is &-complete. Hence, HALT E & - n,. 2. TOT is I12-complete. Hence, TOT E n2 3. COF is &-complete. Hence, COF E - n,. 4. Hilbert’s tenth problem can be expressed as a z,-complete set. Hence it is in XI - n,.
x3
c2.
239
THE COMPLEXITY OF PROBLEMS
5. Let TRUE be the set of true statements that can be expressed in the logical languages [+, X ] or [+, I, 21. The set TRUE is not in the arithmetic hierarchy.
5. Summary The following tables summarize most of the problems discussed in this article together with what is known about their upper and lower bounds. After each table we interject commentary. Problem MAX ith element Median HI-LO Sorting
Upper Bound
Lower Bound
n-1
+ (i - 1) log n 2.97n + o (n ) 3n O(n log n ) n
+ 0(1)
n - 1 n + (i - 1) log n 2n - c d i
+c
$n - c cn log n
For these upper and lower bounds a decision tree model was used. For MAX, ith largest, and HI-LO the best algorithm to use in the general case is the standard one presented in Sections 2.1,2.2, and 2.4. The lower bounds indicate that these algorithms cannot be improved. If more information is known about the domain, then a faster algorithm might be possible, as was shown in Section 2.6.2. The 2.97n median finding algorithm is not good in practice and one should actually use a fine-tuned version of the algorithm presented in Section 2.3. Such an algorithm can be found in [2]. Sorting is similar to MAX, ith largest, and HI-LO in that for the general case the standard algorithms (see [ l l ] and [5]) are the best; however, for certain domains better algorithms exist (see [5]). P
Linear Linear P Linear S-t TSP NP NP-complete Three-coloring graphs N P NP-complete Two-coloring graphs Graph connectivity
P
The problems stated above that are in P have fast algorithms. The problems stated above that are NP-complete are not known to have fast algorithms. If the problem you are working on is NP-complete, then see if you can get by with an approximation or with solving a less general problem. Your solution may be very domain specific. For example, there are many techniques for solving the TSP problem, but they do not translate to being able to solve other NP-complete problems. HALT TOT
2,
n2
&-complete I12-complete
2 40
WILLIAM GASARCH COF TRUTH
&
zw
&complete Not in arithmetic hierarchy
These problems are unsolvable. If you are faced with one of them, then you may have to scale it down quite a bit before you can solve it. For example, even though the halting problem is undecidable, if the language that the programs are written in is restricted then this subproblem may be solvable. ACKNOWLEDGMENT
I would like to thank Adam Porter and Marv Zelkowitz for proofreading and commentary. This work was supported in part by NSF Grants CCR-8803641 and CCR-902007Y. REFERENCES 1. Bent, S., and John, J. Finding the median requires 2n comparisons. Proc. 17th ACM Symp. on Theory of Computing, 1985. 2. Blum, M., Floyd, R. W., Pratt, V. R., Rivest, R. L., and Tarjan, R. E. (1973). Time bounds for selection. J. Compiir. Sysr. Sci., 7 , 448-461. 3. Browder, F. E., Ed. (1976). “Mathematical Developments Arising from Hilbert Problems.” American Mathematical Society. 4. Cook, S. C. (1971). The complexity of theorem proving procedures. Proc. 3rd ACM Symp. on Theory of Computing, pp. 151-158. 5. Cormen, T., Leiserson, C., and Rivest. R. (1990). “Introduction to Algorithms,” The MIT Press, Cambridge, MA. 6. Davis, M., Putnam, H., and Robinson, J. (1961). The decision problem for exponential diophantine equations. Ann. Math. 74, 425-436. 7. Dor. D., and Zwick, U. (1995). Selecting the median. Proc. 6th Annual Symp. on Discrete Algorithms. 8. Fussenegger, F., and Gabow, H. (1979). A counting approach to lower bounds for selection problems. J. ACM 26(2), 227-238. 9. Garey, M. R., and Johnson, D. S. (1979). “Computers and Intractability,” W. H. Freeman and Company, New York. 10. Karp, R. (1972). Reducibilities among combinatorial problems. In “Complexity of Computer Computations” (R. Miller and J. Thatcher, eds.). pp. 85-103, Plenum Press, New York. 1 I . Knuth, D. E. (1973). “Sorting and Searching,’’ Vol. 3 of “The Art of Computer Programming,” Addison-Wesley, Reading, MA. 12. Matijasevic. Y . (1970). Enumerable sets are diophantine (Russian). Dokludy Academy Nuuk, SSSR 191,279-282. Translation in Soviet Math Dokludy, Vol 11, 1970. 13. Matijasevic, Y . (1993). “Hilbert’s Tenth Problem,” MIT Press, Cambridge, MA. 14. Moran. S., Snir, M., and Manber, U. (1985). Applications of Ramsey’s theorem to decision tree complexity. J . ACM 32, 938-949. 15. Papadimitriou, C. H., and Lewis. H. R. (1981). “Elements of the Theory of Computation,” Prentice Hall, Englewood Cliffs, NJ. 16. Pohl, I. (1972). A sorting problem and its complexity. Comm. ACM, 15. 17. Pratt, V., and Yao, F. F. (1973). On lower bounds for computing the i-th largest element. Proc. 14th IEEE Symp. on Found. of Comp. Sci., pp. 70-81.
THE COMPLEXITY OF PROBLEMS
241
18. Rogers, Jr., H. (1967). “Theory of Recursive Functions and Effective Computability,” McCraw Hill, New York. 19. Schonenhage, A,, Paterson, M., and Pippenger, N. (1976). Finding the median. J . Comput. Sysi. Sci., 13. 20. Soare, R. I. (1987). “Recursively Enumerable Sets and Degrees.” Perspectives in Mathematical Logic, pp. 184-199, Springer Verlag. Berlin.
This Page Intentionally Left Blank
3-0 Computer Vision Using Structured Light: Design, Calibration, and Implementation Issues FRED W. DePiERO Electrical Engineering Department University of Tennessee Knoxville, Tennessee
MOHAN M. TRlVEDl Computer Vision and Robotics Research Laboratory Electrical and Computer Engineering Department University of California-San Diego La Jolla, California
Abstract Structured light (SL) sensing is a well-established method of range acquisition for computer vision. We provide thorough discussions of design issues, calibration methodologies, and implementation schemes for SL sensors. The challenges for SL sensor development are described and a range of approaches are surveyed. A novel SL sensor, PRIME, the PRofile Imaging ModulE recently has been developed and is used as a design example in the detailed discussions.
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Introduction to Structured Light Ranging . . . . . . . . . . . . . . . . . . . 3. Literature Review and Highlight of Critical Design Issues . . . . . . . . . . . 3.1 Backbone Geometry Designs . . . . . . . . . . . . . . . . . . . . . . 3.2 Approaches to the SL Correspondence Problem . . . . . . . . . . . . . 3.3 Methods of Pixel-Level Analysis . . . . . . . . . . . . . . . . . . . . . 3.4 Alternate Structures for Illumination . . . . . . . . . . . . . . . . . . . 3.5 The PRIME Niche . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Structured Light Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Optics and Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Image Processing Operations . . . . . . . . . . . . . . . . . . . . . . 4.3 Ranging Computations . . . . . . . . . . . . . . . . . . . . . . . . . 5. Calibration of Structured Light Sensors . . . . . . . . . . . . . . . . . . . .
243 ADVANCES IN COMPUTERS, VOL. 43
244 245 249 249 250 250 251 252 252 252 254 257 258
Copyright 0 1996 by Academic Press. Inc. All rights of reproduction in any form reserved.
244
FRED W. DePlERO AND MOHAN M . TRlVEDl
5.1 Calibration Process and Formulation of Calibration Model . . . . . . . . 5.2 Numerical Method of Solution for Calihration Models. . . . . . . . . . . 5.3 Evaluation of Calibration Model. . . . . . . . . . . . . . . . . . . . . 6. Sensitivity Analysis of Structured Light Sensors . . . . . . . . . . . . . . . . 7. Performance Benchmarks and Ranging Experiments . . . . . . . . . . . . . . 8. Related Research and Concluding Remarks . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
258 261 263 264 269 272 275
1. Introduction Machine vision as a discipline and technology owes its creation, development, and growth to digital computers. Without computers, machine vision is not possible. The main objective of machine vision is to extract information useful for performing some task from various forms of image inputs [l,21. Examples of machine vision tasks include robot guidance [3, 4, 51, remote sensing [6], medical diagnosis [7, 81, various types of inspection [9], document processing [lo, 111, and many more. For many applications three-dimensional (3-D) descriptors of the scene are required. Conventional cameras capture two-dimensional (2-D) images and computational approaches are needed to infer the 3-D descriptors from one or more images. Common approaches for this include the use of two or more cameras in binocular and photometric stereo [12-181. Approaches using single images include various structure from “x” (x = shading, texture, shadows, motion) techniques [19]. Recent advances include structure from image streams [20,21] and frameworks for integrating more than one technique for 3-D information extraction [22]. The preceding approaches share one very important common feature. They are all “passive” approaches, that is, they do not need a special source of energy to illuminate the scene. There are obvious advantages to this approach: cost, simplicity of imaging hardware, compatibility with human visual processes, etc. However, these approaches need to overcome some inherent challenges. These challenges arise from the loss of information associated with the perspective mapping of a 3-D scene onto a 2-D image. This produces a fundamentally ill-posed problem when single images are used to find the 3-D descriptors. Additional challenges that face machine vision researchers are due to spatial and intensity quantization of images and to computational requirements. These effects manifest themselves in robustness, speed, and accuracy performance metrics. In some sense, the advantages of simpler and lowcost acquisition hardware is compensated with the need for sophisticated computational processing and analysis approaches.
3-D COMPUTER VISION
245
“Active” approaches for 3-D vision use specialized illumination sources and detectors. These techniques overcome the fundamental ambiguities associated with passive approaches. Some active techniques use laser radar [23,24]; others use various forms of structured lighting (25-301. In general, these methods are able to eliminate the ill-posed problems associated with passive approaches by modeling and observing the projected illumination. In the case of laser radar, a spot laser beam is steered across a scene. Range measurements are made by either AM or FM detection schemes. Structured light (SL) techniques model the optical paths associated with emission and detection to compute range data by triangulation. Structured light ranging has some particularly attractive features compared to laser radar approaches. SL systems can be designed “from the ground up” much more so than with a packaged laser radar sensor. This provides significant advantages for customizing the acquisition capabilities of a sensor for a particular application. Generally speaking, SL sensors are also more accurate and can be made more rugged-at less expense-than laser radar devices [31]. This article focuses on SL sensing. Some critical design issues are discussed, as well as methods of sensor calibration and metrics for calibration models. The implementation of PRIME, the PRofile Imaging ModulE, is described in detail, including various design trade-offs and sensor performance benchmarks.
2.
Introduction to Structured Light Ranging
Structured light sensing is a well-established technique for ranging. A great variety of techniques in this general area have been developed [24, 26, 321. The common thread of all these approaches is the underlying use of triangulation. This ranging geometry can be seen in Fig. 1, which depicts the optical components in PRIME. Here, the laser is projected downward toward objects in the scene. Laser illumination striking an object is observed by the camera to reveal surface profiles, which can be converted into Cartesian range data. In PRIME, the ranging triangle is completed by a rigid backbone between the camera and laser. The three main challenges of developing a SL system are calibration, accuracy, and acquisition speed. Calibration models are needed to relate image to world coordinates (see Fig. 2). Methods of calibration are critical for success, but are usually not described in sufficient detail in published works. Typically, procedures require examples of image coordinates to be generated by calibration targets, the positions of which must be known with high accuracy. To ensure accurate ranging in the final system, the
246
FRED W. DePlERO AND MOHAN M. TRlVEDl
Rigid Sensor Backbone
Laser Plane
Conveyer FIG. 1. Structured light systems use triangulation to acquire range measurements. In PRIME, the ranging geometry is formed by a laser emission, the reflected light observed by the camera, and by a rigid backbone. Optical measurements capture range data in a plane. A conveyer produces the necessary motion for 3-D range data.
Image
Precision
Standoff
FIG.2. The purpose of sensor calibration is to find a mapping between image and world coordinates. In PRIME, this relationship is fixed because of the rigid backbone between the laser and camera.
3-D COMPUTER VISION
247
calibration data must be generated at distances from targets that span the range of standoffs that will be used during sensing. If the intended standoff is on the order of a few feet or less, then standard optical bench equipment can be of great utility during calibration. Hence, the difficulty of this task can vary with the intended standoff of the sensor. Challenges in calibration also arise from the complexity of models that are required for sensor kinematics. These kinematics describe the geometrical relationship between the camera and the laser plane. If, for example, these kinematics are fixed, then the calibration procedure is much simpler. PRIME is such a system, which is referred to here as having a “fixed-plane geometry,” as seen in Fig. 1. An alternative to having a fixed triangular geometry is to reorient the optical paths while ranging. Using a “dynamicplane geometry” in this manner [29, 331 can permit larger regions to be scanned more rapidly. These approaches typically reorient the laser beam using low-inertia optical components. Beam repositioning in this manner can be achieved with high speed and high precision. Although dynamic geometries are attractive from the point of view of acquisition speed, they usually require more complex calibration models 129, 30, 341. Ranging accuracy is highly dependent on calibration models. However, even the most careful calibration effort can be fruitless if the ranging geometry is unfavorable. This refers to the sensitivity of range measurements to various system parameters (see Section 6 for a sensitivity analysis of PRIME). Acquisition speed is another challenge to SL system design. Range acquisition involves locating the laser profile within camera images. This requires pixel examination and processing in order to locate precisely image coordinates that reside at the center of the laser profile. Although the complexity of these algorithms is low, the computational requirements are relatively high. As seen in Fig. 3, systems such as PRIME must process images with relatively low information density-this image has only one view of the laser line. Given the size of a standard image and relatively small area of pixels illuminated by the laser line (=1%), a significant amount of pixellevel computational effort must be expended to acquire the range data associated with a single image. Because of this relatively low payoff, many researchers have experimented with ways to pack more laser lines into a single image [28,29,35]. Approaches with multiple laser images necessitate use of a heuristic to determine the correspondence between image features and laser positions. Several methods for this are reviewed later. Some discussion is appropriate concerning the fundamental limitations of SL ranging. Surface reflectivity is one such factor. For reliable range data, a scanned object should have surfaces with Lambertian reflectivity.
FRED W. DePlERO AND MOHAN M . TRlVEDl
FIG.3. Image of laser profile seen by camera. The camera’s optical filter was removed for this image to better reveal objects in the scene.
Specular surfaces will often reflect too much of the structured illumination away from the camera. This produces voids in range data. Note that the degree of surface reflectivity can be counterintuitive when dealing with near-infared ( IR) laser systems, such as PRIME, since these wavelengths are beyond the human visual range. Shadowing is also a fundamental problem in SL systems. This occurs when object geometries occlude the laser from the field of view of the camera. Shadowing effects can be reduced when the camera-to-laser baseline distance is shortened. However, this also increases the sensitivity of the system to measurement noise (see Section 6). Ambient lighting is an important design issue. It can be a limitation to SL or other types of optical ranging if ambient sources are unfavorable and cannot be controlled. Monochromatic illumination and matched optical filters for cameras can be used to tackle this problem, as in PRIME, provided the ambient lighting can be set up on a different wavelength. Fluorescent lighting and IR SL ranging make a very nice complementary pair. This combination provides ample room light without contaminating range imagery. Incandescent light is a very poor choice for use with IR SL systems. The novelty of PRIME stems from new approaches to calibration and to pixel-level operations. These techniques make for a system that has real-
3-D COMPUTER VISION
249
time acquisition, is accurate, easy to calibrate, and made entirely from commercial components. The following sections review other SL efforts and then detail the approach taken in PRIME.
3. Literature Review and Highlight of Critical Design Issues The scope of this review is limited to ranging systems with the same style of laser emission as PRIME-a laser plane. Excellent reviews are available for a much broader scope in [23,24]. This review highlights design alternatives in SL sensors and examines the trade-offs implemented in PRIME. Three critical aspects of SL sensor design are presented here. Backbone geometry describes the geometric relationship between the laser(s) and camera. Correspondence and pixel-level analysis are image processing issues at the large and small scale, respectively. The correspondence problem deals with establishing an association between a region of an image and the location of the illumination source (in world coordinates). Pixel-level analysis takes over once the correspondence problem has been solved, to find the precise image location of illumination patterns.
3.1 Backbone Geometry Designs This aspect of an SL sensor design has to do with the geometry between the camera and laser plane. Fixed-plane geometries have advantages in calibration, simplicity, and ruggedness due to the absence of any moving optical components. This is the approach taken in PRIME. This necessitates some other source of motion in order to acquire range data in 3-D. In [36] a fixed plane is used in conjunction with a rotating table. One of the first industrial applications of SL [32] used a conveyor belt, as does PRIME. Dynamic-plane systems alter backbone geometry during the ranging process. These systems are generally able to scan larger areas more quickly and do not require additional mechanisms to supply motion. Accuracy and calibration can become more challenging, however. Rotating optical components began appearing in the literature [37-391. In [35]the imprecision associated with using gear trains to rotate optics is described. Other approaches have used direct-drive motors, some galvanometer based, to rotate optics [29, 341. The complexity of modeling the laser reflection can vary significantly, depending on the required accuracy of a system. Simple reflection models [33, 401 assume a perfect alignment between the laser line and the axis of rotation. When a front-silvered mirror is rotated about an axis that is offset from the reflecting surface, a displacement of the laser plane is introduced.
250
FRED W. DePlERO AND MOHAN M. TRlVEDl
This displacement is also sometimes ignored. In [29, 341 a more complete geometric model is used. In [30,41] a half-sphere field of view necessitated the use of a dynamicplane system with pan and tilt units for both cameras and lasers. Emitter and detector units were also housed separately, requiring an in situ calibration as well as dynamic geometric models for each unit.
3.2 Approaches to the SL Correspondence Problem It is reasonable to consider imaging multiple laser profiles in a single camera image in order to achieve increased acquisition rates. More than one laser profile per image increases the information content, but necessitates a scheme for establishing the correspondence between a laser profile and the associated laser plane geometry. Having no ancillary means to establish correspondence [42] can result in a combinatorically unfavorable problem. In 12.51 the correspondence problem is addressed using relaxation labeling. In [35] a color camera was used to observe multicolored profiles. In this approach the position of each colored plane was fixed and all planes were projected simultaneously. This provided images with a clear correspondence relationship that could be acquired in a single frame of time. In [29] a time-lapse image of closely spaced profiles was collected. Here the correspondence problem was solved by computing a second registered image that contained position-stamp information for each profile. This was accomplished using simple processing steps, allowing position stamping to be implemented in real time on commercially available hardware. Another useful technique involves collecting a sequence of well-registered images while illumination sources are toggled on and off. In this way, each laser profile can be identified by analyzing in which images in the sequence it appears [28, 43451. If multiple laser profiles are present in an image, or if a sequence of images must be analyzed, then it can be necessary for objects in a scene to remain motionless during the acquisition cycle. These types of approaches introduce limitations in more dynamic environments.
3.3 Methods of Pixel-Level Analysis Once the correspondence between a profile and the actual laser position are established, it is necessary to determine precisely image coordinates at the center of the laser profile. The precision with which these coordinates are located affects the overall accuracy of range measurements. Speed and accuracy trade-offs exist here.
3-D COMPUTER VISION
251
One approach to speeding up SL acquisition is to perform the pixel-level analysis in the analog domain. An early effort in this area [46] made the assumption that stripes are roughly vertical. This approach used dedicated timing hardware to find the illumination on each horizontal scan line. This provided image coordinates at frame rate image. More recent approaches [40] have used very large scale integration (VLSI) implementations that incorporate analog detection and timing operations in a single chip. In [35] a peak detection algorithm was used to find image coordinates at the center of the laser profiles. This analysis did not provide results with subpixel accuracy. An analog implementation of this scheme was also proposed. In [41] the nominal orientation of the laser profile could not be assumed and pixel-level operations had to be performed at different orientations. Here, video images were digitized and pixel-level analysis was performed in different directions, using an adaptive scheme.
3.4 Alternate Structures for Illumination It is worth considering a variety of structures for illumination when at the early design stage of an SL system. One such approach uses a spot of laser illumination. These are sometimes referred to as flying-dot systems. If a video camera is used for this type of system, the approach can suffer in terms of acquisition speed due to the low information density per image [47]. Because of this, many approaches turn to one-dimensional (1-D) detectors [48] or to custom optics [4Y]. Despite the problem of low information density, there is a significant advantage to flying-dot systems that use 2-D video images, or some other type of 2-D detector. When a directional vector (in R’) is available, from the detector to the flying dot, an on-line confidence measure can be computed for each range point. The ranging process in these systems can be formulated as an intersection calculation of two lines, one along the laser optical axis and the other along the camera sighting of the flying dot. The closest point of intersection between these two lines can be used as a best estimate for a range measurement. The minimum distance between these two lines can then be used as an estimate of the measurement uncertainty. This confidence measure is provided in an on-line, point-by-point manner. This provides great advantages for applications demanding high accuracy and high reliability. SL systems that image a laser line, as with PRIME, do not possess this type of inherent accuracy check. Laser optics are available that project alternate light patterns, circular projections. for example. These may provide advantages for some situations
252
FRED W. DePlERO AND MOHAN M. TRlVEDl
where the structure of the light matches an application-dependent measurement region.
3.5
The PRIME Niche
PRIME has been designed for high accuracy, ruggedness, and simple calibration. To accomplish these goals in the most reliable manner and at the highest possible speed, the decision was made to use a single plane of laser light. This provided ruggedness, accuracy, and simple calibration, but did require additional effort to achieve real-time acquisition. Acquisition speeds were improved by mapping portions of the pixel-level operations onto dedicated commercial hardware. Because a single laser profile is imaged, and because range acquisition occurs at frame rate, PRIME is able to scan objects that are continuously moving.
4.
Structured Light Acquisition
The architecture of a SL sensor includes both optical components and pipelined processing elements. A wide variety of components can be selected for these purposes. In PRIME, for example, the computing components include a Motorola 68040-based single board computer and a Datacube MV20 image processing board. The main processor runs under a vxWorks environment. It is responsible for real-time configuration and control of the Datacube hardware, and for applying calibration models.
4.1
Optics and Imaging
Figure 4 shows the optical components that comprise the SL sensor. An IR diode laser, seen on the left, illuminates a scene from above. The laser emission is in the form of a plane of light, which is generated by a cylindrical lens mounted in the laser housing. The black and white camera, seen to the right, is positioned so as to image the light reflected from the laser plane as it strikes objects in the scene. Figure 5 includes typical scanned objects, also. The camera is outfitted with an optical filter that is matched to the laser optical frequency. These matched optics produce very distinct imagery of the laser profile. The image in Fig. 3 was taken with the optical filter removed, for presentation purposes. Figure 10 (Section 5 ) shows an image captured with the IR bandpass filter installed, as is typical during ranging. Because CCD cameras are quite sensitive to IR, manufacturers typically install an IR cut filter. Such a filter was removed from the camera used in PRIME. Another aspect of the imaging process has to do with the use of an electronic shutter. In applications with objects that move continuously past
3-D COMPUTER VISION
253
FIG. 4. Laser (left) and camera (right) used in PRIME sensor. The laser generates a plane of light with a cylindrical lens. A bandpass optical filter on the camera yields distinct imagery of the laser plane as it intersects objects in the scene.
FIG. 5 . PRIME sensor with typical objects.
254
FRED W. DePlERO AND MOHAN M. TRlVEDl
the sensor, a certain degree of blurring would nominally occur in each camera image. Blurring increases the uncertainty with which image coordinates at the center of the laser profile can be recovered and, hence, must be limited. The camera’s electronic shutter reduces the temporal integration period for each pixel. In this way the frame rate of images is unchanged, but the exposure time is reduced. This yields video streams which are subsampled in time, which means that shape information will be missing between sequential laser profiles. This introduces an upper limit on the spatial frequency content of shape descriptions and can result in aliasing. A standard video frame is composed of two interlaced fields. Each field is transmitted sequentially. When using an electronic shutter, each field is exposed individually. Typically the shutter interval for one field will occur immediately before that field is due to be output on the composite video signal. Hence, a single camera image contains data required from two separate time instances, 1/60 apart. This necessitates that the temporally skewed fields be processed separately when the laser profiles in each are converted to range data. In PRIME, the physical thickness of the plane of laser light is e0.040 in. The sensor has been designed for scanning velocities of e l in./s. An electronic shutter interval of <1/250 s is well suited for this situation because the blurring of the beam is limited to
4.2
Image Processing Operations
The images used during range acquisition have an almost totally black background, with gray levels of =lo-20 out of 256. Given the saturated
255
3-D COMPUTER VISION
pixels on the laser profile, this represents a SNR of =25 dB For the image data. These conditions provide considerable latitude in selecting a grayscale threshold for producing binary images. These binary images are used in an intermediate step to locate roughly the laser line within the image. Image processing operations were split between the Datacube board and the main processor for improved pipeline throughput. To permit both devices to process simultaneously, double buffering was used between these two pipeline elements (see Fig. 6). The Datacube board providing image I/O and storage, displayed the real-time status of the ranging sensor, and was used to locate the rough position of the laser line within each image. The rough position estimates were achieved by thresholding and then run-length coding [50]. Run-length coding (RLC) generates a 1-D array having indices with a one-to-one correspondence with the columns of the binary image. Each RLC array element contains the height along a column from the bottom of an image up to the first illuminated pixel. The RLC data are depicted in the image buffers of Fig. 6. Hence the RLC array provides a succinct description of the rough location of the laser line. This information greatly improves the speed of range computations because the
Real-Time Processor
Kalman Filter . Encoder
Conveyer
Real-Time Processor
Position
s Stamp Profile
of Range Data Real-Time Processor
256
FRED W. DePlERO
AND MOHAN M. TRlVEDl
Datacube board can provide the RLC data at frame rate. This eliminates an otherwise burdensome effort by the main processor of searching the entire image for a relatively small illuminated region-which could not be done in real time. Using the run-length coded array, the main processor can directly access the required portions of images. To localize the center of the laser line precisely, pixel values are examined on a cross section of the laser illumination and a weighted centroid calculation is performed. Figure 7 illustrates typical pixel intensities, as sampled along a path roughly orthogonal to the laser line. In PRIME, the intensity profiles are typically 5-7 pixels wide with a roughly Gaussian shape. The main processor examines gray-scale pixel values in a 20 X 1 window, W, centered at locations given by the RLC array. A mapping function, P( g;), is used to describe the likelihood that a pixel having intensity g; is a member of the laser line. The mean, 7, and variance a?,of the row at the center of the laser line are found with
where g; is the gray level of the pixel in row ri,and S = x P ( g i ) .Summations are taken within the window, W, and all include pixels above the binary threshold. The image coordinate recovered, (F, c), is the mean row together with the column under examination. We wanted to make the mapping function, P( g,), a smooth curve varying from 0.0 to 1.0, corresponding to pixels in the background and on the laser profile, respectively. A truncated error function (erf) was chosen for the mapping. Values for P(gJ were found by integrating a Gaussian and then normalizing so that the area under the erf curve was unity. The shape of the original Gaussian was chosen so that 3a below the mean were gray levels clearly belonging to the background and 3a above the mean were levels at the center of the laser profile. The gray levels at these 3a points were chosen manually by examining a histogram of typical images. Previous experiments in camera calibration [34] have shown as much as a 13%change
Probability of laser line membership P ( pixel gray Scale )
0.0
‘
-
-
O ‘-0,
i
?+a,
-
Threshold k Pixel Row
Fic. 7. Recovering image coordinates at the center of the laser line.
3-D COMPUTER VISION
257
in centroid location when weighted centroid calculations are done, versus binary methods. The variance, a;,of each (T, c) coordinate was checked against a threshold as a means to eliminate the use of blurry portions of a laser profile. Blurry imagery can result from excess relative motion o r uneven reflectivity, for example. In these situations the reliability with which the center of the laser profile can be recovered is compromised and the generation of range points should be avoided in order to maintain accurate results.
4.3
Ranging Computations
A calibration model, M , is used to convert image coordinates, (r, c), to world coordinates, ( y, z). The model is applied to an augmented vector of image coordinates. For example, with a second-order model
[ 1-2 c2 rc r c 1 ] M
=
z,
where t is the Z coordinate of a range point. A similar model is used to generate Y coordinates (see Section 5). In PRIME, image data provides the Y and Z components of range points. The X component is found by monitoring the motion of a conveyer belt using a wheel encoder (see Fig. 1). The processing of encoder readings is interrupt driven, occurring at a rate four times higher than the video field rate (60 Hz). This provides accurate position estimates (in X ) for each video field, allowing the range profiles in each to be properly position stamped. The main processor was responsible for orchestrating the image acquisition process and stamping each acquired profile with the appropriate positions along the conveyor. Having camera image data synchronized with conveyor position stamps allows 3-D Cartesian range data to be computed. The encoder on the PRIME testbed has a resolution of 4000 counts per revolution, corresponding to 0.003 in. of travel per encoder tick. The main processor uses Kalman filtering [51] to process the raw encoder readings, for improved position estimates. Because of the relatively constant velocity of the PRIME conveyor, the state transitions of the Kalman filter are modeled as having a constant acceleration [52].The process noise matrix has been set up accordingly [53]. The process noise parameter has been determined experimentally to be q = 50. The measurement uncertainty cr, has been set using the encoder spacing and the standard deviation associated with a uniform distribution [54], a, = O . O 0 3 / a in. Because of the sensor geometry, a simple X-Y grid was used to store range data. This provided advantages in terms of complexity and the speed of data storage. It eliminated the need for an octree data structure, for example. The laser plane has a near-vertical orientation. Because of this
258
FRED W. DePlERO AND MOHAN M. TRlVEDl
multiple range points do not tend to occur that have the same lateral ( X - Y ) position above the grid.
5. Calibration of Structured Light Sensors Calibration models are required in order to provide the relationship between image and world coordinates (see Fig. 2). A distinction is made here between the problems of calibration versus registration of the sensor. Herein, calibration refers to a process in which the location of the world frame ( S in the figure) is defined locally to the sensor. Its position is established with the convenience of sensor calibration in mind. Registration refers to the process of relating the sensor frame S, to some other frame that is pertinent to the application-such as a manipulator frame. In most cases, the design of two aspects of calibration are tightly coupled. These are (1) the process by which calibration data is collected and (2) the formulation of the calibration model. The solution to these two problems typically must be found in a joint manner. The approach taken for PRIME is described next.
5.1
Calibration Process and Formulation of Calibration Model
Structured light ranging is fundamentally a process of triangulation. Calibration is sometimes approached as a process of isolating explicit geometrical parameters of this ranging triangle. In [24] range calculations are described using the law of sines together with a pinhole model of the camera. Note that this would necessitate two separate calibration procedures (each of which would contribute errors). A one-step calibration procedure has been developed for PRIME. This process is very similar to the two planes method of camera calibration [55]. In general, any fixed-plane SL system can be calibrated in a one-step procedure because of the rigid mapping between image and world coordinates. One-step procedures have advantages in terms of accuracy and simplicity. Accuracy is improved because models can be found via a single least norm solution. A model z =f(r, c ) relating height, z, to image coordinates has been found using empirical calibration data. This relationship has been determined by analyzing images to find many examples of the triple.
I I,
ci
I.
(3)
259
3-D COMPUTER VISION
Figures 8 and 9 illustrate the PRIME calibration jig. The jig allows a series of horizontal plates to be located at known heights, zi,and to be imaged by the camera. Figure 10 shows such an image containing many examples of where the laser plane is imaged at a given vertical height. The pixellevel operations described in Section 4.2 are used to generate individual triplets. A number of calibration plates were located across the depth of field of the sensor. Precision standoffs were used to locate these in the 2 direction. When calibrating for X , a linear table was used to automate positioning. For increased image fidelity during calibration, a number of images of a given calibration plate were averaged. This reduces the random noise in pixel values that nominally accompany the imaging process [50]. To find the calibration model, an overdetermined set of equations is formed by augmenting the image coordinates (rl,cl)of each triplet. A variety of forms of calibration models have been studied. In the case of a secondorder model, for example, a calibration n-tuple
StZ
x
Horuonlal allbration Plate at z = ZI Precision Standoffs
Ci
World pane an this line
1
ISuperpowtion of tmges farmed w
t
hanzontal caltbratm plate
FIG.8. A series of horizontal plates are used to generate examples of the I 2, r, c, 1 triplet [Eq. (3)] for PRIME. The triplets are used to form an overdetermined set of equations from which calibration models may be determined. This illustrates the calibration procedure for the z = f(r,c) model.
260
FRED W. DePlERO AND MOHAN M. TRlVEDl
Vertical Calibration Plate at Y =Yi
1
I
C
€LL
R
World points on this line areatY=Yi
Ri
Image of laser plane intersecting vertical calibration plabe
1
both types of calibration plates
FIG.9. A series of vertical plates is used to generate the data needed for the y = f ( r , c ) calibration model in PRIME.
I zirf cf rici ri ci 1 I
(4)
is used. These n-tuples are arranged to form c:
rlcl
rl
c1
1
6
$
r,ci
r,
c,
1
r:
c,2
r,c,
r,
c,
1
r:
*..
...
or Z=FM, where Z ( n X 1)contains world coordinates, F (n X p) contains augmented pixel coordinates, and M ( p X 1) contains model parameters. In this case p = 6. A series of vertical plates is used to generate the calibration triplets needed for the Y model. This process is depicted in Fig. 9.
3-D COMPUTER VISION
26 1
FIG. 10. An image used for range measurement calibration. The central horizontal line is produced by the intersection of the laser plane with a horizontal metal plate.
5.2
Numerical Method of Solution for Calibration Models
Many methods of solution are possible for finding the calibration model, M , in a least norm sense [56]. However, prudent selection of a solution technique can have side benefits in the calibration process. Forming the normal equations [57],for example, allows the solution to be found, but does not provide any additional information. Techniques that reveal the numerical sensitivity of the solution are much more desirable. This provides an indication of how much the solution will change due to slight perturbations in the calibration triplets. The calibration triplets will contain measurement noise, hence the need for an overdetermined specification of the solution and for as low a numerical sensitivity as possible. There is no guarantee that the existence of ill-conditioned calibration data will be apparent in the residual error [58]of the solution. The greatest care in the imaging and pixel-level operations will be fruitless if the solution for a calibration model suffers numerically. The consequence for ranging is that a calibration model may not yield accurate results when new data are applied. A common reason for the matrix F of Eq. (6) to become ill conditioned occurs due to a poor distribution of the input data points. As seen in Eq. ( 5 ) , the right-hand column entries in F are all 1. The columns of F must be linearly independent [57]. Hence if all calibration triplets possess the same row or column, then F will become ill conditioned.
262
FRED W. DePlERO AND MOHAN M. TRlVEDl
One technique for improving numerical performance when finding M involves scaling the image coordinates of the calibration triplets. By normalizing the image coordinates to the range (0, l), the span of entries in F can be reduced. This improves the condition of F [56]. If it is assumed that coordinates vary from 5 to 90% of the image then the normalized and unnormalized coordinates cover the ranges (0.05,0.9S) and (25,485), respectively. The span of largest to smallest entries in F is used as a measure of demand on numerical precision (see Table I). The ratio of the span of entries in F for the normalized versus unnormalized cases is given as the cost ratio ofspans. This gives a measure of the reduction in precision that is achieved by normalizing. This reduction is then expressed as a number of bits. Table I shows that a significantly larger number of bits can be required to represent the ratios for the unnormalized entries. This unnecessary cost in precision is reflected in poorer conditions for F, reaching six orders of magnitude! (see Tables I1 and 111). PRIME has been calibrated to an accuracy of 1 part in 1500 (see Section 5.3). This necessitates =ll bits of precision for ranging nominally. The burden of using unnormalized formulations is additive. Note that these costs in precision have been expressed as a number of bits in integer format. The actual numerical effects are more complicated, because they involve floating-point operations. A singular value decomposition (SVD) [S6] exposes the singular values of F, which can be used to compute the condition number [57]. This provides an excellent measure of the numerical sensitivity of the solution. The SVD approach decomposes F:
F
=
(7)
UDVT,
where U and V are orthonormal and D is diagonal, containing the singular values of F. The technique also permits “repairs” to be made to D, ensuring its invertibility [58].This allows the calibration model TABLEI DEMANDS ON NUMERICAI. PRECISION FOR NORMALIZED A N D UNNORMALILED CALIBRATION MODELS Order
Span of Entries in F Unnormalized
1st 2nd 3rd 4th
48.5‘11 485211 485 ’It 4XS4/1
Span of Entries in F Normalized
Cost Ratio of Spans
Integer Precision of Cost (bits)
~
1/0.05’ 1/0.0.5* 110 05’ 110.054
2.4 10’ 5.8 102 1 4 104
3.5 10’
5 10 14 19
3-D COMPUTER VISION
M
=
263
VD-‘UTF
and the condition number
to be easily computed. Here, d,,, and dmi, are the largest and smallest diagonal elements of D. Note that F is considered to be ill conditioned if 1 / approaches ~ the precision of floating-point computations, for example, no less than lo-’’ for double precision [58].
5.3
Evaluation of Calibration Model
Selecting an appropriate form for a calibration model affects important trade-offs in acquisition spqed and ranging accuracy. This selection process is closely related to that associated with the two-planes method of camera calibration (5.51. These problems are quite similar because each involves a mapping from image coordinates to a plane of world coordinates. Recommendations for appropriate forms of camera models [.59] serve as a guide, as well as several metrics for model evaluation [29, 601 which have been incorporated and extended for PRIME. The metrics used for PRIME involve the computational burden during on-line evaluation and various measures of the quality of the model solution. These are: 1. Compute burden 2. Condition number 3. Span of residual errors 4. Autocorrelation of residual errors 5. Goodness-of-fit, based on chi-squared
The compute burden is a direct result of the number of terms in the model. The condition number is found from Eq. (9). The residual error of the solution is computed by comparing the fitted height of the ith triplet, z; = f(r,c), to the original height. Ideally z, - z; -+ 0, but in practice random measurement noise and higher order lens aberrations keep these from vanishing. Although low residual errors do not guarantee an accurate model, these values are still useful to examine, as a low magnitude is a necessary condition for accuracy. The span of the residual errors is described by computing the maximum, mean, and standard deviation of the absolute residuals. The purpose of calibration is to characterize the distortions in a mapping between two planes. Hence, a proper mapping and proper calibration procedure should result in a set of residual errors with a very low spatial depen-
264
FRED W. DePlERO AND MOHAN M. TRlVEDl
dence. That is, any uniform pattern or trend in the spatial arrangement of residuals should be very minimal. The residuals should appear as random entries. This random character can be described using the autocorrelation of the residuals. As a final metric, a goodness-of-fit measure has been computed involving chi-squared and the degrees of freedom in the system of equations [58]. This involves the use of an estimate of the accuracy of z;, which is noted in the tables. The fit quality, Q, should ideally be Q 2 0.1 to consider a mapping as valid. In some cases values in the range Q 1 0.001 are also deemed acceptable [58]. Tables I1 and I11 summarize the metrics found when calibrating PRIME. Table IV gives the form of each model that was considered. When finding the Z model, 280 calibration triplets were used and the accuracy of the true heights, zi,was estimated at 0.005 in. For Y, 98 triplets and an accuracy of 0.010 in. for xi were used. In addition to the tabular summaries, images have also been generated that depict the residual errors. These provide a visualization of any spatial correlation in the errors and of the location of all the calibration triplets, in a single image. Figures 11 through 14 show images that depict residual errors for types 1 and 4 of the 2 and X models, respectively. The images contain a series of small gray blocks, each of which coincides to the location of a calibration triplet and the corresponding residual error. The gray level of the block is scaled so that the data point possessing a minimum residual error is the darkest and the one possessing the largest error is the lightest. Note that a different gray-scale mapping is used for each image. As seen later in Table V, the mean acquisition time did not vary significantly between model types. This is primarily due to the compute burden associated with managing the Datacube hardware and with finding the nominal position of the laser profile. Because of this, model selection was based primarily on accuracy and condition number. The normalized form of model type 4 was chosen for both X and Z .
6. Sensitivity Analysis of Structured Light Sensors The question of sensitivity is concerned with the relationship between the accuracy of range measurements to sources of error in the acquisition process. The geometry of the optical paths involved in ranging plays an important role in determining how errors during acquisition are amplified in range measurements. A Monte Carlo analysis [61] can be used to perform a thorough study of measurement errors. This would involve simulations of the measurement
TABLE I1 METRICS FOR 2 CALIBRATION MODELFOR PRIME" Type
Normalized
Mean Residual (in.)
Standard Deviation of Residual (in.)
Maximum Residual (in.)
Fit Quality
Autocorrelation (1 shift)
Yes Yes Yes Yes No No No No
0.071 0.007 0.003 0.002 0.071 0.007 0.003 0.002
0.038 0.004 0.003 0.002 0.038 0.004 0.003 0.002
0.137 0.022 0.015 0.013 0.137 0.022 0.015 0.013
0.00 0.00 0.99 1 .00 0.00 0.00 0.99 1.00
0.9 0.9 0.7 0.5 0.9 0.9 0.7 0.5
~
a
A total of 280 calibration triplets was used. A value of 0.005 in. was used for the accuracy of
z,.
Condition Number ~-
10' lo2 10' 103 103 1Oh 1o9 1oy
TABLE 111
METRICS FOR X CALIBRATION MODELFOR PRIME" Type
Normalized
Mean Residual (in.)
Standard Deviation of Residual (in.)
0.093 0.010 0.009 0.004 0.093 0.010 0.009 0.004
0.059 0.008 0.007 0.002 0.059 0.008 0.007 0.002
Maximum Residual (in.)
Fit Quality
Autocorrelation (1 shift)
Condition Number
0.240 0.033 0.031 0.009 0.240 0.033 0.03 1 0.009
0.00 0.00 0.03 1.OO 0.00 0.00 0.03 1.oo
0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8
10' 10' 1o7 10' 10' 1Oh 1o4 10'
~
Yes Yes Yes Yes
No No No No
A total of 98 calibration triplets was used. A value of 0.010 in. was used for the accuracy of x ,
3-D COMPUTER VISION
267
TABLEIV FORMOF CALIBRATION MODELS Type
Coefficients
~~~~
1 2 3 4
~
1r c 1 rc9c’rc 1 r c rZ c2 rc P c’
1r c
9c2 rc 9c rc2 r? 2
process with representative levels of noise being introduced at each stage. This type of approach is particularly desirable when analyzing a SL sensor with dynamic geometry, because it can be used to study accuracies across the entire measurement space. For PRIME, a simpler approach has been taken. Referring to Fig. 15, variations in image coordinates, d 4 , produce a displacement of dw at the standoff of the sensor. Because the laser profile is assumed to be roughly horizontal in each camera image and each column is analyzed individually during pixel-level processing, only the sensitivity of height variations to vertical image displacements is considered. (Actually
FIG. 11. Residual error of a first-order (type 1) 2 calibration model. Mean = 0.071 in. Gray levels of each block are scaled to span the extremes of the residual errors in this model (maximum = 0.137 in.).
268
FRED W. DePlERO AND MOHAN M. TRlVEDl
FIG. 12. Residual error of a third-order (type 4) Z calibration model. Mean = 0.002 in. Gray levels of each block are scaled to span the extremes of the residual errors in this model (maximum = 0.013 in.).
FIG. 13. Residual error of a first-order (type 1) X calibration model. Mean = 0.093 in. Gray levels of each block are scaled to span the extremes of the residual errors in this model (maximum = 0.240 in.).
3-D COMPUTER VISION
269
FIG. 14. Residual error of a third-order (type 4) Z calibration model. Mean = 0.004 in. Gray levels of each block are scaled to span the extremes of the residual errors in this model (maximum = 0.009 in.).
Laser
Camera
-_-
4
dw sin8 dz dz FIG. 15. The sensitivity dzldw of a fixed-plane SL system is determined by the angle, 0, between the laser emission and the camera sighting. This describes the effect of the change in image coordinates with respect to changes in height.
270
FRED W. DePlERO AND MOHAN M. TRlVEDl
in the center of the image d y = dw for lateral image displacements.) The angle between the laser emission and the camera sighting determines the sensitivity of height errors. As seen in the figure, the amplifying factor is
dz=dw
1 sin 8’
where 0 is the angle between the laser emission and camera sighting. This is related to changes in height by sin 8. In fixed-plane SL sensors this sensitivity factor varies in a continuous fashion across the laser plane because 0 varies somewhat across the laser profile (with motion in and out of the paper in Fig. 15). For PRIME, the sensitivity varies 1.5 < = dz/dw < = 1.6. Being near 1, these values are relatively low. As sensitivity improves, the degree of shadowing increases. The ranging geometry for PRIME was chosen to somewhat favor sensitivity versus shadowing. Freedom to increase shadowing was deemed acceptable because mostly convex objects with relatively slow rates of curvature were targeted for use with PRIME.
7. Performance Benchmarks and Ranging Experiments Performance benchmarks are very important during sensor research. These give measures of speed and accuracy that are vital for both automated and manual interpretation of data. Example scenes and range data are presented in Figs. 16 and 17, respectively. Images of the scenes were captured by the PRIME video camera with the IR bandpass filter removed. The laser appears as a bright line near the bottom of each image. A performance metric for active range sensors has been introduced by [24]:
where T is the point dwell time (dpoint), D,is the depth of field in the 1 direction, 6, is the measurement uncertainty, also in the I direction, and M is the rating. In [24] the dimensionality of contributors (x, y , z ) to this expression is reduced for sensors that generate indexed arrays of range data. This is the case for PRIME in the X direction. Also with PRIME, the depth of field in the direction along the conveyer is somewhat arbitrary, because the conveyer is often run at varying speeds depending on application needs. As in [24], the rating has been reduced to
3-D COMPUTER VISION
27 1
FIG. 16. Measurements captured by PRIME for objects with a variety of surface textures.
To determine the accuracy of height measurements, a horizontal plate was scanned at a height other than those used during calibration. This plate and the ones used during calibration have a quoted flatness of 0.002 in. of variation per foot. At most 6 in. of such a plate are used during calibration and testing. The mean absolute variation of height measurements taken from this type of plate is given by 6, in Table V. To determine the point dwell time, a number of scans were made and the mean number of points per video frame was computed. Each type of calibration model was tested. The size of processed imagery was adjusted to maximize the amount of range data, while maintaining frame-rate throughput for each calibration model. The results of these performance benchmarks are given in Table V. These benchmarks were also used in the model selection process. The T values in the table are somewhat conserva-
FIG. 17. Gray-scale images captured from the video camera during the ranging process. The optical filter normally used during acquisition was removed for these images, to better illustrate the interaction between the laser plane and object surfaces. The laser appears as a bright line near the bottom of each image.
272
FRED W. DePlERO AND MOHAN M. TRlVEDl
TABLE V PRIME PERFORMANCE MEASURES AS A FUNCTION OF T H E TYPE OF CALIBRATION MODEL“
1 2 3 4
0.005 0.004 0.004 0.003
0.24 0.25 0.25 0.25
51,500 70,200 70,200 83,900
Performance of the normalized vs. unnormalized forms was essentially identical, normalized models were used herein. (1
tive and are subject to several percent error, due to the empirical nature with which they were determined. These ratings compare well with those given in [24]. Note that the speed benchmarks quoted here include the application of calibration models. Also, PRIME has been built from commercially available components. This makes for a system that is generally less expensive and more easily maintained than a custom implementation.
8. Related Research and Concluding Remarks Across the diverse spectrum of machine vision applications, the main objective is often the same: to extract useful information from image inputs. For tasks requiring 3-D information, machine vision techniques may be grouped into passive or active approaches. Active approaches, such as the structured light method, use specialized illumination sources to overcome the ambiguities associated with passive methods. Despite the longevity of research in SL sensing, a limited number of published works focus on fundamental design and calibration issues. This chapter has included an introduction to the ranging process, discussions of design trade-offs, calibration methods, and performance benchmarks. Structured light ranging has some particularly interesting advantages that allow sensors t o be customized for the specific requirements of an application. These sensors can be built “from the ground up” to yield rugged and inexpensive ranging systems. PRIME is a structured light sensor that has been designed to scan continuously moving objects. PRIME uses a plane of laser light that is mounted
273
3-D COMPUTER VISION
in a fixed geometry. The laser illuminates scenes, allowing vertical profiles of range data to be acquired in real time. Range sensors can be used to form the foundations of larger, end-toend machine vision systems. This involves a number of processing steps. Figure 18 illustrates the components of a recognition system involving range data and graph-matching techniques. Many versions of similar diagrams have been reported [l,21. “Acquire Range Points” generates Cartesian range points, as is the purpose of PRIME. Many range sensors are reviewed in [23,24]. Range points have n o inherent high-level meaning, they are simply individual, 3-D measurements in space. The first step in higher level interpretation is to “Group Range Points” into consistent regions. This process is commonly referred
+
Cartesian Range Data
Group Range Points
Consistent Regions
I
cEgte
Descriptions
Scene Graph
1
I
Match Scene to Database
Scene-to-Database Mapping
Recognized Objects and Pose
Compute Object Position
and Orientation
FIG. 18. Processing steps involved in an end-to-end object recognition system.
274
FRED W. DePlERO AND MOHAN M. TRlVEDl
FIG. 19. Results of segmentation of range measurements taken by PRIME. Each consistent region of range data is shown with a surface patch of a different gray tone. Both flat and curved patches are illustrated.
to as segmentation and has been an active area of research for more than 15 years [62-641. Reviews are available in [65, 661. A novel and real-time approach to range segmentation has been developed for use with PRIME [69]. Results from this process are illustrated in Fig. 19. After “Consistent Regions” have been formed, models are typically used to form a parameterized description of each region. Various types of generalized geometric models are common [70-721 as are approaches based on CAD models [73, 741. Surveys may be found in (75-771. This remains a very active area of research. Graphs are typically used to describe the adjacency relationships of scene elements. Graph-based descriptions also provide a framework for matching schemes used to recognize objects [3, 78, 791. An immense amount of research has also been pursued in the areas of recognition and object localization. In Fig. 18 these are presented as two steps. Some implementations keep these operations distinct [80-83); in many other approaches, recognition and pose calculations are accomplished in a coupled process [38, 48, 84-86]. A relatively low number of end-to-end recognition systems have been reported, compared to the very large amount of effort expended on system components. Complete systems can be found in [38, 48, 71, 73, 77, 861. PRIME is being integrated into an end-to-end recognition system. This includes the novel range segmentation strategy in [69] and a recognition strategy based on graph matching [87]. Applications in the active vision discipline [3,17,20,88]and in geographically distributed real-time manufacturing are being targeted with this system. ACKNOWLEDGMENTS This research is sponsored in part by grants awarded by the Japan Railways and the Office of Technology Development, U.S. Department of Energy.
3-D COMPUTER VISION
275
REFERENCES 1. Trivedi, M. M., and Rosenfeld, A. (1989). On making computers see. IEEE Trans. Syst. Man Cyber. 19(6), 1333-1335. 2. Rosenfeld, A. (1988). Computer Vision. In “Advances in Computers,” Vol. 27, Academic Press, San Diego. 3. Trivedi, M. M., and Chen, C. (1988). Sensor-Driven Intelligent Robotics. In “Advances in Computers,” Vol. 32, pp. 105-148, Academic Press, San Diego. 4. Trivedi, M. M. (1994). Intelligent Robotic Systems. In “Encyclopedia of Science and Technology,” pp. 226-229. McGraw-Hill, New York. 5. Thorpe, C., Hebert, M.. Kanade, T., and Shafer, S. A. (1988). Vision and navigation for the Carnegie-Mellon NAVLAB. IEEE Trans. Patt. Anal. Machine Intell., pp. 362-373. 6. Harlow, C. A,, Trivedi, M. M., Comers, R. W., and Phillips, D. (1986). Scene analysis of high resolution aerial scenes. Opt. Eng. pp. 347-355. 7. Eichel, P. H., Delp, E. J., Koral, K., and Buda, A. J . (1988). A method for fully automatic definition of coronary arterial edges from cineangiograms. IEEE Trans. Med. Imaging, pp. 313-320. 8. Hibbard, L. S., McGlone, J. S., Davis, D. W., and Hawkins, R. A. (1987). Three dirnensional representation and analysis of brain energy metabolism. Science, pp. 1641-1646. 9. Darwish, A. M., and Jain, A. K. (1988). A rule-based approach for visual pattern inspection. IEEE Trans. Patt. Anal. Machine hitell., pp. 56-68. 10. Kasturi, R., Bow, S.T., El-Masri, W., Shah. J., Gattiker, J. R., and Mokate, U. B. (1990). A system for interpretation of line drawings. IEEE Trans. Part. Anal. Machine Intell., pp. 978-992. 11. Okakzaki, A,. Kondo, T., Mori, K., Tsunekawa, S., and Kawamoto, E. (1988). An automatic circuit diagram reader with loop-structure-based symbol recognition. IEEE Trans. Part. Anal. Machine Intell., pp. 331-341. 12. Marr, D. (1982). “Vision.” Freeman, San Fransico. 13. Okutomi, M., Medioni, G., and Kanade, T. (1993). A multiple baseline stereo. IEEE Trans. Patt. Anal. Machine Intell. 4, 353-363. 14. Marapane, S. B.. and Trivedi, M. M. (1989). Region-based stereo analysis for robotic applications. IEEE Trans. Syst. Man Cyber. SMC-19, 1447-1464. 15. Marapane, S. B., and Trivedi, M. M. (1993). An active vision system for multi-primitive hierarchical stereo analysis and multi-cue depth extraction. Proc. Sensor Fusion for Aerospace Systems Conference, Orlando, FL, April 1993. SPIE. 16. Marapane, S. B., and Trivedi, M. M. (1995). Multi-primitive hierarchical (MPH) stereo analysis. IEEE Trans. Patt. Anal. Machine Intell. 16, 227-240. 17. Marapane, S. B., and Trivedi, M. M. (1995). Experiments in active vision with real and virtual robot heads. Int. 1.Appl. Intell. 5, 237-250. 18. Woodham, R. J. (1980). Photometric method for determining surface orientation from multiple images. Opt. Eng. pp. 139-144. 19. Blostein, D., and Ahuja, N. (1989). Shape from texture: Integrating texture element extraction and surface estimation. IEEE Trans. Patt. Anal. Machine Intell., pp. 1233-1251. 20. Dalmia, A. K., and Trivedi, M. M. (1995). Real-time depth extraction using image streams acquired by a single camera. Computer Vision Image Understanding. 63(3). 21. Dalmia, A. K., and Trivedi, M. M. (1996). 3-d structure extraction from image streams: A review. IEEE Trans. Pattern Anal. Machine Intell. (in press). 22. Dalmia, A. K., and Trivedi, M. M. (1996). Integrating depth from motion and binocular stereo approaches. Machine Vision Appl. (in press). 23. Jarvis, R. A. (1983). A perspective on range finding techniques for computer vision. IEEE Trans. Part. Anal. Machine Intell. 5(2), 122-139.
276
FRED W. DePlERO AND MOHAN M. TRlVEDl
24. Besl, P. J. (1988). Active. optical range imaging sensors. Machine Vision Appl. 1,127-152. 25. Stockman, G.. and Hu, G. (1986). Sensing 3-d surface patches using a projected grid. Proc. Computer Vision and Pattern Recognition Conf., pp. 602-607. 26. Ward, M. R., Rheaume, D. P., Holland, S. W., and Dunseth, J. H. (1982). Production plant consight installations. Tech. Rep. GMR-4156, General Motors Research Laboratories, Warren, MI. 27. Gadagkar, H. P.. Trivedi, M. M., and Lassiter, T. N. (1992). Versatile multi-model system for surface profile measurements using a wrist-mounted laser device. Proc. Sensor Fusion V Conference, pp. 466-474, Boston, November 1992, SPIE, Bellingham, WA. 28. Mclvor, A. M.. and Valkenburg. R. J. (1995). Calibrating a structured light system,” Tech. Rep. 362, Industrial Research Limited. 29. DePiero, F. W., and Kress, R. L. (1995). Design and in situ calibration of a structured light sensor. Proc. Int. Conf. on Intelligent Robotics and Systems, pp. 513-518, Pittsburgh, PA, August 5-9, 1995, IEEEIRSJ. 30. Burks, B. L., DePiero, F. W., Rowe, J. C., Selleck, C. B., and Jacoboski, D. L. (1992). Final results of the application of a structured light source for surface mapping of the fernald k-65 silos. Proc. American Nuclear Society, Boston, June 1992, ANS, La Grange Park, IL. 31. Kweon, S., Hoffman, R., and Krotkov, E. (1991). Experimental characterization of the perceptron laser rangefinder. Tech. Rep. CMU-RI-TR-91-1, The Robotics Institute, Carnegie Mellon University, Pittsburgh, PA. 32. Holland, S. W., Rossol, L., and Ward, M. R. (1978). “Computer Vision and Sensor-Based Robotics.” Plenum Press, New York. 33. Kanade, T., Gruss, A., and Carley, L. R. (1991). A very fast VLSI rangefinder. Proc. 1991 IEEE Intl. Conf. on Robotics and Automation, pp. 1322-1329, Sacramento, CA, April 1991, IEEE. 34. DePiero, F. W., and Kress, R. L. (1993). Camera calibration in a hazardous environment performed in situ with automated analysis and verification. Proc. ANS Fifth Topical Meeting on Robotics and Remote Systems, Knoxville, TN, April 1993, ANS, La Grange Park, IL. 35. Boyer, K. L., and Kak. A. C. (1987). Color encoded structured light for rapid active ranging. IEEE Trans. Patt. Anal. Machine Intell. 9(1), 14-28. 36. Shirai, Y., and Suwa, M. (1971). Recognition of polyhedrals with a range finder. Proc. 2nd Int. Joint Conf. on Artificial Intell., pp. 80-87, London, September 1971. 37. Agin, G . , and Binford, T. (1973). Computer description of curved objects. Proc. 3rd Int. Joint Conf. on Artificial Intell., pp. 629-640. 38. Oshima, M., and Shirai, Y. (1983). Object recognition using three dimensional information. IEEE Trans. Patr. Anal. Machine Inrell. 5(4), 353-361. 39. Oshima, M., and Shirai, Y. (1984). A scene description method using three dimensional information. Part. Recog. 11, 9-17. 40. Tada, S.. Gruss. A,, and Kanade, T. (1993). Cmu very fast range-imaging system. Tech. Rep. CMU-CS-93-179, School of Computer Science. 41. Burks, B. L., DePiero, F. W., Rowe, J. C., Selleck, C. B., Jacoboski, D. L., and Markus, R. (1991). Generation of 3 surface maps in waste storage silos using a structured light source. Proc. Space Operations, Applications, and Research Symposium, Houston, 1991, NASA. 42. Minou, M. (1982). “Theoretical and experimental studies on basic relations between real world and pictoral patterns and their generating constraints.” Ph.D. Dissertation, Kyoto University, Department of Information Science. 43. Altscheuler, M. D., Altscheuler, B. R., and Toboada, J. (1981). Laser electro-optic system for rapid 3-d topographic mapping of surfaces. Opt. Eng. 20(6), 953-961.
3-D COMPUTER VISION
277
44. Inokuchi, S.. Sato, K., and Matsuda, F. (1984). Range imaging system for 3-d object recognition. Proc. 7th Int. Conf. on Pattern Recog., pp. 806-808. 45. Yeung, K. K., and Lawrence, P. D. (1986). A low-cost 3d vision system using spaceencoded spot projections. Proc. SPIE Conf. on Optics, Illumination and Image Sensing for Machine Vision, pp. 160-172, SPIE, Bellingham. WA. 46. Popplestone, R. J., Brown, C. M., Ambler, A. P., and Crawford, G. F. (1975). Forming models of plane-and-cylinder faceted bodies from light stripes. Proc. 4th Int. Joint Conf. on Artificial Intell., pp. 664-668. 47. Bickel, G., Hausler, G., and Maul, M. (1985). Triangulation with expanded range of depth. Opt. Eng. 24(6), 975-979. 48. Faugeras, 0. D., and Hebert, M. (1986). The representation, recognition and locating of 3d shapes from range data. Int. J. Roborics Rex 5(3), 27-52. 49. Rioux, M. (1984). Laser range finder based on synchronized scanners. Appl. Opt. 23(21), 3837-3855. 50. Horn, B. K. P. (1984). “Robot Vision.” McGraw-Hill, Cambridge, MA. 51. Kalman. R. E. (1960). A new approach to linear filtering and prediction problems. Trans ASME J . Basic Eng. 83, 35-45. 52. Borrie, J. A. (1992). “Stochastic Systems for Engineers: Modeling, Estimation and Control.” Prentice Hall, New York. 53. Bar-Shalom, Y., and Fortmann, T. E. (1989). “Tracking and Data Association.” Academic Press, New York. 54. Cooper, G. R., and McGillem, C. D. (1986). “Probabalistic Methods of Signal and System Analysis.” Harcourt Brace Jovanovich. Orlando, FL. 55. Isaguirre, A., Pu, P., and Summers, J. (1985). A new development in camera calibration: Calibrating a pair of mobile cameras,” Tech. Rep., Department of Computer and Information Science, GRASP Laboratory, University of Pennsylvania, PA. 56. Golub, G. H., and Loan, C. F. V. (1989). “Matrix Computations,” 2nd ed. John Hopkins University Press, Baltimore. 57. Strang, G. (1980). “Linear Algebra and its Applications,” 2nd ed. Academic Press. New York. 58. Press, W. H., Flannery, B. P., Teukolsky, S. A,, and Vetterling, W. T. (1988). “Numerical Recipes in C.” Cambridge, University Press, New York. 59. Wei, G.-Q.,and Ma, S. D. (1991). Two plane camcra calibration: A unified model,” Tech. Rep., National Laboratory of Pattern Recognition, Institute of Automation, Chinese Academy of Sciences, Bejing. 60. Thayer, S. M., and Trivedi. M. M. (1995). Residual uncertainty in three-dimensional reconstruction using two-planes calibration and stereo methods. Part. Recog. 28(7), 10731082. 61. Sobol, I. M. (1994). “A Primer for the Monte Carlo Method.” CRC Press, Boca Raton. FL. 62. Duda, R., and Hart, P. (1973). “Pattern Classification and Scene Analysis.” John Wiley and Sons, New York. 63. Bolles, R. C., and Fischler, M. A. (1981). A ransac-based approach to model fitting and its application to finding cylinders in range data. Proc. 7th Int. Joint Conf. on Artificial Intelligence, pp. 637-643, Vancouver, B.C., Canada, August 24-28, 1981, IJCAI. 64. Boyer, K. L., Mirza, M. J., and Ganguly, G. (1994). The robust sequential estimator: A general approach and its application to surface organization in range data. IEEE Trans. Putt. Anal. Machine Intell. 16(10), 987-1001. 65. Bed, P. J., and Jain, R. C. (1985). Three-dimcnsional object recognition. ACM Computing Surveys 17(1), 75-145.
278
FRED W. DePlERO AND MOHAN M. TRlVEDl
66. DePiero, F. W., and Trivedi, M. M. (1996). The evolution of adaptive techniques for range image segmentation. Submitted to IEEE Trans. Patt. Anal. Machine Intell. 67. Deleted in proof. 68. Deleted in proof. 69. DePiero, F. W., and Trivedi, M. M. Range profile tracking (RPT): A profile-based approach for robust and real-time range image segmentation. Submitted to IEEE Patt. Anal. Machine Intell. 70. Horn, B. K. P. (1984). Extended gaussian image. Proc. IEEE 61(3), 1671-1686. 71. Brooks, R. A. (1983). Model-based three-dimensional interpretations of two-dimensional images. IEEE Trans. Patt. Anal. Machine Intell., pp. 140-150. 72. Crimson, W. E. L., and Lozano-Perez, T. (1983). Model-based recognition and localization from sparse range or tactile data. Inr. J. Robotics Res. 3, 3-35. 73. Bolles, R. and Horaud, P. (1986). 3DPO: A three-dimensional part orientation system. Int. J. Robotics Res. 5(3), 3-26. 74. Flynn, P. J., and Jain, A. K. (1991). CAD-based computer vision: From cad models to relational graphs. IEEE Trans. Patt. Anal. Machine Intell. 13(2), 114-132. 75. Chin, R. T., and Dyer, C. R. (1986). Model-based recognition in robot vision. ACM Computing Surveys 18(1), 67-108. 76. Binford, T. 0. (1982). Survey of model-based image analysis systems. Int. J . Robotics Res., pp. 18-64. 77. Fan, T.-J., Medioni, G., and Nevatia, R. (1989). Recognizing 3-d objects using surface descriptions. IEEE Trans. Patt. Anal. Machine Intell. l l ( l l ) , 1140-1157. 78. Nevatia, R. (1982). “Machine Perception.” Prentice Hall, Englewood Cliffs, NJ. 79. Ballard, D. H., and Brown, C . M. (1982). “Computer Vision.” Prentice Hall, Englewood Cliffs, NJ. 80. Ambler, A. P., Barrow, H. G., Brown, C. M., Burstall, R. M., and Popplestone, R. J. (1973). A versatile computer-controlled assembly system. NCAI, pp. 298-307. 81. Kim, W.-Y., and Kak, A. C. (1991). 3-d object recognition using bipartite matching embedded in discrete relaxation. IEEE Trans. Patt. Anal. Machine Infell. 13(3), 224-251. 82. Wheeler, M. D., and Ikeuchi, K. (1993). Sensor modeling markov random fields and robust localization for recognizing partially occluded objects. Proc. Image Understanding Workshop, Washington, D.C., April 1993, DARPA. 83. Faugeras, 0.D. (1993). “Three-Dimensional Computer Vision, A Geometric Viewpoint.” The MIT Press, London. 84. Stockman, G. (1987). Object recognition and localization via pose clustering. Computer Vision, Graphics Image Proc., pp. 361-387. 85. Bidlack, C. R., and Trivedi, M. M. (1991). Geometric model based object recognition and localization robotic manipulation tasks. Proc. Applications of Artificial Intelligence IX Conf., pp. 270-280, Orlando, FL, April 1991, SPIE, Bellingham, WA. 86. Chen, C. H., and Kak, A. C. (1989). A robot vision system for recognizing 3-d objects in low-order polynomial time. IEEE Trans. Sysr. Man Cyber. 19(6), 1535-1563. 87. DePiero, F. W., Trivedi, M. M., and Serbin, S. (1996). Graph matching using a direct classification of node attendance. Accepted by Patt. Recog. 29(6). 88. Gadagkar, H. P., and Trivedi, M. M. (1992). An integrated system for active exploration using contact and non-contact sensors. Proc. IEEE IROS ‘92 Conference, Raleigh, NC, July 1992, IEEE.
Author Index Numbers in italics indicate the pages on which complete references are given.
A
Ada, 57, 7 1, 94, 133 Agha, G. A,, 1 1 I , 133 Agin, G . , 244, 276 Agrawal, H., 2-3, 16, 23, 26, 29, 45 Ahituv, N., 209 Ahuja, N., 244, 275 Allen, R., 53, 133-134 Allen, T. J.. 209 alp^, P., 196-197, 209 Altscheuler, B. R., 250, 276 Altscheuler, M. D., 250, 276 Ambler, A. P., 251, 274, 277-278 Andrews, G. R., 67, 133 Andrews, T., 71, 91, 95, 133 Applegate, L., 207, 209 Attewell, P., I8 1, 209 Ayres, R. U . , 209
B Baily, M. N., 187-189, 192, 206, 209, 211 Bakos, J . Y . , 185, 209 Ball, T., 15-16, 45 Ballad, D. H., 274, 278 Balzen, H., 69, 86, 92, 133 Banker, R. D., 209 Banning, J. P., 17, 45 Barendergt, 33, 45 Barrow, H. G., 274, 278 Bar-Shalom, Y . , 257, 277 Barth, J. M., 17, 45 Barua, A., 185, 188, 199, 201, 209 Bates, S., 2, 37, 46 Baumol, W. J., 191, 209 Beck, J., 43, 46 Bender, D. H., 188, 196-197, 209 Beneger, J., 208, 209 Benjamin, R. I., 207, 209 Bent, 222, 240
Bergeretti, J.-F., 32, 46 Berman, E., 191, 195, 209 Berndt, E. R., 182, 185, 188, 191, 193-195, 202. 208, 210, 213 Bemstein, P., 7 I , 88, 1 17, 137 Bertino, E., 123-124, 133 Besl, P. J., 245, 249, 258, 269, 271-274, 276-277 Bickel, G., 25 I , 277 Bidlack, C . R., 274, 278 Bieman, J., 2, 44,46, 48 Biggerstaff, T. J.. 62, 133 Binford, T., 249, 276 Binford, T. O., 274, 278 Binkley, D., 3, 12-13, 16-17, 20-22, 35-38, 46-47 Binkley, D. W., 1 I , 42, 48 Blackman, S. A,, 191, 209 Blaha, M., 59, 69-70, 115-1 16, 138 Blinder. A. S., 207, 210 Blostein, D., 244, 275 Blum, M., 221-222, 239,240 Bobrow, D. G., 62, 71, 90, 106, 110, 117, 133, 138 Bolles, R. C., 274, 277-278 BOoch, G., 58, 69-70, 86, 88, 102, 106, 117, 119-120, 127, 133 Borgida, A., 62, 85, 88, 108, 117-118, 133, 137 Borrie, J. A., 257, 277 Boudriga, N., 62, 133 Bound, J., 191, 195, 209 Bow, S. T., 244, 275 Boyer, K. L., 247, 249-251, 274, 276-277 Brachman, R. J., 70, 108-109, 133 Brand, H., 188, 193, 196, 210 Braunstein, Y. M., 188, 196-197, 213 Bresnahan, T. F., 188, 202, 208, 210 Bricker, T., 2-3, 49 Brodie, M. L., 59, 116. 133-134 Brooke, G. M., 185, 188, 207, 210
279
AUTHOR INDEX
Brooks, R. A,, 274, 278 Browder, F. E., 234, 240 Brown, A. W., 60, 120. 134 Brown, C. M., 251, 274,277-278 Brynjolfsson, E., 182, 185, 188, 192, 195-203, 205-206, 208, 210, 212 Buchanan, B. G., 117, 134 Buda, A. J., 244, 275 Burks, B. L., 245, 247, 250-251, 276 Burstall, R. M., 274, 278
C Cardelli, L., 112, 134 Carley, L. R., 247, 249, 276 C a d , B., 32, 46 Cash, J., 207, 209 Cecil, J. L., 207, 210 Cha, S., 41, 48 Chakrabarti, A,, 188, 209 Champagne, R., 84-85, 119, 135 Champy, J., 198, 207, 210, 212 Chen, C. H., 244, 274, 275, 278 Chin, R. T., 274, 278 Chismar, W. G., 210 Choi, J., 15-16, 46 Choi, J.-D., 2, 46 Clarke, L. A., 55. 58, 78, 87, 99, 101-102, 139 Clarke, R. F., 197, 210 Clemens, E. K., 210 Coad, P., 70, 134 Cockburn, 206, 2 / 2 Conners, R. W., 244, 275 Constantine, L. L., 44, 49, 52, 55, 68-69, 86. 92, 138-139 Cook, S. C., 230, 240 Cooper, G. R., 257, 277 Cooper, R. B., 211 Cooprider, L. W., 76, 134 Cormen, T., 223. 225, 239. 240 Crawford, G. F., 251, 277 Crew, R., 34, 49 Croll, S., 13, 48 Cron, W. L., 188, 211 Crowston, K., 185, 211 Curley, K. F., 211 Cutillo, F., 2, 46
D Dalmia, A. K., 244, 274, 275 Damon, C., 91, 134 Danicic, S., 34, 46 Dart, S . A., 58, 134 Danvish, A. M., 244, 275 Date, C. J., 123, 134 Davenport, T. H., 198, 207, 211 David, P. A., 211 Davis, D. W., 244, 275 Davis, M., 234, 240 Davis, R., 117, 134 Delcourt, B., 84-85, 119, 135 Delor, E., 84-85, 119, I35 Delp, E. J., 244, 275 DeMillo, R. A,, 2, 29, 45 DeMori, P., 2, 48 Denison, E. E., 211 Denning, D. F., 32, 46 Denning, P. J., 32, 46 Denny, M., 188, 196-198, 213 DePiero, F. W., 245, 247. 249-251, 256, 263. 274, 276, 278 DeRemer, F., 55, 63, 72, 74, 87, 134 Diewert, W. E., 188, 197-198, 207, 211 Digital, 68, 134 Dor. D., 222, 240 Dos Santos, B. L., 188, 206-207, 211 DuBoui, E., 59, I39 Duda. R., 274, 277 Dudley, L., 188, 199, 211 Duke, J., 188, 193, 196, 210 Dulay, N., 84, I36 Dulberger, E. R., 180, 211 Dunseth, J. H., 245, 276 Dyer, C. R., 274. 278
E Eddy, F., 59, 69-70, 115-116, 138 Eder, J., 52, 134 Edwards, J . M., 58, 135 Eekelen, 33, 45 Eichel, P. H., 244, 275 Eisenbach, S., 84, 136 Ellison, R. J., 58, 134 El-Masri, W., 244, 275
281
AUTHOR INDEX Emb1ey.D. W., 70, 85, 112,J15-116. 118, 121, 127, 134 Emst, M., 34, 49
F Fan, T.-J., 274. 278 Faugeras, 0. D., 251, 274, 277-278 Feiler, P. H., 58, 134 Feldman, S. I., 72, 134 Ferber, J., 117, 134 Ferrante, J., 3, 13, 15-16, 46 Field, J., 33, 46 Fikes, R. E., 71, 90, 134 Findler, N., 108, 134 Fiore, R., 2, 46 Fischler, M. A,, 274, 277 Fisher, F. M., 206, 211 Fishman, D. H., I 18. 134 Flannery, B. P., 261-264, 277 Floyd, R. W., 221-222, 239. 240 Flynn, P. J., 274, 278 Foote, B., 87, 110, 135 Fortmann, T. E., 257, 277 Fox, S., 71, 138 Franke, R. H., 188, 196-197, 211 Fritzson, P., 2, 47 Fukazawa, Y., 2, 48 Fussenegger, 220, 240
G Gabow, 220, 240 Gadagkar, H. P., 245, 274, 276, 278 Gallagher, K. B., 2, 9, 1 1 , 40, 42-43, 46, 48 Gandle. M.. 32, 46 Gane, C., 68, 134 Ganguly, G., 274, 277 Garey, M. R., 229-23 1, 240 Garlan, D., 53, 133-134, 138 Gattiker, J. R., 244, 275 George, K. M., 55, 82, 121, 139 Giladi, N., 209 Girard, J., 2, 48 Glauert, 33, 45 Goguen, J. A,, 55, 58, 79, 135 Goldberg. A., 58, 71, 108, 135 Golub, G. H., 261-262, 277 Gopal, R., 33, 46
Gordon, R. J., 183, 188, 192, 206, 209, 211 Gotlieb, C . C., 188, 196-198, 213 Graham, J. R., 11, 42, 48 Greenspan, S., 62, 88, 135 Gremillions, L. L., 212 Griliches, Z., 188, 191-195, 198, 201, 205-206, 209, 211-212, 214 Grimson, W.E.L., 274, 278 Grove, A. S., 184, 212 Gruss, A,, 247, 249, 251, 276 Gupta, R., 37, 46 Gurbaxani, V., 210, 212 Guttag, J . V., 81, 135
H Habermann, A. N., 58, 76, 121, 134-135 Habermann, N., 53, 138 Hall, E. A,, 207, 210 Hammer, M., 198, 207. 212 Harbison, S. P., 58, 135 Harlow, C. A,, 244, 275 Harman, M., 34, 46 Harris, S. E., 188, 196-197, 212 Harrold, M. J., 13, 15-16, 37, 46-47 Hart, P., 274, 277 Hausler, G., 251, 277 Hausler, P., 8, 31, 47 Hausman, J. A,, 206, 212 Hawkins, R. A,, 244, 275 Hayes-Roth, F., 1 17, I39 Hebert, M., 244, 251, 274, 275, 277 Henderson-Sellers, B., 58, 135 Hendren, L., 2, 48 Hennessy, J.. 11, 48 Hibbard, L. S., 244, 275 Hitt, L., 182, 188, 196-203, 205-206, 208. 210, 212 Hoare, C.A.R., 73, 81, 135, 139 Hoffman, R., 245, 276 Holland, S. W., 245, 249, 276 Hood, R., 72, 102, 135 Horaud, P., 274, 278 Horgan, J., 3, 23, 26, 45 Horn, B.K.P., 255, 259, 274, 277-278 Horwitz, S., 2-3, 12-13, 15-17, 20, 35-37, 45-47.49 Hu,G., 245, 250, 276 Hudson, S., 85, 135 Hull, R., 59, I35
282
AUTHOR INDEX
I Ikeuchi, K., 274, 278 Inokuchi, S., 250, 277 Isaguirre, A,, 258, 263, 277
J Jackson, D., 40, 47 Jackson, M. A,, 63, 86, 135 Jacoboski, D. L.. 245, 247, 250-251, 276 Jain, A. K., 244, 274, 275, 278 Jain, R. C., 274, 277 Jarke, M., 85, 88, 117-1 18, 137 Jarvis, R. A., 245, 249, 273. 275 John, 222, 240 Johnson, D. S., 229-231, 240 Johnson, R. E., 87, 110, 135 Jololian, L., 53, I35 Jones, C. B., 81, 135 Jonscher, C., 188, 191, 212 Jorgenson, D. W., 180, 182, 187-188, 191, 202-204.212
K Kaiser, G. E., 81, 137 Kak, A. C., 247, 249-251, 274, 276, 278 Kalrnan, R. E., 257, 277 Karnbil, A,, 210 Kamkar, M., 2, 39, 47 Kanade, T., 244, 247. 249, 25 I , 275-276 Kaplan, R., 206, 208, 212 Kappel, G., 52, 134 Karp, R., 23 I , 240 Kasturi, R., 244, 275 Katz, J. L., 188, 196-197, 212 Katz. L. F., 191, 212 Katz, R. H., 121, 135 Kauffrnan, R. J., 209 Kawarnoto, E., 244, 275 Kehler, T. P., 71, 90, 134 Kernerer, C. F., 185, 209, 212 Kenedy, K., 72, 102, 135 Kennawar, 33, 45 Kennedy, K., 9, 47 Kim, M., 196-197, 209 Kim, W., 67, 69, 121, 135 Kim, W.-Y., 274, 278 King, R., 59, 85, 135
Kirova, V., 53, I35 Klashinsky, K., 85, 137 Knuth. D. E., 64, 135, 219, 223, 239, 240 Kofler, E., 58, 136 Kondo, T., 244, 275 Koral, K., 244, 275 Korel, B., 2-3, 22-23, 38, 47 Koubarakis, M., 85, 88, 117-1 18, 137 Kramer, J., 84, 136 Krarner, L., 84, 136 Kress, R. L., 245, 247, 249-250, 256, 263, 2 76 Kriebel, C. H., 183, 185, 188, 199, 201, 209-210, 212 Kron, H. H., 55, 63, 72, 74, 87, 134 Krotkov, E., 245, 276 Krueger, A. B., 188, 191, 203, 212 Kuhn, D. R., 53, 135 Kurtz, B. D., 70, 85, 112, 115-116, 118, 121, 127, 134 Kweon, S., 245, 276 Kwon, M. J., 199, 201, 213
L LaLonde, W., 62, 104, 108, I35 Lam, M., 11, 48 Larnsweerde, A,, 84-85, 119, 135 Landau, R., 212 Landauer, T. K., 185, 213 Landers, T., 71, 138 Landis, G., 91, 134 Lanubile, F., 2, 47 Laski, J., 2-3, 22-23, 38, 47 Lasserre, P., 188, 199, 211, 213 Lassiter, T. N., 245, 276 Lau, L. J., 188. 202, 205, 213 Lawrence, P. D., 250, 277 Leblang, D. B., 121, 135 Leiserson, C., 223, 225, 239, 240 Lenzerini, M., 62, 108, 136 Leveson, N., 41, 48 Levesque, H., 59, 136 Lewis, H. R.,227, 240 Lichtenberg, F. R., 188, 199-200, 205, 213 Liebermann, H., I 1 1, 128, 138 Linger, R., 8, 31. 48 Liskov, B., 91, 136 Livadas, P., 13, 48
283
AUTHOR INDEX Loan, C.F.V., 261-262, 277 Lochovsky, F. H., 67, 69, 121, 135 Longworth, H.. 2,48 Lorensen, W., 59, 69-70, 115-1 16, 138 Loveman, G. W., 188, 199, 201, 213 Lozano-Perez, T., 274, 278 Lyle, J. R., 2, 5-6, 8, I I , 39-40, 42-43, 46, 48 M Ma, S . D., 263, 277 Maccini, L. J., 207, 210 Magee, J., 84, 136 Magnet, M., 181, 181 Maier, D., 71, 118, 137 Malloy, B., 13, 15-16, 47 Malone, T. W., 207-208, 210-211, 213 Manber, U., 223, 240 Mandel, M. J., 181, 181 Marapane, S. B., 244, 275, 275 Mark, J. A,, 213 Markus, R., 250-251, 276 M a r , D., 244, 275 Martin, J., 69-70, 85, 115, 118, 136 Maruyarna, K., 2, 48 Matijasevic, Y., 234, 240 Matsuda, F., 250, 277 Mauer, D. C., 188, 206-207, 211 Maul, M., 251, 277 Maydan, D., 1 I , 48 McClone, J. S., 244, 275 McDermid, L. A., 60, 120, I34 McGillem, T. E., 257, 277 McIvor, A. M., 245, 247, 250, 276 McKersie, R. B., 213 McLean, G . D., 121, 135 Medioni, G . , 244, 274, 275, 278 Mendelson, H., 212 Merlo, E., 2, 48 Meyer, B., 58, 86, 90, 112, 136 Mili, A., 62, 133 Miller, B., 2, 46 Miller, V. E., 207, 213 Mills, D. Q., 207, 209 Mills, H.. 8, 31. 48 Minou, M., 250, 276 Mirza, M. J., 274, 277 Mittermeir, R. T., 53-54, 58, 62, 69, 114, 118, 133, 136, 139
Mokate, U. B., 244, 275 Monarchi, D. E., 129, 136 Moran, S., 223, 240 Mori, K., 244, 275 Morrison, C. J., 182, 185, 188, 191, 193-195, 210, 213 Moss, J. E. B..62, 136 Mossenbock, H.. 58, 136 Motschig-Pitrik, R., 56, 62, 88, 100, 114, 116, 118, 122-124, 136 Mukhopadhyay, T., 185, 188, 199, 201, 209, 211 Muller, H. A,, 72, 85, 102, 135, 137 Muller, R. J., 69-70, 139 Myers, G. J., 52, 86, 137-138 Mylopoulos, J., 59, 62, 71, 85, 88, 108, 117-1 18, 133-137, 139
N Narayanaswamy, K., 80, 137 Nardi, D., 62, 108, 136 Neighbors, J . M., 73, 137 Nelson, R. R., 213 Netzer, P., 2, 46 Nevatia, R.,274, 278 Ng, P. A., 53, 137-138 Nierstrasz, O., 58, 137 Norton, D. P., 206, 212 Notkin, D., 76, 121, 135 Noyelle, T., 197, 206, 213
0 Ockerbloom, J., 53, 131 Odell, J. J., 69-70, 85, 114-115, 118, 136-137 Okakzaki, A., 244, 275 Okutomi, M., 244, 275 Oliner, S . D., 188, 190-191, 200, 202-203, 213 Ono, K., 2, 48 Oppitz, M., 62, 136 Oshima, M., 249. 274, 276 Osterman, P., 188, 191, 213 Ott, L., 2, 44, 46, 48 Ottenstein, K., 3, 12-13, 46, 48 Ottenstein, L., 3, 12-13, 48
AUTHOR INDEX
P Papadimitriou, C. H., 227, 240 Pamas, D. L., 52, 5 5 , 86, 91, 137 Parsons, D. J., 188, 196-198, 213 Peffers, K. G., 188, 206-207, 211 Penedo, M. H., 60, 137 Perlis, A. J., 62, 133 Perry, D. E.. 53, 55, 76, 81-82, 134, 137 Phillips, D., 244, 275 Pircher, P. A,, 69-70, 139 Pitrik, R., 62, 100, 1 18, 137 Plasneijer, 33, 45 Platoff, M., 2, 48 Pohl, 222-223.240 Poole, I. E., 11, 42, 48 Popplestone, R. J., 251, 274, 277-278 Porat, M., 186, 191, 213 Porter, M. E., 207, 213 Prakash, A., 58, 61, 137 Pratt, V. R., 220-222, 239, 240 Prechelt, L., 53, 138 Premerlani, W., 59, 69-70, 115-1 16, 138 Preschem, K., 90. 137 Press, W. H., 261-264, 277 Prieto-Diaz, R., 73, 137 Prim, J., 2-3, 12-13, 36, 47 Pu, P., 258, 263, 277 Pugh, J., 62, 104, 108, I35 Pugh, W., 11, 48 Puhr, G. E., 129, 136 Pulley, L. B., 188, 196-197, 213 Purdy, A., 71, 118, 137 Purtilo, J., 55, 82-84, 137 Putnam, H., 234, 240 Pybum, P. J., 211-212
R Ramalingam, G., 2, 33, 46, 48-49 Ramamoorthy, C. V., 58.61, 137 Rapps, S., 37, 49 Reiser, M., 58, 137 Rennert, P. F., 123, 139 Reps, T., 2-3, 12-13, 16-17, 20, 35-36, 40, 43.46-49 Rheaume, D. P., 245, 276 Rice, M. D., 64, 67, 83, 137 Rioux, M., 251, 277 Rivest, R., 223, 225. 239, 240
Rivest, R. L., 221-222, 239, 240 Roach. S. S., 186, 188-189, 192-194, 213 Robinson, J., 234, 240 Robson. D., 58. 71, 108, 135 Rockart, J. F., 207, 209, 213 Rogers, H., Jr., 227, 233, 241 Rollins, E. J., 40, 47 Romer, P. M., 203, 213 Rosay, G., 17, 49 Rosenblum, L. S., 188, 191, 193, 210 Rosenfeld, A,, 244, 273, 275 Ross, D. T., 68, 137 Rossak, W., 53-54, 62, 114, 118-1 19, 135-136, 138 Rossay, G., 17, 40, 49 Rossol, L., 245, 249, 276 Rothemel, G., 13, 15-16, 47 Rowe, J. C., 245, 247, 250-251, 276 Rule, J., 181, 209 Rurnbaugh, J., 59, 69-70, 114-1 16, 138
S Sagiv, M., 17, 49 Saiedian, H., 55, 82, 121, 139 Samadzadeh, M. H., 55, 82, 121, 139 Santal. A., 32, 46 Sarson. T., 68, 134 Sato, K., 250, 277 Scacchi, W., 80, 82, 137-138 Schayes, M.-C.. 84-85, 119, 135 Scheevel, M., 67, 139 Schepers, J., 53, 138 Scherer, F., 213 Schlemmer, R. A,, 53, 139 Schmidt, J. W., 59, 134 Schneider, F. B., 67, I33 Schneider, K., 192, 214 Schrefl, M., 52, 134 Schuchardt, B., 71, 118, 137 Sciore, E., 121, 138 Scott Morton, M. S., 207, 209, 214 Seidman, S. B., 64, 67, 83, 137 Selleck, C. B., 245, 247, 250-251, 276 Serbin, S., 274, 278 Shafer, S. A,, 244, 275 Shah, J., 244, 275
285
AUTHOR INDEX Shahmehri, N., 2, 47 Shaw, M., 53, 138 Shilling, J. J., 123, 138 Shimeall, T., 41, 48 Shimomura, T., 2, 49 Shirai, Y., 249, 274, 276 Short, J., 198, 211 Shortliffe, E., 117, 134 Sichel, D. E., 188, 190-191, 200, 202-203, 213 Siegel, D., 188, 193, 195, 214 Simi, M., 62, 108, 136 Sinkel, K., 71, 133 Sivaguranathan, Y., 34, 46 Sloman, M., 84, 136 Smith, A. M., 188, 197-198, 207,211 Smith, D.C.P., 70, 108, 118, 138 Smith, J. M., 71, 105, 108, 118, 138 Smith, M., 2, 48 Smith, R. B., 11 I, 139 Snir, M., 223, 240 Snow, C. P., 180, 214 Snyder, A., 105, 110-1 11, 138 Soare, R. I., 22, 233, 241 Sobol, I. M., 264,277 Sobol, M. G., 188, 211 Soffa, M. L., 37, 46 Solow, R. M., 180, 180 Sosa, G. L., 212 Spafford, E., 2, 45 Stabell, C. B., 214 Stay, J. F., 69, 138 Steensgaard, B., 34, 49 Stefik. M., 110, 138 Stein, L. A,, 11 I , 128, 138 Stevens, W. P., 52, 138 Stiroh, K., 180, 182, 187-188, 191, 202-204, 212 Stockman, G., 245, 250, 274, 276, 278 Stoneman, P., 199, 201, 213 Storey, V. C., 114, 116, 136, 138 Strang, G., 261-262, 277 Strassmann, P. A,, 188, 196-197, 214 Stroustrup, B., 58, 71, 138 Stuckle, E. D., 60, 137 Summers, J., 258. 263, 277 Suwa, M., 249, 276 Sweeney, P. F., 123, 138 Szermer, W., 2, 47
T Tada, S., 249, 251, 276 Tarjan, R. E., 221-222, 239, 240 Teukolsky, S. A., 261-264, 277 Thayer, S. M., 263, 277 Thomas, J. W., 76, 138 Thorpe, C., 244, 275 Thurow, L., 189, 214 Thuss, J., 2, 48 Tichy, W. F., 53, 72, 77, 102, 108, 138 Tip, F., 32-33, 46, 49 Tjoa, A. M., 123, I39 Toboada, J., 250, 276 Tokutsu, I., 188, 202, 205, 213 Tomlinson, C., 67, 139 Trajtenberg, M., 202, 206, 210, 214 Treacy, M. E., 185, 211 Trivedi, M. M., 244-245, 263, 273-274, 275-278 Tsai, J. J., 55, 139 Tsai, W. T., 58, 61, 137 Tsunekawa, S., 244, 275
U Ullman, J. D., 123, 139 Ungar, D., 11I , 128, 138-139 Usuda, Y., 58, 61, 237
V
Valkenburg, R. J., 245, 247, 250, 276 Venkatesh, G. A,, 31-32, 46, 49 Vetterling, W. T., 261-264, 277 Vinek, G., 123, 139 Visaggio, G., 2, 46-47
W
Wagner, M., 2, 48 Wallace, D. R., 1 I, 42, 48 Walton, R. E., 213 Wand, Y., 86, 139 Ward, M. R., 245, 249, 276 Warren, J., 3, 13, 46 Wasserman, A. I., 69-70, 139 Waterman, D. A., 117, I39 Watts, L., 207, 214
286
AUTHOR INDEX
Weber, R., 86, 139 Wegner, N., 58, 69, 105, 112, 139 Wegner, P., 112, 134 Wei, G.-Q., 263, 277 Weill, L., 188, 199, 205, 207, 214 Weise, D., 34, 49 Weiser, M. D., 2-3, 11, 18. 38-39, 48-49 Weitzendorf, T., 196- 197, 214 Weyuker, E. J., 37, 49 Wheeler, M. D.. 274, 278 Wigand, R.. 196-197, 214 Wileden. J. C., 55, 58, 78, 87, 99, 101-102, 139
Wilson, D. D., 181, 185, 198, 214 Wirth, N., 57-58, 71, 73, 136, 139 Witt, B., 8, 31, 48 Wolf, A. L., 55, 58, 78, 87, 99, 101-102, 139 Wolf, E. N., 191, 209 Wong, H., 71, 88, 117, 137 Wong, H.K.T., 108, 118, 133 Wonnacott, D.. 11, 48
Woodfield, S. N., 70, 85, 112, 115-116, 118, 121, 127, 134
Woodham, R. J., 244, 275
Y Yang, W., 3, 35, 49 Yao. F. F., 220, 240 Yau, S. S., 55, 139 Yeh, R. T., 53, 139 Yeung, K. K., 250, 277 Yourdon, E., 44, 49. 55. 68-70, 86, 92, 134, 139
Yu, E., 59, 139
Z Zachary, G . P., 180, 214 Zand, M. K., 55, 82, 121, 139 Zwick, U., 222, 240
Subject Index A
C
Abstraction component interconnection, 118-121 model checking, 160-163 Accuracy, SL ranging, 245-247 Acquisition, SL ranging, 247, 252-258 Ada, 102-103, 112, 124, 126 Aggregation, component interconnection, 114-116 Alias, program slicing, 21-22 ALMA environment, 84-85 ALT properties, see Transitions model Ambient lighting, SL ranging, 248 Annotation, design language, 159-160 Application interconnection graph, 65 Architecture, interface issues, 52-53, 54; see also Component interconnection Arithmetic hierarchy, problem complexity, 217, 238-239 Array, program slicing, 10 Assert annotation, 160 Assumption, software cost reduction, 146, 154-155 Automaton, MIN AUT, 232 Axiom system, definitions, 236
C + +, component interconnection, 105, 124, 125, 126 CACTIS project, 85 Calibration, SL ranging, 245-247, 258-264 Calling-context slice, 38 CASE, see Computer-aided software engineering Child component, 89-90 Chopping, program, 39-40 CI, see Component interconnection Clique, 231 Companies, productivity studies, 196-201 Compiler directive, 67-68, 72 Complexity of problems, 215-241 arithmetic hierarchy, 217, 238-239 background information, 216-218 computability, 228, 233 decidable problems, 235-236 decision trees, 216, 217, 218-225 HI-LO, elements, 222-223 ith largest element, 220-221 maximum element, 218-220, 222-223, 224 median element, 221-222 minimum element, 222-223 sorting, 223 definitions, 217-219, 225-226, 228-230, 233-238 domain size, 224-225 enumerable problems, 217 execution time, 216,223-224, 227-230 logical theories, 234-236 model of computation, 216-220,223-232 decision trees, 218-220, 223-225 P versus NP, 217, 225-232 NP-completeness, 230-232 polynomial time, 227-230 recursively enumerable sets, 236-237 recursive problems, 217, 236 reductions, 237-238 s-t connectivity problem, 225, 226 strings, 228-230
B Backbone geometry, SL ranging, 245-247, 249-250 Backward program slicing, 3 Basic interconnection graph, 64-67 interconnection relationships, 96-99 MIL-75, 73-75 Behavioral requirement, software cost reduction, 144-145, 153-154 BIG, see Basic interconnection graph Business, see Information technology and productivity
288
SUBJECT INDEX
Complexity of problems, continued traveling salesperson problem, 225, 226-227,228-229,231 Turing machine, 227-228,230-231,233 unsolvable problems, 233-234 upper/lower bounds, 216, 218-225 Component interconnection, language features, 51-139 background information, 52-62 datalknowledge modeling, 59-60 development process, 61-62 history, 52-53, 55 software engineering/programming language, 57-59 CASE environments, 60, 69 definitions, 55-56, 60-61, 132 features for expressing CI, 86-130 comparison, 124-125, 126-127 encapsulation, 90-95 kinds of components, 86-88 nesting, 88-90 relationships, 96-124 granularity, 96-100, 111 inheritance, 109-1 14 precision, 96-100 semantics, 100-130 syntactic structure, 100 future research, 131 graphs, 64-67,73-76,96-100 self-contained language, 72-84 semantics, 63-67,7943, 100-130 aggregation/decomposition, 114-1 16 generalization/specialization, 108-114, 128, 129 member-of relationship, 116 metaknowledge, 117-118, 130 MILS, 79-83, 105, 121-122, 125, 126 part-of relationship, 114-116 provision/requisition of access, 101-108, 128, 129 relationships, 63-67, 100-130 reprcsentation abstraction, 118-121 version control, 121-122, 130 software development environment, 73, 76 specification, 57-59, 62-86, 125, 128-130 compiler option, 67-68 data/knowledge modeling. 70-71 design languages, 68-70 Gandalf prototype, 77-78 metamodeling, 85
MILS, 72-77,79-83 model, 62-67 PIC, 78-79 programming languages, 71-72 software environments, 84-85 universal interconnection language, 125, 128-130 static versus evolutionary issues, 61-62, 83 Computability, 228, 233 Computational tree logic, 147-151 Computer-aided software engineering, 60, 69 Computer vision, see Structured light for computer vision Concrete interface, 81 Conditioned event, model checking, 144 Consistency axiom system, definition, 236 model checking, 156-159 Consumer surplus, productivity studies, 201-205 Control dependence, program slicing, 13, 24.25 Control-Row graph definition, 4 program slicing, 5-12 Controlled state variable, model checking, 144 Correspondence, SL ranging, 250 Cost, computing, 183-185, 201-205; see also Software cost reduction Cost ratio of spans, 262 CTL, see Computational tree logic
D Database design, 59-60, 123-125 representation abstraction, 119-120 Datacube, 252,255 Data-flow diagram, 68-69 Data-flow problem dynamic program slicing, 22-26 static program slicing, 5-12 Data modeling, component interconnection, 59-60,70-71 Data slicing, 44-45 DDG, see Dynamic dependence graph Debugging, program slicing, 38-40 Decidable axiom system, definition, 236
SUBJECT INDEX Decidable logical language, 235-236 Decidable problem, 235-236 Decidable set, definition, 233 Decision tree, problem complexity, 216, 217,218-225 Decomposition, component interconnection, 114-116 Decomposition slicing, 42-43 Definition use, definition of, 24 Deflator, price, 183 Denotational slicing, 31-32 Dependence, component interconnection, 115 Dependence graph, 3 DDG, 28-29 PDG, 12-21,26-27 VDG, 34 Dependence relation, program slicing, 33-34 Descriptive semantics, program slicing, 31-32 Design backbone geometry, 245-250 model checking, 156-168, 174-176 Design flow graph, 160-163 Design language component interconnection, 68-70 model checking, 159-160 Dicing, program, 39-40 Differencing, program slicing, 35-36 Directed acyclic graph, 100 Distributed computing, 53 DRD, see Dynamic reaching definition Dynamic dependence graph, 28-29 Dynamic-plane geometry, 247, 249 Dynamic reaching definition, 28, 30-31 Dynamic slicing, 3, 22-31, 33-34 Dynamic storage allocation, 231-232
E Economics, of information technology, see Information technology and productivity Edge problem complexity, 225 program slicing, 13-15, 17, 20 Encapsulation, component interconnection, 90-95 Enumerable problem, 217
289
Enumerable set, 236-237 Environmental assumption, software cost reduction, 146, 154-155 Equipment, information technology, 189-190 Event, model checking, 144 Evolutionary issues, component interconnection, 61-62, 83 Executable slicing, 3, 4-5 Execution history, 22 Execution pattern, 37-38 Execution time, 216,223-224,227-230
F Fault-tree analysis, 41 Financial service sector, productivity, 196, 198 Finite-state machine model checking, 160, 162-167 Turing machine, 227-228 Firms, productivity studies, 196-201 Fixed-plane geometry, 247, 249 Flat structure, component interconnection, 89-90 Flow dependence, program slicing, 13 Flying-dot illumination, 251 Forward slicing, 3 Functional cohesion, 44-45 Functional diversity, 40-42 Functional semantics, 31
G Gandalf prototype, component interconnection, 77-78 General graph, 100 Generalization/specialization hierarchy, 108-114, 128, 129 Generic component interconnection language, 128-130 Global component, 88 Goal, software cost reduction requirements specification, 146-147, 155-156 types, 158-159 verification, 167-168 Godel’s incompleteness theorem, 236 Goro statements, 8-10, 15-16
290
SUBJECT INDEX
Granularity, 96-100, 111 Graph definitions, 4, 225 interconnection, 64-67, 73-76, 96-100 model checking, 160-163 problem complexity, 225-227, 229-231 program slicing, 11, 34 structured light ranging, 274 Graph coloring, 231 Graph-reachability problem dynamic program slicing, 26-31 static program slicing, 12-22 Gross domestic product, 203 Gross national product, 189-191 Growth, economic, see Information technology and productivity G/S hierarchy, see Generalization/ specialization hierarchy
H Hamiltonian path, 231 Heterogeneity, large system, 53 Hilbert problems, 234 HI-LO,, elements, decision tree, 222-223
I Identity relation, definition, 24-25 IDG, see International Data Group Illumination, structured light, 251-252 Image processing, see Structured light for computer vision Implementation part, component interconnection, 91 Independence, component interconnection, 115 Index set, definition, 234 Industry, productivity studies, 192-195 Inflation, 205; see also Price Information flow relation, 32-33 Information processing equipment, 182, 189 Information technology and productivity, 179-214 consumer surplus, 201-205 cross-sector studies, 201 data problems, 191, 192, 195, 198,201, 205-208 definitions, 182-183
economy-wide studies, 187, 189-192 equipment, 189-190 firm-level studies, 196-201 financial services, 196, 198 future research, 205-208 gross domestic product, 203 gross national product, 189-191 IDG database, 200-201 industry-level studies, 192-195 information worker studies, 191-192 manufacturing sector, 192-195, 198-201 marginal product, 200 MPIT database, 199-201 prices, 183-185, 201-205, 206 productivity paradox, 179-187 service sector, 192-194, 196-198, 201 summaries, of studies, 188, 193, 197, 199. 202 trends, 183-187 Inheritance, G/S hierarchy, 109-114 Initial annotation, 159 Integer programming, 231 Integration, program slicing, 36 Interconnection of software components, see Component interconnection Interface, see also Component interconnection concrete, 81 issues, 52-53, 91, 129 module, 69 International Data Group, 200-201 Interprocedural slicing, 11-12, 16-22 Intraprocedural slicing, 13-16 IRIS, component interconnection, 127 IT, see Information technology and productivity
K
KEE, component interconnection, 110, 127 Knowledge representation, 59-60,70-71
L Labeled block, definition, 9-10 Labor productivity, definition, 182-183; see also Information technology and productivity
SUBJECT INDEX Language features, component interconnection, see Component interconnection Laser, 245, 250; see also Structured light foI computer vision Library interconnection language, 79-80 Light, structured, see Structured light for computer vision LIL, see Library interconnection language Logic, model checking, 147-153 Logical language, definition, 234-235 Logical theories, decidability, 234-236 Loop, program slicing, 13-14, 30-31 LOOPS, component interconnection, 106, 124, 127 Lowerfupper bounds, see Upperllower bounds
M Machine vision, see Structured light for computer vision Maintenance, software, 42-43 Management Productivity and Information Technology database, 199-201 Manufacturing sector, productivity studies, 192- 195, 198-201 Marginal product, 200 Maximum element, decision tree, 218-220, 222-223,224 Median element, decision tree, 221-222 Member-of relationship, 116 Merging, program slicing, 36 Metaclass, 88, 130 Metaknowledge, 117-118, 130 Metamodeling, 85 MIL, see Module interconnection language MIN AUT, see Automaton Minimum cardinality key, 232 Minimum element, decision tree, 222-223 Mode, model checking, 144,152-153 case study, 168-171 Model checking, 141-178 automatically generated properties, 157-158, 165-167 background information, 142-143 case study, 168-176 assumptions and modes. 168-171 design analysis, 174-176 requirements analysis, 171-174
29 1
computational tree logic, 147-151 designs, 156-168 abstraction, 160-163 ALT properties, 158, 165, 167 consistency, 156-159 definitions, 161-163, 164 language, 159-160 OLT properties, 158, 165-167 verifying properties, 163-168 finite-state machine, 160, 162-167 optimistic analysis, 164 pessimistic analysis, 164 safety properties, 157-158 SCR requirements specification, 143-147, 151-156 behavioral requirements, 144-145, 153-154 environmental assumptions, 146, 154- 155 mode transitions model, 152-153 system goals, 146-147, 155-156 SMV checker, 155-156 system goals, 146-147, 155-156, 158-159, 167- 168 transitions model, 165-171 ALT properties, 158, 165, 167 case study, 168-171 OLT properties, 158, 165-167 Model of computation, 216 decision trees, 218-220 P versus NP, 217, 225-232 Mode transitions model, software cost reduction, 152-153 MODULA-2, 103, 126 Module compared to component, 55-56,60 family, 81 Module interconnection, 55-56 Module interconnection language, see also Component interconnection MIL-75, 55,63,72-76,87, 126 NUMIL, 80-82, 121-122, 125, 126 POLYLITH MIL, 82-83, 105 RMTIL, 82 second generation, 76-77 semantics specification, 79-83 Module interface, 69 Monitored state variable, model checking, 144
292
SUBJECT INDEX
MPIT, see Management Productivity and Information Technology database Multifactor productivity, definition, 182
N Neighbor nodes, definition, 225-226 Nesting, component interconnection, 88-90 Network reliability, 231 Node, 225-226 Nondeterministic polynomial time, 229-230 Nonrecursive set, definition, 233 NP-completeness, 230-232 N P versus P problems, 217, 225-232 NUMIL, 80-82, 121-122, 125, 126
0
Object-oriented design, 88, 127 access, 106-107 databases, 59-60, 121, 123-125 representation abstraction, 120-121 structured, 69-70 Object-oriented programming language, 59-60, 85 Object-oriented systems analysis, 112-1 13, 127 OCAM, see Office, computing, accounting machinery Office, computing, accounting machinery, 182, 189 OLT properties, see Transitions model OOD, see Object-oriented design Optimistic analysis, model checking, 164 Organizational relationship, 63 ORION, component interconnection, 115, 118, 127 OSA, see Object-oriented systems analysis Output, productivity, 203-205; see also Information technology and productivity definition, 183 gross domestic product, 203 gross national product, 189-191
P Package, compared to program, 78 Parallel slicing, 34 Parameter passing, program slicing, 21-22 Parametric slicing, 33 Parent component, 89-90 Partial function, definition, 233 Part-of relationship, 114-116 PDG, see Procedure dependence graph; Program dependence graph Pecuniary externality. 201-202 Pessimistic analysis, model checking, 164 PIC, see Precise interface control Pixel-level analysis, 250-251 P versus N P problems, 217, 225-232 Pointer, program slicing, 11, 29-31 POLYLITH module interconnection language, 82-83, 105 Polynomial time, 227-230 nondeterministic, 229-230 Precise interface control, 78-79, 124, 126 Precision, component interconnection, 67, 96-100 Price, computing, 183-185, 201-205 Price deflator, 183 Price index, 206 PRIME, see Structured light for computer vision Private versus public resources, component interconnection, 91 Problems, complexity, see Complexity of problems Procedure dependence graph, 17-21 Producers’ durable equipment, 189 Productivity paradox, 179-187; see also Information technology and productivity Profile imaging module, see Structured light for computer vision Program, compared to package, 78 Program chopping, 39-40 Program dependence graph, 12-18,26-27 Program dicing, 39-40 Programming language, 57-60,71-72, 85; see also Component interconnection Program slicing, 1-49 alternative approaches, 31-34 denotational slicing, 31-32 information flow relations, 32-33
293
SUBJECT INDEX
parallel slicing, 34 parametric slicing, 33 value dependence graphs, 34 applications, 34-45 debugging, 38-40 dependence relation, 33-34 descriptive semantics, 31-32 differencing, 35-36 functional cohesion, 44-45 integration, 36 reverse engineering, 43-44 software maintenance, 42-43 software quality assurance, 40-42 testing, 36-38 background information, 1-4 backward slicing, 3 definitions, 3, 4-5, 9-10, 24-25, 30 denotational slicing, 31-32 dynamic slicing, 3, 22-31 data-flow problem, 22-26 dependence relations, 33-34 graph-reachability problem, 26-31 executable slicing, 3, 4-5 forward slicing, 3 information flow relations, 32-33 interprocedural slicing, 11-12, 16-22 intraprocedural slicing, 13-16 parametric, 33 static slicing, 5-22 data-flow problem, 5-12 graph-reachability problem, 12-22 Provision access, 101-108, 128, 129 Pseudo-label, definition, 10 Public versus private resources, component interconnection, 91
R Radar, 245 Ranging, structured light, see Structured light for computer vision Record, program slicing, 11, 30 Recursively enumerable set, 236-237 Recursive problem, 217, 236 Recursive set, definition, 233 Reducible problem, 237-238 Reference relationship, 63 Refined interconnection graph, 66-67, 75-76 Registration, SL ranging, 258
Relationships, component interconnection, 63-67,96-130 Relevant set, program slicing, 5-6 Representation abstraction, 118-121 Representational relationship, 63-64 Requirements specification, see Specification Requisition access, 101-108, 128, 129 Reuse, 53,62, 113-114 Reverse engineering, program slicing, 43-44 RIG1 project, 85 RMTIL, 82 Route, definition, 226 Run-length coding, 255-256 S
Safety, model checking, 157-158 Scheduling, 232 SCR, see Software cost reduction SDE, see Software development environment SDG, see System dependence graph Segmentation, SR ranging, 274 Self-contained language, 72-84 Semantic differences, program slicing, 35 Semantics component interconnection, 63-67, 79-83, 100-130 model checking, 147-153 program slicing, 31-32 Sensitivity analysis, SR ranging, 264, 267-268 Sentence, definition, 235 Separation, of components, 91-92, 129 Service sector, productivity studies, 192-194, 196-198.201 Shadowing, SL ranging, 248 Simplified water-level monitoring system, see also Water-level monitoring system model checking designs, 157-158, 160, 163, 165-168 requirements, 145, 154-155 Singular value decomposition, SR calibration, 262 SL, see Structured light for computer vision Slicing, program, see Program slicing Slicing criterion, 3 SmallTalk, 104-105, 109-110, 124, 127
294
SUBJECT INDEX
SMV model checker, 155-156 Software component interconnection, see Component interconnection Software cost reduction, 143-147, 151-156; see also Model checking Software development environment, 73, 76, 84-85 Software engineering, 57-59, 60 Software maintenance, 42-43 Software quality assurance, 40-42 Solvable set, definition, 233 Sorting, decision tree, 223 Specialization, see Generalization/ specialization hierarchy Specification component interconnection, 57-59, 62-86, 125, 128-130 model checking, 143-147,151-154, 171-174 Specification part, component interconnection, 91 Static issues, component interconnection, 61-62, 83 Static slicing, 5-22 s-t connectivity problem, 225, 226 Straight-line program, 5-6 String, problem complexity, 228-230 Structure, component interconnection, 67, 69-70.89-90, 100 Structured light for computer vision, 243-278 accuracy, 245-247 acquisition, 252-258 image processing operations, 254-257 optical components, 252-254 ranging computations, 257-258 acquisition speed, 247 background information, 244-249 active versus passive approaches, 244-245 backbone geometry, 245-247 design challenges, 245-249 calibration, 245-247, 258-264 model evaluation, 263-264,265-266 model formulation, 258-260 model solution, 261-263 design issues, 249-252 backbone geometry, 249-250 correspondence, 250 illumination structures, 251-252 pixel-level analysis, 250-251
limitations, SL ranging, 247-248 metrics, model evaluation, 263-264, 265-266 performance benchmarks, 269, 271-272 PRIME, 245-249,252,272-274 calibration, 258-264 image processing, 256 optical components, 252-254 performance benchmarks, 269, 271-272 ranging computations, 257 sensitivity analysis, 267-268 segmentation, 274 sensitivity analysis, 264, 267-268 Structured program, 6-8 Sublist property, program slicing, 23 Surface reflectivity, SL ranging, 247-248 SWLMS, see Simplified water-level monitoring system Syntactical structure, component interconnection, 67, 100 System dependence graph, 16-21 Systems integration, 52-53; see also Component interconnection
T TAXIS, component interconnection, 88, 124, 125, 126 Technological revolution, 180; see also Information technology and productivity Temporal logic, 147-148 Test control, definition, 24 Testing, program slicing, 36-38 3-D computer vision, see Structured light for computer vision Total factor productivity, definition, 182 Transitions model, 152-153 ALT properties, 158, 165, 167 case study, 168-171 OLT properties, 158, 165-167 Traveling salesperson problem, 225, 226-221, 228-229, 231 Tree graph, 100 Triangulation, SL ranging, 245-247 Triggering event, model checking, 144 TSP, see Traveling salesperson problem Turing machine, 227-228,230-231 computability, 228, 233 Turing reducibility, 237
295
SUBJECT INDEX
U Undecidable set, definition, 233 Universal component interconnection language, 125, 128-130 Unsolvable problem, 233-234 Unsolvable set, definition, 233 Unstructured program, 8-10 Update annotation, 160 Upperllower bounds, problem complexity, 216 decision tree model, 218-225 P versus N P problems, 225
V Value dependence graph, 34 Vbase, component interconnection, 95, 127
VDG, see Value dependence graph Verification, model checking, 163-168 Version control, component interconnection, 121-122, 130 Vertex problem complexity, 225 program slicing, 13-21
W Water-level monitoring system, 168-176; see also Simplified water-level monitoring system Weighted directed graph, 225 WLMS, see Water-level monitoring system Workforce productivity, see Information technology and productivity
This Page Intentionally Left Blank
Contents of Volumes in This Series
Volume 1 General-Purpose Programming for Business Applications CALVIN C. GOTLIEB Numerical Weather Prediction NORMAN A. PHILLIPS The Present Status of Automatic Translation of Languages YEHOSHUA BAR-HILLEL Programming Computers to Play Games ARTHUR L. SAMUEL Machine Recognition of Spoken Words RICHARD FATEHCHAND Binary Arithmetic GEORGE W. REITWIESNER Volume 2 A Survey of Numerical Methods for Parabolic Differential Equations JIMDOUGLAS, JR. Advances in Orthonormalizing Computation PHILIPJ. DAVISAND PHILIPRABINOWITZ Microelectronics Using Electron-Beam-Activated Machining Techniques KENNETH R. SHOULDERS Recent Developments in Linear Programming SAULI. GASS The Theory of Automata: A Survey ROBERT MCNAUGHTON Volume 3 The Computation of Satellite Orbit Trajectories SAMUEL D. CONTE Multiprogramming E. F. CODD Recent Developments in Nonlinear Programming PHILIPWOLFE Alternating Direction Implicit Methods GARRET BIRKHOFF, RICHARD S. VARGA, AND DAVID YOUNG Combined Analog-Digital Techniques in Simulation F. SKRAMSTAD HAROLD Information Technology and the Law REEDC. LAWLOR
297
298
CONTENTS OF VOLUMES IN THIS SERIES
Volume 4 The Formulation of Data Processing Problems for Computers WILLIAM C. MCGEE All-Magnetic Circuit Techniques DAVID R. BENNION AND HEWITID.CRANE Computer Education HOWARD E. TOMPKINS Digital Fluid Logic Elements H. H. GLAETTLI Multiple Computer Systems WILLIAM A. CURTIN Volume 5 The Role of Computers in Election Night Broadcasting JACKMOSHMAN Some Results of Research on Automatic Programming in Eastern Europe WLADYSLAW TURSKI A Discussion of Artificial Intelligence and Self-Organization GORDON PASK Automatic Optical Design ORESTES N. STAVROUDIS Computing Problems and Methods in X-Ray Crystallography CHARLES L. COULTER Digital Computers in Nuclear Reactor Design ELIZABETH CUTHILL An Introduction to Procedure-Oriented Languages HARRY D. HUSKEY Volume 6 Information Retrieval CLAUDE E. WALSTON Speculations Concerning the First Ultraintelligent Machine IRVING JOHNGOOD Digital Training Devices CHARLES R. WICKMAN Number Systems and Arithmetic HARVEY L. GARNER Considerations of Man versus Machines for Space Probing P. L. BARGELLINI Data Collection and Reduction for Nuclear Particle Trace Detectors HERBERT GELERNTER Volume 7 Highly Parallel Information Processing Systems JOHNC. MURTHA
CONTENTS OF VOLUMES IN THIS SERIES
299
Programming Language Processors RUTHM. DAVIS The Man-Machine Combination for Computer-Assisted Copy Editing A. DANIELSON WAYNE Computer Aided Typesetting R. BOZMAN WILLIAM Programming Languages for Computational Linguistics ARNOLD C. SATTERTHWAIT Computer Driven Displays and Their Use in Manh4achine Interaction V A N DAM ANDRIES Volume 8 Time-shared Computer Systems THOMAS N. PYKE,JR. Formula Manipulation by Computer JEANE. SAMMET Standards for Computers and Information Processing T. B. STEEL,JR. Syntactic Analysis of Natural Language NAOMISAGER Programming Languages and Computers: A Unified Metatheory R. NARASIMHAN Incremental Computation LIONELLO A. LOMBARD[ Volume 9 What Next in Computer Technology? W. J. POPPELBAUM Advances in Simulation JOHNMCLEOD Symbol Manipulation Languages PAULW. ABRAHAMS Legal Information Retrieval S. FRAENKEL AVIEZRI Large Scale Integration- An Appraisal L. M. SPANDORFER Aerospace Computers A. S. BUCHMAN The Distributed Processor Organization L. J. KOCZELA Volume 10 Humanism, Technology, and Language CHARLES DECARLO Three Computer Cultures: Computer Technology, Computer Mathematics, and Computer Science PETER WECNER
300
CONTENTS OF VOLUMES IN THIS SERIES
Mathematics in 1984-The Impact of Computers BRYAN THWAITES Computing from the Communication Point of View E. E. DAVID, JR. Computer-Man Communication: Using Computer Graphics in the Instructional Process FREDERICK P. BROOKS, JR. Computers and Publishing: Writing, Editing. and Printing V A N DAMA N D DAVID E. RICE ANDRIES A Unified Approach to Pattern Analysis ULFGRENANDER Use of Computers in Biomedical Pattern Recognition S. LEDLEY ROBERT Numerical Methods of Stress Analysis WILLIAM PRACER Spline Approximation and Computer-Aided Design J. H. AHLBERC Logic per Track Devices D. L. SLOTNICK
Volume 11 Automatic Translation of Languages Since 1960: A Linguist’s View HARRY H. JOSSELSON Classification, Relevance, and Information Retrieval D. M. JACKSON Approaches to the Machine Recognition of Conventional Speech KLAUSW. OTTEN Man-Machine Interaction Using Speech DAVID R. HILL Balanced Magnetic Circuits for Logic and Memory Devices R. B. KIEBURTZ A N D E. E. NEWHALL Command and Control: Technology and Social Impact ANTHONY DEBONS
Volume 12 Information Security in a Multi-User Computer Environment JAMES P. ANDERSON Managers, Deterministic Models, and Computers G. M. FERRERO DIROCCAFERRERA Uses of the Computer in Music Composition and Research HARRY B. LINCOLN File Organization Techniques DAVID C. ROBCRTS Systems Programming Languages R. D. BERCERON, J. D. GANNON, D. P. SHECHTER, F. w . TOMPA, AND A. VAN DAM Parametric and Nonpardmetric Recognition by Computer: An Application to Leukocyte Image Processing JUDITH M. S . PREWITT
CONTENTS OF VOLUMES IN THIS SERIES Volume 13
Programmed Control of Asynchronous Program Interrupts RICHARD L. WEXELBLAT Poetry Generation and Analysis JAMESJOYCE Mapping and Computers PATRICIA FULTON Practical Nautical Language Processing: The REL System as Prototype FREDERICK B. THOMPSON AND BOZENA HENISZ THOMPSON Artificial Intelligence-The Past Decade B. CHANDRASEKARAN Volume 14
On the Structure of Feasible Computations J . HARTMANIS AND J. SIMON A Look at Programming and Programming Systems T. E. CHEATHAM, JR., AND JUDYA. TOWNLEY Parsing of General Context-Free Languages SUSAN L. GRAHAM AND MICHAEL A. HARRISON Statistical Processors W. J. POPPELBAUM Information Secure Systems DAVID K. HSlAO AND RICHARD I. BAUM Volume 15
Approaches to Automatic Programming ALANW. BIERMANN The Algorithm Selection Problem JOHNR. RICE Parallel Processing of Ordinary Programs DAVIDJ. KUCK The Computational Study of Language Acquistion H. REEKER LARRY The Wide World of Computer-Based Education DONALD BITER Volume 16
3-D Computer Animation CHARLES A. CSURI Automatic Generation of Computer Programs NOAHS. PRYWES Perspectives in Clinical Computing KEVINC. O'KANEAND A. HALUSKA The Design and Development of Resource-Sharing Services in Computer Communication Networks: A Survey SANDRA A. MAMRAK
301
302
CONTENTS OF VOLUMES IN THIS SERIES
Privacy Protection in Infomation Systems REINTURN Volume 17 Semantics and Quantification in Natural Language Question Answering w . A. WOODS Natural Language Information Formatting: The Automatic Conversion of Texts to a Structured Data Base NAOMI SAGER Distributed Loop Computer Networks MINGT. Lru Magnetic Bubble Memory and Logic TIENCHICHENA N D Hsu CHANG Computers and the Public’s Right of Access to Government Information ALANF. WESTIN Volume 18 Image Processing and Recognition AZRIEL ROSENFELD Recent Progress in Computer Chess MONROE M. NEWBORN Advances in Software Science M. H. HALSTEAD Current Trends in Computer-Assisted Instruction PATRIC SUPPES Software in the Soviet Union: Progress and Problems S. E. GOODMAN Volume 19 Data Base Computers DAVID K. HSIAO The Structure of Parallel Algorithms H. T. KUNG Clustering Methodologies in Exploratory Data Analysis RICHARD DUBESAND A. K. JAIN Numerical Software: Science or Alchemy? C. W. GEAR Computing as Social Action: The Social Dynamics of Computing in Complex Organizations AND WALTSCACCHI ROBLING Volume 20 Management Information Systems: Evolution and Status GARYW. DICKSON Real-Time Distributed Computer Systems W. R. FRANTA. E. DOUGLAS JENSEN. R. Y.KAIN,AND GEORGE D. MARSHALL
CONTENTS OF VOLUMES IN THIS SERIES Architecture and Strategies for Local Networks: Examples and Important Systems K. J. THURBER Vector Computer Architecture and Processing Techniques KAIHWANG, SHUN-PlAO S U , AND LIONEL M. NI An Overview of High-Level Languages JEANE. SAMMET Volume 21 The Web of Computing: Computer Technology as Social Organization ROBKLINC AND WALT SCACCHI Computer Design and Description Languages SUBRATA DASGUFTA Microcomputers: Applications, Problems, and Promise ROBERT C. GAMMILL Query Optimization in Distributed Data Base Systems GIOVANNI MARIA SACCO AND s. BING Y A O Computers in the World of Chemistry PETERLYKOS Library Automation Systems and Networks JAMESE. RUSH Volume 22 Legal Protection of Software: A Survey MICHAEL C. GEMIGNANI Algorithms for Public Key Cryptosystems: Theory and Applications S. LAKSHMIVARAHAN Software Engineering Environments ANTHONY I. WASSERMAN Principles of Rule-Based Expert Systems BRUCEG. BUCHANAN AND RICHARD 0. DUDA Conceptual Representation of Medical Knowledge for Diagnosis by Computer: MDX and Related Systems B. CHANDRASEKARAN AND SANJAY MITTAL Specification and Implementation of Abstract Data Types AND SATISH THATTE ALFST. BERZTISS Volume 23 Supercomputers and VLSI: The Effect of Large-Scale Integration on Computer Architecture SNYDER LAWRENCE Information and Computation J. F. TRAUB AND H. WOZNIAKOWSKI The Mass Impact of Videogame Technology THOMAS A. DEFANTl Developments in Decision Support Systems AND ANDREW B. WHINSTON ROBERT H. BONCZEK, CLYDEW. HOLSAPPLE, Digital Control Systems k T E R DORATO AND DANIEL PETERSEN
303
304
CONTENTS OF VOLUMES IN THIS SERIES
International Developments in Information Privacy G. K. GUITA Parallel Sorting Algorithms S. LAKSHMIVARAHAN, SUDARSHAN K. DHALL,AND LESLIE L. MILLER Volume 24 Software Effort Estimation and Productivity S. D. CONTE,H. E. DUNSMORE, AND V. Y. SHEN Theoretical Issues Concerning Protection in Operating Systems MICHAEL A. HARRISON Developments in Firmware Engineering AND BRUCE D. SHRIVER SUBRATA DASGUITA The Logic of Learning: A Basis for Pattern Recognition and for Improvement of Performance RANAN B. BANERJI The Current State of Language Data Processing PAULL. GARVIN Advances in Information Retrieval: Where Is That /#*&@g Record? H. KRAFT DONALD The Development of Computer Science Education WILLIAM F. ATCHISON Volume 25 Accessing Knowledge through Natural Language AND GORDON MCCALLA NICKCERCONE Design Analysis and Performance Evaluation Methodologies for Database Computers K. HSIAO,AND PAULA R. STRAWSER STEVEN A. DEMURJIAN. DAVID Partitioning of Massivemeal-Time Programs for Parallel Processing I. LEE,N. PRYWES, A N D B. SZYMANSKI Computers in High-Energy Physics MICHAEL METCALF Social Dimensions of Office Automation ABBEMOWSHOWITZ Volume 26 The Explicit Support of Human Reasoning in Decision Support Systems AMITAVA DUTTA Unary Processing A. DOLLAS, J. B. GLICKMAN, AND C. O’TOOLE W. J. POPPELBAUM, Parallel Algorithms for Some Computational Problems AND s. SITHARAMA IYENCAR ABHAMOITRA Multistage Interconnection Networks for Multiprocessor Systems S. C. KOTHARI Fault-Tolerant Computing WINGN. TOY Techniques and Issues in Testing and Validation of VLSI Systems H. K. REOHBATI
CONTENTS OF VOLUMES IN THIS SERIES
305
Software Testing and Verification LEEJ. WHITE Issues in the Development of Large. Distributed, and Reliable Software c. v . RAMAMOORTHY, ATULPRAKASH, VlJAY GARG,TSUNEO YAMAUKA, AND ANUPAM BHIDE
Volume 27 Military Information Processing JAMESSTARK DRAPER Multidimensional Data Structures: Review and Outlook S. SITHARAMA IYENGAK,R. L. KASHYAP, V. K. VAISHNAVI, AND N. S. V. RAO Distributed Data Allocation Strategies ALANR. HEVNER AND ARUNA RAO A Reference Model for Mass Storage Systems STEPHEN W. MILLER Computers in the Health Sciences KEVIN c . O’KANE Computer Vision AZRIEL ROSENFELD Supercomputer Performance: The Theory, Practice, and Results OLAFM. LUBECK Computer Science and Information Technology in the People’s Republic of China: The Emergence of Connectivity JOHNH. MAIER
Volume 28 The Structure of Design Processes SUBRATA DASCUFTA Fuzzy Sets and Their Applications to Artificial Intelligence ABRAHAM KANDELAND MORDECHAY SCHNEIDER Parallel Architecture for Database Systems A. R. HURSON, L. L. MILLER, S. H. PAKZAD, M. H. EICH,AND B. SHIRAZI Optical and Optoelectronic Computing MIRSALEHI, MUSTAFA A. G. ABUSHAGUR, AND H. JOHNCAULFIELD MIRMOJTABA Management Intelligence Systems MANFRED KOCHEN
Volume 29 Models of Multilevel Computer Security JONATHAN K. MILLEN Evaluation, Description, and Invention: Paradigms for Human-Computer Interaction JOHN M. CARROLL Protocol Engineering MINCT. LIU Computer Chess: Ten Years of Significant Progress MONROE NEWBORN Soviet Computing in the 1980s RICHARD w . JUDYA N D ROBERT w. CLOUCH
CONTENTS OF VOLUMES IN THIS SERIES Volume 30 Specialized Parallel Architectures for Textual Databases A. R. HURSON, L. L.MILLER,s. H. PAKZAD, A N 0 JIA-BING CHENG Database Design and Performance MARKL. GILLENSON Software Reliability IANNINOAND JOHND. MUSA ANTHONY Cryptography Based Data Security GEORGE J. DAVIOA A N D Yvo DESMEDT Soviet Computing in the 1980s: A Survey of the Software and Its Applications w . CLOUGH RICHARD w . JUDYA N 0 ROBERT
Volume 31 Command and Control Information Systems Engineering: Progress and Prospects STEPHEN J. ANDRIOLE Perceptual Models for Automatic Speech Recognition Systems J. PALAKAL, AND PIERO COSI RENATO DEMORI,MATHEW Availability and Reliability Modeling for Computer Systems DAVID I. HEIMANN, NITINMITTAL,AND KISHOR S. TRIVEOI Molecular Computing MICHAEL CONRAD Foundations of Information Science ANTHONY DEBONS
Volume 32 Computer-Aided Logic Synthesis for VLSl Chips SABURO MUROGA Sensor-Driven Intelligent Robotics AND CHUXlN C H E N MOHAN M. TRIVEDI Multidatabase Systems: An Advanced Concept in Handling Distributed Data A. R. HURSON AND M. W. BRIGHT Models of the Mind and Machine: Information Flow and Control between Humans and Computers KENTL. NORMAN Computerized Voting ROYG. SALTMAN
Volume 33 Reusable Software Components BRUCE W. WEIDE,WILLIAM F. OGDEN, AND STUART H. ZWEBEN Object-Oriented Modeling and Discrete-Event Simulation BERNARD P. ZIEGLER Human-Factors Issues in Dialog Design A N D MARTIN HELANDER THIAGARAIAN PALANIVEL Neurocomputing Formalisms for Computational Learning and Machine Intelligence S. GULATI, J. BARHEN, AND S. S. IYENGAR
CONTENTS OF VOLUMES IN THIS SERIES Visualization in Scientific Computing THOMAS A. DEFANTl AND MAXINE D. BROWN Volume 34 An Assessment and Analysis of Software Reuse TEDJ. BIGGERSTAFF Multisensory Computer Vision AND J. K. AGGARWAL N. NANDHAKUMAR Parallel Computer Architectures RALPHDUNCAN Content-Addressable and Associative Memory LAWRENCE CHISVIN AND R. JAMES DUCKWORTH Image Database Management WILLIAM I. GROSKY AND RAJlV MEHROTRA Paradigmatic Influences on Information Systems Development Methodologies: Evolution and Conceptual Advances RUDYHIRSCHHEIM AND HEINZK. KLElN Volume 35 Conceptual and Logical Design of Relational Databases S. B. NAVATHE AND G. PERNUL Computational Approaches for Tactile Information Processing and Analysis HRISHIKESH P. GADAGKAR AND MOHAN M. TRlVEDl Object-Oriented System Development Methods ALANR. HEVNER Reverse Engineering JAMESH. CROSS11, ELLIOTJ. CHIKOFSKY, AND CHARLES H. MAY,JR. Multiprocessing CHARLES J. FLECKENSTEIN, D. H. GILL, DAVID HEMMENDINGER, C. L. MCCREARY, JOHND. MCGREGOR, ROY P. PARGAS, ARTHUR M. RIEHL, AND VIRGIL WALLENTINE The Landscape of International Computing AND HSlNCHUN CHEN EDWARD M. ROCHE,SEYMOUR E. GOODMAN, Volume 36 Zero Defect Software: Cleanroom Engineering HARLAN D. M i u s Role of Verification in the Software Specification Process MARVIN V. ZELKOWITZ Computer Applications in Music Composition and Research GARYE. WITTLICH, ERIC J. ISAACSON, AND JEFFREY E. HASS Artificial Neural Networks in Control Applications v . VEMURI Developments in Uncertainty-Based Information J. KLlR GEORGE Human Factors in Human-Computer System Design MARYCAROL DAYAND SUSAN J. BOYCE
307
308
CONTENTS OF VOLUMES IN THIS SERIES
Volume 31 Approaches to Automatic Programming C. WATERS CHARLES RICHA N D RICHARD Digital Signal Processing K. HARMS STEPHEN A. DYERAND BRIAN Neural Networks for Pattern Recognition S. C. KOTHARI A N D HEEKUCK OH Experiments in Computational Heuristics and Their Lessons for Software and Knowledge Engineering JURGNIEVERGELT High-Level Synthesis of Digital Circuits GIOVANNI DE MICHELI Issues in Dataflow Computing BENLEEAND A. R. HURSON A Sociological History of the Neural Network Controversy MIKELOLAZARAN Volume 38 Database Security GUNTHER PERNUL Functional Representation and Causal Processes B.~HANDRASEKARAN Computer-Based Medical Systems JOHNM. LONG Algorithm-Specific Parallel Processing with Linear Processor Arrays W. WAH,WEIJASHANG, AND KUMAR N. GANAPATHY JOSEA. B. FORTES,BENJAMIN Information as a Commodity: Assessment of Market Value ABBEMOWSHOWITZ Volume 39 Maintenance and Evolution of Software Products VON MAYRHAUSER ANNELIESE Software Measurement: A Decision-Process Approach WARREN HARRISON Active Databases: Concepts and Design Support THOMAS A. MUECK Operating Systems Enhancements for Distributed Shared Memory Lo VIRGINIA The Social Design of Worklife with Computers and Networks: A Natural Systems Perspective ROBKLINGAND TOMJEWETT Volume 40 Program Understanding: Models and Experiments AND A. M. VANS A. VON MAYRHAUSER Software Prototyping ALANM. DAVIS
CONTENTS OF VOLUMES IN THIS SERIES
309
Rapid Prototyping of Microelectronic Systems A N D J. D. STERLING BABCOCK AWSTOLOS DOLLAS Cache Coherence in Multiprocessors: A Survey AND C. R. DAS MAZINS. YOUSIF,M. J. THAZHUTHAVEETIL, The Adequacy of Office Models S. AMARAVADI, JOEYF. GEORGE, OLIVIA R. Liu SHENG, AND JAY F. NUNAMAKER CHANDRA
Volume 41 Directions in Software Process Research H. DIETERROMBACH A N D MARTIN VERLAGE The Experience Factory and Its Relationship to Other Quality Approaches VICTOR R. BASIL1 CASE Adoption: A Process, Not an Event JOCKA. RADER On the Necessary Conditions for the Composition of lntegrated Software Engineering Environments J. CARNEY A N D ALAN W. BROWN DAVID Software Quality, Software Process, and Software Testing DICKHAMLET Advances in Benchmarking Techniques: New Standards and Quantitative Metrics W. Hwu THOMAS CONTEAND WEN-MEI An Evolutionary Path for Transaction Processing Systems F. CHEN CARLTON Pu, AVRAHAM LEFF,AND SHU-WEI
Volume 42 Nonfunctional Requirements of Real-Time Systems G. KIRNER AND ALAN M. DAVIS TEREZA A Review of Software Inspections VOTTA ADAMPORTER, HARVEY SIY,AND LAWRENCE Advances in Software Reliability Engineering JOHND. MUSAAND WILLAEHRLICH Network Interconnection and Protocol Conversion MINGT. LIU A Universal Model of Legged Locomotion Gaits S. T. VENKATARAMAN
Volume 43 Program Slicing DAVID w. BINKLEY AND KEITH BRIAN GALLAGHER Language Features for the Interconnection of Software Components RENATE MOTSCHNIG-PITRIKAND ROLAND T. MITTERMEIR Using Model Checking to Analyze Requirements and Designs AND JOHNGANNON JOANNE ATLEE.MARSHA CHECHIK. Information Technology and Productivity: A Review of the Literature A N D SHINKYU YANG ERIKBRYNJOLFSSON The Complexity of Problems GASARCH WILLIAM 3-D Computer Vision Using Structured Light: Design, Calibration, and Implementation Issues AND MOHAN M. TRIVEDI FREDW. DEPIERO
This Page Intentionally Left Blank
